Messages in this thread | | | Date | Thu, 14 Jan 1999 00:41:47 -0500 (EST) | From | Jeffrey Hutzelman <> | Subject | Re: Open by inode? (was Re: knfsd) |
| |
> > Note that open-by-inode() is fundamentally broken, and will not be > > implemented. There are several reasons: > > > > - it bypasses directory-based security. > > This is irrelevant for root.
True. The approach we've been working on to provide this capability for AFS fileservers (as well as others who want it; I have a couple in mind) restricts icreate/iopen/iinc/idec to root.
> > - it breaks any filesystems that don't work by inode number. For > > example, a number of filesystems _need_ to know the full pathname: > > any well-thought-out network filesystem (and no, I don't consider NFS > > to be well-thought-out) will use pathnames, and even local > > filesystems like a basic cdrom filesystem needs to know the full path > > Both AFS and Coda have a 4*32bit identifier on each file. Therefore, > don't call it open_by_inode(), call it open_by_handle(), it is much > more general.
The problem is that it's not general - it's very AFS-specific, and requires the underlying filesystem to provide a new indexing mechanism to support it. Further, AFS does not actually want that - it already keeps track of the inode number for each of its files, specifically to _avoid_ using any name-lookup mechanism provided by the filesystem. Thus, iopen() is better for AFS.
Linus is correct - generic iopen support does not belong in the VFS layer, because the concept of inode numbers is not generic. The approach we've been working on for AFS involves already having some file descriptor open on the filesystem you're interested in, and doing ioctl's on it to create and open other files by inode. This has the advantage that it can be done entirely within those filesystems that care to support it, without the need to provide filesystem-dependent functionality in the supposedly filesystem-independent VFS layer.
This is very likely the approach that AFS will use, unless we run into unforeseen problems. I'll also be using it in a lightweight AFS fileserver I'm working on, which provides access to the contents of a workstation's local filesystem to other AFS clients. I'd also like to see Coda and the KTH group make use of the same interface, but obviously I don't have any control over those groups. Feel free to contact me via private mail if you'd like to talk about unifying these efforts.
Below is an example of how our interface will work. The real thing is a bit more complicated at this point, but what I've included here should get the idea across.
fd = open("/vicepa", O_RDONLY);
i = ioctl(fd, I_CREATE, 0); /* create a file; returns inode */ fd2 = ioctl(fd, I_OPEN, i); /* open file by inode */
ioctl(fd2, I_INCDEC, 1); /* increases link count */ ioctl(fd2, I_INCDEC, -1); /* decreases it */ ioctl(fd2, I_INCDEC, -1); /* decrease again, now link count is 0 */ close(fd2); /* so file is deleted on close */
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |