Date: Mon, 06 May 2002 10:02:20 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Philip Homburg <philip@cs.vu.nl> Cc: fs@FreeBSD.ORG Subject: Re: Filesystem Message-ID: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > 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) #2 (minor nit) A btree is O(log2(N)), which is not as happy a number as your O(log(N)) > I know from experience that implementing a directory as a btree is trivial > if lower layers of the filesystem have (rudimentary) transaction support. #1 Bell the cat > 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. -- Terry 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?3CD6B71C.C0A502A1>