On Thu, 07 Jun 2007 09:44:24 -0400 Mark Lord <lkml@xxxxxx> 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?
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.
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.
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.