What about her face? (Score: 2, Insightful) by fishybell@pipedot.org on 2014-09-12 16:45 (#2SBA) I always thought btrfs was the answer (also brought to you by Sun) for the same feature-set as ZFS, but in a linuxy way.I hail all progress made on this front. I dinked around with running a failover ZFS before, and I can say it is pretty awesome stuff (as is btrfs).Competition in the filesystem field is slow going (as it should be), but fierce. That's the ways I's likes it. Re: What about her face? (Score: 1, Interesting) by Anonymous Coward on 2014-09-12 18:43 (#2SBP) btrfs doesn't have anywhere near the same featureset as ZFS. Here's a few examples: ZVOLs for virtual machines. I extensively run VMs under Linux, they all need a block device(ideal) for their disk IO performance. ZVOL is perfect, add in easy ZFS replication and I can back up virtual machines every day offsite, with absolutely no service interruption. BTRFS is ages behind in this category.The 'linuxey' syntax of btrfs is cute and all..but exactly why are my snapshots mounted, and read-write? I keep A LOT of snapshots, and having my mount tab polluted by thousands of entries not to mention users being able to write to the things? Also I found the syntax of ZFS completely intuitive. tank/movies is my movies filesystem, tank/movies@20140701 is my 2014-07-01 snapshot of movies. All commands reference snapshots as a clear subcategory of it's parent filesystem. If I -r recursively remove a snapshot, I can take out a bunch of depending snapshots wihtout screwing around with them individually.In short, ZFS naturally seems to work like I do... In my opinion BTRFS should mimic the syntax instead of going it's own way, and differentiate in the implementaiton. Re: What about her face? (Score: 1) by entropy@pipedot.org on 2014-09-12 19:14 (#2SBT) So this isn't completely abstract, here are a couple examples:BTR: btrfs subvolume snapshot /tank/subvolume /tank/snapshots/subvolume/20140721 ... 75 charactersZFS: zfs snapshot tank/subvolume@20140721 ... 36 characters.Plus you have to maintain a separate directory to manage snapshots... As snapshots grow to hundreds, or thousands your mount screen becomes a worthless jumble of crap. Fundamentally snapshots are treated as peers with filesystems in btrfs, and I believe this is absolutely incorrect. Also apparently not only are a bunch of things required to be mounted(subvolumes) BTRFS pretends it can't figure out how to mount a full volume without playing around in fstab for each things I create. In short it mounts what I don't want mounted, and doesn't mount what I do. Compression?BTR: you go into fstab, which is apparently mandatory(really?) and set compress=lzo.ZFS: zfs set compression=on tank/textfilesFor a use case involving ZVOLs(block devices) it's very simple, in ZFS it's possible:zfs create -V 20G tank/vm/pgserver0In BTR? It's impossible. You're dealing with files in a filesystem which if you've ever benchmarked is tragically underpowered. Personally I think this is the first thing BTRFS should have implemented but perhaps not as many people use VMs or iSCSI? To me those are critically important.
Re: What about her face? (Score: 1, Interesting) by Anonymous Coward on 2014-09-12 18:43 (#2SBP) btrfs doesn't have anywhere near the same featureset as ZFS. Here's a few examples: ZVOLs for virtual machines. I extensively run VMs under Linux, they all need a block device(ideal) for their disk IO performance. ZVOL is perfect, add in easy ZFS replication and I can back up virtual machines every day offsite, with absolutely no service interruption. BTRFS is ages behind in this category.The 'linuxey' syntax of btrfs is cute and all..but exactly why are my snapshots mounted, and read-write? I keep A LOT of snapshots, and having my mount tab polluted by thousands of entries not to mention users being able to write to the things? Also I found the syntax of ZFS completely intuitive. tank/movies is my movies filesystem, tank/movies@20140701 is my 2014-07-01 snapshot of movies. All commands reference snapshots as a clear subcategory of it's parent filesystem. If I -r recursively remove a snapshot, I can take out a bunch of depending snapshots wihtout screwing around with them individually.In short, ZFS naturally seems to work like I do... In my opinion BTRFS should mimic the syntax instead of going it's own way, and differentiate in the implementaiton. Re: What about her face? (Score: 1) by entropy@pipedot.org on 2014-09-12 19:14 (#2SBT) So this isn't completely abstract, here are a couple examples:BTR: btrfs subvolume snapshot /tank/subvolume /tank/snapshots/subvolume/20140721 ... 75 charactersZFS: zfs snapshot tank/subvolume@20140721 ... 36 characters.Plus you have to maintain a separate directory to manage snapshots... As snapshots grow to hundreds, or thousands your mount screen becomes a worthless jumble of crap. Fundamentally snapshots are treated as peers with filesystems in btrfs, and I believe this is absolutely incorrect. Also apparently not only are a bunch of things required to be mounted(subvolumes) BTRFS pretends it can't figure out how to mount a full volume without playing around in fstab for each things I create. In short it mounts what I don't want mounted, and doesn't mount what I do. Compression?BTR: you go into fstab, which is apparently mandatory(really?) and set compress=lzo.ZFS: zfs set compression=on tank/textfilesFor a use case involving ZVOLs(block devices) it's very simple, in ZFS it's possible:zfs create -V 20G tank/vm/pgserver0In BTR? It's impossible. You're dealing with files in a filesystem which if you've ever benchmarked is tragically underpowered. Personally I think this is the first thing BTRFS should have implemented but perhaps not as many people use VMs or iSCSI? To me those are critically important.
Re: What about her face? (Score: 1) by entropy@pipedot.org on 2014-09-12 19:14 (#2SBT) So this isn't completely abstract, here are a couple examples:BTR: btrfs subvolume snapshot /tank/subvolume /tank/snapshots/subvolume/20140721 ... 75 charactersZFS: zfs snapshot tank/subvolume@20140721 ... 36 characters.Plus you have to maintain a separate directory to manage snapshots... As snapshots grow to hundreds, or thousands your mount screen becomes a worthless jumble of crap. Fundamentally snapshots are treated as peers with filesystems in btrfs, and I believe this is absolutely incorrect. Also apparently not only are a bunch of things required to be mounted(subvolumes) BTRFS pretends it can't figure out how to mount a full volume without playing around in fstab for each things I create. In short it mounts what I don't want mounted, and doesn't mount what I do. Compression?BTR: you go into fstab, which is apparently mandatory(really?) and set compress=lzo.ZFS: zfs set compression=on tank/textfilesFor a use case involving ZVOLs(block devices) it's very simple, in ZFS it's possible:zfs create -V 20G tank/vm/pgserver0In BTR? It's impossible. You're dealing with files in a filesystem which if you've ever benchmarked is tragically underpowered. Personally I think this is the first thing BTRFS should have implemented but perhaps not as many people use VMs or iSCSI? To me those are critically important.