On 2010-12-08, at 16:07, Neil Brown wrote: > On Mon, 6 Dec 2010 11:48:45 -0500 "J. Bruce Fields" <bfields@xxxxxxxxxx> > wrote: > >> On Fri, Dec 03, 2010 at 04:01:44PM -0700, Andreas Dilger wrote: >>> Any chance we can add a ->get_fsid(sb, inode) method to >>> export_operations (or something simiar), that allows the >>> filesystem to generate an FSID based on the volume and >>> inode that is being exported? >> >> No objection from here. > > My standard objection here is that you cannot guarantee that the > fsid is 100% guarantied to be unique across all filesystems in > the system (including filesystems mounted from dm snapshots of > filesystems that are currently mounted). NFSd needs this uniqueness. Sure, but you also cannot guarantee that the devno is constant across reboots, yet NFS continues to use this much-less-constant value... > This is only really an objection if user-space cannot over-ride > the fsid provided by the filesystem. Agreed. It definitely makes sense to allow this, for whatever strange circumstances might arise. However, defaulting to using the filesystem UUID definitely makes the most sense, and looking at the nfs-utils mountd code, it seems that this is already standard behaviour for local block devices (excluding "btrfs" filesystems). > I'd be very happy to see an interface to user-space whereby > user-space can get a reasonably unique fsid for a given > filesystem. Hmm, maybe I'm missing something, but why does userspace need to be able to get this value? I would think that nfsd gets it from the filesystem directly in the kernel, but if a "uuid=" option is present in the exports file that is preferentially used over the value from the filesystem. That said, I think Aneesh's open_by_handle patchset also made the UUID visible in /proc/<pid>/mountinfo, after the filesystems stored it in sb->s_uuid at mount time. That _should_ make it visible for non-block mountpoints as well, assuming they fill in s_uuid. > Whether this is an export_operations method or some field in the > 'struct super' which gets copied out doesn't matter to me. Since Aneesh has already developed patches, is there any objection to using those (last sent to linux-fsdevel on 2010-10-29): [PATCH -V22 12/14] vfs: Export file system uuid via /proc/<pid>/mountinfo [PATCH -V22 13/14] ext3: Copy fs UUID to superblock. [PATCH -V22 14/14] ext4: Copy fs UUID to superblock Cheers, Andreas -- 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
