[Pvfs2-developers] CoalescingLowWatermark setting

[Rob Ross]

as an aside, the accepted way to hide this sync cost is preallocation of 
unused objects. just keep them around and drop them into place when needed.

that would cost one direntry write and sync, plus perhaps another 
write/sync to note that the object isn't unused any more.

rob

Sam Lang wrote:
> 
> 
> Pete Wyckoff wrote:
>> slang at mcs.anl.gov wrote on Thu, 21 Sep 2006 11:20 -0500:
>>> That said, the code you are referring to will behave in the way you 
>>> described under 'low load' conditions.  If there are no other 
>>> operations in the dbpf op queue marked TROVE_SYNC (or less than 
>>> whatever LWM is set to) when that second check is made, we sync.
>>
>> Thanks for the explanation.  I see what your intent is now with this
>> low watermark, just to keep things a bit more in-sync when load is
>> low.
>>
>>> Just curious, you mentioned 5 calls to fdatasync() in a single 
>>> create. That _should not_ happen, and is a bug if it does.  Its the 
>>> db->sync call that we make 5 times (potentially, depending on 
>>> parameters and load).  Are you seeing fdatasync() for metadata 
>>> operations?  Also, have you see a big drop in metadata performance?
>>
>> I meant single create from the client sysint point of view.  As you
>> saw, that's three requests under the hood, with 1 + 2 + 2 = 5 total
>> syncs across the three requests.
>>
>> We did talk about transactions before.  Seems like the way to go if
>> this becomes an issue for people in real life.  I'm just running
>> benchmarks now.
>>
>> Metadata performance has not dropped as far as I can tell.  It's
>> just that we've been taking a closer look at MD operations and found
>> big timing variations due to the presence of sync operations.  First
>> cut was just to turn off disk effects, which led to my confusion
>> about what the watermarks meant.  (They're marks on different water
>> levels:  pending unprocessed sync-requiring ops, and total dirty
>> unsynced ops present in database.)
> 
> Exactly.  They're admittedly not the best names, and some of the only 
> options in server-config.c that I haven't documented yet.  If it makes 
> sense to change the names to something else, I'll be all for it.  We 
> could probably keep the old ones privately for backwards compatibility.
> 
> -sam
> 
>>
>>         -- Pete
>>
> _______________________________________________
> Pvfs2-developers mailing list
> Pvfs2-developers at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>