Re: [PATCH 1/5] vfs: vfs-level fiemap interface

[Joel Becker <Joel.Becker@oracle.com>]

On Wed, May 28, 2008 at 10:09:52AM -0600, Andreas Dilger wrote:
> On May 27, 2008  11:31 -0700, Mark Fasheh wrote:
> > I hope that when we add new feature flags to fiemap, we take the time to
> > do it right and add it to FIEMAP_FLAGS_COMPAT, which is defined in the same
> > header for that reason. Likewise, we can't just add flags in any case
> > without considering how they affect existing users of ->fiemap. If we add a
> > flag that everyone can implement for example, we'll have to touch all file
> > systems anyway.
> 
> Well, the problem is that older kernel will not have the most current
> upstream FIEMAP_FLAGS_COMPAT, and short of patching the kernel to change
> this ONE value (which we've worked for a long time to not do on the
> client) there is no way that support for additional upstream flags can
> be added.

...

> But the problem is that people are error prone in their updating of code,
> and if the filesystems assume "the VFS has checked all of the flags except
> this one I don't understand" will likely become incorrect over time as
> someone will forget, will misunderstand whether the different per-fs codes
> need to be updated, or some patch will be delayed in a FS maintainer queue
> while the VFS "acceptance" of the new feature will be included upstream.

	This is a specious argument - if it doesn't go upstream, we
then have the overloaded-flag problem.  If you're looking for vendor
flags, let's just design a space for them.
 
> The issue is that most users don't have the latest upstream kernel
> because they are using a vendor kernel that is a few years old, as you
> likely know, but an updated Lustre or OCFS2 or btrfs should work with
> the existing vendor kernels.
> 
> If we wanted to add something like FIEMAP_FLAG_METADATA, if the check
> was done in the VFS, it would be impossible without patching the client
> even if it exactly matched the upstream kernel implementation.

	First, getting vendor kernels to update a supported flag set
that is already in mainline is pretty easy.  They are rightly interested
in following a well-defined interface, which is what Mark's trying to do
- no filesystems supporting flags that aren't part of the well-defined
interface.
	But if you are really worried about no kernel updates when you
install a new fs module, you can still solve it with a generic check.
Just add /proc/sys/fs/fiemap-flag-mask.  This covers any new flags for
the generic VFS check.  Alternately, allow filesystems to register their
flags and then do the VFS check based on that.

Joel

-- 

"What do you take me for, an idiot?"  
        - General Charles de Gaulle, when a journalist asked him
          if he was happy.

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127