Re: [gentoo-user] installing Gentoo in a xen VM

[Rich Freeman]

On Sun, Jan 11, 2015 at 8:14 AM, lee <lee@××××××××.de> wrote:
> Rich Freeman <rich0@g.o> writes:
>>
>> 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.

Generally you do backup at the filesystem layer, not at the volume
management layer.  LVM just manages a big array of disk blocks.  It
has no concept of files.

>>
>> 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.

Cite?  This seems unlikely.

> Caching in memory is also less efficient because another
> file system has its own cache.

There is no other filesystem.  ZFS is running on bare metal.  It is
just pointing to a partition on a drive (an array of blocks) instead
of the whole drive (an array of blocks).  The kernel does not cache
partitions differently from drives.

> On top of that, you have the overhead of
> software raid for that small partition unless you can dedicate
> hardware-raided disks for /boot.

Just how often are you reading/writing from your boot partition?  You
only read from it at boot time, and you only write to it when you
update your kernel/etc.  There is no requirement for it to be raided
in any case, though if you have multiple disks that wouldn't hurt.

>
>> 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.

Better not buy an EFI motherboard.  :)

>
>>> 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.

You seem to have an interesting definition of "obsolete" - something
which holds potential promise for the future is better described as
"experimental."

>
> Solutions are needed /now/, not in about 10 years when btrfs might be
> ready.
>

Well, feel free to create one.  Nobody is stopping anybody from using
zfs, but unless it is either relicensed by Oracle or the
kernel/grub/etc is relicensed by everybody else you're unlikely to see
it become a mainstream solution.  That seems to be the biggest barrier
to adoption, though it would be nice for small installations if vdevs
were more dynamic.

By all means use it if that is your preference.  A license may seem
like a small thing, but entire desktop environments have been built as
a result of them.  When a mainstream linux distro can't put ZFS
support on their installation CD due to licensing compatibility it
makes it pretty impractical to use it for your default filesystem.

I'd love to see the bugs worked out of btrfs faster, but for what I've
paid for it so far I'd say I'm getting good value for my $0.  It is
FOSS - it gets done when those contributing to it (whether paid or
not) are done.  The ones who are paying for it get to decide for
themselves if it meets their needs, which could be quite different
from yours.

I'd actually be interested in a comparison of the underlying btrfs vs
zfs designs.  I'm not talking about implementation (bugs/etc), but the
fundamental designs.  What features are possible to add to one which
are impossible to add to the other, what performance limitations will
the one always suffer in comparison to the other, etc?  All the
comparisons I've seen just compare the implementations, which is
useful if you're trying to decide what to install /right now/ but less
so if you're trying to understand the likely future of either.

-- 
Rich