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

Ian Lepore ian at FreeBSD.org
Mon Mar 4 15:16:22 UTC 2013


On Sun, 2013-03-03 at 19:01 -0800, Don Lewis wrote:
> On  3 Mar, Poul-Henning Kamp wrote:
> 
> > For various reasons (see: Lemming-syncer) FreeBSD will block all I/O
> > traffic to other disks too, when these pileups gets too bad.
> 
> The Lemming-syncer problem should have mostly been fixed by 231160 in
> head (231952 in stable/9 and 231967 in stable/8) a little over a year
> ago. The exceptions are atime updates, mmaped files with dirty pages,
> and quotas. Under certain workloads I still notice periodic bursts of
> seek noise. After thinking about it for a bit, I suspect that it could
> be atime updates, but I haven't tried to confirm that.
> 
> When using TCQ or NCQ, perhaps we should limit the number of outstanding
> writes per device to leave some slots open for reads.  We should
> probably also prioritize reads over writes unless we are under memory
> pressure.
>  

Then either those changes didn't have the intended effect, or the
problem we're seeing with lack of system responsiveness when there's a
large backlog of writes to a slow device is not the lemming-syncer
problem.  It's also not a lack of TCQ/NCQ slots, given that no such
thing exists with SD card IO.

When this is going on, the process driving the massive output spends
almost all its time in a wdrain wait, and if you try to launch an app
that isn't already in cache, a siginfo generally shows it to be in a
getblk wait.

-- Ian




More information about the freebsd-current mailing list