Hi Bart,
I think I understand what's going on in this case. There are actually
two issues:
a) allowing truncate to proceed after the permissions are revoked
b) returning enoent when the permission check finally fails
a) is tough if the acache is enabled. The acache is not consistent
across clients. For truncate this is particularly a problem because
datafiles don't store permission and the I/O servers therefore can't do
independent permission checking. We could modify truncate to force it
to get fresh permissions before proceeding. Maybe optionally at least.
b) is a bug. That is coming from a follow up operation (setattr or
getattr) after the truncate that has its permissions checked by the
metadata server. There is a problem there in which if all permission
checks fail on the server side PVFS returns enoent:
https://trac.mcs.anl.gov/projects/pvfs/ticket/104
It shouldn't be too hard to cook up a patch for each of these issues.
I'll look into it.
-Phil
Bart Taylor wrote:
Hey guys, we have run into another odd permissions case.
The problem happens when updating a user's access to a file while it is
still stored in another client's acache. In our test a client does an
ls, their write permissions are removed from another client, and while
the cache entry is still valid they try to overwrite the file. The
result is a truncated file of zero bytes with an ENOENT return value.
The test fails as expected and does not truncate the file if acache is
turned off.
Attached is a bash script that sets up the test for you, but it does
require manually running a couple of commands at the right time on
another client. Our clients are using an acache time out of 30 seconds.
To run:
Client1 - start the bash script and waith for the first prompt (
./perms-update-test.sh myuser mygroup /mnt/pvfs2 )
Client2 - execute an ls in the directory passed to the script ( from
/mnt/pvfs2: ls )
Client1 - wait for the second prompt
Client2 - overwrite the file (echo "text" > file1.txt)
Client1 - check the file size if file1.txt in the output
I also attached a server log that shows the truncate succeeding and
immediately calling setattr which fails. The server logging was turned
on only for the file overwrite.
Should the server be checking the file's permissions before the truncate
happens?
Bart.
------------------------------------------------------------------------
_______________________________________________
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
