zfs discuss - Sep 2008 - Error: value too large for defined data type

I am having a very odd problem on one of our ZFS filesystems

On certain files, when accessed on the Solaris server itself locally
where the zfs fs sits, we get an error like the following:

root at jabba # ls -l
./README: Value too large for defined data type
total 36
-rw-r-----   1 mreuter  mreuter     1019 Sep 25  2006 Makefile
-rw-r-----   1 mreuter  mreuter     3185 Feb 22  2000 lcompgre.cc
-rw-r-----   1 mreuter  mreuter     3238 Feb 22  2000 lcompgsh.cc
-rw-r-----   1 mreuter  mreuter     2485 Feb 22  2000 lcompreg.cc
-rw-r-----   1 mreuter  mreuter     2774 Feb 22  2000 lcompshf.cc

The odd thing is that when the filesystem is accessed from our
Linux boxes over NFS, there is no error access the same file


vader:complex[84] ls -l
total 24
drwxr-x---+ 2 mreuter mreuter    8 Sep 25  2006 .
drwxr-x---+ 5 mreuter mreuter    5 Mar 31  1997 ..
-rw-r-----+ 1 mreuter mreuter 3185 Feb 22  2000 lcompgre.cc
-rw-r-----+ 1 mreuter mreuter 3238 Feb 22  2000 lcompgsh.cc
-rw-r-----+ 1 mreuter mreuter 2485 Feb 22  2000 lcompreg.cc
-rw-r-----+ 1 mreuter mreuter 2774 Feb 22  2000 lcompshf.cc
-rw-r-----+ 1 mreuter mreuter 1019 Sep 25  2006 Makefile
-rw-r-----+ 1 mreuter mreuter 1435 Jan  4  1945 README
vader:mreuter:complex[85] wc README
   40  181 1435 README

The file is obvious small so this is not a "large file" problem.

Anyone have an idea what gives?


-- 
---------------------------------------------------------------
Paul Raines                email: raines at nmr.mgh.harvard.edu
MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging
149 (2301) 13th Street     Charlestown, MA 02129	    USA

On Fri, Sep 05, 2008 at 03:17:44PM -0400, Paul Raines
wrote:
> root at jabba # ls -l
> ./README: Value too large for defined data type
> total 36
> -rw-r-----   1 mreuter  mreuter     1019 Sep 25  2006 Makefile
> -rw-r-----   1 mreuter  mreuter     3185 Feb 22  2000 lcompgre.cc
> -rw-r-----   1 mreuter  mreuter     3238 Feb 22  2000 lcompgsh.cc
> -rw-r-----   1 mreuter  mreuter     2485 Feb 22  2000 lcompreg.cc
> -rw-r-----   1 mreuter  mreuter     2774 Feb 22  2000 lcompshf.cc
> -rw-r-----+ 1 mreuter mreuter 1435 Jan  4  1945 README
> vader:mreuter:complex[85] wc README
>    40  181 1435 README
> 
> The file is obvious small so this is not a "large file" problem.
Probably the date.

I don''t think ''ls'' is isaexec-wrapped by default. 
You might try running
the 64-bit version of ls.

-- 
Darren

Paul Raines wrote:
> I am having a very odd problem on one of our ZFS filesystems
>
> On certain files, when accessed on the Solaris server itself locally
> where the zfs fs sits, we get an error like the following:
>
> root at jabba # ls -l
> ./README: Value too large for defined data type
> total 36
> -rw-r-----   1 mreuter  mreuter     1019 Sep 25  2006 Makefile
> -rw-r-----   1 mreuter  mreuter     3185 Feb 22  2000 lcompgre.cc
> -rw-r-----   1 mreuter  mreuter     3238 Feb 22  2000 lcompgsh.cc
> -rw-r-----   1 mreuter  mreuter     2485 Feb 22  2000 lcompreg.cc
> -rw-r-----   1 mreuter  mreuter     2774 Feb 22  2000 lcompshf.cc
>
>   
Do you by chance have /usr/gnu/bin, or any directory with a Gnu
''ls'' in
your path before /usr/bin?
(what does ''which ls'' show?)

I''ve seen this with Gnu ls that I have compiled myself as far back as 
Solaris 9 mayber earlier. By default Gnu ls compiled on solaris doesn''t
know how to handle latgr files (and therefore probably 64bit dates either.)

When I''ve seen this, explicitly running /usr/bin/ls -l worked fine, and
I suspect it will for you too.

   -Kyle
> The odd thing is that when the filesystem is accessed from our
> Linux boxes over NFS, there is no error access the same file
>
>
> vader:complex[84] ls -l
> total 24
> drwxr-x---+ 2 mreuter mreuter    8 Sep 25  2006 .
> drwxr-x---+ 5 mreuter mreuter    5 Mar 31  1997 ..
> -rw-r-----+ 1 mreuter mreuter 3185 Feb 22  2000 lcompgre.cc
> -rw-r-----+ 1 mreuter mreuter 3238 Feb 22  2000 lcompgsh.cc
> -rw-r-----+ 1 mreuter mreuter 2485 Feb 22  2000 lcompreg.cc
> -rw-r-----+ 1 mreuter mreuter 2774 Feb 22  2000 lcompshf.cc
> -rw-r-----+ 1 mreuter mreuter 1019 Sep 25  2006 Makefile
> -rw-r-----+ 1 mreuter mreuter 1435 Jan  4  1945 README
> vader:mreuter:complex[85] wc README
>    40  181 1435 README
>
> The file is obvious small so this is not a "large file" problem.
>
> Anyone have an idea what gives?
>
>
>

>>>>> "add" == A Darren Dunham <ddunham at
taos.com> writes:
    >> ./README: Value too large for defined data type

   add> Probably the date.

seconded.  I saw that bug also.  Just touch the file to work around
it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20080906/52e75cf1/attachment.bin>

On Fri, 5 Sep 2008, Kyle McDonald wrote:
> Paul Raines wrote:
>> I am having a very odd problem on one of our ZFS filesystems
>> 
>> On certain files, when accessed on the Solaris server itself locally
>> where the zfs fs sits, we get an error like the following:
>> 
>> root at jabba # ls -l
>> ./README: Value too large for defined data type
>> total 36
>> -rw-r-----   1 mreuter  mreuter     1019 Sep 25  2006 Makefile
>> -rw-r-----   1 mreuter  mreuter     3185 Feb 22  2000 lcompgre.cc
>> -rw-r-----   1 mreuter  mreuter     3238 Feb 22  2000 lcompgsh.cc
>> -rw-r-----   1 mreuter  mreuter     2485 Feb 22  2000 lcompreg.cc
>> -rw-r-----   1 mreuter  mreuter     2774 Feb 22  2000 lcompshf.cc
>> 
>> 
> Do you by chance have /usr/gnu/bin, or any directory with a Gnu
''ls'' in your
> path before /usr/bin?
> (what does ''which ls'' show?)
>
> I''ve seen this with Gnu ls that I have compiled myself as far back
as Solaris
> 9 mayber earlier. By default Gnu ls compiled on solaris doesn''t
know how to
> handle latgr files (and therefore probably 64bit dates either.)
>
> When I''ve seen this, explicitly running /usr/bin/ls -l worked
fine, and I
> suspect it will for you too.
>
>  -Kyle
>
No, it is using the default Solaris ls.  I also tried the ls from
/usr/xpg6/bin with the same problem.  I could also not ''touch''
the
file to fix the date issue on the Solaris box itself.  So I ended
up going to the LInux that had it mounted by NFS and touch''ing it
there.  Now I can ''ls'' it just fine on the Solaris box.

you need to run /usr/bin/amd64/ls

Some utils eg virtualbox shared folders in an old build munge file dates
--
This message posted from opensolaris.org

Possible workaround :

echo nfs_allow_preepoch_time/W1 | adb -wk

and in /etc/system:
set nfs:nfs_allow_preepoch_time = 1


-- 
Francois

hmm same problem with rsync occuring here (on sun os 5.10) : we tried using both
rsync from sun freeware, and recompiling rsync from source.

errors, e.g.: rsync: readlink_stat ("filename") failed: Value too
large for defined data type (79)

When nfs mounting these files, fedora rsync handles them fine, but we want to
rsync directly from solaris/zfs filesystem..
-- 
This message posted from opensolaris.org

On 11/18/2008 12:14 PM, shanna wrote:
> hmm same problem with rsync occuring here (on sun os 5.10) : we tried
> using both rsync from sun freeware, and recompiling rsync from
> source.
>
> errors, e.g.: rsync: readlink_stat ("filename") failed: Value too
> large for defined data type (79)
>
> When nfs mounting these files, fedora rsync handles them fine, but we
> want to rsync directly from solaris/zfs filesystem..
Fix the timestamp on the files (probably after 2038), or compile a 
64-bit version of rsync.

-- 
Carson

1)  fix timestamp 
yeah, done that. But since this is our main backup for a set of maybe 700-900
users, these files periodically crop up and don''t get backed up. It
seems like a real hack to set a cron job to go around touching files... And a
pain to keep monitoring and doing it manually
2) recompile 64 bit version of rsync
Tried that - tried setting LDFLAGS=''-L/lib/64''
  & recompiling rsync, but it did not seem to pick up the right libraries.
Suggestions?
-- 
This message posted from opensolaris.org

Did you try ? :
echo nfs_allow_preepoch_time/W1 | adb -wk


--
Francois

the problem is not with nfs mounted files, but with rsync over ssh from the
machine itself.
-- 
This message posted from opensolaris.org

We were able to compile rsync for 64 bit, (Sun c compiler) with: 
CFLAGS=-xarch=amd64

However, it still fails with the message:
rsync: failed to set times on "/tmp/foo/xxx/.filename.java.b0aGxe":
Value too large for defined data type (79)

rsync does copy the file, but fails to reset the timestamp on the file, and
leaves it owned by root, with a modify time of now.

I note that cp, touch also fail. It seems this is not limited to rsync.
-- 
This message posted from opensolaris.org

> 2) recompile 64 bit version of rsync
> Tried that - tried setting LDFLAGS=''-L/lib/64''
>   & recompiling rsync, but it did not seem to pick up the right
libraries. Suggestions?
Assuming you are running (t)csh and have the Sun Studio compiler, do:

  unsetenv LD_LIBRARY_PATH
  unsetenv LDFLAGS

  setenv CC /opt/SUNWspro/bin/cc
  setenv CFLAGS "-fast -s -m64"

  ./configure -C --disable-nls --prefix=/opt/local
  make
  make install


If you have a Bourne-like shell, replace "setenv XX YY" with
"export XX=YY".
If you want the software to land in some other place, change the
"/opt/local" above.


Good luck -- Volker
-- 
------------------------------------------------------------------------
Volker A. Brandt                  Consulting and Support for Sun Solaris
Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim                     Email: vab at bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgr??e: 45
Gesch?ftsf?hrer: Rainer J. H. Brandt und Volker A. Brandt

Francois <francois.lesage at ovh.net> wrote:
> Did you try ? :
> echo nfs_allow_preepoch_time/W1 | adb -wk
if this also happens on a local ZFS filesysten, then his problem is
a time stamp past 2038

J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       schilling at fokus.fraunhofer.de     (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Incidentally, I just wanted to let you know that solved my problem :)
I can now parse my samba mounts which were complaining about value too large.
Changed to the standard ls.

Yet, this does not completely solve my problem, because file parsers do not
manage to list files of my mount, even if I do export /usr/bin in PATH as first.
I mount a samba partition on which there are several pictures, and I''d
need to view them quickly as thumbnails using a tool such as gthumb, but it does
not work with that fix...

Any idea ?

Regards
Axelle
-- 
This message posted from opensolaris.org