Announcement

Collapse
No announcement yet.

Large HDD/SSD Linux 2.6.38 File-System Comparison

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • jakubo
    replied
    ntfs might have been a nice part. i think many ppl use it on mass storages for usability with windoze

    Leave a comment:


  • TrevorPH
    replied
    Originally posted by locovaca View Post
    Sounds like a bug report is in order for them? Btrfs has no problem adapting to a SSD by default.
    I don't have the ability to mkfs a btrfs filesystem unless I go in search of the utilities and compile them myself but I did have a quick read of the btrfs source from 2.6.37 and there are several options there relating to SSDs. There's ssd, ssd_spread, nossd and discard. These all seem to be set independently and the info in Documentation/filesystems/btrfs.txt says that discard is not default. Running `mount` would get it to tell you what options were actually in effect though and I would expect it to say both ssd and discard if both were in effect - ssd does not seem to imply or set discard. I also looked at Documentation/filesystems/nilfs.txt and that also says that nodiscard is default.

    Leave a comment:


  • drag
    replied
    Originally posted by cruiseoveride View Post
    Where are the overall performance charts?

    Hopefully never going to happen. Micheal should have better sense then that.

    Such things would be so blindingly worthless and counterproductive that it would counter any sort of positive benefit PTS file system benchmarks can offer.

    Leave a comment:


  • Xanikseo
    replied
    I also find it hard to work out which is the best solution. I think it would be best to order results with best performance at the top. The current disorder is infinitely harder to analyse.

    Leave a comment:


  • cruiseoveride
    replied
    Where are the overall performance charts? I've been asking for these sort of charts since pts was in beta. These sort of articles are useful for individual metrics but are useless for the average reader who is just trying to choose the best overall.

    If you take the time to tabulate and average out relative performance, you will see that NILFS2 was the best overall for a HDD, but reading this article won't tell you that. Is this so much to ask from pts?

    Leave a comment:


  • energyman
    replied
    Originally posted by curaga View Post
    Thanks for finally including JFS. It's surprisingly fast on a SSD.
    does jfs support barriers? are they turned on?
    if not, you can disregard the results.

    Leave a comment:


  • locovaca
    replied
    Originally posted by TrevorPH View Post
    On CentOS and according to the ext4 doc, the mount option 'discard' is off by default and should probably be turned on for SSD testing to take advantage of TRIM support.
    Sounds like a bug report is in order for them? Btrfs has no problem adapting to a SSD by default.

    Leave a comment:


  • TrevorPH
    replied
    On CentOS and according to the ext4 doc, the mount option 'discard' is off by default and should probably be turned on for SSD testing to take advantage of TRIM support.

    Leave a comment:


  • curaga
    replied
    Thanks for finally including JFS. It's surprisingly fast on a SSD.

    Leave a comment:


  • energyman
    replied
    ext3 always was, always will be, optizimed for benchmarks with default settings.

    These default settings are completely idiotic. They risk the data of the user. But that does not count. For ext3 devs it is more important to have good numbers when somebody does a standard test without leveling the field via mount options.

    Now, turn on barriers for everybody and see ext3 die a slow death.

    Leave a comment:

Working...
X