From owner-freebsd-current@FreeBSD.ORG Wed Mar 6 05:37:20 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 53EACB20; Wed, 6 Mar 2013 05:37:20 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 3A66E1E9; Wed, 6 Mar 2013 05:37:19 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id r265b3Kv014960; Tue, 5 Mar 2013 21:37:07 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201303060537.r265b3Kv014960@gw.catspoiler.org> Date: Tue, 5 Mar 2013 21:37:03 -0800 (PST) From: Don Lewis Subject: Re: access to hard drives is "blocked" by writes to a flash drive To: ian@FreeBSD.org In-Reply-To: <1362499296.1291.6.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: deeptech71@gmail.com, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, peter@rulingia.com 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:37:20 -0000 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.