Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 22

Thread: Testing EXT4 & Btrfs On A Serial ATA 3.0 SSD

  1. #11
    Join Date
    Sep 2011
    Posts
    71

    Question

    Quote Originally Posted by liam View Post
    You're assuming performance is the raison d'etre for btrfs, but the big gain would be in the snapshotting. You would no longer have unrecoverable systems due updates. You would be able to safely update your system from release to release without doing a reinstall (this doesn't mean the update would work but it would mean that it would be safe). These are ease of use features that would be fantastic to have and that's ignoring the data assurances it provides.
    Don't we already have snapshots courtesy of LVM? OpenSUSE plans to introduce a tool called snapper with their next release that does everything you want it to (including snapshot before installs, updates and timed snapshots and the ability to recover even a single file) with Btrfs, but a Google Summer of Code project is supposed to "Add ext4 snapshots support to snapper". If the project was successful, it might be offering everything you're looking for.

  2. #12
    Join Date
    Nov 2010
    Posts
    103

    Default

    Quote Originally Posted by Ruud Koot View Post
    As space_cache and (ironically) nossd almost always seem to improve performance, it would be nice to know how btrfs performs with a combination of mount options. E.g., would btrfs + space_cache + nossd + compress=lzo get closer in performance to ext4 for the SQLite benchmark?
    It could be that the BtrFS SSD optimizations are used to increase lifespan of the SSD rather than to increase performance. So it could be worthwhile to keep SSD enabled.

  3. #13
    Join Date
    Sep 2011
    Posts
    1

    Default

    Quote Originally Posted by Cova View Post
    The Vertex 3 is a sandforce-based drive is it not? If so, the enabling filesystem-level compression will prevent the sandforce controller from doing any compression which will have a large effect on the benchmark results. While still a fair test as it is a combination a user could end up with, I would also like to see results from a non-sandforce drive.
    If the drive was indeed using internal compression then the results would be really interesting. In that case, some of the gains appearing when the btrfs compression is enabled suggest that the internal drive compression is really bad and doing the compression in software rather than in hardware is much better solution.

  4. #14
    Join Date
    Aug 2009
    Location
    south east
    Posts
    342

    Default Give and Gain

    Copying files shouldn't introduce latency in your desktop experience. Moving files should be throttled.

  5. #15
    Join Date
    Nov 2010
    Posts
    103

    Default

    So apparently, there's another cache that can be enabled at mount time. It's the inode_cache.

    It'll be nice to see the performance of the options missing from this benchmark (autodefrag, inode_cache)

  6. #16
    Join Date
    Jan 2010
    Posts
    3

    Default What about ZFS?

    The comparison was very informative and useful, Michael.

    However, an argument could be made that BTRFS lags behind EXT4 for the simple reason that the checksumming and healing power it offers is simply costing something. I think it would help the comparison a lot if Debian/kFreeBSD (or native FreeBSD) was installed in the same machine, and the benchmarks were run under ZFS, too.

    That way, BTRFS would be compared to ZFS, which has similar features: checksums, snapshots, etc.

    Just my 2c.

  7. #17
    Join Date
    Apr 2010
    Posts
    271

    Default

    Quote Originally Posted by liam View Post
    You're assuming performance is the raison d'etre for btrfs, but the big gain would be in the snapshotting. You would no longer have unrecoverable systems due updates. You would be able to safely update your system from release to release without doing a reinstall (this doesn't mean the update would work but it would mean that it would be safe). These are ease of use features that would be fantastic to have and that's ignoring the data assurances it provides.
    No, I do not assume performance is the reason for btrfs, but the lack of performance will be its downfall. *I* don't care how magical the snapshot abilities are, I will not knowingly allow my performance to be sacrificed like that. Then again, I don't run beta distributions and do not have updates fail.

  8. #18
    Join Date
    Feb 2010
    Location
    Sweden
    Posts
    58

    Default

    Copying files shouldn't introduce latency in your desktop experience.
    It shouldn't but it has plagued the Linux desktop for years (not that Windows fares much better though) even though it has been highly improved over the years, or I have simply bought better hw over the years

    However I don't really think that we will find 100% of the problem in the kernel since I have never seen a server drop latency do to heavy I/O so perhaps our window managers access the disk more than they should and that is why is the cause of these latencies when there is high I/O. Or the I/O system gets completely clogged up so there can be no I/O over for keyboard and mouse (they are I/O operations as well).

    And this not that far fetched since we all remember the Firefox + ext3 fsync fiasco. Who would think before that that Firefox would have latencies due to disk activity...

  9. #19
    Join Date
    May 2010
    Location
    Australian Capital Territory
    Posts
    14

    Default EXT4, BTRFS, NTFS-3G & NTFS-W7 ... please.

    The supposedly superior EXT4 does not have encryption nor compression. NTFS-3G is not the same as NTFS-W7, but BTRFS is, with compression, file-permissions, multiple-dates, & encryption.

    Personally all my data & archive files are NTFS-W7 (which differs from previous versions of NTFS). Linux, which I use for most functions, most times, uses EXT4 partitions, but creates many incompatibilities with NTFS-W7: non-MS file names, multiple same-name files & seemingly rare & random write errors onto compressed NTFS-W7 partitions.

  10. #20
    Join Date
    Jan 2009
    Posts
    1,435

    Default

    Quote Originally Posted by gregzeng View Post
    The supposedly superior EXT4 does not have encryption nor compression. NTFS-3G is not the same as NTFS-W7, but BTRFS is, with compression, file-permissions, multiple-dates, & encryption.

    Personally all my data & archive files are NTFS-W7 (which differs from previous versions of NTFS). Linux, which I use for most functions, most times, uses EXT4 partitions, but creates many incompatibilities with NTFS-W7: non-MS file names, multiple same-name files & seemingly rare & random write errors onto compressed NTFS-W7 partitions.
    Most of ext4's improvements were to make scaling better and improve performance while not changing TOO much code. The point was to be an incremental upgrade not breaking the bank to build fort knox (or whatever appropriate metaphor you like).
    Compression, presumably, would've forced more changes than T'so liked, and encryption is handled by a lower level system (in the nix tradition of "small" programs doing "small" tasks) that any fs (saving btrfs, at least) can take advantage of.

Posting Permissions

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