On Tue, Dec 13, 2011 at 07:03:45AM +0000, Ben Hutchings wrote:
> On Thu, 2011-12-01 at 14:52 +0100, Mirco Bauer wrote:
>> tags 633526 + patch
>> retitle 633526 NFS client uid/gid cache broken on VServer kernels
>> thanks
>> Herbert Poetzl wrote:
>>> we now understand the problem, and it was fixed for
>>> 3.0.4 with the following patch:
>>> http://vserver.13thfloor.at/ExperimentalT/delta-nfs-fix02.diff
>> I can confirm that this patch is fixing the issue. I have
>> tested the patch on top of linux-2.6 2.6.32-37 on a production
>> server and we no longer experience the NFS uid/gid issue.
>> The issue can easily be tested by doing "ls -l $file" on a NFS
>> mount. The values will show up correctly. After "cat $file >
>> /dev/null; ls -l $file" it will suddenly show wrong uid/gid
>> values of: 4294967294/4294967294 (-2/-2) Waiting for about 20
>> seconds "ls -l $file" will show again correct values. So the
>> client cached values are clearly the problem.
>> I strongly recommend to include the patch into the next stable
>> point release as this is major NFS regression from Debian
>> Lenny.
> I'll update to vs2.6.32.48-vs2.3.0.36.29.8 which includes the
> above and one other NFS fix
> <http://vserver.13thfloor.at/ExperimentalT/delta-nfs-fix01.diff>.
> Herbert, if you could briefly explain what the two changes are
> doing that would be helpful.
well, the first one fixes a long outstanding bug, which
was caused by using the wrong macros INOTAG_* instead
of TAGINO_*, which, depending on the tagging and actual
uid/gid/tag will result in funny numbers ...
the second one doesn't fix any real issue, but it is a
more defensive solution for the potentially possible
case where NFS_ATTR_FATTR_OWNER is set but the group
nfs attribute is not (or the other way round)
HTH,
Herbert
> Ben.
> --
> Ben Hutchings
> Computers are not intelligent. They only think they are.
Received on Tue Dec 13 18:04:39 2011