Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 05 Mar 2013 06:38:55 +0000
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        Don Lewis <truckman@FreeBSD.org>
Cc:        kostikbel@gmail.com, deeptech71@gmail.com, freebsd-current@FreeBSD.org, peter@rulingia.com, ian@FreeBSD.org
Subject:   Re: access to hard drives is "blocked" by writes to a flash drive
Message-ID:  <28305.1362465535@critter.freebsd.dk>
In-Reply-To: <201303050519.r255JbAu012422@gw.catspoiler.org>
References:  <201303050519.r255JbAu012422@gw.catspoiler.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Content-Type: text/plain; charset=ISO-8859-1
--------
In message <201303050519.r255JbAu012422@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 ?

Doesn't sound like a good idea to me.

>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.

>> 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.

It used to be impossible because of all the implicit locking based on
pseudo-vnodes and whats-not...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?28305.1362465535>