User Tools

Site Tools


computing:btrfsreminders

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
computing:btrfsreminders [2026/02/08 16:06] oemb1905computing:btrfsreminders [2026/04/04 19:48] (current) – lo oemb1905
Line 274: Line 274:
 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//
computing/btrfsreminders.1770566773.txt.gz · Last modified: by oemb1905