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@xxxxxxxxxx
Phone: (650) 506-8127
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
