Prbecker Posted March 26 Share Posted March 26 Hi all -- I noticed that pihole wasn't blocking ad's this morning and I was unable to connect to the docker instance and some other docker containers so I rebooted my box. When it came back up, I was able to start the array but noticed that my cache disk was unmountable. I'm hoping the disk isn't totally dead or corrupt. Please see attached diags. Thank you! tower-diagnostics-20240326-1128.zip Quote Link to comment
Solution JorgeB Posted March 26 Solution Share Posted March 26 Check filesystem on cache, run it without -n and if it asks for -L use it. Quote Link to comment
Prbecker Posted March 26 Author Share Posted March 26 Thank you, reading through the section now. The mover started running(?) so I'll start the procedure when its complete. Quote Link to comment
trurl Posted March 26 Share Posted March 26 Since the only pool you have is unmountable, there is nothing mover can do. Might as well stop it. Disable Docker and VM Manager in Settings until you get cache working again. They have already created new files on the array that you will need to clean up later. Why do you have docker.img set to 100G? Quote Link to comment
Prbecker Posted March 26 Author Share Posted March 26 32 minutes ago, JorgeB said: Check filesystem on cache, run it without -n and if it asks for -L use it. I did need to run it with the -L switch. It ran for a few minutes and the cache drive was able to be mounted. Looks good, thanks again! Quote Link to comment
Prbecker Posted March 26 Author Share Posted March 26 15 minutes ago, trurl said: Since the only pool you have is unmountable, there is nothing mover can do. Might as well stop it That's what I figured too. By the time I came back to the console, the mover had finished. 16 minutes ago, trurl said: Why do you have docker.img set to 100G? At one point I had a lot of containers and honestly I didn't know what I was doing when trying to troubleshoot a problem a few years ago. After finding the resolution to whatever that problem was I just never resized it. Should I modify it? Quote Link to comment
Prbecker Posted March 26 Author Share Posted March 26 2 minutes ago, trurl said: Post new diagnostics. tower-diagnostics-20240326-1241.zip Output from the Check Filesystem Status: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata agi_freecount 840, counted 839 in ag 2 sb_icount 1714048, counted 1750528 sb_ifree 4102, counted 13564 sb_fdblocks 366196900, counted 369685270 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 correcting imap correcting imap correcting imap correcting imap correcting imap correcting imap correcting imap correcting imap - agno = 2 correcting imap correcting imap correcting imap correcting imap correcting imap correcting imap bad CRC for inode 3031665751 bad CRC for inode 3031665751, will rewrite cleared inode 3031665751 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... bad hash table for directory inode 3038392851 (no leaf entry): rebuilding rebuilding directory inode 3038392851 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (78:1390421) is ahead of log (1:2). Format log to cycle 81. done Quote Link to comment
trurl Posted March 26 Share Posted March 26 Doesn't look like anything was lost+found so that's good. Also doesn't look like you did this 2 hours ago, trurl said: Disable Docker and VM Manager in Settings until you get cache working again. They have already created new files on the array that you will need to clean up later. Quote Link to comment
Prbecker Posted March 26 Author Share Posted March 26 22 minutes ago, trurl said: Also doesn't look like you did this Agh, you are right, I did not do this step. I missed this portion of your comment when following through on JorgeB's comment. Maybe this is why I can't connect to sonarr? I'm able to connect to/interact with the rest of my containers except for sonarr. It just displays the "cannot connect" page in the browser. I tried deleting the container and re-adding it from the template then deleting the container + image then re-adding it from the template and still no go. It's up, or so it says, but I can't seem to make a connection to it. I am able to click and launch the console. If I grab linuxserver's version of sonarr I'm able to use it but I'd rather try to get this one working again. Quote Link to comment
trurl Posted March 26 Share Posted March 26 6 hours ago, trurl said: Disable Docker and VM Manager in Settings until you get cache working again. They have already created new files on the array that you will need to clean up later. Why do you have docker.img set to 100G? Post new diagnostics after Disabling Docker and VM Manager Quote Link to comment
Prbecker Posted March 27 Author Share Posted March 27 21 hours ago, trurl said: Post new diagnostics after Disabling Docker and VM Manager Sorry for the delay! Attached is the diag after disabling both. Thank you tower-diagnostics-20240327-1641.zip Quote Link to comment
trurl Posted March 27 Share Posted March 27 appdata, domains, and system shares have files on the array. In fact, you have domains configured to be moved to the array. Ideally, appdata, domains, and system shares would have all files on fast pool such as cache with nothing on the array, so Dockers/VMs will perform better and so array disks can spin down since these files are always open. Mover won't replace files, so if something exists on both cache and the array you will have to decide which to keep. Dynamix File Manager plugin will let you work with folders and files directly on the server and can help you figure that out. And, from your previous diagnostics, it looks like default 20G docker.img would be more than enough. After you get those shares moved and configured correctly, you can delete, recreate at 20G, reinstall containers. https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file https://docs.unraid.net/unraid-os/manual/docker-management/#re-installing-docker-applications Quote Link to comment
Prbecker Posted March 27 Author Share Posted March 27 Thank you so much for reviewing my config and for the suggestions. I am definitely going to take your suggestions and implement them! Quote Link to comment
Recommended Posts
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.