Hello Garrett,
Thursday, February 19, 2009, 5:45:50 PM, you wrote:
GDA> Robert Milkowski wrote:
>> Hello Garrett,
>>
>> Wednesday, February 18, 2009, 5:15:52 PM, you wrote:
>>
>> GDA> Robert Milkowski wrote:
>>
>>>> Hello Garrett,
>>>>
>>>> Wednesday, February 18, 2009, 12:26:11 AM, you wrote:
>>>>
>>>> GDA> Robert Milkowski wrote:
>>>>
>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> GDA> Minor nodes are inherently not portable between systems. Why on earth
>>>> GDA> would you want to rsync them from one OS to another?
>>>>
>>>> It's not about if it works in rsync or not - I was just surprised that
>>>> it is possible to create such a device with 64bit application but then
>>>> default tools like ls will fail and one has to specifically point to
>>>> 64bit version of ls. I would prefer if ls was using isaexec which
>>>> would help to avoid such problems.
>>>>
>>>>
>>
>> GDA> isaexec adds a small perf. penalty. If you really want isaexec, you
>> GDA> can change it on your system.
>>
>> GDA> I personally am not fond of making default system utilities isaexec
>> based.
>>
>> Probably not all of them - but why are you so much concerned about
>> performance overhead caused by using isaexec for ls utility?
>> I would argue that in ls case it's more important to end-user that it
>> works than if it takes a little bit more time to start it.
>> If someone has an application which executes ls hundreds times per
>> second so isaexec overhead might be important than that someone could
>> point it's app to a specific ls - I think it's much less common case
>> to worry about. (then my case isn't common either...)
>>
>>
GDA> There are lots of scripts out in the wild. Many of them may do
GDA> surprising things, like call "ls" in a loop.
GDA> I'm not prepared to say the performance of ls is unimportant.
GDA> And yes, your case is rather an oddball -- the results would differ in a
GDA> 32-bit environment vs. a 64-bit one. I'm not too thrilled about *that*
GDA> either. I actually think rsync probably has very little business trying
GDA> to copy over special nodes. (In retrospect, I wonder if mknod(2) should
GDA> be deprecated. With devfs, nobody should be creating special files
GDA> anymore....)
As others mention it won't be that easy to get rid of mknod().
Coming back to rsync example - I'm using it for backup purposes and
lots of systems are old enough to not have a devfs implemented.
As I already wrote it's not that important for me to have a copy of
/dev from these systems I was more curious that one can create such a
device so default tools on default path in OS won't behave properly.
While I can easily imagine scripts calling ls in a loop where all
metadata is cached so your isaexec overhead could be substantial...
still it is rather very rare and it would be more desirable to have a
"working tools". As I understand the problem with 32bit ls is not only
with devices like the one I found but also with stat() syscall when
date is out of range which also happens.
Just a thought - maybe default path for a shell should depend on a
mode a OS booted (32bit vs. 64bit) so if one booted into 64bit all
64bit system tools are first on a path? That way isaexec won't be
necessary and it should work in many cases (except for script
providing a full path - but then the behavior for them will stay the
same as it is today).
?
--
Best regards,
Robert Milkowski
http://milek.blogspot.com
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
