| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| computing:btrfsreminders [2026/02/08 16:06] – oemb1905 | computing:btrfsreminders [2026/04/04 19:48] (current) – lo oemb1905 |
|---|
| In lay terms, these reports confirm that read speed is 5,520 MB/s, or 5.5 GB/s, and write speed is 1,603 MB/s, or 1.6 GB/s. This is a 4x improvement for reads and 2x improvement for writes compared to zfs. For whatever reason, zfs was not benefitting from the parallelization. It's possible that I could get zfs to perform better with tinkering, but why? Every major upgrade I have to re-compile it with dkms against the new kernel headers, which takes forever. Additionally, zfs gobbles up my RAM (BTRFS is using 40% comparitively). Lastly, I am not a fan of zfs-send / zfs-receive and/or its snapshotting tools ... I use rsync and rsnapshot for my needs and have no need for those tools. So, although it might be possible to fix the old zfs setup, there's no value in doing so. Natively supported filesystems work out of the box and don't require janky re-compilation with dkms. Also, these benchmarks above speak for themselves! | In lay terms, these reports confirm that read speed is 5,520 MB/s, or 5.5 GB/s, and write speed is 1,603 MB/s, or 1.6 GB/s. This is a 4x improvement for reads and 2x improvement for writes compared to zfs. For whatever reason, zfs was not benefitting from the parallelization. It's possible that I could get zfs to perform better with tinkering, but why? Every major upgrade I have to re-compile it with dkms against the new kernel headers, which takes forever. Additionally, zfs gobbles up my RAM (BTRFS is using 40% comparitively). Lastly, I am not a fan of zfs-send / zfs-receive and/or its snapshotting tools ... I use rsync and rsnapshot for my needs and have no need for those tools. So, although it might be possible to fix the old zfs setup, there's no value in doing so. Natively supported filesystems work out of the box and don't require janky re-compilation with dkms. Also, these benchmarks above speak for themselves! |
| |
| --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/02/08 15:49// | Simple version |
| | |
| | <code> |
| | sudo lsblk -d -o NAME,SIZE,TYPE,MODEL,TRAN,ROTA,VENDOR,SERIAL |
| | df -h |
| | ls -lah /dev/disk/by-id/ |
| | sudo mkdir -p /mnt/storage |
| | sudo cryptsetup luksFormat /dev/disk/by-id/xxx-1x7000000000000023 --key-file /home/user/.unlock/storage.key --type luks2 --cipher aes-xts-plain64 --key-size 512 --pbkdf argon2id --pbkdf-memory 4194304 --pbkdf-parallel 4 --iter-time 4000 --sector-size 4096 --use-random |
| | sudo cryptsetup luksOpen /dev/disk/by-id/xxx-1x7000000000000023 storage --key-file /home/user/.unlock/storage.key |
| | sudo mkfs.btrfs -f -L storage /dev/mapper/storage #single volume |
| | sudo mkfs.btrfs -f -d raid10 -m raid1 --checksum=xxhash --nodesize=32k /dev/mapper/hdd1 /dev/mapper/hdd2 /dev/mapper/hdd3 /dev/mapper/hdd4 #JBOD in R10 equivalent |
| | sudo mount -o compress=zstd:1,noatime,space_cache=v2,discard=async,commit=120,nodatacow /dev/mapper/storage /mnt/storage |
| | cat << 'EOF' | sudo tee /usr/local/bin/btrfs-mount-volumes.sh > /dev/null |
| | #!/bin/bash |
| | cryptsetup luksOpen /dev/disk/by-id/xxx-1x7000000000000023 storage --key-file /home/user/.unlock/storage.key |
| | mount -o compress=zstd:1,noatime,space_cache=v2,discard=async,commit=120,nodatacow /dev/mapper/storage /mnt/storage |
| | EOF |
| | chmod 750 /usr/local/bin/btrfs-mount-volumes.sh |
| | </code> |
| | |
| | --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/04/04 19:39// |