We just ran across a strange happening on our F760 filer. One of our folks did a "du -s" on an RCS directory to see how much space it was using:
=> du -s RCS du: RCS/ParseNVP.pm,v: Value too large for defined data type
And got a strange error. In fact, pretty much anything that would do a stat(2) call on this file in this directory would generate the same error message. There were no errors logged on the filer and all weekly messages seem to indicate that all is well, but it still puzzles me.
I ran off for the requisite caffine boost and came back and am now unable to reproduce the problem. I asked the user if they perhaps did something such as recreating the RCS directory from another source... they hadn't.
The file which was complained about is a mere 3422 bytes, and all timestamps indicate that the file has not changed recently.
Has anybody else seen this problem or have any ideas on how/why this may have occurred?
For what it's worth, the NFS client accessing the files is running Solaris 5.7. I unfortunately didn't pop over to one of my BSD boxes before the problem worked itself out.
~mitch
mitch asked>
We just ran across a strange happening on our F760 filer. One of our folks did a "du -s" on an RCS directory to see how much space it was using:
=> du -s RCS du: RCS/ParseNVP.pm,v: Value too large for defined data type
I've seen this error on Solaris boxes running 32-bit code, such as GNU ls, when they are accessing Netapp volumes and directories with very large files (>2GB.)
I've also seen this on Solaris clients when accessing files on a Linux fileserver, when the dates were outrageously wrong on the file. Like a year of 1935!
If you see this again you might want to look at atime, mtime and ctime to see if something is strange. I've appended a Perl script below called `stat' that will show you all sorts of good things (or bad things), and that may help.
But I don't have a silver bullet for you -- your description does not match what I've seen, unless you did not notice wacky file dates. (ls -l, ls -cl, ls -ul) Was the system clock off on the client?
And got a strange error. In fact, pretty much anything that would do a stat(2) call on this file in this directory would generate the same error message. There were no errors logged on the filer and all weekly messages seem to indicate that all is well, but it still puzzles me.
I ran off for the requisite caffine boost and came back and am now unable to reproduce the problem. I asked the user if they perhaps did something such as recreating the RCS directory from another source... they hadn't.
The file which was complained about is a mere 3422 bytes, and all timestamps indicate that the file has not changed recently.
Has anybody else seen this problem or have any ideas on how/why this may have occurred?
For what it's worth, the NFS client accessing the files is running Solaris 5.7. I unfortunately didn't pop over to one of my BSD boxes before the problem worked itself out.
~mitch
#!/tool/pandora/.package/perl-5.6.0/bin/perl # # Last edited: Mon Oct 5 11:48:02 1992 by Tim Wilson # $Id: stat,v 1.1 1992/10/05 10:53:13 tdw Exp $ # # Stat(2) files and print results. # # Usage: stat [-?] [-l] [-n] [-h] [--] files... # # -l: use lstat(2) instead of stat(2) # -n: print output in numeric format (instead of readable format) # -h: if in numeric format, also print header line # -?: print help message # --: remaining arguments are file names # ###################################################################### # # Copyright (C) 1992 T D Wilson. All rights reserved. # # Permission to copy without fee all or part of this material is # granted provided that the copies are not made or distributed for # direct commercial advantage, the copyright notice and the title and # date appear, and notice is given that copying is by permission of # the author. To copy otherwise, or to republish, requires specific # permission. # # T D Wilson makes no representations about the suitability of this # software for any purpose. It is provided "as is" without express or # implied warranty. # ###################################################################### # # Modification summary: # 5 Oct 1992 Tim Wilson Altered comments; posted to # alt.sources. Revision 1.1. # 11 Jul 1991 Tim Wilson Created. # # Tim Wilson, University of Cambridge Computer Laboratory, UK. # tdw@cl.cam.ac.uk #
sub usage { die "Usage: $progname [-l] [-n] [-h] [--] files...\n"; }
sub Lstat { ($st_dev,$st_ino,$st_mode,$st_nlink,$st_uid,$st_gid,$st_rdev,$st_size, $st_atime,$st_mtime,$st_ctime,$st_blksize,$st_blocks) = lstat(shift(@_)); }
require "stat.pl"; require "ctime.pl";
###################################################################### # # p_perm -- Return part permissions symbolically # # perm: Permissions. Only the low three bits are significant # extra: Extra bit to be encoded with execute (suid, sgid, sticky) # c: Character to be used instead of `x' (`s' or `t') # # Returns -- three character string # # Side effects -- Output # ######################################################################
sub p_perm { local ($perm,$extra,$c) = @_; local ($lower,$upper) = ($c, $c); local ($result); $lower =~ tr/ST/st/; # Guaranteed lower case `s' or `t' $upper =~ tr/st/ST/; # Guaranteed upper case `S' or `T'
$result = ($perm & 04) ? "r" : "-"; $result .= ($perm & 02) ? "w" : "-"; # Want 2D array; do index arithmetic ourselves $result .= ("-", "x", $upper, $lower)[!!$extra * 2 + ($perm & 01)]; }
###################################################################### # # p_mode -- Return symbolic $st_mode (and/or memorized stat structure) # # Arguments are global variables. Ahem! # # Returns -- ten character string # # Side effects -- Output # ######################################################################
sub p_mode { local ($result); # First letter according to type of file TYPE: { -p _ && do {$result = "p"; last TYPE;}; -c _ && do {$result = "c"; last TYPE;}; -d _ && do {$result = "d"; last TYPE;}; -b _ && do {$result = "b"; last TYPE;}; -l $file && do {$result = "l"; last TYPE;};# lstat problems -f _ && do {$result = "-"; last TYPE;}; -S _ && do {$result = "s"; last TYPE;}; warn ("unknown type of file, mode %#o\n", $st_mode); $result = "?"; }
$result .= &p_perm ($st_mode >> 6, -u _, "s"); # User $result .= &p_perm ($st_mode >> 3, -g _, "s"); # Group $result .= &p_perm ($st_mode >> 0, -k _, "t"); # Others }
###################################################################### # # uid, gid -- Convert numeric uid, gid to symbolic # # arg: numeric id # # Returns -- Name associated with id if found, else number # # Side effects -- Accesses /etc/passwd or replacement # ######################################################################
sub uid { local ($uid) = @_; $uid{$uid} = getpwuid($uid) unless defined $uid{$uid}; $uid{$uid} = "#$uid" unless defined $uid{$uid}; $uid{$uid}; }
sub gid { local ($gid) = @_; $gid{$gid} = getgrgid($gid) unless defined $gid{$gid}; $gid{$gid} = "#$gid" unless defined $gid{$gid}; $gid{$gid}; }
###################################################################### # # verbstat -- Print $st_* variable (and/or remembered stat structure) # in multiline verbose format # # Arguments are global variables. Ahem! # # Returns -- nothing # # Side effects -- Output # ######################################################################
sub verbstat { local ($atime, $mtime, $ctime) = (&ctime ($st_atime), &ctime ($st_mtime), &ctime ($st_ctime)); # local ($mode) = &p_mode;
printf ("%s\n", $file); printf ("\tdevice\t\t%#x\n", $st_dev); printf ("\tinode\t\t%d\t\t%#x\n", $st_ino, $st_ino); printf ("\tmode\t\t%s\t%#o\n", &p_mode, $st_mode); printf ("\tnlink\t\t%d\n", $st_nlink); printf ("\towner\t\t%s\n", &uid ($st_uid)); printf ("\tgroup\t\t%s\n", &gid ($st_gid)); printf ("\trdev\t\t%d\n", $st_rdev); printf ("\tsize\t\t%d\n", $st_size); chop ($atime); chop ($mtime); chop ($ctime); printf "\tatime\t\t%d %s\n\tmtime\t\t%d %s\n\tctime\t\t%d %s\n", $st_atime, $atime, $st_mtime, $mtime, $st_ctime, $ctime;
printf ("\tblksize\t\t%d\n", $st_blksize); printf ("\tblocks\t\t%d\n", $st_blocks); }
###################################################################### # Main program ######################################################################
$_ = $0; $progname = m|.*/([^/]+)| ? $1 : $_;
$opt_lstat = 0; # If true use lstat not stat $opt_header = 0; # Add header line $opt_numeric = 0; # One-line numeric format
# No switch clustering with this simple parser
SWITCH: while ($_ = shift) { /^-?/ && &usage; # stat -? ... gives usage /^--$/ && last SWITCH; # -- terminates switches /^-l$/ && ($opt_lstat = 1, next SWITCH); /^-h$/ && ($opt_header = 1, next SWITCH); /^-n$/ && ($opt_numeric = 1, next SWITCH);
unshift (@ARGV, $_); # We are looking at the first file last SWITCH; }
($#ARGV < $[) && &usage; # Must have at least one arg
# Print out header if requested and numeric format
$opt_numeric && $opt_header && print "dev ino mode nlink uid gid rdev size atime mtime ctime blksize blocks\n";
# Stat remaining args and print result
foreach $file (@ARGV) { if ($opt_lstat) { &Lstat ($file); } else { &Stat ($file); }
if (defined ($st_dev)) { if ($opt_numeric) { # fn dev ino md nl ud gd rdv siz atm mtm ctm bks nbk printf "%s %#x %#x %#o %d %d %d %#x %ld %ld %ld %ld %d %d\n", $file, $st_dev, $st_ino, $st_mode, $st_nlink, $st_uid, $st_gid, $st_rdev, $st_size, $st_atime, $st_mtime, $st_ctime, $st_blksize, $st_blocks; } else { &verbstat; } } else { warn "$0: can't ", $opt_lstat ? "lstat" : "stat", " $file: $!\n"; } }
# End of stat
-- Quentin Fennessy Quentin.Fennessy@amd.com Voice: 512.602.3873 Pager: 512.622.6316
/* Quentin Fennessy [quentin.fennessy@amd.com] writes: */
=> du -s RCS du: RCS/ParseNVP.pm,v: Value too large for defined data type
I've seen this error on Solaris boxes running 32-bit code, such as GNU ls, when they are accessing Netapp volumes and directories with very large files (>2GB.)
I double checked my environment, and I'd have been getting the standard Solaris utilities (ls, du, ...) though I do used the /usr/ucb verions...
I've also seen this on Solaris clients when accessing files on a Linux fileserver, when the dates were outrageously wrong on the file. Like a year of 1935!
The filer sync's to our stratum-2 NTP server. Since "ls -l" was giving that error and not reporting anything, I'm not sure if the date was screwy one way or another, but neither the logs on the Solaris host nor on the filer indicate that anybody has been messing with the time.
I've also seen this on Solaris clients when accessing files on a Linux fileserver, when the dates were outrageously wrong on the file. Like a year of 1935!
The filer sync's to our stratum-2 NTP server. Since "ls -l" was giving that error and not reporting anything, I'm not sure if the date was screwy one way or another, but neither the logs on the Solaris host nor on the filer indicate that anybody has been messing with the time.
The file dates can be set arbitrarily. Our users routinely manage to set file dates back as far as 1904. The file timestamp is a 32 bit signed integer. The value zero corresponds to Jan 1, 1970 00:00 GMT. Negative values take you back before then. I suspect it is a problem where folks create files on a PC with the time set totally wrong. Then they zip up the files and unzip them on the filer, which preserves the bogus timestamps. Or else it's a bug in zip, unzip, or some other file archiving software.
Steve Losen scl@virginia.edu phone: 804-924-0640
University of Virginia ITC Unix Support
[...]
du: RCS/ParseNVP.pm,v: Value too large for defined data type
[snip]
Has anybody else seen this problem or have any ideas on how/why this may have occurred?
Yup. I called this in as a bug report about four or five months ago. I could probably dig up the case #, but I think it's closed...
This filer that first displayed this problem is running both CIFS and NFS, and I thought (at first) that it might be a bug related to using a "mixed" security style. But the problem appeared even on volumes that were not - nor had they ever been - anything but Unix-style security, nor even accessed once by a CIFS client. The odd thing is, when those files would pop up I could go in and delete them via CIFS...
For what it's worth, the NFS client accessing the files is running Solaris 5.7. I unfortunately didn't pop over to one of my BSD boxes before the problem worked itself out.
I first encountered this using RCS on Solaris 7 as well (both SPARC & x86). I figured it might be some obscure bug related to file locking and the NFS lock manager, but then someone reported that a _core file_ was displaying the same oddball symptoms...
The workaround (if you have CIFS licensed) is to try deleting the file via CIFS. If that doesn't work, try again via NFS - you may find that just as mysteriously as it appeared, the error will then go away and you'll be able to delete (or access) the file. Tickling it via CIFS seems to get it "unstuck." Very odd. And, I know, not very scientific. ;-) I suppose I should have shut down the box and wack'ed it upside its WAFL, just to see if there really is some insidious directory corruption waiting to bite me on the backside at some inopportune time. But I don't really have the luxury of an extended downtime, and since it appears there's a crude workaround, I haven't (to my deep shame :-) re-opened the case and pestered for a fix...
-- Chris
-- Chris Lamb, Unix Guy MeasureCast, Inc. 503-241-1469 x247 skeezics@measurecast.com
+-- On Monday, December 04, 2000 14:54:05 -0800 mitch@netline.com wrote: | We just ran across a strange happening on our F760 filer. One of our | folks did a "du -s" on an RCS directory to see how much space it was | using: | | => du -s RCS | du: RCS/ParseNVP.pm,v: Value too large for defined data type | | And got a strange error. In fact, pretty much anything that would | do a stat(2) call on this file in this directory would generate | the same error message. There were no errors logged on the filer | and all weekly messages seem to indicate that all is well, but it | still puzzles me. | | I ran off for the requisite caffine boost and came back and am now | unable to reproduce the problem. I asked the user if they perhaps | did something such as recreating the RCS directory from another | source... they hadn't. | | The file which was complained about is a mere 3422 bytes, and all | timestamps indicate that the file has not changed recently. | | Has anybody else seen this problem or have any ideas on how/why this | may have occurred? | | For what it's worth, the NFS client accessing the files is running | Solaris 5.7. I unfortunately didn't pop over to one of my BSD boxes | before the problem worked itself out. +--
NFS defines all dates to be 32 bit unsigned values but many clients, including older Solaris clients ignore this and treat it as a 32 bit signed value. Starting with Solaris 7 Sun began enforcing the standard and refuse to accept a date after 2038 as the standard requires. Presumably filers use a 32 bit date and hence can accept it and still follow the standard.
/Michael