itimpi Posted August 10, 2018 Share Posted August 10, 2018 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? Quote Link to comment
JorgeB Posted August 10, 2018 Share Posted August 10, 2018 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. Quote Link to comment
itimpi Posted August 10, 2018 Share Posted August 10, 2018 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. Quote Link to comment
trurl Posted August 10, 2018 Share Posted August 10, 2018 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. Quote Link to comment
JorgeB Posted August 10, 2018 Share Posted August 10, 2018 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. Quote Link to comment
JonathanM Posted August 10, 2018 Share Posted August 10, 2018 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. Quote Link to comment
JorgeB Posted August 10, 2018 Share Posted August 10, 2018 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.