File-System Benchmarks On The Intel X25-E SSD

[energyman]

that still doesn't answer which options were used to mount the fs. ext3 cheats (speed is more important than data safety) and IMHO after the 'lost kde/gnome/everything in /etc' desaster nobody should use ext4. Ever.

There are fs that care about your data (reiserfs, reiser4, ext3 with the right mount options) and fs that don't (ext4).

[GreatWalrus]

that still doesn't answer which options were used to mount the fs.

Well, they most likely used the defaults here. Isn't that what matters, the defaults, which the system sets up for the user? Phoronix wasn't trying to find which options would create different effects on file system performance. As far as I know, they were taking the defaults and testing those. The performance with the default settings is most likely what the average person is looking for with such a wide array of file system benchmarks.

[energyman]

yeah, you see - that is the problem - ext3 was tuned to look good in benchmarks with 'the defaults'. But 'the defaults' are shit.

[marakaid]

that still doesn't answer which options were used to mount the fs. ext3 cheats (speed is more important than data safety) and IMHO after the 'lost kde/gnome/everything in /etc' desaster nobody should use ext4. Ever.

There are fs that care about your data (reiserfs, reiser4, ext3 with the right mount options) and fs that don't (ext4).

What are the right options for ext3 and the others?

[mutlu_inek]

Regarding Reiser4: There are patchsets for all recent kernels available on kernel.org: http://www.kernel.org/pub/linux/kern...dward/reiser4/

It would be great if it was included in these tests.

[Michael]

that still doesn't answer which options were used to mount the fs. ext3 cheats (speed is more important than data safety) and IMHO after the 'lost kde/gnome/everything in /etc' desaster nobody should use ext4. Ever.

There are fs that care about your data (reiserfs, reiser4, ext3 with the right mount options) and fs that don't (ext4).

Everything was left at their Ubuntu defaults.

[energyman]

as I am afraid. Yeah, then you can add 30% to the times of ext3 (if there devs is to believe).

try barrier=1 for ext3. For xfs and reiserfs the option is not needed. jfs does not support barriers.

[kernelOfTruth]

noatime,nodiratime (or only noatime) should be the bare minimum and should speed things noticably up

unfortunately delete performance of reiser4 sucks somewhat but that's the price to pay for a filesystem that is the best in all the other areas

[paul_one]

ANOTHER test with encryption/compression?

You even mention in the testing that it's CPU-bound, and not drive-bound... So why do them?

There's no details on how the different filesystems were created - which someone else has mentioned so far.
Due to the wear-levelling I'd have thought it would be sensible to totally blank the drives after each test to get true comparitive results (this is basically a hardware format of the drive - not simply an fdisk operation).

Personally, I'd have preferred different systems set up - but that would require 5 (or so) X-25's and Intel laptop's. Obviously silly (but also the only way to get TRUE comparisons).

Maybe run the first Filesystem, wipe, do each test and then re-test the first filesystem (to see if any impact has been done).

Again, no true read/write timing was performed (only **simulated** DATA reading/writing).
Again, only single read/write actions at the same time.

.. I'm starting to loose faith..

[chithanh]

The MySQL performance blog has also done performance testing on the X25-E.

They came to the conclusion that write cache enabled and write barriers disabled leads to lost transactions (unsurprisingly).

With write barriers enabled the performance turned out to be very poor.