OpenSUSE 13.2 To Use Btrfs By Default

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

Comments

Beta testers

[Anonymous Coward]

Finally someone who beta tests btrfs for me!

Re:Beta testers

[complete loony]

I've lost data with btrfs, but I did have a failing drive that I didn't notice was going bad. I didn't have a redundant copy of meta-data and couldn't seem to change that.

All of those things have changed since then. You can set up a cron job to scrub your data instead of being blind to sectors going bad. And you have much better control over the redundancy of your data.

Re:Beta testers

[caseih]

Been beta testing BtrFS for about 3 years now. Haven't had any problems. This is home desktop use. All my laptops run it, and I'm starting to use snapshotting more and more. Snapshotting a single VM disk image file is very handy.

Re:Beta testers

[buchner.johannes]

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

Re:Beta testers

[AvitarX]

More likely scenario,

Most OpenSUSE users use it because they generally like, and trust, the choices of OpenSUSE. This trust may be misplaced, we'll know soon, but in the learning, we'll have a MUCH better understanding of how ready btrfs is to move past the beta testing zone (or if OpenSUSE bosses are right, proven to be past there).

Defaults matter, reputations of Linux distros can shatter on them, because we're not passive users, and thought they aren't all drop in replacements, as non-passive users, they're close enough.

Re:Beta testers

[relisher]

BTRFS inode limitations once cause my system to go completely bonkers. I lost a huge amount of data due to a "limitation of space" when in reality it was an inode limit.

Re:Beta testers

[Menkhaf]

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.

But then again, they were also big ReiserFS fans.

[fustakrakich]

I don't get it. Is Chris Mason about to murder his wife/girlfriend?

An inspiring decision

[MoonlessNights]

It surprising but nice to see someone stepping outside of the "just do what we have done before" box but I suppose there is precedent for SUSE (given the mention of ReiserFS).

Personally, I have been using BTRFS on a few of my systems for a little over a year and it is quite nice. Later versions have some really intriguing snapshot delta capabilities but my main win, with a slightly older version, is the big benefit of reduced disk I/O via transparent compression.

The way that it manages storage pools looks good, as well, although I haven't tried playing with it yet (the systems using it have lopsided disk geometries so it wouldn't be appropriate).

Re:But then again, they were also big ReiserFS fan

[RITjobbie]

He _did_ used to work at Namesys for Hans. Joking aside, his wife is pretty cool. She teaches IT/networking at my alma mater, RIT. I've met a few other (now former) Namesys employees in the past, probably some of the brightest minds I've ever known.

Re:tm abbrevs mk it hrd 2 rd.

[Wolfrider]

--A fairly accurate summation. I would only amend it thusly:

EXT4 = most current open journaling filesystem in widespread use on Linux systems; Successor to ext3 and generally faster

btrfs = journaling filesystem with more bells and whistles than ext4; Functionally designed to compete with (and mostly equivalent to) ZFS, and may have more features for home/average non-Enterprise users

frontend to YaST = graphical utility to command line versions of various Linux setup/configuration tools

Have they fixed the need to manually rebalance?

[csirac]

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.

Re:Have they fixed the need to manually rebalance?

[Swistak]

This is actually a horrible flaw in my opinion. I've also installed btrfs on one of my laptop drives and it was a horrible mistake. If you run out of space it's possible in some edge cases that you won't be able to free your space!
You'd expect `rm huge_file` to work, but no it won't. Some pages recomend echo "">huge_file but that not always help either if the reason the disk got full is metadata
I honestly cannot understand how anyone can create filesystem that A) lies about free disk space B) Does not allow you to free up space when it's full.

Re:tm abbrevs mk it hrd 2 rd.

[Barsteward]

so you'd agree with his definition of KDE Frameworks and QT5?