Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

EXT4 Is Coming

CowboyNeal posted more than 8 years ago | from the we're-going-five-blades dept.


ah admin writes "A series of patches has been proposed in Linux kernel mailing list earlier by a team of engineers from Red Hat, ClusterFS, IBM and Bull to extend the Ext3 filesystem to add support for very large filesystems. After a long-winded discussion, the developers came forward with a plan to roll these changes into a new version — Ext4."

cancel ×


Sorry! There are no comments related to the filter you selected.

hi (-1, Offtopic)

pfangel (985870) | more than 8 years ago | (#15642341)

Apple Bets Farm on Heterosexual Computing - GNAA Members Offended
Apple Bets Farm on Heterosexual Computing - GNAA Members Offended

San Francisco, Ca - Mikhail Borovskiy (GNAP) - Moments after the announcement made by Steve Jobs that Apple would be changing the Macintosh computing platform from a PowerPC based CPU architecture to an Intel Pentium based architecture, GNAA executives jesuitx and timecop were visibly shaken. The announcement confirmed rumors started four days prior when C-Net News reported that this change would be taking place. As C-Net News was the first technical news source to report this story, most people assumed the truth would be somewhere near the polar opposite of their findings.

"Guys what is going on? It seems Apple is trying to market towards 'Straighties'! That's never going to work! Fuck Apple, Apple is dead to me, Apple hit WTC!" said jesuitx upon hearing the news. He was later seen backstage speaking with Apple's Vice-President of Marketing, Phil Schiller, quoted as saying "Phil, baby, this is massively fucked up. As a typical Macintosh user [] , and as a fellow Vice-President of Marketing [Gay Nigger Association of America], I can tell you there's no amount of spin you could put on this that will save you from losing support from the homosexual installed base [all Macintosh users] that has kept Apple Computer alive for so many years!"

timecop, founder and President of GNAA, is expected to renounce Apple and order the immediate purchase of Chinese made IBM computers by its members, 87% of which are Macintosh users, at the July 8th Copperfield Conference to be held in Kyoto, Japan. At the last Copperfield conference, held in Nome, Alaska, timecop had praised Apple for their continuous support of the homosexual community.

About Apple

Until today, Apple Computer was the creator of the Macintosh, popularly known as the "gay computer". 87% of GNAA members were Mac users. Founded in 1974 by Steve Jobs and Steve Wozniak, Apple was nearly out of business in the mid 90's, when Jobs was rehired. He then started the now infamous iGay marketing scheme which involved both the Step 2 ???? Profit model, and a 100% effort towards marketing to homosexuals. Apple is nowadays run by fuckfaced retards.

About GNAA:
GNAA (GAY NIGGER ASSOCIATION OF AMERICA) is the first organization which gathers GAY NIGGERS from all over America and abroad for one common goal - being GAY NIGGERS.

Are you GAY [] ?
Are you a NIGGER [] ?
Are you a GAY NIGGER [] ?

If you answered "Yes" to all of the above questions, then GNAA (GAY NIGGER ASSOCIATION OF AMERICA) might be exactly what you've been looking for!
Join GNAA (GAY NIGGER ASSOCIATION OF AMERICA) today, and enjoy all the benefits of being a full-time GNAA member.
GNAA (GAY NIGGER ASSOCIATION OF AMERICA) is the fastest-growing GAY NIGGER community with THOUSANDS of members all over United States of America and the World! You, too, can be a part of GNAA if you join today!

Why not? It's quick and easy - only 3 simple steps!
  • First, you have to obtain a copy of GAYNIGGERS FROM OUTER SPACE THE MOVIE [] and watch it. You can download the movie [] (~130mb) using BitTorrent.
  • Second, you need to succeed in posting a GNAA First Post [] on [] , a popular "news for trolls" website.
  • Third, you need to join the official GNAA irc channel #GNAA on, and apply for membership.
Talk to one of the ops or any of the other members in the channel to sign up today! Upon submitting your application, you will be required to submit links to your successful First Post, and you will be tested on your knowledge of GAYNIGGERS FROM OUTER SPACE.

If you are having trouble locating #GNAA, the official GAY NIGGER ASSOCIATION OF AMERICA irc channel, you might be on a wrong irc network. The correct network is NiggerNET, and you can connect to as our official server. Follow this link [irc] if you are using an irc client such as mIRC.

If you have mod points and would like to support GNAA, please moderate this post up.

| ______________________________________._a,____ | Press contact:
| _______a_._______a_______aj#0s_____aWY!400.___ | Gary Niger
| __ad#7!!*P____a.d#0a____#!-_#0i___.#!__W#0#___ | [mailto]
| _j#'_.00#,___4#dP_"#,__j#,__0#Wi___*00P!_"#L,_ | GNAA Corporate Headquarters
| _"#ga#9!01___"#01__40,_"4Lj#!_4#g_________"01_ | 143 Rolloffle Avenue
| ________"#,___*@`__-N#____`___-!^_____________ | Tarzana, California 91356
| _________#1__________?________________________ |
| _________j1___________________________________ | All other inquiries:
| ____a,___jk_GAY_NIGGER_ASSOCIATION_OF_AMERICA_ | Enid Al-Punjabi
| ____!4yaa#l___________________________________ | [mailto]
| ______-"!^____________________________________ | GNAA World Headquarters
` _______________________________________________' 160-0023 Japan Tokyo-to Shinjuku-ku Nishi-Shinjuku 3-20-2

Copyright (c) 2003-2005 Gay Nigger Association of America []

How does it compare to zfs? (0, Offtopic)

smartin (942) | more than 8 years ago | (#15642350)

I've heard good things about zfs, event that apple may adopt it, does any one know how it compares to ext4?

Re:How does it compare to zfs? (3, Insightful)

Ignominious Cow Herd (540061) | more than 8 years ago | (#15642447)

Ummm...zfs exists, ext4 doesn't. Yet.

Well, how does a Honda Civic ... (2, Insightful)

tetromino (807969) | more than 8 years ago | (#15642611)

compare to a Liebherr T282 [] ? These are two projects with vastly different goals. Ext4 is basically Ext3 with better performance and a much larger maximum capacity; it's still a typical traditional Unix filesystem, a safe default choice for desktops and small servers. ZFS is an exotic beast with a totally ridiculous maximum capacity and tons of advanced of features that do not exist in any other Unix filesystem, but are only useful for Big Iron.

Re:Well, how does a Honda Civic ... (0)

Anonymous Coward | more than 8 years ago | (#15642816)

Since Ext3 is just Ext2 with journaling, we can apply transitivity:

Ext4 is just Ext2 with journaling and support for more/bigger files. Ext2 is a pretty run-of-the-mill filesystem. Since most linux distrubutions run filesystem checks every 20 boots anyway, Ext2 and Ext4 are entirely interchangable for desktop users.

Re:Well, how does a Honda Civic ... (3, Informative)

DavidS (31112) | more than 8 years ago | (#15642861)

This is simply not true. ZFS is not just for big iron. It's strongest feature is perhaps the melding of the volume manager and raid into one single unit greatly simplifies administration. Not to mention other nice features, either new os greatly simplified from their past versions, such as pooling, dynamic striping, CoW, instant snapshots and cloning, fault tolerance, etc.

I'd suggest reading through these links before spreading more mis-information: [] - ZFS vs. Linux Raid vs. Linux LVM vs. Linux LVM + Raid e.html [] - Why ZFS for home


Re:Well, how does a Honda Civic ... (1)

tetromino (807969) | more than 8 years ago | (#15642899)

ZFS is not just for big iron. It's strongest feature is perhaps the melding of the volume manager and raid into one single unit greatly simplifies administration. Not to mention other nice features, either new os greatly simplified from their past versions, such as pooling, dynamic striping, CoW, instant snapshots and cloning, fault tolerance, etc.

Yes, ZFS has awesome volume-management features. If you have a big fileserver with a dozen drives, ZFS is a godsend. However, considering that most laptops, desktop, and small servers only have only 1-2 hard drives, ZFS is a total overkill for the average user. Which was precisely my point.

Re:Well, how does a Honda Civic ... (4, Informative)

DavidS (31112) | more than 8 years ago | (#15642985)

This is true, but let's look at the case of 1-2 drives:

Assuming we still want mirroring or volume management on our two drives:
The overhead is still greater for SVM or for linux md and sistina lvm. Both require more administration knowledge, time, and commands to accomplish the same tasks that ZFS can do in a couple commands. (Yes, I'm aware that mdadm helps the process a *bit*, but it's still obtuse.) Anyone who has setup either knows how annoying anything is with either choice. (having to micromanage partitions, etc.)

The biggest thing for ZFS in a ``small'' 1-2 drive usage case is, in my opinion, the pooling: ZFS doesn't require one to set volume sizes in advance. Since everything pulls out of a common pool, the size of volumes can grow or shrink accordingly. (Affected by free pool space or volume quotas.) So, that means that one can just create their volumes, and not have to worry about making them the wrong size.

I'd also argue that fault tolerance is important anywhere, large or small.

Another thing is on-disk, low overhead, compression that can be enabled just by toggling one filesystem paramater, live. For a lot of things that people store, this compression would save a lot of space.

They really put a lot of thought in ZFS. It scales amazingly well, from small to large. I'm not really giving it justice explaining it here, so I'd encourage you to look at the documentation with an open mind before just writing it off as an ``enterprise only'' thing.

(I have no affiliation with Sun in any way.

design (1)

m874t232 (973431) | more than 8 years ago | (#15643557)

I'm not so sure that that's a reasonable analogy.

ext2 and ext3 are very high performance file systems that have no trouble moving large amounts of data. ext4 appears to be a market-driven extension of ext3, in which what amounts to users pay for the minimum number of changes necessary to get the job done.

ZFS, on the other hand, is a typical Sun design, in which their kernel engineers throw in every feature they can think of and Sun is marketing the hell out of it. But a lot of features also means a lot of features that can be misconfigured, that can have bugs, and that can cause unexpected performance bottlenecks.

Even if the ZFS feature set is the right one, it's far from clear that putting them into the file system layer is the right place to put them.

So, at this point, ZFS may end up being more Edsel than Liebherr T282.

Re:How does it compare to zfs? (1)

The_Wilschon (782534) | more than 8 years ago | (#15643375)

Wow. I realized most people didn't RTFA, but this is the first instance I've seen of of not RTFS(ummary)... It is proposed. That is, it doesn't exist yet.

Sounds like a good idea. (5, Funny)

Ant P. (974313) | more than 8 years ago | (#15642352)

This'll fill the gap between now and when Reiser4 is declared stable - some time after Duke Nukem Forever gets released.

Re:Sounds like a good idea. (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15642388)

Reiser4 is such a good FS... its BS its not considered "stable".

Re:Sounds like a good idea. (2, Interesting)

Anonymous Coward | more than 8 years ago | (#15642392)

It's BS that people think it should be considered stable. I've never had more corruptions, other than using XFS w/ very heavy writes, than Resier4. It needs at least another year. ext3 on its own, though not awesome in all areas, hasn't lost me any data yet.

Re:Sounds like a good idea. (1)

kimvette (919543) | more than 8 years ago | (#15643538)

I don't trust Ext3, because the journaling in it is a hack riding on top of Ext2, and if you mount the partition as Ext2 (say, from a rescue disk, or move the HDD to another partition) you lose the journal, or at least render it useless. What they ought to have done was made it NOT backwards-compatible so it could not be mounted as Ext2, then the journal and data remain intact and in sync. IMHO of course.

Re:Sounds like a good idea. (4, Interesting)

CRCulver (715279) | more than 8 years ago | (#15642547)

This'll fill the gap between now and when Reiser4 is declared stable

Reiser4 will never be declared stable in the Linux kernel because Hans Reiser refuses to make his code conformant to kernel coding standards. There has been long and wearying discussion of this on the LKML.

Re:Sounds like a good idea. (0)

Anonymous Coward | more than 8 years ago | (#15642630)

Interesting? He's just repeating what Ant P said.

Re:Sounds like a good idea. (1)

Jesus_666 (702802) | more than 8 years ago | (#15643404)

No, Ant P said what happens; the GP explained why it happens.

Re:Sounds like a good idea. (2, Interesting)

mnmn (145599) | more than 8 years ago | (#15643522)

Who cares? Linux has more than its fair share of filesystems, including XFS. I'm still wondering why XFS isnt used universally on desktop and server Linux installations everywhere. Is the ext2/3 just 'traditional'?

But... (1)

Ulrich Hobelmann (861309) | more than 8 years ago | (#15642552)

will it support the Hurd?

Re:But... (1)

kimvette (919543) | more than 8 years ago | (#15643543)

Didn't you mean to say the obligatory "but will it run Linux?"

However in this case we need to flip it:

"Will it run Vista, and will it come out before Duke Nukem Forever?"

Oh and to for a momentary instance of reason: is it GPL-compatible? If so then I'm sure that it will support Hurd, or the reverse, Hurd will support it.

Re:Sounds like a good idea. (1)

kimvette (919543) | more than 8 years ago | (#15643528)

Well, for what it's worth, based on ReiserFS 3.6, I'd trust Reiser4 before I'd trust Ext2 (and derivatives - Ext3 is Ext2 with journaling on top) again. I've lost data more than once on Ext2, but never on Reiser. In fact, Reiser's journaling was able to rescue data for me when an ABIT motherboard caught fire (bad caps burst, the motherboard started smouldering, and one of the processors exploded and punched a hole through the board). One of the NTFS drives got scrambled, yet the Reiser drives on the same controller were intact. I could not access the data, but reiserfsck --fix-fixable brought the data back, to its latest-saved state. Very nice. I'd call that stable. Ext2 has lost data on me due to lesser mishaps. Also, I LOVE the zero-slack feature of Reiser. Why do most systems STILL have fixed block sizes? Why can they not just map to sectors instead? No, you have to waste an ENTIRE 64K/32K/16K/8K/4K/etc. block of disk space when it's only partially filled.

Of course I haven't read up on Ext4 yet to see if it's significantly changed. but based on the hack that is Ext3's journaling I personally wouldn't run it (Disclaimer: I WILL read up on it when it's released in a "stable" kernel and give it a fair chance if it's something more than Ext2 plus journaling). Granted, much of the work that went into making the implementation of ReiserFS stable is Novell's doing, but it's still a good design to start with.

Where does the current "Stable" Reiser fall short? Lack of the immutable bit, compression, and other extended attributes supported by Ext2/3. I do miss those, but IMHO the gain in data integrity and AVAILABLE usable space is worth the tradeoff. Reiser does have its faults, but in my experience it's been very, very stable. I have not tried Reiser4 yet but the documents outlining the design show a lot of promise.

(Note: this is not intended to be a troll, just my anecdotal experience, so Ext3 fanboys can just chill. If you disagree, you're welcome to post your own opinions.)

Yes but (5, Interesting)

Anonymous Coward | more than 8 years ago | (#15642354)

Yes, but will it be enough if you had energy to boil all the oceans?

Interesting bit from wiki/ZFS:
ZFS is a 128-bit file system, which means it can provide 16 billion billion times the capacity of current 64-bit systems. The limitations of ZFS are designed to be so large that they will never be encountered in any practical operation. When contemplating the capacity of this system, Bonwick stated "Populating 128-bit file systems would exceed the quantum limits of earth-based storage. You couldn't fill a 128-bit storage pool without boiling the oceans."

In reply to a question about filling up the ZFS without boiling the ocean, Jeff Bonwick, an engineer at Sun Microsystems who led the team in developing ZFS for Solaris, offered this answer:

"Although we'd all like Moore's Law to continue forever, quantum mechanics imposes some fundamental limits on the computation rate and information capacity of any physical device. In particular, it has been shown that 1 kilogram of matter confined to 1 liter of space can perform at most 1051 operations per second on at most 1031 bits of information [see Seth Lloyd, "Ultimate physical limits to computation." Nature 406, 1047-1054 (2000)]. A fully-populated 128-bit storage pool would contain 2128 blocks (nibbles) = 2137 bytes = 2140 bits; therefore the minimum mass required to hold the bits would be (2140 bits) / (1031 bits/kg) = 136 billion kg.

To operate at the 1031 bits/kg limit, however, the entire mass of the computer must be in the form of pure energy. By E=mc2, the rest energy of 136 billion kg is 1.2x1028 J. The mass of the oceans is about 1.4x1021 kg. It takes about 4,000 J to raise the temperature of 1 kg of water by 1 degree Celsius, and thus about 400,000 J to heat 1 kg of water from freezing to boiling. The latent heat of vaporization adds another 2 million J/kg. Thus the energy required to boil the oceans is about 2.4x106 J/kg * 1.4x1021 kg = 3.4x1027 J. Thus, fully populating a 128-bit storage pool would, literally, require more energy than boiling the oceans."

Re:Yes but (4, Informative)

Anonymous Coward | more than 8 years ago | (#15642372)

That post makes more sense if you realize that there should be ^ marks to show exponentiation, such as 10^51 and 2^140. Otherwise it just looks like gibberish numbers that someone made up and stuck in the wiki for shits and giggles.

Re:Yes but (2, Funny)

Anonymous Coward | more than 8 years ago | (#15642943)

Nature 406, 10^47-10^54 (2000)
Volume 406 is really thick.

Re:Yes but (0)

Anonymous Coward | more than 8 years ago | (#15643049)

hey, thanks, man. I was thinking and thinking about what "1 kilogram of matter confined to 1 liter of space can perform at most 1051 operations per second on at most 1031 bits of information" could possibly mean? Can't a 286 do that? I was thinking "do they mean 2^1031 ? Then WTF??" Thanks for clearing that up :)

Re:Yes but (1)

thephotoman (791574) | more than 8 years ago | (#15642450)

The limitations of ZFS are designed to be so large that they will never be encountered in any practical operation. When contemplating the capacity of this system, Bonwick stated "Populating 128-bit file systems would exceed the quantum limits of earth-based storage. You couldn't fill a 128-bit storage pool without boiling the oceans.

That is, until next week, when some guy in Peoria manages to do just that by trying to create a single mirror of all the pr0n on the Internet.

Re:Yes but (1)

AccUser (191555) | more than 8 years ago | (#15642451)

Wow. Imaging the size of the fan you would need to keep that hard drive cool.

128 bits? (2, Funny)

turgid (580780) | more than 8 years ago | (#15642520)

"128 bits should be enough for anyone." - Scott G. McNealy (retired).

/me ducks.

Re:128 bits? (2, Funny)

maxwell demon (590494) | more than 8 years ago | (#15642725)

Well, let's see what you can address with 128 bits. If we assume byte-addressing, it's enough for 2^128=3.4*10^38 bytes, or 2.7*10^39 bits.

Now lets assume we want to store every bit in a single carbon atom. Carbon has a specific mass of 12 g/mol, 1 mol about 6.022*10^23 atoms. So 2.7*10^39 bits would translate to 4.5*10^15 mol, or 5.4*10^16 g, which is 54 gigatonnes of carbon.

I doubt hard drives will get larger than that any time soon :-)

Re:128 bits? (1)

turgid (580780) | more than 8 years ago | (#15643180)

Calm down dude, it's OK, I used to work for Sun. I heared all about ZFS before they started writing the code.

Re:Yes but - Limes Compu.... something (0)

Anonymous Coward | more than 8 years ago | (#15642602)

[see Seth Lloyd, "Ultimate physical limits to computation." Nature 406, 1047-1054 (2000)].

Now in which book (though admittedly sci-fi) did I read that weight before 2000, it had a similar concept named Limes compu... (my Latin fails me). There it was the other way around though, it was faster to compute "something" on a given location than to compute it "on the next node" and transfer it over, i.e. throwing more hardware at it wouldn't help and the ultimately best computer (also an AI) was the size of half a cubic metre.

and 640 K... (1)

a_greer2005 (863926) | more than 8 years ago | (#15642604)

...will be enough for anyone...right?

Everytime I hear someone say "there is no way we would ever use that much data", I laugh out loud! HD cameras are coming, bandwidth is getting faster and cheaper (DSL is like $12 here in Indiana) and lets face it, people want to save this is good or bad is a differant topic, but the fact is, if you give people the storage, they will use it...Remember when you asked yourself "How will I ever fill this 500MB HDD?" I do...

Re:and 640 K... (1)

G Morgan (979144) | more than 8 years ago | (#15642769)

It's not so much that its enough for anyone just that theres pretty much a natural limit on this. You'd have to find QM to be wrong to fill it to its maximum.

Re:and 640 K... (1)

0racle (667029) | more than 8 years ago | (#15642803)

I'm reporting greer2005 to Homland Security for his terrorist plot to boil the oceans.

Re:and 640 K... (1)

kimvette (919543) | more than 8 years ago | (#15643556)

For what it's worth, I'd suspect that if such amounts of storage were to become available, the current administration here in America could fill it up.

In addition to knowing who my friends are, whom I call, and that I'm interested in aviation and fast cars, they'll be able to track which brand of mouthwash I buy (and where I buy it), who my dentist is, how much I've spent on my teeth, which brand of toilet tissue I buy (because only terrorists buy Scotts, right?), how many times I've read 1984 over the years, which really bad sci-fi movies I buy (yes I bought Battlefield Earth, a great poorly-written b-movie experience), and that I've watched Lord of the G-Strings and Lord of the Rings back to back on OnDemand cable, not to mention cataloguing every post I've made here on slashdot.

Build the storage, and SOMEBODY will fill it up, probably the government (not necessarily just the current administration by the way) with tracking every inane detail of our lives in the name of "combating terrorism" and "increasing safety/security."

Re:Yes but (1, Funny)

Anonymous Coward | more than 8 years ago | (#15643079)

"That's no moon. It's a full ZFS SAN."

Re:Yes but (0)

Anonymous Coward | more than 8 years ago | (#15643288)

In reply to a question about filling up the ZFS without boiling the ocean, Jeff Bonwick, an engineer at Sun Microsystems who led the team in developing ZFS for Solaris, offered this answer

Sun, boiling oceans... Am I the only one who suddenly feel very uncomfortable on this planet?..

LWN article on ext4 (5, Informative)

ElMiguel (117685) | more than 8 years ago | (#15642360)

LWN [] had an interesting article on ext4 [] not long ago.

Modularizable filesystem (3, Interesting)

Square Snow Man (985909) | more than 8 years ago | (#15642371)

What about a modularizable filesystem, which can be upgraded with modules for compression, encryption, larger file support etc. ? Is this impossible or is it a unkown area for the linux developers?

Re:Modularizable filesystem (5, Informative)

Bogtha (906264) | more than 8 years ago | (#15642393)

Reiser4 does this [] .

Re:Modularizable filesystem (2, Insightful)

dbIII (701233) | more than 8 years ago | (#15642435)

Interesting article - the premise that Reiser is more stable than ext3 "because it has been out longer", the quote from Adam Smith, the ridicule of the unix approach of everything as a file and all the naked people covered in newsprint?

Anyone have a "more technical" link without dancing trees and with a bit about how to recover your filesystem when something goes weird with the hardware even if the filesystem is perfect?

Re:Modularizable filesystem (4, Insightful)

Bogtha (906264) | more than 8 years ago | (#15642509)

the premise that Reiser is more stable than ext3 "because it has been out longer"

It's dishonest to put something in quotes when it's not a direct quote. The exact quote is:

"We don't touch the V3 code except to fix a bug, and as a result we don't get bug reports for the current mainstream kernel version. It shipped before the other journaling filesystems for Linux, and is the most stable of them as a result of having been out the longest. We must caution that just as Linux 2.6 is not yet as stable as Linux 2.4, it will also be some substantial time before V4 is as stable as V3."

There's a substantial difference between saying that something is more stable "as a result" of something and more stable "because" of something. He's not claiming that being out longer intrinsically makes it more stable as your misquote suggests, he's claiming that it led to reiserfs becoming more stable - because of the practices he mentioned.

In short - something being out longer == more stable? No. Something being exposed to lots of real-world use and receiving only bugfixes == more stable? Yes.

the quote from Adam Smith

He didn't quote Adam Smith, he drew an analogy between what he was saying and the network effect. It's an entirely reasonable analogy.

the ridicule of the unix approach of everything as a file

What ridicule? He's actually supporting that approach. For example:

Can we do everything that can be done with {files, directories, attributes, streams} using just {files, directories}? I say yes--if we make files and directories more powerful and flexible. I hope that by the end of reading this you will agree.

Would you care to point out where you thought he was ridiculing the UNIX approach?

all the naked people covered in newsprint

Yeah, they look dumb, don't they?

Anyone have a "more technical" link

I can only assume you mean something other than "technical".

without dancing trees

Dancing trees are a fundamental part of the design. How are you meant to understand the filesystem without understanding dancing trees?

and with a bit about how to recover your filesystem when something goes weird with the hardware even if the filesystem is perfect?

Ah, you don't mean technical at all, you mean practical for somebody who is entirely uninterested in the way the filesystem works. Perhaps Reiser4 Transaction Design Document [] is what you are after, but I doubt it.

Re:Modularizable filesystem (1)

dbIII (701233) | more than 8 years ago | (#15642638)

Sorry it's beyond midnight in this part of the world - so here is the correct quote:

"and is the most stable of them as a result of having been out the longest"
The context is supplied in the article and the portion above - do you see what I am getting at here and why I do not agree that it is a definition of stability? It certainly gives me no confidence to the questions of stability and recovery, which I'm sure are answered elsewhere, but no - I didn't think much of the article - perhaps the annoying graphics distracted too much for me to get much out of the content.

Thanks for the second link. No pictures of people dancing to describe dancing trees.

Re:Modularizable filesystem (1)

jZnat (793348) | more than 8 years ago | (#15642533)

You can't really get more technical about filesystems than talking about things like dancing trees and other algorithms for storing and retrieving data quickly, safely, and efficiently. Don't forget, Hans Reiser is a filesystem expert, so don't expect his site to not have that sort of information on it.

Re:Modularizable filesystem (1)

dbIII (701233) | more than 8 years ago | (#15642670)

OK - I should have phrased that as without pictures of people pretending to be trees that are dancing, or even pictures of leafy trees dancing. Something boring with only the sort of diagrams and descriptions you would see in a published paper would be nice.

Re:Modularizable filesystem (1)

Antique Geekmeister (740220) | more than 8 years ago | (#15642587)

Like the Abrams tank going 60 miles an hour, ReiserFS is fine for doing all sorts of amazing things, once. Actually being trying to recover any data from ReiserFS if any hardware errors creep in, such as a failing drive in a RAID array, is like the drive train seizing up on the Abrams: it's a big development effort to get spectacular features which don't actually work well in the field.

Ext2 and its descendants have been less ambitious and thus considerably more robust.

Re:Modularizable filesystem (1)

hskinnemoen (782323) | more than 8 years ago | (#15642503)

What's the point? One of the main reasons for creating a new filesystem with a new name is that the on-disk format changes. No matter how you implement the change, using plugins or otherwise, you need to make it very clear to the users that if they upgrade to the new on-disk format, they will not be able to use older kernels. The most obvious way of doing this is giving the filesystem a new name -- if your kernel doesn't support ext4, you won't be able to read an ext4 filesystem.

Besides, filesystems can be considered modularized components of the VFS. There will always be room for another layer of abstraction, but that doesn't mean that adding it will make things any better.

Re:Modularizable filesystem (2, Informative)

CastrTroy (595695) | more than 8 years ago | (#15642573)

However, a kernel which didn't support EXT3 could still read and write EXT3. EXT 3 is completely backwards compatible with EXT2. While you're running in EXT2 mode, none of the journalling stuff is done, but the data can still be read and written. Then you can unmount, and remount the drive as EXT3, and everything will be fine. At least that's my understanding. This might be harder to do with certain features. You can't just ignore encryption. Especially when trying to read data.

Re:Modularizable filesystem (1)

Znork (31774) | more than 8 years ago | (#15642527)

Take a look at the device mapper and associated stuff like EVMS, LVM2, dm-crypt, etc.

Arbitrary block device layering is the way forward.

Yawn, large filesystems (-1, Troll)

Gothmolly (148874) | more than 8 years ago | (#15642373)

So there's a bunch of FSes out there that support large filesystems. And now ext3fs will. Who cares?

ClusterFS (5, Funny)

schon (31600) | more than 8 years ago | (#15642377)

engineers from Red Hat, ClusterFS, IBM

OK, hands up - who wants to run ClusterFS so that they can say they needed to do a "clusterfsck"?

Re:ClusterFS (0)

ScrewMaster (602015) | more than 8 years ago | (#15642420)

Dammit! You beat me to it.

Re:ClusterFS (1, Insightful)

Anonymous Coward | more than 8 years ago | (#15642494)

Unfortunately, lustre's fsck is just called lfsck. You run it across the aggregate of file stores making up the cluster filesystem to ensure total consistency, after running clusterfs' e2fsck friendly-fork on each individual object store to ensure local consistency. Most of these changes to ext3 -> ext4 are driven by the needs of Lustre. Lustre FS is basically a virtual filesystem striped across a load of ext3 filesystems on servers. It is blazingly fast and very stable in our tests (clusterfs are _very_ conservative about tagging something "stable", their stuff is used on some serious computers).

define very large (2, Insightful)

frovingslosh (582462) | more than 8 years ago | (#15642404)

OK, I've read both links. What does this mean? Can anyone give a breakdown of ext3 vs. ext4, particularly in terms of what size files and what size partitions they both support, as well as any other differences that can be quantified?

Re:define very large (1)

gsnedders (928327) | more than 8 years ago | (#15642430)

ext3 has a 32TiB max volume size, and 2TiB max file size.

Re:define very large (5, Insightful)

Kjella (173770) | more than 8 years ago | (#15642440)

Let me put it this way, it's a little past the average slashdot porn collection:

ext3: 8TB total, 4TB files
ext4: 32 zettabyte (1024*1024*1024 TB), 1 exabyte files (1024*1024 TB)

Beyond that, it doesn't seem to actually change much.

Re:define very large (3, Funny)

runep (159408) | more than 8 years ago | (#15642554)

Let me put it this way, it's a little past the average slashdot porn collection:
I think you underestimate the combination of lonely geeks, OCD, unemployment, broadband and wget.

Re:define very large (2, Interesting)

zlogic (892404) | more than 8 years ago | (#15642639)

Though this may be needed in some rare applications, I don't see ext4 as something needed in the near future. As I understand, the larger the max partition&file size, the more space indexes will need (not to mention that speed will probably drop).
For example, if we have 20-bit indexes (2^20 clusters max) and use 4-kilobyte clusters, to increase the maximum space we'll either have to add one bit to the indexes to double the maximum space or we'll have to increase the cluster size and have problems storing small files (remember the FAT16->FAT32 transition?)
ext4 is thousands larger than ext3, which will probably mean that indexes will need a lot more space, which will be bad for 8TB volumes (and besides, noone would notice any benefits!)

Re:define very large (3, Informative)

Kjella (173770) | more than 8 years ago | (#15642739)

From what I understood the sector index will be configurable as either 32 or 64 bit, so pick it if you need it... Since there's no reason to use it unless the disk is that big, I imagine this can be set automaticly. Also, the whole reason this will be ext4 is that they'll change the way it stores the sectors (ranges instead of singles) which will be better for big files, and since one sector is 4kB almost any file is "big".

Re:define very large (3, Insightful)

glwtta (532858) | more than 8 years ago | (#15642703)

ext3: 8TB total, 4TB files
ext4: 32 zettabyte (1024*1024*1024 TB), 1 exabyte files (1024*1024 TB)

Are they just going to work on improving the 8TB paper limitation, or are they actually trying to improve on ext3 scalability? Which, currently tends to suck the big one, especially on a significant number of disks (eg: lts [] ).

I also seem to keep coming up against a pretty hard 2TB block device limit in Linux (eg LVM2 lv size, LUN size for fibre attached SAN, etc). I don't really know what the reasons for it are, anyone know what technologies allow for larger single partitions?

Anyway, I've long ago settled on reiserfs (3) for speedy random access to small files, and XFS for file server type applications; though I still wonder why RedHat doesn't include any "enterprise" filesystems by default in their "enterprise" products (I know, I know, you can enable it - I did say "by default").

What about directories? (1)

Roadkills-R-Us (122219) | more than 8 years ago | (#15643043)

Everyone sweats out the file and FS size limits, but it's amazing to me that Linux's most popular filesystem still limits you to under 32K directories at one level in a directory. Does ext4 address this? Why not?

I realize this is irrelevant for most people, but for some of us it's crucial.

LKML Message (3, Informative)

Anonymous Coward | more than 8 years ago | (#15642427)

The kernel mailing list message:

Subject Proposal and plan for ext2/3 future development work
From "Theodore Ts'o"
Date Wed, 28 Jun 2006 19:55:39 -0400

Given the recent discussion on LKML two weeks ago, it is clear that many
people feel they have a stake in the future development plans of the
ext2/ext3 filesystem, as it one of the most popular and commonly used
filesystems, particular amongst the kernel development community. For
this reason, the stakes are higher than it would be for other
filesystems. The concerns that were expressed can be summarized in the
following points:

        * Stability. There is a concern that while we are adding new
                features, bugs might cause developers to lose work.
                This is particularly a concern given that 2.6 is a
                "stable" kernel series, but traditionally ext2/3
                developers have been very careful even during
                development series since kernel developers tend to get
                cranky when all of their filesystems get trashed.

        * Compatibility confusion. While the ext2/3 superblock does
                have a very flexible and powerful system for
                indicating forwards and backwards compatibility, the
                possibility of user confusion has caused concern by
                some, to the point where there has been one proposal
                to deliberately break forwards compatibility in order
                to remove possible confusion about backwards
                compatibility. This seems to be going too far,
                although we do need to warn against kernel and
                distribution-level code from blindly upgrading users'
                filesystems and removing the ability for those
                filesystems to be mounted on older systems without an
                explicit user approval step, preferably with tools
                that allow for easy upgrading and downgrading.

        * Code complexity. There is a concern that unless the code is
                properly factored, that it may become difficult to
                read due to a lot of conditionals to support older
                filesystem formats.

Unfortunately, these various concerns were sometimes mixed together in
the discussion two months ago, and so it was hard to make progress.
Linus's concern seems to have been primarily the first point, with
perhaps a minor consideration of the 3rd. Others dwelled very heavily
on the second point.

To address these issues, after discussing the matter amongst ourselves,
the ext2/3 developers would like to propose the following path forward.

1) The creation of a new filesystem codebase in the 2.6 kernel tree in /usr/src/linux/fs/ext4 that will initially register itself as the
"ext3dev" filesystem. This will be explicitly marked as an
CONFIG_EXPERIMENTAL filesystem, and will in affect be a "development
fork" of ext3. A similar split of the fs/jbd will be made in order to
support 64-bit jbd, which will be used by fs/ext4 and future versions
of ocfs2.

2) Bug fixes to fix 32-bit cleanliness issues, security/oops problems
will go into fs/ext3, but all new development work will go into fs/ext4.
There is some question about whether relatively low risk features such
as slimming the extX in-core memory structure, and delayed allocation
for ext3, which have no format impacts, should go into fs/ext3, or
whether such enhancement should only benefit fs/ext4 users. This is a
cost/benefit tradeoff for which the guidance of the LKML community about
whether the loss in code stability is worth the improvements to current
ext3 users, given the existence of the development branch.

In addition, we are assuming that various "low risk" changes that do
involve format changes, such as support for higher resolution
timestamps, will _not_ get integrated into the fs/ext3 codebase, and
that people who want these features will have to use the
stable/development fs/ext4 codebase.

3) The ext4 code base will continue to mount older ext3 filesystems,
as this is necessary to ensure a future smooth upgrade path from ext3
to ext4 users. In addition, once a feature is added to the ext3dev
filesystem, a huge amount of effort will be made to provide continuing
support for the filesystem format enhancements going forward, just as
we do with the syscall ABI. (Emergencies might happen if we make a
major mistake and paint ourselves into a corner; but just as with
changes to the kernel/userspace ABI, if there is some question about
whether or not a particular filesystem format can be supported going
forward indefinitely, we will not push changes into the mainline
kernel until we are can be confident on this point.)

4) At some point, probably in 6-9 months when we are satisified with the
set of features that have been added to fs/ext4, and confident that the
filesystem format has stablized, we will submit a patch which causes the
fs/ext4 code to register itself as the ext4 filesystem. The
implementation may still require some shakedown before we are all
confident that it is as stable as ext3 is today. At that point, perhaps
12-18 months out, we may request that the code in fs/ext3/*.c be deleted
and that fs/ext4 register itself as supporting the ext3 filesystem as
We believe this should satisfy most of the concerns that were
articulated, in particular those that Linus and Jeff were most concerned
about. Comments are of course appreciated.

                                                        - Ted

Too late... (0, Troll)

Anonymous Coward | more than 8 years ago | (#15642439)

Reiser4 is stable for at least 1 1/2 years now. Why not include that? Because of the changes that would go beyond of the focus of the FS layer?

First of all, they should return to the old development model and put all the broken stuff from 2.6.x into 2.7.x instead of continuing this 2.6.x.y BS.

I don't want to make these decisions myself by abandoning Linux for FreeBSD.

Why EXT4 ? (4, Interesting)

Anonymous Coward | more than 8 years ago | (#15642449)

Ext4 is an extention of ext3, much like ext3 is an extention of ext2. The plan is to ensure backwards compatability and sanity for when things break, and with filesystems.. things break.

There are many factors that influence filesystems, not just "how fast it can write", but rather.. how it breaks when it does.

While the fanboys of XFS, JFS, ZFS may promise that their filesystems are faster, had no problems, secure and will not eat your data, it simply is not as proven as ext2 and ext3.

Scream fanboys scream, someone will listen, but the problem is that these filesystems are not proven in the field, or in some circumstances even in the kernel itself.

Re:Why EXT4 ? (4, Informative)

Frumious Wombat (845680) | more than 8 years ago | (#15642486)

Actually, XFS (SGI), JFS (IBM), and ZFS (Sun) are very well proven in the field, on their respective native operating systems. Given the situations they're used in (financial sector, pharmaceutical research data, supercomputing), they're far more proven that EXT(anything). Now, whether the average Linux user knows how to install, tune, and use them is a different issue, but if I were worried about scalable, mission-critical, filesystems, those three would be on the top of my list. (and my personal history says that while XFS never gave me any trouble, JFS would be my first choice. Nobody ever let me have a budget large enough to buy a machine that would justify ZFS).

With IBM's know-how in the mix, EXT4 may be able to join the above three, but it would seem to be time better spent fixing XFS/JFS support in Linux first, rather than worrying about backwards compatibility with EXT2.

Re:Why EXT4 ? (0)

Anonymous Coward | more than 8 years ago | (#15642510)

ZFS, well proven in the field? As in, being first announced stable in Solaris 10 just a month ago?


EXT3 has been solid for around 5 years in commercial environments.

Re:Why EXT4 ? (3, Informative)

Znork (31774) | more than 8 years ago | (#15642564)

"ZFS (Sun) are very well proven in the field"

Um, I have yet to see a production installation of ZFS in an enterprise environment, and it hasn't been out as an actual release for even a year yet. You probably mean UFS. HTH.

Re:Why EXT4 ? (1)

eviltypeguy (521224) | more than 8 years ago | (#15642830)

Um, I have yet to see a production installation of ZFS in an enterprise environment...

Then you haven't been looking very hard. SUN has been using ZFS internally in their enterprise environment for a while. In addition, there are several special customers that were using ZFS in production working closely with SUN engineers. Not only that, I know of a hosting company that posted about using ZFS already for their production environment. In addition, ZFS is now officially supported and part of Solaris 10 as of Update 2, so there are definitely many production installations already. If you read the ZFS discussion forums on, you will see a lot of posts from people that have already set up ZFS installations in production environments.

Re:Why EXT4 ? (2, Informative)

Builder (103701) | more than 8 years ago | (#15643470)

Actually, I think you'll find that ZFS has been out as a production release (GA or Generally available) for just under 2 weeks now. That's weeks!

There is no way in hell that ZFS is even _remotely_ proven in the field. And since we're still fighting with a bug with Sun Disksuite where you can't boot off the second disk when a disk in a mirror breaks, I'd be VERY loathe to mention Sun, Filesystems and Disk management as being stable right now.

fsck quality (5, Informative)

r00t (33219) | more than 8 years ago | (#15642582)

Nobody has a fsck that can compare to e2fsck (ext2/ext3/etc.) for quality.

The e2fsck program has a huge test suite that it must pass before a release. A set of corrupted filesystems must be correctly repaired to be bit-for-bit identical to the desired result.

A typical fsck has a good chance of crashing (SIGSEGV, the "segmentation violation") when the going gets tough.

While FreeBSD's UFS developers were messing around with sync writes to avoid testing a fsck that would often crash, the ext2 developers ran full async and wrote a damn fine fsck to put things back in order. Now you can choose from three different levels of journalling, and you still get the ass-kicking fsck program.

There basically is no fsck for XFS, Reiserfs, or Reiser4. JFS doesn't have much AFAIK, and ZFS is a newborn.

What are you going to do when your fancy filesystem gets trashed? I hope you keep excellent backups, very recent and tested to be readable.

Re:fsck quality (1, Informative)

Anonymous Coward | more than 8 years ago | (#15642680)

The fsck.reiser4 utility is actually *very* good. It basically implements reiser4 in userspace with very extensive checking and it must not crash on any crazy input. It also has a vast test-suite and never fails (short of hardware error).

I have been using it a lot as I am developing some reiser4 plugins and little toys around the reiser4 code, and am very impressed with the code.

Re:fsck quality (1)

MrHanky (141717) | more than 8 years ago | (#15642751)

I've had e2fsck crash with a segfault, fairly recently, on an Mac. This was with Debian unstable, so I downloaded a static build of e2fsck from the web to try a more conservative solution, and that would also crash. It didn't cause that many problems, because I could still read the FS, backed it up somewhere else, and recreated the FS. Reiserfsck had no problem fixing the other FSes (I have had loads of FS related problems with this machine, probably because it writes gibberish to the disk when the power is cut. It's a laptop, but the battery is flat). Now that it's running OS X, though, the whole system partition becomes unreadable and unfixable quite often. HFS+ isn't very reliable, even with journaling.

Sorry, just had to get some OS X bashing in there, it's so ridiculously overestimated on this site. My only point was that e2fsck can crash.

Re:fsck quality (1)

rs232 (849320) | more than 8 years ago | (#15642871)

"There basically is no fsck for XFS .."

XFS provides journaling [] for file system metadata ..In the event of a system crash .. Recovery is performed automatically at file system mount time ..

Re:fsck quality (1)

ComputerSlicer23 (516509) | more than 8 years ago | (#15642949)

Clearly you've never had hit a bug in hardware or software. As someone who has had fsck turn up errors on both reiserfs and ext3 while running with Journals, I can assure you, that a really good fsck is a wonderful thing. Bugs in hardware or software can reduce the "journaling" to nothing. Journaling is really about applying database ACID technology to filesystems in the event of an crash. It's also pretty speedy.


Re:fsck quality (1)

rs232 (849320) | more than 8 years ago | (#15643109)

Re:fsck quality (0)

Anonymous Coward | more than 8 years ago | (#15643555)

Fat lot of good that does you. With data=journal set, EXT3 checks whether or not the DATA is consistent.

Re:Why EXT4 ? (1, Informative)

Anonymous Coward | more than 8 years ago | (#15642723)

On Linux, XFS has slightly better large-file performance but worse small-file performance than EXT3. EXT3 is comparable in performance to reiser3 on small files (a few kilobytes), and is stable and reliable, unlike reiserfs. JFS is lacking quota support. EXT3 also has the option to do data journalling, not just meta-data journalling like the other journalling filesystems. Right now, unless you are larger than a few terabytes, EXT3 is the way to go. If you're larger, XFS and accept the performance penalty and occaisional (massive) xfs_repair or restore (XFS is more likely to become corrupt due to memory or block layer errors, and recovers poorly compared to EXT3).

Re:Why EXT4 ? (1)

demotivator (933851) | more than 8 years ago | (#15642911)

JFS on AIX has certainly been around for awhile, but it was not without problems or limitations. JFS2 is really what people use on AIX these days, and is generally a good feature-rich filesystem. But between the LVM bugs and JFS2 bugs I've encountered over the last couple years AIX is not nearly as reliable as I would have hoped. One of the more problematic features with JFS2 was the dynamic resizing, as there was a lovely bug where the resize would hang, which in turn hung all I/O to that filesystem. The only option at that point was a reboot. Needless to say, we were forced to do all resizes offline for a while (even after we'd applied the patches to fix the issue, as we simply couldn't take the chance of it happening again).

Re:Why EXT4 ? (1)

51mon (566265) | more than 8 years ago | (#15643219)

Mod parent up -- oh he had 5 points -- still give it a try.

Please complete the following;

We need another enterprise file system;

- like we need another web browser.
- like we need another Window manager.
- like we need another Bourne shell derivative.
- more than we need improved network filesystem support.
- more than we need Hans Reiser to rip out the limitations of the VFS from the kernel.
- because the other Enterprise level filesystems just don't support big enough filesystems/files.
- because the other Enterprise level filesystems are too fast.
- because backwards compatibility to ext2 is written in stone on tablets handed to McKusick on Mount Berkeley by someone with a burning beard.
- because cludgy journaling addon are cool and we should strive to preserve cludges as long as possible.
- other - please specify.

Re:Why EXT4 ? (1)

dnaumov (453672) | more than 8 years ago | (#15642613)

"While the fanboys of XFS, JFS, ZFS may promise that their filesystems are faster, had no problems, secure and will not eat your data, it simply is not as proven as ext2 and ext3."

I am sorry, but you got this quite the wrong way around :)

XFS and JFS have been used in enterprise enviroments far longer than EXT2 (not to mention EXT3) has been in existance.

Re:Why EXT4 ? (2, Interesting)

Carewolf (581105) | more than 8 years ago | (#15642653)

In enterprise.. Exactly!

Note that servers with extensive mirroring and other hardware error-handling rarely need error-recovery from the filesystem. Filesystem errors happen on ordinary peoples harddrives when they grow old, and ext* have a million times more experience in the handling those than any enterprise FS..

Re:Why EXT4 ? (1)

fimbulvetr (598306) | more than 8 years ago | (#15643365)

I got this:
xfs_force_shutdown(sdb1,0x8) called from line 1088 of file
fs/xfs/xfs_trans.c. Return address = 0xf8c3043b
Filesystem "sdb1": Corruption of in-memory data detected. Shutting down
filesystem: sdb1
Please umount the filesystem, and rectify the problem(s)
Last week on a debian sarge box runing 2.6.8 while setting up a file system on a box that built, ran and read from ext3 just fine. A format and reinstall of the 400GB array got XFS working on the second try.

This was minutes after creating the partition and in the process of making 3 million 4k files.

After doing it the second time, it's created the files and hasn't crashed yet (crosses fingers).

More features - More bugs (0, Troll)

bazmail (764941) | more than 8 years ago | (#15642456)

The ist of bugs for the kernel is growing faster than they are being fixed.

inux is now built on a foundation of sand. Time to jump ship methinks.

Why only 48 bits? (2, Insightful)

The Wicked Priest (632846) | more than 8 years ago | (#15642461)

Why not go all the way to 64 bits now, and thereby avoid further changes for the forseeable future? In one of the messages linked from the article, it's suggested that 1024 PB, obscene as it sounds, may only be good enough for another decade.

I guess we'll be on to ext5 or 6 by then, though.

Re:Why only 48 bits? (4, Interesting)

r00t (33219) | more than 8 years ago | (#15642499)

With a block size of 32 kB (64 kB is expected to be supported soonish) the 48-bit numbers will take you 1 byte over the maximum file size that apps can support. There is no UNIX-like OS that lets an app handle files bigger than 2**63.

We'll need to adjust other things if filesystems ever get so huge. The whole design probably needs a rethink, but we can't do it now. We don't know what the future holds in terms of seek times, transfer rates, sector sizes, etc.

2.7.x is coming (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15642465)

2.6.x.y is getting ridiculous.

Yes but... (0)

mkw87 (860289) | more than 8 years ago | (#15642471)

will it run linux? Oh darn it, wrong thread.

Pattern (4, Funny)

Eudial (590661) | more than 8 years ago | (#15642532)


Wait... I think I can detect a pattern. The next number has to be Ext7½!

Re:Pattern (0)

Anonymous Coward | more than 8 years ago | (#15642592)

Microsoft plans to supercede all of these with a superior version, Ext2007. A beta release is expected early 2010...

Re:Pattern (1)

ConceptJunkie (24823) | more than 8 years ago | (#15643223)

No, the next one will be ext2008.

Then extxp.

What about performance? (2)

Tamerz (702147) | more than 8 years ago | (#15642540)

I may be blind but I can't find any info on that. Is it simply going to allow larger file systems? Or will there be performance increases as well?

Yes. (2, Informative)

r00t (33219) | more than 8 years ago | (#15642589)

The new data structures take up less space. They are thus faster to write and faster to read. They also seem to make delayed allocation easier.

Linux and other Unix FSes (3, Insightful)

digitalhermit (113459) | more than 8 years ago | (#15642734)

I'm as big a Linux fan as anyone, but one glaring thing that it needs is some better filesystem tools. Don't get me wrong -- they've come a long way in the last couple years -- but compared to something like AIX it still has a little ways to go. Here's one feature that causes a challenge: Linux filesystems and the underlying logical volume layer is largely decoupled. You have an immense amount of flexibility but as a consequence, the filesystem and volume layers don't always communicate as well. For example, the AIX JFS2 tools allow you to dynamically grow/shrink filesystems. This functionality exists in Linux for some filesystems (EXT3, ReiserFS) but the procedure varies depending on how the filesystem is constructed. And at this point, I'm not fully convinced of its stability as I've recently (three months ago) lost an entire disk after a dynamic resize on an LVM backed EXT3 partition. I have yet to reproduce the failure but it occurred with a 95% full /home and a kernel compile going full tilt.

But I'm amazed at how quickly these features are being integrated. There's functionality in Linux that allows me to easily create file-backed volumes, remote volumes, SAN LUNs, etc.. The "resize in a single command" is not fully there yet, but within 6 months I'd expect it to be.

Re:Linux and other Unix FSes (3, Insightful)

Homology (639438) | more than 8 years ago | (#15642958)

>I'm as big a Linux fan as anyone, but one glaring thing that it needs is some better filesystem tools.

I'm pretty certain that Linux would have better filesystem tools if the developers could resist add a new filesystem every few months.

My take on current filesystems (0)

Anonymous Coward | more than 8 years ago | (#15642832)

Just my bit on current filesystems

I have a laptop which currently has a corrupted filesystem. It's only a "little" corrupted in that it's just some metadata. Basically there's a file that when I delete it, it still thinks it's there, if I try to do anything to it it says "no such file or directory".
This system is running reiserfs. Now to be fair I bash my filesystems VERY hard. My laptop crashes a minimum of once a week. I use gentoo so I have a lot of small files that get updated daily (which is why I was usinr reiser). ReiserFSCK is unable to repair this problem. Apparently the only way is to do a full tree rebuild, which is a fairly scary proposition. I've never had a problem with JFS. I have had problems with ext3, but only if I never fsck'd, which is not it's intended usage pattern.

Now, in tests JFS performs as well or better except with very large directories, and usually with less CPU load than reiser. I would use JFS on any system where performance mattered, but if you want stability it's all about ext3. Sometimes I don't care if it takes an extra second to read a file, as long as it friging works.

I have friends who run XFS, and it's crash performance is abismal. XFS was designed for SGI servers, which have a different failure pattern than PC's. Primarilly, XFS deals very poorly with power deaths. As a result XFS ZERO'S things that it gets confused about. It doesn't even just ignore them, it intentionally zero's them. That is not the right thing to do pretty much ever. On top of that the locking uses a wrapper layer around the linux locking primitives because it wasn't so much ported as wrapped in a layer of code that pretends to be IRIX. This mapping from one set of locking primitives to another is not perfect. As any real systems hacker knows the EXACT implementation of locking DOES matter, and can mean the difference between deadlocks, and not. E.G. Posix mutexes != basic yield spinlock, one will deadlock in cases where the other wont (even on a uniprocessor system). Basically the people I know who run XFS do a filesystem rebuild every couple months.

I have not yet toyed with reiser4, though another friend who runs that also only has a filesystem crash once every couple of months (Yeah... ONLY). I consider it to be about as stable as XFS. In short, I think ext4 is kindof silly, good tree based stuff is the right way to go not more extensions of ancient concepts. But practically speeking no-one else is up to the job of a stable filesystem just yet, so for now we NEED ext4.

Re:My take on current filesystems (1)

PenGun (794213) | more than 8 years ago | (#15642865)

I've run xfs for years on my media storage partitions and I've never had a problem. Crashs. power failure etc ... nothing. It is a journaling filesystem and works so well I'm thinking of running my whole system next install.

  Do What Now ??? ... Standards and Practices !

Re:My take on current filesystems (3, Insightful)

waferhead (557795) | more than 8 years ago | (#15643301)

"I consider it to be about as stable as XFS."

I have had my /video and /home partitions on XFS for... WAY too long, several years, same drives.
(I just keep adding on)

I lose power a lot where I live (glitches) and XFS has been utterly bullet proof.

(This filesystem has bee thru 3 motherboards, several linux distros (1 mb dead/2 upgrades), 2 cases, and so on)

If Reiser4 is about as stable as XFS, I'll glady switch everything over tomorrow on my MythTV box.

What they really should do is (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15642846)

In ext4 they should get rid of some legacy stuff to foster development and usage of new technologies. The users of legacy technologies could still use ext3 and it would be very nice for ext4 users. I'm talking mostly about dropping support for the old style octal file access permissions system and bolting the ACL system as the default and enabling the metadata features by default.

The fact that nothing pressurises ever the distribution builders into using anything new has lead to majorly slowed down development of Linux.

How Boring (0)

Anonymous Coward | more than 8 years ago | (#15642970)

Darn. I read EXT4 may be coming soon and got my hopes up. I have always disliked EXT3 because it was essentially just EXT2 with journalizing tacked on with no performance advantages whatsoever. I've had much better results both performance-wise and even stability-wise with ReiserFS versus EXT3 (both tested over several hardware crashes and the ReiserFS filesystem remained undamaged while the EXT3 became badly enough damaged to prevent the operating system from booting eventually. Perhaps it would be more accurate that I did not so much test as that I used EXT3 when I installed, crashed a few times causing problems each time, was unable to even boot at all the last time, then reinstalled with ReiserFS instead and despite a few crashes since before I solved the hardware problem it remained undamaged.) The fact is, it has been said many times over the past that EXT3 was basically just a quick-fix for the problem of lack of journalization. Unfortunately, by the sound of things, in the same way that EXT3 is essentially EXT2 + journalizing, it would appear that EXT4 will just be EXT3 + insanely huge filesystem support, which is a great quick-fix for those with uber RAID arrays filled with 500GB harddrives, though those of us who can't even afford one 500GB harddrive will find that to be no more helpful than EXT3 was since ReiserFS supports a filesystem of up to 16 terabytes (which means you'll need 32 500GB harddrives -- well, in a few more years you'll actually be able to have 16 terabytes without a gigantic RAID array, but, for the moment you're still very unlikely to hit 16 terabytes in any kind of rush. Oh, and I think the size limit has to do with the paging inherant in the CPU, which may mean a CPU supporting larger paging than the 4K they say was standard among Intel CPUs at that time should therefore support a larger filesystem.)

Oh well. I can always hope that EXT5 will be what I really want to see -- a complete rework of the filesystem implementing all the advantages seen in filesystems like ReiserFS with the support that the well known EXT standards enjoy. I'm sure EXT5 will just be a quick fix for tiered storage or something. In the meantime, so other filesystem will end up doing it better for those who are patient.

ext4 is coming! (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#15643527)

That's really good to know, especially since as of yet nonexistant ext4 is already obsolete because of Jeff Bonwick's ZFS.

People! Wake up!!! Are you living under a rock or something?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?