sevenz Posted March 9, 2021 Share Posted March 9, 2021 (edited) Yep as other people who have similar issues I dare not touch until I know what I need to do. mynas-diagnostics-20210309-1800.zip After a restart this is what happened to sdb I tried changing the cable but still the same. I wonder how should I proceed from here? Do I need to xfs_repair -v /dev/ something? It's been few days because I didnt have the time (work) to fix this immediately. I wonder what would happen to my data? Anyone can fill me here? Thanks! Edited March 9, 2021 by sevenz Quote Link to comment
JorgeB Posted March 9, 2021 Share Posted March 9, 2021 https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui Quote Link to comment
sevenz Posted March 9, 2021 Author Share Posted March 9, 2021 (edited) Quote Phase 1 - find and verify superblock... - reporting progress in intervals of 15 minutes - block cache size set to 1859624 entries Phase 2 - using internal log - zero log... zero_log: head block 452803 tail block 451456 ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - 19:14:06: zeroing log - 59617 of 59617 blocks done - scan filesystem freespace and inode maps... agi_freecount 11571, counted 11570 in ag 31 agi unlinked bucket 37 is 33999013 in ag 31 (inode=8355498149) block (34,321655-321910) multiply claimed by cnt space tree, state - 2 agf_freeblks 15995487, counted 15995828 in ag 34 sb_ifree 172202, counted 173174 sb_fdblocks 938740953, counted 941210108 - 19:14:08: scanning filesystem freespace - 64 of 64 allocation groups done - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - 19:14:08: scanning agi unlinked lists - 64 of 64 allocation groups done - process known inodes and perform inode discovery... - agno = 45 - agno = 30 - agno = 15 - agno = 0 - agno = 60 - agno = 61 - agno = 62 - agno = 63 - agno = 46 - agno = 47 - agno = 16 - agno = 31 - agno = 17 - agno = 48 - agno = 49 - agno = 50 - agno = 51 - agno = 52 - agno = 53 - agno = 54 - agno = 55 - agno = 56 - agno = 57 - agno = 58 - agno = 59 imap claims a free inode 8355498174 is in use, would correct imap and clear inode - agno = 32 - agno = 33 - agno = 34 - agno = 18 - agno = 35 - agno = 19 - agno = 36 - agno = 1 - agno = 2 - agno = 37 - agno = 38 - agno = 39 - agno = 40 - agno = 41 - agno = 3 - agno = 20 - agno = 4 - agno = 21 - agno = 42 - agno = 5 - agno = 22 - agno = 6 - agno = 23 - agno = 24 - agno = 25 - agno = 7 - agno = 26 - agno = 8 - agno = 27 - agno = 9 - agno = 28 - agno = 43 - agno = 44 - agno = 29 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - 19:15:10: process known inodes and inode discovery - 612864 of 612864 inodes done - process newly discovered inodes... - 19:15:10: process newly discovered inodes - 64 of 64 allocation groups done Phase 4 - check for duplicate blocks... - setting up duplicate extent list... free space (34,321911-321995) only seen by one free space btree - 19:15:10: setting up duplicate extent list - 64 of 64 allocation groups done - check for inodes claiming duplicate blocks... - agno = 1 - agno = 2 - agno = 11 - agno = 0 - agno = 3 - agno = 4 - agno = 5 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 6 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 - agno = 39 - agno = 40 - agno = 41 - agno = 42 - agno = 43 - agno = 44 - agno = 45 - agno = 46 - agno = 47 - agno = 48 - agno = 49 - agno = 50 - agno = 51 - agno = 52 - agno = 53 - agno = 54 - agno = 55 - agno = 56 - agno = 57 - agno = 58 - agno = 59 - agno = 60 - agno = 61 - agno = 62 - agno = 63 - 19:15:10: check for inodes claiming duplicate blocks - 612864 of 612864 inodes done No modify flag set, skipping phase 5 Inode allocation btrees are too corrupted, skipping phases 6 and 7 No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Tue Mar 9 19:15:10 2021 Phase Start End Duration Phase 1: 03/09 19:14:05 03/09 19:14:05 Phase 2: 03/09 19:14:05 03/09 19:14:08 3 seconds Phase 3: 03/09 19:14:08 03/09 19:15:10 1 minute, 2 seconds Phase 4: 03/09 19:15:10 03/09 19:15:10 Phase 5: Skipped Phase 6: Skipped Phase 7: Skipped Total run time: 1 minute, 5 seconds So this is what I got from the first checkup. Doesnt look so good. Trying to do xfs_repair -nv /dev/sdb now Edited March 9, 2021 by sevenz Quote Link to comment
JorgeB Posted March 9, 2021 Share Posted March 9, 2021 You need to remove -n or nothing will be done, and if it asks for it use -L. Quote Link to comment
sevenz Posted March 9, 2021 Author Share Posted March 9, 2021 (edited) Quote Phase 1 - find and verify superblock... - reporting progress in intervals of 15 minutes - block cache size set to 1859624 entries Phase 2 - using internal log - zero log... zero_log: head block 452803 tail block 451456 ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - 20:48:25: zeroing log - 59617 of 59617 blocks done - scan filesystem freespace and inode maps... agi_freecount 11571, counted 11570 in ag 31 agi unlinked bucket 37 is 33999013 in ag 31 (inode=8355498149) block (34,321655-321910) multiply claimed by cnt space tree, state - 2 agf_freeblks 15995487, counted 15995828 in ag 34 sb_ifree 172202, counted 173174 sb_fdblocks 938740953, counted 941210108 - 20:48:28: scanning filesystem freespace - 64 of 64 allocation groups done - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - 20:48:28: scanning agi unlinked lists - 64 of 64 allocation groups done - process known inodes and perform inode discovery... - agno = 0 - agno = 30 - agno = 15 - agno = 60 - agno = 45 - agno = 61 - agno = 62 - agno = 63 - agno = 31 - agno = 16 - agno = 46 - agno = 47 imap claims a free inode 8355498174 is in use, correcting imap and clearing inode cleared inode 8355498174 - agno = 32 - agno = 17 - agno = 48 - agno = 49 - agno = 50 - agno = 51 - agno = 52 - agno = 53 - agno = 54 - agno = 55 - agno = 56 - agno = 57 - agno = 58 - agno = 59 - agno = 33 - agno = 34 - agno = 35 - agno = 18 - agno = 36 - agno = 1 - agno = 19 - agno = 2 - agno = 37 - agno = 38 - agno = 39 - agno = 40 - agno = 41 - agno = 3 - agno = 4 - agno = 20 - agno = 5 - agno = 21 - agno = 42 - agno = 22 - agno = 6 - agno = 23 - agno = 24 - agno = 7 - agno = 25 - agno = 8 - agno = 26 - agno = 9 - agno = 27 - agno = 28 - agno = 43 - agno = 44 - agno = 10 - agno = 11 - agno = 29 - agno = 12 - agno = 13 - agno = 14 - 20:49:30: process known inodes and inode discovery - 612864 of 612864 inodes done - process newly discovered inodes... - 20:49:30: process newly discovered inodes - 64 of 64 allocation groups done Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - 20:49:30: setting up duplicate extent list - 64 of 64 allocation groups done - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 4 - agno = 9 - agno = 10 - agno = 3 - agno = 6 - agno = 7 - agno = 8 - agno = 2 - agno = 11 - agno = 5 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 - agno = 39 - agno = 40 - agno = 41 - agno = 42 - agno = 43 - agno = 44 - agno = 45 - agno = 46 - agno = 47 - agno = 48 - agno = 49 - agno = 50 - agno = 51 - agno = 52 - agno = 53 - agno = 54 - agno = 55 - agno = 56 - agno = 57 - agno = 58 - agno = 59 - agno = 60 - agno = 61 - agno = 62 - agno = 63 - 20:49:30: check for inodes claiming duplicate blocks - 612864 of 612864 inodes done Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 - agno = 39 - agno = 40 - agno = 41 - agno = 42 - agno = 43 - agno = 44 - agno = 45 - agno = 46 - agno = 47 - agno = 48 - agno = 49 - agno = 50 - agno = 51 - agno = 52 - agno = 53 - agno = 54 - agno = 55 - agno = 56 - agno = 57 - agno = 58 - agno = 59 - agno = 60 - agno = 61 - agno = 62 - agno = 63 - 20:49:43: rebuild AG headers and trees - 64 of 64 allocation groups done - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 - agno = 39 - agno = 40 - agno = 41 - agno = 42 - agno = 43 - agno = 44 - agno = 45 - agno = 46 - agno = 47 - agno = 48 - agno = 49 - agno = 50 - agno = 51 - agno = 52 - agno = 53 - agno = 54 - agno = 55 - agno = 56 - agno = 57 - agno = 58 - agno = 59 - agno = 60 - agno = 61 - agno = 62 - agno = 63 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 8355498149, moving to lost+found Phase 7 - verify and correct link counts... - 20:50:13: verify and correct link counts - 64 of 64 allocation groups done Maximum metadata LSN (62:452259) is ahead of log (1:2). Format log to cycle 65. XFS_REPAIR Summary Tue Mar 9 20:50:27 2021 Phase Start End Duration Phase 1: 03/09 20:48:21 03/09 20:48:21 Phase 2: 03/09 20:48:21 03/09 20:48:28 7 seconds Phase 3: 03/09 20:48:28 03/09 20:49:30 1 minute, 2 seconds Phase 4: 03/09 20:49:30 03/09 20:49:30 Phase 5: 03/09 20:49:30 03/09 20:49:43 13 seconds Phase 6: 03/09 20:49:43 03/09 20:50:13 30 seconds Phase 7: 03/09 20:50:13 03/09 20:50:13 Total run time: 1 minute, 52 seconds done Ahh alright, it does it's thing now. I used the option -vL there. What should I do next? Edited March 9, 2021 by sevenz Quote Link to comment
JorgeB Posted March 9, 2021 Share Posted March 9, 2021 Start the array in normal mode. Quote Link to comment
itimpi Posted March 9, 2021 Share Posted March 9, 2021 Stop the array and restart it in normal mode. The drive should now mount OK. Quote Link to comment
sevenz Posted March 9, 2021 Author Share Posted March 9, 2021 (edited) IT COMES BACK NORMALLY. THANK YOU SO MUCH KIND SIRS @JorgeB and @itimpi! Edit: how do I mark it as solved? Edited March 9, 2021 by sevenz solved Quote Link to comment
itimpi Posted March 9, 2021 Share Posted March 9, 2021 27 minutes ago, sevenz said: xfs_repair -nv /dev/sdb Just realized - I hope you did not do this exact command from the command line? If you did it via the GUI it would have (correctly run the command against the appropriate mdX device which maintains parity. Running directly against a sdX type device invalidates parity, and you have to add the partition number on the end Quote Link to comment
itimpi Posted March 9, 2021 Share Posted March 9, 2021 1 minute ago, sevenz said: how do I mark it as solved? Edit the title on the first post in the thread to add "(SOLVED)". Quote Link to comment
sevenz Posted March 9, 2021 Author Share Posted March 9, 2021 I did it via GUI terminal. It looks for secondary block and all it does is giving dots ....................... and never stops. I canceled it via ctrl + z. I hope I'm not making any mistake there? Quote Link to comment
itimpi Posted March 9, 2021 Share Posted March 9, 2021 12 minutes ago, sevenz said: I did it via GUI terminal. It looks for secondary block and all it does is giving dots ....................... and never stops. I canceled it via ctrl + z. I hope I'm not making any mistake there? The correct command would have been xfs_repair -Lv /dev/mdX where X is the disk number and the md device both handles the partition number for you and maintains parity as corrections are made. It is better to run the command from the GUI by clicking on the drive on the Main tab as it handles the device name for you. If running against the raw device the command is xfs_repair -Lv /dev/sdb1 Note the additional '1' on the end to specify the partition. However doing it this way does not update parity as corrections are made so you then need to run a correcting parity check to get parity to be correct. Quote Link to comment
sevenz Posted March 9, 2021 Author Share Posted March 9, 2021 Got it. Thank you for the explanation! Quote Link to comment
trurl Posted March 9, 2021 Share Posted March 9, 2021 Did you get a lost+found share after the repair? Quote Link to comment
sevenz Posted March 11, 2021 Author Share Posted March 11, 2021 Sorry for the late reply, yes I do but only 1 file. 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.