Shared publicly  - 
 
btrfs is maturing. Recently, a discussion on the openSUSE mailing list came close to deciding to set it as default in openSUSE 13.1. Have you tried this next generation filesystem lately and what were your experiences?
[GIT PULL] Btrfs. From: Chris Mason Date: Thu Sep 12 2013 - 11:36:41 EST. Next message: Daniel Vetter: "Re: [BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE"; Previous message: Joerg Roedel: "[git pull] IOMMU Updates for v3.12"; Next in thread: Josh Boyer: "Re: [GIT PULL] Btrfs ...
25
8
Estêvão Valadão's profile photoGaetano Di Bari's profile photoJoan de Gracia's profile photoBo Ye's profile photo
18 comments
 
I tried it last year. It made my laptop hang at boot one time due to lack of fsck support.
I haven't tried it recently.
 
Had it running on a company laptop with a fairly small partition ... and one day broke btrfs beyond repair by using up all free space. Trying to rm files afterwards just resulted in 'No space left on device' error :( I couldn't find a way to fix this (even 'btrfs fi balance' failed with the error), and had to reinstall the whole system.

I understand the reasoning behind it (in a journaled filesystem even deleting stuff will generate metadata that has to be stored somewhere), but I'd have expected that there's at least some solution short of reinstalling everything.
 
+Kai Köhne Suse creates automatic snapshots, you have to remove those to get space. 
 
I will still use ext4 it is more stable for me.
 
+Bernd Paysan Alright, so deleting snapshots would still work in such a setup?

(In my case it was btw a Fedora with btrfs ... as I said, company laptop ;)
 
Running OpenSUSE 12.3 with many of the 13.1 packages. I love the btrfs but it broke twice with the default kernel (3.7.*) and inode_cache enabled. 3-4 weeks ago I disabled the inode_cache and switched to a newer kernel (3.11.0). So far - no other issues with the FS. I enabled skinny extents a few days ago, not really sure if I feel the difference but definitely no issues :)
Current mount options - rw,relatime,compress=zlib,ssd,discard,space_cache
 
+Kai Köhne snapper (which is taking snapshot of the system) has been improved to better clean old snapshots. Moreover, Jeff Mahoney has also improved btrfs recently to allow recovery of space when removing snapshots or files in the case you describe.
 
+Ivan Arabadzhiev
you should drop compress=zlib, it is considered not mature enough by SUSE btrfs hackers for now (I was also using it). Can't talked about skinny extents but extended inode refs should be enabled these days. And you can drop space_cache from your mount options, it is by default for a long time now :)
 
+Kai Köhne I occasionally need to delete my snapshots here on a SuSE 12.3 machine, which has "just" 24GB of SSD - which I use for OS and swap.

At first, it was very confusing, because df didn't even report that the file system was full, but that has been fixed by now.

What btrfs lacks for maturity is encryption.  Yes, you can use LVM+dm-crypt/LUKS, but that goes against the idea of btrfs (and ZFS) to not layer on top of some other virtual disk layer.
 
+Frederic Crozat 10x for the tips :) I`ll stick with the compress, mostly because I backup often enough (long time Windows user ... I`ve felt the pain :P)
As for the space_cache ... I think I didn`t add that one (just didn`t see the need to remove it:))
 
I've used it for the last two releases of +openSUSE and not had any problems. Unfortunately both my computer and I were in an accident and my computer came out not booting (no post), but recovering the drive on a Mac was as simple as downloading a live CD of openSUSE and passing the drive as a raw disk to a VirtualBox VM. Hopefully I'll be able to get a replacement/fix my machine so I'll be back on Linux :). One thing I'd find useful is a way to sync/mirror a btrfs subvol and it's snapshots to another machine running btrfs (i.e. a server). I wrote a script to do that, but it is extremely specific on how it's supposed to be run and will barf/be terribly inefficient on kill and resume. (I'd use it with snapper's snapshot layout)
 
I tried it when setting up a new server and the tools hosed the installation and made it unbootable. I am sure in the end it was my fault, but the tools definitely need some safeguards.
 
I have tried btrfs about a year ago and it was much slower than ext4. I'm not sure that it's speed is now compatible with ext4.
 
I'm regularly running into the "no free space left" problem. Balancing does not work then. (However, partial balance might actually work, with -usage={n}. That's somewhere on the btrfs troubleshooting wiki page. Not something a normal user would find.) All I can do is increase the size of the LV and the btrfs on it. As long as I have physical space left that's not taken up by the LV.
Iirc, also deleting snapshots won't with in this case. What could work is to Mount the fs with the clear_cache option.

I am using compress=lzo. Seems to work for me.

Btrfs gets really, really, really slow over time. Only balancing (which can basically freeze my machine for days - partial balance works better. And knowing the skip_balance mount option) and defragmenting helps. Still not sure in which order to do the two.
I didn't yet dare to enable auto defrag.
 
PS: snapper saved my ass a few times. I love being able to diff and roll back my entire system. Very helpful with broken packages, failed binary installers and manual-fiddling-gone-wrong.
Add a comment...