Date: Mon, 4 Mar 2013 21:27:00 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: ian@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: <201303050527.r255R0Gd012437@gw.catspoiler.org> In-Reply-To: <1362410177.1195.234.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 Mar, Ian Lepore wrote: > 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. If your only drive is a single SD card, then you're pretty much hosed when I/O is blocked because the SD card is doing an erase. It can only handle one command at a time, and if a write blocks, there's nothing that we can do to get it to execute a read until it is done with the write command that it is hung up on. I'm not familiar with the lower layers, but things might be less bad if read ops can jump ahead and get sent to the drive before any queued writes.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201303050527.r255R0Gd012437>