Re: [PATCH 0/5] VFS API for getting filesystem's UUID

[Dave Chinner <david@fromorbit.com>]

On Thu, Apr 27, 2017 at 11:59:29AM +0300, Amir Goldstein wrote:
> Miklos,
> 
> As you observed, the sb->s_uuid field is not always filled by filesystems.
> 
> Consumers, like overlayfs, that wish to use this field can check if is
> zeroed out as an indication for valid value.
> 
> Christoph suggested to make the test more explicit and require the
> filesystems that fill the s_uuid field to set a super block flag.
> 
> Do you agree with the proposed API?
> 
> The first patch in the series defines the flag.
> If you push this patch through your tree to Al or Linus, then filesystem
> maintainers could later pick the individual patches to their trees.
> 
> The xfs patch is based on a patch I already sent to Darrick for filling
> out the s_uuid field.
> 
> Thanks,
> Amir.
> 
> Amir Goldstein (5):
>   vfs: define a flag to indicate sb->s_uuid is available
>   ext4: set the super block SB_I_HAVE_UUID flag
>   f2fs: set the super block SB_I_HAVE_UUID flag
>   ocfs2: set the super block SB_I_HAVE_UUID flag
>   xfs: set the super block SB_I_HAVE_UUID flag
> 
>  fs/ext4/super.c    | 1 +
>  fs/f2fs/super.c    | 1 +
>  fs/ocfs2/super.c   | 1 +
>  fs/xfs/xfs_mount.c | 1 +
>  include/linux/fs.h | 3 +++
>  5 files changed, 7 insertions(+)

Doesn't this make the struct export_opierations .get_uuid method
somewhat redundant?  Shouldn't that now be replaced with generic
functions that looks at SB_I_HAVE_UUID before allowing PNFS export
is allowed and then just use s_uuid directly in the PNFS code?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com