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: J. Bruce Fields on 7 Jul 2010 11:10 On Wed, Jul 07, 2010 at 01:40:53AM -0600, Andreas Dilger wrote: > On 2010-07-06, at 11:09, Aneesh Kumar K. V wrote: > > On Tue, 6 Jul 2010 12:10:02 -0400, "J. Bruce Fields" <bfields(a)fieldses.org> wrote: > >> ... 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. > > Won't having it be in a separate system call be racy w.r.t. doing the pathname lookup twice? It'll be rare that a server will want to *just* get a filehandle; normally it will at least want to get some attributes at the same time. So I think it will always need to open the file first and then do the rest of the operations on the returned filehandle. --b. -- 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: J. Bruce Fields on 7 Jul 2010 12:40 On Wed, Jul 07, 2010 at 10:03:39PM +0530, Aneesh Kumar K. V wrote: > On Wed, 7 Jul 2010 10:45:11 -0400, "J. Bruce Fields" <bfields(a)fieldses.org> wrote: > > On Wed, Jul 07, 2010 at 03:35:50PM +0200, Miklos Szeredi wrote: > > > On Wed, 7 Jul 2010, J. Bruce Fields wrote: > > > > > > If you use sys or proc, is it possible to get the uuid from a file > > > > > > descriptor or pathname without races? > > > > > > > > > > You can do stat/fstat to find out the device number (which is unique, > > > > > but not persistent) > > > > > > > > Is it really unique over time? (Can't a given st_dev value map to one > > > > filesystem now, and another later?) > > > > > > It's unique at a single point in time. But if you have a reference > > > (e.g. open file descriptor) on the mount then that's not a problem. > > > > > > fd = open(path, ...); > > > fstat(fd, &st); > > > search st.st_dev in mountinfo > > > close(fd) > > > > > > is effectively the same as an getuuid(path) syscall (lazy unmounted > > > filesystems will not be found in mountinfo, but the reference is still > > > there so st_dev will not be reused for other filesystems). > > > > OK, cool. > > > > That still leaves the problem that there isn't always an underlying > > block device, and/or when there is it doesn't always uniquely specify > > the filesystem. > > > > And for this reason we would need this as a syscall right ? That's the only solution I see. (Or use an xattr?) --b. -- 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: J. Bruce Fields on 7 Jul 2010 13:40 On Wed, Jul 07, 2010 at 11:02:47AM -0600, Andreas Dilger wrote: > On 2010-07-07, at 09:05, J. Bruce Fields wrote: > > On Wed, Jul 07, 2010 at 01:40:53AM -0600, Andreas Dilger wrote: > >> On 2010-07-06, at 11:09, Aneesh Kumar K. V wrote: > >>> 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. > >> > >> Won't having it be in a separate system call be racy w.r.t. doing the pathname lookup twice? > > > > It'll be rare that a server will want to *just* get a filehandle; > > normally it will at least want to get some attributes at the same time. > > So I think it will always need to open the file first and then do the > > rest of the operations on the returned filehandle. > > I think you are assuming too much about the use of the file handle. What I'm interested in is not a userspace file server, but rather a more efficient way to have 10000's to millions of clients to be able to open the same regular file, without having to do full path traversal for each one. Understood. I don't understand how that case decides the question of whether to use a separate system call for the uuid or not? Those millions of clients are doing the filehandle-to-file-descriptor mapping, not the reverse. And you may not need any uuid at all since the clients probably all have some way of knowing which shared filesystem they want to work with. > >>> That still leaves the problem that there isn't always an > >>> underlying block device, and/or when there is it doesn't always > >>> uniquely specify the filesystem. > >> > >> And for this reason we would need this as a syscall right ? > > > > That's the only solution I see. (Or use an xattr?) > > Or... return the UUID as part of the file handle in the first place. > That avoids races, avoids adding more syscalls that have to be called > for each file handle, I don't hate the idea. A uuid lookup seems like a useful thing, though, and maybe less expensive, so it seems weird if the only way to get the uuid is by looking up the filehandle as well. > or IMNSHO the worst proposal that requires > applications to parse a text file in some obscure path for each file > handle (requiring a stat() to find the major/minor device of the file, > walking through /proc or /sys, and other nastiness). OK. --b. -- 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: Nick Piggin on 7 Jul 2010 14:10 On Wed, Jul 07, 2010 at 11:02:47AM -0600, Andreas Dilger wrote: > On 2010-07-07, at 09:05, J. Bruce Fields wrote: > > On Wed, Jul 07, 2010 at 01:40:53AM -0600, Andreas Dilger wrote: > >> On 2010-07-06, at 11:09, Aneesh Kumar K. V wrote: > >>> 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. > >> > >> Won't having it be in a separate system call be racy w.r.t. doing the pathname lookup twice? > > > > It'll be rare that a server will want to *just* get a filehandle; > > normally it will at least want to get some attributes at the same time. > > So I think it will always need to open the file first and then do the > > rest of the operations on the returned filehandle. > > I think you are assuming too much about the use of the file handle. What I'm interested in is not a userspace file server, but rather a more efficient way to have 10000's to millions of clients to be able to open the same regular file, without having to do full path traversal for each one. Really? What kind of clients? What sort of speedups do you hope to see? Path traversal can get vastly cheaper in both single threaded and parallel cases with my locking changes. It is not acceptable to work around fixable deficiencies in our critical infrastructure like path walking with hacks like this. If path walking is still much too expensive, that's another story... -- 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: Alan Cox on 7 Jul 2010 16:40
> I think you are assuming too much about the use of the file handle. What I'm interested in is not a userspace file server, but rather a more efficient way to have 10000's to millions of clients to be able to open the same regular file, without having to do full path traversal for each one. The unix security model requires the traversal. In that respect it differs significantly from some other OS's that did have handle based direct opens and treat directories as a lookup and translation index only. -- 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/ |