[PVFS2-developers] Removing of a directory
pcarns at wastedcycles.org
Mon Dec 19 22:03:44 EST 2005
Ahh, you are right. I didn't realize that the attributes weren't read
until after removing the directory entry. With that being the case it
would have to come after step 2) as you say, although that isn't as
helpful as if we had the information earlier.
Sam Lang wrote:
> On Dec 16, 2005, at 1:57 PM, Phil Carns wrote:
>> That is a good point. As it turns out there is a cheap way to add
>> this extra check. sys-rename has a bit of code that looks like this
>> (which was part of a fix to some rename bugs I ran into a while back):
>> if(attr->objtype == PVFS_TYPE_DIRECTORY && attr- >u.dir.dirent_count
>> != 0)
>> js_p->error_code = -PVFS_ENOTEMPTY;
>> I think remove could do the same thing. sys-remove already retrieve
>> the attributes, so there is no extra cost involved in checking the
>> dirent_count on the client side before proceeding.
> Hi Phil,
> It looks like the directory entry gets removed before we actually get
> the attributes of the object. This prevents us from just checking the
> attrs right away before the rmdirent. I think I can add the check
> before doing the actual remove and after getting the attrs, but I
> wasn't sure that's exactly what you meant. The order of operations for
> a remove on a non-empty directory are:
> 1. rmdirent(object name,parent handle) => object handle
> 2. getattr(object handle) => attr
> 3. remove(object handle) => ENOTEMPTY
> 4. crdirent(object_handle)
> If I understand things correctly, your proposal was to put the check
> right after 2. This would prevent us from doing remove, but it would
> still be necessary to do the crdirent. Is that right?
>> There isn't any way to 100% protect against race conditions if
>> directory renames/removals are driven from the client, but this check
>> would help a lot.
>> Julian Martin Kunkel wrote:
>>> I have a question, if a client wants to remove a handle first the
>>> directory entry is removed and then the client verifies if a
>>> directory is going to be removed.
>>> If a non empty directory is going to be removed the client just
>>> creates the directory entry again for the parent directory, because
>>> it is not allowed to remove a non emtpy directory.
>>> Ok, but what happens with a filled directory if a client somehow
>>> breaks while trying to remove ? If it breaks after removing the
>>> dirent and before recreating the dirent, will the whole non-empty
>>> directory be lost ? Wouldn't it be better to first verify that the
>>> directory is empty ? I understand that after one client has verified
>>> the directory to remove is empty another client might create some
>>> files. So I think it would be better to verify the emptiness twice.
>>> Directories which already have some entries could be never messed up
>>> this way.
>>> Or is there already a cool mechanism I did not realize to circumvent
>>> that problem ?
>>> Thanks for your reply.
>>> Have a nice day,
>>> PVFS2-developers mailing list
>>> PVFS2-developers at beowulf-underground.org
>> PVFS2-developers mailing list
>> PVFS2-developers at beowulf-underground.org
> PVFS2-developers mailing list
> PVFS2-developers at beowulf-underground.org
More information about the PVFS2-developers