On Wed, 17 Apr 2002, Richard Troy wrote: > One observation I have is that many people have a bizarre, one-sided view > of performance. This is true of a vast number of human activities, such as > the automobile driver who focuses on driving on dry, smooth pavement and > forgets s/he drives in the wet on rough roads. ...And, it's common enough > throughout the disciplines of computer science, such as the database > engineer who focuses on transactions per second and forgets about failure > recovery time... ??? One of my observations was about restart times ... I find that on a pair of ~30G filesystems, jfs recovers much more quickly than another FS. I also should note that ext3 works very well ... in fact I did an upgrade a long time ago converting ext2 to ext3 and experienced no trouble whatsoever. A problem rebooting isn't necessarily any fault of the ext3 fs, which had been found useful in many situations, apparently gives excellent performance on database systems and in my experience has yet to foul up in any way over a large number of unexpected shutdowns (children, unstable 3D graphics and a bit of trouble with SB Live! drivers :o) > And so it is with file systems: Some aspects of performance which I find > are critical of a file system seem to be completely ignored or at least > discounted and put as low priority by current practitioners. (...I have > left below the previous keystrokes of this thread for easy review to see > what I'm talking about.) What are these over-looked aspects of > performance? Two things: Data security (safty) and system restart times. Having a mixture of three filesystems my home workstation, and two on this mail server, I've had some chance to compare them. As far as *data* integrity is concerned, use ext3. > Here's my imperative: Every change to the structure on disk _must_be_ > written to disk that very instant. On-disk structure changes are _the_ > most critical aspect. Caching disk structure is fine, but having changes > in cache that are not yet reflected on disk is, OK, I'll say it: STUPID. > (Note that I'm _only_ talking about the disk structure, not file data.) > With a stale cache, if power is cut or any other malfeasance occurrs, the > entire volume is at risk. FSCK, even if it works flawlessly every time, is > another silly thing: The file system _should_ provide for knowledge of > what files were open at the time, and a check be made only of them, where > that may make sense. (Some file systems of the past have not needed _any_ > fsck type of checking following system failure, and they have been quite > reliable.) I remain in dumbfounded awe that Unix/Linux has come all this > way with such a fundamentally flawed file system paradigm. This is exactly what journalled/logged filesystems do. There are two supported in the current kernel, one more included in the RH kernels and yet another available as a set of patches and included in at least one of the "alternative" kernel trees maintained by the likes of Alan Cox, David Jones et al. These are ext3, reiserfs, jfs and xfs. > That said, I've heard that there are some new file system types available > that address my concerns. I sure wish I had time to hunt them down! It's > my guess that some of you are familliar with these file systems. ...I am, > (we are) running Red Hat 7.2 on most of my/our systems and would love to > find a file system that makes me feel more at ease. It's rare, but does > happen that a system will need a kick in the pants and has to be brought > down abruptly. If the file system weren't so flawed, I'd be much less > anxious at these moments! Hunt them down? They're in front of you! > Yes, I have even turned on sync, but from a performance standpoint, it's a > dumb way to go since _all_ data is written synchronously - it's only a > move of desperation. Still, for some of our more critical systems, sync is > left ON! That's how important this issue is. Try ext3 with the current default settings. > Please note that in my experience, ext3 doesn't work. When I upgraded my > systems from RH 6.2 to 7.2, I tried to tell it to use ext3, the default, > on several systems and each time was rewarded with a system that wouldn't > boot. (I don't recall just what the errors were, unfortunately.) If you're > going to propose an alternative file system, please give me some practical > advice about how I'm going to apply it. This doesn't show that "ext3 doesn't work" at all, it shows some flaw in the upgrade process; report the fault properly! Sure, having problems would put me off, but please give it a try out before rejecting it out of hand. > Thank you for your thoughts, > Richard
