slang at mcs.anl.gov
Mon Jun 12 19:34:14 EDT 2006
The new keyval code currently stores the size of a directory as a
separate common keyval. The server state machines update this value
with get/set state actions as needed (in crdirent,rmdirent,etc.).
This get and set actually prevents us from allowing the create and
delete operations of different files in the same directory to take
place concurrently, since the crdirent and rmdirent ops (on the
parent dirdata handle) get serialized.
I'd like to fix all this by providing a keyval per handle that
contains a null string as part of the key (I call it keyval-handle-
info). The advantage of making it the null string is that it will
appear first in the lexical ordering of directory entries, so I can
skip over it in readdir easily. This null keyval would only be
created on handles as necessary (right now only for counting
dirents). The TROVE_KEYVAL_HANDLE_COUNT ds flag can be passed to
trove operations, for example in the case of crdirent, the
TROVE_KEYVAL_HANDLE_COUNT and TROVE_NOOVERWITE flags would be passed
to the trove_keyval_write call and specify that the count should be
incremented (or created and set to 0 if it doesn't exist). rmdirent
would do something similar in trove_keyval_remove.
Also, at present the crdirent and rmdirent state machines first do a
read of the keyval to check for existence. This seems unnecessary.
Instead, the crdirent sm can just pass TROVE_NOOVERWITE to the
keyval_write call, and fail if that call fails. rmdirent already
fails if the keyval_remove fails so the extra keyval_read to check
for existence seems redundant. Are there any good reasons for those
extra state actions that I'm missing?
I've attached a patch of the changes I've described. I would like to
have this go in to the trunk before the upcoming release, since it
requires (yet another) storage format change. Let me know if there
are any questions or concerns.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 56612 bytes
Desc: not available
Url : http://www.beowulf-underground.org/pipermail/pvfs2-developers/attachments/20060612/2832fec9/keyval_get_handle_info-0001.obj
More information about the Pvfs2-developers