From owner-freebsd-current@FreeBSD.ORG Wed Mar 6 05:56:28 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9B472EE5; Wed, 6 Mar 2013 05:56:28 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6F49D26E; Wed, 6 Mar 2013 05:56:28 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id D515A1A3C2A; Tue, 5 Mar 2013 21:56:27 -0800 (PST) Message-ID: <5136DA87.8050408@mu.org> Date: Tue, 05 Mar 2013 21:56:23 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Don Lewis Subject: Re: access to hard drives is "blocked" by writes to a flash drive References: <201303060537.r265b3Kv014960@gw.catspoiler.org> In-Reply-To: <201303060537.r265b3Kv014960@gw.catspoiler.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: deeptech71@gmail.com, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, peter@rulingia.com, ian@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 05:56:28 -0000 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