On 9/16/13 7:53 AM, Sebastian wrote:
On 09/16/2013 12:05 PM, Stephan Kulow wrote:
Hi,
The last btrfs bugs have shown that we just have too little coverage of btrfs. As using btrfs is a very prominent option - and hopefully our future default file system, we had some discussion how can we improve that in the remaining time frame.
Our "solution" (noone likes it, but noone has a better idea either) is to add a popup asking to use btrfs during the installation of the Beta. I hope that this leads to more testing of btrfs in real life scenarios - the feedback from those using btrfs in Factory is good (just for reference, I use it too :) but IMO we have too few new installations using it.
The popup is a crude hack and will be taken out during the Rc phase. Hopefully til then we found and fixed enough btrfs problems.
first: please tell me you resolved my bug:
On 09/14/2013 03:59 AM, Sebastian wrote: can't boot my btrfs raid1 anymore
You reported this on Friday night and I'm afraid I rather enjoy my weekends mostly away from computers. So no, it's not fixed yet.
second: i really really really advice against using btrfs yet unless you have backups ready and know what you are doing!
i've been using btrfs for over a year now on both root and home with raid1 and compression (whereas /home is on an encrypted lvm), and had several unmountable partitions. while that has improved a lot lately, its still unstable especially with power loss or system crashes. with kernel < 3.7 you would have an unmountable drive. with 3.8 onwards you might get only ro which still means you'll have to run btrfsck or even recreate the partition. both options mean you'll be greeted with "welcome to the emergency mode!" if it is in fstab.
This is pretty much the poster child for why I've been pushing the "allow_unsupported" option. We know there are features in btrfs that aren't fully mature yet and that's how we avoid situations like this. You're welcome to test it. We appreciate the bug reports and will use the reports to improve the fs -- but you're using the feature set that we have published as immature and that I've said multiple times on this list shouldn't be used yet.
btrfsck has improved a lot, too, but still you might get an unrepairable filesystem. oh and: you'll probably want latest btrfsck from git not the suse shipped one.
This part is true and we should be more aggressive about updating and releasing btrfsprogs.
moreover, for anything that uses a database (better: has many writes in small portions) like sqlite, one should at least add chattr +C (=no copy on write) to the parent folder. yes, this includes all browsers, mail clients, RPM & zypper and so on. (to do that on an already installed system you'll have to create a new folder with +C, copy the old files in it and rename that folder to the actual name).
put together, btrfs is nothing for newbies, no its only for someone that has backups and - if using btrfs root - a backup or live system always ready.
This is FUD. You are using a file system that has features enabled that we've clearly discouraged.
plus if someone from suse decides to add a "allow_unsupported" switch within initrd, your system becomes unbootable for no reason whatsoever....
I'm not sure what you're getting at here. This is an issue for the integration of that patch. -Jeff -- Jeff Mahoney SUSE Labs