Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Aug 1999 13:20:45 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        phk@critter.freebsd.dk, current@FreeBSD.ORG, sobomax@altavista.net
Subject:   Re: Sync(8) doesn't have any effect on softupdates-enabled filesystem
Message-ID:  <199908222020.NAA92717@apollo.backplane.com>
References:   <199908221915.FAA07442@godzilla.zeta.org.au>

next in thread | previous in thread | raw e-mail | index | archive | help

:
:>So what do we do when we halt or reboot ?
:
:We unmount the file system.  dounmount() calls VFS_SYNC() with the
:MNT_WAIT flag, and then (for ffs) ffs_unmount() calls ffs_flushfiles()
:or softdep_flushfiles().  I'm not sure why the latter is necessary.
:
:I don't understand this problem.  sync() intentionally calls
:VFS_SYNC() with the MNT_NOWAIT flag to stop it from waiting for
:i/o to complete.  It's just an implementation quirk that i/o is
:more likely to have completed when sync() returns for the non-
:softdep case.
:
:Bruce

    In the non-softdep case, when you write out a buffer, the buffer is
    truely written out and becomes clean.

    In the softupdates case, when you write out a buffer softupdates may
    *redirty* it.  The buffer may *NOT* become clean.  Specifically, if the
    buffer contains dependancies softupdates will write the non-dependant
    version of the buffer rather then the actual contents of the buffer,
    and then re-dirty the buffer as an indication that the buffer still has
    dependancies and cannot be marked clean yet.

    When you sync() with MNT_NOWAIT, a single pass through the dirty buffers
    occurs.  In a non-softupdates filesystem all the buffers will be clean
    after this pass.  In a softupdates filesystem many of the buffers will
    remain dirty after this pass - mainly when you have done complex directory
    interactions with file creation and deletion.

    When you umount, the sync code cycles through the dirty buffer list at
    full speed and keeps cycling until there are no dirty buffers left. 
    Depending on how complex the dependancy lists are, this can take a very 
    short time or it can take a very long time.  It can be very inefficient,
    in fact, and write the same buffer out many times before all the related
    dependancies are flushed out.

    In fact, we had to fix a number of infinite-loop cases with the VOP_FSYNC
    code for ffs on softupdates-mounted partitions.  This is why the B_SCANNED
    flag had to be added to the scanning code in ffs_fsync().  Changes also
    had to be made to getnewbuf(), the syncer (Kirk's circle queue), and
    other places.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908222020.NAA92717>