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

On  5 Mar, Poul-Henning Kamp wrote:
> Content-Type: text/plain; charset=ISO-8859-1
> --------
> In message <201303050519.r255JbAu012422_at_gw.catspoiler.org>, Don Lewis writes:
> 
>>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.
> 
> That would require that you move the syncer to the bottom of GEOM
> and initiate syncs by upcalls to the consumers above.  But how
> does that work in the case of a mirrored drive ?

... or even worse, raid5.

> Doesn't sound like a good idea to me.

I wasn't advocating anything like that, but something more like this
example:
	When we first boot, we mount /dev/ada0s1a to /.  We query geom to
	find the underlying device name for ada0s1a and find that it is
        ada0.  We find that we don't have a syncer thread for ada0, so
        we start one and attach the syncer worklist for / to the thread.

	Next we mount /dev/ada0s1h to /home.  We query geom to find the
	underlying device name and find that it is also ada0.  Since there
	is already a syncer thread for ada0, we just attach the /home
	worklist to this thread.

	Next we mount /dev/ada1s1a to /somewhere.  We query geom, find that
	there is no syncer thread for ada1, so we start one and attach the
	worklist for /somewhere to this thread.

For composite devices such as mirrors, using the first underlying device
is probably a reasonable choice.  For more complicated cases, or to
override the default, the syncer thread could be specified as a mount
option.

Each time it woke up, each syncer thread would walk through its list
of worklists, and for each worklist it would fsync all the vnodes in
the current bucket.

>>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.
> 
> It would also allow us to have different sync-intervals for different
> filesystems.

Yup, you could override the system default intervals using mount
options.