VFS fsal and ESTALE
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.
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.
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@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@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
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
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.
participants (3)
-
Daniel Gryniewicz -
Frank Filz -
gstarovic＠gmail.com