IMO, large (32-bit instead of 18-bit) minor numbers are a farce in
Solaris. You can *only* use them from a 64-bit process -- you can't
even open() a device with a large minor number from a 32-bit process.
I'm not sure the filesystems can properly represent a large minor number
either. (I think some have only 32-bits for the entire devt.)
I believe that makes them almost completely useless. I had hoped to be
able to use clone opens with large numbers in another project I was
using, and that didn't work with 32-bit programs either.
I don't think we should go too far out of our way to enable such minor
nodes to be transported via rsync -- if folks have filesystems with them
on them its more likely the result of a bug than actual intention.
-- Garrett
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
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
