[Top] [All Lists]

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

To: Bill Kendall <wkendall@xxxxxxx>
Subject: Re: [PATCH] xfsdump support for 64K page size
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 15 Jan 2009 09:48:57 +1100
Cc: Mark Goodwin <markgw@xxxxxxx>, xfs-dev <xfs-dev@xxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <4967A73E.9020907@xxxxxxx>
Mail-followup-to: Bill Kendall <wkendall@xxxxxxx>, Mark Goodwin <markgw@xxxxxxx>, xfs-dev <xfs-dev@xxxxxxx>, xfs@xxxxxxxxxxx
References: <4964C5EF.3060308@xxxxxxx> <4965629C.2000703@xxxxxxx> <20090108222800.GG9448@disturbed> <4967A73E.9020907@xxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
On Fri, Jan 09, 2009 at 01:36:30PM -0600, Bill Kendall wrote:
> Dave Chinner wrote:
> > 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.:
> Right, only difference is that I removed the asserts rather than
> just having them commented out. In my determination the asserts
> are totally bogus -- there isn't a dependency on the system's
> page size in the inomap code.


> The inomap code uses xfsdump's PGSZ variable, which is fixed at 4K.
> There's no dependency here on the system's actual page size. I was
> able to dump and then restore on a system with a different page size.

Ok, that looks fine. however, there is a dependency that HNKSZ >=
PGSZ, right? And that is currently hardwired to (4 * PGSZ)?

And given that the intent of the PGSZ was to be made variable at
some point, isn't this really trying to ensure that HNKSZ is always
greater than the PGSZ the program was built with?


Dave Chinner

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