From owner-freebsd-fs Fri May 3 13:31:23 2002 Delivered-To: freebsd-fs@freebsd.org Received: from repulse.cnchost.com (repulse.concentric.net [207.155.248.4]) by hub.freebsd.org (Postfix) with ESMTP id 791C137B404 for ; Fri, 3 May 2002 13:31:18 -0700 (PDT) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by repulse.cnchost.com id QAA24496; Fri, 3 May 2002 16:31:04 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200205032031.QAA24496@repulse.cnchost.com> To: Terry Lambert Cc: Scott Hess , "Vladimir B. Grebenschikov" , fs@FreeBSD.ORG Subject: Re: Filesystem In-reply-to: Your message of "Fri, 03 May 2002 11:03:08 PDT." <3CD2D0DC.9B636A54@mindspring.com> Date: Fri, 03 May 2002 13:31:03 -0700 From: Bakul Shah Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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: //.. == //../ == / /../ == / 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.... > 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! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message