Ext4 data corruption trouble

Posted Oct 25, 2012 1:30 UTC (Thu) by ewen (subscriber, #4772)
In reply to: Ext4 data corruption trouble by dlang
Parent article: Ext4 data corruption trouble [Updated]

Wouldn't "mount -o remount /dev/sdb" solve the first problem? In theory it should close off the journal and get the file system into a stable state, but not require the non-responsive NFS server to reply. And in theory it should be safe to force unmount a read-only file system, once it's reached that read-only/stable state.

However finding all the file systems in the face of many PID/filesystem name spaces is still non-trivial.

Ewen

Ext4 data corruption trouble

Posted Oct 25, 2012 1:56 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

dlang has it right, that's the problem I was trying to solve with this lazy umount kludge. And for many, many years, it worked!

I had no idea you could use remounting (plus, presumably, readonly remounting) on raw devices like that. That might work rather well in my case: all my devices are in one LVM VG, so I can just do a readonly remount on /dev/$vgname/*.

But in the general case, including PID and fs namespaces, that's really not going to work, indeed.

Ext4 data corruption trouble

Posted Oct 25, 2012 3:50 UTC (Thu) by ewen (subscriber, #4772) [Link] (1 responses)

Yes, I did intend to say "mount -o remount,ro /dev/sdb". For years it's been my usual "try to minimise the harm" approach, when dealing with a stuck server due to some mounts not responding. I'm not sure what happens with a modern server where the same volume is mounted in more than one location (hopefully all the mounts end up read-only). But it definitely works with /dev/mapper/$vgname-$lvname for instance if it's only mounted once.

Ewen

Ext4 data corruption trouble

Posted Oct 25, 2012 11:16 UTC (Thu) by nix (subscriber, #2304) [Link]

Bind mounts will be fine with this: they all share the same read-only state unless explicitly otherwise requested.