Hello Garrett,
In my case I'm rsync'ing entire file systems from other servers which
are not necessarily Solaris servers. The specific device is coming
from BSD system. Looks like ZFS is handling them fine but one needs to
use 64bit userland tools, I haven't testes UFS or any other
file system.
--
Best regards,
Robert Milkowski
http://milek.blogspot.com
Tuesday, February 17, 2009, 4:44:30 PM, you wrote:
GDA> IMO, large (32-bit instead of 18-bit) minor numbers are a farce in
GDA> Solaris. You can *only* use them from a 64-bit process -- you can't
GDA> even open() a device with a large minor number from a 32-bit process.
GDA> I'm not sure the filesystems can properly represent a large minor number
GDA> either. (I think some have only 32-bits for the entire devt.)
GDA> I believe that makes them almost completely useless. I had hoped to be
GDA> able to use clone opens with large numbers in another project I was
GDA> using, and that didn't work with 32-bit programs either.
GDA> I don't think we should go too far out of our way to enable such minor
GDA> nodes to be transported via rsync -- if folks have filesystems with them
GDA> on them its more likely the result of a bug than actual intention.
GDA> -- Garrett
GDA> Milan Jurik wrote:
>> Hi,
>>
>> we are looking for guidance how to solve "interoperability" problem with
>> rsync. Robert reported problem with rsync from BSD to Solaris box, where
>> 32-bit rsync fails. He compiled 64-bit rsync and that works without
>> problem. After some investigation he discovered that problem is with
>> e.g.:
>>
>>
>>> # /usr/bin/ls -l dev/mdctl
>>> dev/mdctl: Value too large for defined data type
>>>
>>> # truss -t lstat /usr/bin/ls -l dev/mdctl
>>> lstat64("dev/mdctl", 0x08046930) Err#79 EOVERFLOW
>>> dev/mdctl: Value too large for defined data type
>>>
>>> lets try 64bit version of ls:
>>>
>>> # /usr/bin/amd64/ls -l dev/mdctl
>>> crw------- 1 root root 235, 4294902015 Sep 13 2006
>>>
>> dev/mdctl
>>
>> After additional investigation he found that for 32-bit userspace we
>> limit minor to L_MAXMIN32 (because we want major+minor to fit in 32-bit
>> value). But only for 32-bit userspace. We allow to create bigger minors
>> in 64-bit userspace.
>>
>> For 32-bit limit of time members in stat structure we can claim that
>> time outside of 32-bit range is (and will be for next 30 years) invalid
>> (and even ZFS has test for it), but what about minor number comming from
>> other systems (yes, unusual case, used only for backups)?
>>
>> For people with access to Bugster, you can see some comments in CR
>>
>> 6248065 *ls* should be isaexec'ed (64bit on 64bit kernel, 32bit on 32bit
>> kernel)
>>
>> And now the question - how to deal with this situation? Should we
>> deliver 64-bit rsync? There are no tools on Solaris to deal with such
>> files. Or should we discourage to bundle such tool? Should filesystems
>> block creating of these minors?
>>
>> Best regards,
>>
>> Milan
>>
>> _______________________________________________
>> opensolaris-code mailing list
>> [email protected]
>> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>>
GDA> _______________________________________________
GDA> opensolaris-code mailing list
GDA> [email protected]
GDA> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
