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

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.