On Tue, Dec 16, 2014 at 02:21:07PM -0500, Josh Boyer wrote:

Your requests aren't bad at all, but they aren't new. Everyone wants btrfs because it was hyped as the filesystem of the future. The future isn't here yet, and it's going to require the people that would like these things to happen to pitch in.

It may only be tangentially relevant to workstation, but it's interesting to note that CoreOS is looking at switching _from_ btrfs to ext4 for the root filesystem (and using overlayfs for docker instead of the btrfs backend).

One more point/request (sorry!).

I'd like to see a GUI partitioner interface somewhere. Actually Anaconda has it already. If you select not to use the automatic partionioning proposal during install there is an option to open it. Why note expose this GUI to user after installation then? It will be useful when attaching more hard disks(s) to the system or just claiming unused space from existing harddisks.

It may be possible already to invoke the Anaconda partitioner GUI interface from command line somehow, but most users will not be able to figure out how (and I cannot either).

-- Peter (still a hardcore SuSE user, as you will understand! :-) )

On Tue, Dec 16, 2014 at 9:17 PM, Peter Laursen jazcyk@gmail.com wrote:

If the same usability can be achieved with other technologies (LVM, containers/docker), I would not mind of course (but I doubt). I also find containers a too complicated technology for a Desktop edition (and btw: it is not more mature than btrfs). I think it is a 'showstopper' for new Linux users that once the system breaks it can require skills that user does not have to restore the system to a point where it was working. once it is broken for any reason.

I have known some people over the last 5 years giving up Linux for same reason.

(and BTW: SuSE 12.3's default is btrfs for" /" and "xfs" for "/home" (no separate "/boot" partition in SuSe default setup). I use btrfs everywhere on my SuSE (I use Suse and Windows for my professional work currently).

-- Peter ​

looks good, indeed!

-- Peter

On Tue, Dec 16, 2014 at 9:57 PM, Matthew Miller mattdm@fedoraproject.org wrote:

On Tue, Dec 16, 2014 at 09:55:49PM +0100, Peter Laursen wrote:

...

It may be possible already to invoke the Anaconda partitioner GUI

interface

...

from command line somehow, but most users will not be able to figure out how (and I cannot either).

Check out Blivet GUI. It's not yet in Fedora proper, but there is a COPR:

http://fedoramagazine.org/manage-your-partitions-like-in-anaconda-with-blive...

-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop

On Tue, Dec 16, 2014 at 12:21 PM, Josh Boyer jwboyer@fedoraproject.org wrote:

Your requests aren't bad at all, but they aren't new. Everyone wants btrfs because it was hyped as the filesystem of the future.

tl;dr Those who want it, want it for the features, and much simpler access to those features. Not because of hype.

Raid, resizing, snapshots, are much easier with Btrfs separately let alone in combination. And they're safer because the nomenclature is nowhere near as obscure or varied due to the differing syntax of mdadm, lvm, and mkfs. Today.

mkfs.btrfs -draid5 /dev/sd[bcde]

vs

mdadm -C md0 -n 4 -l raid5 /dev/sd[bcde] mdadm --detail --scan >> /etc/mdadm.conf pvcreate /dev/md/md0 vgcreate VG /dev/md/md0 lvcreate -l 95%FREE -T VG/thinp -V 2500M -n home mkfs.xfs /dev/VG/home

mkfs.btrfs doesn't need to sync, so it's a < 2 second mkfs. It's hours or days for conventional raid sync.

How about growing by adding a new device?

btrfs device add /dev/sdf <mountpoint>

vs

mdadm --add /dev/md/md0 /dev/sdf mdadm --grow --raid-devices=5 /dev/md/md0 pvresize /dev/md/md0 lvextend -L+100G VG/home xfs_growfs /dev/VG/home

The mdadm add/grow requires a reshape. Btrfs doesn't. And there are inefficiencies in resizing XFS or ext4 that don't apply to Btrfs. Today, there's some bug preventing the grow/reshape from completing, so it's not like everyone except Btrfs is immune to showstopper bugs. So right now I can't even complete the above grow for md+lvm+xfs, while the raid5 one not only works but it's faster. https://bugzilla.kernel.org/show_bug.cgi?id=89851

How about I take a snapshot of /home, and then accidentally delete a file and want to rollback?

btrfs subvolume snapshot /home /home.1 rm -f /home/chris/importantdonteverdelete.tar.gz cp --reflink /home.1/chris/importantdonteverdelete.tar.gz /home/chris/

This completes instantly regardless of the file's size.

vs

lvcreate -s --name home_snap VG/home rm -f /home/chris/importantdonteverdelete.tar.gz lvchange -ay -K VG/home_snap mount -o nouuid /dev/VG/home_snap /mnt/homesnap cp /mnt/homesnap/importantdonteverdelete.tar.gz /home/chris/

Not the end of the world, but it's still more lines to remember and type, I had to man lvchange to recall the -K, and this method requires a full file copy which is slower and takes up space in the pool.

On Wed, Dec 17, 2014 at 3:56 PM, Josh Boyer jwboyer@fedoraproject.org wrote:

On Wed, Dec 17, 2014 at 5:45 PM, Chris Murphy lists@colorremedies.com wrote:

...

On Tue, Dec 16, 2014 at 12:21 PM, Josh Boyer jwboyer@fedoraproject.org wrote:

...

Your requests aren't bad at all, but they aren't new. Everyone wants btrfs because it was hyped as the filesystem of the future.

tl;dr Those who want it, want it for the features, and much simpler access to those features. Not because of hype.

tl;dr I know all of that. It still doesn't change the fact that the features are tied to a filesystem that isn't actually read yet. It doesn't matter how simple it is to use if it doesn't actually keep your data safe.

I was responding to the hype assertion. OK so now about the suggestion it doesn't keep data safe...

What's this based on? It connotes data on Btrfs commonly isn't safe on stable hardware.

How about, "you can yank the power cable 1000 times and the filesystem survives with no abnormalities, and does not require an fsck" in which case it's safer than ext4 or XFS based on [1] and [2]. That is just one test, and it's probably on well behaved hardware. But I don't know of any other side by side comparison like this, in particular one suggesting Btrfs isn't keeping user data safe.

Ok so what's Fedora's "Btrfs is ready" metric? It used to be that an fsck needs to ship. Ok, there's been one for a while. Is the real metric that the fsck needs to fix use cases x, y, and z even though those aren't listed anywhere? OK fine, it just needs to work better and the various repair methods need consolidation, all reasonable but not stated as the thing that makes it ready.

What if it turns out Btrfs needs fsck less often in the first place, and what remains to be fixed by an offline fsck is just really hard to fix, hence a higher fsck fail rate?

Opensuse 13.2 by default puts /home on XFS, and everything else on Btrfs. Did Fedora consider this? Should it be considered? It gets around having to answer the question whether it's ready for user data, by using it for more easily replaceable system data should it go belly up. And in the meantime provides a means for online atomic updates and dropping the immediate reboot requirement; and rollbacks; and dropping the complexities (to users and admins alike) of LVM.

Also, opensuse 13.2 doesn't appear to limit Btrfs by default on command line as far as I can tell. I can create and use multiple device Btrfs volumes, including raid56, autodefrag, compression, and send/receive all work.

[1] http://events.linuxfoundation.jp/sites/events/files/slides/linux_file_system... slide 21 [2] https://events.linuxfoundation.org/sites/events/files/slides/Btrfs_Current%2... slide 8