How To Move Your Linux Systems To ext4

LinucksGirl writes "Ext4 is the latest in a long line of Linux file systems, and it's likely to be as important and popular as its predecessors. As a Linux system administrator, you should be aware of the advantages, disadvantages, and basic steps for migrating to ext4. This article explains when to adopt ext4, how to adapt traditional file system maintenance tool usage to ext4, and how to get the most out of the file system."

Not for the casual user

ext4fs is designed to be used in systems requiring many terabytes of storage and vast directory trees. It is unlikely the common desktop (or even, for that matter, the common server) will see appreciable performance increase with it.

Re:Not for the casual user

Do you realize how much porn some people have?

Re:Not for the casual user

It is unlikely the common desktop (or even, for that matter, the common server) will see appreciable performance increase with it.

Disk sizes are going up. In a few years you'll see a terabyte on a single drive. I'd also say that features like undelete, and online de-frag are important to anyone.

So while you may not see any real performance increases, that's really beside the point.

Re:Not for the casual user

Instead of waiting a few years, go to your local computer store. They should have terabyte drives now.

Re:Not for the casual user

Disk sizes are going up. In a few years you'll see a terabyte on a single drive.

Unlike those two 1000 GB (or is it 1024) drives I have on my desk now.

Re:Not for the casual user

Disk sizes are going up. Since last year we've seen a terabyte on a single drive.

Fix'd it for you.

Re:Not for the casual user

Ext4 has a lot of performance improvements, like extents or delayed allocation. Desktop users will notice that ext4 is much faster

That said, ext4 is unstable. It can easily eat your data. Just say NO to moving your filesystem to ext4 - for now.

Re:Not for the casual user

All you young kids want these days is a faster, more convenient fsck.. What about the old days where fscking was about the technique, not the speed or the size...

Re:Not for the casual user

What about the old days where fscking was about the technique, not the speed or the size...

I'm just happy when it's done for me, and I don't have to handle it manually. When fscking fails at the beginning, it can ruin your whole day if you're not an expert.

Re:Not for the casual user

No kidding. Sometimes I'm just not into fscking either, but if you're failing at the beginning, you may want to call an expert.

Usually my problem is that my fsck gets a "fsck-completed-normally", when the media is really only half fscked.

But don't worry -- fscking takes practice. If you got a quality media, you can half-fsck it many times before the media fails completely.

May I also suggest fscking aids? There are many tools on the market that can help when your fscking routinely fails doesn't complete. They're usually lightweight and easy to use, and can help to save your media from getting fscked elsewhere.

As you said, when all else fails, sometimes you really do just need to handle it manually.

Re:Not for the casual user

This is why we have XFS. I fscked a 9TB partition is under 10 minutes. Hopefully they've done some improvements for ext4 in this area. A volume that takes days to fsck might as well just die completely.

Re:Not for the casual user

I fscked a 9TB partition is under 10 minutes.

That's what you get when you throw a harddrive in a bathtub with water.

Re:Not for the casual user

I can't wait for faster fsck.

I can tell you're a slashdotter. When most people fsck they want it to last as long as possible.

Wikipedia entry

Link to Ext4 [wikipedia.org] entry on Wikipedia for people who aren't familar with it (like me).

Re:Wikipedia entry

My Linux box goes to ext11.

To all ext3 users...

...who are on the lookout for a new fs to entrust with keeping their precious data: make sure to check out btrfs ( http://oss.oracle.com/projects/btrfs/ [oracle.com] ). It's a really neatly spec'd filesystem (with all the zfsish stuff like data checksumming and so on), developed by Oracle employees under GPLv2, which will feature a converter application for ext3's on-disk-format - so you can migrate from ext3 to the much more feature-packed and modern btrfs without having to mkfs anew.

On a related sidenode: I'm very happy with SGI's xfs right now. ext\d isn't the only player in the field, so please, go out and boldly evaluate available alternatives. You won't be disappointed, I promise.

Re:To all ext3 users...

btrfs -- How fast are deletes?

ext3 is both so slow and so bottlenecked that mythtv had to implement a special "slow delete" mode which gradually truncates files instead of just unlinking them. Without the "slow deletes" mode, you get hiccups in any shows that are being recorded while old shows are deleted.

On my system, deleting a 20GB file can take a minute on ext3 (and the filesystem is completely locked - all other processes are blocked), but on ntfs it is almost instantaneous.

undelete

Oh, please. ext2 had "undelete" capability, just as it had filesystem compression capability. Neither were ever implemented.

What about comparison to other filesystems?

Those features may be new to ext3, but not to the real competitors. I see nothing that might grant an edge over JFS or XFS. The real justifications will come from performance tests.

This reminds me of the recent NTFS article here, which actually suggested that since Hans Reiser is in jail and reiser4 is dead, we should consider NTFS. WTF? The ludicrousness of using NTFS as the primary filesystem is further justified in this article by its similar performance to ZFS, but both run in user-space (and are thus horrible in performance), so neither is really an option. What the heck is wrong with JFS and XFS?

Here are some real comparisons: First, Wikipedia's Comparison of file systems [wikipedia.org] gets you started with a nice mapping of features. Second, a benchmarking of filesystems from 2006 [linuxgazette.net] which is still quite applicable (though it doesn't yet cover ext4). What we need is a comparison of EXT4 to XFS and JFS (et al), with EXT2/3 in there for reference.

