On Wed, Dec 08, 2010 at 09:41:33PM -0700, Andreas Dilger wrote: > On 2010-12-08, at 16:07, Neil Brown wrote: > > On Mon, 6 Dec 2010 11:48:45 -0500 "J. Bruce Fields" <[email protected]> > > 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.
Well, the kernel can't distinguish the case of an explicit "uuid=" option in /etc/exports from one that was (as is the normal default) generated automatically by mountd. Maybe not a big deal. The uuid seems like a useful thing to have access to from userspace anyway, for userspace nfs servers if for no other reason: > 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 I can't see anything wrong with that. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
