Received: with ECARTIS (v1.0.0; list xfs); Thu, 24 Jan 2008 07:50:29 -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=0.6 required=5.0 tests=AWL,BAYES_00,RCVD_NUMERIC_HELO autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0OFoN1E021946 for ; Thu, 24 Jan 2008 07:50:25 -0800 X-ASG-Debug-ID: 1201189843-78eb00590000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail161.messagelabs.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id B768B5569F7 for ; Thu, 24 Jan 2008 07:50:43 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by cuda.sgi.com with SMTP id tb098A8DjyklIh9f for ; Thu, 24 Jan 2008 07:50:43 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: salmr0@bp.com X-Msg-Ref: server-6.tower-161.messagelabs.com!1201189841!10611962!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.230.248.44] Received: (qmail 25720 invoked from network); 24 Jan 2008 15:50:42 -0000 Received: from unknown (HELO bp1xeuav001.bp1.ad.bp.com) (129.230.248.44) by server-6.tower-161.messagelabs.com with SMTP; 24 Jan 2008 15:50:42 -0000 Received: from bp1xeuex712.bp1.ad.bp.com ([149.182.218.243]) by bp1xeuav001.bp1.ad.bp.com with InterScan Messaging Security Suite; Thu, 24 Jan 2008 15:50:17 -0000 Received: from BP1XEUEX706-C.bp1.ad.bp.com ([149.182.218.110]) by bp1xeuex712.bp1.ad.bp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Jan 2008 15:50:17 +0000 Received: from 149.179.228.36 ([149.179.228.36]) by BP1XEUEX706-C.bp1.ad.bp.com ([149.182.218.28]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 Jan 2008 15:50:16 +0000 Received: from holwrs01 by BP1XEUEX706-C.bp1.ad.bp.com; 24 Jan 2008 09:50:16 -0600 X-ASG-Orig-Subj: Re: xfs_rapair memory requirement per TB Subject: Re: xfs_rapair memory requirement per TB From: Rene Salmon To: Barry Naujok Cc: David Chinner , Ralf Gross , xfs@oss.sgi.com In-Reply-To: References: <1201042882.32649.256.camel@holwrs01.bp.com> <20080123085339.GB12435@p15145560.pureserver.info> <20080124002828.GC155259@sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 24 Jan 2008 09:50:16 -0600 Message-Id: <1201189816.32649.358.camel@holwrs01.bp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 X-OriginalArrivalTime: 24 Jan 2008 15:50:17.0308 (UTC) FILETIME=[D0EDC1C0:01C85EA0] X-Barracuda-Connect: mail161.messagelabs.com[216.82.253.115] X-Barracuda-Start-Time: 1201189843 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.77 X-Barracuda-Spam-Status: No, SCORE=-0.77 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=RCVD_NUMERIC_HELO, UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.40372 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.25 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Virus-Scanned: ClamAV 0.91.2/5544/Thu Jan 24 03:02:44 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14278 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: salmr0@bp.com Precedence: bulk X-list: xfs > >> > > >> > 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? Thanks Rene >