Point/Counterpoint - Ext3 vs. XFS
Unlike the Twitter-fest that was the previous column, this time Bill will be able to talk in full sentences—even if they are more than 140 characters! Stay tuned for Kyle's love of (and Bill's angst toward) XFS.
Kyle: Okay, I admit I use ext3 in plenty of systems. It's an all-around good filesystem, but when I need high performance, especially with large files, I always turn to XFS.
Bill: That's fine and dandy when you're running Debian or Ubuntu, but what about a Red Hat box? And, no, CentOS, although cool, doesn't count here. I'm talking the actual Crimson Fedora here—Red Hat. It doesn't support XFS in its kernel at all, does it? So, you're forced to build your own stuff, and then you're in for an admin headache.
Kyle: Well, you already ruled out CentOS, but if you are stuck in a Red Hat-like environment and want high performance, like XFS, you might have to stray from the list of supported packages and either use CentOS or a custom repository. In any case, it wouldn't be the first time an admin had to make up for the limited set of supported packages in Red Hat.
Bill: Pop quiz, hotshot: does that break you out of the support matrix for Red Hat?
Kyle: My understanding is that you would pop out of support only for problems that are directly related to the filesystem or kernel. I'll be honest though, in all the years I've had Red Hat support, I can't think of a time I legitimately needed it. I have, however, had plenty of situations where a developer wanted to use the filesystem like a database and store millions of files in huge nested directories—something XFS handles quite well.
Bill: Shhh. You'll anger a possible advertiser. Didn't we engage them once on a dm-mapper or ocfs issue or something? But yeah, that's a tangential thing—just because you don't use the support doesn't mean you don't need it. There's a reason you continue to pay that fee. And with respect to developers using the filesystem as a database, we've both seen that. XFS helps here, but redesigning your whole filesystem isn't necessarily a fix for poor software architectural design. (I used the architectural word in there—bonus points for me!)
Kyle: Yeah, yeah, put away your drafting table Mr Architect. We both know how rarely a sysadmin can dictate how a developer solves a problem. In any case, there isn't much of a redesign. In a Red Hat-based system, it's a matter of a different kernel package (included with CentOS) and reformatting a filesystem. With a Debian-based system, the ability is already there. In any case, you don't have to format everything with XFS, only the filesystems where it would benefit.
Bill: True. Speaking of ability, what about the ability to recover a system when things go pear-shaped? I've never had any luck fixing an XFS filesystem—they've always gobbled my data. Ext3 may be slow, but I've always been able to save something off a damaged filesystem.
Kyle: See, I've had the exact opposite experience. The one big advantage in my mind to XFS is how well the recovery tools work. I've lost data on basically every major filesystem out there from ReiserFS (let's not go there) to ext2 and ext3 and yes, even XFS, but whenever I've needed to do a recovery, the XFS recovery tools always have been successful, even when the problem was related to a bad hard drive controller.
Bill: Well, I may be biased, as I formatted my laptop with XFS at your behest some years ago and watched as a fun bug gobbled all my data. I never did recover that, if you recall.
Kyle: Like I said, I've had data gobbled by every filesystem. I'll also note that I never was really bitten by that bug, but I do remember a pretty nasty ext3 bug from a few years back that was so bad they actually labeled the kernel as defective after the fact. I've used XFS on my personal systems both for large file storage and even as the filesystem for my own /home directory on my personal laptop now, without issue. The fact is, I noticed a tangible difference on the speed of my system when I moved to XFS.
Bill: I know you have. You have a halo effect about you with things like that though. I have...the opposite effect. If it can break, I will break it. I've always been able to recover from an ext3 explosion. For me, it's not about the speed. The ext3 filesystem and tools are well known and have been shipped in everything. I know if my machine dies, I can move the disk to another Linux box and be able to read the filesystem, or I can use a “standard” recovery disk. Heck, there are even plugins for other OSes that can read ext3. Try that with XFS.
Kyle: My standard recovery disc always has been Knoppix [insert plug here], and it always has worked just fine with XFS filesystems. I'm not saying that XFS should be used for everything. There's a reason ext3 is the default filesystem for most distributions. After all, it offers good all-around performance for all kinds of filesystems. When you need high performance for terabytes of large files or millions of small files though, it's hard to beat XFS. Even formatting an XFS filesystem is substantially faster than ext3.
Bill: I'm not arguing that XFS isn't faster—it is, and by a large margin. I don't think it's as safe, however.
Kyle: I think these days the biggest risk on any system isn't from filesystem corruption. It's either from hard drive failure or from user error. In either case, if you are that worried, you should have a solid, tested backup system in place.
Bill: True, no filesystem or RAID is a substitute for a solid backup method. That's something we do agree on.
Kyle: The bottom line for me is that whenever I reach the limits of ext3, I know I have a solid, fast alternative in XFS. The XFS recovery tools are excellent, and in my experience, they work well. Plus, it's been available in Linux long enough to iron out any major bugs and is available in anything from CentOS to Debian to Ubuntu. When I want an ordinary filesystem, I choose ext3, but when I need speed, I choose XFS.
Bill: Except that XFS isn't available from Red Hat, and that's a considerable installed base. Just because something is faster doesn't necessarily mean it's the best long-term solution. XFS may be more capable, but the downside of possibly falling out of a supportable configuration at the enterprise level keeps me from deploying XFS on anything but nonessential gear.
Last minute note from Bill: Just as we were readying this for print, Red Hat announced that XFS will be in the Red Hat Enterprise 5.4 beta. My arguments will be sent to /dev/null after 5.4 releases.
Kyle Rankin is a Senior Systems Administrator in the San Francisco Bay Area and the author of a number of books, including Knoppix Hacks and Ubuntu Hacks for O'Reilly Media. He is currently the president of the North Bay Linux Users' Group.
Bill Childers is an IT Manager in Silicon Valley, where he lives with his wife and two children. He enjoys Linux far too much, and he probably should get more sun from time to time. In his spare time, he does work with the Gilroy Garlic Festival, but he does not smell like garlic.
Kyle Rankin is a VP of engineering operations at Final, Inc., the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal. Follow him @kylerankin.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SourceClear Open
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide