Re: [PATCH] xfsdump support for 64K page size

[Eric Sandeen <sandeen@sandeen.net>]

Dave Chinner wrote:
> On Thu, Jan 08, 2009 at 01:19:08PM +1100, Mark Goodwin wrote:
>> Bill Kendall wrote:
>>> Various fixes to allow xfsdump/xfsrestore to work with 64K
>>> page size. This is essentially Chinner's patch from a while
>>> back.
>>>
>>> Signed-off-by: Bill Kendall <wkendall@sgi.com>
>> Lachlan reviewed and ack'd this on an internal list and I've committed
>> it (on Bill's behalf) as follows :
>>
>> git://oss.sgi.com/xfs/cmds/xfsdump.git
>> 	commit 9502587dbbfdd465958889a568dc2842f10b1ff9
>> 	Author: Mark Goodwin <markgw@sgi.com>
>> 	Date:   Thu Jan 8 12:37:53 2009 +1100
>>
>> 	    Various fixes to allow xfsdump/xfsrestore to work with 64K
>> 	    page size. This is essentially Chinner's patch from a while
>> 	    back.
> 
> I guess I don't have a real name ;)
> 
> BTW, these changes are the *exact* patches I sent back in March.
> I note that the change logs from those patches have been dropped
> on the floor. i.e.:
> 
> http://oss.sgi.com/archives/xfs/2008-05/msg00339.html
> 
> The extended attr buffer size used by xfsdump is based on page size.
> The maximum buffer size the kernel will accept is 64k. On a 64k page
> machine, the default buffer size will be rejected by the kernel,
> thereby breaking dump and restore.
> 
> Limit the buffer size to XATTR_LIST_MAX in dump, restore and
> libhandle so the kernel won't reject otherwise valid requests.

Christoph pointed out on that thread that this define is linux-kernel
specific, so should probably be in an #ifdef, #else, too.

> ----
> 
> http://oss.sgi.com/archives/xfs/2008-05/msg00340.html
> 
> xfsrestore has assumptions about page size built into the inode hunk
> size in the dump format. Seems to be a stupid thing to do - this
> patch simply comments out the asserts to allow it to work on
> 64k page size machine, but probably subtly breaks the code.
> Nasty hack, really, but allows xfsqa tests to pass.

Heh, I totally missed this and arrived at it independently, and hackily
as well:

http://oss.sgi.com/bugzilla/show_bug.cgi?id=799

but I'm not sure that counts as review; hopefully Bill confirmed that
this is safe?

> ----
> 
> I'd also like to know what validation has been done of the second
> patch. e.g. is it going to break when dump and restore are done on
> machines of different page size? This is why I didn't sign-off on
> the second patch....

*nod* - there is a "standard" dumpfile as part of xfsqa, so at least I
know it does properly restore that, still.  But has anything tested the
other direction?

-Eric

>> In any case, Christoph, please pull these commits into your kernel.org 
>> -dev trees.
> 
> NACK. Lets do a proper review cycle first.
> 
> Cheers,
> 
> Dave.

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