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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <46680BB8.50404@rtr.ca>
Date:	Thu, 07 Jun 2007 09:44:24 -0400
From:	Mark Lord <lkml@....ca>
To:	Stephen Tweedie <sct@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Theodore Ts'o <tytso@....edu>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: ext3fs: umount+sync not enough to guarantee metadata-on-disk

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/