Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 41

Thread: Linux 3.3 Kernel: Btrfs vs. EXT4

  1. #11
    Join Date
    Jan 2009
    Posts
    1,309

    Default

    Quote Originally Posted by fackamato View Post
    .. which is not visible to the filesystem, so compression still matters a lot.
    It's not visible to the file system, but if you have a SF controller you shouldn't run filesystem level compression b/c it's superfluous. At best you may save a bit of space, but it will, in all cases, slow down your ops.
    What is it I'm missing?

  2. #12
    Join Date
    Jan 2012
    Posts
    9

    Default

    Any upcoming benchmark with transparent FS compression on Phoronix ?

  3. #13
    Join Date
    Jan 2009
    Posts
    462

    Default

    Any upcoming benchmark with transparent FS compression on Phoronix ?
    I'm sure that the data already exists to a usable degree. Does anyone know how to sort/filter OB to show btrfs results with compression?

    http://openbenchmarking.org/s/btrfs

    It would be nice to compare http://openbenchmarking.org/result/1...AR-BTRFSLZ4124 with http://openbenchmarking.org/result/1...BY-LINUX33BT16 and others in a single window and not have to switch between tabs.


    F
    Last edited by russofris; 03-03-2012 at 11:04 AM.

  4. #14
    Join Date
    Sep 2006
    Posts
    714

    Default

    Quote Originally Posted by mayankleoboy1 View Post
    I am disappointed by the stock performance of BTRFS. It has been said to be the next standard linux file system and it cant compete with ext4.
    Is transparent compression the only saving grace of BTRFS?
    I don't see why you should be. At least not from these benchmarks. These benchmarks are artificial and only show very specific aspects of the file system... most of which is almost entirely irrelevant to most people's use cases. They really likely have very little bearing on what it is going to be like to run them in your desktop or a production system.

    The principal advantage that Ext4 is going to have is that some of it's code is decades old and has hundred's of man-hours poured into it's development. It is very mature and there is very little that is going to surprise you with it and best practices are well established and widely known.

    Btrfs on the other hand is going to require years of in-field usage and wide scale deployment before it can compete with Ext4 with that. But what Btrfs offers is significantly enhanced ability to manage data and from a administrative standpoint this is going to be invaluable once people learn to take advantage of it.

    .. which is not visible to the filesystem, so compression still matters a lot.
    Maybe, maybe not.

    Most data people care about performance nowadays is already heavily compressed. If you care about, say, your ability to use Linux to manage multimedia files then compression is utterly irrelevant on the file system level and on the controller level. They use format-specific compression techniques and the chances of file system compression helping out is _NONE_AT_ALL_.

    Now if you are dealing with thousands of plain text files ranging in size from 2MB to multiple GBs then compression is something that is probably going to matter a lot to you. That is, of course, you are not already using gzip or whatever to compress your data.

  5. #15

    Default

    Quote Originally Posted by fackamato View Post
    .. which is not visible to the filesystem, so compression still matters a lot.
    The Sandforces compress all data they write, and reaching their advertised performance/endurance depends on the data written to them to be compressible. If you compress your data before that, you interfere with the controller doing its job properly, and waste the cpu cycles needed for filesystem compression.

  6. #16
    Join Date
    May 2008
    Posts
    43

    Default

    Quote Originally Posted by liam View Post
    It's not visible to the file system, but if you have a SF controller you shouldn't run filesystem level compression b/c it's superfluous. At best you may save a bit of space, but it will, in all cases, slow down your ops.
    What is it I'm missing?
    Since SSDs are tiny, I don't mind having compression enabled sometimes saving ~50% of space on a filesystem, with non-noticeable performance impact.

  7. #17

    Default

    Quote Originally Posted by fackamato View Post
    Since SSDs are tiny, I don't mind having compression enabled sometimes saving ~50% of space on a filesystem, with non-noticeable performance impact.
    Except that on a Sandforce SSD, when it does save noticeable amounts of space, it will have a noticeable performance impact.

  8. #18
    Join Date
    May 2008
    Posts
    43

    Default

    Quote Originally Posted by AnonymousCoward View Post
    Except that on a Sandforce SSD, when it does save noticeable amounts of space, it will have a noticeable performance impact.
    Why won't it save space? I'm not saying you're wrong, I just don't understand it. Example:

    100GB SF SSD, 1 single btrfs partition. So let's say ~95GB or so available to the user. If the user writes 95GB of iso files with no compression, the performance while writing will be good and he'll use the entire filesystem.
    If he choses to mount the filesystem with some compression option (lzo or something as fast) then the write performance will suffer a bit (at ~ 500MB/s, who cares? It's a tradeoff I guess.), but the user will still have some free space on the file system, depending on how good lzo is at compressing these ISO images. Therefore, the user can store more data than the SSD is physically capable of.

  9. #19
    Join Date
    Jul 2008
    Posts
    1,720

    Default

    http://marc.info/?l=linux-ext4&m=133052231227201&w=2

    oh look, btrfs a lot faster than ext4 in a real world example.

  10. #20
    Join Date
    Jul 2008
    Posts
    1,720

    Default

    Quote Originally Posted by fackamato View Post
    Since SSDs are tiny, I don't mind having compression enabled sometimes saving ~50% of space on a filesystem, with non-noticeable performance impact.
    with an SF controller who does compression you do not gain any space - but you are wearing the SSD down if you compress the data. Because the controller will not be able to compress it further, defeating one of the wear leveling mechanism.

Posting Permissions

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