Hi! I try to keep this as short as possible. In the past I had problems with drives (maybe the controller, mabye the wire, maybe the whole hardware not high-level - more a noob-lab Frankestein...), however I simply removed the bad drive (or blanked it) then re-attached, and the whole thing come alive again, after the usual parity rebuilt. I never lost anything, and I usually could have used the Unraid server in the meantime.

This time probably I did a mess, so I'm here simply to understand if I can recover the files (I have a manual backup for the important things, just not so recent).

In short:

• even this time I had a drive with the "x" in Main.

• I removed it and I substitute it with a used Western Digital I had here, unused.

• The last thing I saw was the usual parity rebuilding.

• Today I see that the WD drive shows in Main as partially full (as the old one was), but the file in it are "gone"

• After a reboot I get "Unmountable: wrong or no file system" on that drive.

From my totally noob point of view, I suppose that the parity rebuilding went bad, so the system initially thought that all was good instead.

Now the question is: may I try to access to the "unmountable" HDD, hoping for recovering what I can?

With the started array I tried to do a xfs_repair /dev/md4p1, but I got:

Phase 1 - find and verify superblock...

- reporting progress in intervals of 15 minutes

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 the filesystem is a snapshot of a mounted

filesystem, you may need to give mount the nouuid option. 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.

I read that I could do the same command with a -L in addition, to discard the journal and trying again, but I'm really scared to do that, and I don't know if doing it could impact on the rest of the Unraid.

I'm not desperate, I have an (old...) backup, so I'll probably lose only the last month, not so critical, data, however I'm not sure what those data are, so even a file list could be useful to understand what I'm really losing.

Any suggestion is really welcome. Thanks in advance.

PS: I had the chance to copy this part of the Log before the reboot:

Jun 2 04:59:12 nastower kernel: Call Trace: Jun 2 04:59:24 nastower kernel: XFS (md4p1): Internal error !(flags & XFS_DABUF_MAP_HOLE_OK) at line 2751 of file fs/xfs/libxfs/xfs_da_btree.c. Caller xfs_dabuf_map.constprop.0+0x1ba/0x2a0 Jun 2 04:59:24 nastower kernel: CPU: 7 UID: 0 PID: 2625731 Comm: find Tainted: P O 6.12.54-Unraid #1 Jun 2 04:59:24 nastower kernel: Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE Jun 2 04:59:24 nastower kernel: Call Trace: Jun 2 04:59:36 nastower kernel: XFS (md4p1): Internal error !(flags & XFS_DABUF_MAP_HOLE_OK) at line 2751 of file fs/xfs/libxfs/xfs_da_btree.c. Caller xfs_dabuf_map.constprop.0+0x1ba/0x2a0 Jun 2 04:59:36 nastower kernel: CPU: 2 UID: 0 PID: 2626829 Comm: find Tainted: P O 6.12.54-Unraid #1 Jun 2 04:59:36 nastower kernel: Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE Jun 2 04:59:36 nastower kernel: Call Trace: Jun 2 04:59:49 nastower kernel: XFS (md4p1): Internal error !(flags & XFS_DABUF_MAP_HOLE_OK) at line 2751 of file fs/xfs/libxfs/xfs_da_btree.c. Caller xfs_dabuf_map.constprop.0+0x1ba/0x2a0 Jun 2 04:59:49 nastower kernel: CPU: 12 UID: 0 PID: 2627870 Comm: find Tainted: P O 6.12.54-Unraid #1 Jun 2 04:59:49 nastower kernel: Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE Jun 2 04:59:49 nastower kernel: Call Trace: Jun 2 05:00:01 nastower kernel: XFS (md4p1): Internal error !(flags & XFS_DABUF_MAP_HOLE_OK) at line 2751 of file fs/xfs/libxfs/xfs_da_btree.c. Caller xfs_dabuf_map.constprop.0+0x1ba/0x2a0 Jun 2 05:00:01 nastower kernel: CPU: 13 UID: 0 PID: 2628928 Comm: find Tainted: P O 6.12.54-Unraid #1 Jun 2 05:00:01 nastower kernel: Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE Jun 2 05:00:01 nastower kernel: Call Trace: Jun 2 05:00:14 nastower kernel: XFS (md4p1): xfs_difree_inobt: xfs_inobt_get_rec() returned error -117. Jun 2 05:00:14 nastower kernel: XFS (md4p1): xfs_inactive_ifree: xfs_ifree returned error -117 Jun 2 05:00:14 nastower kernel: XFS (md4p1): xfs_difree_inobt: xfs_inobt_lookup() returned error -5. Jun 2 05:00:14 nastower kernel: XFS (md4p1): xfs_difree_inobt: xfs_inobt_lookup() returned error -5. Jun 2 05:00:14 nastower kernel: XFS (md4p1): xfs_difree_inobt: xfs_inobt_lookup() returned error -5. Jun 2 05:00:14 nastower kernel: XFS (md4p1): xfs_difree: xfs_ialloc_read_agi() returned error -5. Jun 2 05:00:20 nastower kernel: XFS (md4p1): Metadata I/O Error (0x1) detected at xfs_inactive_if

nastower-diagnostics-20260602-0845.zip

Edited June 2Jun 2 by Andrea P.

47 minutes ago, Andrea P. said:

I read that I could do the same command with a -L in addition

Try this

2 minutes ago, JorgeB said:

Try this

Ok, the command ended. Now what?
In Main, the drive is still shown as unmountable. Should I stop the array and start it again?
Or, is the drive still unmountable even from now on, so I need a way to manually mount it, check the files, then at the end blank it and re-add it to the pool as a blank drive?

9 minutes ago, Andrea P. said:

Ok, the command ended. Now what?
In Main, the drive is still shown as unmountable. Should I stop the array and start it again?
Or, is the drive still unmountable even from now on, so I need a way to manually mount it, check the files, then at the end blank it and re-add it to the pool as a blank drive?

Have you restarted the array in Normal mode? Normally if a xfs_repair completes it will now mount. If not then you should post new diagnostics.

Also look to see if a Lost+Found share has appeared as if so that is where the repair process puts any file/folders (with cryptic names) for which it could not find the directory entry to give the correct name.

15 minutes ago, itimpi said:

Have you restarted the array in Normal mode?

(Ouch, I did the command while my array was already started in Normal mode)

However, after the command, I stopped the array and restarted it in Normal mode, and now I see the drive connected to the pool.

I see some standard folders and files, and the Lost+Found folder with (empty) folders and some file named as random numbers.

So, now I have two remaining doubts:

1) Is there still the chance I totally lost some file? I suppose there's no easy way to understand it.

2) Those Lost+Found files, should I simply try to move them to another folder, then, try to randomly apply a file extension hoping that they will be usable again? EDIT: about this point I found there's a linux command that I can launch in the folder: file *

EDIT: marked the topic as Solved. However, if you have suggestions about those two points, I'm listening.

Edited June 2Jun 2 by Andrea P.