Messages in this thread | | | From | "Aneesh Kumar K. V" <> | Subject | Re: [PATCH -V14 0/11] Generic name to handle and open by handle syscalls | Date | Wed, 07 Jul 2010 23:48:51 +0530 |
| |
On Wed, 7 Jul 2010 11:02:47 -0600, Andreas Dilger <andreas.dilger@oracle.com> 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.
With the suggested syscall approach we can do on the client that does the path traversal.
fd = open(name) file_identifier = fd_to_handle(fd); fs_identifier = fd_to_fshandle(fd); close(fd);
> > >>> 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, 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).
I would also like to get both file system identifier and file identifier in a single call.
That would also imply instead of the above sequence of 4 calls, we can do
file_handle = name_to_handle(name);
-aneesh
| |