consumer tier ROG STRIX X370F-GAMING. Which much to my surprise supports TSME, Bifurcation, pcie ari/10b, configuring iommu, unbuffered ecc and sr-iov etc. Its packed full of stuff ive hardly began to touch in the uefi
The AMD CBS section in 10 menus deep man. Like idk even how to begin learning it
I donât think thatâs correct? A dedicated, fast SLOG will improve sync write performance. There is no difference in resiliency. ZIL provides resiliency whether its on a SLOG or not. I suppose a faster SLOG provides better resiliency in the sense that it is lower latency so the data becomes persistent sooner, but thatâs splitting hairs.
Its sync=always that increases it a bit. Provides better PLP and system crash protection but its only WORTH turning on if you have a fast enough slog that you wouldnât be lol⌠slogging it out on your gaint spinning rust bunker of a hard drive array
Yeah essentially what I was communicating earlier. Im adding slog so I can turn it on. The kernel panics have made me realize man I need to make this crash resilient. Im tired of recovering Nextcloud DBs because of the odd system crash now and then
Yeah, you want sync for database and virtualization/container workloads. From what I understand that is the typical use case for sync=always. To @Dynamic_Gravityâs point though, I think sync=standard should respect applications when they explicitly ask for sync. Thatâs a bit over my head though.
yeah Im just sorting through my docker and vm stuff in terms of volumes and getting ready to make 8KiB dataset for them. Then when the stuff is here I will make it sync always
Sync standard will respect application settings. I donât respect application settings LOL
Question for yall smarties @Dynamic_Gravity@oO.o if I delete data from zfs and its not reflecting in zfs list and refer is the actual size of the data where as the used in the dataset is not even close does that mean data is getting tied up in the snapshots?
If it is what is the recommended safe prune schedule of snapshots? I seek to be safe but efficient.
Iâd start deleting oldest to newest until you open up the space you need. If unsure about the data, then look in the snapshots. Itâs really hard to say without knowing the history of the pool and the data.
A while back, I was migrating data and found a snapshot I had taken during a previous migration. It was years old, redundant and completely unnecessary by that point. I deleted it and opened 30TB. Snapshots are amazing for data retention but you do have to keep tabs on them.
I deleted every snapshot after verifying a clean state on stuff then took one and named it clean. It freed up 4 TB of data
Now im going to work on a better snapshot policy that auto grooms
I dont need snapshots from a year ago. Ill do hourly and keep 24 for safety reasons. And ill do a weekly and delete the prior week and ill do a monthly and keep 1
Also im completely shocked at the performance benefit of lz4 over no compression. No compression was a fatal mistake. Ive added about 35% the speed (opportunistically) and about 10% less storage usage on the new datasets
Whos got some new SLOG. I do. Mirrored it. Off to the races
root@odin:/mnt/OnePoint21GigaWatts# zfs get sync
NAME PROPERTY VALUE SOURCE
OnePoint21GigaWatts sync always local
OnePoint21GigaWatts/books sync always inherited from OnePoint21GigaWatts
OnePoint21GigaWatts/databases sync always local
OnePoint21GigaWatts/datahorde sync always local
OnePoint21GigaWatts/docker sync always local
OnePoint21GigaWatts/minecraft sync always local
OnePoint21GigaWatts/minecraft-servers sync always local
OnePoint21GigaWatts/multimedia sync always local
OnePoint21GigaWatts/music sync always inherited from OnePoint21GigaWatts
OnePoint21GigaWatts/vault sync always inherited from OnePoint21GigaWatts
OnePoint21GigaWatts/virtualmachines sync always inherited from OnePoint21GigaWatts
root@odin:/mnt/OnePoint21GigaWatts# zpool status
pool: OnePoint21GigaWatts
state: ONLINE
scan: scrub repaired 0B in 13:17:07 with 0 errors on Sun Jul 9 13:41:10 2023
config:
NAME STATE READ WRITE CKSUM
OnePoint21GigaWatts ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
wwn-0x5000039a4ba00bb8 ONLINE 0 0 0
wwn-0x5000039a5b880197 ONLINE 0 0 0
wwn-0x5000039a4c280b93 ONLINE 0 0 0
wwn-0x5000039a4c400ae7 ONLINE 0 0 0
wwn-0x5000039a4c700b01 ONLINE 0 0 0
wwn-0x5000039a5c2801d2 ONLINE 0 0 0
logs
mirror-1 ONLINE 0 0 0
wwn-0x50015178f3586652 ONLINE 0 0 0
wwn-0x50015178f3594112 ONLINE 0 0 0
cache
nvme-Samsung_SSD_970_EVO_Plus_250GB_S59BNM0R703421X ONLINE 0 0 0
errors: No known data errors
root@odin:/mnt/OnePoint21GigaWatts#