[Prev][Next][Index][Thread]
The fsnamespace cache doesn't work without multithread
Hi,
I have verified what I said last evening. The erroneous behaviour of the
fsnamespace object in a monothreaded program disappears when using the
multithreaded version of the fsnamespace library. I think there is
something to re-think there.
Nevertheless, I am having another trouble with the fsnamespace and my NFS
client. It is due to the fact that another client can do an unlink() on a
file and that the fsnamespace is not notified of it. So, when I do two
consecutive open() on the same file on the OSKit client and that the file
has been destroyed and re-created meanwhile by another client, I encounter
an error of stale handle in the read() following the second open() because
the cache didn't let the second lookup go to the server to get the new NFS
handle to the new version of the file.
The solution would be to disable the cache of the fsnamespace object. But
there is no way for the directory object to notify the fsnamespace object
that no cache should be used. Don't you think it should be permitted ?
There may be other solutions consisting in re-doing a new NFS lookup in
each query for the stream interface of a file, but would it not
unnecessarily overload the network ? And is it satisfactory ?
References: