On 8/3/05, Bryan J. Smith b.j.smith@ieee.org wrote:
sudo Yang sudoyang@gmail.com 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.
Does XFS do data journaling (ReiserFS 4 is supposed to do this at minimal cost)?
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@ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers) _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos