Date: Tue, 5 Mar 2013 21:37:03 -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: <201303060537.r265b3Kv014960@gw.catspoiler.org> In-Reply-To: <1362499296.1291.6.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201303060537.r265b3Kv014960>