Does UFS2 send BIO_FLUSH to GEOM when update metadata (with
softupdates)?
Kirk McKusick
mckusick at mckusick.com
Fri Dec 2 02:36:30 UTC 2011
> Date: Fri, 25 Nov 2011 12:02:35 +0100
> From: Pawel Jakub Dawidek <pjd at freebsd.org>
> To: Kostik Belousov <kostikbel at gmail.com>
> Cc: freebsd-fs at freebsd.org
> Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with
> softupdates)?
>
> On Wed, Nov 23, 2011 at 09:44:44PM +0200, Kostik Belousov wrote:
> > On Wed, Nov 23, 2011 at 11:00:26PM +0400, Lev Serebryakov wrote:
> > > Hello, Freebsd-fs.
> > >=20
> > > Does UFS2 with softupdates (without journal) issues BIO_FLUSH to
> > > GEOM layer when it need to ensure consistency on on-disk metadata?
> > No. Softupdates do not need flushes.
>
> Well, they do for two reasons:
> 1. To properly handle sync operations (fsync(2), O_SYNC).
> 2. To maintain consistent on-disk structures.
SU does not use synchronous writes to maintain consistency (see below).
It rarely uses synchronous writes even to immplement fsync. Instead it
issues async I/O requests for all the blocks necessary to ensure that
the inode in question is stable. It then waits until all of those writes
have been acknowledged. When they have been acknowledged the fsync
returns. If the subsystem acknowledges them before they are truely on
stable store, then SU and correspondingly the caller of fsync is screwed.
The one place where a synchronous write (bwrite) is used is when the
completion of a particular I/O is needed to make progress on many other
things (usually an update to the SUJ log) in which case SU will force a
flush on that I/O (e.g., bwrite it) to hasten it along.
> The second point is there, because BIO_FLUSH is the only way to avoid
> reordering (apart from turning off disk write cache).
>
> SU assumes no I/O reordering will happen, which is very weak assumption.
>
> --
> Pawel Jakub Dawidek http://www.wheelsystems.com
> FreeBSD committer http://www.FreeBSD.org
> Am I Evil? Yes, I Am! http://yomoli.com
SU has no problems with reordering. It makes no assumptions on the
order in which its I/O operations are done. Its only requirement is
that it not be told that something is stable before it truely is
stable. Because the way that it maintains consistency is to not
issue a write on something before it knows that something that it
depends on for consistency is in fact stable. But it has no problem
with any of its outstanding writes being done in any particular order.
Kirk McKusick
More information about the freebsd-fs
mailing list