+++ This bug was initially created as a clone of Bug #227610 +++ When a NFSv4 client requests a READDIR and the server hits an error while getting attributes for a directory entry, the server will return the error for the entire READDIR call. This isn't optimal, so we can and should set the "fattr4_rdattr_error" flag in the request to specify that the server should continue on and only report the error on the problem directory entries. -- Additional comment from jlayton on 2007-02-06 20:58 EST -- Created an attachment (id=147529) patch 1 -- preliminary patch to make needed one apply cleanly This patch makes the next one apply cleanly (and looks like it also fixes another potential bug). -- Additional comment from jlayton on 2007-02-06 21:00 EST -- Created an attachment (id=147530) patch 2 - set and handle fattr_rdattr_error attribute This patch fixes the problem, and allowing the server to return a more granular mix of valid results and errors. -- Additional comment from steved on 2007-02-21 09:45 EST -- Was there a reproducer for this problem? -- Additional comment from jlayton on 2007-02-21 10:09 EST -- Now that I think we have a resolution on bz228893, I think I might be able to get one. The way I reproduced it at connectathon was mounting a nfs4 directory that contained a referral export within it (hopefully I have the terminology correct here). When trying to do a readdirplus on the directory that contained the referral, the client would get an error back on the entire directory because this wasn't set. I was hoping I might be able to set up a similar situation by having a v4 root dir that exports a mix of directories to krb5 and krb5i exclusively, but haven't had time to reproduce it as of yet. -- Additional comment from jlayton on 2007-04-20 16:40 EST -- To reproduce, you'll need a Fedora 7 server (the server-side referral bits aren't yet in RHEL5): # mkdir /export # mkdir /export/fsloc # mount --bind /export/fsloc /export/fsloc # cat /etc/exports /export *(rw,nohide,insecure,fsid=0) /export/fsloc *(ro,nohide,insecure,refer=/foo.10.10) # service nfs start (server path and address don't really matter here since RHEL4 can't chase the referral anyway)... On the client: # mkdir -p /mnt/referral # mount -t nfs4 server:/ /mnt/referral # ls -l /mnt/referral # ls -l /mnt/referral ls: reading directory /mnt/referral: Input/output error total 0 ...you'll also get this in the ring buffer: nfs4_map_errors could not handle NFSv4 error 10019 ...the expectation is that you'll be able to list the contents of the directory, though the READDIRPLUS entry for the referral will come back with an error. -- Additional comment from jlayton on 2007-04-23 15:12 EST -- Actually, given my reproducer, only the first patch here is needed to fix this. I'll go ahead and propose that and hold off on the other one since I don't seem to have a situation that actually requires rdattr_error. -- Additional comment from jlayton on 2007-04-23 15:34 EST -- Expected results (with an empty file # ls -al /mnt/referral total 16 drwxr-xr-x 3 root root 4096 Apr 23 15:32 . drwxr-xr-x 12 root root 4096 Apr 20 11:58 .. ?--------- ? ? ? ? ? fsloc ...the directory entries are listable, but attempting to stat fsloc gives back a -EIO. I think this is the best we can do for RHEL4. Backporting the referral-chasing code is probably too much. -- Additional comment from jlayton on 2007-04-23 15:42 EST -- Patch 1 posted to RHKL: Subject: [RHEL4.6 PATCH] allow RHEL4 to do READDIR on directory containing a referral (BZ 227610) -- Additional comment from pm-rhel on 2007-04-23 15:45 EST -- This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. -- Additional comment from pm-rhel on 2007-04-23 16:02 EST -- This request was evaluated by Red Hat Kernel Team for inclusion in a Red Hat Enterprise Linux maintenance release, and has moved to bugzilla status POST. -- Additional comment from jlayton on 2007-09-05 17:41 EST -- Moving to 4.7. This patch was less critical, and we already had a lot of NFS patches for 4.6. -- Additional comment from pm-rhel on 2007-09-05 17:43 EST -- This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. -- Additional comment from vgoyal on 2008-03-27 19:21 EST -- Committed in 68.27.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
When I proposed the patch for bug 227610, Peter mentioned that we should consider the patch to add the rdattr_error attribute to NFS4 READDIR calls. I wasn't able to get it done and proposed in time for 4.7, so I've opened this to track whether we want to include it for 4.8. In general, it makes sense to me that we should request more granular errors in readdir calls. We don't in general want to have the entire READDIR error out just because one entry was bad. The only issue is that I don't have a clear situation/reproducer where this is needed. We'll probably need to concoct one for the QA group, so that may be the challenge here.
Created attachment 299505 [details] patch -- add support for rdattr_error in NFSv4 readdir Patch that adds support for this option. I've verified that it works by inspection, but if we want to include it, we probably need to come up with a clear situation that this fixes...
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Updating PM score.
Committed in 78.28.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: When a NFSv4 server is issued a READDIR call and has a problem getting info on one or more entries in a directory, it can either return an error for the entire readdir call or it can return what info it did find and flag the problem entries with an error. This behavior is governed by a flag in the READDIR call, which indicates how errors should be reported. This patch makes the RHEL4 NFSv4 client request and handle more granular error reporting.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,3 +1 @@ -When a NFSv4 server is issued a READDIR call and has a problem getting info on one or more entries in a directory, it can either return an error for the entire readdir call or it can return what info it did find and flag the problem entries with an error. +previously, when a NFSv4 (Network File System Version 4) client encountered issues while processing a directory using readdir(), an error for the entire readdir() call was returned. With this update, the "fattr4_rdattr_error" flag is now set when readdir() is called, instructing the server to continue on and only report an error on the specfic directory that was causing the issue.- -This behavior is governed by a flag in the READDIR call, which indicates how errors should be reported. This patch makes the RHEL4 NFSv4 client request and handle more granular error reporting.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -previously, when a NFSv4 (Network File System Version 4) client encountered issues while processing a directory using readdir(), an error for the entire readdir() call was returned. With this update, the "fattr4_rdattr_error" flag is now set when readdir() is called, instructing the server to continue on and only report an error on the specfic directory that was causing the issue.+previously, when a NFSv4 (Network File System Version 4) client encountered issues while processing a directory using readdir(), an error for the entire readdir() call was returned. With this update, the "fattr4_rdattr_error" flag is now set when readdir() is called, instructing the server to continue on and only report an error on the specfic directory entry that was causing the issue.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -previously, when a NFSv4 (Network File System Version 4) client encountered issues while processing a directory using readdir(), an error for the entire readdir() call was returned. With this update, the "fattr4_rdattr_error" flag is now set when readdir() is called, instructing the server to continue on and only report an error on the specfic directory entry that was causing the issue.+previously, when a NFSv4 (Network File System Version 4) client encountered issues while processing a directory using readdir(), an error for the entire readdir() call was returned. With this update, the "fattr4_rdattr_error" flag is now set when readdir() is called, instructing the server to continue on and only report an error on the specific directory entry that was causing the issue.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-1024.html