[OpenAFS] sqlite on AFS will not work, even with whole-file locking

[Simon Wilkinson]

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.