Announcement

Collapse
No announcement yet.

Btrfs File-System Mount Option Testing From Linux 3.14

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

  • Btrfs File-System Mount Option Testing From Linux 3.14

    Phoronix: Btrfs File-System Mount Option Testing From Linux 3.14

    Following our recent HDD benchmarking and solid-state drive testing of the Linux 3.14 kernel with various file-systems, for this weekend article we have done more tests of Btrfs on Linux 3.14 when trying out various Btrfs mount options.

    http://www.phoronix.com/vr.php?view=19940

  • #2
    Off-topic, but: @Michael: why are your recent photo shots so yellow?

    Comment


    • #3
      Wrt last test, nodatacow is pretty much eat-my-data. It turns off checksumming so Btrfs won't detect if your data gets corrupted and can lead to in time catastrophic results since there's no possibility of having on-boot fsck detect corruption either.

      Comment


      • #4
        Originally posted by nanonyme View Post
        Wrt last test, nodatacow is pretty much eat-my-data. It turns off checksumming so Btrfs won't detect if your data gets corrupted and can lead to in time catastrophic results since there's no possibility of having on-boot fsck detect corruption either.
        True, but nodatacow can be turned on/off per filesystem, subvolume, and even i think per file so its only REALLY an issue here where its off for the whole filesystem

        Comment


        • #5
          Originally posted by mudig View Post
          Off-topic, but: @Michael: why are your recent photo shots so yellow?
          Generally when I am after taking a quick photo at night with lights on in my office and for just a quick photo will use iPhone 5S over pulling out a proper DSLR camera.
          Michael Larabel
          http://www.michaellarabel.com/

          Comment


          • #6
            Sooo... space_cache is one of the default mount options.

            Comment


            • #7
              Originally posted by nanonyme View Post
              Wrt last test, nodatacow is pretty much eat-my-data. It turns off checksumming so Btrfs won't detect if your data gets corrupted and can lead to in time catastrophic results since there's no possibility of having on-boot fsck detect corruption either.
              On platters, yeah, but on ssds I don't think it would matter since the controller decides where to put the data. That is, I'm not sure it differentiates between cow and nodatacow.
              I'd be curious about how combinations of options benchmark. So, say, space cache, lzo, discard(this should only run during downtime so shouldn't affect benchmarks), ssd spread and noatime(although modification times should still register).

              Comment


              • #8
                In 2 years time, no one will hear anything about ZFS.

                Comment


                • #9
                  Would BTRFS be good for USB flash drives and SD cards? What kind of CPU overhead is expected with LZO and ZLIB compression especially on a Silvermont Atom based PCs or even on older Atoms like the ones in old Compulab devices?

                  Comment


                  • #10
                    Seconded

                    Originally posted by liam View Post
                    On platters, yeah, but on ssds I don't think it would matter since the controller decides where to put the data. That is, I'm not sure it differentiates between cow and nodatacow.
                    I'd be curious about how combinations of options benchmark. So, say, space cache, lzo, discard(this should only run during downtime so shouldn't affect benchmarks), ssd spread and noatime(although modification times should still register).
                    I also want to know the best combo. Please think like an admin when testing:
                    1. Take corruption switches out of consideration
                    2. Find the best combination.

                    Comment


                    • #11
                      Does anyone know something about the state of lz4 transparent (de)compression in btrfs? I think with it's higher (de)compression speed lz4 should perform even better than lzo/zlib for transparent (de)compression in btrfs.

                      Comment


                      • #12
                        I have more Btrfs compression and general filesystem questions for the experts out there.

                        First for non-compressed filesystems. When an existing file is modified (something in the middle is changed or some data is prepended or appended like log files), is the entire file rewritten to disk or are the changes detected and only those parts are written to disk? It seems at least appending to a file won't cause the existing data to be rewritten.

                        For compressed files, how does this work? When reading the file it is decompressed and nothing is changed on the disk. When a file is modified, will the entire file be recompressed or only the modified parts? For example, when appending to a log file, will the entire file be recompressed or does Btrfs use independent compressed blocks and just appends the new blocks to the log file? If so, then if a file is changed "enough" will Btrfs try to recompress the entire file?

                        Thanks!

                        Comment


                        • #13
                          skinny metadata and larger leaf/node sizes

                          It would be interesting if we can see some differences between defaults vs 16k leaf size vs skinny metadata. Though I think 16k was already moved to default.

                          Comment


                          • #14
                            Originally posted by guido12 View Post
                            First for non-compressed filesystems. When an existing file is modified (something in the middle is changed or some data is prepended or appended like log files), is the entire file rewritten to disk or are the changes detected and only those parts are written to disk? It seems at least appending to a file won't cause the existing data to be rewritten.
                            It depends how the program is written. Most programs cause full overwrites. I'd be very surprised if btrfs (or any other fs for the matter) expended the cpu cycles to detect changes - think 30GB video files and the lag it would cause.

                            Comment


                            • #15
                              Originally posted by liam View Post
                              On platters, yeah, but on ssds I don't think it would matter since the controller decides where to put the data. That is, I'm not sure it differentiates between cow and nodatacow.
                              The data may end up in a new block on a SSD, but the logical address of that data would be in the same place the old data was. So your filesystem would have no way of knowing it was a copy and no way of getting back the old data.

                              Comment

                              Working...
                              X