[Solved] The Clear Drive Then Remove Drive Method - now one share is "empty"

[luca]

Unraid 6.2.4.  I shrunk the array twice, removing 2 drives in succession, following this procedure (the "Clear Drive Then Remove Drive" Method):

 

https://lime-technology.com/wiki/index.php/Shrink_array#Procedure_2

 

Both time I had no errors, and the array restarted fine with no need for a parity check.

 

The content in one of the user shares (let's call it "data") is not shown.  "data" was the only folder present on the drives I have removed, but of course its content was copied to the remaining drives before removing the drives.

 

I can still see/access the files by disk share (\\fs2\disk1\data,  \\fs2\disk2\data and so on), but the share itself is empty.

 

I checked the Shares tab, and the "data" share is still a public share, with all drives included and none excluded.  Also tried stopping/restarting the array.  Any idea what is going on? 

[trurl]

post diagnostics

[luca]

post diagnostics

 

Sorry, I'm a dummy.    I didn't check the logs first.  Apparently was caused by another xfs corruption problem (same drive as before too).

After running xfs_repair on the drive the share is populated again.  I'm curious if it's by design that everything seems to grind to a halt if there is a problem with one of the drives?    Would not make sense to keep files that are still accessible available?

 

This bit in the log was pointing out the problem (and the solution) all along:

 

Jan  2 09:31:15 FS2 kernel: XFS (md1): metadata I/O error: block 0xb41d5ab0 ("xfs_trans_read_buf_map") error 117 numblks 8

Jan  2 09:31:15 FS2 kernel: XFS (md1): Corruption warning: Metadata has LSN (1:82393) ahead of current LSN (1:866). Please unmount and run xfs_repair (>= v4.3) to resolve.

Jan  2 09:31:15 FS2 kernel: XFS (md1): Metadata corruption detected at xfs_dir3_block_read_verify+0xa1/0xa9, xfs_dir3_block block 0xb41d5950

Jan  2 09:31:15 FS2 kernel: XFS (md1): Unmount and run xfs_repair

Jan  2 09:31:15 FS2 kernel: XFS (md1): First 64 bytes of corrupted metadata buffer:

Jan  2 09:31:15 FS2 kernel: ffff88007ef77000: 58 44 42 33 fb 51 05 18 00 00 00 00 b4 1d 59 50  XDB3.Q........YP

Jan  2 09:31:15 FS2 kernel: ffff88007ef77010: 00 00 00 01 00 01 41 d9 c3 eb 9b 3e 0c 62 48 a0  ......A....>.bH.

Jan  2 09:31:15 FS2 kernel: ffff88007ef77020: 9b 97 05 f6 42 43 88 19 00 00 00 00 c5 74 f2 0e  ....BC.......t..

Jan  2 09:31:15 FS2 kernel: ffff88007ef77030: 03 60 0c 28 00 00 00 00 00 00 00 00 68 6f 73 74  .`.(........host

 

 

[Squid]

Would not make sense to keep files that are still accessible available?

Probably complicated to do that because unRaid combines the separate filesystems into a unified one.  Would be nice in a perfect world however...