On Fri, Jan 9, 2015 at 4:02 PM, lee <l...@yagibdah.de> wrote: > Rich Freeman <ri...@gentoo.org> writes: > >> On Mon, Dec 29, 2014 at 8:55 AM, lee <l...@yagibdah.de> wrote: >>> >>> Just why can't you? ZFS apparently can do such things --- yet what's >>> the difference in performance of ZFS compared to hardware raid? >>> Software raid with MD makes for quite a slowdown. >>> >> >> Well, there is certainly no reason that you couldn't serialize a >> logical volume as far as design goes. It just isn't implemented (as >> far as I'm aware), though you certainly can just dd the contents of a >> logical volume. > > You can use dd to make a copy. Then what do you do with this copy? I > suppose you can't just use dd to write the copy into another volume > group and have it show up as desired. You might destroy the volume > group instead ...
You can dd from a logical volume into a file, and from a file into a logical volume. You won't destroy the volume group unless you do something dumb like trying to copy it directly onto a physical volume. Logical volumes are just block devices as far as the kernel is concerned. > >> ZFS performs far better in such situations because you're usually just >> snapshotting and not copying data at all (though ZFS DOES support >> serialization which of course requires copying data, though it can be >> done very efficiently if you're snapshotting since the filesystem can >> detect changes without having to read everything). > > How's the performance of software raid vs. hardware raid vs. ZFS raid > (which is also software raid)? Well, depends on your hardware. mdadm does pretty well though I'm sure a very good quality hardware RAID will outperform it. I would think that ZFS would outperform both for some workloads, and underperform it for others - it works very differently. ZFS doesn't have the write hole and all that, but I would think that large (many stripes) internal writes to files would work worse since ZFS has to juggle metadata and other filesystems will overwrite it in place. > >> Incidentally, other than lacking maturity btrfs has the same >> capabilities. > > IIRC, there are things that btrfs can't do and ZFS can, like sending a > FS over the network. There are things that each filesystem can do that the other cannot. That doesn't include sending a filesystem over the network. btrfs send can serialize snapshots or the differences between two snapshots. > > How about ZFS as root file system? I'd rather create a pool over all > the disks and create file systems within the pool than use something > like ext4 to get the system to boot. I doubt zfs is supported by grub and such, so you'd have to do the usual in-betweens as you're eluding to. However, I suspect it would generally work. I haven't really used zfs personally other than tinkering around a bit in a VM. > > And how do I convert a system installed on an ext4 FS (on a hardware > raid-1) to ZFS? I can plug in another two disks, create a ZFS pool from > them, make file systems (like for /tmp, /var, /usr ...) and copy > everything over. But how do I make it bootable? > I'm pretty sure you'd need an initramfs and a boot partition that is readable by the bootloader. You can skip that with btrfs, but not with zfs. GRUB is FSF so I doubt they'll be doing anything about zfs anytime soon. Otherwise, you'll have to copy everything over - btrfs can do in-place ext4 conversion, but not zfs. -- Rich
