[PATCH] Syncer rewriting

Jeff Roberson jroberson at jroberson.net
Sun Apr 18 02:37:30 UTC 2010

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?


> Scott
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"

More information about the freebsd-arch mailing list