[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
strange nfs problem
Hi--
I'm having a strange NFS problem and it has been described by Sun as bugid
number 4183633 for Solaris 2.7 with the fix being upgrade to Solaris 8 (is
not an option)
or to use NFS version 2 which I tried and it did not solve the problem.
This file is mounted off of a netapp filer 630 running OS 5.2.3. Anyone
have any ideas ? Solaris 2.6 machines reports this file's last access
time as 12/31/69-- the day before the birth of UNIX.
Thanks,
--Melinda :o)
"Jumping from 18-wheelers can be a health hazard, safety experts warn."
-The Wall Street Journal
RPC: ----- SUN RPC Header -----
RPC:
RPC: Transaction id = 2711524856
RPC: Type = 0 (Call)
RPC: RPC version = 2
RPC: Program = 100003 (NFS), version = 3, procedure = 1
RPC: Credentials: Flavor = 1 (Unix), len = 68 bytes
RPC: Time = 04-Jan-00 05:21:41
RPC: Hostname = orff
RPC: Uid = 0, Gid = 1
RPC: Groups = 1 0 2 3 4 5 6 7 8 9 12
RPC: Verifier : Flavor = 0 (None), len = 0 bytes
RPC:
NFS: ----- Sun NFS -----
NFS:
NFS: Proc = 1 (Get file attributes)
NFS: File handle = [6E0A]
NFS: 40000000DB3767002000000000B93AA141058D0BB81C000040000000DB376700
[..snip..]
RPC: ----- SUN RPC Header -----
RPC:
RPC: Transaction id = 2711524856
RPC: Type = 1 (Reply)
RPC: This is a reply to frame 5
RPC: Status = 0 (Accepted)
RPC: Verifier : Flavor = 0 (None), len = 0 bytes
RPC: Accept status = 0 (Success)
RPC:
NFS: ----- Sun NFS -----
NFS:
NFS: Proc = 1 (Get file attributes)
NFS: Status = 0 (OK)
NFS: File type = 1 (Regular File)
NFS: Mode = 06777
NFS: Setuid = 1, Setgid = 1, Sticky = 0
NFS: Owner's permissions = rwx
NFS: Group's permissions = rwx
NFS: Other's permissions = rwx
NFS: Link count = 1, User ID = 60001, Group ID = 60001
NFS: File size = 0, Used = 0
NFS: Special: Major = 0, Minor = 0
NFS: File system id = 7352, File id = 12139169
NFS: Last access time = -1265632489.-1743781888
NFS: Modification time = 23-Dec-99 05:56:32.690000000 GMT
NFS: Attribute change time = 23-Dec-99 05:56:32.690000000 GMT
...The sane values for ctime and mtime suggest that this may not have gone
wacky at creation time. So the permissions are very odd, as is the atime
(and the file length is 0)..
nfs v3 spec is RFC1813 (http://www.faqs.org/rfcs/rfc1813.html). I guess
what we would be curious about from it is how the actual setting of the
atime works (does the client send a timestamp that the server is supposed
to blindly accept? does the client simply mention that it accessed the
file and the server updates things accordingly? ..or does the client even
know for sure that the atime is getting updated -- ie, it happens
automagically)
Now, for the gory details from the truss:
open64(0x000241B8, 04) = 3
0x000241B8: "."
fcntl(3, 2, 0x00000001) = 0
fstat64(3, 0xFFBEFBA0) = 0
d=0x02D00001 i=14471787 m=0040777 l=3 u=60001 g=60001 sz=4096
at = Dec 22 21:56:28 PST 1999 [ 945928588 ]
mt = Jan 3 18:42:09 PST 2000 [ 946953729 ]
ct = Jan 3 18:42:09 PST 2000 [ 946953729 ]
bsz=8192 blks=8 fs=nfs
getdents64(3, 0x0002DAF0, 1048) = 176
ino=14471787 off=1 rlen=24 "."
ino=9300341 off=2 rlen=24 ".."
ino=12139168 off=3 rlen=32 "_vti_cnf"
ino=12139169 off=4 rlen=32 "bottom.htm"
ino=12139171 off=5 rlen=32 "top.htm"
ino=12139172 off=4096 rlen=32 "left.htm"
This little snippet shows the directory being opened, and then we read all
of the contents of the directory (which returns inode numbers and names,
which we can then go and stat() to get their properties)
lstat64(0x00024220, 0xFFBEFBA0) = 0
0x00024220: "./_vti_cnf"
d=0x02D00001 i=12139168 m=0040777 l=2 u=60001 g=60001 sz=4096
at = Dec 22 21:56:29 PST 1999 [ 945928589 ]
mt = Jan 3 18:42:10 PST 2000 [ 946953730 ]
ct = Jan 3 18:42:10 PST 2000 [ 946953730 ]
bsz=8192 blks=8 fs=nfs
acl(0x00024220, 3, 0, 0x00000000) = 4
0x00024220: "./_vti_cnf"
lstat64(0x00024220, 0xFFBEFBA0) Err#79 EOVERFLOW
0x00024220: "./bottom.htm"
write(2, 0x00024220, 12) = 12
0x00024220: " . / b o t t o m . h t m"
write(2, 0xFF3227B0, 2) = 2
0xFF3227B0: " : "
write(2, 0xFF31F160, 37) = 37
V a l u e t o o l a r g e f o r d e f i n e d d a t a
t y p e
..here's a file that worked, and one that didn't. The first lstat64() is
on ./_vti_cnf, and it comes back with all kinds of normal looking things
-- atime, mtime, ctime, size, uid, gid, inode #, etc..
The second lstat64() (the one on ./bottom.htm, as we all know now), shits
itself. lstat64() returns, telling us that it was unable to complete
because of an overflowed value. Most likely, its because it saw that
crazy-assed atime (that we saw in the snoop), and knew that it couldn't
represent that appropriately.
So, the question remains... How did that atime get that way, and is it
related to the funky file perms, and the fact that the file is of 0
length.