Jon Lewis <jlewis@xxxxxxxxx> wrote:
> If these releases were so stable, could someone from SGI
> please put them back up on the oss.sgi.com FTP server?
Actually, that would be nice since Red Hat Linux 7.3 is still
supported by FedoraLegacy.ORG, Progeny and select, mission
critical hardware/software companies like FalconStor.
Then again, the Red Hat Linux 9 / XFS 1.3.1 releases _are_ on
the SGI site. I only had 1 system running with those, and
have far less time with them, but they were fairly good
> I've got a RH 8.0 based system (switching/upgrading the
> entire distro hoping for XFS stability is not an option...
> if I have to do that, I'm abandoning XFS) that's really not
> behaving well using Red Hat's kernel RPMs rebuilt with the
> XFS 1.3.0 release.
As I mentioned off-list, Red Hat Linux 8.0 is a ".0" release
and not well trusted. And your issues are compounded by the
fact that you are running a 3rd party "hacked together" XFS
> huh? From what I've read, ext3 can handle up to 4TB
Yes, it has been extended from 1.1TB to 2.2TB to 4.4TB to,
now, 8.8TB with all sorts of hacks in 2.6. That's not what I
> What problems do you run into with >1TB, but <4TB? I
> realize, XFS being 64-bit means it can have filesystems
> of inconceivable size...but after recent threads on this
> list about how xfs_repair needs considerable RAM in order
> to repair large fs's, abusing XFS's fs size limit seems a
> really bad idea.
I haven't been installing Opteron systems with less than 4GiB
of RAM since they first came out. Heck, 16GiB RAM is pretty
much standard when I install a 4-way Opteron.
> Same here. Unfortunately, it was put into production
> without sufficient testing and has never been entirely
I assume you're referring to the previous integrator, not
SGI, XFS or anything else. I tire of fly-by-night system
integrators who put in hacked kernels and ".0" releases.
Bryan J. Smith | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)