Date: Fri, 03 May 2002 17:45:55 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Bakul Shah <bakul@bitblocks.com> Cc: Scott Hess <scott@avantgo.com>, "Vladimir B. Grebenschikov" <vova@sw.ru>, fs@FreeBSD.ORG Subject: Re: Filesystem Message-ID: <3CD32F43.327CDA46@mindspring.com> References: <200205040019.UAA13780@illustrious.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bakul Shah wrote: > Unless enough systems provide this capability no one sane > will use it. So yes, portability suffers. Generally the "large amount of object in a directory" objection is brought up by some [FS] advocate, who wants to advocate their pet FS, and isn't really noticing a real problem: instead, they are implementing a solution, and then trying to invent a problem that requires it. So they really don't care about portability, they care about advocacy. > My frustration is with the 70s mindset when it comes to > extending basic capabilities. Reasoning like: the disk > access speed is very slow so the speed of directory access is > not an issue. And since speed is not an issue a linear > search is fine and dandy. Never mind that with a large > buffer cache, chances are you will find dir. blocks in core > and a linear search is not a great searching strategy when > you have more than 10 to 20 items. And this is not the > only such instance in the kernel. This case is an externalized interface used by programs, which have a choice in their implementation, and choose badly. I agree that there is a lot of room for extending the basic OS capabilities; I would also argue that there is generally a lot of research in that area, as well, and that research isn't being put into practice, for the most part, for a reason other than "not invented here" or "it's too hard: let's go shopping" (though that is sometimes the reason). The main reason I think applies is that legacy interoperability has more value than the other benefits that the change brings. For FS research, Poul and Kirk are working on UFS2. It would be wise to appeal to them to include sufficient mechanisms in the way of extension fields so that you could (for example) mark a directory as being "btree" or "patricia tree" or "trie" or whatever, and have it work transparently with legacy support for linear directory block layout. Poul has already stated that he and Kirk do not intend to change the directory layout to a btree, even though they have an on disk format change that they will be making, so this is the most logical compatability break. I don't know if they intend to provide sufficient extension instertion points for this type of thing (this would include extensions to the soft updates system being pluggable, as well -- so I doubt it). Either way, they haven't said, so you could always ask Kirk. > If you build scalable solutions people will use them. If > enough Unix variants provide fast dir search, others will > have to pick it up. Fast dir search won't be picked up until important applications start to rely on it. And important applications won't rely on it until it's generally available. So the only real way to break the log-jam is to come up with a killer app, which relies on some feature you want to proselytize. The main enemy of new features like this is that there is always more than one way to solve a problem. 8-). -- 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?3CD32F43.327CDA46>