[kwlug-disc] Old Man Yells at ZFS (was: Docker Host Appliance)

[L.D. Paniak]

On 2023-01-17 17:16, William Park via kwlug-disc wrote:
>
>
> On 2023-01-17 01:19, Chris Irwin via kwlug-disc wrote:
>>>> if you wanted. WIth BTRFS if I had four disks and one failed (and I 
>>>> have enough free space), I could rebalance the array to use one fewer
>>>> drive and recover a measure of redundancy while waiting for 
>>>> stock/sale/shipping/payday.
>>>
>>> Sounds like a handy feature.
>>>
>>> But again, with btrfs RAID5/6 *should not be used in production*.
>>
>> Agreed, never use the parity modes in BTRFS.
> > ...
>
> Yeah.  For those who aren't aware, BTRFS interpret RAID1 as "copies on 
> 2 different disks".  So, it can do RAID1 across 3 disks, eg. disk A & 
> B, disk B & C, and disk A & C.
>

Sorry, if you have three or more disks or they are bigger than 10TB, ZFS 
is the only game in town.

BTRFS does fun things but only for RAID1/10.  For big drives, you will 
want three (or more) redundant drives to have a fair chance of not 
catching a bad read while rebuilding from a drive failure.

XFS/mdraid is OK if you do not care about your data.  Only ZFS is going 
to reasonably check (and repair) data consistency problems.

If you want to expand your ZFS pool, leave a few drive bays empty and 
add a new vdev when budget/capacity allow/require.  You might want to 
touch a few files to rebalance, but pool autoexpansion is plenty fun.  
You can also autoexpand by replacing drives in the existing array with 
larger ones.

At the end of the day, do people really add drives to their storage 
arrays all the time?
It always seemed like a feature that sounded great but probably does not 
get used that often.
I am running the same ZFS array I built several years ago (with a couple 
of failed drive replacements).

Finally, nothing beats LXD/LXC container snapshotting on ZFS for 
convenience and security!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xC9C450AD41E27BAA.asc
Type: application/pgp-keys
Size: 1696 bytes
Desc: OpenPGP public key
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20230117/a3383238/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20230117/a3383238/attachment.sig>