Date: Tue, 07 May 2002 00:18:14 +0200 From: Philip Homburg <philip@cs.vu.nl> To: Terry Lambert <tlambert2@mindspring.com> Cc: fs@FreeBSD.ORG Subject: Re: Filesystem Message-ID: <m174qoA-000OesC@sluis.cs.vu.nl> In-Reply-To: Your message of "Mon, 06 May 2002 10:02:20 -0700 ." <3CD6B71C.C0A502A1@mindspring.com> References: <200205040019.UAA13780@illustrious.cnchost.com> <3CD32F43.327CDA46@mindspring.com> <20020504041936.GA19646@quic.net> <3CD3FB02.3EC1DA29@mindspring.com> <20020505084827.GA3688@quic.net> <m174kb0-0014NkC@centaur.cs.vu.nl> <3CD6B71C.C0A502A1@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: >Philip Homburg wrote: >> >From an O.S. point of view, what's the problem with providing large >> directories? Some tools, such as ls and find, may need some attention due to >> scaling issues. Backup software is needed to handle the new filesystem >> layout. > >#1 Binary backwards compatability with millions of installed > systems What kind backwards compatability? The usual Unix system calls are uneffected (creat, open, link, unlink, getdents, etc.). Even then, it is user's choice to create large directories, the system just supports it. >> If somebody would like to create 1M files, and you know that, when properly >> implemented, directories accesses cost O(log(n)), then what's the problem? > >#1 No one has written the code to optionally store directories > this way (and made it publically available) A small practical problem, that can be dealt with easily. (Unless you are asking for production quality code :-) >#2 (minor nit) A btree is O(log2(N)), which is not as happy a > number as your O(log(N)) O(log2(N)) = O(log(N)/log(2)) = O(log(N)) I don't see where you get the log2. The fan-out is determined by the avarage size of a directory. >> I don't want to think about crash recovery of btrees in a normal FFS >> filesystem. > >No one does, except the people asking us to switch to their pet >FS by default, but not releasing it under a usable license, and >expecting that we would just "eat" the backward compatability >issue. But that is just an implementation issue. The binary backwards compatability issues that you hinted at are more fundamental. Philip Homburg 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?m174qoA-000OesC>