| |||||||||||||
Ext4 data corruption trouble [Updated]Ext4 data corruption trouble [Updated]Posted Oct 26, 2012 0:45 UTC (Fri) by neilbrown (subscriber, #359)In reply to: Ext4 data corruption trouble [Updated] by nix Parent article: Ext4 data corruption trouble [Updated]
echo S > /proc/sysrq-trigger echo U > /proc/sysrq-trigger??
(Log in to post comments)
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?)
|
|||||||||||||