EXT3 Driver Might Not End Up Getting Removed From Linux 4.3

[duby229]

People, please stop and read what is actually going on. Nobody is talking about dropping support for ext2/ext3. They are talking about dropping the separate driver because the ext4 driver supports those previous filesystems, making the separate drivers redundant. This would have very little affect on anyone.

Ext2 filesystems perform better with the ext2 driver than they do with the ext4 driver. I'd hate to see it go. It doesn't make sense to enforce a totally needless performance loss.

[geearf]

How big is that performance difference?

[Scimmia]

Ext2 is a bit of a red herring here, as nobody is proposing it be removed, but I'm also curious what the performance difference is.

[duby229]

I've seen it about as high as 5% on flash drives. But in my experience it's mostly a subjective responsiveness. The difference is more noticeable than benchmarks suggest.

[geearf]

I don't think 5% should be worth it, but it you can "feel" it, it'd be way more than 5%...
Though the option of fixing ext4 for that speed regression is also valid (if easily feasible).
But if you've done the test recently, are you sure the OS did not use ext4 when it said it was using ext2? (based on my previous quote).
If not, well in this case Scimmia's comment applies.

[duby229]

Of course I agree with you. I haven't put much thought into it until this thread because in my daily usage it rarely comes up.

[mup4]

People, please stop and read what is actually going on. Nobody is talking about dropping support for ext2/ext3. They are talking about dropping the separate driver because the ext4 driver supports those previous filesystems, making the separate drivers redundant. This would have very little affect on anyone.

As per Linus' statement ext2/ext3 support via the ext4 driver cannot be considered the same as native ext2/ext3 support. That is what Linus (and I) mean by ext2/ext3 support.

[Zan Lynx]

I've seen it about as high as 5% on flash drives. But in my experience it's mostly a subjective responsiveness. The difference is more noticeable than benchmarks suggest.

I wonder if it is something like enforcing write barriers. As I understand it the ext4 driver properly defaults to barrier=1.

Which means the drive is forced to write everything before the barrier before receiving more data. This is because many drives, given the command to write blocks 1-7 will happily write blocks 5 and 6, read a few other unrelated blocks and then write blocks 1-4 and then block 7 depending on head position, free SSD erase blocks or whatever. But if the kernel sends a barrier it wants to be sure blocks 1-4 are down first. So yeah that can slow things down and I believe it can block reads for a tiny bit of time while the drive commits writes to disk. But using barrier correctly is the difference between a disk that actually has your data on it and one that doesn't.

[geearf]

As per Linus' statement ext2/ext3 support via the ext4 driver cannot be considered the same as native ext2/ext3 support. That is what Linus (and I) mean by ext2/ext3 support.

Even if most distributions currently use the ext4 driver for the 2 others?
In that case I fail to see how removing the other 2 drivers is anything different than current anyway..

And also forgetting Tso's replying saying that he does test ext3 status against the ext4 drivers every time before sending a pull request to Linux.

[duby229]

I wonder if it is something like enforcing write barriers. As I understand it the ext4 driver properly defaults to barrier=1.

Which means the drive is forced to write everything before the barrier before receiving more data. This is because many drives, given the command to write blocks 1-7 will happily write blocks 5 and 6, read a few other unrelated blocks and then write blocks 1-4 and then block 7 depending on head position, free SSD erase blocks or whatever. But if the kernel sends a barrier it wants to be sure blocks 1-4 are down first. So yeah that can slow things down and I believe it can block reads for a tiny bit of time while the drive commits writes to disk. But using barrier correctly is the difference between a disk that actually has your data on it and one that doesn't.

I had always attributed it to being lighter code in the driver. You have a more knowledgeable understanding of how it works. Indeed it may be a scenario worth considering for benchmark runs.