Received: with ECARTIS (v1.0.0; list xfs); Thu, 24 Jan 2008 16:01:55 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_42 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0P00hIf029234 for ; Thu, 24 Jan 2008 16:00:46 -0800 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA12170; Fri, 25 Jan 2008 11:00:57 +1100 Date: Fri, 25 Jan 2008 11:01:09 +1100 To: "Rene Salmon" Subject: Re: xfs_rapair memory requirement per TB From: "Barry Naujok" Organization: SGI Cc: "Ralf Gross" , xfs@oss.sgi.com Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <1201042882.32649.256.camel@holwrs01.bp.com> <20080123085339.GB12435@p15145560.pureserver.info> <20080124002828.GC155259@sgi.com> <1201189816.32649.358.camel@holwrs01.bp.com> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <1201189816.32649.358.camel@holwrs01.bp.com> User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/5546/Thu Jan 24 13:32:07 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14280 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Fri, 25 Jan 2008 02:50:16 +1100, Rene Salmon wrote: > > > > >> >> > >> >> > General rule of thumb at the moment is 128MB of RAM/TB of >> filesystem >> >> > plus 4MB/million inodes on that filesystem. >> >> >> >> Did this change lately? I found the rule of thumb: 2 GB RAM for 1 >> TB >> >> of disk storage + some RAM per x inodes. >> > >> > The above is based on actual theoretical usage, the below: >> > >> >> http://oss.sgi.com/archives/xfs/2005-08/msg00045.html >> > >> > was based on reported usage on during live repair runs. >> > >> > I think Barry discovered the difference to be things external >> > to repair such as heap fragmentation and has since corrected >> > the worst of the issues so requirements are, in general, >> > much closer to the theoretical numbers now. >> >> Yes, quite a few memory improvements have been made. >> >> Right now, I can repair a 9TB filesystem with ~150 million inodes >> in 2GB of RAM without going to swap using xfs_repair 2.9.4 and >> with no custom/tuning/config options. > > > > > Thanks. That is great news about the memory improvements. We currently > run SLES 10 SP1 which comes with: > > hpcxe005:# xfs_repair -V > xfs_repair version 2.8.16 > > others come with: > > hpcxe001:~ # xfs_repair -V > xfs_repair version 2.9.2 > > > Did the memory improvements make it into 2.8.16? How about 2.9.2? If not > i take it we can download the latest source and just have the 2.9.4 > xfs_repair binary laying around in case we ever need to use it. Would > using a 2.9.4 xfs_repair binary on a 2.8.16 created xfs file system > cause any problems? The memory improvements showed up in 2.9.2. As Ralf said, xfs_repair can always fix older mkfs'ed filesystems. Regards, Barry.