7:53 a.m.
I have an export (vfs fsal, the underlying fs is ext4) and initially things work ok, when
I do basic create/r/w files.
If I leave it for 20-30mins and do ls on the existing file it failes with stale file
handle.
I am using defaults for config, tried full logging for components but still no idea why it
finds the fh is bad.
8:32 a.m.
In case this is of any interest, ESTALE was not generated on the server side. Enabling
debug on the client side showed that while resolving the pathname, the fsid received was
seen as crossing the fs boundary, and resolve of the next part of the path was tried in
this new context and not found so the client said ESTALE.
Why was this happening and why only after some idle time (initially the same thing worked
ok) no idea, needs more testing. The point where it happened on the client is
nfs_xdev_get_sb function.
9:01 a.m.
That's interesting. I believe it means that the FSID that Ganesha sent
was changing. This shouldn't be happening. Do you have (or can you
get) a packet dump of the working and breaking cases? This may be a bug
in Ganesha afterall.
Daniel
On 11/28/19 9:32 AM, gstarovic(a)gmail.com wrote:
In case this is of any interest, ESTALE was not generated on the
server side. Enabling debug on the client side showed that while resolving the pathname,
the fsid received was seen as crossing the fs boundary, and resolve of the next part of
the path was tried in this new context and not found so the client said ESTALE.
Why was this happening and why only after some idle time (initially the same thing worked
ok) no idea, needs more testing. The point where it happened on the client is
nfs_xdev_get_sb function.
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
9:30 a.m.
In case this is of any interest, ESTALE was not generated on the
server side.
Enabling debug on the client side showed that while resolving the pathname, the
fsid received was seen as crossing the fs boundary, and resolve of the next part
of the path was tried in this new context and not found so the client said
ESTALE.
Why was this happening and why only after some idle time (initially the same
thing worked ok) no idea, needs more testing. The point where it happened on
the client is nfs_xdev_get_sb function.
In your first message, you indicated using FSAL_VFS and ext4. The fsid should be stable
from ext4 unless you have something unusual going on. Can you tell us more about your
setup?
As Daniel mentioned, a packet trace would help identify which inode is having its fsid
change.
Frank
8:59 a.m.
I don't see anything strange in my setup (export /mnt/scratch and mount that on /mnt,
no submounts), except maybe that the exported fs is on a devmap device; have a file with
some tracing info but don't see a way to send attachment to the list, can mail
directly. It has some things that look strange to me but it's probably just me.
1609
days inactive
1624
days old
4 comments
3 participants
participants (3)
-
Daniel Gryniewicz -
Frank Filz -
gstarovic＠gmail.com