There is an error in the "stuct stat: time of last modification" st_mtime
member when calling 'stat' on an NFS mounted file.
NFS server is a linux 2.4.21-pre5 SMP kernel with knfsd and nfs-utils 0.3.3
NFS client is a linux 2.4.20 and nfs-utils 1.0.3
It can take quiet a while before it happens, but basically:
while true
{
'stat' the file to get it's last modification time
fopen it
read on it
close it
}
once upon a time , the modification time will vary as this log shows:
Size : 9586 , time: 1068133738 <= Real time
Size : 9586 , time: 1068141476 <= Time got higher for a little while
Size : 9586 , time: 1068141476
Size : 9586 , time: 1068141476
Size : 9586 , time: 1068133738 <= Time got back to normal on file
All calls to 'stat' occured in the same second.
Is there any known issues regarding this ? Or any special care to take when
using 'stat' on an NFS mounted drive ?
Thanks in advance
Francois Isabelle
[email protected]
Concepteur de logiciel
Software designer
Kontron Canada
-------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == Francois Isabelle <Isabelle> writes:
> Size : 9586 , time: 1068133738 <= Real time Size : 9586 , time:
> 1068141476 <= Time got higher for a little while Size : 9586 ,
> time: 1068141476 Size : 9586 , time: 1068141476 Size : 9586 ,
> time: 1068133738 <= Time got back to normal on file
> All calls to 'stat' occured in the same second.
I assume nobody was writing to the file at the time (either on the
client or the server)?
Cheers,
Trond
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Exacly
Francois Isabelle
[email protected]
Concepteur de logiciel
Software designer
Kontron Canada
>-----Original Message-----
>From: Trond Myklebust [mailto:[email protected]]
>Sent: 7 novembre, 2003 12:22
>To: Isabelle, Francois
>Cc: '[email protected]'; David Roy-Moder (E-mail); Ryan. J.
>Kummet (E-mail)
>Subject: Re: [NFS] File modification bug (mismatch with stat)
>
>
>>>>>> " " == Francois Isabelle <Isabelle> writes:
>
> > Size : 9586 , time: 1068133738 <= Real time Size : 9586 , time:
> > 1068141476 <= Time got higher for a little while Size : 9586 ,
> > time: 1068141476 Size : 9586 , time: 1068141476 Size : 9586 ,
> > time: 1068133738 <= Time got back to normal on file
>
> > All calls to 'stat' occured in the same second.
>
>I assume nobody was writing to the file at the time (either on the
>client or the server)?
>
>Cheers,
> Trond
>
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
I know you said it was hard to reproduce, but could you still try to get
a tcpdump of this for me? Just do a standard binary dump using
tcpdump -w /tmp/dumpfile.out host blah and port 2049
while running your test (preferably with no other NFS traffic on that
client). Just stop the dump as soon as you see the problem.
Cheers,
Trond
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
I could but one major restriction I have is that the dump file will have to
be written to NFS since I'm running on a very small drive, this will result
in some NFS traffic on that client, will it be usefull anyways ?
>Message: 6
>Date: Fri, 7 Nov 2003 13:39:03 -0500
>To: "Isabelle, Francois" <[email protected]>
>Cc: "'[email protected]'" <[email protected]>,
> "David Roy-Moder (E-mail)" <[email protected]>,
> "Ryan. J. Kummet (E-mail)" <[email protected]>
>Subject: RE: [NFS] File modification bug (mismatch with stat)
>Reply-To: [email protected]
>From: Trond Myklebust <[email protected]>
>
>
>I know you said it was hard to reproduce, but could you still
>try to get
>a tcpdump of this for me? Just do a standard binary dump using
>
>tcpdump -w /tmp/dumpfile.out host blah and port 2049
>
>while running your test (preferably with no other NFS traffic on that
>client). Just stop the dump as soon as you see the problem.
>
>Cheers,
> Trond
>
>
>
>--__--__--
>
>_______________________________________________
>NFS maillist - [email protected]
>https://lists.sourceforge.net/lists/listinfo/nfs
>
>
>End of NFS Digest
>
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == Francois Isabelle <Isabelle> writes:
> I could but one major restriction I have is that the dump file
> will have to be written to NFS since I'm running on a very
> small drive, this will result in some NFS traffic on that
> client, will it be usefull anyways ?
Could you perhaps do the tcpdump on the server instead, then? That
should be alright in this case since we're not worried about dropped
requests.
Command is the same (tcpdump -w /tmp/dumpfile.out host blah and port 2049).
Just substitute client name for "blah".
Cheers,
Trond
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs