Rich Freeman <ri...@gentoo.org> writes: > On Sat, Jan 10, 2015 at 1:22 PM, lee <l...@yagibdah.de> wrote: >> Rich Freeman <ri...@gentoo.org> writes: >>> >>> 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. >> >> You mean I need to create a LV (of the same size) and then use dd to >> write the backup into it? That doesn't seem like a safe method. > > Doing backups with dd isn't terribly practical, but it is completely > safe if done correctly. The LV would need to be the same size or > larger, or else your filesystem will be truncated.
Yes, my impression is that it isn't very practical or a good method, and I find it strange that LVM is still lacking some major features. >>>> 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. >> >> That would be a very big disadvantage. When you use zfs, it doesn't >> really make sense to have extra partitions or drives; you just want to >> create a pool from all drives and use that. Even if you accept a boot >> partition, that partition must be on a raid volume, so you either have >> to dedicate at least two disks to it, or you're employing software raid >> for a very small partition and cannot use the whole device for ZFS as >> recommended. That just sucks. > > Just create a small boot partition and give the rest to zfs. A > partition is a block device, just like a disk. ZFS doesn't care if it > is managing the entire disk or just a partition. ZFS does care: You cannot export ZFS pools residing on partitions, and apparently ZFS cannot use the disk cache as efficiently when it uses partitions. Caching in memory is also less efficient because another file system has its own cache. On top of that, you have the overhead of software raid for that small partition unless you can dedicate hardware-raided disks for /boot. > This sort of thing was very common before grub2 started supporting > more filesystems. That doesn't mean it's a good setup. I'm finding it totally undesirable. Having a separate /boot partition has always been a crutch. >> Well, I don't want to use btrfs (yet). The raid capabilities of brtfs >> are probably one of its most unstable features. They are derived from >> mdraid: Can they compete with ZFS both in performance and, more >> important, reliability? >> > > > Btrfs raid1 is about as stable as btrfs without raid. I can't say > whether any code from mdraid was borrowed but btrfs raid works > completely differently and has about as much in common with mdraid as > zfs does. Hm, I might have misunderstood an article I've read. > I can't speak for zfs performance, but btrfs performance isn't all > that great right now - I don't think there is any theoretical reason > why it couldn't be as good as zfs one day, but it isn't today. Give it another 10 years, and btrfs might be the default choice. > Btrfs is certainly far less reliable than zfs on solaris - zfs on > linux has less long-term history of any kind but most seem to think it > works reasonably well. It seems that ZFS does work (I can't say anything about its reliability yet), and it provides a solution unlike any other FS. Btrfs doesn't fully work yet, see [1]. [1]: https://btrfs.wiki.kernel.org/index.php/RAID56 >> With ZFS at hand, btrfs seems pretty obsolete. > > You do realize that btrfs was created when ZFS was already at hand, > right? I don't think that ZFS will be likely to make btrfs obsolete > unless it adopts more dynamic desktop-oriented features (like being > able to modify a vdev), and is relicensed to something GPL-compatible. > Unless those happen, it is unlikely that btrfs is going to go away, > unless it is replaced by something different. Let's say it seems /currently/ obsolete. It's not fully working yet, reliability is very questionable, and it's not as easy to handle as ZFS. By the time btrfs has matured to the point where it isn't obsolete anymore, chances are that there will be something else which replaces it. Solutions are needed /now/, not in about 10 years when btrfs might be ready. -- Again we must be afraid of speaking of daemons for fear that daemons might swallow us. Finally, this fear has become reasonable.
