Not really sure what’s happening and kinda stumped. I have one pool (raidz3) that has an encrypted dataset. Not sure what the reason is but every time I load the key and unlock it the machine just restarts.
Things I’ve tried:
Rollbacked from 24.04.x.x to 23.10.2
Reverted settings I changed (ssl certs)
Tried loading the key from the shell
turned off dedupe
memtest
The pool is around 47Tib and zpool & dataset is 43Tib, the server has 128 GB of RAM. Not sure but it might be running out of RAM when it’s trying to unlock it. I’ve always been able to unlock it before so not sure what would make it do it now.
Disabling deduplication doesn’t change the existing data in place, including the memory required to load the deduplication tables.
I understand you have a single RAIDZ3 pool that’s ~47TiB - are there other datasets that mount fine, but when attempting to unlock the ~43TiB encrypted dataset, it restarts?
Is dedup set on the pool, all datasets, some datasets?
Sadly, you might be dealing with what @HoneyBadger explained earlier.
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD DEDUP ENCRYPTION ENCROOT KEYFORMAT
PoolName/datasetName/VM2zvol 6.78T 43.3T 0B 41.9T 1.39T 0B off aes-256-gcm PoolName/datasetName passphrase
I’m assuming this VM2zvol is where you had originally created it with deduplication enabled, wrote over 43 TiB worth of data, and now as suggested, your 128 GiB of RAM isn’t enough to hold the DDT in memory.
But that’s where I have to defer to others. I’m not entirely sure what the RAM requirements are for dedup.
I do believe that smaller “recordsizes” are more taxing, since it takes more blocks (and hence more entries in the table) for the same amount of total data.
What is the recordsize for VM2zvol? (Assuming you didn’t change it.)
zfs get recordsize,volblocksize PoolName/datasetName/VM2zvol
I think it may very well be that upon trying to mount the volume, there isn’t enough free RAM to hold all of those entries in the DDT.
To “un-dedup” the volume, you’d have to be able to safely mount, and then copy everything over again to a dataset/zvol with the dedup property disabled.
But you can’t even get that far, since unlocking the 44 TiB volume automatically attempts to mount it. Even if you don’t automatically mount it upon unlocking… you’d still need to mount it eventually.
But from what you said, it sounds like you have a very good, up-to-date backup of this specific data? (Is it also using deduplication?)