December 30, 20169 yr unraid 6.19 server (fs2). I could not copy to it today (windows complained of I/O error), so I attempted restarting the system, but it hanged on unmount disks. I forced a reboot and booted up fine, all drives green, but it's been hanging again at "mounting disks...." for the past 20 minutes. The GUI is also unresponsive. From the syslog: Dec 29 20:01:12 FS2 kernel: XFS (md10): xfs_log_force: error -5 returned. Dec 29 20:01:12 FS2 kernel: XFS (md10): xfs_log_force: error -5 returned. Dec 29 20:01:12 FS2 kernel: XFS (md10): xfs_log_force: error -5 returned. Dec 29 20:01:13 FS2 kernel: XFS (md10): xfs_log_force: error -5 returned. Dec 29 20:01:13 FS2 kernel: XFS (md10): xfs_log_force: error -5 returned. Dec 29 20:01:13 FS2 kernel: XFS (md10): xfs_log_force: error -5 returned. Dec 29 20:01:13 FS2 kernel: XFS (md10): xfs_log_force: error -5 returned. Dec 29 20:01:13 FS2 kernel: XFS (md10): xfs_log_force: error -5 returned. Dec 29 20:01:13 FS2 kernel: XFS (md10): xfs_log_force: error -5 returned. I figured it's probably a drive failing or with cables that need re-seating, but which one? Also, what is md10 (all drives are relatively recent SATA drives: sda, sdb, etc.)? fs2.zip
December 30, 20169 yr Community Expert You need to check disk10 (md10) before starting the array. https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Drives_formatted_with_XFS
December 30, 20169 yr Community Expert Device md10 equates to disk10 in the GUI. I have seen that error if the disk has dropped offline before attempting to shutdown the system.
December 30, 20169 yr Author Thanks for replying guys. I'm in maintenance mode, and got this from xfs_repair: root@FS2:~# xfs_repair -v /dev/md10 Phase 1 - find and verify superblock... - block cache size set to 1489264 entries Phase 2 - using internal log - zero log... zero_log: head block 2546292 tail block 2546155 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. root@FS2:~# I'm thinking I should bite the bullet, and use -L , since mounting the drive is what was failing before. What do you recommend? Is it possible this is just FS corruption, and there is actually nothing wrong with the physical drive?
December 30, 20169 yr Author Use -L, it's quite common and usually there's no data loss. I've done that. Rebooted, and the array started immediately. No apparent data loss, though there is now a lost+found folder in /disk10, with 0 bytes in it. Here's the repair output, just in case anyone cares: root@FS2:~# xfs_repair -v -L /dev/md10 Phase 1 - find and verify superblock... - block cache size set to 1489264 entries Phase 2 - using internal log - zero log... zero_log: head block 2546292 tail block 2546155 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... freeblk count 5 != flcount 6 in ag 0 block (0,342577-342577) multiply claimed by bno space tree, state - 2 block (0,342577-342577) multiply claimed by cnt space tree, state - 2 agi unlinked bucket 32 is 1428038816 in ag 0 (inode=1428038816) sb_ifree 4026, counted 4028 sb_fdblocks 615020007, counted 615238856 - 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 - 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 = 3 - agno = 2 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - 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 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 1428038816, moving to lost+found Phase 7 - verify and correct link counts... XFS_REPAIR Summary Fri Dec 30 10:46:38 2016 Phase Start End Duration Phase 1: 12/30 10:41:15 12/30 10:41:15 Phase 2: 12/30 10:41:15 12/30 10:46:08 4 minutes, 53 seconds Phase 3: 12/30 10:46:08 12/30 10:46:12 4 seconds Phase 4: 12/30 10:46:12 12/30 10:46:12 Phase 5: 12/30 10:46:12 12/30 10:46:12 Phase 6: 12/30 10:46:12 12/30 10:46:12 Phase 7: 12/30 10:46:12 12/30 10:46:12 Total run time: 4 minutes, 57 seconds done
Archived
This topic is now archived and is closed to further replies.