Re: [Ext2-devel] [RFC 0/13] extents and 48bit ext3

Chase Venters
2006-06-09T18:25:34Z

On Fri, 9 Jun 2006, Gerrit Huizenga wrote:

> We are seeing storage needs increasing at a frightening rate. Health
> Care folks want to store your MRI's, x-ray's, ultraounds, etc. in high
> res digital format across your entire life in near-line format. Terabytes
> over time per person. Europe is already doing this pretty extensively,
> the US is following suit. Digital media creation has huge storage needs.
> Most everything is moving to podcasts, webcasts, streaming audio & video.
> Storage is huge, and ext3 is at the current breaking point.
>
> I'd argue that whatever we call it, we need a standard, stable, supported
> solution *soon* for large files, large filesystems, large storage systems
> in Linux.
>
> I'd think the quickest path is to relieve the pressure now in ext3.

Makes sense...

>> So we have empirical evidence that splitting filesystem work up does
>> actually help.
>
> Agreed. But... Maybe that should be the set of changes *following*
> extents. Then the file format can change, several of the pending ideas
> can be worked in, and some of the backwards compatibility can be cleaned
> out if it is in the way. Then the extents work can get us something
> usable in all the interim distro releases for the real users who are
> screaming now about the filesystem size limits.

Let's call ext3 "Linux 2.4" for a second and ext(x) w/extents and 48-bit
"Linux 2.5". We can now do all the crazy, wild work we want on 2.5, but
people need it tomorrow. And they can have it, but we're stamping
"Dangerous! Dangerous! Unstable! API changes every 5 minutes, your data
will be obsoleted each release!" all over it. This goes on for years until
we finally reach a point where we can roll out "Linux 2.6".

The trouble is that "Linux 2.6" is something many of us are going to be
wanting _now_.

Now, taking the quotes back off "Linux 2.6" and speaking about the kernel
as a whole again - isn't lots of incremental stable releases with new
functionality something that cutting off the development arm made
possible?

I acknowledge the concerns about filesystem stability and Linus's points
about improperly shared code. From a practical standpoint, I see the need
of bigger filesystems coming.

And the biggest practical problem I see is one of perception. Making
'ext4' means labelling it unstable for a while. And once something like a
_filesystem_ is called unstable, it's going to be a long time before
people trust it with terabytes of their incredibly valuable data (even if
we promise them that it's mostly an ext3 fork).

Whereas if you play with some experimental 48-bit extension on ext3, well,
ext3 already has a good reputation and is in use everywhere, so maybe this
isn't a bad "last feature" to add before forking off into ext4-land?

> gerrit

Cheers,
Chase