From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 08:40:54 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 8B9BF816; Tue, 5 Mar 2013 08:40:54 +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 57001973; Tue, 5 Mar 2013 08:40:53 +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 r258egAG012697; Tue, 5 Mar 2013 00:40:46 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201303050840.r258egAG012697@gw.catspoiler.org> Date: Tue, 5 Mar 2013 00:40:42 -0800 (PST) From: Don Lewis Subject: Re: access to hard drives is "blocked" by writes to a flash drive To: phk@phk.freebsd.dk In-Reply-To: <28305.1362465535@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: kostikbel@gmail.com, deeptech71@gmail.com, 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: Tue, 05 Mar 2013 08:40:54 -0000 On 5 Mar, Poul-Henning Kamp wrote: > Content-Type: text/plain; charset=ISO-8859-1 > -------- > In message <201303050519.r255JbAu012422@gw.catspoiler.org>, Don Lewis writes: > >>That's been my opinion for a long time as well, though I think it would >>be better to have one thread per device to avoid syncer threads for >>multiple partitions on the same drive all contending for the same >>actuator. > > That would require that you move the syncer to the bottom of GEOM > and initiate syncs by upcalls to the consumers above. But how > does that work in the case of a mirrored drive ? ... or even worse, raid5. > Doesn't sound like a good idea to me. I wasn't advocating anything like that, but something more like this example: When we first boot, we mount /dev/ada0s1a to /. We query geom to find the underlying device name for ada0s1a and find that it is ada0. We find that we don't have a syncer thread for ada0, so we start one and attach the syncer worklist for / to the thread. Next we mount /dev/ada0s1h to /home. We query geom to find the underlying device name and find that it is also ada0. Since there is already a syncer thread for ada0, we just attach the /home worklist to this thread. Next we mount /dev/ada1s1a to /somewhere. We query geom, find that there is no syncer thread for ada1, so we start one and attach the worklist for /somewhere to this thread. For composite devices such as mirrors, using the first underlying device is probably a reasonable choice. For more complicated cases, or to override the default, the syncer thread could be specified as a mount option. Each time it woke up, each syncer thread would walk through its list of worklists, and for each worklist it would fsync all the vnodes in the current bucket. >>Multiple threads would allow us to better exploit the parallelism >>provided by the hardware and prevent a slow drive from impacting the >>performance of the other drives in the system. > > It would also allow us to have different sync-intervals for different > filesystems. Yup, you could override the system default intervals using mount options.