[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?
Thanks,
Jeff
> 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