NFS fixes from SPECsfs test runs
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest3 patches 0 repliesNew
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | Fix gfs2_block_truncate_page err return | +0 | 2 replies | |
| 3/3 | Remove i_mode passing from NFS File Handle | +0 | 1 reply | |
| 3/3 | Remove i_mode passing from NFS File Handle | +0 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [Cluster-devel] [GFS2 PATCH 0/3] NFS fixes from SPECsfs test runs
Red Hat bugzilla 243136 - bug fixes found during SPECsfs test runs:
[Patch 1-3] EIO error from gfs2_block_truncate_page
Code segment inside gfs2_block_truncate_page() doesn't set the return code correctly. This causes NFSD erroneously returns EIO back to client with setattr procedure call (truncate error),
[Patch 3-2] Obtaining no_formal_ino from directory entry GFS2 lookup code doesn't ask for inode shared glock. This implies during in-memory inode creation for existing file, GFS2 will not disk-read in the inode contents. This leaves no_formal_ino un-initialized during lookup time. The un-initialized no_formal_ino is subsequently encoded into file handle. Clients will get ESTALE error whenever it tries to access these files.
[Patch 3-3] Remove i_mode passing from NFS File Handle
GFS2 passes i_mode within NFS File Handle. Other than the wrong assumption that there is always room for this extra 16 bit value, the current gfs2_get_dentry doesn't really need the i_mode to work correctly. Note that GFS2 NFS code does go thru the same lookup code path as direct file access route (where the mode is obtained from name lookup) but gfs2_get_dentry() is coded for different purpose. It is not used during lookup time. It is part of the file access procedure call. When the call is invoked, if on-disk inode is not in-memory, it has to be read-in. This makes i_mode passing a useless overhead.
-- Wendy