SCIENTIFIC-LINUX-USERS Archives

July 2014

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Lamar Owen <[log in to unmask]>
Reply To:
Lamar Owen <[log in to unmask]>
Date:
Tue, 8 Jul 2014 11:06:39 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (49 lines)
On 07/08/2014 10:31 AM, Konstantin Olchanski wrote:
> On Tue, Jul 08, 2014 at 01:19:58AM -0700, Jim McCarthy wrote:
>> On Mon, 7 Jul 2014, Connie Sieh wrote:
>>>> I note that only X86-64 is available; have I missed something about
>>>> supported ISAs, or will there also be an IA-32 port/distribution as
>>>> well?
>>>>
>>>> Yasha Karant
>>> TUV is only releasing X86-64 .
>>>
>>> -Connie Sieh
>> Is this for TUV "v7 ALPHA", or is this to become 'the new normal' going
>> forward ?
>>
> My best guess is - there is no 32-bit RHEL7 because "they" decided to use the XFS filesystem by default, but XFS only works on 64-bit systems (something about stack size or page size or something obscure like that).

It's worse than just 'not working.'

It's 'let's silently stop working when you pass 16TB of occupied space 
on your 24TB filesystem and no longer even mount it on bootup.'  (I ran 
into this; nothing prevented me from making a 24TB XFS filesystem on EL5 
i686, and I started backups onto it.  Then one day the backup job just 
stopped, and after a reboot the filesystem simply would not mount 
anymore.  It was a mad dash to reinstall x86_64 EL5 to get access back 
to the backup filesystem, after researching the problem.)  But it was 
never really 'supported' by upstream anyway, and I don't remember the 
package I used to gain xfs on 32-bit.  Suffice to say it is very very 
broken.

See Connie's post in the archives about the 4k-stacks issue; here's a 
quick link: 
[log in to unmask]" target="_blank">https:[log in to unmask]

>
> This is a wise decision if you consider that all serious UNIX machines went 64-bit back in the late-1990-ies (SGI, DEC, etc),
> and that all new PC hardware is 64-bit capable.
>
Oddly enough Linux on SPARC64 typically uses a 32-bit userland even with 
a 64-bit kernel, since on SPARC there is no performance improvement 
going 64-bit; the only differences between 32-bit SPARC code and 64-bit 
SPARC code are the size of the executable (64-bit is larger) and the 
memory size that can be addressed per-process, being much greater with 
64-bit code.

x86_64 is not just a 64-bit i686; there are many other improvements that 
make 64-bit code run faster than equivalent 32-bit code.

And MIPS32 is still alive and kicking in the embedded Linux market.

ATOM RSS1 RSS2