March 18, 20242 yr I recently replaced disk 2 in my array after it had been giving me problems for several months. The new disk has been in about 2 weeks now and it's already giving me problems. I did a 'Check Filesystem Status' and I'm seeing lots of these messages: Metadata corruption detected at 0x438a03, xfs_inode block 0x87a0/0x4000 bad CRC for inode 34720 bad magic number 0x86c5 on inode 34720 bad version number 0x69 on inode 34720 inode identifier 8206885521470191829 mismatch on inode 34720 imap claims inode 34720 is present, but inode cluster is sparse, would correct imap I'm not sure anymore what it could be. Is it possible the disk controller is bad?
March 18, 20242 yr Community Expert Nothing suggesting a disk problem so far, only a filesystem issue, probably as a result of the previously failed disk, check filesystem on disk2, run it without -n, and if it asks for -L use it.
March 18, 20242 yr Author Ok, I'll give that a shot. Any idea what would cause the filesytem to have this issue? because this is the same issue I had with the old drive
March 18, 20242 yr Community Expert 23 minutes ago, jsmid6 said: this is the same issue I had with the old drive 33 minutes ago, JorgeB said: probably as a result of the previously failed disk The replacement has the rebuilt filesystem from the original
March 18, 20242 yr Author 5 minutes ago, trurl said: The replacement has the rebuilt filesystem from the original In that case, is it possible to reset the filesystem?
March 18, 20242 yr Community Expert 42 minutes ago, JorgeB said: check filesystem on disk2, run it without -n, and if it asks for -L use it.
March 18, 20242 yr Author 4 hours ago, trurl said: I did that and it seems to have resolved the issue for now, but considering the issues I've had lately, the filesystem will likely go bad again in a few weeks. Is there anything that could be causing this?
March 19, 20242 yr Author After the file system repair I ran a parity check and that has just finished, so here's the new diagnostics. jmedia-diagnostics-20240319-1028.zip
March 20, 20242 yr Community Expert Unrelated to the corruption Your "app" share where you have your docker.img and default appdata location configured, has some files on disk3. Ideally, these would all be on fast pool such as cache, with nothing on the array, so Dockers can perform better, and so array disks can spin down since these files are always open. Instead of reconfiguring things so Mover will move those for you, it's probably simpler to clean this up yourself with Dynamix File Manager plugin. Nothing can move or delete open files so you will have to disable Docker in Settings.
March 22, 20242 yr Author I've used that tool to move all of those files and clean up some old directories as well, I had some old data from dockers that aren't used anymore. The tool worked perfectly to move everything
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.