[PATCH] Syncer rewriting

[Scott Long]

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