"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/