Date: Sun, 16 Sep 2001 15:49:29 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Kris Kennaway <kris@obsecurity.org> Cc: Dennis Berger <Dennis.Berger@nipsi.de>, freebsd-fs@FreeBSD.ORG Subject: Re: Porting a new filesystem to FreeBSD Message-ID: <3BA52C79.E1E247F5@mindspring.com> References: <3BA4B507.CC70ECD4@nipsi.de> <20010916140843.A21982@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote: > > On Sun, Sep 16, 2001 at 04:19:51PM +0200, Dennis Berger wrote: > > >>Note that the JFS that IBM put out for Linux is the OS/2 > > >>JFS -- the only thing of real value it brings to the table, > > >>IMO, is the btree directory structure, which you can put > > >>into FFS fairly easily (less than a days work). > > So why nobody implemented it yet ? > > Because a lot of people like to talk about how easy things are without > doing the work and finding it to be harder. That's not true. The reason is binary backward compatability, with a minor amount of politics. To guarantee backward compatability, there are several things that have to happen, in addition to the code changes to fsck for checking the new directories and the code changes to ufs to support them (both of which are trivial for anyone who has ever read Knuth's "Seminumerical Algorithms: Sorting and Searching", and is a halfway decent C coder): 1) FreeBSD's fsck needs to treat unknown file types (at least those within a certain range) as being valid files just like files or directories, but with an unknown type, rather than puking on them. 2) The ufs in libstand needs to be taught about the new directory type, in case / is one of them, so that it can still find the kernel to boot it. Unlike Linux, FreeBSD doesn't stomp the absolute block addresses, in order, of the kernel into the boot loader. 3) The FreeBSD VOP_READDIR code needs to be split into seperate "get directory block" and "externalize an already obtained directory block into the system neutral format" functions, and cookies need to go away. 4) The code that uses cookies needs to be changed; this os mostly the Linux ABI and the NFS server code. 5) FreeBSD's fsck needs to be updated to support upgrading existing directories to the new implementation. Without these changes being in the FreeBSD tree for at least one release cycle, the patches would never gain acceptance from anyone, except those people who are intimidated by pseudo-benchmarks intended to market a specific OS or FS as "better than FreeBSD". Note that without #2, the boot FS _must not_ use the new format, and without #3 and #4, the Linux software running weenies, who are the people who mostly want this, will not be able to run their code. #5 is just a "nice to have", and #1 is a "don't destroy my disk if I run the old fsck" option. #1 and #2 are what mostly drive the "one release cycle" requirement. Note that most of the changes in #1 and #3 will be seen as being "gratuitous: adds nothing" by most of the old guard, who want to have instant gratification on code changes that touch already working code in fundamental and potentially destabilizing ways, if they are unable/unwilling to look at the big picture. This kind of leaves anyone trying to do the code (unless they are a core team member) out in the cold, unless they are willing to campaign for it the same way Julian campaigned for the new KSE code (and he had the distinction of being one of the oldest members of the community, as he predates FreeBSD itself, and coded on it back when it was "386BSD+patchkit"). -- 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?3BA52C79.E1E247F5>