Andrew Morton wrote:
On Thu, 07 Jun 2007 09:44:24 -0400 Mark Lord <[email protected]> wrote:
..
2. When I trigger the shutdown whilst this is happening, Myth gets
killed off, and so the unlinked file is automatically closed.
and the kernel (filesystem) code begins finishing the delete operation.
3. The shutdown scripts do their thing quickly, so the delete is
*still* underway when the umount commands are issued.
On this system, I use this sequence:
## /var/lib/mythtv is the recording's ext3fs, on /dev/md0 (RAID0):
I assume the applikcaton has already been killed at this stage, and it is
blocked in the kernel running the truncate?
Yes, I believe I saw that once.
mount /var/lib/mythtv -oremount,ro
sync
umount /var/lib/mythtv
Did this succeed? If the application is still truncating that file, the
umount should have failed.
Actually, what I expect to happen is for the remount,ro
to block until the file deletion completes. But it doesn't.
Once a f/s is read-only, there should be NO writing to it. Right?
I don't know if the umount worked or not, but the f/s ought to be
read-only at this point, so why is it still writing to the device?
I'll instrument the shutdown more for next time, to see if the remount
and umount really do succeed or not. Mmm.. do they log anything on failure?
sync
mount / -oremount,ro
sync
sleep 1
hdparm -W0 /dev/sda /dev/sdb
sync
sleep 2
halt -f -p
4. The hard drive light is on solid throughout, including at the point
when the power goes out.
5. On the next reboot, there is a LONG pause (20-30 seconds) at the
point where /var/lib/mythtv is remounted --> indicating unfinished business
from the journal file that needs to be replayed (eg. the file deletion).
That opened-but-deleted file's inode is on the orphan list.
See, the unlink-then-slowly-truncate trick is done in this fashion so that
if the box crashes during the slow unlink, the orhpan list handling on the
reboot will finish off the truncate for us.
Yes, absolutely.
So.. how can I guarantee a quiescent filesystem before doing "halt -f -p" ??
This looks pretty dangerous as-is.
Wait for the killed-off applicaiton to actually exit, perhaps? But
that unmount should have failed.
But some applications just "hang" regardless, and so this cannot wait forever.
There must be *some* way to know when a filesystem is really quiescent
and therefore safe to power off?
Cheers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
