From owner-linux-xfs@oss.sgi.com Sat Mar 1 03:54:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Mar 2003 03:54:28 -0800 (PST) Received: from mail.automatix.de ([62.67.57.175]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h21BsNeA006459 for ; Sat, 1 Mar 2003 03:54:24 -0800 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.35 #1) id 18p5ZO-0003JY-00 for linux-xfs@oss.sgi.com; Sat, 01 Mar 2003 12:54:22 +0100 Received: from pc2.s.automatix.de ([192.168.11.12]) by s.automatix.de with esmtp (Exim 3.36 #1) id 18p5Tg-0006bx-00; Sat, 01 Mar 2003 12:48:28 +0100 From: Juergen Sauer Reply-To: juergen.sauer@automatix.de Organization: AutomatiX GmbH To: Bernhard Erdmann Subject: Re: XFS version 1 on linux Date: Sat, 1 Mar 2003 12:48:33 +0100 User-Agent: KMail/1.5 Cc: Christopher Pelton , linux-xfs@oss.sgi.com References: <200302280906.16457.juergen.sauer@automatix.de> <3E6050F2.3000908@berdmann.de> In-Reply-To: <3E6050F2.3000908@berdmann.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200303011248.37172.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h21BsOeA006460 X-archive-position: 2987 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: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Samstag, 1. März 2003 07:19 schrieb Bernhard Erdmann: > Juergen Sauer wrote: > [...] > > Ok, all that should work, really. > > You shold be able to: > > - transfer the DVDs > > - transfer the Harddisks > > - Install Linux on the SGI machine (http://www.debian.org) > > > > First, you may Check it / Test is before you do the real work: > > You find at: http://www.knopper.net/knoppix/ > > an single iso-CD Linux, ready to run without installing anything, just > > burn it to CD. > > It has the current XFS included and you may test your datatransfer > > work without any risks. > I guess this SGI box has one or more MIPS CPU - Knoppix is for the i386 > architecture. Of course, Knoppix is to test out on PC/i386 Achitecture. You need a MIPS Distribution for Running on SGI Hardware, there a lot aroud. mfG Jojo - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** ** http://www.automatix.de http://www.kranautomatisierung.de ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+YJ4TW7UKI9EqarERAs4wAKDULKpngIVtTNr1+TLRNQ04B0nlZgCeKUCY La1SDl/hVkk8xZJHJBHiYqw= =f+7K -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sat Mar 1 05:44:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Mar 2003 05:44:11 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h21Di7eA008164 for ; Sat, 1 Mar 2003 05:44:08 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h21Di2Kp009561 for ; Sat, 1 Mar 2003 05:44:02 -0800 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA18290; Sat, 1 Mar 2003 07:44:01 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-24.corp.sgi.com [134.15.64.24]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA66020; Sat, 1 Mar 2003 07:44:00 -0600 (CST) Subject: Re: Compile Error....kmem_zalloc From: Stephen Lord To: Scott Jepson Cc: Marc Schmitt , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 01 Mar 2003 07:42:44 -0600 Message-Id: <1046526165.1711.38.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 2988 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: lord@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2003-02-28 at 11:04, Scott Jepson wrote: > Looks like I'm running a different qlogin driver: > > kernel: 2.4.20 > XFS: 1.2.0 > qla2xxx: qla2x00-v6.04.00b8 I am running this version - but xfs is built in and the driver is a module. Steve From owner-linux-xfs@oss.sgi.com Sat Mar 1 09:30:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Mar 2003 09:30:36 -0800 (PST) Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h21HU9eA010162 for ; Sat, 1 Mar 2003 09:30:10 -0800 Received: from [209.96.179.24] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.36 #1) id 18pABC-000Etv-00; Sat, 01 Mar 2003 11:49:42 -0500 Received: from daydream.shannon.net (daydream.shannon.net [192.168.1.10]) by escape.shannon.net (8.11.6/8.11.3) with ESMTP id h21GXJr22449; Sat, 1 Mar 2003 11:33:19 -0500 (EST) Received: from daydream.shannon.net (localhost [127.0.0.1]) by daydream.shannon.net (8.12.4/8.11.4) with ESMTP id h21GXFUY004011; Sat, 1 Mar 2003 11:33:15 -0500 Received: (from shannon@localhost) by daydream.shannon.net (8.12.4/8.12.4/Submit) id h21GX9X9004004; Sat, 1 Mar 2003 11:33:09 -0500 Date: Sat, 1 Mar 2003 11:33:09 -0500 From: Charles Shannon Hendrix To: linux-xfs@oss.sgi.com Cc: linux-list@ssc.com, ext3-users@redhat.com Subject: Re: XFS vs. ext3 Message-ID: <20030301163305.GA3906@widomaker.com> Mail-Followup-To: linux-xfs@oss.sgi.com, linux-list@ssc.com, ext3-users@redhat.com References: <20030226044329.GP2107@dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030226044329.GP2107@dkp.com> User-Agent: Mutt/1.4i X-archive-position: 2989 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: shannon@widomaker.com Precedence: bulk X-list: linux-xfs On Tue, Feb 25, 2003 at 11:43:30PM -0500, Andrew Klaassen wrote: > In our last IMAX film project, right at crunch time, we were > getting a whole bunch of dropped frames during compositing. Our > compositing program would report "invalid file" partway through > writing, and move on to the next frame. I assume you are getting the error on the Windows machine, correct? If that's true, I don't know you can blame ext3. For one thing, you cannot drop a frame or anything due to a particular filesystem unless there is an error; the filesystem code has failed. This should show up as a serious problem or at least a system log entry. Did you check the Linux side of things, in Samba and system logs? I guess I'm trying to figure out how you know it is the filesystem. -- UNIX/Perl/C/Pizza____________________s h a n n o n@wido !SPAM maker.com From owner-linux-xfs@oss.sgi.com Sat Mar 1 21:05:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Mar 2003 21:05:38 -0800 (PST) Received: from c2mailgw02.mailcentro.net (c2gw.mailcentro.com [207.183.238.8]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h2255ZeA015880 for ; Sat, 1 Mar 2003 21:05:35 -0800 Received: from c2web201 (207.183.238.51) by c2mailgw02.mailcentro.net (NPlex 6.0.045) id 3E615A3500021C5C for linux-xfs@oss.sgi.com; Sat, 1 Mar 2003 20:07:00 -0800 X-Version: Mailcentro 1.0 X-SenderIP: 68.46.72.236 X-SenderID: 5759619 From: "Vash the Stampede" Message-Id: <75B45FA2F6741EF49BD14FAC68423EFD@webmaster.kkpc.zzn.com> Date: Sat, 1 Mar 2003 23:11:31 -0500 X-Priority: Normal Content-Type: text/html To: linux-xfs@oss.sgi.com Reply-To: Webmaster@kkpc.zzn.com Subject: XFS Problem - mkfs.xfs: No such file or directory X-Mailer: Web Based Pronto Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-archive-position: 2990 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: webmaster@kkpc.zzn.com Precedence: bulk X-list: linux-xfs
mymachine dev # mkfs -t xfs /dev/hda5
mkfs.xfs: No such file or directory
mymachine dev # uname -a
Linux mymachine.mydomain.com 2.4.19-xfs #2 Sat Mar 1
22:41:09 EST 2003          own CPU Type AuthenticAMD
GNU/Linux


That's the output of my console. I cannot figure out why this isn't
working, but it isn't. I patched my kernel using the XFS 1.2
Release patch on a 2.4.19 vanilla-sources kernel from kernel.org

I'm in desperate need of an answer for this problem, since I need
to make a partition soon.



Get your Free E-mail at http://kkpc.zzn.com
___________________________________________________________
Get your own Web-based E-mail Service at http://www.zzn.com

From owner-linux-xfs@oss.sgi.com Sat Mar 1 21:22:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Mar 2003 21:22:17 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h225MAeA016425 for ; Sat, 1 Mar 2003 21:22:12 -0800 Received: (qmail 29871 invoked from network); 2 Mar 2003 05:22:08 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 2 Mar 2003 05:22:08 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id C4366300087; Sun, 2 Mar 2003 16:22:06 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id A69018F; Sun, 2 Mar 2003 16:22:06 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Webmaster@kkpc.zzn.com Cc: linux-xfs@oss.sgi.com Subject: Re: XFS Problem - mkfs.xfs: No such file or directory In-reply-to: Your message of "Sat, 01 Mar 2003 23:11:31 CDT." <75B45FA2F6741EF49BD14FAC68423EFD@webmaster.kkpc.zzn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 02 Mar 2003 16:22:01 +1100 Message-ID: <22247.1046582521@ocs3.intra.ocs.com.au> X-archive-position: 2991 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: kaos@sgi.com Precedence: bulk X-list: linux-xfs On Sat, 1 Mar 2003 23:11:31 -0500, "Vash the Stampede" wrote: > Please send in plain text to this list, not html. >mkfs.xfs: No such file or directory What does 'ldd -v /sbin/mkfs.xfs' report? From owner-linux-xfs@oss.sgi.com Sat Mar 1 21:25:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Mar 2003 21:25:58 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h225PueA016866 for ; Sat, 1 Mar 2003 21:25:56 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h225PoKp007602 for ; Sat, 1 Mar 2003 21:25:50 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id XAA04579; Sat, 1 Mar 2003 23:25:49 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id XAA22598; Sat, 1 Mar 2003 23:25:49 -0600 (CST) Date: Sat, 1 Mar 2003 23:22:45 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Vash the Stampede cc: linux-xfs@oss.sgi.com Subject: Re: XFS Problem - mkfs.xfs: No such file or directory In-Reply-To: <75B45FA2F6741EF49BD14FAC68423EFD@webmaster.kkpc.zzn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by zok.sgi.com id h225PoKp007602 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h225PueA016869 X-archive-position: 2992 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs You need to install the xfsprogs userspace. ftp://oss.sgi.com/projects/xfs/Release-1.2/cmd_tars -Eric On Sat, 1 Mar 2003, Vash the Stampede wrote: > mymachine dev # mkfs -t xfs /dev/hda5 > mkfs.xfs: No such file or directory > mymachine dev # uname -a > Linux mymachine.mydomain.com 2.4.19-xfs #2 Sat > Mar 1 > 22:41:09 EST 2003          own CPU Type > AuthenticAMD > GNU/Linux > > > That's the output of my console. I cannot figure > out why this isn't > working, but it isn't. I patched my kernel using > the XFS 1.2 > Release patch on a 2.4.19 vanilla-sources kernel > from kernel.org > > I'm in desperate need of an answer for this > problem, since I need > to make a partition soon. > > > > Get your Free E-mail at http://kkpc.zzn.com > ___________________________________________________________ > Get your own Web-based E-mail Service at > http://www.zzn.com > > > From owner-linux-xfs@oss.sgi.com Sun Mar 2 07:56:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Mar 2003 07:56:55 -0800 (PST) Received: from zafiro.ciencias.ubiobio.cl (IDENT:postfix@zafiro.ciencias.ubiobio.cl [146.83.193.221]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h22FukeA029462 for ; Sun, 2 Mar 2003 07:56:47 -0800 Received: by zafiro.ciencias.ubiobio.cl (Postfix, from userid 500) id BD48613DF8; Sun, 2 Mar 2003 12:56:40 -0300 (CLST) Received: from localhost (localhost [127.0.0.1]) by zafiro.ciencias.ubiobio.cl (Postfix) with ESMTP id AB0F313DEE; Sun, 2 Mar 2003 12:56:40 -0300 (CLST) Date: Sun, 2 Mar 2003 12:56:39 -0300 (CLST) From: Leonardo Saavedra Henriquez X-Sender: leo@zafiro.ciencias.ubiobio.cl To: Vash the Stampede Cc: linux-xfs@oss.sgi.com Subject: Re: XFS Problem - mkfs.xfs: No such file or directory In-Reply-To: <75B45FA2F6741EF49BD14FAC68423EFD@webmaster.kkpc.zzn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2993 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: leo@ubiobio.cl Precedence: bulk X-list: linux-xfs On Sat, 1 Mar 2003, Vash the Stampede wrote: > I'm in desperate need of an answer for this > problem, since I need > to make a partition soon. Which Linux distributions? if is RedHat or rpm based, you need to install xfsprogs from ftp://oss.sgi.com/projects/xfs/cmd_rpms/ if your distribution is debian you only need to "apt-get it" apt-get install xfsprogs xfsdump attr attr-dev or follow the instruccion for cvs download from xfs home page and then you have to compile your self xfsprogs. -- +----------------------------------------------+ ,''`. | Leonardo Saavedra Henriquez |leo@ubiobio.cl | : :' : | Est. Ing Civil en Informatica|U. del Bio-Bio | `. `' +----------------------------------------------+ `- [leo-> ~ $] cd pub && more beer From owner-linux-xfs@oss.sgi.com Sun Mar 2 14:33:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Mar 2003 14:34:04 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h22MXueA032589 for ; Sun, 2 Mar 2003 14:33:58 -0800 Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 18pc1s-0005Df-00 for linux-xfs@oss.sgi.com; Sun, 02 Mar 2003 23:33:56 +0100 Received: from [217.88.212.121] (helo=kernelpanix.aura.of.mankind) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 18pc1r-0000Ai-00 for linux-xfs@oss.sgi.com; Sun, 02 Mar 2003 23:33:56 +0100 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.6/8.11.2) id h22MSUW16501 for linux-xfs@oss.sgi.com; Sun, 2 Mar 2003 23:28:30 +0100 Date: Sun, 2 Mar 2003 23:28:30 +0100 From: utz lehmann To: linux-xfs@oss.sgi.com Subject: [PATCH] xfs_fsr: avoid unnessary copying Message-ID: <20030302232830.A16452@s2y4n2c.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 2994 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: xfs@s2y4n2c.de Precedence: bulk X-list: linux-xfs Hi This patch moves the check for improved extent count directly after the preallocation of the extents. So it can avoid copying of the extent data in the case that no improvement is made. The patch is against current CVS. On my testsystem with 3 files which cant improved the elapsed time went down from 3min to 6s and saved about 3GB disk io. utz --- xfs_fsr.c.orig Sat Mar 1 13:53:36 2003 +++ xfs_fsr.c Sun Mar 2 23:02:25 2003 @@ -967,7 +967,8 @@ { int tfd; int srval; - int nextents, extent, cur_nextents, new_nextents; + int nextents, extent, cur_nextents; + int new_nextents = 0; unsigned blksz_dio; unsigned dio_min; struct dioattr dio; @@ -1111,6 +1112,15 @@ return -1; } } + /* Check if the extent count improved */ + new_nextents = getnextents(tfd); + if (cur_nextents <= new_nextents) { + if (vflag) + fsrprintf(_("No improvement made: %s\n"), fname); + close(tfd); + free(fbuf); + return 1; /* no change/no error */ + } for (cnt = outmap[extent].bmv_length; cnt > 0; cnt -= ct, pos += ct) { if (nfrags && --nfrags) { @@ -1195,15 +1205,6 @@ sx.sx_offset = 0; sx.sx_length = statp->bs_size; - /* Check if the extent count improved */ - new_nextents = getnextents(tfd); - if (cur_nextents <= new_nextents) { - if (vflag) - fsrprintf(_("No improvement made: %s\n"), fname); - close(tfd); - return 1; /* no change/no error */ - } - /* switch to the owner's id, to keep quota in line */ if (fchown(tfd, statp->bs_uid, statp->bs_gid) < 0) { if (vflag) From owner-linux-xfs@oss.sgi.com Sun Mar 2 15:18:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Mar 2003 15:19:04 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h22NIqeA000814 for ; Sun, 2 Mar 2003 15:18:52 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h22NIkG8031990 for ; Sun, 2 Mar 2003 15:18:46 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA29919; Sun, 2 Mar 2003 17:18:46 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id RAA80928; Sun, 2 Mar 2003 17:18:46 -0600 (CST) Date: Sun, 2 Mar 2003 17:15:34 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: utz lehmann cc: linux-xfs@oss.sgi.com Subject: Re: [PATCH] xfs_fsr: avoid unnessary copying In-Reply-To: <20030302232830.A16452@s2y4n2c.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2995 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Thanks Utz - Chris W. had talked about doing this too, I'm glad someone got around to it. :) I'll look at the patch more closely when I'm in the office tomorrow, but it sounds like the right thing to do. -Eric On Sun, 2 Mar 2003, utz lehmann wrote: > Hi > > This patch moves the check for improved extent count directly after the > preallocation of the extents. So it can avoid copying of the extent data in > the case that no improvement is made. The patch is against current CVS. > > On my testsystem with 3 files which cant improved the elapsed time went down > from 3min to 6s and saved about 3GB disk io. > > > utz > From owner-linux-xfs@oss.sgi.com Sun Mar 2 16:38:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Mar 2003 16:38:33 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h230cNeA003685 for ; Sun, 2 Mar 2003 16:38:24 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h230mbkq003975 for ; Sun, 2 Mar 2003 18:48:38 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h230ax7L482624 for ; Mon, 3 Mar 2003 11:36:59 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h230axSu481802 for linux-xfs@oss.sgi.com; Mon, 3 Mar 2003 11:36:59 +1100 (EST) Date: Mon, 3 Mar 2003 11:36:59 +1100 (EST) From: Nathan Scott Message-Id: <200303030036.h230axSu481802@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_stats.pl X-archive-position: 2996 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Cleanup code, add missing pb_get_read metric, leave quota metrics to xqmstats (in quota-tools package) giving more compact layout here. Date: Sun Mar 2 16:35:14 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:140671a cmd/xfsmisc/xfs_stats.pl - 1.4 From owner-linux-xfs@oss.sgi.com Mon Mar 3 09:55:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Mar 2003 09:55:17 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h23Ht7eA013489 for ; Mon, 3 Mar 2003 09:55:07 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h23Ht1G8025910 for ; Mon, 3 Mar 2003 09:55:01 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA33095 for ; Mon, 3 Mar 2003 11:55:01 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA52669 for ; Mon, 3 Mar 2003 11:55:01 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h23Ht0g28911; Mon, 3 Mar 2003 11:55:00 -0600 Message-Id: <200303031755.h23Ht0g28911@jen.americas.sgi.com> Date: Mon, 3 Mar 2003 11:55:00 -0600 Subject: TAKE - some optizations in writing out the xfs log To: linux-xfs@oss.sgi.com X-archive-position: 2998 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 727 Lines: 25 reduce byte swapping and spinlock usage in log write path Date: Mon Mar 3 09:54:29 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140714a linux/fs/xfs/xfs_log.c - 1.265 - only update h_numlog_ops and the iclog byte offset once per use of an iclog in a transaction, instead of once per log item. Keep h_numlog_ops in host byte order until we are about to write it out, then endian flip it. linux/fs/xfs/xfs_log_priv.h - 1.86 - minor cleanup, remove function argument which was always zero linux/fs/xfs/xfs_log_recover.c - 1.257 - drop second argument from xlog_assign_tail_lsn From owner-linux-xfs@oss.sgi.com Mon Mar 3 11:20:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Mar 2003 11:21:04 -0800 (PST) Received: from mail.dkp.com (mail.dkp.com [204.191.16.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h23JKoeA019500 for ; Mon, 3 Mar 2003 11:20:53 -0800 Received: by mail.dkp.com (Postfix, from userid 20001) id DAEC82AD4F; Mon, 3 Mar 2003 14:20:49 -0500 (EST) Received: from wallace.dkp.com (wallace.dkp.com [10.0.0.81]) by mail.dkp.com (Postfix) with ESMTP id 3A6D72AD4E; Mon, 3 Mar 2003 14:20:49 -0500 (EST) Received: by wallace.dkp.com (Postfix, from userid 168) id 217806F017; Mon, 3 Mar 2003 14:20:47 -0500 (EST) Date: Mon, 3 Mar 2003 14:20:47 -0500 From: Andrew Klaassen To: linux-xfs@oss.sgi.com, linux-list@ssc.com Cc: ext3-users@redhat.com Subject: Re: XFS vs. ext3 Message-ID: <20030303192047.GC22652@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com, linux-list@ssc.com, ext3-users@redhat.com References: <20030226044329.GP2107@dkp.com> <20030301163305.GA3906@widomaker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030301163305.GA3906@widomaker.com> User-Agent: Mutt/1.4i X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: $Id: Sanitizer.pm,v 1.54 2002/02/15 16:59:07 bre Exp $ X-archive-position: 2999 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: ak@dkp.com Precedence: bulk X-list: linux-xfs Content-Length: 1478 Lines: 40 On Sat, Mar 01, 2003 at 11:33:09AM -0500, Charles Shannon Hendrix wrote: > On Tue, Feb 25, 2003 at 11:43:30PM -0500, Andrew Klaassen wrote: > > > In our last IMAX film project, right at crunch time, we were > > getting a whole bunch of dropped frames during compositing. > > Our compositing program would report "invalid file" partway > > through writing, and move on to the next frame. > > I assume you are getting the error on the Windows machine, > correct? > > If that's true, I don't know you can blame ext3. For one > thing, you cannot drop a frame or anything due to a particular > filesystem unless there is an error; the filesystem code has > failed. This should show up as a serious problem or at least > a system log entry. > > Did you check the Linux side of things, in Samba and system > logs? > > I guess I'm trying to figure out how you know it is the > filesystem. I have no idea if it is the filesystem or not - I just know that changing the filesystem made the problem go away. My half-baked theory at this point is that XFS is less likely to respond so slowly to requests under load that Samba/Windows 2000 give up than ext3 is. I doubt there is any corruption because of gaps in the filesystem code itself. Unfortunately, my chance for further testing has been delayed, because we just lost (another) GigE blade on our Foundry switch, and there aren't enough free GigE ports to test through. Hopefully in a couple of weeks... Andrew Klaassen From owner-linux-xfs@oss.sgi.com Mon Mar 3 17:57:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Mar 2003 17:58:00 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h241vrf30185 for ; Mon, 3 Mar 2003 17:57:53 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h23NnBKp025839 for ; Mon, 3 Mar 2003 15:49:12 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h23Nls7L727087; Tue, 4 Mar 2003 10:47:54 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h23Nls3R727995; Tue, 4 Mar 2003 10:47:54 +1100 (EST) Date: Tue, 4 Mar 2003 10:47:54 +1100 (EST) From: Nathan Scott Message-Id: <200303032347.h23Nls3R727995@snort.melbourne.sgi.com> To: agruen@suse.de, linux-xfs@oss.sgi.com Subject: TAKE - get/setfacl error reporting X-archive-position: 3000 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 377 Lines: 15 More error reporting tweaks from AndreasG - report errors on directories that nftw can't read. Date: Mon Mar 3 15:46:53 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:140780a cmd/acl/setfacl/setfacl.c - 1.9 cmd/acl/getfacl/getfacl.c - 1.11 From owner-linux-xfs@oss.sgi.com Mon Mar 3 17:58:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Mar 2003 17:58:19 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h241wFf30252 for ; Mon, 3 Mar 2003 17:58:15 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h23MfwKp015387 for ; Mon, 3 Mar 2003 14:41:59 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h23Mef7L725718; Tue, 4 Mar 2003 09:40:41 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h23Meeti725475; Tue, 4 Mar 2003 09:40:40 +1100 (EST) Date: Tue, 4 Mar 2003 09:40:40 +1100 (EST) From: Nathan Scott Message-Id: <200303032240.h23Meeti725475@snort.melbourne.sgi.com> To: agruen@suse.de, linux-xfs@oss.sgi.com Subject: TAKE - get/setfacl error reporting X-archive-position: 3001 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 353 Lines: 14 Tweak error reporting (patch from AndreasG) - also show path on error. Date: Mon Mar 3 14:40:05 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:140768a cmd/acl/setfacl/setfacl.c - 1.8 cmd/acl/getfacl/getfacl.c - 1.10 From owner-linux-xfs@oss.sgi.com Mon Mar 3 18:19:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Mar 2003 18:19:58 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h242Jrf00465 for ; Mon, 3 Mar 2003 18:19:53 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h242UFkq016602 for ; Mon, 3 Mar 2003 20:30:16 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h242IZ7L740012 for ; Tue, 4 Mar 2003 13:18:35 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h242IYf6740800 for linux-xfs@oss.sgi.com; Tue, 4 Mar 2003 13:18:34 +1100 (EST) Date: Tue, 4 Mar 2003 13:18:34 +1100 (EST) From: Nathan Scott Message-Id: <200303040218.h242IYf6740800@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - pagebuf X-archive-position: 3002 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 700 Lines: 23 Remove an unused parameter from pagebuf_lookup. Ensure we don't mark a page uptodate in the bsize==pgsize case when we didn't do IO to the entire page. Date: Mon Mar 3 18:17:57 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140809a linux/fs/xfs/pagebuf/page_buf.c - 1.100 - Remove an unused parameter from pagebuf_lookup. Ensure we don't mark a page uptodate in the bsize==pgsize case when we didn't do IO to the entire page. linux/fs/xfs/pagebuf/page_buf.h - 1.59 linux/fs/xfs/linux/xfs_aops.c - 1.19 - Remove an unused parameter from pagebuf_lookup. From owner-linux-xfs@oss.sgi.com Mon Mar 3 18:21:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Mar 2003 18:21:54 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h242Lnf00615 for ; Mon, 3 Mar 2003 18:21:49 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h242WCkq016661 for ; Mon, 3 Mar 2003 20:32:13 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h242KW7L739801 for ; Tue, 4 Mar 2003 13:20:32 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h242KV4S740761 for linux-xfs@oss.sgi.com; Tue, 4 Mar 2003 13:20:31 +1100 (EST) Date: Tue, 4 Mar 2003 13:20:31 +1100 (EST) From: Nathan Scott Message-Id: <200303040220.h242KV4S740761@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - export end_buffer_io_async X-archive-position: 3003 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 438 Lines: 16 Export the end_buffer_io_async from the kernel - we need access to this in order to implement support for unwritten extents in XFS. Date: Mon Mar 3 18:19:52 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140810a linux/kernel/ksyms.c - 1.142 linux/include/linux/fs.h - 1.160 linux/fs/buffer.c - 1.116 From owner-linux-xfs@oss.sgi.com Mon Mar 3 18:27:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Mar 2003 18:27:07 -0800 (PST) Received: from andrei.myip.org (12-234-128-127.client.attbi.com [12.234.128.127]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h242Qof01273 for ; Mon, 3 Mar 2003 18:26:51 -0800 Received: from spampd.localdomain (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 048A12FA71 for ; Mon, 3 Mar 2003 14:09:06 -0800 (PST) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 1D2592FA71 for ; Mon, 3 Mar 2003 14:09:05 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id C02641967B for ; Mon, 3 Mar 2003 14:08:54 -0800 (PST) Subject: Re: XFS vs. ext3 From: Florin Andrei Reply-To: linux-xfs@oss.sgi.com To: linux-xfs In-Reply-To: <20030303192047.GC22652@dkp.com> References: <20030226044329.GP2107@dkp.com> <20030301163305.GA3906@widomaker.com> <20030303192047.GC22652@dkp.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 03 Mar 2003 14:08:54 -0800 Message-Id: <1046729334.20565.173.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-archive-position: 3004 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: florin@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2518 Lines: 54 On Mon, 2003-03-03 at 11:20, Andrew Klaassen wrote: > > My half-baked theory at this point is that XFS is less likely to > respond so slowly to requests under load that Samba/Windows 2000 > give up than ext3 is. I doubt there is any corruption because > of gaps in the filesystem code itself. (I'm speaking from my own personal perspective) Or it just could be the FS itself that makes the difference. I have my share of experiences with disk-bandwidth-hungry applications on Linux. I'm doing quite a bit of work with digital video, which is a very disk-I/O intensive thing. For example, i'm capturing DV video streams (actually on Digital8 support, not proper DVCAM or DVCPRO or anything) over IEEE1394 (that's FireWire for you MacOS guys, or i.Link for the Sony gang). I'm using for that purpose an application that's the bare minimum (dvgrab) so there's no CPU overhead or anything. The process is entirely disk-I/O bound. For NTSC 720x480 interlaced 29.9fps 16bit-sound DV stream, the space requirement is like 16GB per hour. With XFS, i don't have to worry about anything, i just let it capture and do other stuff at the same time with that system. I sort of like that. :-) With Ext3 it happened, albeit rarely, to get dropped frames if i use the disks with other applications while capturing, so i have to be careful with the other stuff i'm doing with the system at the same time. ReiserFS seems to have the worst performance for this workload (albeit it's doing great for other things, i won't deny that). Even when capturing analog video, it's all the same. Capturing raw YUV is brutal; there's a huge stress on the disk I/O. It's better to not do anything else at that time, not even touch that whole spindle, no matter what's the filesystem. Capturing in lossless compressed formats is slightly better, but at the cost of some CPU effort. Capturing in lossy formats such as the MPEG4 family is a lot better from the disk p.o.v., i could use any FS i want, but then the CPU is used a lot (only when capturing high-quality material, though), so the system becomes CPU-bound. So it's a trade-off, but even then i still see XFS as being the best choice for the partition where i generate the primary files - it has the smallest percentage of lost frames in any scenario. The hardware i'm using are, typically, recent AthlonXP systems, with large non-RAID IDE drives (yeah, i know), running recent 2.4 Linux kernels. -- Florin Andrei "Do not look into laser with remaining eye." - on a laser pointer From owner-linux-xfs@oss.sgi.com Mon Mar 3 19:11:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Mar 2003 19:11:34 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h243BRf12277 for ; Mon, 3 Mar 2003 19:11:27 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h243Lnkq017808 for ; Mon, 3 Mar 2003 21:21:51 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h243A87L748885 for ; Tue, 4 Mar 2003 14:10:08 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h243A8gX754331 for linux-xfs@oss.sgi.com; Tue, 4 Mar 2003 14:10:08 +1100 (EST) Date: Tue, 4 Mar 2003 14:10:08 +1100 (EST) From: Nathan Scott Message-Id: <200303040310.h243A8gX754331@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - unwritten extents X-archive-position: 3005 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1066 Lines: 31 Support for unwritten extents. Create separate IO completion thread pools in pagebuf for log/data IO, to prevent deadlocks when scheduling iclog/unwritten extent IO completion handlers. We also no longer create as many pagebuf threads as there are CPUs, but cap this at 8 threads max (or 2 threads per CPU for machines with <=4 CPUs). cheers. Date: Mon Mar 3 19:08:37 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140814a linux/fs/xfs/xfs_buf.h - 1.104 linux/fs/xfs/pagebuf/page_buf.c - 1.101 linux/fs/xfs/pagebuf/page_buf.h - 1.60 - Create separate IO completion thread pools in pagebuf for log/data IO, to prevent deadlocks when scheduling iclog/unwritten extent IO completion handlers. We also no longer create as many pagebuf threads as there are CPUs, but cap this at 8 threads max (or 2 threads per CPU for machines with <=4 CPUs). linux/fs/xfs/linux/xfs_aops.c - 1.20 - Support for unwritten extents. From owner-linux-xfs@oss.sgi.com Mon Mar 3 19:21:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Mar 2003 19:21:17 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h243L8f14172 for ; Mon, 3 Mar 2003 19:21:08 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h243L70a027495 for ; Mon, 3 Mar 2003 19:21:07 -0800 From: "l.a walsh" To: Subject: Pagebuf behavior.... Date: Mon, 3 Mar 2003 19:21:07 -0800 Message-ID: <000401c2e1fd$18b732f0$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_01C2E1BA.0A93F2F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-archive-position: 3006 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: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 12752 Lines: 228 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C2E1BA.0A93F2F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Running with 2.4.20 and the early feb xfs patches, still have debug enabled....(maybe that's it?).... But, running two long-running tar/bzip2 routines (mach=2xP3-1GB)...did a chmod/chgrp -R in a directory tree that has about 185,000 files.... Seemed to take a long time. I'm used to the first of the pair taking a while if they aren't in cache. But the 2nd did as well... looked at top and saw: PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 9 root 20 0 0 0 0 RW 96.8 0.0 7:58 pagebuf/0 10 root 20 0 0 0 0 SW 79.3 0.0 7:47 pagebuf/1 7 root 20 0 0 0 0 DW 18.0 0.0 7:31 kupdated 16415 root 15 0 556 556 456 D 2.8 0.0 1:25 chmod 14275 root 16 4 7784 7784 352 R N 1.7 0.7 114:08 bzip2 14405 root 17 12 7784 7784 352 R N 0.9 0.7 67:36 bzip2 16418 root 11 0 1032 1032 820 R 0.3 0.1 0:00 top --- Wow! ... seems like alot of overhead for a chmod running on one disk (SCSI). The tars were executing on a separate disk/IDE. Just a WAG, but I'm guessing this isn't normal behavior? I did dump /proc/meminfo, and slabinfo (included below) immediately after the event. System has been up for almost 7 days now, so could be some housekeeping is broken somewhere, perhaps a side effect only produced with debugging enabled? Dunno -- Very strange. meminfo: total: used: free: shared: buffers: cached: Mem: 1056473088 1047224320 9248768 0 0 402280448 Swap: 271425536 16781312 254644224 MemTotal: 1031712 kB MemFree: 9032 kB MemShared: 0 kB Buffers: 0 kB Cached: 391020 kB SwapCached: 1832 kB Active: 129052 kB Inactive: 306576 kB HighTotal: 131064 kB HighFree: 1760 kB LowTotal: 900648 kB LowFree: 7272 kB SwapTotal: 265064 kB SwapFree: 248676 kB slabinfo: ....was going to include it...but the colums are waAay wide and will certainly get malformed, so will attach it -- hopefully it will be decipherable. ------=_NextPart_000_0005_01C2E1BA.0A93F2F0 Content-Type: text/plain; name="slabinfo.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="slabinfo.txt" slabinfo - version: 1.1 (statistics) (SMP) kmem_cache 91 91 288 7 7 1 : 91 91 = 7 0 0 : 124 62 : 28 7 0 0 tcp_tw_bucket 2 40 96 1 1 1 : 280 165154 104= 1 1040 0 : 252 126 : 31482 4270 34709 0 tcp_bind_bucket 14 290 24 2 2 1 : 290 507049 5= 2 50 0 : 252 126 : 38511 4134 42577 2 tcp_open_request 0 0 64 0 0 1 : 177 82812 122= 7 1227 0 : 252 126 : 9707 2726 11206 0 inet_peer_cache 1 78 48 1 1 1 : 156 6372 2= 3 22 0 : 252 126 : 129 105 210 0 ip_fib_hash 22 145 24 1 1 1 : 145 521 = 1 0 0 : 252 126 : 26 6 9 0 ip_dst_cache 103 312 160 13 13 1 : 1176 662676 23= 9 226 0 : 252 126 : 143682 6966 150228 78 arp_cache 4 64 120 2 2 1 : 160 42863 6= 3 61 0 : 252 126 : 1990 623 2546 0 blkdev_requests 1024 1040 96 26 26 1 : 1160 1160 2= 9 3 0 : 252 126 : 1251 58 256 0 ktrace_ent 0 0 4096 0 0 1 : 0 0 = 0 0 0 : 60 30 : 0 0 0 0 ktrace_hdr 0 0 32 0 0 1 : 0 0 = 0 0 0 : 252 126 : 0 0 0 0 xfs_acl 0 0 312 0 0 1 : 36 9814 78= 6 786 0 : 124 62 : 427191 1603 428008 0 xfs_chashlist 15233 15246 28 121 121 1 : 23562 1854717 40= 4 283 0 : 252 126 : 157320 16084 157093 799 xfs_ili 100125 100125 156 4005 4005 1 : 100125 910347 852= 6 4521 0 : 252 126 : 357955 23151 270719 1789 xfs_ifork 30 118 64 2 2 1 : 767 35198 9= 6 94 0 : 252 126 : 8788 511 9140 33 xfs_efi_item 0 0 268 0 0 1 : 154 64924 257= 7 2577 0 : 124 62 : 200126 6550 203940 159 xfs_efd_item 0 0 268 0 0 1 : 154 68504 240= 8 2408 0 : 124 62 : 200167 6340 203940 159 xfs_buf_item 48 48 160 2 2 1 : 432 429391 333= 2 3330 0 : 252 126 : 978111 17033 991786 17 xfs_dabuf 145 145 24 1 1 1 : 145 3142176 785= 8 7857 0 : 252 126 : 27356631 47890 27396663 0 xfs_da_state 0 0 344 0 0 1 : 33 52183 405= 6 4056 0 : 124 62 : 1594104 8868 1598916 0 xfs_trans 13 13 596 1 1 2 : 416 841628 925= 4 9253 0 : 124 62 : 2121499 36198 2139577 8859 xfs_inode 438104 438104 472 54763 54763 1 : 569456 7043358 54= 3669 488906 0 : 124 62 : 6458628 1136986 6521197 92656 xfs_btree_cur 28 28 140 1 1 1 : 112 385133 1157= 6 11575 0 : 252 126 : 1427764 25430 1441618 0 xfs_bmap_free_item 0 0 20 0 0 1 : 169 384010 16= 20 1620 0 : 252 126 : 207215 5552 211147 0 page_buf_t 365 756 212 41 42 1 : 8280 4721260 1303= 5 12993 0 : 252 126 : 57055544 93467 57134484 1423 linvfs_icache 435743 435743 544 62249 62249 1 : 569443 7072240 63= 5204 572955 0 : 124 62 : 5725828 1319034 5880757 93166 nfs_write_data 0 0 352 0 0 1 : 0 0 = 0 0 0 : 124 62 : 0 0 0 0 nfs_read_data 0 0 336 0 0 1 : 0 0 = 0 0 0 : 124 62 : 0 0 0 0 nfs_page 0 0 100 0 0 1 : 0 0 = 0 0 0 : 252 126 : 0 0 0 0 devfsd_event 0 0 28 0 0 1 : 0 0 = 0 0 0 : 252 126 : 0 0 0 0 dnotify_cache 3 126 28 1 1 1 : 252 5783 = 8 7 0 : 252 126 : 142 55 186 0 file_lock_cache 20 180 108 5 5 1 : 324 1840563 85= 2 847 0 : 252 126 : 28774166 21588 28794882 0 fasync_cache 0 0 24 0 0 1 : 290 969642 7= 1 71 0 : 252 126 : 82159 8123 90211 0 uid_cache 7 113 32 1 1 1 : 226 8794 = 3 2 0 : 252 126 : 49 78 117 0 skbuff_head_cache 345 552 164 23 23 1 : 600 10485627 1= 27 104 0 : 252 126 : 11593766 86530 11628859 51084 sock 101 162 864 18 18 2 : 324 466404 88= 5 867 0 : 124 62 : 1244115 12037 1255149 19 sigqueue 28 28 140 1 1 1 : 280 1087512 1941= 1 19410 0 : 252 126 : 8688326 60678 8728672 921 kiobuf 0 0 68 0 0 1 : 112 5012 5= 0 50 0 : 252 126 : 824 143 917 0 cdev_cache 1765 1800 52 25 25 1 : 1872 31696 27= 0 245 0 : 252 126 : 22452 665 20941 141 bdev_cache 9 168 68 3 3 1 : 168 1008 = 7 4 0 : 252 126 : 169 20 173 0 mnt_cache 20 112 68 2 2 1 : 168 930 = 5 3 0 : 252 126 : 38 16 34 0 inode_cache 224 224 492 28 28 1 : 336 1131552 155= 5 1514 0 : 124 62 : 5456661 26259 5481089 118 dentry_cache 518793 518793 116 15721 15721 1 : 518793 9857984 10= 2470 7446 0 : 252 126 : 11851103 261917 11450519 41274 filp 1224 1292 112 38 38 1 : 1292 4442 3= 8 0 0 : 252 126 : 1146 116 0 0 names_cache 2 2 4096 2 2 1 : 25 48473 4272= 6 42724 0 : 60 30 : 49788723 90573 49836570 0 buffer_head 83759 178812 108 4967 4967 1 : 244944 24158109 479= 59 42992 0 : 252 126 : 37381905 276289 37476158 50536 mm_struct 185 208 152 8 8 1 : 338 433119 30= 3 295 0 : 252 126 : 1024191 4957 1028775 10 vm_area_struct 1915 2300 76 46 46 1 : 4050 5035250 75= 0 704 0 : 252 126 : 59852858 41754 59875546 16503 fs_cache 185 312 48 4 4 1 : 390 541359 3= 4 30 0 : 252 126 : 1024121 4768 1028760 37 files_cache 122 126 428 14 14 1 : 207 212135 48= 7 473 0 : 124 62 : 1024010 5332 1028687 110 signal_act 87 87 1312 29 29 1 : 153 74583 136= 2 1333 0 : 60 30 : 1023616 6605 1028432 363 size-131072(DMA) 0 0 131072 0 0 32 : 0 0 = 0 0 0 : 0 0 : 0 0 0 0 size-131072 0 0 131072 0 0 32 : 1 15 = 2 2 0 : 0 0 : 0 0 0 0 size-65536(DMA) 0 0 65536 0 0 16 : 0 0 = 0 0 0 : 0 0 : 0 0 0 0 size-65536 3 3 65536 3 3 16 : 3 3 = 3 0 0 : 0 0 : 0 0 0 0 size-32768(DMA) 0 0 32768 0 0 8 : 0 0 = 0 0 0 : 0 0 : 0 0 0 0 size-32768 19 19 32768 19 19 8 : 19 43 2= 7 8 0 : 0 0 : 0 0 0 0 size-16384(DMA) 0 0 16384 0 0 4 : 0 0 = 0 0 0 : 0 0 : 0 0 0 0 size-16384 6 6 16384 6 6 4 : 18 10195488 206= 25 20619 0 : 0 0 : 0 0 0 0 size-8192(DMA) 0 0 8192 0 0 2 : 0 0 = 0 0 0 : 0 0 : 0 0 0 0 size-8192 15 15 8192 15 15 2 : 25 179 5= 0 35 0 : 0 0 : 0 0 0 0 size-4096(DMA) 0 0 4096 0 0 1 : 0 0 = 0 0 0 : 60 30 : 0 0 0 0 size-4096 53 53 4096 53 53 1 : 137 222766 2666= 8 26615 0 : 60 30 : 616770 62342 646210 6181 size-2048(DMA) 0 0 2048 0 0 1 : 0 0 = 0 0 0 : 60 30 : 0 0 0 0 size-2048 112 144 2048 72 72 1 : 266 5262476 7014= 2 70070 0 : 60 30 : 22292403 327567 22408453 141269 size-1024(DMA) 0 0 1024 0 0 1 : 0 0 = 0 0 0 : 124 62 : 0 0 0 0 size-1024 316 316 1024 79 79 1 : 360 68572 55= 0 471 0 : 124 62 : 166917 3168 169279 21 size-512(DMA) 0 0 512 0 0 1 : 0 0 = 0 0 0 : 124 62 : 0 0 0 0 size-512 680 680 512 85 85 1 : 808 1063370 1174= 9 11664 0 : 124 62 : 8477136 55811 8519507 1077 size-256(DMA) 0 0 264 0 0 1 : 0 0 = 0 0 0 : 124 62 : 0 0 0 0 size-256 1740 1740 264 116 116 1 : 2685 4709731 402= 3 3907 0 : 124 62 : 13467588 93831 13537706 18027 size-128(DMA) 0 0 136 0 0 1 : 0 0 = 0 0 0 : 252 126 : 0 0 0 0 size-128 7436 7448 136 266 266 1 : 11956 3346655 171= 4 1448 0 : 252 126 : 6028515 33362 6052766 338 size-64(DMA) 0 0 72 0 0 1 : 0 0 = 0 0 0 : 252 126 : 0 0 0 0 size-64 14257 14257 72 269 269 1 : 36623 2291101 253= 5 2266 0 : 252 126 : 2146995 23755 2152357 1706 size-32(DMA) 0 0 40 0 0 1 : 0 0 = 0 0 0 : 252 126 : 0 0 0 0 size-32 82248 82248 40 894 894 1 : 96968 7739798 828= 2 7388 0 : 252 126 : 27413177 75945 27390722 8009 ------=_NextPart_000_0005_01C2E1BA.0A93F2F0-- From owner-linux-xfs@oss.sgi.com Tue Mar 4 00:14:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 00:14:52 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h248Eif20844 for ; Tue, 4 Mar 2003 00:14:44 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 87A7E14331; Tue, 4 Mar 2003 09:14:43 +0100 (MET) Date: Tue, 4 Mar 2003 09:14:42 +0100 From: Andi Kleen To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - unwritten extents Message-ID: <20030304081442.GA14913@wotan.suse.de> References: <200303040310.h243A8gX754331@snort.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303040310.h243A8gX754331@snort.melbourne.sgi.com> X-archive-position: 3007 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: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 177 Lines: 7 On Tue, Mar 04, 2003 at 02:10:08PM +1100, Nathan Scott wrote: > Support for unwritten extents. Create separate IO completion Gratulations. Do they work fully already? -Andi From owner-linux-xfs@oss.sgi.com Tue Mar 4 01:29:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 01:30:01 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h249Tdf29228 for ; Tue, 4 Mar 2003 01:29:40 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 9D7A7AC34 for ; Tue, 4 Mar 2003 10:19:08 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id E7631190C6 for ; Tue, 4 Mar 2003 10:19:09 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 6AAE530881D for ; Tue, 4 Mar 2003 10:07:47 +0100 (CET) Message-ID: <3E646CE3.BA8A100A@ch.sauter-bc.com> Date: Tue, 04 Mar 2003 10:07:47 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: linux-xfs Subject: Success with software RAID5 / XFS resizing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3008 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: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 1430 Lines: 37 First I want to thank everybody involved with XFS development for the ongoing effort producing a really high quality filesystem for Linux! I have successfully upgraded my home server from 4x15G disks to 4x60G. I was afraid first but everything went so easy that I wanted to let other people know how I did it. Word of WARNING: Doing backups is strongly recommended!! This has worked for me, YMMV!! Here we go: The four 15G disks were partitioned with several small partitions for system on RAID1 and one big partition for /home on RAID5 with external v1 log on a RAID1. The RAID5 consisted of four 11G partitions located 'at the end' of each disk, resulting in a ~33G RAID5 volume. I have now replaced disk1, partitioned the new disk, and did a raidhotadd for every partition. After all volumes were synced, I replaced the same steps for disk 2-4. Now I had all disks replaced but with the same RAID and XFS volumes on it. Now I did umount /home xfs_check /dev/md8 raidstop /dev/md8 Then I used fdisk to delete the 11G partition on every disk and replaced it with a new partition with the full size but the same starting point. A reboot ensured that all partition tables were reread. (Note: one must _not_ change the chunk size or anything else in /etc/raidtab at this point!!) Now I simply did the following: mkraid /dev/md8 mount /home xfs_growfs /home and voila, /home is now 168G in size with all data in place! Simon From owner-linux-xfs@oss.sgi.com Tue Mar 4 01:54:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 01:54:28 -0800 (PST) Received: from hbcse.tifr.res.in (hbcse.tifr.res.in [158.144.44.129]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h249sIf30526 for ; Tue, 4 Mar 2003 01:54:19 -0800 Received: from linto (helo=localhost) by hbcse.tifr.res.in with local-esmtp (Exim 3.35 #1 (Debian)) id 18q95H-0004gR-00 for ; Tue, 04 Mar 2003 15:21:39 +0530 Date: Tue, 4 Mar 2003 15:21:38 +0530 (IST) From: "'Linto Joseph Mathew" To: linux-xfs@oss.sgi.com Subject: Problem while I formatting Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3009 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: linto@hbcse.tifr.res.in Precedence: bulk X-list: linux-xfs Content-Length: 390 Lines: 11 I have partition (logical /dev/hda6 ) of size 16 MB.When i tried to format using mkfs.xfs (ie mkfs.xfs /dev/hda6 ) it showing that " warning - cannot set block size on bock device /dev/hda6 :Input/output error".I am not thinking that it is a H/W problem because mkfs.ext3 and mkfs.reiserfs are working on /dev/hda6.What is the minimum size required for xfs partition? Regards, Linto. From owner-linux-xfs@oss.sgi.com Tue Mar 4 02:45:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 02:45:33 -0800 (PST) Received: from kerberos.suse.cz (kerberos.suse.cz [195.47.106.10]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24AjSf02753 for ; Tue, 4 Mar 2003 02:45:28 -0800 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (SuSE SMTP server) with ESMTP id 9309359D385; Tue, 4 Mar 2003 11:14:04 +0100 (CET) Received: from alienAngel.upjs.sk (test12.suse.cz [10.20.3.140]) by chimera.suse.cz (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h24AE4424928; Tue, 4 Mar 2003 11:14:04 +0100 X-Authentication-Warning: chimera.suse.cz: Host test12.suse.cz [10.20.3.140] claimed to be alienAngel.upjs.sk Received: from localhost (ja@localhost) by alienAngel.upjs.sk (8.12.6/8.12.6/Submit) with ESMTP id h24ADaiE012356; Tue, 4 Mar 2003 11:13:36 +0100 X-Authentication-Warning: alienAngel.home.sk: ja owned process doing -bs Date: Tue, 4 Mar 2003 11:13:36 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: "'Linto Joseph Mathew" Cc: linux-xfs@oss.sgi.com Subject: Re: Problem while I formatting In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3010 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: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 246 Lines: 10 On Tue, 4 Mar 2003, 'Linto Joseph Mathew wrote: > > I have partition (logical /dev/hda6 ) of size 16 MB.When i tried to I think, your partiton is too small. The minimum allocation group size is 16 MB, but you need space for logs. jan From owner-linux-xfs@oss.sgi.com Tue Mar 4 03:37:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 03:37:17 -0800 (PST) Received: from hbcse.tifr.res.in (webmail.hbcse.tifr.res.in [158.144.44.129]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24Bb2f03777 for ; Tue, 4 Mar 2003 03:37:03 -0800 Received: from linto (helo=localhost) by hbcse.tifr.res.in with local-esmtp (Exim 3.35 #1 (Debian)) id 18qAgU-0005VZ-00; Tue, 04 Mar 2003 17:04:10 +0530 Date: Tue, 4 Mar 2003 17:04:10 +0530 (IST) From: "'Linto Joseph Mathew" To: Jan Derfinak cc: linux-xfs@oss.sgi.com Subject: Re: Problem while I formatting In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3011 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: linto@hbcse.tifr.res.in Precedence: bulk X-list: linux-xfs Content-Length: 523 Lines: 26 Greetings jan, I tried the same thing on my another partition, ie /dev/hda5 of size 5 GB.But still it showing the same err.I don't understand what is this? Is xfs needed primary partition? regards , Linto On Tue, 4 Mar 2003, Jan Derfinak wrote: > On Tue, 4 Mar 2003, 'Linto Joseph Mathew wrote: > > > > > I have partition (logical /dev/hda6 ) of size 16 MB.When i tried to > > I think, your partiton is too small. > The minimum allocation group size is 16 MB, but you need space for logs. > > jan > > From owner-linux-xfs@oss.sgi.com Tue Mar 4 05:15:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 05:15:22 -0800 (PST) Received: from kerberos.suse.cz (kerberos.suse.cz [195.47.106.10]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24DFEf05481 for ; Tue, 4 Mar 2003 05:15:15 -0800 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (SuSE SMTP server) with ESMTP id EE79659D398; Tue, 4 Mar 2003 14:15:10 +0100 (CET) Received: from alienAngel.upjs.sk (test12.suse.cz [10.20.3.140]) by chimera.suse.cz (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h24DFA413228; Tue, 4 Mar 2003 14:15:10 +0100 X-Authentication-Warning: chimera.suse.cz: Host test12.suse.cz [10.20.3.140] claimed to be alienAngel.upjs.sk Received: from localhost (ja@localhost) by alienAngel.upjs.sk (8.12.6/8.12.6/Submit) with ESMTP id h24DEQPb013256; Tue, 4 Mar 2003 14:14:26 +0100 X-Authentication-Warning: alienAngel.home.sk: ja owned process doing -bs Date: Tue, 4 Mar 2003 14:14:26 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: "'Linto Joseph Mathew" Cc: linux-xfs@oss.sgi.com Subject: Re: Problem while I formatting In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3012 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: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 639 Lines: 21 On Tue, 4 Mar 2003, 'Linto Joseph Mathew wrote: > Greetings jan, > I tried the same thing on my another partition, ie /dev/hda5 of size > 5 GB.But still it showing the same err.I don't understand what is this? > Is xfs needed primary partition? No. Please show us mkfs.xfs -V, kernel version. Do you have self compiled xfsprogs or binary one? How you run mkfs.xfs? jan -- We've been walled-in, malled-in, insulated, air-conditioned, cine-plexed, programmed, brainwashed, unalterably directed by materialism, consumerism, and capitalism, unaware of our own heartbeats, only dimly aware of our diminished, starving spirits. From owner-linux-xfs@oss.sgi.com Tue Mar 4 05:27:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 05:27:50 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24DRlf06154 for ; Tue, 4 Mar 2003 05:27:47 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24DRlG8019593 for ; Tue, 4 Mar 2003 05:27:47 -0800 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA87408; Tue, 4 Mar 2003 07:27:46 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-62.corp.sgi.com [134.15.64.62]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA08683; Tue, 4 Mar 2003 07:27:45 -0600 (CST) Subject: Re: Problem while I formatting From: Stephen Lord To: Jan Derfinak Cc: "'Linto Joseph Mathew" , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 04 Mar 2003 07:26:27 -0600 Message-Id: <1046784389.1367.2.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 3013 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1166 Lines: 34 On Tue, 2003-03-04 at 07:14, Jan Derfinak wrote: > On Tue, 4 Mar 2003, 'Linto Joseph Mathew wrote: > > > Greetings jan, > > I tried the same thing on my another partition, ie /dev/hda5 of size > > 5 GB.But still it showing the same err.I don't understand what is this? > > Is xfs needed primary partition? > No. > > Please show us mkfs.xfs -V, kernel version. > Do you have self compiled xfsprogs or binary one? > How you run mkfs.xfs? > > I suspect you need a newer mkfs.xfs binary, also, if you are getting output like this: meta-data=/dev/sda2 isize=256 agcount=8, agsize=64511 blks data = bsize=4096 blocks=516088, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200, version=1 = sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 It actually worked. There is an ioctl call which xfs attempts to use, it is not implemented by all block devices and mkfs actually carries on after the failure anyway. Steve From owner-linux-xfs@oss.sgi.com Tue Mar 4 05:32:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 05:32:09 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24DW7f06781 for ; Tue, 4 Mar 2003 05:32:07 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24DW7G8019985 for ; Tue, 4 Mar 2003 05:32:07 -0800 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA31140; Tue, 4 Mar 2003 07:32:06 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-62.corp.sgi.com [134.15.64.62]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA15853; Tue, 4 Mar 2003 07:32:05 -0600 (CST) Subject: Re: TAKE - unwritten extents From: Stephen Lord To: Andi Kleen Cc: Nathan Scott , linux-xfs@oss.sgi.com In-Reply-To: <20030304081442.GA14913@wotan.suse.de> References: <200303040310.h243A8gX754331@snort.melbourne.sgi.com> <20030304081442.GA14913@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 04 Mar 2003 07:30:47 -0600 Message-Id: <1046784648.1367.9.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 3014 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 486 Lines: 14 On Tue, 2003-03-04 at 02:14, Andi Kleen wrote: > On Tue, Mar 04, 2003 at 02:10:08PM +1100, Nathan Scott wrote: > > Support for unwritten extents. Create separate IO completion > > Gratulations. Do they work fully already? Yep, they are all there. The preallocation calls are still restricted to privileged user's, that should get fixed up soon. I also have some ideas for reworking how we use daemons for this and other things - but that may take a little while to show up. Steve From owner-linux-xfs@oss.sgi.com Tue Mar 4 06:48:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 06:48:14 -0800 (PST) Received: from relay.dstl.gov.uk (relay.dera.gov.uk [192.5.29.49]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24Em9f08426 for ; Tue, 4 Mar 2003 06:48:10 -0800 Received: (qmail 24496 invoked from network); 4 Mar 2003 14:48:08 +0000 Received: from warlock.dstl.gov.uk (192.5.29.10) by relay.dera.gov.uk with SMTP; 4 Mar 2003 14:48:08 +0000 Subject: Re: TAKE - unwritten extents From: Tony Gale To: linux-xfs@oss.sgi.com In-Reply-To: <1046784648.1367.9.camel@dstl.gov.uk> References: <200303040310.h243A8gX754331@dstl.gov.uk> <20030304081442.GA14913@wotan.suse.de> <1046784648.1367.9.camel@localhost.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-gQeaC/cvPYfI2ofS/J6+" Organization: Message-Id: <1046789287.28300.4.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 04 Mar 2003 14:48:07 +0000 X-archive-position: 3015 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: gale@syntax.dstl.gov.uk Precedence: bulk X-list: linux-xfs Content-Length: 1258 Lines: 40 --=-gQeaC/cvPYfI2ofS/J6+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2003-03-04 at 13:30, Stephen Lord wrote: > On Tue, 2003-03-04 at 02:14, Andi Kleen wrote: > > On Tue, Mar 04, 2003 at 02:10:08PM +1100, Nathan Scott wrote: > > > Support for unwritten extents. Create separate IO completion > >=20 > > Gratulations. Do they work fully already? >=20 > Yep, they are all there. The preallocation calls are still restricted > to privileged user's, that should get fixed up soon. I also have some > ideas for reworking how we use daemons for this and other things - but > that may take a little while to show up. >=20 Please excuse my ignorance, but what are "unwritten extents", and should I be excited about their support? Cheers, -tony --=-gQeaC/cvPYfI2ofS/J6+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iQCVAwUAPmS8px/0GZs/Z0FlAQIYaAP/Xod0TdUOXx2DZmg58ndar3qRNMl0yvr/ r5lkIKHfNODAN84sHf2iJxPVKngz/1JflkuhQDj/OLO2WSATTgu3F66w7IZFag/8 3xsNRlzm/FFVCoeDUJXH5XzBovcLq9ual1gHUPSITVajUsYVOF4jqqZgdNOuGrQQ WHPd0RlT8bw= =qkmx -----END PGP SIGNATURE----- --=-gQeaC/cvPYfI2ofS/J6+-- From owner-linux-xfs@oss.sgi.com Tue Mar 4 07:02:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 07:02:27 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24F2Lf09202 for ; Tue, 4 Mar 2003 07:02:21 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24F2KKp017341 for ; Tue, 4 Mar 2003 07:02:20 -0800 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA48992; Tue, 4 Mar 2003 09:02:19 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-62.corp.sgi.com [134.15.64.62]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA95974; Tue, 4 Mar 2003 09:02:19 -0600 (CST) Subject: Re: TAKE - unwritten extents From: Stephen Lord To: Tony Gale Cc: linux-xfs@oss.sgi.com In-Reply-To: <1046789287.28300.4.camel@syntax.dstl.gov.uk> References: <200303040310.h243A8gX754331@dstl.gov.uk> <20030304081442.GA14913@wotan.suse.de> <1046784648.1367.9.camel@localhost.localdomain> <1046789287.28300.4.camel@syntax.dstl.gov.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 04 Mar 2003 09:00:56 -0600 Message-Id: <1046790057.1367.89.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 3016 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1342 Lines: 36 On Tue, 2003-03-04 at 08:48, Tony Gale wrote: > On Tue, 2003-03-04 at 13:30, Stephen Lord wrote: > > On Tue, 2003-03-04 at 02:14, Andi Kleen wrote: > > > On Tue, Mar 04, 2003 at 02:10:08PM +1100, Nathan Scott wrote: > > > > Support for unwritten extents. Create separate IO completion > > > > > > Gratulations. Do they work fully already? > > > > Yep, they are all there. The preallocation calls are still restricted > > to privileged user's, that should get fixed up soon. I also have some > > ideas for reworking how we use daemons for this and other things - but > > that may take a little while to show up. > > > > Please excuse my ignorance, but what are "unwritten extents", and should > I be excited about their support? Unwritten extents improve the security of the file preallocation interface in xfs. When you preallocate space in a file, it is not zeroed on disk, So if you read from it you get old data. Unless you have unwritten extent support. For this reason the preallocate calls on linux were restricted to root. Unwritten extents slow things down when they are used, which is why they are selectable via a mkfs option: mkfs -t xfs -d unwritten=1 So nothing too exciting, unless you are attempting to read Irix created filesystems on linux, or need the preallocation interface and have security concerns. Steve From owner-linux-xfs@oss.sgi.com Tue Mar 4 08:25:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 08:25:12 -0800 (PST) Received: from mail.srz-berlin.de (ambrosius.srz-berlin.de [217.9.41.134]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24GP5f11521 for ; Tue, 4 Mar 2003 08:25:05 -0800 Received: from [192.168.1.17] (helo=srz-berlin.de) by mail.srz-berlin.de with esmtp (Exim 6.66 #1) id 18qFDu-0002T4-00 for linux-xfs@oss.sgi.com; Tue, 04 Mar 2003 17:24:58 +0100 Message-ID: <3E64D298.ADC2C124@srz-berlin.de> Date: Tue, 04 Mar 2003 17:21:44 +0100 From: Axel Bringenberg Organization: Satz-Rechen-Zentrum Berlin - Systemgruppe (http://www.srz.de) X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.4.9-31SGI_XFS_1.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS and RH8 failing install Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *18qFDu-0002T4-00*2YyB2WAfRsg* on Astaro Security Linux X-archive-position: 3017 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: A.Bringenberg@srz-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 472 Lines: 19 Eric Sandeen schrieb: > > I think that Russell fixed this on the latest iso, can you verify that > you're using the latest? Oups - yes: my fault. it was the v3 iso image, sorry. But with v4 I have the next problem: a installation (custom, with "everything" packages) failed on disc 6 while installing "anaconda-8.0-2XFS". iso images is ok (check with md5sum an installer-build test). Regards, - bringi Axel Bringenberg -- Satz-Rechen-Zentrum Berlin - Systemgruppe From owner-linux-xfs@oss.sgi.com Tue Mar 4 08:51:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 08:51:39 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24GpZf14268 for ; Tue, 4 Mar 2003 08:51:35 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24GpYF6009188 for ; Tue, 4 Mar 2003 08:51:35 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA89723 for ; Tue, 4 Mar 2003 10:51:33 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA18173 for ; Tue, 4 Mar 2003 10:51:33 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h2507FZ11589 for linux-xfs@oss.sgi.com; Tue, 4 Mar 2003 19:07:15 -0500 Resent-Message-Id: <200303050007.h2507FZ11589@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA81705 for ; Tue, 4 Mar 2003 10:47:31 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id h24GlUok18723640 for ; Tue, 4 Mar 2003 08:47:30 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h24GiUQv001644 for ; Tue, 4 Mar 2003 17:44:30 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h24GiUIr001643 for hch@sgi.com; Tue, 4 Mar 2003 17:44:30 +0100 Date: Tue, 4 Mar 2003 17:44:30 +0100 From: Christoph Hellwig Message-Id: <200303041644.h24GiUIr001643@lab343.munich.sgi.com> Subject: TAKE - remove VFS_DOUNMOUNT To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Tue, 4 Mar 2003 19:07:14 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 3018 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: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 437 Lines: 17 No need for it on Linux. Date: Tue Mar 4 08:45:43 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:140841a linux/fs/xfs/xfs_vfsops.c - 1.403 linux/fs/xfs/linux/xfs_fs_subr.c - 1.38 linux/fs/xfs/linux/xfs_super.c - 1.256 linux/fs/xfs/linux/xfs_vfs.h - 1.31 linux/fs/xfs/linux/xfs_fs_subr.h - 1.10 From owner-linux-xfs@oss.sgi.com Tue Mar 4 09:03:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 09:03:14 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24H34f15275 for ; Tue, 4 Mar 2003 09:03:04 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 9D8EA14543; Tue, 4 Mar 2003 18:03:03 +0100 (MET) Date: Tue, 4 Mar 2003 18:03:00 +0100 From: Andi Kleen To: Tony Gale Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - unwritten extents Message-ID: <20030304170300.GA7113@wotan.suse.de> References: <200303040310.h243A8gX754331@dstl.gov.uk> <20030304081442.GA14913@wotan.suse.de> <1046784648.1367.9.camel@localhost.localdomain> <1046789287.28300.4.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1046789287.28300.4.camel@syntax.dstl.gov.uk> X-archive-position: 3019 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: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 1031 Lines: 24 On Tue, Mar 04, 2003 at 02:48:07PM +0000, Tony Gale wrote: > On Tue, 2003-03-04 at 13:30, Stephen Lord wrote: > > On Tue, 2003-03-04 at 02:14, Andi Kleen wrote: > > > On Tue, Mar 04, 2003 at 02:10:08PM +1100, Nathan Scott wrote: > > > > Support for unwritten extents. Create separate IO completion > > > > > > Gratulations. Do they work fully already? > > > > Yep, they are all there. The preallocation calls are still restricted > > to privileged user's, that should get fixed up soon. I also have some > > ideas for reworking how we use daemons for this and other things - but > > that may take a little while to show up. > > > > Please excuse my ignorance, but what are "unwritten extents", and should > I be excited about their support? Basically it makes preallocation useful and secure. Preallocation has potentially big advantages for handling of very big files with consistent performance. With preallocation XFS can essentially only use a single extent for the whole file and avoid any fragmentation at all. -Andi From owner-linux-xfs@oss.sgi.com Tue Mar 4 10:20:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 10:20:21 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24IK8f21341 for ; Tue, 4 Mar 2003 10:20:09 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id AB94B1830E07; Tue, 4 Mar 2003 10:20:08 -0800 (PST) Date: Tue, 4 Mar 2003 10:20:08 -0800 From: Chris Wedgwood To: Stephen Lord Cc: Tony Gale , linux-xfs@oss.sgi.com Subject: Re: TAKE - unwritten extents Message-ID: <20030304182008.GA25814@f00f.org> References: <200303040310.h243A8gX754331@dstl.gov.uk> <20030304081442.GA14913@wotan.suse.de> <1046784648.1367.9.camel@localhost.localdomain> <1046789287.28300.4.camel@syntax.dstl.gov.uk> <1046790057.1367.89.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1046790057.1367.89.camel@localhost.localdomain> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 3020 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 358 Lines: 12 On Tue, Mar 04, 2003 at 09:00:56AM -0600, Stephen Lord wrote: > So nothing too exciting, unless you are attempting to read Irix > created filesystems on linux, or need the preallocation interface > and have security concerns. For most people the biggest implication will be that non-root users defragment files (xfs_fsr) if they choose to do so. --cw From owner-linux-xfs@oss.sgi.com Tue Mar 4 11:36:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 11:36:35 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24JaOf25712 for ; Tue, 4 Mar 2003 11:36:24 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24JaOF6030081 for ; Tue, 4 Mar 2003 11:36:24 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA40188 for ; Tue, 4 Mar 2003 13:36:23 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA05444 for ; Tue, 4 Mar 2003 13:36:23 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h24JaMW17922; Tue, 4 Mar 2003 13:36:22 -0600 Message-Id: <200303041936.h24JaMW17922@stout.americas.sgi.com> Date: Tue, 4 Mar 2003 13:36:22 -0600 Subject: TAKE - Make KDB compatible with LBD X-archive-position: 3021 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 490 Lines: 16 Make KDB compatible with the LBD (large block device) patch: Cast sector / block numbers to (unsigned long long) and print with %llu - works for 32 or 64 bit block numbers. Date: Tue Mar 4 11:35:58 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140870a linux/kdb/modules/kdbm_vm.c - 1.23 linux/kdb/modules/kdbm_pg.c - 1.62 From owner-linux-xfs@oss.sgi.com Tue Mar 4 12:16:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 12:16:41 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24KGVf27624 for ; Tue, 4 Mar 2003 12:16:31 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24KGUnH006338 for ; Tue, 4 Mar 2003 12:16:30 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA06170 for ; Tue, 4 Mar 2003 14:16:29 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA77947 for ; Tue, 4 Mar 2003 14:16:29 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h24KGSZ19726; Tue, 4 Mar 2003 14:16:28 -0600 Message-Id: <200303042016.h24KGSZ19726@stout.americas.sgi.com> Date: Tue, 4 Mar 2003 14:16:28 -0600 Subject: TAKE - Add error reporting for EFSCORRUPTED X-archive-position: 3022 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3236 Lines: 85 Add error reporting calls in error paths that return EFSCORRUPTED Date: Tue Mar 4 12:15:43 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Inspected by: gwehrman@sgi.com Author: overby Merged by: sandeen Merged mods: irix6.5f:irix:136445a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:136445a linux/fs/xfs/xfs_ialloc.c - 1.163 linux/fs/xfs/xfs_rw.c - 1.373 - Merge of irix6.5f:irix:136445a by sandeen. Merge of grove2-6520stage:irix:136445a by roehrich. Merge of grove2:irix:136445a by roehrich. Add error reporting calls in error paths that return EFSCORRUPTED linux/fs/xfs/xfs_da_btree.c - 1.138 - Merge of irix6.5f:irix:136445a by sandeen. Merge of grove2-6520stage:irix:136445a by roehrich. Merge of grove2:irix:136445a by roehrich. Add error reporting calls in error paths that return EFSCORRUPTED and cmn_error messages for additional information. linux/fs/xfs/xfs_vnodeops.c - 1.584 linux/fs/xfs/xfs_dir2_block.c - 1.29 linux/fs/xfs/xfs_dir.c - 1.148 linux/fs/xfs/xfs_log_recover.c - 1.258 linux/fs/xfs/xfs_dir_leaf.c - 1.109 linux/fs/xfs/xfs_mount.c - 1.317 linux/fs/xfs/xfs_btree.c - 1.103 - Merge of irix6.5f:irix:136445a by sandeen. Merge of grove2-6520stage:irix:136445a by roehrich. Merge of grove2:irix:136445a by roehrich. Add error reporting calls in error paths that return EFSCORRUPTED linux/fs/xfs/xfs_btree.h - 1.54 - Merge of irix6.5f:irix:136445a by sandeen. Merge of grove2-6520stage:irix:136445a by roehrich. Merge of grove2:irix:136445a by roehrich. Add error reporting calls in macros that return EFSCORRUPTED linux/fs/xfs/xfs_qm.c - 1.94 linux/fs/xfs/xfs_inode.c - 1.362 linux/fs/xfs/xfs_attr_leaf.c - 1.68 - Merge of irix6.5f:irix:136445a by sandeen. Merge of grove2-6520stage:irix:136445a by roehrich. Merge of grove2:irix:136445a by roehrich. Add error reporting calls in error paths that return EFSCORRUPTED linux/fs/xfs/xfs_error.c - 1.37 - Merge of irix6.5f:irix:136445a by sandeen. Merge of grove2-6520stage:irix:136445a by roehrich. Merge of grove2:irix:136445a by roehrich. Add xfs_error_report and xfs_corruption_error functions. These are called by the XFS_ERROR_REPORT and XFS_CORRUPTION_ERROR macros placed in places where there is an error that will result in a filesystem shutdown. linux/fs/xfs/xfs_error.h - 1.30 - Merge of irix6.5f:irix:136445a by sandeen. Merge of grove2-6520stage:irix:136445a by roehrich. Merge of grove2:irix:136445a by roehrich. add prototypes for xfs_error_report and xfs_corruption error and macros to call them. linux/fs/xfs/xfs_alloc.c - 1.163 linux/fs/xfs/xfs_bmap.c - 1.300 linux/fs/xfs/xfs_dir2_node.c - 1.29 linux/fs/xfs/xfs_attr.c - 1.101 - Merge of irix6.5f:irix:136445a by sandeen. Merge of grove2-6520stage:irix:136445a by roehrich. Merge of grove2:irix:136445a by roehrich. Add error reporting calls in error paths that return EFSCORRUPTED linux/fs/xfs/linux/xfs_globals.c - 1.41 linux/fs/xfs/linux/xfs_linux.h - 1.98 linux/fs/xfs/linux/xfs_sysctl.h - 1.10 linux/fs/xfs/linux/xfs_sysctl.c - 1.15 linux/fs/xfs/linux/xfs_iomap.c - 1.6 From owner-linux-xfs@oss.sgi.com Tue Mar 4 12:51:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 12:51:17 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24KpAf28516 for ; Tue, 4 Mar 2003 12:51:10 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24L1bkq017241 for ; Tue, 4 Mar 2003 15:01:37 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA99903 for ; Tue, 4 Mar 2003 14:51:09 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA94446 for ; Tue, 4 Mar 2003 14:51:08 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h24Kp7S25088; Tue, 4 Mar 2003 14:51:07 -0600 Message-Id: <200303042051.h24Kp7S25088@stout.americas.sgi.com> Date: Tue, 4 Mar 2003 14:51:07 -0600 Subject: TAKE - Fix v1dir getdents to not return false EFSCORRUPTED X-archive-position: 3023 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 670 Lines: 22 fix getdents so that xfs_da_read_buf doesn't return an EFSCORRUPTED except when there is a real problem. Date: Tue Mar 4 12:49:48 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Inspected by: overby Author: cwf Merged by: sandeen Merged mods: irix6.5f:irix:138531a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:138531a linux/fs/xfs/xfs_dir.c - 1.149 - Merge of irix6.5f:irix:138531a by sandeen. Merge of irix6.5m:irix:138531a by cwf. fix getdents so that xfs_da_read_buf doesn't return an EFSCORRUPTED except when there is a real problem. From owner-linux-xfs@oss.sgi.com Tue Mar 4 13:17:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 13:17:37 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24LHUf29656 for ; Tue, 4 Mar 2003 13:17:30 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24LRvkq018170 for ; Tue, 4 Mar 2003 15:27:57 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA53520 for ; Tue, 4 Mar 2003 15:17:26 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA68214 for ; Tue, 4 Mar 2003 15:17:29 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h24LHRl27423; Tue, 4 Mar 2003 15:17:27 -0600 Message-Id: <200303042117.h24LHRl27423@stout.americas.sgi.com> Date: Tue, 4 Mar 2003 15:17:27 -0600 Subject: TAKE - Fix freespace entry search to handle holes X-archive-position: 3024 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 678 Lines: 23 Fix freespace entry search to handle holes in the freespace area correctly. Date: Tue Mar 4 13:16:58 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Inspected by: cwf lord Author: overby Merged by: sandeen Merged mods: irix6.5f:irix:133509a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:133509a linux/fs/xfs/xfs_dir2_node.c - 1.30 - Merge of irix6.5f:irix:133509a by sandeen. Merge of grove2-6520stage:irix:133509a by roehrich. Merge of grove2:irix:133509a by roehrich. Fix freespace entry search to handle holes in the freespace area correctly. From owner-linux-xfs@oss.sgi.com Tue Mar 4 13:35:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 13:35:55 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24LZgf00533 for ; Tue, 4 Mar 2003 13:35:42 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24LZgnH024336 for ; Tue, 4 Mar 2003 13:35:42 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA45168 for ; Tue, 4 Mar 2003 15:35:41 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA07712 for ; Tue, 4 Mar 2003 15:35:41 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h24LZdL28246; Tue, 4 Mar 2003 15:35:39 -0600 Message-Id: <200303042135.h24LZdL28246@stout.americas.sgi.com> Date: Tue, 4 Mar 2003 15:35:39 -0600 Subject: TAKE - Fix target_linkzero calculation in rename X-archive-position: 3025 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 684 Lines: 23 Fix target_linkzero calculation Date: Tue Mar 4 13:35:08 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Inspected by: overby Author: gwehrman Merged by: sandeen Merged mods: irix6.5f:irix:135993a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:135993a linux/fs/xfs/xfs_rename.c - 1.47 - Merge of irix6.5f:irix:135993a by sandeen. Merge of grove2-6520stage:irix:135993a by roehrich. Merge of grove2:irix:135993a by roehrich. Bug 836139. Don't calculate target_linkzero until after droping the old '.' link when it is a directory that is being moved. From owner-linux-xfs@oss.sgi.com Tue Mar 4 14:29:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 14:29:50 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24MTef01527 for ; Tue, 4 Mar 2003 14:29:40 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24MTd9n012594 for ; Tue, 4 Mar 2003 14:29:39 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA31822 for ; Tue, 4 Mar 2003 16:29:38 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id QAA12652 for ; Tue, 4 Mar 2003 16:29:38 -0600 (CST) Subject: hold off on cvs updates for a bit - merge flurry From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 04 Mar 2003 16:29:37 -0600 Message-Id: <1046816977.6344.27.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 3026 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 382 Lines: 16 I'm pushing in a bunch of backmerges from irix, and things may not be entirely stable until I'm done. Guess I could have done it all in one big merge but it's easier to wrap my head around one mod at a time. I'll let you know when I'm done. Thanks, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Mar 4 15:30:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 15:30:59 -0800 (PST) Received: from mail02.securities.com (mail02.securities.com [57.69.15.72]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24NUtf02673 for ; Tue, 4 Mar 2003 15:30:55 -0800 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5-DELIVERY) with ESMTP id h24NUseD017995 for ; Tue, 4 Mar 2003 18:30:54 -0500 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5-SMTP) with ESMTP id h24NUrje017990 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 4 Mar 2003 18:30:53 -0500 Received: from localhost (venevene@localhost) by mail02.securities.com (8.12.5/8.12.5/Submit) with ESMTP id h24NUrh6017986 for ; Tue, 4 Mar 2003 18:30:53 -0500 X-Authentication-Warning: mail02.securities.com: venevene owned process doing -bs Date: Tue, 4 Mar 2003 18:30:52 -0500 (EST) From: "Benito A. Venegas" X-X-Sender: Reply-To: "Benito A. Venegas" To: Linux XFS List Subject: How-to convert XFS log v1 -> v2 In-Reply-To: <20030227232109.GA2236@f00f.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3027 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: bvenegas@securities.com Precedence: bulk X-list: linux-xfs Content-Length: 898 Lines: 32 Team xfs: I have 1 FS, 1/4 TB waiting to be converted from v1 to v2. I have a full backup , but I don't want to waste and make a wrong step, and well, recreate FS with xfs v2 and recover the info from tape :/ (My would kill me) The FS was created with mkfs -t xfs -l size=32768b -f /dev/sdb1 and mounted with: mount -t xfs -o logbufs=8,logbsize=32768 /dev/sdb1 /nas02 But I was reading xfs_db manual, based in Chris Wedgwood tip, and I am not so clear how to do it. I heard in the list there was a procedure done in IRIX to convert file systems to v1 to v2, but I am not sure if Eric or Steve have worked on that yet (export to linux). Also I dont know if I can do it in my current file system in the way I created previously. I wouldn't like to rebuild the FS again only for v2, but I know it's going to be much better... I hope you can help me boys. Thanks Benito.- From owner-linux-xfs@oss.sgi.com Tue Mar 4 15:52:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 15:52:37 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24NqSf10797 for ; Tue, 4 Mar 2003 15:52:28 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24NqRnH018809 for ; Tue, 4 Mar 2003 15:52:27 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA09115 for ; Tue, 4 Mar 2003 17:52:26 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA99088 for ; Tue, 4 Mar 2003 17:52:26 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h24NqOp06076; Tue, 4 Mar 2003 17:52:24 -0600 Message-Id: <200303042352.h24NqOp06076@stout.americas.sgi.com> Date: Tue, 4 Mar 2003 17:52:24 -0600 Subject: TAKE - Last of the dir2 backmerges from Irix X-archive-position: 3028 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1273 Lines: 30 Last of the dir2 backmerges from Irix Date: Tue Mar 4 15:51:58 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Merged by: sandeen Merged mods: irix6.5f:irix:137928a,irix6.5f:irix:137929a,irix6.5f:irix:138887a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140918a linux/fs/xfs/xfs_dir2_node.c - 1.32 - Merge of irix6.5f:irix:137928a originally by overby on 02/04/03 Merge of grove2-6520stage:irix:137928a by roehrich. Merge of cxfs-client2.5.0:irix:137928a by roehrich. Merge of grove2:irix:137928a by roehrich. Fix xfs_dir2_node_addname_int call to xfs_da_read_buf. Allow it to return a NULL buf pointer if the block isn't there. Merge of irix6.5f:irix:137929a originally by overby on 02/04/03 Merge of grove2-6520stage:irix:137929a by roehrich. Merge of cxfs-client2.5.0:irix:137929a by roehrich. Merge of grove2:irix:137929a by roehrich. in xfs_dir2_node_trim_free, make reading a nonexistant freespace block a non-fatal error. Merge of irix6.5f:irix:138887a originally by overby on 02/06/03 Merge of irix6.5m:irix:138887a by overby. Check for a NULL freespace buffer pointer before calling xfs_da_buf_done. From owner-linux-xfs@oss.sgi.com Tue Mar 4 15:55:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 15:55:45 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h24Ntgf13195 for ; Tue, 4 Mar 2003 15:55:42 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24Ntg9n023019 for ; Tue, 4 Mar 2003 15:55:42 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA52903 for ; Tue, 4 Mar 2003 17:55:40 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id RAA14580; Tue, 4 Mar 2003 17:55:41 -0600 (CST) Subject: Re: hold off on cvs updates for a bit - merge flurry From: Eric Sandeen To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <1046816977.6344.27.camel@stout.americas.sgi.com> References: <1046816977.6344.27.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 04 Mar 2003 17:55:38 -0600 Message-Id: <1046822138.6313.52.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 3029 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 199 Lines: 8 Ok, I think all the dir v2 changes are in now... carry on.... Thanks, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Mar 4 16:06:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 16:06:21 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h2506If22219 for ; Tue, 4 Mar 2003 16:06:18 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2506I9n024332 for ; Tue, 4 Mar 2003 16:06:18 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA41919 for ; Tue, 4 Mar 2003 18:06:17 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id SAA14110 for ; Tue, 4 Mar 2003 18:06:17 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h2506Fs07250; Tue, 4 Mar 2003 18:06:15 -0600 Message-Id: <200303050006.h2506Fs07250@stout.americas.sgi.com> Date: Tue, 4 Mar 2003 18:06:15 -0600 Subject: TAKE - getdents fix for dir v2 X-archive-position: 3030 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 531 Lines: 20 getdents needs to check for reaching the end of a directory block when searching for the entry after the "cookie" that comes in with the call. Date: Tue Mar 4 16:05:12 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Inspected by: cwf kbeck Author: overby Merged by: sandeen Merged mods: irix6.5f:irix:139574a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:139574a linux/fs/xfs/xfs_dir2_leaf.c - 1.30 From owner-linux-xfs@oss.sgi.com Tue Mar 4 17:28:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 17:28:36 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h251SSf27408 for ; Tue, 4 Mar 2003 17:28:28 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h251cskq024532 for ; Tue, 4 Mar 2003 19:38:55 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h251R97L846276 for ; Wed, 5 Mar 2003 12:27:09 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h251R9AY846418 for linux-xfs@oss.sgi.com; Wed, 5 Mar 2003 12:27:09 +1100 (EST) Date: Wed, 5 Mar 2003 12:27:09 +1100 (EST) From: Nathan Scott Message-Id: <200303050127.h251R9AY846418@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - minor unwritten extents tweak X-archive-position: 3031 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 508 Lines: 17 Implement a suggestion from Christoph - instead of using a new pagebuf flag, we now pass in an additional parameter to pagebuf_iodone instead. Date: Tue Mar 4 17:26:08 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140933a linux/fs/xfs/xfs_buf.h - 1.105 linux/fs/xfs/pagebuf/page_buf.c - 1.102 linux/fs/xfs/pagebuf/page_buf.h - 1.61 linux/fs/xfs/linux/xfs_aops.c - 1.21 From owner-linux-xfs@oss.sgi.com Tue Mar 4 17:55:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 17:55:11 -0800 (PST) Received: from provone.provsol.net (66.83.239.66.nw.nuvox.net [66.83.239.66]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h251t7f08986 for ; Tue, 4 Mar 2003 17:55:08 -0800 Received: from serria.provsol.int (serria.provsol.int [192.168.20.22]) by provone.provsol.net (Postfix) with ESMTP id 4ED59F3 for ; Tue, 4 Mar 2003 19:55:07 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by serria.provsol.int (Postfix) with ESMTP id 3FD8FA02529 for ; Tue, 4 Mar 2003 19:55:07 -0600 (CST) Received: from orion (orion.provsol.int [192.168.20.23]) by serria.provsol.int (Postfix) with SMTP id F2454A017DE for ; Tue, 4 Mar 2003 19:55:06 -0600 (CST) From: "Vernon A. Fort" To: Subject: RE: XFS and RH8 failing install Date: Tue, 4 Mar 2003 19:55:35 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <3E64D298.ADC2C124@srz-berlin.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS snapshot-20020300 X-archive-position: 3032 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: vfort@provident-solutions.com Precedence: bulk X-list: linux-xfs Content-Length: 1213 Lines: 46 I'm having the exact same problem. I have successfully install RedHat-7.3-XFS on this hardware (a new drive - exactly the same but just new). The specs: Athlon 1900+ 768meg ram WD 40gig drive (ata100) Etc.... It seems like the disc 6 completes and fails to prompt for the next CD....again, the exact same problem, failing to install anaconda-8.0-2XFS.. Andy ----------------------------------- Vernon A. Fort (Andy) Provident Solutions, LLC (615) 427-4016 http://www.provident-solutions.com -----Original Message----- From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Axel Bringenberg Sent: Tuesday, March 04, 2003 10:22 AM To: linux-xfs@oss.sgi.com Subject: Re: XFS and RH8 failing install Eric Sandeen schrieb: > > I think that Russell fixed this on the latest iso, can you verify that > you're using the latest? Oups - yes: my fault. it was the v3 iso image, sorry. But with v4 I have the next problem: a installation (custom, with "everything" packages) failed on disc 6 while installing "anaconda-8.0-2XFS". iso images is ok (check with md5sum an installer-build test). Regards, - bringi Axel Bringenberg -- Satz-Rechen-Zentrum Berlin - Systemgruppe From owner-linux-xfs@oss.sgi.com Tue Mar 4 18:24:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 18:24:59 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h252Oqf21199 for ; Tue, 4 Mar 2003 18:24:52 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h24MWp9n012998 for ; Tue, 4 Mar 2003 14:32:51 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA76661 for ; Tue, 4 Mar 2003 16:32:50 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA61360 for ; Tue, 4 Mar 2003 16:32:51 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h24MWn130725; Tue, 4 Mar 2003 16:32:49 -0600 Message-Id: <200303042232.h24MWn130725@stout.americas.sgi.com> Date: Tue, 4 Mar 2003 16:32:49 -0600 Subject: TAKE - Rearrange leaf space allocation X-archive-position: 3033 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 902 Lines: 26 Rearrange leaf space allocation Date: Tue Mar 4 14:32:14 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Inspected by: cwf@sgi.com Author: overby Merged by: sandeen Merged mods: irix6.5f:irix:136459a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:136459a linux/fs/xfs/xfs_dir2_node.c - 1.31 - Merge of irix6.5f:irix:136459a by sandeen. Merge of grove2-6520stage:irix:136459a by roehrich. Merge of grove2:irix:136459a by roehrich. Move the leaf space allocation in xfs_dir2_node_addname_int from before allocating data space to within data space allocation. This is to fix a problem where new leaf space block was not allocated when it should have been. Now xfs_node_addname_int will allocate a free space block if it finds that the one it needs is missing. From owner-linux-xfs@oss.sgi.com Tue Mar 4 20:08:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 20:08:10 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25482f31844 for ; Tue, 4 Mar 2003 20:08:02 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h254809n007327 for ; Tue, 4 Mar 2003 20:08:01 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2546h7L852710 for ; Wed, 5 Mar 2003 15:06:43 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2546hYh860271 for linux-xfs@oss.sgi.com; Wed, 5 Mar 2003 15:06:43 +1100 (EST) Date: Wed, 5 Mar 2003 15:06:43 +1100 (EST) From: Nathan Scott Message-Id: <200303050406.h2546hYh860271@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - bigger, better unwritten extent tweak X-archive-position: 3035 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 730 Lines: 21 Ah -- knew if I stared at it long enough I'd see a way to do this. Remove the page array I created to hold pages until we could setup enough state for the IO completion handlers to do their thing - we now make more judicious use of the atomic pb_io_remaining field to ensure the IO completion handlers are never called before the pb is completely setup. Also fixed several comments, and renamed several functions which are no longer specific to delayed allocation. cheers. Date: Tue Mar 4 20:03:40 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140937a linux/fs/xfs/linux/xfs_aops.c - 1.22 From owner-linux-xfs@oss.sgi.com Tue Mar 4 21:46:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Mar 2003 21:47:04 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h255kvf01511 for ; Tue, 4 Mar 2003 21:46:57 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h255ku9n012850 for ; Tue, 4 Mar 2003 21:46:56 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id XAA21375; Tue, 4 Mar 2003 23:46:56 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id XAA32205; Tue, 4 Mar 2003 23:46:55 -0600 (CST) Date: Tue, 4 Mar 2003 23:46:50 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: utz lehmann cc: linux-xfs@oss.sgi.com Subject: Re: [PATCH] xfs_fsr: avoid unnessary copying In-Reply-To: <20030302232830.A16452@s2y4n2c.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3036 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2345 Lines: 80 Ok, this isn't quite right. For a file with holes, the "best-case" scenario is > 1 extent. I think your patch will bail out if any particular extent on one side of a hole does not defrag, rather than looking at all extents in a hole-y file. I think the right way to do it is to do 2 loops - first loop, go through allocating extents (accounting for holes if necessary). THEN check how many extents the temp file has, and proceed with copying in a 2nd loop if things look better. I have a patch that does this, I'll probably get it checked in tomorrow if it looks good to a reviewer or two. Thanks, -Eric On Sun, 2 Mar 2003, utz lehmann wrote: > Hi > > This patch moves the check for improved extent count directly after the > preallocation of the extents. So it can avoid copying of the extent data in > the case that no improvement is made. The patch is against current CVS. > > On my testsystem with 3 files which cant improved the elapsed time went down > from 3min to 6s and saved about 3GB disk io. > > > utz > > > --- xfs_fsr.c.orig Sat Mar 1 13:53:36 2003 > +++ xfs_fsr.c Sun Mar 2 23:02:25 2003 > @@ -967,7 +967,8 @@ > { > int tfd; > int srval; > - int nextents, extent, cur_nextents, new_nextents; > + int nextents, extent, cur_nextents; > + int new_nextents = 0; > unsigned blksz_dio; > unsigned dio_min; > struct dioattr dio; > @@ -1111,6 +1112,15 @@ > return -1; > } > } > + /* Check if the extent count improved */ > + new_nextents = getnextents(tfd); > + if (cur_nextents <= new_nextents) { > + if (vflag) > + fsrprintf(_("No improvement made: %s\n"), fname); > + close(tfd); > + free(fbuf); > + return 1; /* no change/no error */ > + } > for (cnt = outmap[extent].bmv_length; cnt > 0; > cnt -= ct, pos += ct) { > if (nfrags && --nfrags) { > @@ -1195,15 +1205,6 @@ > sx.sx_offset = 0; > sx.sx_length = statp->bs_size; > > - /* Check if the extent count improved */ > - new_nextents = getnextents(tfd); > - if (cur_nextents <= new_nextents) { > - if (vflag) > - fsrprintf(_("No improvement made: %s\n"), fname); > - close(tfd); > - return 1; /* no change/no error */ > - } > - > /* switch to the owner's id, to keep quota in line */ > if (fchown(tfd, statp->bs_uid, statp->bs_gid) < 0) { > if (vflag) > > > > From owner-linux-xfs@oss.sgi.com Wed Mar 5 00:48:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 00:48:29 -0800 (PST) Received: from mail.automatix.de ([62.67.57.175]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h258mMf04293 for ; Wed, 5 Mar 2003 00:48:22 -0800 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.35 #1) id 18qUZU-0008T9-00 for linux-xfs@oss.sgi.com; Wed, 05 Mar 2003 09:48:16 +0100 Received: from pc2.s.automatix.de ([192.168.11.12]) by s.automatix.de with esmtp (Exim 3.36 #1) id 18qUZ5-0002DT-00 for linux-xfs@oss.sgi.com; Wed, 05 Mar 2003 09:47:51 +0100 From: Juergen Sauer Reply-To: juergen.sauer@automatix.de Organization: AutomatiX GmbH To: linux-xfs@oss.sgi.com Subject: Kernel with XFS + nvidia/nforce2 Chipset ? Date: Wed, 5 Mar 2003 10:48:54 +0100 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200303051048.54271.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h258mMf04294 X-archive-position: 3037 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: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs Content-Length: 1157 Lines: 40 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moin, does anybody know a 'working' patch for a 2.4 Kernel, included XFS of course ? The well known/common patches for 2.4 Kernels are failing on our XFS stable kernels. Without this patched the ide modules are not enableing DMA/UDMA at all so this is not a usable solution. The original Nvidia "Drivers" has only "audio" and "network" drivers, but nvida excluded the IDE Part. (Bad Boys!). You can google the "common" solutions here: http://www.google.com/search?hl=en&ie=ISO-8859-1&q=linux%2Bnforce2%2Bide&btnG=Google+Search But those does not work/patch works not on linux-2.4-XFS Kernels. Has anybody already got a working solution ? TIA - quite a lot ... mfG Jürgen automatiX Linux Support Crew - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** ** http://www.automatix.de http://www.kranautomatisierung.de ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ZcgGW7UKI9EqarERAl1TAJ9C/Pl2CpUZhbuytBGYsorogkn/eACeLB17 vzQyEhb2OSu141mx/MkNmoI= =og0Y -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Mar 5 01:08:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 01:08:08 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25985f05103 for ; Wed, 5 Mar 2003 01:08:05 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id A995CAC38; Wed, 5 Mar 2003 10:19:21 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 3796819012; Wed, 5 Mar 2003 10:19:21 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 8F63B30881E; Wed, 5 Mar 2003 10:08:01 +0100 (CET) Message-ID: <3E65BE71.3D819D0D@ch.sauter-bc.com> Date: Wed, 05 Mar 2003 10:08:01 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: juergen.sauer@automatix.de Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? References: <200303051048.54271.juergen.sauer@automatix.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 3038 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: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 1704 Lines: 55 Juergen Sauer schrieb: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Moin, > > does anybody know a 'working' patch for a 2.4 Kernel, > included XFS of course ? > > The well known/common patches for 2.4 Kernels are failing on our > XFS stable kernels. > > Without this patched the ide modules are not enableing DMA/UDMA at all so > this is not a usable solution. > > The original Nvidia "Drivers" has only "audio" and "network" drivers, but > nvida excluded the IDE Part. (Bad Boys!). Nvidia is one of those companies who generate too much headaches for Linux users. Just think about all the graphic cards related problems with binary only kernel modules... The good news is that DMA/UDMA seems to work well with nforce chipsets. I'm always using XFS enhanced RedHat Kernels and I did not have any problems. I just enabled UDMA with kernel parameter, IIRC it was something like 'ide0=ata66 ide1=ata66'. HTH Simon > > You can google the "common" solutions here: > http://www.google.com/search?hl=en&ie=ISO-8859-1&q=linux%2Bnforce2%2Bide&btnG=Google+Search > But those does not work/patch works not on linux-2.4-XFS Kernels. > > Has anybody already got a working solution ? > > TIA - quite a lot ... > > mfG > Jürgen > automatiX Linux Support Crew > - -- > Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** > ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** > ** http://www.automatix.de http://www.kranautomatisierung.de ** > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (GNU/Linux) > > iD8DBQE+ZcgGW7UKI9EqarERAl1TAJ9C/Pl2CpUZhbuytBGYsorogkn/eACeLB17 > vzQyEhb2OSu141mx/MkNmoI= > =og0Y > -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Mar 5 01:35:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 01:36:03 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h259Zsf06133 for ; Wed, 5 Mar 2003 01:35:54 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id D313C1830671; Wed, 5 Mar 2003 01:35:54 -0800 (PST) Date: Wed, 5 Mar 2003 01:35:54 -0800 From: Chris Wedgwood To: Juergen Sauer Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? Message-ID: <20030305093554.GA29602@f00f.org> References: <200303051048.54271.juergen.sauer@automatix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303051048.54271.juergen.sauer@automatix.de> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 3039 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 544 Lines: 23 On Wed, Mar 05, 2003 at 10:48:54AM +0100, Juergen Sauer wrote: > The well known/common patches for 2.4 Kernels are failing on our XFS > stable kernels. failing? how so? > Without this patched the ide modules are not enableing DMA/UDMA at > all so this is not a usable solution. does the amd7xx IDE driver fix this? it has some nv IDs in there by the looks of things? if not, what does "lspci -n" say for the ide controller? > Has anybody already got a working solution ? avoid hardware where vendors make your life difficult --cw From owner-linux-xfs@oss.sgi.com Wed Mar 5 01:56:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 01:56:58 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h259upf06833 for ; Wed, 5 Mar 2003 01:56:51 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 732DD146A7 for ; Wed, 5 Mar 2003 10:56:50 +0100 (MET) Date: Wed, 5 Mar 2003 10:56:50 +0100 From: Andi Kleen To: linux-xfs@oss.sgi.com Subject: cvs checkout stalling Message-ID: <20030305095649.GA25200@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 3040 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: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 390 Lines: 15 When I check out or update linux-2.4-xfs the checkout always stalls on U linux/scripts/lxdialog/yesno.c cvs server: Updating linux/scripts/usb Fresh checkout makes no difference. That's towards the end so it may do some book kepping issue on the server. Does anybody else have these problems with CVS? Thanks, -Andi From owner-linux-xfs@oss.sgi.com Wed Mar 5 02:12:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 02:12:24 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25ACLf07581 for ; Wed, 5 Mar 2003 02:12:21 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id A6AD4AC38 for ; Wed, 5 Mar 2003 11:23:38 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 4E4E519160 for ; Wed, 5 Mar 2003 11:23:39 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 84E8E30881D for ; Wed, 5 Mar 2003 11:12:19 +0100 (CET) Message-ID: <3E65CD83.5C2BC92F@ch.sauter-bc.com> Date: Wed, 05 Mar 2003 11:12:19 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: linux-xfs Subject: RedHat errata kernel with XFS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3041 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: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 259 Lines: 8 I've just created source rpm for RedHat errata kernel, based on Seth's last version. This one is untested at all but seems to build fine on RedHat 7.3. It can be found here http://www.sauter-bc.com/XFS/kernel-2.4.18-26SGI_XFS_1.2.0.src.rpm Good luck! Simon From owner-linux-xfs@oss.sgi.com Wed Mar 5 02:25:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 02:25:26 -0800 (PST) Received: from relay.dstl.gov.uk (relay.dera.gov.uk [192.5.29.49]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25APMf09476 for ; Wed, 5 Mar 2003 02:25:22 -0800 Received: (qmail 14779 invoked from network); 5 Mar 2003 10:25:19 +0000 Received: from warlock.dstl.gov.uk (192.5.29.10) by relay.dera.gov.uk with SMTP; 5 Mar 2003 10:25:16 +0000 Subject: Re: cvs checkout stalling From: Tony Gale To: Andi Kleen Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030305095649.GA25200@dstl.gov.uk> References: <20030305095649.GA25200@dstl.gov.uk> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/ZOnGNRMUwnFVcOyV8yw" Organization: Message-Id: <1046859916.6953.1.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 05 Mar 2003 10:25:17 +0000 X-archive-position: 3042 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: gale@syntax.dstl.gov.uk Precedence: bulk X-list: linux-xfs Content-Length: 1175 Lines: 38 --=-/ZOnGNRMUwnFVcOyV8yw Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2003-03-05 at 09:56, Andi Kleen wrote: > When I check out or update linux-2.4-xfs the checkout always stalls on=20 >=20 > U linux/scripts/lxdialog/yesno.c > cvs server: Updating linux/scripts/usb > >=20 > Fresh checkout makes no difference. >=20 > That's towards the end so it may do some book kepping issue on the=20 > server. Does anybody else have these problems with CVS? As Seth told me last week "upgrade your cvs tools". 1.11.5 works fine. Or you can simply break out, as the update has actually finished. -tony --=-/ZOnGNRMUwnFVcOyV8yw Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iQCVAwUAPmXQjB/0GZs/Z0FlAQKq7AQAgkO7h/1zlSPEW6dSjVgdhRwMVL9AgWl6 /+ypFRIGLPbFRBaJ6RUqmfEunEtlDbjbZtx/vNugOrYoGUvIf56m5igNWJY/zXOK PSsNr2TbCI6jGZzx8N2ayo83d058jLm6V8Ko6MqBMRHzjRcIc/s4jHgoA+LVtut3 jXgIw7LNR8o= =WCP9 -----END PGP SIGNATURE----- --=-/ZOnGNRMUwnFVcOyV8yw-- From owner-linux-xfs@oss.sgi.com Wed Mar 5 02:45:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 02:45:52 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25Ajhf11499 for ; Wed, 5 Mar 2003 02:45:44 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 39A4B146AE; Wed, 5 Mar 2003 11:45:43 +0100 (MET) Date: Wed, 5 Mar 2003 11:45:39 +0100 From: Andi Kleen To: Tony Gale Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: cvs checkout stalling Message-ID: <20030305104539.GC3051@wotan.suse.de> References: <20030305095649.GA25200@dstl.gov.uk> <1046859916.6953.1.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1046859916.6953.1.camel@syntax.dstl.gov.uk> X-archive-position: 3043 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: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 209 Lines: 7 > As Seth told me last week "upgrade your cvs tools". 1.11.5 works fine. > Or you can simply break out, as the update has actually finished. Ok thanks for the hint. Will update. This was cvs 1.11.1p1 -Andi From owner-linux-xfs@oss.sgi.com Wed Mar 5 03:54:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 03:54:54 -0800 (PST) Received: from dmz.tecosim.de (dmz.tecosim.com [195.135.152.162]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25Bskf13142 for ; Wed, 5 Mar 2003 03:54:46 -0800 Received: by dmz.tecosim.de (Postfix, from userid 10) id A92DB1402D; Wed, 5 Mar 2003 12:54:44 +0100 (CET) Received: from alg-ru-ext.tecosim.com(195.135.152.146), claiming to be "alg-ru.tecosim.de" via SMTP by dmz.tecosim.com, id smtpdAPxrDj; Wed Mar 5 12:54:42 2003 Received: from ns.tecosim.de (unknown [10.0.2.1]) by alg-ru.tecosim.de (Postfix) with ESMTP id 98A5418015; Wed, 5 Mar 2003 12:54:41 +0100 (CET) Received: from donner.tecosim.de (donner.tecosim.de [10.0.16.1]) by ns.tecosim.de (8.11.6/8.11.6) with ESMTP id h25Bseg22234; Wed, 5 Mar 2003 12:54:40 +0100 Received: (from leh@localhost) by donner.tecosim.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) id h25Bseq21706; Wed, 5 Mar 2003 12:54:40 +0100 Date: Wed, 5 Mar 2003 12:54:40 +0100 From: Utz Lehmann To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: [PATCH] xfs_fsr: avoid unnessary copying Message-ID: <20030305125440.F20654@de.tecosim.com> References: <20030302232830.A16452@s2y4n2c.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from sandeen@sgi.com on Tue, Mar 04, 2003 at 11:46:50PM -0600 X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) X-archive-position: 3044 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: ulehmann@de.tecosim.com Precedence: bulk X-list: linux-xfs Content-Length: 2947 Lines: 98 Hi Eric Eric Sandeen [sandeen@sgi.com] wrote: > Ok, this isn't quite right. For a file with holes, the "best-case" > scenario is > 1 extent. I think your patch will bail out > if any particular extent on one side of a hole does not defrag, > rather than looking at all extents in a hole-y file. No. I have tested that case. cur_nextents and getnextents() are always for the whole file and not for a group of non hole extents that will preallocated at once. Sometimes there will be unnessary coping of extents when the file is hole-y. But the final result is the same. > > I think the right way to do it is to do 2 loops - first loop, go > through allocating extents (accounting for holes if necessary). > THEN check how many extents the temp file has, and proceed with > copying in a 2nd loop if things look better. I thought about that too. It's the better way. But this require to spilt the loop. I dont know if it's worth. utz > > I have a patch that does this, I'll probably get it checked in tomorrow > if it looks good to a reviewer or two. > > Thanks, > -Eric > > On Sun, 2 Mar 2003, utz lehmann wrote: > > > Hi > > > > This patch moves the check for improved extent count directly after the > > preallocation of the extents. So it can avoid copying of the extent data in > > the case that no improvement is made. The patch is against current CVS. > > > > On my testsystem with 3 files which cant improved the elapsed time went down > > from 3min to 6s and saved about 3GB disk io. > > > > > > utz > > > > > > --- xfs_fsr.c.orig Sat Mar 1 13:53:36 2003 > > +++ xfs_fsr.c Sun Mar 2 23:02:25 2003 > > @@ -967,7 +967,8 @@ > > { > > int tfd; > > int srval; > > - int nextents, extent, cur_nextents, new_nextents; > > + int nextents, extent, cur_nextents; > > + int new_nextents = 0; > > unsigned blksz_dio; > > unsigned dio_min; > > struct dioattr dio; > > @@ -1111,6 +1112,15 @@ > > return -1; > > } > > } > > + /* Check if the extent count improved */ > > + new_nextents = getnextents(tfd); > > + if (cur_nextents <= new_nextents) { > > + if (vflag) > > + fsrprintf(_("No improvement made: %s\n"), fname); > > + close(tfd); > > + free(fbuf); > > + return 1; /* no change/no error */ > > + } > > for (cnt = outmap[extent].bmv_length; cnt > 0; > > cnt -= ct, pos += ct) { > > if (nfrags && --nfrags) { > > @@ -1195,15 +1205,6 @@ > > sx.sx_offset = 0; > > sx.sx_length = statp->bs_size; > > > > - /* Check if the extent count improved */ > > - new_nextents = getnextents(tfd); > > - if (cur_nextents <= new_nextents) { > > - if (vflag) > > - fsrprintf(_("No improvement made: %s\n"), fname); > > - close(tfd); > > - return 1; /* no change/no error */ > > - } > > - > > /* switch to the owner's id, to keep quota in line */ > > if (fchown(tfd, statp->bs_uid, statp->bs_gid) < 0) { > > if (vflag) > > > > > > > > > From owner-linux-xfs@oss.sgi.com Wed Mar 5 06:27:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 06:27:55 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25ERkf17363 for ; Wed, 5 Mar 2003 06:27:46 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25ERjnH006915 for ; Wed, 5 Mar 2003 06:27:45 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA85228 for ; Wed, 5 Mar 2003 08:27:44 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA72515 for ; Wed, 5 Mar 2003 08:27:43 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h25LhOr18843 for linux-xfs@oss.sgi.com; Wed, 5 Mar 2003 16:43:24 -0500 Resent-Message-Id: <200303052143.h25LhOr18843@taclab54.munich.sgi.com> Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA70195 for ; Wed, 5 Mar 2003 08:26:58 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h25LgcT18775 for hch@sgi.com; Wed, 5 Mar 2003 16:42:38 -0500 Date: Wed, 5 Mar 2003 16:42:38 -0500 From: Christoph Hellwig Message-Id: <200303052142.h25LgcT18775@taclab54.munich.sgi.com> Subject: TAKE - Spelling fixes from 2.5.64 Resent-From: hch@sgi.com Resent-Date: Wed, 5 Mar 2003 16:43:24 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 3045 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: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 503 Lines: 17 Date: Wed Mar 5 06:26:06 PST 2003 Workarea: taclab54.munich.sgi.com:/home/hch/repo/slinx/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140951a linux/fs/xfs/xfs_trans_dquot.c - 1.40 linux/fs/xfs/xfs_buf_item.c - 1.136 linux/fs/xfs/xfs_da_btree.c - 1.139 linux/fs/xfs/xfs_dquot.c - 1.73 linux/fs/xfs/xfs_dir_leaf.c - 1.110 linux/fs/xfs/xfs_mount.c - 1.318 linux/fs/xfs/xfs_inode.c - 1.363 linux/fs/xfs/xfs_attr_leaf.c - 1.69 From owner-linux-xfs@oss.sgi.com Wed Mar 5 07:51:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 07:51:21 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25FpEf20776 for ; Wed, 5 Mar 2003 07:51:14 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25G1ikq005399 for ; Wed, 5 Mar 2003 10:01:44 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA13720; Wed, 5 Mar 2003 09:51:12 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA59825; Wed, 5 Mar 2003 09:51:12 -0600 (CST) Subject: Re: [PATCH] xfs_fsr: avoid unnessary copying From: Eric Sandeen To: Utz Lehmann Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030305125440.F20654@de.tecosim.com> References: <20030302232830.A16452@s2y4n2c.de> <20030305125440.F20654@de.tecosim.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 05 Mar 2003 09:51:04 -0600 Message-Id: <1046879464.13282.41.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 3046 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 616 Lines: 20 On Wed, 2003-03-05 at 05:54, Utz Lehmann wrote: > No. I have tested that case. cur_nextents and getnextents() are always for > the whole file and not for a group of non hole extents that will preallocated > at once. > Sometimes there will be unnessary coping of extents when the file is hole-y. > But the final result is the same. Ok, yes - I agree. Finally took a few moments to really look at it. Well, so I have code for both ways now... I'll check one of them in. :) Thanks, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Mar 5 08:31:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 08:32:01 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25GVpf21780 for ; Wed, 5 Mar 2003 08:31:51 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25GVo9n024028 for ; Wed, 5 Mar 2003 08:31:51 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA00079 for ; Wed, 5 Mar 2003 10:31:50 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA30147 for ; Wed, 5 Mar 2003 10:31:50 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h25GVf219340; Wed, 5 Mar 2003 10:31:41 -0600 Message-Id: <200303051631.h25GVf219340@stout.americas.sgi.com> Date: Wed, 5 Mar 2003 10:31:41 -0600 Subject: TAKE - Eliminate a race condition in xfs_inval_cached_pages X-archive-position: 3047 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 681 Lines: 23 Eliminate a race condition in xfs_inval_cached_pages Date: Wed Mar 5 08:30:55 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Inspected by: gwehrman Author: overby Merged by: sandeen Merged mods: irix6.5f:irix:136462a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:136462b linux/fs/xfs/xfs_rw.c - 1.374 - Merge of irix6.5f:irix:136462a by sandeen. Merge of grove2-6520stage:irix:136462a by roehrich. Merge of grove2:irix:136462a by roehrich. Eliminate a race condition in xfs_inval_cached_pages by using XFS_ILOCK_DEMOTE instead of unlock / lock. From owner-linux-xfs@oss.sgi.com Wed Mar 5 09:06:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 09:06:59 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25H6mf22652 for ; Wed, 5 Mar 2003 09:06:48 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25H6l9n028065 for ; Wed, 5 Mar 2003 09:06:47 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA36124 for ; Wed, 5 Mar 2003 11:06:47 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA63056 for ; Wed, 5 Mar 2003 11:06:46 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h25H6ku20613; Wed, 5 Mar 2003 11:06:46 -0600 Message-Id: <200303051706.h25H6ku20613@jen.americas.sgi.com> Date: Wed, 5 Mar 2003 11:06:46 -0600 Subject: TAKE 877736 - Eliminate a race condition in xfs_inval_cached_pages X-archive-position: 3048 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 434 Lines: 16 back out the last change to this file, it is incorrect, the merge tools broke on this one before. The actual fix has been in xfs linux for a long time. Date: Wed Mar 5 08:47:58 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.4 Undoes mod: 2.4.x-xfs:slinx:136462b The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140964a linux/fs/xfs/xfs_rw.c - 1.375 From owner-linux-xfs@oss.sgi.com Wed Mar 5 09:55:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 09:55:44 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25HtRf24756 for ; Wed, 5 Mar 2003 09:55:27 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25HtQ9n031805 for ; Wed, 5 Mar 2003 09:55:26 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA70156 for ; Wed, 5 Mar 2003 11:55:25 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA55887 for ; Wed, 5 Mar 2003 11:55:23 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h261B4H19971 for linux-xfs@oss.sgi.com; Wed, 5 Mar 2003 20:11:04 -0500 Resent-Message-Id: <200303060111.h261B4H19971@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA77659 for ; Wed, 5 Mar 2003 11:52:04 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id h25Hq2ok19132740 for ; Wed, 5 Mar 2003 09:52:02 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h25Hn1M0007800 for ; Wed, 5 Mar 2003 18:49:01 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h25Hn1Zo007799 for hch@sgi.com; Wed, 5 Mar 2003 18:49:01 +0100 Date: Wed, 5 Mar 2003 18:49:01 +0100 From: Christoph Hellwig Message-Id: <200303051749.h25Hn1Zo007799@lab343.munich.sgi.com> Subject: TAKE - Merge up to 2.5.64 To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Wed, 5 Mar 2003 20:11:04 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 3049 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: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 50114 Lines: 1279 Date: Wed Mar 5 09:44:20 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:140970a linux/drivers/acpi/events/evgpeblk.c - 1.1 linux/scripts/genksyms/parse.y - 1.1 linux/scripts/genksyms/parse.h_shipped - 1.1 linux/scripts/genksyms/parse.c_shipped - 1.1 linux/scripts/genksyms/lex.l - 1.1 linux/Documentation/DocBook/usb.tmpl - 1.1 linux/scripts/genksyms/lex.c_shipped - 1.1 linux/Documentation/arm/XScale/IOP3XX/IQ80310 - 1.1 linux/Documentation/arm/XScale/IOP3XX/IQ80321 - 1.1 linux/Documentation/arm/XScale/IOP3XX/aau.txt - 1.1 linux/Documentation/arm/XScale/IOP3XX/dma.txt - 1.1 linux/Documentation/arm/XScale/IOP3XX/message.txt - 1.1 linux/Documentation/arm/XScale/IOP3XX/pmon.txt - 1.1 linux/Documentation/arm/XScale/cache-lock.txt - 1.1 linux/Documentation/arm/XScale/pmu.txt - 1.1 linux/Documentation/arm/XScale/tlb-lock.txt - 1.1 linux/scripts/genksyms/keywords.gperf - 1.1 linux/Documentation/cpu-freq/core.txt - 1.1 linux/Documentation/cpu-freq/cpu-drivers.txt - 1.1 linux/Documentation/cpu-freq/governors.txt - 1.1 linux/Documentation/cpu-freq/index.txt - 1.1 linux/Documentation/cpu-freq/user-guide.txt - 1.1 linux/scripts/genksyms/keywords.c_shipped - 1.1 linux/scripts/genksyms/genksyms.h - 1.1 linux/drivers/base/init.c - 1.1 linux/drivers/char/watchdog/amd7xx_tco.c - 1.1 linux/scripts/genksyms/genksyms.c - 1.1 linux/drivers/cpufreq/userspace.c - 1.1 linux/scripts/genksyms/Makefile - 1.1 linux/net/ipv6/netfilter/ip6t_frag.c - 1.1 linux/include/linux/netfilter_ipv6/ip6t_ipv6header.h - 1.1 linux/include/linux/netfilter_ipv6/ip6t_opts.h - 1.1 linux/include/linux/netfilter_ipv6/ip6t_rt.h - 1.1 linux/net/sctp/proc.c - 1.1 linux/include/linux/netfilter_ipv6/ip6t_hl.h - 1.1 linux/include/linux/netfilter_ipv6/ip6t_frag.h - 1.1 linux/include/linux/netfilter_ipv6/ip6t_esp.h - 1.1 linux/include/linux/netfilter_ipv6/ip6t_ah.h - 1.1 linux/fs/sysfs/bin.c - 1.1 linux/fs/sysfs/dir.c - 1.1 linux/net/ipv6/netfilter/ip6t_rt.c - 1.1 linux/net/ipv6/netfilter/ip6t_ipv6header.c - 1.1 linux/drivers/hotplug/cpqphp_sysfs.c - 1.1 linux/drivers/scsi/scsi_pc98.c - 1.1 linux/drivers/usb/input/kbtab.c - 1.1 linux/drivers/usb/serial/keyspan_mpr_fw.h - 1.1 linux/net/ipv6/netfilter/ip6t_hl.c - 1.1 linux/net/ipv6/netfilter/ip6t_hbh.c - 1.1 linux/drivers/video/cg14.c - 1.1 linux/drivers/usb/serial/keyspan_usa49wlc_fw.h - 1.1 linux/drivers/video/bw2.c - 1.1 linux/net/ipv6/netfilter/ip6t_esp.c - 1.1 linux/fs/sysfs/file.c - 1.1 linux/drivers/video/cg3.c - 1.1 linux/drivers/video/cg6.c - 1.1 linux/net/ipv6/netfilter/ip6t_dst.c - 1.1 linux/drivers/video/ffb.c - 1.1 linux/drivers/video/p9100.c - 1.1 linux/net/ipv6/netfilter/ip6t_ah.c - 1.1 linux/drivers/video/sbuslib.c - 1.1 linux/drivers/video/sbuslib.h - 1.1 linux/arch/i386/kernel/srat.c - 1.1 linux/fs/sysfs/mount.c - 1.1 linux/init/do_mounts_md.c - 1.1 linux/drivers/video/tcx.c - 1.1 linux/fs/sysfs/symlink.c - 1.1 linux/init/do_mounts.h - 1.1 linux/init/do_mounts_devfs.c - 1.1 linux/init/do_mounts_rd.c - 1.1 linux/arch/i386/mm/boot_ioremap.c - 1.1 linux/fs/sysfs/sysfs.h - 1.1 linux/include/asm-i386/srat.h - 1.1 linux/include/asm-arm/arch-pxa/bitfield.h - 1.1 linux/scripts/README.Menuconfig - 1.4 linux/scripts/Makefile - 1.17 linux/net/sunrpc/auth_unix.c - 1.13 linux/net/socket.c - 1.51 linux/net/netsyms.c - 1.62 linux/net/irda/irttp.c - 1.21 linux/net/irda/irlmp_event.c - 1.21 linux/net/ipx/af_ipx.c - 1.33 linux/net/ipv6/sit.c - 1.28 linux/net/ipv6/route.c - 1.29 linux/net/ipv6/ndisc.c - 1.29 linux/net/ipv6/addrconf.c - 1.32 linux/net/ipv4/tcp.c - 1.51 linux/net/core/dev.c - 1.69 linux/net/core/Makefile - 1.14 linux/mm/swap_state.c - 1.59 linux/mm/swap.c - 1.34 linux/mm/slab.c - 1.52 linux/mm/mmap.c - 1.72 linux/mm/memory.c - 1.101 linux/mm/filemap.c - 1.150 linux/kernel/sys.c - 1.48 linux/kernel/module.c - 1.39 linux/kernel/ksyms.c - 1.183 linux/kernel/fork.c - 1.85 linux/kernel/exit.c - 1.66 linux/init/main.c - 1.102 linux/include/video/sbusfb.h - 1.7 linux/include/net/irda/irda_device.h - 1.16 linux/include/linux/time.h - 1.12 linux/include/linux/swap.h - 1.73 linux/include/linux/smp.h - 1.26 linux/include/linux/serial.h - 1.18 linux/include/linux/sdla_x25.h - 1.5 linux/include/linux/pci.h - 1.73 linux/include/linux/net.h - 1.13 linux/include/linux/module.h - 1.46 linux/include/linux/mm.h - 1.114 linux/include/linux/list.h - 1.24 linux/include/linux/if.h - 1.7 linux/include/linux/ghash.h - 1.3 linux/include/linux/fs.h - 1.208 linux/include/linux/dcache.h - 1.34 linux/include/linux/cyclades.h - 1.10 linux/include/asm-sparc64/uaccess.h - 1.10 linux/include/asm-sparc64/pbm.h - 1.13 linux/include/asm-sparc64/ioctl.h - 1.3 linux/include/asm-sparc64/hardirq.h - 1.19 linux/include/asm-sparc/uaccess.h - 1.11 linux/include/asm-sparc/ioctl.h - 1.4 linux/include/asm-ppc/uaccess.h - 1.14 linux/include/asm-ppc/page.h - 1.22 linux/include/asm-mips/processor.h - 1.21 linux/include/asm-mips/pgtable.h - 1.20 linux/include/asm-mips/pci.h - 1.14 linux/include/asm-mips/mipsregs.h - 1.10 linux/include/asm-m68k/posix_types.h - 1.5 linux/include/asm-m68k/page.h - 1.15 linux/include/asm-m68k/io.h - 1.10 linux/include/asm-m68k/dvma.h - 1.8 linux/include/asm-i386/uaccess.h - 1.20 linux/include/asm-i386/sigcontext.h - 1.5 linux/include/asm-i386/semaphore.h - 1.19 linux/include/asm-i386/page.h - 1.35 linux/include/asm-arm/proc-fns.h - 1.13 linux/include/asm-arm/bitops.h - 1.14 linux/include/asm-alpha/pci.h - 1.18 linux/include/asm-alpha/mman.h - 1.6 linux/include/asm-alpha/bitops.h - 1.15 linux/fs/ufs/util.h - 1.11 linux/fs/super.c - 1.97 linux/fs/proc/array.c - 1.58 linux/fs/nfsd/nfsctl.c - 1.39 linux/fs/nfsd/export.c - 1.49 linux/fs/inode.c - 1.91 linux/fs/filesystems.c - 1.26 linux/fs/ext2/ialloc.c - 1.35 linux/fs/ext2/dir.c - 1.27 linux/fs/dcache.c - 1.47 linux/fs/buffer.c - 1.150 linux/drivers/video/virgefb.c - 1.20 linux/drivers/video/tcxfb.c - 1.11 linux/drivers/video/sbusfb.c - 1.26 linux/drivers/video/retz3fb.c - 1.21 linux/drivers/video/macfb.c - 1.18 linux/drivers/video/fbmem.c - 1.59 linux/drivers/video/creatorfb.c - 1.17 linux/drivers/video/controlfb.c - 1.27 linux/drivers/video/cgthreefb.c - 1.13 linux/drivers/video/cgsixfb.c - 1.16 linux/drivers/video/cgfourteenfb.c - 1.15 linux/drivers/video/bwtwofb.c - 1.13 linux/drivers/video/amifb.c - 1.27 linux/drivers/video/Makefile - 1.51 linux/drivers/scsi/wd33c93.c - 1.12 linux/drivers/scsi/sym53c8xx.c - 1.41 linux/drivers/scsi/sym53c416.c - 1.17 linux/drivers/scsi/st.c - 1.63 linux/drivers/scsi/sr.c - 1.62 linux/drivers/scsi/sgiwd93.c - 1.16 linux/drivers/scsi/seagate.c - 1.24 linux/drivers/scsi/sd.c - 1.83 linux/drivers/scsi/scsi_syms.c - 1.29 linux/drivers/scsi/scsi_proc.c - 1.16 linux/drivers/scsi/scsi_ioctl.c - 1.28 linux/drivers/scsi/scsi.h - 1.45 linux/drivers/scsi/scsi.c - 1.71 linux/drivers/scsi/qlogicpti.c - 1.26 linux/drivers/scsi/qlogicfc.c - 1.35 linux/drivers/scsi/ncr53c8xx.c - 1.32 linux/drivers/scsi/megaraid.c - 1.44 linux/drivers/scsi/mac_NCR5380.c - 1.8 linux/drivers/scsi/ibmmca.c - 1.23 linux/drivers/scsi/hosts.c - 1.42 linux/drivers/scsi/gdth.h - 1.13 linux/drivers/scsi/gdth.c - 1.26 linux/drivers/scsi/g_NCR5380.c - 1.21 linux/drivers/scsi/fdomain.c - 1.29 linux/drivers/scsi/esp.c - 1.32 linux/drivers/scsi/atari_NCR5380.c - 1.9 linux/drivers/scsi/aha1542.c - 1.33 linux/drivers/scsi/aha152x.c - 1.37 linux/drivers/scsi/NCR53c406a.c - 1.19 linux/drivers/scsi/NCR53C9x.c - 1.23 linux/drivers/scsi/NCR5380.c - 1.18 linux/drivers/scsi/Makefile - 1.50 linux/drivers/scsi/FlashPoint.c - 1.4 linux/drivers/scsi/AM53C974.c - 1.19 linux/drivers/sbus/char/envctrl.c - 1.20 linux/drivers/net/via-rhine.c - 1.41 linux/drivers/net/tlan.c - 1.32 linux/drivers/net/sunlance.c - 1.31 linux/drivers/net/sunhme.h - 1.14 linux/drivers/net/sunhme.c - 1.41 linux/drivers/net/smc-ultra.c - 1.27 linux/drivers/net/slhc.c - 1.15 linux/drivers/net/ne.c - 1.25 linux/drivers/net/irda/actisys.c - 1.14 linux/drivers/net/hp100.c - 1.27 linux/drivers/net/eth16i.c - 1.24 linux/drivers/net/eepro100.c - 1.56 linux/drivers/net/e2100.c - 1.19 linux/drivers/net/dgrs.c - 1.23 linux/drivers/net/cs89x0.c - 1.28 linux/drivers/net/atp.c - 1.23 linux/drivers/net/acenic.c - 1.44 linux/drivers/net/8390.c - 1.28 linux/drivers/net/3c527.c - 1.23 linux/drivers/net/3c515.c - 1.28 linux/drivers/net/3c509.c - 1.43 linux/drivers/net/3c503.c - 1.25 linux/drivers/net/3c501.c - 1.25 linux/drivers/macintosh/via-pmu.c - 1.24 linux/drivers/isdn/hisax/teles3.c - 1.19 linux/drivers/isdn/hisax/sedlbauer.c - 1.23 linux/drivers/isdn/hisax/rawhdlc.c - 1.8 linux/drivers/isdn/hisax/niccy.c - 1.21 linux/drivers/isdn/hisax/l3dss1.c - 1.19 linux/drivers/isdn/hisax/ix1_micro.c - 1.16 linux/drivers/isdn/hisax/elsa.c - 1.24 linux/drivers/isdn/hisax/diva.c - 1.20 linux/drivers/isdn/hisax/asuscom.c - 1.19 linux/drivers/char/vt.c - 1.33 linux/drivers/char/tty_io.c - 1.64 linux/drivers/char/synclink.c - 1.35 linux/drivers/char/rocket_int.h - 1.5 linux/drivers/char/nvram.c - 1.28 linux/drivers/char/n_hdlc.c - 1.19 linux/drivers/char/ftape/zftape/zftape-write.c - 1.6 linux/drivers/char/ftape/zftape/zftape-vtbl.h - 1.5 linux/drivers/char/ftape/lowlevel/ftape_syms.c - 1.5 linux/drivers/char/ftape/lowlevel/ftape-calibr.c - 1.6 linux/drivers/char/epca.c - 1.26 linux/drivers/char/cyclades.c - 1.28 linux/drivers/char/cd1865.h - 1.4 linux/drivers/char/Makefile - 1.82 linux/drivers/cdrom/sbpcd.c - 1.35 linux/drivers/cdrom/cdrom.c - 1.53 linux/drivers/block/loop.c - 1.79 linux/drivers/block/ll_rw_blk.c - 1.128 linux/drivers/block/genhd.c - 1.48 linux/drivers/acorn/net/ether3.c - 1.17 linux/drivers/acorn/block/mfmhd.c - 1.37 linux/drivers/acorn/block/fd1772.c - 1.33 linux/arch/sparc64/solaris/entry64.S - 1.6 linux/arch/sparc64/prom/misc.c - 1.15 linux/arch/sparc64/prom/Makefile - 1.15 linux/arch/sparc64/mm/Makefile - 1.13 linux/arch/sparc64/lib/Makefile - 1.16 linux/arch/sparc64/kernel/traps.c - 1.26 linux/arch/sparc64/kernel/time.c - 1.30 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.53 linux/arch/sparc64/kernel/setup.c - 1.38 linux/arch/sparc64/kernel/ioctl32.c - 1.68 linux/arch/sparc64/kernel/init_task.c - 1.11 linux/arch/sparc64/kernel/Makefile - 1.31 linux/arch/sparc64/defconfig - 1.87 linux/arch/sparc/mm/sun4c.c - 1.42 linux/arch/sparc/mm/srmmu.c - 1.43 linux/arch/sparc/mm/iommu.c - 1.15 linux/arch/sparc/lib/checksum.S - 1.3 linux/arch/sparc/lib/blockops.S - 1.3 linux/arch/sparc/kernel/time.c - 1.25 linux/arch/sparc/kernel/ioport.c - 1.25 linux/arch/sparc/kernel/init_task.c - 1.10 linux/arch/ppc/kernel/time.c - 1.25 linux/arch/mips/kernel/traps.c - 1.13 linux/arch/mips/kernel/time.c - 1.16 linux/arch/mips/kernel/setup.c - 1.15 linux/arch/mips/kernel/r4k_switch.S - 1.9 linux/arch/mips/kernel/r4k_misc.S - 1.9 linux/arch/mips/kernel/r2300_switch.S - 1.9 linux/arch/mips/kernel/r2300_misc.S - 1.6 linux/arch/mips/kernel/process.c - 1.16 linux/arch/mips/kernel/pci.c - 1.11 linux/arch/mips/kernel/irq.c - 1.15 linux/arch/m68k/q40/README - 1.7 linux/arch/m68k/kernel/time.c - 1.9 linux/arch/m68k/kernel/head.S - 1.12 linux/arch/i386/mm/ioremap.c - 1.20 linux/arch/i386/mm/Makefile - 1.14 linux/arch/i386/kernel/time.c - 1.36 linux/arch/i386/kernel/smp.c - 1.55 linux/arch/i386/kernel/setup.c - 1.89 linux/arch/i386/kernel/ldt.c - 1.17 linux/arch/i386/kernel/irq.c - 1.54 linux/arch/i386/kernel/io_apic.c - 1.55 linux/arch/i386/kernel/i386_ksyms.c - 1.67 linux/arch/i386/kernel/entry.S - 1.75 linux/arch/i386/kernel/apm.c - 1.59 linux/arch/i386/kernel/Makefile - 1.46 linux/arch/i386/boot/bootsect.S - 1.17 linux/arch/arm/kernel/time.c - 1.23 linux/arch/arm/kernel/ptrace.c - 1.26 linux/arch/arm/kernel/entry-armv.S - 1.39 linux/arch/arm/kernel/entry-armo.S - 1.17 linux/arch/alpha/lib/checksum.c - 1.4 linux/arch/alpha/kernel/traps.c - 1.29 linux/arch/alpha/kernel/time.c - 1.28 linux/arch/alpha/kernel/smp.c - 1.43 linux/arch/alpha/kernel/process.c - 1.34 linux/arch/alpha/kernel/entry.S - 1.36 linux/arch/alpha/boot/tools/objstrip.c - 1.5 linux/Makefile - 1.241 linux/MAINTAINERS - 1.134 linux/Documentation/ioctl-number.txt - 1.21 linux/Documentation/filesystems/vfs.txt - 1.8 linux/Documentation/filesystems/hpfs.txt - 1.5 linux/Documentation/00-INDEX - 1.16 linux/net/decnet/dn_dev.c - 1.17 linux/include/net/dn_dev.h - 1.6 linux/fs/hpfs/dnode.c - 1.8 linux/drivers/video/cyber2000fb.c - 1.37 linux/drivers/net/sk_mca.c - 1.16 linux/drivers/isdn/hisax/avm_pci.c - 1.20 linux/drivers/isdn/eicon/eicon_idi.c - 1.17 linux/Documentation/networking/decnet.txt - 1.11 linux/Documentation/kernel-parameters.txt - 1.22 linux/drivers/net/declance.c - 1.19 linux/arch/mips/dec/boot/decstation.c - 1.2 linux/arch/mips/baget/wbflush.c - 1.4 linux/drivers/block/cpqarray.c - 1.65 linux/drivers/parport/parport_pc.c - 1.54 linux/drivers/char/sx.c - 1.32 linux/drivers/char/generic_serial.c - 1.15 linux/Documentation/sx.txt - 1.3 linux/drivers/scsi/oktagon_esp.c - 1.12 linux/drivers/isdn/hisax/isurf.c - 1.16 linux/drivers/isdn/hisax/hfcscard.c - 1.13 linux/arch/m68k/math-emu/fp_util.S - 1.5 linux/drivers/net/sis900.c - 1.42 linux/drivers/net/sb1000.c - 1.21 linux/drivers/net/fc/tach_structs.h - 1.3 linux/drivers/net/fc/iph5526.c - 1.24 linux/drivers/atm/suni.c - 1.11 linux/drivers/atm/horizon.h - 1.5 linux/drivers/atm/horizon.c - 1.16 linux/net/core/netfilter.c - 1.20 linux/net/atm/lec.h - 1.8 linux/net/atm/lec.c - 1.18 linux/net/802/fc.c - 1.4 linux/include/linux/fcdevice.h - 1.3 linux/arch/alpha/kernel/pci.c - 1.30 linux/arch/sparc64/kernel/pci_common.c - 1.20 linux/arch/sh/kernel/time.c - 1.19 linux/arch/sh/kernel/irq.c - 1.17 linux/drivers/video/p9100fb.c - 1.7 linux/drivers/video/p9100.h - 1.3 linux/drivers/scsi/ips.c - 1.38 linux/include/linux/n_r3964.h - 1.4 linux/include/asm-sh/semaphore.h - 1.7 linux/drivers/pcmcia/i82365.c - 1.34 linux/drivers/pcmcia/cardbus.c - 1.27 linux/arch/m68k/sun3/config.c - 1.11 linux/fs/udf/dir.c - 1.23 linux/include/asm-m68k/swim_iop.h - 1.2 linux/include/asm-sparc64/pci.h - 1.14 linux/include/asm-sparc/pci.h - 1.13 linux/drivers/net/pcmcia/Makefile - 1.26 linux/include/linux/acpi.h - 1.35 linux/drivers/net/tokenring/olympic.c - 1.25 linux/arch/i386/lib/mmx.c - 1.10 linux/arch/i386/kernel/smpboot.c - 1.58 linux/include/linux/pci_ids.h - 1.85 linux/drivers/net/wan/z85230.c - 1.13 linux/drivers/net/wan/sealevel.c - 1.13 linux/drivers/net/wan/sdlamain.c - 1.15 linux/drivers/net/wan/sdla_x25.c - 1.16 linux/drivers/net/wan/sdla_ppp.c - 1.21 linux/drivers/net/wan/sdla_fr.c - 1.21 linux/drivers/net/wan/sbni.c - 1.21 linux/drivers/net/wan/hostess_sv11.c - 1.12 linux/drivers/net/wan/dlci.c - 1.11 linux/Documentation/vm/locking - 1.9 linux/include/asm-i386/pgtable-2level.h - 1.11 linux/fs/proc/proc_misc.c - 1.56 linux/drivers/scsi/sun3_scsi.c - 1.15 linux/drivers/net/sk98lin/skxmac2.c - 1.7 linux/drivers/net/sk98lin/skgepnmi.c - 1.6 linux/drivers/net/sk98lin/skgesirq.c - 1.6 linux/Documentation/networking/sk98lin.txt - 1.6 linux/drivers/net/sk98lin/h/lm80.h - 1.5 linux/drivers/net/sk98lin/h/skdrv1st.h - 1.8 linux/drivers/net/sk98lin/h/skdrv2nd.h - 1.5 linux/drivers/net/sk98lin/skvpd.c - 1.7 linux/drivers/net/sk98lin/skge.c - 1.23 linux/drivers/net/sk98lin/skgehwt.c - 1.4 linux/drivers/net/sk98lin/skqueue.c - 1.5 linux/drivers/net/sk98lin/ski2c.c - 1.5 linux/drivers/net/sk98lin/h/xmac_ii.h - 1.6 linux/drivers/net/sk98lin/skcsum.c - 1.5 linux/arch/ppc/mm/mem_pieces.h - 1.5 linux/arch/ppc/mm/mem_pieces.c - 1.8 linux/include/linux/agp_backend.h - 1.27 linux/drivers/net/pcmcia/aironet4500_cs.c - 1.18 linux/kernel/timer.c - 1.41 linux/drivers/char/agp/agp.h - 1.35 linux/drivers/i2c/i2c-dev.c - 1.25 linux/drivers/i2c/i2c-core.c - 1.22 linux/Documentation/video4linux/bttv/Sound-FAQ - 1.10 linux/arch/sparc64/kernel/sbus.c - 1.19 linux/arch/sparc64/kernel/iommu_common.h - 1.6 linux/include/linux/telephony.h - 1.9 linux/drivers/telephony/ixj.c - 1.27 linux/drivers/net/tokenring/smctr.c - 1.19 linux/net/sched/sch_gred.c - 1.13 linux/drivers/ieee1394/raw1394.c - 1.25 linux/drivers/ieee1394/ieee1394_core.c - 1.28 linux/drivers/ieee1394/ohci1394.h - 1.19 linux/drivers/ieee1394/ohci1394.c - 1.29 linux/drivers/ieee1394/ieee1394_types.h - 1.18 linux/drivers/ieee1394/ieee1394_transactions.h - 1.7 linux/drivers/ieee1394/ieee1394_transactions.c - 1.14 linux/arch/i386/kernel/apic.c - 1.41 linux/drivers/ieee1394/hosts.c - 1.18 linux/arch/i386/kernel/mpparse.c - 1.35 linux/drivers/ieee1394/Makefile - 1.20 linux/drivers/scsi/scsi_scan.c - 1.41 linux/drivers/net/wan/sdla_chdlc.c - 1.21 linux/drivers/net/tokenring/madgemc.c - 1.9 linux/drivers/char/scc.h - 1.2 linux/drivers/atm/iphase.h - 1.4 linux/drivers/atm/iphase.c - 1.18 linux/arch/ia64/ia32/ia32_signal.c - 1.13 linux/arch/alpha/kernel/pci_iommu.c - 1.22 linux/arch/ia64/kernel/irq.c - 1.26 linux/arch/ia64/kernel/smp.c - 1.21 linux/arch/ia64/kernel/time.c - 1.19 linux/arch/ia64/lib/checksum.c - 1.4 linux/arch/ia64/lib/do_csum.S - 1.8 linux/arch/ia64/kernel/perfmon.c - 1.21 linux/fs/adfs/dir_f.c - 1.11 linux/kernel/pm.c - 1.14 linux/include/asm-ia64/page.h - 1.20 linux/drivers/scsi/sun3_NCR5380.c - 1.9 linux/drivers/isdn/hisax/hfc_sx.c - 1.18 linux/arch/i386/kernel/microcode.c - 1.22 linux/drivers/scsi/pcmcia/fdomain_stub.c - 1.12 linux/fs/devfs/base.c - 1.52 linux/drivers/isdn/hysdn/hysdn_boot.c - 1.8 linux/drivers/net/skfp/hwt.c - 1.2 linux/drivers/net/skfp/h/smc.h - 1.3 linux/drivers/net/tulip/tulip_core.c - 1.45 linux/drivers/net/tulip/interrupt.c - 1.19 linux/drivers/char/nwflash.c - 1.17 linux/include/asm-mips64/sn/klconfig.h - 1.5 linux/include/asm-mips64/processor.h - 1.14 linux/include/asm-mips64/pgtable.h - 1.17 linux/include/asm-mips64/pci.h - 1.10 linux/include/asm-mips64/mipsregs.h - 1.8 linux/drivers/atm/fore200e.c - 1.18 linux/arch/mips64/kernel/traps.c - 1.8 linux/arch/mips64/sgi-ip27/ip27-pci-dma.c - 1.5 linux/arch/mips64/kernel/r4k_switch.S - 1.4 linux/arch/mips64/kernel/process.c - 1.10 linux/include/asm-sh/pci.h - 1.14 linux/arch/sh/kernel/fpu.c - 1.6 linux/include/linux/usb.h - 1.56 linux/drivers/usb/serial/usb-serial.h - 1.29 linux/drivers/ide/ide-dma.c - 1.36 linux/drivers/ide/ide-cd.c - 1.58 linux/Documentation/DocBook/Makefile - 1.41 linux/drivers/net/tokenring/lanstreamer.c - 1.15 linux/Documentation/DocBook/kernel-api.tmpl - 1.26 linux/net/ipv4/netfilter/ipt_state.c - 1.5 linux/net/ipv4/netfilter/ipfwadm_core.c - 1.14 linux/net/ipv4/netfilter/ipchains_core.c - 1.14 linux/net/ipv4/netfilter/ip_tables.c - 1.17 linux/net/ipv4/netfilter/ip_nat_standalone.c - 1.20 linux/net/ipv4/netfilter/ip_nat_core.c - 1.18 linux/net/ipv4/netfilter/ip_conntrack_standalone.c - 1.18 linux/net/ipv4/netfilter/ip_conntrack_proto_udp.c - 1.8 linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c - 1.12 linux/net/ipv4/netfilter/ip_conntrack_ftp.c - 1.12 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.19 linux/include/linux/netfilter_ipv4/ip_conntrack.h - 1.13 linux/Documentation/DocBook/parportbook.tmpl - 1.10 linux/drivers/video/sa1100fb.c - 1.21 linux/drivers/usb/serial/visor.c - 1.50 linux/arch/ia64/kernel/minstate.h - 1.10 linux/drivers/net/wan/lmc/lmc_main.c - 1.14 linux/drivers/net/pppoe.c - 1.26 linux/drivers/char/rio/riotty.c - 1.7 linux/drivers/char/rio/riotable.c - 1.7 linux/drivers/char/rio/rioroute.c - 1.6 linux/drivers/char/rio/list.h - 1.2 linux/drivers/char/rio/rioparam.c - 1.4 linux/drivers/char/rio/rioinit.c - 1.6 linux/drivers/char/rio/parmmap.h - 1.2 linux/drivers/char/rio/rio_linux.c - 1.19 linux/include/asm-s390/types.h - 1.5 linux/drivers/s390/net/iucv.h - 1.6 linux/drivers/s390/char/con3215.c - 1.12 linux/drivers/s390/block/dasd_eckd.c - 1.15 linux/drivers/s390/block/dasd.c - 1.38 linux/include/asm-s390/processor.h - 1.13 linux/arch/s390/kernel/time.c - 1.11 linux/arch/s390/kernel/smp.c - 1.19 linux/net/ipv6/netfilter/ip6_tables.c - 1.16 linux/net/ipv6/netfilter/Makefile - 1.14 linux/arch/mips64/kernel/smp.c - 1.11 linux/arch/mips64/sgi-ip27/ip27-nmi.c - 1.4 linux/drivers/char/drm/i810_drm.h - 1.5 linux/drivers/usb/serial/keyspan.h - 1.16 linux/drivers/usb/serial/keyspan.c - 1.40 linux/drivers/acpi/tables.c - 1.10 linux/drivers/acpi/resources/rsxface.c - 1.14 linux/drivers/acpi/resources/rsutils.c - 1.16 linux/drivers/acpi/resources/rsmemory.c - 1.13 linux/drivers/acpi/hardware/hwregs.c - 1.19 linux/drivers/acpi/hardware/hwgpe.c - 1.16 linux/drivers/acpi/events/evxfevnt.c - 1.16 linux/drivers/acpi/events/evxface.c - 1.19 linux/drivers/acpi/events/evsci.c - 1.14 linux/drivers/acpi/events/evrgnini.c - 1.17 linux/drivers/acpi/events/evmisc.c - 1.18 linux/drivers/acpi/events/evevent.c - 1.22 linux/drivers/acpi/ec.c - 1.18 linux/drivers/acpi/dispatcher/dsobject.c - 1.24 linux/drivers/ieee1394/video1394.c - 1.26 linux/drivers/mtd/ftl.c - 1.32 linux/drivers/mtd/mtdchar.c - 1.12 linux/drivers/usb/storage/freecom.c - 1.21 linux/drivers/media/video/zr36120_i2c.c - 1.2 linux/drivers/media/video/saa7110.c - 1.9 linux/drivers/media/radio/radio-terratec.c - 1.12 linux/drivers/media/radio/radio-sf16fmi.c - 1.17 linux/drivers/media/radio/radio-rtrack2.c - 1.12 linux/drivers/media/radio/radio-gemtek.c - 1.12 linux/drivers/media/radio/radio-aimslab.c - 1.12 linux/drivers/isdn/hysdn/hycapi.c - 1.13 linux/drivers/isdn/hisax/l3ni1.c - 1.12 linux/drivers/isdn/eicon/idi.c - 1.5 linux/drivers/isdn/eicon/adapter.h - 1.5 linux/drivers/acpi/events/Makefile - 1.8 linux/drivers/block/cciss.c - 1.52 linux/drivers/block/cciss_cmd.h - 1.10 linux/drivers/md/md.c - 1.70 linux/drivers/net/hamachi.c - 1.22 linux/drivers/scsi/cpqfcTScontrol.c - 1.9 linux/drivers/scsi/cpqfcTSinit.c - 1.27 linux/drivers/scsi/cpqfcTSworker.c - 1.15 linux/include/asm-ppc/uninorth.h - 1.7 linux/include/linux/cciss_ioctl.h - 1.4 linux/mm/oom_kill.c - 1.21 linux/drivers/usb/serial/belkin_sa.c - 1.28 linux/Documentation/networking/netdevices.txt - 1.3 linux/net/irda/irsyms.c - 1.12 linux/include/linux/ethtool.h - 1.14 linux/arch/sparc64/lib/U3memcpy.S - 1.3 linux/arch/sparc64/lib/U3copy_to_user.S - 1.3 linux/arch/sparc64/lib/U3copy_in_user.S - 1.3 linux/arch/sparc64/lib/U3copy_from_user.S - 1.4 linux/include/asm-parisc/mman.h - 1.4 linux/drivers/usb/serial/mct_u232.c - 1.29 linux/arch/parisc/mm/init.c - 1.7 linux/arch/parisc/kernel/time.c - 1.7 linux/arch/i386/kernel/dmi_scan.c - 1.25 linux/arch/parisc/kernel/ptrace.c - 1.8 linux/include/asm-parisc/assembly.h - 1.4 linux/arch/parisc/kernel/irq.c - 1.10 linux/arch/parisc/kernel/cache.c - 1.3 linux/drivers/acpi/tables/tbconvrt.c - 1.17 linux/drivers/atm/firestream.c - 1.14 linux/drivers/acpi/power.c - 1.14 linux/arch/m68k/ifpsp060/src/pfpsp.S - 1.6 linux/arch/m68k/ifpsp060/src/fpsp.S - 1.6 linux/arch/m68k/ifpsp060/src/isp.S - 1.5 linux/include/asm-ia64/sn/klconfig.h - 1.5 linux/include/asm-ia64/sn/sn_cpuid.h - 1.5 linux/arch/ia64/lib/swiotlb.c - 1.11 linux/arch/ia64/sn/io/hcl.c - 1.8 linux/arch/ia64/sn/io/l1.c - 1.7 linux/include/asm-ia64/sn/pci/pcibr_private.h - 1.6 linux/include/asm-ia64/sn/pci/bridge.h - 1.6 linux/fs/reiserfs/stree.c - 1.28 linux/fs/reiserfs/super.c - 1.33 linux/drivers/acpi/acpi_ksyms.c - 1.17 linux/drivers/acpi/hardware/hwsleep.c - 1.16 linux/drivers/acpi/hardware/hwtimer.c - 1.14 linux/fs/reiserfs/lbalance.c - 1.9 linux/fs/reiserfs/journal.c - 1.39 linux/fs/reiserfs/do_balan.c - 1.14 linux/drivers/usb/storage/unusual_devs.h - 1.17 linux/arch/s390x/kernel/time.c - 1.10 linux/arch/s390x/kernel/smp.c - 1.16 linux/include/asm-s390x/processor.h - 1.10 linux/Documentation/s390/TAPE - 1.3 linux/arch/alpha/kernel/pci-noop.c - 1.6 linux/arch/cris/drivers/ethernet.c - 1.11 linux/arch/cris/drivers/serial.c - 1.13 linux/arch/cris/kernel/kgdb.c - 1.6 linux/arch/cris/kernel/process.c - 1.14 linux/arch/cris/kernel/setup.c - 1.12 linux/arch/cris/kernel/signal.c - 1.11 linux/arch/cris/kernel/time.c - 1.9 linux/arch/cris/mm/fault.c - 1.9 linux/arch/cris/mm/tlb.c - 1.6 linux/arch/s390x/kernel/exec32.c - 1.6 linux/drivers/s390/block/dasd_fba.c - 1.11 linux/include/asm-s390x/types.h - 1.4 linux/drivers/s390/block/dasd_diag.c - 1.11 linux/drivers/s390/block/dasd_3990_erp.c - 1.12 linux/include/asm-cris/uaccess.h - 1.5 linux/include/asm-cris/processor.h - 1.12 linux/include/asm-cris/namei.h - 1.2 linux/drivers/scsi/aic7xxx_old.c - 1.29 linux/drivers/scsi/aic7xxx/aic7xxx_osm.h - 1.13 linux/drivers/scsi/aic7xxx/aic7xxx.h - 1.8 linux/drivers/net/wan/dscc4.c - 1.17 linux/drivers/net/sungem.h - 1.9 linux/drivers/net/sungem.c - 1.25 linux/drivers/net/wan/wanpipe_multppp.c - 1.9 linux/Documentation/DocBook/deviceiobook.tmpl - 1.3 linux/net/wanrouter/af_wanpipe.c - 1.13 linux/Documentation/s390/s390dbf.txt - 1.4 linux/include/asm-i386/rwsem.h - 1.8 linux/arch/mips/mips-boards/generic/pci.c - 1.5 linux/net/ipv4/netfilter/ip_nat_helper.c - 1.9 linux/arch/mips/math-emu/sp_sub.c - 1.2 linux/arch/mips/math-emu/sp_mul.c - 1.2 linux/arch/cris/boot/rescue/head.S - 1.6 linux/arch/mips/math-emu/sp_fdp.c - 1.2 linux/arch/mips/math-emu/sp_div.c - 1.2 linux/arch/mips/math-emu/sp_add.c - 1.2 linux/arch/mips/math-emu/ieee754sp.c - 1.2 linux/arch/mips/math-emu/ieee754dp.c - 1.2 linux/arch/mips/math-emu/ieee754.c - 1.2 linux/arch/mips/math-emu/dp_sub.c - 1.3 linux/arch/mips/math-emu/dp_mul.c - 1.2 linux/arch/mips/math-emu/dp_div.c - 1.2 linux/arch/mips/math-emu/dp_add.c - 1.2 linux/include/asm-sparc64/rwsem.h - 1.5 linux/include/linux/rwsem-spinlock.h - 1.4 linux/drivers/net/irda/irda-usb.c - 1.30 linux/drivers/net/wireless/orinoco.c - 1.16 linux/drivers/net/wireless/todo.txt - 1.3 linux/arch/cris/drivers/eeprom.c - 1.10 linux/drivers/mtd/nftlcore.c - 1.29 linux/drivers/mtd/nand/spia.c - 1.6 linux/drivers/mtd/maps/vmax301.c - 1.3 linux/drivers/mtd/maps/sun_uflash.c - 1.3 linux/drivers/mtd/maps/sc520cdp.c - 1.3 linux/drivers/mtd/maps/sbc_gxx.c - 1.4 linux/drivers/mtd/maps/sa1100-flash.c - 1.7 linux/drivers/mtd/maps/rpxlite.c - 1.3 linux/drivers/mtd/maps/pnc2000.c - 1.3 linux/drivers/mtd/maps/physmap.c - 1.3 linux/drivers/mtd/maps/octagon-5066.c - 1.3 linux/drivers/mtd/maps/ocelot.c - 1.3 linux/drivers/mtd/maps/nora.c - 1.3 linux/drivers/mtd/maps/netsc520.c - 1.3 linux/drivers/mtd/maps/iq80310.c - 1.4 linux/drivers/mtd/maps/elan-104nc.c - 1.5 linux/drivers/mtd/maps/dc21285.c - 1.4 linux/drivers/mtd/maps/dbox2-flash.c - 1.3 linux/drivers/mtd/maps/cstm_mips_ixx.c - 1.3 linux/drivers/mtd/maps/cfi_flagadm.c - 1.3 linux/drivers/mtd/devices/pmc551.c - 1.5 linux/drivers/mtd/chips/sharp.c - 1.4 linux/drivers/mtd/chips/map_rom.c - 1.3 linux/drivers/mtd/chips/map_ram.c - 1.3 linux/drivers/mtd/chips/jedec.c - 1.7 linux/drivers/mtd/chips/cfi_probe.c - 1.3 linux/drivers/mtd/chips/cfi_cmdset_0002.c - 1.4 linux/drivers/mtd/chips/cfi_cmdset_0001.c - 1.3 linux/drivers/mtd/chips/amd_flash.c - 1.5 linux/drivers/media/radio/miropcm20-rds-core.c - 1.5 linux/drivers/media/radio/miropcm20-radio.c - 1.8 linux/drivers/acpi/utilities/utglobal.c - 1.19 linux/drivers/acpi/utilities/utcopy.c - 1.17 linux/drivers/net/wireless/airo.c - 1.26 linux/arch/sh/stboards/pcidma.c - 1.2 linux/drivers/usb/serial/pl2303.c - 1.28 linux/arch/sh/kernel/pci-sh7751.c - 1.6 linux/arch/sh/kernel/pci-dma.c - 1.3 linux/arch/mips64/math-emu/sp_sub.c - 1.2 linux/arch/mips64/math-emu/sp_mul.c - 1.2 linux/arch/mips64/math-emu/sp_fdp.c - 1.2 linux/drivers/isdn/tpam/tpam_commands.c - 1.7 linux/arch/mips64/math-emu/sp_div.c - 1.2 linux/arch/mips64/math-emu/sp_add.c - 1.2 linux/arch/mips64/math-emu/ieee754sp.c - 1.2 linux/arch/mips64/math-emu/ieee754dp.c - 1.2 linux/arch/mips64/math-emu/dp_sub.c - 1.2 linux/arch/mips64/math-emu/dp_mul.c - 1.2 linux/arch/mips64/math-emu/dp_add.c - 1.2 linux/arch/mips64/math-emu/dp_div.c - 1.2 linux/drivers/scsi/pcmcia/nsp_cs.c - 1.16 linux/drivers/scsi/pcmcia/nsp_cs.h - 1.9 linux/arch/cris/drivers/lpslave/e100lpslavenet.c - 1.6 linux/drivers/media/video/zr36067.c - 1.12 linux/drivers/usb/usb-skeleton.c - 1.21 linux/drivers/char/ser_a2232.c - 1.7 linux/include/asm-alpha/rwsem.h - 1.5 linux/drivers/video/pvr2fb.c - 1.8 linux/drivers/message/fusion/mptscsih.c - 1.17 linux/drivers/message/fusion/mptlan.c - 1.10 linux/drivers/ieee1394/sbp2.c - 1.20 linux/drivers/ieee1394/sbp2.h - 1.13 linux/drivers/ieee1394/nodemgr.c - 1.15 linux/drivers/char/drm/drm_vm.h - 1.16 linux/include/asm-arm/arch-sa1100/simpad.h - 1.3 linux/include/net/irda/vlsi_ir.h - 1.5 linux/arch/arm/mach-sa1100/irq.c - 1.11 linux/arch/ppc/kernel/temp.c - 1.4 linux/arch/ppc/kernel/l2cr.S - 1.6 linux/drivers/video/sstfb.c - 1.13 linux/drivers/scsi/dpt_i2o.c - 1.21 linux/arch/mips/au1000/common/serial.c - 1.8 linux/arch/mips64/mips-boards/generic/pci.c - 1.3 linux/arch/mips/ddb5xxx/common/pci.c - 1.4 linux/drivers/i2c/i2c-adap-ite.c - 1.8 linux/drivers/i2c/i2c-algo-ite.c - 1.5 linux/include/asm-mips/ddb5xxx/ddb5xxx.h - 1.2 linux/Documentation/input/joystick-api.txt - 1.2 linux/fs/jffs2/compr_rtime.c - 1.4 linux/scripts/mkspec - 1.4 linux/arch/i386/kernel/nmi.c - 1.13 linux/drivers/char/mwave/tp3780i.h - 1.2 linux/drivers/mtd/maps/l440gx.c - 1.2 linux/drivers/mtd/devices/blkmtd.c - 1.21 linux/drivers/mtd/maps/integrator-flash.c - 1.3 linux/drivers/mtd/chips/map_absent.c - 1.2 linux/drivers/mtd/chips/jedec_probe.c - 1.4 linux/drivers/mtd/maps/cdb89712.c - 1.2 linux/drivers/mtd/maps/tqm8xxl.c - 1.2 linux/fs/namespace.c - 1.27 linux/drivers/mtd/maps/solutionengine.c - 1.2 linux/drivers/pcmcia/sa1100_graphicsclient.c - 1.4 linux/drivers/pcmcia/sa1100_generic.c - 1.14 linux/drivers/pcmcia/sa1100_freebird.c - 1.4 linux/drivers/pcmcia/sa1100_flexanet.c - 1.4 linux/drivers/pcmcia/sa1100_cerf.c - 1.5 linux/drivers/pcmcia/sa1100_assabet.c - 1.7 linux/drivers/pcmcia/sa1100_adsbitsy.c - 1.5 linux/drivers/pcmcia/sa1100.h - 1.5 linux/drivers/pcmcia/sa1100_graphicsmaster.c - 1.5 linux/drivers/pcmcia/sa1100_h3600.c - 1.4 linux/drivers/pcmcia/sa1100_jornada720.c - 1.6 linux/drivers/pcmcia/sa1100_neponset.c - 1.7 linux/drivers/pcmcia/sa1100_pangolin.c - 1.4 linux/drivers/pcmcia/sa1100_pfs168.c - 1.5 linux/drivers/pcmcia/sa1100_simpad.c - 1.5 linux/drivers/pcmcia/sa1100_stork.c - 1.5 linux/drivers/pcmcia/sa1100_xp860.c - 1.5 linux/drivers/pcmcia/sa1100_yopy.c - 1.4 linux/drivers/i2c/i2c-proc.c - 1.11 linux/include/linux/i2c-proc.h - 1.5 linux/drivers/message/i2o/i2o_core.c - 1.10 linux/drivers/message/i2o/i2o_block.c - 1.30 linux/drivers/atm/lanai.c - 1.7 linux/net/ipv4/netfilter/ip_nat_irc.c - 1.4 linux/net/ipv4/netfilter/ip_conntrack_irc.c - 1.6 linux/net/8021q/vlan.h - 1.4 linux/Documentation/networking/ifenslave.c - 1.4 linux/drivers/scsi/sym53c8xx_2/sym_conf.h - 1.2 linux/drivers/scsi/sym53c8xx_2/sym_fw.c - 1.2 linux/drivers/scsi/sym53c8xx_2/sym_fw1.h - 1.3 linux/drivers/scsi/sym53c8xx_2/sym_fw2.h - 1.3 linux/drivers/scsi/sym53c8xx_2/sym_glue.c - 1.13 linux/drivers/scsi/sym53c8xx_2/sym_hipd.c - 1.6 linux/fs/ext3/file.c - 1.9 linux/fs/ext3/namei.c - 1.18 linux/drivers/hotplug/pci_hotplug_core.c - 1.18 linux/drivers/hotplug/cpqphp_proc.c - 1.7 linux/drivers/hotplug/cpqphp_pci.c - 1.9 linux/drivers/hotplug/cpqphp_core.c - 1.12 linux/drivers/hotplug/cpqphp.h - 1.5 linux/drivers/hotplug/Makefile - 1.9 linux/fs/intermezzo/super.c - 1.10 linux/fs/jbd/revoke.c - 1.10 linux/fs/seq_file.c - 1.7 linux/fs/ext3/dir.c - 1.8 linux/drivers/net/pcmcia/axnet_cs.c - 1.8 linux/fs/bio.c - 1.27 linux/include/linux/device.h - 1.28 linux/init/do_mounts.c - 1.25 linux/include/linux/gfp.h - 1.10 linux/drivers/usb/serial/ipaq.c - 1.20 linux/drivers/usb/serial/ipaq.h - 1.7 linux/drivers/usb/serial/kl5kusb105.c - 1.18 linux/arch/arm/mach-iop310/iop310-pci.c - 1.9 linux/arch/arm/mach-iop310/mm.c - 1.4 linux/arch/arm/kernel/head.S - 1.8 linux/drivers/block/cciss_scsi.c - 1.10 linux/lib/crc32.c - 1.7 linux/drivers/ieee1394/dv1394-private.h - 1.7 linux/drivers/ieee1394/dv1394.c - 1.12 linux/include/net/iw_handler.h - 1.5 linux/drivers/net/wireless/wavelan_cs.h - 1.2 linux/drivers/base/core.c - 1.23 linux/drivers/base/Makefile - 1.12 linux/include/linux/pnpbios.h - 1.8 linux/sound/sound_core.c - 1.7 linux/arch/ppc/4xx_io/serial_sicc.c - 1.4 linux/sound/pci/es1968.c - 1.14 linux/sound/pci/ens1370.c - 1.17 linux/arch/ppc/8xx_io/cs4218_tdm.c - 1.5 linux/sound/pci/cs46xx/cs46xx_lib.c - 1.13 linux/sound/pci/ali5451/ali5451.c - 1.16 linux/sound/oss/wavfront.c - 1.4 linux/sound/oss/trident.h - 1.4 linux/sound/oss/trident.c - 1.11 linux/sound/oss/rme96xx.c - 1.8 linux/sound/oss/opl3sa2.c - 1.8 linux/sound/oss/nec_vrc5477.c - 1.5 linux/sound/oss/maestro3.c - 1.7 linux/sound/oss/maestro.c - 1.8 linux/sound/oss/ite8172.c - 1.5 linux/sound/oss/es1371.c - 1.9 linux/sound/oss/dmasound/dmasound_core.c - 1.4 linux/sound/oss/dmasound/dmasound_awacs.c - 1.5 linux/arch/ppc/platforms/pmac_feature.c - 1.5 linux/sound/oss/cs46xx.c - 1.7 linux/sound/oss/cs4232.c - 1.6 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.15 linux/arch/x86_64/kernel/apic.c - 1.12 linux/arch/x86_64/kernel/bluesmoke.c - 1.7 linux/arch/x86_64/kernel/io_apic.c - 1.6 linux/arch/x86_64/kernel/irq.c - 1.8 linux/arch/x86_64/kernel/ldt.c - 1.7 linux/arch/x86_64/kernel/nmi.c - 1.9 linux/arch/x86_64/kernel/smp.c - 1.12 linux/arch/x86_64/kernel/smpboot.c - 1.13 linux/arch/x86_64/kernel/time.c - 1.10 linux/arch/x86_64/mm/ioremap.c - 1.8 linux/sound/oss/awe_wave.c - 1.4 linux/sound/oss/ad1848.c - 1.10 linux/sound/oss/ad1816.c - 1.4 linux/sound/isa/wavefront/wavefront_synth.c - 1.9 linux/sound/isa/wavefront/wavefront_fx.c - 1.7 linux/sound/isa/opl3sa2.c - 1.13 linux/sound/drivers/mtpav.c - 1.13 linux/sound/core/seq/seq_timer.c - 1.8 linux/sound/core/seq/seq_midi_emul.c - 1.6 linux/sound/core/device.c - 1.10 linux/include/asm-x86_64/semaphore.h - 1.4 linux/include/asm-x86_64/rwsem.h - 1.6 linux/include/sound/wavefront.h - 1.3 linux/include/asm-alpha/thread_info.h - 1.5 linux/include/asm-x86_64/uaccess.h - 1.6 linux/arch/ppc64/boot/addRamDisk.c - 1.3 linux/arch/ppc64/boot/addSystemMap.c - 1.3 linux/arch/ppc64/kernel/head.S - 1.11 linux/arch/ppc64/kernel/ioctl32.c - 1.17 linux/arch/ppc64/kernel/lmb.c - 1.5 linux/arch/ppc64/kernel/pSeries_lpar.c - 1.10 linux/arch/ppc64/kernel/pci_dn.c - 1.7 linux/arch/ppc64/kernel/ras.c - 1.3 linux/arch/ppc64/kernel/smp.c - 1.16 linux/arch/ppc64/kernel/time.c - 1.14 linux/arch/ppc64/xmon/xmon.c - 1.10 linux/include/asm-ppc64/uaccess.h - 1.6 linux/include/asm-ppc64/pgtable.h - 1.10 linux/include/asm-ppc64/page.h - 1.12 linux/drivers/hotplug/ibmphp_res.c - 1.5 linux/drivers/hotplug/ibmphp_hpc.c - 1.7 linux/drivers/hotplug/ibmphp_core.c - 1.11 linux/drivers/hotplug/ibmphp.h - 1.4 linux/fs/jfs/jfs_dmap.c - 1.12 linux/fs/quota_v2.c - 1.10 linux/drivers/net/tg3.h - 1.14 linux/drivers/net/tg3.c - 1.17 linux/drivers/pcmcia/sa1111_generic.h - 1.2 linux/drivers/pcmcia/sa1111_generic.c - 1.7 linux/drivers/pcmcia/sa1100_system3.c - 1.4 linux/drivers/pcmcia/sa1100_shannon.c - 1.3 linux/drivers/net/tulip/winbond-840.c - 1.9 linux/drivers/pcmcia/sa1100_generic.h - 1.4 linux/drivers/pcmcia/sa1100_badge4.c - 1.6 linux/drivers/net/tulip/xircom_cb.c - 1.6 linux/drivers/net/tulip/xircom_tulip_cb.c - 1.4 linux/drivers/net/e100/e100.h - 1.13 linux/drivers/net/e100/e100_config.c - 1.8 linux/drivers/net/e100/e100_eeprom.c - 1.5 linux/drivers/net/e100/e100_main.c - 1.15 linux/Documentation/sound/oss/Wavefront - 1.2 linux/arch/ia64/sn/fakeprom/fpmem.c - 1.4 linux/arch/ia64/sn/kernel/sn2/sn2_smp.c - 1.3 linux/arch/ia64/sn/kernel/sn1/sn1_smp.c - 1.4 linux/kernel/futex.c - 1.15 linux/arch/ia64/sn/kernel/setup.c - 1.6 linux/include/asm-ia64/sn/sn2/shub_mmr.h - 1.2 linux/include/asm-ia64/sn/sn2/mmzone_sn2.h - 1.3 linux/include/asm-ia64/sn/sn1/mmzone_sn1.h - 1.3 linux/include/asm-ia64/sn/pda.h - 1.3 linux/arch/ia64/sn/kernel/llsc4.c - 1.6 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_slot.c - 1.3 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_intr.c - 1.3 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_error.c - 1.4 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c - 1.6 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_ate.c - 1.3 linux/arch/ia64/sn/fakeprom/fw-emu.c - 1.4 linux/arch/ia64/sn/io/sn1/pcibr.c - 1.6 linux/net/ipv4/netfilter/arp_tables.c - 1.3 linux/drivers/net/wan/comx-hw-munich.c - 1.8 linux/drivers/ieee1394/eth1394.c - 1.6 linux/drivers/net/sb1250-mac.c - 1.3 linux/drivers/usb/image/microtek.c - 1.9 linux/drivers/usb/class/bluetty.c - 1.15 linux/drivers/usb/core/hcd.h - 1.14 linux/drivers/usb/core/hub.c - 1.20 linux/include/asm-arm/arch-pxa/time.h - 1.3 linux/include/asm-arm/arch-pxa/system.h - 1.3 linux/include/asm-arm/arch-pxa/pxa-regs.h - 1.5 linux/include/asm-arm/arch-pxa/lubbock.h - 1.2 linux/drivers/usb/input/hid-core.c - 1.15 linux/include/asm-arm/arch-pxa/irqs.h - 1.2 linux/include/asm-arm/arch-pxa/hardware.h - 1.3 linux/drivers/usb/media/konicawc.c - 1.10 linux/drivers/usb/host/ehci-dbg.c - 1.13 linux/arch/arm/mach-pxa/Makefile - 1.7 linux/arch/arm/mach-pxa/generic.c - 1.5 linux/arch/arm/mach-pxa/irq.c - 1.5 linux/arch/arm/mach-pxa/leds.c - 1.2 linux/arch/arm/mach-pxa/lubbock.c - 1.7 linux/drivers/usb/host/ehci-hcd.c - 1.18 linux/drivers/usb/host/ehci-q.c - 1.17 linux/drivers/usb/host/ehci-sched.c - 1.13 linux/drivers/usb/host/ehci.h - 1.11 linux/drivers/usb/host/ohci-dbg.c - 1.13 linux/drivers/usb/host/ohci-hcd.c - 1.18 linux/drivers/usb/host/ohci-hub.c - 1.8 linux/drivers/usb/host/ohci-mem.c - 1.11 linux/drivers/usb/host/ohci-q.c - 1.20 linux/drivers/usb/host/ohci.h - 1.10 linux/drivers/base/sys.c - 1.9 linux/drivers/base/base.h - 1.13 linux/drivers/usb/image/mdc800.c - 1.12 linux/drivers/usb/image/scanner.c - 1.18 linux/drivers/usb/image/scanner.h - 1.12 linux/drivers/usb/input/Makefile - 1.9 linux/drivers/ieee1394/amdtp.c - 1.7 linux/drivers/ieee1394/eth1394.h - 1.4 linux/mm/pdflush.c - 1.12 linux/drivers/usb/misc/auerswald.c - 1.13 linux/drivers/usb/misc/rio500.c - 1.8 linux/drivers/pcmcia/sa1100_trizeps.c - 1.4 linux/fs/ntfs/attrib.c - 1.10 linux/include/sound/uda1341.h - 1.2 linux/drivers/scsi/aic7xxx/aic7xxx_core.c - 1.8 linux/drivers/char/synclinkmp.c - 1.8 linux/fs/ntfs/namei.c - 1.8 linux/fs/ntfs/mft.c - 1.8 linux/fs/ntfs/layout.h - 1.4 linux/drivers/char/pcmcia/synclink_cs.c - 1.9 linux/sound/i2c/l3/uda1341.c - 1.6 linux/fs/ntfs/aops.c - 1.12 linux/net/ipv6/ipv6_syms.c - 1.6 linux/drivers/pci/hotplug.c - 1.10 linux/drivers/pci/probe.c - 1.13 linux/fs/fs-writeback.c - 1.14 linux/arch/i386/pci/numa.c - 1.7 linux/arch/i386/pci/visws.c - 1.5 linux/init/Makefile - 1.15 linux/include/linux/jiffies.h - 1.4 linux/Documentation/block/biodoc.txt - 1.3 linux/kernel/suspend.c - 1.21 linux/drivers/video/cfbcopyarea.c - 1.7 linux/drivers/base/bus.c - 1.13 linux/drivers/char/drm/i830_drm.h - 1.3 linux/drivers/video/cfbimgblt.c - 1.7 linux/include/linux/suspend.h - 1.9 linux/fs/mpage.c - 1.18 linux/drivers/acpi/pci_link.c - 1.9 linux/drivers/acpi/processor.c - 1.17 linux/drivers/acpi/osl.c - 1.15 linux/include/asm-s390x/rwsem.h - 1.4 linux/drivers/isdn/hisax/amd7930_fn.c - 1.9 linux/drivers/isdn/hisax/enternow_pci.c - 1.6 linux/drivers/usb/host/ohci-sa1111.c - 1.12 linux/drivers/usb/class/usb-midi.h - 1.3 linux/drivers/s390/net/lcs.c - 1.11 linux/arch/i386/kernel/suspend.c - 1.10 linux/include/asm-s390/rwsem.h - 1.4 linux/drivers/usb/host/ohci-pci.c - 1.6 linux/arch/i386/kernel/cpu/intel.c - 1.12 linux/arch/i386/kernel/cpu/cyrix.c - 1.7 linux/arch/i386/kernel/cpu/amd.c - 1.9 linux/arch/i386/kernel/cpu/centaur.c - 1.5 linux/arch/arm/mm/proc-arm6_7.S - 1.6 linux/net/llc/llc_pdu.c - 1.6 linux/include/net/llc_conn.h - 1.7 linux/arch/i386/mm/pageattr.c - 1.3 linux/fs/direct-io.c - 1.17 linux/drivers/serial/clps711x.c - 1.7 linux/drivers/serial/uart00.c - 1.8 linux/drivers/serial/sa1100.c - 1.6 linux/drivers/serial/core.c - 1.9 linux/drivers/serial/anakin.c - 1.7 linux/drivers/serial/amba.c - 1.8 linux/drivers/serial/8250.c - 1.13 linux/arch/i386/mm/pgtable.c - 1.6 linux/drivers/serial/21285.c - 1.7 linux/include/linux/serial_core.h - 1.10 linux/Documentation/vm/overcommit-accounting - 1.3 linux/drivers/serial/sunzilog.c - 1.10 linux/drivers/serial/sunsu.c - 1.11 linux/net/sched/sch_htb.c - 1.6 linux/drivers/usb/misc/speedtouch.c - 1.12 linux/drivers/usb/misc/usblcd.c - 1.5 linux/drivers/i2c/i2c-algo-ibm_ocp.c - 1.4 linux/drivers/base/intf.c - 1.5 linux/net/ipv4/netfilter/ipt_helper.c - 1.2 linux/net/ipv4/netfilter/ipt_conntrack.c - 1.2 linux/drivers/base/class.c - 1.8 linux/include/net/sctp/user.h - 1.3 linux/net/sctp/ulpevent.c - 1.5 linux/net/sctp/protocol.c - 1.13 linux/net/sctp/Makefile - 1.5 linux/include/net/sctp/sctp.h - 1.10 linux/net/sctp/associola.c - 1.9 linux/net/sctp/endpointola.c - 1.6 linux/net/sctp/input.c - 1.10 linux/net/sctp/inqueue.c - 1.3 linux/net/sctp/ipv6.c - 1.10 linux/net/sctp/output.c - 1.7 linux/include/net/sctp/ulpqueue.h - 1.4 linux/net/sctp/outqueue.c - 1.9 linux/net/sctp/primitive.c - 1.5 linux/include/net/sctp/ulpevent.h - 1.2 linux/net/sctp/tsnmap.c - 1.2 linux/net/sctp/sm_make_chunk.c - 1.10 linux/include/net/sctp/command.h - 1.4 linux/net/sctp/sm_sideeffect.c - 1.11 linux/net/sctp/sm_statefuns.c - 1.10 linux/include/net/sctp/tsnmap.h - 1.2 linux/include/net/sctp/structs.h - 1.11 linux/net/sctp/socket.c - 1.11 linux/net/sctp/ulpqueue.c - 1.5 linux/arch/i386/mm/discontig.c - 1.6 linux/arch/i386/kernel/numaq.c - 1.5 linux/include/asm-i386/mmzone.h - 1.6 linux/include/asm-i386/numaq.h - 1.6 linux/drivers/ide/setup-pci.c - 1.10 linux/drivers/ide/ppc/pmac.c - 1.5 linux/drivers/ide/ppc/mpc8xx.c - 1.3 linux/drivers/ide/pci/pdc202xx_new.c - 1.9 linux/arch/um/kernel/irq.c - 1.6 linux/include/asm-um/pgtable.h - 1.6 linux/drivers/ide/arm/icside.c - 1.4 linux/arch/i386/mm/hugetlbpage.c - 1.12 linux/include/asm-i386/numnodes.h - 1.2 linux/arch/sparc64/mm/hugetlbpage.c - 1.6 linux/net/bridge/netfilter/ebtable_nat.c - 1.2 linux/net/bridge/netfilter/ebtable_filter.c - 1.2 linux/net/bridge/netfilter/ebtable_broute.c - 1.2 linux/drivers/base/platform.c - 1.4 linux/arch/i386/mach-visws/visws_apic.c - 1.4 linux/arch/ia64/mm/hugetlbpage.c - 1.6 linux/drivers/block/deadline-iosched.c - 1.7 linux/drivers/base/hotplug.c - 1.8 linux/drivers/base/cpu.c - 1.5 linux/drivers/usb/core/driverfs.c - 1.6 linux/Documentation/cpufreq - 1.3 linux/Documentation/vm/hugetlbpage.txt - 1.4 linux/include/asm-generic/topology.h - 1.4 linux/sound/pci/cs46xx/dsp_spos_scb_lib.c - 1.7 linux/include/asm-i386/topology.h - 1.5 linux/sound/pci/cs46xx/dsp_spos.h - 1.5 linux/kernel/cpufreq.c - 1.9 linux/net/llc/af_llc.c - 1.4 linux/include/sound/cs46xx_dsp_spos.h - 1.6 linux/include/linux/cpufreq.h - 1.10 linux/arch/i386/kernel/cpu/cpufreq/powernow-k6.c - 1.7 linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c - 1.8 linux/arch/i386/kernel/cpu/cpufreq/speedstep.c - 1.9 linux/arch/i386/kernel/cpu/cpufreq/elanfreq.c - 1.7 linux/arch/i386/kernel/cpu/cpufreq/longrun.c - 1.7 linux/arch/i386/kernel/cpu/cpufreq/longhaul.c - 1.7 linux/sound/usb/usbaudio.c - 1.9 linux/drivers/usb/misc/usbtest.c - 1.9 linux/drivers/scsi/nsp32.c - 1.6 linux/drivers/scsi/aacraid/linit.c - 1.8 linux/drivers/scsi/aacraid/commsup.c - 1.3 linux/drivers/scsi/aacraid/comminit.c - 1.2 linux/fs/cifs/cifs_unicode.h - 1.2 linux/fs/nfsd/nfs4xdr.c - 1.8 linux/fs/cifs/cifspdu.h - 1.4 linux/arch/i386/kernel/timers/timer_tsc.c - 1.9 linux/drivers/isdn/hardware/eicon/istream.c - 1.2 linux/drivers/isdn/hardware/eicon/i4l_idi.c - 1.3 linux/drivers/isdn/hardware/eicon/dadapter.c - 1.2 linux/drivers/isdn/hardware/eicon/di.c - 1.2 linux/Documentation/arm/XScale/IOP310/IQ80310 - 1.2 linux/drivers/mtd/maps/autcpu12-nvram.c - 1.2 linux/drivers/mtd/maps/ceiva.c - 1.2 linux/drivers/mtd/maps/edb7312.c - 1.2 linux/drivers/mtd/maps/epxa10db-flash.c - 1.2 linux/drivers/mtd/maps/fortunet.c - 1.2 linux/drivers/mtd/maps/impa7.c - 1.2 linux/drivers/mtd/maps/pci.c - 1.2 linux/fs/afs/vnode.c - 1.2 linux/arch/i386/oprofile/nmi_int.c - 1.6 linux/drivers/block/scsi_ioctl.c - 1.6 linux/arch/x86_64/kernel/pci-gart.c - 1.5 linux/arch/x86_64/kernel/e820.c - 1.4 linux/arch/x86_64/mm/pageattr.c - 1.3 linux/scripts/Makefile.clean - 1.4 linux/drivers/isdn/i4l/isdn_ppp_ccp.c - 1.5 linux/fs/sysfs/Makefile - 1.4 linux/fs/sysfs/inode.c - 1.8 linux/include/linux/sysfs.h - 1.7 linux/drivers/pnp/interface.c - 1.7 linux/include/linux/kobject.h - 1.7 linux/drivers/net/pcmcia/Kconfig - 1.4 linux/arch/i386/Kconfig - 1.13 linux/drivers/net/wireless/Kconfig - 1.5 linux/arch/i386/mach-voyager/voyager_smp.c - 1.6 linux/scripts/Makefile.build - 1.8 linux/include/asm-parisc/pdc_chassis.h - 1.2 linux/arch/ia64/mm/discontig.c - 1.3 linux/include/asm-parisc/eisa_eeprom.h - 1.2 linux/include/asm-parisc/cacheflush.h - 1.2 linux/include/asm-ia64/mmzone.h - 1.3 linux/drivers/media/dvb/av7110/saa7146_core.c - 1.4 linux/drivers/media/dvb/av7110/saa7146.c - 1.3 linux/arch/parisc/kernel/perf.c - 1.6 linux/arch/parisc/kernel/perf_images.h - 1.2 linux/arch/parisc/kernel/smp.c - 1.4 linux/drivers/md/dm-table.c - 1.5 linux/drivers/md/dm-ioctl.c - 1.5 linux/drivers/scsi/Kconfig - 1.8 linux/drivers/char/agp/Kconfig - 1.7 linux/drivers/hotplug/acpiphp_glue.c - 1.6 linux/drivers/hotplug/acpiphp_pci.c - 1.3 linux/arch/sparc/Kconfig - 1.8 linux/arch/sparc64/Kconfig - 1.8 linux/fs/befs/linuxvfs.c - 1.6 linux/fs/befs/btree.c - 1.4 linux/fs/befs/ChangeLog - 1.5 linux/net/ipv6/netfilter/Kconfig - 1.2 linux/drivers/acpi/Kconfig - 1.5 linux/drivers/video/Kconfig - 1.9 linux/drivers/usb/serial/Kconfig - 1.6 linux/drivers/usb/input/Kconfig - 1.6 linux/fs/hugetlbfs/inode.c - 1.9 linux/fs/eventpoll.c - 1.6 linux/include/asm-m68knommu/MC68328.h - 1.2 linux/include/asm-m68knommu/MC68EZ328.h - 1.2 linux/include/asm-m68knommu/MC68VZ328.h - 1.2 linux/drivers/parisc/sba_iommu.c - 1.5 linux/drivers/parisc/dino.c - 1.6 linux/drivers/parisc/ccio-dma.c - 1.6 linux/include/linux/hugetlb.h - 1.6 linux/include/asm-m68knommu/mcftimer.h - 1.2 linux/drivers/net/fec.c - 1.4 linux/drivers/mtd/maps/uclinux.c - 1.2 linux/include/asm-v850/sim.h - 1.3 linux/include/asm-m68knommu/siginfo.h - 1.2 linux/drivers/base/firmware.c - 1.3 linux/include/asm-m68knommu/unistd.h - 1.2 linux/arch/v850/kernel/time.c - 1.4 linux/arch/m68knommu/kernel/ints.c - 1.3 linux/arch/m68knommu/kernel/syscalltable.S - 1.3 linux/arch/m68knommu/kernel/time.c - 1.3 linux/arch/m68knommu/platform/5307/entry.S - 1.3 linux/arch/m68knommu/platform/68360/ints.c - 1.2 linux/arch/v850/kernel/rte_ma1_cb.c - 1.2 linux/arch/v850/kernel/rte_cb_multi.c - 1.3 linux/arch/v850/kernel/ma.c - 1.2 linux/arch/v850/kernel/irq.c - 1.5 linux/drivers/net/b44.h - 1.2 linux/drivers/net/irda/actisys-sir.c - 1.2 linux/drivers/net/irda/irtty-sir.c - 1.2 linux/drivers/net/irda/sir_dev.c - 1.3 linux/drivers/net/irda/sir_kthread.c - 1.5 linux/drivers/hotplug/cpci_hotplug_pci.c - 1.4 linux/drivers/serial/68328serial.h - 1.2 linux/arch/i386/kernel/cpu/mcheck/non-fatal.c - 1.3 linux/arch/ppc/syslib/mpc10x_common.c - 1.5 linux/net/ipv4/esp.c - 1.4 linux/drivers/s390/char/sclp.c - 1.2 linux/drivers/s390/char/sclp_rw.c - 1.2 linux/Documentation/fb/sstfb.txt - 1.2 linux/Documentation/scsi/ibmmca.txt - 1.3 linux/drivers/usb/serial/kobil_sct.c - 1.3 linux/drivers/ieee1394/dma.c - 1.3 linux/drivers/acpi/events/evgpe.c - 1.6 linux/drivers/s390/cio/device_fsm.c - 1.2 linux/include/asm-s390x/ccwdev.h - 1.2 linux/include/asm-s390/ccwdev.h - 1.2 linux/drivers/char/agp/intel-agp.c - 1.6 linux/drivers/s390/cio/qdio.h - 1.3 linux/drivers/char/watchdog/Kconfig - 1.5 linux/drivers/char/watchdog/Makefile - 1.4 linux/drivers/char/watchdog/acquirewdt.c - 1.5 linux/drivers/char/watchdog/i810-tco.c - 1.4 linux/drivers/ide/ide-io.c - 1.3 linux/drivers/char/watchdog/ib700wdt.c - 1.4 linux/drivers/char/watchdog/machzwd.c - 1.5 linux/drivers/char/watchdog/mixcomwd.c - 1.4 linux/drivers/char/watchdog/pcwd.c - 1.5 linux/drivers/char/watchdog/sbc60xxwdt.c - 1.5 linux/drivers/char/watchdog/wdt977.c - 1.5 linux/drivers/char/watchdog/wdt_pci.c - 1.4 linux/drivers/char/watchdog/shwdt.c - 1.4 linux/drivers/char/watchdog/softdog.c - 1.4 linux/drivers/char/watchdog/wdt.c - 1.5 linux/drivers/i2c/busses/i2c-amd8111.c - 1.2 linux/drivers/i2c/chips/adm1021.c - 1.3 linux/drivers/i2c/chips/lm75.c - 1.3 linux/arch/i386/kernel/sysenter.c - 1.4 linux/lib/crc32defs.h - 1.2 linux/drivers/scsi/aic7xxx/aic79xx.h - 1.3 linux/drivers/scsi/aic7xxx/aic79xx_core.c - 1.4 linux/include/asm-i386/mach-summit/mach_apic.h - 1.5 linux/include/asm-i386/mach-numaq/mach_apic.h - 1.4 linux/include/asm-i386/mach-default/mach_apic.h - 1.4 linux/include/asm-i386/mach-default/do_timer.h - 1.2 linux/drivers/scsi/aic7xxx/aic79xx_osm.c - 1.6 linux/drivers/scsi/aic7xxx/aic79xx_osm.h - 1.4 linux/drivers/scsi/aic7xxx/aic79xx_osm_pci.c - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx_osm.c - 1.6 linux/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c - 1.3 linux/drivers/char/watchdog/indydog.c - 1.3 linux/drivers/char/watchdog/sc520_wdt.c - 1.5 linux/drivers/ide/pci/triflex.h - 1.2 linux/arch/ppc/platforms/4xx/ibmstbx25.h - 1.4 linux/net/sunrpc/rpc_pipe.c - 1.4 linux/arch/i386/kernel/cpu/cpufreq/gx-suspmod.c - 1.4 linux/include/asm-i386/mach-bigsmp/mach_apic.h - 1.3 linux/include/linux/ipmi.h - 1.2 linux/arch/sparc64/kernel/us3_cpufreq.c - 1.2 linux/arch/alpha/kernel/sys_marvel.c - 1.3 linux/drivers/char/hangcheck-timer.c - 1.2 linux/include/acpi/acconfig.h - 1.3 linux/include/acpi/acdebug.h - 1.3 linux/arch/i386/kernel/cpu/cpufreq/acpi.c - 1.2 linux/include/acpi/acutils.h - 1.3 linux/include/acpi/acresrc.h - 1.3 linux/include/acpi/acpixf.h - 1.4 linux/arch/arm/common/sa1111.c - 1.3 linux/include/acpi/aclocal.h - 1.3 linux/include/acpi/acevents.h - 1.3 linux/include/acpi/acglobal.h - 1.3 linux/include/acpi/achware.h - 1.3 linux/drivers/cpufreq/Makefile - 1.2 linux/scripts/modpost.c - 1.3 linux/scripts/mk_elfconfig.c - 1.2 linux/drivers/cpufreq/Kconfig - 1.2 linux/scripts/Makefile.modpost - 1.2 linux/drivers/char/agp/alpha-agp.c - 1.2 linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c - 1.2 linux/drivers/acpi/sleep/proc.c - 1.2 linux/drivers/acpi/sleep/main.c - 1.2 linux/drivers/ieee1394/ieee1394-ioctl.h - 1.2 linux/arch/i386/kernel/acpi/wakeup.S - 1.2 linux/arch/i386/kernel/acpi/boot.c - 1.2 linux/arch/i386/kernel/acpi/sleep.c - 1.2 linux/arch/m68knommu/platform/5307/vectors.c - 1.2 linux/drivers/net/wireless/arlan.c - 1.2 linux/drivers/net/wireless/arlan-proc.c - 1.2 linux/arch/i386/kernel/cpu/cpufreq/Kconfig - 1.2 linux/kernel/posix-timers.c - 1.2 linux/include/asm-i386/mach-visws/cobalt.h - 1.2 From owner-linux-xfs@oss.sgi.com Wed Mar 5 10:07:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 10:08:03 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25I7pf25540 for ; Wed, 5 Mar 2003 10:07:51 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25I7p9n000370 for ; Wed, 5 Mar 2003 10:07:51 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA55488 for ; Wed, 5 Mar 2003 12:07:50 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id MAA90369 for ; Wed, 5 Mar 2003 12:07:50 -0600 (CST) Subject: TAKE - Fix indices into xfs_min/xfs_max for sysctls in 2.5.x From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 05 Mar 2003 12:07:40 -0600 Message-Id: <1046887661.13282.59.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 3050 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 451 Lines: 19 Fix indices into xfs_min/xfs_max for sysctls in 2.5.x Date: Wed Mar 5 10:03:28 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.5.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:140972a linux/fs/xfs/linux/xfs_sysctl.c - 1.14 -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Mar 5 10:23:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 10:23:51 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25INnf26307 for ; Wed, 5 Mar 2003 10:23:49 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25INm9n001749 for ; Wed, 5 Mar 2003 10:23:48 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA32718 for ; Wed, 5 Mar 2003 12:23:47 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA37182 for ; Wed, 5 Mar 2003 12:23:47 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h25INci21229; Wed, 5 Mar 2003 12:23:38 -0600 Message-Id: <200303051823.h25INci21229@stout.americas.sgi.com> Date: Wed, 5 Mar 2003 12:23:38 -0600 Subject: TAKE - Add stack trace print to xfs_error_report X-archive-position: 3051 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 862 Lines: 30 Add stack trace print to xfs_error_report, warning cleanup Date: Wed Mar 5 10:23:21 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Inspected by: gwehrman lord Author: overby Merged by: sandeen Merged mods: irix6.5f:irix:136543a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:136543a linux/fs/xfs/xfs_error.c - 1.38 - Merge of irix6.5f:irix:136543a by sandeen. Merge of grove2-6520stage:irix:136543a by roehrich. Merge of grove2:irix:136543a by roehrich. fix warnings about xfs_mount linux/fs/xfs/xfs_error.h - 1.31 - Merge of irix6.5f:irix:136543a by sandeen. Merge of grove2-6520stage:irix:136543a by roehrich. Merge of grove2:irix:136543a by roehrich. add xfs_stack_trace to print stack traces for xfs_error_report. From owner-linux-xfs@oss.sgi.com Wed Mar 5 10:24:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 10:24:57 -0800 (PST) Received: from mail.automatix.de ([62.67.57.175]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25IOKf26362 for ; Wed, 5 Mar 2003 10:24:20 -0800 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.35 #1) id 18qdYx-0000PP-00 for linux-xfs@oss.sgi.com; Wed, 05 Mar 2003 19:24:19 +0100 Received: from pc2.s.automatix.de ([192.168.11.12]) by s.automatix.de with esmtp (Exim 3.36 #1) id 18qdWI-0003Eh-00; Wed, 05 Mar 2003 19:21:34 +0100 From: Juergen Sauer Reply-To: juergen.sauer@automatix.de Organization: AutomatiX GmbH To: Chris Wedgwood Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? Date: Wed, 5 Mar 2003 20:22:34 +0100 User-Agent: KMail/1.5 Cc: linux-xfs@oss.sgi.com References: <200303051048.54271.juergen.sauer@automatix.de> <20030305093554.GA29602@f00f.org> In-Reply-To: <20030305093554.GA29602@f00f.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200303052022.38108.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h25IOLf26364 X-archive-position: 3052 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: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs Content-Length: 2030 Lines: 57 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 5. März 2003 10:35 schrieb Chris Wedgwood: A few Remarks before to other replies, yes, Nvidia is well known to have problems with linux. (proprietrary, buggy, incomplete driver etc). On the other hand we are doing here a evaluation, if this board is usable. > On Wed, Mar 05, 2003 at 10:48:54AM +0100, Juergen Sauer wrote: > > The well known/common patches for 2.4 Kernels are failing on our XFS > > stable kernels. > failing? how so? The XFS Kernel 2.4.20-xfs out of the SGI/CVS Repository does not know about the the nforce2 ide and gives errors, if I enable DMA/UDMA modes. The common patches for fixing it are working against plain vanilla kernel - - without XFS. :-<< > does the amd7xx IDE driver fix this? it has some nv IDs in there by > the looks of things? The amd7xx driver is not in the kernel visible here. Should it be visible? (Error in config.in ?) > if not, what does "lspci -n" say for the ide controller? lspci -v 00:09.0 IDE interface: nVidia Corporation: Unknown device 0065 (rev a2) (prog-if 8a [Master SecP PriP]) Subsystem: Asustek Computer, Inc.: Unknown device 0c11 Flags: bus master, 66Mhz, fast devsel, latency 0 I/O ports at f000 [size=16] Capabilities: [44] Power Management version 2 lspci -n 00:09.0 Class 0101: 10de:0065 (rev a2) > avoid hardware where vendors make your life difficult Best idea - but it is not for private usage, it's for a small series of cheap performant development boxes. Paralell we requested the drivers from ASUS/Germany. mfG Jürgen automatiX Linux Support Crew - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** ** http://www.automatix.de http://www.kranautomatisierung.de ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Zk59W7UKI9EqarERAlzfAJ9qUGTBTY58PA1YatALPmfI1CtGMgCfZ1wA xHyx7U5L41Xu2hD3XUzqDL8= =9RY1 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Mar 5 10:29:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 10:29:35 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25ITXf26895 for ; Wed, 5 Mar 2003 10:29:33 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25ITWnH032087 for ; Wed, 5 Mar 2003 10:29:32 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA58210 for ; Wed, 5 Mar 2003 12:29:31 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA64085 for ; Wed, 5 Mar 2003 12:29:32 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h25ITM921984; Wed, 5 Mar 2003 12:29:22 -0600 Message-Id: <200303051829.h25ITM921984@stout.americas.sgi.com> Date: Wed, 5 Mar 2003 12:29:22 -0600 Subject: TAKE - check the inode for extents after getting the shared lock X-archive-position: 3053 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 848 Lines: 25 In open, check the inode for extents after getting the shared lock on the inode. The inode could have changed since before the lock. Date: Wed Mar 5 10:29:00 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge Inspected by: lord Author: overby Merged by: sandeen Merged mods: irix6.5f:irix:137931a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:137931a linux/fs/xfs/xfs_vnodeops.c - 1.585 - Merge of irix6.5f:irix:137931a by sandeen. Merge of grove2-6520stage:irix:137931a by roehrich. Merge of cxfs-client2.5.0:irix:137931a by roehrich. Merge of grove2:irix:137931a by roehrich. In open, check the inode for extents after getting the shared lock on the inode. The inode could have changed since before the lock. From owner-linux-xfs@oss.sgi.com Wed Mar 5 10:59:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 10:59:50 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25Ixff28533 for ; Wed, 5 Mar 2003 10:59:41 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25IxfnH002680 for ; Wed, 5 Mar 2003 10:59:41 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA36581 for ; Wed, 5 Mar 2003 12:59:40 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA36241 for ; Wed, 5 Mar 2003 12:59:40 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h25IxUD22534; Wed, 5 Mar 2003 12:59:30 -0600 Message-Id: <200303051859.h25IxUD22534@stout.americas.sgi.com> Date: Wed, 5 Mar 2003 12:59:30 -0600 Subject: TAKE - Remove #if(n)def __KERNEL__ from xfs_error.c X-archive-position: 3054 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 333 Lines: 13 Remove #if(n)def __KERNEL__ from xfs_error.c, not needed Date: Wed Mar 5 10:59:24 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-modmerge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140981a linux/fs/xfs/xfs_error.c - 1.39 From owner-linux-xfs@oss.sgi.com Wed Mar 5 11:08:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 11:09:03 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25J8tf29347 for ; Wed, 5 Mar 2003 11:08:55 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25J8s9n006276 for ; Wed, 5 Mar 2003 11:08:54 -0800 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA80903 for ; Wed, 5 Mar 2003 13:08:54 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA94714 for ; Wed, 5 Mar 2003 13:08:54 -0600 (CST) Received: from clink.americas.sgi.com (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id h25J9B0t9154565 for ; Wed, 5 Mar 2003 13:09:11 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id h25J9BC28582151 for linux-xfs@oss.sgi.com; Wed, 5 Mar 2003 13:09:11 -0600 (CST) Date: Wed, 5 Mar 2003 13:09:11 -0600 (CST) From: Dean Roehrich Message-Id: <200303051909.h25J9BC28582151@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 883150 - fix mem leak in dm_send_namesp_event X-archive-position: 3055 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: roehrich@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 520 Lines: 18 Date: Wed Mar 5 11:08:26 PST 2003 Workarea: clink.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs Inspected by: felixb Author: roehrich Merged by: roehrich Merged mods: grove2:irix:140983a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140983a linux/fs/xfs/dmapi/dmapi_event.c - 1.11 - Merge of grove2:irix:140983a by roehrich. dm_send_namesp_event leaked memory via tdp1 and tdp2 when preunmount comes in but the HSM doesn't want it. From owner-linux-xfs@oss.sgi.com Wed Mar 5 11:27:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 11:27:29 -0800 (PST) Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13]) by oss.sgi.com (8.11.6/8.11.6) with SMTP id h25JRJf30185 for ; Wed, 5 Mar 2003 11:27:19 -0800 Received: from localhost (ifrs@fiesta.cs.tu-berlin.de [130.149.17.4]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with SMTP id UAA21184 for ; Wed, 5 Mar 2003 20:25:05 +0100 (MET) Date: Wed, 5 Mar 2003 20:25:04 +0100 From: Robert Starzynski To: XFS Mailing List Subject: incremental backup with xfsdump Message-Id: <20030305202504.2502bb80.ifrs@cs.tu-berlin.de> X-Mailer: Sylpheed version 0.8.10claws13 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.g_nlHKg'ktGl2:" X-archive-position: 3056 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: ifrs@cs.tu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1093 Lines: 42 --=.g_nlHKg'ktGl2: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi! I want to do an incremental backup with xfsdump excluding at the same time a directory so the "-s" switch doesn't work. Due to the docs I have use the SGI_XFSDUMP_SKIP_FILE attribute. I expected that setting this attribute on a directory would recursively exclude all files in that directory from the backup but unfortunately that's not the case. Is there a smarter way to do such an incremental backup than just setting this attribute on every file in that directory before a backup? (I have to assure that every file added since the last backup gets this attribute too.) I'm currently using the following debian packages: kernel-patch-xfs 1.2pre4-1 xfsdump 2.2.4-1 (dump format 3.0) attr 2.2.0-1 Thanks, Robert --=.g_nlHKg'ktGl2: Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Zk8Q9xefhZz8LH4RAjxvAJ98JV8VorICq8F766CTvMAHxDNQgwCgq2so IlQ4JCI4AdHydcjH1sPwATk= =ESF5 -----END PGP SIGNATURE----- --=.g_nlHKg'ktGl2:-- From owner-linux-xfs@oss.sgi.com Wed Mar 5 12:18:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 12:18:56 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h25KIm40024774 for ; Wed, 5 Mar 2003 12:18:48 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h25KImKT024772 for linux-xfs@oss.sgi.com; Wed, 5 Mar 2003 12:18:48 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h25KIk42024759 for ; Wed, 5 Mar 2003 12:18:46 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h25KI2B2024689; Wed, 5 Mar 2003 12:18:02 -0800 Date: Wed, 5 Mar 2003 12:18:02 -0800 Message-Id: <200303052018.h25KI2B2024689@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 221] reload xfs/dmapi module crash X-Bugzilla-Reason: AssignedTo X-archive-position: 3058 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 719 Lines: 24 http://oss.sgi.com/bugzilla/show_bug.cgi?id=221 roehrich@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From roehrich@sgi.com 2003-03-05 12:18 ------- I checked in the following mod to fix the mem leak. Modid: 2.4.x-xfs:slinx:140983a linux/fs/xfs/dmapi/dmapi_event.c - 1.11 dm_send_namesp_event leaked memory via tdp1 and tdp2 when preunmount comes in but the HSM doesn't want it. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 5 12:52:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 12:52:24 -0800 (PST) Received: from andrei.myip.org (12-234-128-127.client.attbi.com [12.234.128.127]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h25Kom40025529 for ; Wed, 5 Mar 2003 12:52:20 -0800 Received: from spampd.localdomain (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 089962FA71 for ; Wed, 5 Mar 2003 12:50:48 -0800 (PST) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 6FA6A2FA71 for ; Wed, 5 Mar 2003 12:50:47 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 1DE1C1967B for ; Wed, 5 Mar 2003 12:50:37 -0800 (PST) Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? From: Florin Andrei Reply-To: linux-xfs@oss.sgi.com To: linux-xfs In-Reply-To: <200303051048.54271.juergen.sauer@automatix.de> References: <200303051048.54271.juergen.sauer@automatix.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 05 Mar 2003 12:50:36 -0800 Message-Id: <1046897437.31215.43.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-archive-position: 3059 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: florin@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1018 Lines: 31 On Wed, 2003-03-05 at 01:48, Juergen Sauer wrote: > > The well known/common patches for 2.4 Kernels are failing on our > XFS stable kernels. > Without this patched the ide modules are not enableing DMA/UDMA at all so > this is not a usable solution. Is this a specific nForce2 problem? I was able to use XFS and DMA on nForce1 with no problems. > The original Nvidia "Drivers" has only "audio" and "network" drivers, but > nvida excluded the IDE Part. (Bad Boys!). Is it related just to IDE for the CD-ROM, or for all devices? If it's just for CD-ROMs, here's an excerpt from the RELEASE-NOTES for RH8.0: ########################### DMA is disabled on CD-ROM drives in this release in a different but more reliable way than previously. If you are sure that your CD-ROM drive is capable of IDE DMA, place the following line in the /etc/modules.conf file: options ide-cd dma=1 ############################ -- Florin Andrei "It is not because books are too expensive that they worship football." - Paul Graham From owner-linux-xfs@oss.sgi.com Wed Mar 5 13:05:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 13:05:17 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h25L5D40029710 for ; Wed, 5 Mar 2003 13:05:15 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id D2484183068A; Wed, 5 Mar 2003 13:05:13 -0800 (PST) Date: Wed, 5 Mar 2003 13:05:13 -0800 From: Chris Wedgwood To: Juergen Sauer Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? Message-ID: <20030305210513.GA427@f00f.org> References: <200303051048.54271.juergen.sauer@automatix.de> <20030305093554.GA29602@f00f.org> <200303052022.38108.juergen.sauer@automatix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303052022.38108.juergen.sauer@automatix.de> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 3060 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 509 Lines: 19 On Wed, Mar 05, 2003 at 08:22:34PM +0100, Juergen Sauer wrote: > The XFS Kernel 2.4.20-xfs out of the SGI/CVS Repository does not > know about the the nforce2 ide and gives errors, if I enable > DMA/UDMA modes. I knows about the nv/amd driver though > The amd7xx driver is not in the kernel visible here. Should it be > visible? (Error in config.in ?) CONFIG_BLK_DEV_AMD74XX=y actually, i think you need an -ac tree for this, i was looking at the 2.5.x where the nv ide and amd ide are unified --cw From owner-linux-xfs@oss.sgi.com Wed Mar 5 13:57:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 13:58:01 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h25LvqRu000672 for ; Wed, 5 Mar 2003 13:57:53 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h25Lvl9n025500 for ; Wed, 5 Mar 2003 13:57:47 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA02286 for ; Wed, 5 Mar 2003 15:57:46 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA36661 for ; Wed, 5 Mar 2003 15:57:40 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h25LvT529618; Wed, 5 Mar 2003 15:57:29 -0600 Message-Id: <200303052157.h25LvT529618@stout.americas.sgi.com> Date: Wed, 5 Mar 2003 15:57:29 -0600 Subject: TAKE - Get all of userspace building within the tree again X-archive-position: 3061 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 378 Lines: 15 Get all of userspace building within the tree again Date: Wed Mar 5 13:57:25 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:141016a acl/libacl/Makefile - 1.22 - Add to LTLDFLAGS, don't clobber - lost settings from top level Makefile From owner-linux-xfs@oss.sgi.com Wed Mar 5 14:11:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 14:11:39 -0800 (PST) Received: from jello277.jellocom.de (root@jello277.jellocom.de [217.17.194.152]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h25MAERu003784 for ; Wed, 5 Mar 2003 14:11:30 -0800 Received: from cobo-1.intranet.cobonet.de (ppp587.jetz.de [217.17.206.75]) (authenticated bits=0) by jello277.jellocom.de (8.12.8/8.12.1) with ESMTP id h25MA4oq000940; Wed, 5 Mar 2003 23:10:04 +0100 Content-Type: text/plain; charset="iso-8859-15" From: Thomas Bittermann To: juergen.sauer@automatix.de Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? Date: Wed, 5 Mar 2003 23:09:46 +0100 User-Agent: KMail/1.4.3 References: <200303051048.54271.juergen.sauer@automatix.de> <20030305093554.GA29602@f00f.org> <200303052022.38108.juergen.sauer@automatix.de> In-Reply-To: <200303052022.38108.juergen.sauer@automatix.de> Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Message-Id: <200303052309.51984.t.bittermann@online.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h25MBVRu003879 X-archive-position: 3062 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: t.bittermann@online.de Precedence: bulk X-list: linux-xfs Content-Length: 1898 Lines: 62 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Juergen, I'm using a "home-grown" 2.4.21-pre5-ac1 with XFS (CVS-2003-03-05). Alan's patch removes nvidia.* from drivers/ide/pci (pre5). It includes nForce(2) support in drivers/ide/pci/amd74xx.* so be sure to activate "AMD Viper support". For now I could say it works stable and fast on my Leadtek K7NCR18D-Pro (nForce2): [root@cobo-1 root]# hdparm /dev/hda /dev/hda: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 8 (on) geometry = 7476/255/63, sectors = 120103200, start = 0 [root@localhost root]# hdparm -itT /dev/hda /dev/hda: Model=IC35L060AVER07-0, FwRev=ER6OA46A, SerialNo=SZPTZT98569 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40 BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=120103200 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 AdvancedPM=yes: disabled (255) WriteCache=enabled Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1: 2 3 4 5 Timing buffer-cache reads: 128 MB in 0.36 seconds =355.56 MB/sec Timing buffered disk reads: 64 MB in 1.66 seconds = 38.55 MB/sec The box isn't really under stress but it serves my imap stuff and I'm coding a lot with Eclipse and compiling new kernels every hour ;-) Hope this helps... Cheers Thomas PS: XFS really ROCKS and you xfs-dev-guys doing a very good job! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ZnWq3E3TGgPB70IRAu/SAKCe9PNkeOOLukyf5ne577NjNWHFdACfZQkQ M4wWS9TYhMU5Hy+2ImWQuF0= =ecXm -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Mar 5 18:20:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 18:20:56 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h262Knq9012471 for ; Wed, 5 Mar 2003 18:20:49 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h262Kn2U012469 for linux-xfs@oss.sgi.com; Wed, 5 Mar 2003 18:20:49 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h262Klq9012456 for ; Wed, 5 Mar 2003 18:20:47 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h261Pc30012127; Wed, 5 Mar 2003 17:25:38 -0800 Date: Wed, 5 Mar 2003 17:25:38 -0800 Message-Id: <200303060125.h261Pc30012127@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 227] New: unmount fail X-Bugzilla-Reason: AssignedTo X-archive-position: 3063 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 977 Lines: 47 http://oss.sgi.com/bugzilla/show_bug.cgi?id=227 Summary: unmount fail Product: Linux XFS Version: 1.2.x Platform: IA32 OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: grandsonata@netscape.net If this is a userspace bug, what version of the package are you using: XFS 1.2 What kernel are you using: 2.4.19 Where did the XFS code come from? (CVS, Linus, your distribution, etc): SGI Description of Problem: Unmounting at shutdown failed. Didn't happen in version 1.1. How Reproducible: not really reproducible. don't know what cause the unmount to fail. Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information: ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 5 19:20:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 19:20:52 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h263Knq9014020 for ; Wed, 5 Mar 2003 19:20:49 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h263KmjX014018 for linux-xfs@oss.sgi.com; Wed, 5 Mar 2003 19:20:48 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h263KlqB014005 for ; Wed, 5 Mar 2003 19:20:47 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h262WQTA013092; Wed, 5 Mar 2003 18:32:26 -0800 Date: Wed, 5 Mar 2003 18:32:26 -0800 Message-Id: <200303060232.h262WQTA013092@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 228] New: xfs_repair can't deal with small (agcount==1) filesystems X-Bugzilla-Reason: AssignedTo X-archive-position: 3064 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 751 Lines: 27 http://oss.sgi.com/bugzilla/show_bug.cgi?id=228 Summary: xfs_repair can't deal with small (agcount==1) filesystems Product: Linux XFS Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: critical Priority: High Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: cw@f00f.org xfs_repair barfs if you try to repair a fs with only on ag (no spare sb's): charon:~# xfs_repair /dev/hda1 Phase 1 - find and verify superblock... Only one AG detected - cannot proceed. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 5 20:42:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 20:42:18 -0800 (PST) Received: from web10402.mail.yahoo.com (web10402.mail.yahoo.com [216.136.130.94]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h264g9q9014841 for ; Wed, 5 Mar 2003 20:42:10 -0800 Message-ID: <20030306044209.13733.qmail@web10402.mail.yahoo.com> Received: from [66.25.61.37] by web10402.mail.yahoo.com via HTTP; Wed, 05 Mar 2003 20:42:09 PST Date: Wed, 5 Mar 2003 20:42:09 -0800 (PST) From: John Subject: cvs 2.4 To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 3065 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: jsh_45@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 340 Lines: 14 Hay I've been trying to check out the 2.4xfs tree and it keeps hanging up at linux/scrips/usb. the last line printed is cvs is updating said file. It did this yesterday and again tonight. John __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-linux-xfs@oss.sgi.com Wed Mar 5 21:13:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 21:13:32 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h265DPq9016018 for ; Wed, 5 Mar 2003 21:13:30 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 222D41833FEA; Wed, 5 Mar 2003 21:13:25 -0800 (PST) Date: Wed, 5 Mar 2003 21:13:25 -0800 From: Chris Wedgwood To: John Cc: linux-xfs@oss.sgi.com Subject: Re: cvs 2.4 Message-ID: <20030306051325.GB2317@f00f.org> References: <20030306044209.13733.qmail@web10402.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030306044209.13733.qmail@web10402.mail.yahoo.com> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 3067 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 274 Lines: 11 On Wed, Mar 05, 2003 at 08:42:09PM -0800, John wrote: > I've been trying to check out the 2.4xfs tree and it keeps hanging > up at linux/scrips/usb. the last line printed is cvs is updating > said file. It did this yesterday and again tonight. get a newer cvs --cw From owner-linux-xfs@oss.sgi.com Wed Mar 5 21:13:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 21:13:17 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h265DAq9015947 for ; Wed, 5 Mar 2003 21:13:11 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h265D3nH031924 for ; Wed, 5 Mar 2003 21:13:04 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA13181; Thu, 6 Mar 2003 16:11:47 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 26A873000B8; Thu, 6 Mar 2003 16:11:45 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 898458F; Thu, 6 Mar 2003 16:11:45 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: John Cc: linux-xfs@oss.sgi.com Subject: Re: cvs 2.4 In-reply-to: Your message of "Wed, 05 Mar 2003 20:42:09 -0800." <20030306044209.13733.qmail@web10402.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Mar 2003 16:11:39 +1100 Message-ID: <15726.1046927499@kao2.melbourne.sgi.com> X-archive-position: 3066 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: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 548 Lines: 14 On Wed, 5 Mar 2003 20:42:09 -0800 (PST), John wrote: >I've been trying to check out the 2.4xfs tree and it >keeps hanging up at linux/scrips/usb. the last line >printed is cvs is updating said file. It did this >yesterday and again tonight. This is getting to be a FAQ. cvs on oss.sgi.com has been upgraded to fix a security problem that affected all CVS servers. Users need to upgrade their CVS clients to access any of the fixed severs. For RH users, http://www.redhat.com/mailing-lists/redhat-watch-list/msg00950.html From owner-linux-xfs@oss.sgi.com Wed Mar 5 21:23:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 21:23:55 -0800 (PST) Received: from web10412.mail.yahoo.com (web10412.mail.yahoo.com [216.136.128.126]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h265NDq9016852 for ; Wed, 5 Mar 2003 21:23:53 -0800 Message-ID: <20030306052312.33727.qmail@web10412.mail.yahoo.com> Received: from [66.25.61.37] by web10412.mail.yahoo.com via HTTP; Wed, 05 Mar 2003 21:23:12 PST Date: Wed, 5 Mar 2003 21:23:12 -0800 (PST) From: John Subject: Re: cvs 2.4 To: Keith Owens Cc: linux-xfs@oss.sgi.com In-Reply-To: <15726.1046927499@kao2.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 3068 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: jsh_45@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 646 Lines: 28 > This is getting to be a FAQ. That's a good idea, or maybe someone at SGI should add this note on cvs clients on their cvs instructions webpage? > > cvs on oss.sgi.com has been upgraded to fix a > security problem that > affected all CVS servers. Users need to upgrade > their CVS clients to > access any of the fixed severs. For RH users, > http://www.redhat.com/mailing-lists/redhat-watch-list/msg00950.html sorry I'm a lazy ass debian user running woody, but I know what to do now Thanks __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-linux-xfs@oss.sgi.com Wed Mar 5 23:13:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Mar 2003 23:14:06 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h267Dvq9017925 for ; Wed, 5 Mar 2003 23:13:58 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h267DpnH005443 for ; Wed, 5 Mar 2003 23:13:51 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h267CU7L1013144 for ; Thu, 6 Mar 2003 18:12:30 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h267CTrL1014062 for linux-xfs@oss.sgi.com; Thu, 6 Mar 2003 18:12:29 +1100 (EST) Date: Thu, 6 Mar 2003 18:12:29 +1100 (EST) From: Nathan Scott Message-Id: <200303060712.h267CTrL1014062@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs X-archive-position: 3069 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3917 Lines: 120 Fix up print format compiler warnings. Date: Wed Mar 5 20:28:53 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141056a linux/fs/xfs/xfs_da_btree.c - 1.140 linux/fs/xfs/xfs_dir2_node.c - 1.33 New xfsprogs version - enabled unwritten extents by default, new commands in xfs_db and xfs_admin to manipulate the version extflg bit on unmounted filesystems, make xfs_db check for a dirty log before zeroing it in the uuid command, man page updates, sync'd up user/kernel code and headers. Add stripe information into xfs_bmap output. Date: Wed Mar 5 22:59:34 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:141069a cmd/xfsprogs/db/bmap.c - 1.8 cmd/xfsprogs/db/data.c - 1.5 cmd/xfsprogs/db/data.h - 1.5 cmd/xfsprogs/db/dquot.c - 1.7 cmd/xfsprogs/db/write.c - 1.7 cmd/xfsprogs/db/dir2.c - 1.5 cmd/xfsprogs/db/attr.c - 1.5 cmd/xfsprogs/db/sb.c - 1.8 cmd/xfsprogs/db/dir.c - 1.5 cmd/xfsprogs/db/sb.h - 1.5 cmd/xfsprogs/db/cntbt.c - 1.5 cmd/xfsprogs/db/bnobt.c - 1.5 cmd/xfsprogs/db/dbread.c - 1.5 cmd/xfsprogs/db/mount.h - 1.5 cmd/xfsprogs/db/mount.c - 1.6 cmd/xfsprogs/db/bmapbt.c - 1.5 cmd/xfsprogs/db/bmroot.c - 1.5 cmd/xfsprogs/db/inobt.c - 1.5 cmd/xfsprogs/db/inode.c - 1.6 cmd/xfsprogs/db/faddr.c - 1.6 cmd/xfsprogs/db/init.h - 1.6 cmd/xfsprogs/db/init.c - 1.8 cmd/xfsprogs/db/uuid.h - 1.5 cmd/xfsprogs/db/uuid.c - 1.8 cmd/xfsprogs/db/agf.c - 1.6 cmd/xfsprogs/db/frag.c - 1.9 cmd/xfsprogs/db/freesp.c - 1.9 cmd/xfsprogs/db/agi.c - 1.6 cmd/xfsprogs/db/command.c - 1.6 cmd/xfsprogs/db/convert.c - 1.6 cmd/xfsprogs/db/agfl.c - 1.6 cmd/xfsprogs/db/check.c - 1.12 cmd/xfsprogs/db/block.c - 1.5 cmd/xfsprogs/db/main.c - 1.6 cmd/xfsprogs/db/io.c - 1.9 cmd/xfsprogs/db/text.c - 1.5 - Rationalise headers in xfs_db, fix up early initialisation so we can use libxlog to check for a dirty log, add version command. cmd/xfsprogs/man/man8/xfs_db.8 - 1.6 - Add new version command for setting feature bits in superblocks. cmd/xfsprogs/db/xfs_admin.sh - 1.8 cmd/xfsprogs/man/man8/xfs_admin.8 - 1.2 - Add -e option which sets unwritten extent bit. cmd/xfsprogs/VERSION - 1.67 cmd/xfsprogs/doc/CHANGES - 1.92 cmd/xfsprogs/debian/changelog - 1.60 - New xfsprogs version - enabled unwritten extents by default, new commands in xfs_db and xfs_admin to manipulate the version extflg bit on unmounted filesystems, make xfs_db check for a dirty log before zeroing it in the uuid command, man page updates, sync'd up user/kernel code and headers. Add stripe information into xfs_bmap output. cmd/xfsprogs/bmap/xfs_bmap.c - 1.13 - Add stripe information into xfs_bmap output. cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.40 - Enable unwritten extents by default. cmd/xfsprogs/include/libxfs.h - 1.22 cmd/xfsprogs/libxfs/init.c - 1.25 - Add flags for libxfs_mount so that xfs_db can use it too. cmd/xfsprogs/libxlog/xfs_log_recover.c - 1.19 cmd/xfsprogs/include/xfs_log.h - 1.13 cmd/xfsprogs/include/xfs_log_priv.h - 1.12 cmd/xfsprogs/include/libxlog.h - 1.5 cmd/xfsprogs/include/xfs_bmap_btree.h - 1.9 cmd/xfsprogs/include/xfs_btree.h - 1.7 cmd/xfsprogs/libxfs/xfs_ialloc.c - 1.17 cmd/xfsprogs/libxfs/xfs_da_btree.c - 1.20 cmd/xfsprogs/libxfs/xfs.h - 1.29 cmd/xfsprogs/libxfs/xfs_dir2_block.c - 1.10 cmd/xfsprogs/libxfs/xfs_bmap_btree.c - 1.14 cmd/xfsprogs/libxfs/xfs_dir_leaf.c - 1.13 cmd/xfsprogs/libxfs/xfs_btree.c - 1.12 cmd/xfsprogs/libxfs/xfs_inode.c - 1.16 cmd/xfsprogs/libxfs/xfs_attr_leaf.c - 1.8 cmd/xfsprogs/libxfs/xfs_alloc.c - 1.18 cmd/xfsprogs/libxfs/xfs_bmap.c - 1.18 cmd/xfsprogs/libxfs/xfs_dir2_node.c - 1.13 - Sync with recent kernel changes. cmd/xfsprogs/po/xfsprogs.pot - 1.3 - Update after additional output for xfs_bmap. From owner-linux-xfs@oss.sgi.com Thu Mar 6 00:20:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 00:20:58 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h268Koq9018899 for ; Thu, 6 Mar 2003 00:20:50 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h268KoZx018897 for linux-xfs@oss.sgi.com; Thu, 6 Mar 2003 00:20:50 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h268Kmq9018884 for ; Thu, 6 Mar 2003 00:20:48 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h267lRPI018565; Wed, 5 Mar 2003 23:47:27 -0800 Date: Wed, 5 Mar 2003 23:47:27 -0800 Message-Id: <200303060747.h267lRPI018565@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 227] unmount fail X-Bugzilla-Reason: AssignedTo X-archive-position: 3070 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 582 Lines: 23 http://oss.sgi.com/bugzilla/show_bug.cgi?id=227 ------- Additional Comments From olaf@cbk.poznan.pl 2003-03-05 23:47 ------- Hi, Have this one too... I use CVS from January 10. But I had it earlier, too. As I have several XFS partitions I have to check if it is all the time one of them or it is by chance. I have putted some echos in "halt" script to get it, but from this time it occured only once, so I have to wait to have reproducible results. Olaf ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 6 00:53:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 00:53:16 -0800 (PST) Received: from relay.dstl.gov.uk (relay.dera.gov.uk [192.5.29.49]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h268qQq9019562 for ; Thu, 6 Mar 2003 00:53:07 -0800 Received: (qmail 27959 invoked from network); 6 Mar 2003 08:52:22 +0000 Received: from warlock.dstl.gov.uk (192.5.29.10) by relay.dera.gov.uk with SMTP; 6 Mar 2003 08:52:22 +0000 Subject: Re: cvs 2.4 From: Tony Gale To: Keith Owens Cc: John , linux-xfs@oss.sgi.com In-Reply-To: <15726.1046927499@dstl.gov.uk> References: <15726.1046927499@dstl.gov.uk> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-H2CIaA7X8Gwwdq0/VEln" Organization: Message-Id: <1046940743.4262.3.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 06 Mar 2003 08:52:23 +0000 X-archive-position: 3071 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: gale@syntax.dstl.gov.uk Precedence: bulk X-list: linux-xfs Content-Length: 1285 Lines: 40 --=-H2CIaA7X8Gwwdq0/VEln Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2003-03-06 at 05:11, Keith Owens wrote: > On Wed, 5 Mar 2003 20:42:09 -0800 (PST),=20 > John wrote: > >I've been trying to check out the 2.4xfs tree and it > >keeps hanging up at linux/scrips/usb. the last line > >printed is cvs is updating said file. It did this > >yesterday and again tonight. >=20 > This is getting to be a FAQ. >=20 > cvs on oss.sgi.com has been upgraded to fix a security problem that > affected all CVS servers. Users need to upgrade their CVS clients to > access any of the fixed severs. For RH users, > http://www.redhat.com/mailing-lists/redhat-watch-list/msg00950.html Note though, that the RH updated RPM doesn't fix the hanging problem. -tony --=-H2CIaA7X8Gwwdq0/VEln Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iQCVAwUAPmcMRx/0GZs/Z0FlAQLdNAP+NSgx/ZzSefH5w15abylITnPIz8j3uIDL a77gqZ8PEZo3tJl2nIjTKOTuc4cZS3Oxwhvqqm9MKBuCfJgniJCmfjKDvPy+tBjQ CnO+JAMfd4AYElqKXdqO99Svd3gzGKZyQTShlOzj9jun+2/2wVi0CWYnfZdItC7u 4efRYusQiiI= =YfTK -----END PGP SIGNATURE----- --=-H2CIaA7X8Gwwdq0/VEln-- From owner-linux-xfs@oss.sgi.com Thu Mar 6 03:04:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 03:04:33 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26B4Pq9025009 for ; Thu, 6 Mar 2003 03:04:26 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h26B4J9n019216 for ; Thu, 6 Mar 2003 03:04:19 -0800 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id h26B3IK08337; Thu, 6 Mar 2003 22:03:18 +1100 Date: Thu, 6 Mar 2003 22:03:18 +1100 From: Keith Owens Message-Id: <200303061103.h26B3IK08337@sherman.melbourne.sgi.com> Subject: TAKE - kdb memmap command is i386 only X-archive-position: 3072 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: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 394 Lines: 14 The kdb memmap command is specific to i386 and kills kdb on ia64. Patches to extend memmap to other architectures will be gratefull accepted. Date: Thu Mar 6 03:01:45 PST 2003 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141086a linux/kdb/modules/kdbm_pg.c - 1.63 From owner-linux-xfs@oss.sgi.com Thu Mar 6 04:20:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 04:21:00 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h26CKqq9026782 for ; Thu, 6 Mar 2003 04:20:52 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h26CKqdd026780 for linux-xfs@oss.sgi.com; Thu, 6 Mar 2003 04:20:52 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h26CKnq9026766 for ; Thu, 6 Mar 2003 04:20:49 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h26BkFv2025816; Thu, 6 Mar 2003 03:46:15 -0800 Date: Thu, 6 Mar 2003 03:46:15 -0800 Message-Id: <200303061146.h26BkFv2025816@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 227] unmount fail X-Bugzilla-Reason: AssignedTo X-archive-position: 3073 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 410 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=227 ------- Additional Comments From grandsonata@netscape.net 2003-03-06 03:46 ------- Hi Olaf let me know if you capture some results as to what cause umounting fail. machine just hung there when umounting. ctr+alt+del does not work. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 6 06:20:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 06:20:45 -0800 (PST) Received: from w1301.hostcentric.net (w1301.hostcentric.net [209.25.197.254]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26EKdq9007108 for ; Thu, 6 Mar 2003 06:20:40 -0800 Received: (qmail 12876 invoked by alias); 6 Mar 2003 14:20:37 -0000 Received: from unknown (HELO avalanche) (195.228.226.66) by 0 with SMTP; 6 Mar 2003 14:20:37 -0000 Message-ID: <007001c2e3eb$9ff13500$0104a8c0@avalanche> Reply-To: "Gabor Forgacs" From: "Gabor Forgacs" To: "xfs mailing list" Subject: direct io performance problem Date: Thu, 6 Mar 2003 15:21:04 +0100 Organization: Colorfront MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-archive-position: 3074 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: gabor@colorfront.com Precedence: bulk X-list: linux-xfs Content-Length: 1428 Lines: 47 Hi all we are testing the disk speed on linux, here how it is going: Test System kernel: 2.4.20 and 2.4.18 hardware: IBM Z-PRO , qlogic 2342 driver 6.4, 7-7 disks md parameters: chunck_size 32 XFS: i used the latest cvs version of the xfs (2.0) file sequence test were done with 12mb files whitout any previuos cached buffer all the files were read with one request (that is what we need) - xfs filesystem with direct-io with one thread reading can scale up to 220-230 Mb/sec with relativly low cpu load - xfs filesystem with direct-io with more than one thread is only capable ~100 mb/sec here probably there is some locking issue in the filesystem - xfs without direct-io can produce ~260-280 mb/sec with pretty high cpu load ,here the cpu load is probably related to the caching - ext3 is about the same like xfs without direct-io So right now, we can do fast diskio but unable to do anything else because it ruins the disk performance. What is your experience did you manage to get higher disk speed values on linux ? Any idea what else could we try? the same system under windos 2000 can do a sustain 300/310 mb/sec i suspect there is some bottleneck in the direct io implementation on linux. if the cached version can do 260-280 mb/sec with the extra memcpy then the driver should be fast enough to do the task. is there any recommendation to get the same io rate like on windows ? Thank You gabor forgacs From owner-linux-xfs@oss.sgi.com Thu Mar 6 06:41:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 06:41:51 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26Ef7q9009239 for ; Thu, 6 Mar 2003 06:41:48 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18qwYT-0002f2-00; Thu, 06 Mar 2003 14:41:05 +0000 Date: Thu, 6 Mar 2003 14:41:05 +0000 From: Christoph Hellwig To: Gabor Forgacs Cc: xfs mailing list Subject: Re: direct io performance problem Message-ID: <20030306144105.A10089@infradead.org> References: <007001c2e3eb$9ff13500$0104a8c0@avalanche> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <007001c2e3eb$9ff13500$0104a8c0@avalanche>; from gabor@colorfront.com on Thu, Mar 06, 2003 at 03:21:04PM +0100 X-archive-position: 3075 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: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 295 Lines: 9 On Thu, Mar 06, 2003 at 03:21:04PM +0100, Gabor Forgacs wrote: > Hi all > > we are testing the disk speed on linux, here how it is going: I'd suggest using vendors kernel (i.e. the XFS patches redhat RPMs or SuSE's tree, they have certain important I/O fixes that mainline is still missing). From owner-linux-xfs@oss.sgi.com Thu Mar 6 07:29:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 07:29:07 -0800 (PST) Received: from w1301.hostcentric.net (w1301.hostcentric.net [209.25.197.254]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26FT2q9014922 for ; Thu, 6 Mar 2003 07:29:03 -0800 Received: (qmail 12498 invoked by alias); 6 Mar 2003 15:29:00 -0000 Received: from unknown (HELO avalanche) (195.228.226.66) by 0 with SMTP; 6 Mar 2003 15:29:00 -0000 Message-ID: <00ab01c2e3f5$2d5cbbe0$0104a8c0@avalanche> Reply-To: "Gabor Forgacs" From: "Gabor Forgacs" To: "Christoph Hellwig" Cc: "xfs mailing list" References: <007001c2e3eb$9ff13500$0104a8c0@avalanche> <20030306144105.A10089@infradead.org> Subject: Re: direct io performance problem Date: Thu, 6 Mar 2003 16:29:27 +0100 Organization: Colorfront MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-archive-position: 3076 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: gabor@colorfront.com Precedence: bulk X-list: linux-xfs Content-Length: 656 Lines: 24 hi christoph which rpms do you advice could you point me there (we use rpm)? thank you ----- Original Message ----- From: "Christoph Hellwig" To: "Gabor Forgacs" Cc: "xfs mailing list" Sent: Thursday, March 06, 2003 3:41 PM Subject: Re: direct io performance problem > On Thu, Mar 06, 2003 at 03:21:04PM +0100, Gabor Forgacs wrote: > > Hi all > > > > we are testing the disk speed on linux, here how it is going: > > I'd suggest using vendors kernel (i.e. the XFS patches redhat RPMs > or SuSE's tree, they have certain important I/O fixes that mainline > is still missing). > > From owner-linux-xfs@oss.sgi.com Thu Mar 6 07:32:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 07:32:38 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26FWXq9015238 for ; Thu, 6 Mar 2003 07:32:34 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18qxMH-0002yr-00; Thu, 06 Mar 2003 15:32:33 +0000 Date: Thu, 6 Mar 2003 15:32:32 +0000 From: Christoph Hellwig To: Gabor Forgacs Cc: xfs mailing list Subject: Re: direct io performance problem Message-ID: <20030306153232.A11335@infradead.org> References: <007001c2e3eb$9ff13500$0104a8c0@avalanche> <20030306144105.A10089@infradead.org> <00ab01c2e3f5$2d5cbbe0$0104a8c0@avalanche> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <00ab01c2e3f5$2d5cbbe0$0104a8c0@avalanche>; from gabor@colorfront.com on Thu, Mar 06, 2003 at 04:29:27PM +0100 X-archive-position: 3077 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: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 588 Lines: 18 On Thu, Mar 06, 2003 at 04:29:27PM +0100, Gabor Forgacs wrote: > hi christoph > > which rpms do you advice could you point me there (we use rpm)? > thank you RedHat-based: ftp://oss.sgi.com/projects/xfs/Release-1.2/kernel_rpms/2.4.18-18-RH/ SuSE: ftp://ftp.suse.com/pub/people/mantel/next/RPM/ Note that the RedHAT RPMs are not based on their latest errata, there are people who have patches their latest errata kernels with XFS, but Redat disabled O_DIRECT in never kernels, so you'll have to decide whether you want their latests fix, working O_DIRECT or hack the kernel yourself. From owner-linux-xfs@oss.sgi.com Thu Mar 6 07:56:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 07:56:35 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26FuVq9017596 for ; Thu, 6 Mar 2003 07:56:32 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h26FuQnH009988 for ; Thu, 6 Mar 2003 07:56:26 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA82698 for ; Thu, 6 Mar 2003 09:56:25 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA45975 for ; Thu, 6 Mar 2003 09:56:26 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h26FuPr26163; Thu, 6 Mar 2003 09:56:25 -0600 Message-Id: <200303061556.h26FuPr26163@jen.americas.sgi.com> Date: Thu, 6 Mar 2003 09:56:25 -0600 Subject: TAKE - tweak io completion thread count again X-archive-position: 3078 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 477 Lines: 17 move back to a thread per cpu for I/O completion, we had second thoughts about this. Experiments in progress to use a new model here, but in the mean time, stick to one thread per cpu. Date: Thu Mar 6 07:56:00 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141108a linux/fs/xfs/pagebuf/page_buf.c - 1.103 - define MAX_IO_DAEMONS as NR_CPUS From owner-linux-xfs@oss.sgi.com Thu Mar 6 11:39:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 11:39:20 -0800 (PST) Received: from hotmail.com (f65.sea2.hotmail.com [207.68.165.65]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26JcZq9006231 for ; Thu, 6 Mar 2003 11:39:13 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 6 Mar 2003 11:38:30 -0800 Received: from 208.244.233.175 by sea2fd.sea2.hotmail.msn.com with HTTP; Thu, 06 Mar 2003 19:38:29 GMT X-Originating-IP: [208.244.233.175] From: "Rick Smith" To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Subject: files written in multiple fragments Date: Thu, 06 Mar 2003 11:38:29 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Mar 2003 19:38:30.0231 (UTC) FILETIME=[F7303E70:01C2E417] X-archive-position: 3079 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: rgsmith72@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 2514 Lines: 57 Steve, I have encountered another oddity while writing successive files to my high speed XFS partition under linux. The problem that I am seeing is that files are intermittently written in several 1024 block fragments. This filesystem has been performing well for the past two weeks with many directories created, many files written, and many directories deleted. While this would normally not be a problem, it is a big performance hit when it comes time to read the file. Do you have any suggestions on how I might prevent this behavior? I have included the xfs_info and xfs_bmap output below. Thanks. Rick meta-data=/test isize=256 agcount=172, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=179566240, imaxpct=25 = sunit=1 swidth=10 blks, unwritten=0 naming =version 2 bsize=4096 log =external bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=40960 blocks=0, rtextents=0 test.36.data: 0: [0..10799]: 1368218048..1368228847 test.37.data: 0: [0..1023]: 1367828040..1367829063 1: [1024..2047]: 1367827016..1367828039 2: [2048..3071]: 1367825992..1367827015 3: [3072..4095]: 1367824968..1367825991 4: [4096..5119]: 1367823944..1367824967 5: [5120..6143]: 1367822920..1367823943 6: [6144..7167]: 1367821896..1367822919 7: [7168..8191]: 1367820872..1367821895 8: [8192..9215]: 1367819848..1367820871 9: [9216..10239]: 1367818824..1367819847 10: [10240..10799]: 1367818256..1367818815 test.38.data: 0: [0..10799]: 1368228848..1368239647 test.39.data: 0: [0..1023]: 1367817232..1367818255 1: [1024..2047]: 1367816208..1367817231 2: [2048..3071]: 1367815184..1367816207 3: [3072..4095]: 1367814160..1367815183 4: [4096..5119]: 1367813136..1367814159 5: [5120..6143]: 1367812112..1367813135 6: [6144..7167]: 1367811088..1367812111 7: [7168..8191]: 1367810064..1367811087 8: [8192..9215]: 1367809040..1367810063 9: [9216..10239]: 1367808016..1367809039 10: [10240..10799]: 1367807448..1367808007 _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail From owner-linux-xfs@oss.sgi.com Thu Mar 6 13:38:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 13:38:44 -0800 (PST) Received: from mailout1.echostar.com (mailout1.echostar.com [204.76.128.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26Lbuq9013872 for ; Thu, 6 Mar 2003 13:38:37 -0800 Received: from riv-exchcon.echostar.com ([10.1.200.73]) by 10.0.221.101 with InterScan Messaging Security Suite; Thu, 06 Mar 2003 14:38:21 -0700 Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 14:37:50 -0700 Received: from echostar.com (linux1.echostar.com [10.79.98.101]) by riv-exchcon.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GHS29Q1M; Thu, 6 Mar 2003 14:37:43 -0700 From: "Buzbee, James" To: linux-xfs@oss.sgi.com Message-ID: <3E67BFA7.4080601@echostar.com> Date: Thu, 06 Mar 2003 14:37:43 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: LBA to File? X-Enigmail-Version: 0.62.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3080 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: James.Buzbee@echostar.com Precedence: bulk X-list: linux-xfs Content-Length: 479 Lines: 13 We've been running an IDE analyzer on our system in order to better understand the pattern of disk usage for our application. We're seeing what appears to be a high number of writes to a particular area of the drive, and we're having trouble determining what is being accessed. The analyzer gives us output in terms of LBA accesses. Is there an easy way to translate an LBA address into a particular file or perhaps an internal XFS data structure? Thanks, Jim Buzbee From owner-linux-xfs@oss.sgi.com Thu Mar 6 13:48:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 13:48:59 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26Lmoq9014503 for ; Thu, 6 Mar 2003 13:48:51 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id D2139149FB; Thu, 6 Mar 2003 22:48:44 +0100 (MET) Subject: Re: LBA to File? From: Andi Kleen To: "Buzbee, James" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E67BFA7.4080601@echostar.com> References: <3E67BFA7.4080601@echostar.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 06 Mar 2003 22:48:43 +0100 Message-Id: <1046987324.1511.193.camel@averell> Mime-Version: 1.0 X-archive-position: 3081 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: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 621 Lines: 16 On Thu, 2003-03-06 at 22:37, Buzbee, James wrote: > We've been running an IDE analyzer on our system in order to better > understand the pattern of disk usage for our application. We're seeing > what appears to be a high number of writes to a particular area of the > drive, and we're having trouble determining what is being accessed. The > analyzer gives us output in terms of LBA accesses. Is there an easy way > to translate an LBA address into a particular file or perhaps an > internal XFS data structure? I bet it is the XFS log. You can test by moving it to another partition or another disk. -Andi From owner-linux-xfs@oss.sgi.com Thu Mar 6 13:56:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 13:56:11 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26LtTq9015217 for ; Thu, 6 Mar 2003 13:56:09 -0800 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id h26LtRk15656; Thu, 6 Mar 2003 16:55:27 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 6 Mar 2003 16:55:27 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: "Buzbee, James" cc: linux-xfs@oss.sgi.com Subject: Re: LBA to File? In-Reply-To: <3E67BFA7.4080601@echostar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3082 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: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 685 Lines: 18 On Thu, 6 Mar 2003 at 2:37pm, Buzbee, James wrote > We've been running an IDE analyzer on our system in order to better > understand the pattern of disk usage for our application. We're seeing > what appears to be a high number of writes to a particular area of the > drive, and we're having trouble determining what is being accessed. The > analyzer gives us output in terms of LBA accesses. Is there an easy way > to translate an LBA address into a particular file or perhaps an > internal XFS data structure? I don't know, but I'd hazard a guess that what you're seeing are journal writes... -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu Mar 6 14:05:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 14:05:18 -0800 (PST) Received: from mailout1.echostar.com (mailout1.echostar.com [204.76.128.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26M59q9016125 for ; Thu, 6 Mar 2003 14:05:10 -0800 Received: from riv-exchcon.echostar.com ([10.1.200.73]) by 10.0.221.101 with InterScan Messaging Security Suite; Thu, 06 Mar 2003 15:05:31 -0700 Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 15:04:59 -0700 Received: from echostar.com (linux1.echostar.com [10.79.98.101]) by riv-exchcon.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GHS29TBT; Thu, 6 Mar 2003 15:04:52 -0700 From: "Buzbee, James" To: Andi Kleen Cc: linux-xfs@oss.sgi.com Message-ID: <3E67C603.8040107@echostar.com> Date: Thu, 06 Mar 2003 15:04:51 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: LBA to File? References: <3E67BFA7.4080601@echostar.com> <1046987324.1511.193.camel@averell> X-Enigmail-Version: 0.62.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3083 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: James.Buzbee@echostar.com Precedence: bulk X-list: linux-xfs Content-Length: 879 Lines: 34 Andi Kleen wrote: > On Thu, 2003-03-06 at 22:37, Buzbee, James wrote: > >>We've been running an IDE analyzer on our system in order to better >>understand the pattern of disk usage for our application. We're seeing >>what appears to be a high number of writes to a particular area of the >>drive, and we're having trouble determining what is being accessed. The >>analyzer gives us output in terms of LBA accesses. Is there an easy way >>to translate an LBA address into a particular file or perhaps an >>internal XFS data structure? > > > I bet it is the XFS log. We actually see the writes occuring in two distinct areas on the drive. Would journal accesses show up this way? > > You can test by moving it to another partition or another disk. > We are in a single disk system using an internal log. Is there any way to move it ? Jim > -Andi > > From owner-linux-xfs@oss.sgi.com Thu Mar 6 14:13:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 14:14:00 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26MDuq9017044 for ; Thu, 6 Mar 2003 14:13:56 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h26MDonH020714 for ; Thu, 6 Mar 2003 14:13:51 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA44935; Thu, 6 Mar 2003 16:13:50 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h26MDoCI4856722; Thu, 6 Mar 2003 16:13:50 -0600 (CST) Subject: Re: LBA to File? From: Eric Sandeen To: "Buzbee, James" Cc: Andi Kleen , linux-xfs@oss.sgi.com In-Reply-To: <3E67C603.8040107@echostar.com> References: <3E67BFA7.4080601@echostar.com> <1046987324.1511.193.camel@averell> <3E67C603.8040107@echostar.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 06 Mar 2003 16:13:29 -0600 Message-Id: <1046988809.438.267.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 3084 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 741 Lines: 24 On Thu, 2003-03-06 at 16:04, Buzbee, James wrote: > > We actually see the writes occuring in two distinct areas on the drive. > Would journal accesses show up this way? The superblock could also be getting written a lot. > We are in a single disk system using an internal log. Is there any way > to move it ? While you can move an internal log with some xfs_db wizardry, it would probably be easiest to just re-make your fs with an external log on another partition. (oh, and there is also an undocumented mkfs option to put an internal log in a different AG... have to check the xfs_mkfs.c source). -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Mar 6 14:16:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 14:16:35 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26MGVq9017698 for ; Thu, 6 Mar 2003 14:16:31 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 700B81830E0C; Thu, 6 Mar 2003 14:16:31 -0800 (PST) Date: Thu, 6 Mar 2003 14:16:31 -0800 From: Chris Wedgwood To: "Buzbee, James" Cc: linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030306221631.GA6770@f00f.org> References: <3E67BFA7.4080601@echostar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E67BFA7.4080601@echostar.com> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 3085 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 708 Lines: 23 On Thu, Mar 06, 2003 at 02:37:43PM -0700, Buzbee, James wrote: > We've been running an IDE analyzer on our system in order to better > understand the pattern of disk usage for our application. We're > seeing what appears to be a high number of writes to a particular > area of the drive, and we're having trouble determining what is > being accessed. Is this near the middle of the fs? --- if so, it's likely an internal log. > The analyzer gives us output in terms of LBA accesses. Is there an > easy way to translate an LBA address into a particular file or > perhaps an internal XFS data structure? LBA -> block should be possible Finding the file for that would be expensive but doable. --cw From owner-linux-xfs@oss.sgi.com Thu Mar 6 14:26:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 14:26:36 -0800 (PST) Received: from mailout2.echostar.com (mailout2.echostar.com [204.76.128.102]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26MQSq9019001 for ; Thu, 6 Mar 2003 14:26:30 -0800 Received: from riv-exchcon.echostar.com ([10.1.200.73]) by 10.0.221.102 with InterScan Messaging Security Suite; Thu, 06 Mar 2003 15:25:44 -0700 Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 15:26:22 -0700 Received: from echostar.com (linux1.echostar.com [10.79.98.101]) by riv-exchcon.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GHS29V08; Thu, 6 Mar 2003 15:26:18 -0700 From: "Buzbee, James" To: linux-xfs@oss.sgi.com Message-ID: <3E67CB02.2030600@echostar.com> Date: Thu, 06 Mar 2003 15:26:10 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: LBA to File? References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> X-Enigmail-Version: 0.62.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3086 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: James.Buzbee@echostar.com Precedence: bulk X-list: linux-xfs Content-Length: 569 Lines: 20 Chris Wedgwood wrote: > On Thu, Mar 06, 2003 at 02:37:43PM -0700, Buzbee, James wrote: > > >>We've been running an IDE analyzer on our system in order to better >>understand the pattern of disk usage for our application. We're >>seeing what appears to be a high number of writes to a particular >>area of the drive, and we're having trouble determining what is >>being accessed. > > > Is this near the middle of the fs? --- if so, it's likely an internal > log. We're seeing two areas. One near the start of the partition, the other in the middle. Jim From owner-linux-xfs@oss.sgi.com Thu Mar 6 14:51:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 14:51:52 -0800 (PST) Received: from mailout1.echostar.com (mailout1.echostar.com [204.76.128.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26Mp7q9020375 for ; Thu, 6 Mar 2003 14:51:47 -0800 Received: from riv-exchcon.echostar.com ([10.1.200.73]) by 10.0.221.101 with InterScan Messaging Security Suite; Thu, 06 Mar 2003 15:51:32 -0700 Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 15:51:00 -0700 Received: from echostar.com (linux1.echostar.com [10.79.98.101]) by riv-exchcon.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GHS2953N; Thu, 6 Mar 2003 15:50:55 -0700 From: "Buzbee, James" To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Message-ID: <3E67D0CE.3080902@echostar.com> Date: Thu, 06 Mar 2003 15:50:54 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: LBA to File? References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> X-Enigmail-Version: 0.62.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3087 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: James.Buzbee@echostar.com Precedence: bulk X-list: linux-xfs Content-Length: 487 Lines: 25 Eric Sandeen wrote: > On Thu, 2003-03-06 at 16:26, Buzbee, James wrote: > > >>We're seeing two areas. One near the start of the partition, the other > > > Superblock... > > >>in the middle. > > > ... and log. > > -Eric > The scary thing about what we are seeing is that the "grown defect list" on the disk is showing a lot of sectors in these two areas. It's almost as if we are wearing out the sectors in these areas by writing them so often. Strange but true ;-( Jim From owner-linux-xfs@oss.sgi.com Thu Mar 6 15:15:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 15:15:46 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26NFcq9021846 for ; Thu, 6 Mar 2003 15:15:39 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 79B95149C2; Fri, 7 Mar 2003 00:14:54 +0100 (MET) Subject: Re: LBA to File? From: Andi Kleen To: "Buzbee, James" Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <3E67D0CE.3080902@echostar.com> References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> <3E67D0CE.3080902@echostar.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 07 Mar 2003 00:14:53 +0100 Message-Id: <1046992493.1388.235.camel@averell> Mime-Version: 1.0 X-archive-position: 3088 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: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 974 Lines: 27 On Thu, 2003-03-06 at 23:50, Buzbee, James wrote: > The scary thing about what we are seeing is that the "grown defect list" > on the disk is showing a lot of sectors in these two areas. It's almost > as if we are wearing out the sectors in these areas by writing them so > often. Strange but true ;-( It was long suspected that journaling FS are bad for cheap IDE disks, but you're probably the first to really verify it using an IDE analyzer. There were also some informal experiences on that collected by the reiserfs people. Thanks for verify this. For that it would be actually nice to have some way to relocate the journal offline or better online. Then you could just move the journal around a bit once a week and avoid these problems. However you would need enough free space as the journal can only move into free space. I guess offline (umounted fs) would be already possible with XFS with some tweaks. Just don't fill the disk over 90% or so. -Andi From owner-linux-xfs@oss.sgi.com Thu Mar 6 15:34:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 15:34:25 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h26NYIq9023111 for ; Thu, 6 Mar 2003 15:34:19 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h26Nimkq011077 for ; Thu, 6 Mar 2003 17:44:48 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA72428; Thu, 6 Mar 2003 17:34:12 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h26NYBCI4856448; Thu, 6 Mar 2003 17:34:11 -0600 (CST) Subject: Re: LBA to File? From: Eric Sandeen To: Andi Kleen Cc: "Buzbee, James" , linux-xfs@oss.sgi.com In-Reply-To: <1046992493.1388.235.camel@averell> References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> <3E67D0CE.3080902@echostar.com> <1046992493.1388.235.camel@averell> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 06 Mar 2003 17:33:50 -0600 Message-Id: <1046993631.440.280.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 3089 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 864 Lines: 22 > For that it would be actually nice to have some way to relocate the > journal offline or better online. Then you could just move the journal > around a bit once a week and avoid these problems. That's on the XFS todo list (even documented as "unimplemented" in the xfs_growfs man page...) I looked at it a bit, shouldn't be too hard, but need some time to do it. Moving it offline is pretty easy, could do it with an xfs_db script wrapper, I think. Hm, I suppose that for the truly paranoid, with cheap IDE disks, there could be an option to rotate an internal log through the AGs each time you mount. Of course that would be a lot of space sitting idle most of the time, but it's probably better than trashing the disk... :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Mar 6 16:33:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 16:34:01 -0800 (PST) Received: from mailout1.echostar.com (mailout1.echostar.com [204.76.128.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h270Xrq9025086 for ; Thu, 6 Mar 2003 16:33:54 -0800 Received: from riv-exchcon.echostar.com ([10.1.200.73]) by 10.0.221.101 with InterScan Messaging Security Suite; Thu, 06 Mar 2003 17:34:15 -0700 Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 17:33:44 -0700 Received: from echostar.com (linux1.echostar.com [10.79.98.101]) by riv-exchcon.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GHS20D99; Thu, 6 Mar 2003 17:33:35 -0700 From: "Buzbee, James" To: Eric Sandeen Cc: Andi Kleen , linux-xfs@oss.sgi.com Message-ID: <3E67E8DF.30700@echostar.com> Date: Thu, 06 Mar 2003 17:33:35 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: LBA to File? References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> <3E67D0CE.3080902@echostar.com> <1046992493.1388.235.camel@averell> <1046993631.440.280.camel@stout.americas.sgi.com> X-Enigmail-Version: 0.62.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3090 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: James.Buzbee@echostar.com Precedence: bulk X-list: linux-xfs Content-Length: 368 Lines: 16 Eric Sandeen wrote: ... > Hm, I suppose that for the truly paranoid, with cheap IDE disks, there > could be an option to rotate an internal log through the AGs each > time you mount. Of course that would be a lot of space sitting idle > most of the time, but it's probably better than trashing the disk... :) Yep, it would help our situation :-) > > -Eric > From owner-linux-xfs@oss.sgi.com Thu Mar 6 16:39:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 16:39:13 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h270cTq9026102 for ; Thu, 6 Mar 2003 16:39:09 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h270cNnH030318 for ; Thu, 6 Mar 2003 16:38:23 -0800 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA99537; Thu, 6 Mar 2003 18:38:22 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-25.corp.sgi.com [134.15.64.25]) by tulip-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h270cL6511182576; Thu, 6 Mar 2003 18:38:22 -0600 (CST) Subject: Re: LBA to File? From: Stephen Lord To: "Buzbee, James" Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <3E67D0CE.3080902@echostar.com> References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> <3E67D0CE.3080902@echostar.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 06 Mar 2003 18:36:51 -0600 Message-Id: <1046997413.1373.14.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 3091 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1319 Lines: 31 On Thu, 2003-03-06 at 16:50, Buzbee, James wrote: > > The scary thing about what we are seeing is that the "grown defect list" > on the disk is showing a lot of sectors in these two areas. It's almost > as if we are wearing out the sectors in these areas by writing them so > often. Strange but true ;-( > > Jim > Ugh, yes these will be continually written to, the log in particular, I like Eric's idea, but the scope of that is fairly drastic and it will only postpone the inevitable - you can probably do the math to work out how long the drive will run before it runs out of bad blocks to remap to. All running with alternating logs would do is delay the drive becoming scrap metal. The reliability of these devices may not be up to the load you are placing on them. Not all ide drives are this bad, I have been running xfs on the same ide drive for about 3 years now - but then I am not running a PVR. I suspect also you may have the write cache turned off to avoid errors after a crash. Possibly the way your app runs is making things worse. There is a script in the cmd/misc directory called xfsstats.pl you can watch log activity with this. In particular xs_log_writes and xs_log_blocks. If log_blocks is not a reasonable multiple of log_writes then you are doing a lot of very small writes. Steve From owner-linux-xfs@oss.sgi.com Thu Mar 6 16:48:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 16:48:14 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h270mBq9027338 for ; Thu, 6 Mar 2003 16:48:12 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h26Md9nH022479 for ; Thu, 6 Mar 2003 14:39:09 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA59214; Thu, 6 Mar 2003 16:39:08 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h26Md8CI4794361; Thu, 6 Mar 2003 16:39:08 -0600 (CST) Subject: Re: LBA to File? From: Eric Sandeen To: "Buzbee, James" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E67CB02.2030600@echostar.com> References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 06 Mar 2003 16:38:48 -0600 Message-Id: <1046990328.439.273.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 3092 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 302 Lines: 16 On Thu, 2003-03-06 at 16:26, Buzbee, James wrote: > We're seeing two areas. One near the start of the partition, the other Superblock... > in the middle. ... and log. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Mar 6 17:42:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 17:42:41 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h271gXq9003079 for ; Thu, 6 Mar 2003 17:42:34 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h271gSbw015765 for ; Thu, 6 Mar 2003 17:42:28 -0800 From: "l.a walsh" To: Subject: Just some odd questions out of the blue... Date: Thu, 6 Mar 2003 17:42:28 -0800 Message-ID: <00a501c2e44a$cfaba280$1403a8c0@sc.tlinx.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 3093 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: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 2158 Lines: 52 I was reading a bit through the messages about high activity in the log file area of the disk. Seems like ...well...that's likely going to up the #seeks needed for writes, right? So lets say you had 2 disks...would it make sense to put the log of disk1 on disk2 and the log of disk2 on disk1? This would be under the assumption, that most often, you will be writing to 1 of the two disks (RAID stuff excluded from this meandering). Seems like if 90% of the time you are going to be writing to only 1 disk at a time, it could really eliminate excessive seekage and theoretically up throughput. Second question ... suppose one disk was faster than the other -- or one was a sda and the other hda. How much metadata is written compared to file data, i.e. is there some average ratio or range? On the assumption that metadata is smaller, seem like one could use a slower log disk for a primary work disk, and the slower log disk is mostly archival things that aren't written alot, but more read alot -- like mp3's, or CD images....things where the slower read isn't going to be a big problem. When writing to disks with a cache, does XFS force any flushes (like on log data?) Seem like even if you had a slower disk but an 8Mb cache you could keep up with a fairly good write speed on the faster disk. Dunno.... But here's another Q...if you don't flush the on disk cache after a log write, then it is 'granted' that the potential for metadata loss is at least the size of the on-disk cache. That could beg the question -- would it be of any benefit to write a pseudo-block device that lives on top of a disk that just does read-write caching -- maybe it lives with a 64Mb Buffer and attempts to use geometry knowledge of the disk to optimize head motion, whatever. But the point there, being, you could lose 64Mb of log data if the write-log function doesn't flush. If it does flush..well, that would eliminate much of the benefit of an off-disk pseudo device as well as the on-disk cache....some how that seems unfortunate. Maybe this is a 'tuneable' --write-log=sync/async? sorry for the meandering...just bouncing around ideas.... -linda From owner-linux-xfs@oss.sgi.com Thu Mar 6 17:55:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 17:55:08 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h271sjq9004394 for ; Thu, 6 Mar 2003 17:55:06 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2725Ekq012948 for ; Thu, 6 Mar 2003 20:05:15 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h271rM7L1099401 for ; Fri, 7 Mar 2003 12:53:22 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h271rMGX1099599 for linux-xfs@oss.sgi.com; Fri, 7 Mar 2003 12:53:22 +1100 (EST) Date: Fri, 7 Mar 2003 12:53:22 +1100 (EST) From: Nathan Scott Message-Id: <200303070153.h271rMGX1099599@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs X-archive-position: 3094 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 372 Lines: 14 Need to define cmn_err in libxfs for all gcc versions, ie. with both of the supported incantations of varargs cpp macros. Date: Thu Mar 6 17:52:48 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: xfs-cmds:slinx:141165a cmd/xfsprogs/libxfs/xfs.h - 1.30 From owner-linux-xfs@oss.sgi.com Thu Mar 6 18:00:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 18:00:54 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2720Iq9005627 for ; Thu, 6 Mar 2003 18:00:19 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2720D9n002633 for ; Thu, 6 Mar 2003 18:00:13 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA07884; Thu, 6 Mar 2003 20:00:12 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2720CCJ4831819; Thu, 6 Mar 2003 20:00:12 -0600 (CST) Date: Thu, 6 Mar 2003 19:59:50 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: "l.a walsh" cc: linux-xfs@oss.sgi.com Subject: Re: Just some odd questions out of the blue... In-Reply-To: <00a501c2e44a$cfaba280$1403a8c0@sc.tlinx.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3095 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1945 Lines: 47 On Thu, 6 Mar 2003, l.a walsh wrote: > So lets say you had 2 disks...would it make sense to put the log > of disk1 on disk2 and the log of disk2 on disk1? This would be Yes, external logs are available for this reason. Your cross-log scenario would probably only help if you were really only writing to 1 fs at a time. > Second question ... suppose one disk was faster than the other -- > or one was a sda and the other hda. How much metadata is written > compared to file data, i.e. is there some average ratio or range? You can look at the stats with the xfs_stats.pl script in cvs. It really depends on the nature of your workload. > On the assumption that metadata is smaller, seem like one could use > a slower log disk for a primary work disk, and the slower log disk > is mostly archival things that aren't written alot, but more read > alot -- like mp3's, or CD images....things where the slower read isn't > going to be a big problem. True, for reads the log speed isn't critical, but for writes again it will depend on your workload. > When writing to disks with a cache, does XFS force any flushes (like > on log data?) Seem like even if you had a slower disk but an 8Mb > cache you could keep up with a fairly good write speed on the faster > disk. Which is great until you crash, if the cached data is lost... I don't think xfs explicitly does any ide cache flushing. > But here's another Q...if you don't flush the on disk cache after > a log write, then it is 'granted' that the potential for metadata > loss is at least the size of the on-disk cache. That could beg > the question -- would it be of any benefit to write a pseudo-block > device that lives on top of a disk that just does read-write > caching -- maybe it lives with a 64Mb Buffer and attempts to use > geometry knowledge of the disk to optimize head motion, whatever. Ick. :) I think the drive mfgr is the only one who has the knowledge. -Eric From owner-linux-xfs@oss.sgi.com Thu Mar 6 20:43:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Mar 2003 20:43:45 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h274haq9021389 for ; Thu, 6 Mar 2003 20:43:37 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h274s5kq015232 for ; Thu, 6 Mar 2003 22:54:06 -0600 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA25931 for ; Fri, 7 Mar 2003 15:42:14 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 3634C300087; Fri, 7 Mar 2003 15:42:14 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 32EF88F for ; Fri, 7 Mar 2003 15:42:14 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: lbs 2.1.2 builds for i386 again Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Mar 2003 15:42:09 +1100 Message-ID: <32686.1047012129@kao2.melbourne.sgi.com> X-archive-position: 3096 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: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 122 Lines: 3 XFS developers who are working on lbs 2.1.2 - PV 883422 means that lbs t-o-t will build again for i386 with kdb enabled. From owner-linux-xfs@oss.sgi.com Fri Mar 7 03:08:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 03:08:48 -0800 (PST) Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27B7xq9007934 for ; Fri, 7 Mar 2003 03:08:40 -0800 Received: from kenzo.iwr.uni-heidelberg.de (kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.11.2/8.11.1) with ESMTP id h27B7vP22647; Fri, 7 Mar 2003 12:07:57 +0100 (MET) Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.11.6/8.11.6) with ESMTP id h27B7r130949; Fri, 7 Mar 2003 12:07:53 +0100 Date: Fri, 7 Mar 2003 12:07:53 +0100 (CET) From: Bogdan Costescu To: Eric Sandeen cc: Andi Kleen , "Buzbee, James" , Subject: Re: LBA to File? In-Reply-To: <1046993631.440.280.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3097 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: bogdan.costescu@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs Content-Length: 1256 Lines: 30 On 6 Mar 2003, Eric Sandeen wrote: > Hm, I suppose that for the truly paranoid, with cheap IDE disks, No, not only for them. The frequent access exists for all drives and will destroy a high-end SCSI disk just as well, but maybe not as fast. > there could be an option to rotate an internal log through the AGs each > time you mount. Ehh, how about those using XFS on file servers that have to have an uptime of hundreds of days ? Changing its place online would be bliss... However, placing the journal seems to raise the problem: where ? As it's accessed often, it should be on the area of the disk where speed is maximum (speed = read+write+seek). But if it's moved, can the new location be controlled somehow so that it doesn't accidentally end up in an area with low speed ? Of course, that does mean that free space has to exist at the new location. That begs the question: could defragmentation or something similar take care of creating free space at a specific location on disk ? -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From owner-linux-xfs@oss.sgi.com Fri Mar 7 05:56:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 05:56:17 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27Du5q9032387 for ; Fri, 7 Mar 2003 05:56:06 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h27Du09n010453 for ; Fri, 7 Mar 2003 05:56:00 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA03484; Fri, 7 Mar 2003 07:55:59 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h27DtwCJ4893675; Fri, 7 Mar 2003 07:55:59 -0600 (CST) Date: Fri, 7 Mar 2003 07:55:32 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Bogdan Costescu cc: Andi Kleen , "Buzbee, James" , Subject: Re: LBA to File? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3098 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1824 Lines: 41 On Fri, 7 Mar 2003, Bogdan Costescu wrote: > On 6 Mar 2003, Eric Sandeen wrote: > > > Hm, I suppose that for the truly paranoid, with cheap IDE disks, > > No, not only for them. The frequent access exists for all drives and > will destroy a high-end SCSI disk just as well, but maybe not as fast. I think it's important to remember that XFS has been in use for -many- years on irix, on everything from personal desktops to huge servers with filesystems on the order of tens of terabytes. While I'm sure that usage patterns will affect the life of any device, I don't think that this has been a problem in general. (And, I can think of other disk usages patterns which could result in disproportional use of one area of a disk - /var/log partitions, for example). > Ehh, how about those using XFS on file servers that have to have an uptime > of hundreds of days ? Changing its place online would be bliss... Actually if this were implemented, a quick xfs_freeze/log move/xfs_thaw would be plausible. > However, placing the journal seems to raise the problem: where ? As it's > accessed often, it should be on the area of the disk where speed is > maximum (speed = read+write+seek). But if it's moved, can the new location > be controlled somehow so that it doesn't accidentally end up in an area > with low speed ? Of course, that does mean that free space has to exist at > the new location. That begs the question: could defragmentation or > something similar take care of creating free space at a specific location > on disk ? I think you're asking too much here... I think each individual disk would need to be profiled to even know where the "fast" spots are. And then technically, the log could go anywhere, but I think that for the effort involved, the returns would not be that great. -Eric From owner-linux-xfs@oss.sgi.com Fri Mar 7 06:17:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 06:17:08 -0800 (PST) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27EH1q9002800 for ; Fri, 7 Mar 2003 06:17:02 -0800 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZBLDPQR6; Fri, 7 Mar 2003 09:17:29 -0500 Received: from wgate.com (localhost.localdomain [127.0.0.1]) by sinz.eng.tvol.net (8.12.8/8.12.5) with ESMTP id h27EFvfj027384; Fri, 7 Mar 2003 09:15:58 -0500 Message-ID: <3E68A99D.4060301@wgate.com> Date: Fri, 07 Mar 2003 09:15:57 -0500 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bogdan Costescu CC: Eric Sandeen , Andi Kleen , "Buzbee, James" , linux-xfs@oss.sgi.com Subject: Re: LBA to File? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3099 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: msinz@wgate.com Precedence: bulk X-list: linux-xfs Content-Length: 2417 Lines: 52 Bogdan Costescu wrote: > On 6 Mar 2003, Eric Sandeen wrote: > > >>Hm, I suppose that for the truly paranoid, with cheap IDE disks, > > > No, not only for them. The frequent access exists for all drives and > will destroy a high-end SCSI disk just as well, but maybe not as fast. I would think that all of this "worry" is not a major issue. One of the reasons you may find more "remapped" blocks in the highly used areas is that they drive had more chance to notice a questionable sector. (That is a sector where error correction was needed to recover the data beyond the norm and thus it chose to relocate the sector) If you are worried that such usage patterns can be a problem, just look at filesystems such as FAT/FAT32/VFAT/etc. They always must write to the front of the disk (fat table) and read from that same area (except when cached) There is no noticable higher failure rate of drives due to FAT file system usage (don't count Windows re-install and file corruption as disk failures :-) NTFS also has the central allocation bitmap and control structures. The main problem with the "low end" IDE drives is that they are very fragile bits of mechanical equipment. Very small head to disk spacing and very high rotational rates and very high bit density means that failures will happen due to mechanical reasons. As you cut your costs and try to pump out millions of these units, the MTBF will tend to drop until you get some new technique to make them more reliable. Then then push the limits and make the drives double their bit density and half the head flying height and the cycle starts over. Given the track record of XFS and other file systems and usage patterns that cause certain areas of disks to be used much more often than others, I have not seen a major failure mode in many years. (There was the lubrication failure mode from many years ago, but that has long since been solved) That is not to say that we should not look at the fact that there are hot zones in where writing happens. The fact that there are hot zones (multiple) means that there is more seeking going on than you might want (albeit it may be needed). (And each seek does cause some mechanical wear and poses potential mechanical failure) -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Fri Mar 7 06:29:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 06:29:42 -0800 (PST) Received: from oxygen.dynamix-ltd.com (proxy.dynamix-ltd.com [204.107.254.187]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27ESvq9003846 for ; Fri, 7 Mar 2003 06:29:38 -0800 Received: from dynamix-ltd.com (unknown [192.168.1.103]) by oxygen.dynamix-ltd.com (Postfix) with ESMTP id 94D75ED48; Fri, 7 Mar 2003 09:11:22 -0500 (EST) Message-ID: <3E68ACFD.20702@dynamix-ltd.com> Date: Fri, 07 Mar 2003 09:30:21 -0500 From: Andy Skunza User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Lord Cc: linux-xfs@oss.sgi.com Subject: Re: LBA to File? References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> <3E67D0CE.3080902@echostar.com> <1046997413.1373.14.camel@localhost.localdomain> In-Reply-To: <1046997413.1373.14.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3100 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: askunza@dynamix-ltd.com Precedence: bulk X-list: linux-xfs Content-Length: 1535 Lines: 46 Stephen Lord wrote: >On Thu, 2003-03-06 at 16:50, Buzbee, James wrote: > > >>The scary thing about what we are seeing is that the "grown defect list" >>on the disk is showing a lot of sectors in these two areas. It's almost >>as if we are wearing out the sectors in these areas by writing them so >>often. Strange but true ;-( >> >>Jim >> >> >> > >Ugh, yes these will be continually written to, the log in particular, >I like Eric's idea, but the scope of that is fairly drastic and it >will only postpone the inevitable - you can probably do the math to >work out how long the drive will run before it runs out of bad >blocks to remap to. All running with alternating logs would do is >delay the drive becoming scrap metal. The reliability of these >devices may not be up to the load you are placing on them. >Not all ide drives are this bad, I have been running xfs on >the same ide drive for about 3 years now - but then I am >not running a PVR. I suspect also you may have the write cache >turned off to avoid errors after a crash. > >Possibly the way your app runs is making things worse. There is a script >in the cmd/misc directory called xfsstats.pl you can watch log activity >with this. In particular xs_log_writes and xs_log_blocks. If log_blocks >is not a reasonable multiple of log_writes then you are doing a lot of >very small writes. > >Steve > > > > > > What is a "reasonable multiple" of log_writes to log_blocks? Would 22 be unreasonable? And, how to use xfs_stats.pl per xfs partion? Thanks, andy From owner-linux-xfs@oss.sgi.com Fri Mar 7 06:43:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 06:44:03 -0800 (PST) Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27Ehvq9004991 for ; Fri, 7 Mar 2003 06:43:59 -0800 Received: from kenzo.iwr.uni-heidelberg.de (kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.11.2/8.11.1) with ESMTP id h27EhuX28541; Fri, 7 Mar 2003 15:43:57 +0100 (MET) Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.11.6/8.11.6) with ESMTP id h27Ehv032671; Fri, 7 Mar 2003 15:43:57 +0100 Date: Fri, 7 Mar 2003 15:43:57 +0100 (CET) From: Bogdan Costescu To: Eric Sandeen cc: Andi Kleen , "Buzbee, James" , Subject: Re: LBA to File? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3101 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: bogdan.costescu@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs Content-Length: 1990 Lines: 52 On Fri, 7 Mar 2003, Eric Sandeen wrote: > I think it's important to remember that XFS has been in use for -many- > years on irix, Yes, we use it there as well. It's just that it came a bit as a surprise that the choice of a FS would affect the lifetime of the disk... I guess that we'll soon see disk-savers that save the oxide from our disks as the screen-savers saved the phosphor from our monitors :-))) > (And, I can think of other disk usages patterns which could result in > disproportional use of one area of a disk - /var/log partitions, for > example). Swap partitions might be hit even harder... > I think you're asking too much here... Well, I should have enclosed the whole block within quotes or something. But there _are_ performane freaks that pay attention to these details... Even more the problem might become hard when thinking about relocated sectors in which case the FS has no idea what is the real location. > I think each individual disk would need to be profiled to even know > where the "fast" spots are. Oh, I thought that this is common knowledge. Look at http://www.storagereview.com or http://www.hardware.fr/articles/448/page1.html (in French) and you'll see that there are drives which provide at the end of the disk close to half of reading speed from the beginning of the disk, while writes are even more affected. So, would you place the journal at the end of such a disk ? Of course, seek times also count... > And then technically, the log could go anywhere, but I think that for > the effort involved, the returns would not be that great. No, you'r right, possibly the fastest solution is to have a fast SCSI disk only for the journal and a replacement disk at hand. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From owner-linux-xfs@oss.sgi.com Fri Mar 7 06:57:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 06:57:07 -0800 (PST) Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27EuJq9006232 for ; Fri, 7 Mar 2003 06:57:00 -0800 Received: from kenzo.iwr.uni-heidelberg.de (kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.11.2/8.11.1) with ESMTP id h27EuIX28896; Fri, 7 Mar 2003 15:56:18 +0100 (MET) Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.11.6/8.11.6) with ESMTP id h27EuFZ00305; Fri, 7 Mar 2003 15:56:15 +0100 Date: Fri, 7 Mar 2003 15:56:15 +0100 (CET) From: Bogdan Costescu To: Michael Sinz cc: Eric Sandeen , Andi Kleen , "Buzbee, James" , Subject: Re: LBA to File? In-Reply-To: <3E68A99D.4060301@wgate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3102 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: bogdan.costescu@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs Content-Length: 737 Lines: 19 On Fri, 7 Mar 2003, Michael Sinz wrote: > That is not to say that we should not look at the fact that there > are hot zones in where writing happens. The fact that there are > hot zones (multiple) means that there is more seeking going on than > you might want (albeit it may be needed). (And each seek does > cause some mechanical wear and poses potential mechanical failure) You are absolutely right and I think that the above paragraph expresses better what I wanted to say... -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From owner-linux-xfs@oss.sgi.com Fri Mar 7 07:17:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 07:17:50 -0800 (PST) Received: from muaddib.localnet (mail@port-212-202-170-13.reverse.qdsl-home.de [212.202.170.13]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27FHeq9009352 for ; Fri, 7 Mar 2003 07:17:42 -0800 Received: from ij by muaddib.localnet with local (Exim 3.36 #1 (Debian)) id 18rJbI-0006gW-00; Fri, 07 Mar 2003 16:17:32 +0100 Date: Fri, 7 Mar 2003 16:17:32 +0100 To: Michael Sinz Cc: linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030307151732.GO1446@spice.cologne.de> References: <3E68A99D.4060301@wgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E68A99D.4060301@wgate.com> User-Agent: Mutt/1.5.3i From: Ingo Juergensmann X-archive-position: 3103 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: ij@spice.cologne.de Precedence: bulk X-list: linux-xfs Content-Length: 5347 Lines: 100 On Fri, Mar 07, 2003 at 09:15:57AM -0500, Michael Sinz wrote: > >No, not only for them. The frequent access exists for all drives and > >will destroy a high-end SCSI disk just as well, but maybe not as fast. > I would think that all of this "worry" is not a major issue. One > of the reasons you may find more "remapped" blocks in the highly used > areas is that they drive had more chance to notice a questionable > sector. (That is a sector where error correction was needed to > recover the data beyond the norm and thus it chose to relocate the > sector) Hmm, well, I have some disks with large grown defects tables and others without any grown defect at all, regardless of how old the disks are. But I had as well more failing IDE disks than SCSI disks. Only one SCA disk failed in an array the last days, but some IDE disks died just after a few days (yes, IBM ones ;). The failing SCA disk instead was an old 2 GB Seagate Barracuda, just to mention how old this disk was... > If you are worried that such usage patterns can be a problem, just look > at filesystems such as FAT/FAT32/VFAT/etc. They always must write to > the front of the disk (fat table) and read from that same area (except > when cached) There is no noticable higher failure rate of drives due > to FAT file system usage (don't count Windows re-install and file > corruption as disk failures :-) > NTFS also has the central allocation bitmap and control structures. Most users will re-install Windows anyway on broken disks as well, until they realises that actually the disk is broken and not Windows... ;) > The main problem with the "low end" IDE drives is that they are very > fragile bits of mechanical equipment. Very small head to disk spacing > and very high rotational rates and very high bit density means that > failures will happen due to mechanical reasons. As you cut your costs > and try to pump out millions of these units, the MTBF will tend to > drop until you get some new technique to make them more reliable. > Then then push the limits and make the drives double their bit > density and half the head flying height and the cycle starts over. Try and error or "public betatesting"... There is no time anymore to test the hard-/software inhouse, instead many uses the crowd out there as public betatesters... *sigh* IBM disks are a good example for this QA problems. > Given the track record of XFS and other file systems and usage > patterns that cause certain areas of disks to be used much more > often than others, I have not seen a major failure mode in many > years. (There was the lubrication failure mode from many > years ago, but that has long since been solved) > > That is not to say that we should not look at the fact that there > are hot zones in where writing happens. The fact that there are > hot zones (multiple) means that there is more seeking going on than > you might want (albeit it may be needed). (And each seek does > cause some mechanical wear and poses potential mechanical failure) For me as a user it's something like this: I don't bother about the filesystem internals as long as I can get my data back in some way. I know that each filesystem can and certainly will fail at some time. I made this experiences with Amiga OFS and FFS, with Amiga AFS (now SFS), FAT, NTFS, ext2/ext3 and XFS (both Irix and x86). As you might now FFS has a certain manner in accessing data, which make it easy to regain data after a disk error (disk validating error): quick format it and let some undelete tools do their job (such as DiskSalv from Dave H.). Back then I tried AFS (Advanced FileSystem), which worked fine for some time, until it failed. The delivered AFS salvage tools failed in validating the disk and 400 MB of data (back in 1995 that was a big block of data ;). My experiences with FAT and NTFS are not as deep as with others operating systems or file systems, but it's similar: as long as there are tools that are doing their job excellent, you don't worry much about your data - as long the operating/file systems doesn't try to be very clever and doing stuff it better shouldn't do. Ext2/3 is doing some fscking regularly, but when fsck stumbles about an error it can't solve at its own, you're doomed as an average user. XFS instead is somewhat different. Not that I haven't had failing disks under XFS usage - indeed I had the most failing disks (IBMs that is ;) under XFS, but I was always able to recover my data (with the help of esandeen and others from #xfs). The reason is simple (for me): I can make a diskimage of that filesystem and try to salvage the data from that "backup"... if dd stumbles across an error on hardware, I can skip that block and XFS is robust enough to get a clean file system with this missing block. And because XFS is on disk compatible I can use XFS tools on my SGI to exclude bugs in Linux XFS tools. To make it short: A good file system is not the fastest one or the newest one, but the one that gives me my data back after an error happened - errors will happen for sure! Regardless of FS errors or hardware errors on disk. So, the FS tools are somewhat more important than the FS itself. For me XFS and Amiga FFS are the most robust file systems I came across over the years... :-) -- Ciao... // Ingo \X/ From owner-linux-xfs@oss.sgi.com Fri Mar 7 07:18:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 07:18:09 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27FI5q9009472 for ; Fri, 7 Mar 2003 07:18:05 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h27FHxnH014765 for ; Fri, 7 Mar 2003 07:18:00 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA69404; Fri, 7 Mar 2003 09:17:56 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h27FHuwX24947160; Fri, 7 Mar 2003 09:17:56 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h27FHtf28660; Fri, 7 Mar 2003 09:17:55 -0600 Subject: Re: LBA to File? From: Steve Lord To: Bogdan Costescu Cc: Eric Sandeen , Andi Kleen , "Buzbee, James" , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047050275.26370.2197.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 07 Mar 2003 09:17:55 -0600 X-archive-position: 3104 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 623 Lines: 19 On Fri, 2003-03-07 at 08:43, Bogdan Costescu wrote: > > No, you'r right, possibly the fastest solution is to have a fast SCSI disk > only for the journal and a replacement disk at hand. Actually the fastest solution is to have a partitioned solid state device you use for logs - battery backed ram, definitely not flash. Unfortunately xfs cannot share logs between filesystems so if you put several on a drive dedicated to logs you are in for a lot of head seeking. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Mar 7 07:18:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 07:18:45 -0800 (PST) Received: from mailout1.echostar.com (mailout1.echostar.com [204.76.128.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27FIgq9009934 for ; Fri, 7 Mar 2003 07:18:43 -0800 Received: from riv-exchcon.echostar.com ([10.1.200.73]) by 10.0.221.101 with InterScan Messaging Security Suite; Fri, 07 Mar 2003 08:19:07 -0700 Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 08:18:35 -0700 Received: from echostar.com (linux1.echostar.com [10.79.98.101]) by riv-exchcon.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GHSJAG8H; Fri, 7 Mar 2003 08:18:32 -0700 From: "Buzbee, James" To: Stephen Lord Cc: Eric Sandeen , linux-xfs@oss.sgi.com Message-ID: <3E68B848.2040509@echostar.com> Date: Fri, 07 Mar 2003 08:18:32 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: LBA to File? References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> <3E67D0CE.3080902@echostar.com> <1046997413.1373.14.camel@localhost.localdomain> X-Enigmail-Version: 0.62.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3105 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: James.Buzbee@echostar.com Precedence: bulk X-list: linux-xfs Content-Length: 1612 Lines: 50 Stephen Lord wrote: > On Thu, 2003-03-06 at 16:50, Buzbee, James wrote: > >>The scary thing about what we are seeing is that the "grown defect list" >>on the disk is showing a lot of sectors in these two areas. It's almost >>as if we are wearing out the sectors in these areas by writing them so >>often. Strange but true ;-( >> >>Jim >> > > > Ugh, yes these will be continually written to, the log in particular, > I like Eric's idea, but the scope of that is fairly drastic and it > will only postpone the inevitable - you can probably do the math to > work out how long the drive will run before it runs out of bad > blocks to remap to. All running with alternating logs would do is > delay the drive becoming scrap metal. The reliability of these > devices may not be up to the load you are placing on them. > Not all ide drives are this bad, I have been running xfs on > the same ide drive for about 3 years now - but then I am > not running a PVR. Some of these units are never turned off. The user turns off the TV and leaves the Set Top box on. They are running 24/7 recording at least one video stream, maybe two. > I suspect also you may have the write cache > turned off to avoid errors after a crash. > > Possibly the way your app runs is making things worse. There is a script > in the cmd/misc directory called xfsstats.pl you can watch log activity > with this. In particular xs_log_writes and xs_log_blocks. If log_blocks > is not a reasonable multiple of log_writes then you are doing a lot of > very small writes. Thanks - We'll take a look at it. Jim > > Steve > > From owner-linux-xfs@oss.sgi.com Fri Mar 7 07:19:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 07:19:49 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27FJkq9010730 for ; Fri, 7 Mar 2003 07:19:46 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h27FJfnH014919 for ; Fri, 7 Mar 2003 07:19:41 -0800 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA91040 for ; Fri, 7 Mar 2003 09:19:39 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h27FJdvw6917239 for ; Fri, 7 Mar 2003 09:19:39 -0600 (CST) Received: from clink.americas.sgi.com (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id h27FJfkY446772 for ; Fri, 7 Mar 2003 09:19:41 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id h27FJe6C446638 for linux-xfs@oss.sgi.com; Fri, 7 Mar 2003 09:19:40 -0600 (CST) Date: Fri, 7 Mar 2003 09:19:40 -0600 (CST) From: Dean Roehrich Message-Id: <200303071519.h27FJe6C446638@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - allow dmapi test tools get/set_dmattr to take handle or pathname X-archive-position: 3106 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: roehrich@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 437 Lines: 17 allow dmapi test tools get/set_dmattr to take handle or pathname Date: Fri Mar 7 07:19:18 PST 2003 Workarea: clink.americas.sgi.com:/data/clink/a67/roehrich/dmapitests The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs/cmd/xfstests/dmapi Modid: xfs-cmds:slinx:141196a src/suite1/cmd/get_dmattr.c - 1.7 - allow pathname or handle src/suite1/cmd/set_dmattr.c - 1.7 - allow pathname or handle From owner-linux-xfs@oss.sgi.com Fri Mar 7 07:34:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 07:34:06 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27FY3q9012150 for ; Fri, 7 Mar 2003 07:34:04 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h27FXwnH015894 for ; Fri, 7 Mar 2003 07:33:58 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA96555; Fri, 7 Mar 2003 09:33:57 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h27FXvwX24967945; Fri, 7 Mar 2003 09:33:57 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h27FXvG28690; Fri, 7 Mar 2003 09:33:57 -0600 Subject: Re: LBA to File? From: Steve Lord To: Andy Skunza Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E68ACFD.20702@dynamix-ltd.com> References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> <3E67D0CE.3080902@echostar.com> <1046997413.1373.14.camel@localhost.localdomain> <3E68ACFD.20702@dynamix-ltd.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047051236.26370.2238.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 07 Mar 2003 09:33:57 -0600 X-archive-position: 3107 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1205 Lines: 37 On Fri, 2003-03-07 at 08:30, Andy Skunza wrote: > Stephen Lord wrote: > > > >Possibly the way your app runs is making things worse. There is a script > >in the cmd/misc directory called xfsstats.pl you can watch log activity > >with this. In particular xs_log_writes and xs_log_blocks. If log_blocks > >is not a reasonable multiple of log_writes then you are doing a lot of > >very small writes. > > > >Steve > > > What is a "reasonable multiple" of log_writes to log_blocks? Would 22 be > unreasonable? And, how to use xfs_stats.pl per xfs partion? > > Thanks, > andy The stats are global and not available on a per fs basis. You can clear the stats with echo 1 > /proc/sys/fs/xfs/stats_clear So you can measure more controlled periods of time. Perfection is 64, the more recent your code the closer you should get, we have been removing synchronous transactions from the code. My workstation which has been up 27 days is averaging a ratio of 52. It also depends on what you run, something which does O_SYNC writes all the time can hammer it. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Mar 7 07:46:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 07:46:58 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e14d.dsl.mediaWays.net [213.20.225.77]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27Fkmq9016886 for ; Fri, 7 Mar 2003 07:46:52 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=localhost) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18rK3W-0006gy-00 for linux-xfs@oss.sgi.com; Fri, 07 Mar 2003 16:46:42 +0100 Received: from 192.168.1.1 ( [192.168.1.1]) as user be@ente.berdmann.de by apollo.berdmann.de with HTTP; Fri, 7 Mar 2003 16:46:42 +0100 Message-ID: <1047052002.3e68bee241784@apollo.berdmann.de> Date: Fri, 7 Mar 2003 16:46:42 +0100 From: Bernhard Erdmann To: linux-xfs@oss.sgi.com Subject: suppressing syncs on spools MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 192.168.1.1 X-archive-position: 3108 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: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 443 Lines: 15 Hi, for a spool/scratch filesystem I'm only interested in speed. Disk I/O should be as minimal as possible. Files will be deleted some 1/10 sec or some secs later. It won't hurt if files are lost if the box crashes. This filesystem can even be mkfs'd at system boot. Just speed, like a ram disk, but I don't want to spend 1-2 GB to a ram disk. Are there mount options or mkfs.xfs options which can help to reduce disk I/O? Regards Bernie From owner-linux-xfs@oss.sgi.com Fri Mar 7 07:48:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 07:48:47 -0800 (PST) Received: from deepstrike.nameip.net (IDENT:aMrWp9KwxmMH4lnd1G6jepmqKoyV6c37@[211.49.14.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27Fmhq9017336 for ; Fri, 7 Mar 2003 07:48:45 -0800 Received: (qmail 8247 invoked by uid 500); 7 Mar 2003 15:48:39 -0000 Subject: latest RH + XFS kernel From: Seung-yeong Oh To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047052119.6227.4.camel@deepstrike.nameip.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Mar 2003 00:48:39 +0900 X-archive-position: 3109 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: so1713@orgio.net Precedence: bulk X-list: linux-xfs Content-Length: 82 Lines: 7 Should anyone is interested; http://www.withseha.net/~so1713 Have a nice day. From owner-linux-xfs@oss.sgi.com Fri Mar 7 07:56:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 07:56:56 -0800 (PST) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27Furq9017831 for ; Fri, 7 Mar 2003 07:56:54 -0800 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZBLDPSAY; Fri, 7 Mar 2003 10:57:21 -0500 Received: from wgate.com (localhost.localdomain [127.0.0.1]) by sinz.eng.tvol.net (8.12.8/8.12.5) with ESMTP id h27Ftnfj027846; Fri, 7 Mar 2003 10:55:49 -0500 Message-ID: <3E68C105.6060805@wgate.com> Date: Fri, 07 Mar 2003 10:55:49 -0500 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ingo Juergensmann CC: linux-xfs@oss.sgi.com Subject: Re: LBA to File? References: <3E68A99D.4060301@wgate.com> <20030307151732.GO1446@spice.cologne.de> In-Reply-To: <20030307151732.GO1446@spice.cologne.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3110 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: msinz@wgate.com Precedence: bulk X-list: linux-xfs Content-Length: 2112 Lines: 50 Ingo Juergensmann wrote: > On Fri, Mar 07, 2003 at 09:15:57AM -0500, Michael Sinz wrote: [...] >>That is not to say that we should not look at the fact that there >>are hot zones in where writing happens. The fact that there are >>hot zones (multiple) means that there is more seeking going on than >>you might want (albeit it may be needed). (And each seek does >>cause some mechanical wear and poses potential mechanical failure) > > > For me as a user it's something like this: > I don't bother about the filesystem internals as long as I can get my data > back in some way. I know that each filesystem can and certainly will fail > at some time. > I made this experiences with Amiga OFS and FFS, with Amiga AFS (now SFS), > FAT, NTFS, ext2/ext3 and XFS (both Irix and x86). Ahh, the Amiga FFS - it would not scale to very large disks very well (bitmap rather than extents is a major limiting factor) but it did have a lot going for it. (so says an ex-Amiga OS Systems Engineer/Architect - we are talking 10 years ago here...) [...] > To make it short: > A good file system is not the fastest one or the newest one, but the one > that gives me my data back after an error happened - errors will happen for > sure! Regardless of FS errors or hardware errors on disk. So, the FS tools > are somewhat more important than the FS itself. > > For me XFS and Amiga FFS are the most robust file systems I came across over > the years... :-) Yes, high reliability and recoverability are key aspects of filesystem design (well, good filesystem design... Don't look at FAT as a good design) However, that does not mean you should not look at issues that can cause performance hits or long-term hardware wear. They may be non-solveable but the point is not to just ignore them. If you can get both the high quality and high performance, so much the better. (And I think that XFS does provide a very good balance in this respect...) -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Fri Mar 7 08:00:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 08:00:10 -0800 (PST) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27G07q9018325 for ; Fri, 7 Mar 2003 08:00:08 -0800 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZBLDPSCR; Fri, 7 Mar 2003 11:00:36 -0500 Received: from wgate.com (localhost.localdomain [127.0.0.1]) by sinz.eng.tvol.net (8.12.8/8.12.5) with ESMTP id h27Fx4fj027856; Fri, 7 Mar 2003 10:59:04 -0500 Message-ID: <3E68C1C8.6090606@wgate.com> Date: Fri, 07 Mar 2003 10:59:04 -0500 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord CC: Andy Skunza , linux-xfs@oss.sgi.com Subject: Re: LBA to File? References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> <3E67D0CE.3080902@echostar.com> <1046997413.1373.14.camel@localhost.localdomain> <3E68ACFD.20702@dynamix-ltd.com> <1047051236.26370.2238.camel@jen.americas.sgi.com> In-Reply-To: <1047051236.26370.2238.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3111 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: msinz@wgate.com Precedence: bulk X-list: linux-xfs Content-Length: 1575 Lines: 44 Steve Lord wrote: > On Fri, 2003-03-07 at 08:30, Andy Skunza wrote: > >>Stephen Lord wrote: >> >>>Possibly the way your app runs is making things worse. There is a script >>>in the cmd/misc directory called xfsstats.pl you can watch log activity >>>with this. In particular xs_log_writes and xs_log_blocks. If log_blocks >>>is not a reasonable multiple of log_writes then you are doing a lot of >>>very small writes. >>> >> >>What is a "reasonable multiple" of log_writes to log_blocks? Would 22 be >>unreasonable? And, how to use xfs_stats.pl per xfs partion? >> >>Thanks, >>andy > > The stats are global and not available on a per fs basis. You can clear > the stats with > > echo 1 > /proc/sys/fs/xfs/stats_clear > > So you can measure more controlled periods of time. > > Perfection is 64, the more recent your code the closer you should get, > we have been removing synchronous transactions from the code. My > workstation which has been up 27 days is averaging a ratio of 52. > It also depends on what you run, something which does O_SYNC writes > all the time can hammer it. So, for a workstation that has been up for 6 days (running relatively new XFS from CVS) seeing a value of around 20 to 21:1 is not there yet. Do you want us to monitor this for you and provide feedback? (This is a development system - that is, build/compile/edit/etc, and not a server - I will check on those later) -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Fri Mar 7 08:33:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 08:33:39 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27GXZq9020165 for ; Fri, 7 Mar 2003 08:33:36 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h27GXU9n020436 for ; Fri, 7 Mar 2003 08:33:30 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA58250 for ; Fri, 7 Mar 2003 10:33:29 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h27GXTwX24760342 for ; Fri, 7 Mar 2003 10:33:29 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h27GX2923479; Fri, 7 Mar 2003 10:33:02 -0600 Message-Id: <200303071633.h27GX2923479@stout.americas.sgi.com> Date: Fri, 7 Mar 2003 10:33:02 -0600 Subject: TAKE - Turn on random() if INDUCE_IO_ERROR is defined X-archive-position: 3112 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 419 Lines: 16 This is really just for debugging... allow error injection without a full debug kernel. Turn on random() if INDUCE_IO_ERROR is defined Date: Fri Mar 7 08:31:58 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs-dev/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-dev Modid: 2.4.x-xfs-dev:slinx:141200a linux/fs/xfs/support/debug.c - 1.23 From owner-linux-xfs@oss.sgi.com Fri Mar 7 09:41:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 09:41:36 -0800 (PST) Received: from imf13bis.bellsouth.net (mail213.mail.bellsouth.net [205.152.58.153]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27HfRq9024307 for ; Fri, 7 Mar 2003 09:41:28 -0800 Received: from tiger2 ([67.35.81.4]) by imf13bis.bellsouth.net (InterMail vM.5.01.04.25 201-253-122-122-125-20020815) with SMTP id <20030307174325.SKSJ2682.imf13bis.bellsouth.net@tiger2>; Fri, 7 Mar 2003 12:43:25 -0500 Date: Fri, 7 Mar 2003 12:45:10 -0500 From: Greg Freemyer Subject: re[2]: LBA to File? To: Bogdan Costescu cc: Mime-Version: 1.0 Organization: Norcross Group X-Mailer: GoldMine [6.00.21021] Content-Type: Text/plain Message-Id: <20030307174325.SKSJ2682.imf13bis.bellsouth.net@tiger2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h27HfTq9024313 X-archive-position: 3113 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: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 1051 Lines: 23 >> On Fri, 7 Mar 2003, Michael Sinz wrote: >> > That is not to say that we should not look at the fact that there >> > are hot zones in where writing happens. The fact that there are >> > hot zones (multiple) means that there is more seeking going on than >> > you might want (albeit it may be needed). (And each seek does >> > cause some mechanical wear and poses potential mechanical failure) Performance: What is the failure rate of the log sectors on these drives? Is even possible to tell from the Linux kernel? If possible to tell, then maybe the journal itself should be created a little on the large size, then when an underlying sector is re-mapped, simply quit using that sector in the journal. This would eliminate time wasting seeks out to the remapped sectors. Longevity: Even if your losing 1% of sectors/month, allocating a spare 100% of log space as above would allow the drive to last 100 months before it was trashed and would ensure high log speed access for the duration of that 100 months. Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Fri Mar 7 10:30:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 10:31:58 -0800 (PST) Received: from mail.automatix.de ([62.67.57.175]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27IThq9026497 for ; Fri, 7 Mar 2003 10:30:25 -0800 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.35 #1) id 18rFYB-0007U0-00 for linux-xfs@oss.sgi.com; Fri, 07 Mar 2003 11:58:03 +0100 Received: from pc2.s.automatix.de ([192.168.11.12]) by s.automatix.de with esmtp (Exim 3.36 #1) id 18rFUx-0008VA-00; Fri, 07 Mar 2003 11:54:43 +0100 From: Juergen Sauer Reply-To: juergen.sauer@automatix.de Organization: AutomatiX GmbH To: Chris Wedgwood Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? Date: Fri, 7 Mar 2003 11:54:44 +0100 User-Agent: KMail/1.5 Cc: linux-xfs@oss.sgi.com References: <200303051048.54271.juergen.sauer@automatix.de> <200303052022.38108.juergen.sauer@automatix.de> <20030305210513.GA427@f00f.org> In-Reply-To: <20030305210513.GA427@f00f.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200303071154.44584.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h27IUQq9026556 X-archive-position: 3114 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: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs Content-Length: 1173 Lines: 39 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 5. März 2003 22:05 schrieb Chris Wedgwood: > On Wed, Mar 05, 2003 at 08:22:34PM +0100, Juergen Sauer wrote: > > > The XFS Kernel 2.4.20-xfs out of the SGI/CVS Repository does not > > know about the the nforce2 ide and gives errors, if I enable > > DMA/UDMA modes. > > I knows about the nv/amd driver though > > > The amd7xx driver is not in the kernel visible here. Should it be > > visible? (Error in config.in ?) > > CONFIG_BLK_DEV_AMD74XX=y > > actually, i think you need an -ac tree for this, i was looking at the > 2.5.x where the nv ide and amd ide are unified - -ac Kernel tree is not avaible in the KErnel-2.4-xfs CVS by SGI. Exactly that is the problem ! mfG Jürgen automatiX Linux Support Crew - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** ** http://www.automatix.de http://www.kranautomatisierung.de ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+aHp0W7UKI9EqarERAsIhAJ9uhPQ43Ywzaxd/X/qB4/umBt/pdgCeI59B gth1BDDemL/YKPEseJ7VNng= =cxzf -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Mar 7 10:31:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 10:32:14 -0800 (PST) Received: from mail.automatix.de ([62.67.57.175]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27IUQq9026558 for ; Fri, 7 Mar 2003 10:31:07 -0800 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.35 #1) id 18rFUR-0007Tb-00 for linux-xfs@oss.sgi.com; Fri, 07 Mar 2003 11:54:11 +0100 Received: from pc2.s.automatix.de ([192.168.11.12]) by s.automatix.de with esmtp (Exim 3.36 #1) id 18rFTi-0008Uf-00; Fri, 07 Mar 2003 11:53:26 +0100 From: Juergen Sauer Reply-To: juergen.sauer@automatix.de Organization: AutomatiX GmbH To: linux-xfs@oss.sgi.com, Florin Andrei Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? Date: Fri, 7 Mar 2003 11:53:27 +0100 User-Agent: KMail/1.5 References: <200303051048.54271.juergen.sauer@automatix.de> <1046897437.31215.43.camel@stantz.corp.sgi.com> In-Reply-To: <1046897437.31215.43.camel@stantz.corp.sgi.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200303071153.27690.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h27IV7q9026644 X-archive-position: 3115 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: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs Content-Length: 1153 Lines: 37 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 5. März 2003 21:50 schrieb Florin Andrei: > Is it related just to IDE for the CD-ROM, or for all devices? > If it's just for CD-ROMs, here's an excerpt from the RELEASE-NOTES for > RH8.0: > > ########################### > DMA is disabled on CD-ROM drives in this release in a different but more > reliable way than previously. If you are sure that your CD-ROM drive is > capable of IDE DMA, place the following line in the /etc/modules.conf > file: > options ide-cd dma=1 > ############################ RedHat is not standard. RH is only one distri. The base problem is that the cvs/2.4-xfs kernel does not complain to the common nforec2 Patches. mfG Jürgen automatiX Linux Support Crew - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** ** http://www.automatix.de http://www.kranautomatisierung.de ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+aHonW7UKI9EqarERAiibAJsHefk4FRkm1qqlYby9yotIe+CixgCguE6T zfq2vp22Df/RKpl6349Ao9A= =h4nd -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Mar 7 10:32:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 10:33:34 -0800 (PST) Received: from mail.automatix.de ([62.67.57.175]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27IVjq9026711 for ; Fri, 7 Mar 2003 10:32:26 -0800 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.35 #1) id 18rFYB-0007U4-00 for linux-xfs@oss.sgi.com; Fri, 07 Mar 2003 11:58:03 +0100 Received: from pc2.s.automatix.de ([192.168.11.12]) by s.automatix.de with esmtp (Exim 3.36 #1) id 18rFWe-0008VL-00; Fri, 07 Mar 2003 11:56:28 +0100 From: Juergen Sauer Reply-To: juergen.sauer@automatix.de Organization: AutomatiX GmbH To: Thomas Bittermann Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? Date: Fri, 7 Mar 2003 11:56:29 +0100 User-Agent: KMail/1.5 Cc: linux-xfs@oss.sgi.com References: <200303051048.54271.juergen.sauer@automatix.de> <200303052022.38108.juergen.sauer@automatix.de> <200303052309.51984.t.bittermann@online.de> In-Reply-To: <200303052309.51984.t.bittermann@online.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200303071156.29730.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h27IWQq9026981 X-archive-position: 3116 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: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs Content-Length: 837 Lines: 29 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 5. März 2003 23:09 schrieb Thomas Bittermann: > Hallo Juergen, > > I'm using a "home-grown" 2.4.21-pre5-ac1 with XFS (CVS-2003-03-05). > Alan's patch removes nvidia.* from drivers/ide/pci (pre5). It includes > nForce(2) support in drivers/ide/pci/amd74xx.* so be sure to activate "AMD > Viper support". Which CVS Source do you use ? mfG Jürgen automatiX Linux Support Crew - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** ** http://www.automatix.de http://www.kranautomatisierung.de ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+aHrdW7UKI9EqarERAvPiAKCx5a2/uLG+/YrzDiayF1FNnzmPIgCdFvTm 7H9/Sx6UGfVHzzpBqCasga4= =/hhP -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Mar 7 12:42:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 12:42:27 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27KgMq9002107 for ; Fri, 7 Mar 2003 12:42:22 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h27KgG9n005893 for ; Fri, 7 Mar 2003 12:42:16 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA85879 for ; Fri, 7 Mar 2003 14:42:15 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h27KgDwX24738099 for ; Fri, 7 Mar 2003 14:42:14 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h283vp908421 for linux-xfs@oss.sgi.com; Fri, 7 Mar 2003 22:57:51 -0500 Resent-Message-Id: <200303080357.h283vp908421@taclab54.munich.sgi.com> Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h27KciwX24536320 for ; Fri, 7 Mar 2003 14:38:45 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h283sMZ08411 for hch@sgi.com; Fri, 7 Mar 2003 22:54:22 -0500 Date: Fri, 7 Mar 2003 22:54:22 -0500 From: Christoph Hellwig Message-Id: <200303080354.h283sMZ08411@taclab54.munich.sgi.com> Subject: TAKE - time_after takes an unsigned long Resent-From: hch@sgi.com Resent-Date: Fri, 7 Mar 2003 22:57:51 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 3117 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: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 328 Lines: 13 This has been cought by the stricter typechecking in 2.5 mainline. Date: Fri Mar 7 12:36:49 PST 2003 Workarea: taclab54.munich.sgi.com:/home/hch/repo/slinx/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141237a linux/fs/xfs/xfs_buf_item.c - 1.137 From owner-linux-xfs@oss.sgi.com Fri Mar 7 12:46:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 12:46:34 -0800 (PST) Received: from loki (firewall.conet.cz [213.175.54.250]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27KkTq9002520 for ; Fri, 7 Mar 2003 12:46:30 -0800 Received: from conet.cz (liborwin [192.168.1.130]) by loki (8.12.8/8.12.5) with ESMTP id h27KI8O4014220 for ; Fri, 7 Mar 2003 21:18:08 +0100 Message-ID: <3E68FCB8.4050505@conet.cz> Date: Fri, 07 Mar 2003 21:10:32 +0100 From: Libor Vanek User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs_repair produces 990 error Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3118 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: libor@conet.cz Precedence: bulk X-list: linux-xfs Content-Length: 3498 Lines: 129 Hi, I've had disk failure in my SW RAID, which was quite OK since it was only 1 of 3 disks. But system was halted so I rebooted it and afterthat I was unable to mount XFS system so I run xfs_repair with this result: [root@Discobolos_2 root]# xfs_repair /dev/md0 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 no .. entry for directory 196669223 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 no .. entry for directory 486539427 - agno = 30 - agno = 31 - agno = 32 entry contains offset out of order in shortform dir 537155859 corrected entry offsets in directory 537155859 - agno = 33 - agno = 34 - agno = 35 no .. entry for directory 587629607 - agno = 36 - agno = 37 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 no .. entry for directory 196669223 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 no .. entry for directory 486539427 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 no .. entry for directory 587629607 - agno = 36 - agno = 37 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected inode 134386441, moving to lost+found disconnected inode 134386465, moving to lost+found disconnected inode 134386469, moving to lost+found corrupt inode 134386469 (btree). Unmount and run xfs_repair. fatal error -- 990 - couldn't iget disconnected inode Any suggestions? Thanks a LOT, Libor Vanek From owner-linux-xfs@oss.sgi.com Fri Mar 7 13:22:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 13:22:52 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e14d.dsl.mediaWays.net [213.20.225.77]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27LM2q9005147 for ; Fri, 7 Mar 2003 13:22:43 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18rPHw-0007FQ-00 for linux-xfs@oss.sgi.com; Fri, 07 Mar 2003 22:21:56 +0100 Message-ID: <3E690D72.5080801@berdmann.de> Date: Fri, 07 Mar 2003 22:21:54 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4a) Gecko/20030307 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: rsync://oss.sgi.com with a very low timeout value? "unexpected EOF in read_timeout" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3119 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: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 1142 Lines: 37 Hi, I'm trying to rsync on rsync://oss.sgi.com/xfsftp/Release-1.0.2, but every time rsync stops at the file RH7.2-SGI-XFS-1.0.2a.iso: "unexpected EOF in read_timeout" This file is on my local hard disk (320 MB). The local rsync seems to calculate a checksum (as I see hard disk activity while waiting for "unexpected EOF in read_timeout") and does not finish within the timeout of the rsync server. Using -vvv I get the following output: $ pwd /net/software/xfs/oss.sgi.com/projects/xfs $ rsync --progress --delete -vvv -aH rsync://oss.sgi.com/xfsftp/Release-1.0.2 . local_version=24 remote_version=24 receiving file list ... recv_file_name(Release-1.0.2) recv_file_name(Release-1.0.2/cmd_rpms) [...] recv_generator(Release-1.0.2/installer/i386/RH7.2-SGI-XFS-1.0.2a.iso,159) unexpected EOF in read_timeout sending sums for 159 unexpected EOF in read_timeout It takes 20 sec from the last line "recv_generator" to "unexpected EOF in read_timeout". If I exclude this file (--exclude=RH7.2-SGI-XFS-1.0.2a.iso), rsync properly syncs down the tree. Is there some timeout value on the rsync server being that small? Regards Bernie From owner-linux-xfs@oss.sgi.com Fri Mar 7 13:26:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 13:26:13 -0800 (PST) Received: from hotmail.com (f66.sea2.hotmail.com [207.68.165.66]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27LQAq9012472 for ; Fri, 7 Mar 2003 13:26:11 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 7 Mar 2003 13:26:05 -0800 Received: from 208.244.233.175 by sea2fd.sea2.hotmail.msn.com with HTTP; Fri, 07 Mar 2003 21:26:05 GMT X-Originating-IP: [208.244.233.175] From: "Rick Smith" To: linux-xfs@oss.sgi.com Subject: unwritten extents vs. fragmentation Date: Fri, 07 Mar 2003 13:26:05 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Mar 2003 21:26:05.0566 (UTC) FILETIME=[2947F1E0:01C2E4F0] X-archive-position: 3120 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: rgsmith72@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 398 Lines: 12 A couple questions. Does enabling unwritten extent flagging in XFS ultimately reduce filesystem fragmentation? What is the downside of enabling unwritten extents other than slower write performance? Thanks. Rick Smith _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-linux-xfs@oss.sgi.com Fri Mar 7 13:33:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 13:33:04 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27LX1q9013762 for ; Fri, 7 Mar 2003 13:33:02 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h27LhYkq001625 for ; Fri, 7 Mar 2003 15:43:34 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA55206; Fri, 7 Mar 2003 15:32:55 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h27LWswX25031681; Fri, 7 Mar 2003 15:32:54 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h27LWs620670; Fri, 7 Mar 2003 15:32:54 -0600 Subject: Re: unwritten extents vs. fragmentation From: Steve Lord To: Rick Smith Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047072773.1864.60.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 07 Mar 2003 15:32:54 -0600 X-archive-position: 3121 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 810 Lines: 19 On Fri, 2003-03-07 at 15:26, Rick Smith wrote: > A couple questions. Does enabling unwritten extent flagging in XFS > ultimately reduce filesystem fragmentation? What is the downside of enabling > unwritten extents other than slower write performance? Thanks. It should make no difference to physical fragmentation, and in the normal I/O path unwritten extents should not be used. They only come into play with space preallocation. In this case they will slow down I/O somewhat, but provide more security in that you cannot use unwritten extents to read old data. This is why the prealloc calls on -d unwritten=0 filesystems are restricted to root. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Mar 7 14:05:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 14:05:46 -0800 (PST) Received: from hotmail.com (f46.sea2.hotmail.com [207.68.165.46]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27M5cq9018536 for ; Fri, 7 Mar 2003 14:05:39 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 7 Mar 2003 14:05:33 -0800 Received: from 208.244.233.175 by sea2fd.sea2.hotmail.msn.com with HTTP; Fri, 07 Mar 2003 22:05:32 GMT X-Originating-IP: [208.244.233.175] From: "Rick Smith" To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: unwritten extents vs. fragmentation Date: Fri, 07 Mar 2003 14:05:32 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Mar 2003 22:05:33.0073 (UTC) FILETIME=[AC6CD810:01C2E4F5] X-archive-position: 3122 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: rgsmith72@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1888 Lines: 45 By preallocation are you referring to an ioctl after opening a file with XFS_IOC_RESVSP64? If so, does this only have an effect with unwritten=1? Does using the XFS_IOC_RESVSP64 ioctl guarantee contiguous extents when the file is written, or at least make more of an effort to ensure contiguous extent allocation? As you may remember from some of my previous emails, my goal is to have each file written as contiguous as possible and have each consecutive file as close to the previous file as possible. I have been experimenting with the realtime subvolume (due to the limited documentation speaking of reduced fragmentation), but I have not had much success so far. Thanks. Rick >From: Steve Lord >To: Rick Smith >CC: linux-xfs@oss.sgi.com >Subject: Re: unwritten extents vs. fragmentation >Date: 07 Mar 2003 15:32:54 -0600 > >On Fri, 2003-03-07 at 15:26, Rick Smith wrote: > > A couple questions. Does enabling unwritten extent flagging in XFS > > ultimately reduce filesystem fragmentation? What is the downside of >enabling > > unwritten extents other than slower write performance? Thanks. > >It should make no difference to physical fragmentation, and in the >normal I/O path unwritten extents should not be used. They only come >into play with space preallocation. In this case they will slow >down I/O somewhat, but provide more security in that you cannot >use unwritten extents to read old data. This is why the prealloc >calls on -d unwritten=0 filesystems are restricted to root. > >Steve > >-- > >Steve Lord voice: +1-651-683-3511 >Principal Engineer, Filesystem Software email: lord@sgi.com _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-linux-xfs@oss.sgi.com Fri Mar 7 14:12:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 14:12:05 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27MC0q9019229 for ; Fri, 7 Mar 2003 14:12:01 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h27MMXkq003107 for ; Fri, 7 Mar 2003 16:22:33 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA51513; Fri, 7 Mar 2003 16:11:51 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h27MBrwX24985840; Fri, 7 Mar 2003 16:11:53 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h27MBrx25054; Fri, 7 Mar 2003 16:11:53 -0600 Subject: Re: unwritten extents vs. fragmentation From: Steve Lord To: Rick Smith Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047075112.6402.64.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 07 Mar 2003 16:11:52 -0600 X-archive-position: 3123 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2492 Lines: 59 On Fri, 2003-03-07 at 16:05, Rick Smith wrote: > By preallocation are you referring to an ioctl after opening a file > with XFS_IOC_RESVSP64? If so, does this only have an effect with > unwritten=1? > Does using the XFS_IOC_RESVSP64 ioctl guarantee contiguous extents when > the file is written, or at least make more of an effort to ensure contiguous > extent allocation? As you may remember from some of my previous emails, my > goal is to have each file written as contiguous as possible and have each > consecutive file as close to the previous file as possible. I have been > experimenting with the realtime subvolume (due to the limited documentation > speaking of reduced fragmentation), but I have not had much success so far. > Thanks. They do not guarantee continuous space, but they go to the allocator and ask for it all in one go. If it is available, you will get continuous space. I did not realize you had control over the app writing the data. The calls are always available, but with unwritten extent support off, they are restricted to root. Steve > > Rick > > >From: Steve Lord > >To: Rick Smith > >CC: linux-xfs@oss.sgi.com > >Subject: Re: unwritten extents vs. fragmentation > >Date: 07 Mar 2003 15:32:54 -0600 > > > >On Fri, 2003-03-07 at 15:26, Rick Smith wrote: > > > A couple questions. Does enabling unwritten extent flagging in XFS > > > ultimately reduce filesystem fragmentation? What is the downside of > >enabling > > > unwritten extents other than slower write performance? Thanks. > > > >It should make no difference to physical fragmentation, and in the > >normal I/O path unwritten extents should not be used. They only come > >into play with space preallocation. In this case they will slow > >down I/O somewhat, but provide more security in that you cannot > >use unwritten extents to read old data. This is why the prealloc > >calls on -d unwritten=0 filesystems are restricted to root. > > > >Steve > > > >-- > > > >Steve Lord voice: +1-651-683-3511 > >Principal Engineer, Filesystem Software email: lord@sgi.com > > > _________________________________________________________________ > The new MSN 8: smart spam protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Mar 7 14:48:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 14:48:58 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27Mmnq9021388 for ; Fri, 7 Mar 2003 14:48:50 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h27LdnY2006934; Fri, 7 Mar 2003 13:39:49 -0800 From: "l.a walsh" To: "'Eric Sandeen'" Cc: Subject: RE: Just some odd questions out of the blue... Date: Fri, 7 Mar 2003 13:39:49 -0800 Message-ID: <000001c2e4f2$14753780$1403a8c0@sc.tlinx.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 3124 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: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 3901 Lines: 96 > -----Original Message----- > From: linux-xfs-bounce@oss.sgi.com > [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Eric Sandeen > Sent: Thu, Mar 06, 2003 6:00p > To: l.a walsh > Cc: linux-xfs@oss.sgi.com > Subject: Re: Just some odd questions out of the blue... > > > On Thu, 6 Mar 2003, l.a walsh wrote: > > > So lets say you had 2 disks...would it make sense to put the log > > of disk1 on disk2 and the log of disk2 on disk1? This would be > > Yes, external logs are available for this reason. > > Your cross-log scenario would probably only help if you were > really only > writing to 1 fs at a time. --- Yes...but say you have 1 disk setup with system and home dir where home dir is mainly docs and email, and second disk is setup mainly to do builds on.... > > Second question ... suppose one disk was faster than the other -- > > or one was a sda and the other hda. How much metadata is written > > compared to file data, i.e. is there some average ratio or range? > > You can look at the stats with the xfs_stats.pl script in cvs. > It really depends on the nature of your workload. ---- CVS again...everything is CVS...seems like every piece of software I'm interested in I've got to pull down the whole bloomin CVS tree...grumble. I don't suppose such scripts could be put into xfsprogs or xfsprogs-devel? (not right this second...but just in general)... > > On the assumption that metadata is smaller, seem like one could use > > a slower log disk for a primary work disk, and the slower log disk > > is mostly archival things that aren't written alot, but more read > > alot -- like mp3's, or CD images....things where the slower > read isn't > > going to be a big problem. > > True, for reads the log speed isn't critical, but for writes again > it will depend on your workload. --- Yeah, if I think of builds / mail-read/browse as separate workloads that may overlap, but mail-read/browsing isn't usually that disk intensive...compared to a parallel build. > > When writing to disks with a cache, does XFS force any flushes (like > > on log data?) Seem like even if you had a slower disk but an 8Mb > > cache you could keep up with a fairly good write speed on the faster > > disk. > > Which is great until you crash, if the cached data is lost... --- Well...xfs's delayed writes are exactly this type of operation: grouping writes in hopes of decreasing fragmentation. If your system is stable and stays up for many days except for planned reboots, and you're on UPS, one might trade off speed for risk. On the other hand, if you are testing a new kernel or a new patch, you might want to disable some of those features -- it's like syslog, normally many log messages are written asynchronously, but if I'm expecting trouble, I'll change them to synchronous and mount disks as synchronous, though drive caching is usually ok unless I'm also expecting a power outage :-). > I don't think xfs explicitly does any IDE cache flushing. > > > But here's another Q...if you don't flush the on disk cache after > > a log write, then it is 'granted' that the potential for metadata > > loss is at least the size of the on-disk cache. That could beg > > the question -- would it be of any benefit to write a pseudo-block > > device that lives on top of a disk that just does read-write > > caching -- maybe it lives with a 64Mb Buffer and attempts to use > > geometry knowledge of the disk to optimize head motion, whatever. > > Ick. :) I think the drive mfgr is the only one who has the > knowledge --- Hmm....I thought that info was available for some drives in scsiinfo, though for IDE drives the best you could do would be to section up the disk by "logical track", assuming that a logical track would normally map to a group physical sectors that are physically (barring defect management) located near each other, though that is an assumption, admittedly. -l From owner-linux-xfs@oss.sgi.com Fri Mar 7 17:49:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 17:49:33 -0800 (PST) Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h281nPq9027586 for ; Fri, 7 Mar 2003 17:49:26 -0800 Received: from [209.96.189.100] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.36 #1) id 18rTSl-000L7j-00 for linux-xfs@oss.sgi.com; Fri, 07 Mar 2003 20:49:24 -0500 Received: from daydream.shannon.net (daydream.shannon.net [192.168.1.10]) by escape.shannon.net (8.11.6/8.11.3) with ESMTP id h281Jjr14337 for ; Fri, 7 Mar 2003 20:19:46 -0500 (EST) Received: from daydream.shannon.net (localhost [127.0.0.1]) by daydream.shannon.net (8.12.4/8.11.4) with ESMTP id h281JjUY003810 for ; Fri, 7 Mar 2003 20:19:45 -0500 Received: (from shannon@localhost) by daydream.shannon.net (8.12.4/8.12.4/Submit) id h281JjnB003809 for linux-xfs@oss.sgi.com; Fri, 7 Mar 2003 20:19:45 -0500 Date: Fri, 7 Mar 2003 20:19:45 -0500 From: Charles Shannon Hendrix To: linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030308011942.GH1102@widomaker.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 3125 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: shannon@widomaker.com Precedence: bulk X-list: linux-xfs Content-Length: 1076 Lines: 28 On Fri, Mar 07, 2003 at 07:55:32AM -0600, Eric Sandeen wrote: > I think it's important to remember that XFS has been in use for -many- > years on irix, on everything from personal desktops to huge servers > with filesystems on the order of tens of terabytes. While I'm > sure that usage patterns will affect the life of any device, I don't think > that this has been a problem in general. I think this is mostly a matter of IDE disks often not being very high quality. So far, I've not had SCSI disks which died show a particular excessive defect pattern in places like the superblock, swap spaces, and other high-use areas. Of course, I usually don't look. I _have_ seen it on IDE. > (And, I can think of other disk usages patterns which could result in > disproportional use of one area of a disk - /var/log partitions, for > example). I would imagine that programs which access raw partitions would have usage patterns which would hit certain areas very hard in comparison to others. -- UNIX/Perl/C/Pizza____________________s h a n n o n@wido !SPAM maker.com From owner-linux-xfs@oss.sgi.com Fri Mar 7 17:49:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Mar 2003 17:49:33 -0800 (PST) Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h281nQq9027589 for ; Fri, 7 Mar 2003 17:49:27 -0800 Received: from [209.96.189.100] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.36 #1) id 18rTSn-000L7j-00 for linux-xfs@oss.sgi.com; Fri, 07 Mar 2003 20:49:26 -0500 Received: from daydream.shannon.net (daydream.shannon.net [192.168.1.10]) by escape.shannon.net (8.11.6/8.11.3) with ESMTP id h281Emr13833 for ; Fri, 7 Mar 2003 20:14:48 -0500 (EST) Received: from daydream.shannon.net (localhost [127.0.0.1]) by daydream.shannon.net (8.12.4/8.11.4) with ESMTP id h281EiUY003537 for ; Fri, 7 Mar 2003 20:14:44 -0500 Received: (from shannon@localhost) by daydream.shannon.net (8.12.4/8.12.4/Submit) id h281EdmB003536 for linux-xfs@oss.sgi.com; Fri, 7 Mar 2003 20:14:39 -0500 Date: Fri, 7 Mar 2003 20:14:39 -0500 From: Charles Shannon Hendrix To: linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030308011435.GG1102@widomaker.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3E67BFA7.4080601@echostar.com> <20030306221631.GA6770@f00f.org> <3E67CB02.2030600@echostar.com> <1046990328.439.273.camel@stout.americas.sgi.com> <3E67D0CE.3080902@echostar.com> <1046992493.1388.235.camel@averell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1046992493.1388.235.camel@averell> User-Agent: Mutt/1.4i X-archive-position: 3125 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: shannon@widomaker.com Precedence: bulk X-list: linux-xfs Content-Length: 1042 Lines: 25 On Fri, Mar 07, 2003 at 12:14:53AM +0100, Andi Kleen wrote: > It was long suspected that journaling FS are bad for cheap IDE disks, > but you're probably the first to really verify it using an IDE analyzer. > There were also some informal experiences on that collected by the > reiserfs people. Thanks for verify this. I've thought about this too, as I once found damage in superblocks even on other drives, across about 5 different IDE drives that had "gone bad". I found error patterns, and it appeard to me it was occuring in superblocks and in one case, a journal. Does this mean that these areas are also wearing out even good disks, just not as fast? I know over the last 10 years, I've replaced IDE drives at a rate several times higher than SCSI drives, even for "good" IDE drives. They don't seem to last very well. Seems like the high-end Seagates and IBMs aren't too bad so far, but I've not run the IDE versions long enough to see problems yet. -- UNIX/Perl/C/Pizza____________________s h a n n o n@wido !SPAM maker.com From owner-linux-xfs@oss.sgi.com Sat Mar 8 06:31:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Mar 2003 06:31:12 -0800 (PST) Received: from smtp.ii.uib.no (eik.ii.uib.no [129.177.16.3]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h28EV3q9006048 for ; Sat, 8 Mar 2003 06:31:04 -0800 Received: from apal-192.ii.uib.no ([129.177.192.27] helo=apal.ii.uib.no) by smtp.ii.uib.no with esmtp (Exim 4.12) id 18re6Z-0000xs-00; Sat, 08 Mar 2003 14:11:11 +0100 Received: (from janfrode@localhost) by apal.ii.uib.no (8.11.6+Sun/8.11.6) id h28DBBp20999; Sat, 8 Mar 2003 14:11:11 +0100 (MET) Date: Sat, 8 Mar 2003 14:11:10 +0100 From: Jan-Frode Myklebust To: Bernhard Erdmann Cc: linux-xfs@oss.sgi.com Subject: Re: suppressing syncs on spools Message-ID: <20030308141110.B19567@ii.uib.no> References: <1047052002.3e68bee241784@apollo.berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1047052002.3e68bee241784@apollo.berdmann.de>; from be@berdmann.de on Fri, Mar 07, 2003 at 04:46:42PM +0100 X-Spam-Score: -8.9 (--------) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *18re6Z-0000xs-00*PyKkwmX7oEM* X-archive-position: 3126 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: janfrode@parallab.no Precedence: bulk X-list: linux-xfs Content-Length: 726 Lines: 22 On Fri, Mar 07, 2003 at 04:46:42PM +0100, Bernhard Erdmann wrote: > > for a spool/scratch filesystem I'm only interested in speed. Disk I/O > should be as minimal as possible. Files will be deleted some 1/10 sec or > some secs later. It won't hurt if files are lost if the box crashes. > This filesystem can even be mkfs'd at system boot. > > Just speed, like a ram disk, but I don't want to spend 1-2 GB to a ram disk. Have you considered tmpfs? tmpfs can live in both ram and disk (swap). Read linux/Documentation/filesystems/tmpfs.txt. > > Are there mount options or mkfs.xfs options which can help to reduce > disk I/O? Don't know of any, except maybe putting the log on a ramdisk? And of course 'noatime'. -jf From owner-linux-xfs@oss.sgi.com Sat Mar 8 06:54:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Mar 2003 06:54:30 -0800 (PST) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h28Eriq9006593 for ; Sat, 8 Mar 2003 06:54:25 -0800 Received: from rss1.rz.uni-regensburg.de (rss1.rz.uni-regensburg.de [132.199.1.200]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with SMTP id h28ErgZr018269 for ; Sat, 8 Mar 2003 15:53:42 +0100 Received: (qmail 13534 invoked from network); 8 Mar 2003 15:53:41 +0100 Received: from pc9391.physik.uni-regensburg.de (HELO pc9391) (guc28561@132.199.98.219) by rss1.rz.uni-regensburg.de with SMTP; 8 Mar 2003 15:53:41 +0100 Date: Sat, 8 Mar 2003 15:53:41 +0100 From: Christian Guggenberger To: "l.a walsh" Cc: "'Eric Sandeen'" , linux-xfs@oss.sgi.com Subject: Re: Just some odd questions out of the blue... Message-ID: <20030308155341.A5088@pc9391.uni-regensburg.de> References: <000001c2e4f2$14753780$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <000001c2e4f2$14753780$1403a8c0@sc.tlinx.org>; from xfs@tlinx.org on Fri, Mar 07, 2003 at 22:39:49 +0100 X-Mailer: Balsa 1.2.4 X-archive-position: 3127 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: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 1717 Lines: 47 On 07.03.2003 22:39 l.a walsh wrote: > > > -----Original Message----- > > From: linux-xfs-bounce@oss.sgi.com > > [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Eric Sandeen > > Sent: Thu, Mar 06, 2003 6:00p > > To: l.a walsh > > Cc: linux-xfs@oss.sgi.com > > Subject: Re: Just some odd questions out of the blue... > > > > > > On Thu, 6 Mar 2003, l.a walsh wrote: > > > > > So lets say you had 2 disks...would it make sense to put the log > > > of disk1 on disk2 and the log of disk2 on disk1? This would be > > > > Yes, external logs are available for this reason. > > > > Your cross-log scenario would probably only help if you were > > really only > > writing to 1 fs at a time. > --- > Yes...but say you have 1 disk setup with system and home > dir where home dir is mainly docs and email, and second disk is > setup mainly to do builds on.... > > > > Second question ... suppose one disk was faster than the other -- > > > or one was a sda and the other hda. How much metadata is written > > > compared to file data, i.e. is there some average ratio or range? > > > > You can look at the stats with the xfs_stats.pl script in cvs. > > It really depends on the nature of your workload. > ---- > CVS again...everything is CVS...seems like every piece of > software I'm interested in I've got to pull down the whole bloomin > CVS tree...grumble. I don't suppose such scripts could be put into > xfsprogs or xfsprogs-devel? (not right this second...but just in > general)... > You probably want to browse the cvs web-tree, and download the script you are looking for.... There's no need for a full cvs-checkout, I think. http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfsmisc/ Christian From owner-linux-xfs@oss.sgi.com Sat Mar 8 07:08:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Mar 2003 07:08:57 -0800 (PST) Received: from silver.digirati.com.br (silver.digirati.com.br [200.185.109.126]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h28F8Bq9007167 for ; Sat, 8 Mar 2003 07:08:52 -0800 Received: from wsmichel (titanio.k8.com.br [200.185.109.31]) (authenticated (0 bits)) by silver.digirati.com.br (8.11.6/8.11.6) with ESMTP id h28F89C19020 for ; Sat, 8 Mar 2003 12:08:09 -0300 Message-ID: <011401c2e584$98c97ae0$1601070a@mz.digirati.com.br> From: "Michel Machado" To: Subject: Re: LBA to File? Date: Sat, 8 Mar 2003 12:08:37 -0300 Organization: Digirati MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 3128 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: michel@digirati.com.br Precedence: bulk X-list: linux-xfs Content-Length: 107 Lines: 7 Dears, How do I can to get the defect list of a IDE or/and SCSI disk on Linux? [ ]'s Michel Machado From owner-linux-xfs@oss.sgi.com Sat Mar 8 13:37:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Mar 2003 13:38:01 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h28LbAq9012113 for ; Sat, 8 Mar 2003 13:37:51 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 64FFC1833FF7; Sat, 8 Mar 2003 13:37:08 -0800 (PST) Date: Sat, 8 Mar 2003 13:37:08 -0800 From: Chris Wedgwood To: Michel Machado Cc: linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030308213708.GA17656@f00f.org> References: <011401c2e584$98c97ae0$1601070a@mz.digirati.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011401c2e584$98c97ae0$1601070a@mz.digirati.com.br> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 3129 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 245 Lines: 11 On Sat, Mar 08, 2003 at 12:08:37PM -0300, Michel Machado wrote: > How do I can to get the defect list of a IDE or/and SCSI disk on > Linux? for scsi for 'scsiinfo' ... i'm not sure if there is any standardized way to do this for IDE --cw From owner-linux-xfs@oss.sgi.com Sat Mar 8 14:53:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Mar 2003 14:53:37 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e12a.dsl.mediaWays.net [213.20.225.42]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h28Mqoq9012891 for ; Sat, 8 Mar 2003 14:53:34 -0800 Received: from ente.berdmann.de ([192.168.1.6] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 18rnBM-0001xj-00; Sat, 08 Mar 2003 23:52:44 +0100 Message-ID: <3E6A743C.3080603@berdmann.de> Date: Sat, 08 Mar 2003 23:52:44 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4a) Gecko/20030308 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Jan-Frode Myklebust CC: linux-xfs@oss.sgi.com Subject: Re: suppressing syncs on spools References: <1047052002.3e68bee241784@apollo.berdmann.de> <20030308141110.B19567@ii.uib.no> In-Reply-To: <20030308141110.B19567@ii.uib.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3130 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: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 391 Lines: 12 > Have you considered tmpfs? tmpfs can live in both ram and disk (swap). > Read linux/Documentation/filesystems/tmpfs.txt. I already read the article on IBM developernetworks about it in the meanwhile. Seems it can do what I want when tmpfs' size is limited to say 500 MB. > Don't know of any, except maybe putting the log on a ramdisk? And of > course 'noatime'. Thanks for the hint! From owner-linux-xfs@oss.sgi.com Sat Mar 8 18:33:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Mar 2003 18:33:19 -0800 (PST) Received: from sparrow.stearns.org (101.24.177.216.inaddr.g4.Net [216.177.24.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h292XAq9014477; Sat, 8 Mar 2003 18:33:11 -0800 Received: from localhost (localhost [127.0.0.1]) by sparrow.stearns.org (8.11.6/8.11.6) with ESMTP id h292X1X19395; Sat, 8 Mar 2003 21:33:02 -0500 Date: Sat, 8 Mar 2003 21:33:01 -0500 (EST) From: William Stearns X-X-Sender: wstearns@sparrow Reply-To: William Stearns To: owner-xfs@oss.sgi.com, , cc: William Stearns , ML-uml-devel Subject: XFS in 2.5.64-bk3, compile problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3131 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: wstearns@pobox.com Precedence: bulk X-list: linux-xfs Content-Length: 2666 Lines: 56 Good day, all, My _sincere_ apologies if this a known issue; I haven't followed xfs development. In compiling a 2.5.64-bk3 uml kernel, I found this error when xfs was compiled in: xfs: gcc -Wp,-MD,fs/xfs/.xfs_mount.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -U__i386__ -Ui386 -g -D__arch_um__ -DSUBARCH=\"i386\" -D_LARGEFILE64_SOURCE -Iarch/um/include -Derrno=kernel_errno -Dsigprocmask=kernel_sigprocmask -I/usr/src/uml-linux/linux-2.5.64-bk3-63um1/arch/um/kernel/tt/include -I/usr/src/uml-linux/linux-2.5.64-bk3-63um1/arch/um/kernel/skas/include -nostdinc -iwithprefix include -Ifs/xfs -funsigned-char -DKBUILD_BASENAME=xfs_mount -DKBUILD_MODNAME=xfs -c -o fs/xfs/xfs_mount.o fs/xfs/xfs_mount.c fs/xfs/xfs_mount.c: In function `xfs_initialize_perag': fs/xfs/xfs_mount.c:339: Unrecognizable insn: (insn/i 164 594 597 (parallel[ (set (reg:SI 0 eax) (asm_operands ("") ("=a") 0[ (reg:DI 1 edx) ] [ (asm_input:DI ("A")) ] ("fs/xfs/linux/xfs_linux.h") 255)) (set (reg:SI 1 edx) (asm_operands ("") ("=d") 1[ (reg:DI 1 edx) ] [ (asm_input:DI ("A")) ] ("fs/xfs/linux/xfs_linux.h") 255)) (clobber (reg:QI 19 dirflag)) (clobber (reg:QI 18 fpsr)) (clobber (reg:QI 17 flags)) ] ) -1 (insn_list 163 (nil)) (nil)) fs/xfs/xfs_mount.c:339: confused by earlier errors, bailing out make[2]: *** [fs/xfs/xfs_mount.o] Error 1 make[1]: *** [fs/xfs] Error 2 make: *** [fs] Error 2 The compile options used are almost identical to http://www.stearns.org/uml/config-2.5.64-bk3-63um1-3 , except - of course: CONFIG_XFS_FS=y Compiler is gcc-c++-2.96-113, gcc-2.96-113, base system is Redhat 7.3. If there are more details I can provide, please let me know. Again, I'm sorry if this is a known problem. Cheers, - Bill --------------------------------------------------------------------------- "Nothing scares me. Except Pepsi. That stuff will keep me awake at night." (Courtesy of Allaria on Slashdot) -------------------------------------------------------------------------- William Stearns (wstearns@pobox.com). Mason, Buildkernel, freedups, p0f, rsync-backup, ssh-keyinstall, dns-check, more at: http://www.stearns.org Linux articles at: http://www.opensourcedigest.com -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Sun Mar 9 02:42:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Mar 2003 02:42:26 -0800 (PST) Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h29AgHq9020837 for ; Sun, 9 Mar 2003 02:42:19 -0800 Received: from kenzo.iwr.uni-heidelberg.de (kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.11.2/8.11.1) with ESMTP id h29AgFX13505; Sun, 9 Mar 2003 11:42:15 +0100 (MET) Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.11.6/8.11.6) with ESMTP id h29AgE732731; Sun, 9 Mar 2003 11:42:14 +0100 Date: Sun, 9 Mar 2003 11:42:14 +0100 (CET) From: Bogdan Costescu To: Chris Wedgwood cc: Michel Machado , Subject: Re: LBA to File? In-Reply-To: <20030308213708.GA17656@f00f.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3132 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: bogdan.costescu@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs Content-Length: 653 Lines: 20 On Sat, 8 Mar 2003, Chris Wedgwood wrote: > On Sat, Mar 08, 2003 at 12:08:37PM -0300, Michel Machado wrote: > > How do I can to get the defect list of a IDE or/and SCSI disk on > > Linux? > for scsi for 'scsiinfo' ... i'm not sure if there is any standardized > way to do this for IDE S.M.A.R.T. is supposed to provide this kind of info for IDE. See: http://sourceforge.net/projects/smartmontools/ -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From owner-linux-xfs@oss.sgi.com Sun Mar 9 03:05:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Mar 2003 03:05:23 -0800 (PST) Received: from jello277.jellocom.de (root@jello277.jellocom.de [217.17.194.152]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h29B5Gq9021400 for ; Sun, 9 Mar 2003 03:05:18 -0800 Received: from cobonote.intranet.cobonet.de (pD903268F.dip0.t-ipconnect.de [217.3.38.143]) (authenticated bits=0) by jello277.jellocom.de (8.12.8/8.12.1) with ESMTP id h29B5AWb030120; Sun, 9 Mar 2003 12:05:12 +0100 Content-Type: text/plain; charset="iso-8859-15" From: Thomas Bittermann To: juergen.sauer@automatix.de Subject: Re: Kernel with XFS + nvidia/nforce2 Chipset ? Date: Sun, 9 Mar 2003 12:02:50 +0100 User-Agent: KMail/1.4.3 References: <200303051048.54271.juergen.sauer@automatix.de> <200303052309.51984.t.bittermann@online.de> <200303071156.29730.juergen.sauer@automatix.de> In-Reply-To: <200303071156.29730.juergen.sauer@automatix.de> Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Message-Id: <200303091202.50542.pufferbrater@cobonet.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h29B5Jq9021401 X-archive-position: 3133 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: pufferbrater@cobonet.de Precedence: bulk X-list: linux-xfs Content-Length: 323 Lines: 11 [...] > Which CVS Source do you use ? I'm using CVSROOT=':pserver:cvs@oss.sgi.com:/cvs', but when I started off, (2.4.21-pre4-ac1 and CVS from feb) there was quite a lot of merging necessary. From then I'm doing "cvs diff" and get all the XFS related changes this way. I can send you my patch if you like. cheers Thomas From owner-linux-xfs@oss.sgi.com Sun Mar 9 06:18:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Mar 2003 06:18:48 -0800 (PST) Received: from fruit.eu.org (qmailr@c3607d26.cable.wanadoo.nl [195.96.125.38]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h29EIYq9027961 for ; Sun, 9 Mar 2003 06:18:38 -0800 Received: (qmail 6551 invoked by uid 500); 9 Mar 2003 14:18:32 -0000 Date: Sun, 9 Mar 2003 15:18:32 +0100 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: Re: XFS in 2.5.64-bk3, compile problem Message-ID: <20030309141832.GT13846@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-oi: oi User-Agent: Mutt/1.5.3i X-archive-position: 3134 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: wsl@fruit.eu.org Precedence: bulk X-list: linux-xfs Content-Length: 731 Lines: 23 On 2003-03-08 21:33:01-0500, William Stearns wrote: > Good day, all, > My _sincere_ apologies if this a known issue; I haven't followed > xfs development. > In compiling a 2.5.64-bk3 uml kernel, I found this error when xfs > was compiled in: > [snip] > fs/xfs/xfs_mount.c:339: Unrecognizable insn: [snip] > Compiler is gcc-c++-2.96-113, gcc-2.96-113, base system is Redhat 7.3. The problem is in gcc, not in the kernel. Red Hat ships with a broken, unofficial beta gcc. Please replace that gcc with gcc 3.2.2 (and while you're at it, replace Red Hat with a competent distribution that provides a working compiler). You'll find that your kernel compiles fine. It does here ;) Cheers, -- Wessel Dankers From owner-linux-xfs@oss.sgi.com Sun Mar 9 07:54:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Mar 2003 07:55:04 -0800 (PST) Received: from K-7.stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h29FsFq9030506 for ; Sun, 9 Mar 2003 07:54:56 -0800 Received: from stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id h29FtA56023482 for ; Sun, 9 Mar 2003 16:55:10 +0100 Message-ID: <3E6B63DE.9040308@stesmi.com> Date: Sun, 09 Mar 2003 16:55:10 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS in 2.5.64-bk3, compile problem References: <20030309141832.GT13846@fruit.eu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (K-7.stesmi.com) X-archive-position: 3135 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: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 463 Lines: 14 Hi. > The problem is in gcc, not in the kernel. Red Hat ships with a broken, > unofficial beta gcc. Please replace that gcc with gcc 3.2.2 (and while > you're at it, replace Red Hat with a competent distribution that provides > a working compiler). You'll find that your kernel compiles fine. > It does here ;) I'm sorry, I missed the sign around your neck saying "Troll". You could put that in your sig for instance so that it's readily apparent. // Stefan From owner-linux-xfs@oss.sgi.com Sun Mar 9 08:24:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Mar 2003 08:24:40 -0800 (PST) Received: from fruit.eu.org (qmailr@c3607d26.cable.wanadoo.nl [195.96.125.38]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h29GNtq9032100 for ; Sun, 9 Mar 2003 08:24:36 -0800 Received: (qmail 6728 invoked by uid 500); 9 Mar 2003 16:23:55 -0000 Date: Sun, 9 Mar 2003 17:23:55 +0100 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: Re: XFS in 2.5.64-bk3, compile problem Message-ID: <20030309162355.GU13846@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20030309141832.GT13846@fruit.eu.org> <3E6B63DE.9040308@stesmi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E6B63DE.9040308@stesmi.com> X-oi: oi User-Agent: Mutt/1.5.3i X-archive-position: 3136 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: wsl@fruit.eu.org Precedence: bulk X-list: linux-xfs Content-Length: 735 Lines: 19 On 2003-03-09 16:55:10+0100, Stefan Smietanowski wrote: > I'm sorry, I missed the sign around your neck saying "Troll". > > You could put that in your sig for instance so that it's readily apparent. Funny, I don't see a useful reply to his question from you on the list. Perhaps it got lost somewhere? Pardon me for being harsh towards Red Hat for shipping a broken compiler, but if you have such a problem with the tone of my reply, may I kindly suggest that you answer such questions about the infamous gcc 2.96 "release" yourself next time? If you feel a need for additional argumentation, please follow up in private; discussions like this are a waste of mailing list bandwidth. Thanks, -- Wessel Dankers From owner-linux-xfs@oss.sgi.com Sun Mar 9 12:45:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Mar 2003 12:45:31 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h29KjLq9002904 for ; Sun, 9 Mar 2003 12:45:23 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id C71FF1834559; Sun, 9 Mar 2003 12:45:21 -0800 (PST) Date: Sun, 9 Mar 2003 12:45:21 -0800 From: Chris Wedgwood To: Bogdan Costescu Cc: Michel Machado , linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030309204521.GA22210@f00f.org> References: <20030308213708.GA17656@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 3137 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 256 Lines: 11 On Sun, Mar 09, 2003 at 11:42:14AM +0100, Bogdan Costescu wrote: > S.M.A.R.T. is supposed to provide this kind of info for IDE. See: > > http://sourceforge.net/projects/smartmontools/ Alas, it seems it doesnt work for lots of (cheap) drives... --cw From owner-linux-xfs@oss.sgi.com Sun Mar 9 13:19:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Mar 2003 13:19:32 -0800 (PST) Received: from hell.org.pl (qmailr@hell.org.pl [212.244.218.42]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h29LJJq9003654 for ; Sun, 9 Mar 2003 13:19:21 -0800 Received: (qmail 15467 invoked by uid 777); 9 Mar 2003 21:19:24 -0000 Date: Sun, 9 Mar 2003 22:19:24 +0100 From: Karol Kozimor To: Chris Wedgwood Cc: Bogdan Costescu , Michel Machado , linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030309211924.GA31809@hell.org.pl> Mail-Followup-To: Chris Wedgwood , Bogdan Costescu , Michel Machado , linux-xfs@oss.sgi.com References: <20030308213708.GA17656@f00f.org> <20030309204521.GA22210@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <20030309204521.GA22210@f00f.org> User-Agent: Mutt/1.4i X-archive-position: 3138 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: sziwan@hell.org.pl Precedence: bulk X-list: linux-xfs Content-Length: 412 Lines: 13 Thus wrote Chris Wedgwood: > > S.M.A.R.T. is supposed to provide this kind of info for IDE. See: > > http://sourceforge.net/projects/smartmontools/ > Alas, it seems it doesnt work for lots of (cheap) drives... Seriously? Are there any recent drives that don't support S.M.A.R.T? Perhaps it just hasn't been enabled (either in BIOS, or by smartctl)? Best regards, -- Karol 'sziwan' Kozimor sziwan@hell.org.pl From owner-linux-xfs@oss.sgi.com Sun Mar 9 13:30:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Mar 2003 13:30:43 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h29LULq9004162 for ; Sun, 9 Mar 2003 13:30:22 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 57E181834558; Sun, 9 Mar 2003 13:30:21 -0800 (PST) Date: Sun, 9 Mar 2003 13:30:21 -0800 From: Chris Wedgwood To: Bogdan Costescu , Michel Machado , linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030309213021.GA22398@f00f.org> References: <20030308213708.GA17656@f00f.org> <20030309204521.GA22210@f00f.org> <20030309211924.GA31809@hell.org.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030309211924.GA31809@hell.org.pl> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 3139 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 384 Lines: 15 On Sun, Mar 09, 2003 at 10:19:24PM +0100, Karol Kozimor wrote: > Seriously? Are there any recent drives that don't support S.M.A.R.T? I've not checked super recent drives, but some about a year or so old do support SMART but it seems in a limitied (ie. broken) capacity. > Perhaps it just hasn't been enabled (either in BIOS, or by > smartctl)? Nope, just cheap drives. --cw From owner-linux-xfs@oss.sgi.com Mon Mar 10 02:02:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 02:02:11 -0800 (PST) Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2AA1Kq9015805 for ; Mon, 10 Mar 2003 02:02:05 -0800 Received: from [209.96.179.160] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.36 #1) id 18ro47-00055L-00 for linux-xfs@oss.sgi.com; Sat, 08 Mar 2003 18:49:19 -0500 Received: from daydream.shannon.net (daydream.shannon.net [192.168.1.10]) by escape.shannon.net (8.11.6/8.11.3) with ESMTP id h28NA2r14147 for ; Sat, 8 Mar 2003 18:10:02 -0500 (EST) Received: from daydream.shannon.net (localhost [127.0.0.1]) by daydream.shannon.net (8.12.4/8.11.4) with ESMTP id h28N9xUY007886 for ; Sat, 8 Mar 2003 18:09:59 -0500 Received: (from shannon@localhost) by daydream.shannon.net (8.12.4/8.12.4/Submit) id h28N9sAe007885 for linux-xfs@oss.sgi.com; Sat, 8 Mar 2003 18:09:54 -0500 Date: Sat, 8 Mar 2003 18:09:54 -0500 From: Charles Shannon Hendrix To: linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030308230950.GA7882@widomaker.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <011401c2e584$98c97ae0$1601070a@mz.digirati.com.br> <20030308213708.GA17656@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030308213708.GA17656@f00f.org> User-Agent: Mutt/1.4i X-archive-position: 3140 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: shannon@widomaker.com Precedence: bulk X-list: linux-xfs Content-Length: 486 Lines: 15 On Sat, Mar 08, 2003 at 01:37:08PM -0800, Chris Wedgwood wrote: > On Sat, Mar 08, 2003 at 12:08:37PM -0300, Michel Machado wrote: > > > How do I can to get the defect list of a IDE or/and SCSI disk on > > Linux? > > for scsi for 'scsiinfo' ... i'm not sure if there is any standardized > way to do this for IDE You can get the S.M.A.R.T. tools to query SCSI and IDE drives, to varying degrees of success. -- UNIX/Perl/C/Pizza____________________s h a n n o n@wido !SPAM maker.com From owner-linux-xfs@oss.sgi.com Mon Mar 10 02:49:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 02:49:43 -0800 (PST) Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2AAnXq9019161 for ; Mon, 10 Mar 2003 02:49:35 -0800 Received: from kenzo.iwr.uni-heidelberg.de (kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.11.2/8.11.1) with ESMTP id h2AAnWX07554; Mon, 10 Mar 2003 11:49:32 +0100 (MET) Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.11.6/8.11.6) with ESMTP id h2AAnVZ12033; Mon, 10 Mar 2003 11:49:31 +0100 Date: Mon, 10 Mar 2003 11:49:30 +0100 (CET) From: Bogdan Costescu To: Chris Wedgwood cc: Michel Machado , Subject: Re: LBA to File? In-Reply-To: <20030309213021.GA22398@f00f.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3141 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: bogdan.costescu@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs Content-Length: 1198 Lines: 26 On Sun, 9 Mar 2003, Chris Wedgwood wrote: > I've not checked super recent drives, but some about a year or so old > do support SMART but it seems in a limitied (ie. broken) capacity. S.M.A.R.T. is supposed to be an industry standard. Now, disk manufacturers can on one hand implement only a part of the parameters or introduce extensions to this standard; some other times they might have their own interpretation of what a parameter should mean. My impression is that it doesn't depend on whether they are cheap drives or not, but more on the manufacturer - f.e. I got almost the same parameters for IBM drives from different drive families of various ages (last 2 years or so). IDE controllers cards or mainboards have had S.M.A.R.T. related functions for several years - I have Intel 440BX based mainboards from 1998 that offer the option of enabling it and give a warning message if something is wrong with the disk at boot time. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From owner-linux-xfs@oss.sgi.com Mon Mar 10 04:54:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 04:54:15 -0800 (PST) Received: from K-7.stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2ACrPq9022242 for ; Mon, 10 Mar 2003 04:54:06 -0800 Received: from stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id h2ACsR56029523 for ; Mon, 10 Mar 2003 13:54:27 +0100 Message-ID: <3E6C8B03.1060603@stesmi.com> Date: Mon, 10 Mar 2003 13:54:27 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS in 2.5.64-bk3, compile problem References: <20030309141832.GT13846@fruit.eu.org> <3E6B63DE.9040308@stesmi.com> <20030309162355.GU13846@fruit.eu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (K-7.stesmi.com) X-archive-position: 3142 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: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 1332 Lines: 29 Wessel Dankers wrote: > On 2003-03-09 16:55:10+0100, Stefan Smietanowski wrote: > >>I'm sorry, I missed the sign around your neck saying "Troll". >> >>You could put that in your sig for instance so that it's readily apparent. > > > Funny, I don't see a useful reply to his question from you on the list. > Perhaps it got lost somewhere? Pardon me for being harsh towards Red Hat > for shipping a broken compiler, but if you have such a problem with the > tone of my reply, may I kindly suggest that you answer such questions about > the infamous gcc 2.96 "release" yourself next time? > > If you feel a need for additional argumentation, please follow up in > private; discussions like this are a waste of mailing list bandwidth. 2.96 was a beta compiler, granted. However RedHat went far to make sure it produced code that was production worthy. The first release didn't have a good compiler (7.0) but subsequent compilers were. I'm sick and tired of people racking down on RedHat distributions and compilers all the time. Any compiler has bugs. It is not anything special (as you seem to be believe) with 2.96. Also, a more useful reply would perhaps be "Switch to RedHat 8.0, it's got GCC 3.2" if in fact the bug is caused by a bug in the compiler, but alas, you rack down on RedHat instead. That is trolling. // Stefan From owner-linux-xfs@oss.sgi.com Mon Mar 10 05:07:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 05:07:49 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2AD6wq9022856 for ; Mon, 10 Mar 2003 05:07:38 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id EE2251830676; Mon, 10 Mar 2003 05:06:57 -0800 (PST) Date: Mon, 10 Mar 2003 05:06:57 -0800 From: Chris Wedgwood To: Bogdan Costescu Cc: Michel Machado , linux-xfs@oss.sgi.com Subject: Re: LBA to File? Message-ID: <20030310130657.GA25467@f00f.org> References: <20030309213021.GA22398@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 3143 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 1331 Lines: 33 On Mon, Mar 10, 2003 at 11:49:30AM +0100, Bogdan Costescu wrote: > S.M.A.R.T. is supposed to be an industry standard. Now, disk > manufacturers can on one hand implement only a part of the > parameters or introduce extensions to this standard; some other > times they might have their own interpretation of what a parameter > should mean. There a vendor-specific and vendor-neutral things you can poll. Mostly the interesting ones are vendor-specific and I've not found a source for information about these. > My impression is that it doesn't depend on whether they are cheap > drives or not, but more on the manufacturer - f.e. I got almost the > same parameters for IBM drives from different drive families of > various ages (last 2 years or so). I get different values for almost identical Maxtor drives on the same age.... > IDE controllers cards or mainboards have had S.M.A.R.T. related > functions for several years - I have Intel 440BX based mainboards > from 1998 that offer the option of enabling it and give a warning > message if something is wrong with the disk at boot time. I'm not 100% sure about this, but I don't think controllers and/or mainboards need to know anything about SMART at all... presumably the BIOS knowledge here allows you to disable it in case the OS gets confused or something. --cw From owner-linux-xfs@oss.sgi.com Mon Mar 10 05:25:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 05:25:41 -0800 (PST) Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2ADPVq9024058 for ; Mon, 10 Mar 2003 05:25:33 -0800 Received: from kenzo.iwr.uni-heidelberg.de (kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.11.2/8.11.1) with ESMTP id h2ADPUX11851; Mon, 10 Mar 2003 14:25:30 +0100 (MET) Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.11.6/8.11.6) with ESMTP id h2ADPTO12815; Mon, 10 Mar 2003 14:25:29 +0100 Date: Mon, 10 Mar 2003 14:25:29 +0100 (CET) From: Bogdan Costescu To: Chris Wedgwood cc: Bogdan Costescu , Michel Machado , Subject: SMART (was Re: LBA to File?) In-Reply-To: <20030310130657.GA25467@f00f.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3144 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: bogdan.costescu@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs Content-Length: 1565 Lines: 36 On Mon, 10 Mar 2003, Chris Wedgwood wrote: > There a vendor-specific and vendor-neutral things you can poll. But that's the best you can get while online... Offline, I think that each manufacturer provides some diagnostic tool that can go and test each sector (and destroy any data that was there before :-)) and report if there are problems. 'badblocks' is also useful while offline, although it only reports the present situation and doesn't know about transparent remapping done by the drive firmware. > I'm not 100% sure about this, but I don't think controllers and/or > mainboards need to know anything about SMART at all... They need to know how to read and interpret a bunch of parameters which give the health status of the drive. If some warning value is triggered, you get when you boot some message like: Warning: Disk failure. Please backup and replace disk 1. Press any key to continue. (this is all from memory, so I might get it wrong). When BIOS does the checking it's also supposed to leave the drive with SMART enabled, so more sofisticated tools can read parameters and logs after the OS is loaded. I did however used safely (= no data loss) such drives for months, so it might be that because of some combination of BIOS and drive firmware the early warning was too early... -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From owner-linux-xfs@oss.sgi.com Mon Mar 10 08:02:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 08:02:26 -0800 (PST) Received: from hell.org.pl (qmailr@hell.org.pl [212.244.218.42]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2AG2Fq9027855 for ; Mon, 10 Mar 2003 08:02:21 -0800 Received: (qmail 17708 invoked by uid 777); 10 Mar 2003 16:02:16 -0000 Date: Mon, 10 Mar 2003 17:02:16 +0100 From: Karol Kozimor To: linux-xfs@oss.sgi.com Subject: Internal errors Message-ID: <20030310160216.GA4183@hell.org.pl> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 3145 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: sziwan@hell.org.pl Precedence: bulk X-list: linux-xfs Content-Length: 802 Lines: 19 Hello, Many thanks for the new code debugging the 990 error. I had these since I ever started *trying* to use 2.5.x, that is 2.5.59. Here's what I did: I patched vanilla 2.5.64 with linux-2.5.64-xfs-2003-03-09.patch.bz2, and rebooted the system. As usual, it barfed buring ldconfig state (libraries in /usr/lib). Got about 50 kB of logs. Then I did "ls -l /usr/lib", and got about another 50 kB. Then, as usual, I got the fs/buffer.c error during shutdown, with some xfs functions in call trace. The log is quite largish, so I put it here instead: http://hell.org.pl/~sziwan/xfs-errors My .config is at http://hell.org.pl/~sziwan/config , if it's of any relevance. Is it really so rare that nobody has encountered these errors except me? Best regards, -- Karol 'sziwan' Kozimor sziwan@hell.org.pl From owner-linux-xfs@oss.sgi.com Mon Mar 10 09:05:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 09:05:55 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2AH5jq9005237 for ; Mon, 10 Mar 2003 09:05:47 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2AH5dnH014152 for ; Mon, 10 Mar 2003 09:05:40 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA81521 for ; Mon, 10 Mar 2003 11:05:39 -0600 (CST) Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2AH5dwX26857114 for ; Mon, 10 Mar 2003 11:05:39 -0600 (CST) From: Dean Roehrich Received: by chewtoy.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id LAA25491; Mon, 10 Mar 2003 11:05:38 -0600 (CST) Message-Id: <200303101705.LAA25491@chewtoy.americas.sgi.com> Date: Mon, 10 Mar 2003 11:05:38 -0600 (CST) To: linux-xfs@oss.sgi.com Subject: TAKE - fix invis I/O X-archive-position: 3146 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: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 514 Lines: 16 Date: Mon Mar 10 09:02:33 PST 2003 Workarea: clink.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141339a linux/fs/xfs/linux/xfs_lrw.c - 1.179 - generic_file_read() and generic_file_write_nolock() will update linux inode timestamps. For Invis I/O we have to undo those timestamp updates. Also, in xfs_write, do the xfs_inode timestamp update _after_ the write, rather than before. From owner-linux-xfs@oss.sgi.com Mon Mar 10 10:21:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 10:21:22 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2AILEq9006485 for ; Mon, 10 Mar 2003 10:21:14 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2AILEWU006483 for linux-xfs@oss.sgi.com; Mon, 10 Mar 2003 10:21:14 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2AILBqB006470 for ; Mon, 10 Mar 2003 10:21:12 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2AHloEl005915; Mon, 10 Mar 2003 09:47:50 -0800 Date: Mon, 10 Mar 2003 09:47:50 -0800 Message-Id: <200303101747.h2AHloEl005915@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 228] xfs_repair can't deal with small (agcount==1) filesystems X-Bugzilla-Reason: AssignedTo X-archive-position: 3147 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 889 Lines: 25 http://oss.sgi.com/bugzilla/show_bug.cgi?id=228 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER ------- Additional Comments From cattelan@thebarn.com 2003-03-10 09:47 ------- While 1 AG FSs are valid the lack of redundant info (i.e. no backup SuperBlocks) makes them a bit dangerous. While repair could try to do a some more processing it would require some effort. xfs_repair is currently going through some rewrites to fix some scaling issues, so it's possible to look into the reverse scaling as well. Marking this bug as a later. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Mar 10 12:10:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 12:10:43 -0800 (PST) Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2AK9uq9008405 for ; Mon, 10 Mar 2003 12:10:36 -0800 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel9.hp.com (Postfix) with ESMTP id AEA471C0149C; Mon, 10 Mar 2003 15:09:55 -0500 (EST) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 7FF211C009E8; Mon, 10 Mar 2003 15:09:55 -0500 (EST) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Mon, 10 Mar 2003 15:09:55 -0500 Message-ID: From: "HABBINGA,ERIK (HP-Loveland,ex1)" To: "'linux-xfs@oss.sgi.com'" Cc: "'nathans@snort.melbourne.sgi.com'" Subject: re: TAKE - pagebuf Date: Mon, 10 Mar 2003 15:09:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 3148 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: erik.habbinga@hp.com Precedence: bulk X-list: linux-xfs Content-Length: 1271 Lines: 46 When applying this patch from March 3rd, creating a file system, and then unmounting and remounting xfs filesystems gives me the following error: Mar 10 13:04:07 localhost kernel: XFS mounting filesystem lvm(58,1) Mar 10 13:04:07 localhost kernel: Filesystem "lvm(58,1)": Failed to initialize disk quotas. We're using the -o rw,nodev,noatime,quota mount options. Mounting without the quota option doesn't generate the error. Using a CVS take from March 6th does the same thing, but dumps a stack trace as well. Any ideas? Thanks, Erik Habbinga Hewlett Packard Remove an unused parameter from pagebuf_lookup. Ensure we don't mark a page uptodate in the bsize==pgsize case when we didn't do IO to the entire page. Date: Mon Mar 3 18:17:57 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:140809a linux/fs/xfs/pagebuf/page_buf.c - 1.100 - Remove an unused parameter from pagebuf_lookup. Ensure we don't mark a page uptodate in the bsize==pgsize case when we didn't do IO to the entire page. linux/fs/xfs/pagebuf/page_buf.h - 1.59 linux/fs/xfs/linux/xfs_aops.c - 1.19 - Remove an unused parameter from pagebuf_lookup. From owner-linux-xfs@oss.sgi.com Mon Mar 10 14:48:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 14:48:52 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2AMmiq9031092 for ; Mon, 10 Mar 2003 14:48:45 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2AMmZnH005995 for ; Mon, 10 Mar 2003 14:48:36 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA27408; Tue, 11 Mar 2003 09:47:19 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id JAA70982; Tue, 11 Mar 2003 09:47:19 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2AMijqM001555; Tue, 11 Mar 2003 09:44:45 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2AMiix6001553; Tue, 11 Mar 2003 09:44:44 +1100 Date: Tue, 11 Mar 2003 09:44:44 +1100 From: Nathan Scott To: "HABBINGA,ERIK (HP-Loveland,ex1)" Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - pagebuf Message-ID: <20030310224444.GA1470@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 3149 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1943 Lines: 61 hi Erik, On Mon, Mar 10, 2003 at 03:09:47PM -0500, HABBINGA,ERIK (HP-Loveland,ex1) wrote: > When applying this patch from March 3rd, creating a file system, and then > unmounting and remounting xfs filesystems gives me the following error: > > Mar 10 13:04:07 localhost kernel: XFS mounting filesystem lvm(58,1) > Mar 10 13:04:07 localhost kernel: Filesystem "lvm(58,1)": Failed to > initialize disk quotas. > > We're using the -o rw,nodev,noatime,quota mount options. Mounting without > the quota option doesn't generate the error. Using a CVS take from March > 6th does the same thing, but dumps a stack trace as well. > > Any ideas? > Hmm... not really. I just tried a mkfs & mount with those options and it worked correctly for me. A few suggestions - try adding a few printk's in xfs_qm_mount_quotas and friends, to pinpoint where the error is really coming from (there are several potential error sources in that routine). You might also want to try turning XFS debugging on, see if you trip an assert earlier on. Also what pagesize and blocksize are you using here? If you back this mod out (and just this mod), does it start working again? thanks. > > Remove an unused parameter from pagebuf_lookup. Ensure we don't mark > a page uptodate in the bsize==pgsize case when we didn't do IO to the > entire page. > > > Date: Mon Mar 3 18:17:57 PST 2003 > Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > Modid: 2.4.x-xfs:slinx:140809a > linux/fs/xfs/pagebuf/page_buf.c - 1.100 > - Remove an unused parameter from pagebuf_lookup. Ensure we don't > mark > a page uptodate in the bsize==pgsize case when we didn't do IO to > the > entire page. > > linux/fs/xfs/pagebuf/page_buf.h - 1.59 > linux/fs/xfs/linux/xfs_aops.c - 1.19 > - Remove an unused parameter from pagebuf_lookup. > > > > -- Nathan From owner-linux-xfs@oss.sgi.com Mon Mar 10 17:21:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 17:21:22 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2B1LFq9000397 for ; Mon, 10 Mar 2003 17:21:15 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2B1LFYW000395 for linux-xfs@oss.sgi.com; Mon, 10 Mar 2003 17:21:15 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2B1LCqB000381 for ; Mon, 10 Mar 2003 17:21:12 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2B0wgDt032685; Mon, 10 Mar 2003 16:58:42 -0800 Date: Mon, 10 Mar 2003 16:58:42 -0800 Message-Id: <200303110058.h2B0wgDt032685@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 229] New: xfs_repair unable to repair system X-Bugzilla-Reason: AssignedTo X-archive-position: 3150 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 7107 Lines: 481 http://oss.sgi.com/bugzilla/show_bug.cgi?id=229 Summary: xfs_repair unable to repair system Product: Linux XFS Version: Current Platform: All OS/Version: All Status: NEW Severity: critical Priority: High Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: alde@alde.com If this is a userspace bug, what version of the package are you using: What kernel are you using: 2.4.20-xfs Where did the XFS code come from? (CVS, Linus, your distribution, etc): CVS Description of Problem: Using wget to mirror a website, certain invalid files were created. Some of these files are created with absurdly large filesizes. For example: # find . -size +500k -ls 64459932 8 -rw-r--r-- 1 alde alde 35184372094294 Aug 23 2002 . /www/adrianne/tn_ad12829.jpg This is just one of many. However this doesn't seem to the the big problem. The big problem is that xfs allows some files to be created with a / as the first character. # find . -size +500k -ls find: ./portrait//imi: No such file or directory # cd portrait # ls /imi # ls -l ls: /imi: No such file or directory And as you know, any file name starting with a / is considered a full pathname for the file. So, any type of rm -f ?imi or rm -f *imi or rm -f ???? still results in the / getting expanded and the shell looking for the file /imi. If I touch /imi, and try to remove /foo/portrait/\/imi, it will delete the root directory /imi. When running xfs_repair to fix this problem, I beleive it crashes due to both problems listed above. # xfs_repair /dev/hda4 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 entry "/." at block 0 offset 32 in directory inode 4327089 references invalid inode 18374686479671623679 clearing inode number in entry at offset 32... entry at block 0 offset 32 in directory inode 4327089 has illegal name "/.": no .. entry for directory 4327089 - agno = 2 - agno = 3 - agno = 4 entry "/." at block 0 offset 32 in directory inode 16970686 references invalid inode 18374686479671623679 clearing inode number in entry at offset 32... entry at block 0 offset 32 in directory inode 16970686 has illegal name "/.": no .. entry for directory 16970686 entry "/rs096am08" at block 2 offset 1824 in directory inode 17028818 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1824... entry at block 2 offset 1824 in directory inode 17028818 has illegal name "/rs096am08": invalid inode 18374686479671623679 clearing inode number in entry at offset 1824... entry at block 2 offset 1824 in directory inode 17028818 has illegal name "/rs096am08": - agno = 5 - agno = 6 entry "/." at block 0 offset 968 in directory inode 25279432 references invalid inode 18374686479671623679 clearing inode number in entry at offset 968... entry at block 0 offset 968 in directory inode 25279432 has illegal name "/.": no .. entry for directory 25279432 entry "/." at block 0 offset 32 in directory inode 25847335 references invalid inode 18374686479671623679 clearing inode number in entry at offset 32... entry at block 0 offset 32 in directory inode 25847335 has illegal name "/.": no .. entry for directory 25847335 - agno = 7 - agno = 8 entry "/." at block 0 offset 584 in directory inode 33798096 references invalid inode 18374686479671623679 clearing inode number in entry at offset 584... entry at block 0 offset 584 in directory inode 33798096 has illegal name "/.": no .. entry for directory 33798096 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 entry "/imi" at block 0 offset 288 in directory inode 68882319 references invalid inode 18374686479671623679 clearing inode number in entry at offset 288... entry at block 0 offset 288 in directory inode 68882319 has illegal name "/imi": - agno = 17 - agno = 18 - agno = 19 entry "/." at block 0 offset 584 in directory inode 80188330 references invalid inode 18374686479671623679 clearing inode number in entry at offset 584... entry at block 0 offset 584 in directory inode 80188330 has illegal name "/.": no .. entry for directory 80188330 - agno = 20 entry "/." at block 0 offset 32 in directory inode 86492409 references invalid inode 18374686479671623679 clearing inode number in entry at offset 32... entry at block 0 offset 32 in directory inode 86492409 has illegal name "/.": no .. entry for directory 86492409 - agno = 21 - agno = 22 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 no .. entry for directory 4327089 - agno = 2 - agno = 3 - agno = 4 no .. entry for directory 16970686 - agno = 5 - agno = 6 no .. entry for directory 25279432 no .. entry for directory 25847335 - agno = 7 - agno = 8 no .. entry for directory 33798096 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 no .. entry for directory 80188330 - agno = 20 no .. entry for directory 86492409 - agno = 21 - agno = 22 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... fatal error -- malloc failed in longform_dir2_entry_check (1073741844 bytes) # How Reproducible: Anytime a file gets a corrupted filesize & a file with a / as its first character is created. A website with alot of php calls with /'s in the file name. Steps to Reproduce: 1. wget -r http://www.aol.com 2. wget -r http://www.php.net 3. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Mar 10 18:26:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 18:26:52 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2B2Qmq9003231 for ; Mon, 10 Mar 2003 18:26:49 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2B2QgnH020012 for ; Mon, 10 Mar 2003 18:26:43 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2B2PP7L1339487 for ; Tue, 11 Mar 2003 13:25:25 +1100 (EST) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2B2PODN924612 for linux-xfs@oss.sgi.com; Tue, 11 Mar 2003 13:25:24 +1100 (EST) Date: Tue, 11 Mar 2003 13:25:24 +1100 (EST) From: Timothy Shimmin Message-Id: <200303110225.h2B2PODN924612@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - CREDITS update X-archive-position: 3151 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: tes@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 327 Lines: 14 update some Connex details Date: Mon Mar 10 18:23:57 PST 2003 Workarea: snort.melbourne.sgi.com:/home/tes/isms/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:141397a cmd/xfsprogs/doc/CREDITS - 1.12 - update John Trostel details and connex details From owner-linux-xfs@oss.sgi.com Mon Mar 10 20:21:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 20:21:23 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2B4LHq9006573 for ; Mon, 10 Mar 2003 20:21:17 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2B4LHmk006571 for linux-xfs@oss.sgi.com; Mon, 10 Mar 2003 20:21:17 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2B4LFqB006558 for ; Mon, 10 Mar 2003 20:21:15 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2B3NvfS005922; Mon, 10 Mar 2003 19:23:57 -0800 Date: Mon, 10 Mar 2003 19:23:57 -0800 Message-Id: <200303110323.h2B3NvfS005922@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 229] xfs_repair unable to repair system X-Bugzilla-Reason: AssignedTo X-archive-position: 3152 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 356 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=229 ------- Additional Comments From lord@sgi.com 2003-03-10 19:23 ------- Can you report the wget command line you used? I have used wget on XFS, but without odd occurences like this. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Mar 10 20:52:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 20:52:08 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2B4pPq9007207 for ; Mon, 10 Mar 2003 20:52:06 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2B4pI9n020190 for ; Mon, 10 Mar 2003 20:51:19 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2B4o17L1363938 for ; Tue, 11 Mar 2003 15:50:01 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2B4o1cX1363775 for linux-xfs@oss.sgi.com; Tue, 11 Mar 2003 15:50:01 +1100 (EST) Date: Tue, 11 Mar 2003 15:50:01 +1100 (EST) From: Nathan Scott Message-Id: <200303110450.h2B4o1cX1363775@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - bhv code cleanup X-archive-position: 3153 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1023 Lines: 31 First stage of behavior code cleanup - removes a bunch of unused macros related to read/write locking the behavior list. Date: Mon Mar 10 20:37:23 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141401a linux/fs/xfs/xfsidbg.c - 1.214 linux/fs/xfs/xfs_dmapi.c - 1.89 linux/fs/xfs/xfs_dfrag.c - 1.36 linux/fs/xfs/linux/xfs_behavior.c - 1.16 linux/fs/xfs/linux/xfs_ioctl.c - 1.86 linux/fs/xfs/dmapi/dmapi_attr.c - 1.7 linux/fs/xfs/dmapi/dmapi_bulkattr.c - 1.7 linux/fs/xfs/dmapi/dmapi_config.c - 1.8 linux/fs/xfs/dmapi/dmapi_dmattr.c - 1.7 linux/fs/xfs/dmapi/dmapi_handle.c - 1.7 linux/fs/xfs/dmapi/dmapi_hole.c - 1.7 linux/fs/xfs/dmapi/dmapi_io.c - 1.7 linux/fs/xfs/dmapi/dmapi_region.c - 1.7 linux/fs/xfs/dmapi/dmapi_register.c - 1.21 linux/fs/xfs/dmapi/dmapi_right.c - 1.15 linux/fs/xfs/linux/xfs_vnode.h - 1.75 linux/fs/xfs/linux/xfs_vfs.h - 1.32 linux/fs/xfs/linux/xfs_behavior.h - 1.12 From owner-linux-xfs@oss.sgi.com Mon Mar 10 21:21:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Mar 2003 21:21:18 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2B5LFq9007833 for ; Mon, 10 Mar 2003 21:21:15 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2B5LF6W007831 for linux-xfs@oss.sgi.com; Mon, 10 Mar 2003 21:21:15 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2B5LDqB007818 for ; Mon, 10 Mar 2003 21:21:13 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2B4vqYQ007675; Mon, 10 Mar 2003 20:57:52 -0800 Date: Mon, 10 Mar 2003 20:57:52 -0800 Message-Id: <200303110457.h2B4vqYQ007675@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 229] xfs_repair unable to repair system X-Bugzilla-Reason: AssignedTo X-archive-position: 3154 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 880 Lines: 38 http://oss.sgi.com/bugzilla/show_bug.cgi?id=229 ------- Additional Comments From alde@alde.com 2003-03-10 20:57 ------- Sure... But you'll want to wget a large site with lots of php links... wget --load-cookies=cookies.txt --save-cookies=cookies.txt -r -l 0 -p -nc -np --follow-ftp --user-agent="Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0; Q312461)" site.com $ wget -V GNU Wget 1.8.2 I get things like: 38947690 drwxr-xr-x 2 alde alde 1099511640064 Mar 10 21:11 pt2 directories that I can't remove. or files like: # find . -size +50000k -ls 76342129 132 -rw-r--r-- 1 alde alde 17592186177711 Dec 13 15:34 ./www.site.com/jial/jjial.jpg problem is, neither Inode even shows up in the xfs_repair as having a problem. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Mar 11 06:44:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 06:44:10 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2BEi0q9024941 for ; Tue, 11 Mar 2003 06:44:02 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2BEslkq016628 for ; Tue, 11 Mar 2003 08:54:47 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA39786; Tue, 11 Mar 2003 08:43:54 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2BEhqwX27101486; Tue, 11 Mar 2003 08:43:53 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h2BLxOA25022; Tue, 11 Mar 2003 16:59:24 -0500 Date: Tue, 11 Mar 2003 16:59:23 -0500 From: Christoph Hellwig To: torvalds@transmeta.com Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: [PATCH] fix kmem_cache_size() for new slab poisoning Message-ID: <20030311165923.A25018@sgi.com> Mail-Followup-To: Christoph Hellwig , torvalds@transmeta.com, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 3156 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: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 875 Lines: 30 The new slab poisoning code broke kmem_cache_size(), it now returns a too large size as the poisoning area after the object is includes. XFS's kmem_zone_zalloc thus overwrites exactly that area and triggers the new checks everytime such an object is freed again. I don't recommend using XFS on BK-current without this patch applied :) --- 1.68/mm/slab.c Sat Mar 8 23:50:36 2003 +++ edited/mm/slab.c Tue Mar 11 15:15:44 2003 @@ -2041,11 +2041,16 @@ unsigned int kmem_cache_size(kmem_cache_t *cachep) { + unsigned int objlen = cachep->objsize; + #if DEBUG if (cachep->flags & SLAB_RED_ZONE) - return (cachep->objsize - 2*BYTES_PER_WORD); + objlen -= 2*BYTES_PER_WORD; + if (cachep->flags & SLAB_STORE_USER) + objlen -= BYTES_PER_WORD; #endif - return cachep->objsize; + + return objlen; } kmem_cache_t * kmem_find_general_cachep (size_t size, int gfpflags) From owner-linux-xfs@oss.sgi.com Tue Mar 11 09:17:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 09:17:38 -0800 (PST) Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2BHHUq9005742 for ; Tue, 11 Mar 2003 09:17:31 -0800 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel9.hp.com (Postfix) with ESMTP id B94E51C0144E; Tue, 11 Mar 2003 12:17:29 -0500 (EST) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 86BD81C000BD; Tue, 11 Mar 2003 12:17:29 -0500 (EST) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Tue, 11 Mar 2003 12:17:29 -0500 Message-ID: From: "HABBINGA,ERIK (HP-Loveland,ex1)" To: "'Nathan Scott'" , "HABBINGA,ERIK (HP-Loveland,ex1)" Cc: linux-xfs@oss.sgi.com Subject: RE: TAKE - pagebuf Date: Tue, 11 Mar 2003 12:17:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 3157 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: erik.habbinga@hp.com Precedence: bulk X-list: linux-xfs Content-Length: 2686 Lines: 92 Nathan, When I pull out this particular take, everything works fine. The volumes that fail to initialize quotas are on LVM devices, not standard scsi devices. The scsi devices mount correctly. I'm not consciously changing the pagesize and blocksize, so I assume I'm using the defaults. I'll work on adding the printks/debugging enablement later on today. Thanks, Erik > -----Original Message----- > From: Nathan Scott [mailto:nathans@sgi.com] > Sent: Monday, March 10, 2003 3:45 PM > To: HABBINGA,ERIK (HP-Loveland,ex1) > Cc: linux-xfs@oss.sgi.com > Subject: Re: TAKE - pagebuf > > > hi Erik, > > On Mon, Mar 10, 2003 at 03:09:47PM -0500, HABBINGA,ERIK > (HP-Loveland,ex1) wrote: > > When applying this patch from March 3rd, creating a file > system, and then > > unmounting and remounting xfs filesystems gives me the > following error: > > > > Mar 10 13:04:07 localhost kernel: XFS mounting filesystem lvm(58,1) > > Mar 10 13:04:07 localhost kernel: Filesystem "lvm(58,1)": Failed to > > initialize disk quotas. > > > > We're using the -o rw,nodev,noatime,quota mount options. > Mounting without > > the quota option doesn't generate the error. Using a CVS > take from March > > 6th does the same thing, but dumps a stack trace as well. > > > > Any ideas? > > > > Hmm... not really. I just tried a mkfs & mount with those options > and it worked correctly for me. A few suggestions - try adding a > few printk's in xfs_qm_mount_quotas and friends, to pinpoint where > the error is really coming from (there are several potential error > sources in that routine). You might also want to try turning XFS > debugging on, see if you trip an assert earlier on. > > Also what pagesize and blocksize are you using here? If you back > this mod out (and just this mod), does it start working again? > > thanks. > > > > > Remove an unused parameter from pagebuf_lookup. Ensure we > don't mark > > a page uptodate in the bsize==pgsize case when we didn't do > IO to the > > entire page. > > > > > > Date: Mon Mar 3 18:17:57 PST 2003 > > Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf > > > > The following file(s) were checked into: > > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > > > > Modid: 2.4.x-xfs:slinx:140809a > > linux/fs/xfs/pagebuf/page_buf.c - 1.100 > > - Remove an unused parameter from pagebuf_lookup. > Ensure we don't > > mark > > a page uptodate in the bsize==pgsize case when we > didn't do IO to > > the > > entire page. > > > > linux/fs/xfs/pagebuf/page_buf.h - 1.59 > > linux/fs/xfs/linux/xfs_aops.c - 1.19 > > - Remove an unused parameter from pagebuf_lookup. > > > > > > > > > > -- > Nathan > From owner-linux-xfs@oss.sgi.com Tue Mar 11 14:07:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 14:08:00 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2BM7Dq9012359 for ; Tue, 11 Mar 2003 14:07:53 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h2BM78uX032005 for ; Tue, 11 Mar 2003 14:07:08 -0800 From: "l.a walsh" To: Subject: RE: XFS in 2.5.64-bk3, compile problem Date: Tue, 11 Mar 2003 14:07:06 -0800 Message-ID: <000401c2e81a$8dde1210$1403a8c0@sc.tlinx.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E6B63DE.9040308@stesmi.com> Importance: Normal X-archive-position: 3158 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: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 904 Lines: 22 ...*scribble* *scribble* *scribble*...note to self. "Troll" = someone who provides helpful answers to repeated questions. *scribble* *scribble* more *scribbling* Stephan smomethingski (I know, it's probably the equivalent of Smith in Polish) has short fuse, probably won't like scribblings....:-/ sigh nobody has a sense of humor anymore, least of all, me!....:-| > -----Original Message----- > From: Stefan Smietanowski > > The problem is in gcc, not in the kernel. Red Hat ships with a broken, > > unofficial beta gcc. Please replace that gcc with gcc 3.2.2 (and while > > you're at it, replace Red Hat with a competent distribution that provides > > a working compiler). You'll find that your kernel compiles fine. > > It does here ;) > > I'm sorry, I missed the sign around your neck saying "Troll". > You could put that in your sig for instance so that it's > readily apparent. > > // Stefan From owner-linux-xfs@oss.sgi.com Tue Mar 11 14:10:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 14:11:00 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2BMAGq9012605 for ; Tue, 11 Mar 2003 14:10:56 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h2BMABuX032017 for ; Tue, 11 Mar 2003 14:10:11 -0800 From: "l.a walsh" To: Subject: mount options... Date: Tue, 11 Mar 2003 14:10:09 -0800 Message-ID: <000501c2e81a$fac45600$1403a8c0@sc.tlinx.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-archive-position: 3159 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: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 401 Lines: 10 I'm not sure who maintains options to mount, its man page or error messages, but it would really be helpful if the error message for mounting a fs. that is the same UUID instead of a generic can't mount message. It would also be useful to document the -nouuid flag in the mount manpage (the one on my SuSE81 system is deficient -- dunnow if it is just them or source farther up the line.... -linda From owner-linux-xfs@oss.sgi.com Tue Mar 11 14:16:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 14:16:33 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2BMGSq9013908 for ; Tue, 11 Mar 2003 14:16:29 -0800 Received: from [10.0.0.3] (sandeen.net [209.173.210.139]) by sandeen.net (Postfix) with ESMTP id CD5432800FF; Tue, 11 Mar 2003 16:21:09 -0600 (CST) Subject: Re: mount options... From: Eric Sandeen To: "l.a walsh" Cc: linux-xfs@oss.sgi.com In-Reply-To: <000501c2e81a$fac45600$1403a8c0@sc.tlinx.org> References: <000501c2e81a$fac45600$1403a8c0@sc.tlinx.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 11 Mar 2003 16:17:52 -0600 Message-Id: <1047421073.17614.18.camel@porter> Mime-Version: 1.0 X-archive-position: 3160 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 696 Lines: 21 Mount almost always gives you a generic message on failure; I always make a habit of looking at the syslogs to see what went wrong. also, FWIW, all xfs mount options are documented in Documentation/filesystems/xfs.txt -Eric On Tue, 2003-03-11 at 16:10, l.a walsh wrote: > I'm not sure who maintains options to mount, its man page or error messages, > but it would really be helpful if the error message for mounting a fs. > that is the same UUID instead of a generic can't mount message. > It would also be useful to document the -nouuid flag in the mount manpage > (the one on my SuSE81 system is deficient -- dunnow if it is just them > or source farther up the line.... > > -linda > > From owner-linux-xfs@oss.sgi.com Tue Mar 11 14:24:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 14:24:10 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2BMNQq9014406 for ; Tue, 11 Mar 2003 14:24:07 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2BJfYnH012407 for ; Tue, 11 Mar 2003 11:41:34 -0800 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA51744 for ; Tue, 11 Mar 2003 13:41:33 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2BJfYvw7375677 for ; Tue, 11 Mar 2003 13:41:34 -0600 (CST) Received: from clink.americas.sgi.com (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id h2BJg0oG1096960 for ; Tue, 11 Mar 2003 13:42:00 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2BJg0vW1093343 for linux-xfs@oss.sgi.com; Tue, 11 Mar 2003 13:42:00 -0600 (CST) Date: Tue, 11 Mar 2003 13:42:00 -0600 (CST) From: Dean Roehrich Message-Id: <200303111942.h2BJg0vW1093343@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Use a dynamic minor number for dmapi device X-archive-position: 3161 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: roehrich@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 379 Lines: 16 Date: Tue Mar 11 11:41:16 PST 2003 Workarea: clink.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141450a linux/include/linux/miscdevice.h - 1.13 - remove DMAPI_MINOR linux/fs/xfs/dmapi/dmapi_sysent.c - 1.19 - Use a dynamic minor number for dmapi device From owner-linux-xfs@oss.sgi.com Tue Mar 11 15:18:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 15:18:08 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2BNI0q9015563 for ; Tue, 11 Mar 2003 15:18:01 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2BNHsnH028080 for ; Tue, 11 Mar 2003 15:17:55 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2BNGc7L1320520 for ; Wed, 12 Mar 2003 10:16:38 +1100 (EST) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2BNGbT11436628 for linux-xfs@oss.sgi.com; Wed, 12 Mar 2003 10:16:37 +1100 (EST) Date: Wed, 12 Mar 2003 10:16:37 +1100 (EST) From: Timothy Shimmin Message-Id: <200303112316.h2BNGbT11436628@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - update CREDITS X-archive-position: 3162 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: tes@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 189 Lines: 7 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:141483a cmd/xfsprogs/doc/CREDITS - 1.13 - Update for Danny Cox email address. From owner-linux-xfs@oss.sgi.com Tue Mar 11 17:08:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 17:08:44 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2C17vq9022954 for ; Tue, 11 Mar 2003 17:08:37 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2C17p9n027329 for ; Tue, 11 Mar 2003 17:07:52 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA04415 for ; Tue, 11 Mar 2003 19:07:51 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2C17pwX27494658 for ; Tue, 11 Mar 2003 19:07:51 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h2C16gF04323; Tue, 11 Mar 2003 19:06:42 -0600 Message-Id: <200303120106.h2C16gF04323@stout.americas.sgi.com> Date: Tue, 11 Mar 2003 19:06:42 -0600 Subject: TAKE 879670 - unaligned access warnings on ia64 X-archive-position: 3163 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 371 Lines: 14 use get/put_unaligned() to avoid unaligned accesses in the extents code on 64-bit machines Date: Tue Mar 11 17:05:21 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141495a linux/fs/xfs/xfs_inode.c - 1.364 From owner-linux-xfs@oss.sgi.com Tue Mar 11 17:14:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 17:14:19 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2C1ECq9023463 for ; Tue, 11 Mar 2003 17:14:13 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h2C1E7uX000616; Tue, 11 Mar 2003 17:14:07 -0800 From: "l.a walsh" To: "'Eric Sandeen'" Cc: Subject: RE: mount options... Date: Tue, 11 Mar 2003 17:14:03 -0800 Message-ID: <000001c2e834$abd32480$1403a8c0@sc.tlinx.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <1047421073.17614.18.camel@porter> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 3164 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: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 1114 Lines: 50 > -----Original Message----- > From: Eric Sandeen [mailto:sandeen@sgi.com] > Sent: Tue, Mar 11, 2003 2:18p > To: l.a walsh > Cc: linux-xfs@oss.sgi.com > Subject: Re: mount options... > > > Mount almost always gives you a generic message on failure; I always > make a habit of looking at the syslogs to see what went wrong. > > also, FWIW, all xfs mount options are documented in > Documentation/filesystems/xfs.txt --- That's nice. Are you saying it wouldn't be helpful to have a more clear error message or that it wouldn't be useful to have all the options documented in the manpages? -l > > -Eric > > On Tue, 2003-03-11 at 16:10, l.a walsh wrote: > > I'm not sure who maintains options to mount, its man page > or error messages, > > but it would really be helpful if the error message for > mounting a fs. > > that is the same UUID instead of a generic can't mount message. > > It would also be useful to document the -nouuid flag in the > mount manpage > > (the one on my SuSE81 system is deficient -- dunnow if it > is just them > > or source farther up the line.... > > > > -linda > > > > > > > From owner-linux-xfs@oss.sgi.com Tue Mar 11 19:03:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 19:03:59 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2C33pq9027969 for ; Tue, 11 Mar 2003 19:03:54 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2C33inH008915 for ; Tue, 11 Mar 2003 19:03:45 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA10703; Wed, 12 Mar 2003 14:02:28 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id OAA73921; Wed, 12 Mar 2003 14:02:27 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2C2xnP9003615; Wed, 12 Mar 2003 13:59:49 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2C2xmKc003613; Wed, 12 Mar 2003 13:59:48 +1100 Date: Wed, 12 Mar 2003 13:59:48 +1100 From: Nathan Scott To: "HABBINGA,ERIK (HP-Loveland,ex1)" Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - pagebuf Message-ID: <20030312025948.GC1412@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 3165 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 827 Lines: 25 On Tue, Mar 11, 2003 at 12:17:22PM -0500, HABBINGA,ERIK (HP-Loveland,ex1) wrote: > Nathan, > When I pull out this particular take, everything works fine. The volumes > that fail to initialize quotas are on LVM devices, not standard scsi > devices. The scsi devices mount correctly. OK, thats convincing enough for me - I'll back that change out for now and ponder it for awhile, see if I can see why this is happening. > I'm not consciously changing the pagesize and blocksize, so I assume I'm > using the defaults. Is this on an IA32 machine (i.e. 4K pagesize)? The default XFS blocksize is always 4K. I'm sure your machine is IA32, cos this change only affects the case whether the blocksize is the same as the pagesize. > I'll work on adding the printks/debugging enablement later on today. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Mar 11 20:08:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 20:08:15 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2C47Pq9031518 for ; Tue, 11 Mar 2003 20:08:06 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2C47J9n003663 for ; Tue, 11 Mar 2003 20:07:20 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2C4627L1484076 for ; Wed, 12 Mar 2003 15:06:02 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2C462CE1484989 for linux-xfs@oss.sgi.com; Wed, 12 Mar 2003 15:06:02 +1100 (EST) Date: Wed, 12 Mar 2003 15:06:02 +1100 (EST) From: Nathan Scott Message-Id: <200303120406.h2C462CE1484989@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - bhv cleanup X-archive-position: 3166 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1790 Lines: 57 Trivial aops.c change to keep 2.4 and 2.5 a little more in sync. Date: Thu Mar 6 15:03:53 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141144a linux/fs/xfs/linux/xfs_aops.c - 1.23 Next step in bhv code cleanup - this is a start on moving quota and dmapi into behavior layers, purging several points where these sit slap bang in the middle of XFS code (esp. read_super). Also removes numerous #ifdef's and a bunch of unused #define's from all over the place. More to come. Date: Tue Mar 11 19:33:01 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141499a linux/fs/xfs/xfs_dmops.c - 1.1 linux/fs/xfs/xfs_qmops.c - 1.1 linux/fs/xfs/xfs_macros.c - 1.48 linux/fs/xfs/xfs_dmapi.h - 1.34 linux/fs/xfs/xfs_dmapi.c - 1.90 linux/fs/xfs/Makefile - 1.153 linux/fs/xfs/xfs_iocore.c - 1.38 linux/fs/xfs/xfs_qm_syscalls.c - 1.73 linux/fs/xfs/xfs_vfsops.c - 1.408 linux/fs/xfs/xfs_mount.h - 1.166 linux/fs/xfs/xfs_mount.c - 1.319 linux/fs/xfs/xfs_qm.h - 1.26 linux/fs/xfs/xfs_inode.c - 1.365 linux/fs/xfs/linux/xfs_lrw.h - 1.32 linux/fs/xfs/linux/xfs_lrw.c - 1.180 linux/fs/xfs/linux/xfs_vfs.c - 1.39 linux/fs/xfs/linux/xfs_linux.h - 1.99 linux/fs/xfs/linux/Makefile - 1.69 linux/fs/xfs/linux/xfs_file.c - 1.86 linux/fs/xfs/linux/xfs_super.h - 1.37 linux/fs/xfs/linux/xfs_super.c - 1.240 linux/fs/xfs/linux/xfs_behavior.c - 1.17 linux/fs/xfs/linux/xfs_ioctl.c - 1.87 linux/fs/xfs/dmapi/dmapi_mountinfo.c - 1.12 linux/fs/xfs/linux/xfs_vnode.h - 1.76 linux/fs/xfs/linux/xfs_vfs.h - 1.33 linux/fs/xfs/linux/xfs_behavior.h - 1.13 From owner-linux-xfs@oss.sgi.com Tue Mar 11 20:49:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 20:49:54 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2C4nkq9000420 for ; Tue, 11 Mar 2003 20:49:47 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2C50Xkq002213 for ; Tue, 11 Mar 2003 23:00:34 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2C4mM7L1498889 for ; Wed, 12 Mar 2003 15:48:22 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2C4mLr21498828 for linux-xfs@oss.sgi.com; Wed, 12 Mar 2003 15:48:21 +1100 (EST) Date: Wed, 12 Mar 2003 15:48:21 +1100 (EST) From: Nathan Scott Message-Id: <200303120448.h2C4mLr21498828@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - pagebuf X-archive-position: 3167 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 462 Lines: 16 Revert last part of recent IO completion changes - folks at HP have reported problems on top of LVM devices with this change. Something to come back to. Let me know if this doesn't help, Erik -- thanks. Date: Tue Mar 11 20:47:15 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141504a linux/fs/xfs/pagebuf/page_buf.c - 1.104 From owner-linux-xfs@oss.sgi.com Tue Mar 11 20:53:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 20:53:36 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2C4rYq9000903 for ; Tue, 11 Mar 2003 20:53:34 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2C54Lkq002248 for ; Tue, 11 Mar 2003 23:04:22 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2C4qA7L1495822 for ; Wed, 12 Mar 2003 15:52:10 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2C4qANV1478139 for linux-xfs@oss.sgi.com; Wed, 12 Mar 2003 15:52:10 +1100 (EST) Date: Wed, 12 Mar 2003 15:52:10 +1100 (EST) From: Nathan Scott Message-Id: <200303120452.h2C4qANV1478139@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - aops.c X-archive-position: 3168 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 469 Lines: 16 Christoph suggests some of the unwritten extent defines relating to buffer_header state should be out in a header somewhere - make it so. Date: Tue Mar 11 20:51:42 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141505a linux/fs/xfs/linux/xfs_linux.h - 1.100 linux/fs/xfs/linux/xfs_iops.h - 1.18 linux/fs/xfs/linux/xfs_aops.c - 1.24 From owner-linux-xfs@oss.sgi.com Tue Mar 11 21:40:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Mar 2003 21:40:52 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2C5enq9004040 for ; Tue, 11 Mar 2003 21:40:50 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2C5ehnH016150 for ; Tue, 11 Mar 2003 21:40:44 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2C5dP7L1505321 for ; Wed, 12 Mar 2003 16:39:26 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2C5dPcI1513586 for linux-xfs@oss.sgi.com; Wed, 12 Mar 2003 16:39:25 +1100 (EST) Date: Wed, 12 Mar 2003 16:39:25 +1100 (EST) From: Nathan Scott Message-Id: <200303120539.h2C5dPcI1513586@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - 2.5 unwritten extents X-archive-position: 3169 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1219 Lines: 46 Doesn't yet work for direct IO into an unwritten extent (on my TODO list), but works correctly for buffered IO. cheers. Export end_buffer_async_write, needed for unwritten extent support in XFS. Date: Tue Mar 11 21:32:02 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:141507a linux/kernel/ksyms.c - 1.184 linux/fs/buffer.c - 1.151 linux/include/linux/buffer_head.h - 1.19 Implement support for unwritten extents in XFS. Date: Tue Mar 11 21:37:01 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:141508a linux/fs/xfs/pagebuf/page_buf.c - 1.101 - Create separate IO completion work queues in pagebuf for log/data IO, to prevent deadlocks when scheduling iclog/unwritten extent IO completion handlers. linux/fs/xfs/xfs_buf.h - 1.106 linux/fs/xfs/linux/xfs_linux.h - 1.100 linux/fs/xfs/linux/xfs_iops.h - 1.18 linux/fs/xfs/pagebuf/page_buf.h - 1.67 linux/fs/xfs/linux/xfs_aops.c - 1.29 - Implement support for unwritten extents in XFS. From owner-linux-xfs@oss.sgi.com Wed Mar 12 00:22:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 00:22:25 -0800 (PST) Received: from hermod.slb.nwc.acsalaska.net (hermod.slb.nwc.acsalaska.net [209.112.155.45]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2C8LZq9013203 for ; Wed, 12 Mar 2003 00:22:16 -0800 Received: from erbenson.alaska.net (120-pm30.nwc.alaska.net [209.112.158.120]) by hermod.slb.nwc.acsalaska.net (8.12.8/8.12.8) with ESMTP id h2C8LX18083268 for ; Tue, 11 Mar 2003 23:21:33 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id BDDD73A04 for ; Tue, 11 Mar 2003 23:21:30 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 6569A4104E2; Tue, 11 Mar 2003 23:21:30 -0900 (AKST) Date: Tue, 11 Mar 2003 23:21:30 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: mount options... Message-ID: <20030312082130.GC20925@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1047421073.17614.18.camel@porter> <000001c2e834$abd32480$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eHhjakXzOLJAF9wJ" Content-Disposition: inline In-Reply-To: <000001c2e834$abd32480$1403a8c0@sc.tlinx.org> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 3170 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: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 4326 Lines: 125 --eHhjakXzOLJAF9wJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 11, 2003 at 05:14:03PM -0800, l.a walsh wrote: >=20 >=20 > > -----Original Message----- > > From: Eric Sandeen [mailto:sandeen@sgi.com] > > Sent: Tue, Mar 11, 2003 2:18p > > To: l.a walsh > > Cc: linux-xfs@oss.sgi.com > > Subject: Re: mount options... > > > > > > Mount almost always gives you a generic message on failure; I always > > make a habit of looking at the syslogs to see what went wrong. > > > > also, FWIW, all xfs mount options are documented in > > Documentation/filesystems/xfs.txt > --- > That's nice. >=20 > Are you saying it wouldn't be helpful to have a more clear > error message or that it wouldn't be useful to have all the options > documented in the manpages? not at all. the problem with mount is its just a wrapper around mount() (the system call), /bin/mount itself doesn't have any idea why the mount failed past mount()'s return value and the contents of errno, from the mount(2) man page: RETURN VALUE On success, zero is returned. On error, -1 is returned, and errno is set appropriately. ERRORS The error values given below result from filesystem type independent errors. Each filesystem type may have its own special errors and its own special behavior. See the ker- nel source code for details. EPERM The user is not the super-user. ENODEV Filesystemtype not configured in the kernel. ENOTBLK Specialfile is not a block device (if a device was required). EBUSY Specialfile is already mounted. Or, it cannot be remounted read-only, because it still holds files open for writing. Or, it cannot be mounted on dir because dir is still busy (it is the working direc- tory of some task, the mount point of another device, has open files, etc.). EINVAL Specialfile had an invalid superblock. Or, a remount was attempted, while specialfile was not already mounted on dir. Or, an umount was attempted, while dir was not a mount point. EFAULT One of the pointer arguments points outside the user address space. ENOMEM The kernel could not allocate a free page to copy filenames or data into. ENAMETOOLONG A pathname was longer than MAXPATHLEN. ENOENT A pathname was empty or had a nonexistent compo- nent. ENOTDIR The second argument, or a prefix of the first argu- ment, is not a directory. EACCES A component of a path was not searchable. Or, mounting a read-only filesystem was attempted without giving the MS_RDONLY flag. Or, the block device Specialfile is located on a filesystem mounted with the MS_NODEV option. ENXIO The major number of the block device specialfile is out of range. EMFILE (In case no block device is required:) Table of dummy devices is full. In general there isn't going to be an errno for all the various ways specific filesystems can fail, so mount is probably just going to end up getting ENODEV most of the time, thus it can't tell you much about what went wrong. you could fix this by adding new errno values to accomidate all the various filesystem mount failure conditions, then make sure /bin/mount just uses perror() to inform the user of failure. this however requires both kernel and glibc modification, and thus will likly be difficult politically (and there are perhaps portability issues, though thats not so important with something like mount() which is never portable anyway). --=20 Ethan Benson http://www.alaska.net/~erbenson/ --eHhjakXzOLJAF9wJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj5u7goACgkQJKx7GixEevz2PwCePhofkDSNc1woy3w11ZezkOYf VmgAniSYpPp7RAiOvF2OJPCeJyvgNkJh =n7Or -----END PGP SIGNATURE----- --eHhjakXzOLJAF9wJ-- From owner-linux-xfs@oss.sgi.com Wed Mar 12 01:34:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 01:34:30 -0800 (PST) Received: from phoenix.infradead.org (carisma.slowglass.com [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2C9YJq9018594 for ; Wed, 12 Mar 2003 01:34:20 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18t2co-0002KJ-00; Wed, 12 Mar 2003 09:34:14 +0000 Date: Wed, 12 Mar 2003 09:34:13 +0000 From: Christoph Hellwig To: "l.a walsh" Cc: linux-xfs@oss.sgi.com Subject: Re: mount options... Message-ID: <20030312093413.A8850@infradead.org> References: <000501c2e81a$fac45600$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <000501c2e81a$fac45600$1403a8c0@sc.tlinx.org>; from xfs@tlinx.org on Tue, Mar 11, 2003 at 02:10:09PM -0800 X-archive-position: 3171 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: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 558 Lines: 11 On Tue, Mar 11, 2003 at 02:10:09PM -0800, l.a walsh wrote: > I'm not sure who maintains options to mount, its man page or error messages, > but it would really be helpful if the error message for mounting a fs. > that is the same UUID instead of a generic can't mount message. > It would also be useful to document the -nouuid flag in the mount manpage > (the one on my SuSE81 system is deficient -- dunnow if it is just them > or source farther up the line.... mount(8) is part of util-linux. Send any updates / comments to Andries Brouwer . From owner-linux-xfs@oss.sgi.com Wed Mar 12 02:29:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 02:29:23 -0800 (PST) Received: from mario.zsu.edu.cn ([61.144.54.55]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2CATBq9024080 for ; Wed, 12 Mar 2003 02:29:13 -0800 Received: from zsulink.zsu.edu.cn (zsulink.zsu.edu.cn [202.116.64.1]) by mario.zsu.edu.cn (8.11.5/8.11.5) with ESMTP id h2CAgW398738 for ; Wed, 12 Mar 2003 18:42:32 +0800 (CST) Received: from mc011.zd.zsu.edu.cn ([202.116.86.49]) by zsulink.zsu.edu.cn (8.11.5/8.11.5) with ESMTP id h2CAWBJ24689 for ; Wed, 12 Mar 2003 18:32:11 +0800 (CST) Subject: How can I patch my Phoebe-3's kernel with XFS patch? From: ihwbox To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1047464916.2241.4.camel@mc011.zd.zsu.edu.cn> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-1) Date: 12 Mar 2003 18:29:04 +0800 Content-Transfer-Encoding: 7bit X-Filter-Version: 1.7 (fw.zsu.edu.cn) X-archive-position: 3172 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: ihwbox@21cn.com Precedence: bulk X-list: linux-xfs Content-Length: 148 Lines: 8 I'm using Redhat 8.0.94 beta. And I also want to use XFS filesystem. How can I patch redhat's kernel-2.4.20-2.48 . -- ihwbox From owner-linux-xfs@oss.sgi.com Wed Mar 12 02:36:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 02:36:20 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2CAZUq9027103 for ; Wed, 12 Mar 2003 02:36:11 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18t3Zz-0002Um-00; Wed, 12 Mar 2003 10:35:23 +0000 Date: Wed, 12 Mar 2003 10:35:22 +0000 From: Christoph Hellwig To: ihwbox Cc: linux-xfs@oss.sgi.com Subject: Re: How can I patch my Phoebe-3's kernel with XFS patch? Message-ID: <20030312103522.A9562@infradead.org> References: <1047464916.2241.4.camel@mc011.zd.zsu.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1047464916.2241.4.camel@mc011.zd.zsu.edu.cn>; from ihwbox@21cn.com on Wed, Mar 12, 2003 at 06:29:04PM +0800 X-archive-position: 3173 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: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 448 Lines: 9 On Wed, Mar 12, 2003 at 06:29:04PM +0800, ihwbox wrote: > I'm using Redhat 8.0.94 beta. And I also want to use XFS filesystem. How > can I patch redhat's kernel-2.4.20-2.48 . Given the way you ask you probably can't as it's nontrivial. I'll do a XFS-enabled RPM for RH8.1 once it's out, but until then just stick to the RRH8-errata based RPMS, they should work under phoebe but you won't get all of it's features (notably the threading changes) From owner-linux-xfs@oss.sgi.com Wed Mar 12 07:15:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 07:15:23 -0800 (PST) Received: from obelix.wu-wien.ac.at (obelix.wu-wien.ac.at [137.208.3.41]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2CFFCq9028710 for ; Wed, 12 Mar 2003 07:15:14 -0800 Received: from ekelhardt ([137.208.224.91]) by obelix.wu-wien.ac.at (8.8.7/8.8.7) with ESMTP id QAA19586 for ; emf h9351252@obelix.wu-wien.ac.at; Wed, 12 Mar 2003 16:15:03 +0100 From: "Peter Alberer" To: Subject: nfs and number of open files Date: Wed, 12 Mar 2003 16:12:57 +0100 Message-ID: <001201c2e8a9$dd402200$5be0d089@ekelhardt> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 3174 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: h9351252@obelix.wu-wien.ac.at Precedence: bulk X-list: linux-xfs Content-Length: 1501 Lines: 34 Hi all, First of, i am not sure whether this is really an xfs issue, but as most of you are experts with filesystems, i hope someone can help here. i am using redhat 8 with a linux 2.4.19 kernel patched with the xfs patches. A 350GB drive has been formatted with xfs and one directory hierarchie on that fs (with 130.000 files) is nfs exported to another server. Besides, the machine is only running the postgresql database (Postgres data files are also on the xfs-drive) The nfs-client is a web server machine that delivers some files from the nfs-drive (only huge downloads) Today and yesterday that web server has crashed due to network problems. today I got the following error message on the nfs server: "too many open files in system". First I increased the limit (/proc/sys/fs/file-max) to 12000 (was 8192) files, to get things running again. But now I want to find out why so many files are open and I would like to know which files are open. Our web service is not so popular that more than a hundred files should be open at the same time over the nfs link. I tried to find open files with "lsof -N" (tried that on client and server) but did not get any result. "lsof" lists only about 600 open files. So my questions are: - how do I find out which files are open - can the crash of the webserver (nfs-client) be part of the problem - is this a "normal" situation (that one has to increase file-max) when exporting so many files or could there be something bad going on? TIA, peter From owner-linux-xfs@oss.sgi.com Wed Mar 12 10:48:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 10:49:01 -0800 (PST) Received: from exchange.ccur.com (mail.ccur.com [208.248.32.212]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2CImtq9031415 for ; Wed, 12 Mar 2003 10:48:56 -0800 Received: by exchange.ccur.com with Internet Mail Service (5.5.2653.19) id <1J8V20CH>; Wed, 12 Mar 2003 13:48:50 -0500 Message-ID: From: "Miro, Felix" To: "'linux-xfs@oss.sgi.com'" Subject: XFS root filesystem Date: Wed, 12 Mar 2003 13:48:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 3176 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: felix.miro@ccur.com Precedence: bulk X-list: linux-xfs Content-Length: 165 Lines: 6 What is the procedure for making XFS my root filesystem under redhat 8.0+ ? Your web page mentioned a working document but the link was broken. Thanks, Felix Miro From owner-linux-xfs@oss.sgi.com Wed Mar 12 10:44:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 10:44:37 -0800 (PST) Received: from exchange.ccur.com (mail.ccur.com [208.248.32.212]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2CIiSq9031180 for ; Wed, 12 Mar 2003 10:44:29 -0800 Received: by exchange.ccur.com with Internet Mail Service (5.5.2653.19) id <1J8V20AY>; Wed, 12 Mar 2003 13:44:15 -0500 Message-ID: From: "Miro, Felix" To: "'linux-xfs@oss.sgi.com'" Subject: XFS file extent size Date: Wed, 12 Mar 2003 13:44:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 3175 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: felix.miro@ccur.com Precedence: bulk X-list: linux-xfs Content-Length: 112 Lines: 6 How do you specify a file's extent size? Your web page says use fcntl but what parameters. Thanks, Felix Miro From owner-linux-xfs@oss.sgi.com Wed Mar 12 13:17:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 13:17:34 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2CLHPq9002543 for ; Wed, 12 Mar 2003 13:17:26 -0800 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2CLSFkq021846 for ; Wed, 12 Mar 2003 15:28:16 -0600 Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.12.5/8.12.5) with ESMTP id h2CLHJh0024586 for ; Wed, 12 Mar 2003 15:17:19 -0600 Received: (from cattelan@localhost) by naboo.americas.sgi.com (8.12.5/8.12.5/Submit) id h2CLHFZL024584 for linux-xfs@oss.sgi.com; Wed, 12 Mar 2003 15:17:15 -0600 Date: Wed, 12 Mar 2003 15:17:15 -0600 From: Rusell Cattelan Message-Id: <200303122117.h2CLHFZL024584@naboo.americas.sgi.com> Subject: TAKE - Make XFS LBD ready X-archive-position: 3177 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: cattelan@naboo.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 560 Lines: 20 Date: Wed Mar 12 13:16:52 PST 2003 Workarea: naboo.americas.sgi.com:/misc/xfs1/rsrc/2.4.x-xfs/find The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141587a linux/fs/xfs/xfs_types.h - 1.65 - Add typedef for sector_t here for now once sector_t is defined in the core kernel remove Also turn on XFS_BIG_FILESYSTEMS if LBD is enabled linux/fs/xfs/linux/xfs_iops.h - 1.19 linux/fs/xfs/linux/xfs_aops.c - 1.25 - change params to sector_t Make ready for LBD (Large Block Device) support From owner-linux-xfs@oss.sgi.com Wed Mar 12 14:17:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 14:17:33 -0800 (PST) Received: from webcube3.volstate.net (webcube2.volstate.net [66.129.16.201]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2CMHOq9003738 for ; Wed, 12 Mar 2003 14:17:26 -0800 Received: from jupiter.solar.com (host10-33-153-216.knightwave.com [216.153.33.10] (may be forged)) by webcube3.volstate.net (8.11.6/8.11.6) with ESMTP id h2CMHNL21379 for ; Wed, 12 Mar 2003 17:17:23 -0500 Content-Type: text/plain; charset="us-ascii" From: Joe Bacom Reply-To: joebacom@volstate.net To: linux-xfs@oss.sgi.com Subject: Permission problems with attr and setfattr Date: Wed, 12 Mar 2003 16:16:44 -0600 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Message-Id: <200303121616.44771.joebacom@volstate.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h2CMHQq9003740 X-archive-position: 3178 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: joebacom@volstate.net Precedence: bulk X-list: linux-xfs Content-Length: 430 Lines: 21 Hi Folks; I am trying to set an extended attribute value to a symbolic link with attr -s some.name -V "some value" some_file and get attr_set: Operation not permitted but if I su up to root and do the same command the attribute is set. I could not find a reference that required root access is required to set extended attributes anywhere except for rootspace. Also, I get the same results using setfattr. Thanks; Joe From owner-linux-xfs@oss.sgi.com Wed Mar 12 14:41:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 14:41:57 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2CMfoq9004300 for ; Wed, 12 Mar 2003 14:41:51 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2CMfh9n013154 for ; Wed, 12 Mar 2003 14:41:44 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA20110; Thu, 13 Mar 2003 09:40:27 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA64259; Thu, 13 Mar 2003 09:40:25 +1100 (EST) Date: Thu, 13 Mar 2003 09:40:24 +1100 From: Nathan Scott To: Joe Bacom Cc: linux-xfs@oss.sgi.com Subject: Re: Permission problems with attr and setfattr Message-ID: <20030313094024.A967615@wobbly.melbourne.sgi.com> References: <200303121616.44771.joebacom@volstate.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200303121616.44771.joebacom@volstate.net>; from joebacom@volstate.net on Wed, Mar 12, 2003 at 04:16:44PM -0600 X-archive-position: 3179 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 352 Lines: 14 On Wed, Mar 12, 2003 at 04:16:44PM -0600, Joe Bacom wrote: > > I am trying to set an extended attribute value to a symbolic link with > ... > I could not find a reference that required root access is required to set > extended attributes anywhere except for rootspace. attr(5) discusses this in the section on user attributes. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Mar 12 17:51:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Mar 2003 17:51:10 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2D1oQq9015247 for ; Wed, 12 Mar 2003 17:51:07 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2D1oJnH001040 for ; Wed, 12 Mar 2003 17:50:20 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2D1n27L1605523 for ; Thu, 13 Mar 2003 12:49:02 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2D1n0tv1618501 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 12:49:00 +1100 (EST) Date: Thu, 13 Mar 2003 12:49:00 +1100 (EST) From: Nathan Scott Message-Id: <200303130149.h2D1n0tv1618501@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - unwritten extents tweak X-archive-position: 3180 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 572 Lines: 18 Add back the pagebuf flag for scheduling on the data daemon. Moving this into just a pagebuf_iodone parameter was broken as we don't have sufficient state in all the places we need it to make the decision. Date: Wed Mar 12 17:47:51 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141626a linux/fs/xfs/xfs_buf.h - 1.106 linux/fs/xfs/pagebuf/page_buf.c - 1.105 linux/fs/xfs/pagebuf/page_buf.h - 1.62 linux/fs/xfs/linux/xfs_aops.c - 1.27 From owner-linux-xfs@oss.sgi.com Thu Mar 13 04:36:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 04:36:54 -0800 (PST) Received: from smtp1.work.ro ([213.157.160.179]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DCa2q9026787 for ; Thu, 13 Mar 2003 04:36:45 -0800 Received: (qmail 29649 invoked by uid 7789); 13 Mar 2003 14:05:36 -0000 Received: from unknown (HELO work.ro) (office@dakorom.ro@192.168.1.21) by 0 with SMTP; 13 Mar 2003 14:05:36 -0000 Message-ID: <3E7073D6.2040207@work.ro> Date: Thu, 13 Mar 2003 14:04:38 +0200 From: Dovli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: problem with XFS 1.2 and linux kernel 2.4.18 and 2.4.19 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3181 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: dovli@work.ro Precedence: bulk X-list: linux-xfs Content-Length: 976 Lines: 24 Hello! I have a high traffic web server running slackware linux 8.1. The most used filesystem on the server which hosts a free web mail application has xfs on it. Until recently the server had been running smoothly with the 2.4.18 kernel but for the last two weeks the server hangs every now and then with an xfs error. I upgraded the kernel to 2.4.19 but the problem persists. This is the dmesg message on the server when the error last occured: xfs_inotobp: xfs_imap() returned an error 22 on ide0(3,8). Returning error.xfs_iunlink_remove: xfs_inotobp() returned an error 22 on ide0(3,8). Returning error.xfs_inactive: xfs_ifree() returned an error = 22 on ide0(3,8) xfs_force_shutdown(ide0(3,8),0x1) called from line 1845 of file xfs_vnodeops.c. Return address = 0xc01e0c14 I/O Error Detected. Shutting down filesystem: ide0(3,8) Please umount the filesystem, and rectify the problem(s) Any help would be appreciated Thank you very much for your support From owner-linux-xfs@oss.sgi.com Thu Mar 13 04:55:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 04:55:50 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DCt6q9027332 for ; Thu, 13 Mar 2003 04:55:47 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-165-123.quicknet.nl [212.58.165.123]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id h2DCt2j0047919; Thu, 13 Mar 2003 13:55:03 +0100 (CET) Message-Id: <4.3.2.7.2.20030313135406.0402a068@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 13:54:26 +0100 To: "Miro, Felix" , "'linux-xfs@oss.sgi.com'" From: Seth Mos Subject: Re: XFS root filesystem In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 3182 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 305 Lines: 12 At 13:48 12-3-2003 -0500, Miro, Felix wrote: >What is the procedure for making XFS my root filesystem under redhat 8.0+ ? >Your web page mentioned a working document but the link was broken. The easiest way is using the 8.0 installer. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Mar 13 05:04:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 05:04:24 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DD4Jq9027808 for ; Thu, 13 Mar 2003 05:04:21 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-165-123.quicknet.nl [212.58.165.123]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id h2DD4IUV072464; Thu, 13 Mar 2003 14:04:18 +0100 (CET) Message-Id: <4.3.2.7.2.20030313135945.034419d8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 14:03:40 +0100 To: Dovli , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: problem with XFS 1.2 and linux kernel 2.4.18 and 2.4.19 In-Reply-To: <3E7073D6.2040207@work.ro> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 3183 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 990 Lines: 28 At 14:04 13-3-2003 +0200, Dovli wrote: >Hello! > >xfs_inotobp: xfs_imap() returned an error 22 on ide0(3,8). Returning >error.xfs_iunlink_remove: xfs_inotobp() returned an error 22 on >ide0(3,8). Returning error.xfs_inactive: xfs_ifree() returned an >error = 22 on ide0(3,8) >xfs_force_shutdown(ide0(3,8),0x1) called from line 1845 of file >xfs_vnodeops.c. Return address = 0xc01e0c14 >I/O Error Detected. Shutting down filesystem: ide0(3,8) >Please umount the filesystem, and rectify the problem(s) IIRC Linda Walsh had the exact same error message on her root filesystem while she tried to dump it with xfsdump. In this case I think there is either a stray file or directory on the filesystem which is confusing the xfs layer. You may want find find the thread using the searchable mailing list archive. You can find the link on the mailinglist page. It lists the way to find the problem and correct it. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Mar 13 05:10:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 05:10:20 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DD9bq9028310 for ; Thu, 13 Mar 2003 05:10:18 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-165-123.quicknet.nl [212.58.165.123]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h2DD9WZ4099927; Thu, 13 Mar 2003 14:09:33 +0100 (CET) Message-Id: <4.3.2.7.2.20030313140702.036dc338@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 14:08:54 +0100 To: "Peter Alberer" , From: Seth Mos Subject: Re: nfs and number of open files In-Reply-To: <001201c2e8a9$dd402200$5be0d089@ekelhardt> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 3184 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 584 Lines: 20 At 16:12 12-3-2003 +0100, Peter Alberer wrote: >Hi all, > >today I got the following error message on the nfs server: "too many >open files in system". First I increased the limit >(/proc/sys/fs/file-max) to 12000 (was 8192) files, to get things running >again. But now I want to find out why so many files are open and I would >like to know which files are open. It might be that the NFS client or webserver is no closing the file handles the way it should. This might be related to the crash of the webserver. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Mar 13 06:13:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 06:13:42 -0800 (PST) Received: from stargate.coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.114.72.97]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DEDaq9029259 for ; Thu, 13 Mar 2003 06:13:37 -0800 Received: from contact.skynet.coplanar.net (contact.skynet.coplanar.net [192.168.7.125]) by stargate.coplanar.net (8.12.8/8.12.5) with ESMTP id h2DEDZAW007868 for ; Thu, 13 Mar 2003 09:13:35 -0500 Subject: XFS 1.2.0 release for linux-2.4.20? From: Jeremy Jackson To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1047564814.2704.41.camel@contact.skynet.coplanar.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 13 Mar 2003 09:13:34 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 3185 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: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 224 Lines: 8 I have just finished merging linux-2.4.19-core-xfs-1.2.0.patch.gz into linux-2.4.20. I am wondering if there might be a forthcoming official release of same, or if the merging I have done might be useful. Cheers, Jeremy From owner-linux-xfs@oss.sgi.com Thu Mar 13 06:37:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 06:37:53 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DEb4q9029877 for ; Thu, 13 Mar 2003 06:37:44 -0800 Received: from [10.0.0.10] (c-24-245-56-70.mn.client2.attbi.com [24.245.56.70]) by lips.thebarn.com (8.12.8/8.12.6) with ESMTP id h2DEax97038529; Thu, 13 Mar 2003 08:37:00 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: XFS 1.2.0 release for linux-2.4.20? From: Russell Cattelan To: Jeremy Jackson Cc: linux-xfs@oss.sgi.com In-Reply-To: <1047564814.2704.41.camel@contact.skynet.coplanar.net> References: <1047564814.2704.41.camel@contact.skynet.coplanar.net> Content-Type: text/plain Organization: Message-Id: <1047566218.36078.12.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 13 Mar 2003 08:36:59 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 3186 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: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs Content-Length: 527 Lines: 16 On Thu, 2003-03-13 at 08:13, Jeremy Jackson wrote: > I have just finished merging linux-2.4.19-core-xfs-1.2.0.patch.gz into > linux-2.4.20. I am wondering if there might be a forthcoming official > release of same, or if the merging I have done might be useful. We probably are not going to do anything "official" i.e. fully tested. But you want to send us the patch, we can look it over and put it on the ftp site in case other people want to grab it. > > Cheers, > > Jeremy -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Thu Mar 13 07:21:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 07:21:32 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2DFLRq9030703 for ; Thu, 13 Mar 2003 07:21:27 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2DFLQ8a030701 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 07:21:26 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2DFLOqB030688 for ; Thu, 13 Mar 2003 07:21:25 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2DENa2U029773; Thu, 13 Mar 2003 06:23:36 -0800 Date: Thu, 13 Mar 2003 06:23:36 -0800 Message-Id: <200303131423.h2DENa2U029773@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] New: umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-archive-position: 3187 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1308 Lines: 36 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 Summary: umount hangs after high disk load Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: major Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: atu@dmeti.dp.ua kernel: 2.4.20+xfs(some modern snapshots up to 2003-03-09, from SGI FTP)+netfiler+openwall build by gcc 3.2.(1-2), XFS in kernel, not in modules. All linux partitions is XFS: /=hda5(300M), /usr=hda8(7G), /var=hda9(2G), /home=hda10(12G). swap=hda7(1G). 256M RAM. Redhat-like initscripts. If afer boot run some disk-using program (I use updatedb), and than try to reboot or halt, shutdown hangs in /etc/rc.d/init.d/halt while first umount loop. Using -v as umount, I found, that hang occured while umounting /usr. fuser shows no processes, using /usr. The same result can be created by: mount /usr -o remount,ro or Alt-PrintScreen-u Alt-PrintScreen-P shows, shows, that current process in swapper. Before hang essenshial disk activity (by LED, approx 10-20s). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 13 11:45:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 11:45:11 -0800 (PST) Received: from hotmail.com (f41.sea2.hotmail.com [207.68.165.41]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DJj3q9003775 for ; Thu, 13 Mar 2003 11:45:03 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 13 Mar 2003 11:43:22 -0800 Received: from 208.244.233.175 by sea2fd.sea2.hotmail.msn.com with HTTP; Thu, 13 Mar 2003 19:43:21 GMT X-Originating-IP: [208.244.233.175] From: "Rick Smith" To: linux-xfs@oss.sgi.com Subject: reserving contiguous files Date: Thu, 13 Mar 2003 11:43:21 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Mar 2003 19:43:22.0138 (UTC) FILETIME=[CE11F7A0:01C2E998] X-archive-position: 3188 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: rgsmith72@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1290 Lines: 24 Hello, I am trying to write sequences of contiguous files in XFS to minimize the drive head seeks that must occur during file reads. Using the XFS_RESVSP64 ioctl to reserve the set of files ahead of time, I am able to get individual files allocated with contiguous extents. However, the allocation of one file versus another (reserved immediately after each other) seems to be somewhat erratic. Is there a way to guarantee or further lock the allocation of one file with respect to another in a contiguous manner? Looking at xfs_vnodeops.c and xfs_bmap.c could this be possibly be achieved by initializing the firstfsb structure in xfs_alloc_file_space() only in the first reserve call for a group allocation? The value of this structure could be maintained for consecutive calls to allow the contiguous allocation of a group of files based on the preceeding reserve ioctl. This behavior could be added as an additional ioctl call (RESVSP64CONTIG?) to maintain the current working code. I am going to experiment with this, but I would appreciate suggestions/comments. Thanks. Rick Smith _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-linux-xfs@oss.sgi.com Thu Mar 13 12:05:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 12:05:08 -0800 (PST) Received: from fed1mtao08.cox.net (fed1mtao08.cox.net [68.6.19.123]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DK54q9004326 for ; Thu, 13 Mar 2003 12:05:05 -0800 Received: from jeeves.kpf.internal ([24.56.60.83]) by fed1mtao08.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030313200457.JVEM29278.fed1mtao08.cox.net@jeeves.kpf.internal> for ; Thu, 13 Mar 2003 15:04:57 -0500 Received: from [192.168.130.55] (helo=cox.net) by jeeves.kpf.internal with esmtp (Exim 4.05) id 18tYwk-0001AI-00 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 13:04:59 -0700 Message-ID: <3E70E46A.20901@cox.net> Date: Thu, 13 Mar 2003 13:04:58 -0700 From: "Kevin P. Fleming" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [NEWBIE] Why aren't directory mtimes updated like other filesystems? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3189 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: kpfleming@cox.net Precedence: bulk X-list: linux-xfs Content-Length: 742 Lines: 13 I've just set up my first XFS system, using kernel 2.5.64-bk7. So far so good, got three XFS volumes on an LVM2 volume group and everything seems to be working well. However, I noticed a behavior that I didn't expect. I've googled, and checked the FAQ, and checked the XFS Bugzilla and I haven't come across it. On my XFS filesystems, when I make changes within a directory (create/remove subdirectory, create/remove/touch files), the mtime (modification time) of the parent directory is not updated. On my other filesystems (ext2 and ext3) it is. I am working on a Makefile that depends on this behavior, so I'm wondering if this is a bug in XFS, or if updating the parent directory's mtime is not mandataory Unix/POSIX behavior? From owner-linux-xfs@oss.sgi.com Thu Mar 13 12:11:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 12:11:46 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DKB4q9004853 for ; Thu, 13 Mar 2003 12:11:44 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2DKLwkq012460 for ; Thu, 13 Mar 2003 14:21:58 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (8.12.8/americas-smart-nospam1.1) with ESMTP id h2DKAv4H16286747; Thu, 13 Mar 2003 14:10:57 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2DKAvwX28572372; Thu, 13 Mar 2003 14:10:57 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2DKAvK12183; Thu, 13 Mar 2003 14:10:57 -0600 Subject: Re: [NEWBIE] Why aren't directory mtimes updated like other filesystems? From: Steve Lord To: "Kevin P. Fleming" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E70E46A.20901@cox.net> References: <3E70E46A.20901@cox.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047586257.30836.58.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 13 Mar 2003 14:10:57 -0600 X-archive-position: 3190 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1745 Lines: 43 On Thu, 2003-03-13 at 14:04, Kevin P. Fleming wrote: > I've just set up my first XFS system, using kernel 2.5.64-bk7. So far so good, > got three XFS volumes on an LVM2 volume group and everything seems to be working > well. > > However, I noticed a behavior that I didn't expect. I've googled, and checked > the FAQ, and checked the XFS Bugzilla and I haven't come across it. On my XFS > filesystems, when I make changes within a directory (create/remove subdirectory, > create/remove/touch files), the mtime (modification time) of the parent > directory is not updated. On my other filesystems (ext2 and ext3) it is. I am > working on a Makefile that depends on this behavior, so I'm wondering if this is > a bug in XFS, or if updating the parent directory's mtime is not mandataory > Unix/POSIX behavior? Well, the code is there to do this, and, when I modify a directory it does change the times: jen{lord}: stat . File: "." Size: 4096 Blocks: 8 IO Block: 4096 Directory Device: 804h/2052d Inode: 131 Links: 28 Access: (0755/drwxr-xr-x) Uid: ( 858/ lord) Gid: ( 1015/ network) Access: Thu Mar 13 14:08:25 2003 Modify: Thu Mar 13 10:50:35 2003 Change: Thu Mar 13 10:50:35 2003 jen{lord}: touch foo jen{lord}: stat . File: "." Size: 4096 Blocks: 8 IO Block: 4096 Directory Device: 804h/2052d Inode: 131 Links: 28 Access: (0755/drwxr-xr-x) Uid: ( 858/ lord) Gid: ( 1015/ network) Access: Thu Mar 13 14:08:25 2003 Modify: Thu Mar 13 14:10:28 2003 Change: Thu Mar 13 14:10:28 2003 Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Mar 13 12:41:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 12:41:34 -0800 (PST) Received: from fed1mtao05.cox.net (fed1mtao05.cox.net [68.6.19.126]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DKf3q9014480 for ; Thu, 13 Mar 2003 12:41:31 -0800 Received: from jeeves.kpf.internal ([24.56.60.83]) by fed1mtao05.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030313204055.KDBJ1559.fed1mtao05.cox.net@jeeves.kpf.internal> for ; Thu, 13 Mar 2003 15:40:55 -0500 Received: from [192.168.130.55] (helo=cox.net) by jeeves.kpf.internal with esmtp (Exim 4.05) id 18tZVZ-0001EU-00 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 13:40:58 -0700 Message-ID: <3E70ECD9.2080008@cox.net> Date: Thu, 13 Mar 2003 13:40:57 -0700 From: "Kevin P. Fleming" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030311 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: [NEWBIE] Why aren't directory mtimes updated like other filesystems? References: <3E70E46A.20901@cox.net> <1047586257.30836.58.camel@jen.americas.sgi.com> In-Reply-To: <1047586257.30836.58.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3191 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: kpfleming@cox.net Precedence: bulk X-list: linux-xfs Content-Length: 955 Lines: 27 Steve Lord wrote: > Well, the code is there to do this, and, when I modify a directory it > does change the times: > > jen{lord}: stat . > File: "." > Size: 4096 Blocks: 8 IO Block: 4096 Directory > Device: 804h/2052d Inode: 131 Links: 28 > Access: (0755/drwxr-xr-x) Uid: ( 858/ lord) Gid: ( 1015/ network) > Access: Thu Mar 13 14:08:25 2003 > Modify: Thu Mar 13 10:50:35 2003 > Change: Thu Mar 13 10:50:35 2003 > > jen{lord}: touch foo > jen{lord}: stat . > File: "." > Size: 4096 Blocks: 8 IO Block: 4096 Directory > Device: 804h/2052d Inode: 131 Links: 28 > Access: (0755/drwxr-xr-x) Uid: ( 858/ lord) Gid: ( 1015/ network) > Access: Thu Mar 13 14:08:25 2003 > Modify: Thu Mar 13 14:10:28 2003 > Change: Thu Mar 13 14:10:28 2003 > Strange, I try exactly the same commands and the ctime gets updated but the mtime does not. Are you running on 2.5? From owner-linux-xfs@oss.sgi.com Thu Mar 13 12:57:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 12:57:34 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DKvWq9015004 for ; Thu, 13 Mar 2003 12:57:32 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2DKvQ9n031051 for ; Thu, 13 Mar 2003 12:57:26 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (8.12.8/americas-smart-nospam1.1) with ESMTP id h2DKvQ4H16367896; Thu, 13 Mar 2003 14:57:26 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2DKvPwX28005102; Thu, 13 Mar 2003 14:57:26 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2DKvPt12834; Thu, 13 Mar 2003 14:57:25 -0600 Subject: Re: [NEWBIE] Why aren't directory mtimes updated like other filesystems? From: Steve Lord To: "Kevin P. Fleming" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E70ECD9.2080008@cox.net> References: <3E70E46A.20901@cox.net> <1047586257.30836.58.camel@jen.americas.sgi.com> <3E70ECD9.2080008@cox.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047589045.12814.2.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 13 Mar 2003 14:57:25 -0600 X-archive-position: 3192 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1436 Lines: 40 On Thu, 2003-03-13 at 14:40, Kevin P. Fleming wrote: > Steve Lord wrote: > > Well, the code is there to do this, and, when I modify a directory it > > does change the times: > > > > jen{lord}: stat . > > File: "." > > Size: 4096 Blocks: 8 IO Block: 4096 Directory > > Device: 804h/2052d Inode: 131 Links: 28 > > Access: (0755/drwxr-xr-x) Uid: ( 858/ lord) Gid: ( 1015/ network) > > Access: Thu Mar 13 14:08:25 2003 > > Modify: Thu Mar 13 10:50:35 2003 > > Change: Thu Mar 13 10:50:35 2003 > > > > jen{lord}: touch foo > > jen{lord}: stat . > > File: "." > > Size: 4096 Blocks: 8 IO Block: 4096 Directory > > Device: 804h/2052d Inode: 131 Links: 28 > > Access: (0755/drwxr-xr-x) Uid: ( 858/ lord) Gid: ( 1015/ network) > > Access: Thu Mar 13 14:08:25 2003 > > Modify: Thu Mar 13 14:10:28 2003 > > Change: Thu Mar 13 14:10:28 2003 > > > > Strange, I try exactly the same commands and the ctime gets updated but the > mtime does not. Are you running on 2.5? Ah, this is 2.4, I don't have a spare box for 2.5 here right now, but I know someone who does. The core xfs code is the same, and it is updating the timestamp fields in the inode. Possibly it is something in the stat path. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Mar 13 13:10:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 13:10:56 -0800 (PST) Received: from fed1mtao05.cox.net (fed1mtao05.cox.net [68.6.19.126]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DLAAq9015568 for ; Thu, 13 Mar 2003 13:10:50 -0800 Received: from jeeves.kpf.internal ([24.56.60.83]) by fed1mtao05.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030313211002.KIEG1559.fed1mtao05.cox.net@jeeves.kpf.internal> for ; Thu, 13 Mar 2003 16:10:02 -0500 Received: from [192.168.130.55] (helo=cox.net) by jeeves.kpf.internal with esmtp (Exim 4.05) id 18tZxl-0001H8-00 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 14:10:05 -0700 Message-ID: <3E70F3AD.5090209@cox.net> Date: Thu, 13 Mar 2003 14:10:05 -0700 From: "Kevin P. Fleming" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: [NEWBIE] Why aren't directory mtimes updated like other filesystems? References: <3E70E46A.20901@cox.net> <1047586257.30836.58.camel@jen.americas.sgi.com> <3E70ECD9.2080008@cox.net> <1047589045.12814.2.camel@jen.americas.sgi.com> In-Reply-To: <1047589045.12814.2.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3193 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: kpfleming@cox.net Precedence: bulk X-list: linux-xfs Content-Length: 701 Lines: 16 Steve Lord wrote: >>Strange, I try exactly the same commands and the ctime gets updated but the >>mtime does not. Are you running on 2.5? > > > Ah, this is 2.4, I don't have a spare box for 2.5 here right now, > but I know someone who does. The core xfs code is the same, and it > is updating the timestamp fields in the inode. Possibly it is > something in the stat path. > Actually, it may be more insidious than that. When I did some testing over a 30 minute period, at one point making a new subdirectory caused the parent's mtime to update, but it updated to a time of about 10 minutes previous, when I had mad other changes. So it did change, but not to the current time. Very strange. From owner-linux-xfs@oss.sgi.com Thu Mar 13 13:16:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 13:16:39 -0800 (PST) Received: from pip (c-24-98-62-33.atl.client2.attbi.com [24.98.62.33]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DLGZq9016046 for ; Thu, 13 Mar 2003 13:16:37 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by pip (8.11.6/8.11.6) with ESMTP id h2DLGYQ02172; Thu, 13 Mar 2003 16:16:34 -0500 Subject: Re: [NEWBIE] Why aren't directory mtimes updated like other filesystems? From: Danny Cox To: "Kevin P. Fleming" Cc: XFS Mailing List In-Reply-To: <3E70F3AD.5090209@cox.net> References: <3E70E46A.20901@cox.net> <1047586257.30836.58.camel@jen.americas.sgi.com> <3E70ECD9.2080008@cox.net> <1047589045.12814.2.camel@jen.americas.sgi.com> <3E70F3AD.5090209@cox.net> Content-Type: text/plain Organization: No Organization at ALL Message-Id: <1047590194.1306.28.camel@pip> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 13 Mar 2003 16:16:34 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 3194 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: danscox@mindspring.com Precedence: bulk X-list: linux-xfs Content-Length: 617 Lines: 20 Kevin, On Thu, 2003-03-13 at 16:10, Kevin P. Fleming wrote: > Actually, it may be more insidious than that. When I did some testing over a 30 > minute period, at one point making a new subdirectory caused the parent's mtime > to update, but it updated to a time of about 10 minutes previous, when I had mad > other changes. So it did change, but not to the current time. Very strange. Does running 'sync' after changes make any difference? -- kernel, n.: A part of an operating system that preserves the medieval traditions of sorcery and black art. Danny From owner-linux-xfs@oss.sgi.com Thu Mar 13 13:30:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 13:30:50 -0800 (PST) Received: from fed1mtao08.cox.net (fed1mtao08.cox.net [68.6.19.123]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DLUlq9016578 for ; Thu, 13 Mar 2003 13:30:48 -0800 Received: from jeeves.kpf.internal ([24.56.60.83]) by fed1mtao08.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030313213041.KLJW29278.fed1mtao08.cox.net@jeeves.kpf.internal> for ; Thu, 13 Mar 2003 16:30:41 -0500 Received: from [192.168.130.55] (helo=cox.net) by jeeves.kpf.internal with esmtp (Exim 4.05) id 18taHi-0001K7-00 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 14:30:42 -0700 Message-ID: <3E70F881.7040605@cox.net> Date: Thu, 13 Mar 2003 14:30:41 -0700 From: "Kevin P. Fleming" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: XFS Mailing List Subject: Re: [NEWBIE] Why aren't directory mtimes updated like other filesystems? References: <3E70E46A.20901@cox.net> <1047586257.30836.58.camel@jen.americas.sgi.com> <3E70ECD9.2080008@cox.net> <1047589045.12814.2.camel@jen.americas.sgi.com> <3E70F3AD.5090209@cox.net> <1047590194.1306.28.camel@pip> In-Reply-To: <1047590194.1306.28.camel@pip> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3195 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: kpfleming@cox.net Precedence: bulk X-list: linux-xfs Content-Length: 611 Lines: 20 Danny Cox wrote: > Kevin, > > On Thu, 2003-03-13 at 16:10, Kevin P. Fleming wrote: > >>Actually, it may be more insidious than that. When I did some testing over a 30 >>minute period, at one point making a new subdirectory caused the parent's mtime >>to update, but it updated to a time of about 10 minutes previous, when I had mad >>other changes. So it did change, but not to the current time. Very strange. > > > > > Does running 'sync' after changes make any difference? > > > Doesn't appear to, no. No change before and after the sync command. From owner-linux-xfs@oss.sgi.com Thu Mar 13 13:54:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 13:54:44 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DLs1q9017931 for ; Thu, 13 Mar 2003 13:54:42 -0800 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2DM4ukq015650 for ; Thu, 13 Mar 2003 16:04:56 -0600 Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.12.5/8.12.5) with ESMTP id h2DLruWg016699 for ; Thu, 13 Mar 2003 15:53:56 -0600 Received: (from cattelan@localhost) by naboo.americas.sgi.com (8.12.5/8.12.5/Submit) id h2DLrtqS016697 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 15:53:55 -0600 Date: Thu, 13 Mar 2003 15:53:55 -0600 From: Rusell Cattelan Message-Id: <200303132153.h2DLrtqS016697@naboo.americas.sgi.com> Subject: TAKE - Move sector_t def to a more appropriate spot X-archive-position: 3196 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: cattelan@naboo.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 294 Lines: 12 Date: Thu Mar 13 13:53:42 PST 2003 Workarea: naboo.americas.sgi.com:/misc/xfs1/rsrc/2.4.x-xfs/find The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141692a linux/fs/xfs/xfs_types.h - 1.66 linux/fs/xfs/linux/xfs_linux.h - 1.101 From owner-linux-xfs@oss.sgi.com Thu Mar 13 13:57:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 13:57:20 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DLvIq9018389 for ; Thu, 13 Mar 2003 13:57:18 -0800 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2DLvCnH009692 for ; Thu, 13 Mar 2003 13:57:13 -0800 Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.12.5/8.12.5) with ESMTP id h2DLvCWg017209 for ; Thu, 13 Mar 2003 15:57:12 -0600 Received: (from cattelan@localhost) by naboo.americas.sgi.com (8.12.5/8.12.5/Submit) id h2DLvCFm017207 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 15:57:12 -0600 Date: Thu, 13 Mar 2003 15:57:12 -0600 From: Rusell Cattelan Message-Id: <200303132157.h2DLvCFm017207@naboo.americas.sgi.com> Subject: TAKE - More kdb info for requests X-archive-position: 3197 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: cattelan@naboo.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 300 Lines: 13 Date: Thu Mar 13 13:56:52 PST 2003 Workarea: naboo.americas.sgi.com:/misc/xfs1/rsrc/2.4.x-xfs/find The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141693a linux/kdb/modules/kdbm_pg.c - 1.64 - print out the number of free requests From owner-linux-xfs@oss.sgi.com Thu Mar 13 14:23:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 14:23:10 -0800 (PST) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [80.190.100.240]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DMMKq9019925 for ; Thu, 13 Mar 2003 14:23:07 -0800 Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id 8A55B100714 for ; Thu, 13 Mar 2003 23:22:19 +0100 (CET) Received: from warp9.sapienti-sat.org (pD9E7F29E.dip.t-dialin.net [217.231.242.158]) by batleth.sapienti-sat.org (Postfix) with ESMTP id 4B649100133 for ; Thu, 13 Mar 2003 23:22:19 +0100 (CET) Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by warp9.sapienti-sat.org (Postfix) with SMTP id A846FBC for ; Thu, 13 Mar 2003 23:22:16 +0100 (CET) Received: from koschikode.com (pktomo.sapienti-sat.org [192.168.200.10]) by warp9.sapienti-sat.org (Postfix) with ESMTP id 7A693B8 for ; Thu, 13 Mar 2003 23:22:16 +0100 (CET) Message-ID: <3E710497.8030208@koschikode.com> Date: Thu, 13 Mar 2003 23:22:15 +0100 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de-de, en-us, en MIME-Version: 1.0 To: XFS Mailing List Subject: Re: [NEWBIE] Why aren't directory mtimes updated like other filesystems? References: <3E70E46A.20901@cox.net> <1047586257.30836.58.camel@jen.americas.sgi.com> <3E70ECD9.2080008@cox.net> <1047589045.12814.2.camel@jen.americas.sgi.com> <3E70F3AD.5090209@cox.net> <1047590194.1306.28.camel@pip> <3E70F881.7040605@cox.net> In-Reply-To: <3E70F881.7040605@cox.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3198 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: juri@koschikode.com Precedence: bulk X-list: linux-xfs Content-Length: 906 Lines: 27 Kevin P. Fleming wrote: > Danny Cox wrote: >> On Thu, 2003-03-13 at 16:10, Kevin P. Fleming wrote: >> >>>Actually, it may be more insidious than that. When I did some testing over a 30 >>>minute period, at one point making a new subdirectory caused the parent's mtime >>>to update, but it updated to a time of about 10 minutes previous, when I had mad >>>other changes. So it did change, but not to the current time. Very strange. >> >> >> >> Does running 'sync' after changes make any difference? >> >> >> > Doesn't appear to, no. No change before and after the sync command. Maybe it's a more generic problem and related to the following bug Ted Ts'o just found: "[PATCH] BUGFIX: Ext2/3 noatime and dirsync sometimes ignored" http://marc.theaimsgroup.com/?l=linux-kernel&m=104754557025362&w=2 Just a(nother) shot in the dark... Regards, Juri From owner-linux-xfs@oss.sgi.com Thu Mar 13 14:28:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 14:28:21 -0800 (PST) Received: from fed1mtao08.cox.net (fed1mtao08.cox.net [68.6.19.123]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DMSIq9020394 for ; Thu, 13 Mar 2003 14:28:19 -0800 Received: from jeeves.kpf.internal ([24.56.60.83]) by fed1mtao08.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030313222812.KXST29278.fed1mtao08.cox.net@jeeves.kpf.internal> for ; Thu, 13 Mar 2003 17:28:12 -0500 Received: from [192.168.130.55] (helo=cox.net) by jeeves.kpf.internal with esmtp (Exim 4.05) id 18tbBN-0001RJ-00 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 15:28:13 -0700 Message-ID: <3E7105FC.2060508@cox.net> Date: Thu, 13 Mar 2003 15:28:12 -0700 From: "Kevin P. Fleming" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: XFS Mailing List Subject: Re: [NEWBIE] Why aren't directory mtimes updated like other filesystems? References: <3E70E46A.20901@cox.net> <1047586257.30836.58.camel@jen.americas.sgi.com> <3E70ECD9.2080008@cox.net> <1047589045.12814.2.camel@jen.americas.sgi.com> <3E70F3AD.5090209@cox.net> <1047590194.1306.28.camel@pip> <3E70F881.7040605@cox.net> <3E710497.8030208@koschikode.com> In-Reply-To: <3E710497.8030208@koschikode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3199 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: kpfleming@cox.net Precedence: bulk X-list: linux-xfs Content-Length: 391 Lines: 15 Juri Haberland wrote: > Maybe it's a more generic problem and related to the following bug Ted > Ts'o just found: > "[PATCH] BUGFIX: Ext2/3 noatime and dirsync sometimes ignored" > http://marc.theaimsgroup.com/?l=linux-kernel&m=104754557025362&w=2 > > Just a(nother) shot in the dark... > > Regards, > Juri > > I don't think so; my ext2 filesystem on the same machine works just fine. From owner-linux-xfs@oss.sgi.com Thu Mar 13 15:05:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 15:05:56 -0800 (PST) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [80.190.100.240]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DN4wq9021045 for ; Thu, 13 Mar 2003 15:05:39 -0800 Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id F1CCB100714 for ; Thu, 13 Mar 2003 23:33:23 +0100 (CET) Received: from warp9.sapienti-sat.org (pD9E7F29E.dip.t-dialin.net [217.231.242.158]) by batleth.sapienti-sat.org (Postfix) with ESMTP id A912E100133 for ; Thu, 13 Mar 2003 23:33:23 +0100 (CET) Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by warp9.sapienti-sat.org (Postfix) with SMTP id A2352BC for ; Thu, 13 Mar 2003 23:33:20 +0100 (CET) Received: from koschikode.com (pktomo.sapienti-sat.org [192.168.200.10]) by warp9.sapienti-sat.org (Postfix) with ESMTP id 30298AA for ; Thu, 13 Mar 2003 23:33:20 +0100 (CET) Message-ID: <3E71072F.8010100@koschikode.com> Date: Thu, 13 Mar 2003 23:33:19 +0100 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de-de, en-us, en MIME-Version: 1.0 To: XFS Mailing List Subject: Re: [NEWBIE] Why aren't directory mtimes updated like other filesystems? References: <3E70E46A.20901@cox.net> <1047586257.30836.58.camel@jen.americas.sgi.com> <3E70ECD9.2080008@cox.net> <1047589045.12814.2.camel@jen.americas.sgi.com> <3E70F3AD.5090209@cox.net> <1047590194.1306.28.camel@pip> <3E70F881.7040605@cox.net> <3E710497.8030208@koschikode.com> <3E7105FC.2060508@cox.net> In-Reply-To: <3E7105FC.2060508@cox.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3200 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: juri@koschikode.com Precedence: bulk X-list: linux-xfs Content-Length: 499 Lines: 17 Kevin P. Fleming wrote: > Juri Haberland wrote: >> Maybe it's a more generic problem and related to the following bug Ted >> Ts'o just found: >> "[PATCH] BUGFIX: Ext2/3 noatime and dirsync sometimes ignored" >> http://marc.theaimsgroup.com/?l=linux-kernel&m=104754557025362&w=2 >> >> Just a(nother) shot in the dark... > I don't think so; my ext2 filesystem on the same machine works just fine. Yes, you mentioned it. And this bug is only in connection with DIRSYNC... Back to lurking ;) Juri From owner-linux-xfs@oss.sgi.com Thu Mar 13 15:21:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 15:21:35 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2DNLTq9021637 for ; Thu, 13 Mar 2003 15:21:29 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2DNLTCG021635 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 15:21:29 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2DNLQqF021618 for ; Thu, 13 Mar 2003 15:21:27 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2DMkXX5020941; Thu, 13 Mar 2003 14:46:34 -0800 Date: Thu, 13 Mar 2003 14:46:34 -0800 Message-Id: <200303132246.h2DMkXX5020941@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 197] stalled files in /var/lock, data fork in ino 79692177 claims free block 5040984 X-Bugzilla-Reason: AssignedTo X-archive-position: 3201 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 563 Lines: 20 http://oss.sgi.com/bugzilla/show_bug.cgi?id=197 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From cattelan@thebarn.com 2003-03-13 14:46 ------- The last patch fixed the problem ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 13 15:26:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 15:26:44 -0800 (PST) Received: from mail.rjmx.net (root@khufu.ne.client2.attbi.com [24.218.135.94]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DNQeq9022082 for ; Thu, 13 Mar 2003 15:26:41 -0800 Received: from cleopatra.rjmx.net.rjmx.net (ron@cleopatra.rjmx.net [192.168.17.2]) by mail.rjmx.net (8.12.8/8.12.8) with ESMTP id h2DNQW4V023673 for ; Thu, 13 Mar 2003 18:26:32 -0500 Date: Thu, 13 Mar 2003 18:26:31 -0500 Message-ID: <871y1ax2zc.wl@PurpleTram.Com> From: Ron Murray To: linux-xfs@oss.sgi.com Subject: Re: [Bug 230] New: umount hangs after high disk load In-Reply-To: <200303131423.h2DENa2U029773@oss.sgi.com> References: <200303131423.h2DENa2U029773@oss.sgi.com> User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI) Reply-To: rjmx@rjmx.net MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII X-archive-position: 3202 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: rjmx@rjmx.net Precedence: bulk X-list: linux-xfs Content-Length: 2807 Lines: 69 I've been experiencing the same problem for several months now, on my Debian-sarge system (1.2G Athlon/512M RAM). I have xfs partitions on /usr (30G), /home (20G), /var (7.5G) (but not on /, too lazy to go through the conversion). Kernel versions I've had it happen with are 2.4.18 and 2.4.19, xfs versions uncertain but at least 1.2, perhaps 1.1 (but I may have been using one of the pre-1.2 versions). Again it's /usr that umount hangs on -- but not all the time. Sometimes it boots clean, sometimes it writes to disk for upwards of two minutes (!) and *then* boots clean. And sometimes it writes to disk for upwards of two minutes, or not at all, and then hangs. I haven't been able to correlate it with any particular disk usage pattern, unlike the person filing this bug. I might go a week or two without rebooting the thing and it'll boot clean, then reboot into Linux for five minutes, reboot again, and watch it lock up. The opposite is equally likely. I have tried reversing the mount order (which reverses the umount order) from having /usr first to having it last, and it still hangs on /usr, never the others. I've waited for the system to show no activity for 5-10 minutes and then rebooted, and still had it write to disk for a long time and then lock up. Suggestions for further troubleshooting welcome. .....Ron At Thu, 13 Mar 2003 06:23:36 -0800, bugzilla-daemon@oss.sgi.com wrote: > > http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 > > Summary: umount hangs after high disk load > Product: Linux XFS > Version: Current > Platform: IA32 > OS/Version: Linux > Status: NEW > Severity: major > Priority: Medium > Component: XFS kernel code > AssignedTo: xfs-master@oss.sgi.com > ReportedBy: atu@dmeti.dp.ua > > > kernel: 2.4.20+xfs(some modern snapshots up to 2003-03-09, from SGI FTP)+netfiler+openwall > build by gcc 3.2.(1-2), XFS in kernel, not in modules. > > All linux partitions is XFS: /=hda5(300M), /usr=hda8(7G), /var=hda9(2G), /home=hda10(12G). > swap=hda7(1G). 256M RAM. > Redhat-like initscripts. > > If afer boot run some disk-using program (I use updatedb), and than try to reboot or halt, > shutdown hangs in /etc/rc.d/init.d/halt while first umount loop. > Using -v as umount, I found, that hang occured while umounting /usr. > fuser shows no processes, using /usr. > The same result can be created by: > mount /usr -o remount,ro or Alt-PrintScreen-u > Alt-PrintScreen-P shows, shows, that current process in swapper. > Before hang essenshial disk activity (by LED, approx 10-20s). -- Ron Murray (rjmx@rjmx.net) http://www.rjmx.net/~ron GPG Public Key Fingerprint: F2C1 FC47 5EF7 0317 133C D66B 8ADA A3C4 D86C 74DE From owner-linux-xfs@oss.sgi.com Thu Mar 13 17:21:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Mar 2003 17:21:36 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2E1LUq9031174 for ; Thu, 13 Mar 2003 17:21:30 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2E1LT0l031172 for linux-xfs@oss.sgi.com; Thu, 13 Mar 2003 17:21:29 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2E1LRqB031158 for ; Thu, 13 Mar 2003 17:21:27 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2E0Vgis022895; Thu, 13 Mar 2003 16:31:42 -0800 Date: Thu, 13 Mar 2003 16:31:42 -0800 Message-Id: <200303140031.h2E0Vgis022895@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-archive-position: 3203 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 315 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From cattelan@thebarn.com 2003-03-13 16:31 ------- Can you drop the system into kdb and btp the umount process? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Mar 14 01:59:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 01:59:57 -0800 (PST) Received: from obelix.wu-wien.ac.at (obelix.wu-wien.ac.at [137.208.3.41]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2E9x8q9012688 for ; Fri, 14 Mar 2003 01:59:49 -0800 Received: from ekelhardt ([137.208.224.91]) by obelix.wu-wien.ac.at (8.8.7/8.8.7) with ESMTP id KAA51996emf h9351252@obelix.wu-wien.ac.at; Fri, 14 Mar 2003 10:58:59 +0100 From: "Peter Alberer" To: "'Seth Mos'" , Subject: AW: nfs and number of open files Date: Fri, 14 Mar 2003 10:58:59 +0100 Message-ID: <000e01c2ea10$559c5400$5be0d089@ekelhardt> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <4.3.2.7.2.20030313140702.036dc338@pop.xs4all.nl> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 3204 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: h9351252@obelix.wu-wien.ac.at Precedence: bulk X-list: linux-xfs Content-Length: 764 Lines: 25 >At 16:12 12-3-2003 +0100, Peter Alberer wrote: >>Hi all, >> >>today I got the following error message on the nfs server: "too many >>open files in system". First I increased the limit >>(/proc/sys/fs/file-max) to 12000 (was 8192) files, to get things running >>again. But now I want to find out why so many files are open and I would >>like to know which files are open. > >It might be that the NFS client or webserver is no closing the file handles >the way it should. > >This might be related to the crash of the webserver. This might of course be a possibility... Do you know how I can find out which files are open via nfs? I tried lsof -N (which did not show anything) and nfsstat but could not find any info on files currently open via nfs? Tia, peter From owner-linux-xfs@oss.sgi.com Fri Mar 14 06:02:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 06:02:31 -0800 (PST) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2EE2Kq9032039 for ; Fri, 14 Mar 2003 06:02:22 -0800 Received: from darke.mpc.local ([172.16.11.6] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 3.22 #1) id 18tplF-0001qB-00 for linux-xfs@oss.sgi.com; Fri, 14 Mar 2003 14:02:13 +0000 Message-ID: <3E71E0E5.19053656@moving-picture.com> Date: Fri, 14 Mar 2003 14:02:13 +0000 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Fast/light weight XFS find utility? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Disclaimer: This email and any attachments are confidential, may be legally X-Disclaimer: privileged and intended solely for the use of addressee. If you X-Disclaimer: are not the intended recipient of this message, any disclosure, X-Disclaimer: copying, distribution or any action taken in reliance on it is X-Disclaimer: strictly prohibited and may be unlawful. If you have received X-Disclaimer: this message in error, please notify the sender and delete all X-Disclaimer: copies from your system. X-Disclaimer: X-Disclaimer: Email may be susceptible to data corruption, interception and X-Disclaimer: unauthorised amendment, and we do not accept liability for any X-Disclaimer: such corruption, interception or amendment or the consequences X-Disclaimer: thereof. X-archive-position: 3205 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: james-p@moving-picture.com Precedence: bulk X-list: linux-xfs Content-Length: 383 Lines: 14 Is there some sort of find like utility that is optimised for XFS file systems? i.e. something that can use the internals of XFS to be fast and have a low CPU overhead. I'm not necessarily looking for a full blown 'fast' find utility, but something that can at least return lists of files based on type, owner, date etc. Is there anything that can do this? Thanks James Pearson From owner-linux-xfs@oss.sgi.com Fri Mar 14 06:48:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 06:48:50 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2EEmfq9002351 for ; Fri, 14 Mar 2003 06:48:42 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2EEmanH002050 for ; Fri, 14 Mar 2003 06:48:36 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA94640; Fri, 14 Mar 2003 08:48:35 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2EEmZwX29099238; Fri, 14 Mar 2003 08:48:35 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2EEmYv05267; Fri, 14 Mar 2003 08:48:34 -0600 Subject: Re: Fast/light weight XFS find utility? From: Steve Lord To: James Pearson Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E71E0E5.19053656@moving-picture.com> References: <3E71E0E5.19053656@moving-picture.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047653222.13590.2.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 14 Mar 2003 08:48:31 -0600 X-archive-position: 3206 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 693 Lines: 22 On Fri, 2003-03-14 at 08:02, James Pearson wrote: > Is there some sort of find like utility that is optimised for XFS file > systems? i.e. something that can use the internals of XFS to be fast and > have a low CPU overhead. > > I'm not necessarily looking for a full blown 'fast' find utility, but > something that can at least return lists of files based on type, owner, > date etc. > > Is there anything that can do this? > > Thanks > > James Pearson Take a look at xfs_ncheck as a starting point, there is a man page it uses some features of xfs_db, not necessarily that fast though. There is the bulkstat call which can walk all the inodes in the fs, see man 5 xfs for that. Steve From owner-linux-xfs@oss.sgi.com Fri Mar 14 07:44:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 07:44:18 -0800 (PST) Received: from sweeney.demon.co.uk (213-152-33-154.dsl.eclipse.net.uk [213.152.33.154]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2EFhxq9005514 for ; Fri, 14 Mar 2003 07:44:11 -0800 Received: from arequipa.sweeney.demon.co.uk (arequipa.sweeney.demon.co.uk [10.0.0.180]) by sweeney.demon.co.uk (Postfix) with SMTP id CD5721710E for ; Fri, 14 Mar 2003 15:43:42 +0000 (GMT) Date: Fri, 14 Mar 2003 15:46:09 +0000 From: Keith Matthews To: linux-xfs Subject: OT: Migration costs and problems Message-Id: <20030314154609.10be6b59.keith_m@sweeney.demon.co.uk> Organization: Frequentous Consultants Ltd X-Mailer: Sylpheed version 0.8.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3207 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: keith_m@sweeney.demon.co.uk Precedence: bulk X-list: linux-xfs Content-Length: 2635 Lines: 54 People, I would like to use the list for a request that has little or nothing to do with xfs, but a lot to do with moves to open-source products. One task I am currently involved in is putting together a document defining the problems and costs of moving from proprietary platforms to FREE/OSS. The client wanted us to extract most of our input data from what is already available on the web, but (as any of you who have made such a study will be aware) there is much exhortation, much claiming that there will be cost savings, some TCO studies (which often have undocumented bases and hence must be regarded as useless) and not a lot else in any useful detail. We have produced a document which details the likely moves and the mapping of proprietary and OSS products involved and are producing some estimates of the costs - both transition and ongoing. We now need to try and find organisations that have done such a change and are prepared to talk to us and help us validate our statements. How much of the result will get published for general public use is up to the client, not us, as the contract specifies that they have copyright. If confidentiality is required then there should be no problem, but all parties will probably want to discusss terms. Note that we are talking all OSS products, not just Linux. Any product whose licence conforms to the OSI definition will be examined, although we have a preference list (primarily to reduce the excessive choice available in some areas). We are also talking moves from green screen mainframe environments as well as from MS server/desktop environments and proprietary Unix based solutions. Since the document covers all non-specialist application areas we have broken the recommendations down by functional areas (e.g.mail servers) and are happy to talk at that level. Our brief is to cover public administration but everyone involved recognises that private sector admin usage is just as valid. Development shops and such like are not being considered. The only cost to you will be time, we will send someone to you. We are prepared to travel to anywhere in Europe or the Mediterranean area plus the East Coast USA/Canada. The client's budget does not allow to travel further without special need. We will allow half to one day for each visit unless you advise that the discussions might take longer. We do not currently see dealing with things by email as appropriate due to the volume of discussion that might well be required. If anyone has appropriate experience and their management is willing for them to help would they please contact me directly. Thank you. From owner-linux-xfs@oss.sgi.com Fri Mar 14 08:40:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 08:40:08 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2EGdMq9006277 for ; Fri, 14 Mar 2003 08:40:02 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2EGoKkq004963 for ; Fri, 14 Mar 2003 10:50:20 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA19588 for ; Fri, 14 Mar 2003 10:39:17 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2EGdGwX29113500 for ; Fri, 14 Mar 2003 10:39:16 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h2EGd2C28571; Fri, 14 Mar 2003 10:39:02 -0600 Message-Id: <200303141639.h2EGd2C28571@stout.americas.sgi.com> Date: Fri, 14 Mar 2003 10:39:02 -0600 Subject: TAKE - Tone down some error reports X-archive-position: 3208 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 426 Lines: 14 Bump the reporting threshold on calls to XFS_ERROR_REPORT which are most likely due to a simple user error. Date: Fri Mar 14 08:38:44 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141751a linux/fs/xfs/xfs_log_recover.c - 1.259 linux/fs/xfs/xfs_mount.c - 1.320 From owner-linux-xfs@oss.sgi.com Fri Mar 14 09:01:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 09:01:24 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2EH1Kq9006855 for ; Fri, 14 Mar 2003 09:01:21 -0800 Received: (qmail 5101 invoked by uid 500); 14 Mar 2003 16:58:48 -0000 Subject: Oddity when upgrading from 2.4.10 to 2.4.20 xfs kernels. From: Austin Gonyou To: XFS List Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1047661127.4678.25.camel@UberGeek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 14 Mar 2003 10:58:48 -0600 X-archive-position: 3209 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: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 577 Lines: 17 Using the snapshot from Dec 18 2002 for 2.4.20 and upgrading a few systems from 2.4.10 to 2.4.20, we noticed some file corruption. It has been rather easily repairable, but it is quite odd. The actions we took are like any other kernel upgrade. Install the new kernel, add entries to grub or lilo, reboot. The one thing that we noted was different though was xfsprogs hadn't been upgraded on the boxes. I was curious if something like that would cause this behavior or if it is a 2.4.10->2.4.20 problem? TIA. -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Fri Mar 14 11:02:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 11:03:05 -0800 (PST) Received: from hqntws.ciprico.com (hqntws.ciprico.com [208.252.143.8]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2EJ2vq9008803 for ; Fri, 14 Mar 2003 11:02:58 -0800 Received: From hqntws.ciprico.com ([127.0.0.1]) by hqntws.ciprico.com (WebShield SMTP v4.5 MR1a); id 1047668567261; Fri, 14 Mar 2003 13:02:47 -0600 Received: from hqntex1.ciprico.com [172.20.0.8] by hqntws.ciprico.com - SurfControl E-mail Filter (4.5); Friday, 14 March 2003, 13:02:46 Received: by hqntex1.ciprico.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Mar 2003 13:02:49 -0600 Message-ID: From: Antonio Ciorri To: "'linux-xfs@oss.sgi.com'" Date: Fri, 14 Mar 2003 13:02:48 -0600 Subject: Quota enable & disable. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Internet Mail Service (5.5.2653.19) X-archive-position: 3210 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: aciorri@ciprico.com Precedence: bulk X-list: linux-xfs Content-Length: 750 Lines: 20 Using quotas on our file systems: - We automatically enable the user quota enforcer in a file system when mounting with flag usrquota. - When the enforcer has to be disabled, we send a quotactl cmd with the option Q_XQUOTAOFF, later on when trying to enforce user quota, we have tried two ways: 1) sending quotactl cmd with the option Q_XQUOTAON, which is not working for us since it does not failed but the enforce is not being enabled or 2) by issuing a FS remount with flag usrquota, neither one of the above have been successful on enabling the user quota enforcer. So far unmounting the FS and mounting it again with flag usrquota is the only wait it has proven to be successful. Does anyone of you run into this before?. Thanks, Antonio. From owner-linux-xfs@oss.sgi.com Fri Mar 14 12:44:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 12:45:01 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2EKipq9011410 for ; Fri, 14 Mar 2003 12:44:52 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2EKtnkq011940 for ; Fri, 14 Mar 2003 14:55:49 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA23353; Fri, 14 Mar 2003 14:44:45 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2EKijwX28822404; Fri, 14 Mar 2003 14:44:45 -0600 (CST) Subject: Re: Oddity when upgrading from 2.4.10 to 2.4.20 xfs kernels. From: Rusell Cattelan To: Austin Gonyou Cc: XFS List In-Reply-To: <1047661127.4678.25.camel@UberGeek> References: <1047661127.4678.25.camel@UberGeek> Content-Type: text/plain Organization: Message-Id: <1047674819.14962.7.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-1) Date: 14 Mar 2003 14:46:59 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 3211 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: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 879 Lines: 23 On Fri, 2003-03-14 at 10:58, Austin Gonyou wrote: > Using the snapshot from Dec 18 2002 for 2.4.20 and upgrading a few > systems from 2.4.10 to 2.4.20, we noticed some file corruption. It has > been rather easily repairable, but it is quite odd. did you happen to save the output? Was the problem on multiple FSs or primarily the root FSs A problem was fixed in 1.2 that was related to the remount ro that happens to the root FS at shutdown time. > > The actions we took are like any other kernel upgrade. Install the new > kernel, add entries to grub or lilo, reboot. > > The one thing that we noted was different though was xfsprogs hadn't > been upgraded on the boxes. I was curious if something like that would > cause this behavior or if it is a 2.4.10->2.4.20 problem? No it shouldn't, but you should have the latest tools to do repair dump, attr etc... > > TIA. From owner-linux-xfs@oss.sgi.com Fri Mar 14 15:40:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 15:40:09 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2ENdIq9026284 for ; Fri, 14 Mar 2003 15:40:01 -0800 Received: (qmail 6905 invoked by uid 500); 14 Mar 2003 23:36:46 -0000 Subject: Re: Oddity when upgrading from 2.4.10 to 2.4.20 xfs kernels. From: Austin Gonyou To: Rusell Cattelan Cc: XFS List In-Reply-To: <1047674819.14962.7.camel@rose.americas.sgi.com> References: <1047674819.14962.7.camel@rose.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1047685005.4678.57.camel@UberGeek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 14 Mar 2003 17:36:45 -0600 X-archive-position: 3212 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: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 681 Lines: 20 On Fri, 2003-03-14 at 14:46, Rusell Cattelan wrote: > On Fri, 2003-03-14 at 10:58, Austin Gonyou wrote: > > Using the snapshot from Dec 18 2002 for 2.4.20 and upgrading a few > > systems from 2.4.10 to 2.4.20, we noticed some file corruption. It > has > > been rather easily repairable, but it is quite odd. > did you happen to save the output? > > Was the problem on multiple FSs or primarily the root FSs > A problem was fixed in 1.2 that was related to the remount ro > that happens to the root FS at shutdown time. > Yes...primarily root. I will update our patch with the latest snap if the fix is in there. -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Fri Mar 14 15:45:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Mar 2003 15:45:39 -0800 (PST) Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2ENjYq9026747 for ; Fri, 14 Mar 2003 15:45:35 -0800 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel6.hp.com (Postfix) with ESMTP id 81C021C01A3D; Fri, 14 Mar 2003 18:45:34 -0500 (EST) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 48D8A1C000B9; Fri, 14 Mar 2003 18:45:34 -0500 (EST) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Fri, 14 Mar 2003 18:45:34 -0500 Message-ID: From: "DICKENS,CARY (HP-Loveland,ex2)" To: "'Antonio Ciorri'" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: Quota enable & disable. Date: Fri, 14 Mar 2003 18:45:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain X-archive-position: 3213 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: cary.dickens2@hp.com Precedence: bulk X-list: linux-xfs Content-Length: 1904 Lines: 54 Antonio, I'm no expert, but I have been able to turn enforcement on and off without any problems. I can't remember when it happened, but there were some changes to the quota system that made it impossible to remount a volume and turn quotas on. Earlier xfs versions allowed this, the current versions do not. The volume in question must be mounted with quotas enabled and then you toggle enforcement on and off. What mount options do you use? I know that I _might_ want to have quotas on a file volume I am using, so I mount it with the following quota options: quota,qnoenforce,grpquota,gqnoenforce This way when I need to turn quota enforcement on, I can. The filesystem has been keeping the quotas calculated and all I have to do is send the quotactl command with Q_XQUOTAON. Example: quotactl(QCMD(Q_XQUOTAON,USRQUOTA), deviceFile, 0, (caddr_t) XFS_QUOTA_UDQ_ENFD); I hope this helps. Cary > -----Original Message----- > From: Antonio Ciorri [mailto:aciorri@ciprico.com] > Sent: Friday, March 14, 2003 12:03 PM > To: 'linux-xfs@oss.sgi.com' > Subject: Quota enable & disable. > > > Using quotas on our file systems: > > - We automatically enable the user quota enforcer in a file > system when mounting with flag usrquota. > - When the enforcer has to be disabled, we send a quotactl > cmd with the option Q_XQUOTAOFF, later on when trying to > enforce user quota, we have tried two ways: > 1) sending quotactl cmd with the option Q_XQUOTAON, which is > not working for us since it does not failed but the enforce > is not being enabled or 2) by issuing a FS remount with flag > usrquota, neither one of the above have been successful on > enabling the user quota enforcer. So far unmounting the FS > and mounting it again with flag usrquota is the only wait it > has proven to be successful. > > Does anyone of you run into this before?. > > Thanks, > > Antonio. > > From owner-linux-xfs@oss.sgi.com Sat Mar 15 13:05:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 15 Mar 2003 13:05:22 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2FL59q9006583 for ; Sat, 15 Mar 2003 13:05:10 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h2FL50uX025821 for ; Sat, 15 Mar 2003 13:05:04 -0800 From: "l.a walsh" To: Subject: extsize in data? Date: Sat, 15 Mar 2003 13:05:00 -0800 Message-ID: <001501c2eb36$8cacee60$1403a8c0@sc.tlinx.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-archive-position: 3214 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: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 2560 Lines: 54 I notice you can specify extent sizes as a sub-option to the realtime section, but it doesn't seem to be an option for the normal data subsection....a bit of a bummer. Is there a reason why? With a maximum block size of 4k (assuming the man page about linux limitations to page size are still accurate and assuming, I think, Linux uses a 4k pagesize) and 64K max extent, that's 256k. Many of my files are > 256k, on one of my larger disks, >15000 files. Is this a temporary limitation or is this sorta a fixed quality of the fs? Also, there was a case of someone making IMAX films writing 4x48Mb or close to 200Mb/second to an XFS disk over SMBFS for 12+hours. Quick math ~> 2 terabytes/file. Does that imply the files were composed of over 8 million extents each? If you had 4 separate streams writing to disk at the same time, what would be the likely placement of the extents for each stream? interleaving with the streams or contiguous/stream, or what? Or is it likely undefined/semi-random -- I guess I'd assume starting with an empty disk for best case. Background/why I'm asking: I'm having a discussion on the relative merits of NTFS that seems to need constant defragmentation vs. Unix file systems that seem to need (or have) little (xfs_defrag ~once a week by default), or no defragmentation process (assumption generally being that fragmentation stays below 5-10% if disk space is kept below 90 or 95% usage -- (is that the "common wisdom"? Is it even valid?)). I somehow got into this by proposing that instead of all these companies writing custom, run-in-the-background, or centrally controlled defragmenting utilities, they could just invest in porting over some of the linux file systems to NT, and make money off support, GUI and network management (XFS was one I suggested, of course). Then started getting into a discussion that is starting to be on the edge of my knowledge -- and, while pointing to the ancient XFS white paper, it also says that fragmentation is expected to be a long-term issue with files like outlook .pst files, since they are written and rewritten in small chunks over a large file with the large file being extended as necessary, in small bits over time (the one corresponding to my main mail folder is >148M...it might be painful, but I'm tempted to put it on smbfs so the file would be on xfs for a while and turn off the xfs-defragger for a week or so (I run mine nightly...but I'm a bit more fanatical about optimizing layout). Any benchmark studies on NTFS/XFS relative speed? Thanks, Linda From owner-linux-xfs@oss.sgi.com Sat Mar 15 13:21:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 15 Mar 2003 13:21:48 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2FLLcq9007171 for ; Sat, 15 Mar 2003 13:21:38 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2FLLcKq007167 for linux-xfs@oss.sgi.com; Sat, 15 Mar 2003 13:21:38 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2FLLaqD007141 for ; Sat, 15 Mar 2003 13:21:36 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2FL5tRB006657; Sat, 15 Mar 2003 13:05:55 -0800 Date: Sat, 15 Mar 2003 13:05:55 -0800 Message-Id: <200303152105.h2FL5tRB006657@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-archive-position: 3216 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 369 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From atu@dmeti.dp.ua 2003-03-15 13:05 ------- Created an attachment (id=68) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=68&action=view) result of btp(mount) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Mar 15 13:21:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 15 Mar 2003 13:21:40 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2FLLcq9007172 for ; Sat, 15 Mar 2003 13:21:38 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2FLLcEk007168 for linux-xfs@oss.sgi.com; Sat, 15 Mar 2003 13:21:38 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2FLLaqF007141 for ; Sat, 15 Mar 2003 13:21:36 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2FLGEiO007080; Sat, 15 Mar 2003 13:16:14 -0800 Date: Sat, 15 Mar 2003 13:16:14 -0800 Message-Id: <200303152116.h2FLGEiO007080@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-archive-position: 3215 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1594 Lines: 42 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From rjmx@rjmx.net 2003-03-15 13:16 ------- I've been experiencing the same problem for several months now, on my Debian-sarge system (1.2G Athlon/512M RAM). I have xfs partitions on /usr (30G), /home (20G), /var (7.5G) (but not on /, too lazy to go through the conversion). Kernel versions I've had it happen with are 2.4.18 and 2.4.19, xfs versions uncertain but at least 1.2, perhaps 1.1 (but I may have been using one of the pre-1.2 versions). Again it's /usr that umount hangs on -- but not all the time. Sometimes it boots clean, sometimes it writes to disk for upwards of two minutes (!) and *then* boots clean. And sometimes it writes to disk for upwards of two minutes, or not at all, and then hangs. I haven't been able to correlate it with any particular disk usage pattern, unlike the person filing this bug. I might go a week or two without rebooting the thing and it'll boot clean, then reboot into Linux for five minutes, reboot again, and watch it lock up. The opposite is equally likely. I have tried reversing the mount order (which reverses the umount order) from having /usr first to having it last, and it still hangs on /usr, never the others. I've waited for the system to show no activity for 5-10 minutes and then rebooted, and still had it write to disk for a long time and then lock up. Suggestions for further troubleshooting welcome. .....Ron ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Mar 16 09:21:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 09:21:49 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2GHLgq9022577 for ; Sun, 16 Mar 2003 09:21:42 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2GHLgSS022574 for linux-xfs@oss.sgi.com; Sun, 16 Mar 2003 09:21:42 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2GHLeqB022561 for ; Sun, 16 Mar 2003 09:21:40 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2GGqiSX022315; Sun, 16 Mar 2003 08:52:45 -0800 Date: Sun, 16 Mar 2003 08:52:45 -0800 Message-Id: <200303161652.h2GGqiSX022315@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-archive-position: 3217 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 345 Lines: 16 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From atu@dmeti.dp.ua 2003-03-16 08:52 ------- bta shows no processes with pagebuf_lock (exept mount), and no processes in __down at all. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Mar 16 16:46:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 16:46:28 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H0kFq9025256 for ; Sun, 16 Mar 2003 16:46:16 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2H0k99n023528 for ; Sun, 16 Mar 2003 16:46:09 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2H0iq7L2000314 for ; Mon, 17 Mar 2003 11:44:52 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2H0ipXk2002954 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 11:44:51 +1100 (EST) Date: Mon, 17 Mar 2003 11:44:51 +1100 (EST) From: Nathan Scott Message-Id: <200303170044.h2H0ipXk2002954@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - types X-archive-position: 3218 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 432 Lines: 16 Find more appropriate homes for uuid_t, timespec_t and xfs_dirent_t defs. Date: Sun Mar 16 16:44:06 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141837a linux/fs/xfs/xfs_types.h - 1.67 linux/fs/xfs/linux/xfs_linux.h - 1.102 linux/fs/xfs/support/uuid.h - 1.8 linux/fs/xfs/support/time.h - 1.10 From owner-linux-xfs@oss.sgi.com Sun Mar 16 17:46:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 17:47:05 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H1kxq9027782 for ; Sun, 16 Mar 2003 17:46:59 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2H1krnH006628 for ; Sun, 16 Mar 2003 17:46:53 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2H1ja7L2005420 for ; Mon, 17 Mar 2003 12:45:36 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2H1jZ5w2003739 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 12:45:35 +1100 (EST) Date: Mon, 17 Mar 2003 12:45:35 +1100 (EST) From: Nathan Scott Message-Id: <200303170145.h2H1jZ5w2003739@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - minor iops.c cleanup X-archive-position: 3219 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 463 Lines: 15 Remove unneeded initialisations to zero, formatting cleanups, remove a no-longer-correct-comment, fix up symlink error path code, several minor changes to help keep this code a little more in sync with 2.5. Date: Sun Mar 16 16:58:22 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141838a linux/fs/xfs/linux/xfs_iops.c - 1.187 From owner-linux-xfs@oss.sgi.com Sun Mar 16 18:11:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 18:11:27 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H2BKq9028337 for ; Sun, 16 Mar 2003 18:11:25 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2H2BE9n028002 for ; Sun, 16 Mar 2003 18:11:14 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2H29v7L2002809 for ; Mon, 17 Mar 2003 13:09:57 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2H29vOJ2005685 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 13:09:57 +1100 (EST) Date: Mon, 17 Mar 2003 13:09:57 +1100 (EST) From: Nathan Scott Message-Id: <200303170209.h2H29vOJ2005685@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - minor header shuffling X-archive-position: 3220 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 482 Lines: 17 Minor header shuffling, removing a bunch of already-included files and allowing 2.4/2.5 to be slightly more in sync. Date: Sun Mar 16 17:55:13 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141841a linux/fs/xfs/linux/xfs_lrw.h - 1.33 linux/fs/xfs/linux/xfs_lrw.c - 1.181 linux/fs/xfs/linux/xfs_file.c - 1.87 linux/fs/xfs/linux/xfs_aops.c - 1.28 From owner-linux-xfs@oss.sgi.com Sun Mar 16 18:24:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 18:24:04 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H2NLq9028862 for ; Sun, 16 Mar 2003 18:24:02 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2H2YQkq028695 for ; Sun, 16 Mar 2003 20:34:27 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2H2Lw7L2008916 for ; Mon, 17 Mar 2003 13:21:58 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2H2LwD12004996 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 13:21:58 +1100 (EST) Date: Mon, 17 Mar 2003 13:21:58 +1100 (EST) From: Nathan Scott Message-Id: <200303170221.h2H2LwD12004996@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - ioctl permissions X-archive-position: 3221 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 534 Lines: 16 Fix permission checks for some ioctls. Its now possible for ordinary users to use the preallocation calls if unwritten extents are enabled, and a couple of places where we were allowing operations if unwritten extents are enabled, but shouldn't have been, have been closed up. Date: Sun Mar 16 18:18:19 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141842a linux/fs/xfs/linux/xfs_ioctl.c - 1.88 From owner-linux-xfs@oss.sgi.com Sun Mar 16 19:00:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 19:00:09 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H301q9031042 for ; Sun, 16 Mar 2003 19:00:02 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2H3B2kq029146 for ; Sun, 16 Mar 2003 21:11:07 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2H2wY7L1985727 for ; Mon, 17 Mar 2003 13:58:34 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2H2wX922010952 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 13:58:33 +1100 (EST) Date: Mon, 17 Mar 2003 13:58:33 +1100 (EST) From: Nathan Scott Message-Id: <200303170258.h2H2wX922010952@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - iget+init code tidyup X-archive-position: 3222 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 725 Lines: 22 Move some of the Linux-specific iget code out of the XFS core code, move some of the initialisation code to a better spot (super.c -> vfs.c), fix up some whitespace abuse and some more code formatting inconsistencies, esp. in xfs_vnode.c and xfs_vfs.c. Date: Sun Mar 16 18:46:55 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141844a linux/fs/xfs/xfs_vfsops.c - 1.409 linux/fs/xfs/xfs_iget.c - 1.182 linux/fs/xfs/linux/xfs_vfs.c - 1.40 linux/fs/xfs/linux/xfs_vnode.c - 1.110 linux/fs/xfs/linux/xfs_super.h - 1.39 linux/fs/xfs/linux/xfs_super.c - 1.243 linux/fs/xfs/linux/xfs_vfs.h - 1.34 From owner-linux-xfs@oss.sgi.com Sun Mar 16 19:09:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 19:09:57 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H39Aq9031534 for ; Sun, 16 Mar 2003 19:09:51 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2H3949n030895 for ; Sun, 16 Mar 2003 19:09:05 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2H37m7L2008266 for ; Mon, 17 Mar 2003 14:07:48 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2H37mYJ2006915 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 14:07:48 +1100 (EST) Date: Mon, 17 Mar 2003 14:07:48 +1100 (EST) From: Nathan Scott Message-Id: <200303170307.h2H37mYJ2006915@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - bmap man page X-archive-position: 3223 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 465 Lines: 16 Remove an incorrect statement from the xfs_bmap(8) man page. Date: Sun Mar 16 19:07:16 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:141845a cmd/xfsprogs/man/man8/xfs_bmap.8 - 1.3 - Remove an incorrect statement from the xfs_bmap(8) man page - we have done a filesystem-type check before issuing any ioctls for some time. From owner-linux-xfs@oss.sgi.com Sun Mar 16 19:17:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 19:17:34 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H3HOq9031987 for ; Sun, 16 Mar 2003 19:17:24 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2H3HH9n031258 for ; Sun, 16 Mar 2003 19:17:18 -0800 Received: from elmo.melbourne.sgi.com (elmo.melbourne.sgi.com [134.14.55.238]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA28013; Mon, 17 Mar 2003 14:16:01 +1100 Received: from elmo.melbourne.sgi.com (localhost [127.0.0.1]) by elmo.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id OAA01629; Mon, 17 Mar 2003 14:16:00 +1100 (AEDT) Message-Id: <200303170316.OAA01629@elmo.melbourne.sgi.com> X-Mailer: exmh version 2.5 05/28/2002 with nmh-1.0.4 To: "l.a walsh" cc: linux-xfs@oss.sgi.com Subject: Re: extsize in data? In-Reply-To: Message from "l.a walsh" of "Sat, 15 Mar 2003 13:05:00 -0800." <001501c2eb36$8cacee60$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Mar 2003 14:16:00 +1100 From: Daniel Moore X-archive-position: 3224 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: dxm@elmo.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1565 Lines: 35 "l.a walsh" writes: => I notice you can specify extent sizes as a sub-option to the realtime => section, but it doesn't seem to be an option for the normal data => subsection....a bit of a bummer. Is there a reason why? With a maximum => block size of 4k (assuming the man page about linux limitations to page => size are still accurate and assuming, I think, Linux uses a 4k pagesize) an => d => 64K max extent, that's 256k. The real time partition generally uses much larger datablocks and uses a different allocation scheme to ensure fast access to blocks. There's no option to set extent size on a normal XFS filesystem because XFS tries to allocate your files in as large extents as possible (using delayed allocation). How effective this is depends on the write patterns, preallocation and free space/fragmentation on your disk. Try out 'xfs_bmap' on a file to see how it's actually layed out in extents. => Many of my files are > 256k, on one of my larger disks, >15000 files. => => Is this a temporary limitation or is this sorta a fixed quality of => the fs? IRIX allows FSB sizes between 512 bytes and 64k. Linux XFS only allows <= PAGE_SIZE FSB sizes due to a limitiation of the linux memory allocator which would make support for large block sizes inefficient. ------------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Australian Software Group Fax: +61-3-98132378 ------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Sun Mar 16 20:29:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 20:29:50 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H4Tgq9002083 for ; Sun, 16 Mar 2003 20:29:43 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2H4Ta9n002177 for ; Sun, 16 Mar 2003 20:29:37 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA28555; Mon, 17 Mar 2003 15:28:20 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id PAA74364; Mon, 17 Mar 2003 15:28:19 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2H4PVom000892; Mon, 17 Mar 2003 15:25:31 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2H4PULd000890; Mon, 17 Mar 2003 15:25:30 +1100 Date: Mon, 17 Mar 2003 15:25:30 +1100 From: Nathan Scott To: Antonio Ciorri Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: Quota enable & disable. Message-ID: <20030317042530.GA855@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 3225 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 703 Lines: 22 On Fri, Mar 14, 2003 at 01:02:48PM -0600, Antonio Ciorri wrote: > Using quotas on our file systems: > > - We automatically enable the user quota enforcer in a file system when > mounting with flag usrquota. > - When the enforcer has to be disabled, we send a quotactl cmd with the > option Q_XQUOTAOFF, later on when trying to enforce user quota, we have > tried two ways: As suggested, it sounds like you should use Q_XQUOTAON and change state from ENFD (quota enforced) to ACCT (accounting only). Using Q_XQUOTAOFF results in the complete quota state for the filesystem being tossed, and a quotacheck (expensive) will need to be done during the next mount with quota enabled. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Mar 16 20:34:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 20:34:38 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H4Yaq9002659 for ; Sun, 16 Mar 2003 20:34:36 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2H4YT9n002468 for ; Sun, 16 Mar 2003 20:34:30 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA28604; Mon, 17 Mar 2003 15:33:13 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id PAA51199; Mon, 17 Mar 2003 15:33:13 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2H4UPom000929; Mon, 17 Mar 2003 15:30:25 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2H4UO4x000927; Mon, 17 Mar 2003 15:30:24 +1100 Date: Mon, 17 Mar 2003 15:30:24 +1100 From: Nathan Scott To: "DICKENS,CARY (HP-Loveland,ex2)" Cc: "'Antonio Ciorri'" , "'linux-xfs@oss.sgi.com'" Subject: Re: Quota enable & disable. Message-ID: <20030317043024.GB855@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 3226 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 979 Lines: 30 hi, On Fri, Mar 14, 2003 at 06:45:28PM -0500, DICKENS,CARY (HP-Loveland,ex2) wrote: > Antonio, > > I'm no expert, but I have been able to turn enforcement on and off without > any problems. I can't remember when it happened, but there were some > changes to the quota system that made it impossible to remount a volume and > turn quotas on. Earlier xfs versions allowed this, the current versions do Enabling quota during remount has never been implemented in XFS. > not. The volume in question must be mounted with quotas enabled and then > you toggle enforcement on and off. *nod* > What mount options do you use? I know that I _might_ want to have quotas on > a file volume I am using, so I mount it with the following quota options: > quota,qnoenforce,grpquota,gqnoenforce Your *noenforce options will be ignored because you have also given the enforce options (quota,grpquota). I think what you intended was just "uqnoenforce,gqnoenforce". cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Mar 16 22:19:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 22:19:16 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H6J9q9004075 for ; Sun, 16 Mar 2003 22:19:09 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2H6J29n008068 for ; Sun, 16 Mar 2003 22:19:03 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2H6Hk7L1768763 for ; Mon, 17 Mar 2003 17:17:46 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2H6HkMo2032311 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 17:17:46 +1100 (EST) Date: Mon, 17 Mar 2003 17:17:46 +1100 (EST) From: Nathan Scott Message-Id: <200303170617.h2H6HkMo2032311@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota/dmapi layering rejigged X-archive-position: 3227 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2936 Lines: 74 Separates the quota source into its own subdirectory ala dmapi. Pushes a bunch of quota- and dmapi-specific code down into these subdirs which previously was compiled into the core XFS code, and don't descend into these subdirs if options config'd off. cheers. Date: Sun Mar 16 22:02:57 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141850a linux/fs/xfs/quota/xfs_qm_bhv.c - 1.1 linux/fs/xfs/quota/xfs_qm_stats.h - 1.1 linux/fs/xfs/quota/xfs_qm_stats.c - 1.1 linux/fs/xfs/dmapi/dmapi_xfs.c - 1.1 linux/fs/xfs/quota/Makefile - 1.1 linux/fs/xfs/xfs_trans_dquot.c 1.41 renamed to linux/fs/xfs/quota/xfs_trans_dquot.c 1.1 linux/fs/xfs/xfsidbg.c - 1.215 linux/fs/xfs/xfs_quota_priv.h 1.24 renamed to linux/fs/xfs/quota/xfs_quota_priv.h 1.1 linux/fs/xfs/xfs_vnodeops.c - 1.586 linux/fs/xfs/xfs_dqblk.h - 1.9 linux/fs/xfs/xfs_dmapi.h - 1.35 linux/fs/xfs/Makefile - 1.154 linux/fs/xfs/xfs_qm_syscalls.c 1.74 renamed to linux/fs/xfs/quota/xfs_qm_syscalls.c 1.1 linux/fs/xfs/xfs_log_recover.c - 1.260 linux/fs/xfs/xfs_dquot_item.h 1.9 renamed to linux/fs/xfs/quota/xfs_dquot_item.h 1.1 linux/fs/xfs/xfs_dquot_item.c 1.34 renamed to linux/fs/xfs/quota/xfs_dquot_item.c 1.1 linux/fs/xfs/xfs_vfsops.c - 1.410 linux/fs/xfs/xfs_iget.c - 1.183 linux/fs/xfs/xfs_bmap_btree.c - 1.134 linux/fs/xfs/xfs_dquot.h 1.23 renamed to linux/fs/xfs/quota/xfs_dquot.h 1.1 linux/fs/xfs/xfs_dquot.c 1.74 renamed to linux/fs/xfs/quota/xfs_dquot.c 1.1 linux/fs/xfs/xfs_mount.h - 1.167 linux/fs/xfs/xfs_mount.c - 1.321 linux/fs/xfs/xfs_qm.h 1.27 renamed to linux/fs/xfs/quota/xfs_qm.h 1.1 linux/fs/xfs/xfs_qm.c 1.95 renamed to linux/fs/xfs/quota/xfs_qm.c 1.1 linux/fs/xfs/xfs_trans.c - 1.141 linux/fs/xfs/xfs_utils.c - 1.58 linux/fs/xfs/xfs_bmap.c - 1.301 linux/fs/xfs/xfs_quota.h - 1.30 linux/fs/xfs/xfs_rename.c - 1.48 linux/fs/xfs/xfs_attr.c - 1.102 linux/fs/xfs/linux/xfs_lrw.c - 1.182 linux/fs/xfs/linux/xfs_vfs.c - 1.41 linux/fs/xfs/linux/xfs_globals.c - 1.42 linux/fs/xfs/linux/xfs_file.c - 1.88 linux/fs/xfs/linux/xfs_super.h - 1.40 linux/fs/xfs/linux/xfs_super.c - 1.244 linux/fs/xfs/dmapi/dmapi_private.h - 1.9 linux/fs/xfs/linux/xfs_globals.h - 1.15 linux/fs/xfs/xfs.h - 1.35 linux/fs/xfs/linux/xfs_vfs.h - 1.36 linux/fs/xfs/linux/xfs_stats.c - 1.10 linux/fs/xfs/linux/xfs_stats.h - 1.6 linux/fs/xfs/dmapi/dmapi.h - 1.2 linux/fs/xfs/linux/xfs_iomap.c - 1.7 linux/fs/xfs/xfs_dmops.c - 1.2 linux/fs/xfs/xfs_qmops.c - 1.3 - Separate the quota source into its own subdirectory ala dmapi. Push a bunch of quota- and dmapi-specific code down into these subdirs which previously was compiled into the core XFS code, and don't descend into these subdirs if options config'd off. linux/fs/xfs/dmapi/Makefile - 1.19 linux/fs/xfs/dmapi/dmapi_mountinfo.c - 1.13 linux/fs/xfs/dmapi/dmapi_sysent.c - 1.20 - Trivial cleanup. From owner-linux-xfs@oss.sgi.com Sun Mar 16 23:39:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Mar 2003 23:39:17 -0800 (PST) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H7cTq9004856 for ; Sun, 16 Mar 2003 23:39:09 -0800 Received: from erbenson.alaska.net (110-pm14.nwc.alaska.net [209.112.141.110]) by iris.acsalaska.net (8.12.8/8.12.8) with ESMTP id h2H7cRB4084300 for ; Sun, 16 Mar 2003 22:38:27 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 75B433A0B for ; Sun, 16 Mar 2003 22:38:24 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 607C84104E2; Sun, 16 Mar 2003 22:38:24 -0900 (AKST) Date: Sun, 16 Mar 2003 22:38:24 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: [PATCH] libdisk: add check for Mac (Apple) partition tables Message-ID: <20030317073824.GA1079@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 3228 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: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 2895 Lines: 101 --cvVnyQ+4j833TQvp Content-Type: multipart/mixed; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable mkfs.xfs checks for known filesystems and partition types so it can warn the user if they may be overwriting existing data, this check does not include Apple partition tables. the following patch adds a check for mac partition tables to libdisk. i have tested it on both big and little endian systems, it works as expected. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfs_libdisk.diff" Content-Transfer-Encoding: quoted-printable Index: libdisk/pttype.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/linux-2.4-xfs/cmd/xfsprogs/libdisk/pttype.c,v retrieving revision 1.5 diff -u -r1.5 pttype.c --- libdisk/pttype.c 12 Nov 2002 04:01:08 -0000 1.5 +++ libdisk/pttype.c 17 Mar 2003 07:34:38 -0000 @@ -93,6 +93,14 @@ return !csum; } =20 +static int +mac_parttable(char *base) +{ + return (ntohs(maclabel(base)->magic) =3D=3D MAC_LABEL_MAGIC || + ntohs(maclabel(base)->magic) =3D=3D MAC_PARTITION_MAGIC || + ntohs(maclabel(base)->magic) =3D=3D MAC_OLD_PARTITION_MAGIC); +} + =20 char * pttype(char *device) @@ -114,6 +122,8 @@ type =3D "AIX"; else if (dos_parttable(buf)) type =3D "DOS"; + else if (mac_parttable(buf)) + type =3D "Mac"; } =20 if (fd >=3D 0) Index: libdisk/pttype.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/linux-2.4-xfs/cmd/xfsprogs/libdisk/pttype.h,v retrieving revision 1.2 diff -u -r1.2 pttype.h --- libdisk/pttype.h 12 Nov 2002 04:01:08 -0000 1.2 +++ libdisk/pttype.h 17 Mar 2003 07:34:38 -0000 @@ -39,3 +39,13 @@ #define AIX_LABEL_MAGIC 0xc9c2d4c1 #define AIX_LABEL_MAGIC_SWAPPED 0xc1d4c2c9 #define aixlabel(x) ((aix_partition *)x) + +typedef struct { + unsigned short magic; + /* ... */ +} mac_partition; + +#define MAC_LABEL_MAGIC 0x4552 +#define MAC_PARTITION_MAGIC 0x504d +#define MAC_OLD_PARTITION_MAGIC 0x5453 +#define maclabel(x) ((mac_partition *)x) --mP3DRpeJDSE+ciuQ-- --cvVnyQ+4j833TQvp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj51e3AACgkQJKx7GixEevx7CgCeIvK9ZmXZdpjs0dgKgOb2sUQT X8QAn2pBHvorAFTgeoSOrkTACTlk4gXT =dydj -----END PGP SIGNATURE----- --cvVnyQ+4j833TQvp-- From owner-linux-xfs@oss.sgi.com Mon Mar 17 00:22:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 00:22:57 -0800 (PST) Received: from hermod.slb.nwc.acsalaska.net (hermod.slb.nwc.acsalaska.net [209.112.155.45]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H8M7q9014921 for ; Mon, 17 Mar 2003 00:22:48 -0800 Received: from erbenson.alaska.net (110-pm14.nwc.alaska.net [209.112.141.110]) by hermod.slb.nwc.acsalaska.net (8.12.8/8.12.8) with ESMTP id h2H8M5i1052434 for ; Sun, 16 Mar 2003 23:22:06 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id AD4E93A0B for ; Sun, 16 Mar 2003 23:22:04 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 517864104E2; Sun, 16 Mar 2003 23:22:04 -0900 (AKST) Date: Sun, 16 Mar 2003 23:22:04 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: [PATCH] libdisk: fix broken HFS filesystem check Message-ID: <20030317082204.GC1079@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GdbWtwDHkcXqP16f" Content-Disposition: inline User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 3229 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: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 1783 Lines: 60 --GdbWtwDHkcXqP16f Content-Type: multipart/mixed; boundary="m1UC1K4AOz1Ywdkx" Content-Disposition: inline --m1UC1K4AOz1Ywdkx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable the test for HFS filesystems is broken, the attached patch fixes it. also the endianess handling in this file appears to be completly insane, but i am not going to address this issue... --=20 Ethan Benson http://www.alaska.net/~erbenson/ --m1UC1K4AOz1Ywdkx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="fstype.c.diff" Content-Transfer-Encoding: quoted-printable Index: libdisk/fstype.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/linux-2.4-xfs/cmd/xfsprogs/libdisk/fstype.c,v retrieving revision 1.5 diff -u -r1.5 fstype.c --- libdisk/fstype.c 28 Aug 2002 22:31:45 -0000 1.5 +++ libdisk/fstype.c 17 Mar 2003 08:19:54 -0000 @@ -313,7 +313,7 @@ if ((hfsmagic(hfssb) =3D=3D HFS_SUPER_MAGIC && hfsblksize(hfssb) =3D=3D 0x20000) || (swapped(hfsmagic(hfssb)) =3D=3D HFS_SUPER_MAGIC && - hfsblksize(hfssb) =3D=3D 0x200)) + hfsblksize(hfssb) =3D=3D 0x20000)) type =3D "hfs"; } =20 --m1UC1K4AOz1Ywdkx-- --GdbWtwDHkcXqP16f Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj51hawACgkQJKx7GixEevw53ACdEyJ1yn2q9kvxmnQlHcd17tyE wI0AoJGatm9Wg3Ja25hiGYLO39bUl7E7 =Q43C -----END PGP SIGNATURE----- --GdbWtwDHkcXqP16f-- From owner-linux-xfs@oss.sgi.com Mon Mar 17 00:44:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 00:44:20 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H8iBq9015528 for ; Mon, 17 Mar 2003 00:44:13 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18uqE4-0000zB-00 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 08:44:08 +0000 Date: Mon, 17 Mar 2003 08:44:08 +0000 From: Christoph Hellwig To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] libdisk: fix broken HFS filesystem check Message-ID: <20030317084407.A3766@infradead.org> References: <20030317082204.GC1079@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030317082204.GC1079@plato.local.lan>; from erbenson@alaska.net on Sun, Mar 16, 2003 at 11:22:04PM -0900 X-archive-position: 3230 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: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 403 Lines: 10 On Sun, Mar 16, 2003 at 11:22:04PM -0900, Ethan Benson wrote: > > the test for HFS filesystems is broken, the attached patch fixes it. > > also the endianess handling in this file appears to be completly > insane, but i am not going to address this issue... fstype.c is taken verbatim from the mount source in util-linux. Please submit a patch to Andries and drop us a note to resync once it's in. From owner-linux-xfs@oss.sgi.com Mon Mar 17 08:21:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 08:21:56 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2HGLlq9027548 for ; Mon, 17 Mar 2003 08:21:47 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2HGLlQk027545 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 08:21:47 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2HGLiqB027531 for ; Mon, 17 Mar 2003 08:21:44 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2HG1dr2027357; Mon, 17 Mar 2003 08:01:39 -0800 Date: Mon, 17 Mar 2003 08:01:39 -0800 Message-Id: <200303171601.h2HG1dr2027357@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-archive-position: 3231 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 431 Lines: 18 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From cattelan@thebarn.com 2003-03-17 08:01 ------- Argghh this bit of code again! XFS_log_write_unmount_ro Calls 3 times... can you toss in some printk's in to find out which of the 3 calls is hanging, dump the pincount also. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Mar 17 09:21:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 09:21:50 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2HHLjq9001374 for ; Mon, 17 Mar 2003 09:21:45 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2HHLjxL001372 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 09:21:45 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2HHLhqB001359 for ; Mon, 17 Mar 2003 09:21:44 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2HH7qtO001022; Mon, 17 Mar 2003 09:07:52 -0800 Date: Mon, 17 Mar 2003 09:07:52 -0800 Message-Id: <200303171707.h2HH7qtO001022@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 231] New: XFS does not update directory mtime when changes made in directory X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3232 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1180 Lines: 35 http://oss.sgi.com/bugzilla/show_bug.cgi?id=231 Summary: XFS does not update directory mtime when changes made in directory Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: kpfleming@cox.net What kernel are you using: 2.5.64-bk7 Where did the XFS code come from? (CVS, Linus, your distribution, etc): Linus Description of Problem: Create a directory on an XFS filesystem. stat the directory and note the mtime and ctime. touch a file in the directory (creating a new file). stat the directory again. The ctime will have been updated, but not the mtime. "sync" has no effect. Repeatedly creating/removing files and/or directories will _sometimes_ update the mtime, but when it does update it changes to a time still in the past, not the time of the most recent change in the directory. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Mar 17 14:21:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 14:21:51 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2HMLkq9011644 for ; Mon, 17 Mar 2003 14:21:46 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2HMLkZi011642 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 14:21:46 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2HMLiqB011629 for ; Mon, 17 Mar 2003 14:21:44 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2HLO2dF011208; Mon, 17 Mar 2003 13:24:02 -0800 Date: Mon, 17 Mar 2003 13:24:02 -0800 Message-Id: <200303172124.h2HLO2dF011208@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 232] New: mkfs.xfs from xfsprogs-2.3.5 fails on 1.1TB partition X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3233 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1589 Lines: 61 http://oss.sgi.com/bugzilla/show_bug.cgi?id=232 Summary: mkfs.xfs from xfsprogs-2.3.5 fails on 1.1TB partition Product: Linux XFS Version: 1.2.x Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: High Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: yocum@fnal.gov If this is a userspace bug, what version of the package are you using: xfsprogs-2.3.5 What kernel are you using: RH2.4.18-18 w/ xfs1.2 Where did the XFS code come from? (CVS, Linus, your distribution, etc): SGI Description of Problem: # mkfs.xfs -f -i size /dev/md0 log stripe unit (4194304 bytes) is too large for kernel to handle (max 256k) Downgrading to v2.0.1 allows me to mkfs.xfs How Reproducible: Every time, multiple machines. Steps to Reproduce: 1. git yerself a 1.1TB box... 2. install xfsprogs 2.3.5 3. try to mkfs.xfs Actual Results: See above. Expected Results: ]# mkfs.xfs -f /dev/md1 meta-data=/dev/md1 isize=256 agcount=266, agsize=1048576 blks data = bsize=4096 blocks=278605824, imaxpct=25 = sunit=1024 swidth=2048 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768 realtime =none extsz=8388608 blocks=0, rtextents=0 Additional Information: Toodles, Dan ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Mar 17 14:42:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 14:42:34 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2HMgNq9012236 for ; Mon, 17 Mar 2003 14:42:25 -0800 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18v3HQ-0006HS-00 for ; Mon, 17 Mar 2003 23:40:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18v3AR-0005mW-00 for ; Mon, 17 Mar 2003 23:33:15 +0100 From: Nicholas Wourms Subject: What happened to the linux-2.4-xfs cvs tree? Date: Mon, 17 Mar 2003 17:31:04 -0500 Message-ID: <3E764CA8.5050404@myrealbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@main.gmane.org User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3234 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: nwourms@myrealbox.com Precedence: bulk X-list: linux-xfs Content-Length: 178 Lines: 9 Hi, I just went to pull the sources from the linux-2.4-xfs tree and I noticed it is gone for both cvs and cvsweb. Was this intentional? Will it be back? Cheers, Nicholas From owner-linux-xfs@oss.sgi.com Mon Mar 17 14:58:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 14:58:21 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2HMwHq9012771 for ; Mon, 17 Mar 2003 14:58:18 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2HMwB9n012501 for ; Mon, 17 Mar 2003 14:58:11 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA06332 for ; Tue, 18 Mar 2003 09:56:55 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id JAA13175 for ; Tue, 18 Mar 2003 09:56:54 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2HMs5SO000998 for ; Tue, 18 Mar 2003 09:54:05 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2HMs5hV000996 for linux-xfs@oss.sgi.com; Tue, 18 Mar 2003 09:54:05 +1100 Date: Tue, 18 Mar 2003 09:54:05 +1100 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] libdisk: add check for Mac (Apple) partition tables Message-ID: <20030317225405.GA948@frodo> References: <20030317073824.GA1079@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030317073824.GA1079@plato.local.lan> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3235 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 495 Lines: 18 On Sun, Mar 16, 2003 at 10:38:24PM -0900, Ethan Benson wrote: > > mkfs.xfs checks for known filesystems and partition types so it can > warn the user if they may be overwriting existing data, this check > does not include Apple partition tables. the following patch adds a > check for mac partition tables to libdisk. > > i have tested it on both big and little endian systems, it works as > expected. > Thanks Ethan - looks fine to me, I'll check it in later today. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Mar 17 15:21:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 15:21:49 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2HNLlq9013398 for ; Mon, 17 Mar 2003 15:21:47 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2HNLlmK013396 for linux-xfs@oss.sgi.com; Mon, 17 Mar 2003 15:21:47 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2HNLjqB013383 for ; Mon, 17 Mar 2003 15:21:45 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2HMnxEr012720; Mon, 17 Mar 2003 14:49:59 -0800 Date: Mon, 17 Mar 2003 14:49:59 -0800 Message-Id: <200303172249.h2HMnxEr012720@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3236 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 462 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From atu@dmeti.dp.ua 2003-03-17 14:49 ------- Hang observed while first call to pagebuf_delwri_flush from XFS_log_write_remount_ro, before loop, (in case of remount ro), and while single call to pagebuf_delwri_flush from XFS_bflush in case of umount. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Mar 17 15:33:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 15:33:34 -0800 (PST) Received: from mail.cnes.com (mail.cnes.com [208.179.92.38]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2HNXVq9013897 for ; Mon, 17 Mar 2003 15:33:32 -0800 Received: from oz.cnes.com (wall.cnes.com [208.179.92.60]) by mail.cnes.com (8.12.8/8.12.8) with ESMTP id h2HNXP0L021826 for ; Mon, 17 Mar 2003 15:33:25 -0800 Received: from localhost (localhost [127.0.0.1]) by oz.cnes.com (8.9.3/8.9.3) with ESMTP id PAA17059 for ; Mon, 17 Mar 2003 15:33:25 -0800 (PST) Date: Mon, 17 Mar 2003 15:33:25 -0800 From: Scott Jepson To: linux-xfs@oss.sgi.com Subject: xfs_fsr Seg faults Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3237 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: scott@cnes.com Precedence: bulk X-list: linux-xfs Content-Length: 2363 Lines: 60 Hi, I ran xfs_fsr when I had about 70 gigs of files in a 1 TB file system and all was fine. Since then we have added another 100 gigs of files and xfs_fsr Seg faults. Here's what i see in the logs: $ xfs_fsr /mnt/x3 /mnt/x3 start inode=0 Segmentation fault Mar 17 15:27:55 dragon kernel: <1>Unable to handle kernel paging request at virtual address 654b0911 Mar 17 15:27:55 dragon kernel: printing eip: Mar 17 15:27:55 dragon kernel: c01ef8a1 Mar 17 15:27:55 dragon kernel: *pde = 00000000 Mar 17 15:27:55 dragon kernel: Oops: 0000 Mar 17 15:27:55 dragon kernel: Mar 17 15:27:55 dragon kernel: CPU: 0 Mar 17 15:27:55 dragon kernel: EIP: 0010:[map_blocks+129/288] Not tainted Mar 17 15:27:55 dragon kernel: EIP: 0010:[] Not tainted Mar 17 15:27:55 dragon kernel: EFLAGS: 00010283 Mar 17 15:27:55 dragon kernel: eax: 654b0909 ebx: 00020002 ecx: f5859d84 edx: f66bb2e0 Mar 17 15:27:55 dragon kernel: esi: 00000000 edi: 00000000 ebp: 00000000 esp: f5859d7c Mar 17 15:27:55 dragon kernel: ds: 0018 es: 0018 ss: 0018 Mar 17 15:27:55 dragon kernel: Process xfs_fsr (pid: 709, stackpage=f5859000) Mar 17 15:27:55 dragon kernel: Stack: f5859d84 f66bb2e0 00000001 f66bb300 00000000 00000000 0001b000 c01f0e78 Mar 17 15:27:55 dragon kernel: f66bb300 00000000 00000000 0001b000 f5859df8 00020002 01080002 00020002 Mar 17 15:27:55 dragon kernel: 0804f000 f66bb2e0 f7127f80 00000000 00000000 0001b000 0001b000 00000000 Mar 17 15:27:55 dragon kernel: Call Trace: [linvfs_direct_IO+840/890] [map_user_kiobuf+180/256] [generic_file_direct_IO+423/544] [generic_file_write_nolock+1744/1904] [xfs_write+1012/1696] [xfs_read+411/464] [linvfs_wri te+177/240] [sys_write+150/272] [sys_ioctl+647/657] [system_call+51/56] Mar 17 15:27:55 dragon kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] Mar 17 15:27:55 dragon kernel: Code: 8b 50 08 51 8b 74 24 34 56 53 8b 4c 24 38 51 55 57 50 ff 52 Any ideas to the problem? Thanks, -Scott ---------------------------------------------------------------- Scott Jepson, Managing Partner Email: scott@cnes.com Creative Network Services, LLC http://www.cnes.com (310)470-6140 ---------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Mar 17 16:01:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 16:01:59 -0800 (PST) Received: from mail.cnes.com (mail.cnes.com [208.179.92.38]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2I01pq9014468 for ; Mon, 17 Mar 2003 16:01:52 -0800 Received: from oz.cnes.com (wall.cnes.com [208.179.92.60]) by mail.cnes.com (8.12.8/8.12.8) with ESMTP id h2I01k0L021986 for ; Mon, 17 Mar 2003 16:01:46 -0800 Received: from localhost (localhost [127.0.0.1]) by oz.cnes.com (8.9.3/8.9.3) with ESMTP id QAA17085 for ; Mon, 17 Mar 2003 16:01:46 -0800 (PST) Date: Mon, 17 Mar 2003 16:01:46 -0800 From: Scott Jepson To: linux-xfs@oss.sgi.com Subject: Re: xfs_fsr Seg faults In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3238 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: scott@cnes.com Precedence: bulk X-list: linux-xfs Content-Length: 3047 Lines: 81 Forgot: I'm running 2.4.20 with linux-2.4.20-xfs-2003-02-23.patch and the latest cmds from the CVS tree. -Scott ---------------------------------------------------------------- Scott Jepson, Managing Partner Email: scott@cnes.com Creative Network Services, LLC http://www.cnes.com (310)470-6140 ---------------------------------------------------------------- On Mon, 17 Mar 2003, Scott Jepson wrote: > Date: Mon, 17 Mar 2003 15:33:25 -0800 > From: Scott Jepson > To: linux-xfs@oss.sgi.com > Subject: xfs_fsr Seg faults > > Hi, > I ran xfs_fsr when I had about 70 gigs of files in a 1 TB file > system and all was fine. Since then we have added another 100 gigs of > files and xfs_fsr Seg faults. Here's what i see in the logs: > > $ xfs_fsr /mnt/x3 > /mnt/x3 start inode=0 > Segmentation fault > > Mar 17 15:27:55 dragon kernel: <1>Unable to handle kernel paging request > at virtual address 654b0911 > Mar 17 15:27:55 dragon kernel: printing eip: > Mar 17 15:27:55 dragon kernel: c01ef8a1 > Mar 17 15:27:55 dragon kernel: *pde = 00000000 > Mar 17 15:27:55 dragon kernel: Oops: 0000 > Mar 17 15:27:55 dragon kernel: > Mar 17 15:27:55 dragon kernel: CPU: 0 > Mar 17 15:27:55 dragon kernel: EIP: 0010:[map_blocks+129/288] Not > tainted > Mar 17 15:27:55 dragon kernel: EIP: 0010:[] Not tainted > Mar 17 15:27:55 dragon kernel: EFLAGS: 00010283 > Mar 17 15:27:55 dragon kernel: eax: 654b0909 ebx: 00020002 ecx: > f5859d84 edx: f66bb2e0 > Mar 17 15:27:55 dragon kernel: esi: 00000000 edi: 00000000 ebp: > 00000000 esp: f5859d7c > Mar 17 15:27:55 dragon kernel: ds: 0018 es: 0018 ss: 0018 > Mar 17 15:27:55 dragon kernel: Process xfs_fsr (pid: 709, > stackpage=f5859000) > Mar 17 15:27:55 dragon kernel: Stack: f5859d84 f66bb2e0 00000001 f66bb300 > 00000000 00000000 0001b000 c01f0e78 > Mar 17 15:27:55 dragon kernel: f66bb300 00000000 00000000 0001b000 > f5859df8 00020002 01080002 00020002 > Mar 17 15:27:55 dragon kernel: 0804f000 f66bb2e0 f7127f80 00000000 > 00000000 0001b000 0001b000 00000000 > Mar 17 15:27:55 dragon kernel: Call Trace: [linvfs_direct_IO+840/890] > [map_user_kiobuf+180/256] [generic_file_direct_IO+423/544] > [generic_file_write_nolock+1744/1904] [xfs_write+1012/1696] > [xfs_read+411/464] [linvfs_wri > te+177/240] [sys_write+150/272] [sys_ioctl+647/657] [system_call+51/56] > Mar 17 15:27:55 dragon kernel: Call Trace: [] [] > [] [] [] [] [] > [] [] [] > Mar 17 15:27:55 dragon kernel: Code: 8b 50 08 51 8b 74 24 34 56 53 8b 4c > 24 38 51 55 57 50 ff 52 > > Any ideas to the problem? > > Thanks, > > -Scott > > > > > ---------------------------------------------------------------- > Scott Jepson, Managing Partner Email: scott@cnes.com > Creative Network Services, LLC http://www.cnes.com > (310)470-6140 > ---------------------------------------------------------------- > > > From owner-linux-xfs@oss.sgi.com Mon Mar 17 16:42:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 16:43:01 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2I0gsq9015336 for ; Mon, 17 Mar 2003 16:42:55 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2I0s2kq026006 for ; Mon, 17 Mar 2003 18:54:03 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2I0fV7L2095887 for ; Tue, 18 Mar 2003 11:41:31 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2I0fUFj2101716 for linux-xfs@oss.sgi.com; Tue, 18 Mar 2003 11:41:30 +1100 (EST) Date: Tue, 18 Mar 2003 11:41:30 +1100 (EST) From: Nathan Scott Message-Id: <200303180041.h2I0fUFj2101716@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - misc minor cleanup X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3239 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2505 Lines: 99 Keep 2.4 and 2.5 get_inode implementations a bit more in sync (wrt flags). Date: Sun Mar 16 19:36:27 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141847a linux/fs/xfs/linux/xfs_vnode.c - 1.111 linux/fs/xfs/linux/xfs_vfs.h - 1.35 Merge change back from 2.5 - need to include init.h for __init/__exit. Date: Sun Mar 16 23:11:13 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141855a linux/fs/xfs/quota/xfs_qm_bhv.c - 1.2 linux/fs/xfs/dmapi/dmapi_xfs.c - 1.2 Remove xfs_dmapi.c - this now lives below fs/xfs/dmapi, effectively. Date: Mon Mar 17 15:02:58 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141911a linux/fs/xfs/xfs_dmapi.c - 1.91 Cleanup/remove a bunch of macros, comments and code. Date: Mon Mar 17 16:39:31 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141925a linux/fs/xfs/xfsidbg.c - 1.216 - Cleanup some of the vnode flags, remove use of bogus macros, extend the vnode command with a couple more fields. linux/fs/xfs/xfs_iocore.c - 1.39 - Remove several unused macros. linux/fs/xfs/xfs_iget.c - 1.184 - Refine a comment. linux/fs/xfs/xfs_clnt.h - 1.37 - Remove several unused macros and some unused fields from mount_args. linux/fs/xfs/xfs_inode.h - 1.177 - Remove several unused macros. linux/fs/xfs/xfs_trans.h - 1.117 - Remove an unused macro and forward declarations of several routines which do not actually exist. linux/fs/xfs/xfs_bmap.h - 1.79 - Remove an unused XFS_BMAPI flag. linux/fs/xfs/linux/xfs_globals.c - 1.43 linux/fs/xfs/linux/xfs_globals.h - 1.16 linux/fs/xfs/support/atomic.h - 1.7 - Rename Atomic_spin to xfs_atomic_spin. linux/fs/xfs/support/debug.c - 1.20 - Refine macro magic around random routine to allow it to be compiled out more easily. linux/fs/xfs/support/mutex.h - 1.10 - Remove second, different and unused mutex initialisation macro. linux/fs/xfs/support/mrlock.h - 1.8 linux/fs/xfs/support/mrlock.c - 1.13 - Turn a couple of routines into macros rather than routines. From owner-linux-xfs@oss.sgi.com Mon Mar 17 16:49:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 16:49:59 -0800 (PST) Received: from mail.cnes.com (mail.cnes.com [208.179.92.38]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2I0ntq9016352 for ; Mon, 17 Mar 2003 16:49:55 -0800 Received: from oz.cnes.com (wall.cnes.com [208.179.92.60]) by mail.cnes.com (8.12.8/8.12.8) with ESMTP id h2I0no0L022305 for ; Mon, 17 Mar 2003 16:49:50 -0800 Received: from localhost (localhost [127.0.0.1]) by oz.cnes.com (8.9.3/8.9.3) with ESMTP id QAA17127 for ; Mon, 17 Mar 2003 16:49:49 -0800 (PST) Date: Mon, 17 Mar 2003 16:49:49 -0800 From: Scott Jepson To: linux-xfs@oss.sgi.com Subject: Re: xfs_fsr Seg faults In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3241 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: scott@cnes.com Precedence: bulk X-list: linux-xfs Content-Length: 3828 Lines: 103 Hmmmm... I think it might have found a fix. It looks like someone else had the problem and opened a bug report [Bug 195]. I will have to check it out. -Scott ---------------------------------------------------------------- Scott Jepson, Managing Partner Email: scott@cnes.com Creative Network Services, LLC http://www.cnes.com (310)470-6140 ---------------------------------------------------------------- On Mon, 17 Mar 2003, Scott Jepson wrote: > Date: Mon, 17 Mar 2003 16:01:46 -0800 > From: Scott Jepson > To: linux-xfs@oss.sgi.com > Subject: Re: xfs_fsr Seg faults > > Forgot: I'm running 2.4.20 with linux-2.4.20-xfs-2003-02-23.patch > and the latest cmds from the CVS tree. > > -Scott > > ---------------------------------------------------------------- > Scott Jepson, Managing Partner Email: scott@cnes.com > Creative Network Services, LLC http://www.cnes.com > (310)470-6140 > ---------------------------------------------------------------- > > On Mon, 17 Mar 2003, Scott Jepson wrote: > > > Date: Mon, 17 Mar 2003 15:33:25 -0800 > > From: Scott Jepson > > To: linux-xfs@oss.sgi.com > > Subject: xfs_fsr Seg faults > > > > Hi, > > I ran xfs_fsr when I had about 70 gigs of files in a 1 TB file > > system and all was fine. Since then we have added another 100 gigs of > > files and xfs_fsr Seg faults. Here's what i see in the logs: > > > > $ xfs_fsr /mnt/x3 > > /mnt/x3 start inode=0 > > Segmentation fault > > > > Mar 17 15:27:55 dragon kernel: <1>Unable to handle kernel paging request > > at virtual address 654b0911 > > Mar 17 15:27:55 dragon kernel: printing eip: > > Mar 17 15:27:55 dragon kernel: c01ef8a1 > > Mar 17 15:27:55 dragon kernel: *pde = 00000000 > > Mar 17 15:27:55 dragon kernel: Oops: 0000 > > Mar 17 15:27:55 dragon kernel: > > Mar 17 15:27:55 dragon kernel: CPU: 0 > > Mar 17 15:27:55 dragon kernel: EIP: 0010:[map_blocks+129/288] Not > > tainted > > Mar 17 15:27:55 dragon kernel: EIP: 0010:[] Not tainted > > Mar 17 15:27:55 dragon kernel: EFLAGS: 00010283 > > Mar 17 15:27:55 dragon kernel: eax: 654b0909 ebx: 00020002 ecx: > > f5859d84 edx: f66bb2e0 > > Mar 17 15:27:55 dragon kernel: esi: 00000000 edi: 00000000 ebp: > > 00000000 esp: f5859d7c > > Mar 17 15:27:55 dragon kernel: ds: 0018 es: 0018 ss: 0018 > > Mar 17 15:27:55 dragon kernel: Process xfs_fsr (pid: 709, > > stackpage=f5859000) > > Mar 17 15:27:55 dragon kernel: Stack: f5859d84 f66bb2e0 00000001 f66bb300 > > 00000000 00000000 0001b000 c01f0e78 > > Mar 17 15:27:55 dragon kernel: f66bb300 00000000 00000000 0001b000 > > f5859df8 00020002 01080002 00020002 > > Mar 17 15:27:55 dragon kernel: 0804f000 f66bb2e0 f7127f80 00000000 > > 00000000 0001b000 0001b000 00000000 > > Mar 17 15:27:55 dragon kernel: Call Trace: [linvfs_direct_IO+840/890] > > [map_user_kiobuf+180/256] [generic_file_direct_IO+423/544] > > [generic_file_write_nolock+1744/1904] [xfs_write+1012/1696] > > [xfs_read+411/464] [linvfs_wri > > te+177/240] [sys_write+150/272] [sys_ioctl+647/657] [system_call+51/56] > > Mar 17 15:27:55 dragon kernel: Call Trace: [] [] > > [] [] [] [] [] > > [] [] [] > > Mar 17 15:27:55 dragon kernel: Code: 8b 50 08 51 8b 74 24 34 56 53 8b 4c > > 24 38 51 55 57 50 ff 52 > > > > Any ideas to the problem? > > > > Thanks, > > > > -Scott > > > > > > > > > > ---------------------------------------------------------------- > > Scott Jepson, Managing Partner Email: scott@cnes.com > > Creative Network Services, LLC http://www.cnes.com > > (310)470-6140 > > ---------------------------------------------------------------- > > > > > > > > > From owner-linux-xfs@oss.sgi.com Mon Mar 17 16:49:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 16:49:48 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2I0njq9016312 for ; Mon, 17 Mar 2003 16:49:46 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2I0ndnH004150 for ; Mon, 17 Mar 2003 16:49:39 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA07573; Tue, 18 Mar 2003 11:48:22 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA00989; Tue, 18 Mar 2003 11:48:21 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2I0jVSO001780; Tue, 18 Mar 2003 11:45:31 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2I0jUfo001778; Tue, 18 Mar 2003 11:45:30 +1100 Date: Tue, 18 Mar 2003 11:45:30 +1100 From: Nathan Scott To: Nicholas Wourms Cc: linux-xfs@oss.sgi.com Subject: Re: What happened to the linux-2.4-xfs cvs tree? Message-ID: <20030318004530.GC948@frodo> References: <3E764CA8.5050404@myrealbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E764CA8.5050404@myrealbox.com> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3240 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 536 Lines: 20 On Mon, Mar 17, 2003 at 05:31:04PM -0500, Nicholas Wourms wrote: > Hi, > > I just went to pull the sources from the linux-2.4-xfs tree > and I noticed it is gone for both cvs and cvsweb. Was this > intentional? Will it be back? > Pfft - not sure what's happened there. I sure hope it comes back, we'll probably have to wait for Russell to do his magic though. The latest commands code is also mirrored below the 2.5.x-xfs part of the CVS tree, so you can at least still get access to that in the interim. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Mar 17 21:34:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 21:34:23 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2I5YCq9003459 for ; Mon, 17 Mar 2003 21:34:13 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2I5jMkq032416 for ; Mon, 17 Mar 2003 23:45:22 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id XAA08571 for ; Mon, 17 Mar 2003 23:34:06 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2I5Y6wX30194781 for ; Mon, 17 Mar 2003 23:34:06 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h2I5XJg31921; Mon, 17 Mar 2003 23:33:19 -0600 Message-Id: <200303180533.h2I5XJg31921@stout.americas.sgi.com> Date: Mon, 17 Mar 2003 23:33:19 -0600 Subject: TAKE - Fix up repair a bit for realtime. X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3242 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 529 Lines: 17 (I still can't repair the realtime fs breakage I have, but this is part of the fix). Remove do_error after libxfs_device_zero, this is left over from when irix could return an error from dev_zero, the do_error was supposed to be in a conditional. Date: Mon Mar 17 21:33:14 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:141952a cmd/xfsprogs/repair/phase6.c - 1.13 From owner-linux-xfs@oss.sgi.com Mon Mar 17 21:47:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Mar 2003 21:47:35 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2I5lUq9003954 for ; Mon, 17 Mar 2003 21:47:31 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2I5wdkq032605 for ; Mon, 17 Mar 2003 23:58:40 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2I5k77L2168988 for ; Tue, 18 Mar 2003 16:46:07 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2I5k7iL2168801 for linux-xfs@oss.sgi.com; Tue, 18 Mar 2003 16:46:07 +1100 (EST) Date: Tue, 18 Mar 2003 16:46:07 +1100 (EST) From: Nathan Scott Message-Id: <200303180546.h2I5k7iL2168801@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3243 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1768 Lines: 62 Header shuffling to try and keep several source trees aligned - move the realtime inode detection macro somewhere more appropriate. Date: Mon Mar 17 21:31:02 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:141951a linux/fs/xfs/xfs_rtalloc.h - 1.23 linux/fs/xfs/xfs_quota.h - 1.31 xfsprogs update - kernel/user sync up and Ethan's Mac partition code. CONTRIBUTED: erbenson@alaska.net. Date: Mon Mar 17 21:44:53 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:141953a cmd/xfsprogs/db/command.c - 1.7 - Remove a useless forward declaration. cmd/xfsprogs/Makefile - 1.16 - Add configure : configure.in dependency, as Mandy suggests. cmd/xfsprogs/doc/CHANGES - 1.93 cmd/xfsprogs/debian/changelog - 1.61 - Bump minor version to 2.4.1. cmd/xfsprogs/libdisk/pttype.c - 1.6 cmd/xfsprogs/libdisk/pttype.h - 1.3 - Add a check for Apple Mac partition tables. cmd/xfsprogs/include/xfs_dqblk.h - 1.7 cmd/xfsprogs/include/libxfs.h - 1.23 cmd/xfsprogs/include/xfs_rtalloc.h - 1.8 cmd/xfsprogs/include/Makefile - 1.16 cmd/xfsprogs/include/xfs_dquot_item.h - 1.7 cmd/xfsprogs/include/libxlog.h - 1.6 cmd/xfsprogs/include/xfs_mount.h - 1.33 cmd/xfsprogs/include/xfs_inode.h - 1.29 cmd/xfsprogs/include/xfs_types.h - 1.17 cmd/xfsprogs/include/xfs_trans.h - 1.12 cmd/xfsprogs/include/xfs_bmap.h - 1.8 cmd/xfsprogs/include/xfs_quota.h - 1.12 cmd/xfsprogs/libxfs/xfs.h - 1.31 cmd/xfsprogs/libxfs/xfs_bmap_btree.c - 1.15 cmd/xfsprogs/libxfs/xfs_bmap.c - 1.19 - Sync up user/kernel code after recent changes. From owner-linux-xfs@oss.sgi.com Tue Mar 18 03:49:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Mar 2003 03:50:08 -0800 (PST) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2IBnuq9020983 for ; Tue, 18 Mar 2003 03:49:58 -0800 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GZVLXR5H; Tue, 18 Mar 2003 06:49:57 -0500 Received: from wgate.com (localhost.localdomain [127.0.0.1]) by sinz.eng.tvol.net (8.12.8/8.12.5) with ESMTP id h2IBlEfj021972; Tue, 18 Mar 2003 06:47:14 -0500 Message-ID: <3E770742.4040904@wgate.com> Date: Tue, 18 Mar 2003 06:47:14 -0500 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: Nicholas Wourms , linux-xfs@oss.sgi.com, Bruce Bauman Subject: Re: What happened to the linux-2.4-xfs cvs tree? References: <3E764CA8.5050404@myrealbox.com> <20030318004530.GC948@frodo> In-Reply-To: <20030318004530.GC948@frodo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3244 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: msinz@wgate.com Precedence: bulk X-list: linux-xfs Content-Length: 1112 Lines: 32 Nathan Scott wrote: > On Mon, Mar 17, 2003 at 05:31:04PM -0500, Nicholas Wourms wrote: > >>Hi, >> >>I just went to pull the sources from the linux-2.4-xfs tree >>and I noticed it is gone for both cvs and cvsweb. Was this >>intentional? Will it be back? >> > > > Pfft - not sure what's happened there. I sure hope it comes back, > we'll probably have to wait for Russell to do his magic though. > > The latest commands code is also mirrored below the 2.5.x-xfs part > of the CVS tree, so you can at least still get access to that in > the interim. I run a local (for our use) mirror using rsync from your CVS tree and a whole bunch of the 2.4 tree has been blown away - specifically, all of the linux/fs, net, kdb, include, lib, mm, and scripts directories are empty (there are no ",v" files in them, just sub directories.) The 2.5 tree seems to still be ok for now... (Looks like someone forgot the "pixi-dust" that I saw on TV :-) -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Tue Mar 18 06:10:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Mar 2003 06:10:39 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2IE9dq9024561 for ; Tue, 18 Mar 2003 06:10:20 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 39CBCAC4C for ; Tue, 18 Mar 2003 15:22:25 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id E06E9190C2 for ; Tue, 18 Mar 2003 15:22:26 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id DB1DA30881E for ; Tue, 18 Mar 2003 15:09:35 +0100 (CET) Message-ID: <3E77289F.960BF744@ch.sauter-bc.com> Date: Tue, 18 Mar 2003 15:09:35 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: linux-xfs Subject: Updated RedHat errata kernel with XFS 1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3245 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: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 366 Lines: 9 I have created XFS enabled versions of todays RedHat errata kernel. I have only compiled them on RedHat 7.3 which is suitable for RedHat 7.1-7.3 but it should compile fine on RedHat 8.0 too. For now the rpms can be downloaded from http://www.sauter-bc.com/XFS/ but maybe I have to remove them soon. Can someone from SGI put them into contrib section on OSS? Simon From owner-linux-xfs@oss.sgi.com Tue Mar 18 06:15:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Mar 2003 06:15:27 -0800 (PST) Received: from xanthie.baobab.home (ABoulogne-106-1-2-109.abo.wanadoo.fr [80.11.103.109]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2IEFLq9025003 for ; Tue, 18 Mar 2003 06:15:23 -0800 Received: from amavis by xanthie.baobab.home with scanned-ok (Exim 3.35 #1 (Debian)) id 18vHrm-0000cW-00 for ; Tue, 18 Mar 2003 15:14:58 +0100 Received: from localhost ([127.0.0.1] helo=xanthie.baobab.home) by xanthie.baobab.home with esmtp (Exim 3.35 #1 (Debian)) id 18vHrm-0000cO-00 for ; Tue, 18 Mar 2003 15:14:58 +0100 To: linux-xfs@oss.sgi.com Subject: Re: XFS 1.2.0 release for linux-2.4.20? References: <1047564814.2704.41.camel@contact.skynet.coplanar.net> <1047566218.36078.12.camel@lupo.thebarn.com> From: Frederic Saincy Organization: GNU/Linux Date: 18 Mar 2003 15:14:57 +0100 In-Reply-To: <1047566218.36078.12.camel@lupo.thebarn.com> Message-ID: <87bs08ep7i.fsf@xanthie.baobab.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS new-20020517 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3246 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: freddy@lovelinux.org Precedence: bulk X-list: linux-xfs Content-Length: 259 Lines: 12 Hi, Russell Cattelan writes: > we can look it over and put it > on the ftp site in case other people want to grab it. I think so: http://www.uwsg.iu.edu/hypermail/linux/kernel/0303.2/0226.html Tank you and bye. -- Frederic Saincy From owner-linux-xfs@oss.sgi.com Tue Mar 18 06:25:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Mar 2003 06:25:30 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2IEOlq9025478 for ; Tue, 18 Mar 2003 06:25:27 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2IEZwkq009757 for ; Tue, 18 Mar 2003 08:35:58 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA14612; Tue, 18 Mar 2003 08:24:40 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2IEOewX23593438; Tue, 18 Mar 2003 08:24:41 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2IEOeh22208; Tue, 18 Mar 2003 08:24:40 -0600 Subject: Re: What happened to the linux-2.4-xfs cvs tree? From: Steve Lord To: Michael Sinz Cc: Nathan Scott , Nicholas Wourms , linux-xfs@oss.sgi.com, Bruce Bauman In-Reply-To: <3E770742.4040904@wgate.com> References: <3E764CA8.5050404@myrealbox.com> <20030318004530.GC948@frodo> <3E770742.4040904@wgate.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047997479.16800.8.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 18 Mar 2003 08:24:40 -0600 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3247 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1385 Lines: 40 On Tue, 2003-03-18 at 05:47, Michael Sinz wrote: > Nathan Scott wrote: > > On Mon, Mar 17, 2003 at 05:31:04PM -0500, Nicholas Wourms wrote: > > > >>Hi, > >> > >>I just went to pull the sources from the linux-2.4-xfs tree > >>and I noticed it is gone for both cvs and cvsweb. Was this > >>intentional? Will it be back? > >> > > > > > > Pfft - not sure what's happened there. I sure hope it comes back, > > we'll probably have to wait for Russell to do his magic though. > > > > The latest commands code is also mirrored below the 2.5.x-xfs part > > of the CVS tree, so you can at least still get access to that in > > the interim. > > I run a local (for our use) mirror using rsync from your CVS tree and > a whole bunch of the 2.4 tree has been blown away - specifically, > all of the linux/fs, net, kdb, include, lib, mm, and scripts directories > are empty (there are no ",v" files in them, just sub directories.) > > The 2.5 tree seems to still be ok for now... These CVS trees are actually recreated from scratch everytime they are updated. The originals of all this stuff are still here, just something in the process of pushing it out to oss is badly broken by the sound of it. Hopefully it will get fixed today. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Mar 18 14:20:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Mar 2003 14:21:10 -0800 (PST) Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2IMKtq9014308 for ; Tue, 18 Mar 2003 14:20:56 -0800 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.3.11]) by mxzilla4.xs4all.nl (8.12.3/8.12.3) with ESMTP id h2IMKrFC034296; Tue, 18 Mar 2003 23:20:53 +0100 (CET) Received: from xs1.xs4all.nl (knuffie@localhost.xs4all.nl [127.0.0.1]) by xs1.xs4all.nl (8.12.8/8.11.6) with ESMTP id h2IMKrkD052298; Tue, 18 Mar 2003 23:20:53 +0100 (CET) (envelope-from knuffie@xs1.xs4all.nl) Received: from localhost (Unknown UID 104317@localhost) by xs1.xs4all.nl (8.12.8/8.12.8/Submit) with ESMTP id h2IMKqdq052295; Tue, 18 Mar 2003 23:20:52 +0100 (CET) (envelope-from knuffie@xs1.xs4all.nl) X-Authentication-Warning: xs1.xs4all.nl: Unknown UID 104317 owned process doing -bs Date: Tue, 18 Mar 2003 23:20:52 +0100 (CET) From: Seth Mos To: Simon Matter cc: linux-xfs Subject: Re: Updated RedHat errata kernel with XFS 1.2 In-Reply-To: <3E77289F.960BF744@ch.sauter-bc.com> Message-ID: <20030318231811.P52057-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3248 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 759 Lines: 23 On Tue, 18 Mar 2003, Simon Matter wrote: > I have created XFS enabled versions of todays RedHat errata kernel. I > have only compiled them on RedHat 7.3 which is suitable for RedHat > 7.1-7.3 but it should compile fine on RedHat 8.0 too. For now the rpms > can be downloaded from http://www.sauter-bc.com/XFS/ but maybe I have to > remove them soon. Can someone from SGI put them into contrib section on > OSS? Ah, I just created a similar source rpm as well, it seems to compile but by sheer lack of time and approaching bedtime I have not tested any of these. Binary rpms will come later. And like Simon, these are compiled on 7.3 as well. Because of the bandwidth I only have the source rpm for now. http://iserv.nl/files/xfs/2.4.18-27/ Cheers Seth From owner-linux-xfs@oss.sgi.com Tue Mar 18 20:00:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Mar 2003 20:00:28 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2J40Jq9016780 for ; Tue, 18 Mar 2003 20:00:20 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2J40CnH002884 for ; Tue, 18 Mar 2003 20:00:13 -0800 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id h2J3xCu02418; Wed, 19 Mar 2003 14:59:12 +1100 Date: Wed, 19 Mar 2003 14:59:12 +1100 From: Keith Owens Message-Id: <200303190359.h2J3xCu02418@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade xfs to kdb v4.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3249 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: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 748 Lines: 26 Upgrade xfs to kdb v4.0 Date: Tue Mar 18 19:57:56 PST 2003 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:142080a linux/drivers/char/serial.c - 1.60 linux/kdb/kdb_bt.c - 1.15 linux/kdb/kdb_bp.c - 1.16 linux/include/linux/kdbprivate.h - 1.23 linux/include/linux/kdb.h - 1.29 linux/kdb/kdbsupport.c - 1.17 linux/kdb/kdbmain.c - 1.36 linux/kdb/kdb_io.c - 1.18 linux/include/asm-i386/kdbprivate.h - 1.19 linux/Documentation/kdb/kdb_bt.man - 1.10 linux/arch/i386/kdb/kdbasupport.c - 1.25 linux/arch/i386/kdb/kdba_io.c - 1.20 linux/arch/i386/kdb/kdba_bt.c - 1.19 linux/kdb/ChangeLog - 1.28 linux/arch/i386/kdb/ChangeLog - 1.17 From owner-linux-xfs@oss.sgi.com Tue Mar 18 21:05:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Mar 2003 21:05:43 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2J54pq9017620 for ; Tue, 18 Mar 2003 21:05:31 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2J54inH005681 for ; Tue, 18 Mar 2003 21:04:44 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA21081; Wed, 19 Mar 2003 16:03:28 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 16D01300087; Wed, 19 Mar 2003 16:03:26 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 498668F; Wed, 19 Mar 2003 16:03:26 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: Announce: XFS split patches for 2.4.20 - respin Date: Wed, 19 Mar 2003 16:03:20 +1100 Message-ID: <15510.1048050200@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3250 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: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 988 Lines: 29 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii ftp://oss.sgi.com/projects/xfs/download/patches/2.4.20. The xfs patches for 2.4.20 have been respun as of 2003-03-19 04:55 UTC, including kdb v4.0. For some time the XFS group have been producing split patches for XFS, separating the core XFS changes from additional patches such as kdb, xattr, acl, dmapi. The split patches are released to the world with the hope that developers and distributors will find them useful. Read the README in each directory very carefully, the split patch format has changed over a few kernel releases. Any questions that are covered by the README will be ignored. There is even a 2.4.21/README for the terminally impatient :). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE+d/oWi4UHNye0ZOoRAgzmAJ4vD9+rDiv+eK/AlxlOqgcELFJVJQCg4Ktm h2q80Zvu3amOD/fQVNKn1I4= =EP8P -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Mar 19 01:15:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 01:15:29 -0800 (PST) Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2J9Ecq9023072 for ; Wed, 19 Mar 2003 01:15:20 -0800 Received: (qmail 30036 invoked by uid 1000); 19 Mar 2003 09:37:08 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 19 Mar 2003 09:37:08 -0000 Date: Wed, 19 Mar 2003 11:37:08 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Linux XFS List Subject: kernel from CVS doesnt compile Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3251 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: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Content-Length: 505 Lines: 14 Hi I just checked out from cvs@oss.sgi.com:/cvs linux-2.4-xfs module and I think it misses Rules.make file (any make {clean|config|mrproper} I try it gives me: No rule to make target Rules.make ). find . -name Rules.make doest find anything in the checked out directory. :) ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Wed Mar 19 03:29:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 03:29:45 -0800 (PST) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JBTYq9027468 for ; Wed, 19 Mar 2003 03:29:35 -0800 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GZVLX5ZG; Wed, 19 Mar 2003 06:29:35 -0500 Received: from wgate.com (localhost.localdomain [127.0.0.1]) by sinz.eng.tvol.net (8.12.8/8.12.5) with ESMTP id h2JBQhfj024422; Wed, 19 Mar 2003 06:26:43 -0500 Message-ID: <3E7853F3.1090406@wgate.com> Date: Wed, 19 Mar 2003 06:26:43 -0500 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mihai RUSU CC: Linux XFS List Subject: Re: kernel from CVS doesnt compile References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3252 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: msinz@wgate.com Precedence: bulk X-list: linux-xfs Content-Length: 691 Lines: 18 Mihai RUSU wrote: > Hi > > I just checked out from cvs@oss.sgi.com:/cvs linux-2.4-xfs module and I > think it misses Rules.make file (any make {clean|config|mrproper} I try it > gives me: No rule to make target Rules.make ). find . -name Rules.make > doest find anything in the checked out directory. :) Something is currently broken in the CVS export of SGI's internal system. They good folks at SGI are very busy and may not have had a chance to look at/fix the problem yet. I am sure that it will be addressed soon. -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Wed Mar 19 05:21:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 05:22:03 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2JDLsq9000743 for ; Wed, 19 Mar 2003 05:21:54 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2JDLsmJ000741 for linux-xfs@oss.sgi.com; Wed, 19 Mar 2003 05:21:54 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2JDLqq9000730 for ; Wed, 19 Mar 2003 05:21:52 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2JDHBW7000689; Wed, 19 Mar 2003 05:17:11 -0800 Date: Wed, 19 Mar 2003 05:17:11 -0800 Message-Id: <200303191317.h2JDHBW7000689@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 233] New: Close system call hangs on creating large files on XFS partition X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3253 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1987 Lines: 62 http://oss.sgi.com/bugzilla/show_bug.cgi?id=233 Summary: Close system call hangs on creating large files on XFS partition Product: Linux XFS Version: 1.2.x Platform: IA32 OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: armin.schoisswohl@med.ge.com CC: armin.schoisswohl@med.ge.com If this is a userspace bug, what version of the package are you using: attr-2.1.1-1 acl-2.1.1-1 dmapi-2.0.5-1 xfsprogs-2.3.5-1 kernel-source-2.4.18-18SGI_XFS_1.2.0 What kernel are you using: 2.4.18-18SGI_XFS_1.2.0custom (=2.4.18-18SGI_XFS_1.2.0 + NTFS ro module support) Where did the XFS code come from? (CVS, Linus, your distribution, etc): kernel-2.4.18-18SGI_XFS_1.2.0.src.rpm from SGI website ftp://oss.sgi.com/projects/xfs/download/latest/kernel_rpms/2.4.18-18-RH/SRPMS/kernel-2.4.18-18SGI_XFS_1.2.0.src.rpm Description of Problem: When creating large files (approx. > 700MB) on a XFS partition the creating process hangs in the close system call. How Reproducible: Completely Steps to Reproduce: 1. dd if=/dev/zero of=/some/file/on/a/XFS/partition bs=512 count=1400000 Actual Results: When the file is created completely (full size 716800000 bytes), dd hangs for about 10 minutes and more (maximum was 220 min) using the whole CPU power in kernel mode. Expected Results: No hang. Additional Information: I dumped the registers during the hang and found out that the kernel spends most of the time in the function invalidate_inode_pages (mm/filemap.c), mostly at 1aa and 315; also 175,177,1b4,17c,1ae, and 175 were found sometimes. I will attach a disassambly of invalidate_inode_pages as well as the source and the output of SysRq. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 19 06:21:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 06:22:01 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2JELsq9001723 for ; Wed, 19 Mar 2003 06:21:54 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2JELsiI001719 for linux-xfs@oss.sgi.com; Wed, 19 Mar 2003 06:21:54 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2JELqqB001697 for ; Wed, 19 Mar 2003 06:21:53 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2JDRpu6001235; Wed, 19 Mar 2003 05:27:51 -0800 Date: Wed, 19 Mar 2003 05:27:51 -0800 Message-Id: <200303191327.h2JDRpu6001235@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 233] Close system call hangs on creating large files on XFS partition X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3254 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 406 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=233 ------- Additional Comments From armin.schoisswohl@med.ge.com 2003-03-19 05:27 ------- Created an attachment (id=70) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=70&action=view) Sample Alt-SysReq-P and Alt-SysReq-M output. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 19 06:21:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 06:22:01 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2JELsq9001722 for ; Wed, 19 Mar 2003 06:21:54 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2JELsnB001718 for linux-xfs@oss.sgi.com; Wed, 19 Mar 2003 06:21:54 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2JELqq9001697 for ; Wed, 19 Mar 2003 06:21:52 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2JDQAbo001173; Wed, 19 Mar 2003 05:26:10 -0800 Date: Wed, 19 Mar 2003 05:26:10 -0800 Message-Id: <200303191326.h2JDQAbo001173@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 233] Close system call hangs on creating large files on XFS partition X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3255 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 546 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=233 ------- Additional Comments From armin.schoisswohl@med.ge.com 2003-03-19 05:26 ------- Created an attachment (id=69) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=69&action=view) Disassembly of mm/filemap.c::truncate_list_pages The EIP positions we obtained by pressing Alt-SysReq-P are marked with asterisks (more asterisks mean a higher number of observations). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 19 06:34:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 06:34:16 -0800 (PST) Received: from centauri.artland.com.pl (centauri.artland.com.pl [62.233.164.19]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JEY9q9003100 for ; Wed, 19 Mar 2003 06:34:12 -0800 Received: (qmail 19909 invoked from network); 19 Mar 2003 14:46:19 -0000 Received: from unknown (HELO ubik) (149.156.124.19) by centauri.artland.com.pl with DES-CBC3-SHA encrypted SMTP; 19 Mar 2003 14:46:19 -0000 Received: from pokryfka by ubik with local (Exim 3.35 #1 (Debian)) id 18vedu-00018x-00 for ; Wed, 19 Mar 2003 15:34:10 +0100 Date: Wed, 19 Mar 2003 15:34:10 +0100 To: linux-xfs@oss.sgi.com Subject: xfs cpu usage Message-ID: <20030319143410.GA4333@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i From: Michal Adamczak X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3256 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: pokryfka@druid.if.uj.edu.pl Precedence: bulk X-list: linux-xfs Content-Length: 746 Lines: 34 hi, when coping/deleting files (both small and very large) the cpu usage reaches 100% so that it's hardly possible to do anything else at the same time what could possibly be the reason? i use linux 2.5.65 (though same goes for 2.4.20) debian sid i use the following hdparm settings: #hdparm -d1 c1 -u1 -m8 /dev/hda which results in #hdparm /dev/hda /dev/hda: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 23989/16/63, sectors = 156301488, start = 0 -- Michal Adamczak pokryfka @ druid.if.uj.edu.pl GS dpu C+++ UL+++++ L+++(++++) w--- !tv h* I code AND I bathe. (seen on slashdot) From owner-linux-xfs@oss.sgi.com Wed Mar 19 09:56:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 09:56:43 -0800 (PST) Received: from imf58bis.bellsouth.net (mail145.mail.bellsouth.net [205.152.58.105]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JHuTq9009254 for ; Wed, 19 Mar 2003 09:56:32 -0800 Received: from tiger2 ([66.156.1.57]) by imf58bis.bellsouth.net (InterMail vM.5.01.04.25 201-253-122-122-125-20020815) with SMTP id <20030319175011.RXTR25382.imf58bis.bellsouth.net@tiger2>; Wed, 19 Mar 2003 12:50:11 -0500 Date: Wed, 19 Mar 2003 13:00:44 -0500 From: Greg Freemyer Subject: re: xfs cpu usage To: Michal Adamczak , Mime-Version: 1.0 Organization: Norcross Group X-Mailer: GoldMine [6.00.21021] Content-Type: Text/plain Message-Id: <20030319175011.RXTR25382.imf58bis.bellsouth.net@tiger2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h2JHuXq9009256 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3257 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: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 1619 Lines: 51 I thought this was the very reason people used SCSI in preference to IDE. i.e. IDE uses the CPU to control seeks, SCSI just tells the controller, and the controller interrupts the CPU when the seek is done. Obviously you could upgrade to SCSI. Alternatively, the 3ware controllers present the CPU with a SCSI interface, but talk to IDE drives on the back-end. I assume there are other controllers that do this as well. I know that some of the Promise controllers imply they do this, but in reality they don't reduce CPU load. Other Promise controllers may do the job right. FYI: A 2-port 3ware card (IIRC 7000-2) only costs a little over $100 (US) and they are supported in the vanilla kernel. Greg >> hi, >> when coping/deleting files (both small and very large) >> the cpu usage reaches 100% so that it's hardly possible to do anything >> else at the same time >> what could possibly be the reason? >> i use linux 2.5.65 (though same goes for 2.4.20) >> debian sid >> i use the following hdparm settings: >> #hdparm -d1 c1 -u1 -m8 /dev/hda >> which results in >> #hdparm /dev/hda >> >> /dev/hda: >> multcount = 16 (on) >> IO_support = 1 (32-bit) >> unmaskirq = 1 (on) >> using_dma = 1 (on) >> keepsettings = 0 (off) >> readonly = 0 (off) >> readahead = 256 (on) >> geometry = 23989/16/63, sectors = 156301488, start = 0 >> >> -- >> Michal Adamczak >> pokryfka @ druid.if.uj.edu.pl >> GS dpu C+++ UL+++++ L+++(++++) w--- !tv h* >> I code AND I bathe. (seen on slashdot) From owner-linux-xfs@oss.sgi.com Wed Mar 19 10:17:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 10:17:39 -0800 (PST) Received: from centauri.artland.com.pl (centauri.artland.com.pl [62.233.164.19]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JIGjq9009779 for ; Wed, 19 Mar 2003 10:17:32 -0800 Received: (qmail 25560 invoked from network); 19 Mar 2003 18:28:56 -0000 Received: from unknown (HELO ubik) (149.156.124.19) by centauri.artland.com.pl with DES-CBC3-SHA encrypted SMTP; 19 Mar 2003 18:28:56 -0000 Received: from pokryfka by ubik with local (Exim 3.35 #1 (Debian)) id 18vi7O-0001xV-00; Wed, 19 Mar 2003 19:16:50 +0100 Date: Wed, 19 Mar 2003 19:16:50 +0100 To: Greg Freemyer Cc: linux-xfs@oss.sgi.com Subject: Re: xfs cpu usage Message-ID: <20030319181650.GA7459@localhost> References: <20030319175011.RXTR25382.imf58bis.bellsouth.net@tiger2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030319175011.RXTR25382.imf58bis.bellsouth.net@tiger2> User-Agent: Mutt/1.5.3i From: Michal Adamczak X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3258 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: pokryfka@druid.if.uj.edu.pl Precedence: bulk X-list: linux-xfs Content-Length: 2367 Lines: 74 thanks for prompt answer k, i know scsi devices are generally more independent and as such less cpu consuming but this drive is on my desktop and i really apprectiate buying 80GB for $100 on a production host (where there are both scsi and ide drives for less critical information) i still use ext3 i thought about switching to xfs and wanted to make some preliminary tests on my desktop unfortunately the way it works right now is unacceptable On Wed, Mar 19, 2003 at 01:00:44PM -0500, Greg Freemyer wrote: > I thought this was the very reason people used SCSI in preference to IDE. > > i.e. IDE uses the CPU to control seeks, SCSI just tells the controller, and the controller interrupts the CPU when the seek is done. > > Obviously you could upgrade to SCSI. > > Alternatively, the 3ware controllers present the CPU with a SCSI interface, but talk to IDE drives on the back-end. > > I assume there are other controllers that do this as well. > > I know that some of the Promise controllers imply they do this, but in reality they don't reduce CPU load. > > Other Promise controllers may do the job right. > > FYI: A 2-port 3ware card (IIRC 7000-2) only costs a little over $100 (US) and they are supported in the vanilla kernel. > > Greg > >> hi, > >> when coping/deleting files (both small and very large) > >> the cpu usage reaches 100% so that it's hardly possible to do anything > >> else at the same time > > >> what could possibly be the reason? > > >> i use linux 2.5.65 (though same goes for 2.4.20) > >> debian sid > > >> i use the following hdparm settings: > >> #hdparm -d1 c1 -u1 -m8 /dev/hda > > >> which results in > > >> #hdparm /dev/hda > >> > >> /dev/hda: > >> multcount = 16 (on) > >> IO_support = 1 (32-bit) > >> unmaskirq = 1 (on) > >> using_dma = 1 (on) > >> keepsettings = 0 (off) > >> readonly = 0 (off) > >> readahead = 256 (on) > >> geometry = 23989/16/63, sectors = 156301488, start = 0 > >> > > >> -- > >> Michal Adamczak > >> pokryfka @ druid.if.uj.edu.pl > >> GS dpu C+++ UL+++++ L+++(++++) w--- !tv h* > >> I code AND I bathe. (seen on slashdot) -- Michal Adamczak pokryfka @ druid.if.uj.edu.pl GS dpu C+++ UL+++++ L+++(++++) w--- !tv h* I code AND I bathe. (seen on slashdot) From owner-linux-xfs@oss.sgi.com Wed Mar 19 11:28:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 11:28:19 -0800 (PST) Received: from wiglaf.cs-i.brandeis.edu ([129.64.46.45]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JJS7q9011260 for ; Wed, 19 Mar 2003 11:28:10 -0800 Received: (from aaronm@localhost) by wiglaf.cs-i.brandeis.edu (8.11.6/8.11.6) id h2JJS6X11408 for linux-xfs@oss.sgi.com; Wed, 19 Mar 2003 14:28:06 -0500 Date: Wed, 19 Mar 2003 14:28:06 -0500 From: Aaron Macks To: linux-xfs@oss.sgi.com Subject: Reserve area for Suid? Message-ID: <20030319192806.GA11189@cs.brandeis.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3259 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: aaronm@cs.brandeis.edu Precedence: bulk X-list: linux-xfs Content-Length: 300 Lines: 6 In the back of my mind I seem to remember that in formatting an XFS drive, one can reserve some percentage for Suid. Is this possible, or have I confused it with something else? aaron -- Aaron Macks(aaronm@cs.brandeis.edu) My sheep has seven gall bladders, that makes me the King of the Universe! From owner-linux-xfs@oss.sgi.com Wed Mar 19 11:49:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 11:49:07 -0800 (PST) Received: from ns1.scripps.edu (ns1.scripps.edu [192.42.82.59]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JJn2q9011852 for ; Wed, 19 Mar 2003 11:49:02 -0800 Received: from antigen.scripps.edu (antigen.scripps.edu [137.131.200.100]) by ns1.scripps.edu (8.11.6/TSRI-4.1rx) with SMTP id h2JJn2L03827 for ; Wed, 19 Mar 2003 11:49:02 -0800 (PST) Received: from relay1.scripps.edu(137.131.200.29) by antigen.scripps.edu via csmap id 17903; Wed, 19 Mar 2003 11:40:15 -0800 (PST) Received: from astra.scripps.edu (astra.scripps.edu [137.131.108.81]) by relay1.scripps.edu (8.11.6/TSRI-4.2rAV) with ESMTP id h2JJmwB29793 for ; Wed, 19 Mar 2003 11:48:58 -0800 (PST) Received: (from arvai@localhost) by astra.scripps.edu (8.9.2/TSRI-3.0.1) id LAA21241 for linux-xfs@oss.sgi.com; Wed, 19 Mar 2003 11:48:57 -0800 (PST) Date: Wed, 19 Mar 2003 11:48:57 -0800 (PST) From: Andy Arvai Message-Id: <200303191948.LAA21241@astra.scripps.edu> To: linux-xfs@oss.sgi.com Subject: optimizing raid performance with xfs X-Sun-Charset: US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3260 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: arvai@scripps.edu Precedence: bulk X-list: linux-xfs Content-Length: 591 Lines: 14 Hi, In the next few weeks I will be building a linux server with a large (1.2TB) raid array. There will be two 3ware 7850 cards (running hardware raid5) and a software raid0 across these two cards. I plan to benchmark three different filesystems (ext3, reiser and xfs) to determine which performs the best. The main thing I am interested in is sequential i/o with large files and I've heard that xfs should be the best choice for this. I am wondering if anyone has recommendations for mkfs.xfs or mount options to maximize performance in this situation. Thanks for any suggestions, Andy From owner-linux-xfs@oss.sgi.com Wed Mar 19 12:31:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 12:31:11 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JKV0q9012525 for ; Wed, 19 Mar 2003 12:31:01 -0800 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id h2JKUwN09501; Wed, 19 Mar 2003 15:30:58 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Wed, 19 Mar 2003 15:30:58 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Andy Arvai cc: linux-xfs@oss.sgi.com Subject: Re: optimizing raid performance with xfs In-Reply-To: <200303191948.LAA21241@astra.scripps.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3261 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: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 1595 Lines: 33 On Wed, 19 Mar 2003 at 11:48am, Andy Arvai wrote > In the next few weeks I will be building a linux server with a large > (1.2TB) raid array. There will be two 3ware 7850 cards (running > hardware raid5) and a software raid0 across these two cards. I plan to > benchmark three different filesystems (ext3, reiser and xfs) to > determine which performs the best. The main thing I am interested in is > sequential i/o with large files and I've heard that xfs should be the > best choice for this. I am wondering if anyone has recommendations for > mkfs.xfs or mount options to maximize performance in this situation. During recent testing on a single 3ware card, I found XFS to have twice the write speed of ext3, with a similar read speed (this is all with bonnie++ and the default mkfs options (except for log size)). I didn't test Reiser. If the server has lots of memory, make sure that your kernel supports HIGH I/O and that you're using 3ware drivers that support it -- it makes a *big* difference. I'm using the RH based XFS 1.2 release kernel and the 7.5.3 3ware driver set. I've got another 3ware based system that's similar to yours (two cards with a software stripe), and I found that increasing the chunk-size of the stripe increased performance (at the cost of CPU load) -- I'm using 4096k in production. mkfs.xfs will automatically tune swidth and sunit for the software stripe. On the hardware side, make sure your cards are on separate PCI busses. You'll be bus limited otherwise. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Wed Mar 19 12:40:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 12:40:47 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JKdWq9013693 for ; Wed, 19 Mar 2003 12:40:12 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2JKdRnH026392 for ; Wed, 19 Mar 2003 12:39:27 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA42956; Wed, 19 Mar 2003 14:39:26 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2JKdQwX29810319; Wed, 19 Mar 2003 14:39:26 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2JKdQa22631; Wed, 19 Mar 2003 14:39:26 -0600 Subject: Re: optimizing raid performance with xfs From: Steve Lord To: Andy Arvai Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1048106365.19339.32.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 19 Mar 2003 14:39:26 -0600 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3262 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2304 Lines: 48 On Wed, 2003-03-19 at 14:30, Joshua Baker-LePain wrote: > On Wed, 19 Mar 2003 at 11:48am, Andy Arvai wrote > > > In the next few weeks I will be building a linux server with a large > > (1.2TB) raid array. There will be two 3ware 7850 cards (running > > hardware raid5) and a software raid0 across these two cards. I plan to > > benchmark three different filesystems (ext3, reiser and xfs) to > > determine which performs the best. The main thing I am interested in is > > sequential i/o with large files and I've heard that xfs should be the > > best choice for this. I am wondering if anyone has recommendations for > > mkfs.xfs or mount options to maximize performance in this situation. > > During recent testing on a single 3ware card, I found XFS to have twice > the write speed of ext3, with a similar read speed (this is all with > bonnie++ and the default mkfs options (except for log size)). I didn't > test Reiser. If the server has lots of memory, make sure that your kernel > supports HIGH I/O and that you're using 3ware drivers that support it -- > it makes a *big* difference. I'm using the RH based XFS 1.2 release > kernel and the 7.5.3 3ware driver set. > > I've got another 3ware based system that's similar to yours (two cards > with a software stripe), and I found that increasing the chunk-size of the > stripe increased performance (at the cost of CPU load) -- I'm using 4096k > in production. mkfs.xfs will automatically tune swidth and sunit for the > software stripe. > > On the hardware side, make sure your cards are on separate PCI busses. > You'll be bus limited otherwise. One thing which came up recently was how inodes get placed once you cross the 1 Tbyte boundary. Policy changes to avoid 33 bit inode numbers. You can avoid this policy change with mkfs -t xfs -f -i size=512 /dev/xxx Also, pay attention to the mkfs output, the sunit and swidth lines, these control how data will get layed out. You want to make sure they line up with your device configuration. This may or may not happen automatically depending on your setup. Read the mkfs.xfs man page for how to control them yourself. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Mar 19 12:57:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 12:57:16 -0800 (PST) Received: from fruit.eu.org (qmailr@d5112018.cable.wanadoo.nl [213.17.32.24]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JKv6q9015773 for ; Wed, 19 Mar 2003 12:57:13 -0800 Received: (qmail 5073 invoked by uid 500); 19 Mar 2003 20:57:01 -0000 Date: Wed, 19 Mar 2003 21:57:01 +0100 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: Re: optimizing raid performance with xfs Message-ID: <20030319205701.GI29548@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200303191948.LAA21241@astra.scripps.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-oi: oi User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3263 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: wsl@fruit.eu.org Precedence: bulk X-list: linux-xfs Content-Length: 645 Lines: 16 On 2003-03-19 15:30:58-0500, Joshua Baker-LePain wrote: > I've got another 3ware based system that's similar to yours (two cards > with a software stripe), and I found that increasing the chunk-size of the > stripe increased performance (at the cost of CPU load) -- I'm using 4096k > in production. In theory you should use a small stripe size for large files (parallellism for sequential access patterns) and a large stripe size for small files (low latency for random access). Of course YMMV so do test it out with your own specific workload (as opposed to a generic benchmark like Bonnie++). HTH, -- Wessel Dankers From owner-linux-xfs@oss.sgi.com Wed Mar 19 13:12:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 13:13:08 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JLCIq9019546 for ; Wed, 19 Mar 2003 13:12:59 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2JLNYkq017422 for ; Wed, 19 Mar 2003 15:23:34 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA60079; Wed, 19 Mar 2003 15:12:12 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2JLCCwX31476015; Wed, 19 Mar 2003 15:12:12 -0600 (CST) Subject: Re: kernel from CVS doesnt compile From: Rusell Cattelan To: Mihai RUSU Cc: Linux XFS List In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1048108368.25121.43.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-1) Date: 19 Mar 2003 15:12:48 -0600 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3264 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: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 934 Lines: 28 We have been having some problems with the machine that does the conversion/push to oss. Everything appears to be functioning normally now so the tree should be complete. NOTE NOTE NOTE the cmds have been moved to it's own repository (actually it's been this internally for quite some time) The xfs commands can now be obtained via cvs co xfs-cmds On Wed, 2003-03-19 at 03:37, Mihai RUSU wrote: > Hi > > I just checked out from cvs@oss.sgi.com:/cvs linux-2.4-xfs module and I > think it misses Rules.make file (any make {clean|config|mrproper} I try it > gives me: No rule to make target Rules.make ). find . -name Rules.make > doest find anything in the checked out directory. :) > > ---------------------------- > Mihai RUSU > > Disclaimer: Any views or opinions presented within this e-mail are solely > those of the author and do not necessarily represent those of any company, > unless otherwise specifically stated. > From owner-linux-xfs@oss.sgi.com Wed Mar 19 13:39:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 13:39:14 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JLTTqF020156 for ; Wed, 19 Mar 2003 13:39:05 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2JK6mnH023941 for ; Wed, 19 Mar 2003 12:06:48 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA13196; Wed, 19 Mar 2003 14:06:47 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2JK6lCI5724084; Wed, 19 Mar 2003 14:06:47 -0600 (CST) Subject: Re: Reserve area for Suid? From: Eric Sandeen To: Aaron Macks Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030319192806.GA11189@cs.brandeis.edu> References: <20030319192806.GA11189@cs.brandeis.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 19 Mar 2003 14:06:29 -0600 Message-Id: <1048104389.5112.7.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3265 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 544 Lines: 15 ext[2,3] can do this, xfs has never had that feature. -Eric On Wed, 2003-03-19 at 13:28, Aaron Macks wrote: > In the back of my mind I seem to remember that in formatting an XFS drive, one can reserve some percentage for Suid. Is this possible, or have I confused it with something else? > aaron > -- > Aaron Macks(aaronm@cs.brandeis.edu) > My sheep has seven gall bladders, that makes me the King of the Universe! > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Mar 19 14:21:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 14:22:05 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2JMLtq9023180 for ; Wed, 19 Mar 2003 14:21:55 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2JMLtbL023178 for linux-xfs@oss.sgi.com; Wed, 19 Mar 2003 14:21:55 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2JMLsq9023165 for ; Wed, 19 Mar 2003 14:21:54 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2JLpJfO022234; Wed, 19 Mar 2003 13:51:19 -0800 Date: Wed, 19 Mar 2003 13:51:19 -0800 Message-Id: <200303192151.h2JLpJfO022234@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 233] Close system call hangs on creating large files on XFS partition X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3266 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 318 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=233 ------- Additional Comments From cattelan@thebarn.com 2003-03-19 13:51 ------- Is this a desktop system or a server with no gui stuff running? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 19 14:26:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 14:26:59 -0800 (PST) Received: from rayen.face.ubiobio.cl (rayen.face.ubiobio.cl [146.83.194.131]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JMQGq9023673 for ; Wed, 19 Mar 2003 14:26:57 -0800 Received: by rayen.face.ubiobio.cl (Postfix, from userid 500) id 083A41BE16; Wed, 19 Mar 2003 18:24:46 -0400 (CLT) Received: from localhost (localhost [127.0.0.1]) by rayen.face.ubiobio.cl (Postfix) with ESMTP id 04469407D for ; Wed, 19 Mar 2003 18:24:46 -0400 (CLT) Date: Wed, 19 Mar 2003 18:24:45 -0400 (CLT) From: Leonardo Saavedra Henriquez X-X-Sender: leo@rayen.face.ubiobio.cl To: linux-xfs@oss.sgi.com Subject: 2.4.20 and ptrace xploit In-Reply-To: <1048106365.19339.32.camel@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3267 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: leo@ubiobio.cl Precedence: bulk X-list: linux-xfs Content-Length: 503 Lines: 19 Hi all I've noticed that xfs patch from ftp : -rw-r--r-- 855192 mar 19 00:54 xfs-2.4.20-all-i386.bz2 has today's date, Has this file been patched for ptrace exploit? I wouldn't like to have to patch with 2.4.21-pre5 plus XFS. TIA -- +----------------------------------------------+ ,''`. | Leonardo Saavedra Henriquez |leo@ubiobio.cl | : :' : | Est. Ing Civil en Informatica|U. del Bio-Bio | `. `' +----------------------------------------------+ `- [leo-> ~ $] cd pub && more beer From owner-linux-xfs@oss.sgi.com Wed Mar 19 14:32:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 14:32:07 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JMW4q9024124 for ; Wed, 19 Mar 2003 14:32:04 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2JMVwnH002558 for ; Wed, 19 Mar 2003 14:31:58 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA36350; Wed, 19 Mar 2003 16:31:57 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2JMVvwX28747778; Wed, 19 Mar 2003 16:31:57 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2JMVvR26522; Wed, 19 Mar 2003 16:31:57 -0600 Subject: Re: 2.4.20 and ptrace xploit From: Steve Lord To: Leonardo Saavedra Henriquez Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1048113117.25898.1.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 19 Mar 2003 16:31:57 -0600 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3268 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 716 Lines: 23 On Wed, 2003-03-19 at 16:24, Leonardo Saavedra Henriquez wrote: > Hi all > > I've noticed that xfs patch from ftp : > -rw-r--r-- 855192 mar 19 00:54 xfs-2.4.20-all-i386.bz2 > has today's date, > Has this file been patched for ptrace exploit? > > I wouldn't like to have to patch with 2.4.21-pre5 plus XFS. > Nope, it has not, but applying the ptrace fix to 2.4.20 should not be a problem. We cannot be in the business of doing a distribution and providing fixes to all and sundry with XFS. Unless you all want to start paying us lots of money ;-). Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Mar 19 14:44:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 14:44:12 -0800 (PST) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2JMi5q9024622 for ; Wed, 19 Mar 2003 14:44:07 -0800 Received: from rx3227.cip.uni-regensburg.de (rx3227.cip.uni-regensburg.de [132.199.221.32]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id h2JMhwX20615; Wed, 19 Mar 2003 23:43:58 +0100 (MET) Subject: Re: 2.4.20 and ptrace xploit From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: Steve Lord Cc: Leonardo Saavedra Henriquez , linux-xfs@oss.sgi.com In-Reply-To: <1048113117.25898.1.camel@jen.americas.sgi.com> References: <1048113117.25898.1.camel@jen.americas.sgi.com> Content-Type: text/plain Organization: Message-Id: <1048113838.1317.14.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Mar 2003 23:43:58 +0100 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3269 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: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 544 Lines: 20 On Wed, 2003-03-19 at 23:31, Steve Lord wrote: > On Wed, 2003-03-19 at 16:24, Leonardo Saavedra Henriquez wrote: > > Hi all > > > > I've noticed that xfs patch from ftp : > > -rw-r--r-- 855192 mar 19 00:54 xfs-2.4.20-all-i386.bz2 > > has today's date, > > Has this file been patched for ptrace exploit? > > > > I wouldn't like to have to patch with 2.4.21-pre5 plus XFS. > > > there has been a post on lkml, maybe you'll have a look at it. http://marc.theaimsgroup.com/?l=linux-kernel&m=104792708117519&w=2 cheers. Christian From owner-linux-xfs@oss.sgi.com Wed Mar 19 17:34:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 17:35:09 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2K1Ysq9026582 for ; Wed, 19 Mar 2003 17:34:55 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 168C7183C88D; Wed, 19 Mar 2003 17:34:54 -0800 (PST) Date: Wed, 19 Mar 2003 17:34:54 -0800 From: Chris Wedgwood To: Michal Adamczak Cc: Greg Freemyer , linux-xfs@oss.sgi.com Subject: Re: xfs cpu usage Message-ID: <20030320013454.GA6989@f00f.org> References: <20030319175011.RXTR25382.imf58bis.bellsouth.net@tiger2> <20030319181650.GA7459@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030319181650.GA7459@localhost> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3270 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 203 Lines: 9 On Wed, Mar 19, 2003 at 07:16:50PM +0100, Michal Adamczak wrote: > unfortunately the way it works right now is unacceptable can you run oprofile and see where the time is baing taken please? --cw From owner-linux-xfs@oss.sgi.com Wed Mar 19 20:58:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Mar 2003 20:58:24 -0800 (PST) Received: from vnode.vmunix.com (eb0b9b39cfc5bc56aee036c4a3a399ec@vnode.vmunix.com [64.7.135.41]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2K4wEq9030535 for ; Wed, 19 Mar 2003 20:58:16 -0800 Received: by vnode.vmunix.com (Postfix, from userid 1000) id 9D763A1806; Thu, 20 Mar 2003 05:04:44 +0000 (GMT) Date: Thu, 20 Mar 2003 05:04:44 +0000 From: Mark Mayo To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: optimizing raid performance with xfs Message-ID: <20030320050444.GA52276@vmunix.com> References: <1048106365.19339.32.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1048106365.19339.32.camel@jen.americas.sgi.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3271 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: mark@vmunix.com Precedence: bulk X-list: linux-xfs Content-Length: 2871 Lines: 69 On Wed, Mar 19, 2003 at 02:39:26PM -0600, Steve Lord wrote: > > Also, pay attention to the mkfs output, the sunit and swidth lines, > these control how data will get layed out. You want to make sure they > line up with your device configuration. This may or may not happen > automatically depending on your setup. Read the mkfs.xfs man page for > how to control them yourself. Ah. I'm just trying XFS for the first time and also have some tuning questions! Is the general recommendation to set sunit/su and swidth/sw when running on a hardware RAID system? In my case, I have a bunch of volumes created on an IBM FAStT700 SAN (rebranded LSI 4884, like the SGI SAN Server 1000). The RAID controller lets me adjust "segment size" from 8-256K, with a default of 64KB on a RAID5 volume. The docs say "A segment is the amount of data, in kilobytes, that the controller writes on a single drive in a logical drive before writing data on the next drive." Am I correct when I interpret this as the "strip unit size" defined in the mkfs.xfs man page? Assuming I'm on the right track then, since I have 512 byte data blocks, the 64KB stripe takes up 128 blocks. I have 12 drives in the stripe, so to create a XFS FS I'd run: mkfs.xfs -d sunit=128,swidth=1536 or mkfs.xfs -d su=64k,sw=768k When I create a FS like this, I get: # mkfs.xfs -f -i size=512 -d sunit=128,swidth=1536 /dev/sdb1 meta-data=/dev/sdb1 isize=512 agcount=188, agsize=1048576 blks data = bsize=4096 blocks=197025168, imaxpct=25 = sunit=16 swidth=192 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=24064, version=1 = sunit=16 blks realtime =none extsz=65536 blocks=0, rtextents=0 Am I going about this the right way, or have I gone wrong somewhere along the way in my logic? :) On a related note, I'm wondering what happens when I grow volumes. In this particular volume, it's 752GB right now but what if I add 2 more drives to the volume to grow it by another 120GB? Can I respecify the swidth value somehow or should I simply not specify sunit/swidth on volumes I know will be growing and leave them at the default 0 values? Finally, anything I should be looking out for on 1.7TB volumes? Regards, -Mark > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > -- Mark Mayo http://www.vmunix.com/~mark PGP Fingerprint: 32BA C076 D78C 109B 2558 25E5 0CCE C6C1 262E 28AF Commitment, n.: Commitment can be illustrated by a breakfast of ham and eggs. The chicken was involved, the pig was committed. From owner-linux-xfs@oss.sgi.com Thu Mar 20 00:21:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 00:22:11 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2K8Lwq9006161 for ; Thu, 20 Mar 2003 00:21:58 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2K8LvBw006159 for linux-xfs@oss.sgi.com; Thu, 20 Mar 2003 00:21:58 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2K8Luq9006148 for ; Thu, 20 Mar 2003 00:21:56 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2K7vM4Q002667; Wed, 19 Mar 2003 23:57:22 -0800 Date: Wed, 19 Mar 2003 23:57:22 -0800 Message-Id: <200303200757.h2K7vM4Q002667@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 233] Close system call hangs on creating large files on XFS partition X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3272 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 365 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=233 ------- Additional Comments From armin.schoisswohl@med.ge.com 2003-03-19 23:57 ------- It's a desktop system, however it also appears when running in single user mode without any GUI stuff. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 20 01:23:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 01:24:03 -0800 (PST) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2K9NEq9007399 for ; Thu, 20 Mar 2003 01:23:55 -0800 Received: from rss1.rz.uni-regensburg.de (rss1.rz.uni-regensburg.de [132.199.1.200]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with SMTP id h2K9NCcx031257 for ; Thu, 20 Mar 2003 10:23:12 +0100 Received: (qmail 7301 invoked from network); 20 Mar 2003 10:23:12 +0100 Received: from pc9391.physik.uni-regensburg.de (HELO pc9391) (guc28561@132.199.98.219) by rss1.rz.uni-regensburg.de with SMTP; 20 Mar 2003 10:23:12 +0100 Date: Thu, 20 Mar 2003 10:23:12 +0100 From: Christian Guggenberger To: Mark Mayo Cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: optimizing raid performance with xfs Message-ID: <20030320102312.A7211@pc9391.uni-regensburg.de> References: <1048106365.19339.32.camel@jen.americas.sgi.com> <20030320050444.GA52276@vmunix.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <20030320050444.GA52276@vmunix.com>; from mark@vmunix.com on Thu, Mar 20, 2003 at 06:04:44 +0100 X-Mailer: Balsa 1.2.4 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3273 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: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 1506 Lines: 35 On 20.03.2003 06:04 Mark Mayo wrote: > On Wed, Mar 19, 2003 at 02:39:26PM -0600, Steve Lord wrote: > > > > Also, pay attention to the mkfs output, the sunit and swidth lines, > > these control how data will get layed out. You want to make sure they > > line up with your device configuration. This may or may not happen > > automatically depending on your setup. Read the mkfs.xfs man page for > > how to control them yourself. > > Ah. I'm just trying XFS for the first time and also have some tuning > questions! > > Is the general recommendation to set sunit/su and swidth/sw when running > on a hardware RAID system? In my case, I have a bunch of volumes created > on an IBM FAStT700 SAN (rebranded LSI 4884, like the SGI SAN Server > 1000). The RAID controller lets me adjust "segment size" from 8-256K, > with a default of 64KB on a RAID5 volume. The docs say "A segment is the > amount of data, in kilobytes, that the controller writes on a single > drive in a logical drive before writing data on the next drive." Am I > correct when I interpret this as the "strip unit size" defined in the > mkfs.xfs man page? > > Assuming I'm on the right track then, since I have 512 byte data > blocks, the 64KB stripe takes up 128 blocks. I have 12 drives in the > stripe, so to create a XFS FS I'd run: > > mkfs.xfs -d sunit=128,swidth=1536 > or > mkfs.xfs -d su=64k,sw=768k > > On Raid5 setups switdh should be (n-1)*sunit, I think. In your case that would be 11*128, not 12*128. Christian From owner-linux-xfs@oss.sgi.com Thu Mar 20 08:08:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 08:08:47 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2KG7vq9029587 for ; Thu, 20 Mar 2003 08:08:37 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2KG7pnH005732 for ; Thu, 20 Mar 2003 08:07:51 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA24489 for ; Thu, 20 Mar 2003 10:07:50 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2KG7owX31787458 for ; Thu, 20 Mar 2003 10:07:51 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h2KG7PG18076; Thu, 20 Mar 2003 10:07:25 -0600 Message-Id: <200303201607.h2KG7PG18076@stout.americas.sgi.com> Date: Thu, 20 Mar 2003 10:07:25 -0600 Subject: TAKE - Un-race-ify timer manipulation in pagebuf X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3274 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 578 Lines: 20 I don't think we've ever seen problems, but this should be safer. Use mod_timer in place of del/modify/add (can race) Also use del_timer_sync when we're done. Date: Thu Mar 20 08:07:06 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean Author: sandeen Merged by: sandeen Merged mods: 2.4.x-xfs-dev:slinx:142197a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:142197a linux/fs/xfs/pagebuf/page_buf.c - 1.106 - Merge of 2.4.x-xfs-dev:slinx:142197a by sandeen. From owner-linux-xfs@oss.sgi.com Thu Mar 20 08:56:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 08:57:15 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2KGuJq9002395 for ; Thu, 20 Mar 2003 08:56:59 -0800 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2KGuEnH012332 for ; Thu, 20 Mar 2003 08:56:14 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by nodin.corp.sgi.com (8.12.8/8.11.4/nodin-1.0) with ESMTP id h2KGtD4L22208652 for ; Thu, 20 Mar 2003 08:55:13 -0800 (PST) Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA01483 for ; Thu, 20 Mar 2003 10:55:10 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2KGt8wX32124233 for ; Thu, 20 Mar 2003 10:55:08 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h2L0ARE26839 for linux-xfs@oss.sgi.com; Thu, 20 Mar 2003 19:10:27 -0500 Resent-Message-Id: <200303210010.h2L0ARE26839@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2KGpTwX13238838 for ; Thu, 20 Mar 2003 10:51:29 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.8/8.11.4/nodin-1.0) with ESMTP id h2KGpQ4L24080577 for ; Thu, 20 Mar 2003 08:51:27 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h2KGmCxD020457 for ; Thu, 20 Mar 2003 17:48:13 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h2KGmCwn020456 for hch@sgi.com; Thu, 20 Mar 2003 17:48:12 +0100 Date: Thu, 20 Mar 2003 17:48:12 +0100 From: Christoph Hellwig Message-Id: <200303201648.h2KGmCwn020456@lab343.munich.sgi.com> Subject: TAKE - Merge up to 2.5.65 To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Thu, 20 Mar 2003 19:10:26 -0500 Resent-To: linux-xfs@oss.sgi.com X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3275 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: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 49357 Lines: 1283 Date: Thu Mar 20 08:45:25 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:142205a linux/arch/arm/kernel/apm.c - 1.1 linux/drivers/i2c/busses/i2c-ali15x3.c - 1.1 linux/drivers/pci/bus.c - 1.1 linux/scripts/kconfig/gconf.glade - 1.1 linux/include/asm-ia64/sn/geo.h - 1.1 linux/arch/i386/boot/mtools.conf.in - 1.1 linux/scripts/kconfig/gconf.c - 1.1 linux/arch/ia64/sn/io/sn2/ml_iograph.c - 1.1 linux/Documentation/basic_profiling.txt - 1.1 linux/include/asm-generic/pci.h - 1.1 linux/include/asm-ia64/sn/ioconfig_bus.h - 1.1 linux/include/asm-ia64/sn/pci/pic.h - 1.1 linux/include/net/esp.h - 1.1 linux/include/media/audiochip.h - 1.1 linux/arch/ia64/sn/io/sn2/module.c - 1.1 linux/net/compat.c - 1.1 linux/drivers/char/hw_random.c - 1.1 linux/arch/ia64/sn/io/sn2/pci_bus_cvlink.c - 1.1 linux/include/net/compat_socket.h - 1.1 linux/arch/ia64/sn/io/sn2/pcibr/Makefile - 1.1 linux/include/media/id.h - 1.1 linux/Documentation/eisa.txt - 1.1 linux/arch/ia64/sn/io/sn2/pciio.c - 1.1 linux/include/asm-ia64/sn/rw_mmr.h - 1.1 linux/include/media/tuner.h - 1.1 linux/arch/m68knommu/platform/68VZ328/ucdimm/Makefile - 1.1 linux/include/asm-ia64/rwsem.h - 1.1 linux/arch/x86_64/ia32/tls32.c - 1.1 linux/Documentation/hw_random.txt - 1.1 linux/arch/arm/mach-sa1100/ssp.c - 1.1 linux/arch/arm/kernel/pm.c - 1.1 linux/net/ipv6/ah6.c - 1.1 linux/include/net/ah.h - 1.1 linux/arch/ia64/sn/io/sn2/pic.c - 1.1 linux/arch/m68knommu/platform/68VZ328/de2/Makefile - 1.1 linux/arch/ia64/sn/io/sn2/sgi_io_init.c - 1.1 linux/arch/ia64/sn/io/ioconfig_bus.c - 1.1 linux/arch/ia64/sn/io/sn2/Makefile - 1.1 linux/include/media/video-buf.h - 1.1 linux/arch/ia64/sn/io/sn2/geo_op.c - 1.1 linux/arch/ia64/sn/io/sn2/shub.c - 1.1 linux/drivers/i2c/busses/i2c-piix4.c - 1.1 linux/drivers/i2c/busses/i2c-i801.c - 1.1 linux/drivers/video/leo.c - 1.1 linux/arch/ia64/sn/io/sn2/shubio.c - 1.1 linux/arch/ia64/sn/io/sn2/xbow.c - 1.1 linux/net/ipv6/esp6.c - 1.1 linux/include/asm-ia64/sn/sn2/geo.h - 1.1 linux/arch/ia64/sn/io/sn2/klconflib.c - 1.1 linux/arch/ia64/sn/io/sn2/klgraph.c - 1.1 linux/arch/ia64/sn/kernel/sn2/sn_proc_fs.c - 1.1 linux/arch/ia64/sn/io/sn2/xtalk.c - 1.1 linux/arch/ia64/sn/io/sn2/l1.c - 1.1 linux/arch/ia64/sn/kernel/iomv.c - 1.1 linux/arch/ia64/sn/io/sn2/ml_SN_init.c - 1.1 linux/arch/ia64/sn/kernel/sn2/ptc_deadlock.S - 1.1 linux/arch/ia64/sn/io/sn2/l1_command.c - 1.1 linux/arch/m68knommu/platform/5307/timers.c - 1.1 linux/scripts/lxdialog/Makefile - 1.10 linux/scripts/Makefile - 1.18 linux/net/x25/x25_timer.c - 1.10 linux/net/x25/x25_subr.c - 1.9 linux/net/x25/x25_in.c - 1.13 linux/net/x25/af_x25.c - 1.33 linux/net/unix/af_unix.c - 1.53 linux/net/sunrpc/xprt.c - 1.40 linux/net/sunrpc/svcsock.c - 1.29 linux/net/sunrpc/sched.c - 1.37 linux/net/sunrpc/clnt.c - 1.29 linux/net/socket.c - 1.52 linux/net/rose/rose_timer.c - 1.8 linux/net/rose/rose_subr.c - 1.8 linux/net/rose/rose_route.c - 1.11 linux/net/rose/rose_in.c - 1.7 linux/net/rose/af_rose.c - 1.29 linux/net/packet/af_packet.c - 1.39 linux/net/netsyms.c - 1.63 linux/net/netrom/nr_timer.c - 1.8 linux/net/netrom/nr_subr.c - 1.7 linux/net/netrom/nr_in.c - 1.6 linux/net/netrom/af_netrom.c - 1.28 linux/net/netlink/af_netlink.c - 1.26 linux/net/irda/af_irda.c - 1.44 linux/net/ipx/af_ipx.c - 1.34 linux/net/ipv6/udp.c - 1.36 linux/net/ipv6/tcp_ipv6.c - 1.47 linux/net/ipv6/route.c - 1.30 linux/net/ipv6/raw.c - 1.31 linux/net/ipv6/ndisc.c - 1.30 linux/net/ipv6/ip6_output.c - 1.18 linux/net/ipv6/ip6_input.c - 1.14 linux/net/ipv6/icmp.c - 1.25 linux/net/ipv6/Makefile - 1.13 linux/net/ipv4/udp.c - 1.39 linux/net/ipv4/tcp_timer.c - 1.28 linux/net/ipv4/tcp_output.c - 1.36 linux/net/ipv4/tcp_ipv4.c - 1.59 linux/net/ipv4/tcp_input.c - 1.48 linux/net/ipv4/tcp.c - 1.52 linux/net/ipv4/route.c - 1.45 linux/net/ipv4/raw.c - 1.31 linux/net/ipv4/igmp.c - 1.23 linux/net/ipv4/icmp.c - 1.38 linux/net/ipv4/af_inet.c - 1.49 linux/net/core/sock.c - 1.31 linux/net/core/skbuff.c - 1.30 linux/net/core/scm.c - 1.10 linux/net/ax25/ax25_subr.c - 1.9 linux/net/ax25/ax25_std_timer.c - 1.6 linux/net/ax25/ax25_std_in.c - 1.6 linux/net/ax25/ax25_in.c - 1.13 linux/net/ax25/ax25_ds_timer.c - 1.7 linux/net/ax25/ax25_ds_in.c - 1.7 linux/net/ax25/af_ax25.c - 1.30 linux/net/appletalk/ddp.c - 1.26 linux/net/Makefile - 1.31 linux/mm/slab.c - 1.53 linux/mm/mremap.c - 1.42 linux/mm/mmap.c - 1.73 linux/mm/memory.c - 1.102 linux/mm/filemap.c - 1.151 linux/kernel/sysctl.c - 1.63 linux/kernel/sys.c - 1.49 linux/kernel/softirq.c - 1.34 linux/kernel/signal.c - 1.51 linux/kernel/sched.c - 1.96 linux/kernel/printk.c - 1.30 linux/kernel/ksyms.c - 1.185 linux/kernel/fork.c - 1.86 linux/init/main.c - 1.103 linux/include/net/tcp.h - 1.42 linux/include/net/sock.h - 1.43 linux/include/net/snmp.h - 1.12 linux/include/net/scm.h - 1.5 linux/include/net/ip6_route.h - 1.9 linux/include/net/inet_common.h - 1.7 linux/include/net/dst.h - 1.12 linux/include/linux/wanrouter.h - 1.11 linux/include/linux/wanpipe.h - 1.10 linux/include/linux/tty.h - 1.21 linux/include/linux/socket.h - 1.13 linux/include/linux/slab.h - 1.29 linux/include/linux/sdladrv.h - 1.5 linux/include/linux/sched.h - 1.100 linux/include/linux/pci.h - 1.74 linux/include/linux/nfsd/export.h - 1.17 linux/include/linux/net.h - 1.14 linux/include/linux/mm.h - 1.115 linux/include/linux/list.h - 1.25 linux/include/linux/kernel.h - 1.44 linux/include/linux/ipv6.h - 1.5 linux/include/linux/init.h - 1.26 linux/include/linux/if_shaper.h - 1.5 linux/include/linux/i2c.h - 1.20 linux/include/linux/genhd.h - 1.34 linux/include/linux/fs.h - 1.209 linux/include/linux/elf.h - 1.24 linux/include/linux/amigaffs.h - 1.14 linux/include/asm-sparc64/termios.h - 1.7 linux/include/asm-sparc64/processor.h - 1.29 linux/include/asm-sparc64/pgtable.h - 1.40 linux/include/asm-sparc64/fcntl.h - 1.17 linux/include/asm-sparc/termios.h - 1.7 linux/include/asm-sparc/processor.h - 1.22 linux/include/asm-ppc/processor.h - 1.41 linux/include/asm-ppc/pgtable.h - 1.41 linux/include/asm-mips/processor.h - 1.22 linux/include/asm-mips/pci.h - 1.15 linux/include/asm-m68k/processor.h - 1.18 linux/include/asm-i386/serial.h - 1.6 linux/include/asm-i386/processor.h - 1.50 linux/include/asm-i386/pgtable.h - 1.44 linux/include/asm-i386/msr.h - 1.19 linux/include/asm-arm/system.h - 1.26 linux/include/asm-arm/processor.h - 1.27 linux/include/asm-arm/proc-fns.h - 1.14 linux/include/asm-arm/posix_types.h - 1.6 linux/include/asm-arm/pgtable.h - 1.30 linux/include/asm-arm/ide.h - 1.10 linux/include/asm-arm/ecard.h - 1.8 linux/include/asm-alpha/processor.h - 1.19 linux/include/asm-alpha/pgtable.h - 1.39 linux/include/asm-alpha/pci.h - 1.19 linux/include/asm-alpha/core_cia.h - 1.13 linux/fs/super.c - 1.98 linux/fs/smbfs/sock.c - 1.18 linux/fs/readdir.c - 1.20 linux/fs/nfsd/vfs.c - 1.64 linux/fs/nfsd/export.c - 1.50 linux/fs/nfs/file.c - 1.41 linux/fs/ncpfs/ioctl.c - 1.19 linux/fs/namei.c - 1.67 linux/fs/locks.c - 1.38 linux/fs/lockd/svclock.c - 1.17 linux/fs/inode.c - 1.92 linux/fs/filesystems.c - 1.27 linux/fs/file_table.c - 1.30 linux/fs/ext2/super.c - 1.44 linux/fs/ext2/ioctl.c - 1.14 linux/fs/ext2/inode.c - 1.66 linux/fs/ext2/ialloc.c - 1.36 linux/fs/ext2/dir.c - 1.28 linux/fs/ext2/balloc.c - 1.28 linux/fs/dcache.c - 1.48 linux/fs/block_dev.c - 1.73 linux/fs/binfmt_elf.c - 1.52 linux/fs/affs/symlink.c - 1.17 linux/fs/affs/super.c - 1.31 linux/fs/affs/namei.c - 1.23 linux/fs/affs/inode.c - 1.25 linux/fs/affs/dir.c - 1.17 linux/fs/affs/bitmap.c - 1.12 linux/fs/affs/Changes - 1.9 linux/drivers/video/leofb.c - 1.14 linux/drivers/video/fbmem.c - 1.60 linux/drivers/video/Makefile - 1.52 linux/drivers/sgi/char/sgiserial.c - 1.15 linux/drivers/scsi/sym53c8xx.h - 1.14 linux/drivers/scsi/sym53c8xx.c - 1.42 linux/drivers/scsi/sr.c - 1.63 linux/drivers/scsi/sg.c - 1.50 linux/drivers/scsi/sd.c - 1.84 linux/drivers/scsi/scsi_error.c - 1.41 linux/drivers/scsi/scsi_debug.h - 1.13 linux/drivers/scsi/scsi_debug.c - 1.31 linux/drivers/scsi/scsi.h - 1.46 linux/drivers/scsi/scsi.c - 1.72 linux/drivers/scsi/qlogicfc.c - 1.36 linux/drivers/scsi/qlogicfas.h - 1.7 linux/drivers/scsi/qlogicfas.c - 1.21 linux/drivers/scsi/ncr53c8xx.h - 1.10 linux/drivers/scsi/ncr53c8xx.c - 1.33 linux/drivers/scsi/inia100.h - 1.15 linux/drivers/scsi/inia100.c - 1.26 linux/drivers/scsi/imm.c - 1.23 linux/drivers/scsi/i91uscsi.h - 1.5 linux/drivers/scsi/hosts.h - 1.37 linux/drivers/scsi/fdomain.h - 1.9 linux/drivers/scsi/fdomain.c - 1.30 linux/drivers/pnp/Makefile - 1.20 linux/drivers/pci/quirks.c - 1.36 linux/drivers/pci/Makefile - 1.31 linux/drivers/net/shaper.c - 1.24 linux/drivers/net/eth16i.c - 1.25 linux/drivers/net/eepro100.c - 1.57 linux/drivers/net/dgrs.c - 1.24 linux/drivers/macintosh/macserial.c - 1.26 linux/drivers/isdn/hisax/teles3.c - 1.20 linux/drivers/isdn/hisax/teles0.c - 1.17 linux/drivers/isdn/hisax/teleint.c - 1.16 linux/drivers/isdn/hisax/sportster.c - 1.16 linux/drivers/isdn/hisax/sedlbauer.c - 1.24 linux/drivers/isdn/hisax/niccy.c - 1.22 linux/drivers/isdn/hisax/mic.c - 1.15 linux/drivers/isdn/hisax/ix1_micro.c - 1.17 linux/drivers/isdn/hisax/isdnl1.h - 1.9 linux/drivers/isdn/hisax/isdnl1.c - 1.21 linux/drivers/isdn/hisax/hisax.h - 1.34 linux/drivers/isdn/hisax/elsa.c - 1.25 linux/drivers/isdn/hisax/diva.c - 1.21 linux/drivers/isdn/hisax/config.c - 1.37 linux/drivers/isdn/hisax/avm_a1.c - 1.16 linux/drivers/isdn/hisax/asuscom.c - 1.20 linux/drivers/isdn/hisax/amd7930.c - 1.17 linux/drivers/char/vt.c - 1.34 linux/drivers/char/tty_io.c - 1.65 linux/drivers/char/serial167.c - 1.18 linux/drivers/char/rtc.c - 1.38 linux/drivers/char/random.c - 1.39 linux/drivers/char/Makefile - 1.83 linux/drivers/cdrom/sonycd535.c - 1.35 linux/drivers/cdrom/sjcd.c - 1.29 linux/drivers/cdrom/sbpcd.c - 1.36 linux/drivers/cdrom/optcd.c - 1.30 linux/drivers/cdrom/mcdx.c - 1.25 linux/drivers/cdrom/mcd.c - 1.30 linux/drivers/cdrom/gscd.c - 1.30 linux/drivers/cdrom/cm206.c - 1.31 linux/drivers/cdrom/cdu31a.c - 1.27 linux/drivers/cdrom/aztcd.c - 1.32 linux/drivers/block/z2ram.c - 1.27 linux/drivers/block/xd.c - 1.52 linux/drivers/block/swim3.c - 1.27 linux/drivers/block/rd.c - 1.70 linux/drivers/block/ps2esdi.c - 1.56 linux/drivers/block/paride/pf.c - 1.35 linux/drivers/block/paride/pd.c - 1.43 linux/drivers/block/paride/pcd.c - 1.31 linux/drivers/block/nbd.c - 1.52 linux/drivers/block/loop.c - 1.80 linux/drivers/block/ll_rw_blk.c - 1.129 linux/drivers/block/genhd.c - 1.49 linux/drivers/block/floppy.c - 1.63 linux/drivers/block/ataflop.c - 1.37 linux/drivers/block/amiflop.c - 1.37 linux/drivers/block/acsi.c - 1.46 linux/drivers/acorn/net/etherh.c - 1.20 linux/drivers/acorn/net/ether3.c - 1.18 linux/drivers/acorn/net/ether1.c - 1.17 linux/drivers/acorn/block/mfmhd.c - 1.38 linux/drivers/acorn/block/fd1772.c - 1.34 linux/drivers/Makefile - 1.43 linux/arch/sparc64/solaris/socket.c - 1.12 linux/arch/sparc64/kernel/systbls.S - 1.42 linux/arch/sparc64/kernel/sys_sunos32.c - 1.45 linux/arch/sparc64/kernel/sys_sparc32.c - 1.71 linux/arch/sparc64/kernel/sys32.S - 1.9 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.54 linux/arch/sparc64/kernel/smp.c - 1.53 linux/arch/sparc64/kernel/ioctl32.c - 1.69 linux/arch/sparc64/kernel/Makefile - 1.32 linux/arch/sparc64/defconfig - 1.88 linux/arch/sparc64/boot/Makefile - 1.6 linux/arch/sparc/kernel/systbls.S - 1.30 linux/arch/sparc/kernel/sys_sunos.c - 1.41 linux/arch/sparc/kernel/pcic.c - 1.27 linux/arch/sparc/kernel/irq.c - 1.27 linux/arch/sparc/kernel/Makefile - 1.23 linux/arch/sparc/boot/Makefile - 1.14 linux/arch/sparc/Makefile - 1.25 linux/arch/ppc/mm/init.c - 1.48 linux/arch/ppc/mm/fault.c - 1.25 linux/arch/ppc/kernel/process.c - 1.49 linux/arch/ppc/kernel/ppc-stub.c - 1.13 linux/arch/ppc/kernel/pci.c - 1.33 linux/arch/ppc/kernel/irq.c - 1.44 linux/arch/ppc/kernel/Makefile - 1.38 linux/arch/ppc/Makefile - 1.38 linux/arch/ppc/8xx_io/uart.c - 1.26 linux/arch/mips/sni/pci.c - 1.13 linux/arch/mips/kernel/pci.c - 1.12 linux/arch/mips/kernel/irq.c - 1.16 linux/arch/mips/kernel/Makefile - 1.15 linux/arch/m68k/kernel/Makefile - 1.15 linux/arch/m68k/atari/stram.c - 1.25 linux/arch/i386/mm/ioremap.c - 1.21 linux/arch/i386/mm/init.c - 1.53 linux/arch/i386/mm/fault.c - 1.32 linux/arch/i386/kernel/vm86.c - 1.26 linux/arch/i386/kernel/traps.c - 1.74 linux/arch/i386/kernel/setup.c - 1.90 linux/arch/i386/kernel/process.c - 1.68 linux/arch/i386/kernel/irq.c - 1.55 linux/arch/i386/kernel/io_apic.c - 1.56 linux/arch/i386/kernel/i386_ksyms.c - 1.68 linux/arch/i386/kernel/head.S - 1.32 linux/arch/i386/kernel/entry.S - 1.76 linux/arch/i386/kernel/Makefile - 1.47 linux/arch/i386/boot/tools/build.c - 1.6 linux/arch/i386/boot/compressed/Makefile - 1.15 linux/arch/i386/boot/bootsect.S - 1.18 linux/arch/i386/boot/Makefile - 1.22 linux/arch/i386/Makefile - 1.49 linux/arch/arm/mm/fault-common.c - 1.26 linux/arch/arm/kernel/time.c - 1.24 linux/arch/arm/kernel/irq.c - 1.29 linux/arch/arm/kernel/entry-common.S - 1.24 linux/arch/arm/kernel/entry-armv.S - 1.40 linux/arch/arm/kernel/ecard.c - 1.28 linux/arch/arm/kernel/Makefile - 1.26 linux/arch/arm/boot/compressed/Makefile - 1.28 linux/arch/arm/boot/Makefile - 1.24 linux/arch/arm/Makefile - 1.43 linux/arch/alpha/mm/fault.c - 1.22 linux/arch/alpha/kernel/irq.c - 1.30 linux/arch/alpha/kernel/Makefile - 1.32 linux/arch/alpha/boot/Makefile - 1.16 linux/arch/alpha/Makefile - 1.30 linux/Makefile - 1.242 linux/MAINTAINERS - 1.135 linux/Documentation/specialix.txt - 1.3 linux/Documentation/oops-tracing.txt - 1.10 linux/Documentation/networking/wanpipe.txt - 1.6 linux/Documentation/networking/wan-router.txt - 1.6 linux/Documentation/md.txt - 1.6 linux/Documentation/magic-number.txt - 1.6 linux/Documentation/kernel-docs.txt - 1.10 linux/Documentation/isdn/INTERFACE - 1.7 linux/Documentation/ide.txt - 1.11 linux/Documentation/devices.txt - 1.15 linux/Documentation/cdrom/cdrom-standard.tex - 1.4 linux/CREDITS - 1.98 linux/net/decnet/dn_nsp_in.c - 1.19 linux/net/decnet/af_decnet.c - 1.37 linux/include/net/dn_route.h - 1.8 linux/include/linux/efs_fs.h - 1.13 linux/include/asm-i386/hdreg.h - 1.3 linux/drivers/net/sk_mca.c - 1.17 linux/drivers/isdn/hisax/telespci.c - 1.15 linux/drivers/isdn/hisax/s0box.c - 1.13 linux/drivers/isdn/hisax/avm_pci.c - 1.21 linux/drivers/isdn/hisax/avm_a1p.c - 1.13 linux/arch/i386/vmlinux.lds.S - 1.18 linux/Documentation/kernel-parameters.txt - 1.23 linux/arch/mips/dec/irq.c - 1.11 linux/arch/mips/baget/irq.c - 1.12 linux/drivers/block/cpqarray.c - 1.66 linux/Documentation/cpqarray.txt - 1.5 linux/drivers/parport/ieee1284_ops.c - 1.18 linux/drivers/parport/ieee1284.c - 1.15 linux/drivers/char/raw.c - 1.36 linux/fs/partitions/check.c - 1.65 linux/drivers/isdn/hisax/saphir.c - 1.14 linux/drivers/isdn/hisax/isurf.c - 1.17 linux/drivers/isdn/hisax/hfcscard.c - 1.14 linux/drivers/isdn/hisax/hfc_pci.c - 1.29 linux/drivers/isdn/hisax/gazel.c - 1.18 linux/drivers/isdn/hisax/bkm_a4t.c - 1.17 linux/drivers/net/sis900.c - 1.43 linux/drivers/atm/Makefile - 1.25 linux/Documentation/computone.txt - 1.8 linux/net/atm/signaling.c - 1.10 linux/net/atm/resources.h - 1.3 linux/net/atm/resources.c - 1.10 linux/net/atm/raw.c - 1.7 linux/net/atm/proc.c - 1.19 linux/net/atm/mpc.c - 1.13 linux/net/atm/lec.c - 1.19 linux/net/atm/common.h - 1.5 linux/net/atm/common.c - 1.21 linux/net/atm/clip.c - 1.15 linux/net/atm/atm_misc.c - 1.5 linux/include/linux/atmdev.h - 1.14 linux/arch/arm/vmlinux-armv.lds.in - 1.26 linux/arch/arm/vmlinux-armo.lds.in - 1.23 linux/arch/arm/kernel/bios32.c - 1.35 linux/arch/alpha/kernel/pci.c - 1.31 linux/drivers/block/DAC960.c - 1.66 linux/arch/sparc64/kernel/pci_common.c - 1.21 linux/arch/sparc64/kernel/pci.c - 1.34 linux/arch/sh/vmlinux.lds.S - 1.18 linux/arch/sh/kernel/irq.c - 1.18 linux/arch/sh/kernel/Makefile - 1.19 linux/net/irda/ircomm/ircomm_core.c - 1.19 linux/include/asm-sh/processor.h - 1.21 linux/include/asm-sh/pgtable.h - 1.27 linux/include/asm-i386/pci.h - 1.21 linux/drivers/pcmcia/tcic.c - 1.22 linux/drivers/pcmcia/i82365.c - 1.35 linux/drivers/block/swim_iop.c - 1.24 linux/arch/m68k/vmlinux-sun3.lds - 1.15 linux/include/asm-sparc64/pci.h - 1.15 linux/include/asm-ppc/pci.h - 1.18 linux/Documentation/filesystems/proc.txt - 1.18 linux/arch/i386/kernel/smpboot.c - 1.59 linux/include/linux/pci_ids.h - 1.86 linux/drivers/net/wan/sdlamain.c - 1.16 linux/drivers/net/wan/sdladrv.c - 1.10 linux/drivers/net/wan/sdla_x25.c - 1.17 linux/drivers/net/wan/sdla_ppp.c - 1.22 linux/drivers/net/wan/sdla_fr.c - 1.22 linux/Documentation/arm/Setup - 1.3 linux/include/asm-i386/pgtable-3level.h - 1.13 linux/include/asm-arm/pci.h - 1.24 linux/fs/proc/proc_misc.c - 1.57 linux/drivers/isdn/hisax/w6692.c - 1.18 linux/drivers/pci/pci.ids - 1.57 linux/Documentation/networking/sis900.txt - 1.6 linux/Documentation/networking/sk98lin.txt - 1.7 linux/drivers/net/sk98lin/h/skgepnm2.h - 1.5 linux/arch/alpha/kernel/sys_nautilus.c - 1.13 linux/Documentation/video4linux/zr36120.txt - 1.4 linux/drivers/scsi/scsi_lib.c - 1.60 linux/include/linux/i2c-id.h - 1.16 linux/drivers/i2c/i2c-algo-pcf.c - 1.14 linux/drivers/i2c/i2c-core.c - 1.23 linux/drivers/i2c/i2c-algo-bit.c - 1.16 linux/Documentation/video4linux/bttv/Sound-FAQ - 1.11 linux/drivers/sbus/char/jsflash.c - 1.28 linux/Documentation/usb/URB.txt - 1.7 linux/Documentation/usb/scanner.txt - 1.9 linux/drivers/pci/setup-res.c - 1.14 linux/drivers/pci/setup-bus.c - 1.11 linux/drivers/scsi/scsi_scan.c - 1.42 linux/drivers/net/wan/sdla_chdlc.c - 1.22 linux/drivers/char/vme_scc.c - 1.14 linux/arch/ia64/kernel/gate.S - 1.14 linux/arch/ia64/kernel/entry.S - 1.35 linux/arch/ia64/kernel/acpi.c - 1.20 linux/arch/ia64/kernel/Makefile - 1.19 linux/arch/ia64/ia32/sys_ia32.c - 1.41 linux/arch/ia64/ia32/ia32_support.c - 1.9 linux/arch/ia64/ia32/ia32_entry.S - 1.21 linux/arch/ia64/vmlinux.lds.S - 1.23 linux/arch/ia64/tools/print_offsets.c - 1.16 linux/arch/ia64/boot/Makefile - 1.10 linux/arch/ia64/Makefile - 1.25 linux/arch/ia64/kernel/init_task.c - 1.7 linux/arch/ia64/kernel/irq.c - 1.27 linux/arch/ia64/kernel/setup.c - 1.24 linux/arch/ia64/kernel/signal.c - 1.23 linux/arch/ia64/kernel/smp.c - 1.22 linux/arch/ia64/kernel/sys_ia64.c - 1.19 linux/arch/ia64/kernel/time.c - 1.20 linux/arch/ia64/kernel/traps.c - 1.19 linux/arch/ia64/kernel/unwind.c - 1.13 linux/arch/ia64/kernel/ivt.S - 1.21 linux/arch/ia64/kernel/machvec.c - 1.6 linux/arch/ia64/kernel/ptrace.c - 1.22 linux/arch/ia64/kernel/process.c - 1.26 linux/arch/ia64/kernel/perfmon.c - 1.22 linux/arch/ia64/mm/tlb.c - 1.16 linux/arch/ia64/kernel/mca.c - 1.18 linux/arch/ia64/mm/fault.c - 1.14 linux/include/asm-ia64/iosapic.h - 1.8 linux/include/asm-ia64/ide.h - 1.15 linux/include/asm-ia64/hardirq.h - 1.17 linux/include/linux/raid/md_p.h - 1.5 linux/include/asm-ia64/siginfo.h - 1.17 linux/include/linux/raid/md_k.h - 1.32 linux/include/asm-ia64/sal.h - 1.13 linux/include/asm-ia64/processor.h - 1.31 linux/include/asm-ia64/posix_types.h - 1.2 linux/include/linux/raid/md.h - 1.22 linux/include/asm-ia64/pgtable.h - 1.21 linux/include/asm-ia64/machvec.h - 1.12 linux/include/asm-ia64/machvec_dig.h - 1.5 linux/include/asm-ia64/machvec_hpsim.h - 1.5 linux/include/asm-ia64/pci.h - 1.17 linux/include/asm-ia64/page.h - 1.21 linux/include/asm-ia64/ptrace.h - 1.12 linux/include/asm-ia64/machvec_sn1.h - 1.7 linux/include/asm-ia64/spinlock.h - 1.12 linux/include/asm-ia64/unistd.h - 1.30 linux/include/asm-ia64/unwind.h - 1.6 linux/include/asm-ia64/system.h - 1.24 linux/drivers/char/amiserial.c - 1.18 linux/drivers/isdn/hisax/hfc_sx.c - 1.19 linux/arch/i386/kernel/microcode.c - 1.23 linux/Documentation/filesystems/devfs/README - 1.18 linux/include/linux/devfs_fs_kernel.h - 1.18 linux/drivers/scsi/pcmcia/qlogic_stub.c - 1.12 linux/drivers/scsi/pcmcia/fdomain_stub.c - 1.13 linux/fs/devfs/base.c - 1.53 linux/arch/mips/ddb5074/pci.c - 1.11 linux/include/asm-mips64/processor.h - 1.15 linux/include/asm-mips64/pci.h - 1.11 linux/arch/mips64/sgi-ip22/ip22-int.c - 1.10 linux/arch/mips64/sgi-ip27/ip27-pci.c - 1.8 linux/arch/mips64/sgi-ip27/ip27-irq.c - 1.12 linux/arch/mips64/kernel/scall_o32.S - 1.11 linux/arch/mips64/kernel/linux32.c - 1.17 linux/arch/mips64/kernel/Makefile - 1.10 linux/drivers/net/bonding.c - 1.19 linux/include/asm-sh/pci.h - 1.15 linux/drivers/char/sh-sci.c - 1.21 linux/net/econet/af_econet.c - 1.18 linux/include/linux/usb.h - 1.57 linux/drivers/usb/serial/usb-serial.h - 1.30 linux/drivers/usb/serial/usb-serial.c - 1.15 linux/drivers/ide/ide-probe.c - 1.50 linux/drivers/ide/ide-floppy.c - 1.43 linux/drivers/ide/ide-dma.c - 1.37 linux/drivers/ide/ide-disk.c - 1.55 linux/drivers/ide/Makefile - 1.35 linux/net/ipv4/netfilter/iptable_mangle.c - 1.12 linux/net/ipv4/netfilter/iptable_filter.c - 1.7 linux/net/ipv4/netfilter/ip_nat_standalone.c - 1.21 linux/net/ipv4/netfilter/ip_nat_rule.c - 1.10 linux/net/ipv4/netfilter/ip_fw_compat.c - 1.15 linux/net/ipv4/netfilter/ip_conntrack_standalone.c - 1.19 linux/include/linux/netfilter_ipv4/ipchains_core.h - 1.2 linux/include/asm-arm/arch-shark/time.h - 1.9 linux/drivers/video/sa1100fb.c - 1.22 linux/drivers/usb/serial/visor.h - 1.16 linux/drivers/usb/serial/visor.c - 1.51 linux/drivers/net/pppoe.c - 1.27 linux/drivers/char/rio/riotty.c - 1.8 linux/drivers/char/rio/riotable.c - 1.8 linux/drivers/char/rio/rioroute.c - 1.7 linux/drivers/char/rio/rioparam.c - 1.5 linux/drivers/char/rio/riointr.c - 1.6 linux/drivers/char/rio/rioinit.c - 1.7 linux/drivers/char/rio/rioctrl.c - 1.10 linux/drivers/char/rio/riocmd.c - 1.9 linux/drivers/char/rio/rioboot.c - 1.8 linux/drivers/char/rio/rio_linux.c - 1.20 linux/include/linux/raid/raid5.h - 1.12 linux/include/linux/raid/raid1.h - 1.14 linux/arch/s390/boot/Makefile - 1.12 linux/arch/s390/Makefile - 1.16 linux/arch/s390/kernel/Makefile - 1.13 linux/drivers/s390/char/con3215.c - 1.13 linux/include/asm-s390/processor.h - 1.14 linux/include/asm-s390/pgtable.h - 1.18 linux/Documentation/s390/cds.txt - 1.10 linux/include/asm-arm/arch-sa1100/time.h - 1.8 linux/net/ipv6/netfilter/ip6table_filter.c - 1.6 linux/Documentation/kernel-doc-nano-HOWTO.txt - 1.6 linux/include/linux/profile.h - 1.6 linux/drivers/char/i810_rng.c - 1.12 linux/drivers/usb/storage/transport.h - 1.17 linux/drivers/usb/storage/transport.c - 1.40 linux/arch/alpha/kernel/core_titan.c - 1.10 linux/drivers/usb/serial/keyspan_usa28msg.h - 1.5 linux/drivers/usb/serial/keyspan_usa26msg.h - 1.6 linux/include/asm-i386/i387.h - 1.8 linux/arch/i386/kernel/i387.c - 1.13 linux/arch/ia64/ia32/ia32_ioctl.c - 1.8 linux/arch/ia64/kernel/palinfo.c - 1.12 linux/arch/ia64/kernel/unwind_i.h - 1.6 linux/drivers/mtd/ftl.c - 1.33 linux/drivers/mtd/mtdblock.c - 1.31 linux/net/ipv4/tcp_minisocks.c - 1.23 linux/drivers/usb/storage/sddr09.c - 1.22 linux/drivers/media/video/zr36120.c - 1.17 linux/drivers/media/video/tvmixer.c - 1.13 linux/drivers/media/video/tuner.h - 1.10 linux/drivers/media/video/tuner.c - 1.15 linux/drivers/media/video/tuner-3036.c - 1.6 linux/drivers/media/video/tda9875.c - 1.11 linux/drivers/media/video/tda7432.c - 1.11 linux/drivers/media/video/planb.c - 1.14 linux/drivers/media/video/msp3400.c - 1.16 linux/Documentation/networking/tuntap.txt - 1.5 linux/drivers/media/video/bw-qcam.c - 1.12 linux/drivers/media/video/bttv-if.c - 1.10 linux/drivers/media/video/bttv-driver.c - 1.28 linux/drivers/media/video/bttv-cards.c - 1.18 linux/drivers/media/video/audiochip.h - 1.4 linux/drivers/isdn/hisax/nj_u.c - 1.14 linux/drivers/isdn/hisax/nj_s.c - 1.15 linux/arch/arm/boot/bootp/Makefile - 1.8 linux/arch/arm/tools/mach-types - 1.23 linux/drivers/md/raid1.c - 1.31 linux/drivers/md/raid5.c - 1.41 linux/Documentation/kbuild/makefiles.txt - 1.9 linux/arch/arm/mach-sa1100/Makefile - 1.19 linux/drivers/block/cciss.c - 1.53 linux/drivers/block/cciss.h - 1.19 linux/drivers/md/linear.c - 1.19 linux/drivers/md/md.c - 1.71 linux/drivers/md/raid0.c - 1.17 linux/drivers/usb/serial/belkin_sa.c - 1.29 linux/drivers/media/video/tvaudio.c - 1.15 linux/drivers/media/video/id.h - 1.4 linux/drivers/media/video/bttvp.h - 1.12 linux/include/asm-generic/xor.h - 1.3 linux/include/asm-i386/cpufeature.h - 1.6 linux/include/asm-i386/xor.h - 1.10 linux/Documentation/arm/SA1100/serial_UART - 1.3 linux/drivers/usb/serial/keyspan_usa49msg.h - 1.5 linux/include/asm-parisc/pci.h - 1.7 linux/include/asm-parisc/pgtable.h - 1.10 linux/include/asm-parisc/processor.h - 1.10 linux/arch/parisc/kernel/syscall.S - 1.8 linux/arch/i386/kernel/dmi_scan.c - 1.26 linux/include/asm-m68k/sun3_pgtable.h - 1.4 linux/arch/parisc/kernel/pci.c - 1.6 linux/arch/parisc/kernel/Makefile - 1.10 linux/arch/parisc/Makefile - 1.13 linux/drivers/atm/firestream.c - 1.15 linux/Documentation/DocBook/sis900.tmpl - 1.3 linux/drivers/scsi/osst.c - 1.24 linux/arch/ia64/kernel/iosapic.c - 1.15 linux/include/asm-ia64/sn/module.h - 1.5 linux/arch/ia64/sn/io/Makefile - 1.10 linux/fs/reiserfs/journal.c - 1.40 linux/net/ipv6/netfilter/ip6table_mangle.c - 1.6 linux/include/asm-s390x/processor.h - 1.11 linux/include/asm-s390x/pgtable.h - 1.15 linux/include/asm-s390x/fcntl.h - 1.3 linux/arch/s390x/kernel/linux32.h - 1.7 linux/arch/s390x/kernel/linux32.c - 1.26 linux/arch/cris/kernel/Makefile - 1.15 linux/arch/cris/kernel/irq.c - 1.11 linux/arch/s390x/kernel/entry.S - 1.22 linux/arch/s390x/kernel/Makefile - 1.13 linux/drivers/s390/block/xpram.c - 1.31 linux/arch/s390x/kernel/wrapper32.S - 1.14 linux/drivers/s390/block/dasd_3990_erp.c - 1.13 linux/drivers/pcmcia/hd64465_ss.c - 1.10 linux/include/asm-cris/processor.h - 1.13 linux/arch/s390x/boot/Makefile - 1.12 linux/arch/s390x/Makefile - 1.17 linux/Documentation/i810_rng.txt - 1.7 linux/drivers/usb/serial/io_ionsp.h - 1.3 linux/drivers/usb/serial/io_edgeport.c - 1.33 linux/drivers/scsi/aic7xxx/aicasm/Makefile - 1.7 linux/arch/arm/mach-integrator/Makefile - 1.7 linux/drivers/net/wan/sdla_ft1.c - 1.6 linux/drivers/net/wan/wanpipe_multppp.c - 1.10 linux/drivers/s390/char/tuball.c - 1.8 linux/net/wanrouter/af_wanpipe.c - 1.14 linux/Documentation/s390/Debugging390.txt - 1.9 linux/arch/sh/kernel/pci_st40.c - 1.7 linux/include/asm-ia64/perfmon.h - 1.9 linux/arch/mips/mips-boards/generic/pci.c - 1.6 linux/arch/mips/mips-boards/atlas/atlas_int.c - 1.5 linux/arch/mips/ite-boards/generic/it8172_pci.c - 1.5 linux/arch/mips/ite-boards/generic/irq.c - 1.7 linux/arch/mips/ddb5476/pci.c - 1.6 linux/arch/mips/arc/arc_con.c - 1.2 linux/include/linux/compiler.h - 1.9 linux/include/linux/if_wanpipe.h - 1.4 linux/include/linux/if_wanpipe_common.h - 1.4 linux/Documentation/usb/philips.txt - 1.7 linux/fs/char_dev.c - 1.7 linux/arch/ppc/boot/images/Makefile - 1.6 linux/include/net/bluetooth/bluetooth.h - 1.9 linux/net/bluetooth/af_bluetooth.c - 1.12 linux/net/bluetooth/hci_sock.c - 1.12 linux/drivers/mtd/nftlcore.c - 1.30 linux/drivers/mtd/mtdblock_ro.c - 1.17 linux/drivers/media/radio/miropcm20-rds.c - 1.5 linux/drivers/usb/serial/pl2303.h - 1.8 linux/drivers/usb/serial/cyberjack.c - 1.23 linux/drivers/usb/serial/pl2303.c - 1.29 linux/arch/sh/kernel/pci-sh7751.c - 1.7 linux/arch/sh/kernel/pci-dc.c - 1.5 linux/arch/mips/kernel/old-irq.c - 1.6 linux/drivers/media/video/zoran.h - 1.2 linux/Documentation/sonypi.txt - 1.11 linux/drivers/usb/usb-skeleton.c - 1.22 linux/fs/partitions/ldm.c - 1.11 linux/drivers/usb/storage/isd200.c - 1.14 linux/arch/ia64/kernel/sigframe.h - 1.4 linux/include/asm-arm/arch-anakin/time.h - 1.4 linux/arch/arm/mach-integrator/cpu.c - 1.12 linux/arch/arm/mach-sa1100/irq.c - 1.12 linux/arch/arm/mach-sa1100/cpu-sa1100.c - 1.11 linux/arch/arm/mach-sa1100/cpu-sa1110.c - 1.13 linux/arch/arm/mach-sa1100/generic.h - 1.6 linux/arch/arm/mach-sa1100/generic.c - 1.13 linux/drivers/char/serial_tx3912.c - 1.8 linux/arch/sh/kernel/pcibios.c - 1.3 linux/arch/mips64/sgi-ip32/ip32-pci.c - 1.4 linux/arch/mips/au1000/common/serial.c - 1.9 linux/arch/mips64/mips-boards/generic/pci.c - 1.4 linux/arch/mips64/sgi-ip32/Makefile - 1.6 linux/arch/mips/ddb5xxx/common/pci.c - 1.5 linux/arch/mips/gt64120/common/pci.c - 1.5 linux/arch/mips/philips/nino/irq.c - 1.5 linux/arch/mips64/mips-boards/malta/malta_int.c - 1.4 linux/arch/mips64/mips-boards/atlas/atlas_int.c - 1.4 linux/drivers/char/decserial.c - 1.2 linux/Documentation/input/ff.txt - 1.4 linux/Documentation/usb/hiddev.txt - 1.5 linux/include/linux/raid/multipath.h - 1.7 linux/drivers/md/multipath.c - 1.18 linux/drivers/usb/serial/ir-usb.c - 1.26 linux/drivers/pcmcia/sa1100_generic.c - 1.15 linux/drivers/i2c/i2c-proc.c - 1.12 linux/drivers/message/i2o/i2o_block.c - 1.31 linux/arch/arm/mach-sa1100/pm.c - 1.9 linux/net/8021q/vlanproc.c - 1.8 linux/Documentation/networking/ifenslave.c - 1.5 linux/Documentation/networking/bonding.txt - 1.8 linux/drivers/scsi/sym53c8xx_2/sym_hipd.c - 1.7 linux/fs/ext3/ialloc.c - 1.23 linux/fs/ext3/inode.c - 1.34 linux/fs/ext3/ioctl.c - 1.7 linux/fs/ext3/super.c - 1.31 linux/fs/intermezzo/file.c - 1.7 linux/drivers/hotplug/cpqphp_pci.c - 1.10 linux/fs/intermezzo/methods.c - 1.8 linux/fs/intermezzo/super.c - 1.11 linux/include/linux/ext3_fs.h - 1.16 linux/fs/seq_file.c - 1.8 linux/fs/ext3/dir.c - 1.9 linux/fs/intermezzo/cache.c - 1.9 linux/fs/intermezzo/dir.c - 1.10 linux/include/linux/bio.h - 1.19 linux/drivers/isdn/hisax/hisax_fcpcipnp.c - 1.12 linux/include/linux/device.h - 1.29 linux/drivers/isdn/hisax/hisax_isac.h - 1.4 linux/drivers/isdn/hisax/hisax_isac.c - 1.5 linux/init/do_mounts.c - 1.26 linux/arch/arm/mach-sa1100/system3.c - 1.14 linux/arch/arm/mach-arc/Makefile - 1.6 linux/drivers/ide/ide-taskfile.c - 1.27 linux/fs/ext2/ext2.h - 1.11 linux/drivers/isdn/hisax/hisax_fcclassic.c - 1.3 linux/include/asm-i386/thread_info.h - 1.9 linux/Documentation/filesystems/directory-locking - 1.4 linux/sound/pci/intel8x0.c - 1.15 linux/arch/ppc/boot/common/util.S - 1.5 linux/sound/pci/ac97/ac97_codec.c - 1.14 linux/arch/ppc/boot/simple/head.S - 1.5 linux/arch/ppc/boot/simple/rw4/ppc_40x.h - 1.3 linux/sound/oss/trident.c - 1.12 linux/sound/oss/sb_card.c - 1.5 linux/arch/ppc/platforms/lopec_setup.c - 1.12 linux/arch/x86_64/Makefile - 1.16 linux/arch/x86_64/boot/Makefile - 1.13 linux/arch/x86_64/boot/compressed/Makefile - 1.7 linux/arch/x86_64/boot/setup.S - 1.4 linux/arch/x86_64/ia32/Makefile - 1.11 linux/arch/x86_64/ia32/ia32_signal.c - 1.11 linux/arch/x86_64/ia32/ia32entry.S - 1.10 linux/arch/x86_64/ia32/ptrace32.c - 1.5 linux/arch/x86_64/ia32/socket32.c - 1.4 linux/arch/x86_64/ia32/sys_ia32.c - 1.16 linux/arch/x86_64/kernel/Makefile - 1.16 linux/arch/x86_64/kernel/apic.c - 1.13 linux/arch/x86_64/kernel/head64.c - 1.6 linux/arch/x86_64/kernel/io_apic.c - 1.7 linux/arch/x86_64/kernel/irq.c - 1.9 linux/arch/x86_64/kernel/process.c - 1.16 linux/arch/x86_64/kernel/ptrace.c - 1.10 linux/arch/x86_64/kernel/setup64.c - 1.11 linux/arch/x86_64/kernel/signal.c - 1.12 linux/arch/x86_64/kernel/time.c - 1.11 linux/arch/x86_64/lib/getuser.S - 1.2 linux/sound/isa/als100.c - 1.8 linux/include/asm-x86_64/segment.h - 1.7 linux/include/asm-x86_64/ptrace.h - 1.7 linux/include/asm-x86_64/processor.h - 1.12 linux/include/asm-x86_64/pgtable.h - 1.13 linux/include/asm-x86_64/pci.h - 1.5 linux/include/asm-x86_64/ia32.h - 1.9 linux/include/asm-x86_64/fcntl.h - 1.2 linux/include/asm-x86_64/desc.h - 1.7 linux/include/asm-x86_64/socket32.h - 1.4 linux/include/asm-x86_64/unistd.h - 1.13 linux/include/asm-x86_64/uaccess.h - 1.7 linux/include/asm-ppc64/fcntl.h - 1.3 linux/arch/ppc64/Makefile - 1.17 linux/arch/ppc64/boot/Makefile - 1.10 linux/arch/ppc64/boot/main.c - 1.5 linux/arch/ppc64/kernel/Makefile - 1.16 linux/arch/ppc64/kernel/chrp_setup.c - 1.11 linux/arch/ppc64/kernel/eeh.c - 1.7 linux/arch/ppc64/kernel/entry.S - 1.16 linux/arch/ppc64/kernel/head.S - 1.12 linux/arch/ppc64/kernel/htab.c - 1.11 linux/arch/ppc64/kernel/irq.c - 1.10 linux/arch/ppc64/kernel/misc.S - 1.17 linux/arch/ppc64/kernel/pSeries_pci.c - 1.10 linux/arch/ppc64/kernel/pci.c - 1.11 linux/arch/ppc64/kernel/pci.h - 1.5 linux/arch/ppc64/kernel/pci_dma.c - 1.8 linux/arch/ppc64/kernel/prom.c - 1.11 linux/arch/ppc64/kernel/rtc.c - 1.6 linux/arch/ppc64/kernel/sys32.S - 1.9 linux/arch/ppc64/kernel/sys_ppc32.c - 1.18 linux/arch/ppc64/mm/extable.c - 1.6 linux/arch/ppc64/xmon/xmon.c - 1.11 linux/include/asm-ppc64/processor.h - 1.14 linux/include/asm-ppc64/pci.h - 1.4 linux/include/asm-ppc64/pci-bridge.h - 1.5 linux/Documentation/arm/mem_alignment - 1.2 linux/Documentation/networking/3c359.txt - 1.2 linux/drivers/hotplug/ibmphp_core.c - 1.12 linux/fs/jfs/jfs_logmgr.c - 1.25 linux/fs/jfs/jfs_txnmgr.c - 1.24 linux/drivers/net/e100/e100_main.c - 1.16 linux/Documentation/sound/oss/NEWS - 1.2 linux/Documentation/sound/oss/PSS-updates - 1.3 linux/Documentation/sound/oss/cs46xx - 1.2 linux/Documentation/ia64/IRQ-redir.txt - 1.2 linux/arch/ia64/sn/kernel/sn2/Makefile - 1.7 linux/arch/ia64/sn/kernel/setup.c - 1.7 linux/arch/ia64/sn/kernel/mca.c - 1.4 linux/include/asm-ia64/thread_info.h - 1.5 linux/include/asm-ia64/machvec_sn2.h - 1.4 linux/Documentation/networking/NAPI_HOWTO.txt - 1.4 linux/drivers/media/video/video-buf.h - 1.6 linux/net/ipv4/netfilter/arptable_filter.c - 1.3 linux/drivers/media/video/video-buf.c - 1.8 linux/drivers/net/wan/comx-hw-munich.c - 1.9 linux/drivers/usb/class/bluetty.c - 1.16 linux/drivers/usb/class/cdc-acm.c - 1.16 linux/drivers/usb/core/hub.c - 1.21 linux/drivers/usb/input/hid-core.c - 1.16 linux/drivers/usb/core/usb.c - 1.29 linux/drivers/usb/media/konicawc.c - 1.11 linux/drivers/usb/host/ohci-q.c - 1.21 linux/drivers/usb/image/hpusbscsi.c - 1.11 linux/drivers/usb/image/hpusbscsi.h - 1.4 linux/drivers/usb/image/scanner.c - 1.19 linux/drivers/usb/image/scanner.h - 1.13 linux/drivers/usb/input/hid-input.c - 1.8 linux/drivers/usb/input/hid.h - 1.8 linux/drivers/usb/media/dsbr100.c - 1.7 linux/drivers/usb/media/pwc-ctrl.c - 1.5 linux/drivers/usb/media/pwc-if.c - 1.9 linux/drivers/usb/media/pwc-uncompress.c - 1.3 linux/drivers/usb/media/pwc.h - 1.5 linux/drivers/usb/media/se401.c - 1.13 linux/drivers/usb/net/usbnet.c - 1.17 linux/drivers/usb/media/vicam.c - 1.11 linux/mm/readahead.c - 1.17 linux/mm/pdflush.c - 1.13 linux/drivers/usb/misc/auerswald.c - 1.14 linux/Documentation/filesystems/Exporting - 1.2 linux/include/asm-ia64/machvec_hpzx1.h - 1.4 linux/drivers/isdn/i4l/isdn_ppp.c - 1.13 linux/fs/exportfs/expfs.c - 1.8 linux/include/asm-arm/proc-armv/tlbflush.h - 1.3 linux/arch/ia64/hp/sim/simserial.c - 1.9 linux/arch/ia64/hp/sim/simscsi.c - 1.9 linux/drivers/isdn/hardware/avm/b1pci.c - 1.6 linux/scripts/mkcompile_h - 1.8 linux/drivers/block/umem.c - 1.19 linux/Documentation/networking/3c509.txt - 1.2 linux/drivers/usb/host/uhci-hcd.c - 1.17 linux/drivers/net/wan/pc300_tty.c - 1.5 linux/arch/i386/pci/common.c - 1.8 linux/arch/i386/pci/i386.c - 1.4 linux/arch/i386/pci/irq.c - 1.4 linux/drivers/pci/probe.c - 1.14 linux/net/bluetooth/sco.c - 1.7 linux/net/bluetooth/l2cap.c - 1.8 linux/mm/page-writeback.c - 1.20 linux/init/Makefile - 1.16 linux/include/linux/writeback.h - 1.12 linux/include/linux/jiffies.h - 1.5 linux/Documentation/block/biodoc.txt - 1.4 linux/Documentation/swsusp.txt - 1.4 linux/drivers/base/bus.c - 1.14 linux/drivers/usb/host/hc_simple.c - 1.7 linux/drivers/usb/host/hc_simple.h - 1.2 linux/drivers/usb/host/hc_sl811.h - 1.2 linux/drivers/char/hvc_console.c - 1.9 linux/drivers/usb/core/urb.c - 1.10 linux/drivers/usb/core/message.c - 1.15 linux/drivers/isdn/hisax/enternow_pci.c - 1.7 linux/drivers/usb/class/usb-midi.c - 1.10 linux/drivers/usb/class/usb-midi.h - 1.4 linux/drivers/usb/host/ohci-pci.c - 1.7 linux/arch/i386/kernel/cpu/proc.c - 1.7 linux/drivers/s390/block/dasd_genhd.c - 1.14 linux/arch/i386/kernel/cpu/centaur.c - 1.6 linux/arch/i386/kernel/cpu/common.c - 1.12 linux/arch/x86_64/pci/x86-64.c - 1.3 linux/arch/x86_64/pci/irq.c - 1.4 linux/arch/x86_64/pci/legacy.c - 1.3 linux/arch/x86_64/pci/pci.h - 1.4 linux/arch/x86_64/pci/direct.c - 1.4 linux/include/asm-x86_64/suspend.h - 1.3 linux/net/llc/llc_conn.c - 1.8 linux/drivers/message/fusion/lsi/mpi_raid.h - 1.3 linux/security/dummy.c - 1.9 linux/security/capability.c - 1.8 linux/drivers/serial/clps711x.c - 1.8 linux/drivers/usb/serial/io_ti.c - 1.9 linux/drivers/serial/uart00.c - 1.9 linux/drivers/serial/sa1100.c - 1.7 linux/drivers/serial/core.c - 1.10 linux/drivers/serial/anakin.c - 1.8 linux/drivers/serial/amba.c - 1.9 linux/drivers/serial/8250_pci.c - 1.7 linux/drivers/serial/8250.h - 1.3 linux/drivers/serial/8250.c - 1.14 linux/arch/i386/mm/pgtable.c - 1.7 linux/drivers/serial/21285.c - 1.8 linux/include/linux/serial_core.h - 1.11 linux/include/linux/security.h - 1.8 linux/drivers/usb/misc/speedtouch.c - 1.13 linux/fs/aio.c - 1.11 linux/arch/alpha/vmlinux.lds.S - 1.8 linux/drivers/i2c/i2c-algo-ibm_ocp.c - 1.5 linux/include/linux/aio.h - 1.4 linux/arch/mips64/vmlinux.lds.S - 1.3 linux/net/sctp/ulpqueue.c - 1.6 linux/arch/i386/mm/discontig.c - 1.7 linux/arch/i386/kernel/numaq.c - 1.6 linux/include/asm-i386/mmzone.h - 1.7 linux/include/asm-i386/numaq.h - 1.7 linux/drivers/ide/pci/via82cxxx.c - 1.7 linux/drivers/ide/pci/amd74xx.c - 1.11 linux/drivers/ide/legacy/hd.c - 1.11 linux/drivers/ide/ide-lib.c - 1.7 linux/arch/um/drivers/stdio_console.c - 1.6 linux/arch/um/drivers/ubd_kern.c - 1.10 linux/arch/um/kernel/mem.c - 1.8 linux/drivers/ide/ide-iops.c - 1.5 linux/include/asm-um/pgtable.h - 1.7 linux/arch/um/sys-i386/util/Makefile - 1.4 linux/arch/um/util/Makefile - 1.6 linux/arch/m68k/vmlinux-std.lds - 1.6 linux/arch/ppc64/vmlinux.lds.S - 1.6 linux/arch/x86_64/vmlinux.lds.S - 1.8 linux/arch/sparc64/vmlinux.lds.S - 1.8 linux/arch/sparc/vmlinux.lds.S - 1.9 linux/arch/s390x/vmlinux.lds.S - 1.9 linux/arch/cris/vmlinux.lds.S - 1.4 linux/arch/ppc/vmlinux.lds.S - 1.8 linux/arch/s390/vmlinux.lds.S - 1.9 linux/arch/mips/vmlinux.lds.S - 1.4 linux/arch/parisc/vmlinux.lds.S - 1.7 linux/Documentation/driver-model/driver.txt - 1.4 linux/Documentation/driver-model/platform.txt - 1.2 linux/net/bridge/netfilter/ebtables.c - 1.5 linux/net/bridge/netfilter/ebtable_nat.c - 1.3 linux/net/bridge/netfilter/ebtable_filter.c - 1.3 linux/net/bridge/netfilter/ebtable_broute.c - 1.3 linux/net/bridge/netfilter/ebt_vlan.c - 1.3 linux/net/bridge/netfilter/ebt_snat.c - 1.2 linux/net/bridge/netfilter/ebt_redirect.c - 1.2 linux/net/bridge/netfilter/ebt_mark_m.c - 1.2 linux/net/bridge/netfilter/ebt_mark.c - 1.2 linux/net/bridge/netfilter/ebt_log.c - 1.3 linux/net/bridge/netfilter/ebt_ip.c - 1.3 linux/drivers/base/platform.c - 1.5 linux/net/bridge/netfilter/ebt_dnat.c - 1.2 linux/net/bridge/netfilter/ebt_arp.c - 1.2 linux/arch/ia64/pci/pci.c - 1.4 linux/arch/ia64/mm/hugetlbpage.c - 1.7 linux/drivers/block/deadline-iosched.c - 1.8 linux/include/linux/netfilter_bridge/ebt_ip.h - 1.3 linux/include/linux/netfilter_bridge/ebt_log.h - 1.2 linux/include/linux/netfilter_bridge/ebt_redirect.h - 1.2 linux/include/linux/netfilter_bridge/ebtables.h - 1.3 linux/include/linux/netfilter_bridge/ebt_nat.h - 1.2 linux/include/linux/netfilter_bridge/ebt_mark_t.h - 1.2 linux/Documentation/vm/hugetlbpage.txt - 1.5 linux/include/asm-ia64/topology.h - 1.6 linux/include/asm-ppc64/topology.h - 1.5 linux/kernel/cpufreq.c - 1.10 linux/net/llc/af_llc.c - 1.5 linux/include/linux/cpufreq.h - 1.11 linux/arch/i386/kernel/cpu/cpufreq/powernow-k6.c - 1.8 linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c - 1.9 linux/arch/i386/kernel/cpu/cpufreq/speedstep.c - 1.10 linux/arch/i386/kernel/cpu/cpufreq/elanfreq.c - 1.8 linux/arch/i386/kernel/cpu/cpufreq/longrun.c - 1.8 linux/arch/i386/kernel/cpu/cpufreq/longhaul.c - 1.8 linux/Documentation/filesystems/ext3.txt - 1.3 linux/drivers/char/amd768_rng.c - 1.4 linux/drivers/scsi/aacraid/linit.c - 1.9 linux/drivers/isdn/i4l/isdn_net_lib.c - 1.6 linux/net/bluetooth/rfcomm/sock.c - 1.7 linux/net/bluetooth/rfcomm/core.c - 1.8 linux/net/bluetooth/bnep/core.c - 1.7 linux/Documentation/DocBook/journal-api.tmpl - 1.6 linux/fs/cifs/TODO - 1.4 linux/fs/cifs/cifs_debug.c - 1.6 linux/fs/cifs/cifs_fs_sb.h - 1.2 linux/net/sunrpc/svcauth_unix.c - 1.6 linux/fs/cifs/cifsfs.c - 1.7 linux/fs/cifs/cifssmb.c - 1.8 linux/fs/cifs/connect.c - 1.7 linux/fs/cifs/file.c - 1.7 linux/fs/cifs/misc.c - 1.5 linux/fs/cifs/CHANGES - 1.6 linux/fs/cifs/transport.c - 1.5 linux/include/linux/sunrpc/cache.h - 1.5 linux/drivers/oprofile/buffer_sync.c - 1.8 linux/drivers/oprofile/cpu_buffer.c - 1.5 linux/drivers/oprofile/cpu_buffer.h - 1.4 linux/drivers/oprofile/oprofile_stats.c - 1.3 linux/drivers/serial/8250_acorn.c - 1.3 linux/include/asm-x86_64/proto.h - 1.8 linux/arch/i386/oprofile/nmi_int.c - 1.7 linux/arch/i386/oprofile/op_model_athlon.c - 1.5 linux/arch/i386/oprofile/op_model_ppro.c - 1.5 linux/fs/intermezzo/replicator.c - 1.3 linux/fs/intermezzo/fileset.c - 1.3 linux/Documentation/filesystems/sysfs.txt - 1.4 linux/arch/x86_64/mm/pageattr.c - 1.4 linux/scripts/Makefile.clean - 1.5 linux/Documentation/pnp.txt - 1.3 linux/drivers/pnp/resource.c - 1.7 linux/drivers/pnp/driver.c - 1.7 linux/fs/sysfs/inode.c - 1.9 linux/drivers/pnp/system.c - 1.5 linux/drivers/pnp/isapnp/core.c - 1.8 linux/drivers/pnp/interface.c - 1.8 linux/include/linux/pnp.h - 1.8 linux/Documentation/crypto/api-intro.txt - 1.6 linux/Documentation/kobject.txt - 1.4 linux/arch/alpha/Kconfig - 1.9 linux/arch/arm/Kconfig - 1.8 linux/scripts/kconfig/zconf.y - 1.3 linux/scripts/kconfig/zconf.tab.c_shipped - 1.4 linux/scripts/kconfig/zconf.l - 1.4 linux/scripts/kconfig/symbol.c - 1.3 linux/scripts/kconfig/qconf.h - 1.3 linux/scripts/kconfig/qconf.cc - 1.4 linux/scripts/kconfig/menu.c - 1.3 linux/scripts/kconfig/mconf.c - 1.4 linux/arch/arm/mach-sa1100/Kconfig - 1.3 linux/arch/cris/Kconfig - 1.6 linux/arch/i386/Kconfig - 1.14 linux/scripts/kconfig/lex.zconf.c_shipped - 1.4 linux/scripts/kconfig/images.c - 1.2 linux/scripts/kconfig/expr.h - 1.4 linux/include/linux/crypto.h - 1.5 linux/arch/ia64/Kconfig - 1.7 linux/scripts/kconfig/Makefile - 1.5 linux/scripts/Makefile.lib - 1.6 linux/scripts/Makefile.build - 1.9 linux/drivers/char/Kconfig - 1.6 linux/arch/m68k/Kconfig - 1.9 linux/arch/mips/Kconfig - 1.7 linux/arch/mips64/Kconfig - 1.7 linux/arch/parisc/Kconfig - 1.8 linux/include/asm-ia64/mmzone.h - 1.4 linux/drivers/pnp/Kconfig - 1.4 linux/arch/parisc/kernel/sys_parisc32.c - 1.8 linux/drivers/md/dm.c - 1.5 linux/drivers/scsi/Kconfig - 1.9 linux/drivers/isdn/i4l/Kconfig - 1.3 linux/arch/ppc/Kconfig - 1.7 linux/arch/ppc64/Kconfig - 1.8 linux/arch/s390/Kconfig - 1.7 linux/net/ipv4/ah.c - 1.6 linux/arch/s390x/Kconfig - 1.8 linux/arch/sh/Kconfig - 1.7 linux/drivers/hotplug/acpiphp_glue.c - 1.7 linux/arch/sparc/Kconfig - 1.9 linux/drivers/scsi/pcmcia/Kconfig - 1.4 linux/drivers/isdn/i4l/isdn_ppp_mp.h - 1.2 linux/drivers/isdn/i4l/isdn_ppp_mp.c - 1.2 linux/arch/sparc64/Kconfig - 1.9 linux/arch/um/Kconfig - 1.5 linux/arch/x86_64/Kconfig - 1.11 linux/fs/Kconfig - 1.10 linux/crypto/api.c - 1.5 linux/crypto/cipher.c - 1.5 linux/crypto/digest.c - 1.5 linux/crypto/internal.h - 1.5 linux/net/ipv4/xfrm_policy.c - 1.7 linux/drivers/serial/Kconfig - 1.5 linux/net/ipv4/xfrm_input.c - 1.4 linux/net/ipv4/xfrm_state.c - 1.5 linux/net/ipv6/Kconfig - 1.3 linux/include/linux/usb_ch9.h - 1.2 linux/include/net/xfrm.h - 1.7 linux/init/Kconfig - 1.7 linux/usr/gen_init_cpio.c - 1.2 linux/usr/Makefile - 1.3 linux/fs/mbcache.c - 1.4 linux/fs/ext3/xattr.c - 1.5 linux/fs/ext2/xattr.c - 1.5 linux/mm/fremap.c - 1.4 linux/include/linux/hugetlb.h - 1.7 linux/drivers/net/mac8390.c - 1.5 linux/drivers/media/video/saa7134/saa7134.h - 1.4 linux/drivers/media/video/saa7134/saa7134-video.c - 1.4 linux/drivers/media/video/saa7134/saa7134-i2c.c - 1.5 linux/drivers/media/video/saa7134/saa7134-core.c - 1.3 linux/drivers/media/video/saa7134/saa7134-cards.c - 1.4 linux/include/asm-m68knommu/pci.h - 1.2 linux/include/asm-m68knommu/processor.h - 1.3 linux/arch/m68knommu/Kconfig - 1.7 linux/arch/m68knommu/Makefile - 1.4 linux/arch/m68knommu/kernel/comempci.c - 1.3 linux/arch/m68knommu/kernel/signal.c - 1.7 linux/arch/m68knommu/platform/5206/Makefile - 1.3 linux/arch/m68knommu/platform/5206/config.c - 1.2 linux/arch/m68knommu/platform/5206e/Makefile - 1.3 linux/arch/m68knommu/platform/5206e/config.c - 1.2 linux/arch/m68knommu/platform/5249/Makefile - 1.3 linux/arch/m68knommu/platform/5249/config.c - 1.2 linux/arch/m68knommu/platform/5272/Makefile - 1.3 linux/arch/m68knommu/platform/5272/config.c - 1.2 linux/arch/m68knommu/platform/5307/Makefile - 1.3 linux/arch/m68knommu/platform/5307/config.c - 1.2 linux/arch/m68knommu/platform/5407/Makefile - 1.3 linux/arch/m68knommu/platform/5407/config.c - 1.2 linux/arch/m68knommu/platform/68328/Makefile - 1.3 linux/arch/m68knommu/platform/68328/entry.S - 1.4 linux/arch/m68knommu/platform/68328/ints.c - 1.2 linux/arch/m68knommu/platform/68360/Makefile - 1.3 linux/arch/m68knommu/platform/68360/commproc.c - 1.3 linux/arch/m68knommu/platform/68360/entry.S - 1.4 linux/arch/m68knommu/platform/68360/ints.c - 1.3 linux/arch/m68knommu/platform/68EZ328/Makefile - 1.3 linux/arch/m68knommu/platform/68VZ328/Makefile - 1.3 linux/arch/m68knommu/platform/68VZ328/de2/config.c - 1.2 linux/arch/m68knommu/vmlinux.lds.S - 1.5 linux/arch/v850/kernel/rte_mb_a_pci.c - 1.4 linux/include/asm-v850/processor.h - 1.4 linux/arch/v850/kernel/irq.c - 1.6 linux/arch/v850/kernel/Makefile - 1.4 linux/arch/v850/Kconfig - 1.7 linux/arch/v850/Makefile - 1.5 linux/Documentation/kbuild/kconfig-language.txt - 1.2 linux/drivers/hotplug/cpci_hotplug_pci.c - 1.5 linux/drivers/serial/68328serial.c - 1.3 linux/drivers/serial/68328serial.h - 1.3 linux/drivers/serial/68360serial.c - 1.7 linux/drivers/serial/mcfserial.c - 1.4 linux/net/key/af_key.c - 1.7 linux/arch/ppc/syslib/open_pic.c - 1.3 linux/net/ipv4/esp.c - 1.5 linux/drivers/scsi/scsi_sysfs.c - 1.6 linux/scripts/per-cpu-check.awk - 1.4 linux/include/linux/compat.h - 1.4 linux/drivers/pnp/card.c - 1.6 linux/drivers/s390/char/sclp_con.c - 1.2 linux/drivers/s390/char/sclp_tty.c - 1.3 linux/drivers/s390/char/tape_block.c - 1.2 linux/Documentation/s390/driver-model.txt - 1.3 linux/Documentation/scsi/ChangeLog.ncr53c8xx - 1.2 linux/Documentation/scsi/ChangeLog.sym53c8xx - 1.3 linux/Documentation/scsi/ChangeLog.sym53c8xx_2 - 1.3 linux/Documentation/scsi/dpti.txt - 1.2 linux/Documentation/scsi/ibmmca.txt - 1.4 linux/Documentation/scsi/ncr53c8xx.txt - 1.2 linux/Documentation/scsi/sym53c8xx_2.txt - 1.2 linux/include/asm-sparc64/compat.h - 1.5 linux/drivers/usb/serial/kobil_sct.c - 1.4 linux/fs/compat.c - 1.3 linux/net/ipv4/xfrm_user.c - 1.4 linux/include/asm-ppc64/compat.h - 1.4 linux/drivers/ide/ide-io.c - 1.4 linux/fs/intermezzo/intermezzo_lib.h - 1.2 linux/arch/x86_64/kernel/suspend.c - 1.2 linux/Documentation/sound/alsa/ALSA-Configuration.txt - 1.3 linux/Documentation/uml/UserModeLinux-HOWTO.txt - 1.2 linux/include/asm-x86_64/compat.h - 1.5 linux/arch/um/kernel/tt/Makefile - 1.3 linux/drivers/i2c/busses/Kconfig - 1.3 linux/drivers/i2c/busses/Makefile - 1.2 linux/drivers/i2c/busses/i2c-amd756.c - 1.2 linux/drivers/i2c/busses/i2c-amd8111.c - 1.3 linux/include/asm-s390x/compat.h - 1.5 linux/arch/i386/kernel/sysenter.c - 1.5 linux/include/asm-ia64/intrinsics.h - 1.3 linux/Documentation/arm/Booting - 1.2 linux/drivers/scsi/zalon.h - 1.2 linux/drivers/scsi/zalon.c - 1.2 linux/net/ipv4/xfrm_algo.c - 1.2 linux/drivers/media/video/tda9887.c - 1.2 linux/include/asm-parisc/bug.h - 1.2 linux/include/asm-parisc/compat.h - 1.3 linux/arch/i386/kernel/cpu/cpufreq/gx-suspmod.c - 1.5 linux/arch/m68knommu/kernel/entry.S - 1.2 linux/include/asm-i386/bug.h - 1.2 linux/include/linux/eisa.h - 1.3 linux/arch/alpha/kernel/core_marvel.c - 1.4 linux/arch/sparc64/kernel/us3_cpufreq.c - 1.3 linux/drivers/eisa/eisa-bus.c - 1.3 linux/Documentation/ia64/fsys.txt - 1.2 linux/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl - 1.3 linux/arch/i386/kernel/cpu/cpufreq/acpi.c - 1.3 linux/arch/ia64/kernel/fsys.S - 1.2 linux/arch/arm/common/sa1111.c - 1.4 linux/arch/i386/oprofile/op_model_p4.c - 1.2 linux/drivers/cpufreq/freq_table.c - 1.2 linux/scripts/modpost.c - 1.4 linux/scripts/Makefile.modpost - 1.3 linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c - 1.3 linux/drivers/eisa/virtual_root.c - 1.2 linux/sound/oss/sb_card.h - 1.2 linux/kernel/posix-timers.c - 1.3 linux/drivers/pnp/manager.c - 1.2 linux/arch/alpha/oprofile/op_model_ev4.c - 1.2 linux/arch/m68knommu/platform/68VZ328/ucdimm/config.c - 1.2 linux/Documentation/arm/XScale/IOP3XX/dma.txt - 1.2 linux/Documentation/cpu-freq/core.txt - 1.2 linux/Documentation/cpu-freq/cpu-drivers.txt - 1.2 linux/Documentation/cpu-freq/governors.txt - 1.2 linux/Documentation/cpu-freq/user-guide.txt - 1.2 linux/drivers/char/watchdog/amd7xx_tco.c - 1.2 linux/drivers/cpufreq/userspace.c - 1.2 linux/scripts/genksyms/Makefile - 1.2 linux/net/ipv6/netfilter/ip6t_frag.c - 1.2 linux/fs/sysfs/bin.c - 1.2 linux/fs/sysfs/dir.c - 1.2 linux/net/ipv6/netfilter/ip6t_rt.c - 1.2 linux/net/ipv6/netfilter/ip6t_ipv6header.c - 1.2 linux/net/ipv6/netfilter/ip6t_hbh.c - 1.2 linux/drivers/video/cg14.c - 1.2 linux/drivers/video/bw2.c - 1.2 linux/net/ipv6/netfilter/ip6t_esp.c - 1.2 linux/drivers/video/cg3.c - 1.2 linux/drivers/video/cg6.c - 1.2 linux/net/ipv6/netfilter/ip6t_dst.c - 1.2 linux/drivers/video/ffb.c - 1.2 linux/drivers/video/p9100.c - 1.2 linux/net/ipv6/netfilter/ip6t_ah.c - 1.2 linux/drivers/video/sbuslib.c - 1.2 linux/drivers/video/sbuslib.h - 1.2 linux/arch/i386/kernel/srat.c - 1.2 linux/fs/sysfs/mount.c - 1.2 linux/drivers/video/tcx.c - 1.2 linux/init/do_mounts.h - 1.2 linux/init/do_mounts_rd.c - 1.2 linux/include/asm-i386/srat.h - 1.2 From owner-linux-xfs@oss.sgi.com Thu Mar 20 10:50:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 10:50:12 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2KInJq9005107 for ; Thu, 20 Mar 2003 10:50:00 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2KInDuY004851 for ; Thu, 20 Mar 2003 10:49:13 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA39353 for ; Thu, 20 Mar 2003 12:49:13 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2KInBwX31450224 for ; Thu, 20 Mar 2003 12:49:12 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h2L24Uj27120 for linux-xfs@oss.sgi.com; Thu, 20 Mar 2003 21:04:30 -0500 Resent-Message-Id: <200303210204.h2L24Uj27120@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2KImfwX30493708 for ; Thu, 20 Mar 2003 12:48:41 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.8/8.11.4/nodin-1.0) with ESMTP id h2KIme4L24092669 for ; Thu, 20 Mar 2003 10:48:41 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h2KIjPxD022221 for ; Thu, 20 Mar 2003 19:45:25 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h2KIjPKe022220 for hch@sgi.com; Thu, 20 Mar 2003 19:45:25 +0100 Date: Thu, 20 Mar 2003 19:45:25 +0100 From: Christoph Hellwig Message-Id: <200303201845.h2KIjPKe022220@lab343.munich.sgi.com> Subject: TAKE - Fix DMAPI build To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Thu, 20 Mar 2003 21:04:30 -0500 Resent-To: linux-xfs@oss.sgi.com X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3276 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: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 331 Lines: 12 Date: Thu Mar 20 10:47:48 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:142218a linux/fs/xfs/dmapi/dmapi_xfs.c - 1.2 - bring back the 2.5 changes that got lost when moving the file around From owner-linux-xfs@oss.sgi.com Thu Mar 20 11:17:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 11:18:07 -0800 (PST) Received: from centauri.artland.com.pl (centauri.artland.com.pl [62.233.164.19]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2KJHhq9002005 for ; Thu, 20 Mar 2003 11:17:47 -0800 Received: (qmail 30818 invoked from network); 20 Mar 2003 19:30:01 -0000 Received: from unknown (HELO ubik) (149.156.124.19) by centauri.artland.com.pl with DES-CBC3-SHA encrypted SMTP; 20 Mar 2003 19:30:01 -0000 Received: from pokryfka by ubik with local (Exim 3.35 #1 (Debian)) id 18w5Xi-0004hx-00; Thu, 20 Mar 2003 20:17:34 +0100 Date: Thu, 20 Mar 2003 20:17:34 +0100 To: Chris Wedgwood Cc: Greg Freemyer , linux-xfs@oss.sgi.com Subject: Re: xfs cpu usage Message-ID: <20030320191734.GA18090@localhost> References: <20030319175011.RXTR25382.imf58bis.bellsouth.net@tiger2> <20030319181650.GA7459@localhost> <20030320013454.GA6989@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030320013454.GA6989@f00f.org> User-Agent: Mutt/1.5.3i From: Michal Adamczak X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3277 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: pokryfka@druid.if.uj.edu.pl Precedence: bulk X-list: linux-xfs Content-Length: 554 Lines: 18 On Wed, Mar 19, 2003 at 05:34:54PM -0800, Chris Wedgwood wrote: > On Wed, Mar 19, 2003 at 07:16:50PM +0100, Michal Adamczak wrote: > > > unfortunately the way it works right now is unacceptable > > can you run oprofile and see where the time is baing taken please? i'm not very familiar with oprofile i know it is and can install it but could You please be more specific and tell what kinds of results You'd expect? -- Michal Adamczak pokryfka @ druid.if.uj.edu.pl GS dpu C+++ UL+++++ L+++(++++) w--- !tv h* I code AND I bathe. (seen on slashdot) From owner-linux-xfs@oss.sgi.com Thu Mar 20 14:10:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 14:11:04 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2KMADq9022690 for ; Thu, 20 Mar 2003 14:10:53 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2KMA7uY019723 for ; Thu, 20 Mar 2003 14:10:07 -0800 Received: from zomba.sgi.com ([198.149.18.14]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA01432 for ; Thu, 20 Mar 2003 16:10:06 -0600 (CST) Received: from zomba.sgi.com (localhost.sgi.com [127.0.0.1]) by zomba.sgi.com (8.12.8/8.12.6/freebsd-sendmail_sa_mtv-1.0) with ESMTP id h2KM9tjc047361 for ; Thu, 20 Mar 2003 16:10:09 -0600 (CST) X-Possible-Spam: the addition of this header was triggered by: localhost.localdomain.failing.dns.checks:helo Received: from localhost.localdomain (eagdhcp-233-140.americas.sgi.com [128.162.233.140]) by zomba.sgi.com (8.12.8/8.12.6/freebsd-nospam-3.1) with ESMTP id h2KM8BVx047156 for ; Thu, 20 Mar 2003 16:08:11 -0600 (CST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h2KCpl7X001393 for ; Thu, 20 Mar 2003 06:51:47 -0600 Received: (from lord@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h2KCpkE1001391; Thu, 20 Mar 2003 06:51:46 -0600 X-Authentication-Warning: localhost.localdomain: lord set sender to lord@sgi.com using -f Subject: [Fwd: Re: optimizing raid performance with xfs] From: Steve Lord To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 20 Mar 2003 06:51:46 -0600 Message-Id: <1048164706.1204.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3278 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1873 Lines: 52 Forwarding this, as it contains some info useful for other folks. Steve -----Forwarded Message----- From: Steve Lord To: Andy Arvai Subject: Re: optimizing raid performance with xfs Date: 19 Mar 2003 20:54:32 -0600 On Wed, 2003-03-19 at 20:42, Andy Arvai wrote: > Hi, > > Thanks for the information. I looked at the man page for mkfs.xfs and > there is no "-f" option. Is this something I need? -f is needed to overwrite an existing filesystem on a disk. > > Also, according to the man page > > If an inode size is specified, or if a filesystem is > sufficiently large, mkfs.xfs will warn if this will create inode > numbers > 32 significant bits. > > What are the ramifications if I get a warning that inode numbers > are > 32 bits? Will this cause a problem as the disk gets full? An xfs inode number is an encoding of a disk address. The larger the filesystem, the larger the inode numbers can potentially be. With the default inode size of 256 bytes, it is possible for the inode numbers to overflow 32 bits at 1 Tbyte. This is a problem for linux where only 32 bits of inode space is available in system calls and in the vfs layer. XFS has an option to restrict inode placement to parts of the disk which will avoid overflowing 32 bits, this is on by default on linux. This policy can affect layout and performance. To avoid xfs operating in this mode, specifying inodes as being 512 bytes in size defers this policy switch over to a 2 Tbyte filesystem. XFS inodes contain a fixed component and a variable component, extent information can be held in the variable component, as can directory entries of small directories. This is one reason xfs supports different sizes of inodes. So there is no danger of overflowing 32 bits of inode space on xfs, but using this mkfs option may give better performance. Steve From owner-linux-xfs@oss.sgi.com Thu Mar 20 14:17:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 14:18:00 -0800 (PST) Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2KMHmq9023178 for ; Thu, 20 Mar 2003 14:17:49 -0800 Received: from fwd03.sul.t-online.de by mailout10.sul.t-online.com with smtp id 18w8M4-0001Se-0B; Thu, 20 Mar 2003 23:17:44 +0100 Received: from puariko.homeip.net (520039812576-0001@[217.231.212.92]) by fmrl03.sul.t-online.com with esmtp id 18w8Lu-0RrREeC; Thu, 20 Mar 2003 23:17:34 +0100 Received: (from thimm@localhost) by puariko.nirvana (8.12.8/8.12.5/Submit) id h2KMHKar002065; Thu, 20 Mar 2003 23:17:20 +0100 Date: Thu, 20 Mar 2003 23:17:20 +0100 From: Axel Thimm To: linux-xfs Cc: Simon Matter , Seth Mos Subject: Re: Updated RedHat errata kernel with XFS 1.2 Message-ID: <20030320221720.GD25879@puariko.nirvana> References: <3E77289F.960BF744@ch.sauter-bc.com> <20030318231811.P52057-100000@xs1.xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qtZFehHsKgwS5rPz" Content-Disposition: inline In-Reply-To: <20030318231811.P52057-100000@xs1.xs4all.nl> User-Agent: Mutt/1.4.1i X-Sender: 520039812576-0001@t-dialin.net X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3279 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: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1452 Lines: 47 --qtZFehHsKgwS5rPz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 18, 2003 at 11:20:52PM +0100, Seth Mos wrote: > On Tue, 18 Mar 2003, Simon Matter wrote: > > I have created XFS enabled versions of todays RedHat errata kernel. [..= .] > Ah, I just created a similar source rpm as well, [...] "me too" for Red Hat 8.0. I also have (re)built the userland xfs rpms, with= some fixes in the dependencies and further minor changes. You can keep your XFS = system now uptodate with apt-get ;) http://atrpms.physik.fu-berlin.de/topic/xfs/ Note: The kernel includes more than the XFS patches: * base kernel sources: Taken from current redhat errata (2.4.18-27.8.0) * XFS: merged patches found in 1.2 * i2c-2.7.0 and lm_sensors-2.7.0. You should also get the updated userl= and tools. * 3ware 1.02.00.027 kernel driver for Escalade 7xxx series. Try to keep= in sync with your firmware and userland tools. * v4l2-api (backported from http://bytesex.org/patches/2.4/11-v4l2-api-2.4.20-pre11.diff.gz) --=20 Axel.Thimm@physik.fu-berlin.de --qtZFehHsKgwS5rPz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ej3wQBVS1GOamfERAiYqAJ41ayLzUdyZsUYkqQ6V0y3FrCy2PgCfdOXP XRtOM/glacr0TrdJb0oQcEI= =z6Qp -----END PGP SIGNATURE----- --qtZFehHsKgwS5rPz-- From owner-linux-xfs@oss.sgi.com Thu Mar 20 15:15:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 15:15:45 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2KNFaq9025170 for ; Thu, 20 Mar 2003 15:15:36 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id A815F183EEE4; Thu, 20 Mar 2003 15:15:35 -0800 (PST) Date: Thu, 20 Mar 2003 15:15:35 -0800 From: Chris Wedgwood To: Michal Adamczak Cc: Greg Freemyer , linux-xfs@oss.sgi.com Subject: Re: xfs cpu usage Message-ID: <20030320231535.GA16975@f00f.org> References: <20030319175011.RXTR25382.imf58bis.bellsouth.net@tiger2> <20030319181650.GA7459@localhost> <20030320013454.GA6989@f00f.org> <20030320191734.GA18090@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030320191734.GA18090@localhost> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3280 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 423 Lines: 15 On Thu, Mar 20, 2003 at 08:17:34PM +0100, Michal Adamczak wrote: > i'm not very familiar with oprofile please check http://oprofile.sourceforge.net/docs/ for a quick quide; how to poke it depends on your CPU and a few other things > i know it is and can install it but could You please be more > specific and tell what kinds of results You'd expect? i'd like to see *where* all the CPU time is being consumed --cw From owner-linux-xfs@oss.sgi.com Thu Mar 20 16:09:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 16:09:25 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2L08Vq9001671 for ; Thu, 20 Mar 2003 16:09:12 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2L0Jokq020071 for ; Thu, 20 Mar 2003 18:19:51 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2L0777L2586813 for ; Fri, 21 Mar 2003 11:07:07 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2L076tU2577579 for linux-xfs@oss.sgi.com; Fri, 21 Mar 2003 11:07:06 +1100 (EST) Date: Fri, 21 Mar 2003 11:07:06 +1100 (EST) From: Nathan Scott Message-Id: <200303210007.h2L076tU2577579@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - mkfs man page X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3281 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 293 Lines: 13 Document the -f option to mkfs.xfs. Date: Thu Mar 20 16:06:49 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:142274a cmd/xfsprogs/man/man8/mkfs.xfs.8 - 1.15 From owner-linux-xfs@oss.sgi.com Thu Mar 20 16:26:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 16:27:01 -0800 (PST) Received: from hotmail.com (bay1-f58.bay1.hotmail.com [65.54.245.58]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2L0Qwq9002548 for ; Thu, 20 Mar 2003 16:26:59 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 20 Mar 2003 16:26:52 -0800 Received: from 66.167.1.42 by by1fd.bay1.hotmail.msn.com with HTTP; Fri, 21 Mar 2003 00:26:51 GMT X-Originating-IP: [66.167.1.42] X-Originating-Email: [mwhang77@hotmail.com] From: "Michael Whang" To: linux-xfs@oss.sgi.com Subject: ultra 320 and XFS Date: Thu, 20 Mar 2003 16:26:51 -0800 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 21 Mar 2003 00:26:52.0385 (UTC) FILETIME=[91DBED10:01C2EF40] X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3282 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: mwhang77@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 770 Lines: 5
Hi,

Im trying to install Redhat 8.0 wih XFS on a workstation but my SCSI drive fails to show up on the list of hard drives to install onto.  I have a super micro motherboard with the E7505 chipset (dual xeon 2.4 GHZ).  It has an onboard AIC7902 Ultra 320 SCSI card.  When I boot off the XFS disk, i type in "linux dd" to install the SCSI drivers for Redhat 8.0 and it seems to go fine, but when the partitioning section of the install comes up, I dont see the hard drive.  Has anyone experienced this before?
 
Michael Whang

Help STOP SPAM with the new MSN 8 and get 2 months FREE* From owner-linux-xfs@oss.sgi.com Thu Mar 20 18:52:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 18:52:16 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2L2pPq9004902 for ; Thu, 20 Mar 2003 18:52:08 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2L2pKnH022527 for ; Thu, 20 Mar 2003 18:51:20 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA73881 for ; Thu, 20 Mar 2003 20:51:20 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2L2pKwX32258221 for ; Thu, 20 Mar 2003 20:51:20 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2L2pJ100630; Thu, 20 Mar 2003 20:51:19 -0600 Message-Id: <200303210251.h2L2pJ100630@jen.americas.sgi.com> Date: Thu, 20 Mar 2003 20:51:19 -0600 Subject: TAKE - fix mtime updates in the 2.5 kernel To: linux-xfs@oss.sgi.com X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3283 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 637 Lines: 23 optimize timestamp updates, use new hires timestamps more directly, also fix a bug where the mtime field was not correctly updated. Date: Thu Mar 20 18:50:03 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:142296a linux/fs/xfs/xfs_inode.c - 1.366 - cleanup xfs_ichgtime, fix assignment of mtime linux/fs/xfs/linux/xfs_vnode.c - 1.112 - use direct assignment between timeval structures, reduce cost of the getattr call. linux/fs/xfs/support/time.h - 1.12 - use CURRENT_TIME to implement nanotime From owner-linux-xfs@oss.sgi.com Thu Mar 20 19:22:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 19:22:08 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2L3M3q9005799 for ; Thu, 20 Mar 2003 19:22:03 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2L3M2la005797 for linux-xfs@oss.sgi.com; Thu, 20 Mar 2003 19:22:02 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2L3M0qB005784 for ; Thu, 20 Mar 2003 19:22:00 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2L2ssCV005105; Thu, 20 Mar 2003 18:54:54 -0800 Date: Thu, 20 Mar 2003 18:54:54 -0800 Message-Id: <200303210254.h2L2ssCV005105@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 231] XFS does not update directory mtime when changes made in directory X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3284 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 724 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=231 lord@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lord@sgi.com 2003-03-20 18:54 ------- Code is in the xfs 2.5 cvs tree, and should make it to Linus in the near future. A typo crept in when the nanosecond resolution timer was added. The mtime seconds field was not being updated in the linux inode. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 20 19:41:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 19:41:40 -0800 (PST) Received: from main.kldp.org ([211.39.143.147]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2L3erq9006280 for ; Thu, 20 Mar 2003 19:41:34 -0800 Received: from kss by main.kldp.org with local (Exim 3.12 #1 (Debian)) id 18wDOh-0007Tn-00; Fri, 21 Mar 2003 12:40:47 +0900 Date: Fri, 21 Mar 2003 12:40:47 +0900 From: Soon-Son Kwon To: linux-xfs@oss.sgi.com Subject: low level access path for xfs operation Message-ID: <20030321124047.A26767@mail.kldp.org> Reply-To: kss@kldp.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: Debian GNU/Linux Organization: KLDP(Korean Linux Documentation Project) X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3285 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: kss@kldp.org Precedence: bulk X-list: linux-xfs Content-Length: 902 Lines: 29 Hi xfs folks: Could anyone please let me know the following xfs internal operation details? I would like to know if there is any operation that bypasses submit_bio() when accessing the lower level block devices. I want to add some function whenever the filesystem tries to modify any block and concluded that submit_bio() seems to be the lowest entry point for such operations. But I later found that I did not consider the direct i/o or raw i/o operations that seems to have shorter path for lower devices by eliminating the copy operations. I suspect those direct i/o or raw i/o operations do not use submit_bio(). If there is any mistake or missing point, please let me know. Thanks very much. -- -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* (o_ **WTFM** (o_ (o_ //\ (/)_ (/)_ V_/_ http://kldp.org -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From owner-linux-xfs@oss.sgi.com Thu Mar 20 21:05:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 21:06:04 -0800 (PST) Received: from out004.verizon.net (out004pub.verizon.net [206.46.170.142]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2L55Wq9015454 for ; Thu, 20 Mar 2003 21:05:54 -0800 Received: from kanhome ([141.154.58.208]) by out004.verizon.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030321050526.RNQE7930.out004.verizon.net@kanhome> for ; Thu, 20 Mar 2003 23:05:26 -0600 Date: Fri, 21 Mar 2003 00:05:25 -0500 From: Alexander Kabaev To: linux-xfs@oss.sgi.com Subject: CVSUP server is down on ftp.thebarn.com Message-Id: <20030321000525.2639f00b.kabaev@bellatlantic.net> Reply-To: ak03@gte.com X-Mailer: Sylpheed version 0.8.10claws18 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out004.verizon.net from [141.154.58.208] at Thu, 20 Mar 2003 23:05:26 -0600 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3286 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: kabaev@bellatlantic.net Precedence: bulk X-list: linux-xfs Content-Length: 52 Lines: 5 Could someone please fix it? -- Alexander Kabaev From owner-linux-xfs@oss.sgi.com Thu Mar 20 22:35:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Mar 2003 22:35:09 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2L6Yxq9017139 for ; Thu, 20 Mar 2003 22:35:00 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 0DAB3AC35; Fri, 21 Mar 2003 07:48:04 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id AE1F8190D1; Fri, 21 Mar 2003 07:48:05 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 7ADBF30881D; Fri, 21 Mar 2003 07:34:56 +0100 (CET) Message-ID: <3E7AB28F.B41482DA@ch.sauter-bc.com> Date: Fri, 21 Mar 2003 07:34:55 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Michael Whang Cc: linux-xfs@oss.sgi.com Subject: Re: ultra 320 and XFS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3287 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: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 896 Lines: 26 Michael Whang schrieb: > > Hi, > > Im trying to install Redhat 8.0 wih XFS on a workstation but my SCSI > drive fails to show up on the list of hard drives to install onto. I > have a super micro motherboard with the E7505 chipset (dual xeon 2.4 > GHZ). It has an onboard AIC7902 Ultra 320 SCSI card. When I boot off > the XFS disk, i type in "linux dd" to install the SCSI drivers for Do you need "linux dd"? AFAIK as long as you only use kernel modules from the RedHat distribution, you don't have to use a driver disk (dd) at all. Did you try without dd? HTH Simon > Redhat 8.0 and it seems to go fine, but when the partitioning section > of the install comes up, I dont see the hard drive. Has anyone > experienced this before? > > Michael Whang > > ---------------------------------------------------------------------- > Help STOP SPAM with the new MSN 8 and get 2 months FREE* From owner-linux-xfs@oss.sgi.com Fri Mar 21 01:15:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 01:15:21 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2L9EQq9022433 for ; Fri, 21 Mar 2003 01:15:07 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18wIbX-0007XY-00; Fri, 21 Mar 2003 09:14:23 +0000 Date: Fri, 21 Mar 2003 09:14:23 +0000 From: Christoph Hellwig To: Soon-Son Kwon Cc: linux-xfs@oss.sgi.com Subject: Re: low level access path for xfs operation Message-ID: <20030321091423.A28976@infradead.org> References: <20030321124047.A26767@mail.kldp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030321124047.A26767@mail.kldp.org>; from kss@kldp.org on Fri, Mar 21, 2003 at 12:40:47PM +0900 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3288 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: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 589 Lines: 18 On Fri, Mar 21, 2003 at 12:40:47PM +0900, Soon-Son Kwon wrote: > Hi xfs folks: > Could anyone please let me know the following > xfs internal operation details? > > I would like to know if there is any operation > that bypasses submit_bio() when accessing the > lower level block devices. No, there is no such operation. > I want to add some function whenever the filesystem > tries to modify any block and concluded that submit_bio() > seems to be the lowest entry point for such operations. You might want to rewrite a block remapper like dm or md instead of modifying core core.. From owner-linux-xfs@oss.sgi.com Fri Mar 21 02:58:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 02:58:18 -0800 (PST) Received: from main.kldp.org ([211.39.143.147]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LAvNq9032193 for ; Fri, 21 Mar 2003 02:58:05 -0800 Received: from kss by main.kldp.org with local (Exim 3.12 #1 (Debian)) id 18wK09-0003Vw-00; Fri, 21 Mar 2003 19:43:53 +0900 Date: Fri, 21 Mar 2003 19:43:53 +0900 From: Soon-Son Kwon To: Christoph Hellwig Cc: Soon-Son Kwon , linux-xfs@oss.sgi.com Subject: Re: low level access path for xfs operation Message-ID: <20030321194353.A12729@mail.kldp.org> Reply-To: kss@kldp.org References: <20030321124047.A26767@mail.kldp.org> <20030321091423.A28976@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030321091423.A28976@infradead.org>; from hch@infradead.org on Fri, Mar 21, 2003 at 09:14:23AM +0000 X-Operating-System: Debian GNU/Linux Organization: KLDP(Korean Linux Documentation Project) X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3289 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: kss@kldp.org Precedence: bulk X-list: linux-xfs Content-Length: 1561 Lines: 41 On Fri, Mar 21, 2003 at 09:14:23AM +0000, Christoph Hellwig wrote: > On Fri, Mar 21, 2003 at 12:40:47PM +0900, Soon-Son Kwon wrote: > > Hi xfs folks: > > Could anyone please let me know the following > > xfs internal operation details? > > > > I would like to know if there is any operation > > that bypasses submit_bio() when accessing the > > lower level block devices. > > No, there is no such operation. > > > I want to add some function whenever the filesystem > > tries to modify any block and concluded that submit_bio() > > seems to be the lowest entry point for such operations. > > You might want to rewrite a block remapper like dm or md > instead of modifying core core.. What I would like to implement is the snapshot functionality within the filesystem. I know LVM supports snapshot but it requires a separate volume for each snapshot. I thought snapshot within the filesystem would be more convenient. Snapshot functionality requires copy-on-write implementation when something tries to modify any block, copy the old content to new block and overwrite the new content to that block while the snapshot image keeps track of the original content. Anyway, do you think implementing that operation requires modifying dm/md code instead of modifying submit_bio()? Any comment is welcomed and thank you very much for answering my question..... -- -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* (o_ **WTFM** (o_ (o_ //\ (/)_ (/)_ V_/_ http://kldp.org -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From owner-linux-xfs@oss.sgi.com Fri Mar 21 07:26:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 07:27:05 -0800 (PST) Received: from THOR.goeci.com (thor.goeci.com [66.28.220.99]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LFQGq9020291 for ; Fri, 21 Mar 2003 07:26:57 -0800 Received: by THOR.goeci.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Mar 2003 10:26:10 -0500 Message-ID: <2D92FEBFD3BE1346A6C397223A8DD3FC0921A5@THOR.goeci.com> From: Murthy Kambhampaty To: "'Simon Matter'" , Michael Whang Cc: linux-xfs@oss.sgi.com Subject: RE: ultra 320 and XFS Date: Fri, 21 Mar 2003 10:26:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3290 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: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs Content-Length: 1947 Lines: 56 I had this problem with the 3ware card way back when. You can look for Bryan Smith's message re XFS (1.02?) on the 3ware card. Basically, you are going to have to: 1. Install with vanilla RedHat distro (not XFS Installer) 2. On your vanilla RedHat system, recompile the kernel with XFS and aic79xx support 3. Reboot to the new kernel; drop to single user; move partitions around; fix lilo 4. Reboot to you target system. Instead of mastering this ballet, I found it much simpler to put the system on a controller that the XFS distro (stock kernel drivers) supports and only put data on the "exotic" controller (I have an XFS database volume running on an Adaptec 39320, in fact; aic79xx v. 1.1.0 drivers; the system volume on the machine with the 3ware card is still on a single SCSI disk, though that should change "any day now"). Cheers, Murthy -----Original Message----- From: Simon Matter [mailto:simon.matter@ch.sauter-bc.com] Sent: Friday, March 21, 2003 01:35 To: Michael Whang Cc: linux-xfs@oss.sgi.com Subject: Re: ultra 320 and XFS Michael Whang schrieb: > > Hi, > > Im trying to install Redhat 8.0 wih XFS on a workstation but my SCSI > drive fails to show up on the list of hard drives to install onto. I > have a super micro motherboard with the E7505 chipset (dual xeon 2.4 > GHZ). It has an onboard AIC7902 Ultra 320 SCSI card. When I boot off > the XFS disk, i type in "linux dd" to install the SCSI drivers for Do you need "linux dd"? AFAIK as long as you only use kernel modules from the RedHat distribution, you don't have to use a driver disk (dd) at all. Did you try without dd? HTH Simon > Redhat 8.0 and it seems to go fine, but when the partitioning section > of the install comes up, I dont see the hard drive. Has anyone > experienced this before? > > Michael Whang > > ---------------------------------------------------------------------- > Help STOP SPAM with the new MSN 8 and get 2 months FREE* From owner-linux-xfs@oss.sgi.com Fri Mar 21 08:28:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 08:28:24 -0800 (PST) Received: from woozle.fnal.gov (woozle.fnal.gov [131.225.9.22]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LGSFq9023475 for ; Fri, 21 Mar 2003 08:28:16 -0800 Received: from fnal.gov (sdsslnx3.fnal.gov [131.225.7.82]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTP id <0HC300A1BXR242@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Fri, 21 Mar 2003 10:28:14 -0600 (CST) Date: Fri, 21 Mar 2003 10:28:14 -0600 From: Dan Yocum Subject: KDB-ized RH 2.4.18-X kernel? To: xfs-list Message-id: <3E7B3D9E.3090805@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3291 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: yocum@fnal.gov Precedence: bulk X-list: linux-xfs Content-Length: 458 Lines: 17 Hi all, I've got a couple machines that like to freeze up for no apparent reason. Does anyone have a kdb-ized RH 2.4.18-X kernel they'd be willing to share? I spent all day yesterday trying to apply different kdb patches to 2.4.18-18 and 2.4.18-26 with no success, and I'm not keen on going to a custom kernel. Thanks, Dan -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Fri Mar 21 08:38:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 08:38:16 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LGbRq9023964 for ; Fri, 21 Mar 2003 08:38:07 -0800 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id h2LGbQR04272; Fri, 21 Mar 2003 11:37:26 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Fri, 21 Mar 2003 11:37:26 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Dan Yocum cc: xfs-list Subject: Re: KDB-ized RH 2.4.18-X kernel? In-Reply-To: <3E7B3D9E.3090805@fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3292 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: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 629 Lines: 17 On Fri, 21 Mar 2003 at 10:28am, Dan Yocum wrote > I've got a couple machines that like to freeze up for no apparent reason. > Does anyone have a kdb-ized RH 2.4.18-X kernel they'd be willing to share? > > I spent all day yesterday trying to apply different kdb patches to 2.4.18-18 > and 2.4.18-26 with no success, and I'm not keen on going to a custom kernel. It looks to me like the RH based kernel from the 1.2 release has kdb in the source but not compiled. Grab the SRPM, install it, tweak the appropriate config files, and rpmbuild it. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Fri Mar 21 09:16:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 09:16:14 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LHG5q9028403 for ; Fri, 21 Mar 2003 09:16:05 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2LHRSkq003010 for ; Fri, 21 Mar 2003 11:27:28 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA32413 for ; Fri, 21 Mar 2003 11:15:59 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2LHFxwX32422401 for ; Fri, 21 Mar 2003 11:15:59 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h2LHFOb32727; Fri, 21 Mar 2003 11:15:24 -0600 Message-Id: <200303211715.h2LHFOb32727@stout.americas.sgi.com> Date: Fri, 21 Mar 2003 11:15:24 -0600 Subject: TAKE - Document -l logdev and -r rtdev mkfs.xfs options X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3293 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 307 Lines: 12 Document -l logdev and -r rtdev mkfs.xfs options Date: Fri Mar 21 09:15:37 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:142333a xfsprogs/man/man8/mkfs.xfs.8 - 1.16 From owner-linux-xfs@oss.sgi.com Fri Mar 21 12:41:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 12:41:35 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LKerq9032155 for ; Fri, 21 Mar 2003 12:41:33 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id AFE3A18469D2; Fri, 21 Mar 2003 12:40:52 -0800 (PST) Date: Fri, 21 Mar 2003 12:40:52 -0800 From: Chris Wedgwood To: Soon-Son Kwon Cc: Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: low level access path for xfs operation Message-ID: <20030321204052.GB27409@f00f.org> References: <20030321124047.A26767@mail.kldp.org> <20030321091423.A28976@infradead.org> <20030321194353.A12729@mail.kldp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030321194353.A12729@mail.kldp.org> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3295 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 1141 Lines: 30 On Fri, Mar 21, 2003 at 07:43:53PM +0900, Soon-Son Kwon wrote: > What I would like to implement is the snapshot functionality within > the filesystem. I know LVM supports snapshot but it requires a > separate volume for each snapshot. I thought snapshot within the > filesystem would be more convenient. How should this work from a user perspective? > Snapshot functionality requires copy-on-write implementation when > something tries to modify any block, copy the old content to new > block and overwrite the new content to that block while the snapshot > image keeps track of the original content. You need to be sure whatever mechanism you use to keep track of block placements is efficient and the granularity are sane or else the metadata to keep track of this can be enormous. > Anyway, do you think implementing that operation requires modifying > dm/md code instead of modifying submit_bio()? No... I don't see why it should --- ideally you want a pseudo-block device or similar to place the fs on; this will then be able to track changes and such like. Check the device-mapper and LVM as they effectively do this. --cw From owner-linux-xfs@oss.sgi.com Fri Mar 21 12:38:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 12:38:28 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LKbbq9031937 for ; Fri, 21 Mar 2003 12:38:17 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id CEC3318469D2; Fri, 21 Mar 2003 12:37:36 -0800 (PST) Date: Fri, 21 Mar 2003 12:37:36 -0800 From: Chris Wedgwood To: Murthy Kambhampaty Cc: "'Simon Matter'" , Michael Whang , linux-xfs@oss.sgi.com Subject: Re: ultra 320 and XFS Message-ID: <20030321203736.GA27409@f00f.org> References: <2D92FEBFD3BE1346A6C397223A8DD3FC0921A5@THOR.goeci.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D92FEBFD3BE1346A6C397223A8DD3FC0921A5@THOR.goeci.com> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3294 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 1290 Lines: 36 On Fri, Mar 21, 2003 at 10:26:10AM -0500, Murthy Kambhampaty wrote: Warning: Non Super-Difficult-Red-Hat-Solution-Ahead :) > 1. Install with vanilla RedHat distro (not XFS Installer) > 2. On your vanilla RedHat system, recompile the kernel with XFS and > aic79xx support > 3. Reboot to the new kernel; drop to single user; move partitions > around; fix lilo > 4. Reboot to you target system. or build a non-modular kernel with all the right magic bits in it (super easy) and put this on a floppy (cp), use rdev to make the floppy strap suitably using a ramdisk, usually "rdev -r /dev/fd0 49152 ; rdev /dev/fd0 /dev/fd0" suffices boot this disk --- it will prompt for a second disk, at this point give it a Debian rootfs image on a floppy and follow the prompts... sorry i can't tell you how to do this with Red Hat, I tried to find out last night how this was done and everyone tells me it can't be, so, if someone does know of a Red Hat solution then perhaps post it here and maybe I'll compile a list of 'more difficult' XFS installation methods or something the other suggestion i have is since most network cards can PXE boot, then PXE boot a kernel which mounts / via nfs --- again, I know how to do this with Debian but not Red Hat[1] --cw [1] bug me if interested From owner-linux-xfs@oss.sgi.com Fri Mar 21 14:00:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 14:00:54 -0800 (PST) Received: from woozle.fnal.gov (woozle.fnal.gov [131.225.9.22]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LM0iq9001892 for ; Fri, 21 Mar 2003 14:00:45 -0800 Received: from fnal.gov (sdsslnx3.fnal.gov [131.225.7.82]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTP id <0HC400FDZD58LP@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Fri, 21 Mar 2003 16:00:44 -0600 (CST) Date: Fri, 21 Mar 2003 16:00:44 -0600 From: Dan Yocum Subject: Re: KDB-ized RH 2.4.18-X kernel? To: Joshua Baker-LePain Cc: xfs-list Message-id: <3E7B8B8C.9020808@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 References: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3296 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: yocum@fnal.gov Precedence: bulk X-list: linux-xfs Content-Length: 884 Lines: 29 Sorry, I jumped ahead in my error reporting - I tried re-compiling the RH kernel source with kdb enabled. No go. Horrible death. Die, die, die. :-( Joshua Baker-LePain wrote: > On Fri, 21 Mar 2003 at 10:28am, Dan Yocum wrote > > >>I've got a couple machines that like to freeze up for no apparent reason. >>Does anyone have a kdb-ized RH 2.4.18-X kernel they'd be willing to share? >> >>I spent all day yesterday trying to apply different kdb patches to 2.4.18-18 >>and 2.4.18-26 with no success, and I'm not keen on going to a custom kernel. > > > It looks to me like the RH based kernel from the 1.2 release has kdb in > the source but not compiled. Grab the SRPM, install it, tweak the > appropriate config files, and rpmbuild it. > -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Fri Mar 21 14:12:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 14:12:08 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LMBLq9002395 for ; Fri, 21 Mar 2003 14:12:02 -0800 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id h2LMBK105163; Fri, 21 Mar 2003 17:11:20 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Fri, 21 Mar 2003 17:11:20 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Dan Yocum cc: xfs-list Subject: Re: KDB-ized RH 2.4.18-X kernel? In-Reply-To: <3E7B8B8C.9020808@fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3297 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: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 502 Lines: 15 On Fri, 21 Mar 2003 at 4:00pm, Dan Yocum wrote > Sorry, I jumped ahead in my error reporting - I tried re-compiling the RH > kernel source with kdb enabled. No go. Horrible death. Die, die, die. Did you compile the source in /usr/src/linux-2.4 as installed by the kernel-source*rpm, or did you compile from the SRPM? ISTR that the first method can be broken sometimes, but I've had had good luck with the second. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Fri Mar 21 15:23:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 15:23:56 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LNNDq9005034 for ; Fri, 21 Mar 2003 15:23:54 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2LNN8nH027776 for ; Fri, 21 Mar 2003 15:23:08 -0800 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA62358 for ; Fri, 21 Mar 2003 17:23:07 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2LNN72r925946 for ; Fri, 21 Mar 2003 17:23:07 -0600 (CST) Received: from clink.americas.sgi.com (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id h2LNN7oG7896022 for ; Fri, 21 Mar 2003 17:23:07 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2LNN7ZV7888357 for linux-xfs@oss.sgi.com; Fri, 21 Mar 2003 17:23:07 -0600 (CST) Date: Fri, 21 Mar 2003 17:23:07 -0600 (CST) From: Dean Roehrich Message-Id: <200303212323.h2LNN7ZV7888357@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix initialization of dmapi code X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3298 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: roehrich@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 333 Lines: 13 Date: Fri Mar 21 15:22:47 PST 2003 Workarea: clink.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:142389a linux/fs/xfs/linux/xfs_super.h - 1.41 - Call dmapi_init/dmapi_uninit instead of xfs_dm_init/xfs_dm_exit From owner-linux-xfs@oss.sgi.com Fri Mar 21 15:29:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 15:29:38 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LNTZq9005524 for ; Fri, 21 Mar 2003 15:29:35 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2LNTUnH028218 for ; Fri, 21 Mar 2003 15:29:30 -0800 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA67561 for ; Fri, 21 Mar 2003 17:29:29 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2LNTT2r924043 for ; Fri, 21 Mar 2003 17:29:29 -0600 (CST) Received: from clink.americas.sgi.com (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id h2LNTToG7910748 for ; Fri, 21 Mar 2003 17:29:29 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2LNTT2d7883723 for linux-xfs@oss.sgi.com; Fri, 21 Mar 2003 17:29:29 -0600 (CST) Date: Fri, 21 Mar 2003 17:29:29 -0600 (CST) From: Dean Roehrich Message-Id: <200303212329.h2LNTT2d7883723@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - add "dmi" mount option for dmapi--for people and code migrating from Irix. X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3299 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: roehrich@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 292 Lines: 13 Date: Fri Mar 21 15:29:14 PST 2003 Workarea: clink.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:142391a linux/fs/xfs/dmapi/dmapi_xfs.c - 1.3 - Add "dmi" mount option. From owner-linux-xfs@oss.sgi.com Fri Mar 21 17:14:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 17:14:44 -0800 (PST) Received: from main.kldp.org ([211.39.143.147]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2M1EUq9009916 for ; Fri, 21 Mar 2003 17:14:32 -0800 Received: from kss by main.kldp.org with local (Exim 3.12 #1 (Debian)) id 18wXad-0000CZ-00; Sat, 22 Mar 2003 10:14:27 +0900 Date: Sat, 22 Mar 2003 10:14:27 +0900 From: Soon-Son Kwon To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: low level access path for xfs operation Message-ID: <20030322101427.A32751@mail.kldp.org> Reply-To: kss@kldp.org References: <20030321124047.A26767@mail.kldp.org> <20030321091423.A28976@infradead.org> <20030321194353.A12729@mail.kldp.org> <20030321204052.GB27409@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030321204052.GB27409@f00f.org>; from cw@f00f.org on Fri, Mar 21, 2003 at 12:40:52PM -0800 X-Operating-System: Debian GNU/Linux Organization: KLDP(Korean Linux Documentation Project) X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3300 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: kss@kldp.org Precedence: bulk X-list: linux-xfs Content-Length: 2936 Lines: 69 On Fri, Mar 21, 2003 at 12:40:52PM -0800, Chris Wedgwood wrote: > On Fri, Mar 21, 2003 at 07:43:53PM +0900, Soon-Son Kwon wrote: > > > What I would like to implement is the snapshot functionality within > > the filesystem. I know LVM supports snapshot but it requires a > > separate volume for each snapshot. I thought snapshot within the > > filesystem would be more convenient. > > How should this work from a user perspective? If a snapshot can be generated/maintained within the filesystem, the user do not have to care for the overall disk layout as long as there are some free spaces in the filesystem while LVM requires additional volume which means even if there are a lot of of free blocks on the source filesystem, the user should allocate another volume for the snapshot. This can be a problem if the system administrator had allocated all the blocks to some volumes already because he/she cannot generate volume for snapshot any more. And the snapshot does not affect anything to normal users. What snapshot can provide to the users are he/she can revert the filesystem to the state when the snapshot was taken which means the user can get an older version of file or deleted files. > > Snapshot functionality requires copy-on-write implementation when > > something tries to modify any block, copy the old content to new > > block and overwrite the new content to that block while the snapshot > > image keeps track of the original content. > > You need to be sure whatever mechanism you use to keep track of block > placements is efficient and the granularity are sane or else the > metadata to keep track of this can be enormous. > > > Anyway, do you think implementing that operation requires modifying > > dm/md code instead of modifying submit_bio()? > > No... I don't see why it should --- ideally you want a pseudo-block > device or similar to place the fs on; this will then be able to track > changes and such like. > > Check the device-mapper and LVM as they effectively do this. So, you mean the following design as follows? (VFS)-(XFS)-(pseudo-block device)-(md)-(dm) I just thought if I can be notified any write/modify operation for a block, then I can copy and allocate the old block to a new location and record that information to the snapshot file, then the original block contents can be (over)written. (of course when generating a snapshot information, it should store every information on which block was in use/free at that time the snapshot was taken as a form of something like block map.) But anyway I am not an expert on this field. Could you please give a little more detailed explanation of the "pseudo block device" or any comment on my descriptions above? Thank you very much... -- -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* (o_ **WTFM** (o_ (o_ //\ (/)_ (/)_ V_/_ http://kldp.org -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From owner-linux-xfs@oss.sgi.com Fri Mar 21 20:55:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Mar 2003 20:56:03 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2M4tDq9013271 for ; Fri, 21 Mar 2003 20:55:53 -0800 Received: from [10.0.0.10] (c-24-245-56-70.mn.client2.attbi.com [24.245.56.70]) by lips.thebarn.com (8.12.8/8.12.6) with ESMTP id h2M4tBxk017049; Fri, 21 Mar 2003 22:55:11 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: CVSUP server is down on ftp.thebarn.com From: Russell Cattelan To: ak03@gte.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030321000525.2639f00b.kabaev@bellatlantic.net> References: <20030321000525.2639f00b.kabaev@bellatlantic.net> Content-Type: text/plain Organization: Message-Id: <1048308910.49263.7.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Mar 2003 22:55:11 -0600 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3301 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: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs Content-Length: 288 Lines: 12 On Thu, 2003-03-20 at 23:05, Alexander Kabaev wrote: > Could someone please fix it? Machine couldn't handle the flood of backlogged email after the power outage. Seems SpamAssassin can be a bit of memory hog. Everything should be up again. -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Sat Mar 22 05:59:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 22 Mar 2003 06:00:02 -0800 (PST) Received: from azrael.blades.cxm (ua57d13hel.dial.kolumbus.fi [62.248.140.57]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2MDx9q9024218 for ; Sat, 22 Mar 2003 05:59:51 -0800 Received: (from blades@localhost) by azrael.blades.cxm (SGI-8.9.3/8.9.3) id PAA15439 for linux-xfs@oss.sgi.com; Sat, 22 Mar 2003 15:59:08 +0200 (EET) X-Authentication-Warning: azrael.blades.cxm: blades set sender to harri.haataja@kolumbus.fi using -f Date: Sat, 22 Mar 2003 15:59:07 +0200 From: Harri Haataja Cc: linux-xfs@oss.sgi.com Subject: Re: CVSUP server is down on ftp.thebarn.com Message-ID: <20030322155907.A15416@azrael.blades.cxm> References: <20030321000525.2639f00b.kabaev@bellatlantic.net> <1048308910.49263.7.camel@lupo.thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1048308910.49263.7.camel@lupo.thebarn.com>; from cattelan@thebarn.com on Fri, Mar 21, 2003 at 10:55:11PM -0600 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3302 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: harri.haataja@kolumbus.fi Precedence: bulk X-list: linux-xfs Content-Length: 596 Lines: 18 On Fri, Mar 21, 2003 at 10:55:11PM -0600, Russell Cattelan wrote: > On Thu, 2003-03-20 at 23:05, Alexander Kabaev wrote: > > Could someone please fix it? > Machine couldn't handle the flood of backlogged email after the power > outage. > Seems SpamAssassin can be a bit of memory hog. > > Everything should be up again. Is it using the client/server setup? (Wasn't that in SA or am I thinking of something else?) Not sure if that cuts down on memory use, but it might if it prevents too many copies being run at once. -- The only person getting his work done by Friday was Robinson Crusoe. From owner-linux-xfs@oss.sgi.com Sun Mar 23 09:58:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Mar 2003 09:58:27 -0800 (PST) Received: from duckman.blub.net (postfix@cust.90.10.adsl.cistron.nl [195.64.90.10]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2NHvZq9021350 for ; Sun, 23 Mar 2003 09:58:16 -0800 Received: from sahara.openoffice.nl (node1ec29.a2000.nl [24.132.236.41]) by duckman.blub.net (Postfix) with ESMTP id 1A69E3FAE0 for ; Sun, 23 Mar 2003 18:57:34 +0100 (CET) Received: by sahara.openoffice.nl (Postfix, from userid 1001) id A32163E24; Sun, 23 Mar 2003 18:57:33 +0100 (CET) Date: Sun, 23 Mar 2003 18:57:33 +0100 From: Valentijn Sessink To: linux-xfs@oss.sgi.com Subject: error 990 out of the blue? Message-ID: <20030323175733.GA32375@openoffice.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Message-Flag: Open Office - Linux for the desktop X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3303 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: valentyn+xfs@nospam.openoffice.nl Precedence: bulk X-list: linux-xfs Content-Length: 1348 Lines: 37 Hello List, Just a short notice, as I don't have any extra info on this. One of my machines showed an "error 990" just out of the blue, 3 days ago. I couldn't find anything - there was a loose inode and that was it. What puzzles me is that this machine has a load of almost 0; the file with problems was /usr/share/mysql/portuguese/errmsg.sys - which is not in use in any way. xfs_check said: disconnected inode 410362, nlink 1 link count mismatch for inode 7536890 (name ?), nlink 0, counted 1 ... xfs_repair put the thing in /lost+found and moving this to /usr/share/mysql/portuguese/errmsg.sys resolved the issue, but it leaves me wondering how this came about? No error messages in the kernel log, no disk errors (used "dd" to read the whole disk to /dev/null). Linux 2.4.19 on a Pentium 133, 48Mb SGI XFS 1.2pre4 with ACLs, quota, no debug enabled (And a VIA vt82c586 (rev 02) IDE controller) Any ideas? Or is this just a single bit that fell of the drive accidentally? Oh, BTW, this was the first time I actually needed xfs_repair and it felt a bit uneasy to see that you can't repair mounted fs's. Well, it's in the faq, I should have read that fine manual before use, I know ;-) Best regards, Valentijn -- http://www.openoffice.nl/ Open Office - Linux Office Solutions Valentijn Sessink valentyn+sessink@nospam.openoffice.nl From owner-linux-xfs@oss.sgi.com Sun Mar 23 21:02:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Mar 2003 21:02:23 -0800 (PST) Received: from relay02.roc.frontiernet.net (relay02.roc.frontiernet.net [66.133.131.35]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2O52Dq9032439 for ; Sun, 23 Mar 2003 21:02:15 -0800 Received: (qmail 11016 invoked from network); 24 Mar 2003 05:02:12 -0000 Received: from unknown (HELO xp1600) ([209.130.163.196]) (envelope-sender ) by relay02.roc.frontiernet.net (FrontierMTA 2.3.2) with SMTP for ; 24 Mar 2003 05:02:12 -0000 From: "Matt & Dawn Pohlman" To: Subject: Installing RedHat on Indy Date: Sun, 23 Mar 2003 23:04:16 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3304 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: dpohlman@frontiernet.net Precedence: bulk X-list: linux-xfs Content-Length: 495 Lines: 8 I just got my first SGI machine (R5000/180mhz) and got IRIX 6.2 loaded and running fine. Now my next project is to try and get RedHat Linux installed on it. I downloaded the RH w/xfs for SGI iso file and burned it onto a CD. Whenever I boot the indy and try to set up the drive for RH/xfs, I get error messages referring to an invalid cd. Any suggestions on how to properly burn the .iso image so the indy can recognize it and what steps are needed to get this loaded on the SGI machine. From owner-linux-xfs@oss.sgi.com Sun Mar 23 23:25:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Mar 2003 23:25:59 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2O7P5q9002942 for ; Sun, 23 Mar 2003 23:25:46 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id h2O7P2KU015712; Mon, 24 Mar 2003 08:25:02 +0100 (CET) Message-Id: <4.3.2.7.2.20030324082033.03629008@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Mar 2003 08:24:59 +0100 To: "Matt & Dawn Pohlman" , From: Seth Mos Subject: Re: Installing RedHat on Indy In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3305 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1175 Lines: 28 At 23:04 23-3-2003 -0800, Matt & Dawn Pohlman wrote: >I just got my first SGI machine (R5000/180mhz) and got IRIX 6.2 loaded and >running fine. Now my next project is to try and get RedHat Linux installed >on it. I downloaded the RH w/xfs for SGI iso file and burned it onto a >CD. Whenever I boot the indy and try to set up the drive for RH/xfs, I get >error messages referring to an invalid cd. Any suggestions on how to >properly burn the .iso image so the indy can recognize it and what steps are >needed to get this loaded on the SGI machine. The Indy is a Mips machine. You will need the mips port of debian (which is fairly complete) or the development version of some redhat packages that are floating around. AFAIK there still is no easy installer software for the Mips machines although it has been some time. The cd that you are trying to install is a Intel CD with XFS filesystem support. Yes, Irix uses XFS but that is the only common between the 2. Mips machines are a entirely different nature from the Intel world. It's the same effect as trying to install windows on a Mac. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Mar 24 00:12:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 00:12:35 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2O8BWq9003988 for ; Mon, 24 Mar 2003 00:12:13 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 51DAEAC42; Mon, 24 Mar 2003 09:24:58 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id CB8BB19097; Mon, 24 Mar 2003 09:24:59 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id C297730881D; Mon, 24 Mar 2003 09:11:28 +0100 (CET) Message-ID: <3E7EBDB0.65DAFBD9@ch.sauter-bc.com> Date: Mon, 24 Mar 2003 09:11:28 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.24-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Valentijn Sessink Cc: linux-xfs@oss.sgi.com Subject: Re: error 990 out of the blue? References: <20030323175733.GA32375@openoffice.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3306 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: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 1545 Lines: 44 You may check this bugreport https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=81925 Simon Valentijn Sessink schrieb: > > Hello List, > > Just a short notice, as I don't have any extra info on this. One of my > machines showed an "error 990" just out of the blue, 3 days ago. > > I couldn't find anything - there was a loose inode and that was it. > > What puzzles me is that this machine has a load of almost 0; the file with > problems was /usr/share/mysql/portuguese/errmsg.sys - which is not in use in > any way. > > xfs_check said: > disconnected inode 410362, nlink 1 > link count mismatch for inode 7536890 (name ?), nlink 0, counted 1 > > ... xfs_repair put the thing in /lost+found and moving this to > /usr/share/mysql/portuguese/errmsg.sys resolved the issue, but it leaves me > wondering how this came about? No error messages in the kernel log, no disk > errors (used "dd" to read the whole disk to /dev/null). > > Linux 2.4.19 on a Pentium 133, 48Mb > SGI XFS 1.2pre4 with ACLs, quota, no debug enabled > (And a VIA vt82c586 (rev 02) IDE controller) > > Any ideas? Or is this just a single bit that fell of the drive accidentally? > > Oh, BTW, this was the first time I actually needed xfs_repair and it felt a > bit uneasy to see that you can't repair mounted fs's. Well, it's in the faq, > I should have read that fine manual before use, I know ;-) > > Best regards, > > Valentijn > -- > http://www.openoffice.nl/ Open Office - Linux Office Solutions > Valentijn Sessink valentyn+sessink@nospam.openoffice.nl From owner-linux-xfs@oss.sgi.com Mon Mar 24 05:24:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 05:24:10 -0800 (PST) Received: from duckman.blub.net (postfix@cust.90.10.adsl.cistron.nl [195.64.90.10]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2ODNNq9027982 for ; Mon, 24 Mar 2003 05:24:04 -0800 Received: from sahara.openoffice.nl (node1ec29.a2000.nl [24.132.236.41]) by duckman.blub.net (Postfix) with ESMTP id 3230F952; Mon, 24 Mar 2003 14:23:19 +0100 (CET) Received: by sahara.openoffice.nl (Postfix, from userid 1001) id 5B2423E59; Mon, 24 Mar 2003 14:23:15 +0100 (CET) Date: Mon, 24 Mar 2003 14:23:15 +0100 From: Valentijn Sessink To: Simon Matter Cc: linux-xfs@oss.sgi.com Subject: Re: error 990 out of the blue? Message-ID: <20030324132315.GD7287@openoffice.nl> References: <20030323175733.GA32375@openoffice.nl> <3E7EBDB0.65DAFBD9@ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E7EBDB0.65DAFBD9@ch.sauter-bc.com> User-Agent: Mutt/1.3.28i X-Message-Flag: Open Office - Linux for the desktop X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3307 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: valentyn+xfs@nospam.openoffice.nl Precedence: bulk X-list: linux-xfs Content-Length: 587 Lines: 18 At Mon, Mar 24, 2003 at 09:11:28AM +0100, Simon Matter wrote: > You may check this bugreport > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=81925 Hmm, that's about a controller failure. It seems a bit weird to have a controller failure help kill a file index that's neither written nor read :-( Oh well, I'll just see what happens during the next month. It /could/ still actually /be/ a controller bug. Thanks for the link. Best regards, Valentijn -- http://www.openoffice.nl/ Open Office - Linux Office Solutions Valentijn Sessink valentyn+sessink@nospam.openoffice.nl From owner-linux-xfs@oss.sgi.com Mon Mar 24 05:36:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 05:37:01 -0800 (PST) Received: from ncstu.ru (ns.stv.runnet.ru [195.209.244.8]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2ODaDq9029209 for ; Mon, 24 Mar 2003 05:36:56 -0800 Received: from [195.209.245.67] (HELO admin-g) by ncstu.ru (CommuniGate Pro SMTP 4.0.6) with ESMTP id 142694 for linux-xfs@oss.sgi.com; Mon, 24 Mar 2003 16:36:07 +0300 Date: Mon, 24 Mar 2003 16:40:30 +0300 From: Oleg Novikov X-Mailer: The Bat! (v1.60f) Reply-To: Oleg Novikov Organization: NCSTU X-Priority: 3 (Normal) Message-ID: <399222921.20030324164030@stv.runnet.ru> To: linux-xfs@oss.sgi.com Subject: ACL and XFS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3309 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: olnow@stv.runnet.ru Precedence: bulk X-list: linux-xfs Content-Length: 644 Lines: 27 Hello, linux-xfs. I setup the xfs 1.2 on kernel version 2.4.19 with support FS_POSIX_ACL. And then i change acl on the directory: chacl u::r-x,g::r-x,o::r-x,m::r-x There ara result of getfacl : # file: profile # owner: student # group: Domain Users user::r-x group::r-x mask::r-x other::r-x default:user::rwx default:group::rwx default:mask::rwx default:other::--- When I try to create in this directory file or another directory the result of this operation is ok. I.e. the mask is r-x, but I can create file. Why acl don't work? -- With redgards, Oleg mailto:olnow@stv.runnet.ru From owner-linux-xfs@oss.sgi.com Mon Mar 24 05:57:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 05:57:18 -0800 (PST) Received: from centauri.artland.com.pl (centauri.artland.com.pl [62.233.164.19]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2ODuSq9029711 for ; Mon, 24 Mar 2003 05:57:12 -0800 Received: (qmail 17278 invoked from network); 24 Mar 2003 14:09:22 -0000 Received: from unknown (HELO ubik) (149.156.124.19) by centauri.artland.com.pl with DES-CBC3-SHA encrypted SMTP; 24 Mar 2003 14:09:22 -0000 Received: from pokryfka by ubik with local (Exim 3.35 #1 (Debian)) id 18xSR3-00013W-00; Mon, 24 Mar 2003 14:56:21 +0100 Date: Mon, 24 Mar 2003 14:56:21 +0100 To: Chris Wedgwood Cc: Greg Freemyer , linux-xfs@oss.sgi.com Subject: Re: xfs cpu usage Message-ID: <20030324135621.GA4038@localhost> References: <20030319175011.RXTR25382.imf58bis.bellsouth.net@tiger2> <20030319181650.GA7459@localhost> <20030320013454.GA6989@f00f.org> <20030320191734.GA18090@localhost> <20030320231535.GA16975@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030320231535.GA16975@f00f.org> User-Agent: Mutt/1.5.4i From: Michal Adamczak X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3310 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: pokryfka@druid.if.uj.edu.pl Precedence: bulk X-list: linux-xfs Content-Length: 903 Lines: 30 > > i know it is and can install it but could You please be more > > specific and tell what kinds of results You'd expect? > > i'd like to see *where* all the CPU time is being consumed didn't have time during weekend but made a few tests now the result of op_time 1 0.0061 0.0000 /lib/libnsl-2.3.1.so 1 0.0061 0.0000 /lib/libproc.so.3.1.6 1 0.0061 0.0000 /oprofile 1 0.0061 0.0000 /usr/bin/mawk 4 0.0242 0.0000 /usr/bin/oprofiled 37 0.2239 0.0000 /bin/bash 38 0.2299 0.0000 /lib/ld-2.3.1.so 81 0.4901 0.0000 /bin/cp 222 1.3433 0.0000 /lib/libc-2.3.1.so 317 1.9182 0.0000 /lib/libncurses.so.5.3 15797 95.5888 0.0000 /boot/v where v is the uncompressed kernel image -- Michal Adamczak pokryfka @ druid.if.uj.edu.pl GS dpu C+++ UL+++++ L+++(++++) w--- !tv h* I code AND I bathe. (seen on slashdot) From owner-linux-xfs@oss.sgi.com Mon Mar 24 08:51:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 08:52:02 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2OGpNq9031903 for ; Mon, 24 Mar 2003 08:51:25 -0800 Received: from rope.americas (rope.americas.sgi.com [128.162.232.44]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2OH2vkq018189 for ; Mon, 24 Mar 2003 11:02:57 -0600 Received: (from roehrich@localhost) by rope.americas (8.11.6/8.11.6) id h2OGpIl01053 for linux-xfs@oss.sgi.com; Mon, 24 Mar 2003 10:51:18 -0600 Date: Mon, 24 Mar 2003 10:51:18 -0600 From: Dean Roehrich Message-Id: <200303241651.h2OGpIl01053@rope.americas> Subject: TAKE - fix initialization of dmapi code X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3311 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: roehrich@rope.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 449 Lines: 16 Date: Mon Mar 24 08:50:43 PST 2003 Workarea: rope.americas.sgi.com:/ptmp/roehrich/2.5.x-xfs-a Author: roehrich Merged by: roehrich Merged mods: 2.4.x-xfs:slinx:142389a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:142389a linux/fs/xfs/linux/xfs_super.h - 1.41 - Merge of 2.4.x-xfs:slinx:142389a by roehrich. Call dmapi_init/dmapi_uninit instead of xfs_dm_init/xfs_dm_exit From owner-linux-xfs@oss.sgi.com Mon Mar 24 11:47:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 11:47:22 -0800 (PST) Received: from woozle.fnal.gov (woozle.fnal.gov [131.225.9.22]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2OJlCq9002520 for ; Mon, 24 Mar 2003 11:47:14 -0800 Received: from fnal.gov (sdsslnx3.fnal.gov [131.225.7.82]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTP id <0HC900H2BQYO80@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Mon, 24 Mar 2003 13:47:12 -0600 (CST) Date: Mon, 24 Mar 2003 13:47:12 -0600 From: Dan Yocum Subject: Re: KDB-ized RH 2.4.18-X kernel? To: xfs-list Message-id: <3E7F60C0.6000708@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 References: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3312 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: yocum@fnal.gov Precedence: bulk X-list: linux-xfs Content-Length: 757 Lines: 32 I compiled the kernel-source...i386.rpm. Maybe Keith might have some insight into this? It looks like it's a linker problem... Keith? Thanks, Dan Joshua Baker-LePain wrote: > On Fri, 21 Mar 2003 at 4:00pm, Dan Yocum wrote > > >>Sorry, I jumped ahead in my error reporting - I tried re-compiling the RH >>kernel source with kdb enabled. No go. Horrible death. Die, die, die. > > > Did you compile the source in /usr/src/linux-2.4 as installed by the > kernel-source*rpm, or did you compile from the SRPM? ISTR that the first > method can be broken sometimes, but I've had had good luck with the > second. > -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Mon Mar 24 15:09:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 15:09:57 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2ON95q9009506 for ; Mon, 24 Mar 2003 15:09:47 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id AF91B1847114; Mon, 24 Mar 2003 15:09:04 -0800 (PST) Date: Mon, 24 Mar 2003 15:09:04 -0800 From: Chris Wedgwood To: Michal Adamczak Cc: Greg Freemyer , linux-xfs@oss.sgi.com Subject: Re: xfs cpu usage Message-ID: <20030324230904.GB27380@f00f.org> References: <20030319175011.RXTR25382.imf58bis.bellsouth.net@tiger2> <20030319181650.GA7459@localhost> <20030320013454.GA6989@f00f.org> <20030320191734.GA18090@localhost> <20030320231535.GA16975@f00f.org> <20030324135621.GA4038@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030324135621.GA4038@localhost> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3313 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 314 Lines: 14 On Mon, Mar 24, 2003 at 02:56:21PM +0100, Michal Adamczak wrote: > the result of op_time > 15797 95.5888 0.0000 /boot/v we actually need the results of where inside the kernel time is being spent... not which userspace objects are consuming time are you able to retest and provide that please? --cw From owner-linux-xfs@oss.sgi.com Mon Mar 24 16:50:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 16:50:49 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2P0ocq9011320 for ; Mon, 24 Mar 2003 16:50:39 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2P0oWuY029667 for ; Mon, 24 Mar 2003 16:50:32 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA17322; Tue, 25 Mar 2003 11:49:14 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id C39FF3000B8; Tue, 25 Mar 2003 11:49:13 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id A9FFF8F; Tue, 25 Mar 2003 11:49:13 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Dan Yocum Cc: xfs-list Subject: Re: KDB-ized RH 2.4.18-X kernel? In-reply-to: Your message of "Mon, 24 Mar 2003 13:47:12 MDT." <3E7F60C0.6000708@fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Mar 2003 11:49:08 +1100 Message-ID: <13516.1048553348@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3314 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: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 377 Lines: 13 On Mon, 24 Mar 2003 13:47:12 -0600, Dan Yocum wrote: >I compiled the kernel-source...i386.rpm. > >Maybe Keith might have some insight into this? It looks like it's a linker >problem... > >Keith? Sorry, my telepathy is not working today. Perhaps if I had some details of the patches used, the compile steps and the errors then I might be able to comment. From owner-linux-xfs@oss.sgi.com Mon Mar 24 20:02:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 20:02:54 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2P42jq9014666 for ; Mon, 24 Mar 2003 20:02:46 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2P42cnH003445 for ; Mon, 24 Mar 2003 20:02:39 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2P41L7L3130530 for ; Tue, 25 Mar 2003 15:01:21 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2P41L5s3043128 for linux-xfs@oss.sgi.com; Tue, 25 Mar 2003 15:01:21 +1100 (EST) Date: Tue, 25 Mar 2003 15:01:21 +1100 (EST) From: Nathan Scott Message-Id: <200303250401.h2P41L5s3043128@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3315 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1814 Lines: 54 Add xfs_io into xfsprogs, an xfs_db-alike program for the XFS IO path which knows about direct IO, space preallocation, realtime files, etc, which the usual tools like dd don't unfortunately. This is a fixed-up version of a hacked tool that I found useful for coding, debugging and testing unwritten extents; hopefully it'll be useful for realtime too. readline support also optionally exists in xfs_db and xfs_io now, but not by default (need to configure with --enable-readline=yes). Handy for command history, editing, etc. cheers. Date: Mon Mar 24 19:48:48 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:142552a cmd/xfsprogs/man/man8/xfs_io.8 - 1.1 cmd/xfsprogs/io/command.c - 1.1 cmd/xfsprogs/io/command.h - 1.1 cmd/xfsprogs/io/xfs_bmap.sh - 1.1 cmd/xfsprogs/io/pread.c - 1.1 cmd/xfsprogs/io/input.h - 1.1 cmd/xfsprogs/io/Makefile - 1.1 cmd/xfsprogs/io/truncate.c - 1.1 cmd/xfsprogs/io/resblks.c - 1.1 cmd/xfsprogs/io/quit.c - 1.1 cmd/xfsprogs/io/pwrite.c - 1.1 cmd/xfsprogs/io/prealloc.c - 1.1 cmd/xfsprogs/io/help.c - 1.1 cmd/xfsprogs/io/input.c - 1.1 cmd/xfsprogs/io/init.h - 1.1 cmd/xfsprogs/io/open.c - 1.1 cmd/xfsprogs/io/init.c - 1.1 cmd/xfsprogs/db/input.c - 1.7 cmd/xfsprogs/db/Makefile - 1.10 cmd/xfsprogs/configure.in - 1.19 cmd/xfsprogs/Makefile - 1.17 cmd/xfsprogs/VERSION - 1.69 cmd/xfsprogs/doc/CHANGES - 1.94 cmd/xfsprogs/bmap/Makefile - 1.9 xfsprogs/bmap/xfs_bmap.c 1.14 renamed to xfsprogs/io/bmap.c 1.1 - xfsprogs/bmap/xfs_bmap.c 1.13 Renamed to xfsprogs/io/bmap.c cmd/xfsprogs/include/xfs_fs.h - 1.24 cmd/xfsprogs/include/builddefs.in - 1.27 cmd/xfsprogs/debian/control - 1.13 cmd/xfsprogs/debian/changelog - 1.62 cmd/xfsprogs/debian/rules - 1.16 From owner-linux-xfs@oss.sgi.com Mon Mar 24 22:09:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 22:09:36 -0800 (PST) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2P68jq9015817 for ; Mon, 24 Mar 2003 22:09:26 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id B2239EDDB17 for ; Tue, 25 Mar 2003 14:08:38 +0800 (PHT) Received: from lawin.leathercollection.ph (lawin.leathercollection.ph [192.168.0.2]) by gusi.leathercollection.ph (Postfix) with ESMTP id 064CBEB4A3C for ; Tue, 25 Mar 2003 14:08:35 +0800 (PHT) Received: by lawin.leathercollection.ph (Postfix, from userid 1000) id AA2D31A4004; Tue, 25 Mar 2003 14:08:34 +0800 (PHT) Date: Tue, 25 Mar 2003 14:08:34 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: mkfs.xfs and zeroing of unwritten extents (was: TAKE - xfsprogs) Message-ID: <20030325060834.GF22572@leathercollection.ph> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200303250401.h2P41L5s3043128@snort.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303250401.h2P41L5s3043128@snort.melbourne.sgi.com> X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3316 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: jijo@free.net.ph Precedence: bulk X-list: linux-xfs Content-Length: 2018 Lines: 39 On Tue, Mar 25, 2003 at 03:01:21PM +1100, Nathan Scott wrote: > This is a fixed-up version of a hacked tool that I found useful for > coding, debugging and testing unwritten extents; hopefully it'll be > useful for realtime too. I read in the announcement about the new Debian package for xfsprogs that zeroing out of unwritten extents is now enabled by default in mkfs.xfs. A search about unwritten extents pointed me to . I haven't been in touch with XFS development lately[1], so please pardon me if this was discussed previously. Is there anything that has to be done for systems that were created with slightly older versions of xfsprogs (eg: 2.3.11)? What problems to XFS filesystems created on top of previously existing filesystems (eg: ext3) pose? --> Jijo [1] I used to be an avid XFS user, then I ran into problems[2] that I couldn't explain, and couldn't get anyone else to figure out. I was forced to shift to ext3, and things ran smoothly as soon as I "jumped ship". Then after around four months, the system again ran into a very similar kernel panic. I had an opportunity to make the server breathe awhile after that, so I decided to run a full memory scan using memtest86, which I can't recall having done before. It found ploblems in a small section of one of the modules, that I have now replaced. With this new information, I am confident the problems I ran into before were largely caused by the problematic RAM and the way XFS stresses systems more than ext3 does. Because of the very significant performance hit of using ext3 instead of XFS, I took time to transfer everything back, and have for a week now been happily running XFS again. :) [2] http://marc.theaimsgroup.com/?l=linux-xfs&m=103369234209733&w=2 -- Federico Sevilla III : http://jijo.free.net.ph : When we speak of free Network Administrator : The Leather Collection, Inc. : software we refer to GnuPG Key ID : 0x93B746BE : freedom, not price. From owner-linux-xfs@oss.sgi.com Mon Mar 24 22:45:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Mar 2003 22:45:19 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2P6jCq9016479 for ; Mon, 24 Mar 2003 22:45:13 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2P6j5nH011708 for ; Mon, 24 Mar 2003 22:45:06 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA20178 for ; Tue, 25 Mar 2003 17:43:50 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id RAA24440 for ; Tue, 25 Mar 2003 17:43:49 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2P6ekuQ032165 for ; Tue, 25 Mar 2003 17:40:46 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2P6ekVX032163 for linux-xfs@oss.sgi.com; Tue, 25 Mar 2003 17:40:46 +1100 Date: Tue, 25 Mar 2003 17:40:46 +1100 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Re: mkfs.xfs and zeroing of unwritten extents (was: TAKE - xfsprogs) Message-ID: <20030325064046.GD6306@frodo> References: <200303250401.h2P41L5s3043128@snort.melbourne.sgi.com> <20030325060834.GF22572@leathercollection.ph> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030325060834.GF22572@leathercollection.ph> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3317 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 891 Lines: 27 On Tue, Mar 25, 2003 at 02:08:34PM +0800, Federico Sevilla III wrote: > ... > I read in the announcement about the new Debian package for xfsprogs > that zeroing out of unwritten extents is now enabled by default in > mkfs.xfs. A search about unwritten extents pointed me to > . There has been more extensive discussion on the XFS list recently; see the archives, I don't have a pointer handy. > I haven't been in touch with XFS development lately[1], so please pardon > me if this was discussed previously. Is there anything that has to be > done for systems that were created with slightly older versions of > xfsprogs (eg: 2.3.11)? You can enable unwritten extents using the xfs_admin(8) -e option. > What problems to XFS filesystems created on top > of previously existing filesystems (eg: ext3) pose? None at all. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Mar 25 00:14:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 00:14:25 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2P8ECq9017564 for ; Tue, 25 Mar 2003 00:14:14 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id h2P8E8sN054349; Tue, 25 Mar 2003 09:14:08 +0100 (CET) Message-Id: <4.3.2.7.2.20030325085227.02421458@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Mar 2003 09:14:03 +0100 To: Keith Owens , Dan Yocum From: Seth Mos Subject: Re: KDB-ized RH 2.4.18-X kernel? Cc: xfs-list In-Reply-To: <13516.1048553348@kao2.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3318 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 3177 Lines: 81 At 11:49 25-3-2003 +1100, Keith Owens wrote: >On Mon, 24 Mar 2003 13:47:12 -0600, >Dan Yocum wrote: > >I compiled the kernel-source...i386.rpm. > > > >Maybe Keith might have some insight into this? It looks like it's a linker > >problem... > > > >Keith? > >Sorry, my telepathy is not working today. Perhaps if I had some >details of the patches used, the compile steps and the errors then I >might be able to comment. I reported this problem earlier as well when I was working on the 2.4.18-24 kernel IIRC and it had to do with the linking. You commented on this that the symbols were not exported right. Here is the first email I sent. 1.2pre5 was hip then. Cheers ---------------snip---------------------- At 08:13 21-1-2003 +1100, Keith Owens wrote: >On Mon, 20 Jan 2003 17:11:46 +0100, >Seth Mos wrote: > >At 10:24 20-1-2003 -0500, Jeremy Jackson wrote: > >> > > >>Any time I've had "internal compiler error", it's been a hardware > >>problem. ie bad heatsing or memory. I suggest running memtest86.com's > >>test utility. > > > >That's not the case here. In fact the error is that the kdb symbols are not > >ending up in the right place when it is linking as far I can tell. > >Details please, my telepathy is not working this morning ... kallsyms pass 1 init/main.o: In function `parse_options': init/main.o(.text.init+0x5e6): undefined reference to `kdb_on' init/main.o(.text.init+0x5eb): undefined reference to `kdb_flags' init/main.o(.text.init+0x622): undefined reference to `kdb_on' init/main.o(.text.init+0x64f): undefined reference to `kdb_on' init/main.o(.text.init+0x674): undefined reference to `kdb_flags' init/main.o(.text.init+0x67f): undefined reference to `kdb_on' init/main.o(.text.init+0x687): undefined reference to `kdb_flags' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2aba): undefined reference to `kdb_printf' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2ac4): undefined reference to `kdb_symbol_print' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2ad1): undefined reference to `kdb_printf' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2ae9): undefined reference to `kdb_printf' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2af3): undefined reference to `kdb_symbol_print' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2afd): undefined reference to `kdb_printf' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2b07): undefined reference to `kdb_symbol_print' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2b14): undefined reference to `kdb_printf' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o: In function `fetch_data': /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2b79): undefined reference to `kdb_printf' make[1]: *** [kallsyms] Fout 1 make: *** [vmlinux] Fout 2 error: Bad exit status from /var/tmp/rpm-tmp.14321 (%build) ------------------snip------------------- -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Mar 25 00:52:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 00:52:44 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2P8psq9018917 for ; Tue, 25 Mar 2003 00:52:34 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2P8plnH018896 for ; Tue, 25 Mar 2003 00:51:48 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA20839; Tue, 25 Mar 2003 19:50:27 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 0E8723000B8; Tue, 25 Mar 2003 19:50:26 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id C6B528F; Tue, 25 Mar 2003 19:50:26 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Seth Mos Cc: Dan Yocum , xfs-list Subject: Re: KDB-ized RH 2.4.18-X kernel? In-reply-to: Your message of "Tue, 25 Mar 2003 09:14:03 BST." <4.3.2.7.2.20030325085227.02421458@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Mar 2003 19:50:21 +1100 Message-ID: <18343.1048582221@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3319 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: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1148 Lines: 30 On Tue, 25 Mar 2003 09:14:03 +0100, Seth Mos wrote: >I reported this problem earlier as well when I was working on the 2.4.18-24 >kernel IIRC and it had to do with the linking. >kallsyms pass 1 >init/main.o: In function `parse_options': >init/main.o(.text.init+0x5e6): undefined reference to `kdb_on' >init/main.o(.text.init+0x5eb): undefined reference to `kdb_flags' >init/main.o(.text.init+0x622): undefined reference to `kdb_on' >init/main.o(.text.init+0x64f): undefined reference to `kdb_on' >init/main.o(.text.init+0x674): undefined reference to `kdb_flags' >init/main.o(.text.init+0x67f): undefined reference to `kdb_on' >init/main.o(.text.init+0x687): undefined reference to `kdb_flags' You only applied the kdb-i386 patch and did not apply the kdb-common patch. If the kdb-common patch was applied the the build did not descend into the kdb directory, probably a missing patch to the top level Makefile, it should look like this. LIBS =$(TOPDIR)/lib/lib.a SUBDIRS =kernel drivers mm fs net ipc lib ifeq ($(CONFIG_KDB),y) CORE_FILES += kdb/kdb.o SUBDIRS += kdb endif DRIVERS-n := From owner-linux-xfs@oss.sgi.com Tue Mar 25 02:22:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 02:22:35 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2PAMNq9021468 for ; Tue, 25 Mar 2003 02:22:23 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2PAMNrt021466 for linux-xfs@oss.sgi.com; Tue, 25 Mar 2003 02:22:23 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2PAMLqB021453 for ; Tue, 25 Mar 2003 02:22:22 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2PA9bCm020065; Tue, 25 Mar 2003 02:09:37 -0800 Date: Tue, 25 Mar 2003 02:09:37 -0800 Message-Id: <200303251009.h2PA9bCm020065@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3320 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 565 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From atu@dmeti.dp.ua 2003-03-25 02:09 ------- Kernel recompiled with xfs-2003-03-23, and without any additional patches. With the same conditions, whan I enter kdb and use 'ps', some untrivial output occures: all processes, exept init have string: Error: does not matsh running process tables:( 0xc03e0000). As the result, bta shows no useful information. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Mar 25 03:22:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 03:22:30 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2PBMMq9024160 for ; Tue, 25 Mar 2003 03:22:22 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2PBMMsQ024158 for linux-xfs@oss.sgi.com; Tue, 25 Mar 2003 03:22:22 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2PBMKqB024144 for ; Tue, 25 Mar 2003 03:22:20 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2PAdxOm022158; Tue, 25 Mar 2003 02:39:59 -0800 Date: Tue, 25 Mar 2003 02:39:59 -0800 Message-Id: <200303251039.h2PAdxOm022158@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3321 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 326 Lines: 16 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From kaos@sgi.com 2003-03-25 02:39 ------- How are you entering kdb? I need the output from these kdb commands cpu ps ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Mar 25 06:30:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 06:30:58 -0800 (PST) Received: from stargate.coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.114.72.97]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PEUjq9029041 for ; Tue, 25 Mar 2003 06:30:47 -0800 Received: from contact.skynet.coplanar.net (contact.skynet.coplanar.net [192.168.7.125]) by stargate.coplanar.net (8.12.8/8.12.5) with ESMTP id h2PEUcAW002664; Tue, 25 Mar 2003 09:30:40 -0500 Subject: Re: low level access path for xfs operation From: Jeremy Jackson To: kss@kldp.org Cc: Chris Wedgwood , linux-xfs@oss.sgi.com In-Reply-To: <20030322101427.A32751@mail.kldp.org> References: <20030321124047.A26767@mail.kldp.org> <20030321091423.A28976@infradead.org> <20030321194353.A12729@mail.kldp.org> <20030321204052.GB27409@f00f.org> <20030322101427.A32751@mail.kldp.org> Content-Type: text/plain Organization: Message-Id: <1048602638.1261.9.camel@contact.skynet.coplanar.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 25 Mar 2003 09:30:38 -0500 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3322 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: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 3274 Lines: 74 If using EVMS with dm/LVM, it is easy to make another volume. The administrator needs to learn the hard way not to fill up the disk with a filesystem that cannot shrink. (I know I have) It will create other problems besides not having room to snapshot. Sure would be nice if XFS *could* shrink. The other features outweigh this disadvantage for me. Jeremy On Fri, 2003-03-21 at 20:14, Soon-Son Kwon wrote: > On Fri, Mar 21, 2003 at 12:40:52PM -0800, Chris Wedgwood wrote: > > On Fri, Mar 21, 2003 at 07:43:53PM +0900, Soon-Son Kwon wrote: > > > > > What I would like to implement is the snapshot functionality within > > > the filesystem. I know LVM supports snapshot but it requires a > > > separate volume for each snapshot. I thought snapshot within the > > > filesystem would be more convenient. > > > > How should this work from a user perspective? > > If a snapshot can be generated/maintained within the filesystem, > the user do not have to care for the overall disk layout as long > as there are some free spaces in the filesystem while LVM > requires additional volume which means even if there are a lot of > of free blocks on the source filesystem, the user should allocate > another volume for the snapshot. This can be a problem if the > system administrator had allocated all the blocks to some > volumes already because he/she cannot generate volume for snapshot > any more. > > And the snapshot does not affect anything to normal users. > What snapshot can provide to the users are he/she can revert > the filesystem to the state when the snapshot was taken > which means the user can get an older version of file or deleted > files. > > > > Snapshot functionality requires copy-on-write implementation when > > > something tries to modify any block, copy the old content to new > > > block and overwrite the new content to that block while the snapshot > > > image keeps track of the original content. > > > > You need to be sure whatever mechanism you use to keep track of block > > placements is efficient and the granularity are sane or else the > > metadata to keep track of this can be enormous. > > > > > Anyway, do you think implementing that operation requires modifying > > > dm/md code instead of modifying submit_bio()? > > > > No... I don't see why it should --- ideally you want a pseudo-block > > device or similar to place the fs on; this will then be able to track > > changes and such like. > > > > Check the device-mapper and LVM as they effectively do this. > > So, you mean the following design as follows? > > (VFS)-(XFS)-(pseudo-block device)-(md)-(dm) > > I just thought if I can be notified any write/modify operation for > a block, then I can copy and allocate the old block to a new location > and record that information to the snapshot file, then the original > block contents can be (over)written. > > (of course when generating a snapshot information, it should > store every information on which block was in use/free at that time > the snapshot was taken as a form of something like block map.) > > But anyway I am not an expert on this field. > Could you please give a little more detailed explanation of > the "pseudo block device" or any comment on my descriptions above? > > Thank you very much... From owner-linux-xfs@oss.sgi.com Tue Mar 25 07:08:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 07:08:26 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PF7Zq9029850 for ; Tue, 25 Mar 2003 07:08:15 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h2PF7VMq005351; Tue, 25 Mar 2003 16:07:31 +0100 (CET) Message-Id: <4.3.2.7.2.20030325160606.03aff8c8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Mar 2003 16:07:08 +0100 To: Keith Owens From: Seth Mos Subject: Re: KDB-ized RH 2.4.18-X kernel? Cc: Dan Yocum , xfs-list In-Reply-To: <18343.1048582221@kao2.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3323 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 467 Lines: 18 > >You only applied the kdb-i386 patch and did not apply the kdb-common >patch. If the kdb-common patch was applied the the build did not >descend into the kdb directory, probably a missing patch to the top >level Makefile, it should look like this. You are right. I'll look into it. The kdb-common wasn't in the pre5 rpm anyways which might explain it. And I normally don't rebuild with KDB. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Mar 25 08:30:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 08:31:17 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PGUpq9032143 for ; Tue, 25 Mar 2003 08:30:56 -0800 Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65]) by palrel11.hp.com (Postfix) with ESMTP id 4D2611C00D2F for ; Tue, 25 Mar 2003 08:30:51 -0800 (PST) Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63]) by xparelay2.ptp.hp.com (Postfix) with ESMTP id 43AD21C00AC8 for ; Tue, 25 Mar 2003 08:30:51 -0800 (PST) Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2655.55) id ; Tue, 25 Mar 2003 08:30:51 -0800 Message-ID: From: "HABBINGA,ERIK (HP-Loveland,ex1)" To: "'linux-xfs@oss.sgi.com'" Subject: crash in xfs_inactive Date: Tue, 25 Mar 2003 08:30:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3324 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: erik.habbinga@hp.com Precedence: bulk X-list: linux-xfs Content-Length: 3047 Lines: 82 I've gotten the following crash in xfs_inactive a few times after pushing a server very hard running the SPEC SFS NFS test. This crash doesn't happen every time unfortunately. Unable to handle kernel NULL pointer dereference at virtual address 00000008 801c932e *pde = 72db8001 Oops: 0000 CPU: 2 EIP: 0010:[<801c932e>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 801c929c ebx: bc0139a0 ecx: 00000001 edx: 000081b6 esi: f7746000 edi: 00000000 ebp: bc0139b8 esp: f7bd9ee8 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 7, stackpage=f7bd9000) Stack: b335bc40 f7bd9f58 b9f1e328 f7bd9f60 00000000 00000296 c4bc8c80 801da3e9 bc0139b8 00000000 b335bc40 801d9348 b335bc40 b335bc60 8014ca1e b335bc60 b335bc60 8014caa4 b335bc60 d5bf0dc0 d5bf0dc8 8014cdd4 f7bd9f58 00000013 Call Trace: [<801da3e9>] [<801d9348>] [<8014ca1e>] [<8014caa4>] [<8014cdd4>] [<8014ce0f>] [<8012fce7>] [<8012fd3c>] [<8012fe41>] [<8012fea6>] [<8012ff Code: 8b 47 08 f6 00 01 0f 85 80 03 00 00 83 bb 34 01 00 00 00 0f >>EIP; 801c932e <===== >>eax; 801c929c >>ebx; bc0139a0 >>edx; 000081b6 Before first symbol >>esi; f7746000 >>ebp; bc0139b8 >>esp; f7bd9ee8 Trace; 801da3e9 Trace; 801d9348 Trace; 8014ca1e Trace; 8014caa4 Trace; 8014cdd4 Trace; 8014ce0f Trace; 8012fce7 Trace; 8012fd3c Trace; 8012fe41 Trace; 8012fea6 Code; 801c932e 00000000 <_EIP>: Code; 801c932e <===== 0: 8b 47 08 mov 0x8(%edi),%eax <===== Code; 801c9331 3: f6 00 01 testb $0x1,(%eax) Code; 801c9334 6: 0f 85 80 03 00 00 jne 38c <_EIP+0x38c> Code; 801c933a c: 83 bb 34 01 00 00 00 cmpl $0x0,0x134(%ebx) Code; 801c9341 13: 0f 00 00 sldtl (%eax) The code in question is derefencing the vp->v_vfsp pointer and failing because the vp pointer is NULL for some scary unknown reason: Dissassembly of xfs_inactive: /src/kernel/linux/fs/xfs/xfs_vnodeops.c:1666 error = 0; /* If this is a read-only mount, don't do this (would generate I/O) */ if (vp->v_vfsp->vfs_flag & VFS_RDONLY) 801c932e: 8b 47 08 mov 0x8(%edi),%eax 801c9331: f6 00 01 testb $0x1,(%eax) 801c9334: 0f 85 80 03 00 00 jne 801c96ba We're running 2.4.20 with XFS CVS from March 17th. I did see this crash on earlier CVS downloads, but wanted to see the crash a few more times before mentioning it. Erik Habbinga From owner-linux-xfs@oss.sgi.com Tue Mar 25 09:40:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 09:40:34 -0800 (PST) Received: from mail.cnes.com (mail.cnes.com [208.179.92.38]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PHeJq9001281 for ; Tue, 25 Mar 2003 09:40:20 -0800 Received: from oz.cnes.com (wall.cnes.com [208.179.92.60]) by mail.cnes.com (8.12.8/8.12.8) with ESMTP id h2PHeE0L009618 for ; Tue, 25 Mar 2003 09:40:14 -0800 Received: from localhost (localhost [127.0.0.1]) by oz.cnes.com (8.9.3/8.9.3) with ESMTP id JAA25247 for ; Tue, 25 Mar 2003 09:40:13 -0800 (PST) Date: Tue, 25 Mar 2003 09:40:13 -0800 From: Scott Jepson To: linux-xfs@oss.sgi.com Subject: Re: crash in xfs_inactive In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3325 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: scott@cnes.com Precedence: bulk X-list: linux-xfs Content-Length: 3976 Lines: 107 Erik, Are you using NFS patches from nfs.sourceforge.net? If so take a look a Bug 195 in bugzilla and you will notice there is an issue with the patch to do Direct IO on NFS. I had the same output when I had the patch installed. -Scott ---------------------------------------------------------------- Scott Jepson, Managing Partner Email: scott@cnes.com Creative Network Services, LLC http://www.cnes.com (310)470-6140 ---------------------------------------------------------------- On Tue, 25 Mar 2003, HABBINGA,ERIK (HP-Loveland,ex1) wrote: > Date: Tue, 25 Mar 2003 08:30:45 -0800 > From: "HABBINGA,ERIK (HP-Loveland,ex1)" > To: "'linux-xfs@oss.sgi.com'" > Subject: crash in xfs_inactive > > I've gotten the following crash in xfs_inactive a few times after pushing a > server very hard running the SPEC SFS NFS test. This crash doesn't happen > every time unfortunately. > > Unable to handle kernel NULL pointer dereference at virtual address 00000008 > 801c932e > *pde = 72db8001 > Oops: 0000 > CPU: 2 > EIP: 0010:[<801c932e>] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010202 > eax: 801c929c ebx: bc0139a0 ecx: 00000001 edx: 000081b6 > esi: f7746000 edi: 00000000 ebp: bc0139b8 esp: f7bd9ee8 > ds: 0018 es: 0018 ss: 0018 > Process kswapd (pid: 7, stackpage=f7bd9000) > Stack: b335bc40 f7bd9f58 b9f1e328 f7bd9f60 00000000 00000296 c4bc8c80 > 801da3e9 > bc0139b8 00000000 b335bc40 801d9348 b335bc40 b335bc60 8014ca1e > b335bc60 > b335bc60 8014caa4 b335bc60 d5bf0dc0 d5bf0dc8 8014cdd4 f7bd9f58 > 00000013 > Call Trace: [<801da3e9>] [<801d9348>] [<8014ca1e>] [<8014caa4>] > [<8014cdd4>] > [<8014ce0f>] [<8012fce7>] [<8012fd3c>] [<8012fe41>] [<8012fea6>] > [<8012ff > Code: 8b 47 08 f6 00 01 0f 85 80 03 00 00 83 bb 34 01 00 00 00 0f > > > >>EIP; 801c932e <===== > > >>eax; 801c929c > >>ebx; bc0139a0 > >>edx; 000081b6 Before first symbol > >>esi; f7746000 > >>ebp; bc0139b8 > >>esp; f7bd9ee8 > > Trace; 801da3e9 > Trace; 801d9348 > Trace; 8014ca1e > Trace; 8014caa4 > Trace; 8014cdd4 > Trace; 8014ce0f > Trace; 8012fce7 > Trace; 8012fd3c > Trace; 8012fe41 > Trace; 8012fea6 > > Code; 801c932e > 00000000 <_EIP>: > Code; 801c932e <===== > 0: 8b 47 08 mov 0x8(%edi),%eax <===== > Code; 801c9331 > 3: f6 00 01 testb $0x1,(%eax) > Code; 801c9334 > 6: 0f 85 80 03 00 00 jne 38c <_EIP+0x38c> > Code; 801c933a > c: 83 bb 34 01 00 00 00 cmpl $0x0,0x134(%ebx) > Code; 801c9341 > 13: 0f 00 00 sldtl (%eax) > > The code in question is derefencing the vp->v_vfsp pointer and failing > because the vp pointer is NULL for some scary unknown reason: > > Dissassembly of xfs_inactive: > /src/kernel/linux/fs/xfs/xfs_vnodeops.c:1666 > error = 0; > > /* If this is a read-only mount, don't do this (would generate I/O) > */ > if (vp->v_vfsp->vfs_flag & VFS_RDONLY) > 801c932e: 8b 47 08 mov 0x8(%edi),%eax > 801c9331: f6 00 01 testb $0x1,(%eax) > 801c9334: 0f 85 80 03 00 00 jne 801c96ba > > We're running 2.4.20 with XFS CVS from March 17th. I did see this crash on > earlier CVS downloads, but wanted to see the crash a few more times before > mentioning it. > > Erik Habbinga > > > From owner-linux-xfs@oss.sgi.com Tue Mar 25 09:51:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 09:51:08 -0800 (PST) Received: from gateway.max-t.com (h216-18-124-229.gtconnect.net [216.18.124.229]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PHp4q9003656 for ; Tue, 25 Mar 2003 09:51:05 -0800 Received: from dog.max-t.internal ([192.168.1.124]) by gateway.max-t.com with esmtp (Exim 3.32 #3) id 18xsbd-0002wq-00; Tue, 25 Mar 2003 12:53:01 -0500 Received: from localhost (sdoyon@localhost) by dog.max-t.internal (8.11.6/8.11.6) with ESMTP id h2PHoYK15657; Tue, 25 Mar 2003 12:50:35 -0500 X-Authentication-Warning: dog.max-t.internal: sdoyon owned process doing -bs Date: Tue, 25 Mar 2003 12:50:34 -0500 (EST) From: =?ISO-8859-1?Q?St=E9phane_Doyon?= X-X-Sender: sdoyon@dog.max-t.internal To: nathans@sgi.com, Subject: Maximum log stripe size Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3326 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: sdoyon@max-t.com Precedence: bulk X-list: linux-xfs Content-Length: 546 Lines: 20 Hi, mkfs.xfs insists that the log stripe unit (-l sunit) must be smaller than 256K. See xfs_mkfs.c around line 1730: if ((lsunit * blocksize) > 256 * 1024) { fprintf(stderr, _("log stripe unit (%d bytes) is too large for kernel to handle (max 256k)\n"), (lsunit * blocksize)); exit(1); } Can anyone please tell me whether this is really necessary? Our SCSI RAID controllers would much prefer stripes in the order of 1MB. And the kernel doesn't seem to mind. Thank you From owner-linux-xfs@oss.sgi.com Tue Mar 25 10:34:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 10:34:49 -0800 (PST) Received: from zipcode.az.mvista.com (fw-az.mvista.com [65.200.49.158]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PIY2q9009733 for ; Tue, 25 Mar 2003 10:34:43 -0800 Received: from mvista.com (persist.az.mvista.com [10.50.1.246]) by zipcode.az.mvista.com (8.9.3/8.9.3) with ESMTP id LAA08217 for ; Tue, 25 Mar 2003 11:46:07 -0700 Message-ID: <3E809EB1.6000904@mvista.com> Date: Tue, 25 Mar 2003 11:23:45 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Need some help with cause of Oops in XFS 1.2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3327 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: sdake@mvista.com Precedence: bulk X-list: linux-xfs Content-Length: 5141 Lines: 113 XFS Developers, Ok here is what I have done: I have a tree that already had XFS 1.1 (with a bunch of other stuff) included. I hand applied the XFS 1.2 on top of XFS 1.1 patch and everything seems to work fine, except when I run bonnie++ and under load (Writing intelligently operation), I receive the following Oops: Mar 24 15:20:13 192 kernel: invalid operand: 0000 Mar 24 15:20:13 192 kernel: CPU: 0 Mar 24 15:20:13 192 kernel: EIP: 0010:[] Not tainted Mar 24 15:20:13 192 kernel: EFLAGS: 00010286 Mar 24 15:20:13 192 kernel: eax: 00000037 ebx: 000000f8 ecx: 00000008 edx: 00000000 Mar 24 15:20:13 192 kernel: esi: c30000bc edi: 00000000 ebp: c2a517c0 esp: f7465e80 Mar 24 15:20:13 192 kernel: ds: 0018 es: 0018 ss: 0018 Mar 24 15:20:13 192 kernel: Process bonnie++ (pid: 114, stackpage=f7465000) Mar 24 15:20:13 192 kernel: Stack: c0327060 000000f8 00018541 00000000 f748ee80 c012abf6 f7465ec0 00001000 Mar 24 15:20:13 192 kernel: 00000000 00001000 00001000 00001000 1650f000 00000000 f740e320 f740e3d4 Mar 24 15:20:13 192 kernel: 00000000 3e7f849d 000e6b32 3e7f849d 3852bb50 0640d230 f7465f64 1650e000 Mar 24 15:20:13 192 kernel: Call Trace: [] [] [] [] [] Mar 24 15:20:13 192 kernel: [] Mar 24 15:20:13 192 kernel: Mar 24 15:20:13 192 kernel: Code: 0f 0b 83 c4 0c 8d 46 04 39 46 04 74 12 5b 89 f0 31 c9 ba 03 Mar 24 15:20:13 192 kernel: invalid operand: 0000 Mar 24 15:20:13 192 kernel: CPU: 0 Mar 24 15:20:13 192 kernel: EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 Mar 24 15:20:13 192 kernel: EFLAGS: 00010286 Mar 24 15:20:13 192 kernel: eax: 00000037 ebx: 000000f8 ecx: 00000008 edx: 00000000 Mar 24 15:20:13 192 kernel: esi: c30000bc edi: 00000000 ebp: c2a517c0 esp: f7465e80 Mar 24 15:20:13 192 kernel: ds: 0018 es: 0018 ss: 0018 Mar 24 15:20:13 192 kernel: Process bonnie++ (pid: 114, stackpage=f7465000) Mar 24 15:20:13 192 kernel: Stack: c0327060 000000f8 00018541 00000000 f748ee80 c012abf6 f7465ec0 00001000 Mar 24 15:20:13 192 kernel: 00000000 00001000 00001000 00001000 1650f000 00000000 f740e320 f740e3d4 Mar 24 15:20:13 192 kernel: 00000000 3e7f849d 000e6b32 3e7f849d 3852bb50 0640d230 f7465f64 1650e000 Mar 24 15:20:13 192 kernel: Call Trace: [] [] [] [] [] Mar 24 15:20:13 192 kernel: [] Mar 24 15:20:13 192 kernel: Code: 0f 0b 83 c4 0c 8d 46 04 39 46 04 74 12 5b 89 f0 31 c9 ba 03 >>EIP; c0128331 <===== Trace; c012abf6 Trace; c024ad64 Trace; c02467a6 Trace; c0135836 Trace; c0116f9b Trace; c0106d03 Code; c0128331 00000000 <_EIP>: Code; c0128331 <===== 0: 0f 0b ud2a <===== Code; c0128333 2: 83 c4 0c add $0xc,%esp Code; c0128336 5: 8d 46 04 lea 0x4(%esi),%eax Code; c0128339 8: 39 46 04 cmp %eax,0x4(%esi) Code; c012833c b: 74 12 je 1f <_EIP+0x1f> c0128350 Code; c012833e d: 5b pop %ebx Code; c012833f e: 89 f0 mov %esi,%eax Code; c0128341 10: 31 c9 xor %ecx,%ecx Code; c0128343 12: ba 03 00 00 00 mov $0x3,%edx I tracked down the oops to a BUG() call in unlock_page which is triggered when a page that is already unlocked is attempted to be unlocked again (this just wouldn't work which is why there is a bug...). I read through the code in generic_file_write_nolock and it looks to me as if the page is being locked, and then unlocked consistently. If I put syslog() calls in the bonnie++ output to write the chunk count, (slowing down the I/Os) there is no oops. Bonnie++ consistently Oops on the 45703 write. I checked every function in the Oops call path and all the functions are identical to taking linux 2.4.19 and applying XFS 1.2 except for 2.4.19 isms. I though perhaps some changes to the mm layer in 2.4.19 would be the cause, so I modified my 2.4.18 to match the 2.4.19 implementation + xfs core patch with same results. I am running on Linux 2.4.18 with significant modifications (although most of the memory manager and filesystem layer are the same as 2.4.18). I am running UP on a custom Pentium4 board/processor (well tested before this to be operational). I have run the same bonnie++ benchmark on other filesystems without incident. I was thinking I could take the xfs_write routine from 1.1 and meld it into the 1.2 source codes, but this looks to be very painful, and hey, I want 1.2 anyway ;) Anyone know why I am receiving this Oops? Thanks -steve From owner-linux-xfs@oss.sgi.com Tue Mar 25 10:42:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 10:42:15 -0800 (PST) Received: from ubergeek (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PIfWq9010355 for ; Tue, 25 Mar 2003 10:42:13 -0800 Received: (qmail 4888 invoked by uid 500); 25 Mar 2003 18:38:24 -0000 Subject: Rebuilding the src rpm for xfs 1.2 redhat kernel. From: Austin Gonyou To: xfs-list Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1048617504.30660.58.camel@UberGeek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 25 Mar 2003 12:38:24 -0600 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3328 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: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 188 Lines: 8 I want it to build for Pentium IVs and SMP but I'm building it on a PIII box. What is the best way to accomplish this? Tia. -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Mar 25 10:51:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 10:52:04 -0800 (PST) Received: from woozle.fnal.gov (woozle.fnal.gov [131.225.9.22]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PIpJq9010926 for ; Tue, 25 Mar 2003 10:51:59 -0800 Received: from fnal.gov (sdsslnx3.fnal.gov [131.225.7.82]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTP id <0HCB003VHJ1IP3@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Tue, 25 Mar 2003 12:51:19 -0600 (CST) Date: Tue, 25 Mar 2003 12:51:18 -0600 From: Dan Yocum Subject: Re: KDB-ized RH 2.4.18-X kernel? To: Keith Owens Cc: xfs-list Message-id: <3E80A526.2050301@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 References: <13516.1048553348@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3329 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: yocum@fnal.gov Precedence: bulk X-list: linux-xfs Content-Length: 1019 Lines: 40 Keith, I simply used the kernel-source-2.4.18-18.i386.rpm, copied the configs/kernel-2.4.18-i686-smp.config to .config, 'make menuconfig,' enable kdb, save, exit, 'make dep && make clean && make bzImage'. Looking at the patch list in the kernel-2.4.18-18.src.rpm I see that there's only one kdb patch, called linux-2.4.19-kdb.patch, I assumed that this was a complete patch containing the common as well as the arch dependent kdb patches. Thanks, Dan Keith Owens wrote: > On Mon, 24 Mar 2003 13:47:12 -0600, > Dan Yocum wrote: > >>I compiled the kernel-source...i386.rpm. >> >>Maybe Keith might have some insight into this? It looks like it's a linker >>problem... >> >>Keith? > > > Sorry, my telepathy is not working today. Perhaps if I had some > details of the patches used, the compile steps and the errors then I > might be able to comment. > > > -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Tue Mar 25 11:02:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 11:02:34 -0800 (PST) Received: from esds.vss.fsi.com (adsl-66-136-174-212.dsl.stlsmo.swbell.net [66.136.174.212]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PJ2Rq9011620 for ; Tue, 25 Mar 2003 11:02:29 -0800 Received: from mosix.vss.fsi.com (mosix [198.51.27.89]) by esds.vss.fsi.com (8.9.1a/8.9.1) with ESMTP id NAA07545 for ; Tue, 25 Mar 2003 13:02:21 -0600 (CST) Subject: XFS 1.1 vs. 1.2 From: Matt Schillinger To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 25 Mar 2003 13:02:33 -0600 Message-Id: <1048618954.22460.5.camel@mosix> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3330 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: mschilli@vss.fsi.com Precedence: bulk X-list: linux-xfs Content-Length: 378 Lines: 16 Could someone tell me if it is worthwhile to use 1.2 over 1.1? I have dev systems that are about to become production file servers.. I am wondering if there are major benefits to 1.2 over 1.1.. particularly data integrity benefits, better prevention of log corruption.. performance of course is great also.. Thanks for the help, -- Matt Schillinger mschilli@vss.fsi.com From owner-linux-xfs@oss.sgi.com Tue Mar 25 11:11:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 11:11:39 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PJBZq9012330 for ; Tue, 25 Mar 2003 11:11:35 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2PJNCkq026296 for ; Tue, 25 Mar 2003 13:23:12 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA82181; Tue, 25 Mar 2003 13:11:29 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2PJBTwX34132525; Tue, 25 Mar 2003 13:11:29 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2PJBTa21835; Tue, 25 Mar 2003 13:11:29 -0600 Subject: Re: Maximum log stripe size From: Steve Lord To: =?ISO-8859-1?Q?St=E9phane?= Doyon Cc: Nathan Scott , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 Organization: Message-Id: <1048619489.4739.416.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 25 Mar 2003 13:11:29 -0600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h2PJBZq9012331 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3331 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1316 Lines: 37 On Tue, 2003-03-25 at 11:50, Stéphane Doyon wrote: > Hi, > > mkfs.xfs insists that the log stripe unit (-l sunit) must be > smaller than 256K. > > See xfs_mkfs.c around line 1730: > if ((lsunit * blocksize) > 256 * 1024) { > fprintf(stderr, > _("log stripe unit (%d bytes) is too large for kernel to handle (max > 256k)\n"), > (lsunit * blocksize)); > exit(1); > } > > Can anyone please tell me whether this is really necessary? > Our SCSI RAID controllers would much prefer stripes in the order of 1MB. > And the kernel doesn't seem to mind. You really really do not want to make them this big. The reason for the maximum size is the maximum size of iclog buffers - which they are written from. These are capped at 256K it is very hard to guarantee allocations of large chunks of kernel memory. Secondly, the larger the stripe, the more log space is burned in padding. The more log space we use, the faster metadata has to be flushed to disk to allow old log space to be reused. So a large stripe size is probably going to mean more I/O for the same number of filesystem operations. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Mar 25 11:39:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 11:39:26 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PJceq9013166 for ; Tue, 25 Mar 2003 11:39:21 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18xuFq-0001bG-00; Tue, 25 Mar 2003 19:38:38 +0000 Date: Tue, 25 Mar 2003 19:38:38 +0000 From: Christoph Hellwig To: Steven Dake Cc: linux-xfs@oss.sgi.com Subject: Re: Need some help with cause of Oops in XFS 1.2 Message-ID: <20030325193838.A6142@infradead.org> References: <3E809EB1.6000904@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E809EB1.6000904@mvista.com>; from sdake@mvista.com on Tue, Mar 25, 2003 at 11:23:45AM -0700 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3332 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: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 472 Lines: 12 On Tue, Mar 25, 2003 at 11:23:45AM -0700, Steven Dake wrote: > XFS Developers, > > Ok here is what I have done: > > I have a tree that already had XFS 1.1 (with a bunch of other stuff) > included. I hand applied the XFS 1.2 on top of XFS 1.1 patch and > everything seems to work fine, except when I run bonnie++ and under load > (Writing intelligently operation), I receive the following Oops: Are you using the preempt patch or other obscure core kernel changes? From owner-linux-xfs@oss.sgi.com Tue Mar 25 12:29:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 12:29:54 -0800 (PST) Received: from zipcode.az.mvista.com (fw-az.mvista.com [65.200.49.158]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PKTgq9014758 for ; Tue, 25 Mar 2003 12:29:43 -0800 Received: from mvista.com (persist.az.mvista.com [10.50.1.246]) by zipcode.az.mvista.com (8.9.3/8.9.3) with ESMTP id NAA09881; Tue, 25 Mar 2003 13:41:43 -0700 Message-ID: <3E80B9C9.5090107@mvista.com> Date: Tue, 25 Mar 2003 13:19:21 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: linux-xfs@oss.sgi.com Subject: Re: Need some help with cause of Oops in XFS 1.2 References: <3E809EB1.6000904@mvista.com> <20030325193838.A6142@infradead.org> In-Reply-To: <20030325193838.A6142@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3333 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: sdake@mvista.com Precedence: bulk X-list: linux-xfs Content-Length: 840 Lines: 31 the preempt patch is applied (heavily modified, as I said :) however, I have preemption turned off. The other significant difference is the use of the real time scheduler (which is also turned off). The realtime scheduler was a MontaVista authored scheduler patch prior to O1. Thanks for any help -steve Christoph Hellwig wrote: >On Tue, Mar 25, 2003 at 11:23:45AM -0700, Steven Dake wrote: > > >>XFS Developers, >> >>Ok here is what I have done: >> >>I have a tree that already had XFS 1.1 (with a bunch of other stuff) >>included. I hand applied the XFS 1.2 on top of XFS 1.1 patch and >>everything seems to work fine, except when I run bonnie++ and under load >>(Writing intelligently operation), I receive the following Oops: >> >> > >Are you using the preempt patch or other obscure core kernel changes? > > > > > From owner-linux-xfs@oss.sgi.com Tue Mar 25 12:30:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 12:30:50 -0800 (PST) Received: from mail.mnsu.edu (Mail.MNSU.EDU [134.29.1.12]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PKUgq9014872 for ; Tue, 25 Mar 2003 12:30:43 -0800 Received: from mnsu.edu (j3gum-3.MNSU.EDU [134.29.1.30]) by mail.mnsu.edu (8.12.8/8.12.8) with ESMTP id h2PKUZ29017545 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 25 Mar 2003 14:30:36 -0600 Message-ID: <3E80BC6B.3090402@mnsu.edu> Date: Tue, 25 Mar 2003 14:30:35 -0600 From: "Jeffrey E. Hundstad" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS: unknown mount option [usrquota] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3334 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: jeffrey.hundstad@mnsu.edu Precedence: bulk X-list: linux-xfs Content-Length: 649 Lines: 20 Hello, I've compiled today's current CVS tree for linux-2.4.20-xfs. When I boot this kernel I get: XFS: unknown mount option [usrquota] If I try to mount the file system manually "mount -o remount,usrquota /" I get the same error. It's like usrquota is no longer an option to mount-xfs. It looks like 8 days ago there was a split off of the quota pieces of xfs. Could there perhaps be problems with it? I used the same kernel .config that I used on the 2003-02-24 CVS tree. That kernel booted fine, with usrquota support. I've double check my config and these are both set: CONFIG_QUOTA=y CONFIG_XFS_QUOTA=y Full .config at request. From owner-linux-xfs@oss.sgi.com Tue Mar 25 12:32:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 12:32:34 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PKWUq9015316 for ; Tue, 25 Mar 2003 12:32:31 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18xv5x-0001n7-00; Tue, 25 Mar 2003 20:32:29 +0000 Date: Tue, 25 Mar 2003 20:32:29 +0000 From: Christoph Hellwig To: Steven Dake Cc: linux-xfs@oss.sgi.com Subject: Re: Need some help with cause of Oops in XFS 1.2 Message-ID: <20030325203229.A6850@infradead.org> References: <3E809EB1.6000904@mvista.com> <20030325193838.A6142@infradead.org> <3E80B9C9.5090107@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E80B9C9.5090107@mvista.com>; from sdake@mvista.com on Tue, Mar 25, 2003 at 01:19:21PM -0700 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3335 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: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 491 Lines: 9 On Tue, Mar 25, 2003 at 01:19:21PM -0700, Steven Dake wrote: > the preempt patch is applied (heavily modified, as I said :) however, I > have preemption turned off. The other significant difference is the use > of the real time scheduler (which is also turned off). The realtime > scheduler was a MontaVista authored scheduler patch prior to O1. Can you please try to reproduce it with a plain 1.2 XFS tree? It's hard to debug some widly different tree we don't even have source to. From owner-linux-xfs@oss.sgi.com Tue Mar 25 12:43:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 12:43:55 -0800 (PST) Received: from zipcode.az.mvista.com (fw-az.mvista.com [65.200.49.158]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PKhBq9016162 for ; Tue, 25 Mar 2003 12:43:52 -0800 Received: from mvista.com (persist.az.mvista.com [10.50.1.246]) by zipcode.az.mvista.com (8.9.3/8.9.3) with ESMTP id NAA10078; Tue, 25 Mar 2003 13:55:12 -0700 Message-ID: <3E80BCF2.5090005@mvista.com> Date: Tue, 25 Mar 2003 13:32:50 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: linux-xfs@oss.sgi.com Subject: Re: Need some help with cause of Oops in XFS 1.2 References: <3E809EB1.6000904@mvista.com> <20030325193838.A6142@infradead.org> <3E80B9C9.5090107@mvista.com> <20030325203229.A6850@infradead.org> In-Reply-To: <20030325203229.A6850@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3336 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: sdake@mvista.com Precedence: bulk X-list: linux-xfs Content-Length: 1035 Lines: 34 I suspect the issue wouldn't present itself with a vanilla 2.4.18 + xfs1.2 tree as it would have already been caught... And unfortunately I can't apply to a plain vanilla tree, it must go into this particular tree for my company to release it... If you have any suggestions on how I could debug, I'd be willing to try them out. I was really hoping someone had run into this type of problem in the past and could provide some quick pointers on how I could debug. Thanks -steve Christoph Hellwig wrote: >On Tue, Mar 25, 2003 at 01:19:21PM -0700, Steven Dake wrote: > > >>the preempt patch is applied (heavily modified, as I said :) however, I >>have preemption turned off. The other significant difference is the use >>of the real time scheduler (which is also turned off). The realtime >>scheduler was a MontaVista authored scheduler patch prior to O1. >> >> > >Can you please try to reproduce it with a plain 1.2 XFS tree? It's hard >to debug some widly different tree we don't even have source to. > > > > > From owner-linux-xfs@oss.sgi.com Tue Mar 25 12:55:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 12:55:16 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PKsWq9016679 for ; Tue, 25 Mar 2003 12:55:13 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18xvRF-0001qY-00; Tue, 25 Mar 2003 20:54:29 +0000 Date: Tue, 25 Mar 2003 20:54:29 +0000 From: Christoph Hellwig To: Steven Dake Cc: Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: Need some help with cause of Oops in XFS 1.2 Message-ID: <20030325205429.A7098@infradead.org> References: <3E809EB1.6000904@mvista.com> <20030325193838.A6142@infradead.org> <3E80B9C9.5090107@mvista.com> <20030325203229.A6850@infradead.org> <3E80BCF2.5090005@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E80BCF2.5090005@mvista.com>; from sdake@mvista.com on Tue, Mar 25, 2003 at 01:32:50PM -0700 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3337 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: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 732 Lines: 16 On Tue, Mar 25, 2003 at 01:32:50PM -0700, Steven Dake wrote: > I suspect the issue wouldn't present itself with a vanilla 2.4.18 + > xfs1.2 tree as it would have already been caught... And unfortunately I > can't apply to a plain vanilla tree, it must go into this particular > tree for my company to release it... > > If you have any suggestions on how I could debug, I'd be willing to try > them out. > > I was really hoping someone had run into this type of problem in the > past and could provide some quick pointers on how I could debug. Maybe get some consultant that knows Linux filesystem code to fix it for your company? I wouldn't expect too much help on a heavily patched tree that's not publically available. From owner-linux-xfs@oss.sgi.com Tue Mar 25 13:13:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 13:13:41 -0800 (PST) Received: from zipcode.az.mvista.com (fw-az.mvista.com [65.200.49.158]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PLCoq9017234 for ; Tue, 25 Mar 2003 13:13:31 -0800 Received: from mvista.com (persist.az.mvista.com [10.50.1.246]) by zipcode.az.mvista.com (8.9.3/8.9.3) with ESMTP id OAA10524; Tue, 25 Mar 2003 14:24:50 -0700 Message-ID: <3E80C3E4.20203@mvista.com> Date: Tue, 25 Mar 2003 14:02:28 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: linux-xfs@oss.sgi.com Subject: Re: Need some help with cause of Oops in XFS 1.2 References: <3E809EB1.6000904@mvista.com> <20030325193838.A6142@infradead.org> <3E80B9C9.5090107@mvista.com> <20030325203229.A6850@infradead.org> <3E80BCF2.5090005@mvista.com> <20030325205429.A7098@infradead.org> In-Reply-To: <20030325205429.A7098@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3338 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: sdake@mvista.com Precedence: bulk X-list: linux-xfs Content-Length: 968 Lines: 33 I understand filesystem code quite well, and the particular problem (if you would have read the oops) is in the memory management layer. But thanks for your advice. -steve Christoph Hellwig wrote: >On Tue, Mar 25, 2003 at 01:32:50PM -0700, Steven Dake wrote: > > >>I suspect the issue wouldn't present itself with a vanilla 2.4.18 + >>xfs1.2 tree as it would have already been caught... And unfortunately I >>can't apply to a plain vanilla tree, it must go into this particular >>tree for my company to release it... >> >>If you have any suggestions on how I could debug, I'd be willing to try >>them out. >> >>I was really hoping someone had run into this type of problem in the >>past and could provide some quick pointers on how I could debug. >> >> > >Maybe get some consultant that knows Linux filesystem code to fix it for >your company? I wouldn't expect too much help on a heavily patched >tree that's not publically available. > > > > > From owner-linux-xfs@oss.sgi.com Tue Mar 25 14:22:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 14:22:32 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2PMMOq9018668 for ; Tue, 25 Mar 2003 14:22:24 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2PMMOUA018665 for linux-xfs@oss.sgi.com; Tue, 25 Mar 2003 14:22:24 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2PMMMqB018651 for ; Tue, 25 Mar 2003 14:22:23 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2PLx2WP018430; Tue, 25 Mar 2003 13:59:02 -0800 Date: Tue, 25 Mar 2003 13:59:02 -0800 Message-Id: <200303252159.h2PLx2WP018430@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3339 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 634 Lines: 25 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From atu@dmeti.dp.ua 2003-03-25 13:59 ------- Created an attachment (id=71) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=71&action=view) result of cpu, ps and some of bta Created by this sequence: normal boot on initlevel3, log as root, than: updatedb ; reboot After updatedb (approx 4 min) system begins to reboot, try to umout disks, (approx 2-3min) , than hangs. Than I press 'pause' and enter kdb. Results in attach. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Mar 25 15:24:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 15:25:05 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PNODq9003839 for ; Tue, 25 Mar 2003 15:24:54 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2PNO7nH001882 for ; Tue, 25 Mar 2003 15:24:08 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA28685; Wed, 26 Mar 2003 10:22:51 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA44918; Wed, 26 Mar 2003 10:22:50 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2PNJjV4001092; Wed, 26 Mar 2003 10:19:45 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2PNJiHb001090; Wed, 26 Mar 2003 10:19:44 +1100 Date: Wed, 26 Mar 2003 10:19:44 +1100 From: Nathan Scott To: "Jeffrey E. Hundstad" Cc: linux-xfs@oss.sgi.com Subject: Re: XFS: unknown mount option [usrquota] Message-ID: <20030325231944.GC789@frodo> References: <3E80BC6B.3090402@mnsu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E80BC6B.3090402@mnsu.edu> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3340 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1388 Lines: 37 On Tue, Mar 25, 2003 at 02:30:35PM -0600, Jeffrey E. Hundstad wrote: > Hello, > > I've compiled today's current CVS tree for linux-2.4.20-xfs. When I > boot this kernel I get: > XFS: unknown mount option [usrquota] > If I try to mount the file system manually "mount -o remount,usrquota /" > I get the same error. It's like usrquota is no longer an option to > mount-xfs. It looks like 8 days ago there was a split off of the quota > pieces of xfs. Could there perhaps be problems with it? Firstly, there is an off chance you never had quota working... previously even if XFS was built without quota support, it would still parse the quota options and silently drop them on the ground. Probably not the case, but could be. > I used the same kernel .config that I used on the 2003-02-24 CVS tree. > That kernel booted fine, with usrquota support. > > I've double check my config and these are both set: > CONFIG_QUOTA=y > CONFIG_XFS_QUOTA=y > > Full .config at request. Do you have a log of your build?, that would be more interesting. In particular, has the build descended into fs/xfs/quota (and are there a bunch of .o files there?). And if so is xfs_quota.o being linked into your xfs.o? I'm suspecting a build problem at your end at the moment, cos this works for me and my nightly QA runs do some quota tests (and all those are working fine). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Mar 25 16:00:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 16:01:06 -0800 (PST) Received: from homer.nks.net (homer.nks.net [66.152.21.172]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q00rq9004635 for ; Tue, 25 Mar 2003 16:00:55 -0800 Received: from hoju.nks.net (hoju.nks.net [192.168.1.17]) by homer.nks.net (8.9.3/8.9.3) with ESMTP id TAA32084 for ; Tue, 25 Mar 2003 19:00:46 -0500 Received: from localhost.localdomain (two.nks.net [192.168.1.22]) by hoju.nks.net (8.12.7/8.12.7/Debian 8.9.3-21) with ESMTP id h2Q00kYq016736 for ; Tue, 25 Mar 2003 19:00:46 -0500 Subject: XFS, extended attrs and UML? From: Derek Glidden To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 25 Mar 2003 19:00:46 -0500 Message-Id: <1048636846.13786.113.camel@two.nks.net> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3341 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: dglidden@illusionary.com Precedence: bulk X-list: linux-xfs Content-Length: 1696 Lines: 44 Does anyone know of a specific problem with XFS, extended attributes and UML (user-mode linux)? We've got a 2.4.19 kernel with XFS 1.2 and UML 2.4.19-51 patches applied that, when we try to run "attr" to add/set extended attributes to a file under the UML, returns: attr_set: Function not implemented if we 'strace' the 'attr' action, we see: SYS_227(0xbffffea1, 0xbffffbb4, 0xbffffe98, 0x8, 0) = -1 ENOSYS (Function not implemented) The exact same kernel source, compiled and running "native" works as-expected. Any ideas? Is this a known problem? Is there anyone else out there crazy enough to be using XFS under User-mode Linux? :) (And yes, we know that running a journaling filesystem under UML isn't entirely the best idea, but we have an application that wants XFS extended attributes that we want to run under UML if at all possible.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/usr/bin/perl -w $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} print+x"C*",@a}';s/x/pack+/g;eval usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec - http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/ From owner-linux-xfs@oss.sgi.com Tue Mar 25 16:27:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 16:27:24 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q0Qcq9008380 for ; Tue, 25 Mar 2003 16:27:18 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2Q0QVuY013332 for ; Tue, 25 Mar 2003 16:26:32 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA29472; Wed, 26 Mar 2003 11:25:13 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id F0078300087; Wed, 26 Mar 2003 11:25:12 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 778088F; Wed, 26 Mar 2003 11:25:12 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Dan Yocum Cc: xfs-list , sandeen@sgi.com Subject: Re: KDB-ized RH 2.4.18-X kernel? In-reply-to: Your message of "Tue, 25 Mar 2003 12:51:18 MDT." <3E80A526.2050301@fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Mar 2003 11:25:06 +1100 Message-ID: <28714.1048638306@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3342 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: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 878 Lines: 18 On Tue, 25 Mar 2003 12:51:18 -0600, Dan Yocum wrote: >I simply used the kernel-source-2.4.18-18.i386.rpm, copied the >configs/kernel-2.4.18-i686-smp.config to .config, 'make menuconfig,' enable >kdb, save, exit, 'make dep && make clean && make bzImage'. > >Looking at the patch list in the kernel-2.4.18-18.src.rpm I see that there's >only one kdb patch, called linux-2.4.19-kdb.patch, I assumed that this was a >complete patch containing the common as well as the arch dependent kdb patches. linux-2.4.19-kdb.patch in kernel-2.4.18-18SGI_XFS_1.2.0.src.rpm is incomplete. At the very least, it is missing the patch to the top level Makefile. So the kdb directory is never built and all the global variables and functions are missing. Eric, do you want to rebuild kernel-source-2.4.18 src.rpm with a working kdb patch or wait for the next XFS release? From owner-linux-xfs@oss.sgi.com Tue Mar 25 16:44:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 16:44:20 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q0iGq9008960 for ; Tue, 25 Mar 2003 16:44:17 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2Q0i8uY014565 for ; Tue, 25 Mar 2003 16:44:11 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA40089; Tue, 25 Mar 2003 18:44:07 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2Q0i7wX32108681; Tue, 25 Mar 2003 18:44:07 -0600 (CST) Subject: Re: XFS, extended attrs and UML? From: Rusell Cattelan To: Derek Glidden Cc: linux-xfs@oss.sgi.com In-Reply-To: <1048636846.13786.113.camel@two.nks.net> References: <1048636846.13786.113.camel@two.nks.net> Content-Type: text/plain Organization: Message-Id: <1048639529.11118.40.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-1) Date: 25 Mar 2003 18:45:29 -0600 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3343 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: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1644 Lines: 43 This is because uml doesn't have the attr syscalls mapped kernel/sys_call_table.c [ __NR_setxattr ] = sys_ni_syscall, [ __NR_lsetxattr ] = sys_ni_syscall, [ __NR_fsetxattr ] = sys_ni_syscall, [ __NR_getxattr ] = sys_ni_syscall, [ __NR_lgetxattr ] = sys_ni_syscall, [ __NR_fgetxattr ] = sys_ni_syscall, [ __NR_listxattr ] = sys_ni_syscall, [ __NR_llistxattr ] = sys_ni_syscall, [ __NR_flistxattr ] = sys_ni_syscall, [ __NR_removexattr ] = sys_ni_syscall, [ __NR_lremovexattr ] = sys_ni_syscall, [ __NR_fremovexattr ] = sys_ni_syscall, You'll need to correct this table before it will work. On Tue, 2003-03-25 at 18:00, Derek Glidden wrote: > Does anyone know of a specific problem with XFS, extended attributes and > UML (user-mode linux)? > > We've got a 2.4.19 kernel with XFS 1.2 and UML 2.4.19-51 patches applied > that, when we try to run "attr" to add/set extended attributes to a file > under the UML, returns: > > attr_set: Function not implemented > > if we 'strace' the 'attr' action, we see: > > SYS_227(0xbffffea1, 0xbffffbb4, 0xbffffe98, 0x8, 0) = -1 ENOSYS > (Function not implemented) > > The exact same kernel source, compiled and running "native" works > as-expected. > > Any ideas? Is this a known problem? Is there anyone else out there > crazy enough to be using XFS under User-mode Linux? :) > > (And yes, we know that running a journaling filesystem under UML isn't > entirely the best idea, but we have an application that wants XFS > extended attributes that we want to run under UML if at all possible.) From owner-linux-xfs@oss.sgi.com Tue Mar 25 16:49:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 16:49:39 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q0naq9009407 for ; Tue, 25 Mar 2003 16:49:36 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2Q0nUuY014914 for ; Tue, 25 Mar 2003 16:49:30 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA55224; Tue, 25 Mar 2003 18:49:29 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2Q0nTwX35259244; Tue, 25 Mar 2003 18:49:29 -0600 (CST) Subject: Re: Need some help with cause of Oops in XFS 1.2 From: Rusell Cattelan To: Steven Dake Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E809EB1.6000904@mvista.com> References: <3E809EB1.6000904@mvista.com> Content-Type: text/plain Organization: Message-Id: <1048639851.11129.44.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-1) Date: 25 Mar 2003 18:50:51 -0600 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3344 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: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 688 Lines: 21 On Tue, 2003-03-25 at 12:23, Steven Dake wrote: > XFS Developers, > > Ok here is what I have done: > > I have a tree that already had XFS 1.1 (with a bunch of other stuff) > included. I hand applied the XFS 1.2 on top of XFS 1.1 patch and > everything seems to work fine, except when I run bonnie++ and under load > (Writing intelligently operation), I receive the following Oops: > If possible get kbd into your tree. Then open a bug and attach what ever backtraces you can get. bta is a good place to start. That might shed some light on the situation, but without wading through the lock changes you might have in your tree this problem may be hard to track down. -Russell From owner-linux-xfs@oss.sgi.com Tue Mar 25 16:51:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 16:51:54 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q0ppq9009843 for ; Tue, 25 Mar 2003 16:51:51 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2Q0pjuY015108 for ; Tue, 25 Mar 2003 16:51:45 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA13688; Tue, 25 Mar 2003 18:51:45 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2Q0piwX35372556; Tue, 25 Mar 2003 18:51:44 -0600 (CST) Subject: Re: KDB-ized RH 2.4.18-X kernel? From: Rusell Cattelan To: Keith Owens Cc: Dan Yocum , xfs-list , sandeen@sgi.com In-Reply-To: <28714.1048638306@kao2.melbourne.sgi.com> References: <28714.1048638306@kao2.melbourne.sgi.com> Content-Type: text/plain Organization: Message-Id: <1048639986.11129.47.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-1) Date: 25 Mar 2003 18:53:06 -0600 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3345 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: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1148 Lines: 26 On Tue, 2003-03-25 at 18:25, Keith Owens wrote: > On Tue, 25 Mar 2003 12:51:18 -0600, > Dan Yocum wrote: > >I simply used the kernel-source-2.4.18-18.i386.rpm, copied the > >configs/kernel-2.4.18-i686-smp.config to .config, 'make menuconfig,' enable > >kdb, save, exit, 'make dep && make clean && make bzImage'. > > > >Looking at the patch list in the kernel-2.4.18-18.src.rpm I see that there's > >only one kdb patch, called linux-2.4.19-kdb.patch, I assumed that this was a > >complete patch containing the common as well as the arch dependent kdb patches. > > linux-2.4.19-kdb.patch in kernel-2.4.18-18SGI_XFS_1.2.0.src.rpm is > incomplete. At the very least, it is missing the patch to the top > level Makefile. So the kdb directory is never built and all the global > variables and functions are missing. > > Eric, do you want to rebuild kernel-source-2.4.18 src.rpm with a > working kdb patch or wait for the next XFS release? If a working kdb patch is available for the current release I'll rebuild the rpms and toss them on oss. After all I can build the whole lot 4 or 5 hours now (down from 12) :-) -Russell From owner-linux-xfs@oss.sgi.com Tue Mar 25 17:01:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 17:01:12 -0800 (PST) Received: from hotmail.com (bay1-f70.bay1.hotmail.com [65.54.245.70]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q11Aq9010345 for ; Tue, 25 Mar 2003 17:01:10 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 25 Mar 2003 17:01:04 -0800 Received: from 66.167.1.42 by by1fd.bay1.hotmail.msn.com with HTTP; Wed, 26 Mar 2003 01:01:04 GMT X-Originating-IP: [66.167.1.42] X-Originating-Email: [mwhang77@hotmail.com] From: "Michael Whang" To: linux-xfs@oss.sgi.com Subject: xfs installer Date: Tue, 25 Mar 2003 17:01:04 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2003 01:01:04.0843 (UTC) FILETIME=[2D48E9B0:01C2F333] X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3346 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: mwhang77@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 256 Lines: 10 Is there anyone that has created an XFS installer with a later kernel? Mike _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From owner-linux-xfs@oss.sgi.com Tue Mar 25 17:22:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 17:22:37 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2Q1MQq9011077 for ; Tue, 25 Mar 2003 17:22:26 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2Q1MQfl011075 for linux-xfs@oss.sgi.com; Tue, 25 Mar 2003 17:22:26 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2Q1MNqB011062 for ; Tue, 25 Mar 2003 17:22:24 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2Q0gfuN008951; Tue, 25 Mar 2003 16:42:41 -0800 Date: Tue, 25 Mar 2003 16:42:41 -0800 Message-Id: <200303260042.h2Q0gfuN008951@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3347 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 641 Lines: 20 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From kaos@sgi.com 2003-03-25 16:42 ------- Kernel bug. UP systems call task_set_cpu() but never call task_release_cpu() so all tasks appear to own the cpu, which confuses debuggers. This problem has been bounced to linux-kernel. I doubt that the missing task_release_cpu() has anything to do with your umount hang. Unfortunately it does stop kdb backtrace working on UP systems. I expect to get a fix from l-k in the next day or so. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Mar 25 17:24:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 17:24:59 -0800 (PST) Received: from zipcode.az.mvista.com (fw-az.mvista.com [65.200.49.158]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q1OFq9011489 for ; Tue, 25 Mar 2003 17:24:56 -0800 Received: from mvista.com (persist.az.mvista.com [10.50.1.246]) by zipcode.az.mvista.com (8.9.3/8.9.3) with ESMTP id SAA14226; Tue, 25 Mar 2003 18:35:47 -0700 Message-ID: <3E80FEB5.90801@mvista.com> Date: Tue, 25 Mar 2003 18:13:25 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rusell Cattelan CC: linux-xfs@oss.sgi.com Subject: XFS 1.2 bug? References: <3E809EB1.6000904@mvista.com> <1048639851.11129.44.camel@rose.americas.sgi.com> In-Reply-To: <1048639851.11129.44.camel@rose.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3348 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: sdake@mvista.com Precedence: bulk X-list: linux-xfs Content-Length: 4631 Lines: 156 Russell, Thanks for the hints but I believe I found a bug in XFS 1.2, and perhaps you could verify it since I'm not very familiar with the XFS code. both linvfs_write_full_page and write_full_page will attempt to unlock_page in some circumstances. The page is previously locked in the function generic_file_write_nolock. This generic_file_write_nolock function will unlock the page after it is done using it. Unlocking a page twice will result in an Oops, so either the mm layer (generic_file_write_nolock) shouldn't be unlocking the page, or the xfs code in linvfs_write_full_page and write_full_page shouldn't unlock the page a second time. The unlock in the xfs code is suspect, since it only unlocks on certain conditions (which will result in an Oops) The function linvfs_write_full_page unlocks a page in the case of an error conditon. I have not been able to hit this error condition, but if it occurs, an Oops will most certainly occur. STATIC int linvfs_write_full_page( struct page *page) { int flagset = 0; int error; int need_trans; int nr_delalloc, nr_unmapped; if (count_page_state(page, &nr_delalloc, &nr_unmapped)) { need_trans = nr_delalloc + nr_unmapped; } else { need_trans = 1; } if ((current->flags & (PF_FSTRANS|PF_NOIO)) && need_trans) goto out_fail; if (need_trans) { current->flags |= PF_NOIO; flagset = 1; } error = write_full_page(page, nr_delalloc); if (flagset) current->flags &= ~PF_NOIO; return error; out_fail: SetPageDirty(page); unlock_page(page); return 0; } The function write_full_page will unlock the page if delalloc_convert returns a negative value. I don't understand why delalloc_convert returns a negative value, and if the page should be unlocked, but it seems that it shouldn't. Could you give me some background on why the page is unlocked at this point? If I comment out this unlock, bonnie++ does not crash and the filesystem seems still stable, but I'd like to understand _why_ this condition is occuring and if the unlock_page is really needed, or if letting the mm handle it is appropriate. STATIC int write_full_page( struct page *page, int delalloc) { struct inode *inode = (struct inode*)page->mapping->host; unsigned long end_index = inode->i_size >> PAGE_CACHE_SHIFT; int ret; /* Are we off the end of the file ? */ if (page->index >= end_index) { unsigned offset = inode->i_size & (PAGE_CACHE_SIZE-1); if ((page->index >= end_index+1) || !offset) { ret = -EIO; goto out; } } if (!page_has_buffers(page)) { create_empty_buffers(page, inode->i_dev, 1 << inode->i_blkbits); } ret = delalloc_convert(inode, page, 1, delalloc == 0); out: if (ret < 0) { /* * If it's delalloc and we have nowhere to put it, * throw it away. */ if (delalloc) block_flushpage(page, 0); ClearPageUptodate(page); // unlock_page(page); } return ret; } It looks like the real problem is that no error return is processed to not unlock the buffer if an error is returned by linvfs_write_full_page by the function generic_file_write_nolock in the call chain but the return values are used to indicate state in some of the calls and cannot be used as error returns... The call stack that gets to the point where the page is unlocked is: generic_file_write_nolock() generic_commit_write() __block_commit_write() balance_dirty() write_some_buffers() write_buffer_delay() linvfs_write_full_page() write_full_page() After that the finish of the call generic_file_write_nolock will also unlock that same page causing an oops. Thanks! -steve Rusell Cattelan wrote: >On Tue, 2003-03-25 at 12:23, Steven Dake wrote: > > >>XFS Developers, >> >>Ok here is what I have done: >> >>I have a tree that already had XFS 1.1 (with a bunch of other stuff) >>included. I hand applied the XFS 1.2 on top of XFS 1.1 patch and >>everything seems to work fine, except when I run bonnie++ and under load >>(Writing intelligently operation), I receive the following Oops: >> >> >> >If possible get kbd into your tree. >Then open a bug and attach what ever backtraces you can get. >bta is a good place to start. > >That might shed some light on the situation, but without wading through >the lock changes you might have in your tree this problem may be hard >to track down. > >-Russell > > > > > > From owner-linux-xfs@oss.sgi.com Tue Mar 25 17:55:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 17:55:49 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q1srq9012074 for ; Tue, 25 Mar 2003 17:55:38 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2Q26Vkq004361 for ; Tue, 25 Mar 2003 20:06:31 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA60031; Tue, 25 Mar 2003 19:54:47 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2Q1slCJ6200481; Tue, 25 Mar 2003 19:54:47 -0600 (CST) Date: Tue, 25 Mar 2003 19:53:31 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Steven Dake cc: Rusell Cattelan , Subject: Re: XFS 1.2 bug? In-Reply-To: <3E80FEB5.90801@mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3349 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 895 Lines: 21 On Tue, 25 Mar 2003, Steven Dake wrote: > The function write_full_page will unlock the page if delalloc_convert > returns a negative value. I don't understand why delalloc_convert > returns a negative value, and if the page should be unlocked, but it > seems that it shouldn't. Could you give me some background on why the > page is unlocked at this point? If I comment out this unlock, bonnie++ delalloc_convert can fail on some error, and we have to do something with the buffer at that point. This case was put in because if we ignored the error, we'd write out a buffer with block 0 (delalloc) and clobber the superblock. Perhaps locking has changed such that the unlock_page is no longer correct, I'd have to look more closely. Are you hitting this case? It would be very helpful if you could run this on a "stock" xfs 1.2 kernel to see if you still hit this problem. -Eric From owner-linux-xfs@oss.sgi.com Tue Mar 25 17:58:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 17:58:21 -0800 (PST) Received: from zipcode.az.mvista.com (fw-az.mvista.com [65.200.49.158]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q1wFq9012508 for ; Tue, 25 Mar 2003 17:58:16 -0800 Received: from mvista.com (persist.az.mvista.com [10.50.1.246]) by zipcode.az.mvista.com (8.9.3/8.9.3) with ESMTP id TAA14731; Tue, 25 Mar 2003 19:10:19 -0700 Message-ID: <3E8106CD.2050101@mvista.com> Date: Tue, 25 Mar 2003 18:47:57 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steven Dake CC: Rusell Cattelan , linux-xfs@oss.sgi.com Subject: update: Re: XFS 1.2 bug? References: <3E809EB1.6000904@mvista.com> <1048639851.11129.44.camel@rose.americas.sgi.com> <3E80FEB5.90801@mvista.com> In-Reply-To: <3E80FEB5.90801@mvista.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3350 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: sdake@mvista.com Precedence: bulk X-list: linux-xfs Content-Length: 6056 Lines: 204 Russell, I had a deeper look at why write_full_page was failing... In the code: STATIC int write_full_page( struct page *page, int delalloc) { struct inode *inode = (struct inode*)page->mapping->host; unsigned long end_index = inode->i_size >> PAGE_CACHE_SHIFT; int ret; /* Are we off the end of the file ? */ if (page->index >= end_index) { unsigned offset = inode->i_size & (PAGE_CACHE_SIZE-1); if ((page->index >= end_index+1) || !offset) { ret = -EIO; printk ("Off the end of the file %d %d %d %d\n", page->index, end_index, offset, inode- >i_size); goto out; } } I added the above printk and got the output Mar 24 22:49:47 192 kernel: Off the end of the file 91406 91406 0 374398976 offset is zero, because 374398976 & ((1 << 12) -1) is zero. This operation looks like it should proceed since the size is ok and the page index and end index are within ranges. Why should we error if the size & PAGE_CACHE_SIZE-1 is zero? Any help appreciated on the two issues (the offset issue and the extra unlock_pages) Thanks! -steve Steven Dake wrote: > Russell, > > Thanks for the hints but I believe I found a bug in XFS 1.2, and > perhaps you could verify it since I'm not very familiar with the XFS > code. > > both linvfs_write_full_page and write_full_page will attempt to > unlock_page in some circumstances. The page is previously locked in > the function generic_file_write_nolock. This > generic_file_write_nolock function will unlock the page after it is > done using it. Unlocking a page twice will result in an Oops, so > either the mm layer (generic_file_write_nolock) shouldn't be unlocking > the page, or the xfs code in linvfs_write_full_page and > write_full_page shouldn't unlock the page a second time. The unlock > in the xfs code is suspect, since it only unlocks on certain > conditions (which will result in an Oops) > > The function linvfs_write_full_page unlocks a page in the case of an > error conditon. I have not been able to hit this error condition, but > if it occurs, an Oops will most certainly occur. > > STATIC int > linvfs_write_full_page( > struct page *page) > { > int flagset = 0; > int error; > int need_trans; > int nr_delalloc, nr_unmapped; > > if (count_page_state(page, &nr_delalloc, &nr_unmapped)) { > need_trans = nr_delalloc + nr_unmapped; > } else { > need_trans = 1; > } > > if ((current->flags & (PF_FSTRANS|PF_NOIO)) && need_trans) > goto out_fail; > > if (need_trans) { > current->flags |= PF_NOIO; > flagset = 1; > } > > error = write_full_page(page, nr_delalloc); > > if (flagset) > current->flags &= ~PF_NOIO; > return error; > > out_fail: > SetPageDirty(page); > unlock_page(page); > return 0; > } > > The function write_full_page will unlock the page if delalloc_convert > returns a negative value. I don't understand why delalloc_convert > returns a negative value, and if the page should be unlocked, but it > seems that it shouldn't. Could you give me some background on why the > page is unlocked at this point? If I comment out this unlock, > bonnie++ does not crash and the filesystem seems still stable, but I'd > like to understand _why_ this condition is occuring and if the > unlock_page is really needed, or if letting the mm handle it is > appropriate. > > STATIC int > write_full_page( > struct page *page, > int delalloc) > { > struct inode *inode = (struct inode*)page->mapping->host; > unsigned long end_index = inode->i_size >> PAGE_CACHE_SHIFT; > int ret; > > /* Are we off the end of the file ? */ > if (page->index >= end_index) { > unsigned offset = inode->i_size & (PAGE_CACHE_SIZE-1); > if ((page->index >= end_index+1) || !offset) { > ret = -EIO; > goto out; > } > } > > if (!page_has_buffers(page)) { > create_empty_buffers(page, inode->i_dev, 1 << inode->i_blkbits); > } > > ret = delalloc_convert(inode, page, 1, delalloc == 0); > > out: > if (ret < 0) { > /* > * If it's delalloc and we have nowhere to put it, > * throw it away. > */ > if (delalloc) > block_flushpage(page, 0); > ClearPageUptodate(page); > // unlock_page(page); > } > > return ret; > } > > It looks like the real problem is that no error return is processed to > not unlock the buffer if an error is returned by > linvfs_write_full_page by the function generic_file_write_nolock in > the call chain but the return values are used to indicate state in > some of the calls and cannot be used as error returns... > > The call stack that gets to the point where the page is unlocked is: > generic_file_write_nolock() > generic_commit_write() > __block_commit_write() > balance_dirty() > write_some_buffers() > write_buffer_delay() > linvfs_write_full_page() > write_full_page() > > After that the finish of the call generic_file_write_nolock will also > unlock that same page causing an oops. > > Thanks! > -steve > > Rusell Cattelan wrote: > >> On Tue, 2003-03-25 at 12:23, Steven Dake wrote: >> >> >>> XFS Developers, >>> >>> Ok here is what I have done: >>> >>> I have a tree that already had XFS 1.1 (with a bunch of other stuff) >>> included. I hand applied the XFS 1.2 on top of XFS 1.1 patch and >>> everything seems to work fine, except when I run bonnie++ and under >>> load (Writing intelligently operation), I receive the following Oops: >>> >>> >> >> If possible get kbd into your tree. >> Then open a bug and attach what ever backtraces you can get. >> bta is a good place to start. >> >> That might shed some light on the situation, but without wading through >> the lock changes you might have in your tree this problem may be hard >> to track down. >> >> -Russell >> >> >> >> >> >> > > > > From owner-linux-xfs@oss.sgi.com Tue Mar 25 20:58:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 20:58:18 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q4w2q9014134 for ; Tue, 25 Mar 2003 20:58:04 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2Q1jguY019452 for ; Tue, 25 Mar 2003 17:45:44 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA00313; Wed, 26 Mar 2003 12:44:26 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 1C8EA300087; Wed, 26 Mar 2003 12:44:24 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 98D118F; Wed, 26 Mar 2003 12:44:24 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Rusell Cattelan Cc: xfs-list Subject: Re: KDB-ized RH 2.4.18-X kernel? In-reply-to: Your message of "25 Mar 2003 18:53:06 MDT." <1048639986.11129.47.camel@rose.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Mar 2003 12:44:18 +1100 Message-ID: <29637.1048643058@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3351 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: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1658 Lines: 45 On 25 Mar 2003 18:53:06 -0600, Rusell Cattelan wrote: >On Tue, 2003-03-25 at 18:25, Keith Owens wrote: >> linux-2.4.19-kdb.patch in kernel-2.4.18-18SGI_XFS_1.2.0.src.rpm is >> incomplete. At the very least, it is missing the patch to the top >> level Makefile. So the kdb directory is never built and all the global >> variables and functions are missing. > >If a working kdb patch is available for the current release I'll rebuild >the rpms and toss them on oss. >After all I can build the whole lot 4 or 5 hours now (down from 12) :-) The missing patch to Makefile is below, apply after linux-2.4.19-kdb.patch. However after applying that and compiling with CONFIG_KALLSYMS=y, CONFIG_KDB=y, CONFIG_KDB_MODULES=y there are build errors in kdb/modules/kdbm_pg.c and kdb/kdbmain.c. The kdb code in the XFS tree needs more work to make it fit all the changes that RH have made to the kernel. Unfortunately I do not have time to work on this at the moment, kdb for 2.4.{19,20}-ia64 is taking all my time. Back to the XFS team. --- linux1/Makefile Wed Mar 26 11:25:48 2003 +++ linux2/Makefile Wed Mar 26 12:24:11 2003 @@ -139,6 +139,11 @@ LIBS =$(TOPDIR)/lib/lib.a SUBDIRS =kernel drivers mm fs net ipc lib abi crypto +ifeq ($(CONFIG_KDB),y) +CORE_FILES += kdb/kdb.o +SUBDIRS += kdb +endif + DRIVERS-n := DRIVERS-y := DRIVERS-m := @@ -254,6 +259,7 @@ scripts/lxdialog/*.o scripts/lxdialog/lxdialog \ .menuconfig.log \ include/asm \ + kdb/gen-kdb_cmds.c \ .hdepend scripts/mkdep scripts/split-include scripts/docproc \ $(TOPDIR)/include/linux/modversions.h \ scripts/mkconfigs kernel/configs.c kernel/configs.o \ From owner-linux-xfs@oss.sgi.com Tue Mar 25 21:26:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 21:26:30 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q5Pcq9014741 for ; Tue, 25 Mar 2003 21:26:18 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2Q5PVuY001999 for ; Tue, 25 Mar 2003 21:25:32 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2Q5OE7L3608010 for ; Wed, 26 Mar 2003 16:24:14 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2Q5OEr73609823 for linux-xfs@oss.sgi.com; Wed, 26 Mar 2003 16:24:14 +1100 (EST) Date: Wed, 26 Mar 2003 16:24:14 +1100 (EST) From: Nathan Scott Message-Id: <200303260524.h2Q5OEr73609823@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs configure script X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3352 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 389 Lines: 14 Fix readline use in xfsprogs configure script such that distributions which do not contain a correctly-linked libreadline will still work. Date: Tue Mar 25 21:23:33 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:142672a cmd/xfsprogs/configure.in - 1.20 From owner-linux-xfs@oss.sgi.com Tue Mar 25 23:03:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 23:03:22 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q73Aq9016042 for ; Tue, 25 Mar 2003 23:03:11 -0800 Received: from thebarn.com (c-24-245-56-70.mn.client2.attbi.com [24.245.56.70]) by lips.thebarn.com (8.12.8/8.12.6) with ESMTP id h2Q738xk090660; Wed, 26 Mar 2003 01:03:08 -0600 (CST) (envelope-from cattelan@thebarn.com) Message-ID: <3E8151E4.809@thebarn.com> Date: Wed, 26 Mar 2003 01:08:20 -0600 From: Russell Cattelan User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steven Dake CC: linux-xfs@oss.sgi.com Subject: Re: update: Re: XFS 1.2 bug? References: <3E809EB1.6000904@mvista.com> <1048639851.11129.44.camel@rose.americas.sgi.com> <3E80FEB5.90801@mvista.com> <3E8106CD.2050101@mvista.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3353 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: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs Content-Length: 6854 Lines: 225 Ok I've looked over the code. write_full_page is modeled after block_write_full_page. The past the end of file is the same check used in that function. Basically the offset var used to see if size of the file is part way into a page so if the size of the file lands on a page boundry offset will be 0. As far as the unlock_page in the error case ... again based on block_write_full_page it seems correct to unlock the page in case of an error. do you have the backtrace of crash again? I'm wondering who called write_full_page in this case. Steven Dake wrote: > Russell, > > I had a deeper look at why write_full_page was failing... In the code: > STATIC int > write_full_page( > struct page *page, > int delalloc) > { > struct inode *inode = (struct inode*)page->mapping->host; > unsigned long end_index = inode->i_size >> PAGE_CACHE_SHIFT; > int ret; > > /* Are we off the end of the file ? */ > if (page->index >= end_index) { > unsigned offset = inode->i_size & (PAGE_CACHE_SIZE-1); > if ((page->index >= end_index+1) || !offset) { > ret = -EIO; > printk ("Off the end of the file %d %d %d %d\n", > page->index, end_index, offset, inode- > >i_size); > goto out; > } > } > > I added the above printk and got the output > Mar 24 22:49:47 192 kernel: Off the end of the file 91406 91406 0 > 374398976 > > offset is zero, because 374398976 & ((1 << 12) -1) is zero. > This operation looks like it should proceed since the size is ok and > the page index and end index are within ranges. Why should we error > if the size & PAGE_CACHE_SIZE-1 is zero? > > Any help appreciated on the two issues > (the offset issue and the extra unlock_pages) > > Thanks! > -steve > > Steven Dake wrote: > >> Russell, >> >> Thanks for the hints but I believe I found a bug in XFS 1.2, and >> perhaps you could verify it since I'm not very familiar with the XFS >> code. >> >> both linvfs_write_full_page and write_full_page will attempt to >> unlock_page in some circumstances. The page is previously locked in >> the function generic_file_write_nolock. This >> generic_file_write_nolock function will unlock the page after it is >> done using it. Unlocking a page twice will result in an Oops, so >> either the mm layer (generic_file_write_nolock) shouldn't be >> unlocking the page, or the xfs code in linvfs_write_full_page and >> write_full_page shouldn't unlock the page a second time. The unlock >> in the xfs code is suspect, since it only unlocks on certain >> conditions (which will result in an Oops) >> >> The function linvfs_write_full_page unlocks a page in the case of an >> error conditon. I have not been able to hit this error condition, >> but if it occurs, an Oops will most certainly occur. >> >> STATIC int >> linvfs_write_full_page( >> struct page *page) >> { >> int flagset = 0; >> int error; >> int need_trans; >> int nr_delalloc, nr_unmapped; >> >> if (count_page_state(page, &nr_delalloc, &nr_unmapped)) { >> need_trans = nr_delalloc + nr_unmapped; >> } else { >> need_trans = 1; >> } >> >> if ((current->flags & (PF_FSTRANS|PF_NOIO)) && need_trans) >> goto out_fail; >> >> if (need_trans) { >> current->flags |= PF_NOIO; >> flagset = 1; >> } >> >> error = write_full_page(page, nr_delalloc); >> >> if (flagset) >> current->flags &= ~PF_NOIO; >> return error; >> >> out_fail: >> SetPageDirty(page); >> unlock_page(page); >> return 0; >> } >> >> The function write_full_page will unlock the page if delalloc_convert >> returns a negative value. I don't understand why delalloc_convert >> returns a negative value, and if the page should be unlocked, but it >> seems that it shouldn't. Could you give me some background on why >> the page is unlocked at this point? If I comment out this unlock, >> bonnie++ does not crash and the filesystem seems still stable, but >> I'd like to understand _why_ this condition is occuring and if the >> unlock_page is really needed, or if letting the mm handle it is >> appropriate. >> >> STATIC int >> write_full_page( >> struct page *page, >> int delalloc) >> { >> struct inode *inode = (struct inode*)page->mapping->host; >> unsigned long end_index = inode->i_size >> PAGE_CACHE_SHIFT; >> int ret; >> >> /* Are we off the end of the file ? */ >> if (page->index >= end_index) { >> unsigned offset = inode->i_size & (PAGE_CACHE_SIZE-1); >> if ((page->index >= end_index+1) || !offset) { >> ret = -EIO; >> goto out; >> } >> } >> >> if (!page_has_buffers(page)) { >> create_empty_buffers(page, inode->i_dev, 1 << inode->i_blkbits); >> } >> >> ret = delalloc_convert(inode, page, 1, delalloc == 0); >> >> out: >> if (ret < 0) { >> /* >> * If it's delalloc and we have nowhere to put it, >> * throw it away. >> */ >> if (delalloc) >> block_flushpage(page, 0); >> ClearPageUptodate(page); >> // unlock_page(page); >> } >> >> return ret; >> } >> >> It looks like the real problem is that no error return is processed >> to not unlock the buffer if an error is returned by >> linvfs_write_full_page by the function generic_file_write_nolock in >> the call chain but the return values are used to indicate state in >> some of the calls and cannot be used as error returns... >> >> The call stack that gets to the point where the page is unlocked is: >> generic_file_write_nolock() >> generic_commit_write() >> __block_commit_write() >> balance_dirty() >> write_some_buffers() >> write_buffer_delay() >> linvfs_write_full_page() >> write_full_page() >> >> After that the finish of the call generic_file_write_nolock will also >> unlock that same page causing an oops. >> >> Thanks! >> -steve >> >> Rusell Cattelan wrote: >> >>> On Tue, 2003-03-25 at 12:23, Steven Dake wrote: >>> >>> >>>> XFS Developers, >>>> >>>> Ok here is what I have done: >>>> >>>> I have a tree that already had XFS 1.1 (with a bunch of other >>>> stuff) included. I hand applied the XFS 1.2 on top of XFS 1.1 >>>> patch and everything seems to work fine, except when I run bonnie++ >>>> and under load (Writing intelligently operation), I receive the >>>> following Oops: >>>> >>>> >>> >>> >>> If possible get kbd into your tree. >>> Then open a bug and attach what ever backtraces you can get. >>> bta is a good place to start. >>> >>> That might shed some light on the situation, but without wading through >>> the lock changes you might have in your tree this problem may be >>> hard to track down. >>> >>> -Russell >>> >>> >>> >>> >>> >>> >> >> >> >> From owner-linux-xfs@oss.sgi.com Tue Mar 25 23:12:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Mar 2003 23:12:16 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q7BAq9016539 for ; Tue, 25 Mar 2003 23:11:50 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 86DDCAC4A; Wed, 26 Mar 2003 07:34:25 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id D1D46190C3; Wed, 26 Mar 2003 07:34:24 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 64F31308828; Wed, 26 Mar 2003 07:34:12 +0100 (CET) Message-ID: <3E8149E4.8A511858@ch.sauter-bc.com> Date: Wed, 26 Mar 2003 07:34:12 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.24-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Matt Schillinger Cc: linux-xfs@oss.sgi.com Subject: Re: XFS 1.1 vs. 1.2 References: <1048618954.22460.5.camel@mosix> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3354 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: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 458 Lines: 21 Matt Schillinger schrieb: > > Could someone tell me if it is worthwhile to use 1.2 over 1.1? Short answer: yes! Simon > > I have dev systems that are about to become production file servers.. I > am wondering if there are major benefits to 1.2 over 1.1.. > > particularly data integrity benefits, better prevention of log > corruption.. performance of course is great also.. > > Thanks for the help, > -- > Matt Schillinger > > mschilli@vss.fsi.com From owner-linux-xfs@oss.sgi.com Wed Mar 26 04:38:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 04:38:11 -0800 (PST) Received: from redix.it (host49-169.pool8172.interbusiness.it [81.72.169.49]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QCbHq9027965 for ; Wed, 26 Mar 2003 04:37:59 -0800 Received: (qmail 4167 invoked by uid 507); 26 Mar 2003 12:37:13 -0000 Received: from roberto@redix.it by mail.redix.it by uid 504 with qmail-scanner-1.14 (clamscan: 0.24. Clear:. Processed in 1.458866 secs); 26 Mar 2003 12:37:13 -0000 Received: from localhost (HELO redix.it) (127.0.0.1) by 0 with SMTP; 26 Mar 2003 12:37:11 -0000 Received: from 212.239.118.101 (proxying for unknown) (SquirrelMail authenticated user roberto) by mail.redix.it with HTTP; Wed, 26 Mar 2003 13:37:11 +0100 (CET) Message-ID: <2545.212.239.118.101.1048682231.squirrel@mail.redix.it> Date: Wed, 26 Mar 2003 13:37:11 +0100 (CET) Subject: Question about upgrade to XFS 1.2 From: To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3355 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: roberto@redix.it Precedence: bulk X-list: linux-xfs Content-Length: 448 Lines: 16 Date: 26 mar 2003 I'm running kernel 2.4.18 + XFS1.1+ LVM 1.3 on my PC. I'd like to know: 1) can I upgrade to kernel 2.4.19 + XFS 1.2 without reformatting and recreate new File System with XFS 1.2? any drawbacks using the current filesystem created with XFS1.1? It is best reformatting? 2) what is the suggested (well tested) version of LVM with XFS 1.2? LVM 1.7 or LVM2? anyone is already using these combination? thanks in advance, Roberto From owner-linux-xfs@oss.sgi.com Wed Mar 26 04:52:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 04:52:52 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QCq4q9028825 for ; Wed, 26 Mar 2003 04:52:44 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2QD3ikq013692 for ; Wed, 26 Mar 2003 07:03:44 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA25779; Wed, 26 Mar 2003 06:51:58 -0600 (CST) Received: from laptop.americas.sgi.com (cf-vpn-sw-corp-64-53.corp.sgi.com [134.15.64.53]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2QCpvwX35441412; Wed, 26 Mar 2003 06:51:58 -0600 (CST) Received: from laptop.americas.sgi.com by laptop.americas.sgi.com (8.12.8/SGI-client-1.7) via ESMTP id h2QCpUHb001414; Wed, 26 Mar 2003 06:51:30 -0600 Received: (from lord@localhost) by laptop.americas.sgi.com (8.12.8/8.12.8/Submit) id h2QCpSm8001412; Wed, 26 Mar 2003 06:51:28 -0600 X-Authentication-Warning: laptop.americas.sgi.com: lord set sender to lord@sgi.com using -f Subject: Re: Question about upgrade to XFS 1.2 From: Steve Lord To: roberto@redix.it Cc: linux-xfs@oss.sgi.com In-Reply-To: <2545.212.239.118.101.1048682231.squirrel@mail.redix.it> References: <2545.212.239.118.101.1048682231.squirrel@mail.redix.it> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 26 Mar 2003 06:51:28 -0600 Message-Id: <1048683088.1247.2.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3356 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 627 Lines: 24 On Wed, 2003-03-26 at 06:37, roberto@redix.it wrote: > Date: 26 mar 2003 > > I'm running kernel 2.4.18 + XFS1.1+ LVM 1.3 on my PC. > > I'd like to know: > 1) can I upgrade to kernel 2.4.19 + XFS 1.2 without reformatting and > recreate new File System with XFS 1.2? any drawbacks using the current > filesystem created with XFS1.1? It is best reformatting? On disk XFS is identical across all versions - we are not changing on disk format. Steve > > 2) what is the suggested (well tested) version of LVM with XFS 1.2? LVM > 1.7 or LVM2? anyone is already using these combination? > > thanks in advance, > Roberto > > From owner-linux-xfs@oss.sgi.com Wed Mar 26 05:22:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 05:22:32 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2QDMRq9005605 for ; Wed, 26 Mar 2003 05:22:27 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2QDMRc2005601 for linux-xfs@oss.sgi.com; Wed, 26 Mar 2003 05:22:27 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2QDMQqB005587 for ; Wed, 26 Mar 2003 05:22:26 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2QCNsro024571; Wed, 26 Mar 2003 04:23:54 -0800 Date: Wed, 26 Mar 2003 04:23:54 -0800 Message-Id: <200303261223.h2QCNsro024571@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3357 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 608 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From christian.guggenberger@physik.uni-regensburg.de 2003-03-26 04:23 ------- Created an attachment (id=72) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=72&action=view) some kdb outputs I'm also seeing that bug on a machine here. I can also reproduce it with 'updatedb; reboot'. System is Debian Woody, Kernel-2.4.20 + xfs-030316+ ptrace patch. I've created some kdb backtraces, maybe they help. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 26 06:01:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 06:01:31 -0800 (PST) Received: from stargate.coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.114.72.97]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QE1Rq9006901 for ; Wed, 26 Mar 2003 06:01:28 -0800 Received: from contact.skynet.coplanar.net (contact.skynet.coplanar.net [192.168.7.125]) by stargate.coplanar.net (8.12.8/8.12.5) with ESMTP id h2QE1OAW004380; Wed, 26 Mar 2003 09:01:24 -0500 Subject: Re: xfs installer From: Jeremy Jackson To: Michael Whang Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1048687283.1248.8.camel@contact.skynet.coplanar.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 26 Mar 2003 09:01:24 -0500 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3358 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: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 369 Lines: 16 I'm working on one for Debian... Jeremy On Tue, 2003-03-25 at 20:01, Michael Whang wrote: > Is there anyone that has created an XFS installer with a later kernel? > > > Mike > > > _________________________________________________________________ > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > From owner-linux-xfs@oss.sgi.com Wed Mar 26 06:22:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 06:22:29 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2QEMQq9007885 for ; Wed, 26 Mar 2003 06:22:26 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2QEMQMX007883 for linux-xfs@oss.sgi.com; Wed, 26 Mar 2003 06:22:26 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2QEMPqB007870 for ; Wed, 26 Mar 2003 06:22:25 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2QDP5vK006062; Wed, 26 Mar 2003 05:25:05 -0800 Date: Wed, 26 Mar 2003 05:25:05 -0800 Message-Id: <200303261325.h2QDP5vK006062@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3359 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 524 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From christian.guggenberger@physik.uni-regensburg.de 2003-03-26 05:25 ------- Created an attachment (id=73) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=73&action=view) another umount backtrace This is another backtrace of the umount process. It has been created some 50 Minutes after the umount process startet. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 26 07:50:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 07:50:45 -0800 (PST) Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QFoYq9009616 for ; Wed, 26 Mar 2003 07:50:35 -0800 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel9.hp.com (Postfix) with ESMTP id C91E91C01936 for ; Wed, 26 Mar 2003 10:50:30 -0500 (EST) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id ADBFF1C009EB for ; Wed, 26 Mar 2003 10:50:30 -0500 (EST) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Wed, 26 Mar 2003 10:50:30 -0500 Message-ID: From: "HABBINGA,ERIK (HP-Loveland,ex1)" To: "'linux-xfs@oss.sgi.com'" Subject: Re: crash in xfs_inactive Date: Wed, 26 Mar 2003 10:50:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3360 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: erik.habbinga@hp.com Precedence: bulk X-list: linux-xfs Content-Length: 834 Lines: 24 Scott, Nope, I'm not using those patches, nor am I using direct IO on NFS. The crash output in bug 195 looks different to me. In that bug, map_blocks is failing in the write path. In my crash, xfs_inactive is failing during the memory pressure/get rid of old inodes path. Erik > Erik, > Are you using NFS patches from nfs.sourceforge.net? If so > take a look a Bug 195 in bugzilla and you will notice there is > an issue with the patch to do Direct IO on NFS. > > I had the same output when I had the patch installed. > > -Scott > > ---------------------------------------------------------------- > Scott Jepson, Managing Partner Email: scott@cnes.com > Creative Network Services, LLC > (310)470-6140 > ---------------------------------------------------------------- > From owner-linux-xfs@oss.sgi.com Wed Mar 26 09:19:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 09:20:08 -0800 (PST) Received: from homer.nks.net (homer.nks.net [66.152.21.172]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QHJtq9011033 for ; Wed, 26 Mar 2003 09:19:57 -0800 Received: from hoju.nks.net (hoju.nks.net [192.168.1.17]) by homer.nks.net (8.9.3/8.9.3) with ESMTP id MAA25640 for ; Wed, 26 Mar 2003 12:19:49 -0500 Received: from localhost.localdomain (two.nks.net [192.168.1.22]) by hoju.nks.net (8.12.7/8.12.7/Debian 8.9.3-21) with ESMTP id h2QHJnYq026814 for ; Wed, 26 Mar 2003 12:19:49 -0500 Subject: Re: XFS, extended attrs and UML? From: Derek Glidden To: linux-xfs@oss.sgi.com In-Reply-To: <1048639529.11118.40.camel@rose.americas.sgi.com> References: <1048636846.13786.113.camel@two.nks.net> <1048639529.11118.40.camel@rose.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 26 Mar 2003 12:19:49 -0500 Message-Id: <1048699189.2156.5.camel@two.nks.net> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3361 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: dglidden@illusionary.com Precedence: bulk X-list: linux-xfs Content-Length: 1643 Lines: 40 On Tue, 2003-03-25 at 19:45, Rusell Cattelan wrote: > This is because uml doesn't have the attr syscalls mapped > kernel/sys_call_table.c > [ __NR_setxattr ] = sys_ni_syscall, > [ __NR_lsetxattr ] = sys_ni_syscall, > [ __NR_fsetxattr ] = sys_ni_syscall, > [ __NR_getxattr ] = sys_ni_syscall, > [ __NR_lgetxattr ] = sys_ni_syscall, > [ __NR_fgetxattr ] = sys_ni_syscall, > [ __NR_listxattr ] = sys_ni_syscall, > [ __NR_llistxattr ] = sys_ni_syscall, > [ __NR_flistxattr ] = sys_ni_syscall, > [ __NR_removexattr ] = sys_ni_syscall, > [ __NR_lremovexattr ] = sys_ni_syscall, > [ __NR_fremovexattr ] = sys_ni_syscall, > > You'll need to correct this table before it will work. > yep, that's exactly it. thanks! -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/usr/bin/perl -w $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} print+x"C*",@a}';s/x/pack+/g;eval usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec - http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/ From owner-linux-xfs@oss.sgi.com Wed Mar 26 09:22:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 09:22:29 -0800 (PST) Received: from zipcode.az.mvista.com (fw-az.mvista.com [65.200.49.158]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QHMOq9011501 for ; Wed, 26 Mar 2003 09:22:24 -0800 Received: from mvista.com (persist.az.mvista.com [10.50.1.246]) by zipcode.az.mvista.com (8.9.3/8.9.3) with ESMTP id KAA28417; Wed, 26 Mar 2003 10:34:28 -0700 Message-ID: <3E81DF67.6020400@mvista.com> Date: Wed, 26 Mar 2003 10:12:07 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: Rusell Cattelan , linux-xfs@oss.sgi.com Subject: Re: XFS 1.2 bug? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3362 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: sdake@mvista.com Precedence: bulk X-list: linux-xfs Content-Length: 2542 Lines: 81 Eric, responses below: Eric Sandeen wrote: >On Tue, 25 Mar 2003, Steven Dake wrote: > > > >>The function write_full_page will unlock the page if delalloc_convert >>returns a negative value. I don't understand why delalloc_convert >>returns a negative value, and if the page should be unlocked, but it >>seems that it shouldn't. Could you give me some background on why the >>page is unlocked at this point? If I comment out this unlock, bonnie++ >> >> > >delalloc_convert can fail on some error, and we have to do something >with the buffer at that point. This case was put in because >if we ignored the error, we'd write out a buffer with block 0 (delalloc) >and clobber the superblock. Perhaps locking has changed such that >the unlock_page is no longer correct, I'd have to look more closely. > >Are you hitting this case? > > No, I'm not. I am hitting the case where the file size is on a page boundary (causing offset to be zero), causing an error to be returned and the page to be unlocked in the out goto (ret is negative). Then the page is unlocked _again_ in the function generic_file_write_nolock, causing an Oops. Whatever should be done with the page after an error, I don't know, but it shouldn't be unlocked twice. Even though I am running into only one of the cases, I believe the other case to be in error as well, because it would cause an oops if this function operates on the same page as generic_file_write_nolock (double unlock_page == Oops). Should the size of the file be checked to ensure it is NOT on a page boundary? I don't understand the need for this check... Could you explain it ? STATIC int write_full_page( struct page *page, int delalloc) { struct inode *inode = (struct inode*)page->mapping->host; unsigned long end_index = inode->i_size >> PAGE_CACHE_SHIFT; int ret; /* Are we off the end of the file ? */ if (page->index >= end_index) { unsigned offset = inode->i_size & (PAGE_CACHE_SIZE-1); if ((page->index >= end_index+1) || !offset) { ret = -EIO; printk ("Off the end of the file %d %d %d %d\n", page->index, end_index, offset, inode- >i_size); goto out; } } >It would be very helpful if you could run this on a "stock" xfs >1.2 kernel to see if you still hit this problem. > > I'll give it a try, but unfortunately I only have FibreChannel disks so will have to add in the Qlogic driver... >-Eric > > > Thanks -steve > > From owner-linux-xfs@oss.sgi.com Wed Mar 26 09:33:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 09:33:19 -0800 (PST) Received: from zipcode.az.mvista.com (fw-az.mvista.com [65.200.49.158]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QHXFq9012019 for ; Wed, 26 Mar 2003 09:33:15 -0800 Received: from mvista.com (persist.az.mvista.com [10.50.1.246]) by zipcode.az.mvista.com (8.9.3/8.9.3) with ESMTP id KAA28573; Wed, 26 Mar 2003 10:45:20 -0700 Message-ID: <3E81E1F2.2040001@mvista.com> Date: Wed, 26 Mar 2003 10:22:58 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russell Cattelan CC: linux-xfs@oss.sgi.com Subject: Re: update: Re: XFS 1.2 bug? References: <3E809EB1.6000904@mvista.com> <1048639851.11129.44.camel@rose.americas.sgi.com> <3E80FEB5.90801@mvista.com> <3E8106CD.2050101@mvista.com> <3E8151E4.809@thebarn.com> In-Reply-To: <3E8151E4.809@thebarn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3363 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: sdake@mvista.com Precedence: bulk X-list: linux-xfs Content-Length: 8988 Lines: 285 Russell thanks for the responses and questions below. Russell Cattelan wrote: > Ok I've looked over the code. > write_full_page is modeled after block_write_full_page. Is block_write_full_page something new in XFS CVS? I don't see it in 1.2... > The past the end of file is the same check used in that function. > Basically the offset var used to see if size of the file is part way > into a page so if the size of the file lands on a page boundry offset > will be 0. I understand that the code is doing that, but I was wondering why XFS should care that write_full_page should fail if the file size is on a page boundary. If the file size is on a page boundary, shouldn't XFS be able to write the page just fine? > > As far as the unlock_page in the error case ... again based on > block_write_full_page > it seems correct to unlock the page in case of an error. If you unlock it here, you must not unlock it in generic_file_write_nolock. It can only be unlocked once... So the code should pick where it shall unlock. Since it will be unlocked later in generic_file_write_nolock, I don't understand the need to unlock it in write_full_page at all. The only case I can think of unlocking the page, is when it is _not_ called from generic_file_write_nolock. Perhaps this is happening somewhere and that is the need for the unlock, but if that is the case, generic_file_write_nolock must not unlock the page a second time... Tthe error code for write_full_page is never passed up to generic_file_write_nolock, so generic_file_write_nolock is never aware that it should _not_ unlock the page because the I/O had a previous error. > > do you have the backtrace of crash again? I'm wondering who called > write_full_page > in this case. The crash is not in write_full_page. write_full_page is the first caller to unlock the page. The crash occurs in generic_file_write_nolock which also calls unlock_page on the same page as write_full_page did, causing a BUG() call. The calling chain is: First generic_file_write_nolock is entered from a system call write: system_call sys_write linvfs_write xfs_write Then the page is unlocked via this call chain: generic_file_write_nolock generic_commit_write __block_commit_write balance_dirty write_some_buffer write_buffer_delay linvfs_write_full_page write_full_page unlock_page Then the page is unlocked again via this call chain: generic_file_write_nolock unlock_page > > > Steven Dake wrote: > >> Russell, >> >> I had a deeper look at why write_full_page was failing... In the code: >> STATIC int >> write_full_page( >> struct page *page, >> int delalloc) >> { >> struct inode *inode = (struct inode*)page->mapping->host; >> unsigned long end_index = inode->i_size >> PAGE_CACHE_SHIFT; >> int ret; >> >> /* Are we off the end of the file ? */ >> if (page->index >= end_index) { >> unsigned offset = inode->i_size & (PAGE_CACHE_SIZE-1); >> if ((page->index >= end_index+1) || !offset) { >> ret = -EIO; >> printk ("Off the end of the file %d %d %d %d\n", >> page->index, end_index, offset, inode- >> >i_size); >> goto out; >> } >> } >> >> I added the above printk and got the output >> Mar 24 22:49:47 192 kernel: Off the end of the file 91406 91406 0 >> 374398976 >> >> offset is zero, because 374398976 & ((1 << 12) -1) is zero. This >> operation looks like it should proceed since the size is ok and the >> page index and end index are within ranges. Why should we error if >> the size & PAGE_CACHE_SIZE-1 is zero? >> >> Any help appreciated on the two issues >> (the offset issue and the extra unlock_pages) >> >> Thanks! >> -steve >> >> Steven Dake wrote: >> >>> Russell, >>> >>> Thanks for the hints but I believe I found a bug in XFS 1.2, and >>> perhaps you could verify it since I'm not very familiar with the XFS >>> code. >>> >>> both linvfs_write_full_page and write_full_page will attempt to >>> unlock_page in some circumstances. The page is previously locked in >>> the function generic_file_write_nolock. This >>> generic_file_write_nolock function will unlock the page after it is >>> done using it. Unlocking a page twice will result in an Oops, so >>> either the mm layer (generic_file_write_nolock) shouldn't be >>> unlocking the page, or the xfs code in linvfs_write_full_page and >>> write_full_page shouldn't unlock the page a second time. The unlock >>> in the xfs code is suspect, since it only unlocks on certain >>> conditions (which will result in an Oops) >>> >>> The function linvfs_write_full_page unlocks a page in the case of an >>> error conditon. I have not been able to hit this error condition, >>> but if it occurs, an Oops will most certainly occur. >>> >>> STATIC int >>> linvfs_write_full_page( >>> struct page *page) >>> { >>> int flagset = 0; >>> int error; >>> int need_trans; >>> int nr_delalloc, nr_unmapped; >>> >>> if (count_page_state(page, &nr_delalloc, &nr_unmapped)) { >>> need_trans = nr_delalloc + nr_unmapped; >>> } else { >>> need_trans = 1; >>> } >>> >>> if ((current->flags & (PF_FSTRANS|PF_NOIO)) && need_trans) >>> goto out_fail; >>> >>> if (need_trans) { >>> current->flags |= PF_NOIO; >>> flagset = 1; >>> } >>> >>> error = write_full_page(page, nr_delalloc); >>> >>> if (flagset) >>> current->flags &= ~PF_NOIO; >>> return error; >>> >>> out_fail: >>> SetPageDirty(page); >>> unlock_page(page); >>> return 0; >>> } >>> >>> The function write_full_page will unlock the page if >>> delalloc_convert returns a negative value. I don't understand why >>> delalloc_convert returns a negative value, and if the page should be >>> unlocked, but it seems that it shouldn't. Could you give me some >>> background on why the page is unlocked at this point? If I comment >>> out this unlock, bonnie++ does not crash and the filesystem seems >>> still stable, but I'd like to understand _why_ this condition is >>> occuring and if the unlock_page is really needed, or if letting the >>> mm handle it is appropriate. >>> >>> STATIC int >>> write_full_page( >>> struct page *page, >>> int delalloc) >>> { >>> struct inode *inode = (struct inode*)page->mapping->host; >>> unsigned long end_index = inode->i_size >> PAGE_CACHE_SHIFT; >>> int ret; >>> >>> /* Are we off the end of the file ? */ >>> if (page->index >= end_index) { >>> unsigned offset = inode->i_size & (PAGE_CACHE_SIZE-1); >>> if ((page->index >= end_index+1) || !offset) { >>> ret = -EIO; >>> goto out; >>> } >>> } >>> >>> if (!page_has_buffers(page)) { >>> create_empty_buffers(page, inode->i_dev, 1 << inode->i_blkbits); >>> } >>> >>> ret = delalloc_convert(inode, page, 1, delalloc == 0); >>> >>> out: >>> if (ret < 0) { >>> /* >>> * If it's delalloc and we have nowhere to put it, >>> * throw it away. >>> */ >>> if (delalloc) >>> block_flushpage(page, 0); >>> ClearPageUptodate(page); >>> // unlock_page(page); >>> } >>> >>> return ret; >>> } >>> >>> It looks like the real problem is that no error return is processed >>> to not unlock the buffer if an error is returned by >>> linvfs_write_full_page by the function generic_file_write_nolock in >>> the call chain but the return values are used to indicate state in >>> some of the calls and cannot be used as error returns... >>> >>> The call stack that gets to the point where the page is unlocked is: >>> generic_file_write_nolock() >>> generic_commit_write() >>> __block_commit_write() >>> balance_dirty() >>> write_some_buffers() >>> write_buffer_delay() >>> linvfs_write_full_page() >>> write_full_page() >>> >>> After that the finish of the call generic_file_write_nolock will >>> also unlock that same page causing an oops. >>> >>> Thanks! >>> -steve >>> >>> Rusell Cattelan wrote: >>> >>>> On Tue, 2003-03-25 at 12:23, Steven Dake wrote: >>>> >>>> >>>>> XFS Developers, >>>>> >>>>> Ok here is what I have done: >>>>> >>>>> I have a tree that already had XFS 1.1 (with a bunch of other >>>>> stuff) included. I hand applied the XFS 1.2 on top of XFS 1.1 >>>>> patch and everything seems to work fine, except when I run >>>>> bonnie++ and under load (Writing intelligently operation), I >>>>> receive the following Oops: >>>>> >>>>> >>>> >>>> >>>> >>>> If possible get kbd into your tree. >>>> Then open a bug and attach what ever backtraces you can get. >>>> bta is a good place to start. >>>> >>>> That might shed some light on the situation, but without wading >>>> through >>>> the lock changes you might have in your tree this problem may be >>>> hard to track down. >>>> >>>> -Russell >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> > > > > From owner-linux-xfs@oss.sgi.com Wed Mar 26 09:35:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 09:35:21 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QHZGq9012448 for ; Wed, 26 Mar 2003 09:35:17 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2QHkvkq021338 for ; Wed, 26 Mar 2003 11:46:57 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA82959 for ; Wed, 26 Mar 2003 11:35:10 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2QHZAwX35935810 for ; Wed, 26 Mar 2003 11:35:10 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h2QHXm622916; Wed, 26 Mar 2003 11:33:48 -0600 Message-Id: <200303261733.h2QHXm622916@stout.americas.sgi.com> Date: Wed, 26 Mar 2003 11:33:48 -0600 Subject: TAKE - teach kdb about the FS_DATAIOD pagebuf flag X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3364 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 322 Lines: 13 teach kdb about the FS_DATAIOD pagebuf flag Date: Wed Mar 26 09:34:45 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:142703a linux/fs/xfs/xfsidbg.c - 1.217 From owner-linux-xfs@oss.sgi.com Wed Mar 26 09:37:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 09:37:24 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QHbMq9012894 for ; Wed, 26 Mar 2003 09:37:22 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2QHn3kq021379 for ; Wed, 26 Mar 2003 11:49:03 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA00529 for ; Wed, 26 Mar 2003 11:37:16 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2QHbGwX35382516 for ; Wed, 26 Mar 2003 11:37:16 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h2QHZsS22993; Wed, 26 Mar 2003 11:35:54 -0600 Message-Id: <200303261735.h2QHZsS22993@stout.americas.sgi.com> Date: Wed, 26 Mar 2003 11:35:54 -0600 Subject: TAKE - Disallow buffered writes to realtime files X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3365 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 352 Lines: 14 Disallow buffered writes to realtime files (only Direct IO allowed) Date: Wed Mar 26 09:36:53 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:142704a linux/fs/xfs/linux/xfs_lrw.c - 1.183 From owner-linux-xfs@oss.sgi.com Wed Mar 26 10:35:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 10:35:28 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QIYdq9014120 for ; Wed, 26 Mar 2003 10:35:20 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2QIkKkq022923 for ; Wed, 26 Mar 2003 12:46:20 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA04838 for ; Wed, 26 Mar 2003 12:34:31 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2QIYYwX35990205 for ; Wed, 26 Mar 2003 12:34:34 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h2QIXBe25074; Wed, 26 Mar 2003 12:33:11 -0600 Message-Id: <200303261833.h2QIXBe25074@stout.americas.sgi.com> Date: Wed, 26 Mar 2003 12:33:11 -0600 Subject: TAKE - Fix that last realtime fix X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3366 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 416 Lines: 15 Argh, get the unbuffered realtime write test correct! Last checkin had a last-minute logic change... maybe I should have tested it! Date: Wed Mar 26 10:33:28 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:142710a linux/fs/xfs/linux/xfs_lrw.c - 1.184 From owner-linux-xfs@oss.sgi.com Wed Mar 26 10:59:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 10:59:52 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QIx6q9014772 for ; Wed, 26 Mar 2003 10:59:46 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2QJAlkq023629 for ; Wed, 26 Mar 2003 13:10:47 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA26439; Wed, 26 Mar 2003 12:59:00 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2QIwxwX35344422; Wed, 26 Mar 2003 12:59:00 -0600 (CST) Subject: Re: update: Re: XFS 1.2 bug? From: Rusell Cattelan To: Steven Dake Cc: Russell Cattelan , linux-xfs@oss.sgi.com In-Reply-To: <3E81E1F2.2040001@mvista.com> References: <3E809EB1.6000904@mvista.com> <1048639851.11129.44.camel@rose.americas.sgi.com> <3E80FEB5.90801@mvista.com> <3E8106CD.2050101@mvista.com> <3E8151E4.809@thebarn.com> <3E81E1F2.2040001@mvista.com> Content-Type: text/plain Organization: Message-Id: <1048705227.11118.121.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-1) Date: 26 Mar 2003 13:00:27 -0600 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3367 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: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 3085 Lines: 77 On Wed, 2003-03-26 at 11:22, Steven Dake wrote: > Russell thanks for the responses and questions below. > > Russell Cattelan wrote: > > > Ok I've looked over the code. > > write_full_page is modeled after block_write_full_page. > > Is block_write_full_page something new in XFS CVS? I don't see it in 1.2... block_write_full_page is the generic write_full_page use by most file systems. eg static int ext2_writepage(struct page *page) { return block_write_full_page(page,ext2_get_block); } The check for writing beyond the end of file is apparently taken from there. /* easy case */ if (page->index < end_index) return __block_write_full_page(inode, page, get_block); /* things got complicated... */ offset = inode->i_size & (PAGE_CACHE_SIZE-1); /* OK, are we completely out? */ if (page->index >= end_index+1 || !offset) { UnlockPage(page); return -EIO; } > > > The past the end of file is the same check used in that function. > > Basically the offset var used to see if size of the file is part way > > into a page so if the size of the file lands on a page boundry offset > > will be 0. I've been looking at the code and I think it's correct to error in the case where page->index == i_size (unit converted ofcourse) That would be the page just past the end if file. > > I understand that the code is doing that, but I was wondering why XFS > should care that write_full_page should fail if the file size is on a > page boundary. If the file size is on a page boundary, shouldn't XFS be > able to write the page just fine? > > > > > As far as the unlock_page in the error case ... again based on > > block_write_full_page > > it seems correct to unlock the page in case of an error. > > If you unlock it here, you must not unlock it in > generic_file_write_nolock. It can only be unlocked once... So the code > should pick where it shall unlock. Since it will be unlocked later in > generic_file_write_nolock, I don't understand the need to unlock it in > write_full_page at all. The only case I can think of unlocking the > page, is when it is _not_ called from generic_file_write_nolock. > Perhaps this is happening somewhere and that is the need for the > unlock, but if that is the case, generic_file_write_nolock must not > unlock the page a second time... Tthe error code for write_full_page is > never passed up to generic_file_write_nolock, so > generic_file_write_nolock is never aware that it should _not_ unlock the > page because the I/O had a previous error Yes I agree the unlock path does looks suspicious. I found 5 spots in the kernel the calls writepage only one of them filemap_fdatasync actually checks the error code and it even that doesn't change if the page is unlocked or not. So yes I think the unlock_page is in error in write_full_page.... and in block_write_full_page for that matter. Stick a BUG() in the check for past eof ... the root of the problem seem to be somebody trying to write past eof. From owner-linux-xfs@oss.sgi.com Wed Mar 26 11:09:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 11:09:25 -0800 (PST) Received: from ncbdc.bbs.com ([208.0.185.14]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QJ8fq9015272 for ; Wed, 26 Mar 2003 11:09:22 -0800 Received: by NCBDC with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Mar 2003 11:08:51 -0800 Message-ID: <057889C7F1E5D61193620002A537E8690AD0A9@NCBDC> From: Mark Grimes To: "'linux-xfs@oss.sgi.com'" Subject: XFS holding onto disk memory Date: Wed, 26 Mar 2003 11:08:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3368 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: MGrimes@snapappliance.com Precedence: bulk X-list: linux-xfs Content-Length: 787 Lines: 22 I'm using linux-2.4.18, XFS version 1.1 with patches. I've been doing some simple tests on XFS behavior when filling up a filesystem (128MB). One of the tests I do is to create zero length files (i.e. touch FileX) to use up the available inodes. When I've used up all available inodes, the disk usage is reported at 26%. This is OK, and expected. The issue I have is after I've deleted all the files. The disk usage stays at 26%. Is this expected behavior? Is there a way to recover the on disk memory without unmounting the filesystem? ````````````````````````````````````````````````````````````````````````` Mark Grimes Senior Software Developer Snap Appliance mgrimes@snapappliance.com (408) 879-8461 ``````````````````````````````````````````````````````````````````````````` From owner-linux-xfs@oss.sgi.com Wed Mar 26 11:18:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 11:18:06 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QJI0q9015746 for ; Wed, 26 Mar 2003 11:18:01 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2QJTgkq024157 for ; Wed, 26 Mar 2003 13:29:42 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA05578; Wed, 26 Mar 2003 13:17:55 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2QJHtCJ6297364; Wed, 26 Mar 2003 13:17:55 -0600 (CST) Date: Wed, 26 Mar 2003 13:16:32 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Mark Grimes cc: "'linux-xfs@oss.sgi.com'" Subject: Re: XFS holding onto disk memory In-Reply-To: <057889C7F1E5D61193620002A537E8690AD0A9@NCBDC> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3369 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 552 Lines: 17 > Is this expected behavior? Is there a way to recover the on disk memory > without unmounting the filesystem? XFS dynamically allocates inodes as they are requested, but they are never freed. Even unmounting won't get this back for you. So if you fill your disk with 0-length files, the space allocated for inodes will always & forever be allocated for those inodes. (compare this to ext2, where inode space is permanently allocated at mkfs time). You can use xfs_growfs to change the % of the disk which can be used for inodes, though. -Eric From owner-linux-xfs@oss.sgi.com Wed Mar 26 11:22:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 11:22:33 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2QJMUq9016398 for ; Wed, 26 Mar 2003 11:22:30 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2QJMUSB016396 for linux-xfs@oss.sgi.com; Wed, 26 Mar 2003 11:22:30 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2QJMTqB016383 for ; Wed, 26 Mar 2003 11:22:29 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2QJL4xt016255; Wed, 26 Mar 2003 11:21:04 -0800 Date: Wed, 26 Mar 2003 11:21:04 -0800 Message-Id: <200303261921.h2QJL4xt016255@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3370 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 676 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From cattelan@thebarn.com 2003-03-26 11:21 ------- Hmm for some reaon you are out of requests. 0xce95fd34 0xc01b856a __get_request_wait+0x9a (0xc03b23c4, 0x1) kernel .text 0xc0100000 0xc01b84d0 0xc01b85d0 load the kdb_pg and kdbm_vm you can then look at the request queue for that device requeue Also send a bta if you could. or at the very least btp of kupdated, dbflush, kswapd, pagebufd, and page_buf_IO ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 26 11:24:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 11:24:09 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QJO5q9016836 for ; Wed, 26 Mar 2003 11:24:05 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2QJO0nH022564 for ; Wed, 26 Mar 2003 11:24:00 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA81914; Wed, 26 Mar 2003 13:23:59 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2QJNxwX36163158; Wed, 26 Mar 2003 13:23:59 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2QJNxp25942; Wed, 26 Mar 2003 13:23:59 -0600 Subject: Re: XFS holding onto disk memory From: Steve Lord To: Eric Sandeen Cc: Mark Grimes , "'linux-xfs@oss.sgi.com'" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1048706638.23087.75.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 26 Mar 2003 13:23:59 -0600 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3371 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 837 Lines: 27 On Wed, 2003-03-26 at 13:16, Eric Sandeen wrote: > > Is this expected behavior? Is there a way to recover the on disk memory > > without unmounting the filesystem? > > XFS dynamically allocates inodes as they are requested, but they are > never freed. Even unmounting won't get this back for you. > > So if you fill your disk with 0-length files, the space allocated > for inodes will always & forever be allocated for those inodes. > > (compare this to ext2, where inode space is permanently allocated > at mkfs time). > > You can use xfs_growfs to change the % of the disk which can be used > for inodes, though. > > -Eric And we do have freeing of inodes working in house. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Mar 26 11:26:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 11:26:35 -0800 (PST) Received: from ncbdc.bbs.com ([208.0.185.14]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QJPqq9017274 for ; Wed, 26 Mar 2003 11:26:32 -0800 Received: by NCBDC with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Mar 2003 11:26:02 -0800 Message-ID: <057889C7F1E5D61193620002A537E8690AD0AA@NCBDC> From: Mark Grimes To: "'Steve Lord'" , Eric Sandeen Cc: Mark Grimes , "'linux-xfs@oss.sgi.com'" Subject: RE: XFS holding onto disk memory Date: Wed, 26 Mar 2003 11:26:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3372 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: MGrimes@snapappliance.com Precedence: bulk X-list: linux-xfs Content-Length: 1114 Lines: 38 Is this a patch I can try? I can build with XFS v1.2 if necessary. -----Original Message----- From: Steve Lord [mailto:lord@sgi.com] Sent: Wednesday, March 26, 2003 11:24 AM To: Eric Sandeen Cc: Mark Grimes; 'linux-xfs@oss.sgi.com' Subject: Re: XFS holding onto disk memory On Wed, 2003-03-26 at 13:16, Eric Sandeen wrote: > > Is this expected behavior? Is there a way to recover the on disk memory > > without unmounting the filesystem? > > XFS dynamically allocates inodes as they are requested, but they are > never freed. Even unmounting won't get this back for you. > > So if you fill your disk with 0-length files, the space allocated > for inodes will always & forever be allocated for those inodes. > > (compare this to ext2, where inode space is permanently allocated > at mkfs time). > > You can use xfs_growfs to change the % of the disk which can be used > for inodes, though. > > -Eric And we do have freeing of inodes working in house. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Mar 26 11:29:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 11:29:47 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QJTiq9017723 for ; Wed, 26 Mar 2003 11:29:45 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2QJTdnH023108 for ; Wed, 26 Mar 2003 11:29:39 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA39124; Wed, 26 Mar 2003 13:29:38 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2QJTcwX35098691; Wed, 26 Mar 2003 13:29:38 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2QJTcg25958; Wed, 26 Mar 2003 13:29:38 -0600 Subject: RE: XFS holding onto disk memory From: Steve Lord To: Mark Grimes Cc: Eric Sandeen , "'linux-xfs@oss.sgi.com'" In-Reply-To: <057889C7F1E5D61193620002A537E8690AD0AA@NCBDC> References: <057889C7F1E5D61193620002A537E8690AD0AA@NCBDC> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1048706978.23087.83.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 26 Mar 2003 13:29:38 -0600 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3373 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 354 Lines: 14 On Wed, 2003-03-26 at 13:26, Mark Grimes wrote: > Is this a patch I can try? > I can build with XFS v1.2 if necessary. Not yet, it only worked for the first time a few days ago, and that was on Irix. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Mar 26 14:00:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 14:00:49 -0800 (PST) Received: from hotmail.com (oe39.law9.hotmail.com [64.4.8.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QM0fq9019985 for ; Wed, 26 Mar 2003 14:00:42 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 26 Mar 2003 14:00:36 -0800 Received: from 217.233.68.19 by oe39.law9.hotmail.com with DAV; Wed, 26 Mar 2003 22:00:36 +0000 X-Originating-IP: [217.233.68.19] X-Originating-Email: [k_leibrandt@hotmail.com] From: "Kai Leibrandt" To: Subject: Updated kernels with ptrace bugfix? Date: Wed, 26 Mar 2003 23:00:25 +0100 Message-ID: <000001c2f3e3$1ab21780$0c00a8c0@Bilbo> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2605 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-OriginalArrivalTime: 26 Mar 2003 22:00:36.0585 (UTC) FILETIME=[218D9D90:01C2F3E3] X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3375 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: k_leibrandt@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 397 Lines: 12 Hi all, I was just wondering if the kernels found at oss.sgi.com or http://iserv.nl/files/xfs/ have the RedHat ptrace bugfix in them, and if not, if there are any RH 8.0 compatible rpms available with xfs that do have the bugfix. If not, what is the recommended path for obtaining a ptrace patched kernel (i.e. download the latest srpm from RH, patch with xfs?). Many thanks for any info, Kai. From owner-linux-xfs@oss.sgi.com Wed Mar 26 14:22:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 14:22:30 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2QMMSq9020596 for ; Wed, 26 Mar 2003 14:22:28 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2QMMS4A020594 for linux-xfs@oss.sgi.com; Wed, 26 Mar 2003 14:22:28 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2QMMRqB020581 for ; Wed, 26 Mar 2003 14:22:27 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2QLQ5Mf019709; Wed, 26 Mar 2003 13:26:05 -0800 Date: Wed, 26 Mar 2003 13:26:05 -0800 Message-Id: <200303262126.h2QLQ5Mf019709@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3376 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 405 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From christian.guggenberger@physik.uni-regensburg.de 2003-03-26 13:26 ------- Created an attachment (id=74) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=74&action=view) ouput of ps, cpu and bta ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 26 14:34:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 14:34:24 -0800 (PST) Received: from zipcode.az.mvista.com (fw-az.mvista.com [65.200.49.158]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QMYJq9021582 for ; Wed, 26 Mar 2003 14:34:20 -0800 Received: from mvista.com (persist.az.mvista.com [10.50.1.246]) by zipcode.az.mvista.com (8.9.3/8.9.3) with ESMTP id PAA00480; Wed, 26 Mar 2003 15:46:23 -0700 Message-ID: <3E822881.4080104@mvista.com> Date: Wed, 26 Mar 2003 15:24:01 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rusell Cattelan CC: Russell Cattelan , linux-xfs@oss.sgi.com Subject: Re: update: Re: XFS 1.2 bug? References: <3E809EB1.6000904@mvista.com> <1048639851.11129.44.camel@rose.americas.sgi.com> <3E80FEB5.90801@mvista.com> <3E8106CD.2050101@mvista.com> <3E8151E4.809@thebarn.com> <3E81E1F2.2040001@mvista.com> <1048705227.11118.121.camel@rose.americas.sgi.com> In-Reply-To: <1048705227.11118.121.camel@rose.americas.sgi.com> Content-Type: multipart/mixed; boundary="------------030108020603090809080108" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3377 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: sdake@mvista.com Precedence: bulk X-list: linux-xfs Content-Length: 4696 Lines: 147 This is a multi-part message in MIME format. --------------030108020603090809080108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Russell, Thanks for all the help, I believe I finally found the issue. I ensured that any page locked in generic_file_write_nolock was never used in write_full_page. I used xfs 1.2 / kernel 2.4.19 / e1000/qla2300. In 2.4.18 / xfs1.2 , the page locked was reused, resulting in the potential that one page could potentially be unlocked twice if the page was past the end of the inode. After doing all that, I went through and rediffed the sources and found the change between 2.4.18 and 2.4.19 which apprently allows xfs to work on 2.4.18 as with 2.4.19. With the change, my 2.4.18 kernel doesn't attempt to unlock the page twice. That patch is attached. Thanks -steve Rusell Cattelan wrote: >On Wed, 2003-03-26 at 11:22, Steven Dake wrote: > > >>Russell thanks for the responses and questions below. >> >>Russell Cattelan wrote: >> >> >> >>>Ok I've looked over the code. >>>write_full_page is modeled after block_write_full_page. >>> >>> >>Is block_write_full_page something new in XFS CVS? I don't see it in 1.2... >> >> >block_write_full_page is the generic write_full_page use by most file >systems. >eg >static int ext2_writepage(struct page *page) >{ > return block_write_full_page(page,ext2_get_block); >} > >The check for writing beyond the end of file is apparently taken from >there. > /* easy case */ > if (page->index < end_index) > return __block_write_full_page(inode, page, get_block); > > /* things got complicated... */ > offset = inode->i_size & (PAGE_CACHE_SIZE-1); > /* OK, are we completely out? */ > if (page->index >= end_index+1 || !offset) { > UnlockPage(page); > return -EIO; > } > > > > >>>The past the end of file is the same check used in that function. >>>Basically the offset var used to see if size of the file is part way >>>into a page so if the size of the file lands on a page boundry offset >>>will be 0. >>> >>> >I've been looking at the code and I think it's correct to error >in the case where page->index == i_size (unit converted ofcourse) >That would be the page just past the end if file. > > > >>I understand that the code is doing that, but I was wondering why XFS >>should care that write_full_page should fail if the file size is on a >>page boundary. If the file size is on a page boundary, shouldn't XFS be >>able to write the page just fine? >> >> >> >>>As far as the unlock_page in the error case ... again based on >>>block_write_full_page >>>it seems correct to unlock the page in case of an error. >>> >>> >>If you unlock it here, you must not unlock it in >>generic_file_write_nolock. It can only be unlocked once... So the code >>should pick where it shall unlock. Since it will be unlocked later in >>generic_file_write_nolock, I don't understand the need to unlock it in >>write_full_page at all. The only case I can think of unlocking the >>page, is when it is _not_ called from generic_file_write_nolock. >> Perhaps this is happening somewhere and that is the need for the >>unlock, but if that is the case, generic_file_write_nolock must not >>unlock the page a second time... Tthe error code for write_full_page is >>never passed up to generic_file_write_nolock, so >>generic_file_write_nolock is never aware that it should _not_ unlock the >>page because the I/O had a previous error >> >> >Yes I agree the unlock path does looks suspicious. >I found 5 spots in the kernel the calls writepage only one >of them filemap_fdatasync actually checks the error code and >it even that doesn't change if the page is unlocked or not. > >So yes I think the unlock_page is in error in write_full_page.... and >in block_write_full_page for that matter. > > >Stick a BUG() in the check for past eof ... the root of the problem seem >to be somebody trying to write past eof. > > > > > > --------------030108020603090809080108 Content-Type: text/plain; name="buffer2418.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="buffer2418.patch" --- buffer.c.broken Wed Mar 26 11:52:22 2003 +++ buffer.c Wed Mar 26 15:09:00 2003 @@ -127,11 +127,11 @@ static inline int write_buffer_delay(struct buffer_head *bh) { struct page *page = bh->b_page; - if (TryLockPage(page)) { + if (!TryLockPage(page)) { spin_unlock(&lru_list_lock); unlock_buffer(bh); page->mapping->a_ops->writepage(page); return 1; } --------------030108020603090809080108-- From owner-linux-xfs@oss.sgi.com Wed Mar 26 15:11:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 15:11:46 -0800 (PST) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QNAtq9023172 for ; Wed, 26 Mar 2003 15:11:40 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-165-123.quicknet.nl [212.58.165.123]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id h2QNAm3C046950; Thu, 27 Mar 2003 00:10:48 +0100 (CET) Message-Id: <4.3.2.7.2.20030326235943.032fce18@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Mar 2003 00:10:46 +0100 To: "Kai Leibrandt" , From: Seth Mos Subject: Re: Updated kernels with ptrace bugfix? In-Reply-To: <000001c2f3e3$1ab21780$0c00a8c0@Bilbo> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3378 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1866 Lines: 44 At 23:00 26-3-2003 +0100, Kai Leibrandt wrote: >Hi all, > >I was just wondering if the kernels found at oss.sgi.com or >http://iserv.nl/files/xfs/ have the RedHat ptrace bugfix in them, and if >not, if there are any RH 8.0 compatible rpms available with xfs that do >have the bugfix. If not, what is the recommended path for obtaining a >ptrace patched kernel (i.e. download the latest srpm from RH, patch with >xfs?). >Many thanks for any info, The kernels at oss.sgi.com are the official 1.2 release kernels and do not contain the ptrace fix. The kernels from my site (2.4.18-27) do contain the ptrace fix since they are based on the Red Hat errata. They have the 1.2 patch in there but are not official because they are not tested as much as the oss.sgi.com rpms. There have been no large changes in the Red Hat errata since the last 4 revisions (except the ptrace fix from -27) were all related to network fixes and mainly the tg3 lockups and hangs which are fixed in -26 after 3 months of public disgrace and fooling around by Red Hat. I think it's safe to say the these errata kernels I made work just as well as the "official" rpms but I will never brand them as such. In case anyone is wondering why I made these updated kernels. I do this because of personal needs and I rather have them work on integrating with mainline and fixing bugs then having them spin new releases for errata which come out every few weeks or so. As long as the patching is not hard or difficult I have no issues with building these things myself and helping others as well. At least I believe that should be the idea behind it or something like that. It's late here and I had a busy day so this may sound like rambling. My brain is 2 bytes short of a ping so I'm gonna shut up and sleep now. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Mar 26 15:22:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 15:22:34 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2QNMTq9025380 for ; Wed, 26 Mar 2003 15:22:29 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2QNMTwB025378 for linux-xfs@oss.sgi.com; Wed, 26 Mar 2003 15:22:29 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2QNMRqB025365 for ; Wed, 26 Mar 2003 15:22:27 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2QN489T022521; Wed, 26 Mar 2003 15:04:08 -0800 Date: Wed, 26 Mar 2003 15:04:08 -0800 Message-Id: <200303262304.h2QN489T022521@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3379 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 313 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From cattelan@thebarn.com 2003-03-26 15:04 ------- would ext3 happen to be in the mix at all on this system? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 26 15:56:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 15:57:00 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QNuBq9025961 for ; Wed, 26 Mar 2003 15:56:52 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2QNu5nH012298 for ; Wed, 26 Mar 2003 15:56:06 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2QNsm7L3741703 for ; Thu, 27 Mar 2003 10:54:48 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2QNsm5X3671855 for linux-xfs@oss.sgi.com; Thu, 27 Mar 2003 10:54:48 +1100 (EST) Date: Thu, 27 Mar 2003 10:54:48 +1100 (EST) From: Nathan Scott Message-Id: <200303262354.h2QNsm5X3671855@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 885065 - userspace packaging goo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3380 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2174 Lines: 74 Merge back some spec file cleanups after investigating a mysterious build problem observed during the internal SGI product builds. Date: Wed Mar 26 15:18:13 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: markgw@sgi.com Author: nathans Merged by: nathans Merged mods: xfs-cmds-lbs:slinx:142673a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:142673a acl/Makepkgs - 1.7 attr/Makepkgs - 1.6 xfsprogs/Makepkgs - 1.7 xfsdump/Makepkgs - 1.5 dmapi/Makepkgs - 1.6 - Merge of xfs-cmds-lbs:slinx:142673a by nathans. Fix Makepkgs scripts to be able to propogate make errors back to the caller. acl/build/rpm/Makefile - 1.11 acl/build/rpm/acl.spec.in - 1.10 attr/build/rpm/Makefile - 1.10 attr/build/rpm/attr.spec.in - 1.13 xfsprogs/build/rpm/xfsprogs.spec.in - 1.15 xfsprogs/build/rpm/Makefile - 1.10 xfsdump/build/rpm/Makefile - 1.9 xfsdump/build/rpm/xfsdump.spec.in - 1.13 dmapi/build/rpm/Makefile - 1.9 dmapi/build/rpm/dmapi.spec.in - 1.15 - Merge of xfs-cmds-lbs:slinx:142673a by nathans. Redistribute the shell code which does the manifest to specfile file list conversion due to strange behavior being observed from rpm (we think). Its cleaner this way anyway. Date: Wed Mar 26 15:50:04 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:142779a acl/VERSION - 1.46 acl/doc/CHANGES - 1.53 acl/build/rpm/Makefile - 1.12 acl/debian/control - 1.13 acl/debian/changelog - 1.40 attr/VERSION - 1.30 attr/doc/CHANGES - 1.38 attr/build/rpm/Makefile - 1.11 attr/debian/changelog - 1.33 xfsprogs/VERSION - 1.70 xfsprogs/doc/CHANGES - 1.95 xfsprogs/build/rpm/Makefile - 1.11 xfsprogs/debian/changelog - 1.63 xfsdump/VERSION - 1.47 xfsdump/doc/CHANGES - 1.55 xfsdump/build/rpm/Makefile - 1.10 xfsdump/debian/control - 1.15 xfsdump/debian/changelog - 1.37 dmapi/VERSION - 1.15 dmapi/doc/CHANGES - 1.14 dmapi/build/rpm/Makefile - 1.10 dmapi/debian/control - 1.9 dmapi/debian/changelog - 1.15 - Minor packaging related cleanups and updates. From owner-linux-xfs@oss.sgi.com Wed Mar 26 16:48:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 16:48:35 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2R0mPq9029383 for ; Wed, 26 Mar 2003 16:48:26 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id A0542184A652; Wed, 26 Mar 2003 16:48:24 -0800 (PST) Date: Wed, 26 Mar 2003 16:48:24 -0800 From: Chris Wedgwood To: Austin Gonyou Cc: xfs-list Subject: Re: Rebuilding the src rpm for xfs 1.2 redhat kernel. Message-ID: <20030327004824.GA19075@f00f.org> References: <1048617504.30660.58.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1048617504.30660.58.camel@UberGeek> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3381 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 299 Lines: 11 On Tue, Mar 25, 2003 at 12:38:24PM -0600, Austin Gonyou wrote: > I want it to build for Pentium IVs and SMP but I'm building it on a > PIII box. What is the best way to accomplish this? Tia. it doesnt matter what what your build box is --- just target for SMP P4 and that should suffice --cw From owner-linux-xfs@oss.sgi.com Wed Mar 26 16:49:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 16:49:45 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2R0ngq9029552 for ; Wed, 26 Mar 2003 16:49:42 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 4DFA0184A652; Wed, 26 Mar 2003 16:49:41 -0800 (PST) Date: Wed, 26 Mar 2003 16:49:41 -0800 From: Chris Wedgwood To: Rusell Cattelan Cc: Derek Glidden , linux-xfs@oss.sgi.com Subject: Re: XFS, extended attrs and UML? Message-ID: <20030327004941.GB19075@f00f.org> References: <1048636846.13786.113.camel@two.nks.net> <1048639529.11118.40.camel@rose.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1048639529.11118.40.camel@rose.americas.sgi.com> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3382 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 296 Lines: 14 On Tue, Mar 25, 2003 at 06:45:29PM -0600, Rusell Cattelan wrote: > This is because uml doesn't have the attr syscalls mapped > kernel/sys_call_table.c [...] > You'll need to correct this table before it will work. and of course make sure you pass the changes upstream to get merged --cw From owner-linux-xfs@oss.sgi.com Wed Mar 26 17:22:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 17:22:37 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2R1MUq9031431 for ; Wed, 26 Mar 2003 17:22:30 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2R1MUA9031429 for linux-xfs@oss.sgi.com; Wed, 26 Mar 2003 17:22:30 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2R1MRqB031416 for ; Wed, 26 Mar 2003 17:22:28 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2R0Ohb4026592; Wed, 26 Mar 2003 16:24:43 -0800 Date: Wed, 26 Mar 2003 16:24:43 -0800 Message-Id: <200303270024.h2R0Ohb4026592@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3383 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1018 Lines: 28 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From christian.guggenberger@physik.uni-regensburg.de 2003-03-26 16:24 ------- Nope there's no ext3 filesystem (But ext3 is compiled as module). The system has 4 partitions, where hda1 (ext2) mounted as /, hda2 (xfs) as /var, hda3 (swap) and hda4 (xfs) mounted as /usr. When I use SysRQ+sync, while the hanging umount process during shutdown occures, I see that all devices except hda4(/usr) can be emergency sync'd. SYSRQ+remount,ro then can do nothing anymore. But then there's another weird thing: When I reboot the machine(while the umount process is hanging - and only with SySRQ-boot, no sync and ro), hda1 will be e2fsck'd on startup, xfs-recovery will be done on hda2 (/var), but not on hda4 (/usr). The kernel claims to do a clean xfs mount here... hmmm? The xfs fs had been created with xfsprogs-2.0.3 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 26 18:07:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 18:07:27 -0800 (PST) Received: from waltsathlon.localhost.net (12-211-67-94.client.attbi.com [12.211.67.94] (may be forged)) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2R26Zq9016551 for ; Wed, 26 Mar 2003 18:07:16 -0800 Received: from comcast.net (localhost [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id 98AC5820722; Wed, 26 Mar 2003 18:06:29 -0800 (PST) Message-ID: <3E825CA5.6010007@comcast.net> Date: Wed, 26 Mar 2003 18:06:29 -0800 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030326 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord Cc: Mark Grimes , Eric Sandeen , "'linux-xfs@oss.sgi.com'" Subject: Re: XFS holding onto disk memory References: <057889C7F1E5D61193620002A537E8690AD0AA@NCBDC> <1048706978.23087.83.camel@jen.americas.sgi.com> In-Reply-To: <1048706978.23087.83.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3384 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: waltabbyh@comcast.net Precedence: bulk X-list: linux-xfs Content-Length: 959 Lines: 27 Steve Lord wrote: > On Wed, 2003-03-26 at 13:26, Mark Grimes wrote: > >>Is this a patch I can try? >>I can build with XFS v1.2 if necessary. > > > Not yet, it only worked for the first time a few days ago, and > that was on Irix. > > Steve > I'm not tremendously familiar with the innards of a filesystem, so this question may be totally off the mark. But.... Would freeing of inodes allow the system to have contiguous free space? I've found when testing servers prior to production, that if I create thousands of files and potentially many runs of bonnie++ etc.. that certain aspects of filesystem operation are slowed down, even after removing all the test files. For example, if after removing all these test files and I want/need to run an xfs_check/xfs_repair on said filesystem, it can drag on for quite some time. This happens on a filesystem which now has very little on it. Would freeing inodes help something such as this? -Walt From owner-linux-xfs@oss.sgi.com Wed Mar 26 18:25:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 18:25:33 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2R2Ooq9017123 for ; Wed, 26 Mar 2003 18:25:30 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2R2OiuY029010 for ; Wed, 26 Mar 2003 18:24:44 -0800 Received: from zomba.sgi.com ([198.149.18.14]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA00084; Wed, 26 Mar 2003 20:24:41 -0600 (CST) Received: from zomba.sgi.com (localhost.sgi.com [127.0.0.1]) by zomba.sgi.com (8.12.8/8.12.6/freebsd-sendmail_sa_mtv-1.0) with ESMTP id h2R2NvRM001489; Wed, 26 Mar 2003 20:24:46 -0600 (CST) X-Possible-Spam: the addition of this header was triggered by: laptop.americas.sgi.com.failing.dns.checks:helo Received: from laptop.americas.sgi.com (cf-vpn-sw-corp-64-39.corp.sgi.com [134.15.64.39]) by zomba.sgi.com (8.12.8/8.12.6/freebsd-nospam-3.1) with ESMTP id h2R2MKKq001365; Wed, 26 Mar 2003 20:22:21 -0600 (CST) Received: from laptop.americas.sgi.com by laptop.americas.sgi.com (8.12.8/SGI-client-1.7) via ESMTP id h2R2Lk9l001254; Wed, 26 Mar 2003 20:21:46 -0600 Received: (from lord@localhost) by laptop.americas.sgi.com (8.12.8/8.12.8/Submit) id h2R2Lhx2001252; Wed, 26 Mar 2003 20:21:43 -0600 X-Authentication-Warning: laptop.americas.sgi.com: lord set sender to lord@sgi.com using -f Subject: Re: XFS holding onto disk memory From: Steve Lord To: Walt H Cc: Mark Grimes , Eric Sandeen , "'linux-xfs@oss.sgi.com'" In-Reply-To: <3E825CA5.6010007@comcast.net> References: <057889C7F1E5D61193620002A537E8690AD0AA@NCBDC> <1048706978.23087.83.camel@jen.americas.sgi.com> <3E825CA5.6010007@comcast.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 26 Mar 2003 20:21:43 -0600 Message-Id: <1048731703.1119.15.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3385 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 996 Lines: 22 On Wed, 2003-03-26 at 20:06, Walt H wrote: > > I'm not tremendously familiar with the innards of a filesystem, so this > question may be totally off the mark. But.... Would freeing of inodes > allow the system to have contiguous free space? I've found when testing > servers prior to production, that if I create thousands of files and > potentially many runs of bonnie++ etc.. that certain aspects of > filesystem operation are slowed down, even after removing all the test > files. For example, if after removing all these test files and I > want/need to run an xfs_check/xfs_repair on said filesystem, it can drag > on for quite some time. This happens on a filesystem which now has very > little on it. Would freeing inodes help something such as this? > > -Walt > It would yes, but we are not currently planning on offering facilities to clean up existing filesystems. Over time inode clusters would be freed, but only as inodes were allocated in them and freed again. Steve From owner-linux-xfs@oss.sgi.com Wed Mar 26 18:58:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 18:58:40 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2R2vqq9017704 for ; Wed, 26 Mar 2003 18:58:33 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2R2vknH023727 for ; Wed, 26 Mar 2003 18:57:46 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2R2uR7L3779324 for ; Thu, 27 Mar 2003 13:56:27 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2R2uQd03687117 for linux-xfs@oss.sgi.com; Thu, 27 Mar 2003 13:56:26 +1100 (EST) Date: Thu, 27 Mar 2003 13:56:26 +1100 (EST) From: Nathan Scott Message-Id: <200303270256.h2R2uQd03687117@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix gcc warning X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3386 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 639 Lines: 29 Cut and paste stuff up on my part in the DMAPI headers. Date: Wed Mar 19 16:17:42 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf Undoes mod: 2.4.x-xfs:slinx:142163a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:142170a linux/fs/xfs/xfs_dmapi.h - 1.37 Fix compiler warning when DMAPI is switched on. Date: Wed Mar 26 18:55:26 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:142795a linux/fs/xfs/xfs_dmapi.h - 1.38 From owner-linux-xfs@oss.sgi.com Wed Mar 26 19:09:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 19:09:29 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2R38hq9018214 for ; Wed, 26 Mar 2003 19:09:23 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2R38auY031400 for ; Wed, 26 Mar 2003 19:08:37 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2R37J7L3833576 for ; Thu, 27 Mar 2003 14:07:19 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2R37IjV3840924 for linux-xfs@oss.sgi.com; Thu, 27 Mar 2003 14:07:18 +1100 (EST) Date: Thu, 27 Mar 2003 14:07:18 +1100 (EST) From: Nathan Scott Message-Id: <200303270307.h2R37IjV3840924@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix setresblks X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3387 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 381 Lines: 16 Fix definition of setresblks - nothing uses it in anger yet, but Dean tells me that DMF will (so fix it now before its needed). cheers. Date: Wed Mar 26 19:05:30 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:142797a linux/fs/xfs/xfs_fs.h - 1.8 From owner-linux-xfs@oss.sgi.com Wed Mar 26 19:22:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 19:22:41 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2R3MVq9018784 for ; Wed, 26 Mar 2003 19:22:31 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2R3MVd5018782 for linux-xfs@oss.sgi.com; Wed, 26 Mar 2003 19:22:31 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2R3MSqB018769 for ; Wed, 26 Mar 2003 19:22:28 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2R2eVjF017626; Wed, 26 Mar 2003 18:40:31 -0800 Date: Wed, 26 Mar 2003 18:40:31 -0800 Message-Id: <200303270240.h2R2eVjF017626@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3388 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 506 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From kaos@sgi.com 2003-03-26 18:40 ------- KDB note: if you are using kdb on uni-processors then you will hit a kernel bug where it does not correctly set scheduler flags. Fetch and apply ftp://oss.sgi.com/projects/kdb/download/v4.0/sched-bug-2.4.20.bz2 Patch is against 2.4.20, it fits 2.4.21-pre5. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 26 20:18:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 20:18:55 -0800 (PST) Received: from adsl.proware.com.tw (IDENT:EeduKM0YweEVyruXsmVz1ArdB7yqAAIa@[211.20.79.38]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2R4Ikq9019519 for ; Wed, 26 Mar 2003 20:18:47 -0800 Received: from proware.proware.com.tw (IDENT:W5LXiifNuQr3BlJ1u+g9J3ZBOynBRKXo@localhost [127.0.0.1]) by adsl.proware.com.tw (8.12.3/8.12.3) with ESMTP id h2R4NATP025294 for ; Thu, 27 Mar 2003 12:23:10 +0800 Received: from Rocky (199-rocky_lee_desktop [192.168.10.199]) by proware.proware.com.tw (8.12.3/8.12.3) with SMTP id h2R4rfY7023769 for ; Thu, 27 Mar 2003 12:53:42 +0800 Message-ID: <002401c2f418$163e4f90$c70aa8c0@RD.proware.com.tw> From: "Rocky Lee" To: Subject: kernel patch fail with LVM Date: Thu, 27 Mar 2003 12:19:40 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3389 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: rocky_lee@proware.com.tw Precedence: bulk X-list: linux-xfs Content-Length: 665 Lines: 29 hi all I patch the LVM 1.0.7 (1.0.6) patch file and XFS patch file for kernel 2.4.19 , but fail when I ddid "make bzImage" Error Message------------------------------------------------------------ fs/fs.o: In function `fsync_dev_lockfs': fs/fs.o(.text+0x32cd): undefined reference to `DQUOT_SYNC' make[1]: *** [kallsyms] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4.19' ---------------------------------------------------------------------------- -- if I only "make bzImage" with LVM patch, OK if I only "make bzImage" with XFS patch, OK if I make with LVM and XFS patch..... fail... does anyone know this condition? Have a nice day ^_^ Rocky From owner-linux-xfs@oss.sgi.com Wed Mar 26 20:33:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 20:34:10 -0800 (PST) Received: from mail.asylumwear.com (evrtwa1-ar10-4-61-238-254.evrtwa1.dsl-verizon.net [4.61.238.254]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2R4Xwq9020073 for ; Wed, 26 Mar 2003 20:33:59 -0800 Received: (qmail 31914 invoked from network); 27 Mar 2003 04:33:57 -0000 Received: from menion.home (10.0.0.3) by 10.0.0.1 with SMTP; 27 Mar 2003 04:33:57 -0000 Subject: 2.4.20 CVS From: Joshua Schmidlkofer To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-PHmzWoyN6CmOZhml4IIY" Organization: Message-Id: <1048739644.12402.5.camel@menion.home> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 26 Mar 2003 20:34:04 -0800 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3390 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: menion@asylumwear.com Precedence: bulk X-list: linux-xfs Content-Length: 1038 Lines: 36 --=-PHmzWoyN6CmOZhml4IIY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hey there all, Formerly the CVS tree contained the most recent pre- style patches, but this behaviour ceased. I am happy the way it is, but I wanted to know if it is safe to use. I like the 2.4.20 kernel - because of the Intel driver inclusion, but I want to make sure that it is not a foolish mistake to use the cvs tree. [for 2.4] thanks, Joshua p.s. I am using the linux-2.4-xfs tree.=20=20=20 --=20 VB programmers ask why no one takes them seriously,=20 it's somewhat akin to a McDonalds manager asking employees=20 why they don't take their 'career' seriously. --=-PHmzWoyN6CmOZhml4IIY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA+gn88cweM6t71VHsRAh5gAJ9SHxYk4bTc6JBliqnPR77e7PYnTgCgsPVy /qVV9kX3SrNxIzsYlQ8EnZY= =Im0a -----END PGP SIGNATURE----- --=-PHmzWoyN6CmOZhml4IIY-- From owner-linux-xfs@oss.sgi.com Wed Mar 26 21:20:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 21:20:50 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2R5Kjq9020757 for ; Wed, 26 Mar 2003 21:20:46 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id CC8D8184AAE2; Wed, 26 Mar 2003 21:20:44 -0800 (PST) Date: Wed, 26 Mar 2003 21:20:44 -0800 From: Chris Wedgwood To: Steve Lord Cc: Walt H , Mark Grimes , Eric Sandeen , "'linux-xfs@oss.sgi.com'" Subject: Re: XFS holding onto disk memory Message-ID: <20030327052044.GA20857@f00f.org> References: <057889C7F1E5D61193620002A537E8690AD0AA@NCBDC> <1048706978.23087.83.camel@jen.americas.sgi.com> <3E825CA5.6010007@comcast.net> <1048731703.1119.15.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1048731703.1119.15.camel@laptop.americas.sgi.com> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3391 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 628 Lines: 27 On Wed, Mar 26, 2003 at 08:21:43PM -0600, Steve Lord wrote: > It would yes, but we are not currently planning on offering > facilities to clean up existing filesystems. Over time inode > clusters would be freed, but only as inodes were allocated in them > and freed again. Surely getting the fs to clean up after itself wouldn't be to hard? Something like: foreach ag ; create dir do 100k times create file dir/foo foreach ag ; do 100k times remove file dir/foo rmdir dir would suffice? --cw From owner-linux-xfs@oss.sgi.com Wed Mar 26 22:23:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 22:23:38 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2R6Mmq9021946 for ; Wed, 26 Mar 2003 22:23:29 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2R6YTkq005503 for ; Thu, 27 Mar 2003 00:34:30 -0600 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA18446; Thu, 27 Mar 2003 17:21:24 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id RAA28313; Thu, 27 Mar 2003 17:21:23 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2R6IH9V009773; Thu, 27 Mar 2003 17:18:17 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2R6IFMR009771; Thu, 27 Mar 2003 17:18:15 +1100 Date: Thu, 27 Mar 2003 17:18:15 +1100 From: Nathan Scott To: Rocky Lee Cc: linux-xfs@oss.sgi.com Subject: Re: kernel patch fail with LVM Message-ID: <20030327061815.GG5658@frodo> References: <002401c2f418$163e4f90$c70aa8c0@RD.proware.com.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002401c2f418$163e4f90$c70aa8c0@RD.proware.com.tw> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3392 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1232 Lines: 40 On Thu, Mar 27, 2003 at 12:19:40PM +0800, Rocky Lee wrote: > hi all > > I patch the LVM 1.0.7 (1.0.6) patch file and XFS patch file for kernel > 2.4.19 > , but fail when I ddid "make bzImage" > > Error Message------------------------------------------------------------ > > fs/fs.o: In function `fsync_dev_lockfs': > fs/fs.o(.text+0x32cd): undefined reference to `DQUOT_SYNC' > make[1]: *** [kallsyms] Error 1 > make[1]: Leaving directory `/usr/src/linux-2.4.19' > > ---------------------------------------------------------------------------- > -- > > if I only "make bzImage" with LVM patch, OK > if I only "make bzImage" with XFS patch, OK > if I make with LVM and XFS patch..... fail... > > does anyone know this condition? > We have Jan Kara's 32 bit quota patches in our tree, because we make use of some quota extensions they provide. The LVM patch most likely is just for a stock-standard 2.4.20, which does not have these patches. So, Jan's patches contain a change which removes DQUOT_SYNC and instead splits the functionality into a DQUOT_SYNC_DEV and a DQUOT_SYNC_SB - you'll need to change the code (looks like fsync_dev_lockfs needs this change) to make use of one of these new macros. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Mar 26 23:33:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Mar 2003 23:33:59 -0800 (PST) Received: from adsl.proware.com.tw (IDENT:MmcaRiaB4aopimVu9aJH2RqaM26Jjr7i@[211.20.79.38]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2R7Xmq9023322 for ; Wed, 26 Mar 2003 23:33:50 -0800 Received: from proware.proware.com.tw (IDENT:AzJRaTqHYP/aoZUL4SQrdQnPd1KPPg9n@localhost [127.0.0.1]) by adsl.proware.com.tw (8.12.3/8.12.3) with ESMTP id h2R7cDTP026841; Thu, 27 Mar 2003 15:38:13 +0800 Received: from Rocky (199-rocky_lee_desktop [192.168.10.199]) by proware.proware.com.tw (8.12.3/8.12.3) with SMTP id h2R88gY7026298; Thu, 27 Mar 2003 16:08:45 +0800 Message-ID: <006d01c2f433$545bffa0$c70aa8c0@RD.proware.com.tw> From: "Rocky Lee" To: "Nathan Scott" Cc: References: <002401c2f418$163e4f90$c70aa8c0@RD.proware.com.tw> <20030327061815.GG5658@frodo> Subject: Re: kernel patch fail with LVM Date: Thu, 27 Mar 2003 15:34:39 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3393 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: rocky_lee@proware.com.tw Precedence: bulk X-list: linux-xfs Content-Length: 1031 Lines: 39 Hi Nathan Thank you for the respone! .... :) Did you mean that I've to change the LVM patch? it sound a big trouble to me (beginner)... but I'll try.... : P I've also found the new 2.4.20 patch. (Mar. 18) is that the release stable patch file? Have a nice day ^_^ Rocky ----- Original Message ----- From: "Nathan Scott" To: "Rocky Lee" Cc: Sent: Thursday, March 27, 2003 2:18 PM Subject: Re: kernel patch fail with LVM > > We have Jan Kara's 32 bit quota patches in our tree, because > we make use of some quota extensions they provide. The LVM > patch most likely is just for a stock-standard 2.4.20, which > does not have these patches. > > So, Jan's patches contain a change which removes DQUOT_SYNC > and instead splits the functionality into a DQUOT_SYNC_DEV > and a DQUOT_SYNC_SB - you'll need to change the code (looks > like fsync_dev_lockfs needs this change) to make use of one > of these new macros. > > cheers. > > -- > Nathan > > From owner-linux-xfs@oss.sgi.com Thu Mar 27 01:22:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Mar 2003 01:22:41 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2R9MWq9008550 for ; Thu, 27 Mar 2003 01:22:32 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2R9MWFk008548 for linux-xfs@oss.sgi.com; Thu, 27 Mar 2003 01:22:32 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2R9MUqB008535 for ; Thu, 27 Mar 2003 01:22:30 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2R8wLgN029115; Thu, 27 Mar 2003 00:58:21 -0800 Date: Thu, 27 Mar 2003 00:58:21 -0800 Message-Id: <200303270858.h2R8wLgN029115@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3394 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 444 Lines: 16 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From christian.guggenberger@physik.uni-regensburg.de 2003-03-27 00:58 ------- Yes it's an UP System here, but I don't run in those kdb probs as Anton does. Maybe because I'm using an SMP Kernel? But, I'll try Keith's schedule patch anyway. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 27 02:33:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Mar 2003 02:33:49 -0800 (PST) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2RAWuq9013130 for ; Thu, 27 Mar 2003 02:33:37 -0800 Received: from rss1.rz.uni-regensburg.de (rss1.rz.uni-regensburg.de [132.199.1.200]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with SMTP id h2RAWsQ7030196 for ; Thu, 27 Mar 2003 11:32:55 +0100 Received: (qmail 16318 invoked from network); 27 Mar 2003 11:32:54 +0100 Received: from pc9391.physik.uni-regensburg.de (HELO pc9391) (guc28561@132.199.98.219) by rss1.rz.uni-regensburg.de with SMTP; 27 Mar 2003 11:32:54 +0100 Date: Thu, 27 Mar 2003 11:32:54 +0100 From: Christian Guggenberger To: kaos@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: [Bug 230] umount hangs after high disk load Message-ID: <20030327113254.A13601@pc9391.uni-regensburg.de> References: <200303270240.h2R2eVjF017626@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <200303270240.h2R2eVjF017626@oss.sgi.com>; from bugzilla-daemon@oss.sgi.com on Thu, Mar 27, 2003 at 03:40:31 +0100 X-Mailer: Balsa 1.2.4 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3395 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: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 540 Lines: 19 On 27.03.2003 03:40 bugzilla-daemon@oss.sgi.com wrote: > http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 > > > > > > ------- Additional Comments From kaos@sgi.com 2003-03-26 18:40 ------- > KDB note: if you are using kdb on uni-processors then you will hit a kernel > bug > where it does not correctly set scheduler flags. Fetch and apply > > ftp://oss.sgi.com/projects/kdb/download/v4.0/sched-bug-2.4.20.bz2 > > Patch is against 2.4.20, it fits 2.4.21-pre5. sorry, but it can't be downloaded - permission denied... Christian From owner-linux-xfs@oss.sgi.com Thu Mar 27 03:28:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Mar 2003 03:28:35 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2RBRiq9016787 for ; Thu, 27 Mar 2003 03:28:25 -0800 Received: (qmail 32551 invoked from network); 27 Mar 2003 11:27:41 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 27 Mar 2003 11:27:41 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 3D7DD3000B8; Thu, 27 Mar 2003 22:27:40 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 202588F; Thu, 27 Mar 2003 22:27:40 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Christian Guggenberger Cc: linux-xfs@oss.sgi.com Subject: Re: [Bug 230] umount hangs after high disk load In-reply-to: Your message of "Thu, 27 Mar 2003 11:32:54 BST." <20030327113254.A13601@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Mar 2003 22:27:34 +1100 Message-ID: <14245.1048764454@ocs3.intra.ocs.com.au> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3396 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: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 529 Lines: 15 On Thu, 27 Mar 2003 11:32:54 +0100, Christian Guggenberger wrote: >On 27.03.2003 03:40 bugzilla-daemon@oss.sgi.com wrote: >> KDB note: if you are using kdb on uni-processors then you will hit a kernel >> bug >> where it does not correctly set scheduler flags. Fetch and apply >> >> ftp://oss.sgi.com/projects/kdb/download/v4.0/sched-bug-2.4.20.bz2 >> >> Patch is against 2.4.20, it fits 2.4.21-pre5. > >sorry, but it can't be downloaded - permission denied... Fixed now. From owner-linux-xfs@oss.sgi.com Thu Mar 27 04:09:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Mar 2003 04:09:17 -0800 (PST) Received: from redix.it (host49-169.pool8172.interbusiness.it [81.72.169.49]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2RC8Pq9018136 for ; Thu, 27 Mar 2003 04:08:42 -0800 Received: (qmail 976 invoked by uid 507); 27 Mar 2003 12:08:23 -0000 Received: from roberto@redix.it by mail.redix.it by uid 504 with qmail-scanner-1.14 (clamscan: 0.24. Clear:. Processed in 1.608848 secs); 27 Mar 2003 12:08:23 -0000 Received: from localhost (HELO redix.it) (127.0.0.1) by 0 with SMTP; 27 Mar 2003 12:08:20 -0000 Received: from 212.239.118.101 (proxying for unknown) (SquirrelMail authenticated user roberto) by mail.redix.it with HTTP; Thu, 27 Mar 2003 13:08:20 +0100 (CET) Message-ID: <2339.212.239.118.101.1048766900.squirrel@mail.redix.it> Date: Thu, 27 Mar 2003 13:08:20 +0100 (CET) Subject: Re: kernel patch fail with LVM From: To: In-Reply-To: <006d01c2f433$545bffa0$c70aa8c0@RD.proware.com.tw> References: <002401c2f418$163e4f90$c70aa8c0@RD.proware.com.tw> <20030327061815.GG5658@frodo> <006d01c2f433$545bffa0$c70aa8c0@RD.proware.com.tw> X-Priority: 3 Importance: Normal Cc: , X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_20030327130820_88439" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3397 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: roberto@redix.it Precedence: bulk X-list: linux-xfs Content-Length: 94722 Lines: 1606 ------=_20030327130820_88439 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I discover the following: LVM 1.0.7 patch: modifies file fs/buffer.c: add function int fsync_dev_lockfs(kdev_t dev) the function use macro DQUOT_SYNC(dev); XFS 1.2 patch: modifies file fs/buffer.c: modifies function int fsync_super(struct super_block *sb) from DQUOT_SYNC(dev) --> to DQUOT_SYNC_SB(sb); modifies function int fsync_dev(kdev_t dev) from DQUOT_SYNC(dev) --> DQUOT_SYNC_DEV(dev); unmodified function int fsync_dev_lockfs(kdev_t dev) (becouse is not know to xfs patch) still use DQUOT_SYNC(dev); I've tried to change file fs/buffer.c: from DQUOT_SYNC(dev) --> to DQUOT_SYNC_DEV(dev); I used *_DEV becouse it is called on kdev_t variable (but really I do not known nothing about these function) The compile was successfull, but is there anybody that can test it work? I'll wait for comments... Bye Roberto > Hi Nathan > > Thank you for the respone! .... :) > > Did you mean that I've to change the LVM patch? > it sound a big trouble to me (beginner)... but I'll try.... : P > > I've also found the new 2.4.20 patch. (Mar. 18) > is that the release stable patch file? > > Have a nice day ^_^ > > Rocky > > ----- Original Message ----- > From: "Nathan Scott" > To: "Rocky Lee" > Cc: > Sent: Thursday, March 27, 2003 2:18 PM > Subject: Re: kernel patch fail with LVM >> >> We have Jan Kara's 32 bit quota patches in our tree, because >> we make use of some quota extensions they provide. The LVM >> patch most likely is just for a stock-standard 2.4.20, which >> does not have these patches. >> >> So, Jan's patches contain a change which removes DQUOT_SYNC >> and instead splits the functionality into a DQUOT_SYNC_DEV >> and a DQUOT_SYNC_SB - you'll need to change the code (looks >> like fsync_dev_lockfs needs this change) to make use of one >> of these new macros. >> >> cheers. >> >> -- >> Nathan >> >> ------=_20030327130820_88439 Content-Type: application/octet-stream; name="buffer-orig-2419.c.gz" Content-Disposition: attachment; filename="buffer-orig-2419.c.gz" Content-Transfer-Encoding: base64 H4sICGbogj4AA2J1ZmZlci1vcmlnLTI0MTkuYwDsXHtz20aS/5v6FKNclU3K JC3JlVTZsrUnW7Stiyx79Yhv1+tDgcRQxAoEGAwgmpvou1//umfwIAEp3ru6 qru6VCKS8+jp6el3z+TpzpbaUSoK4/zb06l5Os6nU50OJ9TKHW+SxSoNr2eZ 6r7pqb3nz/f6+Luv1ClNMeoySW/9KDA0+OnW1lOZ9NhBeazC+SLScx1nRmUz raRjMPEn9GOax5MsTGIzVOf+RA8mSRyE3KBm/q0GqLHWsfJvkzDQgRqv1Nno l9G5inSWhfG18mMVxplO03yRqcnMj6+18u0aqqu/TTS1T5MUSwNa4Gd+XyVT NUny1Ohen8ZmBMJk2g8KqMBz4kcRwQgSFWZDtzd1kflppsbBNMrNrNtTyzCb qRudxjryslkKIHGSKbMymK8G6pOfR+pdkmZzn4YR5fafPv/RQTvX8+SWtuWr iCYRVnkc64k2xk9XhGFAe4kDZUDBcBrSwGxG6BlaYklf/Qw7KmmqhKahiR8T sDxVizScMyRuH6ijOEj1Ul2mYXCtCTvg8lO5tYWmFfIFUd7M+ipK8z4vP021 Ju4wBHOhU98el7oyWl1PF0QDkJc2m0x8EA84AYLK/HGk+yqncRenR68tFhhs 0Z0RtQjS4JhO+kOBxlGAg362f+OGjQnyDRHhH9rQHmi7BNBPtUr1r3mY0tgk CmjY0fkHkD3Tc4PjoqHnH34uoF7K2dBRDt2Krss3q3jiFuNzpV0wiz8Xivnq KJ2As6JQvfS55V8NbWsY6EMG8i9hPIlyOq2XIkTExdPwejg73OgxRIKgqWNq GodH/ripHRRpnECCECeNkJb+oq19kkWNXfOFh4Wa+m7nfOBNXePoJtC3jQBX Jv21cfNhpJvaw5jOq6H91zzJ/GTRSIEwoZNs6piRCpvreVPXPAnyZgwmCZQX WL6tl1BP0Vfp9M38ae5PIMf1WegIk822cZht7Abt83nuES9l+lsmSwR6GsZa nZ1756OL0fkvo2PV3dvd+XD0797rq7fep9G59+no3ahXjETP1dnVxegYA96O zi+qk5/s7yoSgCCBwtC3EEkSDDVPSLpIvcRQN0ZtdfCPwj9xPh/TKFZUJABB TZILAY6zcBBQC8ttkpJwkkC9IFHskE7xoEmYr9Qh6wmP9YRrEbjlIBFgt53X 773R2eX5X7ro77FS8siwpKuutPSVydJ8klm8POBFGt4LY9KlnjSanjNS7wst pa6T5GYoWt5kpMYmhIgJr2PaIpkXNZ55jOrcNzcH944g5THNiiGb2KidnXLT xbh0ib162QZBXqnzz97pxzc/0yniY3R8sHUfcEfgL3TKpycXl18rwxdhzKuw HiYG1rRe7UDKHlr3t4tPJ2f1pe8OioOoH2QbmCGfoEMAZIpTdwpetlroCprr RI0SssNQ+m0T7iNDlY0O1ta3XZXx5mCDRtkGIxJJNilSTDwevTk9Oh95n49O Lr0/X42uRt770dFx166y9MOsd1CjxHWaLN3WutCYtCb97a9RgI1fn2eAGL3a bhJYroI+QLVrqcFoCy3KKfChlOelGvrWTus2kQ+oss0k6ad/RdJXyiRzWN7J LMz0JMtTssdZorTJyMvIqOfWDyOWJlKzSboaQpr8LJmHE88tQD3ewr+mma/U 0eXHDydvvJOzk8vurl3yvU7hwLBTs/BTf66zwgOwXpxzvsi7SVjFqpOpWiW5 8gNyBVIIdspuFTkvK6iqGizTV3DElMmh4xJydwLgLh4cLBSMIVxfdn0wNUgm ObxXdnyUn1lH+bjabCeSWRxm35y3WGhr0snnRx/Uc0tUApnP5ytFTnNOhAit mpWDAFpwbiI9zaQLFMHWYWxosXEYhdkKCLLrSb4PCHFN2zPsEqpF5K+kD9g/ BZUUdGSojSCWx9iIpaLHlFG/bXUsI9C3DkvKNPUn2UGHUP6k0wl2Sq41kbPm awZhmq1Axy1rI2hOeAuKulOiBS1AHssAP/jfwnk+r5gTgcPnzEy1TInHyIel 7ejUwV7SwQ0mqwlxWAGVSbnPUEGKH2Lm7uiHtRHPeIQ1WkUXRw50DNz593BK LrYhIQQBxzpbIvC4sQzCm9GmnEvUsCLEsy/DuRxTnKTkGzkq0VZAtrGewqYu LRxyQyt0YUJ7EOWD/yqxAWSWJnGSm2i1uQR5GZ4deqDcWhnHTK1rYdLmYTJR f1wn6h2Z2jw+2OrUTCNCri9WCEhv3wGat0jnMDK/Pdvtqx936Y/8++PO+7/2 1bNd/viJGvbRfnfnFJLz/cHacxIPCOnc/1bRFVaqWBSI3ktiBg5OltjMmGYb ixohzIbbygFBK5AEZgroKAp1lXzjP/xlj5FTFuNdwq0Gx/9Wg7NHm6MN7vJe Kh97+MuQat/sH0DdYn2di0G6R1uPZ70tkloSC5+sa5h1yUv6TAbHO/nYV4/G s8Hh2IMFgPGojzr18zhAULo+ivyjDmmYzzOE3goIlL4eqarb0ITQ80RRHMTJ 04+KZIb6Spg8H1pNZ0MxJHPtU1RvJUF2hVCbzmieU2zJiFUA9BnCfEzxJdRu tJj5TiXHlcFsHU1CYqcQ4DH/xrSq5uklOCDCgGK7drmhAmoamhvsyfmuQ8Ag tkYgNB97nj8lBvNKCm7Sk7FZJ+Z908Op6sI5+DXXufZYnnXXAmCnoUcCB73n 5YtaO8mRc2PPkkwLv+MwiAqRwhAviR3X9HASnClh584lXWQSSTspXckkWBjl STtKyakhpSHpkdAw1XlGNWcREAm32P9aRPn1NQYHiTacE0kmkzwVE2Q9kTU0 Gz05y922LyMH3LPfdzIDr4yApqQwiZhVJ4x9MCZtX9E4uBeda51541mXINJg 8hZkfSZ9lbZ0gpbEnSBhe5jmsccr27HZrx42ihEd4ivPYkXn3aW1+ury6AI+ 4snZ5ej8/OrT5cnr0xEPxnFv2/0JaYENzrgzpoO7YYBIEVA4yvxxp5YzctZU d3MS9dJig0Nel+jAi55fndGy76hPfKCHt7jIS6IULHWsp34eZVV7Qj5EMEim g5OPFKTEAaLeoVL/BtGd++kNTFq+GGTJgM0ljRA2YM+t5Klh4VQuwTpR5KXk BfMgsiIw/UmFQ2hJ56eHCVvIFgUoDnK+yBKszgwDpNxk19HFyGIU26mqchXG aCTIZbEDSUxKVhJrkHRApMUUyfE4uph8PA9FogJfEmOSvyPKVUNN3it7PPZ8 i7igMX7009Rf9evh5yTJ44z3bVm2RZaIT2T+kyfgNeEIkDlMqGuT3syQvA3Q 5PP5yeWor4ROBWsOBrJ6hVyf2X3jeMFRbZomcyYF42LdcvEymD2HNt0stgLk G9scbFB6s6fnV0xjAhIFkp2EgRefn3znmIfCbQyzbSZxmTK5+MvZG9V9tt+r RlBCdSDaEItVFU+NkLH+Bn3T1MXE/SKrfV33hJhO0PociUIlARIRvgjbkcU5 Pjm//Avmxil1rUfMtREMkAbt0nd7Ggzx0SM1GND0Q+rqPcAPdjMOFWEJ/PCQ +AWSrLaIHgAr3fix/UpoRLoLOSoKirRTcRnFhB4djgfl2G4bG+fagJFnCrIs XqzyeCed9QhW2LFTV++djpwEU+jJk6+8M27HIkK3l5YrGI8KIviJTIAn6qH7 qJbeEOiN4mol04kDDbNcORgdvTs6OUPTHf3XpHZatkXD70Vlq9wPuwp/BC2L 1O6GwEJwULVwMssugpNSrDpsUVvOpWoToiDZsiRtIahl3gZxBIiaaiG7JRUH 56ZYLCnQpVixQPOf0CUSVNP+K7oEdi3VxIEU49R2z9oDxpVwaczjSIAZ6G/y VQ63VaU4MWxXDQyrVS0Uvd+vBr5HCzQ4LyKU6HRb7NwjpFVxv/su1bK1LuEP iGjduVRuVtW8N8jnQ/JWF54mXmiVhPtYwlnte0SksLcbXGdhM1wLs0HM1RuI djVjKAwOcNuvdjmVF0tazMUBXMJ0/nvFyJIeCaOKphAtYD0jWzJhN+gCLluP /KSVnSoF3WliQ/jqPDLToSHX90BNTTmNFi6Lr+/IcSNXZEU+5jwG+KqD0SVD M/cXhpUDiGCLgT2saRbER36sJTFikxsz6tXRrTaF18A1EPLEIwMPD9GLaA0u KH622QRyjDnhSYCWPh0jEY6YyhYmkZOgWBP5iEyqplJhnkpmEoVbiniNRhqV KWg9IYwU1G0qTHYle+fsb+XgNpiKnXnwEX7oNBWXAHG8+hgj+2mMTU4NbEg0 Q1EXTfj9goNlUhHLmhlgTPrr8bI54NF7PZ7qir/OSDSM3P8uuPsVuGX1Deln NONI3Iru4JHFjavxeotNgkqphNyiuIRYbcLLBC48rr7aFc1yL3wG+fsfgCkl hD5RUvSOFS6azhKLo2RJ8Ey+KKNj/mFDph0z5lMv2YH2YsYUE0KNwkOtMg0v zIn2DrsfkvPmMJPHcZHMeGbcJbAIp/989fHSg4PktsbTLDZjR0u7Hp0plLj8 ShbV74NDa9cxE1q9scOCtL5RQ1OJb0Grzf3t9daIFycW1rpf30ia7wBMrX8M 5r3kdqTdJHZ59MWgf4IQRfia6sfGZsng4PgGbhNpLgKgEUaRUiIVGLETxGqQ TJIfrzhgJYkFZB1n0aqMztuoUJJH0CYsfDOPwvgGSW2p662MhPMAtDZpt8F2 oXZMKn3BJoF8ubOr01NFzGd9utvQl4ww3+Qgjeqr27kvulPJkcEVmVYzCGhR OwBaFI0DLiWrHfnsF8lrTKs6bnxySG/y5ys7b3AYyJmWkWFNVkkcDqqiap09 2mkTi5Dm5s1gW7IO0tdW45VKTgrbZFW6/M0xXHU2IyE4rIEwY0Ke5w0OQ4/R u0fC/1tlmlEcDmH06QhXJbYVpY4UG+Mpeq1AVGhHdIOya+T7TUFxDMXUbmFI YY9awD4NqucuLMMf5Rk7prFfDpq5pDzsvih4t4HB6PXR8VvqZuCv1JR83C4t a0m/7Tzq64QoQgYUM+2SrxiTweHUK5Zu5chyuZOzX45Oq9ABgM72999V5Sf9 Za5nG/kUlYDVnxQ8IM6uZ3CD2DnEDHK6vKmTEykROWw9coymbN34wGl+jDtm rHcSFJGVf+3j8h2Z+tgmcsVZSJEk48NPlnH3Ucmlet4rTn9j9W4xjprJl77G WDHxG3vroqWvnLDvOpJjODH6Ni3RkwgBmTGcWQVSsSqsfOOqD4BCOn9tU1uO YOSOTemTEaR2an7xxxi4IMP/M3GViTcZ8n+Orfb+d7EVrm+hTEURCvkA5CnM cE2WgxQdhCgD+KSwVwb1n4xvc6K0ChcBN5fgOxTFpWWCEO044drPXBvj8inl DcxahpbvT01j1uJsrnqdv211uvQP3IiXL7u1K1ZqoH7q9dR/qNbu5z3uJxg0 pisQ74EiA9Thodp75uaVzS9fqo2Ze/u0QnnVDn0V5CtXub503d7eH128Px79 wii7cY9qt8t6XytZBa7W2VoZaUmdZvSRJTK6et2nqR7cfPcMH6/UI0a2SLj0 be6FMYrTXktu2+aGGAhkyEHjxKpAWJA/CWMtQzplGqlMMYGDuWX7FftxPZt1 qk5/VE6s5llABb645jmqMCVyNN58Ny3cYhXMLXr8vT1htpEjc7lrfOes1fp+ HPBOsaibVicb6MHmstxzw/G71FBbwVQ81zHfiGzd/Xi2AKGL9CIP/+oSyhYt worzf1CsaynBHsWw77o2A93dBjyhmIUs2fZ1OLb9rsoargcTS0aqTOky8For jWtoXYfIazWMc13rSVShAZfGNm8eSqd64g4eIw42D8rWXVHuevCg7i0wNWVh Sy5rZc46U1fo1SmYouiW65FIitK4deJVM8Lr1HPsDHTWOEi9AvRKVlj2wo2c GbZ7s6ze6WzML1a+KxioipebuMknrqf5WAcDThq3neugfq4ig2QOm8oH48TW ENav67o7g7Xk7ZZSXGNYL53UeYWLoM0VX8sodW0nCewWfnPF6+py37fYvcWa osjUfbRGgU2c7FKCbjVz1jC380DynXfUIEmoC5TANrKj63do26QOmpPMQmEf xTIWhTbcL2rdNflWSaq6BwfC+VJpXzgZ2bbMX1zyWKwbuU5F7VozDAMpqzfV SUtmxTjZV+uwe+q19ZqKQ/DO7bf1rArXEZr0zl5Wc5cHnLFCckIun7TRux5n 8MeD/Ffuy44nJYL+gGL9R5WO4sJ/YVVcaOHCGZ7mB0HjtL4qXWlOWVfhPcSn reSAd/9/iSa8n+8gjL0CbV/XsXbl8k9VbUpdduPSmVZQpVa5VJir+oqwVck+ zIxM4zpNrEV5iJJ3jT779y3ccICNuDvVLrVEtJNorl8Y2mCdItPYuZ+NJJbc loc180W26rbJAMfa94z7Lr7oNAWiJ1Pax60fhbitVeywJ0W4LMXjnVqtrI9a vdwy5ZtHNyFK+grB69SoScJvRBGZhkZdJ2ApRKiXACQ5bsAC2sqPlv7K8MNV lLQMv2pUhM0Ul7vLq5NL3yC9ukiMJLXITfg7X/zKEn6XaC8mzCheJi6WO7IA NObiI268pcMtNFzOctOwWVQTr3XMgXhukOsJ5SolicQyWcqiTAkAqRcO1Vuy R/qbjwqaCpNJFnXfnl68Pv359dXbHnUs9CQz1U1nCaOGixSaELvlAq7cuHbo 4Oa1EaqYm3Cx4MIoC+VnTTiZhJuL4ctZiCInJnHGkHaDV5Oqhhq/fZj4MXtJ PsGMkdj3mThm4U+0e96AvcMkOV0gKW0yaeFECxXPPl6OXqiT2NauCfElv55w tLYSiee2/A3WbDDXQegPONesb3lxgMpswUQQr1BJHvfGEzlentYNcnlzfG0f bFikVJCGt3LgKOtiEFf3ktQVfYEUXiBzmZtmkfQmK7e/2nGiPjOR8oyyLJHp Kk8z9S3DsYfN+1JienSAbA2SN5WL8qEBrPLqLrGSXOx0RyLVbK6rJGBqf0oE 9VeK2F2uf3ezdGVFI5M0j0VIsBFUlkIkh0h5/4bJOdbIXvKWE0t3fseBOrkF RnP4su1QHQGqewVE22DAvIpPuoNkhItVFh28247l9SF+2js8tanyTImfGyWO +uvld5HO4tnBklicJCf0IyYQidmZvPew4smy0cgCtERoDHOKVKlqrNJ1NxBc kRt36svyd0+uJym5p843uTd0BefjWS3hxgZedDboSNkQ5I/PWm444L3HJAHH x5PK0yF5yKvwXEvGoPGxvId5zNtnpWjkLixZmDQJ8gnUxknGikrrQFRUqgf8 +prvgDLp8TSLDEKseVfubrAIsB3Npf5iQmjkhHK+Io+750spRvD7fKImKpMK Ah+jxydSkwmIk3ES8Anz/xqgUB28nmxKXgfgtTxIzjdKCQbDYkmIb6w0EhLw m1GukBeyqcZDnXWrEK+vMLQs5J6aUSi8JzcycH24+v9EYCl3BRIZLVnWcuY+ gPFkvpaDTn+S5cSAhP2wKM1W2QM1Ved3cFXMstzOuAiQLO+vWXjnN4R9FctF FhPpRdvFV8474a8LaGqXErLEk99drEpeTuBxcRhVIbbnYz3hyzwYjts+cATS 1QtaC2vaK673eS50CN3YZjd2DwRjvuHJ70Vtw5MnlfCsSDzENvVVj9WqQRLH dmHDtTs7VYXqUO2qA7lRa2lAtB0MbCLENrXcrOvwq+kERscqhD9JHa09hKuh h/lnibwe1kF17nYlv9gwj8G33Ohbv0/74JXYtRt3lYn2CPcqcNqh1C/ocSTa eSjlIBSs3Amyhovg25tV0N4oo7jnf7XbjNJRPMXo2MxmnUAsHOWYRUqycdP9 oRS1FzVV+7f4hxLEtr3VDL3mggi5juuILfcgG8SQ/ewNFOysTluA0OlI+qxz p3CZrRXjcW7qCJfEvifyF3T5WIUYZWGPl72zxaX7OaYGgyGwzNvLAe8oEknD oHzAe62tqcL5VRSc7J0fFZfKRSKfMhJHAn0jlFjPE7WrwVb9CYEOUO2sXC5D e8++o62rYdG4zctw9iVAfW5sYW1UAaAvPJgeTzyX8vbMPxJ+zb+j8AVvoiDk 10wUDsSGTCN0sjR8eff2k3f28e2FeqTw9a8fz0Yfji5+/jrEEPNl9yuHZGM/ 8snTtWzH+Tv/5j+b+/anNpJszZ/FX1HNRNuSLQH23t3YC4ZZjHGbaBu8YHdP T++EroQKqLVQqVWSaWaa/ds3v/PKzHpIonvuznZMjFE9MrPycd7nO+nCckjp kluxvqPuNDZeBLTRTbQLjatqTqESv3/vYJqPMyeA/LafXBy9O37T/+nk+P0b MigiG0AekzyrMNuJ1Msga0oXHfAhyxMn4fiS9BdMnyQ2dXm6n7kD81XTibzB 3E0voveO3h8fnpoRxVJopInAj8EZurCZ018Vu2ycdDNozHJKatOcqsAFtOj6 zDLoglaMNHA1HlwXDcx9fjv1d+goPsP/46iuk2dFB1oTv5ymmd5O8xl0Dgkf pgRi8FhqWiWZFv0yV4b0R+TUT0GrdZHOP7p7x1Cs2nhKOuQE0DTpOwH8vu9o xyy9WoxZpCS1ENr/64FhKkGYNAWUXoa0LyNkgBMEyp2cAQNgMCadiOKrnD6V zJH+DeERrgF6eeS0hFEQSz019f3OQqQRiuwOC8Wt0kuHARQRQ1MQ45LhuscH RTIeOKWJw3mR4ItOHQHiAd/M8junH0BLy93J5ezcM9GZXOc6CB2A08XdbacJ 8ojTW2SzyT1uIQy09YlvSAB2ihm91hZWtr+/Q2oKjRhfqQGyW7AO3HKioCEv ALwKb9NXYZj98cDxBsubJz0mvZwJcFg2Lzh/RcEh3LTJJ1MGqqUZ4gu3LHFX JY1+NvulGCC1tno6urzzQUTCvcwHERt5pylT0J0K256YXtmjmoKB2994Z1gg SnDb7n6H8h4iAQxXiakSRyT7Qx9cGvyBO3T/X+5R4qvOvmd9gSOx3Mrmk6Z1 t+mRD3MTNEvJbrV8juxkuc+ZgNkIf/Z7ZMQ2joJ1VdHSkH0NBDa8SYPR5ndl qehYl85xcLo/K2WxA/6Zxo17/hrbEAlnRadt9/d9pjVFllZv0w3S0gYcxZuv tiY35FcOJMGyftdF8bsXkoebFXwiLSr0aVGyE0lKPnirZkH9mGpixuTKMVgy L8DGh4NY7BJIgqQxxOcTPW1Q7Fc2zyhKM+7KUR0yV5ApjLMc+DWn2xeLYZE6 Vi8Rw/Rm5kP9GXLKUR8ONnKNdzEOBqKi0VxxRGiegCxQXJFbM4Qlu40C667q 9Zwyj1SMGRtOZAIIUkwm4E3OpwBKwR2+MkMMI2SVXffcrJizdW1a/kCAd1DS rvErtquzMkyCjFoUJJFlQCr8dc6WU979yF6kXOhpN0phmN/khb3ourKziYdp 2IuZJtu7fQdkRB51tzTDYh4owk+nQOlUkrCnnBUUWz/UAJXPsmsE4Zb2E0k6 FJyJRH/BGWRsngEZUy5Tg9cAW3SdkOHIsvJoepirc/aH2x+cATNP7tO5TxNK 1JpOmXtI6uliHgccG8zzh9Yxr8ThFtc3intIAEgMlIgZHMwvbyQPh6lpt2xF FSsboAPThYAVYjYn6V1lf9vQfRLO1TqAS0vjbijuJPLSsGwVJO5QcOVLksCB jUT2C0aTeuKe3apxRi61jBg/Cr01NMbAFhIBq/UOKMRkbx0fYqRHm35K4YlV wwJbQmocbC3KuPpH9f4Tnp3WSq9kw8w0aPC/08IB1tdqaRJqbKJVdyVnyxMQ Jj/rj1xXfERCYeXwcwY7P+tupu5JtnHKAR3jbHMigtsxlUa3kjYZju7AG3og j+q7yMcjeRojdTTPUX+guPYkaVdz9+BWEPubPA83Rz7t8K/tpbadAMFB4QFe UJq33OdkutIUN07wg9oPajdt7SLXbeKa57bIAra3scxk8gfSS/Wl8DQE2hBv fT7fveOTMwm1CGZmaeannfDG4YBiuLZrAOHopKvi5B6TiGHLNGuJfchfexkI Hkxg2fjOuiKEUrg8Z/PkjPKVkgzs7oRlgaIEQSVpjwMCYYL1674nByQlVSrg eyxBGFoMe/aFNlNmtnHKsoDzibw9Mhp+rMuOWG4kYHrSCLGqEHxkQAA4QJGz 3FDvVjaAIEDZVqeY8MokZRGtBJihTsABBh0bdmNOZL5RZYieYdrXMnvFA0NF IBtZZow4kWk8lcz0tZAB12ZUwTslXoWNtWzrwo4/TQcwBtJ15EOmg8sbittr O4mIgTyrR3hqx6nJPl0i3isBG+oJ2NIDWzqxZWK2nJaJRRNfv+fJ2lrJ5ZoC ymfwxKyIdBxIxTantO4nuICT64w82KBsW+yTnxHo9XSWDwdDdxwXk1so0SoJ XhWB2K5eQ0RQQNoinUEOLYnw0PbYednuKMTNaJZPI/3PYF68qBwA+lTMtqvi VqobMNE0kRUxisw+2pplUh/FssWxtE5LbwpzqWcYtk2p+c4aHYbhMM29RkEz a3e9KuRK9tHZl67oQaS7DcdfmLRlc4EMh6GModW6LPpTTEBGcG5I/o8B2reS DzCBif5PMjgpKuOR2wGw6HWTdpbKCUD2SpcS8cldy6mmoGq3C0cGyZ3qBJ/s MoM+Q17UDFFg+ZfCY3lgN147dWV+c2se3XS0m9zkU1j2xgTaOIeYRUfEHSNH MSFIITJDQj+0tRf/trXzcuvfX+5qM+gPrA3sLj5ZTqPJ5rvSNuAoyd3r9B8i 02ALqnQx4ACUtNmcGBU0ZIysgnDZPqFRd5Ru18e0uhVaK5Y1ijxtMB2TZ4dI bClY1ge5dhVhVt2ORAODKE+VbyLo2sr79FbFVWEOje1nSe9F0jtALrL6uom1 bRDSIu6w+cpfpMf9NU7fZwNoKUoiZoKR/0L8BuYyiY3fAkkwz51ifzOYjeSd cXYLtIQiv5qHVyiBjNZzvwai2CM0IZsIeNz9i3cnbz/BYpjP2YlM8yNrxF6T jm/02T5AIHGwS/2SIx1uHkHQ3ALc5pYgtW60ygNf9rige5HZ8C1sIF0GArT4 mk0kim+aNcA1t2WGOr54UJkXb+jUJypDgmLYNo8PmduSJ8nHt/3Ts5OzTrjj Xux5qXRnT0OSGa7lRRl9RdE3gVa6zhr/CxZz7YUJUVo34gkP5zqeHT9pJjdQ GB0HYHl6RpTTLS2FYvloEzkqOo9KJsWNfrUgXGJAdZIGGdkLFRt2cAdpligd OnLry6KHGBo5XE7uSJQD13NYsEVfdwWJKeAfBNzy1D351EetBbJE7J20NSfK KJCIdQTAdCF+6FWy42eSjCUVF6eZvA/BLK/cNDx1HwpfvuM5fUI1AXou99X1 qkCL2N1tGoHdbceYJwlVIQEGDfks2EnGAa5OiZrPx4SX9/XekqIDczl/wIFB Oy2TRmuAtU7P3hz/YGQ5TjYkkzRP7ErrNs0T+b/2DUP5ebyzA6xk7NQKLhSz BY6RgBRSZDAoW9gm48OSJyr2SEMHupHIOITi5pCC4SzScCILVcQWZxgGAx8N ze4rPzUM4gh8AFFMSDRt+l3U2T+3K1rtametGn/9gw0haMkW7J++tg8bx3/5 eHYOHJMPr8/et+s67ewpfTpUkkQ4T6mFUHOMLikSUDnkIdW0BxwnhQba6db1 FmgUx6rONTq6cFwHUb5OWYII4pSVdz6wtQphtw4ivq4NSFdWIOC7FAZQr6m6 RYkfN997U2BR/Dhxnj3lAXznmzB7TzdDcxZYKw5dkFb2jE9Ld8HXCBNuspI1 5KLCZyWtxTtv7cldRsDq4eRW55pgm5xL6K+5JtBrCEMsan295Ly4slMZB3Et rspRXBq55l7ZC3gKVH+Jvfr++Py0f3x+nmz+8PZiV5DGdpNPs3txXVEmI/1f GJRlnzJ0fAXRRgToPM7AfXnsnW4ita4y2qGXTu5Crj5p7tN87vhq6MKjmKBo CqThpXMQkjEB5eRPtSnk3zRcwuwZ0lx1HJufcTADR09TKauhZUzyREkkLHw7 rf9BN3eDAgFDzqR0tyCj7ZKk5vRLAIPN06LDUca0rPCdtc7ru+tG/QXbIZFq Wi0L8YW8ezK3ZxVxyGceIPljMUGn0KOWaHI8Cb83KVE0L1XdoBPWqWzz3CnS 8ekISEzZshUodZEF//z48E1owK81mq3ZbmQskxvs7omQy3cNaRCoE2wXgAwG j6I3LBFqNfMABB5QZHkdJccRrBZ4WZp/XZN4pfGflL5cWzEGkJrV2kpMBr6g yAmFKpJmANwI+jX1yMnm7vKxvY4A99+eHx97iq1poPuk7+hVC/sw79kGZTzX DDLEeA4zqKPiOECjtZ8+P1+p9yMmtErGyzV0mFY0NFlD0mveL4sY9Y15IeOc c5mikllRTBehCWq8DPmFCzbeUMlB9lj3+I0efadVB0hc47arod5cDbKxU3X2 Qjf/BtNP35+EgHGc4IikF1LHfIIb7eukOdO5Zu6oIEkZpqyOjKxYnGUbPpzC wGK/YjOVAQwatqok569Y/JjAlKFaa16IAg8vESHiCM2WAlk9Fa0CGpy4ld5e cFQZ2+7ILhmuXheKxWAheURvL0x05WIV/vGeLPbcKXdXW5LghyqIFBPrtbh2 myYxIBlUVy+kGfZWp2OQKQHtWJdKlOfOtNqTKzMEAMU+iEDk2o1cVIIzAqPJ CHXRgUcLW7HF6PHghiVIVPfS6s20dDetsZ2iOSHv88p3AjOUcrOYItUf0c5e qIjd8NqsygD3kbblsmD51VWRzgNNTdZa4gExx/wIGBVbrU7+elzmbYiee5dd 33xIb33EHQU5qCmCQmpQpMqx52tKc0OU02RkSaISjUl97W5ovICwNYQs7Cft S6ePJc867R2nO8rAvd85epRC8gajEYxGPCJ7pUG75Jn09P6IiClHQU4BCT7L qECSuV3TibjJBjy9BLlLSb8o9Cko4BTXCwnTSZ5wV2qsxRZVPWU5NT5mwOTA 4rCWygFrXHUocI6J4a3EOTJUUxyIlYIfIVLiWQcXNP1kkZ0wm1phNvIHi12N vtW4GWaQSpmiyCcBiNG4SLGejbJJEIGt5Vvzifi7JdoYLRlThH2PSimlPEk5 EsLSaRTVFhGIqMpFLVcq8b5o3yd1Gx+rwlLzcn5H2WiCQhWcGLdPkLBA3i23 XQXASiiknJjgwAR+PbnZE6yNAFPdvCo1jJkH6SNDbnxo7yTvw5EijhkvBpJd rp6Sy/fosM2rYyUVJE9uNWpOjDfV8uamKDtJAY8DrBH+fOo3OH+k/fNy2QEv Wx5Ca0k5MNZwr5S08peq/5sNPIZGCzkL7sU7SbenT0RwqNynUEFxO8ss7zLB I0q8FpcSQHZeXJ13nXj8Uw7Bbq2SbD2Au/CD1cxmg7E3RRuCPYvibR0l2RJ0 zKA2lNeTlE0JgxdaI9Kp4IBPehWhF9Eq5WvUgEapyNknO4VrrCtZuAzfITEw DA0fUoENDmwje6yViHR9vV7MSzG/yA8qmKbQMiJIRyLGZ2K+sOQEC85xY4AM d5dSRi4XakgGw/xrGson3wwUCTLi3YJKGtnzQbSdMK81LE8ZsR0bjcZivkek qUeSPVkv6TNpQyLh33GCFoFtAtqe0rrPEOGacW6G5MNMYjpLPEhj/ITLiuZb JBQI1xUXhMYRSslIXquwmLUIoQy7ILPRnIi1Ue+1JWJlRDPQ3o8EEYtc4K5Z Lv8d1eUQHuvzXao6uxir1qkBFhgegoxNOqc1pik+dNWsjbhkmyYWVMu2xc99 oA5XPXWe/rLqkdP0ruaRRsSs2sSTB29iSyT/TrY+c4qewR1gk14VPTGDXbpd PR+QtGOLw56+7Q2Kb65prJYnUwHbqykjVprTAuLkezZ+mzSp4qY8guu9A8Uz 3Wj53SU5hHt1D/YOBv18WvQOZGDUevPLK99t81fYFzS0pVUQBXoDdErnVT0X Mp17vob2hFLAkMLE4BiiTsYvmu7kPbhB17seDifMrlQhqTT4sDaOklMlydpr lMXl6EVXo/ED8j0MUz8mecVrjIq0WhfX3aa8McPRSdqTPHyWdkHH1OWoKyYV 6cgnK2jWGLemZnDkC+Hwc8iM41gU8+mD8Y1y3NRs1GalSXJ9nWrQN2iLRjGS C4izNCm4BnFFr8Vs1nftaizkynMQbO4ozku99yaTRs/sbUSCiAgn0UhI2OOR 2KCex5CGcXGfQHgJtD5KrwOmB9m4OaxKIk//bOpdoF6+8t2RaFsi50py/TTp OPdUcpZp9ZUOb2DmUJ1ZD2GxGM4hNvyYlo6SWFpIXyH7PHFVY6BPKYvkKX8D JQdaPpQPRuStSAGl5GbAy7QvRlxO1u0ji3uDkEBSBxVS4FOA6jgkp6i72Ylq YKM+sfOEPQcsGEig5V0++wLbUzfWEQdIJaCXqAb0YOYk8REFSqT3LO/SXoH3 Dc5Q9LRQXwZ/NwDV3aRE8o+I5Rag800dqedDsxOF4ZRCb154r7bobiSS1Gtw 3N6K4uarIRnlEM6d7KgRSyd/+XC8W9Ie1XsA2TTMg5igsBGyhhTwB5Mip6yk f/KAbVgBfHflyBr6bc3BDNU5rlZQMdYFalpZC2rhQwME3doc0+C4kPvHvdKg LUYjjy+LyRGOP7GilG0sdWvsjS0/CirS4IsIfkw0zKLCdUUCCZ8qsi/mKJdE ZghxUMpJZngHdyaBrMRhlAYCJNtPwosHc48zbqVGoXgwWtUtlRGAXIqIF1EK KVPt1+k4u8wQY0RFS/3B0yTFe6eeWTwpg7xpDL4kh3NHmvsmnGogDr1kr9eJ ODFJBBrcoIVSXWs9dZ25ky0oRTj5jMsmWWmi7dJESYaa2GnC4sX3d4N7Impq DcK/PCOAkxdC3KFlKRBta3Qvi9I24c+8m7ljSY0RqHkGkV1iv5+GYV8ydbRU 3A8Jx1cBrlsPH8q5RUg8FSHADRcxHXc3uYSSTbNLmhLG1RV3MVVKvoMLe0v4 faQy8IcRcNMYMlZfxbBH4yw78bjPVhT+qxoe24SR3g1Yq9IIbqNJIZG7exuV XITgTo02wXdjdcEc7v7Vh8Ctevbp+BuCw+GF2ba95hSxoeOHZOejo0s7YZd1 gBbrOC1ViVof3LA5RxJ3T3P8r7W5mHyZ5HeTTbfCFJg1yj3nbHfkyZ/Swj16 k49TPPf3dJb3rmBDxsakm9SU7WY85Le2AOt16dQRcFg20fe4YRp2/NKAklCt AHFmGryEMm6+wenepPLleJslBgM7Q5oxm5naPGnPDWPC6s+ZNNrncDoQCWac FI9x8eEjovbceFPh1wkXoGE4UwlOAhJ0JV2n369vtyYtotY5YAsAFBP7EVaE c1LvXjkglh7aW20/ZfEyVTDgdeTcJkG3VmZQndLX93GMFyUX7NJw/MWdCcro rBePHRsWpBO+QdUQqWoD2XKPDo/eSeAuCFO12ZiNZ4mvn3eBlOvkxW6QHO+T Y8aR6MYb5xspWyOlc1isPglREiTdwu/WrsAkPJ2rFrbRMnCL4D1HlxRsj1Ly He0JABW5ACq/ybMh4TMhQl06vwQ8BsmlePB9SqKwOUDH+V1v7JjWGN5NDfHl D80LGRagTQoiIVweI/nTDjlCGYmO8jBQgYtOmQFYe82hBnWLba2cbeWJiex3 iXRRUARJ2pJUxhh7KjQROYbpE7maWYYaZ5tFLd5aFEzRrKTIPnm5mxgUiZko lV/eSqXwYH/UmKfqICbCW4+zW73hoPfKQ6vFyvoP/C+7YVlzp/4EH7OykkE0 qw1lxddUCpM3kCN6dZAaUqVzovG+TRgigYYjeGWiax6fnl18POoCtZXjt8me Q6gmHDtAm50z44QSjEDzC8qg9iaLAI9BbeUqCXJ6J0MVSPgBx5vgdScEEuYw ROBxKsF6fICOsLa1HxPSr4BYC+zeNtwAlzl8JLJDwS+DlRRsPCVlwaousbrW bd9l+7c0sJ0VB69+9X/fblv2Fesdq/XOVeO2flhra0vFDJslUK8q0k05T7RG kpjOUIM2ZYliXTkitClB7Qj09Xm+VMqw5/g+6W5CuaHfNooeUSpxqRXWwIfg 0KuEFPcPZOqfX/4NFRxIvB7e7ONf9yaHH3xBWAGF2gymHjHIOsI5qRM5Gk12 a0sy3sixTHpBX2HWqO/+EYLN0KQZoKEaReiGq8LwqH7TMb6kv7+HuldJIjwv enXf1rOb1B3ZwLokjm4D0rQ3k/2wxec2OXZG7cFX+7QH66taBN9zgGSquLrG Gg6Xf4EgIqAjK0WRlsXm9GMqb6ifaxKsEtgrA4KWZvlAJ8+prCiHPW/TQXmO 874TnGAnqgaDC+f/lV+mUhsRLXCN4blecLHSoA6Iyk01dcGJfiM2XU1Dqlj+ YEETWTGd61J/bTkJWq1DDkiePIG4i/9q5sl/ms2+8tIlcditlhK158/3LVjt oRTDR/jiI9aYLWinl4wZe+02QJiSOtlgQG1p2I3FV8UuGSie9XryVOXs2Jfr ACPjsSAnPISyViRq/TWd5VwX3ECYAhOXiVEDRsqM5CLGLIRslOD7+aRzCvqc FCqYKQIVyoL2qRt2lltXkuhIcQPIO5/qHIViVZmKenvvH6NuHA4Evwgv7RoU rpG8LAnOb1WzUL4tdsk4g0k1IxG//s3/mmx2nTjx9vPp0aeTs9N+nzfi0hMe 28TWPlvV/DgTmmRadm2WdfpD2eKRAuRq6cmdFAhx/zzhaU0hCWOQYBdGAiNR MMrraxSVVhty1hJ3SrJDWVipyhIiL6wlUDxGjmg4VHBqrjxWZQbCJ8ifkGbE Fz/7FE0dpGqsu5nXy9+sz+B0Xy26bEPJKMYAZmzrlipU5f3xIuR+DxuBUhE9 iQ+upowqvKf4gQe2H1VlHagnRH0aX6L4AnrbaEmIAZpP59kt9h7h0w6SYX69 4JIuYkPVpGmrYcLugK3kXcpWt6fwLkOJfep+cZCFIuveId886powBGdpsRgL SIn7mnaYCicf1lGQv8Bbqrc2GgFIayrUJ9+hLoujJJvEgfHgpndTUXAs8SDN fZeplNpXE6ojsiE5Hup+55cH42x+v2WJDLcB7krYZABCwhHDnAVnczSIsbl6 PTZSxxFGHXWo1QI7d3ytLbI3Dq49x5C0e3JMS+wGdStUieCET87IiGngjz6a g48r1Zyr2L/XNHXXEGojXxYNdJMXURQHqaOZiPbjtUzi7p/BbPYz8r8Q1Prx +LwPZexve6XgkFCLpT/Vls7W+CVWdNLtoDyZdef/Fz2VRTIJkRbt8+SvxwDH qBvSH7PKt8b6vq+FjRF6war3otPQdWQPUwODGfartq0KK/CqxCp1ETflS1/J FgrLOlT0SN1tDC7dqVHVHsqMqtKnyWFmznCMMXsWbLmd0pKuUp2+kGIaXllX zawOfftZ6BMUVy+ROsaqHYVejZgqBXVPmnh02B+VB8FpnMz+ZjETk1lsrc9g yMjMpNGuFzpCAzPN/WTWiZw4YRQdnKeBCz+GuebAylaZHd2l4/GWuUKaGEud va8cjGPm+PldXvU4UPtWsmYH1WleOaLj/n3+fClIlHsaU5lRLZxHuSaiQcFH QGJX4CJoGk7kCGC1l4fQ8YDexmSTxTwDK4y5asD1JHhRjOzukHOMFcVVOLYm gL8agYiI988INRFj6XYo9pPaaRk8AbwXZ/eMEP1lrjc4ureSxJjZNUsCfezU Pvddr0aM86urfjUDXFKg+lwA75kwr9A+KJc8q/I8ssrdQHa7Fv4oqEdqe8U8 K87h29cn3+0R5hb+U6wig2uauSs/n78/+XDyqf8WZP9vW7iE0hzCf/gVd5Lw VP/k9C0QjH8C6hMxrwP3BH1xJ8CLKuDDceNtX5x895e3F3/taoeafhIY1h4E +oYb80xh2Dso3Jz8ymgA0TtBXg+/9yRmP+4zHBfp7CVIBcgQcyNzuc17enF9 s4Xaj7W7pItAM2gc+/vzfH+ft73CFZAVYqP17BmXRWQfLbXhGozcyROCNsdE IB1AxqtIXNQoNZNfaZCV+ymyqgZiPgl5JE2Hlxl6iftAYHxIxhK/wjQS+wBc eV9W6CAp8+Y9vz9Ozz4cf9izyhzXs8GwH3AT2ZRd3nFRuGu8JtJgOUQ7dlog HC7OKgqyi7hl2F7pi+rbi9T45c091FUUCIPkJFDSbonpl/CXbABm3qoF8kTZ vdscMP6XVaI1yn2ODdETStxQGHv1OmqwttOO0omPoN7yIfxEcmq9P7WB0ToT azh6ytGbz+SwrUG2Ihl8r0lSL8vo0bgn6V2/lrpNr6c5BD5OD3RiyaIIn4F5 Cwe01mayRJoOvEaGod4OxVhHy6hr1wbPxMFB+eR0lNtiUNEBaunnLDtF1Ly3 uOor3mYozobtZx6ajTMyLdaiaWQg0dw8i5PB3rduSJyrOQHxA7Ew1mrpfNu0 OMr0f4LuUWdKP8mefSI2HBHpZVDy/m/78V3qVr6swxgXD+Es17tAheHq4Lu2 Mbosf7dKPCE4BbYE3EU0/32SmvGAOhhpxjSHOZqryHRq3UNQL/MjvUmvVaX2 qNVam2Xz15b7ojZE9o/abdoSK3aE2psijS/ca9vPwvpHmTuTI8nXRgI27dxg D2nabmiJ236maWVf05nABiFIfjC77yLXbhRdUnZabnnJ7uQ+COrP4oYFBDzh oFwKFxSXApevTDi+0R89tz8OEr/DnyzZ7r9jv/MQLUYadXTvos/+M9B1biSf 5u/qZqlJ37C9hm5qZ35jzbNV3mkRK1Ge6c+QHiGYK2sPT8hqbWCvkjCVoflI 8VOrTtJap6j8XZHUEDm2XuwuC9EpadjyprKsDaMmtY2EZ6zmuDac1uWHNZJV dBxSW35JGEmtIFGNFyEy+c+x1vkwkTU24JLNZ/Ji8yKVV+mhIsz52alzE603 OY+egSX7k/qiHthHX7/NdmzsXjmtjp7S8Z5JxNrvcHE95pNE92URqq2KYclS WBGpkueurz80IcSd8iLSHwnSgSyC4SUMnWRL9lCKN4ZcJeaEeaiZYdnxYmaI TNn1IrIZAnhW1wm08pp9Ij6vetWtJOnrw7VKcK2M7O2V43RyPQfQQx4EZD1G hhf5vbHcRGCRWEdE5/EYq4rYKum8Eir6mvh0LWN0Wpc5fbi5GFc56CRsmi+G Bu5Hm7YfoUSXte8Gpfqf6gEQYPBJZKklRdUQEjd52jd9nETJXdDiox26a8Ug 67GJTCxsCr5Wsy2Jnq6953GDD2a92tGZaTCZu+9559TquuVfam6mCdbMh4Cj 1VvzRR+7mHMMMg+isc+GAtRxl1rcEWiR86eaZrCVfDALEl0Okl90S9cFPW2s Z9eP5zKalMDgopVRlsYu1VdecV/0+eZmcbNFXkqNrj6CZoDKE4QxtZgI6Pxy p311uuqcI2rp2FFChmE0S4Qx09ho1QFG86f4Ujg8ht1HmpJqLUaejTTkBP2n +0QpLVX4S8wV12I0MTl3q+0++Z4zrHR7xiqi9RdQ4Ka8qEjeC6U86kkK+rpt wZpmRjFeCpljfDD+qCaGKGVVB2yoDTRXt2x/rv2Ug33/Lc9fUDhMqLIsce9Y uBw7U7LrGwyaFEwD2clnVMYlnej3rC0X73i7Z0Uw9pZUOTpVRSw+QmX/by/Q in6nnkWj3OlaOyg4tFsVyJdNIFc0e1imhBGxQNMhko0bTEoVLTEcAfQvZ3cR /A3gebjGMFX4tBgHyoQcatlJd1NQlwpRvSdIvb10c4mkEiTzXg9Q4w/vuzFP ch8HoUPoo6R7/YFfnS1f57pfCU1Rk8hei2rOAV4lOhheXO5Kb0SWLzOSUjnB VuDQXenBjWTyOKW9MsEdn8+u2E5BWUe3E1BlRjbEss2gcDrVzbDWXqhsBDcY lEtbsQ+EyOYqAj16X9Qse3NtQ2l2lv5SLvNZV+0wD2SEx68dNVCzfqV5wfKF ai3TlyFIxkqdSzNR1mGh4YxyVdL1NCAUo4zh+fgKdWCRKU3JBqh5KXKlQgKF b1eUencg08t5/+SMMIFnd6bGyyiTOH71S5a778Jl/FuLz0HRSnE0UzRZSTXf OOuiLA6/0AV0w9fBuCJfWJrcPnfu9kMYJKUqVqCByWOmfFkf7p48tB0pB9uA lsjGIx8pRzhq9fEI0haFJXT105cETBj64lYFfHFLwT9C/cpuiVYbDJQZ2FcK O63fCFiEJzjGszv4cSFjJ39OdpJdyUTB2eQmwijXjONl3DQ4qQAVO/lMMkbE TI4D13eNklcEmpXedCShuMG7oIILUmueZk/1NQtIf9AoKT/AakQ6QtWfWBiP JQfVqUJPglCnbS0+jej9wYS8o1aayAdm6JBoXn/OEA7Ue/GZEFXqEkOCyN7G ITbn6lhiRtPY40+k7L9gYLQR7AyrxDelAtaylVF7j8uW+PkncTM8BdhjdpJ4 09tOGjpO6s731/SyDToAPiqnPFb7o9NXChqjrVPMAWyNQuE6trpx6LFMSJ8x cqWn35ezjKomz9zTKDxEMOzx+aLi6gRqgptCqU7OULGeyqxSvjxKjmjZb30G oN7DweUXgWrJckYzRTgxgRnvaKhOhCoSZxJzU40AzRmVXReAiIBJKD3lf8nM UxtHizbsfRAAeVEZ43SWfXW3iGhWA7EwVPdCX5J82l+UevsWo6ADvxMse3tA sWqIVAnZmhW6PzljmGcwWwYznnEOUVioPkmOKJ89rtTAeFwBhEtpslW2wYiM SWlYbP18//y3UqEMYjI5MyOW+elKg/hD3BobVijvTqS0e1aAmLReLyNo371E 7MH80nPFvW2Be9MySZhcVUR2DyjpKglSuKPUoMmoEby97RGWZgMqiwWefPOU Q0NmiBlC+vhshNih3MK2av6jhEi8LZ+Ti3SFo3K5oArjHLLd/N+AKseSOHym tc6ZAM+KuZpvJHgznOiyqehB6llT0GzOK2r6G1/Ya4ifuaDoKpLGCb3y5r4A nn8yQwVPjEzgVhj4pcsYRjBlI9vAbf45l2PAg3zaeLMUSZuqkFI9nQGxxh7z RjoyXKI4LEMqb5OYrzAAJu5zXUrAvDI2nJW73lB0Vot13aWC0xqtyOUXWTyX psgIRhd0e+gwTggNFgcvD+unaD6GB3L08LCCgcbknRXXopDUtzw0bDguxhV8 8ZWF1psOQowCxtJwfpUM0kM4vZwD5P5bAgZXd8pp9+zJn97qjl/uTEwKd3Rm 6UgvZfqH6zyb2GVMYfBzeBP8MGNVNJiWZ82lL2opnRawtkgpa3EoSAMNQmr6 8KZIfN0WjTKOXA4t4rqUyyKFOSGCEXry2I2QsM2wMQhfBcGwtHGKRPJXlsb9 6uB5XTwBawsz944Ui8T57bcNzmZtxww/eKaU8Xn6w+F7bfgbeWkilTHp0elg kl22N0OuxANDAJxC27ituRlEFtN8nH3PONPjL25O7iayS3FGR5TCSKtwQuSB UPvp911KMSFbOkG8N4iE87/BRnK/vDPh0TPpLYvhbJJZo0mFUSmKdH+lmJJB z5PFO0ZlNHoHFjaMTfY1j1B/vEpKU263dOjYpYlv0/0ChftZnvqbl2rdHRXB LUD48PP7T3teY2Bk63RkYnWL2B5r+vLVVqGy1fI67/BnXofnz7lDn8eH2yy5 W757rV7xaMUgzpmgj4tMmkGiRJ0JEy/oXTFJ8iW5Fm6jQFywqUIMcF/zi/Af ayDyiFeGJE1fxYziZ9qnNE96o4LGb9kaAoVL1MaNLoxV8a+GIJEiG2GSJ9k8 EFS6tQKxaAtxexHQpV0N1tqIaTB80Zjb5Nw1gG1Hb/yl95RIE1w4T3/R+fZb gsyEK6ARwk4NG6EOzqXmwXCZ1mqdHpUE0Gxy2X4iB031EM2usbQHMFAVDVtM 7FqUPGL2SIgSV4Y7BsfGPM+5dro8u+0PEZE1J8N+f3LWR47axfHRpzMtTobN S+OhSgF9GNIghvOiIgQeBQV6wFbSU8NH3yR2DJa6wD9FfGosJnqfg6JrjgWz c2rXb/4qKREubTIk2xda/gzt0lWhML3wHAgVfh5UqohC3qKCODonRrp3tHs1 bMh5fMDcHKMwigT3E0oAT1J4j46V3GqRydrfE3FS3iO2dlKohDaB0uXkJxhY CPgXJIO2iPcy0ZxIkblHLOK6K1hZvvq104Urr5pbIvsp9TaCBgIhJ5bc1hL1 YWTf0KJElv3DaKlBhivDmAfSM2LmuQMCb2S1Bc1mRaDH/uTEcMpUVi9bVRZX 5PN6cRyiDBFeBYLsFYMrRxoG4/kNSd3koWeLxqWUTZDcIbwewkQCHxJQPgtO n7qE1TbjNGnDshT4YyvbxQV+KG2cDDvVDGIGg0eNAbwv/4XFqWEvT76MF6Nr KfDkpON0dgUtaHGN0tAFI8cHCbv6zSVDc+iYrhS9rMj4S0HXl7qtAikS13a5 Y4iQoSK2fbbZ+V2hMTTmUjpsXZBLDBJJk172HC7H+ysjQz9rD52khjsBt2ks P7EEbe33Qvy9rEnf+4MIf0xy/KiWY6A1xNMV97eoslWfSHeZwx3HSRvuwcng VspUOBbxT8usWxatRS4aH6fqo7VKiSTV4K0rwjV/dEoUx7H0DKFccKisyT4r o0sjq51AfDm95/Bpt9t13qzdtROqwsEIgsRpPs8uxQpxxyaIvjudfV/lYSgE byZAjsY/Bb/fA0sXOeM3UCgEAffOZ/ds7ZhqnZy5vu4eT9MNw0/luuDaluNJ 91NYjVwbhM1t8N6OL39h8ALeWT1qwuJDNMxfzCgEdW0lpwg0gd27rrt8Md9i ffXT2Tsm/fnwa8b5zZf5DB46xl9kwHoy2RgP83FcCklRvzMMOMOvA2ZfTY5R 2EVz8JEx/VfM88Md2Rz06k+o7rTHBj3hvWrUk5mIwXHYLI8jDw1jaY24Ji6y PFJCCwrUeMD/pRD81VKG1ADD47OcEwVi8gEgV4AG7tYU3pMJQzU0ms8wpoAJ rKCIPBvWWOckh7iOdwcr0WD8Yk4ucwKtv+8kVuG9NAz06CZo1C9T4a52/N3b j1wEda9EQkv1vFYDU9dGqrJ07QEMw4p3UvEvMHJZbGpQSKOmRI+N2Ucpcuk6 MWvRSGorUAiCg30swynGLVQOBr8a1dvmgW7wO489opWi3aG3jCDy6d3ac9kg /nFMw1oCYM0i1W8tf54i8BUV0bHkBsIgseQmUO0tjZO1137z730OmuWoRPLV P/ElA6yGYBBD9U07kNtgOi1ZPQxJJLDBgEQxaaeSv3tsDKzaW8ryozcxxYUh /YT4/LETgpmKoMkFvYcWmFwfBVdcR8DSQIqn6Ka0UpK0wfsetcqdB5oQvM/k Uf3fWpP8EaKpzLPWSazOtFHMTywUZBMcKinUKhjo5uksfBHCXV/ndTC7XsCy vsHQV1ZY1amHs9uMKlYM4AQQA4C0hPTAwWRegfMnGqvnYkX5m8fQ1AqVLvst mFqKIIo2FdONwkn/7uMUbxfjeYYyHe5rnHyKssRwj9FcqLVBw2K5IsZshEeI JLZdzx0Y/j1ZrXRwx0gK//XFy4SzGiHvmN0l7uMVPfbbb4oRUVev2E2CfE4i la5VJZHLMeKLNPzKJqGTvAraJU4hsc0shR4cBPNlmLuW1RHO5ZDP33AEps2r CwYwmdG8eJqNXzREgV3cPFWRV+G6nAz5bUE4i2gGsrc1YRMr/g8RBqSgYgnz nydONpyEBZu+ErL7oZBiYqlhpodCi21SBRhU1pjDy+KOwOE4+SGbcc6CGDVH 6WX7ibFss2nWsWWtovAO1EQs83p68klMaLguU4WvBOq4HBjVyh/FzaTUJ3WX jjhmwX2w8FshGuRc445vxXEQGnLtjjiz9kplsbbNRcxecYpvxTf+8AGJzmys 0iW8yS5vCAxNzBVDBVjkiAvSN6jcl1YNIujSdETFjKTi8mKKCFWex4Iw9q68 IvH+/DPZzBybgSG5z/5oC6jB54debXe8c6T7BGP+mhVZYF4jsBM3EDZS+qEH haq7om5xK7kYEkDASedDBAm0oyRpB6OC9wZOinA0bnSz1YMhC8U2YcohGMhg 5aSG94SVLx0MF6jFlGkMMMrQsp+B6BP+HlC0F9RVqqHUMFszMsoNxoW634s0 Ygy0uFSTVlf3nsxtsMmS/RSqJQ+j/bIj7nsEX43I8dSlOh2J9MQl4dzGuVlc hwyNygeoYbJUSjfnvaPAM7dklMJzVB3NQwJa3W8q1o0Dou+jRylKThPH26wI AuIV0cqvWjCBQ94IsKpnk8SbgjrMoUeUlMGKDNtjuWTVCFFD9xZf7elF1+rm 3Q7mjitTDSnaXhD45ozBBcjfjZrCKZzE79R9KVBCVXpZoIB5gXTxnDcLDLeC 8aSfnc3Db5RQi5t8HGIrjnUPBdEYYYEwITUkX0DEMkwlzP+4b2RoeG+HW841 bj21An9qMpYuUIJzMZi5JZMoknwIndB3qCMn22BEVzs8viKfzXtuM5ltfpHi ZJVsmLTLbE2kbbLp4PuwT9hIU6MLdcTMIcVqw/Ke5W8bhESItr+USMZuYjt7 /iUNsDRFfKhAd8B6DpsODDRJhqC2uZuiUvlhkpEq0/JoU0ISVQ7iIro0Vck+ F/QM9YBK2kQQQe8zLKpJE1zw5OlcCKojmgGH4RKRW2GqnJO45v0BcLW8DVnI bcmILJpHMGh2gVVA9iDhRSxiRoawOwGoQvWf7Cvih5Tag74GY6ob0nuOca8Z D95wBzT74lq0aRszbaEpUtddZeA1cIT1+QyteKHqvrkBy9cqTMsg6mI0a1qL UwijMtXksbmJXQJWFzJ2xGPLxtb1uNBIaULWz7sIiw5Xa32Hsht4A9b/bkJZ cHSo/sTRdsnrz2/fHp/3X3+++Kn/+uTTRavdfvHqlbrY2Z1Pv8m737H35AOH i4IORqvVlnknEOAnuIaRs7SJVvSK6tTljl3bMvh6qiRhU1Vax4SXaNzM0YnF eDAz2k2wjxNIBcw10ObTgA241opcae6PsOs6QVOYOpyDgkMMJgxofnLqo5T7 bDGZEK5MWHweJeQ3uHx0WIy56IaVhKhpk6zAlH9ZZJdfAKRfWEFaHREqA+6K VIFPcY+SUuFlCsd8C2WfM66se0WWxlk+hiDi3YfCaYCx7AZF6XOATAxrz6sW aFlSF1QECToi6vkx06RRw6wvAg2i4G8o7JBOCGz97itsir0Dsm5Z64zDkVko qlpeS845Uq/e10cjSvU0Fn0MgY7Krmtsmk3EGDSeLcj0YaagFZYijfXZq0u8 oxNBUcFmRcQlpQhqi+Q2yhE+IQHAE9/sJ2KOCYbLGzoesR/ShmAhcVlokafc 3mJFqhuIA3Q2SS6MVShvUDVjUaRJVrWqJe7GZKpRS83fLBPog5P2k9f9t+fH x53EzAktdoeLf4PR1aeSoiq3AJTBdwq7NSWQHpqvYFh8u3ameaLVeFUz1ayY CqnQ+qgiApKg488Tu5IR3NFfTHXiKAZE2zkUmuQpktoCQv+DxK4uMf2uMrnF X1XZ70E98/JepdofnPrfDdTDlBI2SJ1if6GUz6WqnmzvAJFgOkj7hOfij41T qQGO+lVff7WNSIhVwx57kvT7sOqfnHlXQfXuu5Pv3uEJpMTCOvEuu775kN5G VWfI+FURPuOkp0lOwawz2w7kaifpS7O2/PhF+CH60EimTCR6MCjVqAIAM1PH qDQECHttMe0bB9tblllbQ5A5t9YdwPJ/yZt0uLi+Jt97zV3ER5GfwekO3pSK KyDcf8qunNSQHJ2dvj35rn/x4WOjZC4i+RXVUKeKGqKP099WUKPLij4/MCjm +kten2DT7DEMmlMc2KOP8Kv5/TQtfj49778/ufiEvK5/JJtH748PTze7yeb7 s6Pvj9/grzcn559+cn887G38ye3o7AreMDEKvubjzRx/1/HVb//b6MtrGAU3 fBghy0BlQunhZgiDofdip0N0QJs+IodhQ8uxeBWQArKu9ZKlPTd1XVkYBKO5 bcFWT6e/Qyu7EeX280dVvAlYAZ7wkeuNnjVQHjq/0kL5AHs74x5XLaF14nBo /vNVImsjFzQEWveDbQbdCbLwpT3A/grt/GdqSmLnyTeXRLqaMC/uhP0d9Yn0 HCLJv6vP+YIh9Bj9DJ6K1+fGy8aSuVigzWg303jEMWSaANXXwYklLSX2v5Q+ mDiguKnmCfNepM0qkXFnIZgaGiTP8zfEo3lcuje//fdiF8w46R3I6fx21JU0 1RQ/dJ9q4og/btxHl1/zkbMPG6XWvw1sqt+OF8kXOCK6uEwT0sbU7H876rgD umHdbH47StQs5P6kWZehrBoIDk7dbBwcvNgJ3mflQdela71xTZY9xltcxrWE hDw0UFaQz5MJgLvr/wuKWWv9K2+HJ+Yp8X9SGZTECfSPNz47+dwxHSknX3qN HGbievv0/nVymxVFWhBtpZjO94evEw5iKMs1LNQTwYcXMTNCjr/bsYvLUSEm QpoISAlwpfrWnI9ETkjzcJj2ymMIBu4E2DECHM1SJJrIyClDXY4kmmW3ZIOH JUrjcnQkyYFjly/+bW8juPSMowby+hTSjuUdcvYekSx2CtMFeKu0qT2+9Jyw 8hXhhu1otn4wLTNd5ZRXR1CvUwp9gvRAGqaTEgB/j114JYVtBZKKgqQownRM ylaeFLeQtShGWYhZvASaNCAzjDB+79rz37C9YgpAiNhPLDJMWxtU8LaWURle Sf9GcZNdWbw2gzOT2E1LgdQRR3R23L9M7oJ3QELdRS8qot+6AT7ryJntIzqH pRpakDZkvMNPZx9OqEYwPjUU/sOWWdSGka/X45U+4KiOmPv3KjsydQp3ljIR 4z2ySwTy2/GI/akdJkpCU2SCunoW6pbDh8H6EQZxtG8pRiTaVXpCbViuTwsV dXx3yrecOJRNii3NPiuhKtDCaakH3zOnwWvUjjXoaB0HHdQ2Z8xcmjMGFTbm 6GIjYdxXW0xSLKaEiNBMIAPrc5HBr6Rh2qOBk6gmXTggHI343/lQfV453LFf AWc8SEb3k4Hjz6B7s7SY5pMirdhxtpLkjMwmpEHPcsKEQYewpAKyigw9XI0C 6hGRbK7K4FaqGtggkRvI1izUFzFJrnN6mbxxBA5OmoCkc745Pnp/eH7c//Hw 5FP/f34+/nzcf3d8+KYt02S6JZHmkjKg0rgqpH0KGZ8tpnOYnOAhjtpgfoVv 0HJe8OPcTue+HjaNMx+PgglCAvSYPQve2kU6e5Go68utZeCPAiO2WbX4d/e3 m12r/bXJdWg22YpHWcHIw7jLOGoE4yOBdIiIchjFMM/ppFjMjGQyi/hl4diF 087ccKiGgxTwog+au9nHJyEXeETUlReUWua64aTNObXCUS5x9/C3RZ8mICeB cszScjhpZCdzr2P28klqs1FJvSel0z1VUao4Np33OCl69KQ6ydhOUvgbPOlt omZi//bvCnPb22suNyPwKcusZiWxG7W2SJOytFUne0PJxhz2ObejLVhSWorS YKZYLI7qZ7LtAIzQ5uL07M3xD2X3S6n6znqmj2rwuuj6DTBOs4VTcxwXFEvU k/kvfZzjSosBXeLdolkaMAvygXPb7bBQEeAWCS9FPnXvzBkHryvFijQFPJkv Jpw8OxvcIt5JCAmiQYQobXaJL4zIpewUchC8YYodXHi3MW9JcR67o5Bd3WsW rjTcxbs4Jd2aRHXXpARfQYDMJ2ASxAQ2BgXF/bOXFTUe7gujQaTcuzMuYE6A ZmG5ELvjcjBFK+2jw4/9i58u+odvPpycBlpj0jv+eHz+Qfki2gHLfmF4oaO8 n/6aAWQEIdswqbsjiXK6X5h8CJwnwhKo0NDADSIVl5e8SwfEqcXJDlRhSuxi 63shsQk4szi86a+DWwnIGg/+ft+7ve05DeHqSkIQZvmt4/YDfPwl+yuoZgh7 xC9hyx8Mc80ZYt9ycntLiqnT8NQNp1hhe/5Q3t725a9nQD7o396Kw3GDUhCV X7KveEoVathY70MrsomwRoZN6PKbsNnRiPLF5Y1AuQiwQleVfpTMcs9d3hAL ncxzfvUpZoBVCEd0nnLy0mhxmUpKFMf6y7f1uAVHM+ldbNQJT5gdiA3NkJQv RN4sLI999NOfj4ecequIZRUSyXcnI/+8NNQJqINMrGhnGrf1elBItgFtrxdO rB9MOJ2LDwZweV7KVSbodjmdX5ohhN52su1Lhal28wXJFdd7L6kI3gslbIxg AqmThKb+x8Pzww+B3ZEbe4KNvm+ZmhoxDPt2AS/m6Ko/nd1u4Ug5+aqL8kLz Zx06YZxUiabwE70pr7/NJhDGXNd051VwZ/ArqnppInjcOiww7q+9cCQ7obGy Ci/woIFlX8lQji/asbhNOIoFE8gJU4vB2PaxiUVUcol0O2ka7mYIYOmvQAzN cNy/UEmHzhbomzxFOR50gl038vot/GBFepv1EIA0IPGHTdZTJ/ulFIxMkcX/ vQMx79otb6E6ZE0Z0ZC+l0bPoicITjq+2gIKiH7xMLVgGKIVUkZVyQUVtta4 iDucPZkiSleZuea+EqqMo9IT2q0Yvk9N7LMzsL21tdVJAnIIkJ8ABYafAj2A 3r6Nedm69AmDgdyYPKPRLqahH474nxKjOWmEQspYR8CUtX5MVXQaOqrXG5Kw E7zJEp0os5Jgg9Ic9DL5Iq/SO2aLghPraNHmPJ9u0ovbYHnbL7f/kf6admd5 Pu9e3o0e6GVATY2dJEgrXQwm2sAWUp2ox+TSjQC1cjnrEwitgjqx0XLf0zso 3AaDNMoBB3Rpej2bym/3AcjGosvItOommzJnpnZxIXTH2MkfAJ3cSce0kUyQ 6mezX5z8QN1l19CsTTbhkyhvoR+S5rJrzA+AEfitIUt8LHoAIAhvgPK7Lu0l LwM197fR0oC8tko9AfLXs45uAb+6mtkKY82EdaVxfu0kV424o/BUyNMUqgUd jvc/vUz10/SolHQe2qkamTKJ1TB6+WSSODlq3uUiL0gn0+4oLCtkgxk/yn1S 83egKErpCreZ2h0hGAVFVFEX4QeeUCAl1MWUQjKvFmOKi8PsUBCqDJHje53i oIWRHYVOZzeDKZOHr4PxgkQGeVz2+5CiQcccdoiAMapeaQBOEl0g4bi3A7Bn SzaLBPfMj4QoOdHsoVv4Lb5KjODo3fHR9/3jD8fn3x2fHv3kRK3To40NQwGR 9z0KyFKRnyW35aJ5kJwvjfec9n+OftUQTBWvrWMqBx6tTkfM2F5f7dNK9vNJ RXF1DdbSZjEHiCjIpJloMrzjxomA7Opm2gAXOVh2LkoqCVEayuF0AAo/BPmV OEwErE7Ahsgq5Fbz1s2WE5wpsBdp6+wm9RhSBIV170h6APHoBKWr7HoxozhP 7lj5g3/oP/g7/oO3uJdeE4mkZAofyt4dH4oh8vCapD0p0XaWZrAYhBT4e2ml DGJkxNKRI6w2K9LZNeRFkWP1Kls0TJxfl44uI5nuHpifu5dNvrafWJznUO38 0hiqXR6dnX5CLFNw6eLT2cfO/1vSG514FLzkydAFMdWBf5XogF82kT3lt4YV 0tgkA+nT4cX3/ZPTT8fn558/fjp5/f6YznDhhPfRwp1AKBNOY/BtsE/KcDqx bH1Zq9361jF9H4/fRO22FRNDwFRk4gW7g7+ZAR/IMC6bxuIWmV32w1WwbK05 baWpdxSutX2s3axwpHjohG1+TrrY4h67iW0HEZrd9VEa7Lqm51mM9iN74SMh G3dVa719pWPntjs+5CBcGybC4gt+c/z683feNff98flpn67ZgUXJebV4OpGJ jcyqRrXqlbEl5pKHKJF4bg4lIerkUTKbV5wiGxwROSDyNikz+8nR2YeP748/ nZyd9lHX9uTw/clfj8/b4WGK5WUL538iz3STo/dnp8f9txfu2MufJ++P/S+3 hqeH7y2RG9AuflTtJ76rUk8yl/8pPUU6itPIcVZpGsM57Wxs/F9DFwt6SSQB AA== ------=_20030327130820_88439 Content-Type: application/octet-stream; name="buffer-xfs12-lvm107.c.gz" Content-Disposition: attachment; filename="buffer-xfs12-lvm107.c.gz" Content-Transfer-Encoding: base64 H4sICGbogj4AA2J1ZmZlci14ZnMxMi1sdm0xMDcuYwDsXHlz28hy/5v6FOOX KpuUSR127VZ5ZSuRLdpWVpb9dKyz2WxQIDAU8YSDxgCimV199/SvewYHCUr2 SypVScXlkijMTE93T1/T3eDu9pbaViqO0vLr7tTsTsrpVOc7AT3lgTfZfJlH 17NC9d8M1P6LF/tD/Hym1CktMeoyy2/9ODQ0eXdra1cWPXFQnqgomcc60Wlh VDHTSgZGgR/QH9MyDYooS82OOvcDPQqyNIz4gZr5txqgJlqnyr/NolCHarJU Z+Nfxucq1kURpdfKT1WUFjrPy3mhgpmfXmvl2z1UX38NND2fZjm2BrTQL/yh yqYqyMrc6MGQ5hYEwhTaDyuowDPw45hghJmKih1Hm7oo/LxQk3Aal2bWH6hF VMzUjc5THXvFLAeQNCuUWRqsVyP1yS9j9S7Li8SnacS5Z7svfnDQznWS3RJZ voppEWFVpqkOtDF+viQMQ6IlDZUBB6NpRBOLGaFnaIsFffQLUFTzVAlPI5M+ IWBlruZ5lDAkfj5SR2mY64W6zKPwWhN2wOXHmrS5ph3KOXHezIYqzsshbz/N tSbpMARzrnPfHpe6MlpdT+fEA7CXiM0CH8wDToCgCn8S66Eqad7F6dFriwUm W3RnxC2CNDqmk/5QoXEU4qCfP7tx0yYE+YaY8B/aEA1ELgH0c61y/aWMcpqb xSFNOzr/ALYXOjE4Lpp6/uHnCuqlnA0d5Y7b0Q35ZpkGbjM+V6KCRfyFcMxX R3kAyYoj9dLnJ/9kiKydUB8ykH+I0iAu6bReihKRFE+j653Z4dqIIRaEXQNT 0zk99iddz8GRzgWkCGnWCWnhzzc9D4q4cyiZe9ioa+w24QPvGprEN6G+7QS4 NPmXTuKjWHc9j1I6r47nX8qs8LN5JweijE6ya2BGJizRSddQkoVlNwZBBuMF kd80SqjnGGsM+ibZLf0AetxehYEoW382iYo1avA8SUqPZKnQXwvZItTTKNXq 7Nw7H1+Mz38ZH6v+/t72h6N/8V5fvfU+jc+9T0fvxoNqJkauzq4uxseY8HZ8 ftFc/PTZniIFCDMYDH0LlSTFUElG2kXmJYW5MWqrh38K/9IymdAsNlSkAGFL kysFTotoFNIT1tssJ+UkhfqJVLFHNsWDJWG5UodsJzy2E+6JwK0niQI7cl6/ 98Znl+e/9jE+YKPkkWPJl315MlSmyMugsHh5wIssvBelZEs9eWgGzkm9r6yU us6ymx2x8qYgMxYQIia6TolEci9qMvMY1cQ3Nwf3ziDjMS2qKevYqO3tmuhq Xr4ArV6xxpBX6vyzd/rxzc90ivg1Pj7Yug+4Y/BvdMqnJxeXvzemz6OUd2E7 TAKsab/WgdQjtO8fF59Oztpb3x1UB9E+yE1gdvgEHQJgU5q7U/CK5Vw30Fxl apyRH4bR37TgPjY0xehgZX871JhvDtZ4VKwJIrFknSPVwuPxm9Oj87H3+ejk 0vvr1fhq7L0fHx337S4LPyoGBy1OXOfZwpHWh8WkPenncIUD7PyGvALMGLSo yeC5Kv4A1b7lBqMtvKiXIIZSnpdr2Fu7rN/FPqDKPpO0n/6Lpi+VyRJ43mAW FTooypz8cZEpbQqKMgoaufWjmLWJzGyWL3egTX6RJVHguQ1oxJv717TylTq6 /Pjh5I13cnZy2d+zW77XOQIYDmrmfu4nuqgiABvFueCLopuMTaw6maplVio/ pFAgh2LnHFZR8LKEqWrBMkOFQEyZEjYuo3AnBO4SwcFDwRki9OXQB0vDLCgR vXLgo/zCBsrHzcd2IbnFneKrixYra002+fzog3phmUogyyRZKgqaS2JEZM2s HATQQnAT62khQ+AISIezoc0mURwVSyDIoSfFPmDENZFnOCRU89hfyhiw3wWX FGxkpI0gVqYgxHLRY86oP7Z6VhDoU481ZZr7QXHQI5Q/6TwApRRaEztbsWYY 5cUSfNyyPoLWRLfgqDsl2tAC5LkM8IP/NUrKpOFOBA6fMwvVIicZoxiWyNG5 g72ggxsFy4AkrILKrHzGUMGKv6Qs3fFfVmY85xnWaVVDfHOgY+DBv0VTCrEN KSEYONHFAhePGysgTIw29VrihlUhXn0ZJXJMaZZTbOS4RKSAbRM9hU9dWDgU hjb4woz2oMoH/1VmA8gsz9KsNPFyfQuKMjw79UC5vQq+M23cC4vWD5OZ+sMq U+/I1ZbpwVav5Rpx5frNKgHZ7TtA8+Z5Aifzx/O9ofphj37I/x+23//rUD3f 418/0oNneH535wySi/0h2gmpB5Q08b82bIXVKlYF4veChIEvJwsQM6HVxqJG CLPjtnpA0CokgZkCOoquuko+8Q/+sM/IKYvxHuHWguN/bcHZJ+KIwD2mpfFr Hz8ZUuuT/QGotaVnl4xNWC2c62JB7bTfk9lgq9Zo2Fu1zT9fUZwyOpywCaYN etFU9R9d5stT0rtP9KyPgcGAjQB8IZ0mVLL/uOXgyVb3ejLivAjtiIdYPjpM /DmtvR4d+h6FtaNDxnpegcfEXJOlS9U+fb4jPOyfeyQdq2Sz02rSfR/FoKfF HXpuqXmQFz2mp43mZnjfTqolDh/var615oAFcezlFBAwuz+fn1yOhxC+x8xY Gmc2tHl+Dx/IRPoUaUVFnyLmzxR8eCcfGRgIBn9529asU79MQyQoVmdRrNwj b/N5hjSMAgJ13E9u6zYyEXw+aReU8mT3oyJG0VgNk9fDw+liR4KKRPupcVZR qELahfQ1KU2hGLEGgCFDSCb9gYILjucz37nntDGZIyWTkQlWuOyzLUtpV83L a3BAhAGldu+aoApqHpkb0OTuMTuAQSYOl+Jk4nn+lIyNV3NwnZ+MzSoz71sO YUOg+KXUpfbYtuu+BcAB5IDEBz7QK+et5ywgcqU5ywottg+HQVyIFaZ4Weqk ZoCT4KwZq5dLwMkisvzkgCWrZGHUJ+04JaeG9JakyiLDXOcVzfxVSCzc4lh8 HpfX15gcZtpwfiwLgjKXcMRGpStodkb1bbtW0GXMs5+3C4MInYDm5DyJmc2A nONxZu1Q0TyEmr1rXXiTmbVbFDnK/sz6Jm/pBC2Le2HGip+Xqcc727nFFw+E sqqTXHkWKzrvPu01VJdHF7gvnJxdjs/Prz5dnrw+HVe25ZGlT1jL1gUWY0IH d8MAkS4qY83ycacWMwrcK4vUWESjtNnokPclPvCm51dntO27A5hXxMMPkzgv a6ZUInWsp34ZF83YguLJcJRNRycf6cKahsiA7Cj1z1DdxM9vEN6U81GRjTh0 ohkiBhzF1zK1U10wFhCdhgHEjQNhYNaQENrSOb4o42hpgwGUy1I5LzLszgID pNxiN9DHzGoWxyzrDq2TIZcVBZKklgw19iDtgEpLWCLH4/hiykkSiUaFviRJ JZdLnGumHRruTgBUd8TOXIKf5/5y2E5FBFmZFky3FdkNukRyIuufPoWsiUSA zVFGQ+v8ZoFkMsAT66OET5Vojkaye4NdnzmU57uj49o0zxJmBeNir2gScbJ4 7tjSg/gKsG9i8/FhfbM5Pb9iHhOQOJRMNYI9uf9xOIGpuEJExSNmcZ0+u/j1 7I3qP382aN6mhetAtONe3jQ8LUam+ivsTdcQM/c32e331aiY+QSrz1kJmCRA IsZXKRxk9I5Pzi9/xdo0p6HV7ElrBgOkSRRE9expMMTHj9VoRMsPaWjwgDxY YhwqIhL4w0MRgKMkmC3iB8DKMP549Ep4RLYL+Uq6IGtn4gpNUSMdjgfjuNk3 dq7dEHqxo1yPhOsJPMOqAScvOxXK6o4T2F4VqqnR+Ojd0ckZP0PMdqd0TBcP QLX5DCZGNmeNb2y+mmCxoXHb4/R6Ihy8+dOnvzOzD7aaqKuXVlCFhpo3+POB 4PxbCV6ntxGitvHvJoum34vKVvsovgmt1mWgaUOgyyiqOTPCUYszHNh1Z4Ml dVHeJr0OM3ff2cBQq08dFgIgWtaOXKkUxFzkZLGc56ieVWj+HeZNcj5Ef8O8 wdXmmiSQruAt6tmgwd8TLp1pRsl/hPqrfJTD3WjlnGXYbK0Y1kZLVY1+v2X6 HsPUEU/VJsOR2LtHSZsW6O67rN3WqoY/oKLteFdVN+iyCWNNPx/Stw036YYs bNSE+0TCBRL3qEgVAqxJnYXNcC3MDjVXb6DazYS2CDjAPXq1x5nmVLK27mrC FXZ3pWj4fbIjUdywFGIFbLBmK3ocmV0gihxQ6La0S6XfYJrZDFNzHUUOkaFo /EBNTb2MNq57A95RLEnR0ZLC3iQF+GbM0yffl/hzw8YBTLC16gH2NHOSIz/V krezubcZjer4VpsqkOESHV0O4IwmGhcqsRpc7/5sk10Uq3M+ngAtfDpGYhwJ la2bI2VG11+kywop6ksDxFQS5+groEu40cjyMwdtcIaZgrrN1ApVQjsXJxoH tyZUfL/g/Az9ofNcohSkFtTHFMl5Y2zudGRvaTP0HOAR/v6J7+9kIhYtN8CY DFev8OaAZ+8PeKnrTXBOomPms++C+6wBty4OozqCxzgSt6M7eBQZ0mYKYYNP gklpZAHEcAmzNikvM7gKAodqTyzLvfAZ5J/fAFMqXEPipNgdq1y0nDUWR8ma 4JlyXl/Y+Q97i9s2Ez71WhyIFjOhayrMKILmptDwxlwHkkyclGT45svzuIZr PDPpE1jc8P969fHSQ4DkXby2z3ihxWfiuGl3pFOFGZe/snnzs83byUrY9c4B C9JGRx2Paowrbq1TuD9YYV+aWVirl41O5nwHYHr6bTDvZbiTmwa7j8e/uKe1 AFQT/w5mVPfqXD8xNn2HMMc3CJ7IfhEAjfsdmSYyhDGHQmwMyTH56ZJv0qS3 gKzTIl7WaYNNnKhZJGivco7VYroWKZLF4lIjOQiksbiwgLasTBW5mBduSiP1 h9VsmPmt3va2CwXl0RCQcu5ZC8jGk6G9rrrP8qy8njmzz0uLrCCWVF0VQMDE UYKd0yylG3MPpoVjIBubWKa3CVU4jm+Vgl04hEIPGem3FyrhJsBUC8GGO+GK 3E+NLz18UpoiZLmhCotEhIbKVm65b2eIA3acYlfNazgj2ujuCokqIepeYXRP CFciXmZhO97K4FIRI2XJRh0NdGGZ2wa/ClMrv/bE2aVWJFOAnmt4Z0lyw7bb U5JTIR+NU0UGcFi5aXdKLArXPpoLxYmiG6ImqbWtO53vVB/FkuubJI7SG1Q1 pG1iaSRDBhVYEfe9jtgLrTkkq3MOaYhZZ1enp2CnvZPcRr4U3PhcSVB9dZv4 4vuVqA1C6WkzKYcnahtAq56ckDt11Lb8Hla1QSxrXjz4EFEx4N+v7LrRYShC UCdbWr6GjPlB09XYywpRukG020LK1UHrsWsnLX1DFBX1+ZNTlOZqRkJwWAFh JoQ8rxsdRh6jd49/+m/1SIzizg6CVjrCZY1tIyiBzDKe4pcrRIV3xDc4606L vS6jTqCY2xsEUsSjlQObhs1zF5HhX/UZO6GxHw66paQ+7KEEKI6A0fj10fFb Gmbgr9SUtLdP21rWP3I3wuuMOEK6i5V2y1eMyehw6lVbb5TIeruTs1+OTpvQ AYDO9s8/VeNP+slSzzHeLopry39UiOC5YFUgjOfLDVbQpcGbOj2RCrzD1qPA fmrrh7t8A3DGeZ5n6NGpzA/dU21tRILdHHlnPvxskfYf11Kqk0F1+mu796t5 tu6JuRKirtHWx5Ohcsq+51iO6SToj2gL66WQbMaZNSBVuyJK7dz1AVCokK0Q teUYRteJKf1mBOk5Pf7p2wS4YsP/C3FTiNcF8n9OrPb/d4kVumM5zjGIXimg m+EtBL5k6zBCZc0ng700KKlyAJkhwEQcgcZQRL1VvXaRIcVwnHEcmmhjXD6w bnBvFT24PXWashVndzXo/dtWr0//EHm8fNlvdbCqkfpxMFD/rjYOvxjwOMGg OX2BeA8UmaAOD9X+c7eufvzypVpbuf+Mdqg7mTHWQL7RKftb39H2/ujivbuc uHmPW827g987+0s80gGj84J+FZnMbnZT3tNcs9Lai1+v1GNGtkoYDm3ukDFK 88GGcpHNbTIQ6JCDxoUB26tCNyE4a5nSq9OgdYoUEsxPHr3iOG5gs6bN5Y/r hc08IbjAfcGe4wpzosTDm+/mhdusgblFjz9vTviu5XhdOQifOeu6So8D3qs2 dcvabAM/2F3WNHccv0ttbupBkMh1wg3nG6mfzOZgdJUe5+m/u4KIRYuw4vw1 DOtKSnugXl+969sKSv8R4AnHLGSpFq3Csc/vmqLhRrCwFqTGkj4Dbz2leR1P VyHyXh3z3NBqEUB4wNXm9cZuGVRP3cFjxsH6QdlWBlSQHzyoe2u2XVWEWso2 CmdbqBv86lVCUQ1L9zmS+jRvlXnNisYq95w4A50VCVKvAL1R1RBa+CFXNixt VtR7vbX11c53lQA18XIL1+XEjXQf62jERY9N5zpqn6voILnDrvLXJLM1sNW3 IVxLdqv4sKUU18hWS39tWeG+gu4mCisobWsnBZgN8ub6QZrbfd9m9xYbqyJp //EKB9ZxslsJus3Mb8fa3gPFI6aoQ5NQ16qBrWX3V19R2KR1sJzkFir/KJ6x KhSjZW8j1RRbZbnqHxyI5EvzytzpyCMr/FXf1HzVyfUaZte6YThI2b2z9aAS VswTujZOu6cFol0TdAjeOXo3nlUVOsKSuv5P14/jnBWSE9LPtYnf7XsG/3pQ /mq67HwyIhgP6a7/uDFQvU9VeRV3tXDXGV7mh2HnsqGqQ2kuuTThPSSnG9mB 6P7/Ek+Ynu9gjH3DxL68zNaVy5dNsyl9BWt9nFrBlFrj0hCu5kvaG43sw8LI PG7zxHqUhzjZ3RP+fRt3HGAn7s60Sy0cz0k1V3vw1kSnyjT27hcjuUs+kvcW k3mx7G/SAb5r3zPvu+Si13URPUG6/NaPIzRAVhQOpIhc5Hg3slXrHaLXRBq3 uZnvJkJLisLlFVnzjF/Bx800Muo6g0jhhnoJQFKdASygrfx44S8Nfy8AaiaG XxpXhM0U787U3cgL3yC9Os+MJLUoTPgb91IWGb/2bRtrZnRfJimWtnMAmnDx HE2k+c4WHlzOStNBLKrh1zrli3hpkOuJjCvrLOq6Dt+81UrhW70lf6S/+qgA qygLirj/9vTi9enPr6/eDmhgroPCNIkuMkYNjUCaELvlBgR5ocWhw0Ud4Yq5 ieZzLuyzUn7WhJPJ+HE1fTGLUKTHIs4YEjV4KV21UONXywI/5SjJJ5gpEvs+ M8fM/UC7t8ek1OGHzhZISptcWhRo4eLZx8vxT+oktb0XhPiCX05zvLYaiW8z 4E/wZqNEh5E/4lyzvuXNAaqwpT5BvMEl+e6ENJDj5WX9sJSvdLi278NZpFSY R7dy4GhLwCSuTme5a1oAUviCB27ToFWkvdnS0dc6TlQWAyksKisShW7KNHPf ChxH2EyXEtejQ2RrkLxpvIcUGcCqu+FJlKRX2h2JdGNwXSWDUPtTYqi/VCTu UmzqF/nSqkYhaR6LkGAjqCyESQ6Run+M2TnRyF4yyZnlO78mhz4PCww1MfSv 76gjQHUvWRIZDJh38cl2+LE0LFt08LUYqbzcjT9tD1prqbwFym9zZo77q+0j op3VW10LEnHSnMiPmUGkZmfyOp1VT9aNThGgLSJjWFKkStUSlb4rzbkmDbym UrdvDKS9TsmrH/xyxJqtCKSoS2YJHUd4Yb7DRgpB0D8+a+nQwet0QQaJT4PG m5nyPQn8RpLMwcMn8rrhEyafjaKR9nLyMHkWlgHMxknBhkrrUExUrkf85Rbc Vs2sx5uv5BBSzVS5dntRYDubW1WqBZGREyr5rRO8zrGQYgR//QlxEzV1BYVP MeITqxOUwCdZyCfM37xSmQ7eT4iSF25Q6AbLuUmbYDAs1oT0xmojIYG4GeUK +QKCXOM9yFWvkK7usGNFyL3JS1fhfekoQkd+8ytnWMtdgURmS5a1XvkMwHgx t5Vh0A+KkgSQsN+pmgqa4oGaqos7uCpmRW57Ul2QrOyveHgXN0RDlUojlon1 fFMvOeed8NNdaFpNNUXmyd997EpRTuhxXRxVIfbnEx1wMxqmo1sNgUC+/In2 wp62a/y+yIUOof+fzX37VxvHtubP4q9oc1ZsyZYAe+48LhifwTaOWbHBA3Zy cnKzdCXUQA9CraglE84J87dPfftVVf2QRJI7d7LOOkZSd3V1PXbtx7e/PRHv xs4e95gQypSOL188exaYZ+Z4mIjrK7bVQiOJbLusBjYqtyZZ8irZSfYYpC5j 4Ma21xNHiHzVgAxtESlFjkNHBMJfOY7WbMJF3cP9xzmTM6Sj8N5HgX+x5r4A w15BpJbx4Csh3SXEaHCjTOHzoJ3mVmKAKVmirVUuBx7BANMmB5drX5CBkN4I o2h2dYTG5R8su6klns14gGhz+GumM7c3rtubfqvtRqL23yabvolHgsqHXFMj guHkYUJA7TYkPbvSBbmr1WQgtCQxQDIDGns8XBRxh/1gL7H8ubs0rTwYPrBH j72X4NLyFRO1QS3QnhdwwLfOEpllI8+PcJnKUUU4Ii/g+N2Js8ELF7Z8vCUO B3rFlCj7iZrFYKP8xIYeIdoZgCOHIw0elMUwS9z6x5D3ZYT43FDaqkQBIC/6 OHr6rLl49Mw/ciJLeZrgD6QZYpNf0qCQIbZFY4QfaTf89O27T/3jk3dnyeME f/795Pjw48HZdz9v4ZLip52fySQbDsaAfsmyI//d4DpdWIo+feVmrO+kO/WN JwFtdBN9hKICm7MSJe7fezXNx5lTQH7bT87evD982//x6PDDW3IoIptFLpPU xTCBkMzLIBFRJx3sTMtzkRH4kowyDJ/kCnZ5uJ+6DfNVM/S8w9wNL9Cnbz4c HhybE8Wy0qSJII7BBAjwmdNfFb9snMc2aEwcTGozB6u8MDTpes0yZphWTORy MR5cFg2H+/xm6n/xKeoCCLhYjMeLKQv49XIZaYdrcqUzPdObaT6DESJ4eCJs wKFLz1LVptVMEeDHpNU6S+egCjiEpaUZ7JYl/jpN+k4jv+s7YTJLXc9ZxyQ7 Ee6A1wPjsIN2aRYp3Qz1X3rIhFLAfB6dgHNlMCYjiQBXzsBK5qDbgDaJWAHd PHJmwyhIDpiaPX9rmH9g6xksmXB3DwLqN6YCopNMuusuHxTJeOCsKManI4ke D3USiTt8NctvncEAsy13W5kz4E/EiHIP105oB5xx7n52piH3OL1Bxqj8xi2E yHGfXIoke2ep0W1tOdv293fIbhEw6q0B1rfgLrjhZFxjugFZIO6mt0I3++OB OyyMp4QMm/R8JkSN2bzghCwl4yE0puaFB6m8eMMtS45X1aOfzX4pBkhfr26X Lm8FSJVwLfPOxELeacrGddvElieGV9ao5hTh50c+OlZVvtwFYT5Q9GD6zR+2 5Jjo4/jei/P/HpW3nt1o2xSqtPTV/X+5s4LVOvmObQ9GdblFkU+aloyNrIyJ G9tZSj6w5cNrm9L1GxhhPev98hqxv6TgZeRW3i0WvjYn880WHzMpBFtLr9qV ucfgyBAAPFMSEYHg+KIjZ7LjC72X5x/xmFciQdGZ2P19w2BNkVfX+4+DFM4B Q4zz1Z7rhvTogeRH1y/oCOV+Jmn0WZEaTpzUqSdFyScljBo4xzVj8IdUk5gm F+4wJ1cG/InY48Uu8d1Iyk+89fGkDcKZZfOMEKHxo5xAI9cIud04I4hvm9wh c71InVohuHpDUuu9xB7oBBsDmwg8fZsKpyD15oLRp3kCiUMYJjdnAO+7JQNP svoQmPECaUszdtLIABA7pAzA25x3CQyQW7xlBrwk9KJdd92smLMnb1p+QfAw Uc69HYXsw2fDm5Qm9V5I0teA3AWXOXtpeQ8g05eoDKbdKN1nfpUXdqN7lO1d XEzdVtQ5saCA5JZ73S2NsLgiivDVCZSdCofClDPoYk+LOrvyWXYJwG9pPZFW RUBQ8HQIZSzTrA0k/cCYknDiuoeQk8oyWGl4WGHgTCm3PjhbbJ7cpXOfUpeo 556yXJEA18U4DhiHzOOH1jGumuWgFLbEZcectxjBwfz8SrIBWHp3yx5b8eiB BTZdCO8sRnOS3lbWt3XdJ6xdrMOdtxTjQxiXKCLEelyQ5EZAzhek7YPmjnwl TAz42F27VRP4XOqFsaMujAxRHwO/S8SR2XtFcJa9deKVkc1utjBJ86oTg70u NcG8Fh2V/6z+/phHp7UyAtowMg3egt/pTcHR2GppwnbsDtbQKJNdcLJHqxVR LXclHiUSVjY/E1Dwte7H1F3J/lTZoGPsbU56cCum0uhW0iYn1S3Ohh7Eo8ZJ 8vFIrkZPncxz0h+5OL2IGSu5lWwX+PrkeoRU8mmHP20v9SNFJFv2Laeblga2 cVjv1UNRu1Rrp7Zu6dZct0U+tr2NZU6ZP5CArTfV6ni64HlX9w6PTgTMEYzM 0txo29eN3YGccG3XMHrS/lZLzF0W5HYJvpk9UP67F4G6wWKV3ftsjUK7RVB1 Nk9OKIUqyXDIHbEGUJQ4BCUxeEAsevCv3fVkW6RkmwWnHesNRvHE2AGRyMRd YOdjWa35TPEk6Q1f1uVQLzcSHHXSCB1QIWPQgFirkJtn2dM+cG2sXuAirw4x EU5KUi9aCUifnVoDElF2Hcfnj0Vf9Rj0x6S9LR+quGCoFJIjy72RMDX1p8Ld sBa169rHU3BP6YSifMAlSxeRgmk6gLuRvkfGcDo4vyJkYNvpQczEXN3CU9tO TR7wksheSWlSL7aWbtjSji0Ls+WyTHymePs9L9bWol/QJGneg0fmp6TtoMZW vJ4QZE4uM4qRQ7JtcdR/RlULprN8OBi67biY3MAqV/3vogiUdY1LAqMBHYss Bdm0pLjDBuTwaLujvFSjWT6NrELjZvIKcsDCVXEMr0LGVBdgookoK1CQfHy0 NY+lHiezxWhdZ/Y3AWnqDwxbptR8Z40HhoCb5qdGsJy1H70K1CXr6OS6K9YP WWzD8TWLtmwuNR/geWM+xC4r/IQ6yIiDEfQYcYWNreQjfGriFSDNm8yT8cit ALgIu0k7S2UHID+mS1QVFBDmNGxItZuFE4MUsHXqTnaewYqhOG0GnFl+XXi2 G6zGS2ekzK9uLGacjnaTq3wKV+GYWHfnUK5oi7ht5CQm1CdgPwRcoq09/5et nRdb//piV5vB83C04biLd5azY7L5rrQNPmEKKDurh8Q0joU4V5szm+mggl2M nlUoittH1OuOyu161KybobXQshG2tcE5TbEjErElOK6H0XaVIlwDmyQDAxyp 6jcR93jlfvZmlYMhFjLZfpr0nie9V0jj1mg6HW0bRJWLX9ip5b+ky/13THDB HtUSDiM+BKMIiUQmLCgTu9eFtGOeO3P+ajAbyT3j7AZ8IkV+MQ+/oRQ1ms/9 Go55T6uGfCUUVOifvT969xkuyHzOYWoaH5kjjst0fKNP98Hii41dei6F6hFI EgrkLfAlbwnV9kar3PFllwslHzkT38Hz0WX2TkPwbIJEYdN8AK65LXPU8Zev KuPiPad6RaVLMAfbFlMiJ1vyOPn0rn98cnTSCVfc8z2vle7sRUS/vedlfiKl Twbd9Dpz/J8wmWtPTEizvREPeDjW8ej4QTO9gYB6DPHy8owkp5taAnt5PIts FR1HFZMSqL9YELE8+HXJboy8hEruPbiFNkuSDg9y88uqh7gXGZAnvwiOggvy LDhEoKuC1BScH0Rt9MRd+cTj4gJdIo5/2pyTZBQe0zoBYLYQX/Qy2fEjSS6S ShDVHOEHOCwv3DA8cS8KtIA7c/rE+wP6c35W15sCLTrubtKIoXI7ZgVKqIwU WJooCMJRN4bQOiNqPh8TyeXXO0u7Dtzl/AKvjPxsmTZaQz13fPL28HsTy3E6 IzmieWBX+rRpnCigtm8k+M/ilR2Q3WOlVpjT+FhgFAa0kCKDG9mAoUzqTKGt OOYNG+hKsHcA++bQghF9UsCSgSGxxJnowRiDQ2f7ylcNYSKB5z9CnUTDFhFv /7mPotmuPqxVgwi4ty4ELdmE/elze79x+LdPJ6egVvn4+uRDu+6hnT2VTwcq kogJLTWQNqOAyZCAySEXqaU9YCQWGminW5dbkFGMhp0r/rpwpw5wxM5Yggri jJX3HjpbJXlcp6SJzg1EV1YAUl4CGtRbqm5S4sstut8EXYovp5NnT88A/uVR mB+oi6E5z6wVgyOklT07p+VxwdvIIdzkJWvIdkWkSlqLV97ag7tMgNUTLq7O ZsEyORVwsQUk8NSQO1zM+nrNeXFhuzKGiS0uyjgxxca5W/aCMwWmv6C7vjs8 Pe4fnp4mm9+/O9sVLr7d5PPsTgJWlCtJ/xfCvuxVhu5cAZ6JWNjHGU5f7nun m0ixwoxW6LnTuxCXJct9ms/duRoG7gh1FA2BNLx0DEIxJrS1/Ko2hPyZukus QEMaq4475meMjmB8NtUiHFpOJg+UYG0R0Wn9T/pxN6jwMuRcTfcTdLRd0tSc fQnqvHladBjHTNOKiFnrtP5x3eh5wXJIpBxiy0DE0HeP5natchr53Aaklywm eCjsqCWWHA/C7017FMtLTTfYhHUm2zx3hnS8OwIRU/ZsBUZdVDni9PDgbVA4 ot5ptma7kbNMfuAgT1RuYNe4OMFrwX4B6GCII3rHElHN8xkAOAJh1+skObZg tULX0gzvmtQuRZhSgnRtyS+QzlaL47EYuEaVKgJDkmUAZgr6NPV05xbk8uhh J4D7704PD73E1kTTfbJ39FsDg1jMbINyqms6GRKzhznaUXUz8DXbR88AoNL7 AQNaFePlImgsKxqarBHpNfeXVYz6xrySccrZUlHNwwgkRnybiqKhaHDBzhuq Gctx6h7f0aP3tJIeiWvcVjXMm4tBNnamzl4Y3N9g+emfJ5gyRiKOSHshc8yn 0NG6TppzqWvGjipKlYnQ6sTIislZtuDDIQw89isWU5kioWGpSvr/ismPBUyZ zLjmhgjJeA5ciBM0W0qV9USsClhwElZ6d8awJfbdkV8ynL0uDIvBQjKVwGko qitXmPGX92Sy5864u9iSFEKUsSXUrbfi2m0axEBkUGHUUGbYXZ2OkbIEsmNd KVEeO7Nqjy7MEYDSEwGkkYvvciUYzjmMBiO0RQeej2zFEqPLgx8sBaO6llYv pqWraY3lFI0JRZ9X3hO4ofQ0iyVS/RbFYvSG2BXPzaocc4/lLdd1zC8uinQe WGoy14r7dWPMl+CgYq/V0d8Py2cbMHPvs8urj+mNx9kRtEFdEQSkQZVBdzxf UiJdynA/TUMVeCc9a3dDUQJyrAGosJ+0z509ljzttHec7Sgd93Hn6FIC4g1G IziNuEd2S4N1ySPp5f0bEqaMjZyCNH+WUYU7C7umEwmTDXh4iZSa0opRqVl4 8gkoDA3TaZ4IVyrCYovKVrOeGm8zsH5gcthKZZgal40LgmPieCudHBnK4Q7E S8GXkCjxRwdXpP5seE+4Ta2yJsWDxa9G72qnGUaQalGjSjNRlFG/yLCejbJJ AOnW+tv5ROLdAl9GS3Yowr8nlLUbLCSLcZpOIyxbJCCi0jS1p1Lp7IvWfVK3 8DErrDUvP+8o3014roId49YJUiIouuWWq1BkiYSUHRNsmCCuJz/2hM0jqDpg UZWag5k76ZEhHFOh0PAk7yOQIoEZrwaSX65eksv7aLctqmN1UBQ+vJKXJ2a0 anl3U5T/pJTgAZsJvz49N9h/ZP3zdNkGL3seQm9JGQ5rzFoqWvlNNf7NDh5j aoaehfDirST00ysCEiq/E0BQws4yyrss8EgSr3VKSckCnlwddx14/FMGZrdW aba+xIGcB6sPmw1m9xRrCP4sQtk6SbIl/JtBQTdvJ+kxJQe8yBrRToUpf9Kr KL1Aq5S/owZq6KrRWFfyfJkgRDAwXDwhlAIbDGcjf6zV+HXPer2Yl5C+yEAq WKbQNAKkQ3dPBzNxX1i2g4FzXB8Meq6lTJLBMP+ahvrJo4FyTUZnt/CeRv58 CG2nzGsR4mOuaYCFRn2x2CMS4SPNnryX9Jq0IEEp4E6CFtF5ovgDJY6fANea cbKHJNhMYjlLZ5Ai++SUFcu3SAgI15UQhKIHpeYvz1Wgv6nFwcQOMhrNqV4b 9VFbElYmNAPr/Y1wblEI3DV7TmH+qHKNnLE+gaZqs4uzapl/MLLU+QefE0rk d+JIjes41bireCNWU0Pi2ouaYlCtvxhf95E6seqq0/SXVZccp7erLnmLd6u5 qJHMqzYF5t775hJJDZQ9w0dMz5gYsLovip74z87ddpgPSE2yWeUQ4fYGwaFr Gqs9zKl0+cWUyTQt2gE99AN7zU0NVT1VLonqpVpKapDeuFd3oRVWlY5R6803 r7y3zW9hb9DQltY8FVYQCDgdVw15yHDuifwjcpMhAwWFt0Ps0PhGM7p86Dd4 9K5n6gkTP1W7KnU+LDulclhluT41yidzgqar4P1A7g/DTJFJXgk3oxa5VkR3 P1MGm1H8JO1JHl5Lq6Bjdnb0KJYx6cjnNmj+Grem/nOw80NqMNbGHXUEFvXY fRM5VzULtdnakjRkZ1P0jXWjUf/E/3dFDRXKhbh+32I267t2FUS5ch8EizsC iGnY35TZ6Jq9jUiDEa0m6glpidwT69SzmG0xrpsVaD2BuUiJfqAbIec447EE svpXswsDu/SlfxzpxKVzQOWyHybt556q3DKsvq7pFfwjamzrJiwWwzn0jR/S 0lYSFw0ZOuTYp+PYTt4nlHTyhN+B0hQtfcqjGHkpEhKV4hO4mdbFiAuJu3Vk gDloF6SuUHUS3gUoPEUKjsapnY6H89enmB5xyIE1CkFo3uazaziturFxOUDm Ad2EHef2hVPhR4SwSO9YUaa1grAdoqh40kKDIPze4Hp3gxIpTqLPG7LnUZ2o 502zE+F3Spid5z4cLkYf6TL1ph+3F4ZM4g3JW3slW6RswrlTOhXqdPS3j4e7 JbNTww5QasO0iQlqhlEpFeEiwqDILisZrtxh61bALF7ZskbMW7MxQzuQCylU vHyBfVc2n1p40YDctzbbNdguFDdytzSYmVHP46/FV4mIobhfys6Zujn2Xpof hLBpcC0aIwsNc8VwsZ7ANIDt41Y8KpGR/0Iim7KTmXnC7UmQPjH+0viJtI4N 45IHc0+BboWFYbEwkdYNVTiAQguojFiTlNj263ScnWcAJ1GJYr/xNKfxztl1 BkRl/jkF70uaOj9IU+XkpBpIJDDZ63Wik5g0AkVFaFlk11pPY25uZwuBEnY+ U8ZJEpuYyTRQktAmDp6wVPnd7eCOhJq6kfAvjwiY7kUQd2haCsB0Te5lUZYn AqG3M7ctqTHiW8+g6wto/EmIF5Oho6ni55AGfRFQzvXwopyKhDxVUQJcdwEG ub3KBYM2zc5pSJjyV+LMVAXoFrHvLTnvI1uDX4w4pcbQsfqqhj2YAtqpx312 v/BfVVxtE317NzhaVUZwG01Wi/y6t1FJYgh+qTE5+NfYXLBIvb/1PojHnnw+ fERMPTwx27bWnAU3dOch12nC1qWVsMs2QIsNoZbaTa2PrtucUolfj3P8r7W5 mFxP8tvJppthQnSNcn9ytjty5Y9p4S69yscprvtHOst7F3A+Y2HSj9SUrWZc 5Je2lVLCriNOs2yi93HD1O34pgHlrFq58cxMf8FAbr7F7t7EcU13s8ZgPGzI Smb/VJsH7ZmxXVhpR9NG+4zDg5Dgg5OAHGcfPwHu5/qbynmdcG0cZloVVBNI qit5Pv1+fbs1+RS1UQWbABCs2Iew2KLTevfKSFq6aG+145XVy1R5itfRc5sU 3VqdQW1KX3rIHbyoBmFfDcfXbk9QAmi9euyOYSFh4R+o0CgVlCAn8JuDN+8F 8QvBVG02PsazxJemPEOGdvJ8N8il91k140h144XzSCrqSFUfVquPQtIFydPw q7Ur3ApP5mqFbbSMZiO4z8kl5QGkDH4newKuR64tzHfyaAjuJiTPS+fnIOog vRQXfkhJFbbI6Ti/7Y3doTVGWFSxwfyieSHdAslKQSKEK3ckf9mhCCqT5FEC B4qD0S4zbm1vOdQQgrGTltO0vDCR9S4QGeVQkGwvyYGMabFC35I7MH0GWPOR oV7dZlWLlxahMJqNFFknL3YTI0Ux36aelzec+x6ujxofVh0jRfjTw5xbbxkt X7lotVpZ/4L/ZVcSopXlJniZlUUWolHlZoC0++H06POhomrWNAqTt9AjenUM HFIAd6JA4SbKkcDCESo1sTUPj0/OPr2heoUM/CZ/DpGkMOiAFjun1IkkGEHm F5Rw7V0WAX2DOtlVE+S8UGY2ENwCA1Vwu1MCiQ4ZKvA4FZQfb6A3mNvalwnl VyCshRFwG/GD8xzBFVmhOC+DmRTaPhVlwazWumtlx9Ys32Xrt9SxnRUbr372 f99qW/YW622r9fZV47K+X2tpSzEPGyVIryoxTjnBtEaTmM5Q3jlljWJdPSL0 KcHsCOz1eb5Uy7Dr+Hey3URyw75tVD2iHORSK2yBD3FCr1JS3D/QqX968TOK S5B6Pbzax7/uTsYtXAOPQBidwdQTDNmDsE/qVI5Gl93amox3cizTXvCsMN3U P/4Bis3QtBkQtZpE6IazwsytftEx9aX/fQ8luZJEzrzo1n2bz25St2UD75JE yI3j0+5M9sMWn9ng2B61C1/u0xqsL7gRvM8rZGHFhT/WiMr8JygiwlGyUhVp GainH0t5IyRdU2CVeGiZq7Q0yq908JzJikrz8zZtlGfY7zvBDnaqatC5cPxf +mkqtRHJAtcYrusFX1Ya1A5RMLDpEZwhOGLX1TSUiuUXFhqSFcO5rvTXlpOg 1TrKgZAqx0KZ7kvowPivZvD8+9qU6AG7BNXdaqmke/Zs36Bv9yVEIPGhj9iM NghQLxkzi9tNwFIldelxKrWlYdcXX4W+5LV42uvJVZUNZcOhHYw8ysLDcB8q YJH+9fd0RhspIHIK/F6mWw2Y2TNSlphSEQpTgvfn7c8J7XOysuC7COwqSwGg x3Do3R4laZOEQkAW+1THKNS1yqLVO4H/mMhjcBGCJTy1a4i9RpmzBOrfqua0 fFPskseGKnOr54hvf/Rvk82u0zHefTl+8/no5Ljf54W4dNvHjrK1N1w12840 KRmWXRtlHf5Q4XigVrlapXI7BZrdn6dRrak5oQ8CnWE2MdIPoyzBRv1ptXdn LR2opFCUNZiqgiFKxFpaxkOUi4ZNhUjnym1VPlV4B/kd0swf40efsNlB4se6 i3m9bND6fFD31mLgNpS4Ys5i5uJuqZVVXh/PwyPxfiOwNKIr8cLVBFSlEJXg 8MDWo9qxAw2PaKDjOgId0N0mS0I20Xw6z26w9og+d5AM88sFl6ARx6qmYFvN FY4RbCXvU3bFPUHIGZbtE/eJkRfKTnqL7PXo0cRDOEuLxVgoT9zbtMPEOnmx jhIFBiFU/WmjkcQ0ONDMGf8t6sg4SbJJJzAu3PSxK4La0hmkmfQylFKra0J1 TzYkY0Rj8nzzYJzN77YsLeImYHEJmwwoTRh/zDl1NkaDmOmr12PPdQw76miU rZZ3uuNrg5ETcnDpTwxJ4qdotQA66LEilYjt+OiEPJtGIOkhHrxdqUZexSm+ pv+7RlCb+DKI0FVeRNAOslEz0ffHa/nJ3T+D2ewnZJMBIvvp8LQPC+3nvRJi JDRt6U91sLOLfolrnQw+WFTm8vn/xXhllUwA12KSHv39EFQbdV36Y6761ljv 97W70UOvWPWedxoeHTnJ1Otg3v6qw6tyFHj7YpUNiR/lTV/KEgrLUFSMS11t zH3dqbHf7ssHVeWZpoeZj8MdjNnTYMntlKZ0lT11TdZq+M26tme169tPw0Ch xH9J1DHf7SgMdcRSKajT0nRGh8+jcibYjZPZzwakmMxiF34G70Zmfo52vdIR ep1p7CezThTZCaF1g4A3G6ycVcJsvic8jm7T8XjL4iNNB0udE7CM0DEf/fw2 r4YhqH0rsbODajovndBx/z57tpRyyl2Nocyods+D4hVRpxA4ILUriBs0dSeK DrDZy13oeFJwO2STxTzDURifqsGpJ4hG8by7Tc7AKwJbuGNNSIMVlgj8/Bfg T8SDuh2q/WR2Wj5QQBbGuUIjQMIsHofo91aS2GF2yZpAHyu1z8+uNyPG+cVF v5pPLglVfS7Y91QOr9BpKF/5o8qfkdXTDWK3a5hI4VBShyzGWVkT370++naP GLzwnzIfGfnTzH3z0+mHo49Hn/vvIPZ/3sJXKCUi5w/f4nYSruofHb8DC/KP 8JPQ4fXKXUFv3AnYpwoEdlx/22dH3/7t3dnfu/pATWYJvG33QqTDjflDYdh7 Vbgx+ZW5BaJ7giwhvu9xfPy413CnSGcvQWJBBiCOjOU2r+nF5dUWalXWrpIu 0GewOPb35/n+Pi97JT8gL8RG6+lTLuPIgVtqwzUYxZgnRI+OgUBygfRXeb2o UWomv1DklfsouqqiMx+HZyQNh9cZeol7QTCGSP4T38IyEusAp/K+zNCrpHw2 7/n1cXzy8fDjnhUOuZwNhv3gNJFF2eUVF2Fg4zmRBsu47TiSAYxcnKMU5Cpx y3DI0hvVtxeZ8cubu6+rShAi5wQ9aT+JP5jYnKwD5t6qpQVFmcCbHKUAzqtC a5T7jB2SJ5QGolT4GopUBLezjtKJh1VveVw/iZzakFAtWlpHYo3oTxnS+VQ2 2xpiK9LB95o09bKOHvV7kt72a6Xb9HKaQ+HjZEOnliyK8Bq4t7BBa30mS7Tp IJRkPOztUI11sowe7drgkXj1qrxzOnraolPRBmrp6yzbRdS897jqLd5nKBGI 7aee6I3zOw2A0dQziGhuntXJYO3bY0idq9kB8QWxMtZq6XjbsDjJ9H+Cx6Mu lr6SXftYfDii0kun5P7f9uNf6bHyZh1mzLgPR7k+LioHrna+awujy/p3q3Qm BLvApoAfEY1/n7RmXKBRRxoxzYiOxipyndrjoaiXzyP9kW6rau1Rq7U+y+a3 LT+L2hDdP2q3aUmsWBHqb4osvnCtbT8NyzNlbk+OJPsb6dy0coM1pEnAoSdu +6kmqX2lUh/QfIGcH8zuusjcG0Vf6XFabnnJ6uRnEHGggYmFUjxhpC5hCCWk wOU2EwY9+q3n1serxK/wx0uW++9Y79xFA06j7u9t9Np/BVfPlSTZ/EPDLDU5 HbbW8Jjakd9Yc2+VV1p0lOiZ6feQbiG4K2s3T3jUWsdeJmF+Q/OW4qtW7aS1 dlH5vSKtIQpsPd9dhtspWdhypx5ZGyZNahsJ91jNdm3Yrcs3a6SraD/uNwJ/ 3PqKRBVEQmLyz/HWeezIGgtwyeIzfbF5ksqzdF9R5vzo1IWJ1hucB4/AkvVJ z6IncOC+fpntWN+9cVrtPeXoPRUY2+8IcT3klcT2ZRWqrYZhyVNYUamSZ+5Z f2hA6HTKi8h+JIII8giGX6HrpFtyhFKiMRQqsSDMfc0Iy4oXN0Pkyq5Xkc0R wKO6DvrKW/aJxLzqTbeSpq8X1xrBtTqy91eO08nlHLQReYDSeogOL/p7Y/GK wCOxjorO/bGjKjpWyeYV/OhrOqdrD0ZndVnQh5uLWZqDh4RN85ehg/vBru0H GNFl67vBqP5TIwBCMz6JPLVkqBrf4iYP+6bHSZTCBS3e2mG4VhyynunI1MIm RLa6bUn1dO09ixu8N+/Vjo5Mg8vcvc97Z1bXTf9SdzMNsKZDBCdavTdf7LGz OQOTuRONz2womB0/UgtIgnty/kRzD7aSj+ZBoq+DjBhd0nVIqI31/PrxWK4E PYVeGC2+shTQVF/cxb3ml6urxdUWhS4Vh/0G5gKKWxCN1WIivPbLI/nVMayL mKj7Y0elG7rRrCbGJ4kSlfwu5ueHxPnraKKDZb/Br7n7QBdWrafKH18NCUr/ 4bFYypGVcy0+jdc64OJjxC0o98p3nO6l2yI2Te15geRvStKK9MxQu6QnSZ1j t/LYws0IW6bEP3b+xi/VdBBLydgBO4gDi9lN219rX+XVvn+XZ88JhhOaSkvC SgbT4yBOdnmFTpNha1RB+YyK0aQTfZ+19fEd72+tKOTegyu7s2oAxru0HHfu BdbY77TvqJc7XWsHZZN2q4bAsgHkumz3y4w/kkdoOuTjcZ1JqRonuiNlCcqp ZkTiA5IhLr1M1UkNW0FpmUMtmel+FO6oQkz+CfKAz91YIsMFmcWXA9QnxP2u z5Pc4y+0C04o17HBsLrxzxXIiDrIwEqejJqs+lpudgaWlSRs+OXyEH4jP375 rJJkDj2sWkEgeWXkOLIF4vz6ygB3fHK9MlQFJSndSkCtHFkQyxaDcvtUF8Na a6GyEFxnUPRtxToQIZur6vXgdVEz7c0VGqXZWfpLWQWpq9mYB2rIw+eOGqiZ v9K4YPpCc5rlyxAiY6Wtp2kx6xyh4YhyRdX1LC+U1IxJBvkbeoAhYpoyH1C5 U/RZ5ScK7644E9yGTM/n/aMTYjae3Zr7QHqZxLjZ6yx374Wv8W8tWQihpGIU VTRYSTX5OeuiuA/f0AWPxNfBuKJfWM7ePj/crYcQnKWmXWD5yWVm9Nkz3G9y 0XZklGyD5yIbjzxCj9jg6nEQ0hbBIbr66kuAGsYhuVWhkNxSJpLQrrOfxJoO OsoH2FeCu9YvBEzCY2zj2S3ix1Djk78mO8mupMVgb3ITIbo2Y5yOGwanFaDu KO9JJqyYyXbg2rRRJo0QzNKdTiQUV7gXUnBB5tST7IneZkD4e0Vn+Q5WkfCA yD82+JBlKtWZYI8DiNW2Fs5G1sBgQlFZK7DkASHaJRrXnzLAkHrPvxC9S12W SoAobuxic+KQJYQ09T1+RUpFDDpGC8H2sGp8Uyq+LUsZFQS5+Ioff1I3w12A NWY7iRe9raShO0nd/v6anrchB3COyi6P3Q3R7iuB1WjpFHPQc6PIufatrh+6 LROyZ0xc6e73RTmjis8zdzXKJxGZfLy/qDA8MazgR5FURye7Tg+nYrGUvI/C KVqyXK8BNflwcH4tvDFZzpysgDETJfOOQoQiipM4rZmbaqSZzqhkvLBVBIeE ylP+l9xLtfhdtGH3QwDIjXowTmfZV/cTCc0qAAxddTf0Jbmofa3S27cYgR38 SrBU8gFh5ICQCY+19MaJCcTqjk6YrBqHLVMyzzh3KSg77EbxDSXXx/UmmBws 4JMpDbbqNuiRHVIKx60f759+LpX7oEMm58OIdX76pkH9odMaC1Yk785eaLT7 owBYuF4vI4LivUT80HzTM2XvbeH0pmkSeF5VRXYXqOgqKVL4RaVBk98kuHvb 0z3NBlTcC2fy1ROGpMyAVUIu+2wEzFJucLGa/yg7E3fL6+SiXWGrnC+oOjpD xZv/G1D9W1KHT7ROOwvgWTFXD5GARsOBLnuj7qUqN4F1c55Rs9/4i70G3M4Z obpIGycqzau7AlUJkhnqkKJnwv3CLDRdJlSCCx1ZDm7xz7moBC7k3caLpUja VEuVqgIN6Gjs8dlIW4YLLYfFVOVuUvOVk8DUfa6uCbJaJqqzot0byjFrGNtd KputKEkuIsnquTRFfjb6QpeHduOIOG2x8fKwCozmgXhWSU9yK4RsLN7ZcC0K SbnLQ8eGO8W4DjHestCq2QG0KThYGvavikG6CLuXc4/cf0uY6ep2Oa2ePfnT e/vxye2JSeG2ziwd6VeZ/uEenk3sawxh8HF4FXwwZ1XUmZY/mktv1FI5Lcxx kVHWYghKgwxCnvzwqkh89RlFN0ehjhadupRDI+VFoYIRB/TY9ZCI1rAwiOwF IFxaOEUieTNL8cbaeZ4XL8Dacpj7AI4hgH77bYOzaNvxgR9cU8o0Pf7+4IM2 /Ehumkh9T7p0Ophk5+3N8FTijgF4pzw7bmluBohmGo+T75gte3ztxuR2IqsU e3REqZM0C0ckHqj2AH2+TQmLsqUDxGuDRDj/Gywk98kHMR48kt6zGI4muTWa TBjVosj2V4kp6fw8WLxiVEeje+BhQ99kXXMP9cPLpDTk9pN2Has08W26T5Bw P8lVP3ut1v2iKrgBkw++fPi85y0G5udOR6ZWt+jYY0tf3trqbLZa3uYd/sTz 8OwZP9DnD+Jn1twt+b7WrniwYRDnatDLRS7NIEGjzoWJG/RXcUnyV/JduIwC dcGGCtjjvuY14T+2QOQSbwwJZ4CqGcVPtE5pnPSHSk0ByxIRXl6SNq53IUbG 3xoyVopuhEGeZPNAUenWKsRiLcTtRayb9m0w1yZMg+6LxdymoLJRgjt547/6 QAk8wRen6S863n5JkJtwBU9D+FAjaqjjlqm5MJymtVqnSyUYlU3O249lo6kd olk9lm6BA1RVwxYLuxYlrZg/EqrEhZGgIbAxz3OuAC/XbvtNRGLN6bDfHZ30 kRt3dvjm84mWWMPipf5QvYM+HGlQw3lSAb1HWYQeiJ501/DWN40dnaVH4J8i 3jWGxd5nMHbNtuDjnNr1i78qSuSUNh2S/Qstv4d26VuRML1wH4gUfhbU24ig dlFZHx0TE907+nh1bMh+vMfYHKK8iyQVEDsBD1L4G20r+alFLmv/m6iTch8d a0eFamgTGF1Of4KDhViIITJoifgoE42JlMp7wCSuO4OV6aufO5248qy5KbKP UjUkaCBQcmLNbS1VH072DS2tZFlHTN0aZNYyp3qgPQOrzw8gJkk2W9BsVgR2 7I9ODacMaY2yVXVxpWGvV8ehypDgVVbKXjG4cKJhMJ5fkdZNyAD2aJxL8QfJ WcLtIWclyCrBK7TgtK1zeG0zTs82Yk3hYrbiY1ymiMLY5NipZi4zMz0KHuB+ +S8ssQ1/eXI9XowupUyV047T2QWsoMUlClwXTGMfJArrO5cczWFgulK6s6Lj L2WAXxq2CrRIfLfLD4YKGRpi2yebnd8FyaE+l9Jw68A1MWMlDXo5cricfLBM U/20PXSaGn4JTpvGghlLqN9+L9/gi5q0wT9IN8gix/dqOSFbA46vuLtBrbD6 BL7zHOE4ThZxF04GN1Izwx0Rf1pG3zKUGIVoPD7Wo8RKCSxV0NgFkaw/OBWL oTI9o0sXUixrss/G6FJEt1OIz6d3DNt2q13HzdpdO5Er7IwwVxzn8+xcvBC3 7ILou93Z9yUnhiLwZsIqaeenFBPwLNdFzrwRBIUgFuH57I69HVOt9jPX293l abphZK5c3VzbcmfS3RReI9cGEYUb17g7l6+ZNIFXVo+aMHyIpheIG4V4t61w FpE1cHjXPS5fzLfYXv188p5Ffz78mnFe9Xk+Q4SOySCZPZ9cNnaGefyYUmHU rwwj7PDzgNFXl2MEu2gGH9mh/5LP/HBFNoNt/Q7VlfZQ0BPuq6KezEWME4fd 8tjysDCWVrprOkWWIyW0ukFNBPw/tR5AtSAjNcBc/aznRABQ3gAUClDAcE35 QBkw1HSj8QwxBSxghb3k6bDGOye5y3VndzATDc4vPsllTGD1953GKmcvdQNP dAM06pelcFcf/O27T1zKda8kQktVyVazZNciZFm79myKYd0+qVsYOLkMExtU 9aipF2R99kBILsAnbi3qSW05DGGOsJdlbse4hcrG4FujquHc0Q2+56FbtFJ6 PIyWEV8/3Vu7LxvUP8Y0rKUA1kxS/dLy+ykifVEVHVNu5A+CYTeFam8pPtdu +83f9yVollGJFKt/7OsXWCXEAEP1qB3obXCdlrwexmAS+GAgoli0U+HiPXYG Vv0tZf3Ru5ji8pZ+QHze2hHBXiOedGENogmm0EfBdeMBWBpIJRddlFYQkxZ4 36No3X6gAcH9LB41/q2V1R+gmso4a7XH6kibxPzMSkE2waaScrNCyG6RzsKX Utz11WoHs8sFPOsbTLll5WGdeTi7yah8xgBBAHEASEtISxxM5pXaAiRjdV+s qMXzEJlakdLluAVLS1FE0aZyyRGc9B8ep3izGM8z1Axxb+P0UxRXRniMxkK9 DQqL5fIcsxEuIZHYdk/uwPHvxWrlAbfM4PBfn79IOJsS+o75XeJnvKTLfvtN uSnqqi67QZDXSaRet5ok8nXMNCMNv7RB6CQvg3bppBBsM2uhr14F42UEwJZN Eo7lkPffcIRDm2cXB8BkRuPiZTY+UReF7nHzWFVepQlzOuQ3BfE7ohno3taE DazEP0QZkLKQpQIEPHCy4AQWbPZKeNwPRRTTkRpmmCil2SaVo0GZjzmiLG4L HIyT77MZ50qIU3OUnrcf25FtPs26Y1lLOryHNBHPvO6efBILGi4SVTlXAnNc Noxa5Q86zaRgKT0uHTFmwb2wnLciNCi4xg++kcBB6Mi1XySYtVeq0bVtIWKO ihO+Fe/4/UckWLOzSqfwKju/IhI2cVcMldiRERdkb1DtMS1hRJSp6YgqK0nd 6MUUCFUex4K4/S68IfHh9Av5zNwxA0dyn+PRBqjB64dRbbe9c6QZBX3+mhVZ 4F4jkhXXEXZS+q4H5ba7Ym5xK7k4EiDAyeYDggTWUZK0g14heoMgRdgb17vZ 6s6Qh2KbuOwABjI6O6lEPmHjSzvDZXYxZIoBRjFdjjOQfMLfA0J7wVylgk4N ozUjp9xgXGj4vUijg4Emlyrr6uzekbsNPlnyn8K05G60X3QkfA/w1YgCT10q GpLIk7g+nVs4V4vL8ECjWgbqmCwVBM557SjhzQ05pXAdlWrzVIRWvZxKjmOD 6P14opRWp4HjZVYEgHhl0vKzFgzgkBcCvOrZJPGuoA6f0CNKymBDhv2xXD9r BNTQneGrvbzoWhG/m8HcncpU0IqWFxS+OXN/gWp4o6aKC5MHOHNfqqVQrWFW KOBeIFs858UCx61wS+lrZ/PwHQVqcZWPQ07Hsa6hAI0RVisTUUP6BVQs43LC +I/7JoaGd7a5ZV/jpydWbVBdxvII1ANdDGZuygRFkg9hE/oHas/JNxjJ1Q73 r8hn855bTOabX6TYWSUfJq0ymxNpm3w6eD+sE3bS1NhCHXFzSOXcsNZo+d0G oRCi5S+FnrGa2M+eX6cBh6eoDxXKEHjP4dOBgybJAGqbuyEqFVEmHakyLA92 JSRRGSOu6EtDlexzddHQDqikTQQIep9hUU2a4OorT+YiUJ3QDE4Yrle5FWbj OY1r3h+Az8v7kEXclpzIYnkEneYQWIXcDxpedETMyBF2K8RYKEWUfQV+SKU9 5GvQp7oufWCMe01/cIfboNm1a9GGbcyyhYZIQ3eVjtfQINbnM7Tiiap754a8 QquJLZ2ow2jWtCb5h+VG8DtFbK7ikIAVqYwD8ViysXc9rnpSGpD18y7CCsjV iuWh7oazAfN/O6EsONpUf2G0XfL6y7t3h6f911/Ofuy/Pvp81mq3n798qSF2 DufTZ4rud+w+ecHhoqCN0Wq1ZdyJfPgxvkPPWdtEK/qN2tTlB7u2pfP1Uklg U1VZx4KXZNzMyYnFeDAz2U10kxNoBXxqoM0nwTHgWitylbk/wK/rFE051BEc FP5jHMIoCUBBfRSkny0mE+KzyW/xeKmaOlrQQ+dxZeiiG5Y1oqZNs8Kh/Msi O78GgX9h1XG1RyhTuCtaBV7FXUpGhdcp3OFb6PE54zK/F+RpnOVjKCI+fCgn DbidXacofQ5UjVY4DcJRrEDLkjqjikywEVFckA9N6jXc+qLQAAV/RbBD2iHw 9bu3sCH2Aci6aa1zDkduoaiEeq04Z6RefayPepTqbiz66AJtlV3X2DSbiDNo PFuQ68NcQSs8RYr12atLvKMdQahg8yLiK5UI6ovkNsoIn1AA4IpH+4m4Y4Lu 8oKOe+y7tCEcTFyjWvQpt7bYkOoG6gDtTdILYxPKO1TNWRRZklWrakm4MZkq aqn5nWUAPThpP3ndf3d6eNhJzJ3Q4nC4xDc423sqKaryEwg6+JfCfpoSORCN V9At/rl2pHmg1XlVM9RsmIqo0GKtogKSouP3E4eSAe7oL6Y6cIQB0XYORCZ5 iaS+gDD+INjVJa7fVS63+K0q6z0orl5eq1RzhNkFuoF5mFLCBplTHC+UWr5U YpT9HRASLAdpnfBY/LF+qjTAVr/o66e2CQnxathlj5N+H179oxMfKqj++v7o 2/e4Aimx8E68zy6vPqY3UQkccn5VlM846WmSE5h1ZsuBQu2kfWnWlu+/KD8k HxrFlKlE90bhGnEa8GHqDiqFAGGtLaZ9O8H2lmXW1ghkzq11G7D8X/I2HS4u Lyn2XvMr8FEUZ3C2g3el4hsI7r9kF05rSN6cHL87+rZ/9vFTo2YuKjn4MWDp JlTM44LKu9OfYp3T31bWo8tmP18wKOb6SRqbYAntMRmbMyM4vg8w1vxumhY/ HZ/2PxydfUaW1z+TzTcfDg+ON7vJ5oeTN98dvsVfb49OP//o/rjf2/iLW9/Z BWJj4iJ8zZudz/9dd8p+899G16/hItzwoELWiMpi05PeECND7/lOh6SCNv2G wocNLcfKViAYyNfWS5Y+uenRlWkCNM0tEvaBOmseNtqVmLpfPqkZTjQLiIuP 3NPoWqMGot0sLZS3s/c67nHtFJonBkfzny8TmRv5QgHRwerQpWHrQheFrIHS cuBAhvbjJ2pVQPUUtEsiI05OtRY9hAMh9Rn2jJ3kz9XrPKsJXUYfa64yShi+ St4xuDCe0yuvXUvuY4GHRzuAOi6hJbMlqDIQ9jzZOXEEpzQydIZKoGue8OmN xFsVU27/BGNIneQJeUSnPPdL1/M3/1rs4jhPeq9k2r4ZdSXRNcUHXduaeuK3 KD9DBIHH3t4Hvvpv/rtr/ZvAK/vNeJFcI5TRxdc0IG0Mzf43o47b1Bv2mM1v Rok6ltyfvIDwByZE+rSqR9h1dcPy6tXzneB+tkN0grr22BGjmXXOOYyw/CgU SXTfIK4hk48mYCGv/y8o163FvLxzn05kARVK7VPSUfB83PHFKf3uJOPKM+Xb KAon8bzPH14nN1lRpAWJaAKKfjh4nTAyoqwssaVApwhCk5mdDvi7HcfNnDBj WabZhZRVV6rgzUlOFNm0sImZxNyHoONOKx4DNWnuJzFvRs7C6jI8aZbdkGMf 7i0F+2hPklfuDH7+L3sbwVdPGYqQ1+eldiyZkVMCSfJxpJm+QAhMm9rjr54R 8b/S5rBzzuYP/moWz5xH6+TyZUp4KqgkZLY61QNc/liPF1K6V/i1CHlFsNUx WXB5UtxAgSPgswjCeAo0E0FGGLkBPl7o32F7xRBANnHwWRSjtjaoTHQtEzw8 k/6O4iq7MBA4M02TLk9TgXwUJ4d23L8sAYN7IFXdl17/xHPrOvi0I7u3D8gP q0o0IW0ojgefTz4eURVkvGpoUYQts/4Oz2GvxzP9iqEisRLRq6zI1FnxWcpy jdfILsnMb8YjDtJ2WDyJdJEB6upeqJsOj631PQzAue8IeBKtKt2h1i33TMOf uuN7yj85rSqbFFua0laiaqCJ07oV/smcW69QIGvQyTpGMtQ2ZzqBNGdnVtiY k4uNgnFfHTxJsZgSzUKzgAxc2kWGYJViv0cDp5hNuohqOBnxv/OhBtJyxHi/ gpt5kIzuJgN3ZEPuzdJimk+KtOIc2kqSE/LFkFk+y4loBg+EexY8WOQ94tIa sLlIZHOJCTdTVbSEwEGQAlpogGOSXOZ0M4X4iOmczAvJEX17+ObDwelh/4eD o8/9//Xl8Mth//3hwdu2DJMZrCSaSxaGqvhq5fYJhz5bTOfwYyHsHLXB5xXe QWuTITh0M537it/Uz3w8CgYIWdVjDld4Fxo5AopE42luLoMgF45kG1UD1bu/ 3ehaIbNNLqqzya5BSjVGcsdtxlAU9I/02iFg6vC0YZzTSbGYmcjkI+KXhTsu nMnnukMFKaQaGb3Q3I0+XgkJxiOSrjyh1DJXRicT0VknTnJJDInfLXo1YU4J LG5WusNBI+ebux2jl09SG41KPj9Zsu6qiqXGgHde42Q90pUaeWPnS+F/4EFv kzQTp7q/Vw63vb3m2jnCybLMFVdS2VE4jAwyy4V1ejssd4xhnxNG2kJQpXU1 jbuKNeWoGCg7JHAQ2lgcn7w9/L4c0ymVElrPn1JFxIsDoYEbarZw1pI7BcW9 9Xj+Sx/7uNJiIJd4tWjqB3yNvOHccjsoVAW4QRZNkU/dPXMm1+tK5SXNK0/m iwln5M4GNwBRiSABxESE0maXzoURxamdlQ+BN0yxggsfi+YlKRFptxWyiztN 7ZWGu7gXu6Rbk/3umhREFxTIfIJDgg6BjUFByQQcukXBirvCZBAGGHtcGKLA 98J6IVbH+WCKVtpvDj71z3486x+8/Xh0HBifSe/w0+HpRz0X0Q6O7OdGfjrK ++mvGZhLgAOHn95tSdQGvmbxIdykwDpQ1aSB60QqcTS5lzaIs66THVjUlC3G Lv1CAA/Ys9i86a+DG0F5jQf/uOvd3PScrXBxIbiGWX7jTvsBXv6cgyBUAIXD 7OcIEAyGuSYiccA6ubkho9YZfRrbUwKyPb8pb2768tdT0Cn0b24kirlBeY16 XnIAekrldjgC4PEa2USORuZi6PKdcARSj/LF+ZXwwwhbQ1d9B6j/5a47v6Ij dDLP+dYnGAE2IZzQecIZUaPFeSp5VpxAIO/W4xaczKR7sVAnPGC2ITY07VLe EMm4cGf28Zz+fDzkfF6lQauISP51MvLXS0OdQDrIwIp1pmCw14NCUhhoeT13 av1gwjlivDFA9vNCvmWBbl+n83Pzp9DdTrd9oZzbbrygueL73guq6PdcBRvT okDrJKWp/+ng9OBj4Mzkxh5joe9b+qfCkOE0LxAaHV30p7ObLWwpp191UStp /rRDO4wzNdEUPuJpetbfZBMoY+7R9MvL4JfBryhRptnlcevw3ri/9sKe7IQe 0Cpnwb2i1b6S9x1vtGNgUESfhWjIKVOLwdjWsalFVD+KbDtpGjFsKGDpr6Ah zbDdr6k+RWcL8k2uosQR2sHuMXL7DYJrRXqT9YBqGpD6w37wqdP9UkI4E1z5 f3Sg5l266S3UhqypiRrK91LvWfWEwEnHF1ugFtE3HqaGsCFZITVhVVxQlW4F W9xi78kQUQ7MzDX3lahqnJSe0GpF932+Y58jjO2tra1OEohDMAcF1DJ8FeQB 7PZtjMvWuc9CDPTG5Cn1djENg3t0/qkwmpNFKKKMbQQMWeuHVFWnoZN6vSEp O8GdrNGJMStZO6gzQjdTgPMiveVjUchnnSzanOfTTbpxG0fe9ovtf6a/pt1Z ns+757eje7oZ/FVjpwnSTBeDiTawhfwpemJy7nqAwr+cSgraV6Gy2Gi59+m9 KtwCgzbKKAb6ano5m8pn9wJI8aKvkb7VTTZlzMzs4qru7mCnIANscqcd00Iy RaqfzX5x+gM9LruEZW26Ce9EuQvPIW0uu8T4gG2B7xqyxseqB1iHcAckv3uk 3eR1oObnbbQU5ddWrSegE3va0SXgZ1fTZeGsmbCtNM4vneaqMD7CvEKfJvwX bDhe/3QzFYPTrVKyeWilKtxlEpthdPPRJHF61LzLFWuQo6aPI6xXeAxmfCk/ k5q/hURRSVe4xdTuiMAoCKZFjwhf8IjQmTAXU8J5XizGBLbD6BCyVbrIoGFn OGiVZyeh09nVYMri4etgvCCVQS6X9T4kiOmYsYxAoVEpTmOFEsiCYHxvBjie LYMtUtwz3xOS5CSzh27it/hbOgjevD98813/8OPh6beHx29+dKrW8ZuNDaMW kfs9tchSlZ81t+WqeZDxL433nPV/iueqb5jKd9uDqbZ5NDsd8Wx7e7VPM9nP JxXD1TVYK5vFHSCqIItmkskIudtJBLpYN9LG4sgI3LkYqaREKT7E2QCEaYT4 FXAnULATHEPkFXKzeeNGyynOhBZGLjzHXj0xFfFr3TmRHvBGOkXpIrtczAg8 yg/W88Ff9O/8Hv/OS9xrr4nAM1nCh7p3x+M7RB9eU7QnJdnO2gwmg+gHf6+s lE6MTFg6cYTZZkM6u4S+KHqsfsseDVPn15Wjy0Sm+w2Hn/stm3xtPzbw6FA9 /tIYSne+OTn+DIBU8NXZ55NPnf+3ojfa8ajeyYOhE2KmA38qyQE/baJ7ymfF KlLfJK3p88HZd/2j48+Hp6dfPn0+ev3hkPZw4ZT30cLtQBgTzmLwbXCYysg/ MW19mavd+tYxfJ8O30bttpVoQxhaZOCFEITfmVkkyDEui8bAkHxc9sNZsBSw OS2lqQ8yrrV8rN2scKJ46JRtvk4escVP7Ca2HERpdt+P0mDVNV3ParTv2XMP r2xcVa311pX2ndvueBxDODcshCWk/Pbw9ZdvfbTuu8PT4z59ZxvWnZXm8XQq EzuZ1Yxq1RtjS9wl91F28twCSiLUKaJkPq847zbYIrJB5G4yZvaTNycfP304 /Hx0ctxHkd6jgw9Hfz88bYebKdaXLUfgsVzTTd58ODk+7L87c9te/jz6cOg/ uTk8Pvhg2eHgi/G9aj/2jyo9ScbyP+RJkY3iLHLsVRrGcEw7Gxv/F3gDLTgl KwEA ------=_20030327130820_88439 Content-Type: application/octet-stream; name="buffer-xfs12-lvm107-fixed.c.gz" Content-Disposition: attachment; filename="buffer-xfs12-lvm107-fixed.c.gz" Content-Transfer-Encoding: base64 H4sICGbogj4AA2J1ZmZlci14ZnMxMi1sdm0xMDctZml4ZWQuYwDsXHlz28hy /5v6FOOXKpuUSR127VZ5ZSuRLdpWVpb9dKyz2WxQIDAU8YSDxgCimV199/Sv ewYHCUr2SypVScXlkijMTE93T1/T3eDu9pbaViqO0vLr7tTsTsrpVOc7AT3l gTfZfJlH17NC9d8M1P6LF/tD/Hym1CktMeoyy2/9ODQ0eXdra1cWPXFQnqgo mcc60WlhVDHTSgZGgR/QH9MyDYooS82OOvcDPQqyNIz4gZr5txqgJlqnyr/N olCHarJUZ+Nfxucq1kURpdfKT1WUFjrPy3mhgpmfXmvl2z1UX38NND2fZjm2 BrTQL/yhyqYqyMrc6MGQ5hYEwhTaDyuowDPw45hghJmKih1Hm7oo/LxQk3Aa l2bWH6hFVMzUjc5THXvFLAeQNCuUWRqsVyP1yS9j9S7Li8SnacS5Z7svfnDQ znWS3RJZvoppEWFVpqkOtDF+viQMQ6IlDZUBB6NpRBOLGaFnaIsFffQLUFTz VAlPI5M+IWBlruZ5lDAkfj5SR2mY64W6zKPwWhN2wOXHmrS5ph3KOXHezIYq zsshbz/NtSbpMARzrnPfHpe6MlpdT+fEA7CXiM0CH8wDToCgCn8S66Eqad7F 6dFriwUmW3RnxC2CNDqmk/5QoXEU4qCfP7tx0yYE+YaY8B/aEA1ELgH0c61y /aWMcpqbxSFNOzr/ALYXOjE4Lpp6/uHnCuqlnA0d5Y7b0Q35ZpkGbjM+V6KC RfyFcMxXR3kAyYoj9dLnJ/9kiKydUB8ykH+I0iAu6bReihKRFE+j653Z4dqI IRaEXQNT0zk99iddz8GRzgWkCGnWCWnhzzc9D4q4cyiZe9ioa+w24QPvGprE N6G+7QS4NPmXTuKjWHc9j1I6r47nX8qs8LN5JweijE6ya2BGJizRSddQkoVl NwZBBuMFkd80SqjnGGsM+ibZLf0AetxehYEoW382iYo1avA8SUqPZKnQXwvZ ItTTKNXq7Nw7H1+Mz38ZH6v+/t72h6N/8V5fvfU+jc+9T0fvxoNqJkauzq4u xseY8HZ8ftFc/PTZniIFCDMYDH0LlSTFUElG2kXmJYW5MWqrh38K/9IymdAs NlSkAGFLkysFTotoFNIT1tssJ+UkhfqJVLFHNsWDJWG5UodsJzy2E+6JwK0n iQI7cl6/98Znl+e/9jE+YKPkkWPJl315MlSmyMugsHh5wIssvBelZEs9eWgG zkm9r6yUus6ymx2x8qYgMxYQIia6TolEci9qMvMY1cQ3Nwf3ziDjMS2qKevY qO3tmuhqXr4ArV6xxpBX6vyzd/rxzc90ivg1Pj7Yug+4Y/BvdMqnJxeXvzem z6OUd2E7TAKsab/WgdQjtO8fF59Oztpb3x1UB9E+yE1gdvgEHQJgU5q7U/CK 5Vw30FxlapyRH4bR37TgPjY0xehgZX871JhvDtZ4VKwJIrFknSPVwuPxm9Oj 87H3+ejk0vvr1fhq7L0fHx337S4LPyoGBy1OXOfZwpHWh8WkPenncIUD7PyG vALMGLSoyeC5Kv4A1b7lBqMtvKiXIIZSnpdr2Fu7rN/FPqDKPpO0n/6Lpi+V yRJ43mAWFTooypz8cZEpbQqKMgoaufWjmLWJzGyWL3egTX6RJVHguQ1oxJv7 17TylTq6/Pjh5I13cnZy2d+zW77XOQIYDmrmfu4nuqgiABvFueCLopuMTaw6 maplVio/pFAgh2LnHFZR8LKEqWrBMkOFQEyZEjYuo3AnBO4SwcFDwRki9OXQ B0vDLCgRvXLgo/zCBsrHzcd2IbnFneKrixYra002+fzog3phmUogyyRZKgqa S2JEZM2sHATQQnAT62khQ+AISIezoc0mURwVSyDIoSfFPmDENZFnOCRU89hf yhiw3wWXFGxkpI0gVqYgxHLRY86oP7Z6VhDoU481ZZr7QXHQI5Q/6TwApRRa EztbsWYY5cUSfNyyPoLWRLfgqDsl2tAC5LkM8IP/NUrKpOFOBA6fMwvVIicZ oxiWyNG5g72ggxsFy4AkrILKrHzGUMGKv6Qs3fFfVmY85xnWaVVDfHOgY+DB v0VTCrENKSEYONHFAhePGysgTIw29VrihlUhXn0ZJXJMaZZTbOS4RKSAbRM9 hU9dWDgUhjb4woz2oMoH/1VmA8gsz9KsNPFyfQuKMjw79UC5vQq+M23cC4vW D5OZ+sMqU+/I1ZbpwVav5Rpx5frNKgHZ7TtA8+Z5Aifzx/O9ofphj37I/x+2 3//rUD3f418/0oNneH535wySi/0h2gmpB5Q08b82bIXVKlYF4veChIEvJwsQ M6HVxqJGCLPjtnpA0CokgZkCOoquuko+8Q/+sM/IKYvxHuHWguN/bcHZJ+KI wD2mpfFrHz8ZUuuT/QGotaVnl4xNWC2c62JB7bTfk9lgq9Zo2Fu1zT9fUZwy OpywCaYNetFU9R9d5stT0rtP9KyPgcGAjQB8IZ0mVLL/uOXgyVb3ejLivAjt iIdYPjpM/DmtvR4d+h6FtaNDxnpegcfEXJOlS9U+fb4jPOyfeyQdq2Sz02rS fR/FoKfFHXpuqXmQFz2mp43mZnjfTqolDh/var615oAFcezlFBAwuz+fn1yO hxC+x8xYGmc2tHl+Dx/IRPoUaUVFnyLmzxR8eCcfGRgIBn9529asU79MQyQo VmdRrNwjb/N5hjSMAgJ13E9u6zYyEXw+aReU8mT3oyJG0VgNk9fDw+liR4KK RPupcVZRqELahfQ1KU2hGLEGgCFDSCb9gYILjucz37nntDGZIyWTkQlWuOyz LUtpV83La3BAhAGldu+aoApqHpkb0OTuMTuAQSYOl+Jk4nn+lIyNV3NwnZ+M zSoz71sOYUOg+KXUpfbYtuu+BcAB5IDEBz7QK+et5ywgcqU5ywottg+HQVyI FaZ4WeqkZoCT4KwZq5dLwMkisvzkgCWrZGHUJ+04JaeG9JakyiLDXOcVzfxV SCzc4lh8HpfX15gcZtpwfiwLgjKXcMRGpStodkb1bbtW0GXMs5+3C4MInYDm 5DyJmc2AnONxZu1Q0TyEmr1rXXiTmbVbFDnK/sz6Jm/pBC2Le2HGip+Xqcc7 27nFFw+EsqqTXHkWKzrvPu01VJdHF7gvnJxdjs/Prz5dnrw+HVe25ZGlT1jL 1gUWY0IHd8MAkS4qY83ycacWMwrcK4vUWESjtNnokPclPvCm51dntO27A5hX xMMPkzgva6ZUInWsp34ZF83YguLJcJRNRycf6cKahsiA7Cj1z1DdxM9vEN6U 81GRjTh0ohkiBhzF1zK1U10wFhCdhgHEjQNhYNaQENrSOb4o42hpgwGUy1I5 LzLszgIDpNxiN9DHzGoWxyzrDq2TIZcVBZKklgw19iDtgEpLWCLH4/hiykkS iUaFviRJJZdLnGumHRruTgBUd8TOXIKf5/5y2E5FBFmZFky3FdkNukRyIuuf PoWsiUSAzVFGQ+v8ZoFkMsAT66OET5Vojkaye4NdnzmU57uj49o0zxJmBeNi r2gScbJ47tjSg/gKsG9i8/FhfbM5Pb9iHhOQOJRMNYI9uf9xOIGpuEJExSNm cZ0+u/j17I3qP382aN6mhetAtONe3jQ8LUam+ivsTdcQM/c32e331aiY+QSr z1kJmCRAIsZXKRxk9I5Pzi9/xdo0p6HV7ElrBgOkSRRE9expMMTHj9VoRMsP aWjwgDxYYhwqIhL4w0MRgKMkmC3iB8DKMP549Ep4RLYL+Uq6IGtn4gpNUSMd jgfjuNk3dq7dEHqxo1yPhOsJPMOqAScvOxXK6o4T2F4VqqnR+Ojd0ckZP0PM dqd0TBcPQLX5DCZGNmeNb2y+mmCxoXHb4/R6Ihy8+dOnvzOzD7aaqKuXVlCF hpo3+POB4PxbCV6ntxGitvHvJoum34vKVvsovgmt1mWgaUOgyyiqOTPCUYsz HNh1Z4MldVHeJr0OM3ff2cBQq08dFgIgWtaOXKkUxFzkZLGc56ieVWj+HeZN cj5Ef8O8wdXmmiSQruAt6tmgwd8TLp1pRsl/hPqrfJTD3WjlnGXYbK0Y1kZL VY1+v2X6HsPUEU/VJsOR2LtHSZsW6O67rN3WqoY/oKLteFdVN+iyCWNNPx/S tw036YYsbNSE+0TCBRL3qEgVAqxJnYXNcC3MDjVXb6DazYS2CDjAPXq1x5nm VLK27mrCFXZ3pWj4fbIjUdywFGIFbLBmK3ocmV0gihxQ6La0S6XfYJrZDFNz HUUOkaFo/EBNTb2MNq57A95RLEnR0ZLC3iQF+GbM0yffl/hzw8YBTLC16gH2 NHOSIz/VkrezubcZjer4VpsqkOESHV0O4IwmGhcqsRpc7/5sk10Uq3M+ngAt fDpGYhwJla2bI2VG11+kywop6ksDxFQS5+groEu40cjyMwdtcIaZgrrN1ApV QjsXJxoHtyZUfL/g/Az9ofNcohSkFtTHFMl5Y2zudGRvaTP0HOAR/v6J7+9k IhYtN8CYDFev8OaAZ+8PeKnrTXBOomPms++C+6wBty4OozqCxzgSt6M7eBQZ 0mYKYYNPgklpZAHEcAmzNikvM7gKAodqTyzLvfAZ5J/fAFMqXEPipNgdq1y0 nDUWR8ma4JlyXl/Y+Q97i9s2Ez71WhyIFjOhayrMKILmptDwxlwHkkyclGT4 5svzuIZrPDPpE1jc8P969fHSQ4DkXby2z3ihxWfiuGl3pFOFGZe/snnzs83b yUrY9c4BC9JGRx2Paowrbq1TuD9YYV+aWVirl41O5nwHYHr6bTDvZbiTmwa7 j8e/uKe1AFQT/w5mVPfqXD8xNn2HMMc3CJ7IfhEAjfsdmSYyhDGHQmwMyTH5 6ZJv0qS3gKzTIl7WaYNNnKhZJGivco7VYroWKZLF4lIjOQiksbiwgLasTBW5 mBduSiP1h9VsmPmt3va2CwXl0RCQcu5ZC8jGk6G9rrrP8qy8njmzz0uLrCCW VF0VQMDEUYKd0yylG3MPpoVjIBubWKa3CVU4jm+Vgl04hEIPGem3FyrhJsBU C8GGO+GK3E+NLz18UpoiZLmhCotEhIbKVm65b2eIA3acYlfNazgj2ujuCokq IeqbhZHwJQbITGzJ2xlcLGKkLdmwo4kuLHPb5Fdha2XYnjq71YpsCtJzDQ8t iW7Yd3tScjLkp3GyyAIOK1ftTorF4dpHg6E4UnRE1GS1tnUn9J0qpFh6fZPE UXqDyoa0TiyNZMmgBisiv9cRf6E9h+R1zmENMevs6vQU7LT3ktvIl6Ibny0J q69uE1/8vxLVQTg9bSbm8ERtA2jVlxNyt47alt/Dqj6IZc3LBx8iqgb8+5Vd NzoMRRDqhEvL35BBP2i6G3thIUo3iHdbULlCaL127aild4gioz5/csrSXM1I CA4rIMyEkOd1o8PIY/Tu8VH/rV6JUdzZQeBKR7issW0EJpBZxlN8c4Wo8I74 BofdabXXZdQJFHN7g0CKeLTyYNOwee4iMvyrPmMnNPbDQbeU1Ic9lCDFETAa vz46fkvDDPyVmpL29mlby/pH7lZ4nRFHSHex0m75ijEZHU69auuNEllvd3L2 y9FpEzoA0Nn++adq/Ek/Weo5zttFgW35jwpRPBetCoTyfMHBCro4eFOnJ1KF d9h6FNxPbQ1xl28BzkDP8wx9OpX5obuqrY9IwJsj98yHny3S/uNaSnUyqE5/ bfd+Nc/WPjFXwtQ12vp4MlRO2fccyzGdBP0RbWE9FRLOOLMGpGpXRKqduz4A ClWyFaK2HMPoSjGl34wgPafHP32bAFds+H8hbgrxukD+z4nV/v8usUKHLMc6 BhEsBXUzvInAF20dRqiu+WSwlwZlVQ4iMwSZiCPQHIrIt6rZLjKkGY4zjkUT bYzLCdZN7q3CB7eoTlO24uyuBr1/2+r16R8ij5cv+60uVjVSPw4G6t/VxuEX Ax4nGDSnLxDvgSIT1OGh2n/u1tWPX75Uayv3n9EOdTczxhrIN7plf+s72t4f Xbx3MaGb97jVwDv4vbPHxCMdMDov6FeRyexmR+U9DTYr7b349Uo9ZmSrpOHQ 5g8ZozQfbCgZ2fwmA4EOOWhcHLD9KnQbgrOWKb06FVqnSSHB/OTRK47jBjZz 2lz+uF7YzBWCC9wb7DmuMCdKPLz5bl64zRqYW/T48+ak71qe15WE8Jkzr6v0 OOC9alO3rM028IPdZU1zx/G79OamPgSJXCfcdL6R+slsDkZXKXKe/rsrili0 CCvOYcOwrqS1B+r11bu+raL0HwGecMxClorRKhz7/K4pGm4EC2tBaizpM/DW U5rX8XQVIu/VMc8NrRYChAdccV5v7pZB9dQdPGYcrB+UbWdAFfnBg7q3bttV SailbKNwtoW6wa9eJRTVsHSgI7FP81aZ16xqrHLPiTPQWZEg9QrQG5UNoYUf cnXD0mZFvddbW1/tfFcJUBMvt3BdTtxI97GORlz42HSuo/a5ig6SO+wqgU0y WwdbfSPCtWW3ChBbSnGdbLX815YV7i3obqSwgtK2dlKE2SBvriekud33bXZv wbEqlPYfr3BgHSe7laDbzP52rO09UEBiijo0CbWtGthahn/1NYVNWgfLSW6h 8o/iGatiMdr2NlJNsVWWq/7BgUi+NLDMnY48ssJf9U7NV51cr2F2rRuGg5Td O9sPKmHFPKFr47R72iDadUGH4J2jd+NZVaEjLKnrAXU9Oc5ZITkhPV2b+N2+ Z/CvB+WvpsvOJyOC8ZDu+o8bA9U7VZVXcVcLd53hZX4Ydi4bqjqU5rJLE95D crqRHYju/y/xhOn5DsbYt0zsC8xsXbmE2TSb0luw1supFUypNS4N4Wq+qL3R yD4sjMzjNk+sR3mIk9194d+3cccBduLuTLvUw/GcVHO1D29NdKpMY+9+MZK7 5CN5dzGZF8v+Jh3gu/Y9875LLnpdF9ETpMtv/ThCE2RF4UAKyUWO9yNb9d4h +k2keZsb+m4itKUoXF6RNc/4NXzcTCOjrjOIFG6olwAkFRrAAtrKjxf+0vB3 A6BuYvjFcUXYTPH+TN2RvPAN0qvzzEhSi8KEv3E/ZZHxq9+2uWZG92WSYmk9 B6AJF9DRSJrvbOHB5aw0HcSiIn6tU76Ilwa5nsi40s6iru3wzVutFL/VW/JH +quPKrCKsqCI+29PL16f/vz66u2ABuY6KEyT6CJj1NAMpAmxW25CkJdaHDpc 2BGumJtoPufiPivlZ004mYwfV9MXswiFeizijCFRgxfTVQs1fr0s8FOOknyC mSKx7zNzzNwPtHuDTEodfuhsgaS0yaVFgRYunn28HP+kTlLbf0GIL/gFNcdr q5H4RgP+BG82SnQY+SPONetb3hygClvuE8QbXJLvT0gDOV5e1g9L+VqHa/tO nEVKhXl0KweO1gRM4gp1lrvGBSCFL3ngVg1aRdqbLR19reNEdTGQ4qKyIlHo pkwz963AcYTNdClxPTpEtgbJm8a7SJEBrLojnkRJ+qXdkUhHBtdVMgi1PyWG +ktF4i7Fpn6RL61qFJLmsQgJNoLKQpjkEKl7yJidE43sJZOcWb7zq3Lo9bDA UBNDD/uOOgJU96IlkcGAeRefbIcfS9OyRQdfjZHKC9740/ahtZbKm6D8Rmfm uL/aQiLaWb3ZtSARJ82J/JgZRGp2Jq/UWfVk3egUAdoiMoYlRapULVHpu9Kc a9TAqyp1C8dAWuyUvP7BL0is2YpACrtkltB1hJfmO2ykEAT947OWLh28Uhdk kPg0aLydKd+VwG8lyRw8fCKvHD5h8tkoGmkxJw+TZ2EZwGycFGyotA7FROV6 xF9wwa3VzHq8/UoOIdVMlWu5FwW2s7ldpVoQGTmhkt88wSsdCylG8FegEDdR V1dQ+BQjPrE6QRl8koV8wvztK5Xp4P2EKHnpBsVusJwbtQkGw2JNSG+sNhIS iJtRrpAvIcg13oVc9Qrp6g47VoTc27x0Fd6XriJ05Te/doa13BVIZLZkWeuV zwCMF3NrGQb9oChJAAn7naqxoCkeqKm6uIOrYlbktifVBcnK/oqHd3FDNFSp NGOZWM839ZNz3gk/3YWm1VhTZJ783ceuFOWEHtfFURVifz7RATekYTo61hAI 5MufaC/saTvH74tc6BD66X829+1fbRzbmj+Lv6LNWbElWwLsufO4YHwG2zhm xQYP2MnJyc3SlVADPQi1opZMOCfM3z717VdV9UMSSe7cyTrrGEnd1dX12LUf 3/62eDd29rjHhFKmlHz54tmzwDwzx8NEXF+xrRYaSWTbZTXQUbk1yZJXyU6y x0B1GQM3tr2eOELkqwZ0aIuIKXIcOiIQ/spxtGYTLuoe7j/OmaAhHYX3Pgr8 izX3BTj2Ciq1jAlfCesuoUaDG2UKnwftNLcSg0zJEm2tcjnwCAa4Njm4XPuC DoT0RhhFM6wjRC7/YBlOLfFsxgNEm8NfM525vXHd3vRbbTcStf822fRNPBJk PuSaGhEMKQ+TAmq3IenZlS7IXa0mA6ElyQGSHdDY4+GiiDvsB3uJ5c/dpWnl wfCBPXrsvQSXlq+YqA1qgfa8gAO+dZbILBt5joTLVI4qwhJ5AcfvTrwNXriw 5eMtcTjQK6ZE2U/ULAYb5Sc29AjRzgAgORxp8KAshlni1j+GvC8jxOeG0lYl CgB50cfR02fNxaNn/pETYcrTBH8g1RCb/JIGhQyxLRoj/Ei74adv333qH5+8 O0seJ/jz7yfHhx8Pzr77eQuXFD/t/Ewm2XAwBvxLlh357wbX6cLS9OkrN2N9 J92pbzwJaKOb6CMUGdicmShx/96raT7OnALy235y9ub94dv+j0eHH96SQxEZ LXKZpC+GSYRkXgbJiDrpYGhano+MwJdklWH4JF+wy8P91G2Yr5ql5x3mbniB QH3z4fDg2JwolpkmTQRxDCZBgM+c/qr4ZeNctkFj8mBSmz1Y5YahSddrlrHD tGIyl4vx4LJoONznN1P/i09TF0DAxWI8XkxZwK+Xz0g7XBMsnemZ3kzzGYwQ wcQTaQMOXXqWqjatZpoAPyat1lk6B13AISwtzWK3TPHXadJ3Gvld3wmTWep6 zjom2YlwB7weGI8dtEuzSOlmqP/SQyaVAu7z6AS8K4MxGUkEuHIGVjIH5Qa0 ScQK6OaRMxtGQYLA1Oz5W8P9A1/PgMmEu3sQ0L8xHRCdZNJdd/mgSMYDZ0Ux Rh2J9Hiok0jc4atZfusMBphtudvKnAV/IkaUe7h2QjvgjHP3szMNucfpDbJG 5TduIUSP+wRTJNo7S41ua8vZtr+/Q3aLAFJvDbS+BXfBDSfkGtsNCANxN70V utkfD9xhYVwlZNik5zMha8zmBSdlKSEPITI1NzxI58UbblmCvKoe/Wz2SzFA Cnt1u3R5K0CqhGuZdyYW8k5TRq7bJrY8MbyyRjWvCD8/8tGxqvLlLghzgqIH 02/+sCXHRB/H916cA/iovPXsRtumUKWlr+7/y50VrNbJd2x7MKrLLYp80rRk bGRlTNzYzlLygS0fXtuUrt/ACetZ75fXiP0lBS8jt/JusfC1OZlvtviYTSHY WnrVrsw9BkeGAOCZkogIBMcXHTmTHV/ovTwHice8EhGKzsTu7xsGa4q8ut5/ HKRxDhhmnK/2XDekSA8kR7p+QUdI9zNJpc+K1LDipE49KUo+KWHVwDmuWYM/ pJrINLlwhzm5MuBPxB4vdonzRtJ+4q2PJ20QziybZ4QIjR/lBBq5RsjtxllB fNvkDtnrRerUCsHWG5Ja7yUGQSfYGNhE4OnbVHgFqTcXjD7NE0gcwjC5OQOA 3y0ZeJLVh8CsF0hdmrGTRgaAGCJlAN7mvEtggNziLTPgJaEX7brrZsWcPXnT 8guCi4ny7u0oZB8+G96kNKn3QhK/BuQuuMzZS8t7ANm+RGcw7UYpP/OrvLAb 3aNs7+Ji6raizokJBUS33OtuaYTFFVGEr06g7FR4FKacRRd7WtTZlc+ySwB+ S+uJtCoCgoKrQ2hjmWptICkIxpaEE9c9hJxUlsVKw8MKA2dLufXBGWPz5C6d +7S6RD33lOmKJLguxnHAOGQeP7SOcdVMB6WxJT475r3FCA7m51eSEcDSu1v2 2IpHD0yw6UK4ZzGak/S2sr6t6z5p7WId/rylGB/CuEQRIdbjgkQ3AnK+IG0f VHfkK2FywMfu2q2awOdSL4wddWFkiPoY+F0inszeK4Kz7K0Tr4xsdrOFSZpX nRjsdakJ5rXoqPxn9ffHPDqtlRHQhpFp8Bb8Tm8KjsZWS5O2Y3ewhkaZ8IKT PVqtiG65K/EokbCy+ZmEgq91P6buSvanygYdY29z0oNbMZVGt5I2OalucTb0 IB41TpKPR3I1eupknpP+yMfpRexYya1ku8DXJ9cjpJJPO/xpe6kfKSLasm85 5bQ0sI3Deq8eitqlWju1dUu35rot8rHtbSxzyvyBJGy9qVbH0wXPu7p3eHQi YI5gZJbmR9u+buwO5IRru4bVk/a3WmLusiC/S/DN7IHy370I1A0Wq+zeZ2sU 2i2CqrN5ckJpVEmGQ+6INYCixCMoycEDYtKDf+2uJ9siJdssOO1YbzCaJ8YO iEQm/gI7H8tqzWeKJ0lv+LIuh3q5keCok0bogApZgwbEXIX8PMug9oFrY/YC H3l1iIl0UhJ70UpA/OzUGhCJsus4Pn8s+qrHoD8m7W35UMUFQ6WRHFnujYSp qT8V/oa16F3XPp6Ce0onFOUELlm6iBRM0wHcjfQ9sobTwfkVIQPbTg9iNubq Fp7admrygJdE9kpak3qxtXTDlnZsWZgtl2XiM8Xb73mxthYFgyZK8x48Mj8l bQc1tuL1hCBzcplRjBySbYuj/jOqXDCd5cPB0G3HxeQGVrnqfxdFoKxrXBIY DehYZCnIpiXFHTYgh0fbHeWmGs3yaWQVGj+TV5ADJq6KY3gVMqa6ABNNRFmB guTjo615LPU4mS1G6zqzvwlIU39g2DKl5jtrPDAE3DQ/NYLlrP3oVaAuWUcn 112xfshiG46vWbRlc6n7AM8bcyJ2WeEn1EFGPIygyIirbGwlH+FTE68Aad5k noxHbgXARdhN2lkqOwD5MV2iq6CAMKdiQ6rdLJwYpICtU3ey8wxWDMVpM+DM 8uvCM95gNV46I2V+dWMx43S0m1zlU7gKx8S8O4dyRVvEbSMnMaE+Afsh4BJt 7fm/bO282PrXF7vaDJ6How3HXbyznB2TzXelbXAKU0DZWT0kpnEsxPnanN1M BxXsYvSsQlPcPqJed1Ru16Nm3QythZaNsK0NzmmKHZGILcFxPYy2qzThGtgk GRjgSFW/ifjHK/ezN6scDLGQyfbTpPc86b1CKrdG0+lo2yC6XPzCTi3/JV3u v2OSC/aolnAY8SEYRUgkMmFBmdi9LsQd89yZ81eD2UjuGWc34BQp8ot5+A2l qNF87tfwzHtqNeQroahC/+z90bvPcEHmcw5T0/jIHHFcpuMbfboPJl9s7NJz KVSPQJLQIG+BM3lL6LY3WuWOL7tcaPnImfgOno8uM3gagmcTRAqb5gNwzW2Z o46/fFUZF+851SsqXYI52LaYEjnZksfJp3f945Ojk0644p7vea10Zy8i++09 L3MUKYUyKKfXmeP/hMlce2JCqu2NeMDDsY5Hxw+a6Q0E1GOIl5dnJDnd1BLY y+NZZKvoOKqYlED9xYLI5cGxS3Zj5CVUgu/BLbRZknR4kJtfVj3EvciAPPlF cBRclGfBIQJdFaSm4PwgeqMn7sonHhcX6BJx/NPmnCSjcJnWCQCzhfiil8mO H0lykVSCqOYIP8BheeGG4Yl7UaAF3JnTJ+4fUKDzs7reFGjRcXeTRiyV2zEz UEKlpMDUREEQjroxhNYZUfP5mIguv95Z2nXgLucXeGUEaMu00Rr6ueOTt4ff m1iO0xnJEc0Du9KnTeNEAbV9I8J/Fq/sgPAeK7XCnsbHAqMwoIUUGdzIBgxl YmcKbcUxb9hAV4K9A9g3hxaM6JMClgwMiSXORA/GGhw621e+aggTCTz/Eeok GraIfPvPfRTNdvVhrRpEwL11IWjJJuxPn9v7jcO/fTo5Bb3Kx9cnH9p1D+3s qXw6UJFEbGipgbQZBUyGBEwOuUgt7QEjsdBAO9263IKMYjTsXPHXhTt1gCN2 xhJUEGesvPfQ2SrR4zplTXRuILqyApDyEtCg3lJ1kxJfbtH9JuhSfDmdPHt6 BvAvj8L8QF0MzXlmrRgcIa3s2TktjwveRg7hJi9ZQ7YrIlXSWrzy1h7cZQKs nnRxdTYLlsmpgIstIIGnhvzhYtbXa86LC9uVMUxscVHGiSk2zt2yF5wpMP0F 3fXd4elx//D0NNn8/t3ZrvDx7SafZ3cSsKJcSfq/EPZlrzJ05wrwTMTEPs5w +nLfO91EChZmtELPnd6FuCxZ7tN87s7VMHBHqKNoCKThpWMQijGhruVXtSHk z9RdYgUa0lh13DE/Y3QE47OpHuHQcjJ5oARri4hO63/Sj7tBlZch52q6n6Cj 7ZKm5uxL0OfN06LDOGaaVkTMWqf1j+tGzwuWQyIlEVsGIoa+ezS3a5XTyOc2 IL1kMcFDYUctseR4EH5v2qNYXmq6wSasM9nmuTOk490RiJiyZysw6qLqEaeH B2+D4hH1TrM1242cZfIDB3mikgO7xscJXgv2C0AHQxzRO5aIbp7PAMARCLte J8mxBatVupZmeNekdinClBKka8t+gXi2WiCPxcA1KlURGJIsAzBT0Keppzy3 IJdHDzsB3H93enjoJbYmmu6TvaPfGhjEYmYblFNd08mQnD3M0Y4qnIGz2T56 BgCV3g8Y0KoYLxdCY1nR0GSNSK+5v6xi1DfmlYxTzpaK6h5GIDHi3FQUDUWD C3beUN1YjlP3+I4evaeV9Uhc47aqYd5cDLKxM3X2wuD+BstP/zzBlDEScUTa C5ljPoWO1nXSnEtdM3ZUVapMhFYnRlZMzrIFHw5h4LFfsZjKFAkNS1XS/1dM fixgyoTGNTdESMZz4EKcoNlSqqwnYlXAgpOw0rszhi2x7478kuHsdWFYDBaS qQReQ1FducqMv7wnkz13xt3FlqQQopQtoW69Fddu0yAGIoOKo4Yyw+7qdIyU JZAd60qJ8tiZVXt0YY4AlJ8III1cgJerwXDOYTQYoS068HxkK5YYXR78YCkY 1bW0ejEtXU1rLKdoTCj6vPKewA2lp1kskeq3KBajN8SueG5W5Zh7LG+5tmN+ cVGk88BSk7lW3K8bY74EBxV7rY7+flg+24CZe59dXn1MbzzOjqAN6oogIA0q Dbrj+ZIS6VKG+2kaqsA76Vm7G4oSkGMNQIX9pH3u7LHkaae942xH6biPO0eX EhBvMBrBacQ9slsarEseSS/v35AwZWzkFMT5s4yq3FnYNZ1ImGzAw0vE1JRW jGrNwpVPQGFomE7zRLhSERZbVLqa9dR4m4H1A5PDVirD1Lh0XBAcE8db6eTI UBJ3IF4KvoREiT86uCr1Z8N7wm1q1TUpHix+NXpXO80wglSPGpWaiaKM+kWG 9WyUTQJIt9bgzicS7xb4MlqyQxH+PaGt3WAhWYzTdBph2SIBEZWnqT2VSmdf tO6TuoWPWWGtefl5R/luwnMV7Bi3TpASQdEtt1yFIkskpOyYYMMEcT35sSds HkHlAYuq1BzM3EmPDOGYCoWGJ3kfgRQJzHg1kPxy9ZJc3ke7bVEdq4Wi8OGV vDwxo1XLu5ui/CelBQ/YTPj16bnB/iPrn6fLNnjZ8xB6S8pwWGPWUtHKb6rx b3bwGFsz9CyEF28loZ9eEZBQ+Z0AghJ2llHeZYFHknitU0rKFvDk6rjrwOOf MjC7tUqz9WUO5DxYfdhsMLunWEPwZxHK1kmSLeHfDIq6eTtJjyk54EXWiHYq bPmTXkXpBVql/B01UENZjca6kufLBCGCgeECCqEU2GA4G/ljrc6ve9brxbyE 9EUGUsEyhaYRIB26ezqYifvCsh0MnOP6YNBzLWeSDIb51zTUTx4NlGsyOruF 9zTy50NoO2VeCxEfc10DLDTqi8UekQgfafbkvaTXpAUJSgF3ErSIzhMFIChx /AS41oyTPSTBZhLLWTqDFNknp6xYvkVCQLiuhCAUPSh1f3muAv1NLQ4mdpDR aE712qiP2pKwMqEZWO9vhHOLQuCu2XMK80fVa+SM9Qk0VZtdnFXL/IORpc4/ +JxQIr8TR2pcy6nGXcUbsZoaEtdf1BSDag3G+LqP1IlVV52mv6y65Di9XXXJ W7xbzUWNZF61KTD33jeXSGqg7Bk+YnrGxIDVfVH0xH927rbDfEBqks0qhwi3 NwgOXdNY7WFO5csvpkymadEO6KEf2GtuaqjqqXJJVDPVUlKD9Ma9ugutuKp0 jFpvvnnlvW1+C3uDhra07qmwgkDA6bhqyEOGc0/kH5GbDBkoKLwdYofGN5rR 5UO/waN3PVNPmPip2lWp82HpKZXDKsv1qVE+mRM0XQXvB3J/GGaKTPJKuBn1 yLUquvuZMtiM4idpT/LwWloFHbOzo0exjElHPrdB89e4NfWfg50fUoOxNu6o I7Cox+6byLmqWajN1pakITubom+sG436J/6/K2qoUC7ENfwWs1nftasgypX7 IFjcEUBMw/6mzEbX7G1EGoxoNVFPSEvknlinnsVsi3HtrEDrCcxFSvQD3Qg5 xxmPJZDVv5pdGNilL/3jSCcunQMql/0waT/3VOWWYfW1Ta/gH1FjWzdhsRjO oW/8kJa2krhoyNAhxz4dx3byPqGkkyf8DpSmaOlTHsXIS5GQqBSfwM20LkZc TNytIwPMQbsgdYUqlPAuQPEpUnA0Tu10PJy/PsX0iEMOrFEIQvM2n13DadWN jcsBMg/oJuw4ty+cCj8ihEV6x4oyrRWE7RBFxZMWGgTh9wbXuxuUSHESfd6Q PY/qRD1vmp0Iv1PC7Dz34XAx+kiXqTf9uL0wZBJvSN7aK9kiZRPOndKpUKej v3083C2ZnRp2gFIbpk1MUDeMyqkIFxEGRXZZyXDlDlu3AmbxypY1Yt6ajRna gVxIoeLlC+y7svnUwosG5L612a7BdqG4kbulwcyMeh5/Lb5KRAzF/VJ2ztTN sffS/CCETYNr0RhZaJgrhgv2BKYBbB+34lGNjPwXEtmUnczME25PgvSJ8ZfG T6S1bBiXPJh7CnQrLgyLhYm0bqjCARRaQGXEmqTEtl+n4+w8AziJyhT7jac5 jXfOrjMgKvPPKXhf0tT5QZoqJyfVQCKByV6vE53EpBEoKkJLI7vWehpzcztb CJSw85kyTpLYxEymgZKENnHwhOXK724HdyTU1I2Ef3lEwHQvgrhD01IApmty L4uyPBEIvZ25bUmNEd96Bl1fQONPQryYDB1NFT+HNOiLgHKuhxflVCTkqYoS 4LoLMMjtVS4YtGl2TkPClL8SZ6ZKQLeIfW/JeR/ZGvxixCk1ho7VVzXswRTQ Tj3us/uF/6riapvo27vB0aoygttoslrk172NShJD8EuNycG/xuaCRer9rfdB PPbk8+EjYurhidm2teYsuKE7D7lWE7YurYRdtgFabAi11G5qfXTd5pRK/Hqc 43+tzcXkepLfTjbdDBOia5T7k7PdkSt/TAt36VU+TnHdP9JZ3ruA8xkLk36k pmw14yK/tK2UEnYdcZplE72PG6ZuxzcNKGfVSo5nZvoLBnLzLXb3Jo5rups1 BuNhQ1Yy+6faPGjPjO3CyjuaNtpnHB6EBB+cBOQ4+/gJcD/X31TO64Rr4zDT qqCaQFJdyfPp9+vbrcmnqI0q2ASAYMU+hAUXnda7V0bS0kV7qx2vrF6mylO8 jp7bpOjW6gxqU/rSQ+7gRTUI+2o4vnZ7ghJA69VjdwwLCQv/QMVGqaAEOYHf HLx5L4hfCKZqs/ExniW+POUZMrST57tBLr3PqhlHqhsvnEdSUUeq+rBafRSS Lkiehl+tXeFWeDJXK2yjZTQbwX1OLikPIGXwO9kTcD1yfWG+k0dDcDcheV46 PwdRB+mluPBDSqqwRU7H+W1v7A6tMcKiig3mF80L6RZIVgoSIVy5I/nLDkVQ mSSPEjhQHIx2mXFre8uhhhCMnbScpuWFiax3gcgoh4Jke0kOZEyLFfqW3IHp M8Cajwz16jarWry0CIXRbKTIOnmxmxgpivk29by84dz3cH3U+LDqGCnCnx7m 3HrLaPnKRavVyvoX/C+7khCtLDfBy6wsshCNKjcDpN0Pp0efDxVVs6ZRmLyF HtGrY+CQIrgTBQo3UY4EFo5QqYmteXh8cvbpDdUsZOA3+XOIJIVBB7TYOaVO JMEIMr+ghGvvsgjoG9TJrpog54Uys4HgFhiogtudEkh0yFCBx6mg/HgDvcHc 1r5MKL8CYS2MgNuIH5znCK7ICsV5Gcyk0PapKAtmtdZdKzu2ZvkuW7+lju2s 2Hj1s//7Vtuyt1hvW623rxqX9f1aS1uKedgoQXpViXHKCaY1msR0hhLPKWsU 6+oRoU8JZkdgr8/zpVqGXce/k+0mkhv2baPqEeUgl1phC3yIE3qVkuL+gU79 04ufUVyC1Ovh1T7+dXcybuEaeATC6AymnmDIHoR9UqdyNLrs1tZkvJNjmfaC Z4Xppv7xD1BshqbNgKjVJEI3nBVmbvWLjqkv/e97KMmVJHLmRbfu23x2k7ot G3iXJEJuHJ92Z7IftvjMBsf2qF34cp/WYH3BjeB9XiELKy78sUZU5j9BERGO kpWqSMtAPf1Yyhsh6ZoCq8RDy1ylpVF+pYPnTFZUm5+3aaM8w37fCXawU1WD zoXj/9JPU6mNSBa4xnBdL/iy0qB2iIKBTY/gDMERu66moVQsv7DQkKwYznWl v7acBK3WUQ6EVDkWynRfQgfGfzWD59/XpkQP2CWo7lZLJd2zZ/sGfbsvIQKJ D33EZrRBgHrJmFncbgKWKqlNj1OpLQ27vvhK9CWvxdNeT66qbCgbDu1g5FEW Hob7UAGL9K+/pzPaSAGRU+D3Mt1qwMyekbLElIpQmBK8P29/Tmifk5UF30Vg V1kKAD2GQ+/2KEmbJBQCstinOkahrlUWrd4J/MdEHoOLECzhqV1D7DXKnCVQ /1Y1p+WbYpc8NlSdWz1HfPujf5tsdp2O8e7L8ZvPRyfH/T4vxKXbPnaUrb3h qtl2pknJsOzaKOvwhwrHA7XK1SqV2ynQ7P48jWpNzQl9EOgMs4mRfhhlCTbq T6u9O2vpQCWFoqzBVBUMUSLW0jIeolw0bCpEOlduq/KpwjvI75Bm/hg/+oTN DhI/1l3M62WD1ueDurcWA7ehxBVzFjMXd0utrPL6eB4eifcbgaURXYkXriag KoWoBIcHth7Vjh1oeEQDHdcR6IDuNlkSsonm03l2g7VH9LmDZJhfLrgEjThW NQXbaq5wjGAreZ+yK+4JQs6wbJ+4T4y8UHbSW2SvR48mHsJZWizGQnni3qYd JtbJi3WUKDAIoepPG40kpsGBZs74b1FHxkmSTTqBceGmj10R1JbOIM2kl6GU Wl0TqnuyIRkjGpPnmwfjbH63ZWkRNwGLS9hkQGnC+GPOqbMxGsRMX70ee65j 2FFHo2y1vNMdXxuMnJCDS39iSBI/RasF0EGPFalEbMdHJ+TZNAJJD/Hg7Uo1 8ipO8TX93zWC2sSXQYSu8iKCdpCNmom+P17LT+7+GcxmPyGbDBDZT4enfVho P++VECOhaUt/qoOdXfRLXOtk8MGiMpfP/y/GK6tkArgWk/To74eg2qjr0h9z 1bfGer+v3Y0eesWq97zT8OjISaZeB/P2Vx1elaPA2xerbEj8KG/6UpZQWIai YlzqamPu606N/XZfPqgqzzQ9zHwc7mDMngZLbqc0pavsqWuyVsNv1rU9q13f fhoGCiX+S6KO+W5HYagjlkpBnZamMzp8HpUzwW6czH42IMVkFrvwM3g3MvNz tOuVjtDrTGM/mXWiyE4IrRsEvNlg5awSZvM94XF0m47HWxYfaTpY6pyAZYSO +ejnt3k1DEHtW4mdHVTTeemEjvv32bOllFPuagxlRrV7HhSviDqFwAGpXUHc oKk7UXSAzV7uQseTgtshmyzmGY7C+FQNTj1BNIrn3W1yBl4R2MIda0IarLBE 4Oe/AH8iHtTtUO0ns9PygQKyMM4VGgESZvE4RL+3ksQOs0vWBPpYqX1+dr0Z Mc4vLvrVfHJJqOpzwb6ncniFTkP5yh9V/oysnm4Qu13DRAqHkjpkMc7Kmvju 9dG3e8Tghf+U+cjIn2bum59OPxx9PPrcfwex//MWvkIpETl/+Ba3k3BV/+j4 HViQf4SfhA6vV+4KeuNOwD5VILDj+ts+O/r2b+/O/t7VB2oyS+BtuxciHW7M HwrD3qvCjcmvzC0Q3RNkCfF9j+Pjx72GO0U6ewkSCzIAcWQst3lNLy6vtlCr snaVdIE+g8Wxvz/P9/d52Sv5AXkhNlpPn3IZRw7cUhuuwSjGPCF6dAwEkguk v8rrRY1SM/mFIq/cR9FVFZ35ODwjaTi8ztBL3AuCMUTyn/gWlpFYBziV92WG XiXls3nPr4/jk4+HH/escMjlbDDsB6eJLMour7gIAxvPiTRYxm3HkQxg5OIc pSBXiVuGQ5beqL69yIxf3tx9XVWCEDkn6En7SfzBxOZkHTD3Vi0tKMoE3uQo BXBeFVqj3GfskDyhNBClwtdQpCK4nXWUTjysesvj+knk1IaEatHSOhJrRH/K kM6nstnWEFuRDr7XpKmXdfSo35P0tl8r3aaX0xwKHycbOrVkUYTXwL2FDVrr M1miTQehJONhb4dqrJNl9GjXBo/Eq1flndPR0xadijZQS19n2S6i5r3HVW/x PkOJQGw/9URvnN9pAIymnkFEc/OsTgZr3x5D6lzNDogviJWxVkvH24bFSab/ EzwedbH0lezax+LDEZVeOiX3/7Yf/0qPlTfrMGPGfTjK9XFROXC1811bGF3W v1ulMyHYBTYF/Iho/PukNeMCjTrSiGlGdDRWkevUHg9FvXwe6Y90W1Vrj1qt 9Vk2v235WdSG6P5Ru01LYsWKUH9TZPGFa237aVieKXN7ciTZ30jnppUbrCFN Ag49cdtPNUntK5X6gOYL5PxgdtdF5t4o+kqP03LLS1YnP4OIAw1MLJTiCSN1 CUMoIQUut5kw6NFvPbc+XiV+hT9estx/x3rnLhpwGnV/b6PX/iu4eq4kyeYf GmapyemwtYbH1I78xpp7q7zSoqNEz0y/h3QLwV1Zu3nCo9Y69jIJ8xuatxRf tWonrbWLyu8VaQ1RYOv57jLcTsnCljv1yNowaVLbSLjHarZrw25dvlkjXUX7 cb8R+OPWVySqIBISk3+Ot85jR9ZYgEsWn+mLzZNUnqX7ijLnR6cuTLTe4Dx4 BJasT3oWPYED9/XLbMf67o3Tau8pR++pwNh+R4jrIa8kti+rUG01DEuewopK lTxzz/pDA0KnU15E9iMRRJBHMPwKXSfdkiOUEo2hUIkFYe5rRlhWvLgZIld2 vYpsjgAe1XXQV96yTyTmVW+6lTR9vbjWCK7Vkb2/cpxOLuegjcgDlNZDdHjR 3xuLVwQeiXVUdO6PHVXRsUo2r+BHX9M5XXswOqvLgj7cXMzSHDwkbJq/DB3c D3ZtP8CILlvfDUb1nxoBEJrxSeSpJUPV+BY3edg3PU6iFC5o8dYOw7XikPVM R6YWNiGy1W1Lqqdr71nc4L15r3Z0ZBpc5u593juzum76l7qbaYA1HSI40eq9 +WKPnc0ZmMydaHxmQ8Hs+JFaQBLck/MnmnuwlXw0DxJ9HWTE6JKuQ0JtrOfX j8dyJegp9MJo8ZWlgKb64i7uNb9cXS2utih0qTjsNzAXUNyCaKwWE+G1Xx7J r45hXcRE3R87Kt3QjWY1MT5JlKjkdzE/PyTOX0cTHSz7DX7N3Qe6sGo9Vf74 akhQ+g+PxVKOrJxr8Wm81gEXHyNuQblXvuN0L90WsWlqzwskf1OSVqRnhtol PUnqHLuVxxZuRtgyJf6x8zd+qaaDWErGDthBHFjMbtr+Wvsqr/b9uzx7TjCc 0FRaElYymB4HcbLLK3SaDFujCspnVIwmnej7rK2P73h/a0Uh9x5c2Z1VAzDe peW4cy+wxn6nfUe93OlaOyibtFs1BJYNINdlu19m/JE8QtMhH4/rTErVONEd KUtQTjUjEh+QDHHpZapOatgKSsscaslM96NwRxVi8k+QB3zuxhIZLsgsvhyg PiHud32e5B5/oV1wQrmODYbVjX+uQEbUQQZW8mTUZNXXcrMzsKwkYcMvl4fw G/nxy2eVJHPoYdUKAskrI8eRLRDn11cGuOOT65WhKihJ6VYCauXIgli2GJTb p7oY1loLlYXgOoOibyvWgQjZXFWvB6+LmmlvrtAozc7SX8oqSF3NxjxQQx4+ d9RAzfyVxgXTF5rTLF+GEBkrbT1Ni1nnCA1HlCuqrmd5oaRmTDLI39ADDBHT lPmAyp2izyo/UXh3xZngNmR6Pu8fnRCz8ezW3AfSyyTGzV5nuXsvfI1/a8lC CCUVo6iiwUqqyc9ZF8V9+IYueCS+DsYV/cJy9vb54W49hOAsNe0Cy08uM6PP nuF+k4u2I6NkGzwX2XjkEXrEBlePg5C2CA7R1VdfAtQwDsmtCoXkljKRhHad /STWdNBRPsC+Ety1fiFgEh5jG89uET+GGp/8NdlJdiUtBnuTmwjRtRnjdNww OK0AdUd5TzJhxUy2A9emjTJphGCW7nQiobjCvZCCCzKnnmRP9DYDwt8rOst3 sIqEB0T+scGHLFOpzgR7HECstrVwNrIGBhOKylqBJQ8I0S7RuP6UAYbUe/6F 6F3qslQCRHFjF5sThywhpKnv8StSKmLQMVoItodV45tS8W1ZyqggyMVX/PiT uhnuAqwx20m86G0lDd1J6vb31/S8DTmAc1R2eexuiHZfCaxGS6eYg54bRc61 b3X90G2ZkD1j4kp3vy/KGVV8nrmrUT6JyOTj/UWF4YlhBT+KpDo62XV6OBWL peR9FE7RkuV6DajJh4Pza+GNyXLmZAWMmSiZdxQiFFGcxGnN3FQjzXRGJeOF rSI4JFSe8r/kXqrF76INux8CQG7Ug3E6y766n0hoVgFg6Kq7oS/JRe1rld6+ xQjs4FeCpZIPCCMHhEx4rKU3TkwgVnd0wmTVOGyZknnGuUtB2WE3im8ouT6u N8HkYAGfTGmwVbdBj+yQUjhu/Xj/9HOp3AcdMjkfRqzz0zcN6g+d1liwInl3 9kKj3R8FwML1ehkRFO8l4ofmm54pe28LpzdNk8Dzqiqyu0BFV0mRwi8qDZr8 JsHd257uaTag4l44k6+eMCRlBqwSctlnI2CWcoOL1fxH2Zm4W14nF+0KW+V8 QdXRGSre/N+A6t+SOnyiddpZAM+KuXqIBDQaDnTZG3UvVbkJrJvzjJr9xl/s NeB2zgjVRdo4UWle3RWoSpDMUIcUPRPuF2ah6TKhElzoyHJwi3/ORSVwIe82 XixF0qZaqlQVaEBHY4/PRtoyXGg5LKYqd5Oar5wEpu5zdU2Q1TJRnRXt3lCO WcPY7lLZbEVJchFJVs+lKfKz0Re6PLQbR8Rpi42Xh1VgNA/Es0p6klshZGPx zoZrUUjKXR46NtwpxnWI8ZaFVs0OoE3BwdKwf1UM0kXYvZx75P5bwkxXt8tp 9ezJn97bj09uT0wKt3Vm6Ui/yvQP9/BsYl9jCIOPw6vggzmros60/NFceqOW ymlhjouMshZDUBpkEPLkh1dF4qvPKLo5CnW06NSlHBopLwoVjDigx66HRLSG hUFkLwDh0sIpEsmbWYo31s7zvHgB1pbD3AdwDAH0228bnEXbjg/84JpSpunx 9wcftOFHctNE6nvSpdPBJDtvb4anEncMwDvl2XFLczNANNN4nHzHbNnjazcm txNZpdijI0qdpFk4IvFAtQfo821KWJQtHSBeGyTC+d9gIblPPojx4JH0nsVw NMmt0WTCqBZFtr9KTEnn58HiFaM6Gt0DDxv6Juuae6gfXialIbeftOtYpYlv 032ChPtJrvrZa7XuF1XBDZh88OXD5z1vMTA/dzoytbpFxx5b+vLWVmez1fI2 7/Annodnz/iBPn8QP7Pmbsn3tXbFgw2DOFeDXi5yaQYJGnUuTNygv4pLkr+S 78JlFKgLNlTAHvc1rwn/sQUil3hjSDgDVM0ofqJ1SuOkP1RqCliWiPDykrRx vQsxMv7WkLFSdCMM8iSbB4pKt1YhFmshbi9i3bRvg7k2YRp0XyzmNgWVjRLc yRv/1QdK4Am+OE1/0fH2S4LchCt4GsKHGlFDHbdMzYXhNK3VOl0qwahsct5+ LBtN7RDN6rF0Cxygqhq2WNi1KGnF/JFQJS6MBA2BjXmecwV4uXbbbyISa06H /e7opI/cuLPDN59PtMQaFi/1h+od9OFIgxrOkwroPcoi9ED0pLuGt75p7Ogs PQL/FPGuMSz2PoOxa7YFH+fUrl/8VVEip7TpkOxfaPk9tEvfioTphftApPCz oN5GBLWLyvromJjo3tHHq2ND9uM9xuYQ5V0kqYDYCXiQwt9oW8lPLXJZ+99E nZT76Fg7KlRDm8DocvoTHCzEQgyRQUvER5loTKRU3gMmcd0ZrExf/dzpxJVn zU2RfZSqIUEDgZITa25rqfpwsm9oaSXLOmLq1iCzljnVA+0ZWH1+ADFJstmC ZrMisGN/dGo4ZUhrlK2qiysNe706DlWGBK+yUvaKwYUTDYPx/Iq0bkIGsEfj XIo/SM4Sbg85K0FWCV6hBadtncNrm3F6thFrChezFR/jMkUUxibHTjVzmZnp UfAA98t/YYlt+MuT6/FidCllqpx2nM4uYAUtLlHgumAa+yBRWN+55GgOA9OV 0p0VHX8pA/zSsFWgReK7XX4wVMjQENs+2ez8LkgO9bmUhlsHrokZK2nQy5HD 5eSDZZrqp+2h09TwS3DaNBbMWEL99nv5Bl/UpA3+QbpBFjm+V8sJ2RpwfMXd DWqF1SfwnecIx3GyiLtwMriRmhnuiPjTMvqWocQoROPxsR4lVkpgqYLGLohk /cGpWAyV6RldupBiWZN9NkaXIrqdQnw+vWPYtlvtOm7W7tqJXGFnhLniOJ9n 5+KFuGUXRN/tzr4vOTEUgTcTVkk7P6WYgGe5LnLmjSAoBLEIz2d37O2YarWf ud7uLk/TDSNz5erm2pY7k+6m8Bq5Nogo3LjG3bl8zaQJvLJ61IThQzS9QNwo xLtthbOIrIHDu+5x+WK+xfbq55P3LPrz4deM86rP8xkidEwGyez55LKxM8zj x5QKo35lGGGHnweMvrocI9hFM/jIDv2XfOaHK7IZbOt3qK60h4KecF8V9WQu Ypw47JbHloeFsbTSXdMpshwpodUNaiLg/6n1AKoFGakB5upnPScCgPIGoFCA AoZrygfKgKGmG41niClgASvsJU+HNd45yV2uO7uDmWhwfvFJLmMCq7/vNFY5 e6kbeKIboFG/LIW7+uBv333iUq57JRFaqkq2miW7FiHL2rVnUwzr9kndwsDJ ZZjYoKpHTb0g67MHQnIBPnFrUU9qy2EIc4S9LHM7xi1UNgbfGlUN545u8D0P 3aKV0uNhtIz4+une2n3ZoP4xpmEtBbBmkuqXlt9PEemLquiYciN/EAy7KVR7 S/G5dttv/r4vQbOMSqRY/WNfv8AqIQYYqkftQG+D67Tk9TAGk8AHAxHFop0K F++xM7Dqbynrj97FFJe39APi89aOCPYa8aQLaxBNMIU+Cq4bD8DSQCq56KK0 gpi0wPseRev2Aw0I7mfxqPFvraz+ANVUxlmrPVZH2iTmZ1YKsgk2lZSbFUJ2 i3QWvpTirq9WO5hdLuBZ32DKLSsP68zD2U1G5TMGCAKIA0BaQlriYDKv1BYg Gav7YkUtnofI1IqULsctWFqKIoo2lUuO4KT/8DjFm8V4nqFmiHsbp5+iuDLC YzQW6m1QWCyX55iNcAmJxLZ7cgeOfy9WKw+4ZQaH//r8RcLZlNB3zO8SP+Ml Xfbbb8pNUVd12Q2CvE4i9brVJJGvY6YZafilDUIneRm0SyeFYJtZC331Khgv IwC2bJJwLIe8/4YjHNo8uzgAJjMaFy+z8Ym6KHSPm8eq8ipNmNMhvymI3xHN QPe2JmxgJf4hyoCUhSwVIOCBkwUnsGCzV8LjfiiimI7UMMNEKc02qRwNynzM EWVxW+BgnHyfzThXQpyao/S8/diObPNp1h3LWtLhPaSJeOZ19+STWNBwkajK uRKY47Jh1Cp/0GkmBUvpcemIMQvuheW8FaFBwTV+8I0EDkJHrv0iway9Uo2u bQsRc1Sc8K14x+8/IsGanVU6hVfZ+RWRsIm7YqjEjoy4IHuDao9pCSOiTE1H VFlJ6kYvpkCo8jgWxO134Q2JD6dfyGfmjhk4kvscjzZADV4/jGq77Z0jzSjo 89esyAL3GpGsuI6wk9J3PSi33RVzi1vJxZEAAU42HxAksI6SpB30CtEbBCnC 3rjezVZ3hjwU28RlBzCQ0dlJJfIJG1/aGS6ziyFTDDCK6XKcgeQT/h4Q2gvm KhV0ahitGTnlBuNCw+9FGh0MNLlUWVdn947cbfDJkv8UpiV3o/2iI+F7gK9G FHjqUtGQRJ7E9encwrlaXIYHGtUyUMdkqSBwzmtHCW9uyCmF66hUm6citOrl VHIcG0TvxxOltDoNHC+zIgDEK5OWn7VgAIe8EOBVzyaJdwV1+IQeUVIGGzLs j+X6WSOghu4MX+3lRdeK+N0M5u5UpoJWtLyg8M2Z+wtUwxs1VVyYPMCZ+1It hWoNs0IB9wLZ4jkvFjhuhVtKXzubh+8oUIurfBxyOo51DQVojLBamYga0i+g YhmXE8Z/3DcxNLyzzS37Gj89sWqD6jKWR6Ae6GIwc1MmKJJ8CJvQP1B7Tr7B SK52uH9FPpv33GIy3/wixc4q+TBpldmcSNvk08H7YZ2wk6bGFuqIm0Mq54a1 RsvvNgiFEC1/KfSM1cR+9vw6DTg8RX2oUIbAew6fDhw0SQZQ29wNUamIMulI lWF5sCshicoYcUVfGqpkn6uLhnZAJW0iQND7DItq0gRXX3kyF4HqhGZwwnC9 yq0wG89pXPP+AHxe3ocs4rbkRBbLI+g0h8Aq5H7Q8KIjYkaOsFshxkIpouwr 8EMq7SFfgz7VdekDY9xr+oM73AbNrl2LNmxjli00RBq6q3S8hgaxPp+hFU9U 3Ts35BVaTWzpRB1Gs6Y1yT8sN4LfKWJzFYcErEhlHIjHko2963HVk9KArJ93 EVZArlYsD3U3nA2Y/9sJZcHRpvoLo+2S11/evTs87b/+cvZj//XR57NWu/38 5UsNsXM4nz5TdL9j98kLDhcFbYxWqy3jTuTDj/Edes7aJlrRb9SmLj/YtS2d r5dKApuqyjoWvCTjZk5OLMaDmcluopucQCvgUwNtPgmOAddakavM/QF+Xado yqGO4KDwH+MQRkkACuqjIP1sMZkQn01+i8dL1dTRgh46jytDF92wrBE1bZoV DuVfFtn5NQj8C6uOqz1CmcJd0SrwKu5SMiq8TuEO30KPzxmX+b0gT+MsH0MR 8eFDOWnA7ew6RelzoGq0wmkQjmIFWpbUGVVkgo2I4oJ8aFKv4dYXhQYo+CuC HdIOga/fvYUNsQ9A1k1rnXM4cgtFJdRrxTkj9epjfdSjVHdj0UcXaKvsusam 2UScQePZglwf5gpa4SlSrM9eXeId7QhCBZsXEV+pRFBfJLdRRviEAgBXPNpP xB0TdJcXdNxj36UN4WDiGtWiT7m1xYZUN1AHaG+SXhibUN6has6iyJKsWlVL wo3JVFFLze8sA+jBSfvJ6/6708PDTmLuhBaHwyW+wdneU0lRlZ9A0MG/FPbT lMiBaLyCbvHPtSPNA63Oq5qhZsNURIUWaxUVkBQdv584lAxwR38x1YEjDIi2 cyAyyUsk9QWE8QfBri5x/a5yucVvVVnvQXH18lqlmiPMLtANzMOUEjbInOJ4 odTypRKj7O+AkGA5SOuEx+KP9VOlAbb6RV8/tU1IiFfDLnuc9Pvw6h+d+FBB 9df3R9++xxVIiYV34n12efUxvYlK4JDzq6J8xklPk5zArDNbDhRqJ+1Ls7Z8 /0X5IfnQKKZMJbo3CteI04APU3dQKQQIa20x7dsJtrcss7ZGIHNurduA5f+S t+lwcXlJsfeaX4GPojiDsx28KxXfQHD/JbtwWkPy5uT43dG3/bOPnxo1c1HJ wY8BSzehYh4XVN6d/hTrnP62sh5dNvv5gkEx10/S2ARLaI/J2JwZwfF9gLHm d9O0+On4tP/h6Owzsrz+mWy++XB4cLzZTTY/nLz57vAt/np7dPr5R/fH/d7G X9z6zi4QGxMX4Wve7Hz+77pT9pv/Nrp+DRfhhgcVskZUFpue9IYYGXrPdzok FbTpNxQ+bGg5VrYCwUC+tl6y9MlNj65ME6BpbpGwD9RZ87DRrsTU/fJJzXCi WUBcfOSeRtcaNRDtZmmhvJ2913GPa6fQPDE4mv98mcjcyBcKiA5Why4NWxe6 KGQNlJYDBzK0Hz9RqwKqp6BdEhlxcqq16CEcCKnPsGfsJH+uXudZTegy+lhz lVHC8FXyjsGF8Zxeee1ach8LPDzaAdRxCS2ZLUGVgbDnyc6JIzilkaEzVAJd 84RPbyTeqphy+ycYQ+okT8gjOuW5X7qev/nXYhfHedJ7JdP2zagria4pPuja 1tQTv0X5GSIIPPb2PvDVf/PfXevfBF7Zb8aL5BqhjC6+pgFpY2j2vxl13Kbe sMdsfjNK1LHk/uQFhD8wIdKnVT3Crqsbllevnu8E97MdohPUtceOGM2sc85h hOVHoUii+wZxDZl8NAELef1/QbluLeblnft0IguoUGqfko6C5+OOL07pdycZ V54p30ZROInnff7wOrnJiiItSEQTUPTDweuEkRFlZYktBTpFEJrM7HTA3+04 buaEGcsyzS6krLpSBW9OcqLIpoVNzCTmPgQdd1rxGKhJcz+JeTNyFlaX4Umz 7IYc+3BvKdhHe5K8cmfw83/Z2wi+espQhLw+L7VjyYycEkiSjyPN9AVCYNrU Hn/1jIj/lTaHnXM2f/BXs3jmPFonly9TwlNBJSGz1ake4PLHeryQ0r3Cr0XI K4KtjsmCy5PiBgocAZ9FEMZToJkIMsLIDfDxQv8O2yuGALKJg8+iGLW1QWWi a5ng4Zn0dxRX2YWBwJlpmnR5mgrkozg5tOP+ZQkY3AOp6r70+ieeW9fBpx3Z vX1AflhVoglpQ3E8+Hzy8YiqIONVQ4sibJn1d3gOez2e6VcMFYmViF5lRabO is9Slmu8RnZJZn4zHnGQtsPiSaSLDFBX90LddHhsre9hAM59R8CTaFXpDrVu uWca/tQd31P+yWlV2aTY0pS2ElUDTZzWrfBP5tx6hQJZg07WMZKhtjnTCaQ5 O7PCxpxcbBSM++rgSYrFlGgWmgVk4NIuMgSrFPs9GjjFbNJFVMPJiP+dDzWQ liPG+xXczINkdDcZuCMbcm+WFtN8UqQV59BWkpyQL4bM8llORDN4INyz4MEi 7xGX1oDNRSKbS0y4maqiJQQOghTQQgMck+Qyp5spxEdM52ReSI7o28M3Hw5O D/s/HBx97v+vL4dfDvvvDw/etmWYzGAl0VyyMFTFVyu3Tzj02WI6hx8LYeeo DT6v8A5amwzBoZvp3Ff8pn7m41EwQMiqHnO4wrvQyBFQJBpPc3MZBLlwJNuo Gqje/e1G1wqZbXJRnU12DVKqMZI7bjOGoqB/pNcOAVOHpw3jnE6KxcxEJh8R vyzcceFMPtcdKkgh1cjoheZu9PFKSDAekXTlCaWWuTI6mYjOOnGSS2JI/G7R qwlzSmBxs9IdDho539ztGL18ktpoVPL5yZJ1V1UsNQa88xon65Gu1MgbO18K /wMPepukmTjV/b1yuO3tNdfOEU6WZa64ksqOwmFkkFkurNPbYbljDPucMNIW giqtq2ncVawpR8VA2SGBg9DG4vjk7eH35ZhOqZTQev6UKiJeHAgN3FCzhbOW 3Cko7q3H81/62MeVFgO5xKtFUz/ga+QN55bbQaEqwA2yaIp86u6ZM7leVyov aV55Ml9MOCN3NrgBiEoECSAmIpQ2u3QujChO7ax8CLxhihVc+Fg0L0mJSLut kF3caWqvNNzFvdgl3Zrsd9ekILqgQOYTHBJ0CGwMCkom4NAtClbcFSaDMMDY 48IQBb4X1guxOs4HU7TSfnPwqX/241n/4O3Ho+PA+Ex6h58OTz/quYh2cGQ/ N/LTUd5Pf83AXAIcOPz0bkuiNvA1iw/hJgXWgaomDVwnUomjyb20QZx1nezA oqZsMXbpFwJ4wJ7F5k1/HdwIyms8+Mdd7+am52yFiwvBNczyG3faD/Dy5xwE oQIoHGY/R4BgMMw1EYkD1snNDRm1zujT2J4SkO35TXlz05e/noJOoX9zI1HM Dcpr1POSA9BTKrfDEQCP18gmcjQyF0OX74QjkHqUL86vhB9G2Bq66jtA/S93 3fkVHaGTec63PsEIsAnhhM4TzogaLc5TybPiBAJ5tx634GQm3YuFOuEBsw2x oWmX8oZIxoU7s4/n9OfjIefzKg1aRUTyr5ORv14a6gTSQQZWrDMFg70eFJLC QMvruVPrBxPOEeONAbKfF/ItC3T7Op2fmz+F7na67Qvl3HbjBc0V3/deUEW/ 5yrYmBYFWicpTf1PB6cHHwNnJjf2GAt939I/FYYMp3mB0Ojooj+d3WxhSzn9 qotaSfOnHdphnKmJpvART9Oz/iabQBlzj6ZfXga/DH5FiTLNLo9bh/fG/bUX 9mQn9IBWOQvuFa32lbzveKMdA4Mi+ixEQ06ZWgzGto5NLaL6UWTbSdOIYUMB S38FDWmG7X5N9Sk6W5BvchUljtAOdo+R228QXCvSm6wHVNOA1B/2g0+d7pcS wpngyv+jAzXv0k1voTZkTU3UUL6Xes+qJwROOr7YArWIvvEwNYQNyQqpCavi gqp0K9jiFntPhohyYGauua9EVeOk9IRWK7rv8x37HGFsb21tdZJAHII5KKCW 4asgD2C3b2Ncts59FmKgNyZPqbeLaRjco/NPhdGcLEIRZWwjYMhaP6SqOg2d 1OsNSdkJ7mSNToxZydpBnRG6mQKcF+ktH4tCPutk0eY8n27Sjds48rZfbP8z /TXtzvJ83j2/Hd3TzeCvGjtNkGa6GEy0gS3kT9ETk3PXAxT+5VRS0L4KlcVG y71P71XhFhi0UUYx0FfTy9lUPrsXQIoXfY30rW6yKWNmZhdXdXcHOwUZYJM7 7ZgWkilS/Wz2i9Mf6HHZJSxr0014J8pdeA5pc9klxgdsC3zXkDU+Vj3AOoQ7 IPndI+0mrwM1P2+jpSi/tmo9AZ3Y044uAT+7mi4LZ82EbaVxfuk0V4XxEeYV +jThv2DD8fqnm6kYnG6Vks1DK1XhLpPYDKObjyaJ06PmXa5Ygxw1fRxhvcJj MONL+ZnU/C0kikq6wi2mdkcERkEwLXpE+IJHhM6EuZgSzvNiMSawHUaHkK3S RQYNO8NBqzw7CZ3OrgZTFg9fB+MFqQxyuaz3IUFMx4xlBAqNSnEaK5RAFgTj ezPA8WwZbJHinvmekCQnmT10E7/F39JB8Ob94Zvv+ocfD0+/PTx+86NTtY7f bGwYtYjc76lFlqr8rLktV82DjH9pvOes/1M8V33DVL7bHky1zaPZ6Yhn29ur fZrJfj6pGK6uwVrZLO4AUQVZNJNMRsjdTiLQxbqRNhZHRuDOxUglJUrxIc4G IEwjxK+AO4GCneAYIq+Qm80bN1pOcSa0MHLhOfbqiamIX+vOifSAN9IpShfZ 5WJG4FF+sJ4P/qJ/5/f4d17iXntNBJ7JEj7UvTse3yH68JqiPSnJdtZmMBlE P/h7ZaV0YmTC0okjzDYb0tkl9EXRY/Vb9miYOr+uHF0mMt1vOPzcb9nka/ux gUeH6vGXxlC6883J8WcApIKvzj6ffOr8vxW90Y5H9U4eDJ0QMx34U0kO+GkT 3VM+K1aR+iZpTZ8Pzr7rHx1/Pjw9/fLp89HrD4e0hwunvI8WbgfCmHAWg2+D w1RG/olp68tc7da3juH7dPg2aretRBvC0CIDL4Qg/M7MIkGOcVk0Bobk47If zoKlgM1pKU19kHGt5WPtZoUTxUOnbPN18ogtfmI3seUgSrP7fpQGq67pelaj fc+ee3hl46pqrbeutO/cdsfjGMK5YSEsIeW3h6+/fOujdd8dnh736TvbsO6s NI+nU5nYyaxmVKveGFviLrmPspPnFlASoU4RJfN5xXm3wRaRDSJ3kzGzn7w5 +fjpw+Hno5PjPor0Hh18OPr74Wk73Eyxvmw5Ao/lmm7y5sPJ8WH/3Znb9vLn 0YdD/8nN4fHBB8sOB1+M71X7sX9U6Ukylv8hT4psFGeRY6/SMIZj2tnY+L8D 9lgSKSsBAA== ------=_20030327130820_88439-- From owner-linux-xfs@oss.sgi.com Thu Mar 27 04:26:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Mar 2003 04:26:07 -0800 (PST) Received: from smtp.nofida.ch ([62.2.181.77]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2RCPLq9018912 for ; Thu, 27 Mar 2003 04:26:02 -0800 Received: by smtp.nofida.ch (Postfix, from userid 101) id C77E1150; Thu, 27 Mar 2003 13:25:19 +0100 (CET) Received: from [192.168.74.20] (unknown [192.168.74.20]) by smtp.nofida.ch (Postfix) with ESMTP id A9484118; Thu, 27 Mar 2003 13:25:11 +0100 (CET) Subject: Re: kernel patch fail with LVM From: Marcel de Riedmatten To: Rocky Lee Cc: Nathan Scott , linux-xfs@oss.sgi.com In-Reply-To: <006d01c2f433$545bffa0$c70aa8c0@RD.proware.com.tw> References: <002401c2f418$163e4f90$c70aa8c0@RD.proware.com.tw> <20030327061815.GG5658@frodo> <006d01c2f433$545bffa0$c70aa8c0@RD.proware.com.tw> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8T5rArwQYpG9y0YxIkkH" Organization: Message-Id: <1048767911.20049.40.camel@galadriel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 27 Mar 2003 13:25:12 +0100 X-Virus-Scanned: by AMaViS perl-11 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3398 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: mdr@dotforge.ch Precedence: bulk X-list: linux-xfs Content-Length: 1094 Lines: 41 --=-8T5rArwQYpG9y0YxIkkH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le jeu 27/03/2003 =E0 08:34, Rocky Lee a =E9crit : > Hi Nathan=20 >=20 > Thank you for the respone! .... :) >=20 > Did you mean that I've to change the LVM patch? > it sound a big trouble to me (beginner)... but I'll try.... : P >=20 I going to be soon in the same situation as you and i found=20 something interesting in the lvm list archive: http://lists.sistina.com/pipermail/linux-lvm/2002-April/011196.html This is basicaly a lvm-lock patch with the change that you need: s/DQUOT_DEV()/DQUOT_SYNC_DEV()/g --=20 Marcel de Riedmatten pgp key: CFE703CA http://ftp.dotforge.ch/pub/users/mdr/mdr.gpg.asc Empreinte: 4687 F9CB D8E2 AC1A B806 F812 C048 0875 CFE7 03CA --=-8T5rArwQYpG9y0YxIkkH Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+gu2nwEgIdc/nA8oRAmBBAJ9A73RnCzfsvfjJfuTA0ghy5ldiRQCdGQM2 zm06fnn8b7WFB7+dIXZximU= =xqV5 -----END PGP SIGNATURE----- --=-8T5rArwQYpG9y0YxIkkH-- From owner-linux-xfs@oss.sgi.com Thu Mar 27 05:22:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Mar 2003 05:22:46 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2RDMYq9022899 for ; Thu, 27 Mar 2003 05:22:34 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2RDMYi7022897 for linux-xfs@oss.sgi.com; Thu, 27 Mar 2003 05:22:34 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2RDMUqB022884 for ; Thu, 27 Mar 2003 05:22:31 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2RDJUJ9022817; Thu, 27 Mar 2003 05:19:30 -0800 Date: Thu, 27 Mar 2003 05:19:30 -0800 Message-Id: <200303271319.h2RDJUJ9022817@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3399 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 427 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From christian.guggenberger@physik.uni-regensburg.de 2003-03-27 05:19 ------- Created an attachment (id=75) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=75&action=view) new backtraces with schedule-kdb patch applied ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 27 07:16:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Mar 2003 07:16:20 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2RFFQq9025685 for ; Thu, 27 Mar 2003 07:16:07 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2RFFKnH032345 for ; Thu, 27 Mar 2003 07:15:20 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA18432 for ; Thu, 27 Mar 2003 09:15:19 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2RFFKwX35768649 for ; Thu, 27 Mar 2003 09:15:20 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2RFFKf03184; Thu, 27 Mar 2003 09:15:20 -0600 Message-Id: <200303271515.h2RFFKf03184@jen.americas.sgi.com> Date: Thu, 27 Mar 2003 09:15:20 -0600 Subject: TAKE - fix a build breakage in xfs To: linux-xfs@oss.sgi.com X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3400 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 371 Lines: 16 fix dmapi and quota stub inclusion in xfs build Date: Thu Mar 27 07:14:52 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:142816a linux/fs/xfs/Makefile - 1.156 - add stub files to obj-y instead of xfs-y to make the build work again. From owner-linux-xfs@oss.sgi.com Thu Mar 27 10:22:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Mar 2003 10:22:36 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2RIMXq9031537 for ; Thu, 27 Mar 2003 10:22:33 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2RIMXoi031535 for linux-xfs@oss.sgi.com; Thu, 27 Mar 2003 10:22:33 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2RIMVqB031522 for ; Thu, 27 Mar 2003 10:22:31 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2RHPeKh028640; Thu, 27 Mar 2003 09:25:40 -0800 Date: Thu, 27 Mar 2003 09:25:40 -0800 Message-Id: <200303271725.h2RHPeKh028640@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3404 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 793 Lines: 25 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From cattelan@thebarn.com 2003-03-27 09:25 ------- This bascially the same problem the umount code has run out of request. dumping the rqueue will show how many requests are pending vs how many are in flight. The request queue stuff in linux has a very delicate balnce point we need to find out what is getting stuck and thus causing the out of requests situation. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 27 10:21:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Mar 2003 10:21:58 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2RILDq9031373 for ; Thu, 27 Mar 2003 10:21:54 -0800 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18ybzE-0000J7-00 for ; Thu, 27 Mar 2003 19:20:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18yb1m-00043S-00 for ; Thu, 27 Mar 2003 18:18:58 +0100 From: Nicholas Wourms Subject: XFS in mainline 2.4? (was Re: [PATCH] d_alloc_anon for 2.4.21-pre6) Date: Thu, 27 Mar 2003 12:15:57 -0500 Message-ID: <3E8331CD.3050905@myrealbox.com> References: <20030327165112.A2395@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@main.gmane.org User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3403 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: nwourms@myrealbox.com Precedence: bulk X-list: linux-xfs Content-Length: 1200 Lines: 28 Christoph Hellwig wrote: > [$BIGNUM repost since August 2002, still zero feedback] > > The rewritten 2.5 nfsd export handling introduce a funcion, > d_alloc_anon, to get an dentry for a given inode, either taking > a well-connected one or allocating a new one. > > In 2.4 we have the functionality that it does in 2.4 duplicated over > nfsd and all filesystems having their own fh_to_dentry method, and > XFS needs even more instances of this for other handle to dentry > conversations. Speaking of XFS, would it be possible to merge it into the 2.4.X mainline any time soon? Despite what Alan says, XFS doesn't touch any more core code then his ide rewrite has. Also, the sendfile64 syscall modified core code as well. So, I don't think he or anyone else can get away with rejecting it based on it modifying core code. JFS has been in there for a few releases now, and I'd argue that there are probably more XFS users then JFS users. Since it was accepted into 2.5 awhile back, it seems appropriate (to me) that it eventually go into 2.4. IT would also have the side benefit of keeping the XFS code more (or less) in sync with what's in bk. Just a thought.... Cheers, Nicholas From owner-linux-xfs@oss.sgi.com Thu Mar 27 11:22:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Mar 2003 11:22:34 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2RJMWq9002448 for ; Thu, 27 Mar 2003 11:22:32 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2RJMWfO002446 for linux-xfs@oss.sgi.com; Thu, 27 Mar 2003 11:22:32 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2RJMVqB002433 for ; Thu, 27 Mar 2003 11:22:31 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2RIZhU0000596; Thu, 27 Mar 2003 10:35:43 -0800 Date: Thu, 27 Mar 2003 10:35:43 -0800 Message-Id: <200303271835.h2RIZhU0000596@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3405 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 450 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From christian.guggenberger@physik.uni-regensburg.de 2003-03-27 10:35 ------- okay. If someone gives me a hint, how to dump the requeue (and how to load kdb_pg and kdbm_vm - as mentioned in comment #13 of Bug 230), I'll take a look at it. thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 27 12:50:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Mar 2003 12:50:33 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2RKoSq9020000 for ; Thu, 27 Mar 2003 12:50:30 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18yeKQ-0001TU-00; Thu, 27 Mar 2003 20:50:26 +0000 Date: Thu, 27 Mar 2003 20:50:26 +0000 From: Christoph Hellwig To: Nicholas Wourms Cc: linux-xfs@oss.sgi.com Subject: Re: XFS in mainline 2.4? (was Re: [PATCH] d_alloc_anon for 2.4.21-pre6) Message-ID: <20030327205026.A5650@infradead.org> References: <20030327165112.A2395@infradead.org> <3E8331CD.3050905@myrealbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E8331CD.3050905@myrealbox.com>; from nwourms@myrealbox.com on Thu, Mar 27, 2003 at 12:15:57PM -0500 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3406 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: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 328 Lines: 8 On Thu, Mar 27, 2003 at 12:15:57PM -0500, Nicholas Wourms wrote: > Speaking of XFS, would it be possible to merge it into the > 2.4.X mainline any time soon? Talk to Marcelo. If he ever merges the 32bit quota patch I could start to feed him the few remaining XFS core changes, but without that it's not worth to even start. From owner-linux-xfs@oss.sgi.com Thu Mar 27 15:53:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Mar 2003 15:53:47 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2RNqpq9027776 for ; Thu, 27 Mar 2003 15:53:36 -0800 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18ygln-0004Ip-00 for ; Fri, 28 Mar 2003 00:26:51 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18yglm-0004IW-00 for ; Fri, 28 Mar 2003 00:26:50 +0100 From: Nicholas Wourms Subject: Re: XFS in mainline 2.4? (was Re: [PATCH] d_alloc_anon for 2.4.21-pre6) Date: Thu, 27 Mar 2003 18:23:34 -0500 Message-ID: <3E8387F6.9040607@myrealbox.com> References: <20030327165112.A2395@infradead.org> <3E8331CD.3050905@myrealbox.com> <20030327205026.A5650@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@main.gmane.org Cc: Christoph Hellwig , Marcelo Tosatti User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3407 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: nwourms@myrealbox.com Precedence: bulk X-list: linux-xfs Content-Length: 724 Lines: 24 Christoph Hellwig wrote: > On Thu, Mar 27, 2003 at 12:15:57PM -0500, Nicholas Wourms wrote: > >>Speaking of XFS, would it be possible to merge it into the >>2.4.X mainline any time soon? > > > Talk to Marcelo. If he ever merges the 32bit quota patch I could start > to feed him the few remaining XFS core changes, but without that it's > not worth to even start. > Marcelo, The 32bit quota backport has been in Alan's -ac series for ages now. I should think it has been thoroughly tested by now. I can't speak for everyone, but for me it operates quite well with XFS. Would it be possible to merge it into mainline anytime soon? If not, what remaining barriers prevent you from doing so? Cheers, Nicholas From owner-linux-xfs@oss.sgi.com Thu Mar 27 18:49:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Mar 2003 18:49:58 -0800 (PST) Received: from fuerzag.ulatina.ac.cr (fuerzag.ulatina.ac.cr [163.178.60.45]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2S2nhq9029268 for ; Thu, 27 Mar 2003 18:49:47 -0800 Received: from localhost.localdomain (unknown [192.168.32.10]) by fuerzag.ulatina.ac.cr (Postfix) with ESMTP id 9DE9833315 for ; Thu, 27 Mar 2003 20:38:21 -0600 (CST) Subject: [Trivial][Patch][CVS version] Acl's Makefile rm patch From: Alvaro Figueroa To: "linux-xfs@oss.sgi.com" Content-Type: multipart/mixed; boundary="=-GA5v0TfAImz+5oPa/Srx" X-Mailer: Ximian Evolution 1.0.5 Date: 27 Mar 2003 20:52:01 -0600 Message-Id: <1048819921.11523.6.camel@viena> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3408 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: fede2@fuerzag.ulatina.ac.cr Precedence: bulk X-list: linux-xfs Content-Length: 765 Lines: 32 --=-GA5v0TfAImz+5oPa/Srx Content-Type: text/plain Content-Transfer-Encoding: 7bit acl's Makefile tries to erase a couple of dirs with and rm that does not have the -r parameter. -- Alvaro Figueroa --=-GA5v0TfAImz+5oPa/Srx Content-Disposition: attachment; filename=xfs-cmds-acl-trivial_rm_fix.diff Content-Transfer-Encoding: quoted-printable Content-Type: text/x-patch; name=xfs-cmds-acl-trivial_rm_fix.diff; charset=ISO-8859-1 diff -ruN acl/include/Makefile acl-trivial_rm_fix/include/Makefile --- acl/include/Makefile Wed Feb 26 00:29:15 2003 +++ acl-trivial_rm_fix/include/Makefile Thu Mar 27 18:57:14 2003 @@ -38,7 +38,7 @@ LDIRT =3D sys acl =20 default: - rm -f sys acl + rm -rf sys acl $(LN_S) . sys $(LN_S) . acl =20 --=-GA5v0TfAImz+5oPa/Srx-- From owner-linux-xfs@oss.sgi.com Thu Mar 27 18:56:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Mar 2003 18:56:55 -0800 (PST) Received: from fuerzag.ulatina.ac.cr (fuerzag.ulatina.ac.cr [163.178.60.45]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2S2u3q9029743 for ; Thu, 27 Mar 2003 18:56:49 -0800 Received: from localhost.localdomain (unknown [192.168.32.10]) by fuerzag.ulatina.ac.cr (Postfix) with ESMTP id 7AB833332E for ; Thu, 27 Mar 2003 20:44:44 -0600 (CST) Subject: [Trivial][Patch][CVS version] Bogus ";" on debian/rules From: Alvaro Figueroa To: "linux-xfs@oss.sgi.com" Content-Type: multipart/mixed; boundary="=-JRUIXuBI2Qbg5aS30HuZ" X-Mailer: Ximian Evolution 1.0.5 Date: 27 Mar 2003 20:58:24 -0600 Message-Id: <1048820304.11608.12.camel@viena> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3409 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: fede2@fuerzag.ulatina.ac.cr Precedence: bulk X-list: linux-xfs Content-Length: 2009 Lines: 58 --=-JRUIXuBI2Qbg5aS30HuZ Content-Type: text/plain Content-Transfer-Encoding: 7bit I moved a couple of ";" from the variable assignment, to where the export of them takes place. It was generating some ";;"s. -- Alvaro Figueroa --=-JRUIXuBI2Qbg5aS30HuZ Content-Disposition: attachment; filename=xfs-cmds-xfsprogs_deb_rules.diff Content-Transfer-Encoding: quoted-printable Content-Type: text/x-patch; name=xfs-cmds-xfsprogs_deb_rules.diff; charset=ISO-8859-1 diff -ruN xfsprogs/debian/rules xfsprogs_deb_rules_fix/debian/rules --- xfsprogs/debian/rules Mon Mar 24 21:48:48 2003 +++ xfsprogs_deb_rules_fix/debian/rules Thu Mar 27 20:10:45 2003 @@ -12,8 +12,8 @@ pkgbfs =3D DIST_ROOT=3D`pwd`/$(dirbfs); export DIST_ROOT; stdenv =3D @GZIP=3D-q; export GZIP; =20 -options =3D DEBUG=3D-DNDEBUG; DISTRIBUTION=3Ddebian; LOCAL_CONFIGURE_OPTIO= NS=3D--enable-readline=3Dyes; export DEBUG DISTRIBUTION LOCAL_CONFIGURE_OPT= IONS; -bfsopts =3D $(options); OPTIMIZER=3D-Os; LOCAL_CONFIGURE_OPTIONS=3D"--enab= le-shared-uuid=3Dyes --enable-gettext=3Dno"; export OPTIMIZER LOCAL_CONFIGU= RE_OPTIONS; +options =3D DEBUG=3D-DNDEBUG; DISTRIBUTION=3Ddebian; LOCAL_CONFIGURE_OPTIO= NS=3D--enable-readline=3Dyes; export DEBUG DISTRIBUTION LOCAL_CONFIGURE_OPT= IONS +bfsopts =3D $(options); OPTIMIZER=3D-Os; LOCAL_CONFIGURE_OPTIONS=3D"--enab= le-shared-uuid=3Dyes --enable-gettext=3Dno"; export OPTIMIZER LOCAL_CONFIGU= RE_OPTIONS checkdir =3D test -f debian/rules =20 build: built @@ -26,14 +26,14 @@ .census: @echo "=3D=3D dpkg-buildpackage: configure" 1>&2 $(checkdir) - $(options) $(MAKE) configure + $(options); $(MAKE) configure touch .census =20 bfbuild:=20 $(checkdir) @echo "=3D=3D dpkg-buildpackage: bootfloppies" 1>&2 if [ ! -f mkfs/mkfs.xfs-$(bootpkg) ]; then \ - $(bfsopts) $(MAKE) configure; \ + $(bfsopts); $(MAKE) configure; \ for dir in libxfs libdisk mkfs; do $(MAKE) -C $$dir; done; \ mv mkfs/mkfs.xfs mkfs/mkfs.xfs-$(bootpkg); \ $(MAKE) distclean; \ --=-JRUIXuBI2Qbg5aS30HuZ-- From owner-linux-xfs@oss.sgi.com Thu Mar 27 18:58:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Mar 2003 18:58:34 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2S2wBq9029921 for ; Thu, 27 Mar 2003 18:58:31 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2S2w5uY001477 for ; Thu, 27 Mar 2003 18:58:05 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA29405; Fri, 28 Mar 2003 13:56:46 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id NAA45610; Fri, 28 Mar 2003 13:56:45 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2S2rc3u001944; Fri, 28 Mar 2003 13:53:38 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2S2rcq4001941; Fri, 28 Mar 2003 13:53:38 +1100 Date: Fri, 28 Mar 2003 13:53:38 +1100 From: Nathan Scott To: Alvaro Figueroa Cc: "linux-xfs@oss.sgi.com" Subject: Re: [Trivial][Patch][CVS version] Acl's Makefile rm patch Message-ID: <20030328025338.GI887@frodo> References: <1048819921.11523.6.camel@viena> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1048819921.11523.6.camel@viena> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3410 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 272 Lines: 10 On Thu, Mar 27, 2003 at 08:52:01PM -0600, Alvaro Figueroa wrote: > acl's Makefile tries to erase a couple of dirs with and rm that does not > have the -r parameter. No, these are created as symlinks, not directories, so -f is not the right thing to do here. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Mar 27 18:59:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Mar 2003 18:59:23 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2S2xIq9030487 for ; Thu, 27 Mar 2003 18:59:20 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2S3B2kq004963 for ; Thu, 27 Mar 2003 21:11:03 -0600 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA29414; Fri, 28 Mar 2003 13:57:55 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id NAA25275; Fri, 28 Mar 2003 13:57:54 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2S2sn3u001972; Fri, 28 Mar 2003 13:54:49 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2S2smhD001970; Fri, 28 Mar 2003 13:54:48 +1100 Date: Fri, 28 Mar 2003 13:54:48 +1100 From: Nathan Scott To: Alvaro Figueroa Cc: "linux-xfs@oss.sgi.com" Subject: Re: [Trivial][Patch][CVS version] Acl's Makefile rm patch Message-ID: <20030328025448.GJ887@frodo> References: <1048819921.11523.6.camel@viena> <20030328025338.GI887@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030328025338.GI887@frodo> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3411 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 420 Lines: 15 On Fri, Mar 28, 2003 at 01:53:38PM +1100, Nathan Scott wrote: > On Thu, Mar 27, 2003 at 08:52:01PM -0600, Alvaro Figueroa wrote: > > acl's Makefile tries to erase a couple of dirs with and rm that does not > > have the -r parameter. > > No, these are created as symlinks, not directories, so -f is > not the right thing to do here. ugh, I meant "-r is not the right thing to do here", of course. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Mar 27 19:01:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Mar 2003 19:01:56 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2S31nq9031027 for ; Thu, 27 Mar 2003 19:01:50 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2S31hnH030190 for ; Thu, 27 Mar 2003 19:01:43 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2S30Q7L4004317 for ; Fri, 28 Mar 2003 14:00:26 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2S30QHc3494094 for linux-xfs@oss.sgi.com; Fri, 28 Mar 2003 14:00:26 +1100 (EST) Date: Fri, 28 Mar 2003 14:00:26 +1100 (EST) From: Nathan Scott Message-Id: <200303280300.h2S30QHc3494094@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - minor cleanups X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3412 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 672 Lines: 28 Fix xfsdump compile warnings when building with recent xfs headers. Date: Tue Mar 25 22:10:15 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:142676a cmd/xfsdump/include/config.h.in - 1.6 Move some extern declarations out of a .c file into a .h file. Date: Thu Mar 27 18:59:15 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:142922a linux/fs/xfs/xfs_rw.h - 1.70 linux/fs/xfs/linux/xfs_ioctl.c - 1.89 From owner-linux-xfs@oss.sgi.com Thu Mar 27 19:13:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Mar 2003 19:13:49 -0800 (PST) Received: from fuerzag.ulatina.ac.cr (fuerzag.ulatina.ac.cr [163.178.60.45]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2S3Ctq9031524 for ; Thu, 27 Mar 2003 19:13:44 -0800 Received: from localhost.localdomain (unknown [192.168.32.10]) by fuerzag.ulatina.ac.cr (Postfix) with ESMTP id 6719B3332E for ; Thu, 27 Mar 2003 21:01:34 -0600 (CST) Subject: Re: [Trivial][Patch][CVS version] Acl's Makefile rm patch From: Alvaro Figueroa To: "linux-xfs@oss.sgi.com" In-Reply-To: <20030328025338.GI887@frodo> References: <1048819921.11523.6.camel@viena> <20030328025338.GI887@frodo> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 27 Mar 2003 21:15:13 -0600 Message-Id: <1048821314.11608.16.camel@viena> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3413 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: fede2@fuerzag.ulatina.ac.cr Precedence: bulk X-list: linux-xfs Content-Length: 328 Lines: 14 On Thu, 2003-03-27 at 20:53, Nathan Scott wrote: > No, these are created as symlinks, not directories, so -f is > not the right thing to do here. Well, I have the CVS version from today, and they are directories. They even hace a "CVS" directory in them :). (BTW, can you please loose the CC. Thanks.) -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Thu Mar 27 19:27:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Mar 2003 19:28:01 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2S3Rmq9032091 for ; Thu, 27 Mar 2003 19:27:58 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2S3RfnH032213 for ; Thu, 27 Mar 2003 19:27:42 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA29712; Fri, 28 Mar 2003 14:26:26 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id OAA17013; Fri, 28 Mar 2003 14:26:25 +1100 (AEDT) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2S3NJ3u002084; Fri, 28 Mar 2003 14:23:19 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2S3NJS8002082; Fri, 28 Mar 2003 14:23:19 +1100 Date: Fri, 28 Mar 2003 14:23:19 +1100 From: Nathan Scott To: cattelan@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: [Trivial][Patch][CVS version] Acl's Makefile rm patch Message-ID: <20030328032319.GK887@frodo> References: <1048819921.11523.6.camel@viena> <20030328025338.GI887@frodo> <1048821314.11608.16.camel@viena> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1048821314.11608.16.camel@viena> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3414 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 596 Lines: 20 On Thu, Mar 27, 2003 at 09:15:13PM -0600, Alvaro Figueroa wrote: > On Thu, 2003-03-27 at 20:53, Nathan Scott wrote: > > > No, these are created as symlinks, not directories, so -f is > > not the right thing to do here. > > Well, I have the CVS version from today, and they are directories. They > even hace a "CVS" directory in them :). > Ah, well - I wondered if reinstating those deleted entries in the cvs view might have some odd side-effects. These two at least need to not be there in the cvs tree. Probably not fatal though, just confusing for the cvs punters. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Mar 28 02:46:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Mar 2003 02:46:57 -0800 (PST) Received: from adsl.proware.com.tw (IDENT:OFBhAW8/6spCrWvUxyukr7UXPAfluO44@[211.20.79.38]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2SAkhq9012131 for ; Fri, 28 Mar 2003 02:46:45 -0800 Received: from proware.proware.com.tw (IDENT:BM5AIStIHUsrhNq6g/oA+ioRltb8KZYP@localhost [127.0.0.1]) by adsl.proware.com.tw (8.12.3/8.12.3) with ESMTP id h2SApPTP004796 for ; Fri, 28 Mar 2003 18:51:25 +0800 Received: from Rocky (199-rocky_lee_desktop [192.168.10.199]) by proware.proware.com.tw (8.12.3/8.12.3) with SMTP id h2SBLrY7007688 for ; Fri, 28 Mar 2003 19:21:58 +0800 Message-ID: <000901c2f517$73be00c0$c70aa8c0@RD.proware.com.tw> From: "Rocky Lee" Cc: References: <002401c2f418$163e4f90$c70aa8c0@RD.proware.com.tw> <20030327061815.GG5658@frodo> <006d01c2f433$545bffa0$c70aa8c0@RD.proware.com.tw> <1048767911.20049.40.camel@galadriel> Subject: Re: kernel patch fail with LVM Date: Fri, 28 Mar 2003 18:47:39 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3415 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: rocky_lee@proware.com.tw Precedence: bulk X-list: linux-xfs Content-Length: 363 Lines: 17 Hi. I try to patch lvm1.0.7-xfs-2.4.20.patch and XFS 2.4.20 patch, it looks OK now.. Rocky Lee ----- Original Message ----- From: "Marcel de Riedmatten" To: "Rocky Lee" Cc: "Nathan Scott" ; Sent: Thursday, March 27, 2003 8:25 PM Subject: Re: kernel patch fail with LVM From owner-linux-xfs@oss.sgi.com Fri Mar 28 03:28:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Mar 2003 03:28:39 -0800 (PST) Received: from web13602.mail.yahoo.com (web13602.mail.yahoo.com [216.136.175.113]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2SBRpq9013493 for ; Fri, 28 Mar 2003 03:28:29 -0800 Message-ID: <20030328112751.8209.qmail@web13602.mail.yahoo.com> Received: from [202.140.139.169] by web13602.mail.yahoo.com via HTTP; Fri, 28 Mar 2003 03:27:51 PST Date: Fri, 28 Mar 2003 03:27:51 -0800 (PST) From: kishor bhagwat Subject: LVM + XFS + Quotas To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3416 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: aaaaarrrgghhh@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 535 Lines: 19 Hello! I'm using RH 8.0 with kernel upgraded to kernel.org's 2.4.19, and XFS 1.2 patches. I'm able to create quotas etc..but there is an issue with the actual usable space. I create a directory with soft limit of 64 blks, but I'm not even able to 'touch newfile' in that directory -I get the "Disk Quota Limite Exceeded" error. Can someone help? regds, aaaaarrrrgghhh __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com From owner-linux-xfs@oss.sgi.com Fri Mar 28 10:26:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Mar 2003 10:27:08 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2SIQDq9023643 for ; Fri, 28 Mar 2003 10:26:54 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2SIQ7nH024919 for ; Fri, 28 Mar 2003 10:26:07 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA33563 for ; Fri, 28 Mar 2003 12:26:06 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2SIQ2wX37338298 for ; Fri, 28 Mar 2003 12:26:03 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h2T1fAs16861 for linux-xfs@oss.sgi.com; Fri, 28 Mar 2003 20:41:10 -0500 Resent-Message-Id: <200303290141.h2T1fAs16861@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2SIMbwX35609837 for ; Fri, 28 Mar 2003 12:22:37 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.8/8.11.4/nodin-1.0) with ESMTP id h2SIMZ4L27056305 for ; Fri, 28 Mar 2003 10:22:36 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h2SIJEZo020660 for ; Fri, 28 Mar 2003 19:19:14 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h2SIJEZ8020659 for hch@sgi.com; Fri, 28 Mar 2003 19:19:14 +0100 Date: Fri, 28 Mar 2003 19:19:14 +0100 From: Christoph Hellwig Message-Id: <200303281819.h2SIJEZ8020659@lab343.munich.sgi.com> Subject: TAKE - Merge up to 2.5.66 To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Fri, 28 Mar 2003 20:41:09 -0500 Resent-To: linux-xfs@oss.sgi.com X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3417 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: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 47833 Lines: 1260 Date: Fri Mar 28 10:18:16 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:142962a linux/include/asm-i386/pc9800_sca.h - 1.1 linux/sound/pci/ice1712/revo.h - 1.1 linux/sound/pci/ice1712/revo.c - 1.1 linux/sound/pci/ice1712/ice1724.c - 1.1 linux/Documentation/fb/cirrusfb.txt - 1.1 linux/sound/pci/cs46xx/imgs/cwcdma.h - 1.1 linux/include/asm-i386/upd4990a.h - 1.1 linux/sound/pci/cs46xx/imgs/cwcdma.asp - 1.1 linux/sound/isa/cs423x/sound_pc9800.h - 1.1 linux/sound/isa/cs423x/pc9801_118_magic.h - 1.1 linux/drivers/video/logo/logo_linux_vga16.ppm - 1.1 linux/sound/isa/cs423x/pc98.c - 1.1 linux/sound/core/sgbuf.c - 1.1 linux/sound/core/memory_wrapper.c - 1.1 linux/sound/core/memalloc.c - 1.1 linux/scripts/pnmtologo.c - 1.1 linux/include/asm-i386/mach-pc9800/setup_arch_post.h - 1.1 linux/arch/ppc/platforms/tqm8260_setup.c - 1.1 linux/drivers/input/serio/98kbd-io.c - 1.1 linux/net/nonet.c - 1.1 linux/include/video/pmag-ba-fb.h - 1.1 linux/drivers/video/logo/logo_linux_mono.pbm - 1.1 linux/drivers/video/logo/logo_linux_clut224.ppm - 1.1 linux/drivers/video/logo/logo_dec_clut224.ppm - 1.1 linux/include/video/pmagb-b-fb.h - 1.1 linux/drivers/video/logo/logo.c - 1.1 linux/include/video/sisfb.h - 1.1 linux/include/video/sstfb.h - 1.1 linux/drivers/video/logo/clut_vga16.ppm - 1.1 linux/drivers/net/ne2k_cbus.c - 1.1 linux/drivers/net/ne2k_cbus.h - 1.1 linux/net/ipv6/xfrm6_state.c - 1.1 linux/net/ipv6/xfrm6_policy.c - 1.1 linux/net/ipv6/xfrm6_input.c - 1.1 linux/arch/i386/boot98/Makefile - 1.1 linux/arch/i386/boot98/bootsect.S - 1.1 linux/arch/i386/boot98/compressed/Makefile - 1.1 linux/arch/i386/boot98/compressed/head.S - 1.1 linux/arch/i386/boot98/compressed/misc.c - 1.1 linux/arch/i386/boot98/compressed/vmlinux.scr - 1.1 linux/arch/i386/boot98/install.sh - 1.1 linux/arch/i386/boot98/mtools.conf.in - 1.1 linux/arch/i386/boot98/setup.S - 1.1 linux/arch/i386/boot98/tools/build.c - 1.1 linux/arch/i386/boot98/video.S - 1.1 linux/include/video/pm3fb.h - 1.1 linux/arch/ppc/platforms/mpc82xx.h - 1.1 linux/include/video/maxinefb.h - 1.1 linux/include/video/cirrus.h - 1.1 linux/include/sound/memalloc.h - 1.1 linux/drivers/video/logo/logo_superh_vga16.ppm - 1.1 linux/arch/ppc/platforms/est8260_setup.c - 1.1 linux/include/net/compat.h - 1.1 linux/drivers/video/logo/Makefile - 1.1 linux/drivers/video/logo/Kconfig - 1.1 linux/drivers/video/logo/logo_mac_clut224.ppm - 1.1 linux/include/linux/upd4990a.h - 1.1 linux/drivers/ide/ide-default.c - 1.1 linux/drivers/video/logo/logo_superh_mono.pbm - 1.1 linux/include/asm-i386/mach-default/mach_reboot.h - 1.1 linux/net/ipv6/anycast.c - 1.1 linux/drivers/video/logo/logo_parisc_clut224.ppm - 1.1 linux/include/asm-i386/mach-pc9800/setup_arch_pre.h - 1.1 linux/arch/i386/mach-pc9800/Makefile - 1.1 linux/arch/i386/mach-pc9800/setup.c - 1.1 linux/arch/i386/mach-pc9800/topology.c - 1.1 linux/include/asm-i386/mach-default/pci-functions.h - 1.1 linux/include/asm-arm/hardware/ssp.h - 1.1 linux/drivers/video/logo/logo_superh_clut224.ppm - 1.1 linux/net/ipv4/xfrm4_state.c - 1.1 linux/net/ipv4/xfrm4_policy.c - 1.1 linux/net/ipv4/xfrm4_input.c - 1.1 linux/drivers/ide/legacy/hd98.c - 1.1 linux/include/asm-i386/mach-pc9800/pci-functions.h - 1.1 linux/fs/partitions/nec98.c - 1.1 linux/include/asm-i386/mach-pc9800/mach_reboot.h - 1.1 linux/fs/partitions/nec98.h - 1.1 linux/drivers/i2c/busses/i2c-isa.c - 1.1 linux/drivers/ide/legacy/pc9800.c - 1.1 linux/drivers/char/upd4990a.c - 1.1 linux/drivers/serial/serial98.c - 1.1 linux/drivers/video/sis/sis_accel.h - 1.1 linux/drivers/video/logo/logo_sgi_clut224.ppm - 1.1 linux/drivers/video/cirrusfb.c - 1.1 linux/drivers/input/mouse/98busmouse.c - 1.1 linux/drivers/input/keyboard/98kbd.c - 1.1 linux/drivers/video/c2p.h - 1.1 linux/drivers/usb/misc/speedtch.c - 1.1 linux/drivers/char/lp_old98.c - 1.1 linux/drivers/video/logo/logo_sun_clut224.ppm - 1.1 linux/drivers/video/aty/aty128fb.c - 1.1 linux/drivers/video/c2p.c - 1.1 linux/drivers/video/aty/xlinit.c - 1.1 linux/scripts/Makefile - 1.19 linux/net/unix/af_unix.c - 1.54 linux/net/socket.c - 1.53 linux/net/netsyms.c - 1.64 linux/net/netlink/netlink_dev.c - 1.19 linux/net/irda/irlan/irlan_eth.c - 1.17 linux/net/irda/irda_device.c - 1.30 linux/net/ipv6/udp.c - 1.37 linux/net/ipv6/tcp_ipv6.c - 1.48 linux/net/ipv6/sit.c - 1.29 linux/net/ipv6/route.c - 1.31 linux/net/ipv6/reassembly.c - 1.16 linux/net/ipv6/ndisc.c - 1.31 linux/net/ipv6/ipv6_sockglue.c - 1.21 linux/net/ipv6/ip6_output.c - 1.19 linux/net/ipv6/ip6_input.c - 1.15 linux/net/ipv6/icmp.c - 1.26 linux/net/ipv6/exthdrs.c - 1.9 linux/net/ipv6/af_inet6.c - 1.31 linux/net/ipv6/addrconf.c - 1.33 linux/net/ipv6/Makefile - 1.14 linux/net/ipv4/udp.c - 1.40 linux/net/ipv4/tcp_output.c - 1.37 linux/net/ipv4/tcp_ipv4.c - 1.60 linux/net/ipv4/tcp.c - 1.53 linux/net/ipv4/route.c - 1.46 linux/net/ipv4/raw.c - 1.32 linux/net/ipv4/ipmr.c - 1.28 linux/net/ipv4/ipip.c - 1.29 linux/net/ipv4/ipconfig.c - 1.36 linux/net/ipv4/ip_output.c - 1.43 linux/net/ipv4/ip_input.c - 1.22 linux/net/ipv4/ip_gre.c - 1.28 linux/net/ipv4/ip_forward.c - 1.11 linux/net/ipv4/igmp.c - 1.24 linux/net/ipv4/arp.c - 1.29 linux/net/ipv4/af_inet.c - 1.50 linux/net/ipv4/Makefile - 1.17 linux/net/core/sock.c - 1.32 linux/net/core/skbuff.c - 1.31 linux/net/core/scm.c - 1.11 linux/net/core/neighbour.c - 1.19 linux/net/core/dst.c - 1.14 linux/net/core/dev.c - 1.70 linux/net/core/datagram.c - 1.15 linux/net/Makefile - 1.32 linux/mm/swapfile.c - 1.71 linux/mm/swap.c - 1.35 linux/mm/slab.c - 1.54 linux/mm/page_alloc.c - 1.105 linux/mm/mmap.c - 1.74 linux/mm/mlock.c - 1.17 linux/mm/memory.c - 1.103 linux/mm/filemap.c - 1.152 linux/kernel/sysctl.c - 1.64 linux/kernel/sys.c - 1.50 linux/kernel/signal.c - 1.52 linux/kernel/sched.c - 1.97 linux/kernel/ksyms.c - 1.186 linux/kernel/fork.c - 1.87 linux/include/net/transp_v6.h - 1.3 linux/include/net/tcp.h - 1.43 linux/include/net/protocol.h - 1.10 linux/include/net/ipv6.h - 1.14 linux/include/net/if_inet6.h - 1.9 linux/include/net/dst.h - 1.13 linux/include/net/addrconf.h - 1.12 linux/include/linux/vt_kern.h - 1.10 linux/include/linux/tcp.h - 1.14 linux/include/linux/swap.h - 1.74 linux/include/linux/socket.h - 1.14 linux/include/linux/skbuff.h - 1.32 linux/include/linux/serialP.h - 1.18 linux/include/linux/parport_pc.h - 1.11 linux/include/linux/parport.h - 1.25 linux/include/linux/pagemap.h - 1.53 linux/include/linux/nfsd/syscall.h - 1.9 linux/include/linux/netdevice.h - 1.43 linux/include/linux/module.h - 1.47 linux/include/linux/mman.h - 1.5 linux/include/linux/mm.h - 1.116 linux/include/linux/major.h - 1.31 linux/include/linux/list.h - 1.26 linux/include/linux/linux_logo.h - 1.4 linux/include/linux/ipv6.h - 1.6 linux/include/linux/ip.h - 1.8 linux/include/linux/ioport.h - 1.16 linux/include/linux/in6.h - 1.9 linux/include/linux/i2c.h - 1.21 linux/include/linux/fs.h - 1.210 linux/include/linux/file.h - 1.17 linux/include/linux/fb.h - 1.31 linux/include/linux/cyclades.h - 1.11 linux/include/linux/console_struct.h - 1.7 linux/include/asm-sparc64/timer.h - 1.5 linux/include/asm-sparc64/spitfire.h - 1.10 linux/include/asm-sparc64/pgtable.h - 1.41 linux/include/asm-sparc64/linux_logo.h - 1.5 linux/include/asm-sparc64/irq.h - 1.18 linux/include/asm-sparc64/ide.h - 1.21 linux/include/asm-sparc/linux_logo.h - 1.5 linux/include/asm-ppc/ide.h - 1.24 linux/include/asm-mips/linux_logo.h - 1.7 linux/include/asm-mips/elf.h - 1.11 linux/include/asm-m68k/unistd.h - 1.17 linux/include/asm-m68k/system.h - 1.13 linux/include/asm-m68k/siginfo.h - 1.10 linux/include/asm-m68k/page.h - 1.16 linux/include/asm-m68k/linux_logo.h - 1.5 linux/include/asm-m68k/io.h - 1.11 linux/include/asm-m68k/elf.h - 1.7 linux/include/asm-m68k/apollohw.h - 1.4 linux/include/asm-m68k/amigahw.h - 1.6 linux/include/asm-i386/uaccess.h - 1.21 linux/include/asm-i386/timex.h - 1.6 linux/include/asm-i386/system.h - 1.33 linux/include/asm-i386/processor.h - 1.51 linux/include/asm-i386/pgtable.h - 1.45 linux/include/asm-i386/linux_logo.h - 1.4 linux/include/asm-i386/io.h - 1.32 linux/include/asm-i386/hardirq.h - 1.27 linux/include/asm-i386/elf.h - 1.11 linux/include/asm-i386/bitops.h - 1.18 linux/include/asm-arm/proc-armv/system.h - 1.18 linux/include/asm-arm/linux_logo.h - 1.6 linux/include/asm-arm/elf.h - 1.7 linux/include/asm-arm/cache.h - 1.7 linux/include/asm-alpha/linux_logo.h - 1.4 linux/include/asm-alpha/elf.h - 1.8 linux/include/asm-alpha/core_cia.h - 1.14 linux/fs/ufs/util.c - 1.12 linux/fs/super.c - 1.99 linux/fs/select.c - 1.23 linux/fs/readdir.c - 1.21 linux/fs/proc/inode.c - 1.30 linux/fs/nfsd/vfs.c - 1.65 linux/fs/nfs/inode.c - 1.64 linux/fs/locks.c - 1.39 linux/fs/lockd/lockd_syms.c - 1.8 linux/fs/inode.c - 1.93 linux/fs/file_table.c - 1.31 linux/fs/fat/inode.c - 1.55 linux/fs/ext2/super.c - 1.45 linux/fs/ext2/dir.c - 1.29 linux/fs/exec.c - 1.80 linux/fs/dcache.c - 1.49 linux/fs/buffer.c - 1.152 linux/fs/binfmt_elf.c - 1.53 linux/fs/autofs/inode.c - 1.17 linux/fs/attr.c - 1.21 linux/fs/affs/super.c - 1.32 linux/drivers/video/tgafb.c - 1.24 linux/drivers/video/skeletonfb.c - 1.17 linux/drivers/video/q40fb.c - 1.18 linux/drivers/video/pm2fb.h - 1.5 linux/drivers/video/pm2fb.c - 1.19 linux/drivers/video/platinumfb.c - 1.20 linux/drivers/video/imsttfb.c - 1.27 linux/drivers/video/hpfb.c - 1.19 linux/drivers/video/fbmem.c - 1.61 linux/drivers/video/fbcmap.c - 1.9 linux/drivers/video/dnfb.c - 1.19 linux/drivers/video/controlfb.c - 1.28 linux/drivers/video/clgenfb.h - 1.6 linux/drivers/video/clgenfb.c - 1.31 linux/drivers/video/amifb.c - 1.28 linux/drivers/video/Makefile - 1.53 linux/drivers/scsi/wd7000.c - 1.24 linux/drivers/scsi/wd33c93.c - 1.13 linux/drivers/scsi/sym53c416.h - 1.8 linux/drivers/scsi/scsi.h - 1.47 linux/drivers/scsi/scsi.c - 1.73 linux/drivers/scsi/mesh.h - 1.9 linux/drivers/scsi/mesh.c - 1.14 linux/drivers/scsi/mac_NCR5380.c - 1.9 linux/drivers/scsi/mac53c94.h - 1.8 linux/drivers/scsi/mac53c94.c - 1.10 linux/drivers/scsi/gvp11.c - 1.15 linux/drivers/scsi/gdth_proc.h - 1.7 linux/drivers/scsi/gdth_proc.c - 1.16 linux/drivers/scsi/gdth_ioctl.h - 1.6 linux/drivers/scsi/gdth.h - 1.14 linux/drivers/scsi/gdth.c - 1.27 linux/drivers/scsi/fastlane.c - 1.13 linux/drivers/scsi/cyberstormII.c - 1.13 linux/drivers/scsi/cyberstorm.c - 1.13 linux/drivers/scsi/blz2060.c - 1.13 linux/drivers/scsi/blz1230.c - 1.13 linux/drivers/scsi/atari_scsi.h - 1.7 linux/drivers/scsi/atari_scsi.c - 1.12 linux/drivers/scsi/atari_NCR5380.c - 1.10 linux/drivers/scsi/amiga7xx.c - 1.11 linux/drivers/scsi/aha1542.c - 1.34 linux/drivers/scsi/aha152x.c - 1.38 linux/drivers/scsi/advansys.c - 1.34 linux/drivers/scsi/a3000.c - 1.14 linux/drivers/scsi/a2091.c - 1.17 linux/drivers/scsi/NCR53C9x.c - 1.24 linux/drivers/scsi/53c7xx.c - 1.23 linux/drivers/sbus/char/vfc_dev.c - 1.18 linux/drivers/sbus/char/bpp.c - 1.25 linux/drivers/pci/quirks.c - 1.37 linux/drivers/pci/pci.c - 1.66 linux/drivers/net/at1700.c - 1.24 linux/drivers/net/apne.c - 1.13 linux/drivers/net/Space.c - 1.42 linux/drivers/net/Makefile - 1.70 linux/drivers/net/8390.h - 1.14 linux/drivers/net/82596.c - 1.24 linux/drivers/net/3c509.c - 1.44 linux/drivers/net/3c501.c - 1.26 linux/drivers/macintosh/via-pmu.c - 1.25 linux/drivers/macintosh/via-cuda.c - 1.13 linux/drivers/macintosh/mediabay.c - 1.16 linux/drivers/macintosh/macserial.h - 1.10 linux/drivers/macintosh/macserial.c - 1.27 linux/drivers/macintosh/adb.c - 1.24 linux/drivers/fc4/fc_syms.c - 1.4 linux/drivers/char/vt.c - 1.35 linux/drivers/char/tty_io.c - 1.66 linux/drivers/char/stallion.c - 1.28 linux/drivers/char/serial167.c - 1.19 linux/drivers/char/rtc.c - 1.39 linux/drivers/char/pty.c - 1.16 linux/drivers/char/n_tty.c - 1.19 linux/drivers/char/misc.c - 1.34 linux/drivers/char/lp.c - 1.37 linux/drivers/char/istallion.c - 1.27 linux/drivers/char/ftape/zftape/zftape_syms.c - 1.5 linux/drivers/char/ftape/zftape/zftape-ctl.c - 1.8 linux/drivers/char/ftape/lowlevel/ftape_syms.c - 1.6 linux/drivers/char/cyclades.c - 1.29 linux/drivers/char/console_macros.h - 1.3 linux/drivers/char/Makefile - 1.84 linux/drivers/cdrom/sbpcd.c - 1.37 linux/drivers/cdrom/optcd.c - 1.31 linux/drivers/cdrom/cdu31a.c - 1.28 linux/drivers/cdrom/cdrom.c - 1.54 linux/drivers/block/xd.c - 1.53 linux/drivers/block/swim3.c - 1.28 linux/drivers/block/rd.c - 1.71 linux/drivers/block/paride/pt.c - 1.21 linux/drivers/block/paride/pg.c - 1.21 linux/drivers/block/nbd.c - 1.53 linux/drivers/block/loop.c - 1.81 linux/drivers/block/ll_rw_blk.c - 1.130 linux/drivers/block/genhd.c - 1.50 linux/drivers/block/floppy.c - 1.64 linux/drivers/block/amiflop.c - 1.38 linux/drivers/block/acsi_slm.c - 1.15 linux/drivers/acorn/scsi/acornscsi.c - 1.25 linux/arch/sparc64/solaris/socket.c - 1.13 linux/arch/sparc64/mm/ultra.S - 1.31 linux/arch/sparc64/kernel/traps.c - 1.27 linux/arch/sparc64/kernel/trampoline.S - 1.15 linux/arch/sparc64/kernel/time.c - 1.31 linux/arch/sparc64/kernel/sys_sunos32.c - 1.46 linux/arch/sparc64/kernel/sys_sparc32.c - 1.72 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.55 linux/arch/sparc64/kernel/smp.c - 1.54 linux/arch/sparc64/kernel/irq.c - 1.32 linux/arch/sparc64/kernel/head.S - 1.21 linux/arch/sparc64/defconfig - 1.89 linux/arch/sparc64/boot/Makefile - 1.7 linux/arch/sparc64/Makefile - 1.28 linux/arch/sparc/kernel/traps.c - 1.11 linux/arch/ppc/kernel/traps.c - 1.30 linux/arch/ppc/kernel/ppc_ksyms.c - 1.55 linux/arch/ppc/kernel/pci.c - 1.34 linux/arch/ppc/kernel/Makefile - 1.39 linux/arch/ppc/boot/Makefile - 1.23 linux/arch/ppc/Makefile - 1.39 linux/arch/mips/kernel/traps.c - 1.14 linux/arch/m68k/q40/q40ints.c - 1.10 linux/arch/m68k/mm/memory.c - 1.15 linux/arch/m68k/mac/macints.c - 1.13 linux/arch/m68k/kernel/traps.c - 1.19 linux/arch/m68k/kernel/time.c - 1.10 linux/arch/m68k/kernel/signal.c - 1.22 linux/arch/m68k/kernel/process.c - 1.20 linux/arch/m68k/kernel/m68k_ksyms.c - 1.16 linux/arch/m68k/kernel/head.S - 1.13 linux/arch/m68k/kernel/entry.S - 1.21 linux/arch/m68k/ifpsp060/iskeleton.S - 1.6 linux/arch/m68k/ifpsp060/fskeleton.S - 1.5 linux/arch/m68k/atari/stram.c - 1.26 linux/arch/m68k/atari/ataints.c - 1.11 linux/arch/m68k/apollo/config.c - 1.11 linux/arch/m68k/amiga/config.c - 1.18 linux/arch/m68k/amiga/chipram.c - 1.10 linux/arch/m68k/amiga/amisound.c - 1.12 linux/arch/i386/lib/usercopy.c - 1.10 linux/arch/i386/kernel/traps.c - 1.75 linux/arch/i386/kernel/process.c - 1.69 linux/arch/i386/kernel/irq.c - 1.56 linux/arch/i386/kernel/io_apic.c - 1.57 linux/arch/i386/kernel/entry.S - 1.77 linux/arch/arm/kernel/traps.c - 1.35 linux/arch/arm/kernel/time.c - 1.25 linux/arch/arm/kernel/ecard.c - 1.29 linux/arch/arm/boot/compressed/Makefile - 1.29 linux/Makefile - 1.243 linux/MAINTAINERS - 1.136 linux/Documentation/sysrq.txt - 1.15 linux/Documentation/fb/vesafb.txt - 1.4 linux/Documentation/fb/matroxfb.txt - 1.10 linux/CREDITS - 1.99 linux/include/linux/ide.h - 1.75 linux/include/linux/i2o.h - 1.19 linux/drivers/video/vga16fb.c - 1.19 linux/Documentation/kernel-parameters.txt - 1.24 linux/drivers/char/ppdev.c - 1.37 linux/drivers/block/cpqarray.c - 1.67 linux/Documentation/fb/tgafb.txt - 1.3 linux/kernel/ptrace.c - 1.32 linux/drivers/parport/share.c - 1.22 linux/drivers/parport/parport_pc.c - 1.55 linux/drivers/parport/parport_mfc3.c - 1.12 linux/drivers/parport/parport_atari.c - 1.6 linux/drivers/parport/parport_arc.c - 1.4 linux/drivers/parport/parport_amiga.c - 1.10 linux/drivers/parport/init.c - 1.13 linux/drivers/char/raw.c - 1.37 linux/drivers/net/ppp_generic.c - 1.35 linux/include/asm-i386/hw_irq.h - 1.34 linux/fs/partitions/sun.c - 1.9 linux/fs/partitions/sgi.c - 1.9 linux/fs/partitions/check.c - 1.66 linux/fs/partitions/amiga.c - 1.6 linux/fs/partitions/Makefile - 1.14 linux/drivers/scsi/sun3x_esp.c - 1.10 linux/arch/m68k/math-emu/fp_arith.c - 1.2 linux/Documentation/fb/clgenfb.txt - 1.7 linux/drivers/video/modedb.c - 1.9 linux/drivers/char/ip2/ip2.h - 1.4 linux/drivers/atm/suni.h - 1.3 linux/drivers/atm/suni.c - 1.12 linux/drivers/atm/nicstar.c - 1.22 linux/net/sched/sch_atm.c - 1.11 linux/arch/arm/kernel/bios32.c - 1.36 linux/arch/sh/kernel/traps.c - 1.13 linux/drivers/parport/parport_sunbpp.c - 1.9 linux/include/asm-sh/elf.h - 1.8 linux/drivers/pcmcia/tcic.c - 1.23 linux/drivers/pcmcia/rsrc_mgr.c - 1.18 linux/drivers/pcmcia/i82365.c - 1.36 linux/drivers/pcmcia/ds.c - 1.25 linux/drivers/pcmcia/cs.c - 1.35 linux/drivers/pcmcia/cistpl.c - 1.17 linux/drivers/pcmcia/cardbus.c - 1.28 linux/drivers/pcmcia/bulkmem.c - 1.16 linux/arch/m68k/vmlinux-sun3.lds - 1.16 linux/arch/m68k/mm/sun3mmu.c - 1.8 linux/include/pcmcia/ds.h - 1.6 linux/arch/m68k/mac/iop.c - 1.8 linux/include/asm-m68k/sun3-head.h - 1.2 linux/include/asm-ppc/pci.h - 1.19 linux/drivers/net/pcmcia/pcnet_cs.c - 1.23 linux/drivers/char/drm/gamma_dma.c - 1.12 linux/drivers/net/wan/cosa.c - 1.30 linux/arch/i386/kernel/smpboot.c - 1.60 linux/include/linux/pci_ids.h - 1.87 linux/drivers/video/tdfxfb.c - 1.28 linux/include/linux/pmu.h - 1.7 linux/include/linux/adb.h - 1.3 linux/arch/arm/boot/compressed/head-netwinder.S - 1.6 linux/mm/highmem.c - 1.50 linux/include/asm-i386/pgtable-3level.h - 1.14 linux/include/asm-i386/pgtable-2level.h - 1.12 linux/drivers/video/aty128fb.c - 1.32 linux/fs/proc/proc_misc.c - 1.58 linux/drivers/scsi/sun3_scsi.h - 1.6 linux/drivers/scsi/sun3_scsi.c - 1.16 linux/drivers/pci/pci.ids - 1.58 linux/drivers/net/sk98lin/skvpd.c - 1.8 linux/include/asm-arm/arch-cl7500/io.h - 1.7 linux/drivers/video/fbmon.c - 1.5 linux/kernel/timer.c - 1.42 linux/drivers/i2c/i2c-algo-pcf.c - 1.15 linux/drivers/i2c/i2c-dev.c - 1.26 linux/drivers/i2c/i2c-core.c - 1.24 linux/fs/cramfs/inode.c - 1.34 linux/drivers/telephony/ixj.c - 1.28 linux/net/decnet/dn_table.c - 1.7 linux/drivers/ieee1394/ieee1394_core.c - 1.29 linux/drivers/pci/setup-res.c - 1.15 linux/drivers/pci/setup-bus.c - 1.12 linux/drivers/scsi/scsi_scan.c - 1.43 linux/drivers/scsi/3w-xxxx.h - 1.18 linux/drivers/scsi/3w-xxxx.c - 1.28 linux/arch/m68k/apollo/dma.c - 1.2 linux/fs/autofs4/inode.c - 1.16 linux/drivers/net/macmace.c - 1.8 linux/drivers/char/vme_scc.c - 1.15 linux/drivers/atm/idt77105.c - 1.7 linux/arch/ia64/ia32/sys_ia32.c - 1.42 linux/arch/ia64/kernel/traps.c - 1.20 linux/include/linux/rtc.h - 1.9 linux/include/asm-ia64/ia32.h - 1.17 linux/include/asm-ia64/elf.h - 1.9 linux/include/asm-ia64/linux_logo.h - 1.3 linux/drivers/scsi/sun3_NCR5380.c - 1.10 linux/drivers/char/amiserial.c - 1.19 linux/arch/m68k/mac/baboon.c - 1.7 linux/include/linux/devfs_fs_kernel.h - 1.19 linux/fs/devfs/util.c - 1.18 linux/fs/devfs/base.c - 1.54 linux/drivers/char/nwflash.c - 1.18 linux/include/asm-mips64/elf.h - 1.9 linux/include/asm-mips64/linux_logo.h - 1.5 linux/arch/mips64/kernel/traps.c - 1.9 linux/drivers/video/riva/fbdev.c - 1.23 linux/drivers/video/hgafb.c - 1.18 linux/drivers/char/sh-sci.c - 1.22 linux/drivers/ide/ide.c - 1.82 linux/drivers/ide/ide-tape.c - 1.43 linux/drivers/ide/ide-proc.c - 1.27 linux/drivers/ide/ide-probe.c - 1.51 linux/drivers/ide/ide-geometry.c - 1.20 linux/drivers/ide/ide-dma.c - 1.38 linux/drivers/ide/ide-disk.c - 1.56 linux/drivers/ide/ide-cd.c - 1.59 linux/drivers/ide/Makefile - 1.36 linux/Documentation/DocBook/kernel-api.tmpl - 1.27 linux/net/ipv4/netfilter/ipt_unclean.c - 1.11 linux/net/ipv4/netfilter/ipt_tos.c - 1.5 linux/net/ipv4/netfilter/ipt_state.c - 1.6 linux/net/ipv4/netfilter/ipt_owner.c - 1.9 linux/net/ipv4/netfilter/ipt_multiport.c - 1.7 linux/net/ipv4/netfilter/ipt_mark.c - 1.5 linux/net/ipv4/netfilter/ipt_mac.c - 1.7 linux/net/ipv4/netfilter/ipt_limit.c - 1.6 linux/net/ipv4/netfilter/ipt_TOS.c - 1.9 linux/net/ipv4/netfilter/ipt_REJECT.c - 1.18 linux/net/ipv4/netfilter/ipt_REDIRECT.c - 1.7 linux/net/ipv4/netfilter/ipt_MIRROR.c - 1.10 linux/net/ipv4/netfilter/ipt_MASQUERADE.c - 1.10 linux/net/ipv4/netfilter/ipt_MARK.c - 1.5 linux/net/ipv4/netfilter/ipt_LOG.c - 1.11 linux/net/ipv4/netfilter/ipfwadm_core.c - 1.15 linux/net/ipv4/netfilter/ip_tables.c - 1.18 linux/net/ipv4/netfilter/ip_queue.c - 1.18 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.20 linux/drivers/usb/serial/whiteheat.c - 1.38 linux/include/asm-ppc/mpc8260.h - 1.6 linux/drivers/char/rio/riotty.c - 1.9 linux/drivers/char/rio/riotable.c - 1.9 linux/drivers/char/rio/rioroute.c - 1.8 linux/drivers/char/rio/rioparam.c - 1.6 linux/arch/ppc/8260_io/uart.c - 1.16 linux/drivers/char/rio/riointr.c - 1.7 linux/drivers/char/rio/rioinit.c - 1.8 linux/arch/ppc/8260_io/enet.c - 1.10 linux/drivers/char/rio/rioctrl.c - 1.11 linux/drivers/char/rio/riocmd.c - 1.10 linux/drivers/char/rio/rioboot.c - 1.9 linux/include/asm-s390/elf.h - 1.5 linux/drivers/s390/block/dasd.c - 1.39 linux/arch/s390/kernel/traps.c - 1.16 linux/net/ipv6/netfilter/ip6t_mark.c - 1.4 linux/net/ipv6/netfilter/ip6t_limit.c - 1.4 linux/net/ipv6/netfilter/ip6_tables.c - 1.17 linux/include/linux/netfilter_ipv6/ip6_tables.h - 1.5 linux/Documentation/DocBook/kernel-hacking.tmpl - 1.14 linux/include/linux/sisfb.h - 1.5 linux/arch/i386/kernel/msr.c - 1.19 linux/arch/i386/kernel/cpuid.c - 1.12 linux/drivers/video/hitfb.c - 1.11 linux/drivers/char/drm/i810_dma.c - 1.19 linux/include/asm-sh/linux_logo.h - 1.4 linux/net/ipv6/netfilter/ip6t_multiport.c - 1.3 linux/net/ipv6/netfilter/ip6t_mac.c - 1.5 linux/fs/jffs/intrep.c - 1.22 linux/fs/jffs/jffs_fm.c - 1.9 linux/drivers/ieee1394/video1394.c - 1.27 linux/drivers/mtd/mtdblock.c - 1.32 linux/drivers/mtd/mtdchar.c - 1.13 linux/include/asm-arm/mach/pci.h - 1.9 linux/include/asm-arm/mach/dma.h - 1.3 linux/include/asm-arm/mach/arch.h - 1.8 linux/drivers/media/video/cpia_usb.c - 1.19 linux/drivers/media/video/cpia_pp.c - 1.10 linux/drivers/media/video/cpia.h - 1.9 linux/drivers/media/video/cpia.c - 1.19 linux/drivers/media/video/bttv-if.c - 1.11 linux/drivers/media/video/bttv-cards.c - 1.19 linux/drivers/input/mousedev.c - 1.18 linux/drivers/input/input.c - 1.17 linux/drivers/input/evdev.c - 1.16 linux/drivers/md/raid1.c - 1.32 linux/Documentation/cciss.txt - 1.6 linux/Documentation/fb/sa1100fb.txt - 1.2 linux/arch/ppc/8260_io/fcc_enet.c - 1.7 linux/drivers/block/cciss.c - 1.54 linux/drivers/macintosh/mac_hid.c - 1.8 linux/drivers/md/linear.c - 1.20 linux/drivers/md/md.c - 1.72 linux/drivers/scsi/cpqfcTSinit.c - 1.28 linux/mm/oom_kill.c - 1.22 linux/drivers/video/sis/initdef.h - 1.4 linux/drivers/video/sis/sis.h - 1.3 linux/drivers/video/sis/sis_main.c - 1.16 linux/arch/parisc/kernel/entry.S - 1.8 linux/drivers/parport/parport_gsc.c - 1.10 linux/include/asm-parisc/linux_logo.h - 1.4 linux/include/asm-parisc/unistd.h - 1.8 linux/include/asm-parisc/ide.h - 1.9 linux/include/asm-parisc/posix_types.h - 1.4 linux/arch/parisc/kernel/traps.c - 1.8 linux/arch/parisc/kernel/syscall.S - 1.9 linux/arch/parisc/kernel/sys_parisc.c - 1.8 linux/arch/parisc/kernel/signal.c - 1.9 linux/include/asm-parisc/ptrace.h - 1.3 linux/arch/i386/kernel/dmi_scan.c - 1.27 linux/arch/parisc/kernel/process.c - 1.9 linux/arch/parisc/kernel/pci.c - 1.7 linux/include/asm-parisc/assembly.h - 1.5 linux/include/asm-parisc/signal.h - 1.3 linux/include/asm-parisc/elf.h - 1.3 linux/arch/parisc/kernel/init_task.c - 1.5 linux/arch/parisc/kernel/hardware.c - 1.4 linux/arch/parisc/kernel/cache.c - 1.4 linux/arch/parisc/kernel/Makefile - 1.11 linux/arch/parisc/Makefile - 1.14 linux/drivers/mtd/nftlmount.c - 1.7 linux/mm/shmem.c - 1.55 linux/fs/reiserfs/prints.c - 1.19 linux/fs/reiserfs/journal.c - 1.41 linux/arch/s390x/kernel/traps.c - 1.12 linux/drivers/video/riva/rivafb.h - 1.6 linux/include/asm-s390x/elf.h - 1.5 linux/include/asm-s390x/bitops.h - 1.7 linux/arch/s390x/kernel/linux32.c - 1.27 linux/arch/s390x/kernel/exec32.c - 1.7 linux/arch/s390x/kernel/binfmt_elf32.c - 1.8 linux/drivers/s390/block/xpram.c - 1.32 linux/include/asm-cris/elf.h - 1.4 linux/net/ipv4/netfilter/ipt_tcpmss.c - 1.3 linux/net/ipv4/netfilter/ipt_TCPMSS.c - 1.8 linux/drivers/sbus/char/riowatchdog.c - 1.5 linux/drivers/s390/char/tubfs.c - 1.9 linux/drivers/video/maxinefb.c - 1.9 linux/drivers/video/maxinefb.h - 1.2 linux/drivers/video/pmag-ba-fb.c - 1.8 linux/drivers/video/pmag-ba-fb.h - 1.2 linux/drivers/video/pmagb-b-fb.c - 1.8 linux/drivers/video/pmagb-b-fb.h - 1.3 linux/drivers/media/video/w9966.c - 1.7 linux/fs/char_dev.c - 1.8 linux/arch/ppc/boot/prep/Makefile - 1.14 linux/arch/ppc/boot/images/Makefile - 1.7 linux/include/asm-m68k/rtc.h - 1.5 linux/arch/m68k/sun3/sun3dvma.c - 1.3 linux/drivers/media/radio/miropcm20-rds.c - 1.6 linux/drivers/media/radio/miropcm20-rds-core.c - 1.6 linux/drivers/net/wireless/airo_cs.c - 1.6 linux/drivers/net/wireless/airo.c - 1.27 linux/drivers/net/irda/ali-ircc.c - 1.14 linux/drivers/scsi/pcmcia/nsp_cs.c - 1.17 linux/drivers/usb/usb-skeleton.c - 1.23 linux/Documentation/fb/pvr2fb.txt - 1.2 linux/drivers/message/fusion/mptctl.c - 1.14 linux/drivers/video/aty/mach64_gx.c - 1.6 linux/drivers/video/aty/Makefile - 1.7 linux/drivers/video/aty/atyfb.h - 1.6 linux/drivers/video/aty/atyfb_base.c - 1.18 linux/drivers/video/aty/mach64_accel.c - 1.7 linux/drivers/video/aty/mach64_ct.c - 1.5 linux/drivers/video/aty/mach64_cursor.c - 1.6 linux/drivers/char/drm/drm_ioctl.h - 1.4 linux/drivers/char/drm/mga_warp.c - 1.4 linux/drivers/char/drm/drm_vm.h - 1.17 linux/drivers/char/drm/drm_stub.h - 1.5 linux/drivers/char/drm/drm_scatter.h - 1.7 linux/drivers/char/drm/drm_proc.h - 1.4 linux/drivers/char/drm/drm_memory.h - 1.3 linux/drivers/char/drm/drm_lock.h - 1.3 linux/drivers/char/drm/drm_lists.h - 1.3 linux/drivers/char/drm/drm_init.h - 1.2 linux/drivers/char/drm/drm_fops.h - 1.4 linux/drivers/char/drm/drm_drv.h - 1.11 linux/drivers/char/drm/drm_drawable.h - 1.2 linux/drivers/char/drm/drm_dma.h - 1.5 linux/drivers/char/drm/drm_context.h - 1.6 linux/drivers/char/drm/drm_bufs.h - 1.4 linux/drivers/char/drm/drm_auth.h - 1.3 linux/drivers/char/drm/drm_agpsupport.h - 1.10 linux/drivers/char/drm/ati_pcigart.h - 1.7 linux/drivers/video/sstfb.h - 1.6 linux/drivers/video/sstfb.c - 1.14 linux/drivers/video/radeonfb.c - 1.14 linux/drivers/telephony/ixj_pcmcia.c - 1.4 linux/drivers/char/serial_tx3912.c - 1.9 linux/include/asm-mips/linux_logo_dec.h - 1.2 linux/include/asm-mips/linux_logo_sgi.h - 1.2 linux/drivers/char/decserial.c - 1.3 linux/drivers/char/ite_gpio.c - 1.5 linux/include/asm-generic/tlb.h - 1.12 linux/drivers/char/mwave/smapi.c - 1.2 linux/drivers/char/mwave/mwavepub.h - 1.2 linux/drivers/char/mwave/mwavedd.h - 1.2 linux/drivers/char/mwave/mwavedd.c - 1.6 linux/drivers/mtd/devices/blkmtd.c - 1.22 linux/drivers/i2c/i2c-proc.c - 1.13 linux/drivers/message/i2o/i2o_scsi.c - 1.13 linux/drivers/message/i2o/i2o_proc.c - 1.6 linux/drivers/message/i2o/i2o_pci.c - 1.7 linux/drivers/message/i2o/i2o_core.c - 1.11 linux/drivers/message/i2o/i2o_config.c - 1.9 linux/drivers/message/i2o/i2o_block.c - 1.32 linux/drivers/message/i2o/Makefile - 1.7 linux/net/ipv6/netfilter/ip6t_owner.c - 1.3 linux/net/ipv4/netfilter/ipt_ttl.c - 1.2 linux/net/ipv4/netfilter/ipt_length.c - 1.2 linux/net/8021q/vlan_dev.c - 1.7 linux/net/8021q/vlan.c - 1.8 linux/drivers/atm/idt77252.c - 1.9 linux/fs/jbd/journal.c - 1.20 linux/drivers/video/sis/300vtbl.h - 1.3 linux/drivers/video/sis/310vtbl.h - 1.3 linux/drivers/video/sis/325vtbl.h - 1.3 linux/drivers/video/sis/init.c - 1.3 linux/drivers/video/sis/init.h - 1.3 linux/drivers/video/sis/init301.c - 1.3 linux/drivers/video/sis/init301.h - 1.3 linux/drivers/video/sis/oem300.h - 1.3 linux/drivers/video/sis/oem310.h - 1.3 linux/drivers/video/sis/osdef.h - 1.3 linux/drivers/video/sis/sis_main.h - 1.4 linux/net/atm/pppoatm.c - 1.5 linux/drivers/video/sis/vgatypes.h - 1.3 linux/drivers/video/sis/vstruct.h - 1.3 linux/fs/ext3/inode.c - 1.35 linux/fs/ext3/ioctl.c - 1.8 linux/fs/ext3/namei.c - 1.19 linux/fs/ext3/super.c - 1.32 linux/fs/intermezzo/ext_attr.c - 1.6 linux/fs/intermezzo/file.c - 1.8 linux/fs/intermezzo/inode.c - 1.8 linux/fs/intermezzo/kml.c - 1.4 linux/fs/intermezzo/kml_decode.c - 1.3 linux/fs/intermezzo/kml_reint.c - 1.7 linux/fs/intermezzo/kml_setup.c - 1.3 linux/fs/intermezzo/methods.c - 1.9 linux/fs/intermezzo/super.c - 1.12 linux/fs/intermezzo/sysctl.c - 1.8 linux/include/linux/jbd.h - 1.15 linux/fs/intermezzo/vfs.c - 1.14 linux/include/linux/ext3_jbd.h - 1.10 linux/fs/reiserfs/procfs.c - 1.12 linux/fs/ext3/dir.c - 1.10 linux/fs/ext3/acl.c - 1.8 linux/fs/intermezzo/cache.c - 1.10 linux/fs/intermezzo/dir.c - 1.11 linux/fs/intermezzo/dcache.c - 1.8 linux/fs/bio.c - 1.28 linux/init/do_mounts.c - 1.27 linux/arch/arm/mach-clps7500/core.c - 1.3 linux/drivers/net/Makefile.lib - 1.6 linux/drivers/ide/ide-taskfile.c - 1.28 linux/drivers/ieee1394/dv1394.c - 1.13 linux/drivers/video/neofb.c - 1.12 linux/net/ipv6/netfilter/ip6_queue.c - 1.8 linux/net/ipv4/netfilter/ipt_esp.c - 1.5 linux/net/ipv4/netfilter/ipt_ah.c - 1.5 linux/net/ipv4/netfilter/ipt_ULOG.c - 1.7 linux/include/linux/thread_info.h - 1.4 linux/drivers/input/serio/Makefile - 1.8 linux/include/asm-sparc64/thread_info.h - 1.6 linux/sound/synth/emux/emux_seq.c - 1.6 linux/sound/sound_core.c - 1.8 linux/sound/pci/trident/trident_synth.c - 1.5 linux/sound/pci/trident/trident_memory.c - 1.6 linux/sound/pci/trident/trident_main.c - 1.11 linux/sound/pci/trident/trident.c - 1.9 linux/sound/pci/sonicvibes.c - 1.11 linux/sound/pci/rme9652/rme9652.c - 1.15 linux/sound/pci/maestro3.c - 1.13 linux/sound/pci/korg1212/korg1212.c - 1.17 linux/sound/pci/intel8x0.c - 1.16 linux/sound/pci/es1968.c - 1.15 linux/sound/pci/emu10k1/memory.c - 1.8 linux/sound/pci/emu10k1/emuproc.c - 1.8 linux/sound/pci/emu10k1/emupcm.c - 1.10 linux/sound/pci/emu10k1/emufx.c - 1.13 linux/sound/pci/emu10k1/emu10k1_main.c - 1.9 linux/sound/pci/cs46xx/cs46xx_lib.c - 1.14 linux/sound/pci/ac97/ac97_codec.c - 1.15 linux/arch/ppc/boot/simple/embed_config.c - 1.6 linux/sound/oss/sound_config.h - 1.3 linux/sound/oss/sequencer_syms.c - 1.2 linux/sound/oss/opl3sa2.c - 1.9 linux/sound/oss/nm256_audio.c - 1.4 linux/sound/oss/mpu401.c - 1.6 linux/sound/oss/midi_syms.c - 1.2 linux/sound/oss/maestro.c - 1.9 linux/sound/oss/mad16.c - 1.6 linux/sound/oss/i810_audio.c - 1.10 linux/sound/oss/gus_midi.c - 1.3 linux/sound/oss/emu10k1/voicemgr.h - 1.2 linux/sound/oss/emu10k1/voicemgr.c - 1.2 linux/sound/oss/emu10k1/timer.h - 1.2 linux/sound/oss/emu10k1/timer.c - 1.2 linux/sound/oss/emu10k1/recmgr.h - 1.2 linux/sound/oss/emu10k1/recmgr.c - 1.2 linux/sound/oss/emu10k1/passthrough.c - 1.3 linux/sound/oss/emu10k1/mixer.c - 1.2 linux/sound/oss/emu10k1/midi.c - 1.2 linux/sound/oss/emu10k1/main.c - 1.3 linux/sound/oss/emu10k1/irqmgr.c - 1.2 linux/sound/oss/emu10k1/hwaccess.h - 1.2 linux/sound/oss/emu10k1/hwaccess.c - 1.2 linux/sound/oss/emu10k1/efxmgr.h - 1.2 linux/sound/oss/emu10k1/efxmgr.c - 1.2 linux/sound/oss/emu10k1/cardwo.h - 1.2 linux/sound/oss/emu10k1/cardwo.c - 1.3 linux/sound/oss/emu10k1/cardwi.h - 1.2 linux/sound/oss/emu10k1/cardwi.c - 1.3 linux/sound/oss/emu10k1/audio.h - 1.2 linux/sound/oss/emu10k1/audio.c - 1.2 linux/arch/ppc/platforms/Makefile - 1.12 linux/arch/ppc/platforms/est8260.h - 1.3 linux/arch/ppc/platforms/k2_setup.c - 1.8 linux/arch/ppc/platforms/lopec_setup.c - 1.13 linux/arch/ppc/platforms/mcpn765_setup.c - 1.9 linux/arch/ppc/platforms/menf1_setup.c - 1.8 linux/arch/ppc/platforms/pmac_setup.c - 1.9 linux/arch/ppc/platforms/pplus_setup.c - 1.12 linux/arch/ppc/platforms/prep_setup.c - 1.13 linux/arch/ppc/platforms/sandpoint_setup.c - 1.10 linux/arch/ppc/platforms/tqm8260.h - 1.2 linux/sound/oss/cs46xx.c - 1.8 linux/sound/oss/cs4232.c - 1.7 linux/arch/x86_64/ia32/ia32_binfmt.c - 1.9 linux/arch/x86_64/ia32/sys_ia32.c - 1.17 linux/arch/x86_64/kernel/irq.c - 1.10 linux/arch/x86_64/kernel/traps.c - 1.14 linux/sound/oss/awe_wave.c - 1.5 linux/sound/oss/audio_syms.c - 1.2 linux/sound/isa/sgalaxy.c - 1.9 linux/sound/isa/sb/sb8_main.c - 1.5 linux/sound/isa/sb/sb8.c - 1.8 linux/sound/isa/sb/sb16_csp.c - 1.7 linux/sound/isa/sb/sb16.c - 1.10 linux/sound/isa/sb/es968.c - 1.8 linux/sound/isa/opti9xx/opti92x-ad1848.c - 1.10 linux/sound/isa/gus/interwave.c - 1.11 linux/sound/isa/gus/gus_synth.c - 1.6 linux/sound/isa/gus/gus_pcm.c - 1.7 linux/sound/isa/es18xx.c - 1.13 linux/sound/isa/cs423x/Makefile - 1.8 linux/sound/isa/cmi8330.c - 1.10 linux/sound/isa/azt2320.c - 1.8 linux/sound/isa/ad1816a/ad1816a.c - 1.7 linux/sound/drivers/opl3/opl3_seq.c - 1.8 linux/sound/drivers/opl3/opl3_oss.c - 1.5 linux/sound/drivers/opl3/Makefile - 1.11 linux/sound/drivers/mtpav.c - 1.14 linux/sound/drivers/mpu401/mpu401_uart.c - 1.11 linux/sound/drivers/mpu401/Makefile - 1.11 linux/sound/drivers/dummy.c - 1.12 linux/sound/core/wrappers.c - 1.4 linux/sound/core/timer.c - 1.13 linux/sound/core/sound.c - 1.14 linux/sound/core/seq/seq_timer.c - 1.9 linux/sound/core/seq/seq_ports.h - 1.2 linux/sound/core/seq/seq_ports.c - 1.8 linux/sound/core/seq/seq_midi.c - 1.9 linux/sound/core/seq/oss/seq_oss_synth.c - 1.7 linux/sound/core/seq/oss/seq_oss_midi.c - 1.7 linux/sound/core/seq/oss/seq_oss_init.c - 1.6 linux/sound/core/rawmidi.c - 1.14 linux/sound/core/pcm_native.c - 1.15 linux/sound/core/pcm_misc.c - 1.6 linux/sound/core/pcm_memory.c - 1.8 linux/sound/core/pcm_lib.c - 1.12 linux/sound/core/pcm.c - 1.9 linux/sound/core/oss/pcm_oss.c - 1.16 linux/sound/core/misc.c - 1.8 linux/sound/core/memory.c - 1.13 linux/sound/core/isadma.c - 1.6 linux/sound/core/init.c - 1.10 linux/sound/core/info.c - 1.13 linux/sound/core/hwdep.c - 1.7 linux/sound/core/control.c - 1.10 linux/sound/core/Makefile - 1.17 linux/include/asm-x86_64/pgtable.h - 1.14 linux/include/asm-x86_64/page.h - 1.9 linux/include/asm-x86_64/linux_logo.h - 1.2 linux/include/asm-x86_64/elf.h - 1.5 linux/include/sound/version.h - 1.17 linux/include/sound/trident.h - 1.6 linux/include/sound/timer.h - 1.4 linux/include/sound/sndmagic.h - 1.7 linux/include/sound/seq_kernel.h - 1.5 linux/include/sound/pcm.h - 1.11 linux/include/sound/mpu401.h - 1.5 linux/include/sound/initval.h - 1.6 linux/include/sound/hwdep.h - 1.2 linux/include/sound/emu10k1.h - 1.9 linux/include/sound/driver.h - 1.5 linux/include/sound/core.h - 1.17 linux/include/sound/asound.h - 1.11 linux/include/sound/ac97_codec.h - 1.12 linux/include/asm-ppc64/elf.h - 1.7 linux/arch/ppc64/kernel/prom.c - 1.12 linux/arch/ppc64/kernel/sys_ppc32.c - 1.19 linux/arch/ppc64/kernel/traps.c - 1.12 linux/include/asm-ppc64/linux_logo.h - 1.3 linux/include/asm-ppc64/pgtable.h - 1.11 linux/drivers/net/e1000/e1000_main.c - 1.17 linux/Documentation/networking/e1000.txt - 1.6 linux/drivers/net/e1000/e1000_osdep.h - 1.9 linux/drivers/net/e1000/e1000.h - 1.11 linux/drivers/net/e1000/e1000_ethtool.c - 1.9 linux/drivers/net/e1000/e1000_param.c - 1.8 linux/sound/core/ioctl32/timer32.c - 1.7 linux/drivers/net/tg3.c - 1.18 linux/sound/core/ioctl32/rawmidi32.c - 1.7 linux/drivers/net/tulip/winbond-840.c - 1.10 linux/sound/core/ioctl32/pcm32.c - 1.7 linux/sound/core/ioctl32/hwdep32.c - 1.4 linux/drivers/net/e100/e100_phy.h - 1.5 linux/drivers/net/e100/e100.h - 1.14 linux/drivers/net/e100/e100_ucode.h - 1.4 linux/drivers/net/e100/e100_vendor.h - 1.5 linux/Documentation/sound/alsa/CMIPCI.txt - 1.3 linux/drivers/net/e100/e100_phy.c - 1.6 linux/drivers/net/e100/e100_config.c - 1.9 linux/drivers/net/e100/e100_config.h - 1.6 linux/drivers/net/e100/e100_eeprom.c - 1.6 linux/drivers/net/e100/e100_main.c - 1.17 linux/net/ipv4/netfilter/arp_tables.c - 1.4 linux/drivers/media/video/bttv-risc.c - 1.5 linux/Documentation/sound/alsa/serial-u16550.txt - 1.3 linux/drivers/net/e1000/e1000_hw.h - 1.6 linux/drivers/usb/core/hub.c - 1.22 linux/include/asm-arm/arch-pxa/time.h - 1.4 linux/drivers/usb/input/hid-core.c - 1.17 linux/drivers/usb/host/ehci-dbg.c - 1.14 linux/drivers/usb/host/ehci-hcd.c - 1.19 linux/drivers/net/e1000/e1000_hw.c - 1.6 linux/drivers/usb/image/scanner.c - 1.20 linux/drivers/usb/image/scanner.h - 1.14 linux/drivers/usb/input/hiddev.c - 1.13 linux/drivers/net/e100/e100_test.c - 1.7 linux/drivers/usb/net/rtl8150.c - 1.13 linux/drivers/usb/net/pegasus.c - 1.13 linux/drivers/usb/net/cdc-ether.c - 1.11 linux/drivers/usb/misc/Makefile - 1.8 linux/drivers/usb/misc/auerswald.c - 1.15 linux/drivers/usb/misc/rio500.c - 1.9 linux/drivers/usb/misc/tiglusb.c - 1.12 linux/drivers/isdn/i4l/isdn_common.c - 1.12 linux/fs/exportfs/expfs.c - 1.9 linux/drivers/usb/misc/brlvger.c - 1.12 linux/include/sound/uda1341.h - 1.3 linux/sound/arm/sa11xx-uda1341.c - 1.10 linux/drivers/block/umem.c - 1.20 linux/arch/i386/pci/common.c - 1.9 linux/net/ipv6/ipv6_syms.c - 1.7 linux/include/linux/page-flags.h - 1.18 linux/arch/i386/pci/pcbios.c - 1.5 linux/mm/page-writeback.c - 1.21 linux/include/linux/buffer_head.h - 1.20 linux/include/linux/backing-dev.h - 1.5 linux/kernel/suspend.c - 1.22 linux/drivers/video/cfbcopyarea.c - 1.8 linux/drivers/char/drm/sis_mm.c - 1.2 linux/drivers/char/drm/sis_ds.c - 1.3 linux/drivers/char/drm/i830_dma.c - 1.7 linux/drivers/video/cfbfillrect.c - 1.6 linux/drivers/video/cfbimgblt.c - 1.8 linux/drivers/video/tridentfb.c - 1.5 linux/drivers/video/pm3fb.h - 1.3 linux/drivers/video/pm3fb.c - 1.5 linux/drivers/acorn/scsi/scsi.h - 1.5 linux/Documentation/networking/e100.txt - 1.3 linux/drivers/usb/core/message.c - 1.16 linux/include/linux/swapops.h - 1.3 linux/drivers/acpi/processor.c - 1.18 linux/arch/i386/kernel/cpu/intel.c - 1.13 linux/arch/i386/kernel/cpu/amd.c - 1.10 linux/sound/pci/rme9652/hdsp.c - 1.10 linux/sound/pci/rme9652/hammerfall_mem.c - 1.9 linux/drivers/input/tsdev.c - 1.6 linux/drivers/input/mouse/Makefile - 1.4 linux/drivers/input/keyboard/Makefile - 1.5 linux/drivers/usb/core/file.c - 1.4 linux/drivers/serial/uart00.c - 1.10 linux/mm/rmap.c - 1.11 linux/drivers/serial/8250_pnp.c - 1.6 linux/drivers/serial/8250_pci.c - 1.8 linux/drivers/video/sis/sisfb.h - 1.2 linux/include/video/mach64.h - 1.2 linux/include/linux/serial_core.h - 1.12 linux/drivers/char/drm/drm_os_linux.h - 1.5 linux/drivers/usb/misc/atmsar.c - 1.5 linux/drivers/usb/misc/atmsar.h - 1.5 linux/drivers/usb/misc/speedtouch.c - 1.14 linux/drivers/usb/class/usblp.c - 1.7 linux/net/ipv4/netfilter/ipt_DSCP.c - 1.2 linux/drivers/char/genrtc.c - 1.5 linux/net/ipv4/netfilter/ipt_ECN.c - 1.4 linux/net/ipv6/netfilter/ip6t_length.c - 1.2 linux/net/ipv6/netfilter/ip6t_eui64.c - 1.2 linux/net/ipv4/netfilter/ipt_pkttype.c - 1.2 linux/net/ipv4/netfilter/ipt_helper.c - 1.3 linux/include/asm-ppc/rtc.h - 1.4 linux/net/ipv4/netfilter/ipt_ecn.c - 1.2 linux/net/ipv4/netfilter/ipt_dscp.c - 1.2 linux/net/ipv4/netfilter/ipt_conntrack.c - 1.3 linux/net/sctp/sysctl.c - 1.4 linux/include/net/sctp/user.h - 1.4 linux/net/sctp/protocol.c - 1.14 linux/include/net/sctp/sctp.h - 1.11 linux/net/sctp/associola.c - 1.10 linux/net/sctp/bind_addr.c - 1.7 linux/net/sctp/endpointola.c - 1.7 linux/net/sctp/input.c - 1.11 linux/net/sctp/ipv6.c - 1.11 linux/net/sctp/output.c - 1.8 linux/net/sctp/outqueue.c - 1.10 linux/include/net/sctp/constants.h - 1.4 linux/net/sctp/tsnmap.c - 1.3 linux/include/net/sctp/sm.h - 1.9 linux/net/sctp/sm_make_chunk.c - 1.11 linux/include/net/sctp/command.h - 1.5 linux/net/sctp/sm_sideeffect.c - 1.12 linux/net/sctp/sm_statefuns.c - 1.11 linux/include/net/sctp/structs.h - 1.12 linux/net/sctp/socket.c - 1.12 linux/net/sctp/transport.c - 1.7 linux/net/sctp/ulpqueue.c - 1.7 linux/drivers/ide/ppc/pmac.c - 1.6 linux/drivers/ide/pci/via82cxxx.c - 1.8 linux/drivers/ide/pci/slc90e66.c - 1.7 linux/drivers/ide/pci/sis5513.c - 1.9 linux/drivers/ide/pci/siimage.c - 1.8 linux/drivers/ide/pci/serverworks.c - 1.8 linux/drivers/ide/pci/piix.h - 1.5 linux/drivers/ide/pci/piix.c - 1.8 linux/drivers/ide/pci/pdc202xx_old.c - 1.9 linux/drivers/ide/pci/pdc202xx_new.c - 1.10 linux/drivers/ide/pci/opti621.c - 1.7 linux/drivers/ide/pci/hpt366.c - 1.9 linux/drivers/ide/pci/hpt34x.c - 1.8 linux/drivers/ide/pci/cy82c693.c - 1.9 linux/drivers/ide/pci/cmd640.c - 1.4 linux/drivers/ide/pci/amd74xx.c - 1.12 linux/drivers/ide/pci/alim15x3.c - 1.7 linux/drivers/ide/pci/aec62xx.c - 1.8 linux/drivers/ide/legacy/umc8672.c - 1.4 linux/drivers/ide/legacy/qd65xx.c - 1.3 linux/drivers/ide/legacy/pdc4030.c - 1.5 linux/drivers/ide/legacy/ht6560b.c - 1.3 linux/drivers/ide/legacy/dtc2278.c - 1.3 linux/drivers/ide/legacy/ali14xx.c - 1.3 linux/drivers/ide/legacy/Makefile - 1.6 linux/include/asm-um/archparam-i386.h - 1.3 linux/drivers/ide/ide-lib.c - 1.8 linux/arch/um/drivers/line.c - 1.6 linux/arch/um/drivers/mmapper_kern.c - 1.4 linux/arch/um/drivers/ubd_kern.c - 1.11 linux/drivers/ide/ide-iops.c - 1.6 linux/include/asm-um/linux_logo.h - 1.2 linux/drivers/char/vt_ioctl.c - 1.4 linux/net/bridge/netfilter/ebtables.c - 1.6 linux/net/bridge/netfilter/ebtable_nat.c - 1.4 linux/net/bridge/netfilter/ebtable_filter.c - 1.4 linux/net/bridge/netfilter/ebtable_broute.c - 1.4 linux/arch/i386/kernel/reboot.c - 1.4 linux/net/bridge/netfilter/ebt_ip.c - 1.4 linux/arch/ppc/boot/openfirmware/Makefile - 1.6 linux/include/linux/netfilter_bridge/ebtables.h - 1.4 linux/sound/pci/cs46xx/dsp_spos_scb_lib.c - 1.8 linux/sound/pci/cs46xx/dsp_spos.c - 1.6 linux/sound/pci/cs46xx/cs46xx_lib.h - 1.5 linux/sound/pci/ac97/ac97_patch.c - 1.6 linux/sound/pci/ac97/ac97_id.h - 1.5 linux/sound/isa/dt019x.c - 1.4 linux/sound/core/pcm_sgbuf.c - 1.7 linux/kernel/cpufreq.c - 1.11 linux/include/sound/pcm_sgbuf.h - 1.6 linux/arch/i386/kernel/cpu/cpufreq/powernow-k6.c - 1.9 linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c - 1.10 linux/arch/i386/kernel/cpu/cpufreq/longrun.c - 1.9 linux/arch/i386/kernel/cpu/cpufreq/longhaul.c - 1.9 linux/sound/usb/usbquirks.h - 1.7 linux/sound/usb/usbmixer.c - 1.5 linux/sound/usb/usbmidi.c - 1.7 linux/sound/usb/usbaudio.h - 1.7 linux/sound/usb/usbaudio.c - 1.10 linux/sound/pci/via82xx.c - 1.8 linux/sound/pci/ice1712/ice1712.h - 1.6 linux/sound/pci/ice1712/ice1712.c - 1.6 linux/sound/pci/ice1712/ews.h - 1.2 linux/sound/pci/ice1712/ews.c - 1.6 linux/sound/pci/ice1712/delta.c - 1.5 linux/sound/pci/ice1712/ak4524.c - 1.6 linux/sound/pci/ice1712/Makefile - 1.5 linux/fs/cifs/cifs_debug.c - 1.7 linux/arch/i386/kernel/timers/timer_tsc.c - 1.10 linux/drivers/oprofile/buffer_sync.c - 1.9 linux/drivers/char/tipar.c - 1.6 linux/fs/intermezzo/replicator.c - 1.4 linux/arch/x86_64/kernel/pci-gart.c - 1.6 linux/fs/dcookies.c - 1.3 linux/Documentation/filesystems/sysfs.txt - 1.5 linux/drivers/pnp/pnpbios/core.c - 1.8 linux/include/linux/ioctl32.h - 1.2 linux/drivers/pnp/isapnp/core.c - 1.9 linux/drivers/pnp/pnpbios/proc.c - 1.2 linux/sound/isa/Kconfig - 1.2 linux/drivers/net/Kconfig - 1.10 linux/drivers/message/i2o/Kconfig - 1.4 linux/arch/arm/Kconfig - 1.9 linux/drivers/md/dm-linear.c - 1.4 linux/include/linux/eventpoll.h - 1.6 linux/arch/i386/Kconfig - 1.15 linux/drivers/media/dvb/dvb-core/dvbdev.c - 1.3 linux/include/asm-parisc/kmap_types.h - 1.2 linux/include/asm-parisc/cacheflush.h - 1.3 linux/arch/m68k/Kconfig - 1.10 linux/drivers/media/dvb/dvb-core/dvb_demux.c - 1.3 linux/arch/mips64/Kconfig - 1.8 linux/arch/parisc/kernel/binfmt_elf32.c - 1.4 linux/drivers/media/dvb/dvb-core/Kconfig - 1.2 linux/arch/parisc/kernel/ioctl32.c - 1.4 linux/fs/partitions/Kconfig - 1.2 linux/arch/parisc/kernel/sys32.h - 1.4 linux/arch/parisc/kernel/sys_parisc32.c - 1.9 linux/drivers/md/dm-stripe.c - 1.4 linux/drivers/md/dm-ioctl.c - 1.6 linux/include/linux/pfkeyv2.h - 1.4 linux/net/ipv4/ah.c - 1.7 linux/drivers/ide/Kconfig - 1.7 linux/drivers/block/Kconfig - 1.3 linux/fs/befs/debug.c - 1.2 linux/sound/pci/Kconfig - 1.4 linux/fs/Kconfig - 1.11 linux/drivers/input/keyboard/Kconfig - 1.4 linux/crypto/api.c - 1.6 linux/crypto/des.c - 1.5 linux/crypto/digest.c - 1.6 linux/net/ipv4/netfilter/ipt_physdev.c - 1.3 linux/net/ipv4/xfrm_policy.c - 1.8 linux/drivers/input/mouse/Kconfig - 1.5 linux/drivers/video/Kconfig - 1.10 linux/net/ipv4/xfrm_input.c - 1.5 linux/net/ipv4/xfrm_state.c - 1.6 linux/sound/oss/Kconfig - 1.6 linux/include/net/xfrm.h - 1.8 linux/drivers/input/serio/Kconfig - 1.6 linux/include/asm-m68k/kmap_types.h - 1.2 linux/fs/ext3/xattr.c - 1.6 linux/fs/ext2/xattr.c - 1.6 linux/fs/eventpoll.c - 1.7 linux/include/asm-m68knommu/elf.h - 1.3 linux/mm/fremap.c - 1.5 linux/include/asm-m68knommu/linux_logo.h - 1.2 linux/drivers/scsi/sun3_scsi_vme.c - 1.3 linux/drivers/parisc/eisa_eeprom.c - 1.3 linux/drivers/media/video/saa7134/saa7134-video.c - 1.5 linux/drivers/media/video/saa7134/saa7134-vbi.c - 1.4 linux/drivers/media/video/saa7134/saa7134-tvaudio.c - 1.5 linux/drivers/media/video/saa7134/saa7134-ts.c - 1.4 linux/drivers/media/video/saa7134/saa7134-oss.c - 1.4 linux/drivers/media/video/saa7134/saa7134-i2c.c - 1.6 linux/include/asm-v850/elf.h - 1.4 linux/arch/ppc/syslib/prom_init.c - 1.3 linux/arch/ppc/syslib/prom.c - 1.2 linux/arch/ppc/syslib/ppc4xx_setup.c - 1.3 linux/net/key/af_key.c - 1.8 linux/arch/ppc/syslib/m8260_setup.c - 1.2 linux/arch/ppc/syslib/Makefile - 1.5 linux/net/ipv4/esp.c - 1.6 linux/include/linux/compat.h - 1.5 linux/drivers/ide/pci/sc1200.c - 1.5 linux/include/asm-sparc64/compat.h - 1.6 linux/drivers/video/console/Kconfig - 1.5 linux/drivers/video/console/fbcon.c - 1.4 linux/drivers/video/console/fbcon.h - 1.3 linux/drivers/video/console/newport_con.c - 1.3 linux/drivers/video/console/vgacon.c - 1.2 linux/drivers/video/sis/sis_accel.c - 1.2 linux/crypto/twofish.c - 1.2 linux/drivers/video/softcursor.c - 1.2 linux/crypto/serpent.c - 1.2 linux/drivers/ide/pci/cs5520.c - 1.5 linux/fs/compat.c - 1.4 linux/net/ipv4/xfrm_user.c - 1.5 linux/include/asm-ppc64/compat.h - 1.5 linux/drivers/char/watchdog/acquirewdt.c - 1.6 linux/mm/nommu.c - 1.2 linux/drivers/ide/ide-io.c - 1.5 linux/drivers/char/watchdog/ib700wdt.c - 1.5 linux/drivers/char/watchdog/machzwd.c - 1.6 linux/drivers/char/watchdog/mixcomwd.c - 1.5 linux/drivers/char/watchdog/pcwd.c - 1.6 linux/drivers/char/watchdog/sbc60xxwdt.c - 1.6 linux/include/video/vga.h - 1.2 linux/drivers/char/watchdog/wdt977.c - 1.6 linux/drivers/char/watchdog/wdt_pci.c - 1.5 linux/drivers/char/watchdog/shwdt.c - 1.5 linux/include/linux/xfrm.h - 1.3 linux/drivers/char/watchdog/softdog.c - 1.5 linux/Documentation/sound/alsa/ALSA-Configuration.txt - 1.4 linux/Documentation/sound/alsa/ControlNames.txt - 1.2 linux/include/asm-x86_64/compat.h - 1.6 linux/drivers/i2c/busses/Kconfig - 1.4 linux/drivers/i2c/busses/Makefile - 1.3 linux/drivers/i2c/busses/i2c-amd756.c - 1.3 linux/drivers/i2c/busses/i2c-amd8111.c - 1.4 linux/drivers/i2c/chips/adm1021.c - 1.4 linux/drivers/i2c/chips/lm75.c - 1.4 linux/include/asm-s390x/compat.h - 1.6 linux/sound/pci/ice1712/envy24ht.h - 1.2 linux/sound/pci/ice1712/amp.h - 1.2 linux/drivers/video/i810/i810.h - 1.3 linux/drivers/video/i810/i810_accel.c - 1.3 linux/drivers/video/i810/i810_main.c - 1.3 linux/drivers/video/i810/i810_main.h - 1.3 linux/crypto/aes.c - 1.2 linux/net/ipv4/xfrm_algo.c - 1.3 linux/drivers/char/watchdog/indydog.c - 1.4 linux/drivers/char/watchdog/sc520_wdt.c - 1.6 linux/include/asm-parisc/bug.h - 1.3 linux/include/asm-parisc/compat.h - 1.4 linux/drivers/char/ipmi/ipmi_devintf.c - 1.2 linux/arch/parisc/kernel/module.c - 1.3 linux/drivers/video/riva/nv_driver.c - 1.2 linux/drivers/eisa/eisa-bus.c - 1.4 linux/Documentation/sound/alsa/DocBook/alsa-driver-api.tmpl - 1.2 linux/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl - 1.4 linux/drivers/net/wireless/ray_cs.c - 1.2 linux/kernel/posix-timers.c - 1.4 linux/net/ipv6/netfilter/ip6t_frag.c - 1.3 linux/net/ipv6/netfilter/ip6t_rt.c - 1.3 linux/net/ipv6/netfilter/ip6t_ipv6header.c - 1.3 linux/net/ipv6/netfilter/ip6t_hl.c - 1.2 linux/net/ipv6/netfilter/ip6t_hbh.c - 1.3 linux/net/ipv6/netfilter/ip6t_esp.c - 1.3 linux/fs/sysfs/file.c - 1.2 linux/drivers/video/cg6.c - 1.3 linux/net/ipv6/netfilter/ip6t_dst.c - 1.3 linux/drivers/video/ffb.c - 1.3 linux/net/ipv6/netfilter/ip6t_ah.c - 1.3 linux/drivers/video/sbuslib.c - 1.3 linux/drivers/i2c/busses/i2c-ali15x3.c - 1.2 linux/net/compat.c - 1.2 linux/include/net/compat_socket.h - 1.2 linux/arch/arm/mach-sa1100/ssp.c - 1.2 linux/net/ipv6/ah6.c - 1.2 linux/drivers/i2c/busses/i2c-piix4.c - 1.2 linux/drivers/i2c/busses/i2c-i801.c - 1.2 linux/net/ipv6/esp6.c - 1.2 From owner-linux-xfs@oss.sgi.com Fri Mar 28 13:01:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Mar 2003 13:02:06 -0800 (PST) Received: from fuerzag.ulatina.ac.cr (fuerzag.ulatina.ac.cr [163.178.60.45]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2SL1tq9026659 for ; Fri, 28 Mar 2003 13:01:57 -0800 Received: from localhost.localdomain (unknown [192.168.32.10]) by fuerzag.ulatina.ac.cr (Postfix) with ESMTP id 83B5633330 for ; Fri, 28 Mar 2003 14:50:36 -0600 (CST) Subject: QA tests on sparc From: Alvaro Figueroa To: "linux-xfs@oss.sgi.com" Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 28 Mar 2003 15:03:55 -0600 Message-Id: <1048885435.12693.4.camel@viena> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3419 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: fede2@fuerzag.ulatina.ac.cr Precedence: bulk X-list: linux-xfs Content-Length: 540 Lines: 18 FWIW, I'm on the task of improving a bit XFS for the ultrasparc arquitecture. Right know, I'm using the kernel and the usersparc tools from the CVS. The kernel compiles properly and so do the userland tools. I've just runned the QA tests, and more than half of them failed for diferente reasons (such as not implemented ioctls, invalid arguments, and bus errors). I hope I can make mutch of this bugs dissapear. Right know, the only tests that finnished properly are: 001-007,011,013-017,029-030,033,045,069-070. -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Fri Mar 28 14:39:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Mar 2003 14:39:14 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2SMcOq9027584 for ; Fri, 28 Mar 2003 14:39:05 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 6AF1618503FE; Fri, 28 Mar 2003 14:38:23 -0800 (PST) Date: Fri, 28 Mar 2003 14:38:23 -0800 From: Chris Wedgwood To: kishor bhagwat Cc: linux-xfs@oss.sgi.com Subject: Re: LVM + XFS + Quotas Message-ID: <20030328223823.GB7894@f00f.org> References: <20030328112751.8209.qmail@web13602.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030328112751.8209.qmail@web13602.mail.yahoo.com> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3420 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 475 Lines: 19 On Fri, Mar 28, 2003 at 03:27:51AM -0800, kishor bhagwat wrote: > I'm using RH 8.0 with kernel upgraded to kernel.org's 2.4.19, and > XFS 1.2 patches. > I'm able to create quotas etc..but there is an issue with the actual > usable space. what does 'quota' report? > I create a directory with soft limit of 64 blks, but I'm not even > able to 'touch newfile' in that directory -I get the "Disk Quota > Limite Exceeded" error. what does "stat " report? --cw From owner-linux-xfs@oss.sgi.com Fri Mar 28 14:58:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Mar 2003 14:58:13 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2SMvTq9028120 for ; Fri, 28 Mar 2003 14:58:10 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2SN9Ikq003486 for ; Fri, 28 Mar 2003 17:09:18 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA10878 for ; Fri, 28 Mar 2003 16:57:23 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2SMvNCI6445232 for ; Fri, 28 Mar 2003 16:57:23 -0600 (CST) Subject: TAKE - another realtime fix From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 28 Mar 2003 16:57:06 -0600 Message-Id: <1048892226.15055.20.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3421 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 553 Lines: 21 realtime still doesn't work, but at least now you can read from the right device... Set proper device for realtime files in linvfs_get_block_core Date: Fri Mar 28 14:53:54 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:143006a linux/fs/xfs/linux/xfs_aops.c - 1.29 -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Mar 28 14:59:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Mar 2003 14:59:12 -0800 (PST) Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2SMwKq9028196 for ; Fri, 28 Mar 2003 14:59:00 -0800 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel7.hp.com (Postfix) with ESMTP id 269501C00BA3 for ; Fri, 28 Mar 2003 17:28:35 -0500 (EST) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 0CFC31C009FB for ; Fri, 28 Mar 2003 17:28:35 -0500 (EST) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Fri, 28 Mar 2003 17:28:04 -0500 Message-ID: From: "HABBINGA,ERIK (HP-Loveland,ex1)" To: "'linux-xfs@oss.sgi.com'" Subject: crash in linvfs_dentry_to_fh Date: Fri, 28 Mar 2003 17:27:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3422 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: erik.habbinga@hp.com Precedence: bulk X-list: linux-xfs Content-Length: 3551 Lines: 95 I get the following crash in linvfs_dentry_to_fh after pushing a server very hard with the SPEC SFS NFS test. It's a similar crash to the xfs_inactive crash I mentioned earlier in the week. Not always repeatable, but we've seen it a few times: ksymoops 2.4.5 on i686 2.4.18-14. Options used -V (default) -K (specified) -L (specified) -O (specified) -m System.map (specified) Unable to handle kernel NULL pointer dereference at virtual address 00000008 printing eip: 801d9578 *pde = 72da5001 Oops: 0000 CPU: 0 EIP: 0010:[<801d9578>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 00000000 ebx: 0000000d ecx: f508f100 edx: 80336b20 esi: f2121ec4 edi: f4cb64a4 ebp: f2121f04 esp: f2121eb4 ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 4074, stackpage=f2121000) Stack: f4cb6494 f2093000 f4cb64a4 94d29220 fffffff4 94d29220 f508f0e0 8014236d 8016b515 94d29220 f4cb64a4 f2121f04 00000001 94d295a0 94d295a0 0000000d f4cb6404 80336b20 f2121f04 f508f100 0000000d 8016bf65 f4cb6494 f2093000 Call Trace: [<8014236d>] [<8016b515>] [<8016bf65>] [<802c2a24>] [<80171e58>] [<80168eb3>] [<802c2635>] [<80168c67>] [<80105694>] Code: 8b 50 08 56 8b 41 f4 50 8b 42 50 ff d0 8b 44 24 20 89 07 8b >>EIP; 801d9578 <===== >>ecx; f508f100 >>edx; 80336b20 >>esi; f2121ec4 >>edi; f4cb64a4 >>ebp; f2121f04 >>esp; f2121eb4 Trace; 8014236d Trace; 8016b515 Trace; 8016bf65 Trace; 802c2a24 Trace; 80171e58 Trace; 80168eb3 Trace; 802c2635 Trace; 80168c67 Trace; 80105694 Code; 801d9578 00000000 <_EIP>: Code; 801d9578 <===== 0: 8b 50 08 mov 0x8(%eax),%edx <===== Code; 801d957b 3: 56 push %esi Code; 801d957c 4: 8b 41 f4 mov 0xfffffff4(%ecx),%eax Code; 801d957f 7: 50 push %eax Code; 801d9580 8: 8b 42 50 mov 0x50(%edx),%eax Code; 801d9583 b: ff d0 call *%eax Code; 801d9585 d: 8b 44 24 20 mov 0x20(%esp,1),%eax Code; 801d9589 11: 89 07 mov %eax,(%edi) Code; 801d958b 13: 8b 00 mov (%eax),%eax The code in question is derefencing the vp->v_bh pointer to get the vp->v_bh.bh_first->bd_ops (also known as vp->v_fops) pointer in preparation for getting the vop_fid2 function pointer. vp->v_bh is NULL, which causes the crash. Dissassembly of linvfs_dentry_to_fh: /src/kernel/linux/fs/xfs/linux/xfs_super.c:724 VOP_FID2(vp, (struct fid *)&fid, error); 801d9571: 8b 41 f4 mov 0xfffffff4(%ecx),%eax 801d9574: 8d 74 24 10 lea 0x10(%esp,1),%esi 801d9578: 8b 50 08 mov 0x8(%eax),%edx We're running 2.4.20 with XFS CVS from March 17th. Erik Habbinga Hewlett Packard From owner-linux-xfs@oss.sgi.com Fri Mar 28 15:01:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Mar 2003 15:01:56 -0800 (PST) Received: from fuerzag.ulatina.ac.cr (fuerzag.ulatina.ac.cr [163.178.60.45]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2SN1jq9029012 for ; Fri, 28 Mar 2003 15:01:50 -0800 Received: from localhost.localdomain (unknown [192.168.32.10]) by fuerzag.ulatina.ac.cr (Postfix) with ESMTP id E567833315 for ; Fri, 28 Mar 2003 16:50:25 -0600 (CST) Subject: Re: QA tests on sparc From: Alvaro Figueroa To: "linux-xfs@oss.sgi.com" In-Reply-To: <3E84BEF6.4010408@mvista.com> References: <1048885435.12693.4.camel@viena> <3E84BEF6.4010408@mvista.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 28 Mar 2003 17:03:42 -0600 Message-Id: <1048892622.11814.7.camel@viena> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3423 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: fede2@fuerzag.ulatina.ac.cr Precedence: bulk X-list: linux-xfs Content-Length: 267 Lines: 10 On Fri, 2003-03-28 at 15:30, Steven Dake wrote: > where did you get the qa tests? I was looking for something like that I used the CVS instructions to download the source for the xfs commands. Please check XFS' webpage for more info on that. -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Fri Mar 28 16:01:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Mar 2003 16:01:51 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2T01cq9029782 for ; Fri, 28 Mar 2003 16:01:39 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2T0DRkq005697 for ; Fri, 28 Mar 2003 18:13:28 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA50242 for ; Fri, 28 Mar 2003 18:01:33 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2T01WCI5986210 for ; Fri, 28 Mar 2003 18:01:33 -0600 (CST) Subject: TAKE - another realtime fix - set rtdev blocksize correctly From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 28 Mar 2003 18:01:15 -0600 Message-Id: <1048896075.18092.26.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3424 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 649 Lines: 24 With this, realtime should work reasonably well again, but don't trust your data to it yet. :) I can read & write realtime files correctly, but running stress sometimes still corrupts the filesystem. Set correct block size for realtime device Date: Fri Mar 28 15:57:48 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:143019a linux/fs/xfs/xfs_vfsops.c - 1.412 -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Mar 28 19:06:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Mar 2003 19:06:27 -0800 (PST) Received: from web13606.mail.yahoo.com (web13606.mail.yahoo.com [216.136.175.117]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2T35aq9031965 for ; Fri, 28 Mar 2003 19:06:17 -0800 Message-ID: <20030329030536.47438.qmail@web13606.mail.yahoo.com> Received: from [202.63.168.36] by web13606.mail.yahoo.com via HTTP; Fri, 28 Mar 2003 19:05:36 PST Date: Fri, 28 Mar 2003 19:05:36 -0800 (PST) From: kishor bhagwat Subject: Re: LVM + XFS + Quotas To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030328223823.GB7894@f00f.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3425 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: aaaaarrrgghhh@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 977 Lines: 41 --- Chris Wedgwood wrote: > On Fri, Mar 28, 2003 at 03:27:51AM -0800, kishor bhagwat > wrote: > > > I'm using RH 8.0 with kernel upgraded to kernel.org's > 2.4.19, and > > XFS 1.2 patches. > > > I'm able to create quotas etc..but there is an issue > with the actual > > usable space. > > what does 'quota' report? quota reports..... Filesystem /dev/HOME/DataVol blocks quota limit grace files quota limit grace 32 64 80 12 0 0 > > I create a directory with soft limit of 64 blks, but > I'm not even > > able to 'touch newfile' in that directory -I get the > "Disk Quota > > Limite Exceeded" error. > > what does "stat " report? i'm not aware of the stat command, and I dont seem to have it on my machine... regds, kishor __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com From owner-linux-xfs@oss.sgi.com Fri Mar 28 20:50:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Mar 2003 20:50:12 -0800 (PST) Received: from web13608.mail.yahoo.com (web13608.mail.yahoo.com [216.136.175.119]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2T4o2q9000585 for ; Fri, 28 Mar 2003 20:50:03 -0800 Message-ID: <20030329045002.69738.qmail@web13608.mail.yahoo.com> Received: from [202.63.168.36] by web13608.mail.yahoo.com via HTTP; Fri, 28 Mar 2003 20:50:02 PST Date: Fri, 28 Mar 2003 20:50:02 -0800 (PST) From: kishor bhagwat Subject: Re: LVM + XFS + Quotas(with stat output) To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030328223823.GB7894@f00f.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3426 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: aaaaarrrgghhh@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 532 Lines: 20 installed stat... here's te output.. File: "/home/avi/" Size: 127 Blocks: 0 IO Block: 4096 Directory Device: 3a02h/14850d Inode: 32409 Links: 3 Access: (0700/drwx------) Uid: ( 502/ avi) Gid: ( 502/nasgroup) Access: Fri Mar 28 14:49:47 2003 Modify: Fri Mar 28 16:18:49 2003 Change: Fri Mar 28 16:18:49 2003 regds, Kishor __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com From owner-linux-xfs@oss.sgi.com Sat Mar 29 06:18:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 Mar 2003 06:18:22 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2TEIAq9009379 for ; Sat, 29 Mar 2003 06:18:11 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2TEI5uY005784 for ; Sat, 29 Mar 2003 06:18:05 -0800 Received: from zomba.sgi.com ([198.149.18.14]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA75752 for ; Sat, 29 Mar 2003 08:18:04 -0600 (CST) Received: from zomba.sgi.com (localhost.sgi.com [127.0.0.1]) by zomba.sgi.com (8.12.8/8.12.6/freebsd-sendmail_sa_mtv-1.0) with ESMTP id h2TEHshu015457 for ; Sat, 29 Mar 2003 08:18:06 -0600 (CST) X-Possible-Spam: the addition of this header was triggered by: localhost.localdomain.failing.dns.checks:helo Received: from localhost.localdomain (cf-vpn-sw-corp-64-44.corp.sgi.com [134.15.64.44]) by zomba.sgi.com (8.12.8/8.12.6/freebsd-nospam-3.1) with ESMTP id h2TEH1XR015408 for ; Sat, 29 Mar 2003 08:17:02 -0600 (CST) Received: from localhost.localdomain by localhost.localdomain (8.12.8/SGI-client-1.7) via ESMTP id h2TEGTEk001240; Sat, 29 Mar 2003 08:16:29 -0600 Received: (from lord@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h2TEGS3m001238; Sat, 29 Mar 2003 08:16:28 -0600 X-Authentication-Warning: localhost.localdomain: lord set sender to lord@sgi.com using -f Subject: Re: crash in linvfs_dentry_to_fh From: Steve Lord To: "HABBINGA,ERIK ""(HP-Loveland,ex1)" Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 29 Mar 2003 08:16:28 -0600 Message-Id: <1048947388.1166.23.camel@localhost.localdomain> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3427 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 4464 Lines: 111 On Fri, 2003-03-28 at 16:27, HABBINGA,ERIK (HP-Loveland,ex1) wrote: > I get the following crash in linvfs_dentry_to_fh after pushing a server very > hard with the SPEC SFS NFS test. It's a similar crash to the xfs_inactive > crash I mentioned earlier in the week. Not always repeatable, but we've > seen it a few times: > > ksymoops 2.4.5 on i686 2.4.18-14. Options used > -V (default) > -K (specified) > -L (specified) > -O (specified) > -m System.map (specified) > > Unable to handle kernel NULL pointer dereference at virtual address 00000008 > printing eip: > 801d9578 > *pde = 72da5001 > Oops: 0000 > CPU: 0 > EIP: 0010:[<801d9578>] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010202 > eax: 00000000 ebx: 0000000d ecx: f508f100 edx: 80336b20 > esi: f2121ec4 edi: f4cb64a4 ebp: f2121f04 esp: f2121eb4 > ds: 0018 es: 0018 ss: 0018 > Process nfsd (pid: 4074, stackpage=f2121000) > Stack: f4cb6494 f2093000 f4cb64a4 94d29220 fffffff4 94d29220 f508f0e0 > 8014236d > 8016b515 94d29220 f4cb64a4 f2121f04 00000001 94d295a0 94d295a0 > 0000000d > f4cb6404 80336b20 f2121f04 f508f100 0000000d 8016bf65 f4cb6494 > f2093000 > Call Trace: [<8014236d>] [<8016b515>] [<8016bf65>] [<802c2a24>] > [<80171e58>] > [<80168eb3>] [<802c2635>] [<80168c67>] [<80105694>] > > Code: 8b 50 08 56 8b 41 f4 50 8b 42 50 ff d0 8b 44 24 20 89 07 8b > > > >>EIP; 801d9578 <===== > > >>ecx; f508f100 > >>edx; 80336b20 > >>esi; f2121ec4 > >>edi; f4cb64a4 > >>ebp; f2121f04 > >>esp; f2121eb4 > > Trace; 8014236d > Trace; 8016b515 > Trace; 8016bf65 > Trace; 802c2a24 > Trace; 80171e58 > Trace; 80168eb3 > Trace; 802c2635 > Trace; 80168c67 > Trace; 80105694 > Code; 801d9578 > 00000000 <_EIP>: > Code; 801d9578 <===== > 0: 8b 50 08 mov 0x8(%eax),%edx <===== > Code; 801d957b > 3: 56 push %esi > Code; 801d957c > 4: 8b 41 f4 mov 0xfffffff4(%ecx),%eax > Code; 801d957f > 7: 50 push %eax > Code; 801d9580 > 8: 8b 42 50 mov 0x50(%edx),%eax > Code; 801d9583 > b: ff d0 call *%eax > Code; 801d9585 > d: 8b 44 24 20 mov 0x20(%esp,1),%eax > Code; 801d9589 > 11: 89 07 mov %eax,(%edi) > Code; 801d958b > 13: 8b 00 mov (%eax),%eax > > The code in question is derefencing the vp->v_bh pointer to get the > vp->v_bh.bh_first->bd_ops (also known as vp->v_fops) pointer in preparation > for getting the vop_fid2 function pointer. vp->v_bh is NULL, which causes > the crash. > > Dissassembly of linvfs_dentry_to_fh: > /src/kernel/linux/fs/xfs/linux/xfs_super.c:724 > > VOP_FID2(vp, (struct fid *)&fid, error); > 801d9571: 8b 41 f4 mov 0xfffffff4(%ecx),%eax > 801d9574: 8d 74 24 10 lea 0x10(%esp,1),%esi > 801d9578: 8b 50 08 mov 0x8(%eax),%edx > > We're running 2.4.20 with XFS CVS from March 17th. > > Erik Habbinga > Hewlett Packard > Well, looking at how NFS uses the call, and what we do inside it, I would say there is a chance the inode is being torn down on another cpu at the same time. Except there is reference on the dentry here and it does not call this function for negative dentry. This does indeed look like a partially initialized or torn down inode. The xfs_inactive crash looks a little similar. If you can instrument up linvfs_dentry_to_fh and dump the vnode contents when this happens it might show us something. So adding an explicit check for the pointer being null would be the thing to do. Not sure I can suggest a similar thing to try in the inactive path. Steve From owner-linux-xfs@oss.sgi.com Sat Mar 29 06:30:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 Mar 2003 06:30:52 -0800 (PST) Received: from gatekeeper.slim (slimnet.xs4all.nl [194.109.194.192]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2TEUlq9009896 for ; Sat, 29 Mar 2003 06:30:49 -0800 Received: from paragon.slim (paragon.slim [192.168.100.26]) by gatekeeper.slim (8.12.8/8.12.5) with ESMTP id h2TED4BM003074 for ; Sat, 29 Mar 2003 15:13:04 +0100 Subject: XFS compile problem with 2.5.66-XFS From: Jurgen Kramer To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1048948401.5629.2.camel@paragon.slim> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 (1.2.1-1) Date: 29 Mar 2003 15:33:22 +0100 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3428 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: gtm.kramer@inter.nl.net Precedence: bulk X-list: linux-xfs Content-Length: 1058 Lines: 26 Hi, The current 2.5.66 from CVS has some problems compiling. It gets stuck at compiling XFS: gcc -Wp,-MD,fs/xfs/linux/.xfs_super.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=pentium3 -Iinclude/asm-i386/mach-default -fomit-frame-pointer -nostdinc -iwithprefix include -Ifs/xfs -funsigned-char -DKBUILD_BASENAME=xfs_super -DKBUILD_MODNAME=xfs -c -o fs/xfs/linux/xfs_super.o fs/xfs/linux/xfs_super.c fs/xfs/linux/xfs_super.c: In function `xfs_showargs': fs/xfs/linux/xfs_super.c:277: too few arguments to function `bdevname' fs/xfs/linux/xfs_super.c:282: too few arguments to function `bdevname' fs/xfs/linux/xfs_super.c:276: warning: too few arguments passed to inline function, suppressing inlining fs/xfs/linux/xfs_super.c:281: warning: too few arguments passed to inline function, suppressing inlining make[2]: *** [fs/xfs/linux/xfs_super.o] Error 1 make[1]: *** [fs/xfs] Error 2 make: *** [fs] Error 2 -- Jurgen Kramer From owner-linux-xfs@oss.sgi.com Sat Mar 29 09:50:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 Mar 2003 09:50:49 -0800 (PST) Received: from checker.wi1.bucksch.org (dialin-145-254-227-247.arcor-ip.net [145.254.227.247]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2THobq9012226 for ; Sat, 29 Mar 2003 09:50:39 -0800 Received: from beonex.com (packer.wi1.bucksch.org [192.168.2.1]) by checker.wi1.bucksch.org (Postfix) with ESMTP id D1B871C976; Sat, 29 Mar 2003 18:46:10 +0100 (CET) Message-ID: <3E85DCD7.6040107@beonex.com> Date: Sat, 29 Mar 2003 18:50:15 +0100 From: Ben Bucksch Organization: Beonex User-Agent: Mozilla/5.0 (X11; U; Linux i686; en; rv:1.0.2) Gecko/20021218 Beonex/0.8.1-stable X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Copy with extended attributes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3429 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: ben.bucksch.news@beonex.com Precedence: bulk X-list: linux-xfs Content-Length: 1222 Lines: 21 I am using user-space extended attributes for my own bookkeeping of files, so they contain important information. I'd now like to copy those files, incl. ext attributes, but I don't see how that could be done easily. I guess I could use xfsdump/restore, but that seems like total overkill, because they are designed to backup a whole filesystem, not to copy a single file or directory (recursively). I am merely looking for a cp that also copies ext attributes, preferably the standard cp with a special flag or alternatively a XFS-specific workalike (xfs_cp or whatever). I didn't find anything in the FAQ, manpages or on the web. Does something like that exist? Any solution apart from a long and strange xfsdump/restore invokation? All I found were an appearantly custom implementation of cp and that of Solaris . BTW: Extended attributes could prove very useful (compare BeOS' usage of them), but that would need integration into standard tools like ls, cp, find, tar, up to Nautilus / Konqueror (I already filed an enhancement request for Nautilus about a year ago). Is there any plan to achieve that? From owner-linux-xfs@oss.sgi.com Sat Mar 29 09:53:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 Mar 2003 09:53:41 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2THrbq9012487 for ; Sat, 29 Mar 2003 09:53:38 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2TI5Tkq025038 for ; Sat, 29 Mar 2003 12:05:29 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA09648; Sat, 29 Mar 2003 11:53:31 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2THrUCJ6538707; Sat, 29 Mar 2003 11:53:31 -0600 (CST) Date: Sat, 29 Mar 2003 11:53:05 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jurgen Kramer cc: linux-xfs@oss.sgi.com Subject: Re: XFS compile problem with 2.5.66-XFS In-Reply-To: <1048948401.5629.2.camel@paragon.slim> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3430 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1200 Lines: 33 Try this patch? --- /usr/tmp/TmpDir.21969-0/linux/fs/xfs/linux/xfs_super.c_1.259 Sat Mar 29 11:52:33 2003 +++ linux/fs/xfs/linux/xfs_super.c Sat Mar 29 11:42:57 2003 @@ -257,6 +257,7 @@ }; struct proc_xfs_info *xfs_infop; struct xfs_mount *mp = XFS_BHVTOM(bhv); + char b[BDEVNAME_SIZE]; for (xfs_infop = xfs_info; xfs_infop->flag; xfs_infop++) { if (mp->m_flags & xfs_infop->flag) @@ -274,12 +275,12 @@ if (mp->m_ddev_targp->pbr_dev != mp->m_logdev_targp->pbr_dev) seq_printf(m, "," MNTOPT_LOGDEV "=%s", - bdevname(mp->m_logdev_targp->pbr_bdev)); + bdevname(mp->m_logdev_targp->pbr_bdev, b)); if (mp->m_rtdev_targp && mp->m_ddev_targp->pbr_dev != mp->m_rtdev_targp->pbr_dev) seq_printf(m, "," MNTOPT_RTDEV "=%s", - bdevname(mp->m_rtdev_targp->pbr_bdev)); + bdevname(mp->m_rtdev_targp->pbr_bdev, b)); if (mp->m_dalign > 0) seq_printf(m, "," MNTOPT_SUNIT "=%d", I'll check it in as well. -Eric From owner-linux-xfs@oss.sgi.com Sat Mar 29 09:55:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 Mar 2003 09:55:19 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2THtFq9013096 for ; Sat, 29 Mar 2003 09:55:16 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2TI77kq025045 for ; Sat, 29 Mar 2003 12:07:07 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA87934 for ; Sat, 29 Mar 2003 11:55:10 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2THtAwX35514208 for ; Sat, 29 Mar 2003 11:55:10 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h2THsje22041; Sat, 29 Mar 2003 11:54:45 -0600 Message-Id: <200303291754.h2THsje22041@stout.americas.sgi.com> Date: Sat, 29 Mar 2003 11:54:45 -0600 Subject: TAKE - Fix build X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3431 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 338 Lines: 15 Fix build - bdevname Date: Sat Mar 29 09:54:23 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.5.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:143034a linux/fs/xfs/linux/xfs_super.c - 1.260 - fix call to bdevname, now takes 2 args From owner-linux-xfs@oss.sgi.com Sat Mar 29 09:58:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 Mar 2003 09:58:14 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2THw9q9013557 for ; Sat, 29 Mar 2003 09:58:11 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18zIC6-0007wZ-00; Sat, 29 Mar 2003 15:24:30 +0000 Date: Sat, 29 Mar 2003 15:24:30 +0000 From: Christoph Hellwig To: Jurgen Kramer Cc: linux-xfs@oss.sgi.com Subject: Re: XFS compile problem with 2.5.66-XFS Message-ID: <20030329152430.A30520@infradead.org> References: <1048948401.5629.2.camel@paragon.slim> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1048948401.5629.2.camel@paragon.slim>; from gtm.kramer@inter.nl.net on Sat, Mar 29, 2003 at 03:33:22PM +0100 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3432 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: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 1207 Lines: 37 On Sat, Mar 29, 2003 at 03:33:22PM +0100, Jurgen Kramer wrote: > Hi, > > The current 2.5.66 from CVS has some problems compiling. It gets stuck > at compiling XFS: Please try the attached patch. (I'm still wondering why I didn't see it when testing the merge, I guess I was bitten by the broken depencies again) --- linux/fs/xfs/linux/xfs_super.c~ 2003-03-17 02:19:15.000000000 -0500 +++ linux/fs/xfs/linux/xfs_super.c 2003-03-27 09:27:51.000000000 -0500 @@ -257,6 +257,7 @@ }; struct proc_xfs_info *xfs_infop; struct xfs_mount *mp = XFS_BHVTOM(bhv); + char b[BDEVNAME_SIZE]; for (xfs_infop = xfs_info; xfs_infop->flag; xfs_infop++) { if (mp->m_flags & xfs_infop->flag) @@ -274,12 +275,12 @@ if (mp->m_ddev_targp->pbr_dev != mp->m_logdev_targp->pbr_dev) seq_printf(m, "," MNTOPT_LOGDEV "=%s", - bdevname(mp->m_logdev_targp->pbr_bdev)); + bdevname(mp->m_logdev_targp->pbr_bdev, b)); if (mp->m_rtdev_targp && mp->m_ddev_targp->pbr_dev != mp->m_rtdev_targp->pbr_dev) seq_printf(m, "," MNTOPT_RTDEV "=%s", - bdevname(mp->m_rtdev_targp->pbr_bdev)); + bdevname(mp->m_rtdev_targp->pbr_bdev, b)); if (mp->m_dalign > 0) seq_printf(m, "," MNTOPT_SUNIT "=%d", From owner-linux-xfs@oss.sgi.com Sat Mar 29 10:09:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 Mar 2003 10:09:29 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2TI8kq9014094 for ; Sat, 29 Mar 2003 10:09:27 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2TIKckq025215 for ; Sat, 29 Mar 2003 12:20:38 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA00777; Sat, 29 Mar 2003 12:08:41 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2TI8fCJ6544286; Sat, 29 Mar 2003 12:08:41 -0600 (CST) Date: Sat, 29 Mar 2003 12:08:16 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Ben Bucksch cc: linux-xfs@oss.sgi.com Subject: Re: Copy with extended attributes In-Reply-To: <3E85DCD7.6040107@beonex.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3433 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1591 Lines: 37 There are versions of fileutils which include acl/attr support - see http://acl.bestbits.at/ Some distros include this, I know that RH 8.0's fileutils includes acl support. "star" is an archiving tool with acl support - rh 8.0 has this as well. Not sure about nautilus. -Eric On Sat, 29 Mar 2003, Ben Bucksch wrote: > I am using user-space extended attributes for my own bookkeeping of > files, so they contain important information. I'd now like to copy those > files, incl. ext attributes, but I don't see how that could be done > easily. I guess I could use xfsdump/restore, but that seems like total > overkill, because they are designed to backup a whole filesystem, not to > copy a single file or directory (recursively). I am merely looking for a > cp that also copies ext attributes, preferably the standard cp with a > special flag or alternatively a XFS-specific workalike (xfs_cp or > whatever). I didn't find anything in the FAQ, manpages or on the web. > Does something like that exist? Any solution apart from a long and > strange xfsdump/restore invokation? > > All I found were an appearantly custom implementation of cp > and that of Solaris > . > > BTW: Extended attributes could prove very useful (compare BeOS' usage of > them), but that would need integration into standard tools like ls, cp, > find, tar, up to Nautilus / Konqueror (I already filed an enhancement > request for Nautilus about a year ago). Is there any plan to achieve that? > > From owner-linux-xfs@oss.sgi.com Sat Mar 29 14:53:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 Mar 2003 14:53:19 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2TMrBq9018895 for ; Sat, 29 Mar 2003 14:53:11 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2TMr5nH021156 for ; Sat, 29 Mar 2003 14:53:05 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA92722 for ; Sat, 29 Mar 2003 16:53:04 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2TMr4wX36106634 for ; Sat, 29 Mar 2003 16:53:04 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h2TMqbt30374; Sat, 29 Mar 2003 16:52:37 -0600 Message-Id: <200303292252.h2TMqbt30374@stout.americas.sgi.com> Date: Sat, 29 Mar 2003 16:52:37 -0600 Subject: TAKE - Correct display of imaxpct in mkfs output X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3435 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 383 Lines: 16 Just a minor annoyance... Correct display of imaxpct in mkfs output Date: Sat Mar 29 14:52:37 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:143035a cmd/xfsprogs/doc/CHANGES - 1.96 cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.41 From owner-linux-xfs@oss.sgi.com Sat Mar 29 18:15:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 Mar 2003 18:15:12 -0800 (PST) Received: from checker.wi1.bucksch.org (pD950D284.dip.t-dialin.net [217.80.210.132]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2U2ELq9021452 for ; Sat, 29 Mar 2003 18:15:03 -0800 Received: from beonex.com (packer.wi1.bucksch.org [192.168.2.1]) by checker.wi1.bucksch.org (Postfix) with ESMTP id 4CDFD1C81B; Sun, 30 Mar 2003 04:09:51 +0200 (CEST) Message-ID: <3E8652E5.5090307@beonex.com> Date: Sun, 30 Mar 2003 04:13:57 +0200 From: Ben Bucksch Organization: Beonex User-Agent: Mozilla/5.0 (X11; U; Linux i686; en; rv:1.0.2) Gecko/20021218 Beonex/0.8.1-stable X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Copy with extended attributes References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3436 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: ben.bucksch.news@beonex.com Precedence: bulk X-list: linux-xfs Content-Length: 902 Lines: 29 Thanks, Eric, for the fast answer. Eric Sandeen wrote: >There are versions of fileutils which include acl/attr support - >see http://acl.bestbits.at/ > I checked that out, but the description of star explicitly states that it doesn't support EAs, only ACLs, and quickly looking over the fileutils diff suggests the same for that package (cp, mv etc.). I merged the patch with the current Debian sources and built and ran cp, but the attributes were not copied. Did I overlook/misunderstand something? >Not sure about nautilus. > For now, I used getfattr -dR; cp -ax; setfattr --restore. Could you please add this question (and possible answers ;-) ) to the FAQ, because I'd think that everybody seriously using (or wanting to use) EA would stumble over this question? Thanks, Ben From owner-linux-xfs@oss.sgi.com Sat Mar 29 19:15:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 Mar 2003 19:15:23 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2U3Erq9022201 for ; Sat, 29 Mar 2003 19:15:13 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2U3Qlkq001831 for ; Sat, 29 Mar 2003 21:26:47 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA20066; Sat, 29 Mar 2003 21:14:48 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2U3ElCJ6581102; Sat, 29 Mar 2003 21:14:48 -0600 (CST) Date: Sat, 29 Mar 2003 21:14:19 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Ben Bucksch cc: linux-xfs@oss.sgi.com Subject: Re: Copy with extended attributes In-Reply-To: <3E8652E5.5090307@beonex.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3437 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 125 Lines: 8 On Sun, 30 Mar 2003, Ben Bucksch wrote: > Did I overlook/misunderstand something? Hm, no, I guess that was me. :) -Eric From owner-linux-xfs@oss.sgi.com Sun Mar 30 00:57:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 Mar 2003 00:57:59 -0800 (PST) Received: from K-7.stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2U8v7q9024182 for ; Sun, 30 Mar 2003 00:57:49 -0800 Received: from stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id h2U8v48Y005170 for ; Sun, 30 Mar 2003 10:57:05 +0200 Message-ID: <3E86B160.2080004@stesmi.com> Date: Sun, 30 Mar 2003 10:57:04 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [ANNOUNCE] RedHat 8.0 XFS DVD v0.1 Released Content-Type: text/plain; charset=ISO-8859-15; format=flowed X-RAVMilter-Version: 8.4.2(snapshot 20021217) (K-7.stesmi.com) X-MIME-Autoconverted: from 8bit to quoted-printable by K-7.stesmi.com id h2U8v48Y005170 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h2U8voq9024183 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3438 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: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 2855 Lines: 67 Hi. A new version of the RedHat 8.0 XFS DVD has been released. It can be fetched from ftp://ftp.uninett.no/pub/linux/RH-XFS-DVD/ What's on this DVD: * RedHat 8.0 "Psyche" CDs 1-5, including the SRPMS. * All updates that were released up to and including 2003-03-27 at 09:00 GMT. They are installed automatically when the system is installed. The DVD does not contain the old RPMS. * The installer and RPMS from the XFS 1.2 release from SGI. Version history: 0.0.1 2002-12-xx Initial version. Not released. Worked fine. I could even verify the DVD with the MD5 function of the installer. Had the bug that made it ask for the XFS CD after verifying MD5. 0.0.2 2002-12-xx Updated version. Contained a few extra RPMS in the contrib directory. Minor tweaks. Not released. Had a fix for the problem above. 0.0.3 2002-12-xx Same as 0.0.2 but this time I didn't forget to implant the MD5 sum into the image (stupid me). Not released. 0.0.4 2002-12-12 Added latest updates. Verified it works from a DVD-RW. Not released. 0.0.5 2002-12-13 Added latest updates: httpd and mod_ssl. Finished my script that I use to build the DVD with. Not released. 0.0.6 2002-12-18 The ethernet and pcmcia on the laptop died and I had the whole build system on there. Took some time to get the relevant info off of it and start building again. SGI also released 1.2pre4 of the kernel so I updated all files to that. Added updated net-snmp. Not released. 0.0.7 2002-12-20 Found out that the kernel from 1.2pre4 is wrong so I waited for the respin to come out and released it when it had. No other changes. First public release. 0.0.8 2003-01-10 Updated a few RPMs. No other changes. Not really released. 0.0.9 2003-01-15 Updated some more RPMs. Switched to 1.2pre5 from SGI. First public release with new mirror. 0.0.10 2003-01-26 Updated lots of RPMs including MySQL, PostgreSQL, the dhcp server and client and CVS. 0.1 2003-03-27 Major update to XFS 1.2. Updated numerous packages. Seeing the older releases as stable I upped the minor a knotch. Includes some substantial updates like a new glibc (2.3.2). Thanx must go to: (In no particular order) Nicolai Langfeldt Ragnar Kjørstad George Georgalis Ajay Ramaswamy Russel Cattelan Eric Sandeen Nathan Straz and the rest of the XFS team! This DVD wouldn't have existed without you! * The copyright of any program on this DVD are owned by their respective copyright holder. // Stefan From owner-linux-xfs@oss.sgi.com Sun Mar 30 07:25:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 Mar 2003 07:25:15 -0800 (PST) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2UFOOq9003987 for ; Sun, 30 Mar 2003 07:25:07 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id A6972EB4A02 for ; Sun, 30 Mar 2003 23:24:16 +0800 (PHT) Received: from lawin.leathercollection.ph (lawin.leathercollection.ph [192.168.0.2]) by gusi.leathercollection.ph (Postfix) with ESMTP id 3482BEB4A01 for ; Sun, 30 Mar 2003 23:24:13 +0800 (PHT) Received: by lawin.leathercollection.ph (Postfix, from userid 1000) id 551CC1A4020; Sun, 30 Mar 2003 23:24:12 +0800 (PHT) Date: Sun, 30 Mar 2003 23:24:11 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List Subject: linux-xfs Archives as a UNIX mbox file(s) Message-ID: <20030330152411.GK15244@leathercollection.ph> Mail-Followup-To: Linux-XFS Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3441 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: jijo@free.net.ph Precedence: bulk X-list: linux-xfs Content-Length: 1214 Lines: 31 Hi everyone, I don't know where else to ask, so I hope this will be pardoned here. I am interested in adding full archives of the linux-xfs mailing list to the searchable archives of free.net.ph[1]. I know there are already searchable archives available on marc.theaimsgroup.com, but I was hoping to put up searchable archives on free.net.ph anyway. To start things off with the old mail, I will just need a copy of the old mail as an mbox (or multiple mboxes). Newer mail will come through a subscribed address, with absolutely nothing special needed from oss.sgi.com. At the present I don't know where copies of the old mail can be had in their raw form (versus the HTML that MHonarc created). Would it be possible to ask for a copy of this from anyone on the XFS team from SGI? Thank you very much and I hope I am not taking up too much of anyone's time. If this is an impossible request, please just ignore it. Thank you again. :) --> Jijo [1] http://marc.free.net.ph -- Federico Sevilla III : http://jijo.free.net.ph : When we speak of free Network Administrator : The Leather Collection, Inc. : software we refer to GnuPG Key ID : 0x93B746BE : freedom, not price. From owner-linux-xfs@oss.sgi.com Sun Mar 30 15:00:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 Mar 2003 15:01:06 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2UN09q9007778 for ; Sun, 30 Mar 2003 15:00:53 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2UN03uY030979 for ; Sun, 30 Mar 2003 15:00:03 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA21125; Mon, 31 Mar 2003 08:58:47 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id IAA14136; Mon, 31 Mar 2003 08:58:46 +1000 (AEST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2UNtY3h001061; Mon, 31 Mar 2003 09:55:34 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2UNtXxH001059; Mon, 31 Mar 2003 09:55:33 +1000 Date: Mon, 31 Mar 2003 09:55:33 +1000 From: Nathan Scott To: kishor bhagwat Cc: linux-xfs@oss.sgi.com Subject: Re: LVM + XFS + Quotas Message-ID: <20030330235533.GC861@frodo> References: <20030328223823.GB7894@f00f.org> <20030329030536.47438.qmail@web13606.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030329030536.47438.qmail@web13606.mail.yahoo.com> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3442 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 864 Lines: 33 On Fri, Mar 28, 2003 at 07:05:36PM -0800, kishor bhagwat wrote: > > --- Chris Wedgwood wrote: > > On Fri, Mar 28, 2003 at 03:27:51AM -0800, kishor bhagwat > > wrote: > > > > > I'm using RH 8.0 with kernel upgraded to kernel.org's > > 2.4.19, and > > > XFS 1.2 patches. > > > > > I'm able to create quotas etc..but there is an issue > > with the actual > > > usable space. > > > > what does 'quota' report? > > quota reports..... > Filesystem /dev/HOME/DataVol > blocks quota limit grace files quota limit grace > 32 64 80 12 0 0 > This is likely the problem. Your limits are extremely low - that's just 80K above, right? (less than an HD floppy disk ;) Refer to the end of xfsprogs/doc/README.quota (CAVEATS section) for some more information on this as well. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Mar 30 15:10:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 Mar 2003 15:10:56 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2UNA7q9008291 for ; Sun, 30 Mar 2003 15:10:47 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2UNA0uY031465 for ; Sun, 30 Mar 2003 15:10:01 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA21231; Mon, 31 Mar 2003 09:08:44 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id JAA67153; Mon, 31 Mar 2003 09:08:43 +1000 (AEST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) with ESMTP id h2V05U3h001101; Mon, 31 Mar 2003 10:05:30 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.7/8.12.7/Debian-2) id h2V05TCV001099; Mon, 31 Mar 2003 10:05:29 +1000 Date: Mon, 31 Mar 2003 10:05:29 +1000 From: Nathan Scott To: Ben Bucksch , agruen@suse.de Cc: linux-xfs@oss.sgi.com Subject: Re: Copy with extended attributes Message-ID: <20030331000529.GD861@frodo> References: <3E8652E5.5090307@beonex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E8652E5.5090307@beonex.com> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3443 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: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1021 Lines: 30 On Sun, Mar 30, 2003 at 04:13:57AM +0200, Ben Bucksch wrote: > Thanks, Eric, for the fast answer. > > Eric Sandeen wrote: > > >There are versions of fileutils which include acl/attr support - > >see http://acl.bestbits.at/ > > > I checked that out, but the description of star > explicitly states that it > doesn't support EAs, only ACLs, and quickly looking over the fileutils > diff suggests the same for that package (cp, mv etc.). I merged the > patch with the current Debian sources and built and ran cp, but the > attributes were not copied. > There is a project to implement what you're asking for here at Suse, I believe. Andreas has recently implemented some libattr routines for preserving all of the extended attributes on operations line cp, etc. I'm not sure what the current state of this project is, though. The missing piece afaict is the changes to the commands to make use of those new attr_copy_file/attr_copy_fd routines. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Mar 30 17:04:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 Mar 2003 17:05:10 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2V14bq9009769 for ; Sun, 30 Mar 2003 17:04:38 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 326BF14A67; Mon, 31 Mar 2003 02:35:22 +0200 (MEST) From: Andreas Gruenbacher Organization: SuSE Linux AG To: Nathan Scott , Ben Bucksch Subject: Re: Copy with extended attributes Date: Mon, 31 Mar 2003 02:36:05 +0200 User-Agent: KMail/1.5 Cc: linux-xfs@oss.sgi.com, acl-devel@bestbits.at References: <3E8652E5.5090307@beonex.com> <20030331000529.GD861@frodo> In-Reply-To: <20030331000529.GD861@frodo> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303310236.05870.agruen@suse.de> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3444 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: agruen@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 1439 Lines: 39 Hello, On Monday 31 March 2003 02:05, Nathan Scott wrote: > On Sun, Mar 30, 2003 at 04:13:57AM +0200, Ben Bucksch wrote: > > Thanks, Eric, for the fast answer. > > > > Eric Sandeen wrote: > > >There are versions of fileutils which include acl/attr support - > > >see http://acl.bestbits.at/ > > > > I checked that out, but the description of star > > explicitly states that it > > doesn't support EAs, only ACLs, and quickly looking over the fileutils > > diff suggests the same for that package (cp, mv etc.). I merged the > > patch with the current Debian sources and built and ran cp, but the > > attributes were not copied. The web site is out of date. I have copied the most up-to-date coreutils and star patches of for now. I will update the web site as soon as possible. Right now I *really* have more important stuff to do, sorry. > There is a project to implement what you're asking for here at Suse, > I believe. Andreas has recently implemented some libattr routines > for preserving all of the extended attributes on operations line cp, > etc. Check out . > I'm not sure what the current state of this project is, though. > The missing piece afaict is the changes to the commands to make > use of those new attr_copy_file/attr_copy_fd routines. It's in the coreutils patch. Cheers, Andreas. From owner-linux-xfs@oss.sgi.com Sun Mar 30 19:13:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 Mar 2003 19:13:50 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2V3D0q9013033 for ; Sun, 30 Mar 2003 19:13:41 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2V3CsnH008588 for ; Sun, 30 Mar 2003 19:12:55 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2V3Bb7L4407580 for ; Mon, 31 Mar 2003 13:11:37 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2V3Bbgu4407477 for linux-xfs@oss.sgi.com; Mon, 31 Mar 2003 13:11:37 +1000 (EST) Date: Mon, 31 Mar 2003 13:11:37 +1000 (EST) From: Nathan Scott Message-Id: <200303310311.h2V3Bbgu4407477@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3445 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2948 Lines: 93 Bunch of portability related changes to xfsprogs. Includes some code to allow db/mkfs/repair to be used on Mac's (maybe useful for dual boot, but Russell was interested in getting this too), & some code to build on IRIX (mainly so that I can run purify on xfs_repair now). Also fixed a configure script botch which meant we were always trying to link with libreadline, not only when asked to do so. Several configure.in changes here, so be sure to "make distclean" first. cheers. Date: Sun Mar 30 18:57:10 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:143050a cmd/xfsprogs/db/write.c - 1.9 cmd/xfsprogs/db/fprint.c - 1.7 cmd/xfsprogs/db/check.c - 1.14 cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.42 - Fix compiler warnings from newer versions of gcc. cmd/xfsprogs/configure.in - 1.21 - Fix readline test, fix gettext tests, allow alternate install user/root. cmd/xfsprogs/VERSION - 1.71 cmd/xfsprogs/doc/CHANGES - 1.97 cmd/xfsprogs/debian/changelog - 1.64 - bump version for portability changes. cmd/xfsprogs/doc/INSTALL - 1.3 - document how to build on some other platforms. cmd/xfsprogs/include/handle.h - 1.9 cmd/xfsprogs/man/man3/handle.3 - 1.3 cmd/xfsprogs/libhandle/handle.c - 1.12 - Remove unused and static routines. cmd/xfsprogs/mkfs/Makefile - 1.14 - Platform independence related changes. cmd/xfsprogs/build/rpm/Makefile - 1.12 - remove unused reference to PKG_BUILDER, hasn't been used for awhile. cmd/xfsprogs/include/builddefs.in - 1.28 cmd/xfsprogs/include/buildmacros - 1.9 - Allow alternate install user/root. add PLDFLAGS macro. cmd/xfsprogs/include/xfs_mount.h - 1.34 cmd/xfsprogs/include/xfs_inode.h - 1.30 - Sync with minor changes to kernel code. cmd/xfsprogs/libxfs/Makefile - 1.14 - Platform independence related changes. cmd/xfsprogs/libxfs/irix.c - 1.1 - Provide implementation for libxfs platform-dependent code on IRIX. cmd/xfsprogs/include/xfs_bmap_btree.h - 1.10 - Fix compile warnings on big endian platforms. cmd/xfsprogs/imap/xfs_imap.c - 1.8 cmd/xfsprogs/rtcp/xfs_rtcp.c - 1.11 cmd/xfsprogs/freeze/xfs_freeze.c - 1.8 cmd/xfsprogs/growfs/xfs_growfs.c - 1.17 cmd/xfsprogs/include/xfs_fs.h - 1.25 cmd/xfsprogs/include/libxlog.h - 1.7 cmd/xfsprogs/include/platform_defs.h.in - 1.18 cmd/xfsprogs/libxfs/xfs.h - 1.32 cmd/xfsprogs/libxfs/init.c - 1.26 cmd/xfsprogs/mkfile/xfs_mkfile.c - 1.13 cmd/xfsprogs/libxfs/init.h - 1.2 cmd/xfsprogs/libxfs/linux.c - 1.3 cmd/xfsprogs/io/pread.c - 1.2 cmd/xfsprogs/io/resblks.c - 1.2 cmd/xfsprogs/io/prealloc.c - 1.2 cmd/xfsprogs/io/open.c - 1.2 cmd/xfsprogs/io/bmap.c - 1.2 - Abstract platform dependent code out into headers. cmd/xfsprogs/libxfs/darwin.c - 1.1 - Provide implementation for libxfs platform-dependent code on Darwin. cmd/xfsprogs/po/Makefile - 1.4 cmd/xfsprogs/po/xfsprogs.pot - 1.4 - Update messages. From owner-linux-xfs@oss.sgi.com Sun Mar 30 19:19:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 Mar 2003 19:19:10 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2V3J7q9013373 for ; Sun, 30 Mar 2003 19:19:08 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2V3Uxkq030929 for ; Sun, 30 Mar 2003 21:31:02 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2V3He7L4370111 for ; Mon, 31 Mar 2003 13:17:40 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2V3He9D4403449 for linux-xfs@oss.sgi.com; Mon, 31 Mar 2003 13:17:40 +1000 (EST) Date: Mon, 31 Mar 2003 13:17:40 +1000 (EST) From: Nathan Scott Message-Id: <200303310317.h2V3He9D4403449@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix pagebuf leak X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3446 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 354 Lines: 14 Fix a pagebuf leak with the pagebufs used to coordinate IO completion for unwritten extent writes. Date: Sun Mar 30 19:17:17 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:143052a linux/fs/xfs/linux/xfs_aops.c - 1.30 From owner-linux-xfs@oss.sgi.com Sun Mar 30 23:00:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 Mar 2003 23:00:54 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2V70Pq9019234 for ; Sun, 30 Mar 2003 23:00:47 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2V70JnH020249 for ; Sun, 30 Mar 2003 23:00:20 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h2V6x17L4485341 for ; Mon, 31 Mar 2003 16:59:01 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h2V6x1hX4075900 for linux-xfs@oss.sgi.com; Mon, 31 Mar 2003 16:59:01 +1000 (EST) Date: Mon, 31 Mar 2003 16:59:01 +1000 (EST) From: Nathan Scott Message-Id: <200303310659.h2V6x1hX4075900@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - userspace build sync-ups X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3447 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: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1765 Lines: 68 Fix up some minor namespace pollution problems. Date: Sun Mar 30 19:22:06 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:143053a linux/fs/xfs/xfs_bmap_btree.h - 1.57 linux/fs/xfs/xfs_fs.h - 1.9 Add a few more files to the bunch that we keep in sync between packages. Date: Sun Mar 30 22:09:51 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:143060a cmd/xfstests/tools/srcdiff - 1.23 Minor userspace build changes, keeping packages in sync. Date: Sun Mar 30 22:57:56 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:143062a cmd/acl/configure.in - 1.25 cmd/acl/build/rpm/Makefile - 1.13 cmd/acl/build/tar/Makefile - 1.8 cmd/acl/include/builddefs.in - 1.24 cmd/attr/configure.in - 1.14 cmd/attr/build/rpm/Makefile - 1.12 cmd/attr/build/tar/Makefile - 1.7 cmd/attr/include/builddefs.in - 1.20 cmd/xfsprogs/build/Makefile - 1.9 cmd/xfsprogs/build/tar/Makefile - 1.7 cmd/xfsdump/configure.in - 1.31 cmd/xfsdump/build/Makefile - 1.8 cmd/xfsdump/build/rpm/Makefile - 1.11 cmd/xfsdump/build/tar/Makefile - 1.6 cmd/xfsdump/include/builddefs.in - 1.21 cmd/dmapi/configure.in - 1.18 cmd/dmapi/build/Makefile - 1.8 cmd/dmapi/build/rpm/Makefile - 1.11 cmd/dmapi/build/tar/Makefile - 1.6 cmd/dmapi/include/builddefs.in - 1.20 cmd/dmapi/include/buildmacros - 1.8 cmd/acl/include/buildmacros - 1.9 cmd/attr/include/buildmacros - 1.8 cmd/xfsdump/include/buildmacros - 1.8 From owner-linux-xfs@oss.sgi.com Mon Mar 31 02:23:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Mar 2003 02:23:57 -0800 (PST) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2VAN4q9007704 for ; Mon, 31 Mar 2003 02:23:46 -0800 Received: from rss1.rz.uni-regensburg.de (rss1.rz.uni-regensburg.de [132.199.1.200]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with SMTP id h2VAN2jh032673 for ; Mon, 31 Mar 2003 12:23:03 +0200 Received: (qmail 7814 invoked from network); 31 Mar 2003 12:23:02 +0200 Received: from rx3227.cip.uni-regensburg.de (132.199.221.32) by rss1.rz.uni-regensburg.de with SMTP; 31 Mar 2003 12:23:02 +0200 Subject: xfs_force_shutdown(sd(8,17),0x2) called from line 975 ... From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1049106182.479.24.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 31 Mar 2003 12:23:03 +0200 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3448 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: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 2797 Lines: 75 Hi, we had recently a hard disk failure in a Hardware Raid5 setup. I thought this should give us no worries, but.... ( we had some more disk failures over the last year in similar setups with no problems at all). Kernel is 2.4.20 CVS (SGI XFS snapshot 2.4.20-2003-01-14_00:43_UTC, with quota and ACL's) DELL PE 2550, 2 GB of RAM. In the logs: SCSI disk error : host 1 channel 0 id 1 lun 0 return code = 8000002 Current sd08:11: sense key Hardware Error I/O error: dev 08:11, sector 8389384 I/O error in filesystem ("sd(8,17)") meta-data dev 0x811 block 0x800308 ("xfs_trans_read_buf") error 5 buf count 4096 SCSI disk error : host 1 channel 0 id 1 lun 0 return code = 8000002 Current sd08:11: sense key Hardware Error I/O error: dev 08:11, sector 8389384 I/O error in filesystem ("sd(8,17)") meta-data dev 0x811 block 0x800308 ("xfs_trans_read_buf") error 5 buf count 4096 SCSI disk error : host 1 channel 0 id 1 lun 0 return code = 8000002 Current sd08:11: sense key Hardware Error I/O error: dev 08:11, sector 120 I/O error in filesystem ("sd(8,17)") meta-data dev 0x811 block 0x78 ("xfs_trans_read_buf") error 5 buf count 4096 SCSI disk error : host 1 channel 0 id 1 lun 0 return code = 8000002 Current sd08:11: sense key Hardware Error I/O error: dev 08:11, sector 2175531000 I/O error in filesystem ("sd(8,17)") meta-data dev 0x811 block 0x81abf7f8 ("xfs_trans_read_buf") error 5 buf count 4096 xfs_force_shutdown(sd(8,17),0x1) called from line 408 of file xfs_trans_buf.c. Return address = 0xc01e4f23 SCSI disk error : host 1 channel 0 id 1 lun 0 return code = 8000002 Current sd08:11: sense key Hardware Error I/O error: dev 08:11, sector 1761820473 I/O error in filesystem ("sd(8,17)") meta-data dev 0x811 block 0x69033f39 ("xlog_iodone") error 5 buf count 1536 xfs_force_shutdown(sd(8,17),0x2) called from line 975 of file xfs_log.c. Return address = 0xc01d7e94 Filesystem "sd(8,17)": Log I/O Error Detected. Shutting down filesystem: sd(8,17) Please umount the filesystem, and rectify the problem(s) The FS is about 1.6 TB, shared via NFS to about 50 Clients. I tried to run xfs_repair -n, but without success: hostxxx:~# xfs_repair -n /dev/sdb1 Phase 1 - find and verify superblock... superblock read failed, offset 0, size 524288, ag 4294967295, rval 0 fatal error -- Input/output error In the logs: Current sd08:11: sense key Hardware Error I/O error: dev 08:11, sector 149 SCSI disk error : host 1 channel 0 id 1 lun 0 return code = 8000002 Current sd08:11: sense key Hardware Error I/O error: dev 08:11, sector 150 SCSI disk error : host 1 channel 0 id 1 lun 0 return code = 8000002 Current sd08:11: sense key Hardware Error I/O error: dev 08:11, sector 151 and so on (up to sector 255) is there any chance to repair this? thanks Christian From owner-linux-xfs@oss.sgi.com Mon Mar 31 02:50:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Mar 2003 02:50:50 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2VAo0q9009700 for ; Mon, 31 Mar 2003 02:50:41 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h2VAnu4u066376; Mon, 31 Mar 2003 12:49:57 +0200 (CEST) Message-Id: <4.3.2.7.2.20030331124423.03262330@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 31 Mar 2003 12:49:43 +0200 To: christian.guggenberger@physik.uni-regensburg.de, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: xfs_force_shutdown(sd(8,17),0x2) called from line 975 ... In-Reply-To: <1049106182.479.24.camel@bonnie79> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3449 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: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1012 Lines: 29 At 12:23 31-3-2003 +0200, Christian Guggenberger wrote: >Hi, > >we had recently a hard disk failure in a Hardware Raid5 setup. >I thought this should give us no worries, but.... ( we had some more >disk failures over the last year in similar setups with no problems at >all). If the hardware raid presents itself as sdb1 and the hardware raid is actually working you should be able to check your filesystem using xfs_repair. If the raid5 setup has 2 disk failures at the same time and this was the 2nd disk going from the set then you are fried. Hardware raid should _NEVER_ throw an IO error if the raid container is still alive. If it does, either the raid controller is broken or in this case there might have been a 2nd disk gone and thus it restults in a IO error. The hardware raid controller presents itself as a virtual device and the sectors you are referring to are not actual disk sectors. I am afraid we cannot help you. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Mar 31 03:22:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Mar 2003 03:23:01 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2VBMpq9010412 for ; Mon, 31 Mar 2003 03:22:51 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2VBMpGr010410 for linux-xfs@oss.sgi.com; Mon, 31 Mar 2003 03:22:51 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2VBMnqB010397 for ; Mon, 31 Mar 2003 03:22:49 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2VAPjeZ007884; Mon, 31 Mar 2003 02:25:45 -0800 Date: Mon, 31 Mar 2003 02:25:45 -0800 Message-Id: <200303311025.h2VAPjeZ007884@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3450 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 390 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From atu@dmeti.dp.ua 2003-03-31 02:25 ------- Created an attachment (id=76) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=76&action=view) trace of new weekly snapshot (2003-03-30) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Mar 31 04:10:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Mar 2003 04:10:47 -0800 (PST) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2VC9Vq9012311 for ; Mon, 31 Mar 2003 04:10:08 -0800 Received: from rss1.rz.uni-regensburg.de (rss1.rz.uni-regensburg.de [132.199.1.200]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with SMTP id h2VC9Ujh009783 for ; Mon, 31 Mar 2003 14:09:30 +0200 Received: (qmail 11483 invoked from network); 31 Mar 2003 14:09:30 +0200 Received: from pc9391.physik.uni-regensburg.de (HELO pc9391) (guc28561@132.199.98.219) by rss1.rz.uni-regensburg.de with SMTP; 31 Mar 2003 14:09:30 +0200 Date: Mon, 31 Mar 2003 14:09:30 +0200 From: Christian Guggenberger To: Seth Mos Cc: christian.guggenberger@physik.uni-regensburg.de, linux-xfs@oss.sgi.com Subject: sorry - was:xfs_force_shutdown(sd(8,17),0x2) called from line 975 ... Message-ID: <20030331140930.A26238@pc9391.uni-regensburg.de> References: <1049106182.479.24.camel@bonnie79> <4.3.2.7.2.20030331124423.03262330@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <4.3.2.7.2.20030331124423.03262330@pop.xs4all.nl>; from knuffie@xs4all.nl on Mon, Mar 31, 2003 at 12:49:43 +0200 X-Mailer: Balsa 1.2.4 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3451 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: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 635 Lines: 18 On 31.03.2003 12:49 Seth Mos wrote: > At 12:23 31-3-2003 +0200, Christian Guggenberger wrote: >> Hi, >> >> we had recently a hard disk failure in a Hardware Raid5 setup. >> I thought this should give us no worries, but.... ( we had some more >> disk failures over the last year in similar setups with no problems at >> all). > Hi all. sorry for the noise!! I did not have a remote connection to the hardware raid over the weekend, only to the machine which exports the filesystem... Yes, we had a second disk failure, while the rebuild was running... But that's not that tragic, because there's backup of the data. Christian From owner-linux-xfs@oss.sgi.com Mon Mar 31 05:52:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Mar 2003 05:52:17 -0800 (PST) Received: from hbcse.tifr.res.in (hbcse.tifr.res.in [158.144.44.129]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2VDq0q9015620 for ; Mon, 31 Mar 2003 05:52:05 -0800 Received: from linto (helo=localhost) by hbcse.tifr.res.in with local-esmtp (Exim 3.35 #1 (Debian)) id 18zzdp-0006co-00 for ; Mon, 31 Mar 2003 19:18:01 +0530 Date: Mon, 31 Mar 2003 19:18:00 +0530 (IST) From: "'Linto Joseph Mathew" To: linux-xfs@oss.sgi.com Subject: How do i use extrattrib functions in C . Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3453 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: linto@hbcse.tifr.res.in Precedence: bulk X-list: linux-xfs Content-Length: 206 Lines: 11 There are system calls for set/getting extra attributes to a file. How do i invoke it in a c program? Is there any special functions? Please help me . Send me a sample program if u can. Regards, Linto. From owner-linux-xfs@oss.sgi.com Mon Mar 31 09:04:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Mar 2003 09:04:24 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2VH40q9017976 for ; Mon, 31 Mar 2003 09:04:21 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2VH3suY000738 for ; Mon, 31 Mar 2003 09:03:54 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA07218 for ; Mon, 31 Mar 2003 11:03:53 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2VH3qwX36480224 for ; Mon, 31 Mar 2003 11:03:52 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h310Itp30990 for linux-xfs@oss.sgi.com; Mon, 31 Mar 2003 19:18:55 -0500 Resent-Message-Id: <200304010018.h310Itp30990@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2VH1owX38541834 for ; Mon, 31 Mar 2003 11:01:51 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.8/8.11.4/nodin-1.0) with ESMTP id h2VH1n4L27869979 for ; Mon, 31 Mar 2003 09:01:49 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h2VGwPx1000941 for ; Mon, 31 Mar 2003 18:58:25 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h2VGwP4O000940 for hch@sgi.com; Mon, 31 Mar 2003 18:58:25 +0200 Date: Mon, 31 Mar 2003 18:58:25 +0200 From: Christoph Hellwig Message-Id: <200303311658.h2VGwP4O000940@lab343.munich.sgi.com> Subject: TAKE - streamline pagebuf I/O completion thread handling. To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Mon, 31 Mar 2003 19:18:54 -0500 Resent-To: linux-xfs@oss.sgi.com X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3454 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: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 587 Lines: 19 Replace the task queue with a simple list_head and wake the threads directly instead of using a semaphore. Cleanup code a bit in preparation of examining different thread-pool models. Date: Mon Mar 31 09:00:46 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:143110a linux/fs/xfs/pagebuf/page_buf.c - 1.107 - revamp I/O completion thread handling linux/fs/xfs/pagebuf/page_buf.h - 1.63 - replace I/O completion taskqueue with simple list_head From owner-linux-xfs@oss.sgi.com Mon Mar 31 10:21:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Mar 2003 10:21:55 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2VILHq9019739 for ; Mon, 31 Mar 2003 10:21:46 -0800 Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62]) by palrel11.hp.com (Postfix) with ESMTP id E08461C00D11 for ; Mon, 31 Mar 2003 10:21:16 -0800 (PST) Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63]) by xparelay1.ptp.hp.com (Postfix) with ESMTP id D604A1004BB5 for ; Mon, 31 Mar 2003 10:21:16 -0800 (PST) Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2655.55) id ; Mon, 31 Mar 2003 10:21:16 -0800 Message-ID: From: "HABBINGA,ERIK (HP-Loveland,ex1)" To: "'linux-xfs@oss.sgi.com'" Subject: RE: crash in linvfs_dentry_to_fh Date: Mon, 31 Mar 2003 10:21:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3455 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: erik.habbinga@hp.com Precedence: bulk X-list: linux-xfs Content-Length: 5591 Lines: 143 Steve, The kernel I'm running does have a patch to drop the BKL around calls to xfs_permission, xfs_lookup, and xfs_readdir, based on the philosophy of a post of yours from Feb 2002: http://lists.insecure.org/linux-kernel/2002/Feb/4308.html permission, lookup, and readdir were the biggest hitters of BKL usage when profiling the SPEC SFS NFS test last year. I don't know if not having the BKL in the lookup code is the problem here, as we crash out of the lookup code in fh_compose. I don't drop the BKL before entering linvfs_dentry_to_fh. The stack trace from the oops isn't quite correct, the call tree doesn't go through lookup_hash before getting to linvfs_dentry_to_fh, it should go: nfsd_lookup -> fh_compose -> linvfs_dentry_to_fh I'll instrument linvfs_fh_to_dentry and xfs_inactive like you suggest and let you know the results. Let me know if you think dropping the BKL around permission, lookup, and readdir might be causing this problem. Erik > Well, looking at how NFS uses the call, and what we do inside it, I > would say there is a chance the inode is being torn down on another > cpu at the same time. Except there is reference on the dentry here > and it does not call this function for negative dentry. This > does indeed look like a partially initialized or torn down > inode. The xfs_inactive crash looks a little similar. If you can > instrument up linvfs_dentry_to_fh and dump the vnode contents > when this happens it might show us something. So adding an explicit > check for the pointer being null would be the thing to do. > Not sure I can suggest a similar thing to try in the inactive > path. > > Steve > -----Original Message----- > From: HABBINGA,ERIK (HP-Loveland,ex1) > Sent: Friday, March 28, 2003 3:28 PM > To: 'linux-xfs@oss.sgi.com' > Subject: crash in linvfs_dentry_to_fh > > I get the following crash in linvfs_dentry_to_fh after > pushing a server very hard with the SPEC SFS NFS test. It's > a similar crash to the xfs_inactive crash I mentioned earlier > in the week. Not always repeatable, but we've seen it a few times: > > ksymoops 2.4.5 on i686 2.4.18-14. Options used > -V (default) > -K (specified) > -L (specified) > -O (specified) > -m System.map (specified) > > Unable to handle kernel NULL pointer dereference at virtual > address 00000008 > printing eip: > 801d9578 > *pde = 72da5001 > Oops: 0000 > CPU: 0 > EIP: 0010:[<801d9578>] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010202 > eax: 00000000 ebx: 0000000d ecx: f508f100 edx: 80336b20 > esi: f2121ec4 edi: f4cb64a4 ebp: f2121f04 esp: f2121eb4 > ds: 0018 es: 0018 ss: 0018 > Process nfsd (pid: 4074, stackpage=f2121000) > Stack: f4cb6494 f2093000 f4cb64a4 94d29220 fffffff4 94d29220 > f508f0e0 8014236d > 8016b515 94d29220 f4cb64a4 f2121f04 00000001 94d295a0 > 94d295a0 0000000d > f4cb6404 80336b20 f2121f04 f508f100 0000000d 8016bf65 > f4cb6494 f2093000 > Call Trace: [<8014236d>] [<8016b515>] [<8016bf65>] > [<802c2a24>] [<80171e58>] > [<80168eb3>] [<802c2635>] [<80168c67>] [<80105694>] > > Code: 8b 50 08 56 8b 41 f4 50 8b 42 50 ff d0 8b 44 24 20 89 07 8b > > > >>EIP; 801d9578 <===== > > >>ecx; f508f100 > >>edx; 80336b20 > >>esi; f2121ec4 > >>edi; f4cb64a4 > >>ebp; f2121f04 > >>esp; f2121eb4 > > Trace; 8014236d > Trace; 8016b515 > Trace; 8016bf65 > Trace; 802c2a24 > Trace; 80171e58 > Trace; 80168eb3 > Trace; 802c2635 > Trace; 80168c67 > Trace; 80105694 > Code; 801d9578 > 00000000 <_EIP>: > Code; 801d9578 <===== > 0: 8b 50 08 mov 0x8(%eax),%edx <===== > Code; 801d957b > 3: 56 push %esi > Code; 801d957c > 4: 8b 41 f4 mov 0xfffffff4(%ecx),%eax > Code; 801d957f > 7: 50 push %eax > Code; 801d9580 > 8: 8b 42 50 mov 0x50(%edx),%eax > Code; 801d9583 > b: ff d0 call *%eax > Code; 801d9585 > d: 8b 44 24 20 mov 0x20(%esp,1),%eax > Code; 801d9589 > 11: 89 07 mov %eax,(%edi) > Code; 801d958b > 13: 8b 00 mov (%eax),%eax > > The code in question is derefencing the vp->v_bh pointer to > get the vp->v_bh.bh_first->bd_ops (also known as vp->v_fops) > pointer in preparation for getting the vop_fid2 function > pointer. vp->v_bh is NULL, which causes the crash. > > Dissassembly of linvfs_dentry_to_fh: > /src/kernel/linux/fs/xfs/linux/xfs_super.c:724 > > VOP_FID2(vp, (struct fid *)&fid, error); > 801d9571: 8b 41 f4 mov 0xfffffff4(%ecx),%eax > 801d9574: 8d 74 24 10 lea 0x10(%esp,1),%esi > 801d9578: 8b 50 08 mov 0x8(%eax),%edx > > We're running 2.4.20 with XFS CVS from March 17th. > > Erik Habbinga > Hewlett Packard > From owner-linux-xfs@oss.sgi.com Mon Mar 31 10:49:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Mar 2003 10:49:59 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2VInYq9021164 for ; Mon, 31 Mar 2003 10:49:48 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2VInSnH008171 for ; Mon, 31 Mar 2003 10:49:28 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA13058; Mon, 31 Mar 2003 12:49:24 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1904LU-0007FL-00; Mon, 31 Mar 2003 12:49:24 -0600 Date: Mon, 31 Mar 2003 12:49:23 -0600 From: Nathan Straz To: "'Linto Joseph Mathew" Cc: linux-xfs@oss.sgi.com Subject: Re: How do i use extrattrib functions in C . Message-ID: <20030331184923.GB21536@sgi.com> Mail-Followup-To: 'Linto Joseph Mathew , linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3456 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: nstraz@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 619 Lines: 18 On Mon, Mar 31, 2003 at 07:18:00PM +0530, 'Linto Joseph Mathew wrote: > There are system calls for set/getting extra attributes to a file. > How do i invoke it in a c program? > Is there any special functions? Check the getxattr and setxattr man pages that are part of the libattr1-dev[1] package. [1] That's the Debian package name. The name could vary on the distribution you are using. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Mon Mar 31 11:25:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Mar 2003 11:25:15 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2VJOMq9022204 for ; Mon, 31 Mar 2003 11:25:08 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2VJOGnH010644 for ; Mon, 31 Mar 2003 11:24:17 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA74716; Mon, 31 Mar 2003 13:24:15 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2VJOFwX38476437; Mon, 31 Mar 2003 13:24:15 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2VJOFV04684; Mon, 31 Mar 2003 13:24:15 -0600 Subject: RE: crash in linvfs_dentry_to_fh From: Steve Lord To: "HABBINGA,ERIK ""(HP-Loveland,ex1)" Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1049138655.3164.51.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 31 Mar 2003 13:24:15 -0600 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3457 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1549 Lines: 37 On Mon, 2003-03-31 at 12:21, HABBINGA,ERIK (HP-Loveland,ex1) wrote: > Steve, > > The kernel I'm running does have a patch to drop the BKL around calls to > xfs_permission, xfs_lookup, and xfs_readdir, based on the philosophy of a > post of yours from Feb 2002: > > http://lists.insecure.org/linux-kernel/2002/Feb/4308.html > > permission, lookup, and readdir were the biggest hitters of BKL usage when > profiling the SPEC SFS NFS test last year. I don't know if not having the > BKL in the lookup code is the problem here, as we crash out of the lookup > code in fh_compose. I don't drop the BKL before entering > linvfs_dentry_to_fh. The stack trace from the oops isn't quite correct, the > call tree doesn't go through lookup_hash before getting to > linvfs_dentry_to_fh, it should go: > > nfsd_lookup -> fh_compose -> linvfs_dentry_to_fh > > I'll instrument linvfs_fh_to_dentry and xfs_inactive like you suggest and > let you know the results. Let me know if you think dropping the BKL around > permission, lookup, and readdir might be causing this problem. It has been pointed out to me that there are cases where nfs has been known to do things without the i_sem being held when it should be. This in combination with dropping the BKL might the cause here. I don't know what speedup you are seeing from BKL removals, but I really think you may be introducing bugs by doing this. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Mar 31 13:22:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Mar 2003 13:22:58 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2VLMqq9030160 for ; Mon, 31 Mar 2003 13:22:52 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2VLMque030158 for linux-xfs@oss.sgi.com; Mon, 31 Mar 2003 13:22:52 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.8/8.12.5) with ESMTP id h2VLMoqB030145 for ; Mon, 31 Mar 2003 13:22:51 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.8/8.12.8/Submit) id h2VLFLvW028886; Mon, 31 Mar 2003 13:15:21 -0800 Date: Mon, 31 Mar 2003 13:15:21 -0800 Message-Id: <200303312115.h2VLFLvW028886@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 230] umount hangs after high disk load X-Bugzilla-Reason: AssignedTo X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3458 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: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 379 Lines: 18 http://oss.sgi.com/bugzilla/show_bug.cgi?id=230 ------- Additional Comments From cattelan@thebarn.com 2003-03-31 13:15 ------- Still would be helpful to have a look at the request queue rqueue where is the first arg to get_request_wait ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Mar 31 14:44:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Mar 2003 14:44:38 -0800 (PST) Received: from stargate.coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.114.72.97]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2VMhlq9018025 for ; Mon, 31 Mar 2003 14:44:28 -0800 Received: from contact.skynet.coplanar.net (contact.skynet.coplanar.net [192.168.7.125]) by stargate.coplanar.net (8.12.8/8.12.5) with ESMTP id h2VMhkAW015680 for ; Mon, 31 Mar 2003 17:43:47 -0500 Subject: xfs_repair of root filesystem From: Jeremy Jackson To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1049150626.1258.58.camel@contact.skynet.coplanar.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 31 Mar 2003 17:43:46 -0500 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3459 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: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 407 Lines: 12 Hi, I'm wonder what's the official word about xfs_repair on a read-only mounted fs. The utilities complain for me, so I have to boot from a repair partition to fix XFS (a while back when the shutdown files in use bug was still a problem). Ext2 has no problem with this. I'd just to know for future reference, so I know if I have to have a spare root fs or not. -- Jeremy Jackson From owner-linux-xfs@oss.sgi.com Mon Mar 31 14:48:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Mar 2003 14:48:35 -0800 (PST) Received: from hvs.envisage.co.za (hvs.envisage.co.za [196.36.161.89]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2VMmRq9018478 for ; Mon, 31 Mar 2003 14:48:31 -0800 Received: from hvisage by hvs.envisage.co.za with local (Exim 3.36 #1) id 19084g-00036k-00 for linux-xfs@oss.sgi.com; Tue, 01 Apr 2003 00:48:18 +0200 Date: Tue, 1 Apr 2003 00:48:18 +0200 From: Hendrik Visage To: linux-xfs@oss.sgi.com Subject: Moving XFS between sparc64 and ia32 Message-ID: <20030331224818.GA11927@hvs.envisage.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-message-flag: Outlook is Exploitable! -- http://www.rodos.net/outlook/ X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3460 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: hvisage@envisage.co.za Precedence: bulk X-list: linux-xfs Content-Length: 461 Lines: 17 Hi there, I've created an XFS on an Intel 32bit machine, and are now trying to mount it on a sparc64 machine. I've noticed issues with the pagebuff/blocksize, but how do I circumvent it? The messages in dmesg output I'm getting is: XFS mounting filesystem ide0(3,66) Starting XFS recovery on filesystem: ide0(3,66) (dev: 3/66) XFS: dirty log written in incompatible format - can't recover XFS: log mount/recovery failed XFS: log mount failed Thanx Hendrik From owner-linux-xfs@oss.sgi.com Mon Mar 31 14:58:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Mar 2003 14:58:56 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2VMwAq9018959 for ; Mon, 31 Mar 2003 14:58:51 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2VMw5uY032440 for ; Mon, 31 Mar 2003 14:58:05 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA11436; Mon, 31 Mar 2003 16:58:03 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2VMw2wX35966539; Mon, 31 Mar 2003 16:58:02 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2VMw2L05301; Mon, 31 Mar 2003 16:58:02 -0600 Subject: Re: Moving XFS between sparc64 and ia32 From: Steve Lord To: Hendrik Visage Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030331224818.GA11927@hvs.envisage.co.za> References: <20030331224818.GA11927@hvs.envisage.co.za> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1049151482.5177.1.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 31 Mar 2003 16:58:02 -0600 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3461 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 981 Lines: 28 On Mon, 2003-03-31 at 16:48, Hendrik Visage wrote: > Hi there, > > I've created an XFS on an Intel 32bit machine, and are now trying > to mount it on a sparc64 machine. I've noticed issues with the > pagebuff/blocksize, but how do I circumvent it? > > The messages in dmesg output I'm getting is: > > XFS mounting filesystem ide0(3,66) > Starting XFS recovery on filesystem: ide0(3,66) (dev: 3/66) > XFS: dirty log written in incompatible format - can't recover > XFS: log mount/recovery failed > XFS: log mount failed You are moving between little endian and big endian machines. While metadata is always big endian in xfs, the log contents are not. If you are sure you did a clean unmount on ia32, try running xfs_repair -L on the filesystem. But if you can I would mount and unmount it on ia32 just in case before this. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Mar 31 15:01:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Mar 2003 15:01:12 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2VN0lq9019389 for ; Mon, 31 Mar 2003 15:01:07 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2VN0fuY032758 for ; Mon, 31 Mar 2003 15:00:41 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA93728; Mon, 31 Mar 2003 17:00:40 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2VN0eCI6687390; Mon, 31 Mar 2003 17:00:41 -0600 (CST) Subject: Re: xfs_repair of root filesystem From: Eric Sandeen To: Jeremy Jackson Cc: linux-xfs@oss.sgi.com In-Reply-To: <1049150626.1258.58.camel@contact.skynet.coplanar.net> References: <1049150626.1258.58.camel@contact.skynet.coplanar.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 31 Mar 2003 16:59:55 -0600 Message-Id: <1049151595.17362.34.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3462 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1373 Lines: 36 hi Jeremy - It's in the faq, http://oss.sgi.com/projects/xfs/faq.html#xfschecks Q: My filesystem is ok - but xfs_check or xfs_repair shows errors/won't run - whats wrong here? You can not run xfs_repair on a mounted filesystem although support is available in CVS (08-02-2002) that lets you run xfs_repair with the -n switch on a read-only mounted filesystem. You must not try to repair a mounted fs since this will result in dataloss and corruption when attempted. If you have to repair you're filesystem it needs to be unmounted first. If this is the root (/) filesystem this will mean you have to boot from a bootable CD and perform the repair on the unmounted filesystem. There is a link to various bootable floppy/cd projects mentioned in the FAQ here. -Eric On Mon, 2003-03-31 at 16:43, Jeremy Jackson wrote: > Hi, > > I'm wonder what's the official word about xfs_repair on a read-only > mounted fs. The utilities complain for me, so I have to boot from a > repair partition to fix XFS (a while back when the shutdown files in use > bug was still a problem). Ext2 has no problem with this. I'd just to > know for future reference, so I know if I have to have a spare root fs > or not. > > -- > Jeremy Jackson > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Mar 31 15:02:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Mar 2003 15:02:42 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2VN2Kq9019734 for ; Mon, 31 Mar 2003 15:02:40 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2VN2EuY000477 for ; Mon, 31 Mar 2003 15:02:14 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA78795; Mon, 31 Mar 2003 17:02:13 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2VN2DCI6496352; Mon, 31 Mar 2003 17:02:13 -0600 (CST) Subject: Re: Moving XFS between sparc64 and ia32 From: Eric Sandeen To: Hendrik Visage Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030331224818.GA11927@hvs.envisage.co.za> References: <20030331224818.GA11927@hvs.envisage.co.za> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 31 Mar 2003 17:01:28 -0600 Message-Id: <1049151688.29779.36.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3463 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: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 789 Lines: 24 On Mon, 2003-03-31 at 16:48, Hendrik Visage wrote: > Hi there, > > I've created an XFS on an Intel 32bit machine, and are now trying > to mount it on a sparc64 machine. I've noticed issues with the > pagebuff/blocksize, but how do I circumvent it? > > The messages in dmesg output I'm getting is: > > XFS mounting filesystem ide0(3,66) > Starting XFS recovery on filesystem: ide0(3,66) (dev: 3/66) > XFS: dirty log written in incompatible format - can't recover > XFS: log mount/recovery failed > XFS: log mount failed From this message, the best thing to do would be to put it back in the intel machine, and cleanly unmount it before you try to move it. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Mar 31 15:16:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Mar 2003 15:16:12 -0800 (PST) Received: from ubergeek (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2VNFTq9020341 for ; Mon, 31 Mar 2003 15:16:09 -0800 Received: (qmail 32275 invoked by uid 500); 31 Mar 2003 23:13:28 -0000 Subject: Re: xfs_repair of root filesystem From: Austin Gonyou To: XFS List In-Reply-To: <1049151595.17362.34.camel@stout.americas.sgi.com> References: <1049151595.17362.34.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1049152404.29472.199.camel@UberGeek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 31 Mar 2003 17:13:28 -0600 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3464 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: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 580 Lines: 18 On Mon, 2003-03-31 at 16:59, Eric Sandeen wrote: > hi Jeremy - It's in the faq, > http://oss.sgi.com/projects/xfs/faq.html#xfschecks > > Q: My filesystem is ok - but xfs_check or xfs_repair shows > errors/won't > run - whats wrong here? I'm kinda curious about a thought I had around this. Would it be at all possible to perform xfs_freeze on the root FS then check? Where xfs_freeze would potentially have a special "repair" sesion or something so you didn't have to bring the box down to do repair filesystems? -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Mon Mar 31 15:25:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Mar 2003 15:25:57 -0800 (PST) Received: from hvs.envisage.co.za (hvs.envisage.co.za [196.36.161.89]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2VNP7q9020855 for ; Mon, 31 Mar 2003 15:25:50 -0800 Received: from hvisage by hvs.envisage.co.za with local (Exim 3.36 #1) id 1908e3-00039l-00; Tue, 01 Apr 2003 01:24:51 +0200 Date: Tue, 1 Apr 2003 01:24:51 +0200 From: Hendrik Visage To: Steve Lord Cc: Hendrik Visage , linux-xfs@oss.sgi.com Subject: Re: Moving XFS between sparc64 and ia32 Message-ID: <20030331232451.GB11927@hvs.envisage.co.za> References: <20030331224818.GA11927@hvs.envisage.co.za> <1049151482.5177.1.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1049151482.5177.1.camel@jen.americas.sgi.com> User-Agent: Mutt/1.4i X-message-flag: Outlook is Exploitable! -- http://www.rodos.net/outlook/ X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3465 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: hvisage@envisage.co.za Precedence: bulk X-list: linux-xfs Content-Length: 410 Lines: 11 On Mon, Mar 31, 2003 at 04:58:02PM -0600, Steve Lord wrote: > > You are moving between little endian and big endian machines. While > metadata is always big endian in xfs, the log contents are not. > If you are sure you did a clean unmount on ia32, try running > xfs_repair -L on the filesystem. But if you can I would > mount and unmount it on ia32 just in case before this. Thanx. Will try that tomorow. From owner-linux-xfs@oss.sgi.com Mon Mar 31 17:50:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Mar 2003 17:50:22 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h311o9q9022968 for ; Mon, 31 Mar 2003 17:50:10 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h2VNOMuY003127 for ; Mon, 31 Mar 2003 15:24:22 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA74991; Mon, 31 Mar 2003 17:24:21 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.8/SGI-server-1.8) with ESMTP id h2VNOLwX38226598; Mon, 31 Mar 2003 17:24:21 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h2VNOLR05398; Mon, 31 Mar 2003 17:24:21 -0600 Subject: Re: xfs_repair of root filesystem From: Steve Lord To: Austin Gonyou Cc: XFS List In-Reply-To: <1049152404.29472.199.camel@UberGeek> References: <1049151595.17362.34.camel@stout.americas.sgi.com> <1049152404.29472.199.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1049153061.5177.15.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 31 Mar 2003 17:24:21 -0600 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3466 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: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 891 Lines: 25 On Mon, 2003-03-31 at 17:13, Austin Gonyou wrote: > On Mon, 2003-03-31 at 16:59, Eric Sandeen wrote: > > hi Jeremy - It's in the faq, > > http://oss.sgi.com/projects/xfs/faq.html#xfschecks > > > > Q: My filesystem is ok - but xfs_check or xfs_repair shows > > errors/won't > > run - whats wrong here? > > I'm kinda curious about a thought I had around this. Would it be at all > possible to perform xfs_freeze on the root FS then check? Where > xfs_freeze would potentially have a special "repair" sesion or something > so you didn't have to bring the box down to do repair filesystems? The real answer is to fix up the user space libraries to allow repair to run on a mounted fs and issue a big fat warning to reboot NOW at the end. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Mar 31 20:23:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Mar 2003 20:23:19 -0800 (PST) Received: from web13607.mail.yahoo.com (web13607.mail.yahoo.com [216.136.175.118]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h314MRq9024813 for ; Mon, 31 Mar 2003 20:23:08 -0800 Message-ID: <20030401042227.38902.qmail@web13607.mail.yahoo.com> Received: from [202.140.139.169] by web13607.mail.yahoo.com via HTTP; Mon, 31 Mar 2003 20:22:27 PST Date: Mon, 31 Mar 2003 20:22:27 -0800 (PST) From: kishor bhagwat Subject: Re: LVM + XFS + Quotas To: linux-xfs@oss.sgi.com In-Reply-To: <20030330235533.GC861@frodo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 3467 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: aaaaarrrgghhh@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 1179 Lines: 47 --- Nathan Scott wrote: > On Fri, Mar 28, 2003 at 07:05:36PM -0800, kishor bhagwat > wrote: > > > > --- Chris Wedgwood wrote: > > > On Fri, Mar 28, 2003 at 03:27:51AM -0800, kishor > bhagwat > > > wrote: > > > > > > > I'm using RH 8.0 with kernel upgraded to > kernel.org's > > > 2.4.19, and > > > > XFS 1.2 patches. > > > > > > > I'm able to create quotas etc..but there is an > issue > > > with the actual > > > > usable space. > > > > > > what does 'quota' report? > > > > quota reports..... > > Filesystem /dev/HOME/DataVol > > blocks quota limit grace files quota limit > grace > > 32 64 80 12 0 0 > > > > > This is likely the problem. Your limits are extremely > low - > that's just 80K above, right? (less than an HD floppy > disk ;) Yes..this does seem to be the problem - how do I figure out the total space I will lose? (so i can do some capacity planning? Is the amount of space fixed per quota? regds, kishor __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://platinum.yahoo.com