4 hours ago, johnnie.black said:

xfs_repair -vL /dev/md4

I have often wondered why this is so frequently needed?   If i have an unmountable Disk then typically if instead of using xfs_repair with the -L option I simply do a mount from the command line it mounts fine and the contents are visible.   If I then umount the drive and start the array again the disk no longer shows as unmountable (despite the fact I did not run the repair).   There is obviously something in the way that unRAID is trying to mount the drive that is different to the manual mount.  Maybe the built-in unRAID mount should be amended to be more like the manual mount command?

7 minutes ago, itimpi said:

I have often wondered why this is so frequently needed?   If i have an unmountable Disk then typically if instead of using xfs_repair with the -L option I simply do a mount from the command line it mounts fine and the contents are visible.   If I then umount the drive and start the array again the disk no longer shows as unmountable (despite the fact I did not run the repair).   There is obviously something in the way that unRAID is trying to mount the drive that is different to the manual mount.  Maybe the built-in unRAID mount should be amended to be more like the manual mount command?

unRAID only adds noatime and nodiratime to the mount command, wouldn't expect those would cause any issues, needing -L started happening more frequently a while back, always assumed something change with xfs itself, AFAIK the mount command has been the same for a long time, but if it mounts manually then something else could be going on, though mounting the disk outside the array will most likely introduce a few parity sync errors.

Just now, johnnie.black said:

unRAID only adds noatime and nodiratime to the mount command, wouldn't expect those would cause any issues, needing -L started happening more frequently a while back, always assumed something change with xfs itself, AFAIK the mount command has been the same for a long time, but if it mounts manually then something else could be going on, though mounting the disk outside the array will most likely introduce a few parity sync errors.

I mount manually using the md device (with the array in Maintenance mode) so it will not introduce parity errors.

4 hours ago, ThePhotraveller said:

do i have to do anything after this point?

Make a backup plan. You don't have to backup everything, but any important and irreplaceable file must have backup.

Just now, itimpi said:

I mount manually using the md device (with the array in Maintenance mode) so it will not introduce parity errors.

Aah, OK, then we should tell users to to that first in the future instead of using -L.

 

We can even try the default unRAID mount command first, and then a simple one without those options to see if it makes any difference.

2 minutes ago, johnnie.black said:

Aah, OK, then we should tell users to to that first in the future instead of using -L.

 

We can even try the default unRAID mount command first, and then a simple one without those options to see if it makes any difference.

I wonder if it's a timing issue. Maybe unraid should automatically try to mount a second time if the first one fails.

3 minutes ago, jonathanm said:

I wonder if it's a timing issue. Maybe unraid should automatically try to mount a second time if the first one fails.

Not sure, in this case unRAID logged:

 

Aug  9 22:35:35 Tower kernel: XFS (md4): Mounting V5 Filesystem
Aug  9 22:35:35 Tower kernel: XFS (md4): Corruption warning: Metadata has LSN (1:350445) ahead of current LSN (1:349189). Please unmount and run xfs_repair (>= v4.3) to resolve.
Aug  9 22:35:35 Tower kernel: XFS (md4): log mount/recovery failed: error -22
Aug  9 22:35:35 Tower kernel: XFS (md4): log mount failed

Would expect a second try to show the same, but I don't use xfs for while now, so no personal experience.