Date: Mon, 04 Mar 2013 08:16:17 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Don Lewis <truckman@FreeBSD.org> Cc: deeptech71@gmail.com, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, peter@rulingia.com Subject: Re: access to hard drives is "blocked" by writes to a flash drive Message-ID: <1362410177.1195.234.camel@revolution.hippie.lan> In-Reply-To: <201303040301.r2431Rjm008175@gw.catspoiler.org> References: <201303040301.r2431Rjm008175@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1362410177.1195.234.camel>