On Wed, 2003-01-01 at 21:53, Florin Andrei wrote: > That, and also the fact that it's significantly faster than the other FS > when it comes to writing/reading from/to very large files, possibly from > several simultaneously and/or on SMP systems. > I'm not saying it's better than other FS always: ReiserFS has a > noticeable advantage when you have many small files, and of course Ext3 > has the kickass data=journal mode. > But for multi-GB files, XFS fares better: video captue, generally any > kind of video stuff, mastering ISO images, etc.
SGI designed XFS specifically for optimized video and data processing. ReiserFS has its focus. Ext3 has the unique option to do full data journaling, which is nice if you have a nice, large NVRAM PCI card (ala NetApp-like). And I don't know IBM was thinking when they ported JFS from OS/2 instead of their UNIX flavor AIX. IMHO, and maybe it's because I'm used to supporting production file servers, _maturity_ is a _huge_ factor to me. I have used Ext3, XFS and ReiserFS pretty extensively. First off, people _wrongly_ think journaling is about data integrity, with exception of "full data" journaling with a NVRAM board, it's _not_. It's about avoiding a full fsck. That's why if there is a "problem" with a journal, it should _always_ be discarded. As such, Ext3 is basically Ext2, 100% structure-wise. If Ext3 detects a single problem with its journal, it breaks down to a full Ext2 fsck. Yeah, my server might not be available for a hour, but my users won't be corrupting the filesystem. Ext2 has a 7 years proven fsck. I've even recovered from physical disk errors, as well as a RAID miscue. Ext3 continues to add performance and other features, including POSIX EA/ACL support. NFS worked "off-the-bat" and quota support issues were worked out rather quickly. SGI's XFS is 8 years proven on Irix, and has always been 64-bit. The Linux version is a _direct_ port, 100% structure-wise. According to a Linux Gazette article several years back, XFS offers the most features as far as "data packing" and "offset/indexing" are concerned, as well as maximum file and filesystem sizes. Again, we're back to the design focus, GB sizes and TB filesystems for video and large data (and it's capable of PB, or petabyte as in 1 million terabyte, sizes). XFS also offers on-the-fly journal/fsck recovery (i.e. the filesystem is mounted, then flushed and checked real-time), although the filesystem won't mount when it needs an off-line "repair"** (which I've run into a couple of times after a crash). Best of all, despite all its "advanced features," XFS is _still_ a "traditional" filesystem design. That means it worked with NFS off-the-bat and was the _only_ journaling filesystem with _official_ Linux quota support for the longest time (not even Ext3 for awhile). SGI also made sure _all_ XFS features were ported, including _full_ POSIX ACL support, as well as their "xfsdump" utility that preserved them in backups (NOTE: RedHat 8.0 ships star which does both Ext3 and XFS ACLs now). And now that Linus standardized POSIX EA/ACL support in 2.5.3, the SGI team has moved to support the same ACL interfaces designed for Ext3, and have done so even on 2.4 in their forthcoming 1.2 release. ReiserFS is from the Namesys group who believes filesystems should be redesigned every 5 years. ReiserFS v4 is now a true 64-bit design that has a been given a DARPA research grant. The ReiserFS design itself is the most innovative approach, rather than the "evolutionary" ones of other JFSes. At the core is a database-like design that makes directory and indexing extremely fast, resulting in a non-traditional inode design. Although this, among other things, resulted in NFS support issues, even after Linus added it in stock 2.4.1+, most of those issues have been worked out in newer kernels with patches. Despite its age, ReiserFS _does_ have good journal recovery logic. It does a good job to fix any integrity automatically, and isn't shy to force you to run a repair** manually. And that's when you run into issues. Even though Linus required ReiserFS to "standardized" on a "fixed format" before he included ReiserFS v3 in the kernel, it still changes enough that sysadmins need to be "pro-active" in making sure their utilities are "in-sync" with the release. As such, I've seen people _toast_ their ReiserFS filesystems with a manual repair when required, because certain distro flavors** are not very "pro-active" in making sure the correct utilities ship with the correct kernel with ReiserFS. Lastly, I have no idea what IBM is trying to do with JFS, because it ported it from OS/2 instead of its AIX UNIX flavor -- which would have been more appropriate. IBM tends to do that to "avoid competition." The result is that I never looked at JFS because of its NFS, quota and other incompatibilities when it was first released. I don't know if IBM has addressed them either. Feature-wise the AIX version of JFS is almost as good as XFS, but Linux didn't get that version. And I have a further bias against JFS. As a long-time admin of OS/2 (1989-1996) and NT (1992-present, yes before 3.1 was even released, long story), I _hate_ both HPFS and NTFS. Why? Because they _always_ go to their journals to avoid a CHKDSK. The result is that I've had one HPFS and two NTFS _production_ volumes self-toast themselves. Downtime? Several days. I've heard (which means this could be heresy) that JFS from OS/2 (don't know about AIX) still practices that "aggressive journal recovery" logic that doesn't agree with me. I've known at least two people who saw their JFS filesystems self-corrupt due to recovery of an incomplete journal. [ ** NOTE: I've seen people running Mandrake with both XFS and ReiserFS toast their filesystems with the repair utilities because they weren't current, and/or the kernel patching was incompletely done. Mandrake might have the best installer and good looking utilities as well the latest versions of programs, but their QA testing is virtually non-existent, largely because they just "build and ship." People bitch about RedHat's "lag" on kernels and features, but damn them if they don't test their kernels 2+ months in-house in production file server roles. It's also why RedHat only supports Ext3. Although they ship ReiserFS code and utilities ship, their policy on non-support is because they don't want to deal with all the matching of kernel code and user-space utilities (which _is_ a pain with ReiserFS). Same deal with SGI and their XFS releases -- the code is usually in CVS for 2-3 months before release for "regression testing" before release. And XFS has only has 1 major problem (in 1.0, which was fixed with 1.1) since release on Linux. Also note that SGI _only_ officially supports it on RedHat and _no_other_ distro. On the XFS list I've regularly seen people have issues with non-RedHat versions from vendors who "sloppily" patch their kernels with XFS rather non-completely. ] -- Bryan J. Smith, E.I. (BSECE) Contact Info: http://thebs.org [ http://thebs.org/files/resume/BryanJonSmith_certifications.pdf ] ------------------------------------------------------------------ * A lecture on software piracy from Bill Gates is like a lecture * * on adultry from the owner of a brothel of other people's wives *
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Dvdrtools-users mailing list [EMAIL PROTECTED] http://mail.nongnu.org/mailman/listinfo/dvdrtools-users
