[lkml]   [2007]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: ext3fs: umount+sync not enough to guarantee metadata-on-disk
    On Mon 11-06-07 18:47:05, Mark Lord wrote:
    > Jan Kara wrote:
    > >>Andrew Morton wrote:
    > >>>On Thu, 07 Jun 2007 12:11:58 -0400
    > >>>Chuck Ebbert <> 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:
    > >>
    > >>
    > > 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?
    Yes, I'll try to cook up some patch. As I'm looking through the code,
    ext3_remount seems to be the only place where we need to start a
    transaction under s_lock. So probably we could release sb->s_lock for
    the time we have to wait for a transaction...

    Jan Kara <>
    SuSE CR Labs
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-06-12 11:51    [W:0.023 / U:7.384 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site