On 8/8/07, Michael Mansour <[log in to unmask]> wrote:

>
>
> A couple of years ago I spoke to technical employees of TUV (doing RHEL
> courses with them at the time - the techs where "the buck stops here" to solve
> the hardest problems in RHEL) and what they said was, the reason TUV doesn't
> support XFS had nothing to do with data corruption or the XFS filesystem
> itself, it was just simply a matter of "what for, why support another
> filesystem" when ext3 was robust for the enterprise and if you wanted more
> performance with less redundancy (to get the performance you get out of XFS)
> then you simply turn off those ext3 features which slow it down.
>

This was a primary reason. Filesystems are particularly hard problems
and you want a team dedicated to working on issues on them. Back in
2000 or so, Red Hat had to either buy up most of the SGI filesystem
staff or it needed to focus on what it had in ext3. It decided that
for the costs it was better to focus on ext3/4/5/6.

The secondary reasons come from that decision. You need a team of
people to go 'fix' it to deal with 32 bit architectures on small
stacks.. or assume that xfs is a filesystem for 64 bit systems only.

-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"