yes and no.
the sync wheel indicates buffers to wrrite
in an order that will probably ensure that early dependencies are
satisfied before later ones, however even after being written,
a buffer might have remaining unsatisfied dependencies that
required that teh on disk and in momory version sstill do not match.
In this case it will have been rewritten back to the sync-wheel further in
the future. What one can do is acellerate teh speed that teh daemon goes
around the wheel, but you must never go faster than the disks can write,
because if you queue a block that depends on something that hasn't got to
disk yet, you will be queueing the old version.
On Sun, 22 Aug 1999, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
> >:> structures used internally by softupdates are not condusive to doing a
> >:> hard-sync.
> >:
> >:I gues sync needs to set a flag which makes the sync'er go through all
> >:buckets with no delay and then wake the sync'ing process afterwards...
> >:
> >:--
> >:Poul-Henning Kamp FreeBSD coreteam member
> >
> > It won't help. What needs to happen is for the VOP_FSYNC in ffs to
> > figure out buffer<->buffer dependancies
>
> But the buffer to buffer dependencies are already recorded in the
> sequence on the "sync-wheel" which the syncer daemon runs through,
> isn't it ?
>
> --
> Poul-Henning Kamp FreeBSD coreteam member
> [EMAIL PROTECTED] "Real hackers run -current on their laptop."
> FreeBSD -- It will take a long time before progress goes too far!
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
