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:
[EMAIL PROTECTED] 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 t
[EMAIL PROTECTED] 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
>
Pete Wyckoff wrote:
I've been debugging why the metadata server calls fdatasync() five
times during a single create operation. (IO server separate and
not considered here.)
In fs.conf, I had these StorageHints settings
TroveSyncMeta no
TroveSyncData no
CoalescingHighWatermark inf
I've been debugging why the metadata server calls fdatasync() five
times during a single create operation. (IO server separate and
not considered here.)
In fs.conf, I had these StorageHints settings
TroveSyncMeta no
TroveSyncData no
CoalescingHighWatermark infinity
CoalescingLowW
