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
>>> Signed-off-by: Bill Kendall <wkendall@xxxxxxx>
>> Lachlan reviewed and ack'd this on an internal list and I've committed
>> it (on Bill's behalf) as follows :
>> commit 9502587dbbfdd465958889a568dc2842f10b1ff9
>> Author: Mark Goodwin <markgw@xxxxxxx>
>> 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
> 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.:
> 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.
> 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
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
>> In any case, Christoph, please pull these commits into your kernel.org
>> -dev trees.
> NACK. Lets do a proper review cycle first.