Slashdot Mirror
Is ext4 Stable For Production Systems?
dr_dracula writes "Earlier this year, the ext4 filesystem was accepted into the Linux kernel. Shortly thereafter, it was discovered that some applications, such as KDE, were at risk of losing files when used on top of ext4. This was diagnosed as a rift between the design of the ext4 filesystem and the design of applications running on top of ext4. The crux of the problem was that applications were relying on ext3-specific behavior for flushing data to disk, which ext4 was not following. Recent kernel releases include patches to address these issues. My questions to the early adopters of ext4 are about whether the patches have performed as expected. What is your overall feeling about ext4? Do you think is solid enough for most users to trust it with their data? Did you find any significant performance improvements compared to ext3? Is there any incentive to move to ext4, other than sheer curiosity?"
Is ext4 Stable For Production Systems?
Probably.
Is there any incentive to move to ext4, other than sheer curiosity?
Ok so I'm gussing production = income = your ass? Let me turn your question back to you by asking, "What is driving this need to move to ext4?" Because so far, all you've told me is that you are considering risking your ass for sheer curiosity.
... no, we could have a customer on the phone saying, "You mean to tell me that the modifications being made to my site for the past 24 hours are gone?!"
I may be grossly misinformed but that is how the question sounds to me. And by "your ass" I don't mean oh-no-we-had-a-service-outage-for-five-minutes
If it ain't broke, don't fix it!
I don't know about you but I'm too busy dealing with shit like this than to ponder new potential problems I can put into play.
Look through this page for a rough comparison of ext4 with other file systems. There's a better list of features for ext4 here that will tell you why you might need to switch to it. It is backward compatible with ext3 and ext2 so moving to it may be trivial. If you're dealing with more than 32000 subdirectories or need to partition some major petabytes/exobytes then you might not have a choice. Some of these benefits are probably not risking your ass for but if there's a business need that cannot be overcome any easier way then back your shit up and do rigorous testing before you go live with it. If you're using Slashdot to feel out if the majority of users scream OMGNOES so you don't waste your time doing that, then that's fine. Just don't do this if you don't have to.
I tell you what, there's a $288 desktop computer at Dell today that you can buy, put ext4 on and your OS of choice and your application(s) and whipping boy it into next century without risking anything. Where I work we have two servers in addition to our production servers. I don't think this is an uncommon scheme so if you have a development server, throw it on there and poke it with a stick. Then move it to the testing server and let your testers grape it for two weeks. Then you'll know.
My work here is dung.
I've been running ext4 on my system and everything's fi
You are asking the wrong question. Ext4 does not need fixing, the apps do.
Are your apps patched yet?
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I would just wait until it becomes main stream and all the issues are worked out, until then I'll stick with ext3
I moved to ext4 as soon as it became available. I haven't had any problems thusfar (no data loss, etc), and the increased speed is noticable. So - in the opinion of a very casual Linux user - I would say that yes, it's "okay." I'm not sure I'd trust it with anything super serious, though. I could be the only one without any problems, after all. As always, you should tip-toe around anything bleeding-edge.
If you're producing file undelete software.
The extents mean that a large contiguous read is faster and files are more likely to be written in contiguous chunks, giving a bit of a boost to the filesystem. That's the explanation I have for my system and its 5400-rpm laptop disks seeming quicker (note that the appearance of greater performance isn't greater performance).
It depends on why you are switching from an older filesystem to ext4. It's a relatively new filesystem so you should probably expect it to be a bit more buggy when combined with software not designed for it. From my limited experience with a combination of KDE and ext4 recently I'd wait on upgrading for a while. Ext4 looks like it could be very interesting as software matures around it however, as it is currently KDE seemed to me at least a bit less stable on ext4 than it was on ext3. however, I didn't stay with the filesystem as long as I should have so take this with a bit of salt...
Sigs are too short to say anything truly profound so read the above post instead.
I'm using ext4 on an encrypted partition on my tiny X41 tablet. The hard disk is 5400RPM IIRC, so when Ubuntu decides to run fsck due to a scheduled run or an unclean shutdown after a certain bug manifests itself, I don't have to sit there for 10 minutes or more waiting for fsck to run. That for me and many other casual users is probably the biggest advantage of ext4.
Does a laptop count as production? In the eyes of an everyday user, yes. My laptop is very much "production" IMHO, and I trust ext4 enough to not magically make all my school assignments disappear.
Digressing a bit, I haven't seen any of the data loss either, though I use GNOME and not KDE. I do think that if an application relies on specific undocumented behavior, that the application should change, not the filesystem driver. It's acceptable that the kernel developers are doing their best to get temporary workarounds into place, but the permanent solution is to fix the applications so they don't depend on undocumented behavior.
...a moot point for me....I have been using xfs for several years, and so haven't tried, nor do I think I need the latest iteration of ext. But like was opined already, it's not ext4 but the apps that need fixing. So it seems at least.
Well, the fsck times are really fast compared to ext3, and thank god, because EVERY time I reboot it requires an fsck, complaining about group descriptor checksums. Even if I unmount my ext4 filesystem and remount it without rebooting it gets all fscked up. I have a 3TB ext4 fs on LVM on RAID, that was NOT converted from ext3, but built on brand new drives. My similar ext3 filesystem has had so such problems.
ext4 takes about 7 minutes to fsck, ext3 took hours. I hope they fix this soon.
every _exit() is the same, but every clone() is different.
We avoid anything that has less than 24 months of wide deployment unless there is some absolute pressing need to move to an unstable/untested product.
We have test and development systems where we run latest and greatest, but generally they are used in sync with the existing system. We don't switch over until we're damn sure there aren't any unforeseen consequences. That typically means 12 months without any major hiccups and 3 months without minor ones.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
I was one of the people that spoke loudly when Ext4 caused 0-byte file corruption.
While I don't entirely agree that it's just "an application issue", because apps that work fine on every other filesystem should not need to be re-written specifically for Ext4, I am pleased at the work the devs have done to work around the problems. The kernel patches have eradicated the issues I had with corruption, and the performance is still great.
I never did official benchmarking to determine the extent, but my perception is that there's a noticeable performance increase when using Ext4 instead of Ext3.
If I were building a production server, I may think twice and just go with Ext3... unless the app would *greatly* benefit from Ext4. However, for a desktop system, I think Ext4 is a very good choice and ready for primetime.
After the famous filesystem corruption due delayed allocation I lost confidence in ext4. I've been using xfs on some partitions and it works great.
Is anyone else getting a lot of these "connection intrupted" errors when clicking on stories?
It's been going on for a week now and is making slashdot almost unreadable and annoying.
I've never used anything other than Reiser3 with Linux. Might not be the most reliable or fast, but it has other advantages.
- Undeletion.
- Partition resizing.
- Readable from within Windows via YaReG.
http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/
FYI, Ts'o is the ext4 maintainer.
You should be asking this question in a more authoritative forum. The majority of Slashdot readers are likely to just regurgitate their perceived status of ext4 from the last time ext4 was mentioned on Slashdot and I know for certain that ext4 has had more testing and development since then. Try asking the ext4 development team; they're very nice, helpful people in my experience. I refer you to the #ext4 channel on irc.oftc.net and the linux-ext4 mailing list.
last I checked some patches for the dealloc empty file problem was being merged in 2.6.30. if you want to avoid it but want some other advantages like faster fscks you could go with data=journal on your filesystems which is a bit slower but also disables dealloc, while still having extents, barriers, and other ext4 benefits. I've been using data=journal on my /home partition without a single problem.
it also depends a lot on what you have in 'production'. a web server that's mostly doing reads it should be fine for. a heavy email server... well.. can you afford to lose email on a crash? I think it might be alright for a server that just does mta but not the fs for the actual mailbox's (with dealloc anyways). database server should be fine, because the database's job is to make sure data hits the disk, among other things. dns servers are a very read heavy so again I would think it'd be fine. so basically you need to watch anything that's heavy write and not to a database, and even then only with dealloc.
still as I'm sure others have said, it's a good idea to wait on new tech like this. some tools don't yet recognize that ext4 is not ext3.
I have installed a system and have been getting resize inode invalid and group descriptors corrupted issues on clean reboots. fsck has yet to fail me, and IO stress tests have demonstrated no general io corruption other than ext4 errors.
On the flipside, for my applications I haven't really gained much.
XML is like violence. If it doesn't solve the problem, use more.
Im running ext4 too but as you can the content of my posts is fine!
IranAir Flight 655 never forget!
Ive used it for the past few months on my netbook, however I've only recently tried the Fedora 11 build on ext4 on my desktop. I was impressed w/ the boot speed on my netbook, and for the netbook thats all that really matters. I had absolutely no problems w/ the netbook using Jaunty UNR and ext4.
I did have some problems w/Fedora on my desktop though. It booted nice, and did all the easy stuff well (web browsing, office stuff, etc.) but it got all screwy w/Wine and Eclipse. It might be the GPU I have, or the lack of driver support for Fedora w/it, but Wine ran extremely badly with Steam and Left 4 Dead as compared to a Fedora 10 build w/ ext3. Also I had the typically reported problems w/ext4 and data loss when I was doing some Android dev in Eclipse.
Like anything new in the open source community there are bugs to be hashed out. If nobody uses it and nobody reports the bugs then it won't get better. The boot speed gives it value. Windows 7 RC is booting only slightly slower than ext4 (at least on my system) so if Linux is going to make its stand its got to do certain things to make it distinct. I believe simple things like boot-time and broad dev support are the areas that Linux can shine and to that end it appeals to the right clientele to take it in the right direction as a community. :)
It still needs more time. I have played under both ubuntu and rhel 5.3 and run into strange behavior that makes me uncomfortable.
1) Bonnie++ throws errors even on server class hardware that something is wrong when creating and deleting a large number of random files. This is with no errors in the filesystem and everything operating normally. https://www.redhat.com/archives/ext4-beta-list/2009-February/msg00000.html
2) A crash of ubuntu ended up removing *ALL* group and other permission on a laptop drive. Not just those altered within 2 minutes of the crash, but of every single file in the system leading to a system that non-root users could not log into.
Neither of those are acceptable. For now it's still ext3 only until ext4 has had some more time to mature.
If my understanding of this problem is correct, it occurs only if the system crashes shortly after the KDE apps have updated their configuration files. If so many people think this is a big problem, I'm more worried about the great number of constantly crashing linux machines.
It's not that a ton of Linux boxes are crashing. It's just that it's a computer, and sometimes they crash. ANY computer. Any machine, any OS. They're made by people, and nothing we make is ever perfect.
In the light of that though - what we're striving for is to provide the best performance and the best results under any circumstances, even the rare ones. Worrying about these <1% corner cases is what makes a superior product. A problem handled gracefully is a problem the user hopefully never sees. And that goes a long way towards creating a satisfactory experience. People say things like, "I don't know - I just plugged the scanner in and it died." They never say "I've plugged this scanner in over 1000 times and it's never died!" People remember the negatives, so it always pays to minimize those, however rare they may already be.
Weaselmancer
rediculous.
He presents three common cases for 'quickie' file modifications:
-Modify-in-place. Yes, this logically cannot be expected to leave the content intact in an unexpected interruption. You ask the OS to blow away data, then send it new data, there is a logical indeterminate state in the middle where doing things in the order you specified leaves you exposed.
-Write new file, use rename, using fsync to ensure a low exposure of data. This forces data to disk so it's coherent.
-Write new file and then use rename without fsync:
*This* he claims should easily be expected to corrupt the contents. I take issue with this. The fact that this occurs is because ext4 commits the rename out-of-order ahead of the data commit. I don't understand why the rename operation cannot also be delayed until after the data has been written out. I've seen several people ask 'I don't care that the change happens *now*, but I want the changes to occur in the order I specified', and thus far have seen Ts'o miss that point (intentionally or unintentionally). I have not read any explanation of why changing hardlinks should logically be an operation to jump ahead of pending data writeout. I could be missing something, but I'm not the only one with these questions.
fsync gives a relatively expensive guarantee above and beyond what people require to behave sanely. He says its inexpensive 'now' relative to the past. However, 'now' in this context only applies to ext4 users and thus the operation degrades other filesystem performance and fsync remains an expensive operation relative to not doing at all.
In terms of the general attitude of filesystems shrugging off data consistency so long as their indexes are intact, I find myself agreeing with Torvalds' comments on the debacle:
http://thread.gmane.org/gmane.linux.kernel/811167/focus=811700
XML is like violence. If it doesn't solve the problem, use more.
A laptop? No, that doesn't count unless you run your production system on another laptop of the same build and make. At least where I work production is business critical systems on real kit, then we have our development environment, testing environment, and after that (in terms of importance) we have the business/office network and individual workstations (and your laptop would be somewhere after that).
Nothing a developer did on a home system would be considered production ready without, you know, doing lots of actual testing.
Quack, quack.
A couple of months ago i installed Ubuntu 9.01, which used ext4 by default. Running it, i experienced data loss for the first time since i moved from ext2 to ext3 quite a few years ago now. I've just changed back to ext3 - which has been rock solid for me since it first appeared in Redhat or whatever distro it was i was using back then.
I nearly lost my whole filesystem. It's a good thing I had a backup core system on reiserfs to boot from and run fsck. from what I understand, it's a problem with the ext4 journaling system and metadata. this link has info on the journal problem...which may have already been patched in the current kernels. http://lwn.net/Articles/284037/ wiki page for ext4 - bottom has a fix for the problem: http://wiki.archlinux.org/index.php/Ext4 essentially, mounting and ext4 filesystem with option "data=ordered" helped my system out. since I have enabled this mount option, my filesystem is now stable even after hard reboots or power failures. Hope this helps out people as it did me! -Kamphor
As someone who recently had the latest ubuntu trash every inode on my ext3 partitions, I'd have to say no. Not because my case is related to ext4 in any way, but because if a kernel (2.6.28) can get ext3 wrong, I shudder to think what happens with ext4.
Funniest thing I've seen in weeks!
My two cents worth: if in doubt, don't. Wait a year for others to find the bugs.
Why does everyone keep speaking about EXT4 as if it's broken? It's working exactly as designed. It's the applications that need fixing, no?
Filesystems are mission critical for everything. Stabilility is the thing here. Personally, I see no reason to risk this until they iron out all the wrinkles.
Here's my opinion on ext4:
Our 8TB raid system would get trashed after copying data onto it (group descriptor checksums on fsck). It looks like it was an ext4 bug. They fixed it about a week or two ago, here. Maybe it will get in your kernel soon. I'm not going to start ext4 on any production system for at least 6 months I think now.
His point was that POSIX doesn't speak to crash behavior. As such, if a system detects a crash and zeroes the MBR and nearby blocks, it would still be POSIX compliant, but no one would plausibly be mollified by that.
The application isn't making a complex assertion based on undocumented behavior not contained in a spec, it's making a very simple assumption that if it writes data to a file, and then calls rename when those calls complete, that those two operations will proceed in order. It proceeds in order on the running system, and the desire expressed is that same ordering guarantee occurs to persistent storage (it is acceptable to be stale/lagged, so long as the second operation didn't jump in front of the other).
XML is like violence. If it doesn't solve the problem, use more.
Face it: your side lost. "fsync everywhere" is an infeasible, untenable, and useless position to take.
For all the people that complain about 'fsync everywhere', what do they do on other operating systems? There were issues on ext4, but what about Solaris UFS, BSD FFS, NetApp homedirs? What about applications on OS X HFS compiled via pkgsrc or fink?
The debate seems to be between some app developers and the Linux FS devs; how about bringing in some "neutral" parties and see how the applications work on those systems?
If the app is still "broken" on a non-Linux OS, it's probably the app; if it doesn't have data-loss issues, it's probably the behaviour of the Linux FS.
I have the *exact* same problem as the parent poster had (fsck being required with group descriptor corruption and/or resize inode issues). On clean reboots.
This system I have done lots of stress testing outside and inside of the running ext4 without rebooting, and have had no problems with ext3 or any data miscompare at all to suggest fundamental I/O misbehavior. I have only had problems with ext4. I have not seen data loss after fsck -y, but I have had to fsck -y a lot *despite* never having resized, converted, or suffering a crash on the afflicted system.
That being said, I have ext4 in three places. In two places (my smaller systems), I haven't observed this. I have only observed it on my 2 terabyte volume.
XML is like violence. If it doesn't solve the problem, use more.
And had it been enforced, as soon as all developers went thru and added the fsync calls everywhere it would have become necessary for file system maintainers to no-op fsync calls in order to regain any approximation of prior performance.
Is this true on every POSIX FS (UFS, FFS, NetApp NFS, XFS, etc.) or just ext3/4 on Linux? Just because something sucks on Linux doesn't mean it sucks on other Unix-y operating systems.
(It's like NFS getting a bad reputation--especially locking--because Linux's implementation sucked for so many years.)
Disturbingly enough, rename under OS X's HFS+ filesystem doesn't appear to be atomic even on a running system. If they can't get rename right on a running system, I'd hate to see what kind of scrambled mess the filesystem is after a crash.
I've been running it for a few months now, and haven't had a single issue.
If you answer someone's question about a feature being ready for production systems with the word "probably" instead of "absolutely," then it's not ready for production systems.
I tried it briefly. I had no problems with it. However, I did not see the extreme performance promised and the rumours of data loss were surfacing so I switched back to ext3.
I tried ext4 as soon as it hit 2.28. I never ran into the KDE bugs, but I did notice it complaining that the filesystem was full despite many GB being free (and we're not talking about the relatively small amount reserved for root here).
It certainly wasn't fit to be renamed from ext4dev at that stage.
Too subtle. Noone reads the titles these days.
$ make available
Linux is a mess.
but it seems like I've been getting random freeze-ups since using it. Usually happens when downloading 500mb of gmail into evolution, or when deleting/adding more than 100 or 200 MB of files in one fell swoop.
See https://bugs.launchpad.net/bugs/327509 for more.
When the torrent client creates the file (most fill it with zero to avoid fragmentation at the beginning), it's almost instantaneous, while with ext3 it can take a few dozens of seconds for large files. However I've experienced process lockups on ext4, nothing shows up in the log but the process accessing files on ext4 is unkillable (zombified).
When they went to journalling filesystems, by and large a simple mount operation turned into a mini-recovery operation, a psuedo-fsck if you will. This would even happen on read-only mounts, which to me violates expectations of no disk data being modified.
JFS had one 'quirk' that I think they got right, journal replay was an fsck-level event. A filesystem with a dirty journal could only be mounted read-only and the journal replay code was in fsck and had to be ran to enable remount read-write. There are numerous reasons why I stopped using JFS, but that is one point I kinda agreed with their quirkiness on.
XML is like violence. If it doesn't solve the problem, use more.
The comments on this thread seem to be a bit mistaken on average on what the hubbub was regarding ext4 and KDE, so I'll try to clear it up a bit (I'm a KDE dev but I'm not speaking for KDE here of course).
The "issue" with ext4 was that it's handling of the standard write(); close(); rename(); idiom for replacing existing files by writing out a new file and then renaming it in-place over the old one could leave zero-length files laying around if the system crashed .
ext4 never would spontaneously delete data merely because rename() was used, it was a side effect of its implementation that if the system crashed before the data had been written to disk but after the rename had taken effect then a zero-length file would be left in its place after restarting the system.
Where KDE comes into the picture is that KDE 4 writes its updated settings to disk too frequently (which is a known bug, now fixed, KDE bug 187172 pertains). So, if you were starting up or shutting down your KDE session when the system crashed you'd likely have had quite a few config files written out in the past 60 seconds or so. ext4 is very good about writing out metadata so the renames would have taken effect. But apparently ext4 didn't force the actual file data to disk until 60 seconds had gone by (unless asked to via fsync()). So after the reboot there was a great chance that the $KDEHOME/share/config/*rc files had been effectively truncated, thus causing loss of settings.
Many people have complained that KDE should do "the right thing" and use fsync() everywhere, but most people don't know that KDE had always done that... until ext3 became popular. ext3 suffers massive slowdown in the face of fsync() (although I guess some kernel hackers will have that mostly fixed in 2.6.30?) so KDE actually removed fsync() calls in response to user demand. And there's no less than two fsyncs() that would be required, one to force the file to disk, and a second to force the update to the directory after the rename().
People claim that KDE violates POSIX standards but really the effect we get from using rename() with fsync() is exactly what we want, a kind of lazy "version A or version B, one or the other". At least for rc files, it is not at all important that version B be reflected system wide afterwards at the time the write() happens so fsync() is overkill. Of course ext4 isn't "violating" POSIX either, but most agree that its behavior was undesirable in this situation, so patches have been committed to ensure ext4 adds ordering in this case to ensure that metadata updates happen after data updates.
I actually just converted all my filesystems to ext4 (from XFS) the other day, since it's at least possible with appropriate mount flags to get ext4 to act as a proper desktop FS. (I didn't know about XFS's similar issues with power loss until it was too late). So far everything is working nicely for me, although I haven't intentionally power cycled to test that case either.
KDE did already do the 2nd (what you list as correct), and most developers assumed that this was sufficient to keep the files in a consistent state, due to rename() being atomic. The problem is the sync issue you mention afterwards: the failure mode being encountered was that the rename() executed instantly to clobber the old file, while the new file still contained no data on disk. If the machine crashed in the window between the rename() and the sync, you have neither the old nor the new file.
The main thing being discussed with KDE (and others) is how to fix this. Adding a sync() after every config update totally destroys performance, if you might update hundreds of small config files semi-frequently. See, for example, this discussion among Python folks for pros/cons of various options.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
As always, when considering a new technology, the best place to deploy it is in large, single-purpose setups that actually benefit from the differences relative to the thing you're replacing. You'd have to be completely nuts to migrate an existing data center full of disparate workloads to ext4, but if you're about to deploy a bunch of functionally identical streaming media servers where the improvements in handling large volumes and files will make a measurable difference, and the cost of validating the setup is amortized across several production systems, you'd really be nuts not to at least consider it. If there's an app that does something stupid, you have one bug report to file instead of 50, and you need to change one install configuration file to fix it.
Don't be first, but definitely don't be last.
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
I'm running KDE4 on EXT4 since March, and zero problems. Is it any better than EXT3? Not in any noticeable way. I think it's faster, but haven't benchmarked it. It's not the-difference-between-cable-and-dialup faster.
Nothing to see here. Move along.
I love it when an ask Slashdot article has the answer to the question as the first sentence.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
It does seem to be working well, even though it crashed it still managed to recognise that you were half way through doing something and posted the reply for you ! I'm presuming it does this for other data, that, for example, you're trying to save when you have a sudden power outage.
...the three reasons are performance, performance and performance.
Ext4 has extents (and therefore loses indirect blocks), a better on-disk layout policy and generally better algorithms in its allocation code. Of course, performance varies depending on the app in question but we've found that it beats ext2 in almost every respect in our environment. (We don't run ext3 because journals cost performance [by buying reliability] and that's all ext3 gets you: a journal. This is why we wrote and submitted the no-journal hack for ext4.) In particular, ext4 beats ext2 for write-heavy loads by, well, lots. Yes, we've measured this stuff.
So why would one go to ext4 over ext3? Because it's a better file system, not to mention one that's actually (a) being developed and (b) past pre-alpha.
Of course, our environment is a tad different from most. We have *ahem* more than a _couple_ of servers.
Ever heard the term "Time Tested?"
EXT4 will be "time tested" in another 3 years.
That's when production users will **know** how safe this file system is to deploy.
Before that, you have a bunch of unproven yahoos saying "works fine for me" OR "crashes my system constantly" based on individual experience.
I won't be touching it for another 2.5 years and then it will go into a lab for 6 months of testing with
- our hardware
- our operating systems
- our patch methods
- our applications
- our people running the systems.
Good luck and be careful out there.
I've never used anything other than Reiser3 with Linux. Partition resizing.
Which by it self is a sure win of Reiser3/4(*) and Ext2/3/4 versus JFS and XFS which can only increase size.
That's part of the reason I'm using it too.
Readable from within Windows via YaReG.
Another tool you might be interested by too :
Virtual Volumes.
- It's by the same guy who wrote Explore2fs
- It supports ReiserFS using the same tools (rtstools) as YaReG.
- It supports also RAID and LVM.
- Read/Write support.
And hoepfully, they'll end up adding WebDAV support so you can mount file systems under Windows.
(*): Now that development has been taken over by Edward Shishkin, shouldn't this get renamed as ShishkinFS ? :-P
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
EXT4 is the newcomer and KDE has worked fine not just with EXT3, but with all the other filesystems like XFS, JFS, Reiserfs and even Reiser4.
Its clear that EXT4 was NOT testing with crucial existing system software before release. And now that the audio and graphics architectures are a screwed up mess due to disregard for PC users and their most critical software and use cases, we can thank Linus & co for poisoning even the filesystem itself, which will get foisted on unknowing users who won't even know enough to change the default fs or to make a choice between data integrity and performance.
Grrreeeaaaattt job!!!
Computers aren't magic boxes. They have real physical limits. Software engineers aren't magicians. They need time to perfect their code.
i've been using it since, what, 2 days after Ubuntu 9.04 came out, on a 250gb HP convertible and a 20gb SSD eee 901. No issues. I'm impressed by the speed. It does work, and I'm very ok with that.
I am not running what you would call a production system. But I installed the latest Ubuntu with the EXT4 file system and it works just fine.
If you're concerned with specific applications, what is keeping you from testing those on a limited basis in a production environment with EXT4, making frequent backups on those computers as a precaution against what you are worried about?
If you're happy with EXT3 and it works without problems in your work place, why do you feel the need to change? Yes, my Ubuntu boots faster with EXT4. Early development feedback suggested that this would be the case. But once the computer is up and running, I can't say that I notice a large speed difference, so if you're looking at productivity improvements, I wouldn't bother with changing your file system.
Why not just wait until EXT4 has been in general use for a while, then make the switch when you upgrade your Linux distro? By then, if your concerns are valid, they will have either been addressed or not, and you will know if it's something you should avoid.
My understanding, explained by the development people at Ubuntu, is that there were two ways of keeping track of where data was on a hard disk partition, and some programs didn't work well with one of them. That issue was addressed in Ubuntu, and I am sure it was also addressed in any recent major distro that is offering the option of using the EXT4 file system. I don't remember the specifics, as it was complicated and beyond me to completely understand it, but I grasped the basic concept and was satisfied that they pinned down the issue that caused serious problems and addressed it well enough to include the option to install that file system when installing Ubuntu.
Whether you switch file systems or not, you should have a good backup system. Some businesses still don't have a reliable backup plan. I hope you're not one of them. Whether you're using EXT3 or 4, things can and do happen, even hardware failure that is independent of whatever file system you are using.
How did this 'article' ever get past the filters?
Of course the answer is 'if you have to ask, then you can't afford it'.
While the P gave a very detailed response, the ultimate answer is: you should not be asking this question.
Good judgement comes from experience, and experience comes from bad judgement.
- W. Wriston, former Citibank CEO
Forget it. ext4 is still not stable even though they took the "dev" tag off. The filesystem is going to have problems upon problems upon problems for months and months and months and you're going to be looking at updating and patching kernels in perpetuity to keep up with those patches. The only thing they stabilized was featureset and on-disk format.
If you want the features of ext4 for production, you should already be running XFS. You can't get much better on Linux filesystems these days. By the time ext4 gets to be "production worthy" (by this I mean has spent a year in the tree and become the default on major Linux distributions meaning thousands of people have installed on it, found all the showstopper bugs and had it patched in distro downstreams at least), you can bet Btrfs will be out and "stable" anyway, and you'll be asking about whether THAT is ready for production.
Use XFS now. Wait 18 months for Btrfs, if it is indeed any better. If not, and still looking for a filesystem challenge today, work out a way you can use ZFS - which has its problems on Linux (especially that it needs to run through FUSE - not a performance issue so much as a technical nightmare to use it as your root filesystem that no distro actually would support because of moronic non-free policies).
All I know is that I converted my laptop from ext3 to ext4. It became unstable as hell freezing over all the time. Just reinstalled it with ext3 and everything is fine and stable.
Possible it was because one time my comp froze up and had to be forcibly shut down, after that an fsck was run that had to fix some errors. After that hell broke loose.
On a laptop it should be possible that the battery runs out without having to reinstall everything, at least that works with ext3.
So far I value the robustness of ext3 more.
Yeah, I have ReiserFS on my laptop, and everyone here should really switch to that for Desktops at earliest convenience. Quick fsck, reasonably reliable, extremely fast, extremely fast, faster than ext3, faster than ext4, very fast. On my desktop computer however, I didn't have the time to take the system down to re-format for ReiserFS. So I switched to ext4 because it's faster. Time is money, don't argue "don't fix it if it ain't broke" with me. I'll tell you when it's broke. When the long-abandoned ReiserFS is fast as shit on a slow machine, but the ext3 looks like performance wasn't even considered when used on more recent hardware. Time is money guys. Yes, I can be more productive with ext4 when I have 8 virtual desktops and multiple projects for multiple companies requiring completely different application sets simultaneously on my computer and just trying not to get more than a week behind on any of them.
I still use ReiserFS. It's killer!
I hold very few opinions. I hold information based on observation and fact. If you wish to disagree, please use facts.
I've been using it with Kubuntu since 9.04 came out, and haven't had any problems at all. Maybe I just got lucky? but I doubt it. I regularly back up everything anyway, so I'm not too worried.
I use Ext4 on my new notebook without any problem.
JMule user : http://www.jmule.org
It does not even have an equivalent to fsck.
IANAL but write like a drunk one.
We must face this, ZFS ate Linux's lunch this time ...
IANAL but write like a drunk one.
I think it does not harm to ask questions about anything here.
Sometimes you need people with relevant experience that are somehow detached from a given issue but that still can provide useful advice.
On CentOS 5.3, we get data corruption with multiple versions of MySQL, but only if we use ext4. ext3 works fine, but it's the same old crappy performance.
As long as you can get things working you should be OK.
I have installed it in Shuttle machines and the only thing that didn't work out of the box was the network card driver, which I found quickly after googling a bit.
IANAL but write like a drunk one.
You're right. You don't need a server grade machine to run it. You probably don't need RAID to use ZFS either.
But I'm a "home" user. Why would I use a platform which has smaller hardware support when I'm already having problems with Linux? That is, why would I use Solaris if I'm already having issues with some hardware under Linux? My wireless card on my laptop is working ... mostly. How would it perform under Solaris?
What about all the software -- I enjoy Debian and precompiled software. Even installation of packages under Debian takes too long for me; I can't imagine compiling all software not included in Solaris. Not to mention most of it isn't regularly tested under Solaris.
Tell me again, why would I, as a home user, use a platform INTENDED for enterprise, and usually server, environments?