Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15

Thread: Btrfs In Linux 3.11 Has More Fixes, Performance Tuning

  1. #11
    Join Date
    Nov 2011
    Location
    Orange County, CA
    Posts
    72

    Default

    Quote Originally Posted by hiryu View Post
    Impressive. What type of configuration are you using? Hardware RAID? btrfs RAID?
    I run a file server with 6x 2TB dm-RAID6 and a workstation with 6x 3TB RAID6 on an LSI 9271. Root is ext4 (separate LV on the file server, SSD on the workstation) and /home is btrfs.

    The one time I needed surgery to get the filesystem back up was when I backed up from the workstation to the file server and pulled the power cord on the server by accident. Now it's held in with a zip tie

  2. #12
    Join Date
    Nov 2009
    Posts
    97

    Default

    Quote Originally Posted by rrohbeck View Post
    I run a file server with 6x 2TB dm-RAID6 and a workstation with 6x 3TB RAID6 on an LSI 9271. Root is ext4 (separate LV on the file server, SSD on the workstation) and /home is btrfs.

    The one time I needed surgery to get the filesystem back up was when I backed up from the workstation to the file server and pulled the power cord on the server by accident. Now it's held in with a zip tie
    I was about to ask you why you'd use dm raid instead of btrfs raid... and then I remembered that RAID5/6 are fairly recent to btrfs.

  3. #13

    Default

    Quote 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).

  4. #14
    Join Date
    Jun 2010
    Posts
    71

    Default

    Quote 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!

  5. #15
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,859

    Default

    Quote 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.

Posting Permissions

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