Re: Upgrade RedHat 9 to Fedora

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



sudo Yang <sudoyang@xxxxxxxxx> wrote:
> ext3 wasn't supported in RH 7.1.

The Anaconda installer didn't support it.
But the kernels had support for it.

You could make any Ext2 filesystem into Ext3 very easily,
except the root filesystem itself.

> This is very good info about XFS, so thanks for the info. 
> I know it has made it into the standard kernel tree.

IMHO, XFS has always been the most reliable/stable journaling
filesystem in Linux.  The lack of advanced features required
for it in the Linux 2.4 kernel itself was always the issue.
SGI got on-board with the 2.5 development really quick, and
a lot of the VFS features in 2.6 owe their thanx to SGI.

> How's the development effort on it as of late?

Understand that XFS development was pretty straight forward.
Unlike Ext3, they had already dealt with the quota and ACL
issues on Irix, and written that code.
Unlike ReiserFS, the structure hadn't changed a bit.
And unlike JFS from OS/2, XFS came from Irix, a UNIX
platform.
[ IBM's move to port JFS from OS/2 in 1999, instead of AIX,
had to do with Monterey, their joint contract with SCO that
IBM broke later ]

> Wonder why RedHat chose not to support anything else except
> for ext2 and ext3.

Proven, reliable, etc..., and Tweedie (who largely came up
with Ext3) works at Red Hat.  I love the fact that I can
always break down to a full Ext2 fsck if I need to for Ext3.

One of the reasons I refuse to use ReiserFS has nothing to do
with its kernel/journal code -- which from what I've seen, is
far better than JFS and many others (possibly even Ext3) --
but the off-line tools _lag_ the kernel/journal code.

I.e., ReiserFS is typically fine if the journal recovers. 
And ReiserFS does a good job in testing if it should use its
journal are not (arguably better than Ext3).  But the
off-lines tools -- they are seemingly _never_ "up-to-date" so
if the journal can't recovery, you're at their mercy.

> How stable are user-land tools for dealing with corrupted
> XFS filesystems?

xfs_repair is a crapload better than ReiserFS' fsck.
I have never, ever lost an Ext2/Ext3 or XFS filesystem to an
fsck.ext2 or xfs_repair run.  The latter was even able to
repair the 2 /var filesystems I had corruption on back with
the XFS 1.0 bug.  And the former has saved me when I've had
physical disk errors.

I've had toast after toast after toast with ReiserFS' fsck.
In fact, when it comes to an inconsistent ReiserFS that
(correctly) won't replay its journal, I clone it, mount it
read-only and pull all the data off I can -- even though it's
inconsistent.  Because so many ReiserFS fsck have left it
totally inconsistant and umountable on me.

> This is one area of ReiserFS that still needs a lot of
> work.

Thanx because Hans Reiser believes filesystems should be
redesigned every 5 years.

Ext2 (including Ext3) and XFS have had the same structure
since the mid-'90s.  Ext3 underwent a run-time change at
kernel 2.2 (circa 1998), and XFS underweant a run-time change
at XFS 1.1 (i.e., circa 2002 / Red Hat Linux 7.2).

> We've been running ReiserFS in very active systems
> for the past 4+ years.  For the most part, it has been
> fairly good to us.

As long as the ReiserFS journal can recover, I think it's a
great OS.  Reiser & team put in the time to make a good
driver and recovery logic.  I won't fault them there, and I'd
say it's probably better than Ext3's basic approach.

> We've lost about 5 systems we could not recover using these
> tools (sometimes these tools did more harm than good).

Exactly!  Because the focus is _never_ on the off-line tools.
And it is unlike that will _ever_ change.



-- 
Bryan J. Smith                | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx     |  (please excuse any
http://thebs413.blogspot.com/ |   missing headers)

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux