[Top] [All Lists]

Re: review: Simple patch to remove the dmapi support from xfsdump

To: Bill Kendall <wkendall@xxxxxxx>
Subject: Re: review: Simple patch to remove the dmapi support from xfsdump
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Fri, 04 Aug 2006 12:33:22 -0500
Cc: Dean Roehrich <dean.roehrich@xxxxxxx>, Russell Cattelan <cattelan@xxxxxxxxxxx>, Vlad Apostolov <vapo@xxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <44D379A6.9040200@sgi.com>
References: <44D10F9B.8090904@thebarn.com> <44D2CA85.3040208@sgi.com> <20060804141012.GA26@kickball-mn.Central.Sun.COM> <44D36985.1090006@thebarn.com> <20060804155850.GA3338@kickball-mn.Central.Sun.COM> <44D379A6.9040200@sgi.com>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird (Macintosh/20060719)
Bill Kendall wrote:
Dean Roehrich wrote:
On Fri, Aug 04, 2006 at 10:36:37AM -0500, Russell Cattelan wrote:

I appears as if the Hsm routines are only used if the -a flag is given to xfsdump.
(dump DMF dualstate files as offline)

If use of -a causes xfsdump to fail then that may be sufficient.

Then what? Each user (admittedly, this is a small number) has to rebuild
xfsdump locally, and then do so every time their package manager grabs
an updated xfsdump?

Well... if you're using SLES or ProPack or whatever, -a will work fine, when you get updates from your dmapi-supporting distro it will continue to work fine...

But if you're using fedora or whatnot, -a will return a (hopefully helpful) error message and quit, and if you -really- want to use dmapi, you'll have to build a custom kernel and dmapi userspace anyway. Rebuilding xfsprogs to go with it doesn't seem like too big a deal... In such a scenario you'd tell your package manager to exclude both kernel & xfsprogs.

Anyway, other proposals also seem reasonable, so I won't push this point too 
much :)


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