[Top] [All Lists]

Re: xfsdump INTERRUPT issue

To: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
Subject: Re: xfsdump INTERRUPT issue
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sat, 8 Dec 2012 09:58:55 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <50C259F9.2050406@xxxxxxxxxxxxxxxxx>
References: <CCE505AA.B05B7%jellis@xxxxxxxx> <50BFF726.6090006@xxxxxxxxxxxxxxxxx> <68036B67-6AE6-4056-89F5-9549B4E476FD@xxxxxxxx> <50C00583.6000804@xxxxxxxxxxxxxxxxx> <6F909666-9DFE-43F1-973D-170B892F9C5B@xxxxxxxxx> <50C0657D.5050903@xxxxxxxxxxxxxxxxx> <20121207101620.GK27172@dastard> <50C259F9.2050406@xxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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.


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>