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 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
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