Recall that the biggest reason for using ext3 is that it is supported best of all the filesystems. If all hell breaks loose, even Tomsrtbt [toms.net] (an ancient rescue floppy pre-dating knoppix) can fix it. Ext4 breaks this backwards-compatibility to ext2. Therefore, I see no reason to use it. One might as well use something more stable and proven, especially while we lack numbers suggesting it performs as well or better.

Re:Preempting the prefix war

Maybe a linguist can pitch in to explain why tebibyte sounds so awful?

Tebibyte-buh: It's bad-buh because-buh it makes-buh you sound-buh like Mushmouth-buh.

Hey hey hey!

Indulging the prefix war

Of course, in this case you have to balance the confusion stemming from the Tera in IT context meaning 1024 in some cases.

It's worse than that. According to SI prefixes, "Tera" should mean 10^12 (1,000,000,000,000), but in common usage applied to computers it sometimes means 2^40 (1,099,511,627,776). But it also sometimes means "1024 Giga", where the Giga could be using either convention (and, for all you know, the "Mega" implied within could have been computed using either convention). So you can get a gradient of "mixed numbers" that conform to neither standard. You might say that only a non-professional would make such a stupid mistake... but on the other hand, if you see a column of numbers listed in "Gigabytes" and you want to convert them to Terabytes, what conversion factor would you use? How would you know what conversion factor the previous author had used? How could you guarantee that you were doing it right? Would you be able to confidently convert it into an exact number of bytes?

Personally, I think the whole thing is a mess, and computer professionals should be working harder to enforce a consistent scheme. Unfortunately, only a minority of computer professionals seem interested in changing the status quo confusion.

Maybe a linguist can pitch in to explain why tebibyte sounds so awful?

I'm no linguist, but I don't think "Tebibyte" sounding silly is the real problem. I admit that I laughed when I first heard the binary prefixes. They sound lame. But who cares? "Quark" was silly when it was first coined. So was "Yahoo" and "Google" and "Linux" and "WYSIWYG" and "SCSI" and "Drupal" and so on... Silly names become second-nature once they are used enough.

I think the real problem is that people, inherently, are loathe to change. They are more apt to come up with rationalizations and justifications for doing things "the old way" rather than put in the work to learn (and code!) a new system. Sorry if this sounds harsh, but I find the people who say the binary prefixes "sound dumb" or say that "the current (inconsistent)* system works fine" are just coming up with excuses to avoid doing the work to use a properly consistent standard/notation.

Maybe you're right, and that if the new prefixes had sounded "cooler", then adoption would have been faster... but I'm not so sure. Even if true, it doesn't absolve any of us for allowing the confusion to persist: cool or not, we (geeks especially!) should have the discipline to use proper standards.

* The current system can be roughly described as: SI prefixes are powers of 10 everywhere except in computer science, when they become powers of 2. But only when referring to memory, and some data structure sizes, but not when referring to transmission rates or disk space (unless it's a flash drive, sometimes), and other kinds of data structures.

Re:But does it run...

From what I've read, Reiser4 completely kills Ext4 in performance... then it disposes of ext4's kernel module, removes one of its redundant drives, and then cleans the free space left on its array.

Re:But does it run...

But it is too verbose, and that ends up being a problem.

Re:But does it run...

Can you really say it kills it if you just can't find your files anymore? I mean, the files might be in Russia or something...

Re:Wait, what?

They're probably using a 64-bit number to hold the timestamp. That gives you 1.8e19 discreet time intervals, so you're going to get ridiculous precision, dates ridiculously far into the future, or both. I assume that they went for precision because that arguably has more potential for use in the real world than worrying about files thousands of years into the future.

IIRC, today's PCs have high-resolution timers available that surpass the old 14.318MHz clock chip. If you can't get accurate nanoseconds out of the timers yet, they'll just round the numbers off. No big deal.

BTW, NTFS uses 100ns timestamp granularity, and it was designed when systems were almost 100X slower than today. So it had a similar amount of overkill, but that certainly doesn't seem to have had any negative impact on the acceptance of NTFS.