So let me start out by saying… This isn’t so much of a problem with ZFS, as it is just a problem with the tools available in Solaris (not to mention whatever device actually screwed up the timestamp in the first place). But so here is the story. We have found that migrating our lower level file servers to Solaris on top of deduped or compressed ZFS is really fantastic for our environment. So I have been working on migrating more and more data to this pool of storage in order to free up some of our more expensive storage for other data.
So this is the error that I experienced.
rsync: readlink_stat("/mnt/migration/engcommon/data2/eng/common/sc/Assert9797/feCalPersist.dat") failed: Value too large for defined data type (79)
Now to confirm that you are experiencing the same issue try this (of course substituting your file name for the filename I had).
# /usr/bin/ls -lh /mnt/migration/engcommon/data2/eng/common/sc/Assert9797/feCalPersist.dat /mnt/migration/engcommon/data2/eng/common/sc/Assert9797/feCalPersist.dat: Value too large for defined data type
# /usr/bin/amd64/ls -lh /mnt/migration/engcommon/data2/eng/common/sc/Assert9797/feCalPersist.dat -rwxr-xr-x+ 1 2147483658 smbusers 1.5K Jan 5 2080 /mnt/migration/engcommon/data2/eng/common/sc/Assert9797/feCalPersist.dat
Now clearly the /usr/bin/ls has an issue in dealing with files which /usr/bin/amd64/ls does not have. This is due to the 32-bit “2038” problem. Basically Unix has a Y2K bug as well, only it is 38 years later. So the easiest way to fix this is to touch the file to update the time… But really could it be that easy? Yes and No. See you cannot touch the file with Solaris, touch doesn’t have a 64-bit binary so it has the same limitations.
Now from a 64-bit Linux machine we can mount the SMB Share. I used Ubuntu 11.04 amd64 Desktop.
# apt-get install smbfs # mount -t smbfs //server/d$ /mnt -o user=ALLANGLESIT/administrator
Displaying the file shows that someone has apparently returned from the future with this file.
# ls -lh /mnt/data2/eng/common/sc/Assert9797/feCalPersist.dat -rwxr-xr-x 1 root root 1.5K 2080-01-05 12:36 feCalPersist.dat
This can be easily changed by touching it.
# touch /mnt/data2/eng/common/sc/Assert9797/feCalPersist.dat
And now the updated timestamp from Linux.
# ls -lh /mnt/data2/eng/common/sc/Assert9797/feCalPersist.dat -rwxr-xr-x 1 root root 1.5K 2011-08-17 12:36 feCalPersist.dat
But what about from Solaris.
# /usr/bin/ls -lh -rwxrwx---+ 1 2147483658 smbusers 1.5K Aug 17 12:36 feCalPersist.dat
Now when re-running the rsync it runs without any issues.
I experienced something similar this evening while trying to rsync data from a Linux client to a Solaris 11 NFS server. rsync was unable to set the timestamp properly on the file after copying (the file timestamp was in 2075).
Do you have any suggestions for solving the problem? I found an article on SuperUser that seemed to indicate that Solaris 10+ had both 32-bit and 64-bit binaries and would use whichever was appropriate for the platform.
As for rsync, I’m guessing that I probably have to compile it from scratch to enable 64-bit timestamps. I didn’t see any 64-bit packages on pkg.oracle.com.
Hi Mike,
The issue you describe is the same issue I have described in this article. You simply need to “touch” the files with the bad timestamps with a 64-bit version of touch (like on x64 Linux) this will update the timestamps to the correct time (assuming your machine time is correct). This will then allow you to use 32-bit binaries against it (such as rsync).
Re-read and follow the article above and it will sort out your issue.
-matt
Thanks, Matt. When I asked about fixing the problem, I was talking about fixing the problem with the binaries in Solaris itself. It seems to me that touching files on a Linux box is more of a work-around than an actual fix, right?
Is the solution to compile 64-bit applications from source for things like ls, touch, etc. so that they won’t break in the first place? Some other approach?
Hi Mike,
The problem is not really with Solaris itself, sure some more of these tools need to have 64-bit binaries (and thus have the 32-bit binaries depracated) however the root of the issue is unquestionably invalid timestamps, if you resolve the timestamps then the issue is resolved. If it makes you feel better to compile a 64-bit version of rsync then that ought to work as well, but to me it seems unnecessarily complicated for a rather simple issue.
-matt