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

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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"