On 22 Apr 2010, at 08:42, Hans-Werner Paulsen wrote:
I do not know the exact semantics of the AFS filesystem, and
therefore I
do not know that it is a bug. Is it really a bug?
Running the following program on machine A
fd = open("xxx",O_RDONLY);
while (1) {
ret = fstat(fd,&buf);
printf("size: %d mtime: %s",
(int)buf.st_size,ctime(&(buf.st_mtime)));
sleep(1);
}
and modifying "xxx" on machine B (e.g. echo "J" >>xxx) reports me the
up-to-date information on machine A.
But, when I open the file with
fd = open("xxx",O_RDWR);
the stat-information is never updated.
This is on i386_linux26 with 1.4.12, but I have seen this behavior
forever.
Okay, I understand now. And you're right, this is somewhat strange
behaviour, which has been there for years. And it won't help in the
cooperative locking case, sadly.
When a file is opened RW, and is marked as being dirty, the Unix cache
manager stores all of that files details locally - it won't update
stat information in response to callback breaks, nor will it flush
pages that are already in memory, or invalidate chunks on disk. It
does this in an attempt to prevent locally made changes from being
overwritten by those on the server (because AFS is write-on-close, and
our conflict resolution strategy is last-closer-wins).
The fact that just opening the file is sufficient to mark it as dirty
seems like a bug to me (it's not clear from a quick glance at the code
why this is happening, although I wonder if it's related to an attempt
to set the atime).
In theory this behaviour would be mitigated, for the cooperating
processes case at least, by flushing every time we unlock. I haven't
yet checked whether we do so, or whether simply doing so is enough to
clear the dirty flag, but it should be.
S.
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
