Messages in this thread | | | Date | Mon, 17 May 1999 12:44:28 -0400 (EDT) | From | "Theodore Y. Ts'o" <> | Subject | Re: ext2 question |
| |
Date: Mon, 17 May 1999 01:18:54 +0300 (EEST) From: Matti Aarnio <matti.aarnio@sonera.fi>
"David S. Miller" <davem@redhat.com> wrote: > From: Manfred Spraul <manfreds@colorfullife.com> > > Are there any plans to support to a (start+len) system? > > Ted T'so was/is working on using btrees and extents in ext2.
Yup, and now that 2.3 is out, and that I anticipate having significantly more time to work on this in the near future, you should see some results relatively soon. Stay tuned....
Indeed, but the more we look at things, the more I think that we should stop artificially breething more life into old system, and start working on a 'ext3', which could do a much needed radical (new mkfs) handling to existing filesystems for the new one.
There's actually a couple of different dimensions to this question. The first is what to call it, which is purely a marketing question. (i.e., SunOS 5.7 versus Solaris 2.7 versus Solaris 7.0). The second is how the sources are moved into the kernel, since the filesystem has to be rock-solid stable at all times, even during the development kernel. How I plan to do my work is to compile the ext2 code as a module, with the filesystem name "ext2dev", so that I do testing while still using a stable version of ext2 for all of my production filesystems.
From the filesystem design point of view, did a good enough job designing ext2 that we can cleanly extend the format in most areas without having to start from scratch. The one exception in this is the fixed inode table; if we were doing it all over again from scratch, it might make sense to do something using a completely different and extensible mechanism for stsoring inode files. But that adds a lot of complexity to the filesystem.
I believe that with a relatively small amount of work --- far less than doing a whole new modern filesystem from scratch --- it should be possible to make a filesystem which has btree and extent support which is largely based on the ext2 kernel code and for which existing filesystems can be easily converted to take advantage of these new features.
In the long term a completely new filesystem might be the way to go, but that path is a lot of work, and entails more than a little bit of risk. I should point out there have been some projects underway in that space, including a (I believe defunct) logging filesystem project, and the reseirfs project, which uses btrees for *everything*. It turns out, though, that making a filesystem which is robust and highly performant at the same time is not that easy a task, which is why I happen to believe that an incremental improvement strategy might be the best short- and medium-term solution.
- Ted
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |