SCIENTIFIC-LINUX-USERS Archives

August 2007

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:
Michael Mansour <[log in to unmask]>
Reply To:
Michael Mansour <[log in to unmask]>
Date:
Thu, 9 Aug 2007 08:18:48 +1000
Content-Type:
text/plain
Parts/Attachments:
text/plain (100 lines)
Hi Karl,

> Donald Tripp wrote:
> > This argument sounds vary familiar to NFS vs GFS vs Lustre vs GPFS... 
> > All file systems have their pros and cons, and no file system is fool 
> > proof. XFS is a good file system, so is Reiser, and ext3, and HFS 
> > (Apple), but they all have their own faults. 
> >
> > Just my 2 cents...
> >
> >
> > - Donald Tripp
> >  [log in to unmask] <mailto:[log in to unmask]>
> > ----------------------------------------------
> > HPC Systems Administrator
> > High Performance Computing Center
> > University of Hawai'i at Hilo
> > 200 W. Kawili Street
> > Hilo,   Hawaii   96720
> > http://www.hpc.uhh.hawaii.edu
> >
> >
> > On Aug 8, 2007, at 10:15 AM, Troy Dawson wrote:
> >
> >> Brent L. Bates wrote:
> >>>      The installer will not look in the contrib directories?  Ok.  
> >>> Could I as
> >>> part of my combining the CD's into a single DVD process, move the 
> >>> XFS RPM's
> >>> out of the contrib area and into the main stream directories?  Or 
> >>> perhaps,
> >>> with the DVD I've already burned, do some kind of shell escape out 
> >>> of the
> >>> install GUI and install them from there?  People want XFS and we 
> >>> really don't
> >>> care about the top level vendors prejudices.  I'm willing to work 
> >>> with the SL
> >>> people to get a more reasonable solution to this on going problem.
> >>
> >> This isn't a "top level vendors prejudices"
> >> This is a Scientific Linux Developers prejudices.
> >> "People want XFS" until they start loosing critical data.  Trust me, 
> >> it's happened here.  They scream for it and scream for it, and then 
> >> scream at you when it corrupts stuff and somehow it's all become my 
> >> fault.
> >>
> >> You can do all sorts of stuff in the %post install scripts, including 
> >> install stuff from the contrib area.  You are only limited by your 
> >> imagination.
> >>
> >> Troy
> >> -- 
> >> __________________________________________________
> >> Troy Dawson  [log in to unmask] <mailto:[log in to unmask]>  (630)840-6468
> >> Fermilab  ComputingDivision/LCSI/CSI DSS Group
> >> __________________________________________________
> >
> Hi - This thread comes at an opportune time for me.  We are
> experiencing horrible performance on RAID5 arrays on 3Ware
> 9500S controllers (eg. wait for keystrokes to appear when
> doing any kind of IO).  The system is running SL4.4 and it's
> been suggested that the kernel scheduler in RHEL4 is at fault,
> so I'm currently slowly moving up to SL5 to see if that fixes it.
> On the other hand, trying to figure this out, I've seen it suggested
> on a gentoo forum from someone with a similar problem that
> going to XFS from ext3 was a solution.  However, these questions
> of data corruption worry me.  How common is it to lose data on
> an XFS filesystem?  Obviously, TUV thinks it's a problem, but

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.

Regards,

Michael.

> I've only ever seen reference to their 'internal tests'. Do those of
> you using (or have used in the past) XFS, see any greater problems
> with data integrity?
> -Karl
> 
> -- 
> -----------------------------------------------------------------
> | Karl A. Misselt                          Office: Steward 254  |
> | Steward Observatory                       Phone: 520-626-0196 |
> | University of Arizona                       FAX: 520-621-9555 |
> | Tucson, AZ 85721-0065                  [log in to unmask] |
> -----------------------------------------------------------------
> | "To be civilized is to restrain the ability to commit mayhem. |
> |  To be incapable of committing mayhem is not the mark of the  |
> |              civilized, merely the domesticated."             |
> -----------------------------------------------------------------
------- End of Original Message -------

ATOM RSS1 RSS2