EXT3 File-System Driver To Be Removed From The Linux Kernel

[AndyChow]

samsung and motorola use F2FS for their file system which is far faster. I'm sure google could maintain their own fork with ext3 if backwards compatibility doesn't work 100%.

I was speaking specifically of the "Android-x86" distribution, which allows installation on ext3, ext2, ntfs or fat32 partition types only with the provided installer. And there are other distributions.

It doesn't really seem like a big deal, actually, but why remove it? Ext3 is still safer than ext4 by default.

F2FS, BTRFS, etc, are fine and all, but still experimental. Heck, even ext4 had a major corruption bug a couple of months ago!

[Imroy]

Why not the ext2 driver too?

Because it's much smaller and simpler than ext3/4. It's very well tested and presumably well understood. For anyone needing only a simple fs without journalling, etc, it's preferred over the ext3/4 modules.

[oleid]

Some OS still use Ext3 by default, don't offer ext4. Android_x86 for example.

But they use ancient kernels. The code doesn't get removed from those. By the time Android uses kernel 4.3, it will support ext4, too. Or switch to btrfs or f2fs.

[duby229]

But they use ancient kernels. The code doesn't get removed from those. By the time Android uses kernel 4.3, it will support ext4, too. Or switch to btrfs or f2fs.

But then also the ext4 driver will still mount ext3 partitions. It's unlikely they'll have to change anything. If the installer creates an ext3 partition it'll still work just fine.

[droidhacker]

But they use ancient kernels. The code doesn't get removed from those. By the time Android uses kernel 4.3, it will support ext4, too. Or switch to btrfs or f2fs.

AOSP has been using EXT4 for a *VERY* long time. In fact, AOSP went straight from YAFFS2 --> EXT4.
As far as Android-x86 goes, that has always been a bit of a weird fork of AOSP. This change is nothing special though, that they can't deal with in about 5 minutes. That they are still using EXT3 is just a throwback from when AOSP was still using YAFFS2. That they haven't moved up to EXT4 is only because there has been no pressing need when there is so much other work to do on it.

[droidhacker]

samsung and motorola use F2FS for their file system which is far faster. I'm sure google could maintain their own fork with ext3 if backwards compatibility doesn't work 100%.

Huh? Every samsuck and motorola I've ever owned used EXT4.

Far faster... huh, that is hilarious. The only thing I can see that suggests that it is "far" faster, is this benchmark;

http://forum.xda-developers.com/showthread.php?t=2697069

... specifically, the "androbench random write", which is actually a TOTALLY BOGUS result. I mean look at it... 300 MB/s? Mega BYTES per second.... on WRITE? I mean, we are talking about DESKTOP SATA SSD performance levels here. ***READ*** only at 50? Which... BTW... was blown away by EXT4, hitting 66. The hardware the tests were run on is simply not capable of those kinds of write speeds, which means that something very funky is going on.


Here is what f2fs actually is..... SAMSUCK was peddling devices with very poor quality eMMC's (flash chips), there was a very high rate of storage failures on this specific device (I forget what the device actually was...). They tried to blame it on AOSP's use of EXT4, and to support this claim, they started writing f2fs. Basically, they thought that writing a new filesystem would add credibility to their claim. But now they are stuck with it, and yeah, they have tricked a few people into using that junk.

Personally, having struggled through a linux kernel polluted with samsuck drivers and hacks for far too many hours, they are DEFINITELY NOT the outfit you choose when it comes to developing reliable and readable code. Far from it in fact, anything written by them should be avoided like the plague.

[whaevr]

Huh? Every samsuck and motorola I've ever owned used EXT4.

Far faster... huh, that is hilarious. The only thing I can see that suggests that it is "far" faster, is this benchmark;
http://forum.xda-developers.com/show....php?t=2697069
... specifically, the "androbench random write", which is actually a TOTALLY BOGUS result. I mean look at it... 300 MB/s? Mega BYTES per second.... on WRITE? I mean, we are talking about DESKTOP SATA SSD performance levels here. ***READ*** only at 50? Which... BTW... was blown away by EXT4, hitting 66. The hardware the tests were run on is simply not capable of those kinds of write speeds, which means that something very funky is going on.


Here is what f2fs actually is..... SAMSUCK was peddling devices with very poor quality eMMC's (flash chips), there was a very high rate of storage failures on this specific device (I forget what the device actually was...). They tried to blame it on AOSP's use of EXT4, and to support this claim, they started writing f2fs. Basically, they thought that writing a new filesystem would add credibility to their claim. But now they are stuck with it, and yeah, they have tricked a few people into using that junk.

Personally, having struggled through a linux kernel polluted with samsuck drivers and hacks for far too many hours, they are DEFINITELY NOT the outfit you choose when it comes to developing reliable and readable code. Far from it in fact, anything written by them should be avoided like the plague.

Ah yes. Im sure you've done your research and there is no bias present in this opinion at all

That link you're tearing apart notes the crazy speeds, right above the picture in the text

On this one, the results were so incredibly appart that I think we can safely assume a big part of these results are due to poor coding on the benchmark side.

But pointing that out probably wouldn't fit into the SAMSUCK narrative you have going, would it?

[gamerk2]

If you want an example of Windows not being backwards compatible, go play Knights of the Old Republic. Its 12 years old but it was already broken in Windows 7. Or Star Wars Racer, another game I know of that just does not run on modern Windows computers with tons of work, while it runs just fine in Wine.

SW:KotOR is one of the few examples of games that ran into issues moving past XP, though with a few config changes, still runs fine on Windows 8.1 x64. The only games I know of that simply don't work at all are, ironically, both MSFT products: Crimson Skies (broken HW GPU renderer), and Halo 2 Vista (which is broke on 7, which is like Vista SP 2 for crying out loud!).

XP video drivers more or less don't work on Vista and later.

New driver layer, to get rid of the problem where the GPU driver kept bringing down Windows (which is a thing of the past these days). All that was needed was a new HW driver from the OEM, which they did across their product lines. That's why you see many older cards having up to four drivers (XP and XP64, Vista/7 and Vista/7 64). When MSFT changes something on their end, typically it affects the driver layer, and not the user space applications.

[lkundrak]

Why not the ext2 driver too?

Because there's none. Ext2 is handled by the Ext4 driver.

[droidhacker]

Ah yes. Im sure you've done your research and there is no bias present in this opinion at all

That link you're tearing apart notes the crazy speeds, right above the picture in the text


But pointing that out probably wouldn't fit into the SAMSUCK narrative you have going, would it?

Fits it quite perfectly.