Recent Features
| |||||||||||||
Ext4 data corruption troubleExt4 data corruption troublePosted Oct 25, 2012 1:56 UTC (Thu) by nix (subscriber, #2304)In reply to: Ext4 data corruption trouble by ewen Parent article: Ext4 data corruption trouble [Updated]
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.
(Log in to post comments)
Ext4 data corruption trouble Posted Oct 25, 2012 3:50 UTC (Thu) by ewen (subscriber, #4772) [Link]
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.
|
|||||||||||||