On Sat, May 15, 2010 at 11:01:13AM +0530, Aneesh Kumar K. V wrote: > We need to have a file system identifier to identify a file system with > respect to which file_id need to be decoded. Obviously. > We can either do it in > userspace via statfs or any other encoding or let the kernel fill the > field for userspace. Now having kernel providing both file_id and file > system id implies we can get an 'unique' handle with one syscall. (Not > unique if we have multiple file system with same UUID. Userspace > file server can find out whether all the mount point it is exporting > have a unique UUID during startup.) Or it can decide which UUID to use by parsing its analog of /etc/exports, or any number of other schemes. Sure. > Now if we have UUID as a part of file handle, adding the check make > sure that we are passing the right file handle with the correct mountdirfd. > If they don't match return -ESTALE. Pardon? Your variant needs to choose mountdirfd somehow and it has to be done by UUID found in fhandle it has received. Whatever userland code will be doing that, you a) need to open() these suckers at some point b) do _NOT_ want to reopen them on each incoming fhandle, for obvious efficiency reasons c) will have very few opens compared to the amount of fhandles you are going to handle (number of filesystems vs. number of requested accesses to them) d) can be sure that identity of fs hosting an opened directory will _not_ change while it's open, so the checks concerning the validity of UUID -> mountdirfd mapping you need to do should be done only once per opening mountdirfd So why the devil would you repeat them on each open-by-fhandle in a variant that gets mountdirfd from caller? > Adding UUID as a part of file handle also help us to get a 16 byte UUID > of the file system in userspace in a simple syscall interface, rather > than using file system specific libraries like libext2fs. Your choice of fsid encoding is orthogonal to my question; again, the question is "why would you want to have open-by-fhandle do anything with fsid, if it gets filesystem identified by opened file descriptor passed by userland anyway?" I don't think that UUID is always a good choice, BTW, but that's a separate issue. For one thing, not every fs _has_ UUID, so while that might be a reasonable default, it doesn't make sense to hardwire it into the design. For another, you might want a different policy (e.g. you might want to allow explicitly configured "this fsid value corresponds to whatever's mounted on that path" for some userland server), so again it doesn't make any sense to hardwire that one. But that's a completely independent issue; whether you use hardwire UUID into the thing or not, rechecking that yes, mountdirfd is on the same fs as it used to back when we'd opened it, is pointless. It *will* be on the same fs, so checking that we'd got the right filesystem should be done once per opening mountdirfd, not once per opening file by fhandle. -- 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
