Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 32

Thread: File-System Benchmarks On The Intel X25-E SSD

  1. #21
    Join Date
    Jul 2008
    Posts
    1,718

    Default

    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).

  2. #22
    Join Date
    Jan 2009
    Posts
    67

    Default

    Quote Originally Posted by energyman View Post
    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.

  3. #23
    Join Date
    Jul 2008
    Posts
    1,718

    Default

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

  4. #24
    Join Date
    Dec 2007
    Posts
    107

    Question

    Quote Originally Posted by energyman View Post
    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?

  5. #25
    Join Date
    Dec 2008
    Posts
    17

    Default

    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.

  6. #26

    Default

    Quote Originally Posted by energyman View Post
    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.

  7. #27
    Join Date
    Jul 2008
    Posts
    1,718

    Default

    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.

  8. #28
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    622

    Default

    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

  9. #29
    Join Date
    Feb 2009
    Posts
    10

    Default

    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..

  10. #30
    Join Date
    Jul 2008
    Location
    Berlin, Germany
    Posts
    821

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •