Bug 108088 - NFSV3 shares appear to corrupt file attributes
Summary: NFSV3 shares appear to corrupt file attributes
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Brian Brock
Depends On:
Blocks: 107562 107565
TreeView+ depends on / blocked
Reported: 2003-10-27 15:41 UTC by Neil Horman
Modified: 2007-11-30 22:06 UTC (History)
4 users (show)

Fixed In Version: RHEL 3 u1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-01-21 14:55:19 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Neil Horman 2003-10-27 15:41:51 UTC
Description of problem:
NFS V3 appears to corrupt file attributes when rename is used on files in
mounted directories

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.mount an NFS directory specifying version 3 of the protocol
2.create a file in that directory
3.use the rename utility to change its name
4.use the tar utility to place the file in an archive
Actual results:
tar will fail indicating that the file has changed while its being read

Expected results:
tar should correctly create the archive

Additional info:

Comment 1 Steve Dickson 2003-10-27 22:26:49 UTC
Using a 2.4.21-4.ELsmp I'm unable to reproduce the bug
Here is what I'm doing:
pro3# mount ppro1:/home /mnt/ppro1/home
pro3$ cd /mnt/ppro1/home/tmp
pro3$ touch foo1
pro3$ rename foo foo0 foo?
pro3$ tar cvf /tmp/tar.tar foo01

Comment 2 Don Howard 2003-10-29 17:48:53 UTC
It looks like the customer used perl's builtin rename() function, rather than /usr/bin/rename. 
Could be that they handle file attributes differently? 

Comment 3 Don Howard 2003-10-29 20:00:41 UTC
[dhoward@porkchop 28730]$ mkdir foo 
[dhoward@porkchop 28730]$ cvs co rh-rpms/kernel-2.4 
[dhoward@porkchop 28730]$ rename rh-rpms/kernel-2.4/ foo/ rh-rpms/kernel-2.4/* 
[dhoward@porkchop 28730]$ tar cvf foo.tar.gz foo 
tar: foo/COPYING.modules: file changed as we read it 
tar: foo/Makefile: file changed as we read it 
tar: foo/Makefile.config: file changed as we read it 
tar: foo/Makefile.defs: file changed as we read it 
tar: foo/Makefile.project: file changed as we read it 

Comment 7 Frank Hirtz 2003-11-12 18:52:32 UTC
A couple of notes from the customer:

Yet another data point for what it's worth.  I have reproduced the
same issue with Arjan's 2.6 test kernel rpm (2.6.0-0.test9.1.67).  I
booted the kernel on RHEL3.


I looked into this problem a bit further.  It doesn't look like the
CTO patches are the cause since 2.6 lacks them.  However, both kernels
have the READDIRPLUS patch which introduces a separate attribute cache
that is not updated when operations are performed on an open file. 
The relevant routine is dir.c:nfs_cached_lookup() in both kernels.  I
believe this is the source of our troubles.  It would also explain
Frank's observation that NFSv2 does not exhibit the inconsistency
since READDIRPLUS does not exist in v2.  Below is a short perl script
that reproduces the problem.  This is very close to the way tar does
the ctime check.  The script fails reliably on the very first
comparision of ctime.  The stat("junk") is presumably going through
the READDIRPLUS attribute cache whereas stat(F) is using the inode cache.

#!/usr/bin/perl -w

use strict;

open(F, ">junk");
open(X, "/etc/redhat-release");
while (<X>) {
   print F $_;
my $prev_ctime = (stat("junk"))[10];
for (my $i = 0; $i < 60; $i++) {
   sleep 1;
   open(F, "junk");
   my $ctime = (stat(F))[10];
   if ($ctime != $prev_ctime) {
       print "$i: $ctime != $prev_ctime\n";

Comment 8 Neil Horman 2004-01-06 21:08:34 UTC
So is this now fixed in both RHEL3 and the latest errata from RHEL2.1?

Comment 9 David Joo 2004-01-08 00:43:39 UTC

I went to ABC with a setup of test environment used
"kernel-smp-2.4.21-6.EL.i686.rpm" but that didn't solve the issue.
The symptom got reproduced.

I may suggest them to test with kernel-smp-2.4.21-7.EL.i686.rpm and
see what happens.

Comment 10 Steve Dickson 2004-01-08 13:41:47 UTC

Could you please post a ethereal trace of the this problem... 

Comment 11 Don Howard 2004-01-19 20:24:27 UTC
The issue at ABC is different from what is reported in this ticket.  
ABC's issue shows up under both v2 and v3. It appears to be related 
to timestamp resolution and asynchronous update/read of files. 
If I can reproduce what they report I'll open a seperate bugzilla. 
I can't reproduce this issue. The test case appears to be fixed. 

Comment 13 Ernie Petrides 2004-12-03 02:14:43 UTC
An errata 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 the 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.


Note You need to log in before you can comment on or make changes to this bug.