[PATCH] Syncer rewriting
Scott Long
scottl at samsco.org
Sun Apr 18 02:46:59 UTC 2010
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
More information about the freebsd-arch
mailing list