Announcement

Collapse
No announcement yet.

Btrfs Brings "Pretty Beefy" Changes In Linux 3.2

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

  • #11
    Originally posted by sbergman27 View Post
    Note that Hans has moved again. Send your bug reports to:

    Pleasant Valley State Prison
    24863 West Jayne Avenue
    Coalinga, CA 93210

    Update: Oops. All mail sent to the physical address of the prison will be returned to sender. Send bug reports to:

    P.O. Box 8500
    Coalinga, CA 93210

    Fortunately, that stuff is open source, so... theses things are still supported. I don't know for ReiserFS but Reiser4 is still (No new features for now, just bug fix).

    I'm personally working on a resizer for Reiser4 and when it will work, I will sent the patch to Edward for inclusion in the reiser4progs.

    And for BTRFS, I just found cute overhead problem.. Apparently, 8.8GO don't fit in a 10GO ReiserFS don't have any overhead and is faster than all ext* for reading, did not test the write.

    reading result
    [FS] => [space after format] => [space left on device after EVE is copied in] => [reading speed]
    ext2 => 23M => 614M => 0m58.511s [154MB/s]
    ext3 => 151M => 486M => 1m4.450s [139MB/s]
    ext4 => 151M => 497M => 1m8.066s [132MB/s]
    reiserfs => 33M => 1.3G => 1m2.216s [144MB/s]
    reiser4 => 460K => 812M => 1m1.064s [147MB/s]
    reiser4-gzip1 => 460K => 3.1G => 1m50.749s [81MB/s]
    btrfs => 56K => No space left on device : abort
    zram :
    tmpfs => NIL => 1.3G => 0m02.796s [3.3GB/s]
    Last edited by RavFX; 10 November 2011, 05:31 PM.

    Comment


    • #12
      Originally posted by RavFX View Post
      Fortunately, that stuff is open source, so...
      Reiser4 is pretty much dead. Even Edward Shishkin classifies Reiser4 as "low priority". Open Source projects die all the time. I have a very long list of unequivocably dead OS projects I could post.

      And for BTRFS, I just found cute overhead problem...
      So? I can still make Reiser4 stall for 90+ seconds under certain (non-contrived) work loads.

      reading result
      More comprehensive benchmark results generally show EXT4 as being the best performing Linux file system. And anecdotal (i.e. useless) claims aside is, along with EXT3, the most reliable. However, these days, you do need to mount EXT3 with "data=ordered", and EXT4 with "nodelalloc" to enjoy the full extent of their robustness. (Ted T'So has lost his grip on reality.)

      Every time I do a filesystem survey, I always kinda want to move to something "exciting". But the "boring" EXT4 always comes out on top, by all my objective measures.

      Comment


      • #13
        Originally posted by RavFX View Post
        And now they said thing as they will keep the FSCK for Oracle Linux only.
        Waht!? Is that really true?

        Anyways, I ran / and /home on top of Btrfs on top of dm-crypt on a laptop with plenty of unrelated crashes for over a year and didn't *notice* a single corruption to my system or data. Is it the consensus in this thread that it is really that unstable? The reason I moved away was that I was very unhappy with Firefox's sqlite performance.

        Comment


        • #14
          Originally posted by korpenkraxar View Post
          Waht!? Is that really true?
          No. RavFX is talking out of his ass.

          Comment


          • #15
            About data safety:
            I used ext4 on a dm-crypt on raid and it ate my data (silently, randomly) during a kernel rc-phase between one and two years ago (multiple rc's were affected, maybe even a stable kernel or two in between, I don't remember). That filesystem saw only light usage. I'm also an early adopter of btrfs (almost 3 years now I believe) and it never ate my data (maybe I had to redo my fs once at the very beginning, when ENOSPC didn't work at all). That filesystem is my root partition of my main system and sees a lot heavier usage.

            So for me, definitely, it's btrfs. Of course I might crash horribly with that, but at least I expect it, because that fs is at least still marked experimental.

            Btw, I moved that ext4-on-dmcrypt-on-raid to btrfs. The machine had some stability problems (some RAM modules didn't want to work together), so I did have sudden evil crashes. Btrfs didn't hiccup once up to this point.

            Really, the only way is: have backups. It just gets too difficult for multiple TB of only medium importance.


            so my 2 cents: btrfs, I still like you.
            mazumoto



            PS: I love butter, so maybe I'm a little biased.

            Comment


            • #16
              Originally posted by mazumoto View Post
              I used ext4 on a dm-crypt on raid and it ate my data (silently, randomly) during a kernel rc-phase between one and two years ago (multiple rc's were affected, maybe even a stable kernel or two in between, I don't remember)
              Anecdotal. Hard to say what might have happened to you. Between the fs, the encryption layer, and the raid layer, and possible hardware problems, who could guess? If you care about your data, running vanilla kernels is living on the edge. Let alone rc kernels.

              Andrew Morton stated, for the record, years ago, that if you want a well tested kernel, go with a vendor-supplied one.

              I have about 75 users on EXT4 (Ubuntu kernel) and another hundred on EXT3 (CentOS kernel) and have never lost any data to anything that could be even potentially blamed upon the file system.

              Edit: I did have a corrupted (but fixable) Cobol C/ISAM file once with EXT4, after a power failure with a faulty UPS. Do use the "nodelalloc" mount option. It's not a filesystem bug. But a program bug. But it is a common enough program bug that I do think T'So is on crack for not mounting "nodelalloc" by default. He's well aware of the problem, but in denial about it. Delayed allocation gets him better benchmark numbers.
              Last edited by sbergman27; 10 November 2011, 10:22 PM.

              Comment


              • #17
                @RavFX

                What happened with zram?

                Comment


                • #18
                  Originally posted by RavFX View Post
                  I stopped using BTRFS last Friday. The accumulation of silent corruption made me mad
                  Can you explain this a bit more? I thought BTRFS detected and repaired silent corruption? But you say no?

                  Comment


                  • #19
                    Originally posted by curaga View Post
                    @RavFX

                    What happened with zram?
                    I made the bench yesterday, But I did not have the time to clear the RAM because to test zram I need a tmpfs of 8.8GO too. I have 16GB if RAM so it's a bit short but it will be made today.

                    Originally posted by kebabbert View Post
                    Can you explain this a bit more? I thought BTRFS detected and repaired silent corruption? But you say no?
                    Well.. Small-medium sized files started to corrupt by themselves. small file like 100k file seam to be perfect, And big files 100MB+ too but a got lot of the 500k-10M sized files corrupt. And it's usually stuff that I don't use for long time who get corrupt, like pictures who make jpeg error or that I can only see the top... and music that stop playing in the middle of the track... But it only attacked that size of file that I did not request for months. It attacked one time recently used file, like my EVE game who got corrupt and needed a reinstall.

                    I did not get those problems (personally) on any other FS. I saw EXT3-4 destroyed by there own fsck but it was not in my computer/control

                    Comment


                    • #20
                      Originally posted by RavFX View Post
                      ...Small-medium sized files started to corrupt by themselves. small file like 100k file seam to be perfect, And...

                      ...

                      ...I saw EXT3-4 destroyed by there own fsck...
                      Rav,

                      You're really not doing any service to R4 by trash talking other filesystems and making unverifyable claims about them. It just makes you seem defensive. The kernel devs gave you guys a clear list of the salient problems with Resier4. I would suggest that you guys get to work on it. Trash talking the (time tested and stable) competition isn't going to fix the documented flaws in Reiser4. When the kernel devs deem that the R4 code is good enough to merge, we can revisit the matter.

                      Comment

                      Working...
                      X