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: > >> On Apr 16, 2010, at 2:23 AM, Poul-Henning Kamp wrote: >>> >>> >>>> - 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. >>> >>> 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. >>> >>> If you force the syncer to only work on vnodes, then we need a parallel >>> mechanism for non-filesystem disk users. >> >> 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. >> > > 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>