| |||||||||||||
Ext4 data corruption trouble [Updated]Ext4 data corruption trouble [Updated]Posted Oct 26, 2012 0:26 UTC (Fri) by nix (subscriber, #2304)In reply to: Ext4 data corruption trouble [Updated] by ncm Parent article: Ext4 data corruption trouble [Updated]
That requires that you can *find* all the file systems. In the presence of PID and fs namespaces, no single process can necessarily do that (nor can any single process necessarily talk to any group of processes that can do that, even indirectly).
This is somewhat unlikely, it is true.
(Log in to post comments)
Ext4 data corruption trouble [Updated] Posted Oct 26, 2012 0:45 UTC (Fri) by neilbrown (subscriber, #359) [Link] echo S > /proc/sysrq-trigger echo U > /proc/sysrq-trigger??
Ext4 data corruption trouble [Updated] Posted Oct 26, 2012 14:04 UTC (Fri) by nix (subscriber, #2304) [Link]
Oh. Yeah. That would work. I completely forgot that sysrq-trigger even existed. :)
New syscall, who needs it, though relying on sysrq-trigger for something as fundamental as shutting down seems a little icky.
Ext4 data corruption trouble [Updated] Posted Oct 26, 2012 14:37 UTC (Fri) by butlerm (subscriber, #13312) [Link]
Does that work with loopback mounted filesystems, i.e. is the sysrq handler smart enough to unmount a loopback mounted filesystem before the filesystem that holds its backing store?
Ext4 data corruption trouble [Updated] Posted Oct 27, 2012 20:17 UTC (Sat) by nix (subscriber, #2304) [Link]
Sysrq-U remounts read-only, it doesn't unmount.
(But, still, you do want to remount the loopback-mounted filesystem first, or that umount won't be able to do e.g. journal flushes...)
And the answer is no: it ends up calling do_emergency_remount(), which does a straight iteration over all super_blocks: there is no dependency analysis of any kind: I'd expect (given the way super_blocks is built) to unmount the backing store fs *before* the loopback-mounted fs.
(Perhaps do_emergency_remount() should iterate over super_blocks in reverse order?)
|
|||||||||||||