EXT4 Data Corruption Bug Hits Stable Linux Kernels

This will really knock any complacency out of backporting changes to the stable kernels.

This sort of bug is is never good, let alone great.

Most of the enterprise distros only backport bugfixes, patches and sometimes new hardware support. Of course, SUSE Linux Enterprise releases a newer kernel version instead, often breaking compatability with proprietary apps.

I didn't say the bug was great, or even good.

The announcement is great. That it is known, and being fixed, "transparency" is great.

Great, compared to secrecy.

OK, we agree about transparency.

I'm still using ext3. Let's here it for Luddites!!!

I used to use and like ReiserFS... but now, probably irrationally I just can't get past that homicide thing.

Ext3 for the win!

Or ext4 sans journal (great for SSD).

ext4 sans journal? I didn't even know you could do that.

I mean, ext3 without the journal is just ext2. :^)

Ext4 w/o the journal still uses extents, rather than block bitmaps. That alone is a feature in my book.

To remove the journal from an ext4, first, unmount the filesystem in question, then type:

e2fsck to replay the journal if need be, and tune2fs to remove it. Note, the e2fsck has a zero in the command, while tune2fs has a capital O ("oh").

If you have any journal-related options for the filesystem in /etc/fstab, you should remove them. (They shouldn't be there anyway; they can all be stored within the filesystem itself via tune2fs.)

@gus3: From what I've read recent SSDs have life expectancies longer than conventional hard drives. If that's true what advantage is there to running without a journal?

Also, turn off atime and (forgot the other one) in /etc/fstab entry for that device, to prevent the endless re-writing of that one area on every file accessed.

@caitlyn, SSD lifetime still takes a hit with the extra journal I/O.

@gus: How much of a hit out of how long a lifespan? How does that compare to a very long fsck on an unjournaled filesystem? I'm not at all convinced that the perceived savings of not journaling warrants the cost.

I do run ext4, with journaling, with access time recording, on SSD devices.

> I do run ext4, with journaling, with access time recording, on SSD devices.

Exactly the voice of experience this discussion needs.

I had a big, long reply typed up, but I need to erase it to ask a simple question:

@caitlyn, what is the storage type in your SSD?

Quoting:@caitlyn, what is the storage type in your SSD?

Which one? I have everything from an SSD used in lieu of a hard drive in my HP Mini 110 netbook, now over three years old. I have USB sticks ranging from 4GB-32GB in size, with the smallest/oldest one in regular use since 2005.

I realized that where you were saying "SSD", I was understanding "flash". They do not necessarily coincide, so...

Just change everything I said about "SSD" to "flash" instead.

My bad, and my apologies to everyone confused. And my apologies to caitlyn, who is clearly not confused.

P.S. Sorry for the long delays in conversation. No 'net at home, and didn't get online yesterday.

I think we'd all like some extreme clarity on how exactly to run an SSD.

I've heard from the DragonFlyBSD people that you just run it like a normal drive.

I wouldn't be comfortable running ext3 or ext4 without a journal.

What I would be comfortable with is knowing the drive had a five-year life expectancy and running it as if I would replace it by then.

If an SSD can take five years' service while running without extreme tweaking, that is good enough for me. If the length of service goes down to four or three years, that would be fine, too.

I expect that many Linux installers detect SSDs and take that into account when setting up filesystems and writing /etc/fstab.