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