Thanks, It works, but it only spins up the first pool device, though if I don't find a better way I already tested and if I repeat with nameofpool2, nameofpool3, etc it will spin up the others.
By default metadata uses the DUP profile to be redundant, but with memory corruption both can be corrupt, if it's using dup a scrub (with repair enable) will correct it, if it can't be fixed best to reformat.
You can do that, first move that share to the array, then to the new pool, mover can't move from pool to pool, files can't be in use, i.e., stop the docker service first.
Looks more like a similar error to the MX 500 SSD, should be fine, if you keep getting that do the same I do for all my MX500, stop monitoring that attribute for that device.
Since I'm now using a pool instead of an array for the the drives I want to spin up, any chance you know how to change the script to spin up all devices in a pool instead?
Some users are having issues editing smart-one.cfg, I'm also having trouble with both my updated servers, curiously it works on my test server, what you can do for now is to manually edit smart-one.cfg like so:
[TOSHIBA-RD400_664S107XTPGV]
hotTemp="65"
maxTemp="70"
[WDS500G3X0C-00SJG0_19295E805489]
hotTemp="65"
maxTemp="70"
You can copy/paste the device ID after clicking on the device:
loop2 is the docker image, and it's corrupt so it needs to be recreated, because of the log spam can't see the problem with libvirt, but most likely it's because cache is completely full, free up some space, reboot to clear the logs and if still issues post new diags.
ECC would be better, there there some doubts if it actually works with Ryzen, in any case there are some stability issues that until fixed will cause problens.
Like mentioned, and unlike read time corruption, write time corruption indicates a memory (or other hardware problem).
https://btrfs.wiki.kernel.org/index.php/Tree-checker
Cache filesystem is corrupt, and this error:
Mar 18 06:47:21 thelibrary kernel: BTRFS error (device nvme1n1p1): block=1766866944 write time tree block corruption detected
usually means bad RAM, start by running memtest (could also be caused by overclocked RAM, if you ran it like that before), after finding the issue you should backup and reformat cache.
Where the diags grabbed after the i/o error? They appear to be just after array start, and don't see anything logged, if yes post new ones.
Note that I'm going offline in a few minutes, will check back tomorrow morning, I usually only check the forum from around 7:30AM to around 7:30PM UTC time.