Date: Mon, 4 Mar 2013 21:19:37 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: phk@phk.freebsd.dk Cc: kostikbel@gmail.com, deeptech71@gmail.com, freebsd-current@FreeBSD.org, peter@rulingia.com, ian@FreeBSD.org Subject: Re: access to hard drives is "blocked" by writes to a flash drive Message-ID: <201303050519.r255JbAu012422@gw.catspoiler.org> In-Reply-To: <25327.1362404670@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 Mar, Poul-Henning Kamp wrote: > Content-Type: text/plain; charset=ISO-8859-1 > -------- > In message <201303040712.r247CejP008718@gw.catspoiler.org>, Don Lewis writes: > >>Prior to 231160, the syncer thread would call sync_vnode() for the >>syncer vnode of each mountpoint every 30 seconds [...] > > I agree that the lemming syncer is better, but the fundamental mistake of > only having one syncer thread is probably the root-cause in this case: > One camera-grade flash syncing may take (a lot) more than 30 seconds. 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. One complication is that the notion of a device gets pretty hazy given that we have the geom layer in between the syncer and the hardware. I'd still have a separate worklist for each mountpoint. 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. > One mountpoint having trouble (of whatever kind) should not affect > the rest of the mountpoints. > > I'm not sure if the syncer is untangled enough that we can have > per mount-point threads yet, but as soon as we can, we should do that. I'm not aware of any fundamental issues preventing this from being implemented, though I haven't spent much time looking at recent versions of the code.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201303050519.r255JbAu012422>