Date: Fri, 3 May 2002 22:41:26 EDT From: Eric Jacobs <eaja@erols.com> To: fs@freebsd.org, Bakul Shah <bakul@bitblocks.com> Subject: Re: Filesystem Message-ID: <PstOfc.3cd34a56.c67ea6@localhost> In-Reply-To: <200205032031.QAA24496@repulse.cnchost.com> References: <200205032031.QAA24496@repulse.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bakul Shah <bakul@bitblocks.com> wrote: > Terry Lambert writes: > > > I believe this limit is common to all UNIX systems that use hard links > > to do ".." processing. Technically, it should be possible to do this > > with affecting link count. However, it's really easy > > to open a directory and determine if there ar substirectories by > > examining the link count on it, and to know how many there are by > > examining the link count on it. > > > Plan9 does ".." right. The same can be done in Unix by > storing the rooted path in the kernel for a process'es > current working dir. and by following some path rewrite > rules: > > <prefix>/<component>/.. == <prefix> > <prefix>/<component>/../<suffix> == <prefix>/<suffix> > /../<suffix> == /<suffix> Those rules aren't valid on the account of syntax alone. You would have to know which components are symbolic links. And once you take into account symbolic links, you have essentially what namei does anyway. I think what Terry Lambert was saying was that since hard-linking directories isn't allowed anyway, there's no need to refcount them, except for the subdirectory counting tricks. > You would also have to deal with middle directories being > renamed, filesystems being forcibly unmounted and so on. > > Not storing the entire path for cwd may have been the right > decision for '70s but not since then.... The entire path is stored indirectly via the VFS name cache, so getcwd() works _even_ for filesystems which do not implement "..". Implementing ".." at the VFS level would be just as simple. Probably the only reason it isn't is because it has been traditionally handled at the FS level. > > In any case, it's still an incredibly bad idea to have even a tenth of > > that man objects in a single directory, period. > > IMHO it is a bad idea to not have evolved directories to use a B-tree > representation (at least when the number of entries exceed some > threshold. Implement mechanisms and leave policies to the users! If you can handle access considerations yourself, one creative solution might be to use getfh(2) and fhopen(2) and store the file handles however way you want. This bypasses the kernel lookup entirely. -- P 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?PstOfc.3cd34a56.c67ea6>