Messages in this thread | | | Date | Fri, 08 Jun 2007 22:58:36 -0400 | From | Mark Lord <> | Subject | Re: ext3fs: umount+sync not enough to guarantee metadata-on-disk |
| |
Andrew Morton wrote: > On Thu, 07 Jun 2007 12:11:58 -0400 > Chuck Ebbert <cebbert@redhat.com> wrote: > >> On 06/07/2007 11:41 AM, Andrew Morton wrote: >>>> 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. >> Shouldn't sync should wait for truncate to finish? > > I can't think of anything in there at present which would cause that to > happen, and it's not immediately obvious how we _could_ make it happen - we > have an inode which potentially has no dirty pages and which is itself > clean. The truncate can span multiple journal commits, so forcing a > journal commit in sync() won't necessarily block behind the truncate. > > I guess we could ask sync to speculatively take and release every inode's > i_mutex or something. But even that would involve quite some hoop-jumping > due to those infuriating spinlock-protected list_heads on the superblock. > > hmm.
Okay, I added more instrumentation and retested today.
Good and Bad. The umount does indeed fail while the massive unlink is happening, so I can just loop on that a few times before giving up.
But.. the earlier "remount,ro".. well.. I don't know what it does. I did get it to lock up solid, though.. hung on the "remount,ro" when issued during an unlink of a 15GB file. The disk I/O eventually completes, and drives go idle, but the system remains hung inside the remount,ro call.
Alt-sysrq-T was functioning, so I have some screen shots (.jpg) here:
http://rtr.ca/remount_ro/
That's definitely a bug. For now, I'll just not attempt the remount,ro on this system, and have it loop for a minute attempting umount instead.
Cheers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |