Slashdot Mirror
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."
Finally someone who beta tests btrfs for me!
I don't get it. Is Chris Mason about to murder his wife/girlfriend?
“He’s not deformed, he’s just drunk!”
Be prepared to bleed.
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).
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 deleted. This being the case, what happens when the drive fills up?
I have since gone back to using XFS and EXT4 for my files. I have never had any issues with XFS (even when some nasty RAID issues occurred) and have been running it for years and love the tools available for it (xfs_fsr, xfsdump, etc.).
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
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.
--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
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
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.
Successor to ext3 and generally faster
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 handling of directories with lots of files inside, etc.)
All in all, ext4 is pretty darned good for its purpose of storing files. And while I'm looking forward to BTRFS, it's just not ready yet, and ext4 serves me well enough.
Wolde you bothe eate your cake, and have your cake?
so you'd agree with his definition of KDE Frameworks and QT5?
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
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.
[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.
Watch this Heartland Institute video
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 passing criticism or design updates to his visitors.
You don't have to start coding anything by having an idea, starting up an editor and beginning from int main(). You can start development by documenting the idea, the design, implementation and then work out if the design has flaws. And all of it can be done without a computer.
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.
-- Sometimes you have to turn the lights off in order to see.
But you do know openSUSE 13.2 is "pretty far away"? It won't be released until November 2014.
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.
Supporting World Peace Through Nuclear Pacification
The ZFS filesystem from Solaris Unix has some features that ext4 does not, especially filesystem snapshots. That gives you the ability to take a filesystem snapshot at a certain date, and if the system has a filesystem problem in the future that is not from a hardware failure, you can instantly revert your filesystem to the snapshot. Here's a common use case: you take a snapshot, then apply a software upgrade to your system. If the upgrade goes well, you snapshot again. If the upgrade fails, you revert to the original snapshot and the system acts as if the failed upgrade never happened.
This is one of the reasons so many big companies use Solaris Unix. Unfortunately, the software license of ZFS prevents it from being incorporated into the Linux kernel by default. You have to download and install it separately.
Adding that feature to ext4 without completely rewriting it is impossible. That's why btrfs was created, to give many of the good features of ZFS to Linux. The thing is, btrfs needs to be battle-tested before businesses will use it on mission critical servers. You have to start somewhere. Maybe OpenSUSE 13.2 is too soon, maybe it needs another few years as alpha software. But maybe all of the people on this forum complaining about file corruption ran into bugs that have already been patched.
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 all linux distos. I've not used ZFS so I don't know how complex its snapshot feature is and how it would compare to LVM snapshot feature. Using LVM does add an extra layer of complexities in file system management but if you are using a 3rd party file system then the complexities that lvm adds shouldn't be a problem for someone capable of using ZFS.
Supporting World Peace Through Nuclear Pacification
I'm sorry if my post was a little confusing - I don't consider ZFS experimental either. I meant that ZFS is a commonly used Unix filesystem that has more features than ext4, and it can't be part of the Linux kernel. btrfs is an attempt to bring ZFS to Linux without violating any software licenses.
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 and shrinking of storage the two killer btrfs features, and now I see that one can get those from LVM + ext4.
Okay, I find the argument for adapting btrfs as a primary filesystem weaker. I hope there's something I'm missing.