All of lore.kernel.org
 help / color / mirror / Atom feed
* RE: [NFS PATCH] 2.6.0-test10 Invalidate cached inode attributes after rename
@ 2003-12-04  4:25 Lever, Charles
  2003-12-04 15:27 ` Shantanu Goel
  0 siblings, 1 reply; 6+ messages in thread
From: Lever, Charles @ 2003-12-04  4:25 UTC (permalink / raw)
  To: Paul Smith, Shantanu Goel; +Cc: nfs

> %% "Shantanu Goel" <Shantanu.Goel@lehman.com> writes:
>=20
>   sg> 1. Check out a CVS repository into an NFS mounted directory.
>   sg> 2. Move files from CVS working directory into another=20
> directory in the
>   sg> same filesystem.
>   sg> 3. Tar up the resultant directory.
>   sg> 4. Tar prints lots of "file changed after we read it" messages.
>=20
> Interesting: I see this exact same message when taring up the contents
> of a ClearCase view (in 2.4.20-x)... even though I'm 100%=20
> positive that
> no one but me is touching those files.  Is this scenario relevant to a
> kernel that old as well?

yes, steve dickson at red hat also found this problem in 2.4.21.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

^ permalink raw reply	[flat|nested] 6+ messages in thread
* RE: [NFS PATCH] 2.6.0-test10 Invalidate cached inode attributes after rename
@ 2003-12-04 15:34 Lever, Charles
  2003-12-04 17:20 ` Paul Smith
  0 siblings, 1 reply; 6+ messages in thread
From: Lever, Charles @ 2003-12-04 15:34 UTC (permalink / raw)
  To: Shantanu Goel; +Cc: Paul Smith, nfs

i'll state this more carefully --

the problem is exposed after trond's readdirplus patch is
applied to 2.4.2x.

> -----Original Message-----
> From: Shantanu Goel [mailto:Shantanu.Goel@lehman.com]
> Sent: Thursday, December 04, 2003 10:27 AM
> To: Lever, Charles
> Cc: Paul Smith; nfs@lists.sourceforge.net
> Subject: Re: [NFS] [NFS PATCH] 2.6.0-test10 Invalidate cached inode
> attributes after rename
>=20
>=20
> Stock 2.4 kernels don't exhibit this behaviour because they always=20
> invalidate attributes for the last component of the path if CTO is=20
> enabled, see fs/nfs/dir.c:nfs_lookup_verify_inode().  In 2.6 and 2.4=20
> kernels such as AS3's 2.4.21, with the newer CTO patches,=20
> this code was=20
> changed to only do so when the file is being opened.  I am=20
> surprised you=20
> are seeing this on 2.4.20 since I can't replicate it on 2.4.22.
>=20
> Shantanu
>=20
> Lever, Charles wrote:
>=20
> >>%% "Shantanu Goel" <Shantanu.Goel@lehman.com> writes:
> >>
> >>  sg> 1. Check out a CVS repository into an NFS mounted directory.
> >>  sg> 2. Move files from CVS working directory into another=20
> >>directory in the
> >>  sg> same filesystem.
> >>  sg> 3. Tar up the resultant directory.
> >>  sg> 4. Tar prints lots of "file changed after we read it"=20
> messages.
> >>
> >>Interesting: I see this exact same message when taring up=20
> the contents
> >>of a ClearCase view (in 2.4.20-x)... even though I'm 100%=20
> >>positive that
> >>no one but me is touching those files.  Is this scenario=20
> relevant to a
> >>kernel that old as well?
> >>   =20
> >>
> >
> >yes, steve dickson at red hat also found this problem in 2.4.21.
> >
> > =20
> >
>=20
>=20
>=20
> --------------------------------------------------------------
> ----------------
> This message is intended only for the personal and=20
> confidential use of the
> designated recipient(s) named above.  If you are not the=20
> intended recipient of
> this message you are hereby notified that any review, dissemination,
> distribution or copying of this message is strictly prohibited.  This
> communication is for information purposes only and should not=20
> be regarded as
> an offer to sell or as a solicitation of an offer to buy any financial
> product, an official confirmation of any transaction, or as=20
> an official
> statement of Lehman Brothers.  Email transmission cannot be=20
> guaranteed to be
> secure or error-free.  Therefore, we do not represent that=20
> this information is
> complete or accurate and it should not be relied upon as such.  All
> information is subject to change without notice.
>=20
>=20


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

^ permalink raw reply	[flat|nested] 6+ messages in thread
* [NFS PATCH] 2.6.0-test10 Invalidate cached inode attributes after rename
@ 2003-11-26 19:41 Shantanu Goel
  2003-12-04  0:42 ` Paul Smith
  0 siblings, 1 reply; 6+ messages in thread
From: Shantanu Goel @ 2003-11-26 19:41 UTC (permalink / raw)
  To: nfs

Hi Trond et al,

The following one line patch invalidates the attributes of the 
underlying inode when a file is renamed.  Some filesystems update ctime 
upon rename().  One such filesystem is ext3, and a comment in the 
relevant code there indicates this is true with other Unix filesystems 
as well.
The following problem was observed on Fedora Core 1 running a stock 
kernel.org 2.6.0-test10.
The server is running Solaris 2.8 but I have verified the same issue 
exists with a server running Linix 2.4.22.  These operations a done via 
a Perl script.

1. Check out a CVS repository into an NFS mounted directory.
2. Move files from CVS working directory into another directory in the 
same filesystem.
3. Tar up the resultant directory.
4. Tar prints lots of "file changed after we read it" messages.

Tar obtains ctime via stat() before reading the file and compares it to 
the ctime obtained via fstat() after having read the file.  The two 
differ because the intervening open() forces an attribute refresh due to 
CTO consistency at which time ctime is updated.  Forcing a cache 
invalidation during rename() eliminates this particular scenario.

Thanks,
Shantanu

--- 2.6.0-test10/fs/nfs/dir.c.~1~    2003-10-17 17:43:11.000000000 -0400
+++ 2.6.0-test10/fs/nfs/dir.c    2003-11-26 12:42:27.000000000 -0500
@@ -1257,6 +1257,7 @@
 
     nfs_zap_caches(new_dir);
     nfs_zap_caches(old_dir);
+    NFS_CACHEINV(old_inode);
     error = NFS_PROTO(old_dir)->rename(old_dir, &old_dentry->d_name,
                        new_dir, &new_dentry->d_name);
 out:



------------------------------------------------------------------------------
This message is intended only for the personal and confidential use of the
designated recipient(s) named above.  If you are not the intended recipient of
this message you are hereby notified that any review, dissemination,
distribution or copying of this message is strictly prohibited.  This
communication is for information purposes only and should not be regarded as
an offer to sell or as a solicitation of an offer to buy any financial
product, an official confirmation of any transaction, or as an official
statement of Lehman Brothers.  Email transmission cannot be guaranteed to be
secure or error-free.  Therefore, we do not represent that this information is
complete or accurate and it should not be relied upon as such.  All
information is subject to change without notice.



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-12-04 17:21 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-12-04  4:25 [NFS PATCH] 2.6.0-test10 Invalidate cached inode attributes after rename Lever, Charles
2003-12-04 15:27 ` Shantanu Goel
  -- strict thread matches above, loose matches on Subject: below --
2003-12-04 15:34 Lever, Charles
2003-12-04 17:20 ` Paul Smith
2003-11-26 19:41 Shantanu Goel
2003-12-04  0:42 ` Paul Smith

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.