OpenSUSE 13.2 To Use Btrfs By Default 91
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."
Re:Beta testers (Score:4, Interesting)
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 (Score:4, Interesting)
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 (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 [vleu.net]).
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... [github.com]
Re:Beta testers (Score:5, 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.