Disk appears to be unmounting after writing data to it

[cantharides999]

Recently added "replaced" a disk in my array and a strange phenomenon occurs;

 

After writing data to the disk, the disk seems to "disappear".
Accessing it directly through MC or through" samba, the disk appears unavailable.
As such no data can be written anymore.
 

Reboot of the system resolves the issue, until the disk is written to again.

Read checks, smart checks do not reveal any errors, it appears as if the disk "unmounts", although in array config it still accessible.
Accessing it through unraid management console results in screen below (stiil mounted in array).
Anyone any thoughts ?

 

Log registers following error:

 

Sep 28 11:41:49 Tower kernel: XFS (md3): metadata I/O error in "xfs_btree_read_buf_block.constprop.0+0x75/0xc1 [xfs]" at daddr 0xaea86678 len 8 error 74
Sep 28 11:41:49 Tower kernel: XFS (md3): xfs_do_force_shutdown(0x1) called from line 296 of file fs/xfs/xfs_trans_buf.c. Return address = 00000000c3fe9b6d
Sep 28 11:41:49 Tower kernel: XFS (md3): I/O Error Detected. Shutting down filesystem
Sep 28 11:41:49 Tower kernel: XFS (md3): Please unmount the filesystem and rectify the problem(s)

 

Anyone now how to resolve ?

 

 

Edited September 28, 2021 by cantharides999
added screeshot

[itimpi]

You should run a check/repair on the file system for disk 3.   You might want to also check the power/SATA connections to the drive are firmly plugged in.

 

if the problem persists post your system’s diagnostics zip file.

[cantharides999]

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. 

[JorgeB]

Use -L