I've ran the check -n option (from management interface) resulting in the following:
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 ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... Metadata CRC error detected at 0x46b78d, xfs_inobt block 0xaea86678/0x1000 btree block 3/3 is suspect, error -74 bad magic # 0 in inobt block 3/3 sb_ifree 143, counted 140 sb_fdblocks 2394544389, counted 2411574121 - 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 data fork in ino 2149391519 claims free block 287002959 data fork in ino 2149391519 claims free block 295665266 data fork in ino 2149391519 claims free block 297755762 imap claims a free inode 2149391520 is in use, would correct imap and clear inode - 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 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 2 entry "Clockwise.srt" in shortform directory 2149391518 references free inode 2149391520 would have junked entry "Clockwise.srt" in directory inode 2149391518 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 8 - agno = 7 - agno = 11 - agno = 0 - agno = 10 - agno = 9 - agno = 13 - agno = 14 - agno = 15 - agno = 12 - agno = 17 - agno = 16 - agno = 19 - agno = 18 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.
I thought aftrewards I should run check without (-n) option but this results in:
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.
Don't know exactly how to proceed to get the filesystem fixed.
Alternatively I'm thinking of moving the data of the disk and reformatting the disk in XFS.