ext3fs: umount+sync not enough to guarantee metadata-on-disk

[Mark Lord]

Andrew / Stephen / Ted,

I have a MythTV PVR box here, which has had intermittent shutdown issues
over the past while.

The main storage for recordings is a 2-drive RAID0 array,
formatted with ext3fs.  The system runs a 2.6.17 Ubuntu kernel
that I've tailored/rebuild for this specific machine.

My observation is, if I delete a couple of 25+ GByte files,
and then immediately shutdown the system, the disks are still being
written to at the point when the power goes off (halt -f -p).

The overall sequence is something like this:

1. Delete the files in Myth, which uses a "delete slowly" function
to avoid locking up the machine for the 30-60 seconds that this would
otherwise require.  Myth appears to open the file, unlink it, and then
sit in a loop doing small ftruncate's until nothing is left.

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):
  mount /var/lib/mythtv -oremount,ro
  sync
  umount /var/lib/mythtv
  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).

So.. how can I guarantee a quiescent filesystem before doing "halt -f -p" ??
This looks pretty dangerous as-is.

Thanks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/