Date: Tue, 05 Mar 2013 21:56:23 -0800 From: Alfred Perlstein <bright@mu.org> To: Don Lewis <truckman@FreeBSD.org> Cc: deeptech71@gmail.com, phk@phk.freebsd.dk, 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: <5136DA87.8050408@mu.org> In-Reply-To: <201303060537.r265b3Kv014960@gw.catspoiler.org> References: <201303060537.r265b3Kv014960@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/5/13 9:37 PM, Don Lewis wrote: > On 5 Mar, Ian Lepore wrote: > >> I've debated playing with the bio work loop in mmcsd to see if moving >> reads ahead of writes was helpful, but that seems like a dangerous path >> to go down without some mitigation strategy to ensure that writes go >> through eventually. That seems especially important when you consider >> that writes may be necessary to free up memory to un-wedge other things >> that are waiting. (Yeah, people don't often use sd cards as swap >> storage, but I've done so in a pinch.) All in all, I've never pursued >> it because it feels like the wrong layer to address the problem at. > I was initially concerned about the memory starvation problem, but I > don't think it's an issue. If memory is unavailable, then the upper > layer won't be able to allocate the buffer memory for the read requests > and will block before sending any more read commands down to the driver. > > I think that large numbers of reads causing write starvation are also > unlikely. A single thread can generate a large backlog of writes > (unless the filesystem is mounted in sync mode), but it generally can't > queue up a lot of reads because the thread is likely to block every time > it issues a read request until it gets the data back from the drive. If > you are still worried about this, you could maintain separate read and > write queues and alternate between them if both are nonempty. > > What if we ran reads and writes over the loopback via TCP to get some kind of windowing? :) I am only half kidding... it would make sense to look to TCP to allow for some kind of window of IO based on throughput to the device. -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5136DA87.8050408>