Date: Sat, 17 Apr 2010 20:46:55 -0600 From: Scott Long <scottl@samsco.org> To: Jeff Roberson <jroberson@jroberson.net> Cc: Attilio Rao <attilio@freebsd.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Giovanni Trematerra <giovanni.trematerra@gmail.com>, freebsd-arch@freebsd.org Subject: Re: [PATCH] Syncer rewriting Message-ID: <91973FF7-4067-43ED-A20C-14B7B7D78449@samsco.org> In-Reply-To: <alpine.BSF.2.00.1004171606410.1398@desktop> References: <29917.1271406183@critter.freebsd.dk> <F335207A-4AE3-4993-8CC7-16CCEE425BC4@samsco.org> <alpine.BSF.2.00.1004171606410.1398@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 17, 2010, at 8:08 PM, Jeff Roberson wrote: > On Sat, 17 Apr 2010, Scott Long wrote: >=20 >> On Apr 16, 2010, at 2:23 AM, Poul-Henning Kamp wrote: >>>=20 >>>=20 >>>> - The standard syncer may be further improved getting rid of the >>>> bufobj. It should actually handle a list of vnodes rather than a = list >>>> of bufobj. However similar optimizations may be done after the = patch >>>> is ready to enter the tree. >>>=20 >>> That would be the wrong direction: we need the bufobj because for = instance >>> a RAID5 geom module does not have a vnode for the parity data. >>>=20 >>> If you force the syncer to only work on vnodes, then we need a = parallel >>> mechanism for non-filesystem disk users. >>=20 >> It's been 5-6 (7?) years since you invented the bufobj, but I still = haven't seen >> anything in GEOM use it as you suggest. You used to have a saying = about >> premature optimization... I'd like to see Attilio's work move = forward despite this. >>=20 >=20 > I tend to agree. I also think the syncer is inherently a vnode = centric operation. RAID5 should have its own rules and optimizations = for managing its dirty data. It would have to anyway to keep the disk = state consistent. Wouldn't it be a write through cache anyway and only = keep clean data in core? No, the fundamental idea behind RAID-5 caching is that is should try to = hold onto write buffers in an effort to collect enough to do a full = stripe write, instead of having to do a read-modify-write. So yes, = dirty buffers must be cached. However, I agree that the caching and = syncing policy here is likely to be completely different from what the = syncer might think is appropriate. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?91973FF7-4067-43ED-A20C-14B7B7D78449>