[Discuss] Debian 11 -> 12

markw at mohawksoft.com markw at mohawksoft.com
Thu May 30 12:47:43 EDT 2024


Sorry for the top-post

I have been using ZFS professionally and personally for over 10 years. I
have also been an internal maintainer for our linux variant's
modifications for our company's product. ZFS is not perfect. There are a
lot of things I don't like about it. There are also a lot of things I
don't like about LVM and the whole device manager stuff.

All that said, OMG ZFS is absolutely the way to go for any new deployment
unless a bare bones hardware performance is required. Here's what ZFS
gives you:

Data Integrity, all blocks are check-summed and you know and can find
corrupted data (and fix it). You can't on any standard file system on
linux.

You can create proper linux devices from your disk pool. (zvols)

You can create file system "objects" in a pool and mount them anywhere. My
/home and my /devel directories are ZFS "file systems"

Light weight snapshots. On LVM, snapshots are expensive and if you have
more than one snapshot, they are even more expensive. ZFS snapshots don't
cost anything.

Clones, you can take any snapshot and make a whole new read-writable file
system or zvol without copying the data. If your huge database is in a ZFS
file system, you snapshot it, clone it, and have two independent copies of
the database, almost instantly. Only the differences will be store
separately.

Backups are simple, "zfs send" can be configured to send only the
difference between two snapshots to a remote zfs system.

RAID, ZFS has built in raid.

Say what you want, maybe it is a little more complex than LVM, but not
really all that much. LVM PV is the same as a disk assigned to ZFS. LVM VG
is the same as a ZFS pool. An LVM logical volume is equivalent to a ZFS
zvol. You have more with ZFS, your "pool" (like an LVM volume group) is
actually a usable file system.



> On Wed, May 22, 2024 at 03:07:27PM -0400, Steve Litt wrote:
>> Rich Pieri said on Mon, 20 May 2024 14:13:10 -0400
>>
>> >On Sun, 19 May 2024 17:21:48 -0700
>> >Kent Borg <kentborg at borg.org> wrote:
>> >
>> >> I think that is my essence of my complaint. Too complicated for
>> >> someone who isn't studied in it.
>> >
>> >This is a fair complaint. ZFS requires a mental and a temporal
>> >investment. If you're not able to make that investment then stick with
>> >ext4 on LVM.
>>
>> Unless you're encrypting the root partition, I can't think of any use
>> of LVM that can't be done other ways. I view LVM as yet another layer
>> of abstraction and yet another way to lose your data.
>
> I'm with Rich on this, for whatever that's worth...  LVM is pretty
> ancient by now and has had lots of practical "testing" (by distros
> using it by default for years now).  It makes managing your disk space
> so much easier.  In systems that support hot-plugging disks you can do
> most maintenance (replacing disks, growing logical partitions, etc.)
> with no down time.
>
> I have to admit to a bias here though... I came at this already having
> experience in doing this professionally in the 90's with clusters of
> HP-UX servers.  The Linux LVM implementation is modeled on HP's so I
> was already familiar with it when Linux got it.  But honestly, the
> interface isn't that hard to learn, and it's been solid for a long
> time...
>
> Side note:  I only just now noticed that the posting address on my
> reply includes driftwood... does discuss at blu.org no longer work?  I'll
> have to update my aliases.. =8^)
>
> --
> Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
> -=-=-=-=-
> This message is posted from an invalid address.  Replying to it will
> result in
> undeliverable mail due to spam prevention.  Sorry for the inconvenience.
>
> _______________________________________________
> Discuss mailing list
> Discuss at driftwood.blu.org
> https://driftwood.blu.org/mailman/listinfo/discuss
>




More information about the Discuss mailing list