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'd give you good odds that the November release date is optimistic though. I also hope you weren't expecting to run btrfs on RAID.
I don't get it. Is Chris Mason about to murder his wife/girlfriend?
“He’s not deformed, he’s just drunk!”
so how long did openSUSE use EXT4 prv. with KDE 4 and prev Qt5 frontends with YaST b4 2 btrfs? wht r adv. to use btrfs vs. EXT4? hoping OpenSUSE ships w/ dictionary 4 abbrev.s!
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).
Being a huge ZFS fan, I would love to see some competition with the opensource btrfs, but having had it corrupt data pretty quickly after playing with it... This is a dangerous move for OpenSUSE. When you talking filesystems, you should only ever DEFAULT to one that is tried and true.
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.
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.
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.
Democracy Now! - uncensored, anti-establishment news
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.
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!
systemd is Roko's Basilisk.
I hope the upgrader still works if btrfs is the root volume.
Ugprading from openSuSE 12.1 to 13.1 and SLES 11.2 to 11.3 would not work when booting from a valid install media if / was a btrfs volume. The btrfs disks were found, but the mount points were not. I don't know if this is a bug from the heavy use of subvolumes by openSuSE and SLES or from problems internal to the installer.
For those who haven't tried a VM install, the installer for openSuSE and SLES recommend and by default when installing with btrfs for / will suggest making /var, /usr into btrfs subvolumes. This is a feature much like a cross between an LVM volume and a souped up quota controlled directory. You can snapshot the subvolume separately from the root of the disk, manage their size but also mount the subvolume as the root of the disk. I suspect this later feature - no special root - might not be being handled so gracefully.
SLES also has some serious issues with booting btrfs volumes composed of multiple disks. With LVM, you can slap in an extra disk and expanded a volume group then all contained filesystems across to include the new disk. Your sysem will continue to boot just fine. btrfs can just expand the filesystem to include the new disk. Except that when you boot Linux kernel to a btrfs root or other critical must-mount volume composed of multiple disks a special scan has to be done before the disks can mount. Since the SLES and openSuSE mkinitrd don't handle this case it causes the system to panic and drop to an initrd backed shell.
There is a workaround for multi-volume boot failures by hacking in a special boot script. Once can do this since the SuSE mkinitrd process is heavily over-engineered. (This is a good thing.) Certainly beats trying to manually do the Linux kernel mount process by hand each time you boot up.
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
Mavi Teknik Servis Siz Degerli Müsterilerine Hizmet Vermek için istanbulun Bütün Bölgelerine Servis Göndermektedir.
letisim çin 0530 119 5 229 Numarali Hattan 7 Gün 24 Saat Arayabilirsiniz. Mavi Teknik Servis
Uzman Kadrosu ve Tecrübeli Teknik Elemanlari ile istanbul Halkinin Hizmetinde
The manuals in openSUSE are one of the main reasons I adore this distro. They explain how to look after your btrfs filesystem quite nicely.
Also a main part of openSUSE that makes btrfs quite usable for less hands-on sysadmins and "ordinary" desktop/laptop users, is it's integration with Snapper. With btrfs, the main culprit in consuming space that I've encountered (on single-device filesystems which you can't "balance"), is actually old snapshots. Snapper takes periodic and strategic snapshots, but it also prunes old snapshots. You can tune how it cleans up old snapshots if the defaults are keeping too many around.
sudo btrfs filesystem show
The first thing to do when your disc space is low on a btrfs system is not du / |sort and then rm huge_file, but instead to snapper list and snapper delete. Without Snapper, btrfs is a lot more manual (a lot like rpm without zypper/yum). I believe this usability is why openSUSE can adopt btrfs as its default, as much as btrfs' stability itself.
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.
July 2014
Today I am testing openSUSE 13.2 M0, and reports.