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@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
