XFS repair on mounted drive

[anthropoidape]

Is it correct that xfs_repair runs on an unraid-mounted drive without warning that it should be unmounted?

 

I lost some data recently, possibly (but possibly not) because of doing this. It was not critical and I am not complaining, but it does seem like a potential data destroyer if someone runs xfs_repair and forgets to stop the array first.

 

I may be wrong about all this, but I thought I should mention it just in case it's a problem and you guys aren't aware of it.

 

Jason

[trurl]

What were the exact commands you used?

[anthropoidape]

I connected to my unraid box with SSH, then ran:

 

xfs_repair /dev/sdi1

 

... or some similar designation of the device (it might have been sdn1 or some such).

 

I subsequently ran xfs_repair -L /dev/sdi1

 

I realise this was not the right thing to do on a mounted filesystem and it may have caused some filesystem corruption (I ended up with some stuff in LOST+FOUND), but I was really just experimenting.

 

I seem to recall that other filesystem repair tools - for reiserfs and btrfs - decline to run on a mounted filesystem, or am I misremembering?

 

[trurl]

With reiserfs, it is usually run against the md device instead of the sd device. The md device includes parity updates with any changes made. Not sure if the same would apply to xfs or not.

[anthropoidape]

I see. And it seems like xfs_repair does pick up md-devices correctly. So perhaps the answer is simply that I should have run /dev/md1 instead?

[BRiT]

Yes,  the same for all filesystems. If you run against /dev/sd# you just invalidated your parity as you did updates that bypass the /dev/md#.

[anthropoidape]

Thanks! Well, I feel a bit dumb now but I am used to that

[BRiT]

Make sure you run a correcting parity check, otherwise your array remains invalid.

[anthropoidape]

Thanks. Yep, I have since done a correcting parity check.