[Beowulf] OS for 64 bit AMD

[Michael Will]

David Kewley wrote:

>Oh goody, I get to play devil's advocate.  Wait, did I just say RH is the 
>devil? ;)
>
>No, I don't work with them, just have been a RHL, FC, and now RHEL admin for a 
>few years, and have been reading mailing lists for a couple of years.
>  
>
>...
>  
>
> It is not meant as a tautology, but as a practical acknowledgement 
> that if
>
>they are to support customers' problems with xfs at the level they'd wish, 
>then they'd have to hire several people, or spend extensive time to train 
>several people.
>
>As I recall, the remark about difficulty supporting xfs came from Arjan van ee 
>Ven, one of their kernel developers.
>
>  
>
>>Some inherent disadvantages of ext3 show up when you start looking at
>>large file systems and large files.  Xfs has much higher limits.  If you
>>want to build a 30TB file system across a huge disk array attached to a
>>sizeable SMP machine, can you do it with ext3?  (no as of RHEL3).  If
>>you want to work with a 2.5 TB file (part of a recent benchmark we ran),
>>can you do it with ext3?  (no as of RHEL3).  Xfs doesn't have a problem
>>with either of these.
>>    
>>
>
>I don't know what the current limits are, but I'd bet they're relieved.
>  
>
I was suprised that even though SLES8 had already fixed it for a long 
time redhat did not consider
it important to fix the 1TB limit in RHEL3. Maybe because they knew they 
were going from the 2.4
to the 2.6 kernel - but there is guaranteed to be a large RHEL3-customer 
base that relies on commercial
support of third-party apps that cannot simply be switched over to RHEL4 
and thus are still stuck with it.

>>>If customers show RH that there are real-life needs for xfs that are not
>>>satisfied by ext3, then RH may well be willing to invest in in-house xfs
>>>expertise.
>>>      
>>>
>>Unlikely.  Customers have been showing a clear need for this for a while
>>(Sloan sky survey, and many others with huge and high speed data
>>requirements).  Redhat prefers to use the excuse that it is a large and
>>complex package.  Hmmm.  So are Xorg, Openoffice, ....
>>
>>I do not expect Redhat to do this.  SuSE has, as have most of the rest
>>of the major distributions (including the 1 man distribution shops), so
>>the excuses that one hears are ... well ... probably not the real
>>reasons.  Redhat does not want to promote a competitor to technology it
>>supports.  That seems to be a simpler explanation, and I believe is
>>better supported by observing their actions.
>>    
>>
>
>That may well be the case; certainly RH has market self-interests to look 
>after.  And I know that folks have voiced similar suspicions about RH many 
>times regarding many details of technology choices they've made.  May be, may 
>not be, we'll see.
>  
>
How exactly will we see?

Besides looking at evidence (itanium vs. opteron support, gnome vs. kde 
support,
ext3 vs. xfs support).

Michael Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.scyld.com/pipermail/beowulf/attachments/20050401/03ad2e6c/attachment.html