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
