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."
Beta testers (Score:5, Insightful)
Finally someone who beta tests btrfs for me!
Re: (Score:2)
I still click on ext3 on new installs....
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
To be objective; did btrfs got more stable lately? Did suse tweak it?
Re: (Score:1)
I'm pretty sure that it's constantly getting more stable, and if OpenSUSE is using it, they probably did vet it.
I'm pretty sure the only point of distros like OpenSUSE or Fedora are to get wide testing on new technologies (this is good, and running them is a great way to give back to the community).
I would guess that in a year btrfs is going to be the default in general, but it takes someone to make the leap of faith to start that rolling. If no main stream distro adopts ever, it will by tautology never be
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: (Score:2)
Re: (Score:1)
Lost data recently (Score:2)
I've lost data recently with btrfs, in the past two weeks. Redundant metadata & data didn't help me. Neither did the snapshots.
Thankfully, I had a backup of the data.
So my review of btrfs: Not ready. Slow. May eat 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)
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.
Re: (Score:1)
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: (Score:1)
You should definitely make a blog post about this!
Re: (Score:2)
Re: (Score:1)
"autodefrag" seems to habe been in since 3.0:
https://btrfs.wiki.kernel.org/index.php/Mount_options
Re: (Score:2)
OpenSUSE users beta test EVERYTHING for everyone. I thought Fedora was bad, but OpenSUSE puts them to shame...
Re: (Score:2)
I usually lag behind new releases by months, unless I'm setting up a new computer and so I don't have anything to lose
our experience at work of BTRFS having poor and inconsistent performance have put me off ever using it personally except as experimental. OTOH, we found ZFS to be very good.
Re: (Score:1)
Pah. My phone uses btrfs.
Re: (Score:2)
But then again, they were also big ReiserFS fans. (Score:3, Funny)
I don't get it. Is Chris Mason about to murder his wife/girlfriend?
Re: (Score:2)
Re: (Score:1)
Why can't Reiser continue? Just because he is in prison? WTF not? It's not like he has anything else to do now. Just because he can't be allowed near future wives and society says he must be punished does not mean he can't contribute to society.
Re: (Score:1)
Why can't Reiser continue? Just because he is in prison?
Yes, exactly because he's in prison, where they don't allow you your own personal computer hardware or general access to the internet.
Shocking, I know. They'll be locking him in at night next!
Re: (Score:2)
You don't need a PC to code. Seriously, you don't. If he's allowed visitors and they can leave him printed materials, that's all that's needed to code.
Hell, he can sit and think through a lot of the flaws of the filesystem by doing it all mentally or on paper the
Re: (Score:3)
--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
Re: (Score:2)
Create a (non-sparse) 1GB or larger file on ext3. Then time how long it takes to delete it. For large file handling, ext4's use of extents rather then allocating individual blocks is far superior to ext3. (It's not an edge case either these days, not with MKV & MP4 files measured in 100s of megabytes. Or disks measured in terabytes.)
Plus you get the faster fsck times at boot. And a bunch of other useful features (shrink/growing the file system, faster handl
Re: (Score:1)
[ext4 vs ext3] a bunch of other useful features (shrink/growing the file system, faster handling of directories with lots of files inside, etc.)
Uh, ext3 has online grow (but not shrink). Does ext4 do online shrink?
And ext3 hahes big directories for faster access too.
Not that there are no advantages, but you seem to be claiming ones that don't exist.
Re: (Score:2)
If you live on the bleeding edge (Score:1)
Be prepared to bleed.
Re: (Score:2)
Hans, is that you?
An inspiring decision (Score:2)
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
Re: (Score:2)
Quite possibly Red Hat intends to GA RHEL7 before November and it doesn't give them as much time for testing as OpenSuse has. Other than the simple fact that RHEL and Suse are enterprise, and OpenSuse is not.
I sure as hell won't be using Btrfs for any data I care about in the foreseeable future (not through 2015 at least). I consider Zfs On Linux [zfsonlinux.org] to be much more reliable and well-tested as well as far superior.
Re: (Score:2)
Does XFS still shred your files on system crashes or power loss? FAQ claims they fixed that in 2.6.22, yet with 2.6.27 it was still shredding files like crazy for me. This was however years ago, has anything changed still then?
Re: (Score:2)
no
but recently there was little bug where xfs_growfs would sometimes panic kernel (filesystem recoverable)
it's been fixed
Re: (Score:2)
"Shred" as in files getting cut to 0 bytes. With XFS there was a 50/50 chance that your desktop wouldn't boot after a powerloss as half the config files where suddenly empty.
Re: (Score:2)
How is the btrfs speed compared to ext4 in your experience? Most tests I see has it slower with the explanation that it actually does more than ext4. Many of us still have magnetic drives instead of SSDs so, speed could be an issue. On the otherhand, reduced disk I/O should be a speed improvement. So, how does it perform?
Re: (Score:2)
Re: (Score:1)
Yes, the ability to add/remove storage devices is done on the live file system.
I haven't played with it myself but I know that there was talk of using this for OS installation (beyond the more obvious live disk replacement possibility):
-boot from live DVD
-start installation is just "add new device to pool" (returns immediately), followed by "remove DVD device from pool"
-the "remove" doesn't return until it has finished migrating (and possibly balancing, if you added several devices as the target)
-once "remo
Re: (Score:2)
Re: (Score:1)
The American sequestration didn't help ZFSonLinux, since the primary developer is Lawrence Livermore National Laboratory (a research lab funded by the US government). But the pace of development has been pretty constant:
https://github.com/zfsonlinux/... [github.com]
Just because the last stable build was released in 2013 doesn't mean there hasn't been work done.
Too Slow (Score:2)
I tried setting up btrfs about a year ago on one of my servers running imap (which is continually backed up). I gave up in disgust since btrfs was insanely slow just untarring all of the files (Cyrus Imap stores each email as a separate file). This was on a relatively fast Intel SSD drive. As more and more files were added, the speed continued to drop.
The other problem I have is that I could not find an adequate answer with respect to free space. When files are deleted it sounds like they really aren't dele
Have they fixed the need to manually rebalance? (Score:5, 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" [kernel.org] (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: (Score:2)
Re: (Score:2)
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 no
Re: (Score:2)
I've been using btrfs on all my machines/laptops for more than 2 years now. I've never had corruption or lost data
How do you know?
Re: (Score:2)
Because BTRFS actually checks for corruption unlike older file-systems.
Re: (Score:2)
Re: (Score:2)
Dude, nobody said BTRFS is mature. Did you read the part where I've had to manually rebalance several volumes on multiple occasions? I'm sorry that you interpreted this statement as a ringing endorsement of a mature filesystem - but it's not the case that users should have to do this kind of babysitting in a mature technology.
I *have* had BTRFS fill my logs with checksum failures on a couple of dying disks, and I was able to recover everything intact (
Make sense (Score:2)
I have been using BTRFS for a while now with no problems. Even been through a couple of unclean shut downs, and unplugging mounted drives.
I suspect that some of people reporting corruption have bad hardware. If they run ext4 the corruption happens, but they never notice. When they switch to BTRFS it spots the corruption quickly because of checksumming, and makes noise about it. Not to say that BTRFS is bug free, but neither is any other file system.
Re: (Score:1)
Re: (Score:2)
There is a reason to sick to the ext3/4 filesystem as the standard filesystem. Because it is the standard. Almost every filesystem tool in the linux world expects to be working with ext3/ext4. Sure you have special versions for vanity filesystems such as reiser and this one, but most tools expect ext3/ext4. There is nothing wrong with running a specialized filesystem specialized applications such as databases but not as your main default system. And certainly not a damn beta filesystem.
Not off topic but completely on topic. People are doing stupid things with a experimental filesystem and I'm call it what it is. Stupid.
Re: (Score:2)
Re: (Score:2)
The ZFS filesystem from Solaris Unix has some features that ext4 does not, especially filesystem snapshots.
I don't really conceder ZFS to be an experimental fliesystem. I would regard it as a mature and tested file system and I would not have the same issues with someone using it as a specialized file system like I mentioned. But at the same time I wouldn't regard it as a standard file system the same way ext3/ext4 is.
The snapshot feature you mentioned, I admit, would be very handy, but you can achieve the same thing using logical volumes and ext4. Unlike ZFS logical volume management is a standard part of
Re: (Score:2)
I didn't know about LVM snapshots, thanks for informing me. I also didn't realize LVM supports adding and removing storage devices to the volume while the system is live. I considered snapshots and growth a