Announcement

Collapse
No announcement yet.

Testing Out The Btrfs Mount Options On Linux 3.2

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

  • #16
    Well, I saw the results and I've a weird question to ask about them: Why using compression gives so much better performance than not using compression at all? Shouldn't it be the opposite? It seems something very wrong is on the results that use BTRFS compression, btw...

    Also, these results only confirm why at the moment ext4 is the defacto file system for Linux consumer users. But I hope BTRFS will get better over time...

    Cheers

    Comment


    • #17
      Originally posted by rrohbeck
      I've been using Btrfs heavily since October, with a 4x 3TB RAID 10. Frequent creation/snapshotting/deletion of subvolumes for sandboxes that often go up to 140GB and a bunch of VMs (you want chattr -c and -C for VMs, otherwise they're slow.) I also had a few crashes and power failures. Oh and the whole thing runs on top of Flashcache.
      Zero problems.
      +1

      I've also been using btrfs roughly since October for my main /home/ partition on my (frequently used) laptop. Never had a problem with the FS, and I've managed to run the laptop out of battery a couple of times, although I'm not using any of it's features yet.

      Comment


      • #18
        @Kamikaze and rrohbeck:

        I'm not trying to mock your personal experience, far from it.
        But please keep in mind that when it comes to file system corruption, "WORKS-FOR-ME" reports carry *far* less weight than corruption reports - even if only 1/1000 suffers from a catastrophic report. (And by looking at the Fedora bugzilla, btrfs has yet to reach 1/1000 level)

        - Gilboa
        DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
        SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
        BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
        LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

        Comment


        • #19
          Originally posted by gilboa View Post
          @Kamikaze and rrohbeck:

          I'm not trying to mock your personal experience, far from it.
          But please keep in mind that when it comes to file system corruption, "WORKS-FOR-ME" reports carry *far* less weight than corruption reports - even if only 1/1000 suffers from a catastrophic report. (And by looking at the Fedora bugzilla, btrfs has yet to reach 1/1000 level)

          - Gilboa
          +1 This. Using BTRFS on my main / (Gentoo) without any problems and i already had some power blackouts and no corruption for now. I guess everyone has already forgotten how ext4 was eating data and BTRFS is safer than ext4 without crippling performance too much and has a lot more useful features as well. All i say is that if BTRFS is at least 2/3 as fast as ext4 i will choose it any day.

          Comment


          • #20
            Originally posted by gilboa View Post
            @Kamikaze and rrohbeck:

            I'm not trying to mock your personal experience, far from it.
            But please keep in mind that when it comes to file system corruption, "WORKS-FOR-ME" reports carry *far* less weight than corruption reports - even if only 1/1000 suffers from a catastrophic report. (And by looking at the Fedora bugzilla, btrfs has yet to reach 1/1000 level)

            - Gilboa
            Yep, fair enough. I wouldn't advocate it for any kind of business use at this stage and frankly I'm surprised that oracle are (possibly?) considering it production ready with the reports out there of unrecoverable errors.

            I'm hoping this will change in a year or two though; once the btrfs fsck tools are released and stable, and a major distro is comfortable enabling the FS by default (and the bug reports have been addressed).

            BTW - regarding the oracle front, anyone know if they are still considering allowing btrfs to be set as the root partition on their next release considering the btrfs tools still aren't out of their experimental "do not use" state?

            Comment


            • #21
              Originally posted by gilboa View Post
              @Kamikaze and rrohbeck:

              I'm not trying to mock your personal experience, far from it.
              But please keep in mind that when it comes to file system corruption, "WORKS-FOR-ME" reports carry *far* less weight than corruption reports - even if only 1/1000 suffers from a catastrophic report. (And by looking at the Fedora bugzilla, btrfs has yet to reach 1/1000 level)

              - Gilboa
              Valid argument.

              Also remember that running in production in a critical business is another thing than running BTRFS at home. If you bet money, you want to go as safe as possible and minimize the risk.

              Comment


              • #22
                Originally posted by stan View Post
                OK, so let's talk reliability. As it stands, BTRFS is much more prone to corruption and gradual degradation of speed and even available free spance than EXT4. Just look at all the reports of people saying BTRFS becomes unusable after a a few days of running. The fact is that for the vast majority of desktop users, BTRFS still has no advantage over EXT4.
                Performance degradation is exactly what I'm experiencing:: Random apps often stall for many seconds while one or more cores are in I/O wait and no paging takes plae.
                I even updated the kernel from 3.1 to 3.3 and performance degradation happened again within some days.
                Could you give links to bug reports on this (I have difficulties to identify the correct one at bugzilla.kernel.org)?

                Comment

                Working...
                X