On Sun, Sep 14, 2008 at 01:58:10PM -0400, Theodore Tso wrote:

On Sun, Sep 14, 2008 at 09:48:59AM -0400, Christoph Hellwig wrote:

quoted

Let's make it clear, I've said to not add it unless we have users.  And
What Anton brought up is exactly the reason for that - to support
encrypted extents we actually need more information in the structure.
That's why we need to have this broad and sometimes a little slow
discussion on fsdevel instead of just rushing in some flag for future
use that won't make any sense in the end.

You're incorrect here.  Encrypted extents does not require any
additional information in the structure.  Compressed extents are a bit
more useful if we allow the the filesystem to return the amount of
space used on the storage device,

Sorry, should have written compressed and not encrypted above.

cramfs).  But that being said, the fundamental question here is
whether we should try to plan for future users of the data structure,
and reserve space now for the, or not.  Your approach of saying Nein!
Nein!  Nein! for every single feature where we don't have
implementation pretty much guarantees that we will need to expand the
structure later to make room for these extra fields, and then we'll
need to define a new ioctl and have similar complexity to the stat
system call to support multiple userspace interfaces.  If we try to
anticipate new users in advance, then there is at least a *chance*
we'll get it right up front.

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.