Generic name to handle and open by handle syscalls
in [Kernel]
|
Prev: linux-next: build failure after merge of the final tree (rr tree related)
Next: Generic name to handle and open by handle syscalls
From: Dave Chinner on 6 Jul 2010 19:30 On Tue, Jul 06, 2010 at 10:39:56PM +0530, Aneesh Kumar K. V wrote: > On Tue, 6 Jul 2010 12:10:02 -0400, "J. Bruce Fields" <bfields(a)fieldses.org> wrote: > > On Fri, Jul 02, 2010 at 02:45:45AM +0530, Aneesh Kumar K. V wrote: > > > One use case i had was that if the userspace file server can directly > > > work with the returned file system UUID, > > > > I agree that the uuid should be split out from the rest of the > > filehandle, but ... > > > > > the it can build the file > > > handle for client in a single call. > > > > ... I don't understand why both need to come in the same system call. > > Is it purely an efficiency question? If so, why do you expect this to > > be significant? > > Since we know that system wide file handle should include a file system > identifier and a file identifier my plan was to retrieve both in the > same syscall. > > > > > > (I would have thought that the system call overhead is so small, and so > > many calls will already be required to perform the typical rpc, that > > this would be insignificant.) > > > > A filesystem uuid seems like a generally useful thing (maybe more so > > than a filehandle), so it'd seem worth figuring out how to export that > > separately. > > > > I can add a new syscall that returns > > struct fs_uuid { > u8 fs_uuid[16]; > }; > > long sys_get_fs_uuid(int dfd, char *name, struct fs_uuid *fsid, int flag); libblkid already provides the UUID to userspace applications, doesn't it? Cheers, Dave. -- Dave Chinner david(a)fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Neil Brown on 6 Jul 2010 19:40 On Wed, 7 Jul 2010 09:23:51 +1000 Dave Chinner <david(a)fromorbit.com> wrote: > > I can add a new syscall that returns > > > > struct fs_uuid { > > u8 fs_uuid[16]; > > }; > > > > long sys_get_fs_uuid(int dfd, char *name, struct fs_uuid *fsid, int flag); > > libblkid already provides the UUID to userspace applications, doesn't it? Yes and no. libblkid provides the uuid of the thing that uses a block device. That doesn't directly map to "UUID of a filesystem". There are two types of filesystem that I can think of for which libblkid cannot give a uuid. - network filesystems (or virtual filesystems, or fuse ) - filesystems which share a block device, such as btrfs. btrfs can have 'subvols' - multiple "filesystems" within the one (set of) block device(s). libblkid cannot be asked about these different subvols. libblkid is useful, but not a real solution. NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dave Chinner on 6 Jul 2010 22:20 On Wed, Jul 07, 2010 at 09:36:29AM +1000, Neil Brown wrote: > On Wed, 7 Jul 2010 09:23:51 +1000 > Dave Chinner <david(a)fromorbit.com> wrote: > > > > I can add a new syscall that returns > > > > > > struct fs_uuid { > > > u8 fs_uuid[16]; > > > }; > > > > > > long sys_get_fs_uuid(int dfd, char *name, struct fs_uuid *fsid, int flag); > > > > libblkid already provides the UUID to userspace applications, doesn't it? > > Yes and no. > > libblkid provides the uuid of the thing that uses a block device. That > doesn't directly map to "UUID of a filesystem". True. > There are two types of filesystem that I can think of for which libblkid > cannot give a uuid. > - network filesystems (or virtual filesystems, or fuse ) How would you guarantee persistent uniqueness for such filesystems? > - filesystems which share a block device, such as btrfs. > btrfs can have 'subvols' - multiple "filesystems" within > the one (set of) block device(s). libblkid cannot be asked about these > different subvols. > > libblkid is useful, but not a real solution. So libblkid doesn't cover everything, but I think my question is still valid - if we want per-filesystem UUIDs, why a syscall and not just publishing it somewhere where we already publish per-mount information? e.g. in /proc/mounts? Cheers, Dave. -- Dave Chinner david(a)fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Neil Brown on 6 Jul 2010 23:00 On Wed, 7 Jul 2010 12:11:50 +1000 Dave Chinner <david(a)fromorbit.com> wrote: > On Wed, Jul 07, 2010 at 09:36:29AM +1000, Neil Brown wrote: > > On Wed, 7 Jul 2010 09:23:51 +1000 > > Dave Chinner <david(a)fromorbit.com> wrote: > > > > > > I can add a new syscall that returns > > > > > > > > struct fs_uuid { > > > > u8 fs_uuid[16]; > > > > }; > > > > > > > > long sys_get_fs_uuid(int dfd, char *name, struct fs_uuid *fsid, int flag); > > > > > > libblkid already provides the UUID to userspace applications, doesn't it? > > > > Yes and no. > > > > libblkid provides the uuid of the thing that uses a block device. That > > doesn't directly map to "UUID of a filesystem". > > True. > > > There are two types of filesystem that I can think of for which libblkid > > cannot give a uuid. > > - network filesystems (or virtual filesystems, or fuse ) > > How would you guarantee persistent uniqueness for such filesystems? Persistent shouldn't be too hard in many cases. What uniqueness guarantees do we have anyway? Mostly stochastic I expect. > > > - filesystems which share a block device, such as btrfs. > > btrfs can have 'subvols' - multiple "filesystems" within > > the one (set of) block device(s). libblkid cannot be asked about these > > different subvols. > > > > libblkid is useful, but not a real solution. > > So libblkid doesn't cover everything, but I think my question is > still valid - if we want per-filesystem UUIDs, why a syscall and not > just publishing it somewhere where we already publish per-mount > information? e.g. in /proc/mounts? The trouble with /proc/mounts is that it is somewhat clumsy to parse (remember to handle \0ctal escapes) and doesn't include major/minor number which is the primary key for identifying filesystems in Linux (see /sys/class/bdi/MAJOR:MINOR which is e.g. the best place to configure read-ahead for a filesystem). So /proc/mounts could work (and would probably be better than a new syscall) but I would really rather see something sane in /sys for inspecting/configuring filesystems (rather than each filesystem doing their own independent thing in /sys/fs). NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Miklos Szeredi on 7 Jul 2010 08:50
On Wed, 7 Jul 2010, Neil Brown wrote: > The trouble with /proc/mounts is that it is somewhat clumsy to parse > (remember to handle \0ctal escapes) and doesn't include major/minor number /proc/self/mountinfo does. And it's extensible, just add an "uuid:123" before the dash. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |