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/09/23 23:33] (current) – oemb1905
Line 61: Line 61:
   mkfs.btrfs -f -d raid10 -m raid1 --checksum=xxhash --nodesize=32k /dev/mapper/ssd1 /dev/mapper/ssd2 /dev/mapper/ssd3 /dev/mapper/ssd4 /dev/mapper/ssd5 /dev/mapper/ssd6 /dev/mapper/ssd7 /dev/mapper/ssd8   mkfs.btrfs -f -d raid10 -m raid1 --checksum=xxhash --nodesize=32k /dev/mapper/ssd1 /dev/mapper/ssd2 /dev/mapper/ssd3 /dev/mapper/ssd4 /dev/mapper/ssd5 /dev/mapper/ssd6 /dev/mapper/ssd7 /dev/mapper/ssd8
   mkfs.btrfs -f -d raid10 -m raid1 --checksum=xxhash --nodesize=32k /dev/mapper/hdd1 /dev/mapper/hdd2 /dev/mapper/hdd3 /dev/mapper/hdd4   mkfs.btrfs -f -d raid10 -m raid1 --checksum=xxhash --nodesize=32k /dev/mapper/hdd1 /dev/mapper/hdd2 /dev/mapper/hdd3 /dev/mapper/hdd4
-  mount -o compress-force=zstd:3,noatime,autodefrag,space_cache=v2,discard=async,commit=120 /dev/mapper/ssd1 /mnt/vm +  mount -o compress-force=zstd:3,noatime,noautodefrag,space_cache=v2,discard=async,commit=120 /dev/mapper/ssd1 /mnt/vm 
-  mount -o compress=zstd:3,noatime,autodefrag,space_cache=v2,discard=async,commit=120 /dev/mapper/hdd1 /mnt/wh+  mount -o compress=zstd:3,noatime,noautodefrag,space_cache=v2,discard=async,commit=120 /dev/mapper/hdd1 /mnt/wh
   btrfs filesystem show /mnt/vm   btrfs filesystem show /mnt/vm
   btrfs filesystem show /mnt/wh   btrfs filesystem show /mnt/wh
Line 91: Line 91:
   cryptsetup luksOpen /dev/disk/by-id/scsi-35000c500cb1689e3 hdd4 --key-file /home/user/.unlock/wh.key   cryptsetup luksOpen /dev/disk/by-id/scsi-35000c500cb1689e3 hdd4 --key-file /home/user/.unlock/wh.key
   #mount the btrfs r10 pool for vm   #mount the btrfs r10 pool for vm
-  mount -o compress-force=zstd:3,noatime,autodefrag,space_cache=v2,discard=async,commit=120 /dev/mapper/ssd1 /mnt/vm+  mount -o compress-force=zstd:3,noatime,noautodefrag,space_cache=v2,discard=async,commit=120 /dev/mapper/ssd1 /mnt/vm
   #mount the btrfs r10 pool for wh   #mount the btrfs r10 pool for wh
-  mount -o compress=zstd:3,noatime,autodefrag,space_cache=v2,discard=async,commit=120 /dev/mapper/hdd1 /mnt/wh+  mount -o compress=zstd:3,noatime,noautodefrag,space_cache=v2,discard=async,commit=120 /dev/mapper/hdd1 /mnt/wh
      
 This script is designed to be run manually post reboot. In order, you reboot, log in to the admin user via ssh, unlock the crypt key directory with ''screen'' and then ''su - sexa'' (detach with ctrl-a-d). After detaching, simply run the mount the script ''/bin/bash /usr/local/bin/btrfs-mount-datasets.sh''. In the weeks ahead, it is essential to regularly scrub the pool. For that, put the following commands on a cronjob: This script is designed to be run manually post reboot. In order, you reboot, log in to the admin user via ssh, unlock the crypt key directory with ''screen'' and then ''su - sexa'' (detach with ctrl-a-d). After detaching, simply run the mount the script ''/bin/bash /usr/local/bin/btrfs-mount-datasets.sh''. In the weeks ahead, it is essential to regularly scrub the pool. For that, put the following commands on a cronjob:
Line 107: Line 107:
 In addition to scrubbing, I compiled a slew of commands to assess pool health more granularly. I put this script on a cronjob which runs and sends me a statistics report every hour: In addition to scrubbing, I compiled a slew of commands to assess pool health more granularly. I put this script on a cronjob which runs and sends me a statistics report every hour:
  
-<code bash>+<code sh>
 #!/bin/bash #!/bin/bash
 DATE=`date +"%Y%m%d-%H:%M:%S"` DATE=`date +"%Y%m%d-%H:%M:%S"`
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> 
 + 
 +I changed default to ''noautodefrag'' to stop metadata from overfilling. 
 + 
 + --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/09/23 23:32//
computing/btrfsreminders.1770566773.txt.gz · Last modified: by oemb1905