October 9, 20169 yr Returned home today and found out that many files were missing from a share (many disks store files in that share). In MC disk4 appeared as a red "?disk4" and could not be accessed. The main screen had all disks as active (green dot). I did not restart the server, just did a Array stop-start. The files re-appeared in the share and disk4 was accessible through MC. After some minutes that I checked back, the issue had re-appeared, files were missing and disk4 could not be accessed The attached Syslog "xfs error md4.zip" shows some issues with the file system of the disk. I followed the instructions suggested at https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Drives_formatted_with_XFS , I stopped the Array and started it in Maintenance mode, then run xfs_repair -v /dev/md4 which returned some errors and suggestions, see attached "xfs_repair md4.txt", which advises that "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". So I stopped the Array and restarted it (no in Maintenance mode), and now on the webGUI the Dashboard shows the Disk4 as active, but the Main tab shows it as unmountable. Accessing Disk4 from there (its settings) I see the File system status to be "Unmountable - No file system (32)". And that 's how far I could go on my own. I have one parity disk and 5 data disks. xfs_repair suggests I use the -L option in case that helps, but that also says it can cause data corruption so why would I want to do that, I have opted for a parity disk. Is there a way to use the parity to rebuilt disk4? Are there any other suggestions that could restore the file system and mount disk4 again without any data loss? xfs_error_md4.zip xfs_repair_md4.txt
October 9, 20169 yr Community Expert You need to run xfs_repair with -L, usually there's no data loss.
October 9, 20169 yr Author Running xfs_repair -L /dev/md4 returned this 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... Metadata corruption detected at xfs_agf block 0x1/0x200 flfirst 118 in agf 0 too large (max = 118) sb_icount 6656, counted 6912 sb_fdblocks 75816018, counted 73851558 - 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 = 2 - agno = 3 - agno = 1 - agno = 0 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (3:1410955) is ahead of log (1:2). Format log to cycle 6. done Disk4 is mounted again and the files re-appeared. Browsing directly in disk4 did not show and lost+found folder. I will check back the behavior of the disk in a few hours as I have already seeing it "appearing and disappearing" once, but I 'm guessing the command did the trick.
October 9, 20169 yr Author After around 7 hours of operation and continued disk accessing on it due to various operations working in the background, everything is working as should after the repair. Thank you a lot johnnie.black
Archived
This topic is now archived and is closed to further replies.