On Sat, 2010-08-14 at 16:45 -0700, Linda Walsh wrote:
Forward this from the linux-xfs list, in hoping that decision-makers will consider XFS as the default suse OS install choice. It continually bests other file systems in optimized configuration performance tests and these new improvements sound like they only add more speed to the equation.
You subject states "real-world application" but the attached message states "our benchmark scenario". There is no reason to believe their performance increases translate to the general case; and " very I/O-intensive, in-house developed real-time database application" certainly doesn't equate to the general laptop/workstation. I've been a UNIX/LINUX sys-admin for ~15 years; and a previous XFS proponent [and user]. However XFS faces several challenges: (1) The toolset is [or was, maybe it has improved] pretty crappy. The fsck for XFS was essentially just a no-op. In my experience xfs_check & xfs_repair were essentially useless. (2) Much of the performance benefit has diminished. Today's ext3 is not the ext3 of five-to-?? years ago. And most systems use ext4. I've no doubt XFS has improved as well. But in our application(s) I saw the difference between ext3 and XFS diminish over time as ext3 got faster [especially with the introduction of dir_index, which solved a *killer* ext3 performance issue]. The performance difference needs to be enough to make it worth being out of the main-stream [which is ext3/4; and *no* that is not a "political" consideration, it is a technical and support decision. There are lots of people who know lots about and have lots of experience with ext3/4; which is much less true of other file-systems.] The comment for "delaylog" is the following: <quote source="http://kernelnewbies.org/LinuxChanges#head-cb8e94576caa7c117ad3b6edc32686b8cc49a1ce"> 1.3. XFS Delayed logging This version adds a logging (journaling) mode called delayed logging, which is very briefly modeled after the journaling mode in the ext3/4 and reiserfs filesystems. It allows to accumulated multiple asynchronous transactions in memory instead of possibly writing them out many times. The I/O bandwidth used for the log decreases by orders of magnitude and performance on metadata intensive workloads increases massively. The log disk format is not changed, only the in-memory data structures and code. This feature is experimental, so it's not recommended for final users or production servers. Those who want to test it can enable it with the "-o delaylog" mount option. <quote> NOTE: "This feature is experimental, so it's not recommended for final users or production servers." Also note this behavior mimics that used by ext3/4.
For nearly all systems, disk speed is the bottle neck, so using the best solution possible should be strongly considered the default choice for all users -- regardless of 'political' concerns (which seem to often over-rule practicality, unfortunately).
I don't understand this point; I rarely see FOSS tainted by political concerns regarding technical decisions. That is usually an argument thrown out by the loosing side of the technical debate.
p.s. I am not part of the xfs project. I've just used it with open suse (or previously, Suse) since ~ 2002 and have never regretted it. Current filesystem read rates using XFS are about 1GB/second on sustained multi-gigabyte reads. Using 1Gbit ethernet, Samba gets 97MB/s read from disk to 115 MB/s read from memory and 125MB/s writes to memory or disk. -------- Original Message -------- Subject: observed significant performance improvement using "delaylog" in a real-world application Date: Tue, 10 Aug 2010 18:01:33 +0200 From: Peter Niemayer <niemayer@isg.de> To: linux-xfs@oss.sgi.com Hi all, we use XFS for a very I/O-intensive, in-house developed real-time database application, and whenever we see new or significantly changed file-systems becoming available, we run a benchmark using this application on a conserved, fixed real-world data set. I'm pleased to state that using the experimental "delaylog" mount option (in vanilla linux-2.6.35) we measured a 17% performance increase for our benchmark scenario. (Other mount-options in use both before and after the "delaylog" option: noatime,nodiratime,nobarrier) That's a lot given that XFS was the fastest performing file-system for this application already. It's also a promising result regarding stability, as several other tests (using e.g. reiser4 or ceph) in the past led to crashes in the same benchmark scenario. So thanks to all contributing developers for this significant optimization! Regards, Peter Niemayer -- Adam Tauno Williams <awilliam@whitemice.org> LPIC-1, Novell CLA <http://www.whitemiceconsulting.com> OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org