On Thu, May 29, 2008 at 05:46:48PM -0600, Andreas Dilger wrote:
> > If you're looking for vendor flags, let's just design a space for them.
>
> By no means am I looking for "private" flags or adding support for flags
> that don't exist upstream (assuming it is reasonable to get new flags
> upstream). What I'm specifically concerned about is being able to support
> new features that are properly accepted upstream in Lustre built against
> older vendor kernels. We are trying to get out of the kernel-patching
> days because customers aren't willing to void their kernel or 3rd-party
> application support by running a patched kernel on the client.
So, how about we just put the flag checks in a helper function which the fs
calls. It would take as arguments, the fiemap_extent_info struct and set of
flags which the fs supports. That would allow backported modules to plug in
their own check, but we retain the niceness of having the checks in a
central place for in-tree file systems.
int fiemap_check_flags(struct fiemap_extent_info fieinfo, u32 fs_flags)
{
u32 incompat_flags;
incompat_flags = fieinfo.fi_flags & ~(FIEMAP_FLAGS_COMPAT & fs_flags);
if (incompat_flags) {
fieinfo->fi_flags = incompat_flags;
return -EBADR;
}
return 0;
}
> > 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.
>
> If you are suggesting that the filesystems all export their "supported
> flags" mask somewhere, and the VFS uses that for a check, then yes I agree
> it would be possible to do. I don't see a huge benefit of that over just
> letting the filesystems do it directly themselves at that point. Adding a
> /proc or /sys or /debugfs tunable for this seems heavyweight, and needs
> a sysctl or other setting on each boot - a pain for diskless clients.
Yeah, I agree that it's total overkill.
--Mark
--
Mark Fasheh
--
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
