Re: xfsdump INTERRUPT issue

[Dave Chinner <david@fromorbit.com>]

On Fri, Dec 07, 2012 at 05:26:12PM -0600, Stan Hoeppner wrote:
> On 12/7/2012 4:58 PM, Dave Chinner wrote:
> > On Fri, Dec 07, 2012 at 03:04:57PM -0600, Stan Hoeppner wrote:
> >> On 12/7/2012 4:16 AM, Dave Chinner wrote:
> >>> On Thu, Dec 06, 2012 at 03:29:33AM -0600, Stan Hoeppner wrote:
> >>>> On 12/5/2012 9:01 PM, Jeffrey Ellis wrote:
> >>>> BTW, if your goal in all of this is simply copying all the directories
> >>>> and files from one disk to another disk, you could have used "cp -a" and
> >>>> been done already.  It takes longer to execute than xfsdump/xfsrestore,
> >>>> but given you've been at this for many days now, "cp -a" would have
> >>>> already completed--long ago.
> >>>
> >>> Unfortunately, using cp or rsync is not possible because the
> >>> filesystem has a real-time device attached to it. It's basically a
> >>> ~10GB data device and a ~500GB real-time device. I'd say it's from a
> >>> DVR or something like that, and that Jeffrey is trying to put
> >>> a bigger disk in the DVR....
> >>
> >> Ah, yes.  I didn't catch the RT volume.
> >>
> >> Incidentally, since the real-time feature has never been fully supported
> >> under Linux, why are DVR manufacturers even using it?  Without GRIO and
> >> the XBOW ASIC the real-time volume is pretty much useless isn't it?
> > 
> > The realtime volume actually has nothing to do with "real-time" at
> > all. What it has is a deterministic allocator (bitmap rather than
> > tree based) which is what you need for real-time applications (i.e.
> > bound worst case performance). It got called the "real-time device"
> > because of the applications it was used for, not because there is
> > anything "real-time" about it.  IOWs, you don't need special
> > hardware to take advantage of the properties of the allocator.
> > 
> > DVR manufacturers have decided to use it for 3 reasons:
> > 
> > 	1. Folklore says you need a RT device for
> > 	   concurrent streaming workloads
> > 	2. It's supported upstream
> 
> Define "support" and "upstream".  The few RT related posts over the past
> years generated responses, some from you I think, that the RT code isn't
> maintained, hasn't been for a long time.  Maybe I've misunderstood.

We've found that over the past few years that there have been a lot
of "silent users". While we don't actively develop/improve the RT
functionality, maintenance still takes place. That is, we take they
patches for the bugs users find and we try not to introduce new bugs
as we change stuff.  And I do run xfstests with realtime devices
every so often - it's just not a high priority.

IOWs, if a vendor wants to ship a product based on the real-time
functionality, then that is their choice. It is also their
responsibility to ensure what they ship is fit for purpose, which is
why they have their own QA.... :)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs