Slashdot Mirror

← Back to Stories (view on slashdot.org)

OpenSUSE 13.2 To Use Btrfs By Default

Posted by Soulskill on from the changing-horses dept.

An anonymous reader writes "OpenSUSE has shared features coming to their 13.2 release in November. The big feature is using Btrfs by default instead of EXT4. OpenSUSE is committed to Btrfs and, surprisingly, they are the first major Linux distribution to use it by default. But then again, they were also big ReiserFS fans. Other planned OpenSUSE 13.2 features are Wayland 1.4, KDE Frameworks 5, and a new Qt5 front-end to YaST."

4 of 91 comments (clear)

  1. Beta testers by Anonymous Coward · · Score: 5, Insightful

    Finally someone who beta tests btrfs for me!

    1. Re:Beta testers by buchner.johannes · · Score: 5, Interesting

      You can create a file system on a file on your disk (similar to a swap file).
      Contrary to popular believe this is not slower than a partition, because if the file is mostly continuous, it can be mapped to disk directly by the kernel. Here I create a file system using a sparse file:
      $ truncate +20G mylocal.fs
      $ mkfs.btrfs mylocal.fs
      $ mkdir -p mylocal; sudo mount mylocal.fs mylocal/

      You can use such file systems, for example, to bundle directories with many files, which are deleted/created many times. This causes fragmentation in the file system. Contrary to another popular believe, yes, this is a problem on Linux file systems, and it slows down reads. None of the file system currently has a defragger implemented. Btrfs is actually developing one, but I think it is not in the release yet. The recommended solution is rewriting files (shake).

      Sub file system containers can be easily resized, and with sparse files only use up the space filled with data. I use them for the linux kernel build directory (you shouldn't build in /usr/src), for portage (many files, changing frequently), and scientific data directories, to limit the fragmentation, and keep speed high. I use reiserfs for this -- find a managing script here: https://github.com/JohannesBuc...

      --
      NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
    2. Re:Beta testers by Menkhaf · · Score: 4, Interesting

      I experimented a bit with btrfs some months ago as part of my parttime job at my university. The departments file server had disk failures after a power glitch, so I decided to rebuild it and add in a UPS. I'm running Debian jessie on the system, which is just a small 2U SuperMicro rack case with 12 3 TB SATA drives and 16 GB ECC RAM. ZFSonLinux needs a fairly recent kernel, otherwise I'd probably have gone with stable.

      I was initially pretty impressed with btrfs, but before the UPS arrived there was another power glitch (which is fairly unusual in these parts of the world; northern Europe) and it completely trashed btrfs. I was unable to mount, scrub or do anything productive to the FS. Absolutely no luck doing anything.

      After that I've switched to ZFS. I'm really happy with ZFS, even though ZFS on Linux still has some bugs. For some reason zfs threads sometimes crash when doing zfs send | zfs receive, something I've noticed a few times. Performance is pretty good. For reference I'm using raidz3. My offline, off-site backup is done on a clone of the server (OS only) and uses zfs send and receive to transfer the ZFS snapshots which are done nightly.

      --
      A proud member of the Onion-in-Hand alliance
  2. Have they fixed the need to manually rebalance? by csirac · · Score: 4, Informative

    I've been using btrfs on all my machines/laptops for more than 2 years now. I've never had corruption or lost data (btrfs has actually coped rather well with failing/dying disks in my experience), unlike ext4. COW, subvolumes and snapshots are nifty.

    But too many times I've had the dreaded "no space left of device" (despite 100GBs remaining) when you run out of metadata blocks. The fix is to run btrfs balance start /volume/path - I now have a weekly cron job on my non-SSD machines - but it's hugely inconvenient having your machine go down because you're expected to babysit the filesystem.

    Recent months of Docker usage has made me encounter this condition twice this year already.

    I'll continue using btrfs because I've experienced silent corruption with ext4 before which I believe btrfs would have protected me against, and I like snapshots and ability to test my firmware images cheaply with cp --reflink pristine.img test.img.