On Tue, Sep 16, 2008 at 05:31:07PM -0400, Theodore Tso wrote:

On Mon, Sep 15, 2008 at 10:53:05AM -0700, Mark Fasheh wrote:

quoted

On Mon, Sep 15, 2008 at 10:49:48AM -0400, Christoph Hellwig wrote:

quoted

I agree to you (or someone elses - don't remember anymore) suggestion
to put in more padding so we can add fields later.  I strongly disagree
putting in features now that we neither have a user, nor a usecase or
testcase for.

So, how about another 64 bits of padding in struct fiemap_extent? That could
help cover future uses like compression, which might require another 64 bit
offset field - we only have 32 bits of reserved space there right now.

What I'd recommend is a 56 byte structure:

Why not just make it 64 bytes? Sure, that's 8 extra bytes, but I find the
power-of-2 size (and the extra space) comforting. (AFAIK, slab allocators
will give you 64 bytes anyway; and I expect something similar on the
user-space side of things.)

...

Yeah, it's a little extra memory per extent, but filesystems seem to
always invent new things, and it seem spretty clear that we have at
least two extensions on deck (compression, multiple storage devices)
both of which have at least one implementation that are either in the
kernel or will likely enter the kernel.  So it's likely that there is
something that we may have missed, and leaving a little extra space
doesn't actually cost us that much.

Right.

Josef 'Jeff' Sipek.

-- 
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)