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

From: Bill Kendall <wkendall@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs-dev <xfs-dev@sgi.com>, xfs@oss.sgi.com
Subject: Re: [PATCH] xfsdump support for 64K page size
Date: Thu, 15 Jan 2009 12:59:24 -0600	[thread overview]
Message-ID: <496F878C.80905@sgi.com> (raw)
In-Reply-To: <20090114224857.GA8071@disturbed>

On 01/14/2009 04:48 PM, Dave Chinner wrote:
> 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)?

I don't think so, or at least I'm not making the connection. HNKSZ
need only be large enough to contain at least one seg_t plus the
bookkeeping info in a hnk_t. Lookups are more efficient with a few
large hunks compared to many small ones though, and since the list
of hunks will be memory mapped it made sense to make HNKSZ at least
as large as a page (the granularity of a mmap operation, IIRC).

Now with 64K pages, inomap lookups could be made more efficient by
increasing HNKSZ, but at the expense of breaking the dump format.
If/when it is okay to do that, I think it would be simpler to do
away with the list of hnk_t's, and just have a single array (or
other container) with all the seg_t's.

> 
> 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?

Good point about PGSZ being variable. Since HNKSZ must remain constant
to keep the dump format unchanged, that implies it should not be based
on PGSZ. At a quick glance I see that other structures in the dump format
are based on PGSZ as well, so really the whole use of PGSZ needs to be
reviewed.

Bill

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