On Sun, Apr 30, 2017 at 2:01 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > 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? > There's the tiny issue that get_uuid also returns the offset of the uuid on disk. Not sure how much that really matters for PNFS? Amir. -- 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
