Announcement

Collapse
No announcement yet.

Btrfs In Linux 3.11 Has More Fixes, Performance Tuning

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

  • #11
    Originally posted by Ericg View Post
    I'm sorry but that wiki entry is an insult to the readers' intelligence. The same argument can be made about every piece of software, yet enough people agree on stability in many software developments and implement them as default for mission critical systems. NOBODY expects any software to be completely bug free ever, but that's hardly the point of being stable. Including both in the same sentence is disingenuous.

    Depends who you ask... ask me? Its been stable and ready to be used since Fedora 17 was released (that time frame)-- thats about when I installed Arch on my home server with 2 hard drives and told Btrfs to automatically use both as a single volume. Btrfs on a home server, Btrfs on this laptop. Compression is awesome, automatic ssd optimizations are great, great performance, no bugs / crashes / corruption, nothing.

    Its the same issue that KDE had... everyone got told "DONT USE IT ITLL EAT YOUR DATA" because of early bugs. People only speak up when things are bad, they dont speak when things are good. You just have to jump in the pool and see for yourself like I did guys, by the way...the water's great :P
    That's a much better reply, thanks. Maybe you can cast some light on why no major distro uses BTRFS as the default file system. Snapshots itself is a feature that makes so much sense on a desktop that there must be some reason why even bleeding edge distros like Fedora avoid this file system. And that -adoption by major distros- is the only thing any regular user cares about regarding stability (which is what makes the idiotic explanations on the official wiki insulting).

    Comment


    • #12
      Originally posted by GreatEmerald View Post
      I'm not sure I follow. If you cut the power, there is little a filesystem can do. The data written will be truncated, and that's that. It's the same across all other filesystems. If you want to avoid that, get an uninterruptible power supply.
      That's just plain wrong! Not all FSs behave the same way as BTRFS when power is cut off. Try turning the power off on a ZFS filesystem. Go ahead and try it. Then, start a FS heavy process and do a ton of IO and then again power off in the middle of it. Go ahead and try it. And try again. And again. You will never be denied a mount or data consistency.

      Do not try that on a BTRFS filesystem. Ever!

      Comment


      • #13
        Originally posted by devsk View Post
        That's just plain wrong! Not all FSs behave the same way as BTRFS when power is cut off. Try turning the power off on a ZFS filesystem. Go ahead and try it. Then, start a FS heavy process and do a ton of IO and then again power off in the middle of it. Go ahead and try it. And try again. And again. You will never be denied a mount or data consistency.

        Do not try that on a BTRFS filesystem. Ever!
        Assuming you don't hit complete and total filesystem corruption, worst case for BTRFS is old data. You will either get the new data that was flushed from buffers and written to disk, OR the old data BEFORE the write-- thanks to Copy On Write. And they fixed quite a few 'total corruption' bugs in the last few kernel releases. I can't say that they fixed ALL of the total corruption bugs, because I haven't checked git logs THAT much, but you may be working on old information.
        All opinions are my own not those of my employer if you know who they are.

        Comment

        Working...
        X