Date: Wed, 3 May 2000 22:00:55 +0800 From: Adrian Chadd <adrian@freebsd.org> To: Bjoern Groenvall <bg@sics.se> Cc: freebsd-fs@FreeBSD.ORG Subject: Re: A proposal : IFS Message-ID: <20000503220053.D53701@ewok.creative.net.au> In-Reply-To: <wuitwv245x.fsf@bg.sics.se>; from Bjoern Groenvall on Wed, May 03, 2000 at 02:45:30PM %2B0200 References: <20000503040431.B53701@ewok.creative.net.au> <Pine.BSF.4.10.10005031717190.71327-100000@lion.butya.kz> <20000503185457.C53701@ewok.creative.net.au> <wuitwv245x.fsf@bg.sics.se>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Adrian 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?20000503220053.D53701>