Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Mar 2005 14:16:31 -0800 (PST) Received: from quail.cita.utoronto.ca (quail.cita.utoronto.ca [128.100.76.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2VMGTqX028576 for ; Thu, 31 Mar 2005 14:16:29 -0800 Received: from cita.utoronto.ca (lemming.cita.utoronto.ca [128.100.76.53]) by quail.cita.utoronto.ca (8.12.11/8.12.11) with ESMTP id j2VMGOc5014904 for ; Thu, 31 Mar 2005 17:16:24 -0500 Received: from lemming.cita.utoronto.ca (localhost [127.0.0.1]) by cita.utoronto.ca (8.13.1/8.13.1) with ESMTP id j2VMGOpc022988 for ; Thu, 31 Mar 2005 17:16:24 -0500 Received: (from rjh@localhost) by lemming.cita.utoronto.ca (8.13.1/8.13.1/Submit) id j2VMGO88022987 for linux-xfs@oss.sgi.com; Thu, 31 Mar 2005 17:16:24 -0500 Date: Thu, 31 Mar 2005 17:16:24 -0500 From: Robin Humble To: linux-xfs@oss.sgi.com Subject: Re: RHEL 4 -- how build kernel with xfs? Message-ID: <20050331221624.GA17344@lemming.cita.utoronto.ca> References: <200503302123.56513.kewley@gps.caltech.edu> <20050331061345.GA32325@lemming.cita.utoronto.ca> <200503311300.38901.kewley@gps.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503311300.38901.kewley@gps.caltech.edu> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/798/Thu Mar 31 01:54:41 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5201 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rjh@cita.utoronto.ca Precedence: bulk X-list: linux-xfs Content-Length: 1596 Lines: 41 On Thu, Mar 31, 2005 at 01:00:38PM -0800, David Kewley wrote: >I wonder what they'd say to raw performance numbers. Maybe something like The most disturbing thing about bonnie++ numbers isn't XFS related - the 'rewrite' speed in 2.6 is dreadful - it's about 6x less than a 2.4 kernel!!! I think it's a NFS client problem as a 2.4 client talking to a 2.6 server sees ok numbers again. it seems to be filesystem independent. >"Those differences don't matter in real life." or "Sequential I/O isn't >representative of real use." :) Whatever the case, the more of their you'd think RHEL AS4 as an NFS server would be a very common configuration and that RedHat would want it to go faster... :-/ XFS does well at the large single files workload eg. film industry or computational cluster. When testing I didn't pay much attention to benchmarks of small files etc., but maybe it's not so good at that. Still, choice is a good thing, and for a proportion of RedHat customers it'd be a significant win. >customers make the case to them for supporting xfs, and the more that provide >good hard reasons why, the more likely they are to consider investing in >in-house xfs expertise. indeed. >to me. I took a gander at your website, and it sounds like we're in similar >situations. I'm a sysadmin for a computational geophysics beowulf. The computational astrophysics here. >fileserver I'm asking about is a 9.6TB raw (24x400) 3-ware 9500 based box. :) yup, pretty much the same here except we haven't got the box fully loaded with disks yet. seems like a nice toy :) cheers, robin