Re: xfsdump INTERRUPT issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
	3. It makes it hard for windows users to replace the
	   harddisk in the DVR by themselves (true).

#3 is the case we are seeing here.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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


[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux