On 2010-03-29, at 01:12, Aneesh Kumar K. V wrote:
As per the private email exchanges we had on this, do you agree that wewould need the vfsmount to successfully open a file by handle ? If yeswe would need to specify the mount point via mountfd. In that case do weneed the handle returned by kernel to be system wide unique ? We can build uniqueness in the userspace based on the mountfd and that also enables us to use different field width for file systemidentifier. So rather than forcing the usage of uuid, userspace can now decided to use a fsid that is smaller and that uniquely identify only thevfsmounts that the NFS server is exporting ?
To my thinking, forcing userspace to distinguish this is the wrong place to do it. There are a number of uses for this, such as the checkpoint/restart that was discussed on another thread, that could benefit from having consistent filehandles.
The other thing I've long wanted in-kernel identifiers for is jbd/jbd2 being able to share a single journal among multiple filesystems. At one time I was going to make a special-case jbd2 filesystem that contains these identifiers, but having globally-unique filehandles available in the kernel would be even better. That would allow an ext4 instance to get the journal UUID + an agreed-upon filehandle to locate the journal at mount time.
+static struct super_block *fs_get_sb(__kernel_fsid_t *fsid)
+{
+ while (fs_type) {
+ list_for_each_entry(sb, &fs_type->fs_supers, s_instances) {
+ this_fsid = sb->get_fsid();
Rather than walking all of the filesystem, this seems exactly the place to use a hash table to avoid O(n^2) behaviour when mounting hundreds/thousands of filesystems (which happens in some cases).
Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- 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
