Date: Wed, 3 May 2000 10:12:34 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Adrian Chadd <adrian@freebsd.org> Cc: Bjoern Groenvall <bg@sics.se>, freebsd-fs@freebsd.org Subject: Re: A proposal : IFS Message-ID: <Pine.NEB.3.96L.1000503100436.28689A-100000@fledge.watson.org> In-Reply-To: <20000503220053.D53701@ewok.creative.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 3 May 2000, Adrian Chadd wrote: > On Wed, May 03, 2000, Bjoern Groenvall wrote: > > Adrian Chadd <adrian@FreeBSD.ORG> writes: > > > > > An application which keeps an internal database of objects->filenames > > > would simply continue to do so, but the filename is simply the inode number. > > > WHen creating a file, it opens 'newfile' for create/write, which creates > > > a new file. It then stat()s the fd to get the inode number, and records > > > that. In squid case, it eliminates the need for keeping a bitmap of > > > used file entries, since the FS does this anyway. > > > > What about using fhopen and getfh instead? That way you won't have to > > write a new filesystem. You will have to use file handles rather than > > inode numbers though. > > You still need to do a directory lookup in getfh(), and IFS filesystems > take far less time to fsck. There was once a hack floating about for > Linux and FreeBSD which patched VOP_LOOKUP() to take a special filename > and treat it as an inode number- it was designed for INN where once > you opened a news article, you'd keep the inode number in memory and use that. > But you still had the ondisk directory metadata and unlink()s couldn't > be done with the inode number magic sequence, which is why I took it > a step further and wrote IFS. Coda (and presumably early AFS code) made use of an ITC open to open a file by-inode to avoid the namespace costs, as it provides its own namespace. My recollection also is that the fh* calls don't give you a way to allocate new file handles, only convert an existing name into a file handle. So you still pay the cost of file creation in the namespace. And you can't assume that file handles will remain consistent across a backup/restore cycle, whereas if the unique (yet efficient) names are part of the exposed application namespace, you can. This also answers the question about what access limitations to put on the fh* calls in alternative security environments (capabilities, MAC, tokens, et al) as it would no longer be a call to access files out of band of the namespace, but instead be controlled by permissions on the fs. Speaking of which -- it strikes me that it would be nice to have an inode allocated (nominally) to the root directory, and vop_access() and vop_getattr() would return properties of that inode (specifically, permissions/ownership/file flags/etc) and apply those permission limitations on create and delete operations. This way when the file system was created, you could chown/chmod/whatever the root of the FS to set effective rights for use of the FS. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000503100436.28689A-100000>