October 22, 20178 yr My array's Samba shares became unresponsive, so I clicked on reboot in unRAID control panel. After it came back up, it said unclean shutdown was detected. Isn't Reboot button supposed to initiate a clean reboot, or should I have stopped the array first? When the server booted, and I click to start the array, the UI gets stuck on mounting disks and doesn't mount them or start parity check. I can telnet to the array just fine. Syslog attached, first system generated I believe when it first went down, and second manually requested after rebooting. Running the latest version of unRAID. Please advise. themonolith-diagnostics-20171022-0323.zip themonolith-diagnostics-20171022-0421.zip Edited October 23, 20178 yr by Ulvan
October 22, 20178 yr You need to Check Disk File System on disk 7 Oct 22 04:10:02 TheMonolith rc.diskinfo[6874]: PHP Warning: strpos(): Empty needle in /etc/rc.d/rc.diskinfo on line 339 Check for plugin updates to Preclear Disk and Unassigned Devices
October 22, 20178 yr Author 7 hours ago, Squid said: You need to Check Disk File System on disk 7 Oct 22 04:10:02 TheMonolith rc.diskinfo[6874]: PHP Warning: strpos(): Empty needle in /etc/rc.d/rc.diskinfo on line 339 Check for plugin updates to Preclear Disk and Unassigned Devices I've updated Preclear and other plugins, and installed Unassigned Devices (didn't have that earlier). Still the same issue Unassigned Devices plugin doesn't show any such devices, which is correct. All my disks are in use, and are in the right slots. Attached new log. themonolith-diagnostics-20171022-1249.zip Edited October 22, 20178 yr by Ulvan
October 22, 20178 yr Author 6 hours ago, itimpi said: Have you run the check on disk7 yet? Which check? I can't mount the array so can't run a parity check.
October 22, 20178 yr 13 hours ago, Squid said: You need to Check Disk File System on disk 7 Follow the link Edited October 22, 20178 yr by Squid
October 22, 20178 yr Author 5 minutes ago, Squid said: Follow the link Oops, didn't notice the part before the quotes earlier Running after the extended SMART test is finished.
October 23, 20178 yr Author Below results of checking filesystem status. It found corruption, but there's no indication on what to do next? Is it safe to start the array in normal mode, and run parity check? It's an XFS drive. Quote Phase 1 - find and verify superblock... - block cache size set to 730784 entries Phase 2 - using internal log - zero log... zero_log: head block 170800 tail block 169985 - scan filesystem freespace and inode maps... Metadata corruption detected at xfs_agf block 0xaea86661/0x200 flfirst 118 in agf 3 too large (max = 118) agf 118 freelist blocks bad, skipping freelist scan agi unlinked bucket 13 is 8078797 in ag 3 (inode=3229304269) sb_icount 35328, counted 31360 sb_ifree 2730, counted 3389 sb_fdblocks 8406292, counted 9205932 - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - 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 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 3229304269, would move to lost+found Phase 7 - verify link counts... would have reset inode 3229304269 nlinks from 0 to 1 No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Mon Oct 23 09:03:57 2017 Phase Start End Duration Phase 1: 10/23 09:03:46 10/23 09:03:47 1 second Phase 2: 10/23 09:03:47 10/23 09:03:48 1 second Phase 3: 10/23 09:03:48 10/23 09:03:53 5 seconds Phase 4: 10/23 09:03:53 10/23 09:03:53 Phase 5: Skipped Phase 6: 10/23 09:03:53 10/23 09:03:57 4 seconds Phase 7: 10/23 09:03:57 10/23 09:03:57 Total run time: 11 seconds
October 23, 20178 yr According to that log you ran the xfs_repair with the -n flag set which carries out a check but does not fix any errors found. You need to rerun it without the -n flag to get xfs_repair to actually fix the issues found.
October 23, 20178 yr Author Here the result after running Check Filesystem Status without any options. I how do I "mount the filesystem to replay the log", and unmount it? edit: are these the three commands needed to mount and unmount the filesystem, adaptep from this post here? How do I found out the correct dev entry for the disk? mkdir /mnt/disk7 ; mount /dev/[device ID] /mnt/disk7 ; umount /mnt/disk7 Quote Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. Edited October 23, 20178 yr by Ulvan
October 23, 20178 yr Use the -L option - it virtually never results in a loss of data. This is quite a standard message. If you really want to avoid using the -L option then it is possible to do a mount/umount from the command line before doing the xfs_repair, but this is normally more effort than it is worth.
October 23, 20178 yr Author I ran the Check Filesystem Status with the -L option. Here results after re-running with -nv. Good to start the array? Quote Phase 1 - find and verify superblock... - block cache size set to 730784 entries Phase 2 - using internal log - zero log... zero_log: head block 2 tail block 2 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 0 - agno = 2 - agno = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Mon Oct 23 18:18:08 2017 Phase Start End Duration Phase 1: 10/23 18:17:56 10/23 18:17:57 1 second Phase 2: 10/23 18:17:57 10/23 18:17:58 1 second Phase 3: 10/23 18:17:58 10/23 18:18:03 5 seconds Phase 4: 10/23 18:18:03 10/23 18:18:03 Phase 5: Skipped Phase 6: 10/23 18:18:03 10/23 18:18:08 5 seconds Phase 7: 10/23 18:18:08 10/23 18:18:08 Total run time: 12 seconds
October 23, 20178 yr Yes - the array is good to go. You might want to check if you have a Lost_Found folder as this will contain any files for which the metadata cannot be recovered.
October 23, 20178 yr Author Started it and parity was even valid. Lost+found folder had only one zero-sized file. Thanks to everyone for help, really appreciate it!
Archived
This topic is now archived and is closed to further replies.