Re: access to hard drives is "blocked" by writes to a flash drive

On  4 Mar, Poul-Henning Kamp wrote:
> Content-Type: text/plain; charset=ISO-8859-1
> --------
> In message <201303040712.r247CejP008718_at_gw.catspoiler.org>, Don Lewis writes:
> 
>>Prior to 231160, the syncer thread would call sync_vnode() for the
>>syncer vnode of each mountpoint every 30 seconds [...]
> 
> I agree that the lemming syncer is better, but the fundamental mistake of
> only having one syncer thread is probably the root-cause in this case:
> One camera-grade flash syncing may take (a lot) more than 30 seconds.

That's been my opinion for a long time as well, though I think it would
be better to have one thread per device to avoid syncer threads for
multiple partitions on the same drive all contending for the same
actuator.  One complication is that the notion of a device gets pretty
hazy given that we have the geom layer in between the syncer and the
hardware.  I'd still have a separate worklist for each mountpoint.
Multiple threads would allow us to better exploit the parallelism
provided by the hardware and prevent a slow drive from impacting the
performance of the other drives in the system.

> One mountpoint having trouble (of whatever kind) should not affect
> the rest of the mountpoints.
> 
> I'm not sure if the syncer is untangled enough that we can have
> per mount-point threads yet, but as soon as we can, we should do that.

I'm not aware of any fundamental issues preventing this from being
implemented, though I haven't spent much time looking at recent versions
of the code.