From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: with ECARTIS (v1.0.0; list xfs); Wed, 29 Nov 2006 16:48:53 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kAU0mdaG010803 for ; Wed, 29 Nov 2006 16:48:42 -0800 Message-ID: <456E2A30.4010101@melbourne.sgi.com> Date: Thu, 30 Nov 2006 11:47:44 +1100 From: David Chatterton Reply-To: chatz@melbourne.sgi.com MIME-Version: 1.0 Subject: Re: inode64 workaround References: <200611290027.AA04740@TNESG9305.tnes.nec.co.jp> <1164838985.4992.30.camel@edge> <456E1B08.7090802@delusion.com> In-Reply-To: <456E1B08.7090802@delusion.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com List-Id: xfs To: Deanan Cc: xfs@oss.sgi.com Deanan, Would something like the inode rotor help? fs.xfs.rotorstep (Min: 1 Default: 1 Max: 256) In "inode32" allocation mode, this option determines how many files the allocator attempts to allocate in the same allocation group before moving to the next allocation group. The intent is to control the rate at which the allocator moves between allocation groups when allocating extents for new files. David Deanan wrote: > > Hi, > > I've got some systems that I can't change the kernel on (external > vendor) that > are 32bit but I'm running into the performance problem that is fixed by > using > inode64. Is there any known way of working around the problem on a 32bit > kernel? > > In our case, the problem occurs as soon as you start to delete files and > write new ones. > > Cheers, > > Deanan > -- David Chatterton XFS Engineering Manager SGI Australia