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

[Mark Lord]

Jan Kara wrote:
> > Andrew Morton wrote:
> > > On Thu, 07 Jun 2007 12:11:58 -0400
> > > Chuck Ebbert <cebbert@xxxxxxxxxx> 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/
>   Thanks for the traces.
>
> > That's definitely a bug.
>   Yes. We have a nice lock inversion there. ext3_remount() is called
> with sb->s_lock held and waits for transaction to finish in
> journal_lock_updates(). On the other hand ext3_orphan_del() is called
> inside a transaction and tries to do lock_super()... Bad luck.

Peachy.  Do you have enough knowledge here to generate a fix for this?
Maybe just have the remount break out, releasing all locks, and then 
loop and retry (or return -EBUSY?) when this happens?

Cheers
-
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/