I am seeing the following problem with my filesystem:
Intermittently (and difficult to reproduce), files are not
getting
truncated. That is, file X is, say, 2k bytes. A process does
the
following then opens the file (with O_WRONLY _CREAT_TRUNC)
then
writes (fewer than 2k bytes) to it. The result is that the
file is now
still 2kbytes long, but the beginning of the file are the
new bytes.
Potential things about my setup that could be involved:
My filesystem is running on a a few different systems, each
of which
has NFS mounted the same directory from a server; it is this
mounted
directory that contains the "shadow filesystem"
that the operations
take place against. Could NFS attribute caching be a
factor?
I am running my filesystem as root with the following fuse
options:
"-o allow_other -o attr_timeout=0 -o
entry_timeout=1" Do I explicitly
need to say -o noauto_cache or is auto_cache turned off by
default?
My filesystem implements a very naive cache for stat results
-- at the
beginning of each operation handler function (myfs_open(),
myfs_getattr(), etc.) some thread-local storage is cleared
out that
can hold 2 stbufs; the first two paths that get stat()ed
servicing a
request get put in those stbufs; if either of those paths
need to get
stat()ed again during a request, the cached results are
used. This
stbuf is zeroed out at the beginning of myfs_open(),
myfs_truncate(),
etc.
Any thoughts or suggestions on diagnostics or debugging
would be helpful.
Thanks,
David
------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
fuse-devel mailing list
fuse-devel lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel
a>
|