Why Redhat Choose ext3 For 7.2 250
mz001b writes "There is an interesting article from RH posted on LinuxToday discussing why they chose ext3 over the other available journaling filesystems (ReiserFS, xfs, jfs,...) for RH 7.2"
Business is a good game -- lots of competition and minimum of rules. You keep score with money. -- Nolan Bushnell, founder of Atari
well... (Score:1)
Who out there has actually done real research? (Score:3, Troll)
Re:Who out there has actually done real research? (Score:1)
Redhat has done intensive stress testing on ext3.
Re:Who out there has actually done real research? (Score:5, Insightful)
Linux still is about choice. You can choose Red Hat, or Debian, or Suse, or Mandrake, or Progeny, or whatever you want. Inside those choices, you can choose to install whatever packages you like. And you can choose whatever filesystem suits your fancy. Red Hat isn't telling you what works for you, and it isn't telling you that you shouldn't use a certain filesystem. It says that very plainly in the article. Please read them before posting drivel like this.
Re:No it doesn't (Score:2, Flamebait)
I like ReiserFS, but I have had it fuck up on a machine before. I'm not bitter against it, and I'm not saying that it's not good - but there is still work to be done on it. Ext3 has a lot working for it, and that's why Red Hat is using it in 7.2. Read the article for more details.
Re:No it doesn't (Score:1)
Re:No it doesn't (Score:2)
ext2, ext3, XFS, Reiser, UFS, HFS (Mac), etc. I'd guess that there are 40 different filesystems for you to chose from...
Re:No it doesn't (Score:2)
At install time, optionally (check box, just like ext3) set up a few partitions, each a test version. Set each one to a boot partition with a different file system. At boot time, allow the user to pick which one to boot from. Set up a few dummy one's, too, so that new file system types can be added, and a utility to copy a boot partition to the new one, customizing partition mapping tables (which is why the scripting is needed).
I tried doing something sort of like this by hand once, but I had a lot of trouble getting the partition mapping tables straight. In fact I considered myself lucky to be able to straighten things back out without a reinstall.
The names of the boot partition and the dummies need to be shuffled around as you move from one to the other, but the device addresses stay fixed. This is fine, but when some options are used the device addresses get replaced by the current name of the partition... well, it got a bit messy.
Re:Red Hat no longer gives you enough choice. (Score:2)
Benchmark results are not #1 on the list of important features in a server-class OS.
Red Hat is not claiming that "reiser goes corrupt", but you would have known that, had you read the article.
Re:Red Hat no longer gives you enough choice. (Score:2)
Bero has indeed claimed that Reiser experiences corruption at high loads, and it is you who have not done sufficient research. Please pay attention.
However, if the likes of Oracle has stress-tested Reiser and pronounced it good enough, Red Hat's protestations fall upon deaf ears. I myself would have preferred to see XFS or JFS, and we both know that bugs have never stopped Red Hat from making a production release before.
The next time you are insulting, try to be more literate.
Re:Red Hat no longer gives you enough choice. (Score:2)
I am not trying to be insulting. This is Slashdot. By posting you give an implicit license for others to post replies which disagree with you.
Re:Who out there has actually done real research? (Score:5, Funny)
Machine 1: Redhat 7.0/ext2
Machine 2: Debian Woody/ext3
Machine 3: Slack 7.0/reiserfs
Test 1:
The machines were elevated to a distance of 5 stories to the rooftop of a local building, or approximately 70 feet off the ground. Each machine was dropped veritcally then tested to see if this damaged the filesystem.
Machine 1: Destroyed
Machine 2: Destroyed
Machine 3: Almost Destroyed, but made funny noises and started to smoke during CMOS check
Test 2:
Unable to test due to unpredicted destruction in test 1.
Conclusion:
No current filesystem for mainstream Linux systems is capable of surviving a 5-story vertical drop. Until this feature is implemented in an open source file system, it will be hard for that FS to be widely accepted.
Re:Who out there has actually done real research? (Score:1)
flawed methodology! (Score:1)
And do an NT machine while you're at it; it wouldn't do to be seen as biased or anything.
Re:Who out there has actually done real research? (Score:1)
Re:Who out there has actually done real research? (Score:1)
Entertaining (Score:2)
=)
Re:Who out there has actually done real research? (Score:2)
And how are they taking away your ability to choose which filesystem to use? Did RedHat drop support for Reiser from the kernel they distribute?
As for why they chose to use ext3, I believe they were leary about relying on a single persons knowledge of the filesystem code. Also reiser and nfs weren't playing nice the last time I looked (granted, this was a while ago).
Re:Who out there has actually done real research? (Score:1)
If I were RedHat, I'd have done the same thing. If reiserfs screws up or is corrupted by a hardware problem, that's the end of the game -- time to mkreiserfs and restore from backup.
Re:Who out there has actually done real research? (Score:2)
One might also argue its not 'officialy redhat supported' and they dont care to either
However if you look at the projects mentioned in the linuxtoday forums, it supplies modified redhat install disks which allow for ReiserFS to be chosen on install.
I gues the main reasons why rh 7.2 chooses ext3 over reiserfs are
- ReiserFS cannot be converted to, ext3 can
- ReiserFS did have issues with NFS, dump, etc. (Most are fixed if not all right?)
- RedHat should support upgrades and ReiserFS would make that impossible as ext2 could not be upgraded to ReiserFS.
Re:Who out there has actually done real research? (Score:2)
However, i do agree, not 100% well tested software can be dangerous, not 100% tested file systems can be lethal.
Reminds me when IBM's JFS 1.0 kernel patch came out. I spend a day converting my workstation to it, and on the first fsck.jfs that was run, my file system was -nuked-, destroyed, whiped away.. Ever since i'm waiting for the 1.1.0 release
ReiserFS has seen a lot of testing over a long period of time, and has some nice b-tree's and all build in that give it better performance then ext2 in some cases.
So use ext3 in a production envirioment? not for me anyways.. however i do plan to test it out on more experimental computers. I mean, if no one would test it, how is it supposed to become stable
speed reading? (Score:3)
I'm impressed that you were able to write that long paragraph in the three minutes since the article was posted, let alone read the message linked-to. But, I think that in your hurry, you missed a few key things, so I thought I'd quote them here for your benefit and the benefit of anyone else in too much of a rush:
Red Hat is just telling you what they think works -- not taking away any of your choices. They even ship the reiserfs tools. Perhaps you've fallen to the whole "Red Hat is too popular to be cool" thing?
Re:Who out there has actually done real research? (Score:1)
RH makes its name on being a trusted linux distribution that can be run on servers. They certainly need all this testing for business to start adopting ext3. Of course if you don't like ext3, stick with ext2, don't check any of the upgrade boxes when you are installing.
Re:Who out there has actually done real research? (Score:2, Interesting)
Well, we had many problems here with ReiserFS/RAID0 and NFS, even after all the NFS and RAID problems were "fixed". Then we went back to ext2. Which works.
We're thinking about maybe going to ext3 (and not because Redhat told use to do so - we're using Mandrake, and maybe going to Debian sometime). But rather, because if something goes wrong we can do a simple fall back to ext2 and we're working again.
So, yeah, try what you think will work, be it ext2, ext3, XFS, JFS, ReiserFS, or FAT16; if it doesn't work, try something else.
RaiserFS experience (Score:2)
$ ls
.
..
script
$ chmod 700 script
$
File Not Found
Yet, ls still finds the file... This is a phantom problem I have only seen on RaiserFS and appears to be some sort of metadata corruption. It is really irritating because you have to create another file. To the credit of RaiserFS, the problem has not occurred since I upgraded to SuSE 7.1.
journaling fs can crap out on you (Score:1)
Better safe than sorry they say... it is true.
Better than nothing... (Score:2)
Yes, backups and a UPS are alway necesary for mission critical stuff... but this adds another layer of 'help'.
Re:journaling fs can crap out on you (Score:2)
I'm anything but a filesystem expert, but from what I know, a journaling filesystem doesn't magically protect your files against damage. If power fails while writing to your disk, even journaling filesystems won't be able to complete the write later, the data simply isn't stored anywhere.
What the journaling system can do is have a very short disk check time during reboot, because it doesn't have to scan the complete disk after a crash.
That's not what a journal is for. (Score:2)
Contrary to popular misunderstanding, using a journaled filesystem does not mean you can start using the power switch before doing a proper shutdown -- try this and you will lose data on any filesystem. It's just that on the journaled filesystems, the risk of further filesystem corruption as a result of power failure is drastically reduced and there is no long delay to analyze the entire filesystem for consistency when powering up again.
Alternative (Score:1)
euh
bad bad taste
its the migration stupid.. (Score:5, Insightful)
ofcourse its the migration path. Users can choose to install ext3 and later if they want to they can choose to go back to ext2. forward and backwards compatiblity makes ext3 a much more friendly jouraling filesystem for businesses. Some of the intranet servers cannot risk to backup and hope the new filesystem to go up working alright. Ofcourse there are better journaling filesystems out there. But the choice to use ext3 is good one since, its mature,stable and easier to administrate and use. Easier to administrate and use the keywords here. Any kernel out there can read an ext3 partition without extra modules. So it definitely plays well with others. Is there any other journaling filesystem that can say this ?
Migration goot (Score:1)
I once tried creating a boot disk which supports ReiserFS in order to fix a broken linux machine, and couldn't find anything like that ANYWHERE. I didn't have any linux machine near me, so I couldn't create one myself...
At least ext3 will not have that problem.
Re:Migration goot (Score:3, Informative)
use it for recovery.
These make nice emergency disks, including ssh:
http://www.lnx-bbc.org/ The LNX-BBC is a mini Linux-distribution, small enough to fit on a CD-ROM that has been cut, pressed, or molded to the size and shape of a business card.
Re:its the migration stupid.. (Score:1)
That, and the fact that ext3 is more stable now than reiserfs was when SuSE shipped it to its guinea p^W^Wusers
Re:its the migration stupid.. (Score:2)
Re:its the migration stupid.. (Score:2)
I would contest that it's mature (it is brand new), and time will tell if it's stable. Personally I tend to think that filesystems take longer to shake out than the operating systems that use them. The fact that it's largely additive to ext2 and fixes its biggest wart (metadata integrity) makes it quite appealing.
Now if we could see softupdates applied to the ext2 side, I'd be willing to switch servers from BSD over to it (I understand reiser is faster than softupdates, but it needs a lot more time in the oven, being such a radical redesign). Well, to debian with source
Re:its the migration stupid.. (Score:1)
http://olstrans.sourceforge.net/release/OLS2000-ex t3/OLS2000-ext3.html [sourceforge.net] is a good place to go and read about ext3 from a speach Dr Stephen Tweedie made to the 2000 Ottawa Linux Symposium.
Re:its the migration stupid.. (Score:1)
But, you see, it isn't. Not really. The journaling part is new, but in most other respects this filesystem is many years old. Unlike Reiser which has a brand new never before used filesystem layout. ext3's filesystem layout is so old, an old bo (Debian 1.3) system could read it. So I would contest that it's "brand new". In many ways, it's the one of the most mature filesystems available at the moment...
Re:its the migration stupid.. (Score:1)
Re:the word is "administer," stupid (Score:2)
Wow! (Score:1)
Performance... (Score:1)
I assume that since ext3 only adds journaling to ext2, reiser is "faster" than ext3 also.
Again this is the claim of reiser people.
Re:Performance... (Score:3, Informative)
Reiser performs better than ext2 mainly on two points:
ext2 uses a linear search algorithm to index directories while Reiser uses a hashtable. This makes handing of large (10000+ files) directories far more efficient. No more need for /home/h/he/hensema.
Reiserfs also packs together the 'tails' of files, meaning that multiple endings of files can occupy the same disk block. This saves space (less slack). The classic example where this works very well is a newsspool, containing hunderds of thousands of files sized typically around 4 KB.
I'm not sure wether the special Reiserfs API has been implemented which can allocate files without names but using their hash-index. This may speed up processes like squid, which have to store vast amount of files but don't care about their names. Cutting out the directory layer completely is a very nice sollution.
Re:Performance... (Score:1)
Currently squid is slower on ReiserFS compared to ext2 because squid is optimized for ext2.
And if you put the squid files on a seperate partition you don't need journaling anyway if you automatically reformat the partition after a crash.
Re:Performance... (Score:2)
I suspect performance characteristics will vary with how and what you use it for.
An example: When I did benchmarks with PostgreSQL 7.1.1/2 a couple of months ago, XFS and ext3 were of similar speed while ReiserFS was rather slow. OTOH, I'd expect ReiserFS to handle cases with lots of files in a directory faster than ext2. Also, the tailmerging in ReiserFS should save space (especially in situations with many small files), but is somewhat risky (there's been a few bugs in that part of the code) and will cost performance.
One of the big benefits of ext3 is that the filesystem isn't new, it's proven solid and has been around for a long time. Adding a journal layer isn't too risky, and it has been in testing (with good results) for a long time.
Man, I can't imagine... (Score:1)
RedHat came up with ext3. Alan Cox works for RedHat. AC has already made patches to the kernel for ext3.
Hmmm... the math isn't tough for this one.
(Granted I haven't read the article, it seems to be
Re:Man, I can't imagine... (Score:3, Informative)
Stephen Tweedie is. He is one of the top filesystem ext[23] hackers and is employed by Redhat. RedHat runs the mailing list for ext2 and ext3 stuff.
But mostly, ext3 allows new filesystems to be employed over old existing ones without a backup and re-creation of the file system. This means ext3 will be deployed (in the US) 10 times more than any other journaled file system.
As for speed, I think the ext[23] file systems, which are already fast, are going to catch up with the addition of an inode hash from Daniel Phillips. Or with his Tux2 file system which is in development. But really, unless you use directories with a large number of small files, ext2 and ReiserFS are not much different for speed.
Having an EASY upgrade path is the way. I also suspect Linus will add ext3 to the mainline kernels in another 2-3 kernel iterations, since the ext3 hackers are quite used to the appropriate methods for getting new code included.
Re:Man, I can't imagine... (Score:1)
I personally use Reiser. I feel (and so the BenchMarks) that it is superiour to (most) of anything else out there.
Disclaimer:
I haven't used ext3. I'm going on benchmarks and my personal eperience alone on that.
Re:Man, I can't imagine... (Score:2)
Stephen Tweedie and Ted T'so wrote ext3, mostly. Andrew Morton led its port to the 2.4 filesystem, and maintains patches for ext3 to be applied to the 2.4 kernels.
Alan Cox merges those submitted patches into his ac series, which ultimately leads to Linus adding them to the "stock" kernels.
Re:Man, I can't imagine... (Score:2)
In many ways Tux2 is an add-on to ext2 to add
1) A hash function which is analogous to a B-tree for directory searches. This is currently a big speed hit for ext2 for directories with lots of small files.
2) Atomic updating of file system writes. This will make the file system power-button resistant without adding a journal. This is a feature already present in FFS + Soft Updates in FreeBSD.
The atomic updating algorithm will make the file system faster than any journalled file system, ceteris paribus. But Tux2 will also be an add-on to existing ext[23] file systems, and will inherit most of its code base from them. Similarly, the upgrade path will not require a backup and re-creation of the file system. At least, this is according to statements made by its coder, Phillips.
argh! goddammit, LinuxToday! (Score:1, Offtopic)
Even if I resize the window, the whole page doesn't fit on my screen.
Who the hell let the monkey design the website?
- A.P.
Really not a surprise ... (Score:4, Informative)
This thread [indiana.edu] is a good example.
Re:Really not a surprise ... (Score:1)
Re:Really not a surprise ... (Score:1)
Re:Really not a surprise ... (Score:2)
Not sure why you make out the arguments to be overly personal. Alan seemed quite willing to accept reiserfs patches in the AC kernels.
Reiser can get corrupted under heavy loads (Score:2)
Also remember that redhat is made and used for bussiness oriented servers and workstations where stability and reliability over cutting edge technology is very important. I would not want to bet my job on a new technology until its very matured. Redhat needs to take it slow due to their market. You can always use a more bleeding edge distro like mandrake. Also reiser is available on the Redhat Powertools cd with the deluxe or server edition of RH 7.1 if you just have to have it.
PS: Could someone posting anonymously post the story so I could read it. Thanks
Re:Reiser can get corrupted under heavy loads (Score:2)
As for betting your job on new technology, cutting edge still pays better than the stable stuff - kidding here, I know what you are trying to say - if the cutting edge is not greased with the blood of developers, its the ops folks who are next in line for the sacrifice... A bit more QA might be in order between final cuts. Guess I should grab those 7.2b ISO's and get testing again. {Grin}
I have to say, I agree (Score:3, Insightful)
If I push to have the systems upgraded, say to ReiserFS, and something goes wrong. I'm just plain f**ked. It's that simple. This offers me the ability to upgrade with a fraction of the risk. Which, considering RedHats duties to its customers, I think is the perfect decision.
What about Stephen Tweedie? (Score:2, Redundant)
So I read the article, and all of those reasons could easily apply to any of the above filesystems. Never mind that all of them are more mature and more stable than ext3. The only technical argument for ext3 is the upgrade path: ext3 is ext2 with a journal. But the real reason might be that RH can speed adoption (and by the bazaar model, improvement) of ext3, developed at RedHat, this way.
Re:What about Stephen Tweedie? (Score:2, Funny)
My first thought was that it's because Stephen Tweedie, lead developer of ext3, works for RedHat. ReiserFS was developed primarily by SUSE. JFS and XFS come from IBM and SGI. / So I read the article, and all of those reasons could easily apply to any of the above filesystems.
Your very thorough reading probably missed this surprising section:
"Easy transition:
It is easy to change from ext2 to ext3 and gain the benefits of a robust journaling file system, without reformatting. That's right, no need to do a long, tedious, and error-prone backup, reformat, restore operation in order to experience the advantages of ext3."
It could happen to anyone. I know I had to read the article half-way before I even saw it!
crash? (Score:1)
After an unclean system shutdown (unexpected power failure, system crash)...
Power failures have been known to occur sometimes, but I've never had Linux crash.
Not what it says! (Score:5, Informative)
The article at LinuxToday isn't about RedHat prefering ext3 over other journaling filesystems. It's merely an explaination of why they decided to include ext3 in the new RedHat 7.2.
The only comparison made is between ext3 and ext2 where they explain the advantages of a journaling system.
Slashdot and Responsibility (Score:1)
The guy from Atheos (http://www.atheos.cx/) calls Slashdotting " The worst mass attack I have ever seen". Because this seems to be a continual (and somewhat legendary) problem, I think the powers that be (Taco et al) should put a system in place wherein they give sysadmins some sort of warning before they post a slashdot article which could take down their website with a "Friendly DDOS".
As Spiderman says, "With great power comes great responsibility", and Slashdot's power to strain system resources is very great, indeed.
Re:Slashdot and Responsibility (Score:1)
Experiences with ReiserFS (Score:5, Interesting)
Linux has never crashed on me without a hardware problem causing it (not an exaggeration), but that doesn't mean we haven't had plenty of hardware problems, and each time there was a failure, the fsck would take 30-45 minutes. My first thought was ext3, but... heh. It was always grayed out in the kernel config menus. Not a good sign. ReiserFS on the other hand was immediately available.
Of course, you don't trust your data to something without being damn thorough about it, so I did a bunch of tests on staging servers (which went great) and I spent a lot of time reading Hans Reiser, who impressed me considerably as a smart person with a lot of good ideas. We made the move this spring and have had zero problems with the filesystem during normal operations. Zero. It's blazing fast on our tests, it appears to scale beautifully, and if I go down, I have no wait time anymore coming back up.
Of course, I keep up with the kernel changes and upgrade when I see updates relevant to the filesystem.
It's not a perfect package, but nearly. Its consistency checker/repair tool (reiserfsck) is not finished (as its messages vigorously warn). Now, remember, this is not the same thing as e2fsck. You are not using it in the same role, its purpose is much more specialized (disaster recovery), so the significance is different. Still; we came to use it during several of the many times high-speed SCSI chomped on our asses and corrupted data. We have backups, of course, but I wanted to see what the tool was capable of. In several cases it was able to successfully rebuild the filesystem, very slowly, with --rebuilddb, but in several other cases, the tool would dump core, which, if you were one of those fools without a backup, would leave you stranded.
Even in this, however, I was reassured; the maintainer of the tool answers emails quickly and was eager to try to troubleshoot the problem. I thus have no doubt that it will quickly mature into something quite good. It's just not there at this moment.
On the whole I would say I'm extremely happy with ReiserFS; we've punished it here pretty brutally and it's passed every test. I don't have any experience with ext3, but anecdotally I'm told it's less mature. Still, I have nothing against it. I can only comment that I hope Redhat's upgrade process from 7.1 to 7.2 will at least take reiserfs into account, instead of breaking the way it did from 7.0 to 7.1.
We have experienced data loss with reiserfs (Score:2)
I say this not to knock reiser per se (I am quite happy it made it into the kernel tree, although I won't be completely happy until ext3, jfs, and xfs are all in the kernel tree as well so that they can compete with one another on quality and features rather than merely convinience), but to point out that all is not necessarilly sunny, nor is it unequivocably the "leader" when it comes to Linux journalling filesystems. I feel it is important to counterbalance some of these overly sunny depictions of experimental filesystems being used in serious environments with a little real-world, personal experience to the contrary.
I haven't yet tried ext3 or jfs, but have used various incarnations of xfs and must say that I have developed a preference for it over the last few weeks. That having been said, I still make use of ext2 filesystems in production environments and will only use less tried linux filesystems (previously reiser, now ext3 and xfs) in development/test environments only
These filesystems are fun and exciting, but they are not perfect, and in the case of reiser some rather serious (hopefully now fixed, but what's next?) flaws have gotten played down a little more than they should have. Remember, back up early, back up often, and be conservative in using any of them in anything other than a test situation (you can, once its tested to your satisfaction, but be cautious).
Back up early and back up often.
Re:Experiences with ReiserFS (Score:2)
It doesn't.
It'll recognize and keep your partitions.
Re:Experiences with ReiserFS (Score:2)
Corruption with ReiserFS (Score:2)
The only resolution I could come up with was to recreate a new file. It was limited to our ReiserFS / partition, and was most common with the rc.d scripts. This was a major headache and I decided that the journal did give some advantages but at that time (SuSE 7.0) was not ready for prime time, as it added additional ways things could go wrong.
This problem had a habit of preventing certain important services from starting because the metadata for the startup scripts would become corrupt. It was an issue for us, and it has not made us very favorable towards ReiserFS. In fact it prevented further migration.
XFS anyone? (Score:5, Insightful)
Re:XFS anyone? (Score:2)
I didn't know that. I have XFS running on all partitions including root on five machines (4 debian, 1 mandrake).
I've had no problems, either. XFS is awesome!
I wish Linus would put it into 2.5, and I wish Alan would then backport it to 2.4. I think it's proven itself.
LILO works fine with XFS (Score:2)
BTW, people can get more information about XFS, or download patches or kernel source from the SGI Linux XFS [sgi.com] site. CVS is also available.
Re:XFS anyone? (Score:2)
No, because our kernel people dislike some parts of its code. e.g. it adds system calls Linus hasn't approved, and changes too many parts of the kernel a filesystem shouldn't touch.
When those things get resolved, it will probably be re-evaluated.
Linuxtoday (Score:1)
because it seems to be in a little
Puhleeze. NIH (Score:1)
Easier Partitioning (Score:4, Interesting)
PM supports ext2 but not any of the newer exotic journaling file systems like ReiserFS or xfs.
The fact that ext3 is comatable with ext2, and can be converted back and forth is a welcome feature for those who use PM to manage their partitions.
Re:Easier Partitioning (Score:2, Informative)
resize_reiserfs works much in the same way.
I'm honestly not sure if the metadata and journal will be fully compatable with Partition Magic. It may just lead to a corrupt partition, but hell, that's what backups are for.
Re:Easier Partitioning (Score:2)
I'm not sure either. My plan is to try it on a fresh install once I upgrade to RH7.2 and see if it works. If it corrupts everything, no biggie since it was a fresh install.
It may also be that PM might refuse to recognize it if the partition type ID is different for ext3 (which I assume it is, although I don't know for sure).
The nice thing about ext3 in either of these cases is that you can back-convert to ext2, resize the partition, and re-convert to ext3.
BTW, I agree with your comments on alternative partitioning tools; but I have been a PM user for many years and have come to trust it, so I haven't felt like changing even though good GPL'd tools are now available.
Re:Easier Partitioning (Score:2)
I've used Partition Magic for a few years too, and I haven't see any Free alternatives around, apart from fips, and, well that comes no-where near PM for features.
Do you have the names of any of the 'new' ones?
compatibility (Score:1)
i dual boot
if i want to read linux files from windows i have only one tool at my disposal and its called explore2fs. this tool is very useful to me and would not choose lightly to change my linux filesystem.
for standalone linux machines this is not even an issue.
(dont suggest VMware i dont want to pay for it so i simply wont use it)
A review of filesystems (Score:1)
Because they're RedHat (Score:2)
Yes, I'm a Linux user, yes, I have it pre-loaded onto computers I buy for work and will sing it's virtues all day long, but RedHat is still a company and does have to make money. If they've tested the filesystems and one type works better for what Redhat needs in a filesystem, it doesn't take a brain surgeon to figure out which filesystem they're going to use.
The good news is that you can have a dozen filesystems on your hard drive and mount each and every one of them and not have to worry about which one is what when it comes time to go to that directory.
DanH
Re:Because they're RedHat (Score:2)
More importantly RedHat went with Ext3 because it offers similar performace, potentially greater reliability (since it is based on ext2 code) and most importantly, upgrading from ext2 to ext3 is much more straightforward.
RedHat has a lot of existing customers. Providing them with an upgrade path to a journaled is a clear win for them. ReiseFS may have been first, and it almost certainly is better in some situations (and not particularly worse in others). However, it requires a much more painful transition, it isn't backwards compatible with ext2, and it doesn't come with the wide array of bulletproof recovery tools that ext3 inherits from ext2.
The beautty of Linux is (as you pointed out) we Linux users get to pick and choose from a growing assortment of very acceptable choices. We are literally being drowned with cool filesystems, and once they are mounted they will all act similarly to the 'ls -la' command.
Linux rocks!
Michael Johnson Fails Objectivity Test (Score:2)
* Any non-trivial choice in the computer world has its pros and cons.
* Magically, Michael Johnson only finds pros in adopting ext3.
Conclusion: Michael Johnson is not fully confronting the issue or being fully objective and upfront.
Re:Michael Johnson Fails Objectivity Test (Score:2)
Yes, other filesystems have some advantages under some circumstances. Nobody here would contradict to that statement.
ext3 simply happens to be the only filesystem that has all the pros listed in the article, and those are the most important ones IOO.
Why, Indeed. (Score:2)
ReiserFS - mmmm... too hot.
ext3 - mmmmm.... Ah! Just right!
My thoughts... (Score:2)
=WHY CARE WHICH???=
Once you've formatted the partition, and loaded the appropriate FS driver, you don't =NEED= to care what the underlying filesystem is. There is NO DIFFERENCE!
From the perspective of Red Hat, or any other distribution, the difference in effort of supporting one journalling FS or a hundred is negligable. A menu is a menu is a menu. The number of items on it is irrelevent.
From the perspective of the user, it doesn't make a difference, either. Oh, it's a pull-down menu! Wow! Never seen one of those before, I wonder how it works. Duh! Give even novice users the wits to ignore things they don't understand, and expert users the freedom to tweak things they DO understand. Futher, since ALL filing systems behave in much the same way, from the user's standpoint, it doesn't make a damn bit of difference whether someone "messes up" on this or not.
Other Journaling file systems available? (Score:2)
I am have been using ReiserFS for about 18 months now and greatly appreciate it on my 20 gig hard drive on my laptop. Never had a single corruption problem, and always rebooting the machine quickly (specially with VMware crashing the system
Some systems at Ximian use XFS extensively as well. When you have too many files in a directory (for example Gnus spools) ext2/ext2 wont cut it due to the slow operations on directories with lots of files.
Miguel.
Re:Other Journaling file systems available? (Score:4, Informative)
We support installing to ext2 and ext3; reiserfs partitions are preserved when they're existing.
The kernel does not have XFS or JFS patched in (mostly code issues).
fsck not that long (Score:2)
Re:fsck not that long (Score:2)
(We had some wierd NFS problem from an AS/400 that caused Linux to lock.) While it's not a big deal for home users. Production servers are a much different story.
-Pete
Re:fsck not that long (Score:2)
No major fs changes in a point release ... (Score:3, Insightful)
I would, however, be surprised to see them skip XFS, JFS or ReiserFS in their 8.0 release. It would make sense for them to add that capability at that time (and would allow the implementations to mature that much more).
-- James
NVRAM? (Score:2)
Can someone with more patent-searching skills than myself verify? Thanks!
So, where is it? (Score:3, Interesting)
Two things: First, with 2.4 we were `promised' journaling and devfs. Both are still marked experimental, and of journaling, only ReiserFS is included as an appetizer, but the subsystem is still heavily in development. Some smaller things that were supposed to be improved at 2.4 are also still marked experimental. My guess is that most people -like me- are still using ext2 and device nodes, silently but eagerly waiting until journaling and devfs (and these other smaller things) get marked `stable' (by the proper authorities
Second: think GCC-2.96 (IIRC). RedHat has the power to shape the Free Software market a little bit the way they like it. With the inclusion of the compiler marked as GCC-2.96 they have practically released a GCC version without involving the GCC team. When RedHat issues a kernel that does ext3 (not just as an option, but as a default feature), I guess at least some of the results are the same as with the GCC-2.96 case. Although maybe this time not `faced with the facts' (that RedHat issued GCC-2.96), but merely `by popular demand' (from other distro's that want to use journaling by now), there will be some pressure on other distro's and the kernel developers to get journalining in.
Hmm. Maybe I'm really exaggerating the case. And do keep in mind that I'm not mad that I don't `get what I'm promised' or something like that. It just makes me nervous that I can't find ext3 anywhere in my fresh kernel sources (2.4.7; debian testing doesn't have 2.4.8 yet but I don't think the differences are that big wrt journaling and `marked experimental' stuff AFAIK from the changelogs) while the ext3 patches for the 2.2 series _are_ in the distro. And I really can use that stable VM of 2.4; earlier on the GIMP crashed my box, now it just crashes itself when loading huge things. I do get complete keyboard blocks once in a while, but no trashing anymore, and hey, that's what the reset button was built for, right?
Which brings us back to journaling.... Oh well
Related note: beta2 released (Score:2)
what is the max file size? (Score:2)
Re:isn't it Chose? (Score:1)
(Yes, it's chose. Perhaps they'll fix it sometime.)
Re:isn't it Chose? (Score:2)
Why Redhat Choo-Choo-Choose ext3 for 7.2
and replace the Red Hat logo with a picture of a train
Re:NTFS! (Score:2)
If it don't run properly on Linux, I don't run it.