PATCH: Forcible delaying of UFS (soft)updates

[Terry Lambert]

Marko Zec wrote:
> > You are much better off accumulating requests in the kernel in
> > buffers, and then using the normal write mechanism to push them
> > out to the drive ordered (IMO).
> 
> That is precisely what the original OS-controlled delayed synching patch does
> :)

Yeah, but the spin-down isn't really under OS control, except
as a sort of statistical hysteresis thing.  8-).

The real problem that people have with the patch is that it is
moderately evil, in that the fsync() doesn't block until it has
actually sync'ed the data out to the disk, like fsync() is
supposed to... and it lets dependent operations keep going.  So
you break the semantics.

I think people would be happier if you just stopped the soft
updates sync clock, and then if someone actually fsync()'ed, or
the dependency list got too big, it spun up the disk, completed
all the I/O quickly, and then spun it down again.


> > This is useful, but not enough.  You need to actually communicate
> > the information above the block I/O layer, to the soft updates.  I
> > think, effectively, what you actually want to do is to stop the
> > soft updates clock
> 
> Hey man, that's exactly what I have done in my patch ("stopping the soft
> updates clock" as you call it). On the block I/O layer I'm only checking if
> the disk is active or not... Are you sure you have checked out the patch /
> code?

See above; do that AND preserve the fsync() semantics, and
you'll have something (still thinking there's a confusion
between fsync() semantics and syncd operation).

-- Terry