From owner-linux-xfs@oss.sgi.com Thu Jul 31 23:59:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 00:00:14 -0700 (PDT) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h716xoFl011050 for ; Thu, 31 Jul 2003 23:59:51 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h714xnQa018162 for ; Thu, 31 Jul 2003 21:59:49 -0700 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 h716xhJA8137248 for ; Fri, 1 Aug 2003 16:59:43 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h716xgfw8136075 for linux-xfs@oss.sgi.com; Fri, 1 Aug 2003 16:59:42 +1000 (EST) Date: Fri, 1 Aug 2003 16:59:42 +1000 (EST) From: Nathan Scott Message-Id: <200308010659.h716xgfw8136075@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - pagebuf X-archive-position: 4852 X-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 Forward port 2.4 pagebuf locking to 2.5, based on Steve's analysis; should fix the infamous pagebuf IO completion buglet. Date: Thu Jul 31 23:57:10 PDT 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:154781a linux/fs/xfs/pagebuf/page_buf.c - 1.116 Update xfsidbg commands for dumping i_hash Date: Thu Jul 31 23:59:04 PDT 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:154782a linux/fs/xfs/xfsidbg.c - 1.231 From owner-linux-xfs@oss.sgi.com Fri Aug 1 00:09:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 00:09:20 -0700 (PDT) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7179FFl012200 for ; Fri, 1 Aug 2003 00:09:16 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.9/8.12.9) with ESMTP id h7179D7w004057 for ; Fri, 1 Aug 2003 09:09:14 +0200 (CEST) Message-Id: <4.3.2.7.2.20030801085547.0338ac60@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Aug 2003 09:08:53 +0200 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: XFS 1.3.0pre4 RPMS for Red Hat 7.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 4853 X-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 Hello, I've been on a 2 week vacation to croatia so I had some cathing up to do. First spin of some 1.3pre release rpms. Built on Red Hat 7.3 with a small patch that alters the min/max readahead buffers. That should fix the (read) performance issue that has been present since the 2.4.18-27 2.4.20-8 switch. http://iserv.nl/files/xfs/2.4.20-18-xfs-1.3/ Next step is building with the latest errata. If you need the 1.2 rpms I suggest fetching the RPMS Axel Thimm made. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Aug 1 03:06:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 03:07:17 -0700 (PDT) Received: from mail.tamiweb.com (mail.tamiweb.com [194.12.244.146]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71A6rFl031019 for ; Fri, 1 Aug 2003 03:06:56 -0700 Received: (qmail 15883 invoked by uid 89); 1 Aug 2003 10:15:35 -0000 Received: from unknown (HELO tamiweb.com) (larry@tamiweb.com@217.18.248.130) by 0 with SMTP; 1 Aug 2003 10:15:35 -0000 Message-ID: <3F2A3C21.9030909@tamiweb.com> Date: Fri, 01 Aug 2003 13:08:33 +0300 From: Kostadin Karaivanov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030704 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: TAKE - pagebuff Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4854 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: larry@tamiweb.com Precedence: bulk X-list: linux-xfs The recent as of today linux-2.5-xfs CVS tree does not compile. I got this error: CC fs/xfs/pagebuf/page_buf.o CC fs/xfs/pagebuf/page_buf_locking.o CC fs/xfs/linux/xfs_aops.o fs/xfs/linux/xfs_aops.c: In function `linvfs_direct_IO': fs/xfs/linux/xfs_aops.c:948: too few arguments to function `blockdev_direct_IO' make[2]: *** [fs/xfs/linux/xfs_aops.o] Error 1 make[1]: *** [fs/xfs] Error 2 make: *** [fs] Error 2 root@hosting:/usr/src/linux-2.5-xfs/linux# wwell Larry From owner-linux-xfs@oss.sgi.com Fri Aug 1 03:54:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 03:54:26 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71As5Fl002091 for ; Fri, 1 Aug 2003 03:54:06 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h71As0q0004977 for ; Fri, 1 Aug 2003 03:54:00 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h71ArxQK3880150; Fri, 1 Aug 2003 05:53:59 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-40.corp.sgi.com [134.15.64.40]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h71ArvRn204202594; Fri, 1 Aug 2003 05:53:58 -0500 (CDT) Subject: Re: TAKE - pagebuff From: Steve Lord To: Kostadin Karaivanov Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F2A3C21.9030909@tamiweb.com> References: <3F2A3C21.9030909@tamiweb.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 01 Aug 2003 05:54:11 -0500 Message-Id: <1059735252.1923.3.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 4855 X-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-08-01 at 05:08, Kostadin Karaivanov wrote: > The recent as of today linux-2.5-xfs CVS tree does not compile. > I got this error: > > CC fs/xfs/pagebuf/page_buf.o > CC fs/xfs/pagebuf/page_buf_locking.o > CC fs/xfs/linux/xfs_aops.o > fs/xfs/linux/xfs_aops.c: In function `linvfs_direct_IO': > fs/xfs/linux/xfs_aops.c:948: too few arguments to function > `blockdev_direct_IO' > make[2]: *** [fs/xfs/linux/xfs_aops.o] Error 1 > make[1]: *** [fs/xfs] Error 2 > make: *** [fs] Error 2 > root@hosting:/usr/src/linux-2.5-xfs/linux# You may have caught it in mid update, that line number does not match the internal trees (which build). Try updating again, if it still fails, we need to make sure the cvs tree is getting updated correctly. Steve From owner-linux-xfs@oss.sgi.com Fri Aug 1 04:29:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 04:29:27 -0700 (PDT) Received: from khe-mailhub1.eigner.com (khe-mailhub1.eigner.com [194.120.231.246]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71BT4Fl005566 for ; Fri, 1 Aug 2003 04:29:05 -0700 Received: from eigner.com (unknown [194.120.231.18]) by khe-mailhub1.eigner.com (Postfix) with ESMTP id 5D05C2CB; Fri, 1 Aug 2003 13:28:43 +0200 (CEST) Message-ID: <3F2A4EEB.9020601@eigner.com> Date: Fri, 01 Aug 2003 13:28:43 +0200 From: Klaus Strebel Organization: EIGNER Germany GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: de, en, de-de, en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Cc: Steve Lord , Kostadin Karaivanov Subject: Re: TAKE - pagebuff References: <3F2A3C21.9030909@tamiweb.com> <1059735252.1923.3.camel@laptop.americas.sgi.com> In-Reply-To: <1059735252.1923.3.camel@laptop.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-102.6, required 5, EMAIL_ATTRIBUTION -0.50, IN_REP_TO -0.50, QUOTED_EMAIL_TEXT -0.48, REFERENCES -0.50, REPLY_WITH_QUOTES -0.50, USER_AGENT_MOZILLA_UA 0.00, USER_IN_WHITELIST -100.00, X_ACCEPT_LANG -0.10) X-archive-position: 4856 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: klaus.strebel@eigner.com Precedence: bulk X-list: linux-xfs Steve Lord wrote: > On Fri, 2003-08-01 at 05:08, Kostadin Karaivanov wrote: > >>The recent as of today linux-2.5-xfs CVS tree does not compile. >>I got this error: >> >> CC fs/xfs/pagebuf/page_buf.o >> CC fs/xfs/pagebuf/page_buf_locking.o >> CC fs/xfs/linux/xfs_aops.o >>fs/xfs/linux/xfs_aops.c: In function `linvfs_direct_IO': >>fs/xfs/linux/xfs_aops.c:948: too few arguments to function >>`blockdev_direct_IO' >>make[2]: *** [fs/xfs/linux/xfs_aops.o] Error 1 >>make[1]: *** [fs/xfs] Error 2 >>make: *** [fs] Error 2 >>root@hosting:/usr/src/linux-2.5-xfs/linux# > > > You may have caught it in mid update, that line number does not > match the internal trees (which build). Try updating again, if > it still fails, we need to make sure the cvs tree is getting > updated correctly. Hi all, i can confirm to this, i updated my tree on wednesday and just 2 minutes ago, the blockdev_direct_IO call is missing a parameter (i just added a ',NULL' to make it compile, my laptop 's running with it without problems). So, the CVS tree seems to be brocken. Could you push your 'internal' tree :-). Ciao Klaus -- Klaus Strebel UNIX-Engineer klaus.strebel@eigner.com EIGNER - Precision Lifecycle Management - From owner-linux-xfs@oss.sgi.com Fri Aug 1 04:30:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 04:31:09 -0700 (PDT) Received: from mail.tamiweb.com (mail.tamiweb.com [194.12.244.146]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71BUOFl005746 for ; Fri, 1 Aug 2003 04:30:28 -0700 Received: (qmail 15602 invoked by uid 89); 1 Aug 2003 09:52:26 -0000 Received: from unknown (HELO minfin.bg) (larry@tamiweb.com@217.18.248.130) by 0 with SMTP; 1 Aug 2003 09:52:26 -0000 Message-ID: <3F2A36B3.90001@minfin.bg> Date: Fri, 01 Aug 2003 12:45:23 +0300 From: Kostadin Karaivanov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030704 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: TAKE - pagebuff Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4857 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: larry@minfin.bg Precedence: bulk X-list: linux-xfs The recent as of today linux-2.5-xfs CVS tree does not compile. I got this error: CC fs/xfs/pagebuf/page_buf.o CC fs/xfs/pagebuf/page_buf_locking.o CC fs/xfs/linux/xfs_aops.o fs/xfs/linux/xfs_aops.c: In function `linvfs_direct_IO': fs/xfs/linux/xfs_aops.c:948: too few arguments to function `blockdev_direct_IO' make[2]: *** [fs/xfs/linux/xfs_aops.o] Error 1 make[1]: *** [fs/xfs] Error 2 make: *** [fs] Error 2 root@hosting:/usr/src/linux-2.5-xfs/linux# wwell Larry From owner-linux-xfs@oss.sgi.com Fri Aug 1 04:58:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 04:58:32 -0700 (PDT) Received: from mail.tamiweb.com (mail.tamiweb.com [194.12.244.146]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71BwLFl011674 for ; Fri, 1 Aug 2003 04:58:24 -0700 Received: (qmail 19570 invoked by uid 89); 1 Aug 2003 12:07:04 -0000 Received: from unknown (HELO tamiweb.com) (larry@tamiweb.com@217.18.248.130) by 0 with SMTP; 1 Aug 2003 12:07:04 -0000 Message-ID: <3F2A5641.6000709@tamiweb.com> Date: Fri, 01 Aug 2003 15:00:01 +0300 From: Kostadin Karaivanov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030704 X-Accept-Language: en-us MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: TAKE - pagebuff References: <3F2A3C21.9030909@tamiweb.com> <1059735252.1923.3.camel@laptop.americas.sgi.com> In-Reply-To: <1059735252.1923.3.camel@laptop.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4858 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: larry@tamiweb.com Precedence: bulk X-list: linux-xfs Steve Lord wrote: >On Fri, 2003-08-01 at 05:08, Kostadin Karaivanov wrote: > > >>The recent as of today linux-2.5-xfs CVS tree does not compile. >>I got this error: >> >> CC fs/xfs/pagebuf/page_buf.o >> CC fs/xfs/pagebuf/page_buf_locking.o >> CC fs/xfs/linux/xfs_aops.o >>fs/xfs/linux/xfs_aops.c: In function `linvfs_direct_IO': >>fs/xfs/linux/xfs_aops.c:948: too few arguments to function >>`blockdev_direct_IO' >>make[2]: *** [fs/xfs/linux/xfs_aops.o] Error 1 >>make[1]: *** [fs/xfs] Error 2 >>make: *** [fs] Error 2 >>root@hosting:/usr/src/linux-2.5-xfs/linux# >> >> > >You may have caught it in mid update, that line number does not >match the internal trees (which build). Try updating again, if >it still fails, we need to make sure the cvs tree is getting >updated correctly. > >Steve > > 2 hours later still the same wwell Larry From owner-linux-xfs@oss.sgi.com Fri Aug 1 05:20:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 05:21:00 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71CKgFl013605 for ; Fri, 1 Aug 2003 05:20:45 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h71CKaq0022488 for ; Fri, 1 Aug 2003 05:20:37 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h71CKaQK3888710; Fri, 1 Aug 2003 07:20:36 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-40.corp.sgi.com [134.15.64.40]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h71CKZRn187779349; Fri, 1 Aug 2003 07:20:35 -0500 (CDT) Subject: Re: TAKE - pagebuff From: Steve Lord To: Kostadin Karaivanov Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F2A5641.6000709@tamiweb.com> References: <3F2A3C21.9030909@tamiweb.com> <1059735252.1923.3.camel@laptop.americas.sgi.com> <3F2A5641.6000709@tamiweb.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 01 Aug 2003 07:20:48 -0500 Message-Id: <1059740450.1924.6.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 4859 X-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-08-01 at 07:00, Kostadin Karaivanov wrote: > Steve Lord wrote: > > >On Fri, 2003-08-01 at 05:08, Kostadin Karaivanov wrote: > > > > > >>The recent as of today linux-2.5-xfs CVS tree does not compile. > >>I got this error: > >> > >> CC fs/xfs/pagebuf/page_buf.o > >> CC fs/xfs/pagebuf/page_buf_locking.o > >> CC fs/xfs/linux/xfs_aops.o > >>fs/xfs/linux/xfs_aops.c: In function `linvfs_direct_IO': > >>fs/xfs/linux/xfs_aops.c:948: too few arguments to function > >>`blockdev_direct_IO' > >>make[2]: *** [fs/xfs/linux/xfs_aops.o] Error 1 > >>make[1]: *** [fs/xfs] Error 2 > >>make: *** [fs] Error 2 > >>root@hosting:/usr/src/linux-2.5-xfs/linux# > >> > >> > > > >You may have caught it in mid update, that line number does not > >match the internal trees (which build). Try updating again, if > >it still fails, we need to make sure the cvs tree is getting > >updated correctly. > > > >Steve > > > > > 2 hours later still the same OK, the tree update must be busted, your line number for the function is about 40 lines out. I will get someone to refresh the tree, it will not happen for a few hours I expect. Steve From owner-linux-xfs@oss.sgi.com Fri Aug 1 08:09:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 08:09:31 -0700 (PDT) Received: from mee05.mee.com (mee05.mee.com [194.130.244.67]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71F9AFl031022 for ; Fri, 1 Aug 2003 08:09:12 -0700 Received: from meemgw02.mee.com (meemgw02.mee.com [10.226.1.24]) by mee05.mee.com (8.11.6/8.11.6) with ESMTP id h71F94G76962 for ; Fri, 1 Aug 2003 16:09:04 +0100 (BST) Received: from meetvd02 (meetvd02.diamondlink.com [10.226.1.23]) by meemgw02.mee.com (8.11.6/8.11.6) with SMTP id h71F93F23086 for ; Fri, 1 Aug 2003 16:09:03 +0100 (BST) Received: FROM x4.vil.ite.mee.com BY meetvd02 ; Fri Aug 01 15:56:32 2003 +0100 Received: from zebra.vil.ite.mee.com ([10.226.210.109]) by x4.vil.ite.mee.com with esmtp (Exim 3.13 #1) id 19ibWZ-0003pz-00 for linux-xfs@oss.sgi.com; Fri, 01 Aug 2003 16:08:55 +0100 Subject: Nasty bug? From: Paul Furness To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Mitsubishi Electric ITE BV VIL Message-Id: <1059750535.15676.26.camel@Zebra.vil.ite.mee.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 01 Aug 2003 16:08:55 +0100 Content-Transfer-Encoding: 7bit X-Scanner: exiscan *19ibWZ-0003pz-00*KRbjrSogU02* (VIL, Mitsubishi Electric) X-archive-position: 4860 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: paul.furness@vil.ite.mee.com Precedence: bulk X-list: linux-xfs Hi. I've just hit what _could_ be a nasty bug in xfs unless I'm missing something. I have a server which was built on stock redhat 7.3 and then has a 2.4.20 kernel which I patched with xfs and lvm 1 and built (also including net drivers and so on). There is a hardware RAID device attached (full of IDE disks but presenting as a single SCSI disk to the OS). I put the entire RAID (1.6TB) into a single physical volume under lvm and created a number of logical volumes on it, all of which I formatted with xfs. It's been working just fine for about 4 months, but today I tried to create the remainder of the logical volumes I need (the last 200G or so of the disk) and format them with xfs. But xfs won't format them. Instead, it comes back with a load of i/o errors. I thought it might be the array playing up, so I tried mkfs -t ext3 on it ant it worked fine. I tried making lots of small logical volumes and formatting them separately, and after the first few the errors start happening on all the rest. It's as though xfs can't work on disk sectors above a certain limit. Is there some sort of limit on xfs that it can't be used above a certain sector number? Or am I missing something obvious? The following errors from the syslog look possibly relevant: Aug 1 15:17:01 picard modprobe: modprobe: Can't locate module block-major-43 Aug 1 15:18:22 picard last message repeated 32 times Aug 1 15:19:08 picard last message repeated 63 times Aug 1 15:19:20 picard kernel: I/O error: dev 08:00, sector 2789278339 Aug 1 15:19:20 picard kernel: I/O error: dev 08:00, sector 2797666947 Aug 1 15:19:20 picard kernel: I/O error: dev 08:00, sector 2806055555 Aug 1 15:19:20 picard kernel: I/O error: dev 08:00, sector 2814444163 Aug 1 15:19:20 picard kernel: I/O error: dev 08:00, sector 2822832771 Aug 1 15:19:20 picard kernel: I/O error: dev 08:00, sector 2831221379 the last message repeats many many times (> 100) with different sector numbers. As you can see, the sector numbers are not sequential, so it's not a simple hardware failure. I have seen the suggestion that the block-major-43 message (nbd call) can be ignored because it's an unsupported ioctl call to lvm which isn't relevant for local file systems. But if it's being made by xfs then it might be more important than that... :) Whatever the problem it only seems to happen at the 'top' of the disk. Any thoughts, anyone? Paul. From owner-linux-xfs@oss.sgi.com Fri Aug 1 08:29:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 08:29:39 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71FTZFl025818 for ; Fri, 1 Aug 2003 08:29:36 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h71FTUq0028776 for ; Fri, 1 Aug 2003 08:29:30 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h71FSTQK3947576; Fri, 1 Aug 2003 10:28:29 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h71FSTYl16109239; Fri, 1 Aug 2003 10:28:29 -0500 (CDT) Date: Fri, 1 Aug 2003 10:28:29 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Paul Furness cc: linux-xfs@oss.sgi.com Subject: Re: Nasty bug? In-Reply-To: <1059750535.15676.26.camel@Zebra.vil.ite.mee.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4861 X-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 Hi Paul - First I'd make sure you've got the latest xfsprogs, what version are you running? We've recently done some work with large block device kernels, and I have used mkfs.xfs on up to 3T filesystems on ia32. I did notice that your failing sectors do have the 32nd bit set, any driver down the line could have problems with sign extensions - but if mkfs.ext3 works, that probably rules out underlying drivers. I'm sure folks on the list are tired of our "try newer code" answers, but it's a good place to start, to make sure we're not chasing old bugs. You might even try a newer kernel - if you don't want to expose your data to a different kernel, you could just use it to test mkfs without mounting your existing filesystems on the raid. Thanks, -Eric From owner-linux-xfs@oss.sgi.com Fri Aug 1 08:30:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 08:31:13 -0700 (PDT) Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71FUXFl026001 for ; Fri, 1 Aug 2003 08:30:34 -0700 Received: from kenzo.iwr.uni-heidelberg.de (IDENT:GB/Ca58kE6RL6W3eSuYjTd4fgQfTiFhO@kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.12.9/8.12.9) with ESMTP id h71FUVru026952; Fri, 1 Aug 2003 17:30:31 +0200 (MET DST) Received: from kenzo.iwr.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by kenzo.iwr.uni-heidelberg.de (8.12.8/8.12.8) with ESMTP id h71FUV5K014796; Fri, 1 Aug 2003 17:30:31 +0200 Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.12.8/8.12.8/Submit) with ESMTP id h71FUVAv014792; Fri, 1 Aug 2003 17:30:31 +0200 Date: Fri, 1 Aug 2003 17:30:31 +0200 (CEST) From: Bogdan Costescu To: Paul Furness cc: linux-xfs@oss.sgi.com Subject: Re: Nasty bug? In-Reply-To: <1059750535.15676.26.camel@Zebra.vil.ite.mee.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4862 X-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 On 1 Aug 2003, Paul Furness wrote: > Aug 1 15:19:20 picard kernel: I/O error: dev 08:00, sector 2789278339 > Aug 1 15:19:20 picard kernel: I/O error: dev 08:00, sector 2797666947 > Aug 1 15:19:20 picard kernel: I/O error: dev 08:00, sector 2806055555 > Aug 1 15:19:20 picard kernel: I/O error: dev 08:00, sector 2814444163 > Aug 1 15:19:20 picard kernel: I/O error: dev 08:00, sector 2822832771 > Aug 1 15:19:20 picard kernel: I/O error: dev 08:00, sector 2831221379 > > the last message repeats many many times (> 100) with different sector > numbers. As you can see, the sector numbers are not sequential, so it's > not a simple hardware failure. The numbers are not sequential, but they are monotonically increasing :-) The difference between any 2 values is 8388608. Now if these are 512 byte sectors, this is exactly 4294967296 bytes which is 2^32... This won't help you directly... but might give somebody some idea :-) -- 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 Aug 1 08:38:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 08:39:03 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71FckFl027227 for ; Fri, 1 Aug 2003 08:38:47 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h71Fcfq0030775 for ; Fri, 1 Aug 2003 08:38:41 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h71FbeQK3961339; Fri, 1 Aug 2003 10:37:40 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h71FbeRn169721213; Fri, 1 Aug 2003 10:37:40 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h71Fbd113743; Fri, 1 Aug 2003 10:37:39 -0500 Subject: Re: Nasty bug? From: Steve Lord To: Bogdan Costescu Cc: Paul Furness , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1059752259.7842.31.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 01 Aug 2003 10:37:39 -0500 X-archive-position: 4863 X-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-08-01 at 10:30, Bogdan Costescu wrote: > On 1 Aug 2003, Paul Furness wrote: > > > Aug 1 15:19:20 picard kernel: I/O error: dev 08:00, sector 2789278339 > > Aug 1 15:19:20 picard kernel: I/O error: dev 08:00, sector 2797666947 > > Aug 1 15:19:20 picard kernel: I/O error: dev 08:00, sector 2806055555 > > Aug 1 15:19:20 picard kernel: I/O error: dev 08:00, sector 2814444163 > > Aug 1 15:19:20 picard kernel: I/O error: dev 08:00, sector 2822832771 > > Aug 1 15:19:20 picard kernel: I/O error: dev 08:00, sector 2831221379 > > > > the last message repeats many many times (> 100) with different sector > > numbers. As you can see, the sector numbers are not sequential, so it's > > not a simple hardware failure. > > The numbers are not sequential, but they are monotonically increasing :-) > The difference between any 2 values is 8388608. Now if these are 512 byte > sectors, this is exactly 4294967296 bytes which is 2^32... > > This won't help you directly... but might give somebody some idea :-) Almost certainly mkfs trying to lay down the allocation group headers in the filesystem, these would come out 4G apart. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Aug 1 08:39:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 08:39:55 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.85]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71FdnFl027540 for ; Fri, 1 Aug 2003 08:39:50 -0700 Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h71FdnYG000834 for ; Fri, 1 Aug 2003 08:39:49 -0700 (PDT) Received: from mac.com (24-197-163-3.charterga.net [24.197.163.3]) (authenticated bits=0) by mac.com (Xserve/8.12.9/MantshX 2.0) with ESMTP id h71Fct9d029577 for ; Fri, 1 Aug 2003 08:38:57 -0700 (PDT) Date: Fri, 1 Aug 2003 11:38:53 -0400 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: pbd_delwrite_lock and pb_list in page_buf.c From: "Dale J. Stephenson" To: linux-xfs@oss.sgi.com Content-Transfer-Encoding: 7bit Message-Id: <418AB2C2-C436-11D7-9EF1-0003937830E4@mac.com> X-Mailer: Apple Mail (2.552) X-archive-position: 4864 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dalestephenson@mac.com Precedence: bulk X-list: linux-xfs I was looking at a misbehaving xfs_freeze command in an older version of XFS and found myself stuck in the list_for_each_safe() loop in pagebuf_delwri_flush. The head had apparently been removed from the list in a case of spectacularly poor timing. I found that the list had been protected by the pbd_delwrite_lock, but not everywhere. Checking the current CVS, I still see that the list is still not protected everywhere. Examples: pagebuf_daemon, line 2083, calls list_del_init(&pb->pb_list) without holding the lock. pagebuf_delwri_flush, line 2182, calls list_del_init(&pb->pb_list) without holding the lock. pagebuf_delwri_flush, lines 2151-2166, releases the lock inside a list_for_each_safe loop. I don't see any downside to putting locks around the list_del_init calls. I'm not sure what to do with the last one. If it were changed to list_for_each, would it survive the head getting taken away? I'm assuming the lock cannot be held through __pagebuf_iorequest() or pagebuf_run_queues() calls. Dale J. Stephenson dalestephenson@mac.com From owner-linux-xfs@oss.sgi.com Fri Aug 1 08:40:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 08:41:01 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71FevFl028164 for ; Fri, 1 Aug 2003 08:40:57 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h71Fepq0031115 for ; Fri, 1 Aug 2003 08:40:51 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h71FdpQK3941779; Fri, 1 Aug 2003 10:39:51 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h71FdoYl16104982; Fri, 1 Aug 2003 10:39:51 -0500 (CDT) Date: Fri, 1 Aug 2003 10:39:50 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Bogdan Costescu cc: Paul Furness , Subject: Re: Nasty bug? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4865 X-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 On Fri, 1 Aug 2003, Bogdan Costescu wrote: > The numbers are not sequential, but they are monotonically increasing :-) > The difference between any 2 values is 8388608. Now if these are 512 byte > sectors, this is exactly 4294967296 bytes which is 2^32... > > This won't help you directly... but might give somebody some idea :-) The maximum AG size is 4G, for a very large fliesystem. mkfs.xfs writes allocation group headers at the start of each AG. howver, if this was split into small pieces & mkfs'd, then the AGs should not be that large... hm. -Eric From owner-linux-xfs@oss.sgi.com Fri Aug 1 08:51:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 08:52:14 -0700 (PDT) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.86]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71FpnFl029797 for ; Fri, 1 Aug 2003 08:51:51 -0700 Received: from puariko.homeip.net (pD9E7F003.dip.t-dialin.net [217.231.240.3]) by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id h71FpkDD020976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Aug 2003 17:51:47 +0200 Received: (from thimm@localhost) by puariko.nirvana (8.12.8/8.12.8/Submit) id h71Fpj8f007298; Fri, 1 Aug 2003 17:51:45 +0200 Date: Fri, 1 Aug 2003 17:51:45 +0200 From: Axel Thimm To: linux-xfs@oss.sgi.com Subject: Re: XFS 1.3.0pre4 RPMS for Red Hat 7.3 Message-ID: <20030801155145.GB5729@puariko.nirvana> References: <4.3.2.7.2.20030801085547.0338ac60@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030801085547.0338ac60@pop.xs4all.nl> User-Agent: Mutt/1.4.1i X-archive-position: 4866 X-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 --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Aug 01, 2003 at 09:08:53AM +0200, Seth Mos wrote: > If you need the 1.2 rpms I suggest fetching the RPMS Axel Thimm made. Thanks for the reference, but I currently only have RH9 kernels officially at my site. While I've uploaded a src.rpm for RH8.0 which also builds fine on RH7.3, only the RH8.0 setup has been tested in the field (Thanks Rainer). Given the resources I have been offered for backporting some parts of atrpms to RH8.0 I might also start building kernels for RH < 9 again, when the next kernel upgrade is due (probably soon due to the lm_sensors 2.8.0 release). --=20 Axel.Thimm@physik.fu-berlin.de --3uo+9/B/ebqu+fSQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/KoyRQBVS1GOamfERAkIUAJ9GQ99xFJxpc7+Nvq/OFi283VmzHwCfTrmV 7W6hFFLiG+fP5tuJaG9PjnQ= =MK2O -----END PGP SIGNATURE----- --3uo+9/B/ebqu+fSQ-- From owner-linux-xfs@oss.sgi.com Fri Aug 1 08:54:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 08:54:47 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71FsgFl030535 for ; Fri, 1 Aug 2003 08:54:42 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h71Fsbq0001758 for ; Fri, 1 Aug 2003 08:54:37 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h71FraQK3952691; Fri, 1 Aug 2003 10:53:36 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h71FraRn201096243; Fri, 1 Aug 2003 10:53:36 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h71FraH27470; Fri, 1 Aug 2003 10:53:36 -0500 Subject: Re: pbd_delwrite_lock and pb_list in page_buf.c From: Steve Lord To: "Dale J. Stephenson" Cc: linux-xfs@oss.sgi.com In-Reply-To: <418AB2C2-C436-11D7-9EF1-0003937830E4@mac.com> References: <418AB2C2-C436-11D7-9EF1-0003937830E4@mac.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1059753216.7856.38.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 01 Aug 2003 10:53:36 -0500 X-archive-position: 4867 X-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-08-01 at 10:38, Dale J. Stephenson wrote: > I was looking at a misbehaving xfs_freeze command in an older version > of XFS and found myself stuck in the list_for_each_safe() loop in > pagebuf_delwri_flush. The head had apparently been removed from the > list in a case of spectacularly poor timing. I found that the list had > been protected by the pbd_delwrite_lock, but not everywhere. > > Checking the current CVS, I still see that the list is still not > protected everywhere. Examples: > > pagebuf_daemon, line 2083, calls list_del_init(&pb->pb_list) without > holding the lock. This is a temporary local queue, we moved the buffers off the global list prior to processing this list. The whole point of the list is so we can do sleeping things without going near the global list and its spinlock. > pagebuf_delwri_flush, line 2182, calls list_del_init(&pb->pb_list) > without holding the lock. Also a temporary list. > pagebuf_delwri_flush, lines 2151-2166, releases the lock inside a > list_for_each_safe loop. > This one is a little fishy, I think it needs to be doing the same logic as the daemon thread and pulling everything onto the temp list before it processes them. > I don't see any downside to putting locks around the list_del_init > calls. I'm not sure what to do with the last one. If it were changed > to list_for_each, would it survive the head getting taken away? I'm > assuming the lock cannot be held through __pagebuf_iorequest() or > pagebuf_run_queues() calls. It cannot - it is a spinlock, and we cannot sleep with it. Thanks Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Aug 1 08:57:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 08:58:00 -0700 (PDT) Received: from mee05.mee.com (mee05.mee.com [194.130.244.67]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71FvsFl031157 for ; Fri, 1 Aug 2003 08:57:55 -0700 Received: from meemgw02.mee.com (meemgw02.mee.com [10.226.1.24]) by mee05.mee.com (8.11.6/8.11.6) with ESMTP id h71FvnG79502 for ; Fri, 1 Aug 2003 16:57:49 +0100 (BST) Received: from meetvd02 (meetvd02.diamondlink.com [10.226.1.23]) by meemgw02.mee.com (8.11.6/8.11.6) with SMTP id h71FvmF25545 for ; Fri, 1 Aug 2003 16:57:48 +0100 (BST) Received: FROM x4.vil.ite.mee.com BY meetvd02 ; Fri Aug 01 16:45:18 2003 +0100 Received: from zebra.vil.ite.mee.com ([10.226.210.109]) by x4.vil.ite.mee.com with esmtp (Exim 3.13 #1) id 19icHl-0004Gp-00; Fri, 01 Aug 2003 16:57:41 +0100 Subject: Re: Nasty bug? From: Paul Furness To: Eric Sandeen Cc: Bogdan Costescu , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Mitsubishi Electric ITE BV VIL Message-Id: <1059753461.17049.15.camel@Zebra.vil.ite.mee.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 01 Aug 2003 16:57:41 +0100 Content-Transfer-Encoding: 7bit X-Scanner: exiscan *19icHl-0004Gp-00*YjvgIQgrZOA* (VIL, Mitsubishi Electric) X-archive-position: 4868 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: paul.furness@vil.ite.mee.com Precedence: bulk X-list: linux-xfs I'll try making lots of _very_ much smaller file systems (1G each) and see what happens. If it makes any difference, the existing file systems on there are of various sizes from 1G up to 350G, and all of them created and worked fine. The packages I collected in early March, and AFAICT they are the same versions that are still shown as the most recent stable ones, although it took me ages to find a working ftp server with them on this week when I tried to update them. The full list of what I have installed is: Kernel 2.4.20 (direct from kernel.org, not chopped up by RedHat) acl-2.2.4-0.i386.rpm attr-2.2.0-0.i386.rpm dmapi-2.0.5-0.i386.rpm dmapi-devel-2.0.5-0.i386.rpm libacl-2.2.4-0.i386.rpm libacl-devel-2.2.4-0.i386.rpm libattr-2.2.0-0.i386.rpm libattr-devel-2.2.0-0.i386.rpm xfs-2.4.20-all-i386 xfsdump-2.2.6-0.i386.rpm xfsprogs-2.3.9-0.i386.rpm xfsprogs-devel-2.3.9-0.i386.rpm I have got it scheduled to try the newer kernel (21) on there during tomorrow, but afaict the tools / kernel patch are still the most recent ones shown as stable on the ftp mirrors. I could be wrong though; I couldn't get a connection to the sgi ftp server last week to try and get an update. I don't _think_ it's lvm that is the problem, but just in case it matters, the version is 1.0.7 (can't get 2 to compile so sticking with 1 for now...) Paul. On Fri, 2003-08-01 at 16:39, Eric Sandeen wrote: > On Fri, 1 Aug 2003, Bogdan Costescu wrote: > > > The numbers are not sequential, but they are monotonically increasing :-) > > The difference between any 2 values is 8388608. Now if these are 512 byte > > sectors, this is exactly 4294967296 bytes which is 2^32... > > > > This won't help you directly... but might give somebody some idea :-) > > The maximum AG size is 4G, for a very large fliesystem. mkfs.xfs writes > allocation group headers at the start of each AG. > > howver, if this was split into small pieces & mkfs'd, then the AGs should > not be that large... hm. > > -Eric > > From owner-linux-xfs@oss.sgi.com Fri Aug 1 09:13:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 09:13:53 -0700 (PDT) Received: from mee05.mee.com (mee05.mee.com [194.130.244.67]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71GDkFl032634 for ; Fri, 1 Aug 2003 09:13:47 -0700 Received: from meemgw02.mee.com (meemgw02.mee.com [10.226.1.24]) by mee05.mee.com (8.11.6/8.11.6) with ESMTP id h71GDfG80279 for ; Fri, 1 Aug 2003 17:13:41 +0100 (BST) Received: from meetvd02 (meetvd02.diamondlink.com [10.226.1.23]) by meemgw02.mee.com (8.11.6/8.11.6) with SMTP id h71GDeF26262 for ; Fri, 1 Aug 2003 17:13:40 +0100 (BST) Received: FROM x4.vil.ite.mee.com BY meetvd02 ; Fri Aug 01 17:01:10 2003 +0100 Received: from zebra.vil.ite.mee.com ([10.226.210.109]) by x4.vil.ite.mee.com with esmtp (Exim 3.13 #1) id 19icX7-0004OU-00; Fri, 01 Aug 2003 17:13:33 +0100 Subject: Re: Nasty bug? From: Paul Furness To: Eric Sandeen Cc: Bogdan Costescu , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Mitsubishi Electric ITE BV VIL Message-Id: <1059754413.17150.10.camel@Zebra.vil.ite.mee.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 01 Aug 2003 17:13:33 +0100 Content-Transfer-Encoding: 7bit X-Scanner: exiscan *19icX7-0004OU-00*gkfodwSfaPc* (VIL, Mitsubishi Electric) X-archive-position: 4869 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: paul.furness@vil.ite.mee.com Precedence: bulk X-list: linux-xfs I tried some more things: I created a load of 1G lv's and did mkfs -t xfs on each one in turn. First few were fine, then the same problem came back again. Here's the tail of the syslog that's relevant: Aug 1 17:02:00 picard modprobe: modprobe: Can't locate module block-major-43 Aug 1 17:02:00 picard last message repeated 31 times Aug 1 17:02:00 picard kernel: I/O error: dev 08:00, sector 2789278336 Aug 1 17:02:19 picard kernel: I/O error: dev 08:00, sector 2784559747 Aug 1 17:02:19 picard kernel: I/O error: dev 08:00, sector 2784821891 Aug 1 17:02:19 picard kernel: I/O error: dev 08:00, sector 2784821891 Aug 1 17:02:19 picard kernel: I/O error: dev 08:00, sector 2785083904 Aug 1 17:02:19 picard kernel: I/O error: dev 08:00, sector 2784559744 Aug 1 17:02:19 picard kernel: I/O error: dev 08:00, sector 2784559752 Aug 1 17:02:19 picard kernel: Aug 1 17:05:11 picard kernel: I/O error: dev 08:00, sector 2785870467 Aug 1 17:05:11 picard kernel: I/O error: dev 08:00, sector 2786132611 Aug 1 17:05:11 picard kernel: I/O error: dev 08:00, sector 2786394755 Aug 1 17:05:11 picard kernel: I/O error: dev 08:00, sector 2786656899 Aug 1 17:05:11 picard kernel: I/O error: dev 08:00, sector 2786919043 Aug 1 17:05:11 picard kernel: I/O error: dev 08:00, sector 2786919043 Aug 1 17:05:12 picard kernel: I/O error: dev 08:00, sector 2785084032 Aug 1 17:05:12 picard kernel: I/O error: dev 08:00, sector 2786132640 Aug 1 17:05:12 picard kernel: I/O error: dev 08:00, sector 2786133664 Aug 1 17:05:12 picard kernel: I/O error: dev 08:00, sector 2786134688 Aug 1 17:05:12 picard kernel: I/O error: dev 08:00, sector 2786135712 Aug 1 17:05:12 picard kernel: I/O error: dev 08:00, sector 2786137760 I/O error: dev 08:00, sector 2784821888 Aug 1 17:02:19 picard kernel: I/O error: dev 08:00, sector 2784821896 Then, when I tried with any of the lv's created after that one, I get a load of the same error: Aug 1 17:05:11 picard kernel: I/O error: dev 08:00, sector 2785084032 Aug 1 17:05:11 picard kernel: I/O error: dev 08:00, sector 2785084032 Aug 1 17:05:11 picard kernel: I/O error: dev 08:00, sector 2785346179 Aug 1 17:05:11 picard kernel: I/O error: dev 08:00, sector 2785608323 ...and so on and so on. Oh, don't know if this helps, but the lvm PE size is set to 32MB (which I think is the default). I can't quite make this number do anything significant with the gaps between the errors - I mean, there are exactly 128 x 32 in 4096, but I'm not sure that helps... Paul. On Fri, 2003-08-01 at 16:39, Eric Sandeen wrote: > On Fri, 1 Aug 2003, Bogdan Costescu wrote: > > > The numbers are not sequential, but they are monotonically increasing :-) > > The difference between any 2 values is 8388608. Now if these are 512 byte > > sectors, this is exactly 4294967296 bytes which is 2^32... > > > > This won't help you directly... but might give somebody some idea :-) > > The maximum AG size is 4G, for a very large fliesystem. mkfs.xfs writes > allocation group headers at the start of each AG. > > howver, if this was split into small pieces & mkfs'd, then the AGs should > not be that large... hm. > > -Eric > > From owner-linux-xfs@oss.sgi.com Fri Aug 1 09:24:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 09:25:06 -0700 (PDT) Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71GOpFl001376 for ; Fri, 1 Aug 2003 09:24:51 -0700 Received: from kenzo.iwr.uni-heidelberg.de (IDENT:kHcfd7+lEm7IQFT/hTcLck8qco20VrT2@kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.12.9/8.12.9) with ESMTP id h71GOnru028059; Fri, 1 Aug 2003 18:24:50 +0200 (MET DST) Received: from kenzo.iwr.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by kenzo.iwr.uni-heidelberg.de (8.12.8/8.12.8) with ESMTP id h71GOn5K015240; Fri, 1 Aug 2003 18:24:49 +0200 Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.12.8/8.12.8/Submit) with ESMTP id h71GOnXq015236; Fri, 1 Aug 2003 18:24:49 +0200 Date: Fri, 1 Aug 2003 18:24:49 +0200 (CEST) From: Bogdan Costescu To: Paul Furness cc: linux-xfs@oss.sgi.com Subject: Re: Nasty bug? In-Reply-To: <1059754413.17150.10.camel@Zebra.vil.ite.mee.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4870 X-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 On 1 Aug 2003, Paul Furness wrote: > First few were fine, then the same problem came back again. This coupled with the fact that mkfs.ext2 worked fine (writes only in some places on the partition) suggest to me that there might be problems with the partition itself, either hardware or software (LVM). To check this I would suggest making again one big partition and try to read it with 'dd'; this will go through every (virtual) sector of the partition; 'badblocks' might also be used... -- 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 Aug 1 11:50:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 11:50:29 -0700 (PDT) Received: from mail.starkmedia.com (mail.starkmedia.com [63.237.54.130]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71IoMFl026768 for ; Fri, 1 Aug 2003 11:50:23 -0700 Received: from f2o.org (gateway3.starkmedia.com [63.237.54.129] (may be forged)) by mail.starkmedia.com (8.11.6/8.10.1) with ESMTP id h71Isg718743 for ; Fri, 1 Aug 2003 13:54:42 -0500 Message-ID: <3F2AB5D4.7010306@f2o.org> Date: Fri, 01 Aug 2003 13:47:48 -0500 From: "Daniel J. Cody" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Consistant oops on dual athlon boards Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4871 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: djc@f2o.org Precedence: bulk X-list: linux-xfs Hi All, Long time XFS user and mailing list lurker. Over the past few months, I've been able to consistantly crash XFS-enabled kernels with a 35Gb rsync(or any high disk I/O) to a dual AMD server. I'd have reported it earlier, but have been learning how to properly debug and troubleshoot the kernel, which I'm hopefully doing. Anyways, the most recent oops on 2.4.21 with pre4 of 1.3: --------- Unable to handle kernel paging request at virtual address 7461687b c01d3430 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010a83 eax: 00000000 ebx: dedf5640 ecx: 74616863 edx: 72757465 esi: c15aff18 edi: c15aff14 ebp: c15aff10 esp: c15afeec ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 5, stackpage=c15af000) Stack: c124e974 d44dae20 00003479 c03003d4 c01d35c5 c124e974 c15aff10 c15aff14 c15aff18 00000000 00000001 00000000 c124e974 000001d0 c013b611 c124e974 000001d0 00000000 c124e974 c0130c27 c124e974 000001d0 c15ae000 000001fc Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 51 18 89 d0 83 e0 11 48 74 25 f6 c6 10 74 12 c7 06 01 00 >>EIP; c01d3430 <===== Trace; c01d35c5 Trace; c013b611 Trace; c0130c27 Trace; c0130e61 Trace; c0130ed6 Trace; c0130ff4 Trace; c0131059 Trace; c013116d Trace; c01310e0 Trace; c0105000 <_stext+0/0> Trace; c010590b Trace; c01310e0 Code; c01d3430 00000000 <_EIP>: Code; c01d3430 <===== 0: 8b 51 18 mov 0x18(%ecx),%edx <===== Code; c01d3433 3: 89 d0 mov %edx,%eax Code; c01d3435 5: 83 e0 11 and $0x11,%eax Code; c01d3438 8: 48 dec %eax Code; c01d3439 9: 74 25 je 30 <_EIP+0x30> c01d3460 Code; c01d343b b: f6 c6 10 test $0x10,%dh Code; c01d343e e: 74 12 je 22 <_EIP+0x22> c01d3452 Code; c01d3440 10: c7 06 01 00 00 00 movl $0x1,(%esi) ---------- This issue similar to above started back in January with a Tyan Thunder K7X (S2468ugn) with 2.4.18 and XFS 1.2. I've tried every kernel release with every possible XFS release, and the situation remains. I've since replaced both CPU's, all the memory(and memtested the new stuff), and put in a new motherboard from a different mfg. (Asus dual amd) I've also been running 2.6.0-test1 and test2 with XFS enabled and am still able to get the kernel panic. When not under high load, the machine runs fine, and when I run a non-XFS kernel with an ext3 FS on the same hardware, everything works fine as well. I'd give more detail, and hopefully this is enough to get the ball rolling, but if I can provide more detail or info, or give any more oops reports from various kernels/xfs versions, let me know... Thanks for a great product! Dan http://five2one.org/ From owner-linux-xfs@oss.sgi.com Fri Aug 1 12:57:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Aug 2003 12:57:30 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71JvFFl007214 for ; Fri, 1 Aug 2003 12:57:16 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h71KGcsR007831 for ; Fri, 1 Aug 2003 15:16:38 -0500 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h71Jv9QK4041881 for ; Fri, 1 Aug 2003 14:57:09 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h71Jv8Yl16136174 for ; Fri, 1 Aug 2003 14:57:08 -0500 (CDT) Date: Fri, 1 Aug 2003 14:57:08 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: linux-xfs@oss.sgi.com Subject: New xfs userspace snapshots Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4872 X-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 Just realized that I had not updated the userspace snapshots for um... oh... about 6 months. Whoops! New stuff is there now, ftp://oss.sgi.com/projects/xfs/download/cmd_tars/ ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/ for you bleeding-edge types. -Eric From owner-linux-xfs@oss.sgi.com Sat Aug 2 01:29:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 02 Aug 2003 01:30:19 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h728TdFl021374 for ; Sat, 2 Aug 2003 01:29:39 -0700 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id h728TWI28928 for ; Sat, 2 Aug 2003 01:29:32 -0700 Date: Sat, 2 Aug 2003 01:30:32 -0700 From: Andrew Morton To: linux-xfs@oss.sgi.com Subject: use-after-free in xfs_bawrite() Message-Id: <20030802013032.7a42a596.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.4 (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: 4873 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: linux-xfs Using Linus's current tree plus all the -mm gunk I get a fairly easy oops running dbench on XFS on SMP with CONFIG_DEBUG_PAGEALLOC=y: Program received signal SIGEMT, Emulation trap. 0xc0282c9d in xfs_iflush (ip=0xc284a004, flags=2) at fs/xfs/pagebuf/page_buf.h:397 397 if (!pb || atomic_read(&pb->pb_io_remaining)) (gdb) p pb $1 = (page_buf_t *) 0xc98d1004 (gdb) p *pb Cannot access memory at address 0xc98d1004 (gdb) bt #0 0xc0282c9d in xfs_iflush (ip=0xc284a004, flags=2) at fs/xfs/pagebuf/page_buf.h:397 #1 0xc0283dee in xfs_inode_item_push (iip=0xc2849004) at fs/xfs/xfs_inode_item.c:882 #2 0xc0294ddf in xfs_trans_push_ail (mp=0xceb87004, threshold_lsn=21474846993) at fs/xfs/xfs_trans_ail.c:170 #3 0xc0287622 in xlog_grant_push_ail (mp=0xceb87004, need_bytes=492072) at fs/xfs/xfs_log.c:1390 #4 0xc028652c in xfs_log_reserve (mp=0xceb87004, unit_bytes=157880, cnt=3, ticket=0xc9451038, client=105, flags=2) at fs/xfs/xfs_log.c:461 #5 0xc0293afd in xfs_trans_reserve (tp=0xc9451004, blocks=41, logspace=157880, rtextents=0, flags=4, logcount=3) at fs/xfs/xfs_trans.c:275 #6 0xc029c340 in xfs_mkdir (dir_bdp=0xc0c3e024, dentry=0xca964004, vap=0xc790fec4, vpp=0xc790fec0, credp=0x0) at fs/xfs/xfs_vnodeops.c:2878 #7 0xc02a687c in linvfs_mknod (dir=0xc0c3f024, dentry=0xca964004, mode=16832, rdev=0) at fs/xfs/linux/xfs_iops.c:136 #8 0xc02a6a4f in linvfs_mkdir (dir=0xc0c3f024, dentry=0xca964004, mode=448) at fs/xfs/linux/xfs_iops.c:190 #9 0xc016d838 in vfs_mkdir (dir=0xc0c3f024, dentry=0xca964004, mode=448) at fs/namei.c:1510 #10 0xc016d901 in sys_mkdir (pathname=0xbffff2e7 "CLIENTS/CLIENT16/~DMTMP/SEED", mode=448) at fs/namei.c:1537 The memory at 0xc98d1004 has been unmapped. The oops is on the xfs_iflush() -> xfs_bawrite() -> pagebuf_run_queues() path. It looks to me like pagebuf_iostart() has called pagebuf_iorequest() which called _pagebuf_iodone() which called pagebuf_iodone() whuich threw away the pagebuf. If this is vaguely correct then this part of pagebuf_iostart(): /* Wait for I/O if we are not an async request */ if ((status == 0) && (flags & PBF_ASYNC) == 0) { also needs attention... The below quick patch fixes it up. But it also causes zillions of dentries and inodes to be leaked for some reason. Consider it a technology demonstration! XFS has waaaaay too much inlining btw ;) Seems that dbench is not XFS's favourite benchmark. How come? Do I need more logbufs? fs/xfs/xfs_buf.h | 2 ++ 1 files changed, 2 insertions(+) diff -puN fs/xfs/xfs_buf.h~a fs/xfs/xfs_buf.h --- 25/fs/xfs/xfs_buf.h~a 2003-08-02 00:53:59.000000000 -0700 +++ 25-akpm/fs/xfs/xfs_buf.h 2003-08-02 00:56:03.000000000 -0700 @@ -220,8 +220,10 @@ static inline int xfs_bawrite(void *mp, bp->pb_fspriv3 = mp; bp->pb_strat = xfs_bdstrat_cb; xfs_buf_undelay(bp); + atomic_inc(&bp->pb_hold); if ((ret = pagebuf_iostart(bp, PBF_WRITE | PBF_ASYNC)) == 0) pagebuf_run_queues(bp); + pagebuf_rele(bp); return ret; } _ From owner-linux-xfs@oss.sgi.com Sat Aug 2 04:55:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 02 Aug 2003 04:55:25 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h72Bt5Fl002673 for ; Sat, 2 Aug 2003 04:55:06 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 7CB8F14832; Sat, 2 Aug 2003 13:54:59 +0200 (MEST) Date: Sat, 2 Aug 2003 13:54:58 +0200 From: Andi Kleen To: Andrew Morton Cc: linux-xfs@oss.sgi.com Subject: Re: use-after-free in xfs_bawrite() Message-ID: <20030802115458.GA21440@wotan.suse.de> References: <20030802013032.7a42a596.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030802013032.7a42a596.akpm@osdl.org> X-archive-position: 4874 X-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 On Sat, Aug 02, 2003 at 01:30:32AM -0700, Andrew Morton wrote: > > XFS has waaaaay too much inlining btw ;) Really? The core code (outside linux/, pagebuf/) only has a single inline. linux/ has four. pagebuf/ has three. quota/ has four. support/* some more similar to the original linux functions. That looks hardly excessive for a ~120kLOC codebase. > > Seems that dbench is not XFS's favourite benchmark. How come? Do I need > more logbufs? And bigger on disk log than by default. There is a patch in the queue to do the first, but I think it hasn't reached Linus' tree yet. [Actually the hard limit 8 logbufs could be raised to more now] --- linux/fs/xfs/xfs_log.c-o 2003-06-10 14:27:57.000000000 +0200 +++ linux/fs/xfs/xfs_log.c 2003-06-11 11:29:55.000000000 +0200 @@ -1072,9 +1072,15 @@ * This is the normal path. If m_logbufs == -1, then the * admin has chosen to use the system defaults for logbuffers. */ - if (mp->m_logbufs == -1) - log->l_iclog_bufs = XLOG_NUM_ICLOGS; - else + if (mp->m_logbufs == -1) { + if (xfs_physmem <= btoc(128*1024*1024)) { + log->l_iclog_bufs = 3; + } else if (xfs_physmem <= btoc(400*1024*1024)) { + log->l_iclog_bufs = 5; + } else { + log->l_iclog_bufs = 8; /* 256K with 32K bufs */ + } + } else log->l_iclog_bufs = mp->m_logbufs; #if defined(DEBUG) || defined(XLOG_NOLOG) -Andi From owner-linux-xfs@oss.sgi.com Sat Aug 2 05:06:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 02 Aug 2003 05:06:51 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h72C6PFl004021 for ; Sat, 2 Aug 2003 05:06:26 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 9932514C10; Sat, 2 Aug 2003 14:06:20 +0200 (MEST) Date: Sat, 2 Aug 2003 14:06:20 +0200 From: Andi Kleen To: Andi Kleen Cc: Andrew Morton , linux-xfs@oss.sgi.com Subject: Re: use-after-free in xfs_bawrite() Message-ID: <20030802120620.GC21440@wotan.suse.de> References: <20030802013032.7a42a596.akpm@osdl.org> <20030802115458.GA21440@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030802115458.GA21440@wotan.suse.de> X-archive-position: 4875 X-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 On Sat, Aug 02, 2003 at 01:54:58PM +0200, Andi Kleen wrote: > > And bigger on disk log than by default. There is a patch in the queue to do > the first, but I think it hasn't reached Linus' tree yet. I just checked and the patch seems to be already in BK head. So you probably only need a bigger log if you use a recent linus- patch. Newer xfsutils will automatically create one. -Andi From owner-linux-xfs@oss.sgi.com Sat Aug 2 05:08:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 02 Aug 2003 05:08:31 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h72C8PFl004556 for ; Sat, 2 Aug 2003 05:08:26 -0700 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id h72C8HI01318; Sat, 2 Aug 2003 05:08:17 -0700 Date: Sat, 2 Aug 2003 05:09:19 -0700 From: Andrew Morton To: Andi Kleen Cc: linux-xfs@oss.sgi.com Subject: Re: use-after-free in xfs_bawrite() Message-Id: <20030802050919.2c43cd6f.akpm@osdl.org> In-Reply-To: <20030802115458.GA21440@wotan.suse.de> References: <20030802013032.7a42a596.akpm@osdl.org> <20030802115458.GA21440@wotan.suse.de> X-Mailer: Sylpheed version 0.9.4 (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: 4876 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: linux-xfs Andi Kleen wrote: > > On Sat, Aug 02, 2003 at 01:30:32AM -0700, Andrew Morton wrote: > > > > XFS has waaaaay too much inlining btw ;) > > Really? > > The core code (outside linux/, pagebuf/) only has a single inline. > linux/ has four. > pagebuf/ has three. > quota/ has four. > support/* some more similar to the original linux functions. hm, OK, well the code I looked at tonight had too many anyway. xfs_bawrite(), xfs_buf_undelay() and _pagebuf_iodone(). Guess I got lucky. > > Seems that dbench is not XFS's favourite benchmark. How come? Do I need > > more logbufs? > > And bigger on disk log than by default. There is a patch in the queue to do > the first, but I think it hasn't reached Linus' tree yet. > Your patch has been merged, and is in the tree I tested. From owner-linux-xfs@oss.sgi.com Sat Aug 2 05:15:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 02 Aug 2003 05:15:52 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h72CFnFl005343 for ; Sat, 2 Aug 2003 05:15:50 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 1D68E14EFD; Sat, 2 Aug 2003 14:15:44 +0200 (MEST) Date: Sat, 2 Aug 2003 14:15:43 +0200 From: Andi Kleen To: Andrew Morton Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: use-after-free in xfs_bawrite() Message-ID: <20030802121543.GD21440@wotan.suse.de> References: <20030802013032.7a42a596.akpm@osdl.org> <20030802115458.GA21440@wotan.suse.de> <20030802050919.2c43cd6f.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030802050919.2c43cd6f.akpm@osdl.org> X-archive-position: 4877 X-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 > > > Seems that dbench is not XFS's favourite benchmark. How come? Do I need > > > more logbufs? > > > > And bigger on disk log than by default. There is a patch in the queue to do > > the first, but I think it hasn't reached Linus' tree yet. > > > > Your patch has been merged, and is in the tree I tested. I would still increase the on disk log size. The old defaults are showing their age. -andi From owner-linux-xfs@oss.sgi.com Sun Aug 3 16:50:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 03 Aug 2003 16:50:23 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73No4Fl004724 for ; Sun, 3 Aug 2003 16:50:05 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7409XsR029399 for ; Sun, 3 Aug 2003 19:09:34 -0500 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 h73Nnw1S019665; Mon, 4 Aug 2003 09:49:58 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h73NnuxG019676; Mon, 4 Aug 2003 09:49:56 +1000 (EST) Date: Mon, 4 Aug 2003 09:49:56 +1000 (EST) From: Nathan Scott Message-Id: <200308032349.h73NnuxG019676@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, agruen@suse.de Subject: TAKE - acl/attr fixes X-archive-position: 4878 X-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 Fix up quote/unquote routines to handle NULL as input, fixes SEGVs in several ACL tools when running xfstests. Date: Sun Aug 3 16:48:33 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-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:154899a cmd/acl/VERSION - 1.53 cmd/acl/doc/CHANGES - 1.61 cmd/acl/chacl/chacl.c - 1.19 cmd/acl/debian/changelog - 1.47 cmd/attr/VERSION - 1.37 cmd/attr/doc/CHANGES - 1.46 cmd/attr/debian/changelog - 1.40 cmd/attr/libmisc/unquote.c - 1.3 cmd/attr/libmisc/quote.c - 1.3 cmd/acl/libmisc/unquote.c - 1.3 cmd/acl/libmisc/quote.c - 1.3 From owner-linux-xfs@oss.sgi.com Sun Aug 3 23:29:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 03 Aug 2003 23:31:12 -0700 (PDT) Received: from malik.acsalaska.net (malik.acsalaska.net [209.112.155.41]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h746TvFl004918 for ; Sun, 3 Aug 2003 23:29:59 -0700 Received: from erbenson.alaska.net (19-pm5.nwc.alaska.net [209.112.139.19]) by malik.acsalaska.net (8.12.9/8.12.9) with ESMTP id h746Tq25022819 for ; Sun, 3 Aug 2003 22:29:52 -0800 (AKDT) (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 6583439E7 for ; Sun, 3 Aug 2003 22:29:51 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 0484540FF44; Sun, 3 Aug 2003 22:29:50 -0800 (AKDT) Date: Sun, 3 Aug 2003 22:29:50 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: [PATCH] Implement immutable/append-only flags in XFS #4 Message-ID: <20030804062950.GA3132@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="dc+cDN39EJAMEtIO" 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.34 X-archive-position: 4879 X-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 --dc+cDN39EJAMEtIO Content-Type: multipart/mixed; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, [fourth revision: only changes is to propagate the sync bit to new regular files and directories when the parent directory has the sync bit set, and to update to current 2.4.21 CVS] Over time there has been many requests for ext2 file flags such as immutable, append-only, sync, noatime be implemented in XFS. So, here it is. I have implemented all of the above flags in 2.4.21 CVS. The patch is relatively small and non-invasive, and from my testing appears to cause no backwards compatibility issues (older kernels ignore, and leave alone the new flags). Also xfs_repair and xfs_check do not seem to have any problems with the new flags either. If any XFS users would like to try this patch and report on it please do. My testing indicates its stable and will cause no problems except as discussed below with xfsdump. However during my testing I did discover 3 issues: 1: The Linux VFS contains a bug which allows timestamp modification of immutable/append-only files. I have fixed this issue, and will send the patch to the linux-kernel mailing list shortly. I have included that patch in this mail for completeness. 2: xfsrestore breaks when immutable or append-only files are included in the dump. The problem is xfsrestore restores the file inode flags too soon, and then loses the access it needs to restore extended attributes, uid, gid, and permissions. I am not familiar enough with xfsrestore to really propose the fix, however i believe just changing it to restore at the very least immutable/append-only flags very last after all other restoration is complete should suffice to solve this problem. 3: I just found an undocumented behavior with regards to ext2's file flags; when set on a directory any new file/dir created will inherit the flags of the parent directory. I am not entirely convinced this is a good idea, at least for *all* flags. In ext2 this behavior has been half broken for as near as i can tell, forever up to 2.4.20 (2.4.21 fixes it), the brokenness is that the vfs is not immediately informed of any of the flags except sync, thus they don't actually go into affect on new files until the inode is revalidated (which could take quite some time). In addition ext2 only refrains from doing this on symlinks, not device special files; this means if you create a device node in a append-only directory the only way you will ever be able to remove it is with debugfs. (ioctl() calls on a device file go to the driver handling the node, not to the filesystem holding the node, thus chattr won't help you). My question on #3 is whether we want this behavior in XFS? my current patch implements it only for the sync bit, and only to regular files and directories. My opinion is that the only flag this really makes sense for is sync, since setting the sync flag on a directory does not actually do anything for you (it only affects files), so making all new files created under a sync directory is seemingly sensible (and probably what the user would expect, more or less). this might make sense for noatime too, but I am less convinced of this. I am definitely not convinced its a sensible idea for append-only since it ends up allowing non-privileged users to create append-only files, which is not normally permitted. Also automatically setting the append-only flag on a newly created file won't necessarily make it append-only immediately, since a caller doing open("append-only-dir/file" O_RDWR|O_CREAT) will retain full read/write access so long as the file descriptor is kept open (the same is true if you chmod() a file, open descriptors retain access even if they could not get it on a new open()). So for now I submit the patch without the ext2 inheritance behavior (except for sync to IFREG and IFDIR), if you believe we should implement the ext2 behavior either partially, or fully I should be able to do that. I have also implemented the EXT2_IOC_SETFLAGS/EXT2_IOC_GETFLAGS ioctl()s so chattr/lsattr will work on xfs, this part of the patch is optional, if excluded then either lsattr/chattr would need to be modified to use XFS_IOC_FSSETXATTR and XFS_IOC_FSGETXATTR ioctls. I have a (somewhat hideous) test program to check as many things as i could think of to ensure immutable/append-only are properly enforced, the only thing lacking in it is tests of all the XFS ioctls, perhaps someone familiar with xfs ioctls could add these, currently the libhandle open/write tests are done. You can find this test program at http://penguinppc.org/~eb/t_immutable.c Important: this test program creates a test area with full world read/write permissions to ensure regular file permissions are not tainting the test, therefore it is NOT SAFE to run on systems with untrusted users. the usage is t_immutable -c /some/dir which will create a test area as /some/dir and run tests in it. t_immutable -C will create the test area without running any tests, and t_immutable -r will remove a test area. t_immutable /some/dir will run the tests on a previously created test area. Note if you run t_immutable on an ext2 filesystem in 2.4.21 kernels you will need to use debugfs to get rid of the device node it creates (same on kernels prior to 2.4.21 if you leave the test area around long enough). see above for why. Also note that there is currently a bug in the XFS handle code, if you run my test program, then use it to delete the test-area you will get minor filesystem corruption on umount. feedback is welcome. diffstat output follows: linux/xfs_ext2_ioctl.h | 45 ++++++++++++++++++++++ linux/xfs_ioctl.c | 100 ++++++++++++++++++++++++++++++++++++++++++++= +++++ linux/xfs_iops.c | 6 ++ linux/xfs_super.c | 16 +++++++ linux/xfs_vnode.c | 17 ++++++++ xfs_acl.c | 2 xfs_cap.c | 2 xfs_dinode.h | 24 ++++++++--- xfs_fs.h | 7 ++- xfs_inode.c | 7 ++- xfs_itable.c | 8 +++ xfs_vnodeops.c | 16 +++++++ 12 files changed, 241 insertions(+), 9 deletions(-) --=20 Ethan Benson http://www.alaska.net/~erbenson/ --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfs-xflags.diff" Content-Transfer-Encoding: quoted-printable diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_ext2_ioctl.h linu= x-2.4-xfs/linux/fs/xfs/linux/xfs_ext2_ioctl.h --- linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_ext2_ioctl.h Wed Dec 31 14:00= :00 1969 +++ linux-2.4-xfs/linux/fs/xfs/linux/xfs_ext2_ioctl.h Mon Jul 21 15:57:33 2= 003 @@ -0,0 +1,45 @@ +/* + * Copyright (c) 2003 Silicon Graphics, Inc. All Rights Reserved. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of version 2 of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + * + * Further, this software is distributed without any warranty that it is + * free of the rightful claim of any third person regarding infringement + * or the like. Any license provided herein, whether implied or + * otherwise, applies only to this software file. Patent licenses, if + * any, provided herein do not apply to combinations of this program with + * other software, or any other product whatsoever. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write the Free Software Foundation, Inc., 59 + * Temple Place - Suite 330, Boston MA 02111-1307, USA. + * + * Contact information: Silicon Graphics, Inc., 1600 Amphitheatre Pkwy, + * Mountain View, CA 94043, or: + * + * http://www.sgi.com + * + * For further information regarding this notice, see: + * + * http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/ + */ +#ifndef __XFS_EXT2_IOCTL_H__ +#define __XFS_EXT2_IOCTL_H__ + +/* ext2 ioctls (EXT2_IOC_GETFLAGS and EXT2_IOC_SETFLAGS) to support + * chattr/lsattr */ +#define XFS_IOC_EXT2_GETFLAGS _IOR('f', 1, long) +#define XFS_IOC_EXT2_SETFLAGS _IOW('f', 2, long) + +#define EXT2_FLAG_SYNC 0x00000008 /* Synchronous upda= tes */ +#define EXT2_FLAG_IMMUTABLE 0x00000010 /* Immutable file */ +#define EXT2_FLAG_APPEND 0x00000020 /* writes to file m= ay only append */ +#define EXT2_FLAG_NOATIME 0x00000080 /* do not update at= ime */ + +#endif /* __XFS_EXT2_IOCTL_H__ */ diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_ioctl.c linux-2.4= -xfs/linux/fs/xfs/linux/xfs_ioctl.c --- linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_ioctl.c Mon Jul 21 15:12:50 2= 003 +++ linux-2.4-xfs/linux/fs/xfs/linux/xfs_ioctl.c Mon Jul 21 15:19:13 2003 @@ -66,6 +66,7 @@ #include "xfs_utils.h" #include "xfs_dfrag.h" #include "xfs_fsops.h" +#include "xfs_ext2_ioctl.h" =20 #include #include @@ -327,6 +328,13 @@ if (permflag & O_TRUNC) permflag |=3D 2; =20 + if ((!(permflag & O_APPEND) || (permflag & O_TRUNC)) && + (permflag & FMODE_WRITE) && IS_APPEND(inode)) + return -XFS_ERROR(EPERM); + + if ((permflag & FMODE_WRITE) && IS_IMMUTABLE(inode)) + return -XFS_ERROR(EACCES); + /* Can't write directories. */ if ( S_ISDIR(inode->i_mode) && (permflag & FMODE_WRITE)) { iput(inode); @@ -447,6 +455,9 @@ if (error) return -error; =20 + if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) + return -XFS_ERROR(EPERM); + if (copy_from_user(&fsd, dmhreq.data, sizeof(fsd))) { VN_RELE(vp); return -XFS_ERROR(EFAULT); @@ -532,11 +543,21 @@ NULL, ops[i].am_error); break; case ATTR_OP_SET: + if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) { + kfree(ops); + VN_RELE(vp); + return -XFS_ERROR(EPERM); + } VOP_ATTR_SET(vp,ops[i].am_attrname, ops[i].am_attrvalue, ops[i].am_length, ops[i].am_flags, NULL, ops[i].am_error); break; case ATTR_OP_REMOVE: + if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) { + kfree(ops); + VN_RELE(vp); + return -XFS_ERROR(EPERM); + } VOP_ATTR_REMOVE(vp, ops[i].am_attrname, ops[i].am_flags, NULL, ops[i].am_error); break; @@ -842,6 +863,75 @@ error =3D xfs_errortag_clearall(mp); return -error; =20 + case XFS_IOC_EXT2_GETFLAGS: { + unsigned int flags =3D 0; + + if (vp->v_inode.i_flags & S_IMMUTABLE) + flags |=3D EXT2_FLAG_IMMUTABLE; /* EXT2_IMMUTABLE_FL */ + if (vp->v_inode.i_flags & S_APPEND) + flags |=3D EXT2_FLAG_APPEND; /* EXT2_APPEND_FL */ + if (vp->v_inode.i_flags & S_SYNC) + flags |=3D EXT2_FLAG_SYNC; /* EXT2_SYNC_FL */ + if (vp->v_inode.i_flags & S_NOATIME) + flags |=3D EXT2_FLAG_NOATIME; /* EXT2_NOATIME_FL */ + + if (copy_to_user((unsigned int *)arg, &flags, sizeof(flags))) + return -XFS_ERROR(EFAULT); + return 0; + } + + case XFS_IOC_EXT2_SETFLAGS: { + vattr_t va; + unsigned int flags; + int attr_flags =3D 0; + + if (copy_from_user(&flags, (unsigned int *)arg, sizeof(flags))) + return -XFS_ERROR(EFAULT); +=09=09=20=20=20=20 + /* we need to do getattr to preserve XFS xflags ext2 + * has no knowledge of */ + + va.va_mask =3D XFS_AT_XFLAGS; + VOP_GETATTR(vp, &va, 0, NULL, error); + if (error) + return -error; + + if (flags & (EXT2_FLAG_IMMUTABLE|EXT2_FLAG_APPEND) || + va.va_xflags & (XFS_XFLAG_IMMUTABLE|XFS_XFLAG_APPEND)) + if (!capable(CAP_LINUX_IMMUTABLE)) + return -XFS_ERROR(EPERM); + + /* don't silently ignore unsupported ext2 flags */ + if (flags & ~(EXT2_FLAG_IMMUTABLE|EXT2_FLAG_APPEND| + EXT2_FLAG_SYNC|EXT2_FLAG_NOATIME)) + return -XFS_ERROR(EOPNOTSUPP); + + if (flags & EXT2_FLAG_IMMUTABLE) /* EXT2_IMMUTABLE_FL */ + va.va_xflags |=3D XFS_XFLAG_IMMUTABLE; + else + va.va_xflags &=3D ~XFS_XFLAG_IMMUTABLE; + if (flags & EXT2_FLAG_APPEND) /* EXT2_APPEND_FL */ + va.va_xflags |=3D XFS_XFLAG_APPEND; + else + va.va_xflags &=3D ~XFS_XFLAG_APPEND; + if (flags & EXT2_FLAG_SYNC) /* EXT2_SYNC_FL */ + va.va_xflags |=3D XFS_XFLAG_SYNC; + else + va.va_xflags &=3D ~XFS_XFLAG_SYNC; + if (flags & EXT2_FLAG_NOATIME) /* EXT2_NOATIME_FL */ + va.va_xflags |=3D XFS_XFLAG_NOATIME; + else + va.va_xflags &=3D ~XFS_XFLAG_NOATIME; + + if (filp->f_flags & (O_NDELAY|O_NONBLOCK)) + attr_flags |=3D ATTR_NONBLOCK; + + VOP_SETATTR(vp, &va, attr_flags, NULL, error); + if (!error) + vn_revalidate(vp); /* push immutable/append flags into vfs inode */ + return -error; + } + default: return -ENOTTY; } @@ -859,6 +949,9 @@ int attr_flags =3D 0; int error; =20 + if (vp->v_inode.i_flags & (S_IMMUTABLE|S_APPEND)) + return -XFS_ERROR(EPERM); + if (filp->f_flags & O_RDONLY) return -XFS_ERROR(EBADF); =20 @@ -1012,6 +1105,11 @@ if (copy_from_user(&fa, (struct fsxattr *)arg, sizeof(fa))) return -XFS_ERROR(EFAULT); =20 + if (fa.fsx_xflags & (XFS_XFLAG_IMMUTABLE|XFS_XFLAG_APPEND) || + va.va_xflags & (XFS_XFLAG_IMMUTABLE|XFS_XFLAG_APPEND)) + if (!capable(CAP_LINUX_IMMUTABLE)) + return -XFS_ERROR(EPERM); + va.va_mask =3D XFS_AT_XFLAGS | XFS_AT_EXTSIZE; va.va_xflags =3D fa.fsx_xflags; va.va_extsize =3D fa.fsx_extsize; @@ -1020,6 +1118,8 @@ attr_flags |=3D ATTR_NONBLOCK; =20 VOP_SETATTR(vp, &va, attr_flags, NULL, error); + if (!error) + vn_revalidate(vp); /* push immutable/append flags into vfs inode */ return -error; } =20 diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_iops.c linux-2.4-= xfs/linux/fs/xfs/linux/xfs_iops.c --- linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_iops.c Mon Jul 21 15:12:55 20= 03 +++ linux-2.4-xfs/linux/fs/xfs/linux/xfs_iops.c Mon Jul 21 15:19:13 2003 @@ -617,6 +617,9 @@ return error; } =20 + if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) + return -EPERM; + /* Convert Linux syscall to XFS internal ATTR flags */ if (flags & XATTR_CREATE) xflags |=3D ATTR_CREATE; @@ -766,6 +769,9 @@ error =3D xfs_cap_vremove(vp); return error; } + + if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) + return -EPERM; =20 if (strncmp(name, xfs_namespaces[ROOT_NAMES].name, xfs_namespaces[ROOT_NAMES].namelen) =3D=3D 0) { diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_super.c linux-2.4= -xfs/linux/fs/xfs/linux/xfs_super.c --- linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_super.c Mon Jul 21 15:13:02 2= 003 +++ linux-2.4-xfs/linux/fs/xfs/linux/xfs_super.c Mon Jul 21 15:19:13 2003 @@ -181,6 +181,22 @@ inode->i_atime =3D ip->i_d.di_atime.t_sec; inode->i_mtime =3D ip->i_d.di_mtime.t_sec; inode->i_ctime =3D ip->i_d.di_ctime.t_sec; + if (ip->i_d.di_flags & XFS_DIFLAG_IMMUTABLE) + inode->i_flags |=3D S_IMMUTABLE; + else + inode->i_flags &=3D ~S_IMMUTABLE; + if (ip->i_d.di_flags & XFS_DIFLAG_APPEND) + inode->i_flags |=3D S_APPEND; + else + inode->i_flags &=3D ~S_APPEND; + if (ip->i_d.di_flags & XFS_DIFLAG_SYNC) + inode->i_flags |=3D S_SYNC; + else + inode->i_flags &=3D ~S_SYNC; + if (ip->i_d.di_flags & XFS_DIFLAG_NOATIME) + inode->i_flags |=3D S_NOATIME; + else + inode->i_flags &=3D ~S_NOATIME; =20 vp->v_flag &=3D ~VMODIFIED; } diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_vnode.c linux-2.4= -xfs/linux/fs/xfs/linux/xfs_vnode.c --- linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_vnode.c Mon Jul 21 15:13:07 2= 003 +++ linux-2.4-xfs/linux/fs/xfs/linux/xfs_vnode.c Mon Jul 21 15:19:13 2003 @@ -224,6 +224,23 @@ inode->i_mtime =3D va.va_mtime.tv_sec; inode->i_ctime =3D va.va_ctime.tv_sec; inode->i_atime =3D va.va_atime.tv_sec; + if (va.va_xflags & XFS_XFLAG_IMMUTABLE) + inode->i_flags |=3D S_IMMUTABLE; + else + inode->i_flags &=3D ~S_IMMUTABLE; + if (va.va_xflags & XFS_XFLAG_APPEND) + inode->i_flags |=3D S_APPEND; + else + inode->i_flags &=3D ~S_APPEND; + if (va.va_xflags & XFS_XFLAG_SYNC) + inode->i_flags |=3D S_SYNC; + else + inode->i_flags &=3D ~S_SYNC; + if (va.va_xflags & XFS_XFLAG_NOATIME) + inode->i_flags |=3D S_NOATIME; + else + inode->i_flags &=3D ~S_NOATIME; + VUNMODIFY(vp); } return -error; diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_acl.c linux-2.4-xfs/lin= ux/fs/xfs/xfs_acl.c --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_acl.c Mon Jul 21 15:06:54 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_acl.c Mon Jul 21 15:19:13 2003 @@ -388,6 +388,8 @@ vattr_t va; int error; =20 + if (vp->v_inode.i_flags & (S_IMMUTABLE|S_APPEND)) + return EPERM; if (kind =3D=3D _ACL_TYPE_DEFAULT && vp->v_type !=3D VDIR) return ENOTDIR; if (vp->v_vfsp->vfs_flag & VFS_RDONLY) diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_cap.c linux-2.4-xfs/lin= ux/fs/xfs/xfs_cap.c --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_cap.c Mon Jul 21 15:08:15 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_cap.c Mon Jul 21 15:19:13 2003 @@ -192,6 +192,8 @@ =20 if (vp->v_vfsp->vfs_flag & VFS_RDONLY) return EROFS; + if (vp->v_inode.i_flags & (S_IMMUTABLE|S_APPEND)) + return EPERM; if ((error =3D _MAC_VACCESS(vp, NULL, VWRITE))) return error; va.va_mask =3D XFS_AT_UID; diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_dinode.h linux-2.4-xfs/= linux/fs/xfs/xfs_dinode.h --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_dinode.h Mon Jul 21 15:08:29 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_dinode.h Mon Jul 21 15:19:13 2003 @@ -468,13 +468,23 @@ * There should be a one-to-one correspondence between these flags and the * XFS_XFLAG_s. */ -#define XFS_DIFLAG_REALTIME_BIT 0 /* file's blocks come from rt area */ -#define XFS_DIFLAG_PREALLOC_BIT 1 /* file space has been preallocated */ -#define XFS_DIFLAG_NEWRTBM_BIT 2 /* for rtbitmap inode, new format */ -#define XFS_DIFLAG_REALTIME (1 << XFS_DIFLAG_REALTIME_BIT) -#define XFS_DIFLAG_PREALLOC (1 << XFS_DIFLAG_PREALLOC_BIT) -#define XFS_DIFLAG_NEWRTBM (1 << XFS_DIFLAG_NEWRTBM_BIT) +#define XFS_DIFLAG_REALTIME_BIT 0 /* file's blocks come from rt area */ +#define XFS_DIFLAG_PREALLOC_BIT 1 /* file space has been preallocated */ +#define XFS_DIFLAG_NEWRTBM_BIT 2 /* for rtbitmap inode, new format */ +#define XFS_DIFLAG_IMMUTABLE_BIT 3 /* inode is immutable */ +#define XFS_DIFLAG_APPEND_BIT 4 /* inode is append-only */ +#define XFS_DIFLAG_SYNC_BIT 5 /* inode is written synchronously */ +#define XFS_DIFLAG_NOATIME_BIT 6 /* do not update atime */ +#define XFS_DIFLAG_REALTIME (1 << XFS_DIFLAG_REALTIME_BIT) +#define XFS_DIFLAG_PREALLOC (1 << XFS_DIFLAG_PREALLOC_BIT) +#define XFS_DIFLAG_NEWRTBM (1 << XFS_DIFLAG_NEWRTBM_BIT) +#define XFS_DIFLAG_IMMUTABLE (1 << XFS_DIFLAG_IMMUTABLE_BIT) +#define XFS_DIFLAG_APPEND (1 << XFS_DIFLAG_APPEND_BIT) +#define XFS_DIFLAG_SYNC (1 << XFS_DIFLAG_SYNC_BIT) +#define XFS_DIFLAG_NOATIME (1 << XFS_DIFLAG_NOATIME_BIT) #define XFS_DIFLAG_ALL \ - (XFS_DIFLAG_REALTIME|XFS_DIFLAG_PREALLOC|XFS_DIFLAG_NEWRTBM) + (XFS_DIFLAG_REALTIME|XFS_DIFLAG_PREALLOC|XFS_DIFLAG_NEWRTBM| \ + XFS_DIFLAG_IMMUTABLE|XFS_DIFLAG_APPEND|XFS_DIFLAG_SYNC| \ + XFS_DIFLAG_NOATIME) =20 #endif /* __XFS_DINODE_H__ */ diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_fs.h linux-2.4-xfs/linu= x/fs/xfs/xfs_fs.h --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_fs.h Mon Jul 21 15:09:27 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_fs.h Mon Jul 21 15:19:13 2003 @@ -71,9 +71,14 @@ */ #define XFS_XFLAG_REALTIME 0x00000001 #define XFS_XFLAG_PREALLOC 0x00000002 +#define XFS_XFLAG_IMMUTABLE 0x00000008 +#define XFS_XFLAG_APPEND 0x00000010 +#define XFS_XFLAG_SYNC 0x00000020 +#define XFS_XFLAG_NOATIME 0x00000040 #define XFS_XFLAG_HASATTR 0x80000000 /* no DIFLAG for this */ #define XFS_XFLAG_ALL \ - ( XFS_XFLAG_REALTIME|XFS_XFLAG_PREALLOC|XFS_XFLAG_HASATTR ) + ( XFS_XFLAG_REALTIME|XFS_XFLAG_PREALLOC|XFS_XFLAG_IMMUTABLE| \ + XFS_XFLAG_APPEND|XFS_XFLAG_SYNC|XFS_XFLAG_NOATIME|XFS_XFLAG_HASATTR ) =20 =20 /* diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_inode.c linux-2.4-xfs/l= inux/fs/xfs/xfs_inode.c --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_inode.c Sat Aug 2 18:10:39 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_inode.c Sun Aug 3 22:02:37 2003 @@ -1207,6 +1207,8 @@ break; case IFREG: case IFDIR: + if (pip->i_d.di_flags & XFS_DIFLAG_SYNC) + ip->i_d.di_flags |=3D XFS_DIFLAG_SYNC; case IFLNK: ip->i_d.di_format =3D XFS_DINODE_FMT_EXTENTS; ip->i_df.if_flags =3D XFS_IFEXTENTS; @@ -3486,6 +3488,9 @@ if (IS_RDONLY(inode) && (S_ISREG(imode) || S_ISDIR(imode) || S_ISLNK(imode))) return XFS_ERROR(EROFS); + + if (IS_IMMUTABLE(inode)) + return XFS_ERROR(EACCES); } =20 /* @@ -3609,7 +3614,7 @@ * Don't update access timestamps on reads if mounted "noatime" * Throw it away if anyone asks us. */ - if (ip->i_mount->m_flags & XFS_MOUNT_NOATIME && + if ((ip->i_mount->m_flags & XFS_MOUNT_NOATIME || IS_NOATIME(inode)) && ((flags & (XFS_ICHGTIME_ACC|XFS_ICHGTIME_MOD|XFS_ICHGTIME_CHG)) =3D=3D XFS_ICHGTIME_ACC)) return; diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_itable.c linux-2.4-xfs/= linux/fs/xfs/xfs_itable.c --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_itable.c Mon Jul 21 15:10:06 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_itable.c Mon Jul 21 15:19:13 2003 @@ -163,6 +163,14 @@ XFS_XFLAG_REALTIME : 0) | ((di_flags & XFS_DIFLAG_PREALLOC) ? XFS_XFLAG_PREALLOC : 0) | + ((di_flags & XFS_DIFLAG_IMMUTABLE) ? + XFS_XFLAG_IMMUTABLE : 0) | + ((di_flags & XFS_DIFLAG_APPEND) ? + XFS_XFLAG_APPEND : 0) | + ((di_flags & XFS_DIFLAG_SYNC) ? + XFS_XFLAG_SYNC : 0) | + ((di_flags & XFS_DIFLAG_NOATIME) ? + XFS_XFLAG_NOATIME : 0) | (XFS_CFORK_Q_ARCH(dic, arch) ? XFS_XFLAG_HASATTR : 0); =20 diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_vnodeops.c linux-2.4-xf= s/linux/fs/xfs/xfs_vnodeops.c --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_vnodeops.c Mon Jul 21 15:11:41 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_vnodeops.c Mon Jul 21 15:19:13 2003 @@ -266,6 +266,14 @@ XFS_XFLAG_REALTIME : 0) | ((ip->i_d.di_flags & XFS_DIFLAG_PREALLOC) ? XFS_XFLAG_PREALLOC : 0) | + ((ip->i_d.di_flags & XFS_DIFLAG_IMMUTABLE) ? + XFS_XFLAG_IMMUTABLE : 0) | + ((ip->i_d.di_flags & XFS_DIFLAG_APPEND) ? + XFS_XFLAG_APPEND : 0) | + ((ip->i_d.di_flags & XFS_DIFLAG_SYNC) ? + XFS_XFLAG_SYNC : 0) | + ((ip->i_d.di_flags & XFS_DIFLAG_NOATIME) ? + XFS_XFLAG_NOATIME : 0) | (XFS_IFORK_Q(ip) ? XFS_XFLAG_HASATTR : 0); vap->va_extsize =3D ip->i_d.di_extsize << mp->m_sb.sb_blocklog; @@ -833,6 +841,14 @@ ip->i_d.di_flags |=3D XFS_DIFLAG_REALTIME; ip->i_iocore.io_flags |=3D XFS_IOCORE_RT; } + if (vap->va_xflags & XFS_XFLAG_IMMUTABLE) + ip->i_d.di_flags |=3D XFS_DIFLAG_IMMUTABLE; + if (vap->va_xflags & XFS_XFLAG_APPEND) + ip->i_d.di_flags |=3D XFS_DIFLAG_APPEND; + if (vap->va_xflags & XFS_XFLAG_SYNC) + ip->i_d.di_flags |=3D XFS_DIFLAG_SYNC; + if (vap->va_xflags & XFS_XFLAG_NOATIME) + ip->i_d.di_flags |=3D XFS_DIFLAG_NOATIME; /* can't set PREALLOC this way, just ignore it */ } xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="open.c.diff" Content-Transfer-Encoding: quoted-printable --- linux.orig/fs/open.c Sun Jun 1 20:39:38 2003 +++ linux/fs/open.c Sun Jun 1 20:54:14 2003 @@ -272,6 +272,9 @@ /* Don't worry, the checks are done in inode_change_ok() */ newattrs.ia_valid =3D ATTR_CTIME | ATTR_MTIME | ATTR_ATIME; if (times) { + error =3D -EPERM; + if (IS_APPEND(inode) || IS_IMMUTABLE(inode)) + goto dput_and_out; error =3D get_user(newattrs.ia_atime, ×->actime); if (!error)=20 error =3D get_user(newattrs.ia_mtime, ×->modtime); @@ -280,6 +283,9 @@ =20 newattrs.ia_valid |=3D ATTR_ATIME_SET | ATTR_MTIME_SET; } else { + error =3D -EACCES; + if (IS_IMMUTABLE(inode)) + goto dput_and_out; if (current->fsuid !=3D inode->i_uid && (error =3D permission(inode,MAY_WRITE)) !=3D 0) goto dput_and_out; @@ -318,6 +324,9 @@ newattrs.ia_valid =3D ATTR_CTIME | ATTR_MTIME | ATTR_ATIME; if (utimes) { struct timeval times[2]; + error =3D -EPERM; + if (IS_APPEND(inode) || IS_IMMUTABLE(inode)) + goto dput_and_out; error =3D -EFAULT; if (copy_from_user(×, utimes, sizeof(times))) goto dput_and_out; @@ -325,6 +334,10 @@ newattrs.ia_mtime =3D times[1].tv_sec; newattrs.ia_valid |=3D ATTR_ATIME_SET | ATTR_MTIME_SET; } else { + error =3D -EACCES; + if (IS_IMMUTABLE(inode)) + goto dput_and_out; + if (current->fsuid !=3D inode->i_uid && (error =3D permission(inode,MAY_WRITE)) !=3D 0) goto dput_and_out; --n8g4imXOkfNTN/H1-- --dc+cDN39EJAMEtIO 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 iEYEARECAAYFAj8t/V4ACgkQJKx7GixEevw8bgCgoOLFFSRQuND37OWY9QGRBwBe 2GcAni8dN1+qUIfLESz25EoQ0xIuyqHq =BDEc -----END PGP SIGNATURE----- --dc+cDN39EJAMEtIO-- From owner-linux-xfs@oss.sgi.com Mon Aug 4 05:24:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Aug 2003 05:25:12 -0700 (PDT) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74COnFl016989 for ; Mon, 4 Aug 2003 05:24:50 -0700 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <0.016722C6@mailhub2.arup.com>; Mon, 4 Aug 2003 2:44:20 +0100 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Mon, 04 Aug 2003 02:44:20 +0100 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Mon, 04 Aug 2003 11:43:26 +1000 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Mon, 04 Aug 2003 11:40:56 +1000 From: "Scott Fagg" To: Subject: kernel errors when XFS filesystem fills up Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h74COoFl016993 X-archive-position: 4880 X-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.fagg@arup.com Precedence: bulk X-list: linux-xfs I'm getting message like those shown below from dmesg when my XFS filesystems fill up. - happens when the file system completely runs out of space, ie 0 bytes free. - doesn't seem to be any other ill effects ( no oops, no panic ) but the app copying the file crashes ( e.g. cp or rsync will crash ) - happening on both Redhat8.0 2.4.21-xfs ( on raid5 compaq hardware) and Redhat 9.0 2.4.21-xfs ( on plain IDE ) Once the error happens once, i then start to get the same error even when the filesystem is no longer full. Only solution seems to be to reformat the filesystem as xfs_check and xfs_repair don't help. Any thoughts ? Any more info i can provide ? regards, xfs_da_do_buf: bno 0 dir: inode 4688490 Filesystem "ida0(72,17)": XFS internal error xfs_da_do_buf(1) at line 2184 of file xfs_da_btree.c. Caller 0xc01952d7 cd797cc8 c0194b81 c02b1f5d 00000001 cfe6e400 c02b1eb8 00000888 c01952d7 c3c6dd40 cf741868 0000a201 00002000 0001a201 c3c6dd40 0023c530 00000001 00000000 cfe6e400 cd797d3c c01c4def 000003de 0023c530 00000000 00000010 Call Trace: [] xfs_da_do_buf+0x211/0x8b0 [kernel] [] xfs_da_read_buf+0x57/0x60 [kernel] [] xfs_trans_read_buf+0x33f/0x3a0 [kernel] [] xfs_itobp+0xf1/0x270 [kernel] [] xfs_da_read_buf+0x57/0x60 [kernel] [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] [] xfs_attr_node_get+0x3c/0xd0 [kernel] [] xfs_attr_fetch+0xff/0x1b0 [kernel] [] xfs_acl_iaccess+0x54/0xe0 [kernel] [] xfs_dir2_put_dirent64_direct+0x0/0xa0 [kernel] [] xfs_iaccess+0x19c/0x1b0 [kernel] [] xfs_access+0x3b/0x60 [kernel] [] linvfs_permission+0x29/0x30 [kernel] [] permission+0x3a/0x40 [kernel] [] link_path_walk+0x60/0x6e0 [kernel] [] path_lookup+0x39/0x40 [kernel] [] open_namei+0x70/0x5d0 [kernel] [] filp_open+0x43/0x70 [kernel] [] sys_open+0x53/0xa0 [kernel] [] system_call+0x33/0x38 [kernel] Scott Fagg Arup Brisbane (07) 3023 6000 From owner-linux-xfs@oss.sgi.com Mon Aug 4 11:11:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Aug 2003 11:11:11 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74IB3Fl026796 for ; Mon, 4 Aug 2003 11:11:03 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h74IUasR031530 for ; Mon, 4 Aug 2003 13:30:36 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h74IAvQK4780046; Mon, 4 Aug 2003 13:10:57 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h74IAvRn212975206; Mon, 4 Aug 2003 13:10:57 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h74IAuB19414; Mon, 4 Aug 2003 13:10:56 -0500 Subject: Re: use-after-free in xfs_bawrite() From: Steve Lord To: Andrew Morton Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030802013032.7a42a596.akpm@osdl.org> References: <20030802013032.7a42a596.akpm@osdl.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1060020656.19357.10.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 04 Aug 2003 13:10:56 -0500 X-archive-position: 4881 X-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 Sat, 2003-08-02 at 03:30, Andrew Morton wrote: > Using Linus's current tree plus all the -mm gunk I get a fairly easy oops > running dbench on XFS on SMP with CONFIG_DEBUG_PAGEALLOC=y: I can't hit it for some reason, but yes, I see it. As for why xfs and dbench don't mix so well - its a 2.6 thing, but having looked at what the other places which wait for I/O in the kernel do, perhaps if we made some similar changes to the xfs specific spots, things might improve. Looks like getting into io_schedule would be a good thing in a few strategic places. Steve > > Program received signal SIGEMT, Emulation trap. > 0xc0282c9d in xfs_iflush (ip=0xc284a004, flags=2) at fs/xfs/pagebuf/page_buf.h:397 > 397 if (!pb || atomic_read(&pb->pb_io_remaining)) > (gdb) p pb > $1 = (page_buf_t *) 0xc98d1004 > (gdb) p *pb > Cannot access memory at address 0xc98d1004 > (gdb) bt > #0 0xc0282c9d in xfs_iflush (ip=0xc284a004, flags=2) at fs/xfs/pagebuf/page_buf.h:397 > #1 0xc0283dee in xfs_inode_item_push (iip=0xc2849004) at fs/xfs/xfs_inode_item.c:882 > #2 0xc0294ddf in xfs_trans_push_ail (mp=0xceb87004, threshold_lsn=21474846993) at fs/xfs/xfs_trans_ail.c:170 > #3 0xc0287622 in xlog_grant_push_ail (mp=0xceb87004, need_bytes=492072) at fs/xfs/xfs_log.c:1390 > #4 0xc028652c in xfs_log_reserve (mp=0xceb87004, unit_bytes=157880, cnt=3, ticket=0xc9451038, client=105, > flags=2) at fs/xfs/xfs_log.c:461 > #5 0xc0293afd in xfs_trans_reserve (tp=0xc9451004, blocks=41, logspace=157880, rtextents=0, flags=4, logcount=3) > at fs/xfs/xfs_trans.c:275 > #6 0xc029c340 in xfs_mkdir (dir_bdp=0xc0c3e024, dentry=0xca964004, vap=0xc790fec4, vpp=0xc790fec0, credp=0x0) > at fs/xfs/xfs_vnodeops.c:2878 > #7 0xc02a687c in linvfs_mknod (dir=0xc0c3f024, dentry=0xca964004, mode=16832, rdev=0) > at fs/xfs/linux/xfs_iops.c:136 > #8 0xc02a6a4f in linvfs_mkdir (dir=0xc0c3f024, dentry=0xca964004, mode=448) at fs/xfs/linux/xfs_iops.c:190 > #9 0xc016d838 in vfs_mkdir (dir=0xc0c3f024, dentry=0xca964004, mode=448) at fs/namei.c:1510 > #10 0xc016d901 in sys_mkdir (pathname=0xbffff2e7 "CLIENTS/CLIENT16/~DMTMP/SEED", mode=448) at fs/namei.c:1537 > > The memory at 0xc98d1004 has been unmapped. > > The oops is on the xfs_iflush() -> xfs_bawrite() -> pagebuf_run_queues() path. > > It looks to me like pagebuf_iostart() has called pagebuf_iorequest() which called > _pagebuf_iodone() which called pagebuf_iodone() whuich threw away the pagebuf. > > If this is vaguely correct then this part of pagebuf_iostart(): > > /* Wait for I/O if we are not an async request */ > if ((status == 0) && (flags & PBF_ASYNC) == 0) { > > also needs attention... > > > The below quick patch fixes it up. But it also causes zillions of dentries > and inodes to be leaked for some reason. Consider it a technology > demonstration! > > XFS has waaaaay too much inlining btw ;) > > Seems that dbench is not XFS's favourite benchmark. How come? Do I need > more logbufs? > > > > fs/xfs/xfs_buf.h | 2 ++ > 1 files changed, 2 insertions(+) > > diff -puN fs/xfs/xfs_buf.h~a fs/xfs/xfs_buf.h > --- 25/fs/xfs/xfs_buf.h~a 2003-08-02 00:53:59.000000000 -0700 > +++ 25-akpm/fs/xfs/xfs_buf.h 2003-08-02 00:56:03.000000000 -0700 > @@ -220,8 +220,10 @@ static inline int xfs_bawrite(void *mp, > bp->pb_fspriv3 = mp; > bp->pb_strat = xfs_bdstrat_cb; > xfs_buf_undelay(bp); > + atomic_inc(&bp->pb_hold); > if ((ret = pagebuf_iostart(bp, PBF_WRITE | PBF_ASYNC)) == 0) > pagebuf_run_queues(bp); > + pagebuf_rele(bp); > return ret; > } > > > _ -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Aug 4 13:43:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Aug 2003 13:43:58 -0700 (PDT) Received: from smtpgw.ciprico.com (hqntws.ciprico.com [208.252.143.8]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74KhiFl032503 for ; Mon, 4 Aug 2003 13:43:44 -0700 Received: From smtpgw.ciprico.com ([127.0.0.1]) by smtpgw.ciprico.com (WebShield SMTP v4.5 MR1a); id 1060029792332; Mon, 4 Aug 2003 15:43:12 -0500 Received: from Unknown [172.20.0.8] by smtpgw.ciprico.com - SurfControl E-mail Filter (4.6); Monday, 04 August 2003, 15:43:11 Received: by hqntex1.ciprico.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Aug 2003 15:43:10 -0500 Message-ID: From: Aman Shahi To: "'linux-xfs@oss.sgi.com'" Cc: "'Greg Freemyer'" , "'Steve Lord'" , "'Russell Cattelan'" Date: Mon, 4 Aug 2003 15:43:10 -0500 Subject: Data Corruption problem (BUG 269) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Internet Mail Service (5.5.2653.19) X-archive-position: 4882 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ashahi@ciprico.com Precedence: bulk X-list: linux-xfs Hi Guys, We reported a data corruption problem using kernel-2.4.20 and XFS snapshot-xfs-2.4.20-2003-04-07_05:19_UTC. We upgraded our kernel to 2.4.21 and xfs-1.3pre4. After a little of investigation, we found that the type of data corruption that we were getting was related to fsync call made by the NFS daemon.(At the end of the file some data was missing but the metadata was okay). It looks like the fsync call is issued with 0 as the third parameter. (The file that we are talking about is linux/fs/nfsd/vfs.c ). We changed the third parameter to 1 in order to wait until the metadata and data is stable in the storage subsystem. I think that you can close BUG #269 or you can tell us how to close it. Due to more test cycle (it would have cost us, and cause we found what were using to be stable enough) we didn't want to upgrade to the current release. Sorry for the inconvenience. Thank you very much for your support and great product. XFS rocks!!!!!! regards, Gustavo Rincon. Aman Shahi. From owner-linux-xfs@oss.sgi.com Mon Aug 4 14:53:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Aug 2003 14:54:10 -0700 (PDT) Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74LrqFl001775 for ; Mon, 4 Aug 2003 14:53:52 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id OAA17568; Mon, 4 Aug 2003 14:53:46 -0700 Message-ID: <3F2ED423.9E7F227D@mvista.com> Date: Mon, 04 Aug 2003 14:46:11 -0700 From: Blair Barnett Organization: Monta Vista Software, Inc X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: different behaviour between XFS and ext3 References: <3F283E36.778CC934@mvista.com> <1059662873.2837.56.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4883 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bbarnett@mvista.com Precedence: bulk X-list: linux-xfs Steve Lord wrote: > > > Its a bug, not sure what it is yet, those subsequent syncs should > be working. In testing sync and reboot I was untaring a linux kernel > doing sync followed by immediate reset of the box. I can build the > kernel afterwards, so that works. When I run the test, there is more > data on the disk than number 10, but the inode size is back at where > it was at the first sync. > > Steve Need any help chasing this down? Let me know. -blair From owner-linux-xfs@oss.sgi.com Mon Aug 4 15:09:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Aug 2003 15:09:46 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74M9gFl002617 for ; Mon, 4 Aug 2003 15:09:42 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h74MTFsR007841 for ; Mon, 4 Aug 2003 17:29:15 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h74M9aQK4923646; Mon, 4 Aug 2003 17:09:36 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h74M9aRn199463783; Mon, 4 Aug 2003 17:09:36 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h74M9a122164; Mon, 4 Aug 2003 17:09:36 -0500 Subject: Re: different behaviour between XFS and ext3 From: Steve Lord To: Blair Barnett Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F2ED423.9E7F227D@mvista.com> References: <3F283E36.778CC934@mvista.com> <1059662873.2837.56.camel@jen.americas.sgi.com> <3F2ED423.9E7F227D@mvista.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1060034975.19614.68.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 04 Aug 2003 17:09:35 -0500 X-archive-position: 4884 X-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 Mon, 2003-08-04 at 16:46, Blair Barnett wrote: > Steve Lord wrote: > > > > > > > Its a bug, not sure what it is yet, those subsequent syncs should > > be working. In testing sync and reboot I was untaring a linux kernel > > doing sync followed by immediate reset of the box. I can build the > > kernel afterwards, so that works. When I run the test, there is more > > data on the disk than number 10, but the inode size is back at where > > it was at the first sync. > > > > Steve > > Need any help chasing this down? Let me know. Thanks, I have some code which fixes this, causes some other strange behavior though (including corruption in other ways), so it needs work. Basically the file data is on disk, and before remounting the filesystem, the inode size is correct on disk, its just that recovery is rolling the inode size back again. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Aug 5 10:44:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Aug 2003 10:44:24 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h75HiBFl022899 for ; Tue, 5 Aug 2003 10:44:11 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h75HiB23022898 for linux-xfs@oss.sgi.com; Tue, 5 Aug 2003 10:44:11 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h75Hi9Fp022882 for ; Tue, 5 Aug 2003 10:44:10 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h75Gvcbq018860; Tue, 5 Aug 2003 09:57:38 -0700 Date: Tue, 5 Aug 2003 09:57:38 -0700 Message-Id: <200308051657.h75Gvcbq018860@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 269] XFS Data Corruption on Power Failure(on unclean unmount) X-Bugzilla-Reason: AssignedTo X-archive-position: 4885 X-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 http://oss.sgi.com/bugzilla/show_bug.cgi?id=269 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER ------- Additional Comments From cattelan@thebarn.com 2003-05-08 09:57 PDT ------- Hi Guys, We reported a data corruption problem using kernel-2.4.20 and XFS snapshot-xfs-2.4.20-2003-04-07_05:19_UTC. We upgraded our kernel to 2.4.21 and xfs-1.3pre4. After a little of investigation, we found that the type of data corruption that we were getting was related to fsync call made by the NFS daemon.(At the end of the file some data was missing but the metadata was okay). It looks like the fsync call is issued with 0 as the third parameter. (The file that we are talking about is linux/fs/nfsd/vfs.c ). We changed the third parameter to 1 in order to wait until the metadata and data is stable in the storage subsystem. I think that you can close BUG #269 or you can tell us how to close it. Due to more test cycle (it would have cost us, and cause we found what were using to be stable enough) we didn't want to upgrade to the current release. Sorry for the inconvenience. Thank you very much for your support and great product. XFS rocks!!!!!! regards, Gustavo Rincon. Aman Shahi. ------- 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 Aug 5 15:31:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Aug 2003 15:31:35 -0700 (PDT) Received: from ams003.ftl.affinity.com (lvs00-fl.valueweb.net [216.219.253.199]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h75MVEFl010491 for ; Tue, 5 Aug 2003 15:31:15 -0700 Received: from david.internal.NorcrossGroup.com ([66.156.2.86]) by ams.ftl.affinity.com with ESMTP id <215765-23849>; Tue, 5 Aug 2003 18:30:22 -0400 Subject: xfsinvutil From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: "'linux-xfs@oss.sgi.com'" Content-Type: text/plain Organization: Message-Id: <1060143532.17955.1328.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 06 Aug 2003 00:18:52 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4886 X-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-ml@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Under some conditions I want to void my last backup so it will not be used as a basis as future backup reference. i.e. I double check my media after the backup and occasionally it is bad, so I need to void the inventory. I can use xfsinvutil interactively to do it. I have been unable to delete a session via a shell script. Has anybody been able to do this? If so, what command line args do you use for xfsinvutil? Thanks Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Tue Aug 5 21:36:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Aug 2003 21:36:55 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h764aaFl018653 for ; Tue, 5 Aug 2003 21:36:36 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h764uCsR012248 for ; Tue, 5 Aug 2003 23:56:13 -0500 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h764aPns017399; Wed, 6 Aug 2003 14:36:25 +1000 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h764aOf9017397; Wed, 6 Aug 2003 14:36:24 +1000 Date: Wed, 6 Aug 2003 14:36:24 +1000 From: Keith Owens Message-Id: <200308060436.h764aOf9017397@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade XFS to kdb v4.3-2.4.21-{common-8,i386-5} X-archive-position: 4888 X-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: 301 Lines: 12 Upgrade XFS to kdb v4.3-2.4.21-{common-8,i386-5} Date: Tue Aug 5 21:35:22 PDT 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:155127a linux/kdb/modules/kdbm_x86.c - 1.1 From owner-linux-xfs@oss.sgi.com Tue Aug 5 22:03:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Aug 2003 22:03:17 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76532Fl020956 for ; Tue, 5 Aug 2003 22:03:02 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7652tq0017080 for ; Tue, 5 Aug 2003 22:02:56 -0700 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 PAA07767 for ; Wed, 6 Aug 2003 15:02:54 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id A7194C21CF; Wed, 6 Aug 2003 15:02:51 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 9A206140681 for ; Wed, 6 Aug 2003 15:02:51 +1000 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: Announce: XFS split patches for 2.4.21 (respin) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Aug 2003 15:02:50 +1000 Message-ID: <5344.1060146170@kao2.melbourne.sgi.com> X-archive-position: 4889 X-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: 609 Lines: 13 ftp://oss.sgi.com/projects/xfs/download/patches/2.4.21. Respin as of 2003-08-06_04:46_UTC. 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.22/README for the terminally impatient :). From owner-linux-xfs@oss.sgi.com Wed Aug 6 01:03:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Aug 2003 01:03:52 -0700 (PDT) Received: from unicorn.drogon.net (unicorn.drogon.net [195.10.246.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7683ZFl002924 for ; Wed, 6 Aug 2003 01:03:36 -0700 Received: from unicorn.drogon.net (localhost [127.0.0.1]) by unicorn.drogon.net (8.12.9/8.12.9) with ESMTP id h7683Qio028665 for ; Wed, 6 Aug 2003 09:03:27 +0100 Received: from localhost (gordon@localhost) by unicorn.drogon.net (8.12.9/8.12.9/Submit) with ESMTP id h7683QNf028662 for ; Wed, 6 Aug 2003 09:03:26 +0100 X-Authentication-Warning: unicorn.drogon.net: gordon owned process doing -bs Date: Wed, 6 Aug 2003 09:03:26 +0100 (BST) From: Gordon Henderson To: linux-xfs@oss.sgi.com Subject: Processes stuck in D state.. In-Reply-To: <3F2920A4.575A310A@mvista.com> Message-ID: References: <3F283E36.778CC934@mvista.com> <3F28E34D.3EE2CF4A@ch.sauter-bc.com> <3F2920A4.575A310A@mvista.com> Distribution: world Organization: Home for lost Drogons MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-archive-position: 4890 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gordon@drogon.net Precedence: bulk X-list: linux-xfs Content-Length: 1314 Lines: 32 I am running a few production servers with XFS now, but I'm a little concerned... (as I'm seeing some problems) Anyway, I'm using the -ac4 patches to 2.4.21 with the 1.2 release of the xfsprogs and with overnight cron "stuff", (eg. amanda) I get a bunch of processes hanging in the "D" state. Eg. xfsdump. This doesn't inspire confidence. Right now I'm seeing: 1149 ? D 2:20 xfsdump -F -J -l 1 - /dev/md4 9275 ? D 2:02 du -k 10103 ? D 2:26 /usr/bin/find / ( -fstype NFS -o -fstype nfs -o 21671 ? D 1:28 /usr/bin/rsync -a --delete -H -x . /mounts/local0.yesterday/ 13976 ? D 1:16 du -k 14776 ? D 1:59 /usr/bin/find / ( -fstype NFS -o -fstype nfs -o which isn't good. A few days ago I had a bunch of nfsd's stuck in D state too which required a reboot - which in a busy working environment isn't a good thing )-: Is XFS really ready for production? I'm faced with migrating this box back to ext2 and hoping we never get a powerfail (it's on a big UPS, but there is a limit!) as it has 2 x 160GB partitions which I can live without the fsck time... (and this is just the start, I have another half terabyte server with XFS too - I shudder to think of the fsck time on that!) Any clues other than "get the latest CVS patches"? Gordon From owner-linux-xfs@oss.sgi.com Wed Aug 6 04:03:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Aug 2003 04:04:24 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76B3RFl015856 for ; Wed, 6 Aug 2003 04:03:30 -0700 Received: (qmail 32470 invoked from network); 6 Aug 2003 11:03:24 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 6 Aug 2003 11:03:24 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id CA717C21CF; Wed, 6 Aug 2003 21:03:20 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 81960140694; Wed, 6 Aug 2003 21:03:20 +1000 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Gordon Henderson Cc: linux-xfs@oss.sgi.com Subject: Re: Processes stuck in D state.. In-reply-to: Your message of "Wed, 06 Aug 2003 09:03:26 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Aug 2003 21:03:19 +1000 Message-ID: <2597.1060167799@ocs3.intra.ocs.com.au> X-archive-position: 4891 X-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: 1627 Lines: 34 On Wed, 6 Aug 2003 09:03:26 +0100 (BST), Gordon Henderson wrote: > >I am running a few production servers with XFS now, but I'm a little >concerned... (as I'm seeing some problems) > >Anyway, I'm using the -ac4 patches to 2.4.21 with the 1.2 release of the >xfsprogs and with overnight cron "stuff", (eg. amanda) I get a bunch of >processes hanging in the "D" state. Eg. xfsdump. This doesn't inspire >confidence. Right now I'm seeing: > > 1149 ? D 2:20 xfsdump -F -J -l 1 - /dev/md4 > 9275 ? D 2:02 du -k >10103 ? D 2:26 /usr/bin/find / ( -fstype NFS -o -fstype nfs -o >21671 ? D 1:28 /usr/bin/rsync -a --delete -H -x . /mounts/local0.yesterday/ >13976 ? D 1:16 du -k >14776 ? D 1:59 /usr/bin/find / ( -fstype NFS -o -fstype nfs -o > >which isn't good. A few days ago I had a bunch of nfsd's stuck in D state >too which required a reboot - which in a busy working environment isn't a >good thing )-: Do not blame XFS for this problem, it is almost certainly an NFS problem. When an NFS mount marked 'hard' stops responding, any process that accesses the NFS mount will hang in D state. If those processes are holding mount or vfs locks, then other processes that require mount activity will hang on those locks, also in D state. Fix the NFS problems and the other hangs will go away. If NFS hangs a lot, try mounting with 'hard,intr' which lets you kill the hung tasks, or even 'soft,intr' so they automatically time out on hung NFS mounts. Note: a 'soft' NFS mount can result in I/O errors when the NFS server is unreliable. From owner-linux-xfs@oss.sgi.com Wed Aug 6 07:33:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Aug 2003 07:33:47 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76EXRFl024502 for ; Wed, 6 Aug 2003 07:33:28 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h76EXMq0027967 for ; Wed, 6 Aug 2003 07:33:22 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h76EXLQK5484720 for ; Wed, 6 Aug 2003 09:33:21 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h76EXLRn211253674 for ; Wed, 6 Aug 2003 09:33:21 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h76EX9430130; Wed, 6 Aug 2003 09:33:09 -0500 Message-Id: <200308061433.h76EX9430130@jen.americas.sgi.com> Date: Wed, 6 Aug 2003 09:33:09 -0500 Subject: TAKE - get version 1 directories back into action To: linux-xfs@oss.sgi.com X-archive-position: 4892 X-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: 702 Lines: 25 This gets version 1 directories functioning for the most part, there will always be corner cases, this is just so you can mount older irix filesystems. Date: Wed Aug 6 07:31:37 PDT 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 Author: lord Merged by: lord Merged mods: 2.4.x-xfs-kern:slinx:155149a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:155149a linux/fs/xfs/xfs_dir_leaf.c - 1.116 - Merge of 2.4.x-xfs-kern:slinx:155149a by lord. linux/fs/xfs/xfs_dir2_leaf.h - 1.15 - Merge of 2.4.x-xfs-kern:slinx:155149a by lord. linux/fs/xfs/linux/xfs_file.c - 1.93 - Merge of 2.4.x-xfs-kern:slinx:155149a by lord. From owner-linux-xfs@oss.sgi.com Wed Aug 6 08:58:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Aug 2003 08:58:29 -0700 (PDT) Received: from shell.wgops.com (postfix@shell.wgops.com [66.92.192.108]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76Fw5Fl030994 for ; Wed, 6 Aug 2003 08:58:08 -0700 Received: from [10.1.2.77] (jobe.wgops.com [10.1.2.77]) by shell.wgops.com (Postfix) with ESMTP id 853CFBB; Wed, 6 Aug 2003 09:58:01 -0600 (MDT) Date: Wed, 06 Aug 2003 09:57:46 -0600 From: Michael Loftis To: Gordon Henderson , linux-xfs@oss.sgi.com Subject: Re: Processes stuck in D state.. Message-ID: <198095225.1060163866@[10.1.2.77]> In-Reply-To: References: <3F283E36.778CC934@mvista.com> <3F28E34D.3EE2CF4A@ch.sauter-bc.com> <3F2920A4.575A310A@mvista.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 4893 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs Content-Length: 1795 Lines: 46 Yah for production go with a kernel as close to stock as posible. Avoid anything by redhat in the 2.4.20 series, and you should be fine. In other words go get a fresh treee, patch in ONLY the XFS stuff. Don't put in low latency/preeempt patches, they still screw everything up. And just stay away from RedHate kernels. --On Wednesday, August 06, 2003 9:03 AM +0100 Gordon Henderson wrote: > > I am running a few production servers with XFS now, but I'm a little > concerned... (as I'm seeing some problems) > > Anyway, I'm using the -ac4 patches to 2.4.21 with the 1.2 release of the > xfsprogs and with overnight cron "stuff", (eg. amanda) I get a bunch of > processes hanging in the "D" state. Eg. xfsdump. This doesn't inspire > confidence. Right now I'm seeing: > > 1149 ? D 2:20 xfsdump -F -J -l 1 - /dev/md4 > 9275 ? D 2:02 du -k > 10103 ? D 2:26 /usr/bin/find / ( -fstype NFS -o -fstype nfs -o > 21671 ? D 1:28 /usr/bin/rsync -a --delete -H -x . > /mounts/local0.yesterday/ 13976 ? D 1:16 du -k > 14776 ? D 1:59 /usr/bin/find / ( -fstype NFS -o -fstype nfs -o > > which isn't good. A few days ago I had a bunch of nfsd's stuck in D state > too which required a reboot - which in a busy working environment isn't a > good thing )-: > > Is XFS really ready for production? > > I'm faced with migrating this box back to ext2 and hoping we never get a > powerfail (it's on a big UPS, but there is a limit!) as it has 2 x 160GB > partitions which I can live without the fsck time... (and this is just the > start, I have another half terabyte server with XFS too - I shudder to > think of the fsck time on that!) > > Any clues other than "get the latest CVS patches"? > > Gordon > > From owner-linux-xfs@oss.sgi.com Wed Aug 6 12:15:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Aug 2003 12:16:02 -0700 (PDT) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76JFfFl016541 for ; Wed, 6 Aug 2003 12:15:42 -0700 Received: from mailhub.ch.sauter-bc.com (mailhub [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id B278E4E270; Wed, 6 Aug 2003 21:15:34 +0200 (CEST) Received: from imap01.ch.sauter-bc.com (imap01.ch.sauter-bc.com [10.1.6.25]) by mailhub.ch.sauter-bc.com (Postfix) with ESMTP id 8C89432CB5; Wed, 6 Aug 2003 21:15:33 +0200 (CEST) Received: from webmail.ch.sauter-bc.com (localhost.localdomain [127.0.0.1]) by imap01.ch.sauter-bc.com (Postfix) with SMTP id F2E2511E11; Wed, 6 Aug 2003 21:15:32 +0200 (CEST) Received: from 213.173.165.140 (proxying for 157.161.34.15) (SquirrelMail authenticated user mattesim) by imap01.ch.sauter-bc.com with HTTP; Wed, 6 Aug 2003 21:15:33 +0200 (CEST) Message-ID: <38207.213.173.165.140.1060197333.squirrel@imap01.ch.sauter-bc.com> In-Reply-To: <198095225.1060163866@[10.1.2.77]> References: <3F283E36.778CC934@mvista.com><3F28E34D.3EE2CF4A@ch.sauter-bc.com> <3F2920A4.575A310A@mvista.com> <198095225.1060163866@[10.1.2.77]> Date: Wed, 6 Aug 2003 21:15:33 +0200 (CEST) Subject: Re: Processes stuck in D state.. From: "Simon Matter" To: "Michael Loftis" Cc: "Gordon Henderson" , linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-archive-position: 4894 X-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: 2093 Lines: 61 > Yah for production go with a kernel as close to stock as posible. Avoid > anything by redhat in the 2.4.20 series, and you should be fine. In other > words go get a fresh treee, patch in ONLY the XFS stuff. Don't put in low > latency/preeempt patches, they still screw everything up. And just stay > away from RedHate kernels. I don't agree. I'm using XFS enabled RedHat for a long time now on several servers with great success. Are the problem you're talking about always NFS related? That's the only thing I'm not using alot with the XFS boxes. Simon > > --On Wednesday, August 06, 2003 9:03 AM +0100 Gordon Henderson > wrote: > >> >> I am running a few production servers with XFS now, but I'm a little >> concerned... (as I'm seeing some problems) >> >> Anyway, I'm using the -ac4 patches to 2.4.21 with the 1.2 release of the >> xfsprogs and with overnight cron "stuff", (eg. amanda) I get a bunch of >> processes hanging in the "D" state. Eg. xfsdump. This doesn't inspire >> confidence. Right now I'm seeing: >> >> 1149 ? D 2:20 xfsdump -F -J -l 1 - /dev/md4 >> 9275 ? D 2:02 du -k >> 10103 ? D 2:26 /usr/bin/find / ( -fstype NFS -o -fstype nfs >> -o >> 21671 ? D 1:28 /usr/bin/rsync -a --delete -H -x . >> /mounts/local0.yesterday/ 13976 ? D 1:16 du -k >> 14776 ? D 1:59 /usr/bin/find / ( -fstype NFS -o -fstype nfs >> -o >> >> which isn't good. A few days ago I had a bunch of nfsd's stuck in D >> state >> too which required a reboot - which in a busy working environment isn't >> a >> good thing )-: >> >> Is XFS really ready for production? >> >> I'm faced with migrating this box back to ext2 and hoping we never get a >> powerfail (it's on a big UPS, but there is a limit!) as it has 2 x 160GB >> partitions which I can live without the fsck time... (and this is just >> the >> start, I have another half terabyte server with XFS too - I shudder to >> think of the fsck time on that!) >> >> Any clues other than "get the latest CVS patches"? >> >> Gordon >> >> > > > > > > From owner-linux-xfs@oss.sgi.com Wed Aug 6 12:23:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Aug 2003 12:23:56 -0700 (PDT) Received: from mail.modwest.com (marshall.modwest.com [216.129.251.30]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76JNpFl017499 for ; Wed, 6 Aug 2003 12:23:52 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.modwest.com (Postfix) with ESMTP id 0C8A740F4EA0; Wed, 6 Aug 2003 13:23:51 -0600 (MDT) Received: from mail.modwest.com ([127.0.0.1]) by localhost (marshall.modwest.com [127.0.0.1]) (amavisd-new) with ESMTP id 29766-11; Wed, 6 Aug 2003 13:23:50 -0000 (MDT) Received: from 216-220-25-60.vnet-inc.com (216-220-25-60.vnet-inc.com [216.220.25.60]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail.modwest.com (Postfix) with ESMTP id DC3CB40F4DAB; Wed, 6 Aug 2003 13:23:50 -0600 (MDT) Date: Wed, 06 Aug 2003 13:25:40 -0600 From: Michael Loftis To: Simon Matter Cc: Gordon Henderson , linux-xfs@oss.sgi.com Subject: Re: Processes stuck in D state.. Message-ID: <156407234.1060176340@216-220-25-60.vnet-inc.com> In-Reply-To: <38207.213.173.165.140.1060197333.squirrel@imap01.ch.sauter-bc.com> References: <3F283E36.778CC934@mvista.com><3F28E34D.3EE2CF4A@ch.sauter-bc.com> <3F2920A4.575A310A@mvista.com> <198095225.1060163866@[10.1.2.77]> <38207.213.173.165.140.1060197333.squirrel@imap01.ch.sauter-bc.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new amavisd-new-20020630 X-archive-position: 4895 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs Content-Length: 1082 Lines: 25 The whole redhat 2.4.20 kernel is crap. I've had a number of boxes lockup on it. Initially it was the firewall, but then at home I've had other boxes lock up under load with it. 2.4.20-19.x got a little better but was still totally screwed up. Going to a stock 2.4.20 fixed all the issues I've been having. The root of this one is IMHO RH 2.4.20 is actually 2.4.21-pre3 plus a mass of patches. --On Wednesday, August 06, 2003 21:15 +0200 Simon Matter wrote: >> Yah for production go with a kernel as close to stock as posible. Avoid >> anything by redhat in the 2.4.20 series, and you should be fine. In >> other words go get a fresh treee, patch in ONLY the XFS stuff. Don't >> put in low latency/preeempt patches, they still screw everything up. >> And just stay away from RedHate kernels. > > I don't agree. I'm using XFS enabled RedHat for a long time now on several > servers with great success. Are the problem you're talking about always > NFS related? That's the only thing I'm not using alot with the XFS boxes. > > Simon > From owner-linux-xfs@oss.sgi.com Wed Aug 6 12:37:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Aug 2003 12:37:15 -0700 (PDT) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76JaxFl018748 for ; Wed, 6 Aug 2003 12:37:00 -0700 Received: from mailhub.ch.sauter-bc.com (mailhub [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 9D9724E270; Wed, 6 Aug 2003 21:36:53 +0200 (CEST) Received: from imap01.ch.sauter-bc.com (imap01.ch.sauter-bc.com [10.1.6.25]) by mailhub.ch.sauter-bc.com (Postfix) with ESMTP id C149C32CD0; Wed, 6 Aug 2003 21:36:52 +0200 (CEST) Received: from webmail.ch.sauter-bc.com (localhost.localdomain [127.0.0.1]) by imap01.ch.sauter-bc.com (Postfix) with SMTP id EAF3F11E11; Wed, 6 Aug 2003 21:36:51 +0200 (CEST) Received: from 213.173.165.140 (proxying for 157.161.34.15) (SquirrelMail authenticated user mattesim) by imap01.ch.sauter-bc.com with HTTP; Wed, 6 Aug 2003 21:36:52 +0200 (CEST) Message-ID: <38236.213.173.165.140.1060198612.squirrel@imap01.ch.sauter-bc.com> In-Reply-To: <156407234.1060176340@216-220-25-60.vnet-inc.com> References: <3F283E36.778CC934@mvista.com><3F28E34D.3EE2CF4A@ch.sauter-bc.com> <3F2920A4.575A310A@mvista.com> <198095225.1060163866@[10.1.2.77]><38207.213.173.165.140.1060197333.squirrel@imap01.ch.sauter-bc.com> <156407234.1060176340@216-220-25-60.vnet-inc.com> Date: Wed, 6 Aug 2003 21:36:52 +0200 (CEST) Subject: Re: Processes stuck in D state.. From: "Simon Matter" To: "Michael Loftis" Cc: "Simon Matter" , "Gordon Henderson" , linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-archive-position: 4896 X-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: 1546 Lines: 38 > The whole redhat 2.4.20 kernel is crap. I've had a number of boxes lockup > on it. Initially it was the firewall, but then at home I've had other > boxes lock up under load with it. 2.4.20-19.x got a little better but was > still totally screwed up. Going to a stock 2.4.20 fixed all the issues > I've been having. I have my own patched set of 2.4.20-19.9.SGI_XFS_1.2.0 kernels which perform very well on several servers from RedHat 7.2 to RedHat 9. One RedHat 9 box is a dual Xeon 2.8G, 4G ram and lot's of disks, running two quite big, heavily loaded SAP-DB instances on XFS, on top of LVM. Others are running Cyrus-IMAPd mailservers, Samba, whatever. If the kernels were crap, I knew it for sure. Where did you get your kernels from? > > The root of this one is IMHO RH 2.4.20 is actually 2.4.21-pre3 plus a mass > of patches. > > --On Wednesday, August 06, 2003 21:15 +0200 Simon Matter > wrote: > >>> Yah for production go with a kernel as close to stock as posible. >>> Avoid >>> anything by redhat in the 2.4.20 series, and you should be fine. In >>> other words go get a fresh treee, patch in ONLY the XFS stuff. Don't >>> put in low latency/preeempt patches, they still screw everything up. >>> And just stay away from RedHate kernels. >> >> I don't agree. I'm using XFS enabled RedHat for a long time now on >> several >> servers with great success. Are the problem you're talking about always >> NFS related? That's the only thing I'm not using alot with the XFS >> boxes. >> >> Simon >> > > From owner-linux-xfs@oss.sgi.com Wed Aug 6 13:05:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Aug 2003 13:05:47 -0700 (PDT) Received: from mail.modwest.com (marshall.modwest.com [216.129.251.30]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76K5JFl021227 for ; Wed, 6 Aug 2003 13:05:20 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.modwest.com (Postfix) with ESMTP id 5B5D740F58CC; Wed, 6 Aug 2003 14:05:19 -0600 (MDT) Received: from mail.modwest.com ([127.0.0.1]) by localhost (marshall.modwest.com [127.0.0.1]) (amavisd-new) with ESMTP id 19899-11; Wed, 6 Aug 2003 14:05:19 -0000 (MDT) Received: from 216-220-25-60.vnet-inc.com (216-220-25-60.vnet-inc.com [216.220.25.60]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail.modwest.com (Postfix) with ESMTP id 3780540F58BA; Wed, 6 Aug 2003 14:05:19 -0600 (MDT) Date: Wed, 06 Aug 2003 14:07:09 -0600 From: Michael Loftis To: Simon Matter Cc: Gordon Henderson , linux-xfs@oss.sgi.com Subject: Re: Processes stuck in D state.. Message-ID: <158895937.1060178829@216-220-25-60.vnet-inc.com> In-Reply-To: <38236.213.173.165.140.1060198612.squirrel@imap01.ch.sauter-bc.com> References: <3F283E36.778CC934@mvista.com><3F28E34D.3EE2CF4A@ch.sauter-bc.com> <3F2920A4.575A310A@mvista.com> <198095225.1060163866@[10.1.2.77]> <38207.213.173.165.140.1060197333.squirrel@imap01.ch.sauter-bc.com> <156407234.1060176340@216-220-25-60.vnet-inc.com> <38236.213.173.165.140.1060198612.squirrel@imap01.ch.sauter-bc.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new amavisd-new-20020630 X-archive-position: 4897 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs Content-Length: 1333 Lines: 27 RedHat directly. Tried i386 and i686 kernels for systems. Both had the same problem. Symptoms were either lockup of the machine with the IDE HDD activity light stuck on but absolutely no other response, or the machine powers off. So it seems like an ACPI or IDE/ACPI/APM issue. This did not occur in older kernels as far as I can tell. Just in the 2.4.20-18+. --On Wednesday, August 06, 2003 21:36 +0200 Simon Matter wrote: >> The whole redhat 2.4.20 kernel is crap. I've had a number of boxes >> lockup on it. Initially it was the firewall, but then at home I've had >> other boxes lock up under load with it. 2.4.20-19.x got a little better >> but was still totally screwed up. Going to a stock 2.4.20 fixed all the >> issues I've been having. > > I have my own patched set of 2.4.20-19.9.SGI_XFS_1.2.0 kernels which > perform very well on several servers from RedHat 7.2 to RedHat 9. One > RedHat 9 box is a dual Xeon 2.8G, 4G ram and lot's of disks, running two > quite big, heavily loaded SAP-DB instances on XFS, on top of LVM. Others > are running Cyrus-IMAPd mailservers, Samba, whatever. If the kernels were > crap, I knew it for sure. Where did you get your kernels from? > >> >> The root of this one is IMHO RH 2.4.20 is actually 2.4.21-pre3 plus a >> mass of patches. >> From owner-linux-xfs@oss.sgi.com Wed Aug 6 13:09:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Aug 2003 13:09:38 -0700 (PDT) Received: from mail.modwest.com (marshall.modwest.com [216.129.251.30]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76K9aFl021847 for ; Wed, 6 Aug 2003 13:09:36 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.modwest.com (Postfix) with ESMTP id 12B3040F58DD; Wed, 6 Aug 2003 14:09:36 -0600 (MDT) Received: from mail.modwest.com ([127.0.0.1]) by localhost (marshall.modwest.com [127.0.0.1]) (amavisd-new) with ESMTP id 22525-16; Wed, 6 Aug 2003 14:09:35 -0000 (MDT) Received: from 216-220-25-60.vnet-inc.com (216-220-25-60.vnet-inc.com [216.220.25.60]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail.modwest.com (Postfix) with ESMTP id E39C340F58CC; Wed, 6 Aug 2003 14:09:35 -0600 (MDT) Date: Wed, 06 Aug 2003 14:11:25 -0600 From: Michael Loftis To: Simon Matter Cc: Gordon Henderson , linux-xfs@oss.sgi.com Subject: Re: Processes stuck in D state.. Message-ID: <159152656.1060179085@216-220-25-60.vnet-inc.com> In-Reply-To: <38236.213.173.165.140.1060198612.squirrel@imap01.ch.sauter-bc.com> References: <3F283E36.778CC934@mvista.com><3F28E34D.3EE2CF4A@ch.sauter-bc.com> <3F2920A4.575A310A@mvista.com> <198095225.1060163866@[10.1.2.77]> <38207.213.173.165.140.1060197333.squirrel@imap01.ch.sauter-bc.com> <156407234.1060176340@216-220-25-60.vnet-inc.com> <38236.213.173.165.140.1060198612.squirrel@imap01.ch.sauter-bc.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new amavisd-new-20020630 X-archive-position: 4898 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs Content-Length: 99 Lines: 4 To be fair I haven't tested the .9, just 7 and 8. But they both are suck on all my hardware :) From owner-linux-xfs@oss.sgi.com Wed Aug 6 13:58:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Aug 2003 13:58:21 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76KvmFl027924 for ; Wed, 6 Aug 2003 13:58:08 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h76Kvhq0014288 for ; Wed, 6 Aug 2003 13:57:43 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h76KugQK5560980 for ; Wed, 6 Aug 2003 15:56:42 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h76KugRn203103344 for ; Wed, 6 Aug 2003 15:56:42 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h76KugE31382; Wed, 6 Aug 2003 15:56:42 -0500 Message-Id: <200308062056.h76KugE31382@jen.americas.sgi.com> Date: Wed, 6 Aug 2003 15:56:42 -0500 Subject: TAKE - more sync changes (one of two) To: linux-xfs@oss.sgi.com X-archive-position: 4899 X-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: 778 Lines: 27 clean up the flush logic some more, make the inode flush path less lossy since we now depend on it. Add a sync_fs callout which waits for flush to be done. The followup fix to this is going to really make a difference, this one is mostly cleanup. Date: Wed Aug 6 13:55:24 PDT 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: xfs-linux:slinx:155186a linux/fs/xfs/xfs_vnodeops.c - 1.599 - in the write_inode path, try harder to get locks on the inode linux/fs/xfs/xfs_vfsops.c - 1.427 - in the sync path, when forcing the log out to disk to cover an old log, pay attention to the sync options used. linux/fs/xfs/linux/xfs_super.c - 1.266 - add sync_fs call From owner-linux-xfs@oss.sgi.com Wed Aug 6 14:19:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Aug 2003 14:19:48 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76LJFFl031412 for ; Wed, 6 Aug 2003 14:19:35 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h76LJ9q0018469 for ; Wed, 6 Aug 2003 14:19:09 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h76LI9QK5559906 for ; Wed, 6 Aug 2003 16:18:09 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h76LI9Rn209701994 for ; Wed, 6 Aug 2003 16:18:09 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h76LI9q31859; Wed, 6 Aug 2003 16:18:09 -0500 Message-Id: <200308062118.h76LI9q31859@jen.americas.sgi.com> Date: Wed, 6 Aug 2003 16:18:09 -0500 Subject: TAKE - fix repeated sync calls on xfs To: linux-xfs@oss.sgi.com X-archive-position: 4900 X-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: 1466 Lines: 48 Add versioning to the on disk inode which we increment on each flush call. This is used during recovery to avoid replaying an older copy of the inode from the log. We can do this without versioning the filesystem as the pad space we borrowed was always zero and will be ignored by old kernels. There is no need for mkfs or any fancy tricks, just boot a new kernel and it works, old kernels will like your filesystems just fine too. Date: Wed Aug 6 14:17:05 PDT 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: xfs-linux:slinx:155189a linux/fs/xfs/xfsidbg.c - 1.232 - print di_flushiter linux/fs/xfs/xfs_log_recover.c - 1.276 - During recovery, do not replay an inode log record which is older than the on disk copy. Check for wrapping in the counter. linux/fs/xfs/xfs_inode.c - 1.382 - when flushing an inode out to disk, bump di_flushiter, if it hits the maximum value, reset it to zero. When pulling in an inode from disk, always propogate di_flushiter to the in memory copy. linux/fs/xfs/xfs_dinode.h - 1.65 - add di_flushiter field to inode core Modid: xfs-cmds:slinx:155189b cmd/xfsprogs/db/inode.c - 1.10 - Print out the new inode field cmd/xfsprogs/logprint/log_print_all.c - 1.10 - print new di_flushiter field cmd/xfsprogs/include/xfs_dinode.h - 1.10 - add new field to the inode core, stolen from the di_pad field From owner-linux-xfs@oss.sgi.com Wed Aug 6 14:26:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Aug 2003 14:27:00 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76LQrFl032619 for ; Wed, 6 Aug 2003 14:26:56 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h76LkYsR030669 for ; Wed, 6 Aug 2003 16:46:34 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h76LQlQK5564963; Wed, 6 Aug 2003 16:26:47 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h76LQlRn213642984; Wed, 6 Aug 2003 16:26:47 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h76LQkD31872; Wed, 6 Aug 2003 16:26:46 -0500 Subject: Re: different behaviour between XFS and ext3 From: Steve Lord To: Blair Barnett Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F283E36.778CC934@mvista.com> References: <3F283E36.778CC934@mvista.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1060205206.31704.5.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 06 Aug 2003 16:26:46 -0500 X-archive-position: 4901 X-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: 766 Lines: 27 On Wed, 2003-07-30 at 16:52, Blair Barnett wrote: > Hi, > > I have a simple shell script that writes numbers to a file and every 10 > numbers does a sync and after 40 does a reboot. I've attached the script > to this email. > > If the file is written to an EXT3 filesystem, then file contains the > numbers 1-40. However, if the file is written to an XFS 1.1,1.2, or 1.3 > filesystem, then file contains the numbers 1-10. > > Can someone tell me if this is a feature of XFS or a bug? > > Thanks, > > Blair This should be fixed in the 2.4 cvs tree now (or within the hour), I will push it into 2.6 tomorrow. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Aug 6 15:26:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Aug 2003 15:26:32 -0700 (PDT) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76MQEFl003650 for ; Wed, 6 Aug 2003 15:26:15 -0700 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <0.0168B901@mailhub2.arup.com>; Wed, 6 Aug 2003 23:26:08 +0100 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Wed, 06 Aug 2003 23:26:07 +0100 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Thu, 07 Aug 2003 08:25:12 +1000 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Thu, 07 Aug 2003 08:22:47 +1000 From: "Scott Fagg" To: Subject: Re: Processes stuck in D state.. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h76MQFFl003651 X-archive-position: 4902 X-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.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 1403 Lines: 40 I'm using rh7.3, rh8.0 and rh9.0 8 and 9 are running stock 2.4.21 + xfs patches and i'm getting fs corruption 7.3 is running the sgi-supplied redhat installer, and it runs flawlessly Scott Fagg Arup Brisbane (07) 3023 6000 >>> Michael Loftis 07/08/2003 5:25:40 AM >>> The whole redhat 2.4.20 kernel is crap. I've had a number of boxes lockup on it. Initially it was the firewall, but then at home I've had other boxes lock up under load with it. 2.4.20-19.x got a little better but was still totally screwed up. Going to a stock 2.4.20 fixed all the issues I've been having. The root of this one is IMHO RH 2.4.20 is actually 2.4.21-pre3 plus a mass of patches. --On Wednesday, August 06, 2003 21:15 +0200 Simon Matter wrote: >> Yah for production go with a kernel as close to stock as posible. Avoid >> anything by redhat in the 2.4.20 series, and you should be fine. In >> other words go get a fresh treee, patch in ONLY the XFS stuff. Don't >> put in low latency/preeempt patches, they still screw everything up. >> And just stay away from RedHate kernels. > > I don't agree. I'm using XFS enabled RedHat for a long time now on several > servers with great success. Are the problem you're talking about always > NFS related? That's the only thing I'm not using alot with the XFS boxes. > > Simon > From owner-linux-xfs@oss.sgi.com Wed Aug 6 16:13:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Aug 2003 16:13:34 -0700 (PDT) Received: from unicorn.drogon.net (unicorn.drogon.net [195.10.246.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76NDHFl004893 for ; Wed, 6 Aug 2003 16:13:19 -0700 Received: from unicorn.drogon.net (localhost [127.0.0.1]) by unicorn.drogon.net (8.12.9/8.12.9) with ESMTP id h76ND6io001075 for ; Thu, 7 Aug 2003 00:13:06 +0100 Received: from localhost (gordon@localhost) by unicorn.drogon.net (8.12.9/8.12.9/Submit) with ESMTP id h76ND6uP001072 for ; Thu, 7 Aug 2003 00:13:06 +0100 X-Authentication-Warning: unicorn.drogon.net: gordon owned process doing -bs Date: Thu, 7 Aug 2003 00:13:06 +0100 (BST) From: Gordon Henderson To: linux-xfs@oss.sgi.com Subject: Re: Processes stuck in D state.. In-Reply-To: <2597.1060167799@ocs3.intra.ocs.com.au> Message-ID: References: <2597.1060167799@ocs3.intra.ocs.com.au> Distribution: world Organization: Home for lost Drogons MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-archive-position: 4903 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gordon@drogon.net Precedence: bulk X-list: linux-xfs Content-Length: 1120 Lines: 29 On Wed, 6 Aug 2003, Keith Owens wrote: > Do not blame XFS for this problem, it is almost certainly an NFS > problem. Maybe my original email was unclear, but this is an NFS server, not a client. Why would an NFS exported filesystem hang xfsdump? (or even du -k ?) ie. 1149 ? D 2:21 xfsdump -F -J -l 1 - /dev/md4 This xfsdump is trying to dump /dev/md4 which is obviously local to the server and it's stuck. Why is it stuck? /dev/md4 itself doesn't appear to be stuck, as I can access files on it both locally and via NFS mounts on other Linux boxes (and samba mounts on Win boxes) BTW: It's a Debian server (3.0 with security updates, I downloaded and compiled xfsprogs and xfsdump rather than use the supplied Debian ones) It's running a stock 2.4.21 kernel patched with Alan Coxes ac4 patches which include XFS. I've heard that these patches are "old" though. Right now I have lots more processes stuck in D state so I'll have to reboot it in the morning. Tomorow, I'll see what the latest snapshot patches on 2.4.21 do, if nothing better then it's back to ext2 for this partucular box )-: Gordon From owner-linux-xfs@oss.sgi.com Wed Aug 6 16:33:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Aug 2003 16:33:25 -0700 (PDT) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76NXJFl005456 for ; Wed, 6 Aug 2003 16:33:20 -0700 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 h76NXH7T020205 for ; Thu, 7 Aug 2003 01:33:17 +0200 Received: (qmail 19737 invoked from network); 7 Aug 2003 01:33:17 +0200 Received: from rx3227.cip.uni-regensburg.de (132.199.237.32) by rss1.rz.uni-regensburg.de with SMTP; 7 Aug 2003 01:33:17 +0200 Subject: Re: Processes stuck in D state.. From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: Gordon Henderson Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <2597.1060167799@ocs3.intra.ocs.com.au> Content-Type: text/plain Message-Id: <1060212797.464.13.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 07 Aug 2003 01:33:17 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 4904 X-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: 1769 Lines: 42 On Thu, 2003-08-07 at 01:13, Gordon Henderson wrote: > On Wed, 6 Aug 2003, Keith Owens wrote: > > > Do not blame XFS for this problem, it is almost certainly an NFS > > problem. > > Maybe my original email was unclear, but this is an NFS server, not a > client. Why would an NFS exported filesystem hang xfsdump? (or even du -k > ?) > ie. > > 1149 ? D 2:21 xfsdump -F -J -l 1 - /dev/md4 > > This xfsdump is trying to dump /dev/md4 which is obviously local to the > server and it's stuck. Why is it stuck? /dev/md4 itself doesn't appear to > be stuck, as I can access files on it both locally and via NFS mounts on > other Linux boxes (and samba mounts on Win boxes) > > BTW: It's a Debian server (3.0 with security updates, I downloaded and > compiled xfsprogs and xfsdump rather than use the supplied Debian ones) > It's running a stock 2.4.21 kernel patched with Alan Coxes ac4 patches > which include XFS. I've heard that these patches are "old" though. Right > now I have lots more processes stuck in D state so I'll have to reboot it > in the morning. I'm running two BIG NFS Servers with xfs only (Debian 3.0, too + recent xfsprogs...). I'm using them since 2.4.19-cvs, and never ever had stuck D states on the Server. But I've been bitten by stuck D's on client side and workstations even w/o nfs with older kernels (Until March's cvs). Now even those seem to be gone. These Servers have hardware RAID rather than Linux MD, so maybe your probs are related to MD + any scsi/ide drivers?!? Give 2.4.21+ xfs-1.3pre a try. (To fix security issues found in 2.4.21, you might want to try debian unstable's kernel-patch-debian (2.4.21-4), but backout the O_DIRECT changes they made in this Release - they won't play nicely with XFS) Christian From owner-linux-xfs@oss.sgi.com Wed Aug 6 18:13:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Aug 2003 18:13:23 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h771D2Fl007831 for ; Wed, 6 Aug 2003 18:13:05 -0700 Received: (qmail 4675 invoked from network); 7 Aug 2003 01:12:58 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 7 Aug 2003 01:12:57 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 8508EC21FD; Thu, 7 Aug 2003 10:45:48 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 797A9140082; Thu, 7 Aug 2003 10:45:48 +1000 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Gordon Henderson Cc: linux-xfs@oss.sgi.com Subject: Re: Processes stuck in D state.. In-reply-to: Your message of "Thu, 07 Aug 2003 00:13:06 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Aug 2003 10:45:47 +1000 Message-ID: <6501.1060217147@ocs3.intra.ocs.com.au> X-archive-position: 4905 X-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: 1163 Lines: 31 On Thu, 7 Aug 2003 00:13:06 +0100 (BST), Gordon Henderson wrote: >Maybe my original email was unclear, but this is an NFS server, not a >client. Why would an NFS exported filesystem hang xfsdump? (or even du -k >?) >ie. > > 1149 ? D 2:21 xfsdump -F -J -l 1 - /dev/md4 > >This xfsdump is trying to dump /dev/md4 which is obviously local to the >server and it's stuck. Why is it stuck? From your original mail: >> 9275 ? D 2:02 du -k >> 10103 ? D 2:26 /usr/bin/find / ( -fstype NFS -o -fstype nfs -o >> 21671 ? D 1:28 /usr/bin/rsync -a --delete -H -x . >> /mounts/local0.yesterday/ >> 13976 ? D 1:16 du -k >> 14776 ? D 1:59 /usr/bin/find / ( -fstype NFS -o -fstype nfs -o All operations that require filesystem locks. They are queued up behind some task that has grabbed a filesystem lock and is hung, IOW these tasks are innocent victims of the real problem. 99.9% probability that the real problem is a hung NFS event. If you have kdb installed and active, drop into kdb and set LOGGING 1 bta RD go The trace will show what the hung tasks are waiting on. From owner-linux-xfs@oss.sgi.com Wed Aug 6 20:03:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Aug 2003 20:03:38 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7733HFl014522 for ; Wed, 6 Aug 2003 20:03:18 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7733Bq0008157 for ; Wed, 6 Aug 2003 20:03:12 -0700 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h7733MLu002164 for ; Thu, 7 Aug 2003 13:03:22 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h7733L96002163 for linux-xfs@oss.sgi.com; Thu, 7 Aug 2003 13:03:21 +1000 Date: Thu, 7 Aug 2003 13:03:21 +1000 From: Nathan Scott Message-Id: <200308070303.h7733L96002163@bruce.melbourne.sgi.com> Subject: TAKE - xfsprogs version bump X-archive-position: 4906 X-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@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 369 Lines: 14 Bump xfsprogs version to 2.5.5 for XFS 1.3 release. Date: Wed Aug 6 20:01:53 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/nathans/isms/devel26 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: xfs-cmds:slinx:155232a cmd/xfsprogs/VERSION - 1.85 cmd/xfsprogs/doc/CHANGES - 1.123 cmd/xfsprogs/debian/changelog - 1.78 From owner-linux-xfs@oss.sgi.com Wed Aug 6 20:03:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Aug 2003 20:03:39 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7733UFl014544 for ; Wed, 6 Aug 2003 20:03:30 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7733Oq0008199 for ; Wed, 6 Aug 2003 20:03:25 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7733OQK5617558; Wed, 6 Aug 2003 22:03:24 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-16.corp.sgi.com [134.15.64.16]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7733MRn211424377; Wed, 6 Aug 2003 22:03:23 -0500 (CDT) Subject: Re: Processes stuck in D state.. From: Steve Lord To: Gordon Henderson Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <2597.1060167799@ocs3.intra.ocs.com.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 06 Aug 2003 22:03:34 -0500 Message-Id: <1060225416.1776.2.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 4907 X-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: 883 Lines: 22 On Wed, 2003-08-06 at 18:13, Gordon Henderson wrote: > BTW: It's a Debian server (3.0 with security updates, I downloaded and > compiled xfsprogs and xfsdump rather than use the supplied Debian ones) > It's running a stock 2.4.21 kernel patched with Alan Coxes ac4 patches > which include XFS. I've heard that these patches are "old" though. Right > now I have lots more processes stuck in D state so I'll have to reboot it > in the morning. > This combination of code may be the problem - ac patches and xfs, the version of xfs in Alan's tree probably has had less testing than any other combination out there. It has almost certainly degenerated into unbuildable code by now, we have not had the bandwidth to keep it upto date. First thing I would do would be to move to a different code base. If there is something specific in the ac tree you need, that gets harder. Steve From owner-linux-xfs@oss.sgi.com Thu Aug 7 01:26:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 01:26:46 -0700 (PDT) Received: from unicorn.drogon.net (unicorn.drogon.net [195.10.246.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h778QQFl003070 for ; Thu, 7 Aug 2003 01:26:28 -0700 Received: from unicorn.drogon.net (localhost [127.0.0.1]) by unicorn.drogon.net (8.12.9/8.12.9) with ESMTP id h778QIio002993 for ; Thu, 7 Aug 2003 09:26:18 +0100 Received: from localhost (gordon@localhost) by unicorn.drogon.net (8.12.9/8.12.9/Submit) with ESMTP id h778QISA002990 for ; Thu, 7 Aug 2003 09:26:18 +0100 X-Authentication-Warning: unicorn.drogon.net: gordon owned process doing -bs Date: Thu, 7 Aug 2003 09:26:18 +0100 (BST) From: Gordon Henderson To: linux-xfs@oss.sgi.com Subject: Re: Processes stuck in D state.. In-Reply-To: <6501.1060217147@ocs3.intra.ocs.com.au> Message-ID: References: <6501.1060217147@ocs3.intra.ocs.com.au> Distribution: world Organization: Home for lost Drogons MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-archive-position: 4908 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gordon@drogon.net Precedence: bulk X-list: linux-xfs Content-Length: 940 Lines: 27 On Thu, 7 Aug 2003, Keith Owens wrote: > All operations that require filesystem locks. They are queued up > behind some task that has grabbed a filesystem lock and is hung, IOW > these tasks are innocent victims of the real problem. 99.9% > probability that the real problem is a hung NFS event. OK. > If you have kdb installed and active, drop into kdb and > set LOGGING 1 > bta RD > go > The trace will show what the hung tasks are waiting on. I can't easilly do this - it's a production box and they won't afford me the dowtime. I'll try the latest patches against a 2.4.21 kernel (but I'm not sure if I need the AC patches or not with .21, I'll need to check - I needed an AC-1 patch for 2.4.20 to get the Promise IDE controllers to work) Otherwise, it's back to ext2 for this. It ran solidly with ext2 and 2.4.20-ac1 for about 6 months before I tried XFS, and the only thing thats changed is the kernel. Thanks, Gordon From owner-linux-xfs@oss.sgi.com Thu Aug 7 05:32:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 05:33:04 -0700 (PDT) Received: from woozle.fnal.gov (woozle.fnal.gov [131.225.9.22]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77CWlFl010765 for ; Thu, 7 Aug 2003 05:32:47 -0700 Received: from fnal.gov (imapserver2.fnal.gov [131.225.9.17]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTP id <0HJ90044U1IMEO@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Thu, 07 Aug 2003 07:32:46 -0500 (CDT) Date: Thu, 07 Aug 2003 07:32:45 -0500 From: yocum@fnal.gov Subject: Re: Processes stuck in D state.. To: Keith Owens Cc: Gordon Henderson , linux-xfs@oss.sgi.com Message-id: <2785e27e01.27e012785e@fnal.gov> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-archive-position: 4909 X-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: 1637 Lines: 54 Betcha a nickel there's an automount process that's in uninterruptable sleep, too. 'service autofs restart' will get autofs going again with a duplicate process, but the original hung automount will hang around until you reboot. Cheers, Dan ----- Original Message ----- From: Keith Owens Date: Wednesday, August 6, 2003 7:45 pm Subject: Re: Processes stuck in D state.. > On Thu, 7 Aug 2003 00:13:06 +0100 (BST), > Gordon Henderson wrote: > >Maybe my original email was unclear, but this is an NFS server, > not a > >client. Why would an NFS exported filesystem hang xfsdump? (or > even du -k > >?) > >ie. > > > > 1149 ? D 2:21 xfsdump -F -J -l 1 - /dev/md4 > > > >This xfsdump is trying to dump /dev/md4 which is obviously local > to the > >server and it's stuck. Why is it stuck? > > From your original mail: > > >> 9275 ? D 2:02 du -k > >> 10103 ? D 2:26 /usr/bin/find / ( -fstype NFS -o - > fstype nfs -o > >> 21671 ? D 1:28 /usr/bin/rsync -a --delete -H -x . > >> /mounts/local0.yesterday/ > >> 13976 ? D 1:16 du -k > >> 14776 ? D 1:59 /usr/bin/find / ( -fstype NFS -o - > fstype nfs -o > > All operations that require filesystem locks. They are queued up > behind some task that has grabbed a filesystem lock and is hung, IOW > these tasks are innocent victims of the real problem. 99.9% > probability that the real problem is a hung NFS event. > > If you have kdb installed and active, drop into kdb and > set LOGGING 1 > bta RD > go > The trace will show what the hung tasks are waiting on. > > > From owner-linux-xfs@oss.sgi.com Thu Aug 7 05:37:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 05:38:44 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77CbRFl011233 for ; Thu, 7 Aug 2003 05:37:42 -0700 Received: from mail-veri.imag.fr (pave.imag.fr [129.88.43.12]) by imag.imag.fr (8.12.9/8.12.9) with ESMTP id h77B80Eg002946 for ; Thu, 7 Aug 2003 13:08:00 +0200 (CEST) Received: from astazou.imag.fr ([129.88.43.102] helo=astazou.imag.fr.imag.fr ident=kowalski) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 19kici-0003s7-00 for ; Thu, 07 Aug 2003 13:08:00 +0200 To: linux-xfs@oss.sgi.com Subject: Re: Processes stuck in D state.. References: <2597.1060167799@ocs3.intra.ocs.com.au> From: Nicolas Kowalski Date: Thu, 07 Aug 2003 13:07:49 +0200 In-Reply-To: (Gordon Henderson's message of "Thu, 7 Aug 2003 00:13:06 +0100 (BST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Common Lisp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner: Found to be clean X-MailScanner-Information: Please contact the ISP for more information X-archive-position: 4910 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 505 Lines: 18 Gordon Henderson writes: [...] > Tomorow, I'll see what the latest snapshot patches on 2.4.21 do, if > nothing better then it's back to ext2 for this partucular box )-: For information, I have setup a Debian Woody + SGI-XFS (CVS-2003-08-07_05:00_UTC) - without any third-party patches - fileserver with software raid0 devices (2*36Gb SCSI disks, symbios driver) for backup purposes. I am currently running an xfsdump session on the /dev/md0 device and it works fine. -- Nicolas From owner-linux-xfs@oss.sgi.com Thu Aug 7 06:33:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 06:33:38 -0700 (PDT) Received: from unicorn.drogon.net (unicorn.drogon.net [195.10.246.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77DXMFl015626 for ; Thu, 7 Aug 2003 06:33:23 -0700 Received: from unicorn.drogon.net (localhost [127.0.0.1]) by unicorn.drogon.net (8.12.9/8.12.9) with ESMTP id h77DXEio004797 for ; Thu, 7 Aug 2003 14:33:14 +0100 Received: from localhost (gordon@localhost) by unicorn.drogon.net (8.12.9/8.12.9/Submit) with ESMTP id h77DXECc004794 for ; Thu, 7 Aug 2003 14:33:14 +0100 X-Authentication-Warning: unicorn.drogon.net: gordon owned process doing -bs Date: Thu, 7 Aug 2003 14:33:14 +0100 (BST) From: Gordon Henderson To: linux-xfs@oss.sgi.com Subject: Re: Processes stuck in D state.. In-Reply-To: <2785e27e01.27e012785e@fnal.gov> Message-ID: References: <2785e27e01.27e012785e@fnal.gov> Distribution: world Organization: Home for lost Drogons MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-archive-position: 4911 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gordon@drogon.net Precedence: bulk X-list: linux-xfs Content-Length: 1476 Lines: 42 On Thu, 7 Aug 2003 yocum@fnal.gov wrote: > Betcha a nickel there's an automount process that's in uninterruptable > sleep, too. 'service autofs restart' will get autofs going again with a > duplicate process, but the original hung automount will hang around > until you reboot. Bet you a euro there aren't ;-) There are no automount processes, and no automounter at all - it's not compiled into the kernel. % fgrep -i auto .config # Automatically generated by make menuconfig: don't edit CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_HPT34X_AUTODMA is not set CONFIG_IDEDMA_AUTO=y # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set What I'm having difficulty with right now is identifying what the version number of the kernel patch is. I'm being advised to try "xfs-1.3pre" but where/how do I get it? I've just downloaded a patch from: ftp://oss.sgi.com/projects/xfs/patches/2.4.21-2003-07-07_02%3A01_UTC But exactly what is this? I followed the runes to download everything via CVS, but that started to download an entire 2.4.21 kernel source tree and as I'm not on a particularly fast link where I am, I couldn't let it finish, alas. I might be able to do it overnight, then the differences ought to be minimal once I have the whole thing. Anyway, I've applied the above patch to a pristine 2.4.21 kernel, which does appear to support the Promise cards (and the on-board IDE controller) rebooted and am now hoping for the best... Thanks, Gordon From owner-linux-xfs@oss.sgi.com Thu Aug 7 06:50:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 06:50:15 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77DoAFl016197 for ; Thu, 7 Aug 2003 06:50:11 -0700 Received: (qmail 15053 invoked from network); 7 Aug 2003 13:50:06 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 7 Aug 2003 13:50:06 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 407E1C02E0; Thu, 7 Aug 2003 23:50:03 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 3D3331406E8; Thu, 7 Aug 2003 23:50:03 +1000 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Gordon Henderson Cc: linux-xfs@oss.sgi.com Subject: Re: Processes stuck in D state.. In-reply-to: Your message of "Thu, 07 Aug 2003 14:33:14 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Aug 2003 23:50:02 +1000 Message-ID: <6812.1060264202@ocs3.intra.ocs.com.au> X-archive-position: 4912 X-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: 611 Lines: 19 On Thu, 7 Aug 2003 14:33:14 +0100 (BST), Gordon Henderson wrote: >What I'm having difficulty with right now is identifying what the version >number of the kernel patch is. I'm being advised to try "xfs-1.3pre" but >where/how do I get it? XFS 1.n are full blown XFS releases, typically involving an installer to go in front of a Redhat install. >I've just downloaded a patch from: > > ftp://oss.sgi.com/projects/xfs/patches/2.4.21-2003-07-07_02:01_UTC > >But exactly what is this? Wild suggestion. Read the README. 2.4.21-2003-07-07_02:01_UTC is an old patch set, 2.4.21 is current. From owner-linux-xfs@oss.sgi.com Thu Aug 7 12:52:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 12:52:40 -0700 (PDT) Received: from ftp.sicredi.com.br (ipcorp-C8B071B2.terraempresas.com.br [200.176.113.178] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77JqKFl012338 for ; Thu, 7 Aug 2003 12:52:21 -0700 Received: from no.name.available by ftp.sicredi.com.br via smtpd (for oss.SGI.COM [192.48.159.27]) with SMTP; 7 Aug 2003 19:51:11 UT Received: from wobiwan (localhost [127.0.0.1]) by isvwlx.local (8.12.3/8.12.2/SuSE Linux 0.6) with SMTP id h77JfNMt030420 for ; Thu, 7 Aug 2003 16:41:24 -0300 Received: from webmail.sicredi.com.br by wobiwan via smtpd (for [192.168.1.20]) with SMTP; 7 Aug 2003 19:51:09 UT Received: from localhost (localhost [127.0.0.1]) by mailsvr.sicredi.com.br (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 7547AA88 for ; Thu, 7 Aug 2003 16:46:14 -0300 (BRT) Received: from sicredi.com.br (tec-aduarte.sicredi.com.br [10.1.10.6]) by mailsvr.sicredi.com.br (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id CEDE9A86 for ; Thu, 7 Aug 2003 16:46:08 -0300 (BRT) Message-ID: <3F32ADB5.50108@sicredi.com.br> Date: Thu, 07 Aug 2003 16:51:17 -0300 From: Andriei Duarte User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: simple question Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 X-archive-position: 4913 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andriei@sicredi.com.br Precedence: bulk X-list: linux-xfs Content-Length: 227 Lines: 13 Hi, I don't wanna busy you. Can you give me a simple example to how can I configure quotas on XFS partition. Example: all users must have only 200MB on their home (/home). Thanx Andriei Ramos Duarte From owner-linux-xfs@oss.sgi.com Thu Aug 7 13:33:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 13:34:14 -0700 (PDT) Received: from mail.mnsu.edu (Mail.MNSU.EDU [134.29.1.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77KXtFl016538 for ; Thu, 7 Aug 2003 13:33:56 -0700 Received: from mnsu.edu (j3gum-3.MNSU.EDU [134.29.1.30]) by mail.mnsu.edu (8.12.9/8.12.9) with ESMTP id h77KXneN019213 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Aug 2003 15:33:50 -0500 Message-ID: <3F32B7AD.8040905@mnsu.edu> Date: Thu, 07 Aug 2003 15:33:49 -0500 From: "Jeffrey E. Hundstad" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: OT?: simple question 2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4914 X-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: 335 Lines: 11 I've got a program that takes a video stream and writes it to disk. What can I do to force it to avoid the buffer cache. The cache is only going to hurt my performance. Is there a write option or a ioctl that hints to how your going to use a file for XFS? Where do I find documentaion on these features. -- jeffrey hundstad From owner-linux-xfs@oss.sgi.com Thu Aug 7 13:50:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 13:51:06 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77KomFl018123 for ; Thu, 7 Aug 2003 13:50:49 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h77LAXsR009640 for ; Thu, 7 Aug 2003 16:10:33 -0500 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h77KogQK5810569; Thu, 7 Aug 2003 15:50:43 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h77Kogwg16791644; Thu, 7 Aug 2003 15:50:42 -0500 (CDT) Subject: Re: OT?: simple question 2 From: Eric Sandeen To: "Jeffrey E. Hundstad" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F32B7AD.8040905@mnsu.edu> References: <3F32B7AD.8040905@mnsu.edu> Content-Type: text/plain Organization: Message-Id: <1060289441.10186.65.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 07 Aug 2003 15:50:42 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 4915 X-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: 581 Lines: 18 On Thu, 2003-08-07 at 15:33, Jeffrey E. Hundstad wrote: > I've got a program that takes a video stream and writes it to disk. > What can I do to force it to avoid the buffer cache. The cache is only > going to hurt my performance. You probably want O_DIRECT > Is there a write option or a ioctl that hints to how your going to use a > file for XFS? Where do I find documentaion on these features. >From a recent xfsprogs, see man xfsctl(3) -Eric -- Eric Sandeen [C]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 Aug 7 13:59:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 14:00:09 -0700 (PDT) Received: from localhost.fsl.noaa.gov (woody.fsl.noaa.gov [137.75.132.225]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77KxrFl019090 for ; Thu, 7 Aug 2003 13:59:54 -0700 Received: from localhost (localhost [127.0.0.1]) by localhost.fsl.noaa.gov (8.12.5/8.12.5) with ESMTP id h77L0xnA011524; Thu, 7 Aug 2003 15:01:00 -0600 Subject: Re: simple question From: Craig Tierney To: Andriei Duarte Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F32ADB5.50108@sicredi.com.br> References: <3F32ADB5.50108@sicredi.com.br> Content-Type: text/plain Organization: Message-Id: <1060290058.11189.40.camel@woody> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Aug 2003 15:00:59 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 4916 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctierney@hpti.com Precedence: bulk X-list: linux-xfs Content-Length: 528 Lines: 25 On Thu, 2003-08-07 at 13:51, Andriei Duarte wrote: > Hi, I don't wanna busy you. > > Can you give me a simple example to how can I configure quotas on > XFS partition. > > Example: > all users must have only 200MB on their home (/home). > Make sure you have quota support built into the kernel for XFS. Make sure you have a more recent version of rquotad. See the quota howto. http://www.tldp.org/HOWTO/Quota.html Craig > > Thanx > > Andriei Ramos Duarte -- Craig Tierney From owner-linux-xfs@oss.sgi.com Thu Aug 7 16:59:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 16:59:48 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77NxZFl031225 for ; Thu, 7 Aug 2003 16:59:35 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h77NxTq0006355 for ; Thu, 7 Aug 2003 16:59:30 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h77NxTQK5811631 for ; Thu, 7 Aug 2003 18:59:29 -0500 (CDT) Received: from naboo (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h77NxPRn218193639 for ; Thu, 7 Aug 2003 18:59:29 -0500 (CDT) Subject: [ANNOUNC] linux-2.4+xfs tree From: Russell Cattelan To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1060300430.24377.64.camel@naboo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3-2mdk Date: 07 Aug 2003 18:53:50 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 4917 X-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: 323 Lines: 13 Just a quick note anybody who wants to play with xfs on 2.4.22 can grab this BitKeeper tree. bk clone http://xfs.org:8090/linux-2.4+xfs I think the tree has all the correct bits in it but I'm late for something so I don't have time to test it tonight. If anybody is feeling brave check it out and report back. -Russell From owner-linux-xfs@oss.sgi.com Thu Aug 7 17:24:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 17:24:26 -0700 (PDT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h780OKFl032592 for ; Thu, 7 Aug 2003 17:24:21 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 47E3DEB4A04 for ; Fri, 8 Aug 2003 08:24:09 +0800 (PHT) Received: by gusi.leathercollection.ph (Postfix, from userid 1000) id F2BECEB4A00; Fri, 8 Aug 2003 08:23:58 +0800 (PHT) Date: Fri, 8 Aug 2003 08:23:58 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List Subject: Filesystem Benchmarks (2.6.0-test2) Message-ID: <20030808002358.GB29758@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-archive-position: 4918 X-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: 2145 Lines: 47 Hi everyone, I don't know how much of a waste of time benchmarks are, but KernelTrap is running an article[1] on benchmarks done by Grant Miner (as posted on the LKML) comparing the following journalling filesystems for Linux using kernel 2.6.0-test2: Reiser4, ReiserFS, ext3, XFS and JFS. [1] http://kerneltrap.org/node/view/715 The summary of the tests is as follows (not my words): - ext3's syncs tended to take the longest [at] 10 seconds, except - JFS took a whopping 38.18s on its final sync - xfs used more CPU than ext3 but was slower than ext3 - reiser4 had highest throughput and most CPU usage - jfs had lowest throughput and least CPU usage A comment in the KernelTrap thread that follows is also not very reassuring. It's unfortunately by an anonymous poster, though, so I guess we take this with more than just a grain of salt. To wit: "Ah, but I lost a couple of filesystems using XFS. Switching back to ext3 on the same machine solved all corruption problems and the machine is still running today. It crashed three times in production as soon as XFS got a little load. Two times it was completly impossible to recover the filesystem with the xfs tools and I had to restore from backup. That turned a two minute reboot process which most people wouldn't notice into a two hour restore process which everybody noticed. "I used to admin Irix systems and I loved them (though I disagree with the commercial "discipline"). And I used to be a big fan of XFS but I think they have some problems to solve before I'll try it in production again. "In short, my using ext3 isn't because it's convenient, it's because it's both a journaled filesystem and it has the heritage of the stable ext2 code. XFS will run fine under desktop or light loads, but for server's I'd suggest treading carefully." --> Jijo -- 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 Thu Aug 7 17:37:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 17:37:13 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h780b2Fl001009 for ; Thu, 7 Aug 2003 17:37:02 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h780ulsR022602 for ; Thu, 7 Aug 2003 19:56:47 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h780asQK5821394; Thu, 7 Aug 2003 19:36:54 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-74.corp.sgi.com [134.15.64.74]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h780arRn214386388; Thu, 7 Aug 2003 19:36:53 -0500 (CDT) Subject: Re: Filesystem Benchmarks (2.6.0-test2) From: Steve Lord To: Federico Sevilla III Cc: Linux-XFS Mailing List In-Reply-To: <20030808002358.GB29758@leathercollection.ph> References: <20030808002358.GB29758@leathercollection.ph> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 07 Aug 2003 19:36:52 -0500 Message-Id: <1060303013.1766.65.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 4919 X-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: 2308 Lines: 54 On Thu, 2003-08-07 at 19:23, Federico Sevilla III wrote: > Hi everyone, > > I don't know how much of a waste of time benchmarks are, but KernelTrap > is running an article[1] on benchmarks done by Grant Miner (as posted on > the LKML) comparing the following journalling filesystems for Linux > using kernel 2.6.0-test2: Reiser4, ReiserFS, ext3, XFS and JFS. > > [1] http://kerneltrap.org/node/view/715 > > The summary of the tests is as follows (not my words): > > - ext3's syncs tended to take the longest [at] 10 seconds, except > - JFS took a whopping 38.18s on its final sync > - xfs used more CPU than ext3 but was slower than ext3 > - reiser4 had highest throughput and most CPU usage > - jfs had lowest throughput and least CPU usage > > A comment in the KernelTrap thread that follows is also not very > reassuring. It's unfortunately by an anonymous poster, though, so I > guess we take this with more than just a grain of salt. To wit: > > "Ah, but I lost a couple of filesystems using XFS. Switching back to > ext3 on the same machine solved all corruption problems and the > machine is still running today. It crashed three times in production > as soon as XFS got a little load. Two times it was completly > impossible to recover the filesystem with the xfs tools and I had to > restore from backup. That turned a two minute reboot process which > most people wouldn't notice into a two hour restore process which > everybody noticed. > > "I used to admin Irix systems and I loved them (though I disagree > with the commercial "discipline"). And I used to be a big fan of XFS > but I think they have some problems to solve before I'll try it in > production again. > > "In short, my using ext3 isn't because it's convenient, it's because > it's both a journaled filesystem and it has the heritage of the > stable ext2 code. XFS will run fine under desktop or light loads, > but for server's I'd suggest treading carefully." > > --> Jijo > Grr, test2 still has problems, xfs is pretty stable in 2.4, but not always so stable in 2.6. There are more fixes coming in test3. Any anyone running a server in production on 2.6 yet needs their head examining. Thanks for the pointer though. Steve From owner-linux-xfs@oss.sgi.com Thu Aug 7 17:45:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 17:45:07 -0700 (PDT) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h780j2Fl001574 for ; Thu, 7 Aug 2003 17:45:03 -0700 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <0.0169551D@mailhub2.arup.com>; Fri, 8 Aug 2003 1:13:26 +0100 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Fri, 08 Aug 2003 01:13:25 +0100 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Fri, 08 Aug 2003 10:12:29 +1000 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Fri, 08 Aug 2003 10:11:00 +1000 From: "Scott Fagg" To: Subject: Re: kernel errors when XFS filesystem fills up Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h780j3Fl001577 X-archive-position: 4920 X-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.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 2525 Lines: 65 I used a newer patch ( August 7 ) for 2.4.21 and it would appear to have solved the problem. I was suprised that i didn't receive any responses to my query. Was this not the right place to report this sort of thing ? Scott Fagg Arup Brisbane (07) 3023 6000 >>> "Scott Fagg" 04/08/2003 11:40:56 AM >>> I'm getting message like those shown below from dmesg when my XFS filesystems fill up. - happens when the file system completely runs out of space, ie 0 bytes free. - doesn't seem to be any other ill effects ( no oops, no panic ) but the app copying the file crashes ( e.g. cp or rsync will crash ) - happening on both Redhat8.0 2.4.21-xfs ( on raid5 compaq hardware) and Redhat 9.0 2.4.21-xfs ( on plain IDE ) Once the error happens once, i then start to get the same error even when the filesystem is no longer full. Only solution seems to be to reformat the filesystem as xfs_check and xfs_repair don't help. Any thoughts ? Any more info i can provide ? regards, xfs_da_do_buf: bno 0 dir: inode 4688490 Filesystem "ida0(72,17)": XFS internal error xfs_da_do_buf(1) at line 2184 of file xfs_da_btree.c. Caller 0xc01952d7 cd797cc8 c0194b81 c02b1f5d 00000001 cfe6e400 c02b1eb8 00000888 c01952d7 c3c6dd40 cf741868 0000a201 00002000 0001a201 c3c6dd40 0023c530 00000001 00000000 cfe6e400 cd797d3c c01c4def 000003de 0023c530 00000000 00000010 Call Trace: [] xfs_da_do_buf+0x211/0x8b0 [kernel] [] xfs_da_read_buf+0x57/0x60 [kernel] [] xfs_trans_read_buf+0x33f/0x3a0 [kernel] [] xfs_itobp+0xf1/0x270 [kernel] [] xfs_da_read_buf+0x57/0x60 [kernel] [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] [] xfs_attr_node_get+0x3c/0xd0 [kernel] [] xfs_attr_fetch+0xff/0x1b0 [kernel] [] xfs_acl_iaccess+0x54/0xe0 [kernel] [] xfs_dir2_put_dirent64_direct+0x0/0xa0 [kernel] [] xfs_iaccess+0x19c/0x1b0 [kernel] [] xfs_access+0x3b/0x60 [kernel] [] linvfs_permission+0x29/0x30 [kernel] [] permission+0x3a/0x40 [kernel] [] link_path_walk+0x60/0x6e0 [kernel] [] path_lookup+0x39/0x40 [kernel] [] open_namei+0x70/0x5d0 [kernel] [] filp_open+0x43/0x70 [kernel] [] sys_open+0x53/0xa0 [kernel] [] system_call+0x33/0x38 [kernel] Scott Fagg Arup Brisbane (07) 3023 6000 From owner-linux-xfs@oss.sgi.com Thu Aug 7 17:59:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 17:59:27 -0700 (PDT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h780xKFl002083 for ; Thu, 7 Aug 2003 17:59:21 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id B414DEB4A03 for ; Fri, 8 Aug 2003 08:59:14 +0800 (PHT) Received: by gusi.leathercollection.ph (Postfix, from userid 1000) id A6472EB4A00; Fri, 8 Aug 2003 08:59:04 +0800 (PHT) Date: Fri, 8 Aug 2003 08:59:04 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List Subject: Re: Filesystem Benchmarks (2.6.0-test2) Message-ID: <20030808005904.GA3068@leathercollection.ph> Mail-Followup-To: Linux-XFS Mailing List References: <20030808002358.GB29758@leathercollection.ph> <1060303013.1766.65.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1060303013.1766.65.camel@laptop.americas.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.4i X-archive-position: 4921 X-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: 3518 Lines: 76 On Thu, Aug 07, 2003 at 07:36:52PM -0500, Steve Lord wrote: > Grr, test2 still has problems, xfs is pretty stable in 2.4, but not > always so stable in 2.6. There are more fixes coming in test3. I agree about XFS being pretty stable in 2.4 (since I use it, and so far so good). I haven't used 2.6, though, so I was unaware of the XFS-specific problems. I know how to read "test" though, so I guess problems in general are to be expected. BTW, out of curiosity, do you think the pending fixes (to be seen in test3) have anything to do with the performance bits as reported in the benchmarks done by Grant Miner? Or perhaps as an expert on filesystems you have comments with respect to the methods employed (eg: were the tests done sane/fair)? "No comment" will be fine, too. I understand you're probably very busy. > Any anyone running a server in production on 2.6 yet needs their head > examining. I agree wholeheartedly. I don't think the Anonymous poster I quoted mentioning his shift to ext3 from XFS was talking about 2.6, though. That bit seemed to be about XFS in general (eg: 2.4). No mention of what version of XFS and the Linux kernel that poster used last, though. From discussions on this list I know that matters significantly. Maybe I should post on KernelTrap to ask more about the stability problems the Anonymous poster experienced. I forgot to mention a more reassuring bit (except perhaps for the last paragraph) posted by yet another Anonymous poster in the same KernelTrap thread. To wit: Subject: Notice very short SYNC times on XFS Author: Anonymous Date: Thu, 08/07/2003 - 11:51 That's because it is a real journaling filesystem. Sorry to break it to you all. Try ripping out the disks during your script and then seeing which one really need not fsck. I'll put money on JFS and XFS. XFS is the best filesystem available for Linux - and that's too bad people got behind ext3 because it is convenient. Some will say that XFS is hacked into Linux from IRIX - good! Any commercial discipline rubbing off into the Linux kernel is a good thing. Ever hear about those strange bugs involving laptops and EXT3 corruption? I'm also upset that RedHat still refuses to make it easy to get XFS running on out of the box installs. I'll continue to use FreeBSD wherever possible until committing to and the using of Linux becomes more of a meritocracy than a popularity contest/Mobocracy penguin logos and think geek shirts with penguins and Slashdot fan-boys. > Thanks for the pointer though. I don't know if I should say "you're welcome". I think if there's anything that still lets me read these things (benchmarks), it's that they're not always consistent and it's hard to tell which methods are believable and which aren't. In my personal experience, for example, XFS seems to kick ext3's ass. The presence of big-time XFS users also gives one something of a warm fuzzy feeling (going through xfs_users.html is a nice thing every now and then). The recurring surfacing of stability issues during these supposedly performance-centric discussions also makes one (lay-person) wonder: is something wrong with XFS or did this person just do things really wrong with his setup? --> Jijo -- 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 Thu Aug 7 18:05:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 18:05:52 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7815nFl002956 for ; Thu, 7 Aug 2003 18:05:49 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7815hq0017901 for ; Thu, 7 Aug 2003 18:05:44 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7815gQK5854607; Thu, 7 Aug 2003 20:05:42 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-74.corp.sgi.com [134.15.64.74]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7815fRn216152942; Thu, 7 Aug 2003 20:05:42 -0500 (CDT) Subject: Re: kernel errors when XFS filesystem fills up From: Steve Lord To: Scott Fagg 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-11) Date: 07 Aug 2003 20:05:40 -0500 Message-Id: <1060304741.2005.3.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 4922 X-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: 510 Lines: 18 On Thu, 2003-08-07 at 19:11, Scott Fagg wrote: > > I used a newer patch ( August 7 ) for 2.4.21 and it would appear to have solved the problem. > > I was suprised that i didn't receive any responses to my query. Was this not the right place to report this sort of thing ? > > Scott Fagg > Arup Brisbane > (07) 3023 6000 > Sorry about that, yes, right place, we are just very busy right now with other projects. Glad things worked out for you and thanks for persevering. Steve From owner-linux-xfs@oss.sgi.com Thu Aug 7 18:56:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 18:57:04 -0700 (PDT) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h781umFl003636 for ; Thu, 7 Aug 2003 18:56:49 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h77Nv9Qa027408 for ; Thu, 7 Aug 2003 16:57:09 -0700 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h781urYh005735 for ; Fri, 8 Aug 2003 11:56:53 +1000 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h781ujmw005734 for linux-xfs@oss.sgi.com; Fri, 8 Aug 2003 11:56:45 +1000 Date: Fri, 8 Aug 2003 11:56:45 +1000 From: FSG QA Message-Id: <200308080156.h781ujmw005734@bruce.melbourne.sgi.com> Subject: TAKE - xfstests X-archive-position: 4923 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 539 Lines: 20 Add a test to exercise concurrent block device reads and filesystem activity. Testing a specific condition in 2.6 kernels, but its a generally useful test (basically cat's the device while running fsstress on it at the same time). -- nathans Date: Thu Aug 7 18:53:43 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/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:155352a cmd/xfstests/076 - 1.1 cmd/xfstests/076.out - 1.1 cmd/xfstests/group - 1.37 From owner-linux-xfs@oss.sgi.com Thu Aug 7 19:05:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 19:05:19 -0700 (PDT) Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7825EFl004158 for ; Thu, 7 Aug 2003 19:05:14 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id TAA21688; Thu, 7 Aug 2003 19:04:57 -0700 Message-ID: <3F330378.9C5842E1@mvista.com> Date: Thu, 07 Aug 2003 18:57:12 -0700 From: Blair Barnett Organization: Monta Vista Software, Inc X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: different behaviour between XFS and ext3 References: <3F283E36.778CC934@mvista.com> <1060205206.31704.5.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4924 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bbarnett@mvista.com Precedence: bulk X-list: linux-xfs Content-Length: 1028 Lines: 37 Hi Steve, I downloaded the 2.4 cvs tree, built a kernel, and tested my script on the same system that failed before. The script worked as expected. Thanks for fixing this problem so quickly! -blair Steve Lord wrote: > On Wed, 2003-07-30 at 16:52, Blair Barnett wrote: > > Hi, > > > > I have a simple shell script that writes numbers to a file and every 10 > > numbers does a sync and after 40 does a reboot. I've attached the script > > to this email. > > > > If the file is written to an EXT3 filesystem, then file contains the > > numbers 1-40. However, if the file is written to an XFS 1.1,1.2, or 1.3 > > filesystem, then file contains the numbers 1-10. > > > > Can someone tell me if this is a feature of XFS or a bug? > > > > Thanks, > > > > Blair > > This should be fixed in the 2.4 cvs tree now (or within the hour), I > will push it into 2.6 tomorrow. > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Aug 7 19:15:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 19:15:28 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h782FOFl010832 for ; Thu, 7 Aug 2003 19:15:24 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h782FHq0031045 for ; Thu, 7 Aug 2003 19:15:18 -0700 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 MAA01783; Fri, 8 Aug 2003 12:14:45 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h782Ds3K261723; Fri, 8 Aug 2003 12:14:14 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h782CWGi001500; Fri, 8 Aug 2003 12:12:32 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h782Bgxi001498; Fri, 8 Aug 2003 12:11:42 +1000 Date: Fri, 8 Aug 2003 12:11:42 +1000 From: Nathan Scott To: Andriei Duarte , Craig Tierney Cc: linux-xfs@oss.sgi.com Subject: Re: simple question Message-ID: <20030808021142.GA1124@frodo> References: <3F32ADB5.50108@sicredi.com.br> <1060290058.11189.40.camel@woody> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1060290058.11189.40.camel@woody> User-Agent: Mutt/1.5.3i X-archive-position: 4925 X-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: 918 Lines: 32 On Thu, Aug 07, 2003 at 03:00:59PM -0600, Craig Tierney wrote: > On Thu, 2003-08-07 at 13:51, Andriei Duarte wrote: > > Hi, I don't wanna busy you. > > > > Can you give me a simple example to how can I configure quotas on > > XFS partition. > > > > Example: > > all users must have only 200MB on their home (/home). > > > Make sure you have quota support built into the kernel > for XFS. Make sure you have a more recent version > of rquotad. > > See the quota howto. > > http://www.tldp.org/HOWTO/Quota.html > This document doesn't discuss some of the XFS specifics, though it does tell you how to edit quota, report them, etc. With XFS, there is no quotaon and no quotacheck program, quota is enabled only through mount options. A more authorative reference is the xfsprogs' README.quota file. Someone who wants to help out might update that LDP doc for us. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 7 19:17:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 19:17:34 -0700 (PDT) Received: from web7305.mail.yahoo.co.kr (web7305.mail.yahoo.co.kr [211.119.129.206]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h782HJFl011246 for ; Thu, 7 Aug 2003 19:17:20 -0700 Message-ID: <20030808021712.31822.qmail@web7305.mail.yahoo.co.kr> Received: from [203.241.146.9] by web7305.mail.kr.yahoo.com via HTTP; Fri, 08 Aug 2003 11:17:12 JST Date: Fri, 8 Aug 2003 11:17:12 +0900 (JST) From: =?euc-kr?q?Soon=20Son=20Kwon?= Reply-To: kss@kldp.org Subject: building xfsprogs rpm error To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit X-archive-position: 4926 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ksoonson@yahoo.co.kr Precedence: bulk X-list: linux-xfs Content-Length: 1225 Lines: 36 Hello, I got the source rpm for xfsprogs but failed I get the following error when running make. Both on redhat 8.0 & redhat 9 makes the same error. Can anyone please let me know how to cope with this error? --- bit.o: In function `getbitval': /usr/src/redhat/BUILD/xfsprogs-1.2.0/db/bit.c:99: undefined reference to `__fswab64' /usr/src/redhat/BUILD/xfsprogs-1.2.0/db/bit.c:101: undefined reference to `__fswab64' bmap.o: In function `bmap': /usr/src/redhat/BUILD/xfsprogs-1.2.0/db/bmap.c:129: undefined reference to `__fswab64' bmap.o: In function `select_child': /usr/src/redhat/BUILD/xfsprogs-1.2.0/db/bmap.c:345: undefined reference to `__fswab64' /usr/src/redhat/BUILD/xfsprogs-1.2.0/db/bmap.c:346: undefined reference to `__fswab64' bmap.o:/usr/src/redhat/BUILD/xfsprogs-1.2.0/db/bmap.c:347: more undefined references to `__fswab64' follow collect2: ld returned 1 exit status make[1]: *** [xfs_db] Error 1 make: *** [default] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.55937 (%build) _____________________________________________________________________ ¿¹»Û ÆíÁöÁö¿¡ ¸ÞÀÏÀ» º¸³»¼¼¿ä - ¾ßÈÄ! ¸ÞÀÏ http://mail.yahoo.co.kr ½ÅÂ÷,Áß°íÂ÷,Á÷°Å·¡ ¸Å¹°ÀÌ ÇÑÀÚ¸®¿¡ - ¾ßÈÄ! ÀÚµ¿Â÷ http://autos.yahoo.co.kr/autos/ From owner-linux-xfs@oss.sgi.com Thu Aug 7 19:25:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 19:26:12 -0700 (PDT) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h782PuFl012203 for ; Thu, 7 Aug 2003 19:25:57 -0700 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 h782Ps14014054 for ; Fri, 8 Aug 2003 04:25:54 +0200 Received: (qmail 8520 invoked from network); 8 Aug 2003 04:25:54 +0200 Received: from rx3227.cip.uni-regensburg.de (132.199.237.32) by rss1.rz.uni-regensburg.de with SMTP; 8 Aug 2003 04:25:54 +0200 Subject: Re: building xfsprogs rpm error From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: kss@kldp.org Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030808021712.31822.qmail@web7305.mail.yahoo.co.kr> References: <20030808021712.31822.qmail@web7305.mail.yahoo.co.kr> Content-Type: text/plain Message-Id: <1060309554.538.3.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 08 Aug 2003 04:25:54 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 4927 X-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: 1262 Lines: 36 On Fri, 2003-08-08 at 04:17, Soon Son Kwon wrote: > Hello, I got the source rpm for xfsprogs but failed > I get the following error when running make. > Both on redhat 8.0 & redhat 9 makes the same error. > > Can anyone please let me know how to cope with > this error? > > --- > bit.o: In function `getbitval': > /usr/src/redhat/BUILD/xfsprogs-1.2.0/db/bit.c:99: > undefined reference to `__fswab64' > /usr/src/redhat/BUILD/xfsprogs-1.2.0/db/bit.c:101: > undefined reference to `__fswab64' > bmap.o: In function `bmap': > /usr/src/redhat/BUILD/xfsprogs-1.2.0/db/bmap.c:129: > undefined reference to `__fswab64' > bmap.o: In function `select_child': > /usr/src/redhat/BUILD/xfsprogs-1.2.0/db/bmap.c:345: > undefined reference to `__fswab64' > /usr/src/redhat/BUILD/xfsprogs-1.2.0/db/bmap.c:346: > undefined reference to `__fswab64' > bmap.o:/usr/src/redhat/BUILD/xfsprogs-1.2.0/db/bmap.c:347: > more undefined references to `__fswab64' follow > collect2: ld returned 1 exit status > make[1]: *** [xfs_db] Error 1 > make: *** [default] Error 2 > error: Bad exit status from /var/tmp/rpm-tmp.55937 > (%build) > hmmm. I'm just tied to debian, but we're here at xfsprogs-2.5.4. Maybe you want to get newer userspace tools, or am I missing something? Christian From owner-linux-xfs@oss.sgi.com Thu Aug 7 19:29:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 19:29:36 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h782TWFl012850 for ; Thu, 7 Aug 2003 19:29:32 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h782nHsR013851 for ; Thu, 7 Aug 2003 21:49:17 -0500 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h782TQQK5859837; Thu, 7 Aug 2003 21:29:26 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h782TPwh16676780; Thu, 7 Aug 2003 21:29:26 -0500 (CDT) Date: Thu, 7 Aug 2003 21:29:25 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: kss@kldp.org cc: linux-xfs@oss.sgi.com Subject: Re: building xfsprogs rpm error In-Reply-To: <20030808021712.31822.qmail@web7305.mail.yahoo.co.kr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by tolkor.sgi.com id h782nHsR013851 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h782TWFl012857 X-archive-position: 4928 X-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: 1590 Lines: 49 Please start with a version of xfsprogs that is not 1.5 years old... xfsprogs is now at version 2.5.4. you can find it under ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/ or ftp://oss.sgi.com/projects/xfs/download/cmd_tars/ -ERic On Fri, 8 Aug 2003, [euc-kr] Soon Son Kwon wrote: > Hello, I got the source rpm for xfsprogs but failed > I get the following error when running make. > Both on redhat 8.0 & redhat 9 makes the same error. > > Can anyone please let me know how to cope with > this error? > > --- > bit.o: In function `getbitval': > /usr/src/redhat/BUILD/xfsprogs-1.2.0/db/bit.c:99: > undefined reference to `__fswab64' > /usr/src/redhat/BUILD/xfsprogs-1.2.0/db/bit.c:101: > undefined reference to `__fswab64' > bmap.o: In function `bmap': > /usr/src/redhat/BUILD/xfsprogs-1.2.0/db/bmap.c:129: > undefined reference to `__fswab64' > bmap.o: In function `select_child': > /usr/src/redhat/BUILD/xfsprogs-1.2.0/db/bmap.c:345: > undefined reference to `__fswab64' > /usr/src/redhat/BUILD/xfsprogs-1.2.0/db/bmap.c:346: > undefined reference to `__fswab64' > bmap.o:/usr/src/redhat/BUILD/xfsprogs-1.2.0/db/bmap.c:347: > more undefined references to `__fswab64' follow > collect2: ld returned 1 exit status > make[1]: *** [xfs_db] Error 1 > make: *** [default] Error 2 > error: Bad exit status from /var/tmp/rpm-tmp.55937 > (%build) > > > _____________________________________________________________________ > ¿¹»Û ÆíÁöÁö¿¡ ¸ÞÀÏÀ» º¸³»¼¼¿ä - ¾ßÈÄ! ¸ÞÀÏ > http://mail.yahoo.co.kr > ½ÅÂ÷,Áß°íÂ÷,Á÷°Å·¡ ¸Å¹°ÀÌ ÇÑÀÚ¸®¿¡ - ¾ßÈÄ! ÀÚµ¿Â÷ > http://autos.yahoo.co.kr/autos/ > > From owner-linux-xfs@oss.sgi.com Thu Aug 7 19:33:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 19:33:04 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h782X0Fl013475 for ; Thu, 7 Aug 2003 19:33:01 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h782Wsq0002125 for ; Thu, 7 Aug 2003 19:32:55 -0700 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 MAA01994; Fri, 8 Aug 2003 12:32:22 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h782Vp3K263930; Fri, 8 Aug 2003 12:32:11 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h782UbGi001569; Fri, 8 Aug 2003 12:30:37 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h782UTaC001567; Fri, 8 Aug 2003 12:30:29 +1000 Date: Fri, 8 Aug 2003 12:30:29 +1000 From: Nathan Scott To: kss@kldp.org Cc: linux-xfs@oss.sgi.com Subject: Re: building xfsprogs rpm error Message-ID: <20030808023029.GB1124@frodo> References: <20030808021712.31822.qmail@web7305.mail.yahoo.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030808021712.31822.qmail@web7305.mail.yahoo.co.kr> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h782X1Fl013482 X-archive-position: 4929 X-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: 30 On Fri, Aug 08, 2003 at 11:17:12AM +0900, Soon Son Kwon wrote: > Hello, I got the source rpm for xfsprogs but failed > I get the following error when running make. > Both on redhat 8.0 & redhat 9 makes the same error. > > Can anyone please let me know how to cope with > this error? > > --- > bit.o: In function `getbitval': > /usr/src/redhat/BUILD/xfsprogs-1.2.0/db/bit.c:99: ^^^^^^^^^^^^^^ From xfsprogs/doc/CHANGES... xfsprogs-1.2.0 (01 April 2001) Wow, where did you find that src rpm?! (in a time capsule? ;) Seriously, the problem here is those old versions of xfsprogs used to include kernel headers which can change in unexpected ways, and without care for user tools. Your best bet is to use a more recent xfsprogs version - anything circa 2003 will do the trick. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 7 19:57:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 19:58:04 -0700 (PDT) Received: from mx0.gmx.net (mx0.gmx.de [213.165.64.100]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h782vkFl015760 for ; Thu, 7 Aug 2003 19:57:47 -0700 Received: (qmail 23389 invoked by uid 0); 8 Aug 2003 02:57:39 -0000 Date: Fri, 8 Aug 2003 04:57:39 +0200 (MEST) From: onedj@gmx.net To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Subject: trying to repair/recover xfs filesystem after system crash X-Priority: 3 (Normal) X-Authenticated-Sender: #0000482344@gmx.net X-Authenticated-IP: [67.74.151.111] Message-ID: <25353.1060311459@www61.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-archive-position: 4930 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: onedj@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 3420 Lines: 80 A couple weeks ago my system powered down suddenly. One XFS filesystem was affected somehow and I have not been able to repair it with xfs_repair. xfs_repair immediately freezes when I run it and gives no output. The same is true for xfs_check. xfs_info gives the following: think# xfs_info -t /etc/fstab /usr/local meta-data=/usr/local isize=256 agcount=8, agsize=103950 blks = sectsz=512 data = bsize=4096 blocks=831600, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 I have just upgraded to Linux kernel 2.4.21 patched with the latest xfs 1.3pre5 patch and xfsprogs 2.5.4 Below is the kernel output at boot time: Aug 7 21:38:03 think kernel: XFS mounting filesystem ide0(3,4) Aug 7 21:38:03 think kernel: Starting XFS recovery on filesystem: ide0(3,4) (dev: 3/4) Aug 7 21:38:03 think kernel: printing eip: Aug 7 21:38:03 think kernel: c01a58df Aug 7 21:38:03 think kernel: Oops: 0000 Aug 7 21:38:03 think kernel: CPU: 0 Aug 7 21:38:03 think kernel: EIP: 0010:[xlog_recover_do_reg_buffer+207/400] Not tainted Aug 7 21:38:03 think kernel: EFLAGS: 00010202 Aug 7 21:38:03 think kernel: eax: 00000100 ebx: 0000006a ecx: 00000040 edx: d7ee2c60 Aug 7 21:38:03 think kernel: esi: 00000000 edi: d79ec500 ebp: 00000002 esp: d75dbb2c Aug 7 21:38:03 think kernel: ds: 0018 es: 0018 ss: 0018 Aug 7 21:38:03 think kernel: Process mount (pid: 84, stackpage=d75db000) Aug 7 21:38:03 think kernel: Stack: d7ee2d94 0000000a 0000006a 00002205 00001000 0000000a d7ee2d94 00000003 Aug 7 21:38:03 think kernel: d7ee2d80 d7a62540 00000000 00000000 c01a5fe a d746ec00 d7ee2c60 d7a62540 Aug 7 21:38:03 think kernel: d7ee2d80 00002205 d7a78560 00000000 d746ec0 0 d7ee2c60 00000000 d7c89580 Aug 7 21:38:03 think kernel: Call Trace: [xlog_recover_do_buffer_trans+602/8 16] [xlog_recover_do_trans+372/384] [xlog_recover_commit_trans+63/80] [xlog_recover_process_data+237/544] [xlog_do_r ecovery_pass+656/2784] Aug 7 21:38:03 think kernel: [fbcon_vbl_handler+160/176] [xlog_do_log_recover y+147/192] [xlog_do_recover+59/352] [xlog_recover+227/256] [xfs_log_mount+145/256] [xfs_mountfs+1664/3680] Aug 7 21:38:03 think kernel: [__down_failed+8/12] [pagebuf_iostart+108/176] [ xfs_readsb+464/560] [xfs_setsize_buf targ+61/128] [xfs_ioinit+30/64] [xfs_mount+718/1024] Aug 7 21:38:03 think kernel: [vfs_mount+67/80] [linvfs_read_super+141/448] [a lloc_super+58/352] [check_disk_chang e+72/144] [get_sb_bdev+395/592] [get_fs_type+44/128] Aug 7 21:38:03 think kernel: [do_kern_mount+289/320] [do_add_mount+147/400] [ do_mount+352/432] [copy_mount_option s+121/208] [sys_mount+177/224] [system_call+51/56] Aug 7 21:38:03 think kernel: Aug 7 21:38:03 think kernel: Code: f3 a5 a8 02 74 02 66 a5 a8 01 74 01 a4 ff 44 24 1c 01 eb e9 -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -------------------------------------------------- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualitätssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post From owner-linux-xfs@oss.sgi.com Thu Aug 7 20:17:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 20:17:22 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h783HBFl017569 for ; Thu, 7 Aug 2003 20:17:12 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h783arsR023702 for ; Thu, 7 Aug 2003 22:36:55 -0500 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 NAA02403; Fri, 8 Aug 2003 13:16:50 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h783GK3K264283; Fri, 8 Aug 2003 13:16:40 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h783F5Gi001686; Fri, 8 Aug 2003 13:15:05 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h783EX74001684; Fri, 8 Aug 2003 13:14:33 +1000 Date: Fri, 8 Aug 2003 13:14:33 +1000 From: Nathan Scott To: onedj@gmx.net Cc: linux-xfs@oss.sgi.com Subject: Re: trying to repair/recover xfs filesystem after system crash Message-ID: <20030808031433.GC1124@frodo> References: <25353.1060311459@www61.gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25353.1060311459@www61.gmx.net> User-Agent: Mutt/1.5.3i X-archive-position: 4931 X-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: 552 Lines: 15 On Fri, Aug 08, 2003 at 04:57:39AM +0200, onedj@gmx.net wrote: > A couple weeks ago my system powered down suddenly. One XFS filesystem was > affected somehow and I have not been able to repair it with xfs_repair. > xfs_repair immediately freezes when I run it and gives no output. The same is > true for xfs_check. xfs_info gives the following: Do you get any syslog errors when running repair/check (eg. device errors?). They shouldn't just hang... what do they display? If nothing at all, strace output would be useful. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 7 20:40:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 20:40:26 -0700 (PDT) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h783eJFl020164 for ; Thu, 7 Aug 2003 20:40:20 -0700 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <0.01695D7C@mailhub2.arup.com>; Fri, 8 Aug 2003 4:40:13 +0100 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Fri, 08 Aug 2003 04:40:12 +0100 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Fri, 08 Aug 2003 13:39:16 +1000 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Fri, 08 Aug 2003 13:20:07 +1000 From: "Scott Fagg" To: Subject: Re: kernel errors when XFS filesystem fills up Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h783eLFl020173 X-archive-position: 4932 X-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.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 2831 Lines: 69 I spoke too soon, the problem has resurfaced. Not as bad as before. I filled the volume up, got no errors. But at some point after that, quite possibly during an xfs_check or xfs_repair OR deleting large chunks of data the problem resurfaced. I fear that it's probably beyond my to fix this ( kernerl filesystem drivers is not one of my strong points ). I'm trying to work out exactly what the error is telling my. What is the implication of XFS_ERRLEVEL_LOW vs XFS_ERRLEVEL_HIGH ? ( a google search turned up nothing ). Scott Fagg Arup Brisbane (07) 3023 6000 >>> "Scott Fagg" 04/08/2003 11:40:56 AM >>> I'm getting message like those shown below from dmesg when my XFS filesystems fill up. - happens when the file system completely runs out of space, ie 0 bytes free. - doesn't seem to be any other ill effects ( no oops, no panic ) but the app copying the file crashes ( e.g. cp or rsync will crash ) - happening on both Redhat8.0 2.4.21-xfs ( on raid5 compaq hardware) and Redhat 9.0 2.4.21-xfs ( on plain IDE ) Once the error happens once, i then start to get the same error even when the filesystem is no longer full. Only solution seems to be to reformat the filesystem as xfs_check and xfs_repair don't help. Any thoughts ? Any more info i can provide ? regards, xfs_da_do_buf: bno 0 dir: inode 4688490 Filesystem "ida0(72,17)": XFS internal error xfs_da_do_buf(1) at line 2184 of file xfs_da_btree.c. Caller 0xc01952d7 cd797cc8 c0194b81 c02b1f5d 00000001 cfe6e400 c02b1eb8 00000888 c01952d7 c3c6dd40 cf741868 0000a201 00002000 0001a201 c3c6dd40 0023c530 00000001 00000000 cfe6e400 cd797d3c c01c4def 000003de 0023c530 00000000 00000010 Call Trace: [] xfs_da_do_buf+0x211/0x8b0 [kernel] [] xfs_da_read_buf+0x57/0x60 [kernel] [] xfs_trans_read_buf+0x33f/0x3a0 [kernel] [] xfs_itobp+0xf1/0x270 [kernel] [] xfs_da_read_buf+0x57/0x60 [kernel] [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] [] xfs_attr_node_get+0x3c/0xd0 [kernel] [] xfs_attr_fetch+0xff/0x1b0 [kernel] [] xfs_acl_iaccess+0x54/0xe0 [kernel] [] xfs_dir2_put_dirent64_direct+0x0/0xa0 [kernel] [] xfs_iaccess+0x19c/0x1b0 [kernel] [] xfs_access+0x3b/0x60 [kernel] [] linvfs_permission+0x29/0x30 [kernel] [] permission+0x3a/0x40 [kernel] [] link_path_walk+0x60/0x6e0 [kernel] [] path_lookup+0x39/0x40 [kernel] [] open_namei+0x70/0x5d0 [kernel] [] filp_open+0x43/0x70 [kernel] [] sys_open+0x53/0xa0 [kernel] [] system_call+0x33/0x38 [kernel] Scott Fagg Arup Brisbane (07) 3023 6000 From owner-linux-xfs@oss.sgi.com Thu Aug 7 20:50:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 20:50:25 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h783oJFl025300 for ; Thu, 7 Aug 2003 20:50:20 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h784A4sR029776 for ; Thu, 7 Aug 2003 23:10:04 -0500 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h783oDQK5873644; Thu, 7 Aug 2003 22:50:14 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h783oDwh16638898; Thu, 7 Aug 2003 22:50:13 -0500 (CDT) Date: Thu, 7 Aug 2003 22:50:13 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Scott Fagg cc: linux-xfs@oss.sgi.com Subject: Re: kernel errors when XFS filesystem fills up In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4933 X-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: 1002 Lines: 19 On Fri, 8 Aug 2003, Scott Fagg wrote: > > I spoke too soon, the problem has resurfaced. > > Not as bad as before. I filled the volume up, got no errors. But at some point after that, quite possibly during an xfs_check or xfs_repair OR deleting large chunks of data the problem resurfaced. > > I fear that it's probably beyond my to fix this ( kernerl filesystem drivers is not one of my strong points ). I'm trying to work out exactly what the error is telling my. What is the implication of XFS_ERRLEVEL_LOW vs XFS_ERRLEVEL_HIGH ? ( a google search turned up nothing ). It works with /proc/sys/fs/xfs/error_level, to determine when more verbose errors should be printed to the syslog. /proc/sys/fs/xfs/error_level works like a volume control - from 0 to 11, with 11 being the noisiest (i.e. the most information printed for the least severe errors) There are actually only a few "detents" on the volume control though, so you won't notice a difference between, say, 4 and 5, currently. -Eric From owner-linux-xfs@oss.sgi.com Thu Aug 7 21:36:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 21:36:20 -0700 (PDT) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h784a6Fl032252 for ; Thu, 7 Aug 2003 21:36:07 -0700 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <0.01695FB0@mailhub2.arup.com>; Fri, 8 Aug 2003 5:36:00 +0100 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Fri, 08 Aug 2003 05:35:59 +0100 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Fri, 08 Aug 2003 14:35:04 +1000 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Fri, 08 Aug 2003 14:33:52 +1000 From: "Scott Fagg" To: Subject: Re: kernel errors when XFS filesystem fills up Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h784a7Fl032254 X-archive-position: 4934 X-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.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 1771 Lines: 44 /proc/sys/fs/xfs/error_level is set to 3 on the box in question. What is the error message i'm getting actually telling me ? - corrupt filesystem structure ? - corrupt inode ? - it just ran out of space ? ( i didn't think this was the case as i still get problems after freeing up some free space) I'm guessing that what happens is that at the full-volume case is hit, an allocation goes wrong and the structures on disc don't get written out properly, so from that point on the fs is messed up. What puzzles me is that xfs_repair and xfs_check NEVER find any problems even while i'm getting these errors out of dmesg. regards, Scott Fagg Arup Brisbane (07) 3023 6000 >>> Eric Sandeen 08/08/2003 1:50:13 PM >>> On Fri, 8 Aug 2003, Scott Fagg wrote: > > I spoke too soon, the problem has resurfaced. > > Not as bad as before. I filled the volume up, got no errors. But at some point after that, quite possibly during an xfs_check or xfs_repair OR deleting large chunks of data the problem resurfaced. > > I fear that it's probably beyond my to fix this ( kernerl filesystem drivers is not one of my strong points ). I'm trying to work out exactly what the error is telling my. What is the implication of XFS_ERRLEVEL_LOW vs XFS_ERRLEVEL_HIGH ? ( a google search turned up nothing ). It works with /proc/sys/fs/xfs/error_level, to determine when more verbose errors should be printed to the syslog. /proc/sys/fs/xfs/error_level works like a volume control - from 0 to 11, with 11 being the noisiest (i.e. the most information printed for the least severe errors) There are actually only a few "detents" on the volume control though, so you won't notice a difference between, say, 4 and 5, currently. -Eric From owner-linux-xfs@oss.sgi.com Thu Aug 7 22:06:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 22:07:08 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7856nFl001806 for ; Thu, 7 Aug 2003 22:06:50 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7856hq0028568 for ; Thu, 7 Aug 2003 22:06:43 -0700 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 PAA03433; Fri, 8 Aug 2003 15:06:11 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7855e3K262692; Fri, 8 Aug 2003 15:06:01 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7854IGi001989; Fri, 8 Aug 2003 15:04:26 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7853jKG001987; Fri, 8 Aug 2003 15:03:45 +1000 Date: Fri, 8 Aug 2003 15:03:45 +1000 From: Nathan Scott To: Scott Fagg Cc: linux-xfs@oss.sgi.com Subject: Re: kernel errors when XFS filesystem fills up Message-ID: <20030808050345.GE1124@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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7856oFl001813 X-archive-position: 4935 X-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: 2493 Lines: 57 On Fri, Aug 08, 2003 at 02:33:52PM +1000, Scott Fagg wrote: > > /proc/sys/fs/xfs/error_level is set to 3 on the box in question. > > What is the error message i'm getting actually telling me ? > > - corrupt filesystem structure ? > - corrupt inode ? > - it just ran out of space ? ( i didn't think this was the case as i still get problems after freeing up some free space) > > I'm guessing that what happens is that at the full-volume case is hit, an allocation goes wrong and the structures on disc don't get written out properly, so from that point on the fs is messed up. > > What puzzles me is that xfs_repair and xfs_check NEVER find any problems even while i'm getting these errors out of dmesg. From your stack trace... xfs_da_do_buf: bno 0 dir: inode 4688490 Filesystem "ida0(72,17)": XFS internal error xfs_da_do_buf(1) at line 2184 of file xf+s_da_btree.c. Caller 0xc01952d7 cd797cc8 c0194b81 c02b1f5d 00000001 cfe6e400 c02b1eb8 00000888 c01952d7 c3c6dd40 cf741868 0000a201 00002000 0001a201 c3c6dd40 0023c530 00000001 00000000 cfe6e400 cd797d3c c01c4def 000003de 0023c530 00000000 00000010 Call Trace: [] xfs_da_do_buf+0x211/0x8b0 [kernel] [] xfs_da_read_buf+0x57/0x60 [kernel] [] xfs_trans_read_buf+0x33f/0x3a0 [kernel] [] xfs_itobp+0xf1/0x270 [kernel] [] xfs_da_read_buf+0x57/0x60 [kernel] [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] [] xfs_attr_node_get+0x3c/0xd0 [kernel] [] xfs_attr_fetch+0xff/0x1b0 [kernel] [] xfs_acl_iaccess+0x54/0xe0 [kernel] [] xfs_dir2_put_dirent64_direct+0x0/0xa0 [kernel] [] xfs_iaccess+0x19c/0x1b0 [kernel] [] xfs_access+0x3b/0x60 [kernel] [] linvfs_permission+0x29/0x30 [kernel] [] permission+0x3a/0x40 [kernel] You are doing a permissions check on an inode with an ACL. The extended attribute part of the inode is in btree or node format, hence we're down in xfs_da_do_buf (da= dir/attr) reading in the extended attribute data. For some strange reason we are trying to read at AG blk 0 for that inode, which is wrong - block zero in an AG holds the SB/AGF/AGI/ AGFL for that allocation group. Its not clear if this is due to the EA data on disk pointing to that block, or a bug in the kernel code. The tools not finding anything suggests to me a kernel bug, not sure where though... cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 7 22:20:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 22:20:12 -0700 (PDT) Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h785K8Fl003409 for ; Thu, 7 Aug 2003 22:20:09 -0700 Received: from dialup-67.74.149.170.dial1.houston1.level3.net ([67.74.149.170] helo=think.internal.alaya.net) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19kzfX-0004ny-00; Thu, 07 Aug 2003 22:20:04 -0700 Received: from guest by think.internal.alaya.net with local (Exim 3.35 #1 (Debian)) id 19kzdf-0000In-00; Fri, 08 Aug 2003 00:18:07 -0500 Date: Fri, 8 Aug 2003 00:18:07 -0500 From: djoneill@gmx.net To: Nathan Scott Cc: onedj@gmx.net, linux-xfs@oss.sgi.com Subject: Re: trying to repair/recover xfs filesystem after system crash Message-ID: <20030808051806.GA1052@think.internal.alaya.net> References: <25353.1060311459@www61.gmx.net> <20030808031433.GC1124@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030808031433.GC1124@frodo> User-Agent: Mutt/1.5.4i X-archive-position: 4936 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: djoneill@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 2554 Lines: 61 On Fri, Aug 08, 2003 at 01:14:33PM +1000, Nathan Scott wrote: > On Fri, Aug 08, 2003 at 04:57:39AM +0200, onedj@gmx.net wrote: > > A couple weeks ago my system powered down suddenly. One XFS filesystem was > > affected somehow and I have not been able to repair it with xfs_repair. > > xfs_repair immediately freezes when I run it and gives no output. The same is > > true for xfs_check. xfs_info gives the following: > > Do you get any syslog errors when running repair/check (eg. > device errors?). They shouldn't just hang... what do they > display? If nothing at all, strace output would be useful. No output whatsoever to syslog or messages. Here is the strace output: think# strace xfs_repair /dev/hda4 execve("/sbin/xfs_repair", ["xfs_repair", "/dev/hda4"], [/* 21 vars */]) = 0 uname({sys="Linux", node="think", ...}) = 0 brk(0) = 0x80d49f0 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=71606, ...}) = 0 old_mmap(NULL, 71606, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40012000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\275Z\1"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=1103880, ...}) = 0 old_mmap(NULL, 1113636, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40024000 mprotect(0x4012c000, 32292, PROT_NONE) = 0 old_mmap(0x4012c000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x107000) = 0x4012c000 old_mmap(0x40132000, 7716, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40132000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40134000 munmap(0x40012000, 71606) = 0 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=1589840, ...}) = 0 mmap2(NULL, 1589840, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40135000 close(3) = 0 brk(0) = 0x80d49f0 brk(0x80d59f0) = 0x80d59f0 brk(0) = 0x80d59f0 brk(0x80d6000) = 0x80d6000 getcwd("/home/guest", 4096) = 12 stat64("/dev/hda4", {st_mode=S_IFBLK|0660, st_rdev=makedev(3, 4), ...}) = 0 stat64("/dev/hda4", {st_mode=S_IFBLK|0660, st_rdev=makedev(3, 4), ...}) = 0 ustat(0x304, 0xbfffe724 -- Daniel From owner-linux-xfs@oss.sgi.com Thu Aug 7 22:32:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 22:32:40 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h785WYFl004119 for ; Thu, 7 Aug 2003 22:32:34 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h785WSq0000779 for ; Thu, 7 Aug 2003 22:32:28 -0700 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 PAA03664; Fri, 8 Aug 2003 15:32:27 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h785Vu3K260020; Fri, 8 Aug 2003 15:32:16 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h785UfGi002121; Fri, 8 Aug 2003 15:30:41 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h785UXZW002119; Fri, 8 Aug 2003 15:30:33 +1000 Date: Fri, 8 Aug 2003 15:30:33 +1000 From: Nathan Scott To: djoneill@gmx.net Cc: onedj@gmx.net, linux-xfs@oss.sgi.com Subject: Re: trying to repair/recover xfs filesystem after system crash Message-ID: <20030808053033.GG1124@frodo> References: <25353.1060311459@www61.gmx.net> <20030808031433.GC1124@frodo> <20030808051806.GA1052@think.internal.alaya.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030808051806.GA1052@think.internal.alaya.net> User-Agent: Mutt/1.5.3i X-archive-position: 4937 X-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: 1435 Lines: 37 On Fri, Aug 08, 2003 at 12:18:07AM -0500, djoneill@gmx.net wrote: > On Fri, Aug 08, 2003 at 01:14:33PM +1000, Nathan Scott wrote: > > On Fri, Aug 08, 2003 at 04:57:39AM +0200, onedj@gmx.net wrote: > > > A couple weeks ago my system powered down suddenly. One XFS filesystem was > > > affected somehow and I have not been able to repair it with xfs_repair. > > > xfs_repair immediately freezes when I run it and gives no output. The same is > > > true for xfs_check. xfs_info gives the following: > > > > Do you get any syslog errors when running repair/check (eg. > > device errors?). They shouldn't just hang... what do they > > display? If nothing at all, strace output would be useful. > > No output whatsoever to syslog or messages. Here is the strace output: > > > think# strace xfs_repair /dev/hda4 > execve("/sbin/xfs_repair", ["xfs_repair", "/dev/hda4"], [/* 21 vars */]) > = 0 > ... > stat64("/dev/hda4", {st_mode=S_IFBLK|0660, st_rdev=makedev(3, 4), ...}) > = 0 > stat64("/dev/hda4", {st_mode=S_IFBLK|0660, st_rdev=makedev(3, 4), ...}) > = 0 > ustat(0x304, 0xbfffe724 > That's pretty wierd - looks like ustat is not returning from the kernel... huh? xfs_repair is sitting in libxfs code which tries to determine whether there is a filesystem mounted on the device, I've never seen anything like this hang before (its unlikely to be an XFS problem, we're in VFS code there, in the kernel). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 7 22:48:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 22:48:51 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h785mgFl005845 for ; Thu, 7 Aug 2003 22:48:43 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7868IsR019812 for ; Fri, 8 Aug 2003 01:08:25 -0500 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 PAA03839; Fri, 8 Aug 2003 15:48:04 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h785lX3K264630; Fri, 8 Aug 2003 15:47:53 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h785kIGi002160; Fri, 8 Aug 2003 15:46:18 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h785jqDU002158; Fri, 8 Aug 2003 15:45:52 +1000 Date: Fri, 8 Aug 2003 15:45:52 +1000 From: Nathan Scott To: Andriei Duarte Cc: linux-xfs@oss.sgi.com Subject: Re: simple question Message-ID: <20030808054552.GH1124@frodo> References: <3F32ADB5.50108@sicredi.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F32ADB5.50108@sicredi.com.br> User-Agent: Mutt/1.5.3i X-archive-position: 4938 X-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: 375 Lines: 18 On Thu, Aug 07, 2003 at 04:51:17PM -0300, Andriei Duarte wrote: > Hi, I don't wanna busy you. > > Can you give me a simple example to how can I configure quotas on > XFS partition. > > Example: > all users must have only 200MB on their home (/home). > # mount -o usrquota /dev/foo /mnt/bar # setquota andriei 0 204800 0 0 /dev/foo cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 7 23:16:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 23:16:15 -0700 (PDT) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h786GAFl008061 for ; Thu, 7 Aug 2003 23:16:11 -0700 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <0.01696515@mailhub2.arup.com>; Fri, 8 Aug 2003 7:16:05 +0100 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Fri, 08 Aug 2003 07:16:04 +0100 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Fri, 08 Aug 2003 16:15:08 +1000 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Fri, 08 Aug 2003 16:12:22 +1000 From: "Scott Fagg" To: Subject: Re: kernel errors when XFS filesystem fills up Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h786GCFl008069 X-archive-position: 4939 X-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.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 1695 Lines: 53 > > >>>> Nathan Scott 08/08/2003 3:03:45 PM >>> >On Fri, Aug 08, 2003 at 02:33:52PM +1000, Scott Fagg wrote: >> >> /proc/sys/fs/xfs/error_level is set to 3 on the box in question. > > >You are doing a permissions check on an inode with an ACL. The >extended attribute part of the inode is in btree or node format, >hence we're down in xfs_da_do_buf (da= dir/attr) reading in the >extended attribute data. That sounds reasonable. Sometimes the error is triggered during a find, if it hits the inode in question. Sometimes there are subtle variations in the stack trace, in terms of the function names. I'll find some old logs and get some samples. > >For some strange reason we are trying to read at AG blk 0 for that >inode, which is wrong - block zero in an AG holds the SB/AGF/AGI/ >AGFL for that allocation group. Its not clear if this is due to >the EA data on disk pointing to that block, or a bug in the kernel >code. The tools not finding anything suggests to me a kernel bug, >not sure where though... > So what should i do to generate more debug info ? Not sure if it helps, but this sequence of events might give a clue : - run 'find' on the XFS vol - it hits a nasty inode and trigges the kernel message i see. - track down the inode mentioned and remove it and it's parent directory - run 'find' again .. no errors triggered - copy heaps of files back to the XFS vol and the error will probably occur again a couple of times, even if i'm copying 1000's of files. - backup files ( except faulty inodes ) - re-format XFS parition - copy files back - .. no errors occur .. until the volume fills up again. That help ? >cheers. > >-- >Nathan > > From owner-linux-xfs@oss.sgi.com Thu Aug 7 23:37:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 23:37:47 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h786bWFl009915 for ; Thu, 7 Aug 2003 23:37:38 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h786v3sR028385 for ; Fri, 8 Aug 2003 01:57:04 -0500 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 QAA04661; Fri, 8 Aug 2003 16:36:32 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h786a23K264836; Fri, 8 Aug 2003 16:36:22 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h786YlGi002310; Fri, 8 Aug 2003 16:34:47 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h786YFdq002307; Fri, 8 Aug 2003 16:34:15 +1000 Date: Fri, 8 Aug 2003 16:34:15 +1000 From: Nathan Scott To: Scott Fagg Cc: linux-xfs@oss.sgi.com Subject: Re: kernel errors when XFS filesystem fills up Message-ID: <20030808063415.GI1124@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: 4940 X-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: 1853 Lines: 49 On Fri, Aug 08, 2003 at 04:12:22PM +1000, Scott Fagg wrote: > > > >For some strange reason we are trying to read at AG blk 0 for that > >inode, which is wrong - block zero in an AG holds the SB/AGF/AGI/ > >AGFL for that allocation group. Its not clear if this is due to > >the EA data on disk pointing to that block, or a bug in the kernel > >code. The tools not finding anything suggests to me a kernel bug, > >not sure where though... > > > > So what should i do to generate more debug info ? The absolute ideal from my point of view is a recipe of steps which I can follow which is guaranteed to trigger the problem. And if this can be trimmed back to a very basic minimum - e.g. mkfs (-dsize=something small), a dd command line(s) to fill it up so this will trigger, etc, & whatever else... If I have that recipe and can reproduce it, I can be sure of fixing it (and can verify the fix too). The simpler the recipe, the better from my point of view. You seem to be able to reproduce it easily, which is promising. > Not sure if it helps, but this sequence of events might give a clue : This is a good start, but is not deterministic between our two machines (ie. you hit it but I don't, and theres many variables like "heaps of files", and an unknown starting point, etc). > - run 'find' on the XFS vol > - it hits a nasty inode and trigges the kernel message i see. > - track down the inode mentioned and remove it and it's parent directory > - run 'find' again .. no errors triggered > - copy heaps of files back to the XFS vol and the error will probably occur again a couple of times, even if i'm copying 1000's of files. > - backup files ( except faulty inodes ) > - re-format XFS parition > - copy files back > - .. no errors occur .. until the volume fills up again. > > That help ? Getting closer I think. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 7 23:47:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Aug 2003 23:47:03 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h786l0Fl012057 for ; Thu, 7 Aug 2003 23:47:01 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7876gsR029982 for ; Fri, 8 Aug 2003 02:06:45 -0500 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 h786kX1S1333278 for ; Fri, 8 Aug 2003 16:46:38 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h786kS5B1289280 for linux-xfs@oss.sgi.com; Fri, 8 Aug 2003 16:46:28 +1000 (EST) Date: Fri, 8 Aug 2003 16:46:28 +1000 (EST) From: Nathan Scott Message-Id: <200308080646.h786kS5B1289280@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - acl X-archive-position: 4941 X-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: 523 Lines: 21 Somehow the acl segv fix got lost, reinstate it. Date: Thu Aug 7 23:46:09 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds-1.3 Author: nathans Merged by: nathans Merged mods: xfs-cmds:slinx:155367a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds-r1.3 Modid: xfs-cmds-r1.3:slinx:155367a acl/VERSION - 1.54 acl/doc/CHANGES - 1.62 acl/debian/changelog - 1.48 acl/libmisc/unquote.c - 1.4 acl/libmisc/quote.c - 1.4 - Merge of xfs-cmds:slinx:155367a by nathans. From owner-linux-xfs@oss.sgi.com Fri Aug 8 06:57:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Aug 2003 06:57:45 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h78DvQFl009009 for ; Fri, 8 Aug 2003 06:57:26 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h78DvLq0012076 for ; Fri, 8 Aug 2003 06:57:21 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h78DuFQK5963391; Fri, 8 Aug 2003 08:56:15 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h78DuERn209105091; Fri, 8 Aug 2003 08:56:14 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h78DuER09320; Fri, 8 Aug 2003 08:56:14 -0500 Subject: Re: kernel errors when XFS filesystem fills up From: Steve Lord To: Scott Fagg Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1060350974.9276.1.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 08 Aug 2003 08:56:14 -0500 X-archive-position: 4942 X-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: 1457 Lines: 41 On Fri, 2003-08-08 at 01:12, Scott Fagg wrote: > > > > > >>>> Nathan Scott 08/08/2003 3:03:45 PM >>> > > > >For some strange reason we are trying to read at AG blk 0 for that > >inode, which is wrong - block zero in an AG holds the SB/AGF/AGI/ > >AGFL for that allocation group. Its not clear if this is due to > >the EA data on disk pointing to that block, or a bug in the kernel > >code. The tools not finding anything suggests to me a kernel bug, > >not sure where though... > > > > So what should i do to generate more debug info ? > > Not sure if it helps, but this sequence of events might give a clue : > > - run 'find' on the XFS vol > - it hits a nasty inode and trigges the kernel message i see. > - track down the inode mentioned and remove it and it's parent directory > - run 'find' again .. no errors triggered > - copy heaps of files back to the XFS vol and the error will probably occur again a couple of times, even if i'm copying 1000's of files. > - backup files ( except faulty inodes ) > - re-format XFS parition > - copy files back > - .. no errors occur .. until the volume fills up again. Do you have some examples of the type of ACL setup you have on these files? The problem may well be down in dealing with large numbers of them, or large sized acls. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Aug 8 07:05:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Aug 2003 07:05:42 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h78E5CFl009943 for ; Fri, 8 Aug 2003 07:05:13 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h78EOwsR032443 for ; Fri, 8 Aug 2003 09:24:58 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h78E56QK5940187; Fri, 8 Aug 2003 09:05:06 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h78E56Rn215551383; Fri, 8 Aug 2003 09:05:06 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h78E56V09346; Fri, 8 Aug 2003 09:05:06 -0500 Subject: Re: trying to repair/recover xfs filesystem after system crash From: Steve Lord To: djoneill@gmx.net Cc: Nathan Scott , onedj@gmx.net, linux-xfs@oss.sgi.com In-Reply-To: <20030808051806.GA1052@think.internal.alaya.net> References: <25353.1060311459@www61.gmx.net> <20030808031433.GC1124@frodo> <20030808051806.GA1052@think.internal.alaya.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1060351505.9279.6.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 08 Aug 2003 09:05:06 -0500 X-archive-position: 4943 X-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: 736 Lines: 22 On Fri, 2003-08-08 at 00:18, djoneill@gmx.net wrote: > ustat(0x304, 0xbfffe724 > The fact that you are hanging in ustat is strange, is this after the failed mount oops (i.e. without a reboot)? It is possible that the mount failure left the device locked and you will need a reboot to clear it up. Try a reboot, then do xfs_logprint -t /dev/hda4 and send us the output, You can try the mount again and see if the oops repeats, if it does reboot one more time, and run xfs_repair -L (to ignore the log). If the ustat hang is there after a reboot then you may have hardware issues. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Aug 8 09:11:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Aug 2003 09:11:42 -0700 (PDT) Received: from mail.blazebox.homeip.net (postfix@pool-141-155-151-209.ny5030.east.verizon.net [141.155.151.209]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h78GBOFl023660 for ; Fri, 8 Aug 2003 09:11:25 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.blazebox.homeip.net (Postfix) with ESMTP id 6FCD2A20B; Fri, 8 Aug 2003 12:11:23 -0400 (EDT) Received: from mail.blazebox.homeip.net (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.14) id 92559-7F4549DA; Fri, 08 Aug 2003 12:11:23 -0400 Received: from blaze.homeip.net (blaze [192.168.0.250]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail.blazebox.homeip.net (Postfix) with ESMTP id 1DC449EC2; Fri, 8 Aug 2003 12:11:23 -0400 (EDT) Subject: Re: [ANNOUNC] linux-2.4+xfs tree From: Paul Blazejowski To: Russell Cattelan Cc: linux-xfs In-Reply-To: <1060300430.24377.64.camel@naboo> References: <1060300430.24377.64.camel@naboo> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5oiG5tlQVZrG4D+F7LLJ" Message-Id: <1060359233.965.9.camel@blaze.homeip.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 (Slackware Linux) Date: Fri, 08 Aug 2003 12:13:53 -0400 X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.14; AVE: 6.21.0.0; VDF: 6.21.0.6; host: blazebox.homeip.net) X-archive-position: 4944 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: paulb@blazebox.homeip.net Precedence: bulk X-list: linux-xfs Content-Length: 1322 Lines: 51 --=-5oiG5tlQVZrG4D+F7LLJ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2003-08-07 at 19:53, Russell Cattelan wrote: > Just a quick note anybody who wants to play with > xfs on 2.4.22 can grab this BitKeeper tree. > bk clone http://xfs.org:8090/linux-2.4+xfs >=20 > I think the tree has all the correct bits in it > but I'm late for something so I don't have time > to test it tonight. > If anybody is feeling brave check it out and report > back. >=20 > -Russell >=20 >=20 >=20 >=20 So far so good :-) Just few warning when compiling the kernel in llrw file IRC. There's some issues in ACPI/USB on NFORCE2 that i noticed here but XFS is very solid.I did few large cvs checkouts,removed kernel tree few times...etc Is there a plain patch of this tree from 2.4.21 to 2.4.22-rc1? or how would i create a patch from the bk clone to use on kernel.org kernel(s)? As always great work on XFS! Thanks Russell Regards, Paul=20 --=-5oiG5tlQVZrG4D+F7LLJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/M8xBIymMQsXoRDARApImAJ9Q4MH3YkQO0jAX87REYy5i3Z06ngCfYbKg xOYgqLMSf8NLnx9Msch5Nos= =uZCx -----END PGP SIGNATURE----- --=-5oiG5tlQVZrG4D+F7LLJ-- From owner-linux-xfs@oss.sgi.com Fri Aug 8 12:30:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Aug 2003 12:31:11 -0700 (PDT) Received: from badboy.mail.pas.earthlink.net (badboy.mail.pas.earthlink.net [207.217.120.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h78JUBFl001946 for ; Fri, 8 Aug 2003 12:30:12 -0700 Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by badboy.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h78JL1v10411 for ; Fri, 8 Aug 2003 12:21:01 -0700 (PDT) Received: from dialup-67.74.149.211.dial1.houston1.level3.net ([67.74.149.211] helo=think.internal.alaya.net) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19lCiO-0002IJ-00; Fri, 08 Aug 2003 12:15:53 -0700 Received: from guest by think.internal.alaya.net with local (Exim 3.35 #1 (Debian)) id 19lCgY-0000CT-00; Fri, 08 Aug 2003 14:13:58 -0500 Date: Fri, 8 Aug 2003 14:13:58 -0500 From: djoneill@gmx.net To: Steve Lord Cc: Nathan Scott , onedj@gmx.net, linux-xfs@oss.sgi.com Subject: Re: trying to repair/recover xfs filesystem after system crash Message-ID: <20030808191358.GA481@think.internal.alaya.net> References: <25353.1060311459@www61.gmx.net> <20030808031433.GC1124@frodo> <20030808051806.GA1052@think.internal.alaya.net> <1060351505.9279.6.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: <1060351505.9279.6.camel@jen.americas.sgi.com> User-Agent: Mutt/1.5.4i X-archive-position: 4945 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: djoneill@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 1659 Lines: 51 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Aug 08, 2003 at 09:05:06AM -0500, Steve Lord wrote: > On Fri, 2003-08-08 at 00:18, djoneill@gmx.net wrote: > > > ustat(0x304, 0xbfffe724 > > > > The fact that you are hanging in ustat is strange, is this after the > failed mount oops (i.e. without a reboot)? It is possible that the > mount failure left the device locked and you will need a reboot to > clear it up. > > Try a reboot, then do xfs_logprint -t /dev/hda4 and send us the output, > You can try the mount again and see if the oops repeats, if it does > reboot one more time, and run xfs_repair -L (to ignore the log). If the > ustat hang is there after a reboot then you may have hardware issues. > I commented out the fstab entry for the filesystem, then ran xfs_repair which now does not hang and gives the following output: think# xfs_repair /dev/hda4 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. I ran xfs_logprint and the output is extremely long. I have attached it rather than include it here. --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfs.logprint" --h31gzZEtNLTqOjlF-- From owner-linux-xfs@oss.sgi.com Fri Aug 8 12:53:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Aug 2003 12:53:05 -0700 (PDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h78Jr2Fl003999 for ; Fri, 8 Aug 2003 12:53:03 -0700 Received: from dialup-67.74.149.70.dial1.houston1.level3.net ([67.74.149.70] helo=think.internal.alaya.net) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19lDIF-00052j-00; Fri, 08 Aug 2003 12:52:56 -0700 Received: from djo by think.internal.alaya.net with local (Exim 3.35 #1 (Debian)) id 19lDGN-0000bz-00; Fri, 08 Aug 2003 14:50:59 -0500 Date: Fri, 8 Aug 2003 14:50:58 -0500 From: daniel To: Steve Lord Cc: Nathan Scott , onedj@gmx.net, linux-xfs@oss.sgi.com Subject: Re: trying to repair/recover xfs filesystem after system crash Message-ID: <20030808195058.GA618@think.alaya.net> References: <25353.1060311459@www61.gmx.net> <20030808031433.GC1124@frodo> <20030808051806.GA1052@think.internal.alaya.net> <1060351505.9279.6.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1060351505.9279.6.camel@jen.americas.sgi.com> User-Agent: Mutt/1.5.4i X-archive-position: 4946 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: djoneill@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 867 Lines: 23 So has Steve Lord on 09:05 Friday 08 August 2003 written: > On Fri, 2003-08-08 at 00:18, djoneill@gmx.net wrote: > > > ustat(0x304, 0xbfffe724 > > > > The fact that you are hanging in ustat is strange, is this after the > failed mount oops (i.e. without a reboot)? It is possible that the > mount failure left the device locked and you will need a reboot to > clear it up. > > Try a reboot, then do xfs_logprint -t /dev/hda4 and send us the output, > You can try the mount again and see if the oops repeats, if it does > reboot one more time, and run xfs_repair -L (to ignore the log). If the > ustat hang is there after a reboot then you may have hardware issues. The problem had to be what you mentioned: the mount failure at boot was locking the device. Turning off auto mounting at boot and running xfs_repair -L /dev/hda4 solved the problem. -- Daniel From owner-linux-xfs@oss.sgi.com Fri Aug 8 13:13:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Aug 2003 13:14:13 -0700 (PDT) Received: from ente.berdmann.de (frnk-d514e048.dsl.mediaWays.net [213.20.224.72]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h78KDvFl005813 for ; Fri, 8 Aug 2003 13:13:59 -0700 Received: from indigo-3.berdmann.de ([192.168.1.15] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.36 #1) id 19lDcV-0001Yw-00 for linux-xfs@oss.sgi.com; Fri, 08 Aug 2003 22:13:51 +0200 Message-ID: <3F34047D.4030403@berdmann.de> Date: Fri, 08 Aug 2003 22:13:49 +0200 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP28; en-US; rv:1.5b) Gecko/20030723 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: CVS repository not working? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4947 X-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: 595 Lines: 16 Hi, what has happened to the CVS repository? [be@ente xfs-cmds]$ cvs -q update cvs server: failed to create lock directory for `/cvs/xfs-cmds' (/cvs/xfs-cmds/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/cvs/xfs-cmds' cvs [server aborted]: read lock failed - giving up [be@ente linux-2.4-xfs]$ cvs -q update cvs server: failed to create lock directory for `/cvs/linux-2.4-xfs' (/cvs/linux-2.4-xfs/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/cvs/linux-2.4-xfs' cvs [server aborted]: read lock failed - giving up From owner-linux-xfs@oss.sgi.com Fri Aug 8 13:31:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Aug 2003 13:31:43 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h78KVNFl007108 for ; Fri, 8 Aug 2003 13:31:24 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h78KpBsR006938 for ; Fri, 8 Aug 2003 15:51:11 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h78KVIQK6008140; Fri, 8 Aug 2003 15:31:18 -0500 (CDT) Received: from naboo (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h78KVHRn218423087; Fri, 8 Aug 2003 15:31:17 -0500 (CDT) Subject: Re: CVS repository not working? From: Russell Cattelan To: Bernhard Erdmann Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F34047D.4030403@berdmann.de> References: <3F34047D.4030403@berdmann.de> Content-Type: text/plain Message-Id: <1060374330.26696.0.camel@naboo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4-1mdk Date: Fri, 08 Aug 2003 15:25:30 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 4948 X-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: 729 Lines: 21 fixing the perms now. Give it a few to finish. On Fri, 2003-08-08 at 15:13, Bernhard Erdmann wrote: > Hi, > > what has happened to the CVS repository? > > [be@ente xfs-cmds]$ cvs -q update > cvs server: failed to create lock directory for `/cvs/xfs-cmds' > (/cvs/xfs-cmds/#cvs.lock): Permission denied > cvs server: failed to obtain dir lock in repository `/cvs/xfs-cmds' > cvs [server aborted]: read lock failed - giving up > > [be@ente linux-2.4-xfs]$ cvs -q update > cvs server: failed to create lock directory for `/cvs/linux-2.4-xfs' > (/cvs/linux-2.4-xfs/#cvs.lock): Permission denied > cvs server: failed to obtain dir lock in repository `/cvs/linux-2.4-xfs' > cvs [server aborted]: read lock failed - giving up > From owner-linux-xfs@oss.sgi.com Fri Aug 8 23:04:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Aug 2003 23:04:48 -0700 (PDT) Received: from snoopy.pacific.net.au (snoopy.pacific.net.au [61.8.0.36]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7964XFl002337 for ; Fri, 8 Aug 2003 23:04:34 -0700 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) by snoopy.pacific.net.au (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7964R0J011782; Sat, 9 Aug 2003 16:04:28 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h7964RCh028220; Sat, 9 Aug 2003 16:04:27 +1000 (EST) Received: from jdc.local (dyn172.mel2.homedsl.pacific.net.au [203.100.245.172]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h7964QPs003820; Sat, 9 Aug 2003 16:04:26 +1000 (EST) Received: from jdc.local (localhost [127.0.0.1]) by jdc.local (8.12.9/8.12.9/Debian-5) with ESMTP id h7964QSx001368; Sat, 9 Aug 2003 16:04:26 +1000 Received: (from jason@localhost) by jdc.local (8.12.9/8.12.9/Debian-5) id h7964Obj001356; Sat, 9 Aug 2003 16:04:24 +1000 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16180.36584.774468.404979@jdc.local> Date: Sat, 9 Aug 2003 16:04:24 +1000 To: Bernhard Erdmann Cc: linux-xfs@oss.sgi.com Subject: Re: CVS repository not working? In-Reply-To: <3F34047D.4030403@berdmann.de> References: <3F34047D.4030403@berdmann.de> X-Mailer: VM 7.17 under Emacs 21.2.1 Reply-To: jasonw@ariel.ucs.unimelb.edu.au X-archive-position: 4949 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonw@ariel.ucs.unimelb.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 155 Lines: 8 Bernhard Erdmann writes: > Hi, > > what has happened to the CVS repository? error closing /tmp/cvs-serv2178/./CVS/Repository No space left on device From owner-linux-xfs@oss.sgi.com Sat Aug 9 04:35:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 09 Aug 2003 04:35:55 -0700 (PDT) Received: from ente.berdmann.de (frnk-d514e048.dsl.mediaWays.net [213.20.224.72]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h79BZVFl029269 for ; Sat, 9 Aug 2003 04:35:32 -0700 Received: from indigo-3.berdmann.de ([192.168.1.15] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.36 #1) id 19lS0H-0006N2-00; Sat, 09 Aug 2003 13:35:21 +0200 Message-ID: <3F34DC76.6050409@berdmann.de> Date: Sat, 09 Aug 2003 13:35:18 +0200 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP28; en-US; rv:1.5b) Gecko/20030723 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Russell Cattelan CC: linux-xfs@oss.sgi.com Subject: Re: CVS repository not working? References: <3F34047D.4030403@berdmann.de> <1060374330.26696.0.camel@naboo> In-Reply-To: <1060374330.26696.0.camel@naboo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4950 X-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: 190 Lines: 9 Russell Cattelan wrote: > fixing the perms now. > Give it a few to finish. [be@indigo-3 xfs-cmds]$ cvs -q update error closing /tmp/cvs-serv29201/./CVS/Repository No space left on device From owner-linux-xfs@oss.sgi.com Sun Aug 10 15:10:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Aug 2003 15:11:00 -0700 (PDT) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7AMAhFl010244 for ; Sun, 10 Aug 2003 15:10:45 -0700 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <0.016A1C2B@mailhub2.arup.com>; 10 Aug 2003 23:10:37 +0100 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Sun, 10 Aug 2003 23:10:36 +0100 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Mon, 11 Aug 2003 08:09:39 +1000 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Mon, 11 Aug 2003 08:08:59 +1000 From: "Scott Fagg" To: Subject: Re: kernel errors when XFS filesystem fills up Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7AMAkFl010249 X-archive-position: 4951 X-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.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 1661 Lines: 54 > > >>>> Nathan Scott 08/08/2003 4:34:15 PM >>> >On Fri, Aug 08, 2003 at 04:12:22PM +1000, Scott Fagg wrote: >> > >> >For some strange reason we are trying to read at AG blk 0 for that >> >inode, which is wrong - block zero in an AG holds the SB/AGF/AGI/ >> >AGFL for that allocation group. Its not clear if this is due to >> >the EA data on disk pointing to that block, or a bug in the kernel >> >code. The tools not finding anything suggests to me a kernel bug, >> >not sure where though... >> > >> >> So what should i do to generate more debug info ? > >The absolute ideal from my point of view is a recipe of steps >which I can follow which is guaranteed to trigger the problem. >And if this can be trimmed back to a very basic minimum - e.g. >mkfs (-dsize=something small), a dd command line(s) to fill it >up so this will trigger, etc, & whatever else... > I tried creating a small XFS volume (100MB) in a file , not a partition, filled it up but it didn't produce any errors. I'll keep experimenting. >If I have that recipe and can reproduce it, I can be sure of >fixing it (and can verify the fix too). The simpler the recipe, >the better from my point of view. > >You seem to be able to reproduce it easily, which is promising. > >> Not sure if it helps, but this sequence of events might give a clue : > >This is a good start, but is not deterministic between our two >machines (ie. you hit it but I don't, and theres many variables >like "heaps of files", and an unknown starting point, etc). > >Getting closer I think. > >cheers. > >-- >Nathan > > Scott Fagg Arup Brisbane (07) 3023 6000 From owner-linux-xfs@oss.sgi.com Sun Aug 10 15:16:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Aug 2003 15:16:22 -0700 (PDT) Received: from hell.org.pl (qmailr@hell.org.pl [212.244.218.42]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7AMGEFl010825 for ; Sun, 10 Aug 2003 15:16:15 -0700 Received: (qmail 4742 invoked by uid 777); 10 Aug 2003 22:16:40 -0000 Date: Mon, 11 Aug 2003 00:16:40 +0200 From: Karol Kozimor To: Nathan Scott Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [2.5/2.6] buffer layer error at fs/buffer.c:2800 when unlinking Message-ID: <20030810221640.GA14257@hell.org.pl> Mail-Followup-To: Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20030803145113.GA31715@hell.org.pl> <20030806235908.GC854@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <20030806235908.GC854@frodo> User-Agent: Mutt/1.4.1i X-archive-position: 4952 X-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: 608 Lines: 17 Thus wrote Nathan Scott: > This is indeed an XFS issue (thanks for reporting it), the > patch below fixes it. Thanks, it works fine now. I've still got one issue with XFS (this: [1] may be helpful) left, though I didn't manage yet to reproduce it under 2.6.0-test3 (though I've seen it with 2.6.0-test2, even with the above patch applied), so I'll start bothering you when (if, hopefully) this happens. Thanks again, [1] http://marc.theaimsgroup.com/?l=linux-xfs&m=105240964125502&w=2 (I reported this once or twice on linux-xfs, however unsuccessfully) -- Karol 'sziwan' Kozimor sziwan@hell.org.pl From owner-linux-xfs@oss.sgi.com Sun Aug 10 15:16:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Aug 2003 15:16:52 -0700 (PDT) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7AMGlFl010999 for ; Sun, 10 Aug 2003 15:16:48 -0700 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <0.016A1C50@mailhub2.arup.com>; 10 Aug 2003 23:16:41 +0100 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Sun, 10 Aug 2003 23:16:40 +0100 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Mon, 11 Aug 2003 08:15:43 +1000 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Mon, 11 Aug 2003 08:15:15 +1000 From: "Scott Fagg" To: Cc: Subject: Re: kernel errors when XFS filesystem fills up Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7AMGmFl011007 X-archive-position: 4953 X-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.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 2805 Lines: 94 > > >>>> Steve Lord 08/08/2003 11:56:14 PM >>> >On Fri, 2003-08-08 at 01:12, Scott Fagg wrote: >> > >> > >> >>>> Nathan Scott 08/08/2003 3:03:45 PM >>> >> > >> >For some strange reason we are trying to read at AG blk 0 for that >> >inode, which is wrong - block zero in an AG holds the SB/AGF/AGI/ >> >AGFL for that allocation group. Its not clear if this is due to >> >the EA data on disk pointing to that block, or a bug in the kernel >> >code. The tools not finding anything suggests to me a kernel bug, >> >not sure where though... >> > >> >> So what should i do to generate more debug info ? >> >> Not sure if it helps, but this sequence of events might give a clue : >> >> - run 'find' on the XFS vol >> - it hits a nasty inode and trigges the kernel message i see. >> - track down the inode mentioned and remove it and it's parent directory >> - run 'find' again .. no errors triggered >> - copy heaps of files back to the XFS vol and the error will probably occur again a couple of times, even if i'm copying 1000's of files. >> - backup files ( except faulty inodes ) >> - re-format XFS parition >> - copy files back >> - .. no errors occur .. until the volume fills up again. > > >Do you have some examples of the type of ACL setup you have on these >files? Relatively simple ones ( i thought ). getfacl returns : # file: 2003-07-27 ( <- actually a directory in this example ) # owner: slb # group: slb user::rwx user:sf:rwx user:slb:rwx group::rwx group:backups:rwx mask::rwx other::r-x default:user::rwx default:user:sf:rwx default:user:slb:rwx default:group::rwx default:group:backups:rwx default:mask::rwx default:other::r-x I've been applying these permissions with : setfacl -dm u:sf:rwx,g::rwx,o::r-x,m::rwx 2003-07-27 setfacl -m u:sf:rwx,g::rwx,o::r-x,m::rwx 2003-07-27 setfacl -R -dm u:sf:rwx,g::rwx,o::r-x,m::rwx 2003-07-27 setfacl -R -m u:sf:rwx,g::rwx,o::r-x,m::rwx 2003-07-27 As a bit of background, the server in question is a backup server, at the end of each day i do an incremental copy of files to it from another box. Makes for around 10GB per day, and perhaps 5000 files. Worst case actually involved 80,000 files. The volume is 170GB and would have 100,000's of files. ( is there quick way to count files on a volume ? ) 'find | wc' takes ages > >The problem may well be down in dealing with large numbers of them, >or large sized acls. The large numbers i could understand, but i thought my ACLs were relatively simple. I'm only trying to ensure that 2-3 users have full access to all files. > >Steve > >-- > >Steve Lord voice: +1-651-683-3511 >Principal Engineer, Filesystem Software email: lord@sgi.com > > Scott Fagg Arup Brisbane (07) 3023 6000 From owner-linux-xfs@oss.sgi.com Sun Aug 10 17:36:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Aug 2003 17:37:07 -0700 (PDT) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7B0anFl021095 for ; Sun, 10 Aug 2003 17:36:49 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7AMbJQa023703 for ; Sun, 10 Aug 2003 15:37:20 -0700 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 KAA29748; Mon, 11 Aug 2003 10:36:41 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7B0aA3K278180; Mon, 11 Aug 2003 10:36:30 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7B0Ykpa009619; Mon, 11 Aug 2003 10:34:54 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7B0YEDc009617; Mon, 11 Aug 2003 10:34:14 +1000 Date: Mon, 11 Aug 2003 10:34:14 +1000 From: Nathan Scott To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [2.5/2.6] buffer layer error at fs/buffer.c:2800 when unlinking Message-ID: <20030811003413.GD9384@frodo> References: <20030803145113.GA31715@hell.org.pl> <20030806235908.GC854@frodo> <20030810221640.GA14257@hell.org.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030810221640.GA14257@hell.org.pl> User-Agent: Mutt/1.5.3i X-archive-position: 4954 X-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: 794 Lines: 22 On Mon, Aug 11, 2003 at 12:16:40AM +0200, Karol Kozimor wrote: > Thus wrote Nathan Scott: > > This is indeed an XFS issue (thanks for reporting it), the > > patch below fixes it. > > Thanks, it works fine now. I've still got one issue with XFS (this: [1] may > be helpful) left, though I didn't manage yet to reproduce it under > 2.6.0-test3 (though I've seen it with 2.6.0-test2, even with the above > patch applied), so I'll start bothering you when (if, hopefully) this > happens. Thanks again, > > [1] http://marc.theaimsgroup.com/?l=linux-xfs&m=105240964125502&w=2 > (I reported this once or twice on linux-xfs, however unsuccessfully) A random corruption problem was fixed in test3 also, that may well be what this issue is. Let us know if you see it again. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Aug 10 17:39:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Aug 2003 17:39:12 -0700 (PDT) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7B0d8Fl021503 for ; Sun, 10 Aug 2003 17:39:08 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7AMddQa023999 for ; Sun, 10 Aug 2003 15:39:39 -0700 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 KAA29766; Mon, 11 Aug 2003 10:38:20 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7B0bn3K283214; Mon, 11 Aug 2003 10:38:09 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7B0aXpa009637; Mon, 11 Aug 2003 10:36:33 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7B0a8Yu009635; Mon, 11 Aug 2003 10:36:08 +1000 Date: Mon, 11 Aug 2003 10:36:08 +1000 From: Nathan Scott To: Scott Fagg Cc: linux-xfs@oss.sgi.com Subject: Re: kernel errors when XFS filesystem fills up Message-ID: <20030811003608.GE9384@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: 4955 X-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: 533 Lines: 17 On Mon, Aug 11, 2003 at 08:15:15AM +1000, Scott Fagg wrote: > > As a bit of background, the server in question is a backup server, at > the end of each day i do an incremental copy of files to it from > another box. Makes for around 10GB per day, and perhaps 5000 files. > Worst case actually involved 80,000 files. The volume is 170GB and > would have 100,000's of files. ( is there quick way to count files > on a volume ? ) 'find | wc' takes ages > This is part of the statfs(2) info -- df -i reports it. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Aug 10 17:43:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Aug 2003 17:43:03 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7B0gxFl022113 for ; Sun, 10 Aug 2003 17:42:59 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7B12psR024764 for ; Sun, 10 Aug 2003 20:02:53 -0500 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 KAA29810; Mon, 11 Aug 2003 10:42:33 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7B0g23K283008; Mon, 11 Aug 2003 10:42:22 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7B0ekpa009668; Mon, 11 Aug 2003 10:40:46 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7B0ect1009666; Mon, 11 Aug 2003 10:40:38 +1000 Date: Mon, 11 Aug 2003 10:40:38 +1000 From: Nathan Scott To: Scott Fagg Cc: linux-xfs@oss.sgi.com Subject: Re: kernel errors when XFS filesystem fills up Message-ID: <20030811004038.GF9384@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: 4956 X-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: 494 Lines: 16 On Mon, Aug 11, 2003 at 08:08:59AM +1000, Scott Fagg wrote: > ... > I tried creating a small XFS volume (100MB) in a file , not a > partition, filled it up but it didn't produce any errors. I'll > keep experimenting. Probably a good idea to focus on getting/setting ACLs when the volume is full or close to full (so fill it with dd first, then script a bunch of gets/sets, see if that fails reliably), from your other mails sounds like that may be a contributing factor. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Aug 10 19:15:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Aug 2003 19:15:51 -0700 (PDT) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7B2FWFl023252 for ; Sun, 10 Aug 2003 19:15:33 -0700 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <0.016A2222@mailhub2.arup.com>; Mon, 11 Aug 2003 2:44:09 +0100 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Mon, 11 Aug 2003 02:44:07 +0100 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Mon, 11 Aug 2003 11:43:10 +1000 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Mon, 11 Aug 2003 11:40:17 +1000 From: "Scott Fagg" To: Subject: Re: kernel errors when XFS filesystem fills up Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7B2FYFl023253 X-archive-position: 4957 X-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.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 20586 Lines: 312 >>>> Nathan Scott 11/08/2003 10:40:38 AM >>> >On Mon, Aug 11, 2003 at 08:08:59AM +1000, Scott Fagg wrote: >> ... >> I tried creating a small XFS volume (100MB) in a file , not a >> partition, filled it up but it didn't produce any errors. I'll >> keep experimenting. > >Probably a good idea to focus on getting/setting ACLs when the >volume is full or close to full (so fill it with dd first, then >script a bunch of gets/sets, see if that fails reliably), from >your other mails sounds like that may be a contributing factor. > >thanks. Nathan, It does indeed look like it's the ACLs... This process seems to trigger it: - create small file-based XFS volume (100MB) - fill it up - try adding a default ACL recursively or slightly different - create small file-based XFS volumen (100MB) - set default, inheritable ACL on the root - fill it up - ( no errors occur other than 'device full' ) - try copying the same files again over the top ( e.g cp -rfv ) Here's the commands i used to trigger it : dd if=/dev/zero of=/tmp/xfs.fs bs=1M count=100 /sbin/mkfs.xfs -f /tmp/xfs.fs mount -o loop -t xfs /tmp/xfs.fs /mnt/test/ cd /mnt/test/ mkdir subdir setfacl -R -dm u:sf:rwx,g::rwx,o::r-x,m::rwx subdir cd subdir cp -rfv /usr/src/linux* . ( file system fills up with cp return errors like "No space left on device" , but no kernel errors ) cp -rfv /usr/src/linux* . The second attempt at copying files fails with the first log excerpt below. - if i omit the setfacl call, the error never happens, i just get "no space left on device" - the error didn't happen straight away, it had copied a few hundred files before doing so - according to 'df' , space on the volume was going UP AND DOWN, fluctuating between 5MB and a 100k during the copying, it was only when the space dropped to next to nothing and stayed there that the error occured - once an inode is damaged, any attempt to manipulte the inode causes an error - if i remove as many files as possilbe from the volume , but leave at least on damaged inode, trying to get the acls from that inode triggers an error ( see the second log file excerpt below ) Aug 11 11:11:29 bneuxs02 kernel: XFS mounting filesystem loop(7,0) Aug 11 11:11:29 bneuxs02 kernel: Ending clean XFS mount for filesystem: loop(7,0) Aug 11 11:15:49 bneuxs02 kernel: xfs_da_do_buf: bno 0 Aug 11 11:15:49 bneuxs02 kernel: dir: inode 723377 Aug 11 11:15:49 bneuxs02 kernel: Filesystem "loop(7,0)": XFS internal error xfs_da_do_buf(1) at line 2184 of file xfs_da_btree.c. Caller 0xc0195257 Aug 11 11:15:49 bneuxs02 kernel: d32e1d14 c0194b01 c0295101 00000001 d1317400 c029505c 00000888 c0195257 Aug 11 11:15:49 bneuxs02 kernel: 00000001 00000000 d1317400 d32e1d6c 00000001 00000000 00000000 00000001 Aug 11 11:15:49 bneuxs02 kernel: 00000000 d1317400 d32e1d88 c1054da0 000003de 00000c48 00000000 00000000 Aug 11 11:15:49 bneuxs02 kernel: Call Trace: Aug 11 11:15:49 bneuxs02 kernel: [] xfs_da_do_buf+0x211/0x8b0 [kernel] Aug 11 11:15:49 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:15:49 bneuxs02 kernel: [] __alloc_pages+0x4b/0x190 [kernel] Aug 11 11:15:49 bneuxs02 kernel: [] pagebuf_rele+0x81/0xb0 [kernel] Aug 11 11:15:49 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:15:49 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:49 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:49 bneuxs02 kernel: [] xfs_attr_node_get+0x3c/0xd0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_attr_fetch+0xff/0x1b0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_acl_iaccess+0x54/0xe0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_iaccess+0x19c/0x1b0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_access+0x3b/0x60 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] linvfs_permission+0x29/0x30 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] permission+0x3a/0x40 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] open_namei+0xc6/0x5d0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] filp_open+0x43/0x70 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] sys_open+0x53/0xa0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] system_call+0x33/0x38 [kernel] Aug 11 11:15:50 bneuxs02 kernel: Aug 11 11:15:50 bneuxs02 kernel: xfs_attr_leaf_get+0x50/0xe0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_da_do_buf+0x41d/0x8b0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_attr_node_get+0x3c/0xd0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_attr_fetch+0xff/0x1b0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_acl_iaccess+0x54/0xe0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_iaccess+0x19c/0x1b0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_access+0x3b/0x60 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] linvfs_lookup+0x0/0xb0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] linvfs_permission+0x29/0x30 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] permission+0x3a/0x40 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] link_path_walk+0x60/0x6e0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] path_lookup+0x39/0x40 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] __user_walk+0x49/0x60 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] sys_lstat64+0x1f/0x90 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] system_call+0x33/0x38 [kernel] Aug 11 11:15:50 bneuxs02 kernel: Aug 11 11:15:50 bneuxs02 kernel: xfs_da_do_buf: bno 0 Aug 11 11:15:50 bneuxs02 kernel: dir: inode 62552 Aug 11 11:15:50 bneuxs02 kernel: Filesystem "loop(7,0)": XFS internal error xfs_da_do_buf(1) at line 2184 of file xfs_da_btree.c. Caller 0xc0195257 Aug 11 11:15:50 bneuxs02 kernel: d32e1cc8 c0194b01 c0295101 00000001 d1317400 c029505c 00000888 c0195257 Aug 11 11:15:50 bneuxs02 kernel: c17fe340 00000008 c0179850 00007dc8 00000000 c0194d0d 00000001 00000001 Aug 11 11:15:50 bneuxs02 kernel: 00000000 d1317400 d32e1d3c 00000008 000003de d32e1d50 00000000 d32e1d5c Aug 11 11:15:50 bneuxs02 kernel: Call Trace: Aug 11 11:15:51 bneuxs02 kernel: [] xfs_da_do_buf+0x211/0x8b0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_attr_leaf_get+0x50/0xe0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_da_do_buf+0x41d/0x8b0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_attr_node_get+0x3c/0xd0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_attr_fetch+0xff/0x1b0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_acl_iaccess+0x54/0xe0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_iaccess+0x19c/0x1b0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_access+0x3b/0x60 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] linvfs_lookup+0x0/0xb0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] linvfs_permission+0x29/0x30 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] permission+0x3a/0x40 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] link_path_walk+0x60/0x6e0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] path_lookup+0x39/0x40 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] open_namei+0x2a7/0x5d0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] filp_open+0x43/0x70 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] sys_open+0x53/0xa0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] system_call+0x33/0x38 [kernel] Aug 11 11:15:51 bneuxs02 kernel: Aug 11 11:15:51 bneuxs02 kernel: xfs_da_do_buf: bno 0 Aug 11 11:15:51 bneuxs02 kernel: dir: inode 62552 Aug 11 11:15:51 bneuxs02 kernel: Filesystem "loop(7,0)": XFS internal error xfs_da_do_buf(1) at line 2184 of file xfs_da_btree.c. Caller 0xc0195257 Aug 11 11:15:51 bneuxs02 kernel: d32e1cf4 c0194b01 c0295101 00000001 d1317400 c029505c 00000888 c0195257 Aug 11 11:15:51 bneuxs02 kernel: 00000008 000003de d32e1d50 00000000 d32e1d5c 00000000 ca79e1a8 00000001 Aug 11 11:15:51 bneuxs02 kernel: 00000000 d1317400 d32e1d68 d32e1d6c 000003de 00000000 00000000 d5a46a40 Aug 11 11:15:51 bneuxs02 kernel: Call Trace: Aug 11 11:15:51 bneuxs02 kernel: [] xfs_da_do_buf+0x211/0x8b0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:15:52 bneuxs02 last message repeated 2 times Aug 11 11:15:52 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_attr_node_get+0x3c/0xd0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_attr_fetch+0xff/0x1b0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_acl_iaccess+0x54/0xe0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_iaccess+0x19c/0x1b0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_access+0x3b/0x60 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] linvfs_permission+0x29/0x30 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] permission+0x3a/0x40 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] lookup_hash+0x2e/0xd0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] open_namei+0x2f7/0x5d0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] filp_open+0x43/0x70 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] sys_open+0x53/0xa0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] system_call+0x33/0x38 [kernel] Aug 11 11:15:52 bneuxs02 kernel: Aug 11 11:15:52 bneuxs02 kernel: xfs_da_do_buf: bno 0 Aug 11 11:15:52 bneuxs02 kernel: dir: inode 62552 Aug 11 11:15:52 bneuxs02 kernel: Filesystem "loop(7,0)": XFS internal error xfs_da_do_buf(1) at line 2184 of file xfs_da_btree.c. Caller 0xc0195257 Aug 11 11:15:52 bneuxs02 kernel: d32e1cf4 c0194b01 c0295101 00000001 d1317400 c029505c 00000888 c0195257 Aug 11 11:15:52 bneuxs02 kernel: 00000008 000003de d32e1d50 00000000 d32e1d5c 00000000 ca79e1a8 00000001 Aug 11 11:15:52 bneuxs02 kernel: 0000008b0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_attr_leaf_get+0x50/0xe0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_da_do_buf+0x41d/0x8b0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_attr_node_get+0x3c/0xd0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_attr_fetch+0xff/0x1b0 [kernel] ( i stopped watching the log at this point ) Log below is from 'getfacl dir1' , where dir1 is inode 262439 and had been mentioned in a log similar to that above. Aug 11 11:27:56 bneuxs02 kernel: xfs_da_do_buf: bno 0 Aug 11 11:27:56 bneuxs02 kernel: dir: inode 262439 Aug 11 11:27:56 bneuxs02 kernel: Filesystem "loop(7,0)": XFS internal error xfs_da_do_buf(1) at line 2184 of file xfs_da_btree.c. Caller 0xc0195257 Aug 11 11:27:56 bneuxs02 kernel: c4e37d14 c0194b01 c0295101 00000001 cafc4c00 c029505c 00000888 c0195257 Aug 11 11:27:56 bneuxs02 kernel: 00000001 00000000 cafc4c00 c4e37d6c 00000001 00000000 00000000 00000001 Aug 11 11:27:56 bneuxs02 kernel: 00000000 cafc4c00 c4e37d88 c11f5b90 000003de 0000973d 00000000 00000000 Aug 11 11:27:56 bneuxs02 kernel: Call Trace: Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_do_buf+0x211/0x8b0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] __alloc_pages+0x4b/0x190 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] pagebuf_rele+0x81/0xb0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_attr_node_get+0x3c/0xd0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_attr_fetch+0xff/0x1b0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_acl_iaccess+0x54/0xe0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_iaccess+0x19c/0x1b0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_access+0x3b/0x60 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] linvfs_permission+0x29/0x30 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] permission+0x3a/0x40 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] open_namei+0xc6/0x5d0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] filp_open+0x43/0x70 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] sys_open+0x53/0xa0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] system_call+0x33/0x38 [kernel] Aug 11 11:27:56 bneuxs02 kernel: Aug 11 11:27:56 bneuxs02 kernel: xfs_da_do_buf: bno 0 Aug 11 11:27:56 bneuxs02 kernel: dir: inode 262439 Aug 11 11:27:56 bneuxs02 kernel: Filesystem "loop(7,0)": XFS internal error xfs_da_do_buf(1) at line 2184 of file xfs_da_btree.c. Caller 0xc0195257 Aug 11 11:27:56 bneuxs02 kernel: c4e37ab0 c0194b01 c0295101 00000001 cafc4c00 c029505c 00000888 c0195257 Aug 11 11:27:56 bneuxs02 kernel: c03354f0 000001d2 c49edd60 d2db1e40 d599cc20 d599cc20 00000001 00000001 Aug 11 11:27:56 bneuxs02 kernel: 00000000 cafc4c00 c4e37b24 00000286 000003de c128f7c0 00000000 0000ca7e Aug 11 11:27:56 bneuxs02 kernel: Call Trace: Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_do_buf+0x211/0x8b0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] __alloc_pages+0x4b/0x190 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_attr_node_get+0x3c/0xd0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_attr_fetch+0xff/0x1b0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_acl_iaccess+0x54/0xe0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_iaccess+0x19c/0x1b0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_attr_get+0xce/0x1e0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] pagebuf_get+0xbf/0x150 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] kmem_zone_alloc+0x62/0x100 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_attr_leaf_get+0x50/0xe0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_buf_make+0x151/0x160 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_attr_leaf_get+0x50/0xe0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_do_buf+0x41d/0x8b0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_acl_get_attr+0x5d/0x90 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_acl_vget+0x5c/0x180 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] __alloc_pages+0x4b/0x190 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] pagebuf_rele+0x81/0xb0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_da_brelse+0x9a/0xc0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] linvfs_getxattr+0xe4/0x250 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] getxattr+0x121/0x150 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_acl_iaccess+0xd6/0xe0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_iaccess+0x19c/0x1b0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_iunlock+0x3e/0x80 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_access+0x4d/0x60 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] cached_lookup+0x1b/0x70 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] link_path_walk+0x57f/0x6e0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] __user_walk+0x5c/0x60 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] sys_getxattr+0x57/0x70 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] system_call+0x33/0x38 [kernel] Aug 11 11:27:57 bneuxs02 kernel: Aug 11 11:27:57 bneuxs02 kernel: xfs_da_do_buf: bno 0 Aug 11 11:27:57 bneuxs02 kernel: dir: inode 262439 Aug 11 11:27:57 bneuxs02 kernel: Filesystem "loop(7,0)": XFS internal error xfs_da_do_buf(1) at line 2184 of file xfs_da_btree.c. Caller 0xc0195257 Aug 11 11:27:57 bneuxs02 kernel: c4e37ab0 c0194b01 c0295101 00000001 cafc4c00 c029505c 00000888 c0195257 Aug 11 11:27:57 bneuxs02 kernel: c03354f0 000001d2 c49edd60 d2db1e40 d599cc20 d599cc20 00000001 00000001 Aug 11 11:27:57 bneuxs02 kernel: 00000000 cafc4c00 c4e37b24 00000286 000003de c128f7c0 00000000 0000ca7e Aug 11 11:27:57 bneuxs02 kernel: Call Trace: Aug 11 11:27:57 bneuxs02 kernel: [] xfs_da_do_buf+0x211/0x8b0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] __alloc_pages+0x4b/0x190 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_attr_node_get+0x3c/0xd0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_attr_fetch+0xff/0x1b0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_acl_iaccess+0x54/0xe0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_iaccess+0x19c/0x1b0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_attr_get+0xce/0x1e0 [kernel] [ Aug 11 11:27:57 bneuxs02 kernel: [] pagebuf_get+0xbf/0x150 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] kmem_zone_alloc+0x62/0x100 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_attr_leaf_get+0x50/0xe0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_da_buf_make+0x151/0x160 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_attr_leaf_get+0x50/0xe0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_da_do_buf+0x41d/0x8b0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_acl_get_attr+0x5d/0x90 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_acl_vget+0x5c/0x180 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] __alloc_pages+0x4b/0x190 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] pagebuf_rele+0x81/0xb0 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] xfs_da_brelse+0x9a/0xc0 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] linvfs_getxattr+0xe4/0x250 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] getxattr+0x121/0x150 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] xfs_acl_iaccess+0xd6/0xe0 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] xfs_iaccess+0x19c/0x1b0 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] xfs_iunlock+0x3e/0x80 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] xfs_access+0x4d/0x60 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] cached_lookup+0x1b/0x70 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] link_path_walk+0x57f/0x6e0 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] __user_walk+0x5c/0x60 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] sys_getxattr+0x57/0x70 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] system_call+0x33/0x38 [kernel] Aug 11 11:27:58 bneuxs02 kernel: Hope that helps .. > >-- >Nathan > > Scott Fagg Arup Brisbane (07) 3023 6000 From owner-linux-xfs@oss.sgi.com Sun Aug 10 21:49:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Aug 2003 21:50:14 -0700 (PDT) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7B4nrFl025374 for ; Sun, 10 Aug 2003 21:49:53 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7B2oOQa017781 for ; Sun, 10 Aug 2003 19:50:25 -0700 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 OAA02036; Mon, 11 Aug 2003 14:49:25 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7B4ms3K237295; Mon, 11 Aug 2003 14:49:14 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7B4lSpa010403; Mon, 11 Aug 2003 14:47:36 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7B4kt4f010401; Mon, 11 Aug 2003 14:46:55 +1000 Date: Mon, 11 Aug 2003 14:46:55 +1000 From: Nathan Scott To: Andrew Morton , Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: use-after-free in xfs_bawrite() Message-ID: <20030811044655.GK9384@frodo> References: <20030802013032.7a42a596.akpm@osdl.org> <1060020656.19357.10.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1060020656.19357.10.camel@jen.americas.sgi.com> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7B4nsFl025389 X-archive-position: 4958 X-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: 2093 Lines: 52 On Mon, Aug 04, 2003 at 01:10:56PM -0500, Steve Lord wrote: > On Sat, 2003-08-02 at 03:30, Andrew Morton wrote: > > Using Linus's current tree plus all the -mm gunk I get a fairly easy oops > > running dbench on XFS on SMP with CONFIG_DEBUG_PAGEALLOC=y: > > I can't hit it for some reason, but yes, I see it. As for why xfs I'm also unable to hit it - do you have anything special to generate that signal to kgdb Andrew? I'm using a hacked up kdb, not kgdb, but would have expected the pagealloc debug stuff still to trip me up on a bad pointer dereference. Any particular number of dbench clients? (thanks - I just want to be able to verify the fix, so want to start from a failing state). > and dbench don't mix so well - its a 2.6 thing, but having looked > at what the other places which wait for I/O in the kernel do, perhaps > if we made some similar changes to the xfs specific spots, things might > improve. Looks like getting into io_schedule would be a good thing > in a few strategic places. From some simple dbench tests we seem to be getting about half the throughput in 2.6 that we get in 2.4. > > Program received signal SIGEMT, Emulation trap. > > 0xc0282c9d in xfs_iflush (ip=0xc284a004, flags=2) at fs/xfs/pagebuf/page_buf.h:397 > > 397 if (!pb || atomic_read(&pb->pb_io_remaining)) > > (gdb) p pb > > $1 = (page_buf_t *) 0xc98d1004 > > (gdb) p *pb > > Cannot access memory at address 0xc98d1004 > > (gdb) bt > > #0 0xc0282c9d in xfs_iflush (ip=0xc284a004, flags=2) at fs/xfs/pagebuf/page_buf.h:397 > > ... > > > > The memory at 0xc98d1004 has been unmapped. > > ... > > > > The below quick patch fixes it up. But it also causes zillions of dentries > > and inodes to be leaked for some reason. Consider it a technology > > demonstration! Using a slight variation on your patch, same idea though, I am not seeing a dentry/inode leak (I'm looking at /proc/slabinfo, or is there some other definitive source?) and also not seeing any problems with debug_pagealloc switched on (but then, I was unable to hit it beforehand either). thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Aug 10 21:49:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Aug 2003 21:50:14 -0700 (PDT) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7B4nnFl025373 for ; Sun, 10 Aug 2003 21:49:51 -0700 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <0.016A287E@mailhub2.arup.com>; Mon, 11 Aug 2003 5:49:44 +0100 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Mon, 11 Aug 2003 05:49:41 +0100 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Mon, 11 Aug 2003 14:48:44 +1000 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Mon, 11 Aug 2003 14:46:18 +1000 From: "Scott Fagg" To: Subject: Re: kernel errors when XFS filesystem fills up Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7B4nqFl025381 X-archive-position: 1 X-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.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 20965 Lines: 325 One more bit of info , problem occurs on RH8 with 2.4.21-xfs from 8 August. Using standard kernel, not RH kernel. On RH7.2 with 2.4.17-xfs from sgi.com , problem does not occur. XFS version in that cause would have been pre Feb-15 2002. Scott Fagg Arup Brisbane (07) 3023 6000 >>> "Scott Fagg" 11/08/2003 11:40:17 AM >>> >>>> Nathan Scott 11/08/2003 10:40:38 AM >>> >On Mon, Aug 11, 2003 at 08:08:59AM +1000, Scott Fagg wrote: >> ... >> I tried creating a small XFS volume (100MB) in a file , not a >> partition, filled it up but it didn't produce any errors. I'll >> keep experimenting. > >Probably a good idea to focus on getting/setting ACLs when the >volume is full or close to full (so fill it with dd first, then >script a bunch of gets/sets, see if that fails reliably), from >your other mails sounds like that may be a contributing factor. > >thanks. Nathan, It does indeed look like it's the ACLs... This process seems to trigger it: - create small file-based XFS volume (100MB) - fill it up - try adding a default ACL recursively or slightly different - create small file-based XFS volumen (100MB) - set default, inheritable ACL on the root - fill it up - ( no errors occur other than 'device full' ) - try copying the same files again over the top ( e.g cp -rfv ) Here's the commands i used to trigger it : dd if=/dev/zero of=/tmp/xfs.fs bs=1M count=100 /sbin/mkfs.xfs -f /tmp/xfs.fs mount -o loop -t xfs /tmp/xfs.fs /mnt/test/ cd /mnt/test/ mkdir subdir setfacl -R -dm u:sf:rwx,g::rwx,o::r-x,m::rwx subdir cd subdir cp -rfv /usr/src/linux* . ( file system fills up with cp return errors like "No space left on device" , but no kernel errors ) cp -rfv /usr/src/linux* . The second attempt at copying files fails with the first log excerpt below. - if i omit the setfacl call, the error never happens, i just get "no space left on device" - the error didn't happen straight away, it had copied a few hundred files before doing so - according to 'df' , space on the volume was going UP AND DOWN, fluctuating between 5MB and a 100k during the copying, it was only when the space dropped to next to nothing and stayed there that the error occured - once an inode is damaged, any attempt to manipulte the inode causes an error - if i remove as many files as possilbe from the volume , but leave at least on damaged inode, trying to get the acls from that inode triggers an error ( see the second log file excerpt below ) Aug 11 11:11:29 bneuxs02 kernel: XFS mounting filesystem loop(7,0) Aug 11 11:11:29 bneuxs02 kernel: Ending clean XFS mount for filesystem: loop(7,0) Aug 11 11:15:49 bneuxs02 kernel: xfs_da_do_buf: bno 0 Aug 11 11:15:49 bneuxs02 kernel: dir: inode 723377 Aug 11 11:15:49 bneuxs02 kernel: Filesystem "loop(7,0)": XFS internal error xfs_da_do_buf(1) at line 2184 of file xfs_da_btree.c. Caller 0xc0195257 Aug 11 11:15:49 bneuxs02 kernel: d32e1d14 c0194b01 c0295101 00000001 d1317400 c029505c 00000888 c0195257 Aug 11 11:15:49 bneuxs02 kernel: 00000001 00000000 d1317400 d32e1d6c 00000001 00000000 00000000 00000001 Aug 11 11:15:49 bneuxs02 kernel: 00000000 d1317400 d32e1d88 c1054da0 000003de 00000c48 00000000 00000000 Aug 11 11:15:49 bneuxs02 kernel: Call Trace: Aug 11 11:15:49 bneuxs02 kernel: [] xfs_da_do_buf+0x211/0x8b0 [kernel] Aug 11 11:15:49 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:15:49 bneuxs02 kernel: [] __alloc_pages+0x4b/0x190 [kernel] Aug 11 11:15:49 bneuxs02 kernel: [] pagebuf_rele+0x81/0xb0 [kernel] Aug 11 11:15:49 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:15:49 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:49 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:49 bneuxs02 kernel: [] xfs_attr_node_get+0x3c/0xd0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_attr_fetch+0xff/0x1b0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_acl_iaccess+0x54/0xe0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_iaccess+0x19c/0x1b0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_access+0x3b/0x60 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] linvfs_permission+0x29/0x30 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] permission+0x3a/0x40 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] open_namei+0xc6/0x5d0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] filp_open+0x43/0x70 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] sys_open+0x53/0xa0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] system_call+0x33/0x38 [kernel] Aug 11 11:15:50 bneuxs02 kernel: Aug 11 11:15:50 bneuxs02 kernel: xfs_attr_leaf_get+0x50/0xe0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_da_do_buf+0x41d/0x8b0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_attr_node_get+0x3c/0xd0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_attr_fetch+0xff/0x1b0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_acl_iaccess+0x54/0xe0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_iaccess+0x19c/0x1b0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] xfs_access+0x3b/0x60 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] linvfs_lookup+0x0/0xb0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] linvfs_permission+0x29/0x30 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] permission+0x3a/0x40 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] link_path_walk+0x60/0x6e0 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] path_lookup+0x39/0x40 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] __user_walk+0x49/0x60 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] sys_lstat64+0x1f/0x90 [kernel] Aug 11 11:15:50 bneuxs02 kernel: [] system_call+0x33/0x38 [kernel] Aug 11 11:15:50 bneuxs02 kernel: Aug 11 11:15:50 bneuxs02 kernel: xfs_da_do_buf: bno 0 Aug 11 11:15:50 bneuxs02 kernel: dir: inode 62552 Aug 11 11:15:50 bneuxs02 kernel: Filesystem "loop(7,0)": XFS internal error xfs_da_do_buf(1) at line 2184 of file xfs_da_btree.c. Caller 0xc0195257 Aug 11 11:15:50 bneuxs02 kernel: d32e1cc8 c0194b01 c0295101 00000001 d1317400 c029505c 00000888 c0195257 Aug 11 11:15:50 bneuxs02 kernel: c17fe340 00000008 c0179850 00007dc8 00000000 c0194d0d 00000001 00000001 Aug 11 11:15:50 bneuxs02 kernel: 00000000 d1317400 d32e1d3c 00000008 000003de d32e1d50 00000000 d32e1d5c Aug 11 11:15:50 bneuxs02 kernel: Call Trace: Aug 11 11:15:51 bneuxs02 kernel: [] xfs_da_do_buf+0x211/0x8b0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_attr_leaf_get+0x50/0xe0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_da_do_buf+0x41d/0x8b0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_attr_node_get+0x3c/0xd0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_attr_fetch+0xff/0x1b0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_acl_iaccess+0x54/0xe0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_iaccess+0x19c/0x1b0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_access+0x3b/0x60 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] linvfs_lookup+0x0/0xb0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] linvfs_permission+0x29/0x30 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] permission+0x3a/0x40 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] link_path_walk+0x60/0x6e0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] path_lookup+0x39/0x40 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] open_namei+0x2a7/0x5d0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] filp_open+0x43/0x70 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] sys_open+0x53/0xa0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] system_call+0x33/0x38 [kernel] Aug 11 11:15:51 bneuxs02 kernel: Aug 11 11:15:51 bneuxs02 kernel: xfs_da_do_buf: bno 0 Aug 11 11:15:51 bneuxs02 kernel: dir: inode 62552 Aug 11 11:15:51 bneuxs02 kernel: Filesystem "loop(7,0)": XFS internal error xfs_da_do_buf(1) at line 2184 of file xfs_da_btree.c. Caller 0xc0195257 Aug 11 11:15:51 bneuxs02 kernel: d32e1cf4 c0194b01 c0295101 00000001 d1317400 c029505c 00000888 c0195257 Aug 11 11:15:51 bneuxs02 kernel: 00000008 000003de d32e1d50 00000000 d32e1d5c 00000000 ca79e1a8 00000001 Aug 11 11:15:51 bneuxs02 kernel: 00000000 d1317400 d32e1d68 d32e1d6c 000003de 00000000 00000000 d5a46a40 Aug 11 11:15:51 bneuxs02 kernel: Call Trace: Aug 11 11:15:51 bneuxs02 kernel: [] xfs_da_do_buf+0x211/0x8b0 [kernel] Aug 11 11:15:51 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:15:52 bneuxs02 last message repeated 2 times Aug 11 11:15:52 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_attr_node_get+0x3c/0xd0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_attr_fetch+0xff/0x1b0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_acl_iaccess+0x54/0xe0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_iaccess+0x19c/0x1b0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_access+0x3b/0x60 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] linvfs_permission+0x29/0x30 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] permission+0x3a/0x40 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] lookup_hash+0x2e/0xd0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] open_namei+0x2f7/0x5d0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] filp_open+0x43/0x70 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] sys_open+0x53/0xa0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] system_call+0x33/0x38 [kernel] Aug 11 11:15:52 bneuxs02 kernel: Aug 11 11:15:52 bneuxs02 kernel: xfs_da_do_buf: bno 0 Aug 11 11:15:52 bneuxs02 kernel: dir: inode 62552 Aug 11 11:15:52 bneuxs02 kernel: Filesystem "loop(7,0)": XFS internal error xfs_da_do_buf(1) at line 2184 of file xfs_da_btree.c. Caller 0xc0195257 Aug 11 11:15:52 bneuxs02 kernel: d32e1cf4 c0194b01 c0295101 00000001 d1317400 c029505c 00000888 c0195257] xf Aug 11 11:15:52 bneuxs02 kernel: 00000008 000003de d32e1d50 00000000 d32e1d5c 00000000 ca79e1a8 00000001 Aug 11 11:15:52 bneuxs02 kernel: 0000008b0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_attr_leaf_get+0x50/0xe0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_da_do_buf+0x41d/0x8b0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_attr_node_get+0x3c/0xd0 [kernel] Aug 11 11:15:52 bneuxs02 kernel: [] xfs_attr_fetch+0xff/0x1b0 [kernel] ( i stopped watching the log at this point ) Log below is from 'getfacl dir1' , where dir1 is inode 262439 and had been mentioned in a log similar to that above. Aug 11 11:27:56 bneuxs02 kernel: xfs_da_do_buf: bno 0 Aug 11 11:27:56 bneuxs02 kernel: dir: inode 262439 Aug 11 11:27:56 bneuxs02 kernel: Filesystem "loop(7,0)": XFS internal error xfs_da_do_buf(1) at line 2184 of file xfs_da_btree.c. Caller 0xc0195257 Aug 11 11:27:56 bneuxs02 kernel: c4e37d14 c0194b01 c0295101 00000001 cafc4c00 c029505c 00000888 c0195257 Aug 11 11:27:56 bneuxs02 kernel: 00000001 00000000 cafc4c00 c4e37d6c 00000001 00000000 00000000 00000001 Aug 11 11:27:56 bneuxs02 kernel: 00000000 cafc4c00 c4e37d88 c11f5b90 000003de 0000973d 00000000 00000000 Aug 11 11:27:56 bneuxs02 kernel: Call Trace: Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_do_buf+0x211/0x8b0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] __alloc_pages+0x4b/0x190 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] pagebuf_rele+0x81/0xb0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_attr_node_get+0x3c/0xd0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_attr_fetch+0xff/0x1b0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_acl_iaccess+0x54/0xe0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_iaccess+0x19c/0x1b0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_access+0x3b/0x60 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] linvfs_permission+0x29/0x30 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] permission+0x3a/0x40 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] open_namei+0xc6/0x5d0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] filp_open+0x43/0x70 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] sys_open+0x53/0xa0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] system_call+0x33/0x38 [kernel] Aug 11 11:27:56 bneuxs02 kernel: Aug 11 11:27:56 bneuxs02 kernel: xfs_da_do_buf: bno 0 Aug 11 11:27:56 bneuxs02 kernel: dir: inode 262439 Aug 11 11:27:56 bneuxs02 kernel: Filesystem "loop(7,0)": XFS internal error xfs_da_do_buf(1) at line 2184 of file xfs_da_btree.c. Caller 0xc0195257 Aug 11 11:27:56 bneuxs02 kernel: c4e37ab0 c0194b01 c0295101 00000001 cafc4c00 c029505c 00000888 c0195257 Aug 11 11:27:56 bneuxs02 kernel: c03354f0 000001d2 c49edd60 d2db1e40 d599cc20 d599cc20 00000001 00000001 Aug 11 11:27:56 bneuxs02 kernel: 00000000 cafc4c00 c4e37b24 00000286 000003de c128f7c0 00000000 0000ca7e Aug 11 11:27:56 bneuxs02 kernel: Call Trace: Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_do_buf+0x211/0x8b0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] __alloc_pages+0x4b/0x190 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_attr_node_get+0x3c/0xd0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_attr_fetch+0xff/0x1b0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_acl_iaccess+0x54/0xe0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_iaccess+0x19c/0x1b0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_attr_get+0xce/0x1e0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] pagebuf_get+0xbf/0x150 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] kmem_zone_alloc+0x62/0x100 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_attr_leaf_get+0x50/0xe0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_buf_make+0x151/0x160 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_attr_leaf_get+0x50/0xe0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_da_do_buf+0x41d/0x8b0 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_acl_get_attr+0x5d/0x90 [kernel] Aug 11 11:27:56 bneuxs02 kernel: [] xfs_acl_vget+0x5c/0x180 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] __alloc_pages+0x4b/0x190 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] pagebuf_rele+0x81/0xb0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_da_brelse+0x9a/0xc0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] linvfs_getxattr+0xe4/0x250 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] getxattr+0x121/0x150 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_acl_iaccess+0xd6/0xe0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_iaccess+0x19c/0x1b0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_iunlock+0x3e/0x80 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_access+0x4d/0x60 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] cached_lookup+0x1b/0x70 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] link_path_walk+0x57f/0x6e0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] __user_walk+0x5c/0x60 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] sys_getxattr+0x57/0x70 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] system_call+0x33/0x38 [kernel] Aug 11 11:27:57 bneuxs02 kernel: Aug 11 11:27:57 bneuxs02 kernel: xfs_da_do_buf: bno 0 Aug 11 11:27:57 bneuxs02 kernel: dir: inode 262439 Aug 11 11:27:57 bneuxs02 kernel: Filesystem "loop(7,0)": XFS internal error xfs_da_do_buf(1) at line 2184 of file xfs_da_btree.c. Caller 0xc0195257 Aug 11 11:27:57 bneuxs02 kernel: c4e37ab0 c0194b01 c0295101 00000001 cafc4c00 c029505c 00000888 c0195257 Aug 11 11:27:57 bneuxs02 kernel: c03354f0 000001d2 c49edd60 d2db1e40 d599cc20 d599cc20 00000001 00000001 Aug 11 11:27:57 bneuxs02 kernel: 00000000 cafc4c00 c4e37b24 00000286 000003de c128f7c0 00000000 0000ca7e Aug 11 11:27:57 bneuxs02 kernel: Call Trace: Aug 11 11:27:57 bneuxs02 kernel: [] xfs_da_do_buf+0x211/0x8b0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] __alloc_pages+0x4b/0x190 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_da_read_buf+0x57/0x60 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_da_node_lookup_int+0x7a/0x330 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_attr_node_get+0x3c/0xd0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_attr_fetch+0xff/0x1b0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_acl_iaccess+0x54/0xe0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_iaccess+0x19c/0x1b0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_attr_get+0xce/0x1e0 [kernel] [ Aug 11 11:27:57 bneuxs02 kernel: [] pagebuf_get+0xbf/0x150 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] kmem_zone_alloc+0x62/0x100 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_attr_leaf_get+0x50/0xe0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_da_buf_make+0x151/0x160 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_attr_leaf_get+0x50/0xe0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_da_do_buf+0x41d/0x8b0 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_acl_get_attr+0x5d/0x90 [kernel] Aug 11 11:27:57 bneuxs02 kernel: [] xfs_acl_vget+0x5c/0x180 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] __alloc_pages+0x4b/0x190 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] pagebuf_rele+0x81/0xb0 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] xfs_da_brelse+0x9a/0xc0 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] linvfs_getxattr+0xe4/0x250 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] getxattr+0x121/0x150 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] xfs_acl_iaccess+0xd6/0xe0 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] xfs_iaccess+0x19c/0x1b0 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] xfs_iunlock+0x3e/0x80 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] xfs_access+0x4d/0x60 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] cached_lookup+0x1b/0x70 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] link_path_walk+0x57f/0x6e0 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] __user_walk+0x5c/0x60 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] sys_getxattr+0x57/0x70 [kernel] Aug 11 11:27:58 bneuxs02 kernel: [] system_call+0x33/0x38 [kernel] Aug 11 11:27:58 bneuxs02 kernel: Hope that helps .. > >-- >Nathan > > Scott Fagg Arup Brisbane (07) 3023 6000 From owner-linux-xfs@oss.sgi.com Sun Aug 10 22:39:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Aug 2003 22:39:44 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7B5dJFl026509 for ; Sun, 10 Aug 2003 22:39:20 -0700 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id h7B5dCo09515; Sun, 10 Aug 2003 22:39:12 -0700 Date: Sun, 10 Aug 2003 22:39:22 -0700 From: Andrew Morton To: Nathan Scott Cc: lord@sgi.com, linux-xfs@oss.sgi.com Subject: Re: use-after-free in xfs_bawrite() Message-Id: <20030810223922.4095029e.akpm@osdl.org> In-Reply-To: <20030811044655.GK9384@frodo> References: <20030802013032.7a42a596.akpm@osdl.org> <1060020656.19357.10.camel@jen.americas.sgi.com> <20030811044655.GK9384@frodo> X-Mailer: Sylpheed version 0.9.4 (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: 2 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: linux-xfs Content-Length: 20933 Lines: 1001 Nathan Scott wrote: > > I'm also unable to hit it - do you have anything special to generate > that signal to kgdb Andrew? Nope. I can get a traditional oops by disabling kgdb in config and just running `dbench 32' on a 2-way with this .config. # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_LOG_BUF_SHIFT=20 # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MELAN is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_X86_4G is not set # CONFIG_X86_SWITCH_PAGETABLES is not set # CONFIG_X86_4G_VM_LAYOUT is not set # CONFIG_X86_UACCESS_INDIRECT is not set # CONFIG_X86_HIGH_ENTRY is not set CONFIG_HUGETLB_PAGE=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_PREEMPT=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # CONFIG_EDD is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y # CONFIG_HIGHPTE is not set CONFIG_MATH_EMULATION=y CONFIG_MTRR=y CONFIG_HAVE_DEC_LOCK=y # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI Support # CONFIG_ACPI=y # CONFIG_ACPI_HT_ONLY is not set CONFIG_ACPI_BOOT=y # CONFIG_ACPI_SLEEP is not set CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y CONFIG_ACPI_ASUS=y CONFIG_ACPI_TOSHIBA=y CONFIG_ACPI_DEBUG=y CONFIG_ACPI_BUS=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_APM=y CONFIG_APM_IGNORE_USER_SUSPEND=y CONFIG_APM_DO_ENABLE=y CONFIG_APM_CPU_IDLE=y CONFIG_APM_DISPLAY_BLANK=y CONFIG_APM_RTC_IS_GMT=y CONFIG_APM_ALLOW_INTS=y CONFIG_APM_REAL_MODE_POWER_OFF=y # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y # CONFIG_PCI_LEGACY_PROC is not set CONFIG_PCI_NAMES=y CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_PCMCIA_PROBE=y # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_MISC=y # # Generic Driver Options # # CONFIG_FW_LOADER is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PARPORT_PC_CML1=y # CONFIG_PARPORT_SERIAL is not set CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_OTHER is not set # CONFIG_PARPORT_1284 is not set # # Plug and Play support # # CONFIG_PNP is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set CONFIG_BLK_CPQ_CISS_DA=y # CONFIG_CISS_SCSI_TAPE is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y CONFIG_LBD=y # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_IDEDISK_STROKE is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set CONFIG_IDE_TASK_IOCTL=y CONFIG_IDE_TASKFILE_IO=y # # IDE chipset support/bugfixes # # CONFIG_BLK_DEV_CMD640 is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDE_TCQ is not set # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set # CONFIG_IDEDMA_PCI_WIP is not set CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set CONFIG_BLK_DEV_PIIX=y # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_DMA_NONPCI is not set # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set CONFIG_CHR_DEV_SG=y # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_REPORT_LUNS is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_AM53C974 is not set # CONFIG_SCSI_MEGARAID is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_SYM53C8XX is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_SEAGATE is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # CONFIG_SCSI_FERAL_ISP is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=m CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID5=m CONFIG_MD_MULTIPATH=m CONFIG_BLK_DEV_DM=m CONFIG_DM_IOCTL_V4=y # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y # CONFIG_NETLINK_DEV is not set CONFIG_UNIX=y CONFIG_NET_KEY=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set CONFIG_IPV6=y CONFIG_IPV6_PRIVACY=y CONFIG_INET6_AH=y CONFIG_INET6_ESP=y CONFIG_INET6_IPCOMP=y # CONFIG_IPV6_TUNNEL is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_NETFILTER is not set # CONFIG_XFRM_USER is not set # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IPV6_SCTP__=y # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set # CONFIG_LLC is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=y # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_ETHERTAP is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_MII is not set # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set CONFIG_NET_VENDOR_3COM=y # CONFIG_EL1 is not set # CONFIG_EL2 is not set # CONFIG_ELPLUS is not set # CONFIG_EL16 is not set CONFIG_EL3=y # CONFIG_3C515 is not set CONFIG_VORTEX=y # CONFIG_TYPHOON is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_B44 is not set # CONFIG_CS89x0 is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set CONFIG_E100=y # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices (depends on LLC=y) # # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # ISDN subsystem # # CONFIG_ISDN_BOOL is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y # CONFIG_MOUSE_PS2_SYNAPTICS is not set # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_INPORT is not set # CONFIG_MOUSE_LOGIBM is not set # CONFIG_MOUSE_PC110PAD is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set # CONFIG_INPUT_MISC is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y # CONFIG_SERIAL_8250_ACPI is not set # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # CONFIG_PRINTER is not set # CONFIG_PPDEV is not set # CONFIG_TIPAR is not set # # I2C support # # CONFIG_I2C is not set # # I2C Hardware Sensors Mainboard support # # # I2C Hardware Sensors Chip support # # CONFIG_I2C_SENSOR is not set # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_QIC02_TAPE is not set # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_HW_RANDOM is not set # CONFIG_NVRAM is not set CONFIG_RTC=m CONFIG_GEN_RTC=m CONFIG_GEN_RTC_X=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # CONFIG_DRM is not set # CONFIG_MWAVE is not set CONFIG_RAW_DRIVER=m # CONFIG_HANGCHECK_TIMER is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set # # File systems # CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y # CONFIG_EXT3_FS_SECURITY is not set CONFIG_JBD=y CONFIG_JBD_DEBUG=y CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=y # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_JFS_FS is not set CONFIG_FS_POSIX_ACL=y CONFIG_XFS_FS=y # CONFIG_XFS_RT is not set # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_POSIX_ACL is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set CONFIG_AUTOFS4_FS=y # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=y CONFIG_UDF_FS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set CONFIG_DEVPTS_FS=y # CONFIG_DEVPTS_FS_XATTR is not set CONFIG_TMPFS=y CONFIG_HUGETLBFS=y CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_NFS_V4 is not set CONFIG_NFS_DIRECTIO=y CONFIG_NFSD=y CONFIG_NFSD_V3=y # CONFIG_NFSD_V4 is not set # CONFIG_NFSD_TCP is not set CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=y CONFIG_SUNRPC=y # CONFIG_SUNRPC_GSS is not set # CONFIG_SMB_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_INTERMEZZO_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-1" # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ISO8859_1 is not set # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Graphics support # CONFIG_FB=y # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set # CONFIG_FB_VESA is not set CONFIG_VIDEO_SELECT=y # CONFIG_FB_HGA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_VIRTUAL is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=m CONFIG_PCI_CONSOLE=y # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # # Logo configuration # # CONFIG_LOGO is not set # # Sound # # CONFIG_SOUND is not set # # USB support # # CONFIG_USB is not set # CONFIG_USB_GADGET is not set # # Bluetooth support # # CONFIG_BT is not set # # Profiling support # CONFIG_PROFILING=y CONFIG_OPROFILE=m # # Kernel hacking # CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_STACKOVERFLOW is not set CONFIG_DEBUG_SLAB=y # CONFIG_DEBUG_IOVIRT is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_DEBUG_SPINLOCK is not set CONFIG_DEBUG_PAGEALLOC=y # CONFIG_SPINLINE is not set CONFIG_DEBUG_HIGHMEM=y # CONFIG_DEBUG_INFO is not set CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_KGDB is not set CONFIG_FRAME_POINTER=y CONFIG_X86_EXTRA_IRQS=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # CONFIG_SECURITY=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_CAPABILITIES=y # CONFIG_SECURITY_SELINUX is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=y CONFIG_CRYPTO_MD4=y CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA256=y CONFIG_CRYPTO_SHA512=y CONFIG_CRYPTO_DES=y CONFIG_CRYPTO_BLOWFISH=y CONFIG_CRYPTO_TWOFISH=y CONFIG_CRYPTO_SERPENT=y CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_DEFLATE=y CONFIG_CRYPTO_TEST=y # # Library routines # CONFIG_CRC32=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y From owner-linux-xfs@oss.sgi.com Sun Aug 10 23:39:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Aug 2003 23:40:09 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7B6dsFl029560 for ; Sun, 10 Aug 2003 23:39:54 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7B6xnsR010464 for ; Mon, 11 Aug 2003 01:59:50 -0500 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 QAA03084; Mon, 11 Aug 2003 16:39:05 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7B6cY3K284612; Mon, 11 Aug 2003 16:38:55 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7B6b9pa010734; Mon, 11 Aug 2003 16:37:09 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7B6aaHf010732; Mon, 11 Aug 2003 16:36:36 +1000 Date: Mon, 11 Aug 2003 16:36:36 +1000 From: Nathan Scott To: Scott Fagg Cc: linux-xfs@oss.sgi.com Subject: Re: kernel errors when XFS filesystem fills up Message-ID: <20030811063636.GM9384@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: 3 X-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: 790 Lines: 26 On Mon, Aug 11, 2003 at 02:46:18PM +1000, Scott Fagg wrote: > > One more bit of info , problem occurs on RH8 with 2.4.21-xfs from 8 August. Using standard kernel, not RH kernel. > > On RH7.2 with 2.4.17-xfs from sgi.com , problem does not occur. XFS version in that cause would have been pre Feb-15 2002. Ah - interesting to know, thanks. > > It does indeed look like it's the ACLs... > > This process seems to trigger it: Good stuff - I've got it happening locally now and have written a little script to reproduce it (much like yours), I'll look into it in more detail tomorrow. BTW if you're interested, mkfs.xfs -dfile,name=/tmp/foo,size=100m will do those dd+mkfs steps as one (creates foo as a sparse file too if /tmp supports that, so its quite quick). thanks! -- Nathan From owner-linux-xfs@oss.sgi.com Mon Aug 11 09:12:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Aug 2003 09:12:48 -0700 (PDT) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BGCMFl011076 for ; Mon, 11 Aug 2003 09:12:23 -0700 Received: from penguin.americas.sgi.com ([128.162.240.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7BECuQa026650 for ; Mon, 11 Aug 2003 07:12:56 -0700 Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by penguin.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h7BGC3Uo032205 for ; Mon, 11 Aug 2003 11:12:03 -0500 Received: (from lord@localhost) by penguin.americas.sgi.com (8.12.8/8.12.5/Submit) id h7BGC3GE032203 for linux-xfs@oss.sgi.com; Mon, 11 Aug 2003 11:12:03 -0500 Date: Mon, 11 Aug 2003 11:12:03 -0500 From: Steve Lord Message-Id: <200308111612.h7BGC3GE032203@penguin.americas.sgi.com> Subject: TAKE - merge up to 2.6.0-test3 To: linux-xfs@oss.sgi.com X-archive-position: 4 X-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@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 91424 Lines: 2299 Date: Mon Aug 11 08:56:28 PDT 2003 Workarea: penguin.americas.sgi.com:/src/lord/xfs-linux.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:155481a linux/arch/mips/lib-32/memset.S - 1.1 linux/arch/ppc64/boot/div64.S - 1.1 linux/sound/pci/ac97/ac97_proc.c - 1.1 linux/sound/pci/ac97/ac97_local.h - 1.1 linux/Documentation/DocBook/man/Makefile - 1.1 linux/security/selinux/ss/symtab.h - 1.1 linux/security/selinux/ss/symtab.c - 1.1 linux/arch/mips/vr4181/osprey/setup.c - 1.1 linux/security/selinux/ss/sidtab.h - 1.1 linux/security/selinux/ss/sidtab.c - 1.1 linux/security/selinux/ss/services.h - 1.1 linux/security/selinux/ss/services.c - 1.1 linux/security/selinux/ss/policydb.h - 1.1 linux/security/selinux/ss/policydb.c - 1.1 linux/security/selinux/ss/mls_types.h - 1.1 linux/security/selinux/ss/mls.h - 1.1 linux/security/selinux/ss/mls.c - 1.1 linux/arch/mips/vr4181/osprey/reset.c - 1.1 linux/arch/mips/vr4181/osprey/prom.c - 1.1 linux/arch/mips/vr4181/osprey/dbg_io.c - 1.1 linux/security/selinux/ss/hashtab.h - 1.1 linux/security/selinux/ss/hashtab.c - 1.1 linux/security/selinux/ss/global.h - 1.1 linux/security/selinux/ss/ebitmap.h - 1.1 linux/security/selinux/ss/ebitmap.c - 1.1 linux/security/selinux/ss/context.h - 1.1 linux/arch/mips/vr4181/osprey/Makefile - 1.1 linux/arch/mips/vr4181/common/time.c - 1.1 linux/arch/mips/vr4181/common/serial.c - 1.1 linux/security/selinux/ss/constraint.h - 1.1 linux/security/selinux/ss/avtab.h - 1.1 linux/security/selinux/ss/avtab.c - 1.1 linux/arch/mips/vr4181/common/irq.c - 1.1 linux/arch/mips/vr4181/common/int_handler.S - 1.1 linux/arch/mips/vr4181/common/Makefile - 1.1 linux/security/selinux/ss/Makefile - 1.1 linux/security/selinux/selinuxfs.c - 1.1 linux/drivers/i2c/busses/i2c-nforce2.c - 1.1 linux/security/selinux/include/security.h - 1.1 linux/security/selinux/include/objsec.h - 1.1 linux/security/selinux/include/initial_sid_to_string.h - 1.1 linux/drivers/media/video/btcx-risc.c - 1.1 linux/security/selinux/include/flask.h - 1.1 linux/security/selinux/include/common_perm_to_string.h - 1.1 linux/security/selinux/include/class_to_string.h - 1.1 linux/security/selinux/include/avc_ss.h - 1.1 linux/drivers/media/video/btcx-risc.h - 1.1 linux/security/selinux/include/avc.h - 1.1 linux/security/selinux/include/av_permissions.h - 1.1 linux/security/selinux/include/av_perm_to_string.h - 1.1 linux/security/selinux/include/av_inherit.h - 1.1 linux/security/selinux/hooks.c - 1.1 linux/security/selinux/avc.c - 1.1 linux/security/selinux/Makefile - 1.1 linux/security/selinux/Kconfig - 1.1 linux/Documentation/x86_64/boot-options.txt - 1.1 linux/drivers/net/irda/via-ircc.c - 1.1 linux/drivers/net/irda/via-ircc.h - 1.1 linux/scripts/split-man - 1.1 linux/drivers/net/sk98lin/skdim.c - 1.1 linux/drivers/net/sk98lin/skgemib.c - 1.1 linux/arch/alpha/boot/bootpz.c - 1.1 linux/arch/alpha/boot/misc.c - 1.1 linux/include/asm-mips/sn/sn0/arch.h - 1.1 linux/include/asm-mips/sn/sn0/hub.h - 1.1 linux/arch/ia64/ia32/elfcore32.h - 1.1 linux/scripts/mkconfigs - 1.1 linux/arch/mips/lib-32/dump_tlb.c - 1.1 linux/scripts/makeman - 1.1 linux/arch/mips/lib-32/csum_partial.S - 1.1 linux/arch/h8300/platform/h8s/edosk2674/crt0_ram.S - 1.1 linux/scripts/extract-ikconfig - 1.1 linux/arch/alpha/kernel/err_ev6.c - 1.1 linux/arch/alpha/kernel/err_ev7.c - 1.1 linux/scripts/binoffset.c - 1.1 linux/scripts/MAKEDEV.snd - 1.1 linux/arch/h8300/platform/h8s/edosk2674/rom.ld - 1.1 linux/drivers/pnp/pnpbios/bioscalls.c - 1.1 linux/drivers/pnp/pnpbios/pnpbios.h - 1.1 linux/arch/h8300/platform/h8s/generic/Makefile - 1.1 linux/drivers/pnp/pnpbios/rsparser.c - 1.1 linux/arch/h8300/platform/h8s/generic/crt0_rom.S - 1.1 linux/arch/mips/lib-32/Makefile - 1.1 linux/arch/h8300/platform/h8s/generic/ram.ld - 1.1 linux/arch/mips/mm/tlb-andes.c - 1.1 linux/arch/h8300/platform/h8s/generic/rom.ld - 1.1 linux/arch/mips/hp-lj/Makefile - 1.1 linux/arch/h8300/platform/h8s/generic/timer.c - 1.1 linux/arch/mips/hp-lj/asic.c - 1.1 linux/arch/mips/hp-lj/gdb_hook.c - 1.1 linux/arch/mips/hp-lj/init.c - 1.1 linux/include/asm-arm/local.h - 1.1 linux/include/asm-arm/sections.h - 1.1 linux/include/asm-h8300/aki3068net/timer_rate.h - 1.1 linux/include/asm-h8300/edosk2674/timer_rate.h - 1.1 linux/include/asm-h8300/h8max/timer_rate.h - 1.1 linux/include/asm-h8300/local.h - 1.1 linux/include/asm-h8300/sections.h - 1.1 linux/arch/mips/hp-lj/int-handler.S - 1.1 linux/arch/mips/hp-lj/irq.c - 1.1 linux/arch/mips/hp-lj/setup.c - 1.1 linux/arch/mips/defconfig-osprey - 1.1 linux/arch/mips/hp-lj/utils.c - 1.1 linux/include/asm-ia64/sections.h - 1.1 linux/arch/mips/hp-lj/utils.h - 1.1 linux/include/asm-alpha/err_ev7.h - 1.1 linux/include/asm-mips/arc/hinv.h - 1.1 linux/arch/mips/defconfig-ivr - 1.1 linux/include/asm-alpha/err_ev6.h - 1.1 linux/arch/mips/defconfig-ip32 - 1.1 linux/arch/mips/defconfig-ip27 - 1.1 linux/include/asm-mips/asmmacro-32.h - 1.1 linux/arch/mips/defconfig-hp-lj - 1.1 linux/include/asm-mips/asmmacro-64.h - 1.1 linux/include/asm-alpha/err_common.h - 1.1 linux/kernel/power/swsusp.c - 1.1 linux/kernel/power/process.c - 1.1 linux/kernel/power/power.h - 1.1 linux/kernel/power/console.c - 1.1 linux/kernel/power/Makefile - 1.1 linux/arch/mips/mm-64/tlbex-r4k.S - 1.1 linux/arch/mips/jazz/jazz-ksyms.c - 1.1 linux/arch/mips/mm-64/tlb-glue-sb1.S - 1.1 linux/arch/mips/lib-32/r3k_dump_tlb.c - 1.1 linux/arch/mips/mm-64/tlb-glue-r4k.S - 1.1 linux/kernel/configs.c - 1.1 linux/arch/mips/mm/pgtable-64.c - 1.1 linux/arch/mips/mm-64/tlb-dbg-r4k.c - 1.1 linux/arch/mips/mm-64/pg-r4k.c - 1.1 linux/arch/mips/kernel/binfmt_elfn32.c - 1.1 linux/include/asm-mips/compat.h - 1.1 linux/arch/mips/kernel/binfmt_elfo32.c - 1.1 linux/arch/mips/mm-64/init.c - 1.1 linux/arch/mips/kernel/cpu-bugs64.c - 1.1 linux/arch/mips/mm-64/Makefile - 1.1 linux/arch/mips/mm-32/tlbex-r4k.S - 1.1 linux/arch/mips/mm-32/pg-r4k.S - 1.1 linux/arch/mips/kernel/genex.S - 1.1 linux/arch/mips/mm-32/init.c - 1.1 linux/arch/mips/mm/cex-gen.S - 1.1 linux/arch/mips/kernel/ioctl32.c - 1.1 linux/arch/mips/mm-32/Makefile - 1.1 linux/include/asm-mips/hp-lj/asic.h - 1.1 linux/arch/mips/kernel/linux32.c - 1.1 linux/arch/mips/kernel/module-elf32.c - 1.1 linux/include/asm-mips/ip32/crime.h - 1.1 linux/include/asm-mips/ip32/ip32_ints.h - 1.1 linux/include/asm-mips/ip32/mace.h - 1.1 linux/include/asm-mips/ip32/machine.h - 1.1 linux/arch/mips/kernel/module-elf64.c - 1.1 linux/include/asm-x86_64/local.h - 1.1 linux/include/asm-v850/sections.h - 1.1 linux/include/asm-v850/local.h - 1.1 linux/arch/mips/lib-64/watch.S - 1.1 linux/arch/mips/kernel/ptrace32.c - 1.1 linux/include/asm-sparc/sections.h - 1.1 linux/include/asm-sparc/local.h - 1.1 linux/include/asm-ppc64/sections.h - 1.1 linux/include/asm-mips/xtalk/xwidget.h - 1.1 linux/include/asm-mips/xtalk/xtalk.h - 1.1 linux/include/asm-mips/local.h - 1.1 linux/include/asm-mips/vr4181/vr4181.h - 1.1 linux/include/asm-mips/vr4181/irq.h - 1.1 linux/include/asm-mips/m48t35.h - 1.1 linux/arch/mips/lib-64/strnlen_user.S - 1.1 linux/arch/mips/lib-64/strncpy_user.S - 1.1 linux/include/asm-mips/mmzone.h - 1.1 linux/arch/mips/lib-64/strlen_user.S - 1.1 linux/include/asm-mips/page-32.h - 1.1 linux/include/asm-mips/page-64.h - 1.1 linux/arch/mips/kernel/reg.c - 1.1 linux/arch/mips/kernel/scall32-o32.S - 1.1 linux/include/asm-mips/pci/bridge.h - 1.1 linux/include/asm-mips/pgtable-32.h - 1.1 linux/include/asm-mips/pgtable-64.h - 1.1 linux/arch/mips/kernel/scall64-64.S - 1.1 linux/arch/mips/kernel/scall64-n32.S - 1.1 linux/arch/mips/kernel/scall64-o32.S - 1.1 linux/arch/h8300/platform/h8300h/generic/crt0_ram.S - 1.1 linux/arch/mips/lib-64/memset.S - 1.1 linux/arch/mips/lib-64/dump_tlb.c - 1.1 linux/arch/mips/lib-64/csum_partial.S - 1.1 linux/include/asm-mips/sn/types.h - 1.1 linux/include/asm-mips/sn/sn_private.h - 1.1 linux/include/asm-mips/sn/sn0/sn0_fru.h - 1.1 linux/include/asm-mips/sn/sn0/ip27.h - 1.1 linux/include/asm-mips/sn/sn0/hubpi.h - 1.1 linux/include/asm-mips/sn/sn0/hubni.h - 1.1 linux/arch/h8300/platform/h8s/Makefile - 1.1 linux/arch/h8300/platform/h8s/edosk2674/Makefile - 1.1 linux/arch/h8300/platform/h8s/edosk2674/timer.c - 1.1 linux/arch/h8300/platform/h8s/edosk2674/crt0_rom.S - 1.1 linux/arch/h8300/platform/h8s/edosk2674/ram.ld - 1.1 linux/include/asm-mips/sn/nmi.h - 1.1 linux/include/asm-mips/sim.h - 1.1 linux/arch/h8300/platform/h8s/entry.S - 1.1 linux/include/asm-mips/sn/mapped_kernel.h - 1.1 linux/arch/h8300/platform/h8s/generic/crt0_ram.S - 1.1 linux/include/asm-mips/sn/launch.h - 1.1 linux/arch/i386/kernel/cpu/cpufreq/longhaul.h - 1.1 linux/include/asm-mips/sn/klkernvars.h - 1.1 linux/arch/mips/kernel/signal32.c - 1.1 linux/arch/h8300/platform/h8s/ints.c - 1.1 linux/include/asm-mips/sn/sn0/hubmd.h - 1.1 linux/include/asm-mips/sn/sn0/hubio.h - 1.1 linux/arch/mips/mm/pgtable-32.c - 1.1 linux/arch/mips/lib-32/strlen_user.S - 1.1 linux/arch/mips/lib-32/strncpy_user.S - 1.1 linux/arch/mips/lib-32/strnlen_user.S - 1.1 linux/include/asm-mips/sn/sn0/addrs.h - 1.1 linux/arch/mips/lib-64/Makefile - 1.1 linux/include/asm-mips/sn/intr_public.h - 1.1 linux/include/asm-mips/sn/addrs.h - 1.1 linux/include/asm-mips/sn/agent.h - 1.1 linux/arch/mips/kernel/signal_n32.c - 1.1 linux/include/asm-mips/sn/kldir.h - 1.1 linux/include/asm-mips/sn/klconfig.h - 1.1 linux/include/asm-mips/sn/ioc3.h - 1.1 linux/include/asm-mips/sn/io.h - 1.1 linux/include/asm-mips/sn/arch.h - 1.1 linux/include/asm-mips/sn/intr.h - 1.1 linux/include/asm-mips/sn/gda.h - 1.1 linux/arch/mips/lib-32/watch.S - 1.1 linux/scripts/lxdialog/textbox.c - 1.3 linux/net/x25/af_x25.c - 1.38 linux/net/sunrpc/xprt.c - 1.46 linux/net/sunrpc/svcauth_des.c - 1.3 linux/net/rose/sysctl_net_rose.c - 1.7 linux/net/rose/rose_route.c - 1.13 linux/net/rose/rose_dev.c - 1.13 linux/net/rose/af_rose.c - 1.34 linux/net/netsyms.c - 1.75 linux/net/netrom/sysctl_net_netrom.c - 1.7 linux/net/irda/irsysctl.c - 1.13 linux/net/irda/irlap_event.c - 1.31 linux/net/irda/irlan/irlan_common.c - 1.24 linux/net/ipv6/ndisc.c - 1.40 linux/net/ipv6/ip6_output.c - 1.29 linux/net/ipv6/af_inet6.c - 1.38 linux/net/ipv4/ipmr.c - 1.31 linux/net/ipv4/af_inet.c - 1.57 linux/net/core/dev.c - 1.81 linux/net/bridge/br.c - 1.28 linux/net/bridge/Makefile - 1.11 linux/net/ax25/sysctl_net_ax25.c - 1.8 linux/net/ax25/af_ax25.c - 1.35 linux/mm/vmscan.c - 1.132 linux/mm/swapfile.c - 1.77 linux/mm/swap_state.c - 1.64 linux/mm/slab.c - 1.63 linux/mm/page_alloc.c - 1.112 linux/mm/mremap.c - 1.44 linux/mm/memory.c - 1.109 linux/mm/filemap.c - 1.161 linux/lib/string.c - 1.17 linux/kernel/sysctl.c - 1.72 linux/kernel/signal.c - 1.59 linux/kernel/resource.c - 1.23 linux/kernel/panic.c - 1.23 linux/kernel/ksyms.c - 1.197 linux/kernel/itimer.c - 1.10 linux/kernel/exit.c - 1.72 linux/kernel/Makefile - 1.45 linux/include/net/rose.h - 1.8 linux/include/net/pkt_sched.h - 1.13 linux/include/linux/videodev.h - 1.27 linux/include/linux/time.h - 1.19 linux/include/linux/skbuff.h - 1.36 linux/include/linux/sched.h - 1.109 linux/include/linux/quota.h - 1.26 linux/include/linux/pci.h - 1.81 linux/include/linux/nfsd/export.h - 1.19 linux/include/linux/netdevice.h - 1.52 linux/include/linux/msdos_fs.h - 1.32 linux/include/linux/mm.h - 1.121 linux/include/linux/loop.h - 1.17 linux/include/linux/kdev_t.h - 1.12 linux/include/linux/ipv6.h - 1.10 linux/include/linux/igmp.h - 1.10 linux/include/linux/i2c.h - 1.27 linux/include/linux/fs.h - 1.221 linux/include/linux/delay.h - 1.6 linux/include/linux/dcache.h - 1.39 linux/include/linux/blkdev.h - 1.89 linux/include/linux/binfmts.h - 1.18 linux/include/asm-sparc64/pbm.h - 1.15 linux/include/asm-sparc64/asi.h - 1.8 linux/include/asm-mips/watch.h - 1.7 linux/include/asm-mips/usioctl.h - 1.3 linux/include/asm-mips/user.h - 1.4 linux/include/asm-mips/unistd.h - 1.16 linux/include/asm-mips/unaligned.h - 1.7 linux/include/asm-mips/uaccess.h - 1.10 linux/include/asm-mips/types.h - 1.8 linux/include/asm-mips/timex.h - 1.6 linux/include/asm-mips/termios.h - 1.11 linux/include/asm-mips/termbits.h - 1.4 linux/include/asm-mips/system.h - 1.14 linux/include/asm-mips/sysmips.h - 1.3 linux/include/asm-mips/string.h - 1.8 linux/include/asm-mips/statfs.h - 1.4 linux/include/asm-mips/stat.h - 1.8 linux/include/asm-mips/stackframe.h - 1.8 linux/include/asm-mips/sockios.h - 1.3 linux/include/asm-mips/socket.h - 1.11 linux/include/asm-mips/sni.h - 1.7 linux/include/asm-mips/smp.h - 1.5 linux/include/asm-mips/signal.h - 1.9 linux/include/asm-mips/siginfo.h - 1.11 linux/include/asm-mips/sigcontext.h - 1.6 linux/include/asm-mips/shmiq.h - 1.5 linux/include/asm-mips/sgialib.h - 1.8 linux/include/asm-mips/serial.h - 1.7 linux/include/asm-mips/scatterlist.h - 1.6 linux/include/asm-mips/resource.h - 1.10 linux/include/asm-mips/regdef.h - 1.3 linux/include/asm-mips/reg.h - 1.5 linux/include/asm-mips/r4kcache.h - 1.6 linux/include/asm-mips/ptrace.h - 1.11 linux/include/asm-mips/processor.h - 1.24 linux/include/asm-mips/posix_types.h - 1.8 linux/include/asm-mips/pgtable.h - 1.23 linux/include/asm-mips/pci.h - 1.18 linux/include/asm-mips/page.h - 1.12 linux/include/asm-mips/namei.h - 1.7 linux/include/asm-mips/mmu_context.h - 1.11 linux/include/asm-mips/mipsregs.h - 1.12 linux/include/asm-mips/jazz.h - 1.6 linux/include/asm-mips/irq.h - 1.10 linux/include/asm-mips/ipc.h - 1.5 linux/include/asm-mips/ioctl.h - 1.4 linux/include/asm-mips/io.h - 1.10 linux/include/asm-mips/hardirq.h - 1.12 linux/include/asm-mips/gdb-stub.h - 1.6 linux/include/asm-mips/fpregdef.h - 1.3 linux/include/asm-mips/fcntl.h - 1.12 linux/include/asm-mips/elf.h - 1.14 linux/include/asm-mips/dma.h - 1.8 linux/include/asm-mips/delay.h - 1.10 linux/include/asm-mips/checksum.h - 1.9 linux/include/asm-mips/cacheops.h - 1.4 linux/include/asm-mips/cachectl.h - 1.4 linux/include/asm-mips/byteorder.h - 1.6 linux/include/asm-mips/bugs.h - 1.7 linux/include/asm-mips/bitops.h - 1.12 linux/include/asm-mips/atomic.h - 1.10 linux/include/asm-mips/asmmacro.h - 1.7 linux/include/asm-mips/asm.h - 1.6 linux/include/asm-mips/addrspace.h - 1.5 linux/include/asm-mips/a.out.h - 1.3 linux/include/asm-i386/uaccess.h - 1.26 linux/include/asm-i386/pgtable.h - 1.49 linux/include/asm-i386/msr.h - 1.21 linux/include/asm-i386/hardirq.h - 1.30 linux/include/asm-arm/hardware.h - 1.8 linux/include/asm-arm/arch-arc/uncompress.h - 1.4 linux/include/asm-arm/arch-arc/timex.h - 1.4 linux/include/asm-arm/arch-arc/time.h - 1.10 linux/include/asm-arm/arch-arc/system.h - 1.14 linux/include/asm-arm/arch-arc/serial.h - 1.6 linux/include/asm-arm/arch-arc/oldlatches.h - 1.5 linux/include/asm-arm/arch-arc/memory.h - 1.9 linux/include/asm-arm/arch-arc/keyboard.h - 1.5 linux/include/asm-arm/arch-arc/irqs.h - 1.6 linux/include/asm-arm/arch-arc/io.h - 1.10 linux/include/asm-arm/arch-arc/ide.h - 1.9 linux/include/asm-arm/arch-arc/hardware.h - 1.10 linux/include/asm-arm/arch-arc/dma.h - 1.5 linux/include/asm-alpha/pci.h - 1.24 linux/include/asm-alpha/irq.h - 1.10 linux/fs/vfat/namei.c - 1.42 linux/fs/umsdos/mangle.c - 1.4 linux/fs/super.c - 1.103 linux/fs/stat.c - 1.35 linux/fs/proc/root.c - 1.34 linux/fs/open.c - 1.53 linux/fs/ntfs/super.c - 1.27 linux/fs/nfsd/vfs.c - 1.71 linux/fs/nfsd/nfs3xdr.c - 1.40 linux/fs/nfsd/export.c - 1.56 linux/fs/namei.c - 1.75 linux/fs/lockd/svc.c - 1.29 linux/fs/inode.c - 1.101 linux/fs/file_table.c - 1.34 linux/fs/fat/misc.c - 1.20 linux/fs/fat/inode.c - 1.62 linux/fs/fat/dir.c - 1.26 linux/fs/fat/cache.c - 1.23 linux/fs/exec.c - 1.87 linux/fs/buffer.c - 1.161 linux/fs/binfmt_script.c - 1.17 linux/fs/binfmt_misc.c - 1.31 linux/fs/Makefile - 1.78 linux/drivers/video/imsttfb.c - 1.30 linux/drivers/video/fbmem.c - 1.66 linux/drivers/video/chipsfb.c - 1.25 linux/drivers/usb/Makefile - 1.62 linux/drivers/scsi/tmscsim.c - 1.27 linux/drivers/scsi/st.c - 1.70 linux/drivers/scsi/script_asm.pl - 1.7 linux/drivers/scsi/ncr53c8xx.c - 1.39 linux/drivers/scsi/mac53c94.c - 1.13 linux/drivers/scsi/gdth.c - 1.33 linux/drivers/scsi/esp.c - 1.38 linux/drivers/scsi/aha1542.c - 1.39 linux/drivers/scsi/aha152x.c - 1.44 linux/drivers/scsi/NCR53C9x.c - 1.29 linux/drivers/scsi/BusLogic.c - 1.27 linux/drivers/scsi/AM53C974.c - 1.24 linux/drivers/scsi/53c7xx.c - 1.27 linux/drivers/pnp/Makefile - 1.21 linux/drivers/pci/quirks.c - 1.41 linux/drivers/pci/proc.c - 1.36 linux/drivers/pci/pci.c - 1.70 linux/drivers/net/yellowfin.c - 1.37 linux/drivers/net/via-rhine.c - 1.47 linux/drivers/net/tlan.c - 1.36 linux/drivers/net/sunhme.c - 1.48 linux/drivers/net/rrunner.c - 1.29 linux/drivers/net/rcpci45.c - 1.30 linux/drivers/net/pcnet32.c - 1.46 linux/drivers/net/ne2k-pci.c - 1.29 linux/drivers/net/irda/Makefile - 1.26 linux/drivers/net/hamradio/6pack.c - 1.18 linux/drivers/net/epic100.c - 1.37 linux/drivers/net/eepro100.c - 1.62 linux/drivers/net/eepro.c - 1.32 linux/drivers/net/defxx.h - 1.8 linux/drivers/net/defxx.c - 1.27 linux/drivers/net/acenic.c - 1.49 linux/drivers/net/82596.c - 1.27 linux/drivers/net/3c59x.c - 1.50 linux/drivers/char/tty_io.c - 1.72 linux/drivers/char/synclink.c - 1.40 linux/drivers/char/stallion.c - 1.33 linux/drivers/char/rocket.c - 1.25 linux/drivers/char/random.c - 1.41 linux/drivers/char/pcxx.c - 1.21 linux/drivers/char/n_tty.c - 1.22 linux/drivers/char/epca.c - 1.31 linux/drivers/char/cyclades.c - 1.33 linux/drivers/cdrom/sonycd535.c - 1.39 linux/drivers/cdrom/sjcd.c - 1.33 linux/drivers/cdrom/sbpcd.c - 1.41 linux/drivers/cdrom/optcd.c - 1.35 linux/drivers/cdrom/mcdx.c - 1.29 linux/drivers/cdrom/mcd.c - 1.34 linux/drivers/cdrom/gscd.c - 1.34 linux/drivers/cdrom/cm206.c - 1.36 linux/drivers/cdrom/cdu31a.c - 1.32 linux/drivers/cdrom/aztcd.c - 1.36 linux/drivers/block/z2ram.c - 1.32 linux/drivers/block/xd.c - 1.57 linux/drivers/block/swim3.c - 1.32 linux/drivers/block/rd.c - 1.76 linux/drivers/block/ps2esdi.c - 1.60 linux/drivers/block/paride/pf.c - 1.39 linux/drivers/block/paride/pcd.c - 1.35 linux/drivers/block/paride/paride.c - 1.17 linux/drivers/block/nbd.c - 1.60 linux/drivers/block/loop.c - 1.88 linux/drivers/block/ll_rw_blk.c - 1.139 linux/drivers/block/genhd.c - 1.57 linux/drivers/block/floppy.c - 1.70 linux/drivers/block/ataflop.c - 1.42 linux/drivers/block/amiflop.c - 1.43 linux/drivers/block/acsi.c - 1.51 linux/drivers/acorn/block/mfmhd.c - 1.41 linux/drivers/acorn/block/fd1772.c - 1.39 linux/arch/sparc64/lib/debuglocks.c - 1.10 linux/arch/sparc64/lib/Makefile - 1.20 linux/arch/sparc64/kernel/traps.c - 1.31 linux/arch/sparc64/kernel/sys_sparc32.c - 1.77 linux/arch/sparc64/kernel/process.c - 1.48 linux/arch/sparc64/kernel/ioctl32.c - 1.74 linux/arch/sparc64/defconfig - 1.99 linux/arch/ppc/lib/string.S - 1.12 linux/arch/ppc/kernel/setup.c - 1.60 linux/arch/ppc/kernel/pci.c - 1.36 linux/arch/ppc/defconfig - 1.48 linux/arch/mips/sni/setup.c - 1.10 linux/arch/mips/sni/reset.c - 1.3 linux/arch/mips/sni/pcimt_scache.c - 1.7 linux/arch/mips/sni/pci.c - 1.15 linux/arch/mips/sni/io.c - 1.7 linux/arch/mips/sni/int-handler.S - 1.7 linux/arch/mips/sni/Makefile - 1.11 linux/arch/mips/mm/init.c - 1.20 linux/arch/mips/mm/fault.c - 1.16 linux/arch/mips/mm/Makefile - 1.12 linux/arch/mips/lib/watch.S - 1.7 linux/arch/mips/lib/tinycon.c - 1.4 linux/arch/mips/lib/strncpy_user.S - 1.7 linux/arch/mips/lib/strlen_user.S - 1.7 linux/arch/mips/lib/rtc-no.c - 1.7 linux/arch/mips/lib/memset.S - 1.8 linux/arch/mips/lib/memcpy.S - 1.9 linux/arch/mips/lib/floppy-std.c - 1.8 linux/arch/mips/lib/dump_tlb.c - 1.6 linux/arch/mips/lib/csum_partial_copy.c - 1.8 linux/arch/mips/lib/csum_partial.S - 1.6 linux/arch/mips/lib/Makefile - 1.15 linux/arch/mips/kernel/traps.c - 1.16 linux/arch/mips/kernel/time.c - 1.19 linux/arch/mips/kernel/sysmips.c - 1.12 linux/arch/mips/kernel/sysirix.c - 1.24 linux/arch/mips/kernel/syscalls.h - 1.13 linux/arch/mips/kernel/syscall.c - 1.12 linux/arch/mips/kernel/signal.c - 1.21 linux/arch/mips/kernel/setup.c - 1.19 linux/arch/mips/kernel/scall_o32.S - 1.12 linux/arch/mips/kernel/r4k_switch.S - 1.11 linux/arch/mips/kernel/r4k_fpu.S - 1.8 linux/arch/mips/kernel/r2300_switch.S - 1.11 linux/arch/mips/kernel/ptrace.c - 1.17 linux/arch/mips/kernel/process.c - 1.18 linux/arch/mips/kernel/mips_ksyms.c - 1.16 linux/arch/mips/kernel/irq.c - 1.19 linux/arch/mips/kernel/irixsig.c - 1.15 linux/arch/mips/kernel/irix5sys.h - 1.8 linux/arch/mips/kernel/ipc.c - 1.5 linux/arch/mips/kernel/head.S - 1.12 linux/arch/mips/kernel/gdb-stub.c - 1.11 linux/arch/mips/kernel/gdb-low.S - 1.8 linux/arch/mips/kernel/entry.S - 1.11 linux/arch/mips/kernel/branch.c - 1.6 linux/arch/mips/kernel/Makefile - 1.17 linux/arch/mips/jazz/setup.c - 1.8 linux/arch/mips/jazz/reset.c - 1.6 linux/arch/mips/jazz/jazzdma.c - 1.6 linux/arch/mips/jazz/int-handler.S - 1.6 linux/arch/mips/jazz/floppy-jazz.c - 1.7 linux/arch/mips/jazz/Makefile - 1.10 linux/arch/mips/defconfig - 1.26 linux/arch/mips/Makefile - 1.19 linux/arch/m68k/defconfig - 1.17 linux/arch/m68k/atari/stram.c - 1.29 linux/arch/i386/mm/init.c - 1.59 linux/arch/i386/lib/usercopy.c - 1.12 linux/arch/i386/kernel/process.c - 1.73 linux/arch/i386/kernel/Makefile - 1.52 linux/arch/i386/defconfig - 1.119 linux/arch/arm/kernel/time.c - 1.27 linux/arch/arm/defconfig - 1.23 linux/arch/arm/Makefile - 1.47 linux/arch/alpha/kernel/time.c - 1.34 linux/arch/alpha/kernel/sys_dp264.c - 1.21 linux/arch/alpha/kernel/osf_sys.c - 1.41 linux/arch/alpha/kernel/irq.c - 1.35 linux/arch/alpha/kernel/core_tsunami.c - 1.25 linux/arch/alpha/kernel/core_mcpcia.c - 1.21 linux/arch/alpha/kernel/Makefile - 1.34 linux/arch/alpha/defconfig - 1.35 linux/arch/alpha/boot/tools/objstrip.c - 1.6 linux/arch/alpha/boot/Makefile - 1.17 linux/arch/alpha/Makefile - 1.32 linux/Makefile - 1.256 linux/MAINTAINERS - 1.147 linux/Documentation/smp.txt - 1.3 linux/Documentation/networking/vortex.txt - 1.12 linux/Documentation/networking/cs89x0.txt - 1.10 linux/Documentation/networking/arcnet.txt - 1.5 linux/Documentation/networking/DLINK.txt - 1.4 linux/Documentation/networking/00-INDEX - 1.8 linux/Documentation/kbuild/commands.txt - 1.4 linux/Documentation/kbuild/00-INDEX - 1.6 linux/Documentation/isdn/README.HiSax - 1.12 linux/Documentation/cdrom/sbpcd - 1.4 linux/Documentation/cdrom/gscd - 1.3 linux/Documentation/cdrom/cm206 - 1.3 linux/Documentation/arm/README - 1.8 linux/Documentation/Changes - 1.68 linux/CREDITS - 1.105 linux/net/decnet/dn_dev.c - 1.21 linux/include/linux/ide.h - 1.83 linux/include/asm-mips/hdreg.h - 1.5 linux/drivers/video/cyber2000fb.c - 1.41 linux/drivers/net/irda/toshoboe.c - 1.35 linux/drivers/isdn/eicon/eicon_isa.c - 1.12 linux/arch/mips/jazz/kbd-jazz.c - 1.4 linux/arch/mips/dec/time.c - 1.10 linux/arch/mips/baget/irq.c - 1.14 linux/drivers/block/cpqarray.h - 1.12 linux/drivers/block/cpqarray.c - 1.74 linux/arch/arm/def-configs/footbridge - 1.16 linux/arch/arm/def-configs/ebsa110 - 1.12 linux/arch/arm/def-configs/a5k - 1.9 linux/drivers/parport/parport_pc.c - 1.59 linux/drivers/net/ppp_async.c - 1.20 linux/drivers/pci/names.c - 1.13 linux/include/linux/irq.h - 1.13 linux/fs/partitions/osf.c - 1.6 linux/drivers/net/sis900.c - 1.48 linux/drivers/atm/zatm.h - 1.2 linux/drivers/atm/zatm.c - 1.20 linux/drivers/atm/uPD98402.c - 1.9 linux/drivers/atm/eni.c - 1.23 linux/drivers/atm/atmtcp.c - 1.16 linux/drivers/atm/Makefile - 1.28 linux/Documentation/computone.txt - 1.9 linux/net/sched/sch_atm.c - 1.16 linux/net/core/netfilter.c - 1.26 linux/net/atm/signaling.c - 1.16 linux/net/atm/mpc.c - 1.19 linux/net/atm/atm_misc.c - 1.9 linux/net/atm/Makefile - 1.15 linux/include/linux/atm_zatm.h - 1.3 linux/arch/arm/kernel/bios32.c - 1.38 linux/arch/alpha/kernel/pci.c - 1.35 linux/Documentation/README.DAC960 - 1.5 linux/drivers/block/DAC960.h - 1.25 linux/drivers/block/DAC960.c - 1.72 linux/arch/sparc64/kernel/pci_iommu.c - 1.16 linux/arch/sparc64/kernel/pci.c - 1.38 linux/arch/sh/defconfig - 1.24 linux/drivers/scsi/ips.h - 1.25 linux/drivers/scsi/ips.c - 1.45 linux/drivers/char/n_r3964.c - 1.17 linux/drivers/pcmcia/rsrc_mgr.c - 1.25 linux/drivers/pcmcia/i82365.c - 1.45 linux/drivers/pcmcia/cs.c - 1.44 linux/drivers/block/swim_iop.c - 1.27 linux/drivers/pcmcia/ti113x.h - 1.14 linux/drivers/net/starfire.c - 1.33 linux/drivers/net/pcmcia/pcnet_cs.c - 1.27 linux/drivers/net/pcmcia/3c589_cs.c - 1.30 linux/drivers/char/drm/Makefile - 1.18 linux/drivers/net/wan/cycx_drv.c - 1.9 linux/drivers/net/tokenring/olympic.c - 1.28 linux/drivers/net/tokenring/ibmtr.c - 1.25 linux/Documentation/nmi_watchdog.txt - 1.6 linux/include/linux/pci_ids.h - 1.97 linux/drivers/net/wan/z85230.c - 1.15 linux/drivers/net/wan/x25_asy.h - 1.3 linux/drivers/net/wan/x25_asy.c - 1.12 linux/drivers/net/wan/sdladrv.c - 1.13 linux/drivers/video/tdfxfb.c - 1.31 linux/drivers/net/pcmcia/xirc2ps_cs.c - 1.27 linux/Documentation/arm/SA1100/Brutus - 1.6 linux/drivers/net/pcmcia/3c574_cs.c - 1.29 linux/drivers/net/pcmcia/nmclan_cs.c - 1.22 linux/drivers/net/pcmcia/fmvj18x_cs.c - 1.26 linux/Documentation/arm/SA1100/Itsy - 1.3 linux/drivers/net/pcmcia/smc91c92_cs.c - 1.24 linux/arch/arm/def-configs/brutus - 1.13 linux/mm/bootmem.c - 1.30 linux/include/asm-i386/pgtable-3level.h - 1.16 linux/include/asm-arm/arch-arc/param.h - 1.3 linux/include/asm-i386/div64.h - 1.3 linux/drivers/pci/pci.ids - 1.63 linux/drivers/net/sk98lin/skxmac2.c - 1.8 linux/drivers/net/sk98lin/h/skgehwt.h - 1.4 linux/drivers/net/sk98lin/skgepnmi.c - 1.7 linux/drivers/net/sk98lin/h/skgei2c.h - 1.3 linux/drivers/net/sk98lin/h/skgeinit.h - 1.5 linux/drivers/net/sk98lin/skgesirq.c - 1.7 linux/Documentation/networking/sis900.txt - 1.7 linux/Documentation/networking/sk98lin.txt - 1.8 linux/drivers/net/sk98lin/Makefile - 1.9 linux/drivers/net/sk98lin/h/lm80.h - 1.6 linux/drivers/net/sk98lin/h/skaddr.h - 1.5 linux/drivers/net/sk98lin/h/skdebug.h - 1.3 linux/drivers/net/sk98lin/h/skdrv1st.h - 1.9 linux/drivers/net/sk98lin/h/skdrv2nd.h - 1.7 linux/drivers/net/sk98lin/h/skerror.h - 1.3 linux/drivers/net/sk98lin/skvpd.c - 1.10 linux/drivers/net/sk98lin/sktimer.c - 1.4 linux/drivers/net/sk98lin/skrlmt.c - 1.5 linux/drivers/net/sk98lin/h/skgedrv.h - 1.3 linux/drivers/net/sk98lin/h/skgehw.h - 1.7 linux/drivers/net/sk98lin/skgeinit.c - 1.8 linux/drivers/net/sk98lin/skge.c - 1.28 linux/drivers/net/sk98lin/skgehwt.c - 1.5 linux/drivers/net/sk98lin/h/skgepnm2.h - 1.6 linux/drivers/net/sk98lin/h/skgepnmi.h - 1.5 linux/drivers/net/sk98lin/h/skgesirq.h - 1.5 linux/drivers/net/sk98lin/skqueue.c - 1.6 linux/drivers/net/sk98lin/sklm80.c - 1.3 linux/drivers/net/sk98lin/h/ski2c.h - 1.5 linux/drivers/net/sk98lin/h/skqueue.h - 1.4 linux/drivers/net/sk98lin/ski2c.c - 1.6 linux/drivers/net/sk98lin/h/skrlmt.h - 1.5 linux/drivers/net/sk98lin/h/sktimer.h - 1.4 linux/drivers/net/sk98lin/h/sktypes.h - 1.3 linux/drivers/net/sk98lin/h/skvpd.h - 1.5 linux/drivers/net/sk98lin/h/xmac_ii.h - 1.7 linux/drivers/net/sk98lin/skaddr.c - 1.6 linux/drivers/net/sk98lin/skcsum.c - 1.6 linux/arch/ppc/configs/pmac_defconfig - 1.15 linux/arch/ppc/configs/common_defconfig - 1.36 linux/arch/alpha/kernel/sys_nautilus.c - 1.15 linux/include/linux/mmzone.h - 1.40 linux/kernel/timer.c - 1.51 linux/drivers/scsi/scsi_lib.c - 1.69 linux/drivers/i2c/i2c-velleman.c - 1.11 linux/drivers/i2c/i2c-elv.c - 1.12 linux/drivers/i2c/i2c-philips-par.c - 1.12 linux/drivers/i2c/i2c-elektor.c - 1.18 linux/drivers/i2c/i2c-dev.c - 1.31 linux/drivers/i2c/i2c-core.c - 1.29 linux/drivers/i2c/i2c-algo-bit.c - 1.18 linux/drivers/sbus/char/jsflash.c - 1.31 linux/fs/openpromfs/inode.c - 1.28 linux/fs/cramfs/inode.c - 1.39 linux/drivers/telephony/phonedev.c - 1.12 linux/drivers/telephony/ixj.c - 1.32 linux/drivers/net/pcmcia/com20020_cs.c - 1.12 linux/drivers/net/arcnet/rfc1201.c - 1.9 linux/drivers/net/arcnet/com20020-pci.c - 1.18 linux/drivers/net/arcnet/com20020-isa.c - 1.11 linux/Documentation/telephony/ixj.txt - 1.2 linux/Documentation/usb/usb-serial.txt - 1.25 linux/drivers/ieee1394/raw1394.c - 1.31 linux/drivers/ieee1394/pcilynx.c - 1.32 linux/drivers/ieee1394/ieee1394_core.c - 1.35 linux/Documentation/moxa-smartio - 1.3 linux/drivers/ieee1394/ohci1394.c - 1.36 linux/drivers/ieee1394/ieee1394_types.h - 1.23 linux/drivers/ieee1394/ieee1394_transactions.h - 1.8 linux/drivers/ieee1394/ieee1394_transactions.c - 1.19 linux/drivers/ieee1394/highlevel.h - 1.10 linux/drivers/ieee1394/csr.c - 1.14 linux/drivers/char/mxser.c - 1.26 linux/drivers/ieee1394/highlevel.c - 1.14 linux/drivers/pci/setup-res.c - 1.18 linux/drivers/pci/setup-bus.c - 1.14 linux/drivers/net/tokenring/tmspci.c - 1.12 linux/drivers/net/tokenring/abyss.c - 1.11 linux/Documentation/DMA-mapping.txt - 1.20 linux/fs/autofs4/expire.c - 1.11 linux/drivers/atm/iphase.c - 1.23 linux/arch/ia64/kernel/efi.c - 1.24 linux/arch/ia64/kernel/acpi.c - 1.26 linux/arch/ia64/ia32/sys_ia32.c - 1.48 linux/arch/ia64/ia32/ia32_entry.S - 1.26 linux/arch/ia64/ia32/binfmt_elf32.c - 1.21 linux/arch/ia64/ia32/Makefile - 1.13 linux/arch/ia64/Makefile - 1.31 linux/Documentation/networking/atm.txt - 1.2 linux/arch/ia64/kernel/setup.c - 1.29 linux/arch/ia64/kernel/mca.c - 1.23 linux/include/asm-ia64/iosapic.h - 1.10 linux/include/asm-ia64/io.h - 1.15 linux/include/asm-ia64/hardirq.h - 1.20 linux/include/linux/raid/md_k.h - 1.34 linux/include/asm-ia64/sal.h - 1.17 linux/include/asm-ia64/mca.h - 1.11 linux/include/asm-ia64/uaccess.h - 1.12 linux/include/asm-ia64/statfs.h - 1.3 linux/drivers/net/8139too.c - 1.55 linux/Documentation/filesystems/devfs/README - 1.19 linux/fs/devfs/base.c - 1.62 linux/drivers/net/skfp/smt.c - 1.4 linux/drivers/net/skfp/h/cmtdef.h - 1.3 linux/net/bridge/br_stp_if.c - 1.10 linux/net/bridge/br_notify.c - 1.7 linux/arch/mips/lib/strnlen_user.S - 1.4 linux/arch/mips/lib/r3k_dump_tlb.c - 1.6 linux/arch/mips/defconfig-decstation - 1.11 linux/arch/mips/defconfig-ip22 - 1.12 linux/drivers/video/matrox/matroxfb_crtc2.h - 1.4 linux/drivers/video/matrox/matroxfb_crtc2.c - 1.15 linux/drivers/video/matrox/matroxfb_base.h - 1.17 linux/drivers/video/matrox/matroxfb_base.c - 1.25 linux/drivers/video/matrox/matroxfb_Ti3026.c - 1.9 linux/drivers/video/matrox/matroxfb_DAC1064.c - 1.15 linux/drivers/net/tulip/tulip_core.c - 1.49 linux/drivers/net/ioc3-eth.c - 1.25 linux/include/asm-mips64/ioctl.h - 1.5 linux/include/asm-mips64/io.h - 1.8 linux/include/asm-mips64/inst.h - 1.5 linux/include/asm-mips64/init.h - 1.5 linux/include/asm-mips64/ide.h - 1.13 linux/include/asm-mips64/hdreg.h - 1.4 linux/include/asm-mips64/hardirq.h - 1.7 linux/include/asm-mips64/gfx.h - 1.6 linux/include/asm-mips64/fpregdef.h - 1.2 linux/include/asm-mips64/floppy.h - 1.6 linux/include/asm-mips64/fcntl.h - 1.10 linux/include/asm-mips64/errno.h - 1.7 linux/include/asm-mips64/elf.h - 1.12 linux/include/asm-mips64/ds1286.h - 1.5 linux/include/asm-mips64/dma.h - 1.6 linux/include/asm-mips64/div64.h - 1.6 linux/include/asm-mips64/delay.h - 1.8 linux/include/asm-mips64/current.h - 1.5 linux/include/asm-mips64/cpu.h - 1.5 linux/include/asm-mips64/checksum.h - 1.6 linux/include/asm-mips64/cachectl.h - 1.3 linux/include/asm-mips64/cache.h - 1.6 linux/include/asm-mips64/byteorder.h - 1.4 linux/include/asm-mips64/bugs.h - 1.5 linux/include/asm-mips64/branch.h - 1.5 linux/include/asm-mips64/bootinfo.h - 1.7 linux/include/asm-mips64/bitops.h - 1.9 linux/include/asm-mips64/bcache.h - 1.6 linux/include/asm-mips64/atomic.h - 1.8 linux/include/asm-mips64/asmmacro.h - 1.5 linux/include/asm-mips64/asm.h - 1.5 linux/include/asm-mips64/arc/types.h - 1.2 linux/include/asm-mips64/arc/hinv.h - 1.4 linux/include/asm-mips64/addrspace.h - 1.6 linux/include/asm-mips64/a.out.h - 1.5 linux/include/asm-mips/wbflush.h - 1.5 linux/include/asm-mips/shmbuf.h - 1.4 linux/include/asm-mips/pgalloc.h - 1.9 linux/include/asm-mips/div64.h - 1.6 linux/include/asm-mips64/ipcbuf.h - 1.3 linux/include/asm-mips64/irq.h - 1.8 linux/include/asm-mips64/sn/sn0/ip27.h - 1.7 linux/include/asm-mips64/sn/sn0/addrs.h - 1.5 linux/include/asm-mips64/sn/kldir.h - 1.5 linux/include/asm-mips64/sn/klconfig.h - 1.7 linux/include/asm-mips64/sn/io.h - 1.5 linux/include/asm-mips64/sn/gda.h - 1.5 linux/include/asm-mips64/sn/arch.h - 1.6 linux/include/asm-mips64/sn/agent.h - 1.4 linux/include/asm-mips64/sn/addrs.h - 1.5 linux/include/asm-mips64/signal.h - 1.7 linux/include/asm-mips64/siginfo.h - 1.9 linux/include/asm-mips64/xtalk/xwidget.h - 1.5 linux/include/asm-mips64/sigcontext.h - 1.5 linux/include/asm-mips64/shmparam.h - 1.4 linux/include/asm-mips64/shmiq.h - 1.6 linux/include/asm-mips64/shmbuf.h - 1.3 linux/include/asm-mips64/sgidefs.h - 1.4 linux/include/asm-mips64/xtalk/xtalk.h - 1.5 linux/include/asm-mips64/watch.h - 1.5 linux/include/asm-mips64/sgiarcs.h - 1.6 linux/include/asm-mips64/sgialib.h - 1.6 linux/include/asm-mips64/usioctl.h - 1.4 linux/include/asm-mips64/sgi/sgi.h - 1.4 linux/include/asm-mips64/sgi/io.h - 1.4 linux/include/asm-mips64/serial.h - 1.7 linux/include/asm-mips64/sembuf.h - 1.3 linux/include/asm-mips64/semaphore.h - 1.7 linux/include/asm-mips64/user.h - 1.5 linux/include/asm-mips64/unistd.h - 1.13 linux/include/asm-mips64/semaphore-helper.h - 1.6 linux/include/asm-mips64/segment.h - 1.2 linux/include/asm-mips64/scatterlist.h - 1.5 linux/include/asm-mips64/unaligned.h - 1.6 linux/include/asm-mips64/resource.h - 1.7 linux/include/asm-mips64/regdef.h - 1.4 linux/include/asm-mips64/reg.h - 1.3 linux/include/asm-mips64/r4kcache.h - 1.5 linux/include/asm-mips64/ucontext.h - 1.4 linux/include/asm-mips64/ptrace.h - 1.7 linux/include/asm-mips64/processor.h - 1.17 linux/include/asm-mips64/posix_types.h - 1.7 linux/include/asm-mips64/poll.h - 1.5 linux/include/asm-mips64/pgtable.h - 1.20 linux/include/asm-mips64/pgalloc.h - 1.11 linux/include/asm-mips64/uaccess.h - 1.7 linux/include/asm-mips64/pci/bridge.h - 1.6 linux/include/asm-mips64/pci.h - 1.14 linux/include/asm-mips64/parport.h - 1.5 linux/include/asm-mips64/types.h - 1.6 linux/include/asm-mips64/param.h - 1.6 linux/include/asm-mips64/page.h - 1.9 linux/include/asm-mips64/paccess.h - 1.5 linux/include/asm-mips64/timex.h - 1.5 linux/include/asm-mips64/termios.h - 1.7 linux/include/asm-mips64/termbits.h - 1.4 linux/include/asm-mips64/system.h - 1.9 linux/include/asm-mips64/sysmips.h - 1.4 linux/include/asm-mips64/string.h - 1.4 linux/include/asm-mips64/statfs.h - 1.5 linux/include/asm-mips64/stat.h - 1.7 linux/include/asm-mips64/stackframe.h - 1.4 linux/include/asm-mips64/spinlock.h - 1.6 linux/include/asm-mips64/softirq.h - 1.6 linux/include/asm-mips64/sockios.h - 1.4 linux/include/asm-mips64/socket.h - 1.9 linux/include/asm-mips64/sn/types.h - 1.6 linux/include/asm-mips64/sn/sn0/sn0_fru.h - 1.5 linux/include/asm-mips64/ng1.h - 1.4 linux/include/asm-mips64/namei.h - 1.5 linux/include/asm-mips64/sn/sn0/hubpi.h - 1.5 linux/include/asm-mips64/msgbuf.h - 1.3 linux/include/asm-mips64/ipc.h - 1.3 linux/include/asm-mips64/ioctls.h - 1.8 linux/include/asm-mips64/mmu_context.h - 1.10 linux/include/asm-mips64/sn/sn0/hubni.h - 1.5 linux/include/asm-mips64/sn/sn0/hub.h - 1.4 linux/include/asm-mips64/mmzone.h - 1.13 linux/include/asm-mips64/sn/sn0/hubmd.h - 1.5 linux/include/asm-mips64/sn/sn0/arch.h - 1.5 linux/include/asm-mips64/sn/sn0/hubio.h - 1.6 linux/include/asm-mips64/keyboard.h - 1.7 linux/include/asm-mips64/mman.h - 1.5 linux/include/asm-mips64/mipsregs.h - 1.10 linux/include/asm-mips64/m48t35.h - 1.4 linux/include/asm-mips64/mc146818rtc.h - 1.6 linux/arch/mips64/defconfig - 1.23 linux/arch/mips64/mm/init.c - 1.14 linux/arch/mips64/mm/Makefile - 1.9 linux/arch/mips64/mm/fault.c - 1.13 linux/arch/mips64/mm/extable.c - 1.6 linux/arch/mips64/lib/watch.S - 1.4 linux/arch/mips64/lib/strlen_user.S - 1.5 linux/arch/mips64/lib/strnlen_user.S - 1.5 linux/arch/mips64/lib/strncpy_user.S - 1.5 linux/arch/mips64/lib/rtc-std.c - 1.5 linux/arch/mips64/lib/memcpy.S - 1.7 linux/arch/mips64/lib/memset.S - 1.6 linux/arch/mips64/lib/rtc-no.c - 1.5 linux/arch/mips64/lib/floppy-no.c - 1.4 linux/arch/mips64/lib/ide-std.c - 1.6 linux/arch/mips64/lib/ide-no.c - 1.6 linux/arch/mips64/lib/dump_tlb.c - 1.6 linux/arch/mips64/lib/Makefile - 1.10 linux/arch/mips64/lib/csum_partial_copy.c - 1.6 linux/arch/mips64/lib/csum_partial.S - 1.4 linux/arch/mips64/kernel/traps.c - 1.11 linux/arch/mips64/kernel/unaligned.c - 1.7 linux/arch/mips64/lib/floppy-std.c - 1.5 linux/arch/mips64/defconfig-ip22 - 1.14 linux/arch/mips64/kernel/scall_o32.S - 1.14 linux/arch/mips64/Makefile - 1.18 linux/arch/mips64/mm/loadmmu.c - 1.8 linux/arch/mips64/kernel/syscall.c - 1.14 linux/arch/mips64/kernel/signal32.c - 1.16 linux/arch/mips64/kernel/signal.c - 1.14 linux/arch/mips64/kernel/setup.c - 1.11 linux/arch/mips64/kernel/semaphore.c - 1.4 linux/arch/mips64/boot/Makefile - 1.12 linux/arch/mips64/kernel/linux32.c - 1.20 linux/arch/mips64/kernel/scall_64.S - 1.14 linux/arch/mips64/defconfig-ip27 - 1.13 linux/arch/mips64/kernel/Makefile - 1.12 linux/arch/mips64/kernel/branch.c - 1.5 linux/arch/mips64/kernel/entry.S - 1.9 linux/arch/mips64/kernel/head.S - 1.6 linux/arch/mips64/kernel/init_task.c - 1.5 linux/arch/mips64/kernel/r4k_switch.S - 1.6 linux/arch/mips64/kernel/mips64_ksyms.c - 1.12 linux/arch/mips64/kernel/proc.c - 1.7 linux/arch/mips64/kernel/process.c - 1.12 linux/arch/mips64/kernel/ptrace.c - 1.12 linux/arch/mips64/kernel/r4k_cache.S - 1.4 linux/arch/mips64/kernel/r4k_fpu.S - 1.5 linux/arch/mips64/kernel/r4k_genex.S - 1.5 linux/drivers/video/riva/fbdev.c - 1.28 linux/include/linux/usb.h - 1.64 linux/include/asm-ia64/hw_irq.h - 1.11 linux/drivers/usb/serial/usb-serial.c - 1.21 linux/drivers/usb/serial/ftdi_sio.h - 1.10 linux/drivers/ide/ide.c - 1.90 linux/drivers/ide/ide-probe.c - 1.58 linux/drivers/ide/ide-floppy.c - 1.46 linux/drivers/ide/ide-dma.c - 1.41 linux/drivers/ide/ide-disk.c - 1.64 linux/drivers/ide/ide-cd.c - 1.68 linux/Documentation/video4linux/CQcam.txt - 1.3 linux/Documentation/DocBook/Makefile - 1.43 linux/drivers/net/tokenring/lanstreamer.c - 1.18 linux/net/ipv4/netfilter/ipt_REJECT.c - 1.23 linux/net/ipv4/netfilter/ipt_LOG.c - 1.13 linux/net/ipv4/netfilter/ip_tables.c - 1.22 linux/net/ipv4/netfilter/ip_nat_proto_udp.c - 1.4 linux/net/ipv4/netfilter/ip_nat_proto_tcp.c - 1.6 linux/net/ipv4/netfilter/ip_nat_proto_icmp.c - 1.3 linux/net/ipv4/netfilter/ip_nat_ftp.c - 1.14 linux/net/ipv4/netfilter/ip_nat_core.c - 1.23 linux/net/ipv4/netfilter/ip_conntrack_ftp.c - 1.17 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.28 linux/include/linux/netfilter_ipv4/ip_conntrack_core.h - 1.9 linux/drivers/net/pcmcia/ibmtr_cs.c - 1.17 linux/drivers/usb/serial/ftdi_sio.c - 1.51 linux/drivers/usb/serial/visor.c - 1.55 linux/drivers/net/wan/lmc/lmc_main.c - 1.17 linux/drivers/char/rio/riotable.c - 1.10 linux/arch/arm/def-configs/lart - 1.11 linux/drivers/s390/block/dasd.c - 1.46 linux/Documentation/arm/SA1100/Assabet - 1.5 linux/arch/arm/def-configs/assabet - 1.13 linux/arch/arm/def-configs/graphicsclient - 1.12 linux/net/ipv6/netfilter/ip6_tables.c - 1.21 linux/arch/mips64/kernel/smp.c - 1.14 linux/include/asm-mips64/sn/sn_private.h - 1.3 linux/include/asm-mips64/sn/nmi.h - 1.5 linux/include/asm-mips64/sn/launch.h - 1.5 linux/include/asm-mips64/sn/intr_public.h - 1.3 linux/include/asm-mips64/sn/intr.h - 1.3 linux/include/asm-mips64/smplock.h - 1.5 linux/arch/mips64/kernel/ioctl32.c - 1.18 linux/include/asm-mips64/smp.h - 1.6 linux/include/asm-mips64/hw_irq.h - 1.3 linux/include/asm-mips/paccess.h - 1.3 linux/include/asm-mips/hw_irq.h - 1.4 linux/include/asm-mips/sfp-machine.h - 1.2 linux/include/asm-mips64/sfp-machine.h - 1.2 linux/include/asm-mips64/sn/klkernvars.h - 1.3 linux/include/asm-mips64/sn/mapped_kernel.h - 1.5 linux/drivers/char/drm/r128_drv.h - 1.15 linux/drivers/char/drm/r128_drm.h - 1.8 linux/arch/alpha/kernel/core_titan.c - 1.14 linux/arch/alpha/kernel/core_wildfire.c - 1.6 linux/arch/ia64/ia32/ia32_ioctl.c - 1.13 linux/arch/sparc64/lib/dec_and_lock.S - 1.5 linux/include/net/inet_ecn.h - 1.4 linux/drivers/mtd/ftl.c - 1.37 linux/arch/mips/defconfig-cobalt - 1.6 linux/arch/mips/defconfig-rm200 - 1.7 linux/kernel/user.c - 1.9 linux/Documentation/arm/SA1100/CERF - 1.3 linux/drivers/usb/storage/shuttle_usbat.c - 1.16 linux/drivers/net/natsemi.c - 1.30 linux/drivers/media/video/zr36120.c - 1.19 linux/drivers/media/video/videodev.c - 1.19 linux/drivers/media/video/tuner.c - 1.19 linux/drivers/media/video/tuner-3036.c - 1.9 linux/drivers/media/video/tea6420.c - 1.5 linux/drivers/media/video/saa7185.c - 1.13 linux/drivers/media/video/saa7111.c - 1.13 linux/drivers/media/video/saa7110.c - 1.12 linux/drivers/media/video/saa5249.c - 1.17 linux/drivers/media/video/pms.c - 1.12 linux/drivers/media/video/msp3400.c - 1.20 linux/drivers/media/video/cpia_usb.c - 1.21 linux/drivers/media/video/cpia.c - 1.22 linux/drivers/media/video/c-qcam.c - 1.12 linux/drivers/media/video/bw-qcam.c - 1.14 linux/drivers/media/video/bttv.h - 1.15 linux/drivers/media/video/bttv-if.c - 1.14 linux/drivers/media/video/bttv-driver.c - 1.31 linux/drivers/media/video/bttv-cards.c - 1.21 linux/drivers/media/video/bt848.h - 1.5 linux/drivers/media/video/Makefile - 1.17 linux/drivers/isdn/hysdn/hycapi.c - 1.15 linux/arch/arm/tools/mach-types - 1.28 linux/arch/arm/mach-footbridge/netwinder-pci.c - 1.7 linux/drivers/md/raid5.c - 1.44 linux/Documentation/kbuild/makefiles.txt - 1.11 linux/arch/arm/def-configs/clps7500 - 1.4 linux/drivers/block/cciss.c - 1.60 linux/drivers/block/cciss.h - 1.20 linux/drivers/md/linear.c - 1.23 linux/drivers/md/md.c - 1.78 linux/drivers/md/raid0.c - 1.20 linux/drivers/net/hamachi.c - 1.25 linux/drivers/net/sundance.c - 1.28 linux/drivers/usb/storage/initializers.c - 1.7 linux/drivers/usb/storage/initializers.h - 1.5 linux/scripts/makelst - 1.4 linux/fs/xfs/support/sema.h - 1.9 linux/fs/xfs/support/mrlock.h - 1.10 linux/drivers/media/video/bttvp.h - 1.14 linux/include/asm-mips64/module.h - 1.4 linux/include/asm-mips64/xor.h - 1.2 linux/include/linux/ethtool.h - 1.17 linux/Documentation/arm/SA1100/Pangolin - 1.4 linux/arch/arm/def-configs/integrator - 1.7 linux/arch/arm/def-configs/pangolin - 1.10 linux/arch/i386/kernel/dmi_scan.c - 1.32 linux/arch/parisc/kernel/pci.c - 1.9 linux/include/asm-mips64/riscos-syscall.h - 1.3 linux/include/asm-mips64/sn/ioc3.h - 1.2 linux/include/asm-mips64/mmu.h - 1.3 linux/mm/shmem.c - 1.64 linux/drivers/atm/firestream.c - 1.17 linux/Documentation/DocBook/sis900.tmpl - 1.4 linux/include/asm-ia64/sn/dmamap.h - 1.5 linux/include/asm-ia64/sn/hcl.h - 1.5 linux/drivers/char/drm/r128_state.c - 1.10 linux/drivers/char/drm/r128_cce.c - 1.11 linux/include/asm-ia64/sn/ksys/l1.h - 1.6 linux/arch/ia64/kernel/iosapic.c - 1.19 linux/include/asm-ia64/sn/xtalk/xtalk.h - 1.6 linux/arch/ia64/sn/io/io.c - 1.7 linux/include/asm-ia64/sn/nodepda.h - 1.6 linux/arch/ia64/sn/io/xswitch.c - 1.6 linux/fs/reiserfs/stree.c - 1.30 linux/fs/reiserfs/super.c - 1.37 linux/fs/reiserfs/namei.c - 1.29 linux/arch/sparc64/kernel/pci_schizo.c - 1.21 linux/fs/reiserfs/journal.c - 1.45 linux/fs/reiserfs/fix_node.c - 1.28 linux/fs/reiserfs/file.c - 1.17 linux/fs/reiserfs/do_balan.c - 1.17 linux/fs/reiserfs/bitmap.c - 1.25 linux/drivers/usb/storage/unusual_devs.h - 1.26 linux/arch/cris/defconfig - 1.15 linux/arch/cris/mm/fault.c - 1.11 linux/drivers/s390/char/tape.h - 1.8 linux/include/asm-arm/mach/irq.h - 1.8 linux/drivers/net/pci-skeleton.c - 1.18 linux/include/linux/hdlc.h - 1.8 linux/drivers/scsi/aic7xxx/aic7770.c - 1.9 linux/drivers/net/wan/dscc4.c - 1.21 linux/drivers/net/sungem.c - 1.31 linux/drivers/media/radio/radio-maxiradio.c - 1.10 linux/arch/ppc/configs/TQM860L_defconfig - 1.18 linux/arch/ppc/configs/IVMS8_defconfig - 1.18 linux/Documentation/s390/3270.txt - 1.4 linux/include/asm-ia64/sn/sv.h - 1.5 linux/arch/mips/math-emu/kernel_linkage.c - 1.3 linux/arch/mips/math-emu/cp1emu.c - 1.6 linux/arch/mips/ite-boards/qed-4n-s01b/pci_fixup.c - 1.3 linux/arch/mips/ite-boards/qed-4n-s01b/init.c - 1.3 linux/arch/mips/ite-boards/qed-4n-s01b/Makefile - 1.7 linux/arch/mips/ite-boards/generic/time.c - 1.5 linux/arch/mips/ite-boards/generic/reset.c - 1.3 linux/arch/mips/ite-boards/generic/pmon_prom.c - 1.3 linux/arch/mips/ite-boards/generic/lpc.c - 1.3 linux/arch/mips/ite-boards/generic/it8172_setup.c - 1.4 linux/arch/mips/ite-boards/generic/it8172_rtc.c - 1.3 linux/arch/mips/ite-boards/generic/it8172_pci.c - 1.6 linux/arch/mips/ite-boards/generic/irq.c - 1.8 linux/arch/mips/ite-boards/generic/int-handler.S - 1.2 linux/arch/mips/ite-boards/generic/dbg_io.c - 1.3 linux/arch/mips/ite-boards/generic/Makefile - 1.7 linux/arch/mips/defconfig-it8172 - 1.9 linux/include/asm-mips/it8172/it8172.h - 1.3 linux/include/asm-mips/it8172/it8172_cir.h - 1.3 linux/arch/mips/defconfig-ddb5476 - 1.10 linux/include/asm-mips/it8172/it8172_dbg.h - 1.3 linux/include/asm-mips/it8172/it8172_int.h - 1.3 linux/include/asm-mips/it8712.h - 1.2 linux/include/asm-sparc64/chafsr.h - 1.3 linux/drivers/net/fealnx.c - 1.21 linux/drivers/media/video/w9966.c - 1.9 linux/drivers/net/irda/irda-usb.c - 1.34 linux/drivers/net/wireless/orinoco_cs.c - 1.18 linux/drivers/media/video/bt856.c - 1.12 linux/drivers/media/video/bt819.c - 1.10 linux/drivers/media/video/adv7175.c - 1.13 linux/drivers/mtd/maps/elan-104nc.c - 1.8 linux/drivers/net/wireless/airo_cs.c - 1.8 linux/drivers/net/wireless/airo.c - 1.33 linux/drivers/usb/serial/pl2303.c - 1.34 linux/include/asm-mips/time.h - 1.4 linux/drivers/isdn/tpam/tpam_main.c - 1.11 linux/arch/mips/kernel/pci-dma.c - 1.4 linux/arch/mips/kernel/smp.c - 1.13 linux/include/asm-mips64/gcc/sgidefs.h - 1.2 linux/drivers/net/sk98lin/h/skversion.h - 1.3 linux/drivers/net/sk98lin/skproc.c - 1.10 linux/arch/mips/mm/ioremap.c - 1.4 linux/drivers/media/video/meye.c - 1.16 linux/drivers/usb/usb-skeleton.c - 1.31 linux/drivers/net/lp486e.c - 1.12 linux/drivers/parport/parport_serial.c - 1.10 linux/drivers/net/dl2k.h - 1.12 linux/drivers/net/dl2k.c - 1.23 linux/drivers/ieee1394/sbp2.c - 1.29 linux/drivers/ieee1394/sbp2.h - 1.16 linux/drivers/ieee1394/nodemgr.c - 1.20 linux/drivers/char/drm/r128.h - 1.7 linux/drivers/char/drm/drm_drv.h - 1.16 linux/drivers/net/irda/vlsi_ir.c - 1.18 linux/drivers/net/wan/farsync.c - 1.13 linux/arch/arm/def-configs/flexanet - 1.9 linux/arch/arm/def-configs/freebird - 1.7 linux/arch/arm/def-configs/freebird_new - 1.7 linux/arch/arm/def-configs/h3600 - 1.8 linux/arch/arm/def-configs/huw_webpanel - 1.5 linux/arch/arm/def-configs/jornada720 - 1.9 linux/arch/arm/def-configs/omnimeter - 1.6 linux/arch/arm/def-configs/pfs168_mqtft - 1.7 linux/arch/arm/def-configs/pfs168_mqvga - 1.7 linux/arch/arm/def-configs/pfs168_sastn - 1.7 linux/arch/arm/def-configs/pfs168_satft - 1.7 linux/arch/arm/def-configs/pleb - 1.7 linux/Documentation/arm/SA1100/HUW_WEBPANEL - 1.2 linux/drivers/video/sstfb.c - 1.17 linux/drivers/video/radeonfb.c - 1.19 linux/arch/sh/kernel/pcibios.c - 1.4 linux/arch/sh/mm/cache-sh3.c - 1.5 linux/arch/mips/au1000/common/time.c - 1.5 linux/arch/mips/ite-boards/ivr/Makefile - 1.6 linux/include/asm-mips64/tlb.h - 1.3 linux/include/asm-mips64/mips-boards/saa9730_uart.h - 1.2 linux/include/asm-mips64/mips-boards/prom.h - 1.2 linux/include/asm-mips64/mips-boards/piix4.h - 1.2 linux/include/asm-mips64/mips-boards/maltaint.h - 1.2 linux/include/asm-mips64/mips-boards/malta.h - 1.3 linux/include/asm-mips64/mips-boards/io.h - 1.2 linux/include/asm-mips64/mips-boards/gt64120.h - 1.3 linux/include/asm-mips64/mips-boards/generic.h - 1.3 linux/include/asm-mips64/mips-boards/atlasint.h - 1.3 linux/include/asm-mips64/mips-boards/atlas.h - 1.3 linux/arch/mips/defconfig-atlas - 1.5 linux/arch/mips/defconfig-ddb5477 - 1.5 linux/arch/mips/defconfig-malta - 1.5 linux/arch/mips/defconfig-ocelot - 1.4 linux/arch/mips/defconfig-pb1000 - 1.5 linux/arch/mips/gt64120/common/Makefile - 1.5 linux/arch/mips/gt64120/common/gt_irq.c - 1.2 linux/arch/mips/gt64120/common/pci.c - 1.6 linux/arch/mips/gt64120/momenco_ocelot/Makefile - 1.6 linux/arch/mips/gt64120/momenco_ocelot/dbg_io.c - 1.2 linux/arch/mips/gt64120/momenco_ocelot/int-handler.S - 1.2 linux/arch/mips/gt64120/momenco_ocelot/irq.c - 1.3 linux/arch/mips/gt64120/momenco_ocelot/ocelot_pld.h - 1.2 linux/arch/mips/gt64120/momenco_ocelot/pci.c - 1.2 linux/arch/mips/gt64120/momenco_ocelot/prom.c - 1.2 linux/arch/mips/gt64120/momenco_ocelot/reset.c - 1.2 linux/arch/mips/gt64120/momenco_ocelot/setup.c - 1.4 linux/include/asm-mips/mips-boards/prom.h - 1.2 linux/arch/mips/ite-boards/ivr/README - 1.2 linux/arch/mips/ite-boards/ivr/init.c - 1.2 linux/arch/mips/ite-boards/ivr/pci_fixup.c - 1.2 linux/arch/mips/jazz/irq.c - 1.2 linux/drivers/isdn/hisax/st5481_b.c - 1.10 linux/drivers/net/ns83820.c - 1.22 linux/include/asm-mips/gt64120/gt64120.h - 1.2 linux/arch/mips64/defconfig-ip32 - 1.5 linux/arch/mips/sni/irq.c - 1.2 linux/include/asm-mips/gt64120/momenco_ocelot/gt64120_dep.h - 1.2 linux/arch/i386/kernel/nmi.c - 1.19 linux/drivers/mtd/devices/blkmtd.c - 1.24 linux/fs/jffs/jffs_proc.c - 1.4 linux/drivers/net/wireless/orinoco_plx.c - 1.9 linux/drivers/message/i2o/i2o_block.c - 1.35 linux/drivers/net/8139cp.c - 1.27 linux/drivers/atm/lanai.c - 1.10 linux/drivers/pcmcia/i82092.c - 1.18 linux/arch/arm/def-configs/adsbitsy - 1.8 linux/arch/arm/def-configs/cerfcube - 1.8 linux/arch/arm/def-configs/cerfpda - 1.8 linux/arch/arm/def-configs/cerfpod - 1.8 linux/arch/arm/def-configs/edb7211 - 1.4 linux/arch/arm/def-configs/graphicsmaster - 1.8 linux/net/ipv4/netfilter/ip_nat_snmp_basic.c - 1.10 linux/net/ipv4/netfilter/ip_nat_irc.c - 1.7 linux/net/ipv4/netfilter/ip_conntrack_irc.c - 1.12 linux/net/8021q/vlanproc.h - 1.2 linux/net/8021q/vlanproc.c - 1.10 linux/net/8021q/vlan_dev.c - 1.10 linux/net/8021q/Makefile - 1.4 linux/Documentation/networking/ifenslave.c - 1.7 linux/Documentation/networking/bonding.txt - 1.10 linux/drivers/atm/idt77252.c - 1.14 linux/fs/ext3/file.c - 1.11 linux/fs/ext3/super.c - 1.40 linux/fs/intermezzo/vfs.c - 1.19 linux/include/linux/ext3_fs.h - 1.21 linux/fs/jbd/transaction.c - 1.22 linux/fs/reiserfs/procfs.c - 1.14 linux/fs/ext3/balloc.c - 1.13 linux/fs/jbd/commit.c - 1.16 linux/fs/intermezzo/dir.c - 1.13 linux/drivers/net/pcmcia/axnet_cs.c - 1.11 linux/drivers/isdn/hisax/hisax_fcpcipnp.c - 1.16 linux/init/do_mounts.c - 1.29 linux/arch/arm/def-configs/adi_evb - 1.7 linux/arch/arm/def-configs/shannon - 1.7 linux/arch/arm/def-configs/system3 - 1.7 linux/include/asm-arm/hardware/sa1111.h - 1.9 linux/arch/arm/mach-arc/Makefile - 1.7 linux/arch/arm/mach-arc/arch.c - 1.3 linux/arch/arm/mach-arc/debug.S - 1.2 linux/arch/arm/mach-arc/dma.c - 1.6 linux/arch/arm/mach-arc/fault.c - 1.2 linux/arch/arm/mach-arc/head.S - 1.4 linux/arch/arm/mach-arc/irq.c - 1.2 linux/arch/arm/mach-arc/mm.c - 1.4 linux/arch/arm/mach-arc/oldlatches.c - 1.3 linux/arch/arm/mach-clps711x/irq.c - 1.4 linux/arch/arm/mach-arc/small_page.c - 1.4 linux/fs/xfs/pagebuf/page_buf.h - 1.73 linux/drivers/net/wireless/netwave_cs.c - 1.10 linux/drivers/net/wireless/wavelan_cs.c - 1.11 linux/drivers/net/wireless/wavelan_cs.p.h - 1.7 linux/drivers/video/neofb.c - 1.14 linux/net/ipv4/netfilter/ipt_esp.c - 1.7 linux/net/ipv4/netfilter/ipt_ah.c - 1.7 linux/lib/zlib_deflate/deftree.c - 1.3 linux/include/linux/pnpbios.h - 1.10 linux/drivers/input/gameport/emu10k1-gp.c - 1.7 linux/drivers/input/gameport/cs461x.c - 1.5 linux/drivers/input/serio/serio.c - 1.11 linux/sound/synth/emux/soundfont.c - 1.5 linux/sound/ppc/tumbler.c - 1.9 linux/sound/ppc/pmac.h - 1.6 linux/sound/ppc/pmac.c - 1.11 linux/sound/ppc/burgundy.c - 1.5 linux/sound/ppc/awacs.c - 1.9 linux/sound/pci/ymfpci/ymfpci_main.c - 1.14 linux/sound/pci/ymfpci/ymfpci.c - 1.13 linux/sound/pci/trident/trident_main.c - 1.15 linux/sound/pci/trident/trident.c - 1.10 linux/sound/pci/sonicvibes.c - 1.14 linux/sound/pci/rme9652/rme9652.c - 1.19 linux/sound/pci/rme9652/Makefile - 1.7 linux/sound/pci/rme96.c - 1.16 linux/sound/pci/nm256/nm256.c - 1.15 linux/sound/pci/maestro3.c - 1.17 linux/sound/pci/korg1212/korg1212.c - 1.22 linux/sound/pci/intel8x0.c - 1.20 linux/sound/pci/fm801.c - 1.15 linux/sound/pci/es1968.c - 1.17 linux/sound/pci/es1938.c - 1.14 linux/sound/pci/ens1370.c - 1.21 linux/arch/ppc/8xx_io/cs4218_tdm.c - 1.7 linux/sound/pci/emu10k1/irq.c - 1.6 linux/sound/pci/emu10k1/emumixer.c - 1.8 linux/sound/pci/emu10k1/emufx.c - 1.17 linux/sound/pci/emu10k1/emu10k1_main.c - 1.11 linux/sound/pci/emu10k1/emu10k1.c - 1.10 linux/sound/pci/cs46xx/cs46xx_lib.c - 1.19 linux/sound/pci/cs46xx/cs46xx.c - 1.15 linux/sound/pci/cs4281.c - 1.18 linux/sound/pci/cmipci.c - 1.17 linux/sound/pci/als4000.c - 1.12 linux/sound/pci/ali5451/ali5451.c - 1.20 linux/sound/pci/ac97/ac97_codec.c - 1.18 linux/sound/pci/ac97/Makefile - 1.12 linux/sound/oss/ymfpci.c - 1.7 linux/sound/oss/via82cxxx_audio.c - 1.13 linux/sound/oss/trident.c - 1.17 linux/sound/oss/soundcard.c - 1.11 linux/sound/oss/sonicvibes.c - 1.12 linux/sound/oss/rme96xx.c - 1.11 linux/sound/oss/nm256_audio.c - 1.8 linux/sound/oss/nec_vrc5477.c - 1.10 linux/sound/oss/msnd_pinnacle.c - 1.8 linux/sound/oss/maestro3.c - 1.11 linux/sound/oss/maestro.c - 1.15 linux/sound/oss/ite8172.c - 1.10 linux/sound/oss/i810_audio.c - 1.16 linux/sound/oss/esssolo1.c - 1.14 linux/sound/oss/es1371.c - 1.15 linux/sound/oss/es1370.c - 1.14 linux/sound/oss/dmasound/dmasound_core.c - 1.9 linux/sound/oss/cs46xx.c - 1.14 linux/sound/oss/cs4281/cs4281m.c - 1.10 linux/sound/oss/cmpci.c - 1.11 linux/sound/oss/btaudio.c - 1.10 linux/arch/x86_64/defconfig - 1.19 linux/arch/x86_64/ia32/ia32_binfmt.c - 1.14 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.21 linux/arch/x86_64/ia32/sys_ia32.c - 1.24 linux/arch/x86_64/kernel/apic.c - 1.18 linux/arch/x86_64/kernel/bluesmoke.c - 1.12 linux/arch/x86_64/kernel/head.S - 1.12 linux/arch/x86_64/kernel/io_apic.c - 1.10 linux/arch/x86_64/kernel/ioport.c - 1.7 linux/arch/x86_64/kernel/mpparse.c - 1.10 linux/arch/x86_64/kernel/nmi.c - 1.14 linux/arch/x86_64/kernel/setup64.c - 1.15 linux/arch/x86_64/mm/extable.c - 1.5 linux/sound/oss/ac97_codec.c - 1.9 linux/sound/isa/wavefront/wavefront.c - 1.13 linux/sound/isa/sb/sb16.c - 1.14 linux/sound/isa/sb/es968.c - 1.13 linux/sound/isa/sb/emu8000.c - 1.10 linux/sound/isa/opl3sa2.c - 1.17 linux/sound/isa/gus/interwave.c - 1.15 linux/sound/isa/gus/gus_main.c - 1.8 linux/sound/isa/es18xx.c - 1.18 linux/sound/isa/cs423x/cs4236.c - 1.16 linux/sound/isa/cs423x/cs4231_lib.c - 1.14 linux/sound/isa/cmi8330.c - 1.14 linux/sound/isa/azt2320.c - 1.12 linux/sound/isa/als100.c - 1.12 linux/sound/isa/ad1848/ad1848_lib.c - 1.12 linux/sound/isa/ad1848/ad1848.c - 1.6 linux/sound/isa/ad1816a/ad1816a.c - 1.10 linux/sound/i2c/cs8427.c - 1.8 linux/sound/drivers/opl3/opl3_lib.c - 1.9 linux/sound/drivers/dummy.c - 1.15 linux/sound/core/timer.c - 1.16 linux/sound/core/sound_oss.c - 1.7 linux/sound/core/sound.c - 1.19 linux/sound/core/seq/seq_ports.h - 1.3 linux/sound/core/seq/seq_ports.c - 1.10 linux/sound/core/seq/seq_midi_event.c - 1.9 linux/sound/core/seq/seq_clientmgr.c - 1.14 linux/sound/core/rtctimer.c - 1.14 linux/sound/core/rawmidi.c - 1.17 linux/sound/core/pcm_native.c - 1.19 linux/sound/core/pcm_memory.c - 1.9 linux/sound/core/pcm_lib.c - 1.15 linux/sound/core/oss/route.c - 1.4 linux/sound/core/oss/rate.c - 1.4 linux/sound/core/oss/plugin_ops.h - 1.2 linux/sound/core/oss/pcm_plugin.h - 1.3 linux/sound/core/oss/pcm_plugin.c - 1.6 linux/sound/core/oss/pcm_oss.c - 1.19 linux/sound/core/info.c - 1.17 linux/sound/core/control.c - 1.14 linux/include/sound/pcm_oss.h - 1.3 linux/include/asm-x86_64/processor.h - 1.18 linux/include/asm-x86_64/pda.h - 1.10 linux/include/asm-x86_64/mpspec.h - 1.6 linux/include/asm-x86_64/mmu.h - 1.3 linux/include/asm-x86_64/hw_irq.h - 1.6 linux/include/asm-x86_64/desc.h - 1.9 linux/include/asm-x86_64/apic.h - 1.9 linux/include/sound/ymfpci.h - 1.6 linux/include/sound/version.h - 1.19 linux/include/sound/soundfont.h - 1.3 linux/include/sound/seq_midi_event.h - 1.3 linux/include/sound/info.h - 1.8 linux/include/sound/emu10k1.h - 1.12 linux/include/sound/cs8427.h - 1.3 linux/include/sound/core.h - 1.19 linux/include/sound/asound.h - 1.13 linux/include/sound/asequencer.h - 1.5 linux/include/sound/ad1848.h - 1.5 linux/include/sound/ac97_codec.h - 1.15 linux/include/asm-x86_64/smp.h - 1.9 linux/include/asm-x86_64/unistd.h - 1.16 linux/arch/ppc64/mm/fault.c - 1.9 linux/arch/ppc64/mm/init.c - 1.19 linux/include/asm-ppc64/ipc.h - 1.3 linux/arch/ppc64/boot/Makefile - 1.14 linux/arch/ppc64/boot/main.c - 1.7 linux/arch/ppc64/defconfig - 1.18 linux/arch/ppc64/kernel/chrp_setup.c - 1.16 linux/arch/ppc64/kernel/eeh.c - 1.8 linux/arch/ppc64/kernel/iSeries_setup.c - 1.12 linux/arch/ppc64/kernel/irq.c - 1.13 linux/arch/ppc64/kernel/misc.S - 1.22 linux/arch/ppc64/kernel/open_pic.c - 1.10 linux/arch/ppc64/kernel/pSeries_pci.c - 1.14 linux/arch/ppc64/kernel/pci.c - 1.16 linux/arch/ppc64/kernel/process.c - 1.19 linux/arch/ppc64/kernel/setup.c - 1.14 linux/arch/ppc64/kernel/smp.c - 1.21 linux/arch/ppc64/kernel/sys_ppc32.c - 1.26 linux/arch/ppc64/kernel/syscalls.c - 1.10 linux/arch/ppc64/kernel/time.c - 1.17 linux/arch/ppc64/kernel/traps.c - 1.15 linux/arch/ppc64/kernel/xics.c - 1.12 linux/include/asm-ppc64/unistd.h - 1.17 linux/include/asm-ppc64/smp.h - 1.9 linux/drivers/net/e1000/e1000_main.c - 1.24 linux/drivers/net/e1000/e1000_ethtool.c - 1.14 linux/drivers/isdn/hisax/hisax_hfcpci.c - 1.8 linux/drivers/net/tokenring/3c359.c - 1.9 linux/arch/arm/def-configs/badge4 - 1.9 linux/arch/arm/def-configs/fortunet - 1.6 linux/arch/arm/def-configs/stork - 1.7 linux/fs/jfs/jfs_dtree.c - 1.15 linux/fs/jfs/jfs_incore.h - 1.16 linux/fs/jfs/namei.c - 1.19 linux/fs/jfs/jfs_logmgr.c - 1.28 linux/fs/jfs/super.c - 1.26 linux/fs/jfs/jfs_txnmgr.c - 1.28 linux/fs/quota_v1.c - 1.9 linux/drivers/net/tg3.h - 1.15 linux/drivers/net/tg3.c - 1.25 linux/drivers/net/tulip/de2104x.c - 1.11 linux/drivers/net/tulip/dmfe.c - 1.9 linux/drivers/net/tulip/winbond-840.c - 1.13 linux/drivers/net/tulip/xircom_cb.c - 1.9 linux/sound/core/ioctl32/ioctl32.c - 1.10 linux/drivers/net/wan/hdlc_x25.c - 1.7 linux/drivers/net/tulip/xircom_tulip_cb.c - 1.7 linux/drivers/net/wan/hdlc_cisco.c - 1.7 linux/drivers/net/wan/hdlc_fr.c - 1.7 linux/drivers/net/wan/hdlc_generic.c - 1.8 linux/drivers/net/e100/e100_main.c - 1.25 linux/Documentation/sound/oss/Introduction - 1.3 linux/Documentation/sound/oss/README.OSS - 1.2 linux/Documentation/sound/oss/Wavefront - 1.3 linux/arch/ia64/sn/kernel/sv.c - 1.6 linux/arch/ia64/sn/kernel/sn_ksyms.c - 1.4 linux/arch/ia64/sn/kernel/sn2/sn2_smp.c - 1.5 linux/arch/ia64/sn/kernel/sn2/cache.c - 1.3 linux/arch/ia64/sn/kernel/setup.c - 1.12 linux/arch/ia64/sn/kernel/mca.c - 1.6 linux/include/asm-ia64/sn/sn2/sn_private.h - 1.4 linux/arch/ia64/sn/kernel/Makefile - 1.11 linux/arch/ia64/sn/io/sn2/shuberror.c - 1.5 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c - 1.9 linux/net/ipv4/netfilter/arp_tables.c - 1.9 linux/drivers/media/video/bttv-risc.c - 1.6 linux/drivers/media/video/bttv-vbi.c - 1.8 linux/drivers/ieee1394/eth1394.c - 1.13 linux/drivers/net/tc35815.c - 1.11 linux/drivers/ide/ide-tcq.c - 1.8 linux/drivers/usb/class/audio.c - 1.18 linux/drivers/usb/class/bluetty.c - 1.22 linux/drivers/usb/class/cdc-acm.c - 1.23 linux/drivers/usb/core/devices.c - 1.8 linux/drivers/usb/core/devio.c - 1.16 linux/drivers/usb/core/hcd.c - 1.27 linux/drivers/usb/core/hcd.h - 1.18 linux/drivers/usb/core/hub.c - 1.28 linux/drivers/usb/core/usb-debug.c - 1.7 linux/drivers/usb/core/usb.c - 1.38 linux/drivers/usb/media/konicawc.c - 1.13 linux/drivers/usb/host/ehci-dbg.c - 1.17 linux/drivers/usb/media/pwc-ioctl.h - 1.4 linux/arch/arm/mach-pxa/dma.c - 1.4 linux/arch/arm/mach-pxa/generic.c - 1.7 linux/drivers/usb/media/pwc-misc.c - 1.3 linux/drivers/usb/host/ehci-hcd.c - 1.24 linux/drivers/usb/host/ehci-mem.c - 1.8 linux/drivers/usb/host/ehci-q.c - 1.21 linux/drivers/usb/host/ehci-sched.c - 1.14 linux/drivers/usb/host/ohci-hcd.c - 1.23 linux/drivers/usb/host/ohci-mem.c - 1.12 linux/drivers/base/power.c - 1.10 linux/drivers/ieee1394/cmp.c - 1.8 linux/drivers/usb/image/scanner.c - 1.26 linux/drivers/usb/input/usbkbd.c - 1.17 linux/drivers/usb/input/usbmouse.c - 1.14 linux/drivers/usb/input/wacom.c - 1.13 linux/drivers/ieee1394/eth1394.h - 1.8 linux/drivers/usb/media/ibmcam.c - 1.10 linux/drivers/usb/media/ov511.c - 1.16 linux/drivers/usb/media/pwc-ctrl.c - 1.6 linux/drivers/usb/media/pwc-if.c - 1.12 linux/drivers/usb/media/pwc-uncompress.c - 1.4 linux/drivers/usb/media/pwc-uncompress.h - 1.4 linux/drivers/usb/media/pwc.h - 1.6 linux/drivers/usb/net/usbnet.c - 1.26 linux/drivers/usb/net/rtl8150.c - 1.19 linux/drivers/usb/net/pegasus.c - 1.19 linux/drivers/usb/net/catc.c - 1.12 linux/mm/readahead.c - 1.23 linux/drivers/usb/misc/auerswald.c - 1.20 linux/drivers/usb/misc/emi26.c - 1.8 linux/include/asm-ia64/percpu.h - 1.8 linux/drivers/isdn/i4l/isdn_x25iface.c - 1.4 linux/drivers/isdn/i4l/isdn_ppp.c - 1.15 linux/include/asm-x86_64/percpu.h - 1.6 linux/arch/ia64/hp/common/sba_iommu.c - 1.14 linux/drivers/usb/misc/brlvger.c - 1.16 linux/drivers/isdn/hardware/avm/t1pci.c - 1.8 linux/drivers/isdn/hardware/avm/t1isa.c - 1.6 linux/drivers/isdn/hardware/avm/c4.c - 1.8 linux/drivers/isdn/hardware/avm/b1pci.c - 1.9 linux/drivers/isdn/hardware/avm/b1isa.c - 1.5 linux/drivers/isdn/capi/capidrv.c - 1.5 linux/drivers/char/synclinkmp.c - 1.12 linux/sound/pci/rme32.c - 1.12 linux/drivers/char/pcmcia/synclink_cs.c - 1.15 linux/scripts/mkcompile_h - 1.9 linux/drivers/block/umem.c - 1.23 linux/drivers/usb/host/uhci-hcd.c - 1.24 linux/drivers/net/wan/pc300_drv.c - 1.7 linux/arch/i386/pci/fixup.c - 1.7 linux/drivers/net/wireless/orinoco_pci.c - 1.6 linux/arch/i386/pci/i386.c - 1.6 linux/arch/i386/pci/irq.c - 1.9 linux/drivers/pci/probe.c - 1.20 linux/arch/i386/pci/numa.c - 1.10 linux/kernel/suspend.c - 1.27 linux/drivers/char/drm/sis_mm.c - 1.4 linux/drivers/usb/host/hc_sl811_rh.c - 1.6 linux/drivers/video/tridentfb.c - 1.8 linux/include/linux/suspend.h - 1.10 linux/drivers/usb/core/urb.c - 1.14 linux/drivers/usb/core/message.c - 1.22 linux/drivers/usb/core/config.c - 1.5 linux/drivers/acpi/pci_irq.c - 1.14 linux/drivers/usb/host/ohci-sa1111.c - 1.15 linux/drivers/usb/class/usb-midi.c - 1.16 linux/drivers/usb/core/hcd-pci.c - 1.13 linux/arch/i386/kernel/suspend.c - 1.14 linux/drivers/usb/host/ohci-pci.c - 1.10 linux/arch/i386/kernel/cpu/common.c - 1.15 linux/drivers/usb/input/aiptek.c - 1.13 linux/arch/x86_64/ia32/ipc32.c - 1.9 linux/arch/arm/kernel/asm-offsets.c - 1.4 linux/arch/i386/mm/pageattr.c - 1.5 linux/sound/pci/rme9652/hdsp.c - 1.14 linux/sound/pci/rme9652/hammerfall_mem.c - 1.11 linux/drivers/input/serio/i8042.c - 1.14 linux/drivers/input/gameport/fm801-gp.c - 1.4 linux/drivers/input/gameport/vortex.c - 1.4 linux/drivers/usb/core/file.c - 1.7 linux/drivers/usb/input/xpad.c - 1.13 linux/fs/smbfs/request.c - 1.4 linux/security/Makefile - 1.4 linux/drivers/usb/serial/io_ti.c - 1.13 linux/drivers/char/agp/ali-agp.c - 1.9 linux/drivers/char/agp/hp-agp.c - 1.10 linux/drivers/char/agp/i460-agp.c - 1.10 linux/drivers/serial/8250_pci.c - 1.12 linux/drivers/char/agp/sworks-agp.c - 1.9 linux/include/asm-mips64/rmap.h - 1.3 linux/arch/i386/mm/pgtable.c - 1.11 linux/arch/arm/mach-pxa/sleep.S - 1.3 linux/include/asm-mips64/linkage.h - 1.2 linux/arch/arm/mach-pxa/pm.c - 1.3 linux/net/sched/sch_htb.c - 1.11 linux/drivers/usb/class/usblp.c - 1.13 linux/net/ipv4/netfilter/ipt_helper.c - 1.6 linux/arch/i386/kernel/cpu/mtrr/main.c - 1.6 linux/arch/mips64/vmlinux.lds.S - 1.6 linux/fs/jfs/xattr.c - 1.11 linux/net/sctp/protocol.c - 1.21 linux/net/sctp/associola.c - 1.17 linux/include/linux/sctp.h - 1.4 linux/net/sctp/debug.c - 1.5 linux/net/sctp/endpointola.c - 1.13 linux/net/sctp/input.c - 1.16 linux/include/net/sctp/constants.h - 1.8 linux/include/net/sctp/sm.h - 1.14 linux/net/sctp/sm_make_chunk.c - 1.18 linux/include/net/sctp/command.h - 1.7 linux/net/sctp/sm_sideeffect.c - 1.19 linux/net/sctp/sm_statefuns.c - 1.18 linux/include/net/sctp/structs.h - 1.20 linux/include/linux/efi.h - 1.3 linux/net/sctp/sm_statetable.c - 1.10 linux/net/sctp/socket.c - 1.21 linux/drivers/ide/setup-pci.c - 1.14 linux/drivers/ide/pci/via82cxxx.c - 1.11 linux/drivers/ide/pci/trm290.c - 1.8 linux/drivers/ide/pci/slc90e66.c - 1.8 linux/drivers/ide/pci/sl82c105.c - 1.8 linux/drivers/ide/pci/sis5513.c - 1.12 linux/drivers/ide/pci/siimage.c - 1.9 linux/drivers/ide/pci/serverworks.c - 1.11 linux/drivers/ide/pci/rz1000.c - 1.6 linux/drivers/ide/pci/piix.c - 1.10 linux/drivers/ide/pci/pdcadma.c - 1.8 linux/drivers/ide/pci/pdc202xx_old.c - 1.10 linux/drivers/ide/pci/pdc202xx_new.c - 1.13 linux/drivers/ide/pci/opti621.c - 1.8 linux/drivers/ide/pci/ns87415.c - 1.7 linux/drivers/ide/pci/it8172.c - 1.7 linux/drivers/ide/pci/hpt366.c - 1.13 linux/drivers/ide/pci/hpt34x.c - 1.9 linux/drivers/ide/pci/generic.c - 1.7 linux/drivers/ide/pci/cy82c693.c - 1.10 linux/drivers/ide/pci/cs5530.c - 1.9 linux/drivers/ide/pci/cmd64x.c - 1.7 linux/drivers/ide/pci/amd74xx.c - 1.14 linux/drivers/ide/pci/alim15x3.c - 1.8 linux/drivers/ide/pci/aec62xx.c - 1.9 linux/drivers/ide/legacy/hd.c - 1.15 linux/drivers/ide/ide-lib.c - 1.9 linux/arch/um/Makefile - 1.10 linux/arch/um/config.release - 1.2 linux/arch/um/defconfig - 1.6 linux/arch/um/drivers/ubd_kern.c - 1.14 linux/arch/mips/vmlinux.lds.S - 1.7 linux/mm/madvise.c - 1.5 linux/arch/ppc/boot/openfirmware/Makefile - 1.8 linux/arch/ia64/pci/pci.c - 1.12 linux/drivers/usb/core/usb.h - 1.2 linux/include/asm-mips/topology.h - 1.3 linux/include/asm-mips64/topology.h - 1.4 linux/sound/pci/ac97/ac97_patch.h - 1.7 linux/sound/pci/ac97/ac97_patch.c - 1.9 linux/sound/isa/dt019x.c - 1.8 linux/kernel/cpufreq.c - 1.16 linux/include/asm-x86_64/topology.h - 1.3 linux/include/linux/cpufreq.h - 1.16 linux/arch/i386/kernel/cpu/cpufreq/powernow-k6.c - 1.11 linux/arch/i386/kernel/cpu/cpufreq/longrun.c - 1.11 linux/arch/i386/kernel/cpu/cpufreq/longhaul.c - 1.12 linux/sound/usb/usbquirks.h - 1.10 linux/sound/usb/usbmixer.c - 1.8 linux/sound/usb/usbmidi.c - 1.8 linux/sound/usb/usbaudio.h - 1.9 linux/sound/usb/usbaudio.c - 1.13 linux/sound/pci/via82xx.c - 1.12 linux/sound/pci/ice1712/ice1712.h - 1.8 linux/sound/pci/ice1712/ice1712.c - 1.10 linux/sound/pci/ice1712/ews.c - 1.8 linux/drivers/usb/misc/usbtest.c - 1.14 linux/drivers/scsi/nsp32.c - 1.13 linux/drivers/i2c/scx200_acb.c - 1.5 linux/drivers/net/irda/donauboe.c - 1.7 linux/fs/cifs/README - 1.5 linux/Documentation/kbuild/random.txt - 1.2 linux/fs/cifs/cifsfs.c - 1.15 linux/fs/nfsd/nfs4xdr.c - 1.14 linux/fs/cifs/cifsglob.h - 1.9 linux/fs/cifs/cifspdu.h - 1.8 linux/fs/cifs/cifsproto.h - 1.12 linux/fs/cifs/cifssmb.c - 1.14 linux/fs/cifs/connect.c - 1.15 linux/fs/cifs/dir.c - 1.6 linux/fs/cifs/file.c - 1.12 linux/fs/cifs/inode.c - 1.12 linux/fs/cifs/link.c - 1.6 linux/fs/cifs/misc.c - 1.10 linux/fs/cifs/AUTHORS - 1.4 linux/net/sunrpc/cache.c - 1.9 linux/fs/cifs/CHANGES - 1.13 linux/fs/cifs/transport.c - 1.12 linux/fs/cifs/ntlmssp.h - 1.2 linux/drivers/isdn/hardware/eicon/message.c - 1.2 linux/include/linux/sunrpc/cache.h - 1.8 linux/drivers/isdn/hardware/eicon/divasmain.c - 1.9 linux/sound/usb/usbmixer_maps.c - 1.4 linux/Documentation/arm/XScale/ADIFCC/80200EVB - 1.2 linux/drivers/mtd/maps/pci.c - 1.4 linux/drivers/block/scsi_ioctl.c - 1.12 linux/arch/x86_64/kernel/pci-gart.c - 1.12 linux/fs/intermezzo/fileset.c - 1.4 linux/drivers/pnp/pnpbios/core.c - 1.15 linux/drivers/pnp/resource.c - 1.14 linux/drivers/pnp/names.c - 1.5 linux/drivers/pnp/base.h - 1.6 linux/drivers/pnp/core.c - 1.10 linux/drivers/pnp/pnpbios/Makefile - 1.4 linux/include/asm-x86_64/nmi.h - 1.3 linux/include/linux/pnp.h - 1.13 linux/drivers/pnp/idlist.h - 1.3 linux/drivers/net/Kconfig - 1.18 linux/drivers/net/irda/Kconfig - 1.7 linux/net/decnet/Kconfig - 1.3 linux/arch/alpha/Kconfig - 1.17 linux/arch/arm/Kconfig - 1.17 linux/sound/Kconfig - 1.4 linux/security/Kconfig - 1.6 linux/arch/arm/mach-arc/Kconfig - 1.2 linux/scripts/kconfig/mconf.c - 1.7 linux/arch/cris/Kconfig - 1.12 linux/net/ipv4/Kconfig - 1.9 linux/arch/i386/Kconfig - 1.26 linux/net/bridge/br_netfilter.c - 1.9 linux/drivers/media/video/Kconfig - 1.7 linux/drivers/media/dvb/frontends/Makefile - 1.6 linux/arch/ia64/Kconfig - 1.17 linux/drivers/media/dvb/dvb-core/dvb_net.c - 1.6 linux/drivers/media/dvb/dvb-core/dvb_frontend.c - 1.7 linux/drivers/char/Kconfig - 1.10 linux/arch/m68k/Kconfig - 1.16 linux/arch/mips/Kconfig - 1.12 linux/arch/mips64/Kconfig - 1.13 linux/arch/parisc/Kconfig - 1.14 linux/drivers/pnp/Kconfig - 1.6 linux/arch/parisc/kernel/sys_parisc32.c - 1.14 linux/drivers/md/dm.c - 1.11 linux/drivers/md/dm-table.c - 1.9 linux/drivers/md/dm-stripe.c - 1.6 linux/include/linux/pfkeyv2.h - 1.8 linux/arch/ppc/Kconfig - 1.17 linux/drivers/char/drm/Kconfig - 1.6 linux/arch/ppc64/Kconfig - 1.14 linux/arch/s390/Kconfig - 1.12 linux/arch/sh/Kconfig - 1.13 linux/arch/sparc/Kconfig - 1.15 linux/drivers/i2c/Kconfig - 1.8 linux/arch/sparc64/Kconfig - 1.20 linux/drivers/ide/Kconfig - 1.14 linux/arch/um/Kconfig - 1.7 linux/arch/x86_64/Kconfig - 1.20 linux/drivers/input/Kconfig - 1.4 linux/drivers/input/keyboard/Kconfig - 1.5 linux/crypto/tcrypt.c - 1.9 linux/net/ipv4/netfilter/ipt_physdev.c - 1.6 linux/net/Kconfig - 1.9 linux/drivers/serial/Kconfig - 1.12 linux/drivers/acpi/Kconfig - 1.8 linux/drivers/atm/Kconfig - 1.4 linux/net/ipv6/Kconfig - 1.6 linux/include/net/xfrm.h - 1.18 linux/drivers/input/serio/Kconfig - 1.8 linux/usr/gen_init_cpio.c - 1.4 linux/arch/alpha/kernel/err_common.c - 1.3 linux/arch/alpha/kernel/err_impl.h - 1.4 linux/fs/binfmt_flat.c - 1.5 linux/include/linux/videodev2.h - 1.3 linux/drivers/parisc/superio.c - 1.5 linux/drivers/parisc/lba_pci.c - 1.5 linux/drivers/parisc/eisa.c - 1.8 linux/drivers/media/video/saa7134/saa7134.h - 1.6 linux/drivers/media/video/saa7134/saa7134-video.c - 1.8 linux/drivers/media/video/saa7134/saa7134-ts.c - 1.7 linux/drivers/media/video/saa7134/saa7134-i2c.c - 1.9 linux/drivers/media/video/saa7134/saa7134-core.c - 1.6 linux/arch/m68knommu/Kconfig - 1.15 linux/arch/v850/kernel/rte_mb_a_pci.c - 1.7 linux/arch/v850/Kconfig - 1.15 linux/drivers/net/b44.c - 1.5 linux/drivers/net/irda/tekram-sir.c - 1.2 linux/fs/jfs/jfs_acl.h - 1.3 linux/arch/i386/kernel/cpu/mcheck/k7.c - 1.5 linux/net/key/af_key.c - 1.18 linux/arch/ppc/syslib/open_pic.c - 1.7 linux/arch/i386/kernel/suspend_asm.S - 1.4 linux/drivers/s390/char/tape_block.c - 1.7 linux/drivers/ide/pci/sc1200.c - 1.7 linux/Documentation/scsi/BusLogic.txt - 1.2 linux/Documentation/scsi/cpqfc.txt - 1.2 linux/drivers/usb/serial/kobil_sct.c - 1.9 linux/drivers/video/console/Kconfig - 1.6 linux/drivers/video/console/sticore.c - 1.6 linux/drivers/char/agp/amd-k7-agp.c - 1.8 linux/drivers/char/agp/amd-k8-agp.c - 1.11 linux/drivers/char/agp/generic.c - 1.9 linux/drivers/ide/pci/cs5520.c - 1.6 linux/fs/jfs/acl.c - 1.3 linux/drivers/char/agp/intel-agp.c - 1.10 linux/include/asm-mips64/compat.h - 1.3 linux/drivers/char/watchdog/Kconfig - 1.6 linux/drivers/char/watchdog/acquirewdt.c - 1.9 linux/drivers/char/watchdog/advantechwdt.c - 1.5 linux/drivers/ide/ide-io.c - 1.13 linux/kernel/compat.c - 1.12 linux/drivers/net/r8169.c - 1.7 linux/drivers/char/watchdog/ib700wdt.c - 1.8 linux/drivers/char/watchdog/machzwd.c - 1.9 linux/drivers/char/watchdog/mixcomwd.c - 1.8 linux/drivers/char/watchdog/pcwd.c - 1.10 linux/drivers/char/watchdog/sbc60xxwdt.c - 1.9 linux/drivers/char/watchdog/wdt977.c - 1.8 linux/drivers/char/watchdog/wdt_pci.c - 1.8 linux/drivers/char/watchdog/shwdt.c - 1.7 linux/drivers/char/watchdog/scx200_wdt.c - 1.3 linux/include/linux/xfrm.h - 1.10 linux/drivers/char/watchdog/softdog.c - 1.8 linux/drivers/char/watchdog/wdt285.c - 1.4 linux/drivers/char/watchdog/w83877f_wdt.c - 1.7 linux/Documentation/sound/alsa/ALSA-Configuration.txt - 1.6 linux/drivers/i2c/busses/Kconfig - 1.9 linux/drivers/i2c/busses/Makefile - 1.7 linux/drivers/i2c/busses/i2c-amd756.c - 1.6 linux/drivers/i2c/busses/i2c-amd8111.c - 1.7 linux/drivers/i2c/chips/adm1021.c - 1.9 linux/drivers/i2c/chips/lm75.c - 1.8 linux/arch/i386/kernel/sysenter.c - 1.9 linux/include/asm-mips64/dma-mapping.h - 1.2 linux/include/asm-mips/dma-mapping.h - 1.2 linux/include/asm-ia64/compat.h - 1.7 linux/drivers/video/i810/i810_main.c - 1.8 linux/drivers/video/i810/i810_main.h - 1.6 linux/drivers/char/watchdog/alim7101_wdt.c - 1.4 linux/drivers/char/watchdog/wafer5823wdt.c - 1.6 linux/drivers/char/watchdog/indydog.c - 1.7 linux/drivers/char/watchdog/sa1100_wdt.c - 1.3 linux/drivers/char/watchdog/sc520_wdt.c - 1.9 linux/drivers/ide/pci/triflex.h - 1.3 linux/drivers/media/video/tda9887.c - 1.6 linux/drivers/net/amd8111e.c - 1.7 linux/drivers/char/ipmi/ipmi_kcs_intf.c - 1.7 linux/include/asm-mips64/bug.h - 1.4 linux/arch/alpha/kernel/core_marvel.c - 1.8 linux/arch/alpha/kernel/err_marvel.c - 1.2 linux/arch/alpha/kernel/err_titan.c - 1.3 linux/include/asm-alpha/core_marvel.h - 1.3 linux/mm/fadvise.c - 1.5 linux/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl - 1.7 linux/arch/i386/kernel/cpu/cpufreq/acpi.c - 1.6 linux/arch/arm/mach-sa1100/hackkit.c - 1.2 linux/arch/arm/common/sa1111-pcipool.c - 1.3 linux/arch/arm/common/sa1111.c - 1.8 linux/arch/arm/def-configs/trizeps - 1.2 linux/scripts/modpost.c - 1.7 linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c - 1.8 linux/drivers/acpi/sleep/main.c - 1.5 linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.h - 1.2 linux/drivers/eisa/pci_eisa.c - 1.3 linux/drivers/net/typhoon.c - 1.6 linux/arch/i386/kernel/acpi/sleep.c - 1.4 linux/drivers/net/wireless/ray_cs.c - 1.5 linux/drivers/pnp/manager.c - 1.7 linux/drivers/pnp/support.c - 1.5 linux/arch/ppc64/boot/prom.c - 1.2 linux/scripts/genksyms/lex.l - 1.2 linux/scripts/genksyms/lex.c_shipped - 1.2 linux/Documentation/arm/XScale/IOP3XX/IQ80310 - 1.2 linux/Documentation/arm/XScale/IOP3XX/IQ80321 - 1.2 linux/Documentation/cpu-freq/core.txt - 1.3 linux/Documentation/cpu-freq/cpu-drivers.txt - 1.3 linux/Documentation/cpu-freq/governors.txt - 1.3 linux/Documentation/cpu-freq/user-guide.txt - 1.6 linux/drivers/cpufreq/userspace.c - 1.3 linux/net/sctp/proc.c - 1.5 linux/fs/sysfs/bin.c - 1.7 linux/init/do_mounts_devfs.c - 1.2 linux/drivers/i2c/busses/i2c-ali15x3.c - 1.6 linux/scripts/kconfig/gconf.c - 1.6 linux/arch/arm/mach-sa1100/ssp.c - 1.3 linux/net/ipv6/ah6.c - 1.9 linux/arch/ia64/sn/io/sn2/shub.c - 1.4 linux/drivers/i2c/busses/i2c-piix4.c - 1.5 linux/drivers/i2c/busses/i2c-i801.c - 1.6 linux/net/ipv6/esp6.c - 1.9 linux/sound/pci/ice1712/ice1724.c - 1.4 linux/sound/core/memalloc.c - 1.5 linux/scripts/pnmtologo.c - 1.2 linux/net/ipv6/xfrm6_policy.c - 1.7 linux/net/ipv6/xfrm6_input.c - 1.8 linux/drivers/video/logo/Makefile - 1.3 linux/net/ipv4/xfrm4_policy.c - 1.4 linux/net/ipv4/xfrm4_input.c - 1.5 linux/drivers/ide/legacy/hd98.c - 1.5 linux/drivers/i2c/busses/i2c-isa.c - 1.4 linux/drivers/video/aty/aty128fb.c - 1.5 linux/net/xfrm/xfrm_user.c - 1.7 linux/net/xfrm/xfrm_state.c - 1.9 linux/net/xfrm/xfrm_policy.c - 1.8 linux/net/xfrm/xfrm_input.c - 1.4 linux/drivers/char/drm/i830_irq.c - 1.3 linux/drivers/i2c/chips/via686a.c - 1.5 linux/drivers/i2c/chips/w83781d.c - 1.7 linux/net/ipv4/netfilter/ip_conntrack_tftp.c - 1.4 linux/arch/ppc/platforms/pmac_cpufreq.c - 1.5 linux/drivers/media/common/Kconfig - 1.2 linux/arch/s390/kernel/compat_linux.c - 1.4 linux/drivers/media/common/saa7146_i2c.c - 1.4 linux/drivers/media/common/saa7146_video.c - 1.5 linux/include/sound/hdsp.h - 1.2 linux/arch/arm/def-configs/iq80321 - 1.2 linux/drivers/media/dvb/ttpci/budget-av.c - 1.4 linux/drivers/media/dvb/ttpci/budget-patch.c - 1.4 linux/drivers/media/video/tda9840.c - 1.3 linux/drivers/media/video/tea6415c.c - 1.3 linux/drivers/i2c/i2c-keywest.c - 1.3 linux/drivers/i2c/busses/i2c-viapro.c - 1.4 linux/include/asm-h8300/aki3068net/ne.h - 1.2 linux/include/asm-h8300/atomic.h - 1.2 linux/include/asm-h8300/bitops.h - 1.2 linux/arch/h8300/Kconfig - 1.5 linux/arch/h8300/Makefile - 1.3 linux/arch/h8300/defconfig - 1.2 linux/arch/h8300/kernel/asm-offsets.c - 1.2 linux/arch/h8300/kernel/gpio.c - 1.2 linux/arch/h8300/kernel/process.c - 1.2 linux/arch/h8300/kernel/ptrace.c - 1.2 linux/arch/h8300/kernel/setup.c - 1.3 linux/arch/h8300/kernel/signal.c - 1.2 linux/arch/h8300/kernel/sys_h8300.c - 1.2 linux/arch/h8300/kernel/syscalls.S - 1.2 linux/arch/h8300/kernel/time.c - 1.2 linux/arch/h8300/kernel/traps.c - 1.2 linux/arch/h8300/lib/Makefile - 1.3 linux/arch/h8300/lib/abs.S - 1.2 linux/arch/h8300/lib/memset.S - 1.2 linux/arch/h8300/platform/h8300h/Rules.make - 1.2 linux/arch/h8300/platform/h8300h/aki3068net/Makefile - 1.2 linux/arch/h8300/platform/h8300h/aki3068net/crt0_ram.S - 1.2 linux/arch/h8300/platform/h8300h/aki3068net/ram.ld - 1.2 linux/arch/h8300/platform/h8300h/aki3068net/timer.c - 1.2 linux/arch/h8300/platform/h8300h/entry.S - 1.2 linux/arch/h8300/platform/h8300h/generic/Makefile - 1.2 linux/arch/h8300/platform/h8300h/generic/crt0_rom.S - 1.2 linux/arch/h8300/platform/h8300h/generic/ram.ld - 1.2 linux/arch/h8300/platform/h8300h/generic/rom.ld - 1.3 linux/arch/h8300/platform/h8300h/generic/timer.c - 1.2 linux/arch/h8300/platform/h8300h/h8max/Makefile - 1.2 linux/arch/h8300/platform/h8300h/h8max/crt0_ram.S - 1.2 linux/arch/h8300/platform/h8300h/h8max/ram.ld - 1.2 linux/arch/h8300/platform/h8300h/h8max/timer.c - 1.2 linux/arch/h8300/platform/h8300h/ints.c - 1.2 linux/arch/h8300/vmlinux.lds.S - 1.2 linux/include/asm-h8300/checksum.h - 1.2 linux/include/asm-h8300/errno.h - 1.2 linux/include/asm-h8300/generic/timer_rate.h - 1.2 linux/include/asm-h8300/gpio.h - 1.2 linux/include/asm-h8300/h8max/ne.h - 1.2 linux/drivers/block/floppy98.c - 1.6 linux/fs/nfsd/nfs4state.c - 1.5 linux/include/asm-h8300/io.h - 1.2 linux/include/asm-h8300/irq.h - 1.3 linux/net/ipv4/ipcomp.c - 1.6 linux/include/asm-h8300/unistd.h - 1.2 linux/include/asm-h8300/uaccess.h - 1.3 linux/include/asm-h8300/types.h - 1.2 linux/include/asm-h8300/traps.h - 1.2 linux/include/asm-h8300/tlb.h - 1.2 linux/include/asm-h8300/thread_info.h - 1.3 linux/include/asm-h8300/target_time.h - 1.2 linux/include/asm-h8300/system.h - 1.2 linux/include/asm-h8300/semaphore.h - 1.2 linux/include/asm-h8300/ptrace.h - 1.2 linux/include/asm-h8300/regs306x.h - 1.2 linux/include/asm-h8300/processor.h - 1.3 linux/include/asm-h8300/pgtable.h - 1.2 linux/drivers/net/ixgb/ixgb_ethtool.c - 1.4 linux/drivers/net/ixgb/ixgb_main.c - 1.4 linux/drivers/scsi/dc395x.c - 1.7 linux/include/linux/compat_ioctl.h - 1.6 linux/drivers/scsi/dc395x.h - 1.2 linux/drivers/i2c/chips/it87.c - 1.3 linux/include/linux/usb_gadget.h - 1.3 linux/drivers/net/arm/am79c961a.c - 1.2 linux/drivers/net/arm/am79c961a.h - 1.2 linux/drivers/net/arm/ether00.c - 1.2 linux/drivers/net/arm/ether1.c - 1.2 linux/drivers/net/arm/ether3.c - 1.2 linux/drivers/net/arm/etherh.c - 1.2 linux/dev/null - 1.8 linux/drivers/usb/gadget/net2280.c - 1.5 linux/drivers/atm/he.c - 1.5 linux/drivers/i2c/busses/i2c-sis96x.c - 1.2 linux/drivers/char/agp/nvidia-agp.c - 1.3 linux/drivers/scsi/arm/arxescsi.c - 1.5 linux/drivers/scsi/arm/eesox.c - 1.5 linux/net/ipv6/ipcomp6.c - 1.4 linux/drivers/scsi/arm/fas216.c - 1.4 linux/drivers/scsi/arm/fas216.h - 1.3 linux/drivers/char/drm/gamma_lists.h - 1.2 linux/drivers/mtd/maps/ich2rom.c - 1.2 linux/drivers/mtd/maps/amd76xrom.c - 1.2 linux/sound/pcmcia/vx/vxpocket.c - 1.2 linux/drivers/mtd/maps/scb2_flash.c - 1.2 linux/drivers/mtd/mtd_blkdevs.c - 1.5 linux/sound/pci/azt3328.c - 1.2 linux/sound/pci/vx222/vx222.c - 1.2 linux/sound/drivers/opl4/opl4_lib.c - 1.2 linux/drivers/net/wireless/orinoco_tmd.c - 1.2 linux/sound/drivers/opl4/opl4_synth.c - 1.2 linux/arch/arm26/Kconfig - 1.6 linux/arch/arm26/lib/kbd.c - 1.2 linux/drivers/pci/hotplug/cpcihp_zt5550.c - 1.2 linux/drivers/pci/hotplug/cpqphp_core.c - 1.3 linux/sound/pci/ice1712/aureon.c - 1.2 linux/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c - 1.3 linux/arch/i386/kernel/cpu/cpufreq/speedstep-ich.c - 1.3 linux/sound/pci/ice1712/ak4xxx.c - 1.2 linux/drivers/i2c/chips/lm85.c - 1.3 linux/drivers/pci/hotplug/ibmphp_ebda.c - 1.3 linux/net/ipv4/esp4.c - 1.3 linux/net/ipv4/ah4.c - 1.3 linux/sound/drivers/opl4/opl4_local.h - 1.2 linux/sound/drivers/vx/vx_core.c - 1.2 linux/sound/i2c/other/ak4xxx-adda.c - 1.2 linux/sound/isa/sscape.c - 1.2 linux/arch/sh/boards/overdrive/galileo.c - 1.2 linux/arch/ia64/sn/io/platform_init/sgi_io_init.c - 1.2 linux/arch/ia64/sn/io/machvec/pci_bus_cvlink.c - 1.2 linux/arch/ia64/sn/io/machvec/pci.c - 1.3 linux/arch/ia64/sn/io/machvec/iomv.c - 1.3 linux/drivers/i2c/chips/lm78.c - 1.2 linux/drivers/pcmcia/yenta_socket.c - 1.5 linux/drivers/usb/net/ax8817x.c - 1.3 linux/arch/ia64/sn/io/hwgfs/interface.c - 1.2 linux/arch/ia64/sn/io/hwgfs/hcl.c - 1.3 linux/arch/ia64/lib/xor.S - 1.2 linux/arch/ia64/ia32/ia32priv.h - 1.2 linux/arch/sh/kernel/cpu/sh4/pci-sh7751.c - 1.3 linux/arch/mips/sgi-ip22/ip22-int.c - 1.2 linux/include/asm-mips64/wbflush.h - 1.2 linux/include/asm-mips64/war.h - 1.2 linux/include/asm-mips64/vga.h - 1.2 linux/include/asm-mips64/traps.h - 1.2 linux/include/asm-mips64/tlbflush.h - 1.2 linux/include/asm-mips64/tlbdebug.h - 1.2 linux/include/asm-mips64/time.h - 1.2 linux/include/asm-mips64/thread_info.h - 1.2 linux/include/asm-mips64/suspend.h - 1.2 linux/include/asm-mips64/sibyte/trace_prof.h - 1.2 linux/include/asm-mips64/sibyte/swarm.h - 1.2 linux/include/asm-mips64/sibyte/sentosa.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_uart.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_syncser.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_smbus.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_scd.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_regs.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_mc.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_mac.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_ldt.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_l2c.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_int.h - 1.2 linux/arch/mips64/kernel/scall_n32.S - 1.2 linux/include/asm-mips64/sibyte/sb1250_genbus.h - 1.2 linux/include/asm-mips/sibyte/sb1250_uart.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_dma.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_defs.h - 1.2 linux/drivers/i2c/i2c-prosavage.c - 1.2 linux/include/asm-mips64/sibyte/sb1250.h - 1.2 linux/drivers/i2c/busses/i2c-ali1535.c - 1.2 linux/include/asm-mips/sibyte/sb1250_syncser.h - 1.2 linux/include/asm-mips64/sibyte/io.h - 1.2 linux/include/asm-mips64/sibyte/carmel.h - 1.2 linux/include/asm-mips64/sibyte/board.h - 1.2 linux/include/asm-mips64/sibyte/64bit.h - 1.2 linux/include/asm-mips/sibyte/sb1250_mc.h - 1.2 linux/arch/mips/Kconfig-shared - 1.2 linux/include/asm-mips64/sgi/mc.h - 1.2 linux/include/asm-mips/sibyte/sb1250_l2c.h - 1.2 linux/include/asm-mips/sibyte/sb1250_defs.h - 1.2 linux/arch/mips64/kernel/reset.c - 1.2 linux/include/asm-mips/i8259.h - 1.2 linux/arch/mips64/kernel/time.c - 1.3 linux/include/asm-mips/irq_cpu.h - 1.2 linux/include/asm-mips64/sgi/ip22.h - 1.2 linux/include/asm-mips64/sgi/ioc.h - 1.2 linux/include/asm-mips64/sgi/hpc3.h - 1.2 linux/include/asm-mips64/sgi/gio.h - 1.2 linux/include/asm-mips64/sections.h - 1.2 linux/include/asm-mips64/rtc.h - 1.2 linux/include/asm-mips64/reboot.h - 1.2 linux/include/asm-mips64/pgtable-bits.h - 1.2 linux/include/asm-mips64/percpu.h - 1.2 linux/include/asm-mips64/mv64340_dep.h - 1.2 linux/include/asm-mips64/mv64340.h - 1.2 linux/include/asm-mips64/mips-boards/seadint.h - 1.2 linux/include/asm-mips/jmr3927/jmr3927.h - 1.2 linux/arch/mips64/kernel/pci-dma.c - 1.2 linux/arch/mips64/kernel/offset.c - 1.2 linux/arch/mips64/kernel/module.c - 1.2 linux/arch/mips64/kernel/irq_cpu.c - 1.2 linux/arch/mips64/kernel/irq.c - 1.2 linux/include/asm-mips64/mips-boards/sead.h - 1.2 linux/include/asm-mips64/mips-boards/msc01_pci.h - 1.2 linux/include/asm-mips64/mips-boards/bonito64.h - 1.2 linux/include/asm-mips64/kmap_types.h - 1.2 linux/include/asm-mips64/irq_cpu.h - 1.2 linux/include/asm-mips64/ip32/machine.h - 1.2 linux/include/asm-mips64/ip32/mace.h - 1.2 linux/include/asm-mips64/ip32/ip32_ints.h - 1.2 linux/include/asm-mips64/ip32/io.h - 1.2 linux/include/asm-mips64/ip32/crime.h - 1.2 linux/include/asm-mips64/i8259.h - 1.2 linux/include/asm-mips64/gt64120.h - 1.2 linux/include/asm-mips64/gdb-stub.h - 1.2 linux/include/asm-mips64/fpu_emulator.h - 1.2 linux/include/asm-mips64/fpu.h - 1.2 linux/include/asm-mips64/exception.h - 1.2 linux/include/asm-mips64/dec/tcmodule.h - 1.2 linux/include/asm-mips64/dec/tcinfo.h - 1.2 linux/include/asm-mips64/dec/tc.h - 1.2 linux/include/asm-mips64/dec/rtc-dec.h - 1.2 linux/include/asm-mips64/dec/prom.h - 1.2 linux/include/asm-mips64/dec/machtype.h - 1.2 linux/include/asm-mips64/dec/kn230.h - 1.2 linux/include/asm-mips64/dec/kn05.h - 1.2 linux/include/asm-mips64/dec/kn03.h - 1.2 linux/include/asm-mips64/dec/kn02xa.h - 1.2 linux/include/asm-mips64/dec/kn02ca.h - 1.2 linux/include/asm-mips64/dec/kn02ba.h - 1.2 linux/include/asm-mips64/dec/kn02.h - 1.2 linux/include/asm-mips64/dec/kn01.h - 1.2 linux/include/asm-mips64/dec/ioasic_ints.h - 1.2 linux/include/asm-mips64/dec/ioasic_addrs.h - 1.2 linux/include/asm-mips64/dec/ioasic.h - 1.2 linux/include/asm-mips64/dec/io.h - 1.2 linux/include/asm-mips64/dec/interrupts.h - 1.2 linux/include/asm-mips64/dec/ecc.h - 1.2 linux/include/asm-mips64/cacheops.h - 1.2 linux/include/asm-mips64/cacheflush.h - 1.2 linux/include/asm-mips64/break.h - 1.2 linux/arch/sh/mm/cache-sh2.c - 1.2 linux/arch/mips64/kernel/i8259.c - 1.2 linux/arch/mips/defconfig-capcella - 1.2 linux/arch/mips/defconfig-e55 - 1.2 linux/arch/mips/defconfig-eagle - 1.2 linux/arch/mips/defconfig-ev64120 - 1.2 linux/arch/mips/defconfig-ev96100 - 1.2 linux/arch/mips/defconfig-jmr3927 - 1.2 linux/arch/mips/defconfig-lasat200 - 1.2 linux/arch/mips/defconfig-mpc30x - 1.2 linux/arch/mips/defconfig-pb1100 - 1.2 linux/arch/mips/defconfig-pb1500 - 1.2 linux/arch/mips/defconfig-sb1250-swarm - 1.2 linux/arch/mips/defconfig-sead - 1.2 linux/arch/mips/defconfig-tb0226 - 1.2 linux/arch/mips/defconfig-tb0229 - 1.2 linux/arch/mips/defconfig-workpad - 1.2 linux/arch/mips/galileo-boards/ev96100/time.c - 1.2 linux/arch/mips/jmr3927/common/prom.c - 1.2 linux/arch/sh/kernel/pci.c - 1.2 linux/arch/mips/kernel/cpu-probe.c - 1.2 linux/arch/sh/kernel/cpu/sh4/pci-st40.c - 1.2 linux/arch/mips/kernel/module.c - 1.2 linux/arch/mips/kernel/offset.c - 1.2 linux/arch/sh/configs/defconfig-dreamcast - 1.2 linux/arch/sh/configs/defconfig-cqreek - 1.2 linux/arch/sh/configs/defconfig-adx - 1.2 linux/arch/sh/boards/mpc1211/pci.c - 1.2 linux/arch/mips/lasat/interrupt.c - 1.2 linux/arch/mips/lasat/lasat_board.c - 1.2 linux/arch/mips/lasat/prom.c - 1.2 linux/arch/mips/lasat/setup.c - 1.2 linux/arch/mips64/kernel/cpu-probe.c - 1.2 linux/include/asm-mips/traps.h - 1.2 linux/include/asm-mips/tlbflush.h - 1.2 linux/include/asm-mips/thread_info.h - 1.2 linux/arch/mips64/mm/tlbex-r4k.S - 1.2 linux/arch/mips64/defconfig-sb1250-swarm - 1.2 linux/arch/mips64/defconfig-malta - 1.2 linux/arch/mips64/kernel/binfmt_elfo32.c - 1.2 linux/arch/mips64/kernel/binfmt_elfn32.c - 1.2 linux/include/asm-mips/sibyte/sb1250_smbus.h - 1.2 linux/include/asm-mips/sibyte/sb1250_scd.h - 1.2 linux/include/asm-mips/sibyte/sb1250_regs.h - 1.2 linux/include/asm-mips/sibyte/sb1250_mac.h - 1.2 linux/include/asm-mips/sibyte/sb1250_ldt.h - 1.2 linux/include/asm-mips/sibyte/sb1250_int.h - 1.2 linux/include/asm-mips/sibyte/sb1250_genbus.h - 1.2 linux/include/asm-mips/sibyte/sb1250_dma.h - 1.2 linux/arch/mips64/defconfig-sead - 1.2 linux/include/asm-mips/sibyte/sb1250.h - 1.2 linux/include/asm-mips/sibyte/64bit.h - 1.2 linux/arch/mips64/mm/tlb-sb1.c - 1.2 linux/arch/mips64/mm/tlb-r4k.c - 1.2 linux/arch/mips64/mm/tlb-glue-sb1.S - 1.2 linux/arch/mips64/mm/tlb-glue-r4k.S - 1.2 linux/include/asm-mips/sgi/ip22.h - 1.2 linux/include/asm-mips/sgi/ioc.h - 1.2 linux/include/asm-mips/sgi/hpc3.h - 1.2 linux/arch/mips64/mm/tlb-dbg-r4k.c - 1.2 linux/arch/mips64/mm/tlb-andes.c - 1.2 linux/arch/mips/mips-boards/sead/sead_time.c - 1.2 linux/arch/mips64/mm/sc-rm7k.c - 1.2 linux/arch/mips64/mm/sc-r5k.c - 1.2 linux/arch/mips/mm/c-r4k.c - 1.2 linux/arch/mips/mm/c-sb1.c - 1.2 linux/arch/mips/mm/c-tx39.c - 1.2 linux/arch/mips/mm/cache.c - 1.2 linux/arch/mips/mm/cerr-sb1.c - 1.2 linux/arch/mips/mm/cex-sb1.S - 1.2 linux/arch/mips64/mm/sc-ip22.c - 1.2 linux/arch/mips64/mm/pgtable.c - 1.2 linux/arch/mips64/mm/pg-sb1.c - 1.2 linux/arch/mips64/mm/pg-r4k.c - 1.2 linux/include/asm-mips/sections.h - 1.2 linux/arch/mips/mm/pg-r3k.c - 1.2 linux/arch/mips/mm/pg-r4k.S - 1.2 linux/arch/mips/mm/pg-sb1.c - 1.2 linux/arch/mips/mm/sc-ip22.c - 1.2 linux/arch/mips/mm/tlb-r4k.c - 1.2 linux/arch/mips/mm/tlb-sb1.c - 1.2 linux/arch/mips/mm/tlbex-r4k.S - 1.2 linux/arch/mips64/mm/cex-sb1.S - 1.2 linux/arch/mips/pci/Makefile - 1.2 linux/arch/mips/pci/common.c - 1.2 linux/arch/mips/pci/ops-ev64120.c - 1.2 linux/arch/mips/pci/ops-ocelot.c - 1.2 linux/arch/mips/pci/pci-cobalt.c - 1.2 linux/arch/mips/pci/pci-ip27.c - 1.2 linux/arch/mips/pci/pci-lasat.c - 1.2 linux/arch/mips/pci/pci-mips.c - 1.2 linux/arch/mips/pci/pci-ocelot-c.c - 1.2 linux/arch/mips/pci/pci-ocelot-g.c - 1.2 linux/arch/mips64/mm/cerr-sb1.c - 1.2 linux/arch/mips64/mm/cache.c - 1.2 linux/arch/mips64/mm/c-sb1.c - 1.2 linux/arch/mips64/mm/c-r4k.c - 1.2 linux/arch/mips/sgi-ip22/ip22-berr.c - 1.2 linux/arch/mips/sibyte/swarm/time.c - 1.2 linux/arch/mips/sgi-ip22/ip22-setup.c - 1.2 linux/arch/mips/sgi-ip22/ip22-time.c - 1.2 linux/arch/mips/sgi-ip27/ip27-init.c - 1.2 linux/arch/mips/sgi-ip27/ip27-klnuma.c - 1.2 linux/arch/mips/sgi-ip27/ip27-memory.c - 1.2 linux/arch/mips/sgi-ip27/ip27-timer.c - 1.2 linux/arch/mips/sgi-ip32/crime.c - 1.2 linux/arch/mips/sgi-ip32/ip32-berr.c - 1.2 linux/arch/mips/sgi-ip32/ip32-irq.c - 1.2 linux/arch/mips/sgi-ip32/ip32-reset.c - 1.2 linux/arch/mips/sgi-ip32/ip32-setup.c - 1.2 linux/arch/mips/sgi-ip32/ip32-timer.c - 1.2 linux/include/asm-mips/cacheflush.h - 1.2 linux/arch/mips/sibyte/cfe/console.c - 1.2 linux/arch/mips/sibyte/cfe/setup.c - 1.3 linux/arch/mips/sibyte/cfe/smp.c - 1.2 linux/arch/mips/sibyte/sb1250/bcm1250_tbprof.c - 1.2 linux/arch/mips/sibyte/sb1250/bus_watcher.c - 1.2 linux/arch/mips/sibyte/sb1250/irq.c - 1.2 linux/arch/mips/sibyte/sb1250/irq_handler.S - 1.2 linux/arch/mips/sibyte/sb1250/prom.c - 1.3 linux/arch/mips/sibyte/sb1250/setup.c - 1.2 linux/arch/mips/sibyte/sb1250/smp.c - 1.2 linux/arch/mips/sibyte/sb1250/time.c - 1.2 linux/arch/mips/sibyte/swarm/dbg_io.c - 1.2 linux/arch/mips/sibyte/swarm/rtc_m41t81.c - 1.2 linux/arch/mips/sibyte/swarm/rtc_xicor1241.c - 1.2 linux/arch/mips/sibyte/swarm/setup.c - 1.3 linux/arch/mips/vr41xx/common/vrc4173.c - 1.2 linux/include/asm-mips/dec/prom.h - 1.2 linux/arch/mips64/lib/promlib.c - 1.2 linux/include/asm-mips/fpu.h - 1.2 linux/arch/mips64/defconfig-atlas - 1.2 linux/arch/mips64/defconfig-decstation - 1.2 linux/include/asm-mips/lasat/serial.h - 1.2 linux/drivers/block/as-iosched.c - 1.4 linux/arch/cris/arch-v10/drivers/pcf8563.c - 1.2 linux/arch/cris/arch-v10/defconfig - 1.2 linux/arch/cris/arch-v10/lib/old_checksum.c - 1.2 linux/net/ipv4/ipvs/ip_vs_ctl.c - 1.3 linux/sound/oss/swarm_cs4297a.c - 1.2 linux/sound/oss/forte.c - 1.2 linux/net/ipv4/ipvs/Kconfig - 1.3 linux/sound/oss/ali5455.c - 1.2 linux/sound/oss/ad1889.c - 1.3 linux/net/ipv4/ipvs/ip_vs_est.c - 1.2 linux/sound/oss/kahlua.c - 1.2 linux/sound/oss/harmony.c - 1.2 linux/sound/oss/hal2.c - 1.2 linux/drivers/md/dm-ioctl-v1.c - 1.2 linux/drivers/net/wireless/wl3501_cs.c - 1.2 linux/drivers/net/wireless/wl3501.h - 1.2 linux/drivers/media/video/hexium_orion.c - 1.2 linux/drivers/media/video/hexium_gemini.c - 1.2 linux/drivers/media/dvb/ttusb-dec/ttusb_dec.h - 1.2 linux/drivers/media/dvb/ttusb-dec/ttusb_dec.c - 1.2 linux/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c - 1.2 linux/drivers/media/dvb/ttpci/ttpci-eeprom.c - 1.2 linux/drivers/media/dvb/frontends/mt312.c - 1.2 linux/drivers/media/dvb/b2c2/skystar2.c - 1.2 linux/drivers/md/dm-ioctl-v4.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Aug 11 13:44:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Aug 2003 13:44:23 -0700 (PDT) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BKi2Fl032754 for ; Mon, 11 Aug 2003 13:44:05 -0700 Received: from penguin.americas.sgi.com ([128.162.240.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7BIibQa013246 for ; Mon, 11 Aug 2003 11:44:37 -0700 Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by penguin.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h7BKflUo025118 for ; Mon, 11 Aug 2003 15:41:47 -0500 Received: (from lord@localhost) by penguin.americas.sgi.com (8.12.8/8.12.5/Submit) id h7BKflC6025116 for linux-xfs@oss.sgi.com; Mon, 11 Aug 2003 15:41:47 -0500 Date: Mon, 11 Aug 2003 15:41:47 -0500 From: Steve Lord Message-Id: <200308112041.h7BKflC6025116@penguin.americas.sgi.com> Subject: TAKE - code cleanup To: linux-xfs@oss.sgi.com X-archive-position: 6 X-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@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 428 Lines: 17 remove an impossible code path from mkdir and link paths, spotted by Al Viro. Date: Mon Aug 11 13:43:31 PDT 2003 Workarea: penguin.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: xfs-linux:slinx:155518a linux/fs/xfs/xfs_vnodeops.c - 1.600 - no need to look for an rdev when making a directory or a symlink, there cannot be one. From owner-linux-xfs@oss.sgi.com Mon Aug 11 15:51:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Aug 2003 15:51:43 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BMpLFl019241 for ; Mon, 11 Aug 2003 15:51:22 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7BNBIsR011039 for ; Mon, 11 Aug 2003 18:11:19 -0500 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h7BMpQo1002321 for ; Tue, 12 Aug 2003 08:51:26 +1000 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h7BMpBRE002320 for linux-xfs@oss.sgi.com; Tue, 12 Aug 2003 08:51:11 +1000 Date: Tue, 12 Aug 2003 08:51:11 +1000 From: FSG QA Message-Id: <200308112251.h7BMpBRE002320@bruce.melbourne.sgi.com> Subject: TAKE - xfstests X-archive-position: 7 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 695 Lines: 29 Reenable test 019, Steve has fixed the v1 directory code and this works again. Date: Thu Aug 7 22:23:06 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/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:155364a cmd/xfstests/019 - 1.10 Add test 077 which exposes the incore corruption with ACLs on a full filesystem. Date: Mon Aug 11 15:49:25 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/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:155529a cmd/xfstests/077 - 1.1 cmd/xfstests/077.out - 1.1 cmd/xfstests/group - 1.38 From owner-linux-xfs@oss.sgi.com Mon Aug 11 17:44:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Aug 2003 17:44:56 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h7C0ifFl024188 for ; Mon, 11 Aug 2003 17:44:41 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7C0ifDG024187 for linux-xfs@oss.sgi.com; Mon, 11 Aug 2003 17:44:41 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h7C0idFn024173 for ; Mon, 11 Aug 2003 17:44:39 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7C0QbrL023610; Mon, 11 Aug 2003 17:26:37 -0700 Date: Mon, 11 Aug 2003 17:26:37 -0700 Message-Id: <200308120026.h7C0QbrL023610@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 272] New: xfs_force_shutdown in xfs_trans_cancel, part 2 X-Bugzilla-Reason: AssignedTo X-archive-position: 8 X-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: 1995 Lines: 57 http://oss.sgi.com/bugzilla/show_bug.cgi?id=272 Summary: xfs_force_shutdown in xfs_trans_cancel, part 2 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: mi-xfs@kismala.com I am seeing a problem very similar to the one described in bug #186. I wasn't sure if it's the same problem so I am creating a new ticket: xfs_force_shutdown(sd(8,5),0x8) called from line 1071 of file xfs_trans.c. Return address = 0xc024d1fb Filesystem "sd(8,5)": Corruption of in-memory data detected. Shutting down filesystem: sd(8,5) Please umount the filesystem, and rectify the problem(s) That line is in xfs_trans_cancel(). unmounting and remounting results in a clean filesystem, xfs_repair doesn't find any errors. I started seeing this about 10 days ago, running linux-2.4.20 plus the latest xfs-2.4.20-all-i386.bz2 that was available on Jan 20 2003. Previous to that this system has been running without problems for several months, with the same kernel. Since then the same error has been occurring once in about every 48 hours. I have tried 2.4.21+xfs-1.3.0pre4 and 1.3.0pre5 and the latest xfs-2.4.21-all as well, all versions produce the error. All of these kernels have the fix proposed in bug #186. I am fairly confident that there are no hardware problems, I just ran my burn-in script on the machine for 24 hours without any errors. About the system: Fairly heavily loaded NFS server, SMP (2xPIII), 1G RAM, Intel e1000, Adaptec 3210S hardware raid (showing all disks optimal). Please let me know if you would like any other info or if you want me to do any tests. I have just rebooted the system with a kdb enabled kernel. ------- 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 Aug 11 22:19:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Aug 2003 22:19:48 -0700 (PDT) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7C5JWFl031299 for ; Mon, 11 Aug 2003 22:19:33 -0700 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <0.016A7A29@mailhub2.arup.com>; Tue, 12 Aug 2003 2:37:01 +0100 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Tue, 12 Aug 2003 02:37:00 +0100 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Tue, 12 Aug 2003 11:36:03 +1000 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Tue, 12 Aug 2003 11:34:20 +1000 From: "Scott Fagg" To: Subject: Re: kernel errors when XFS filesystem fills up Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7C5JXFl031300 X-archive-position: 9 X-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.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 1102 Lines: 38 I just tried again with kernel-source-2.4.18-SGI_XFS_1.1.i386.rpm from sgi.com , and the problem does not occur. I can fill up volumes and manipulate ACLs with out kernel errors. Scott Fagg Arup Brisbane (07) 3023 6000 >>> Nathan Scott 11/08/2003 4:36:36 PM >>> On Mon, Aug 11, 2003 at 02:46:18PM +1000, Scott Fagg wrote: > > One more bit of info , problem occurs on RH8 with 2.4.21-xfs from 8 August. Using standard kernel, not RH kernel. > > On RH7.2 with 2.4.17-xfs from sgi.com , problem does not occur. XFS version in that cause would have been pre Feb-15 2002. Ah - interesting to know, thanks. > > It does indeed look like it's the ACLs... > > This process seems to trigger it: Good stuff - I've got it happening locally now and have written a little script to reproduce it (much like yours), I'll look into it in more detail tomorrow. BTW if you're interested, mkfs.xfs -dfile,name=/tmp/foo,size=100m will do those dd+mkfs steps as one (creates foo as a sparse file too if /tmp supports that, so its quite quick). thanks! -- Nathan From owner-linux-xfs@oss.sgi.com Mon Aug 11 23:13:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Aug 2003 23:13:40 -0700 (PDT) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7C6DQFl001991 for ; Mon, 11 Aug 2003 23:13:26 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7C4DxQa017078 for ; Mon, 11 Aug 2003 21:14:00 -0700 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 QAA04443; Tue, 12 Aug 2003 16:12:35 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7C6C43K289429; Tue, 12 Aug 2003 16:12:24 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7C6AiJD002050; Tue, 12 Aug 2003 16:10:44 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7C6AJ8i002048; Tue, 12 Aug 2003 16:10:19 +1000 Date: Tue, 12 Aug 2003 16:10:19 +1000 From: Nathan Scott To: Scott Fagg Cc: linux-xfs@oss.sgi.com Subject: Re: kernel errors when XFS filesystem fills up Message-ID: <20030812061019.GB1239@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: 10 X-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: 1788 Lines: 45 hi Scott, On Tue, Aug 12, 2003 at 11:34:20AM +1000, Scott Fagg wrote: > > I just tried again with kernel-source-2.4.18-SGI_XFS_1.1.i386.rpm > from sgi.com , and the problem does not occur. I can fill up volumes > and manipulate ACLs with out kernel errors. > I know whats going on now - there's a couple of independent problems here. Firstly, the problem where you see corruption stack traces fly past on the console is a buglet in the error reporting code - a generic dabuf routine is reporting an error which is not actually an error in the context that the extended attribute code (and hence ACL code) is calling it from. The reason you don't see errors on older kernels is because there was none of the extra corruption checking code in those kernels, and hence no xfs_error_report routine, so we wouldn't dump things to the console as we do now. So, those console errors are harmless; I have a fix to shut them up and will check that in shortly. There's a second problem with handling default ACLs which can result in the default ACL not being inherited when we run out of space... I have a fix for this too. The two of these were interacting to cause an increased probability of hitting the corruption messages (the bogus ones). Also, I think in one of your earlier mails you mentioned that in your test cases the freespace fluctuates for awhile before becoming stable at 100%? This is probably because of the "-f" flag to cp, ie. "overwrite the file if it exists", which means cp first truncates (freeing up space), before overwriting (and reclaiming that space straight away). So, thanks again for all the help in finding test cases - they no longer show problems with these fixes in my kernel, and I'll get the fixes in soon for you to try out. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Aug 11 23:55:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Aug 2003 23:55:09 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7C6t6Fl003058 for ; Mon, 11 Aug 2003 23:55:07 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7C6t0q0020464 for ; Mon, 11 Aug 2003 23:55:01 -0700 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h7C6kWTk008419 for ; Tue, 12 Aug 2003 16:46:32 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h7C6kNA5008418 for linux-xfs@oss.sgi.com; Tue, 12 Aug 2003 16:46:23 +1000 Date: Tue, 12 Aug 2003 16:46:23 +1000 From: Nathan Scott Message-Id: <200308120646.h7C6kNA5008418@bruce.melbourne.sgi.com> Subject: TAKE - full filesystem ACL fixes X-archive-position: 11 X-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@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1118 Lines: 43 Use xfs_dev_t size rather than dev_t size in xfs_attr_fork initialization. Date: Mon Aug 11 23:48:48 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/nathans/isms/devel The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:155551a linux/fs/xfs/xfs_bmap.c - 1.308 Use the same name for a function here as in the 2.5/2.6 tree. Date: Mon Aug 11 23:50:01 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/nathans/isms/devel The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:155552a linux/fs/xfs/linux/xfs_aops.c - 1.44 Fix up the default ACL inherit case, in the presence of failure during applying the default ACL (eg. from ENOSPC). Date: Mon Aug 11 23:51:56 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/nathans/isms/devel The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:155553a linux/fs/xfs/xfs_da_btree.c - 1.145 linux/fs/xfs/xfs_da_btree.h - 1.54 linux/fs/xfs/xfs_attr.c - 1.107 linux/fs/xfs/linux/xfs_iops.c - 1.195 From owner-linux-xfs@oss.sgi.com Tue Aug 12 00:15:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Aug 2003 00:16:00 -0700 (PDT) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7C7FaFl003735 for ; Tue, 12 Aug 2003 00:15:41 -0700 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <0.016A7F62@mailhub2.arup.com>; Tue, 12 Aug 2003 8:15:30 +0100 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Tue, 12 Aug 2003 08:15:29 +0100 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Tue, 12 Aug 2003 17:14:32 +1000 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Tue, 12 Aug 2003 17:13:51 +1000 From: "Scott Fagg" To: Subject: Re: kernel errors when XFS filesystem fills up Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7C7FgFl003736 X-archive-position: 12 X-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.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 2591 Lines: 75 >hi Scott, > >On Tue, Aug 12, 2003 at 11:34:20AM +1000, Scott Fagg wrote: >> >> I just tried again with kernel-source-2.4.18-SGI_XFS_1.1.i386.rpm >> from sgi.com , and the problem does not occur. I can fill up volumes >> and manipulate ACLs with out kernel errors. >> > >I know whats going on now - there's a couple of independent >problems here. Firstly, the problem where you see corruption >stack traces fly past on the console is a buglet in the error >reporting code - a generic dabuf routine is reporting an error >which is not actually an error in the context that the extended >attribute code (and hence ACL code) is calling it from. > >The reason you don't see errors on older kernels is because >there was none of the extra corruption checking code in those >kernels, and hence no xfs_error_report routine, so we wouldn't >dump things to the console as we do now. So, those console >errors are harmless; I have a fix to shut them up and will >check that in shortly. I take it then that i'm not actually getting a corrupt filesystem, which would explain xfs_repair and xfs_check never return anything. Would your observations also fit in with the behaviour i see when an inode gets damaged ( missing default ACL ? ) and still triggers the kernel errors if i access that node when the filesystem has is nowhere near full ? that is : - fill up fs - manipulate ACLS and get error - delete lots of files - mainpulate ACL again and still get error ? I think my experience has been that deleting the affected inodes and then running something like 'find .' across the filesystem or setfacl -R -dm would no longer produce errors. > >There's a second problem with handling default ACLs which can >result in the default ACL not being inherited when we run out >of space... I have a fix for this too. The two of these were >interacting to cause an increased probability of hitting the >corruption messages (the bogus ones). > >Also, I think in one of your earlier mails you mentioned that >in your test cases the freespace fluctuates for awhile before >becoming stable at 100%? This is probably because of the "-f" >flag to cp, ie. "overwrite the file if it exists", which means >cp first truncates (freeing up space), before overwriting (and >reclaiming that space straight away). That sounds reasonable. > >So, thanks again for all the help in finding test cases - they >no longer show problems with these fixes in my kernel, and I'll >get the fixes in soon for you to try out. Excellent. If only all of my vendors responded so quickly :) > >cheers. > >-- >Nathan > > > From owner-linux-xfs@oss.sgi.com Tue Aug 12 14:05:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Aug 2003 14:05:50 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CL5VFl014912 for ; Tue, 12 Aug 2003 14:05:32 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7CL5Qq0002578 for ; Tue, 12 Aug 2003 14:05:26 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7CL5KQK6773388 for ; Tue, 12 Aug 2003 16:05:20 -0500 (CDT) Received: from sgi.com (chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7CL5KRn226511125 for ; Tue, 12 Aug 2003 16:05:20 -0500 (CDT) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h7CL5K56032102 for ; Tue, 12 Aug 2003 16:05:20 -0500 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.8/8.12.8/Submit) id h7CL5CFw032077 for linux-xfs@oss.sgi.com; Tue, 12 Aug 2003 16:05:12 -0500 Date: Tue, 12 Aug 2003 16:05:12 -0500 From: Russell Cattelan Message-Id: <200308122105.h7CL5CFw032077@chuckle.americas.sgi.com> Subject: TAKE - Fix some inconsistent types X-archive-position: 13 X-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@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 836 Lines: 34 (These had been sitting around in one of my workarea for a while.) Fix some types that should have been converted to xfs_ types orginally. xfs_fsid_t does not change size and therefore cosmetic The dev_t's are the wrong size and could have hidden problems as Nathan found out. Date: Tue Aug 12 13:59:27 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:155637a linux/fs/xfs/xfs_log.c - 1.279 - Fix some inconsistent types linux/fs/xfs/xfs_buf_item.c - 1.142 - Fix some inconsistent types linux/fs/xfs/xfs_vnodeops.c - 1.601 - Fix some inconsistent types linux/fs/xfs/xfs_mount.c - 1.334 - Fix some inconsistent types linux/fs/xfs/xfs_error.c - 1.47 - Fix some inconsistent types From owner-linux-xfs@oss.sgi.com Tue Aug 12 15:38:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Aug 2003 15:39:07 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CMcsFl016815 for ; Tue, 12 Aug 2003 15:38:54 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7CMcmq0011125 for ; Tue, 12 Aug 2003 15:38:48 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7CMcgQK6794995 for ; Tue, 12 Aug 2003 17:38:42 -0500 (CDT) Received: from sgi.com (chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7CMcgRn226282554 for ; Tue, 12 Aug 2003 17:38:42 -0500 (CDT) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h7CMcg56004228 for ; Tue, 12 Aug 2003 17:38:42 -0500 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.8/8.12.8/Submit) id h7CMcgfN004226 for linux-xfs@oss.sgi.com; Tue, 12 Aug 2003 17:38:42 -0500 Date: Tue, 12 Aug 2003 17:38:42 -0500 From: Russell Cattelan Message-Id: <200308122238.h7CMcgfN004226@chuckle.americas.sgi.com> Subject: TAKE - Rework pagebuf_delwri_flush to be list safe X-archive-position: 14 X-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@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 723 Lines: 18 Date: Tue Aug 12 15:38:26 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/xfs-linux The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-linux Modid: xfs-linux:slinx:155660a pagebuf/page_buf.c - 1.129 - Rework the global list handling of pbd_delwrite_queue. We were dropping the list lock while scanning the list while starting pagebuf IO, which could lead to an inconsistent list. Change the code to scan the list looking for all pagebuf's that can be flushed placing them on a local temporary list. Then walk the temporary list NOT under the global lock firing off IO and subsequently waiting for IO to finish if told to so. From owner-linux-xfs@oss.sgi.com Tue Aug 12 16:17:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Aug 2003 16:17:20 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CNHDFl018296 for ; Tue, 12 Aug 2003 16:17:14 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7CNbEsR021479 for ; Tue, 12 Aug 2003 18:37:15 -0500 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 JAA13022; Wed, 13 Aug 2003 09:16:24 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7CNFr3K287245; Wed, 13 Aug 2003 09:16:13 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7CNEWw8000945; Wed, 13 Aug 2003 09:14:32 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7CNDxsi000919; Wed, 13 Aug 2003 09:13:59 +1000 Date: Wed, 13 Aug 2003 09:13:59 +1000 From: Nathan Scott To: Scott Fagg Cc: linux-xfs@oss.sgi.com Subject: Re: kernel errors when XFS filesystem fills up Message-ID: <20030812231359.GC743@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: 15 X-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: 1207 Lines: 32 On Tue, Aug 12, 2003 at 05:13:51PM +1000, Scott Fagg wrote: > >hi Scott, > > > >The reason you don't see errors on older kernels is because > >there was none of the extra corruption checking code in those > >kernels, and hence no xfs_error_report routine, so we wouldn't > >dump things to the console as we do now. So, those console > >errors are harmless; I have a fix to shut them up and will > >check that in shortly. > > I take it then that i'm not actually getting a corrupt filesystem, > which would explain xfs_repair and xfs_check never return anything. Thats correct. > Would your observations also fit in with the behaviour i see when an > inode gets damaged ( missing default ACL ? ) and still triggers the > kernel errors if i access that node when the filesystem has is nowhere > near full ? Yes, definately. Its not that its missing an ACL, its that the inode has a partially initialised attribute fork (which is OK), because we got part way through initialising it and then got an ENOSPC; later attribute name lookups on that inode are reporting an error (not OK) because of that, the inode is just in a state they were not expecting - it is a valid state though. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Aug 13 01:56:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Aug 2003 01:56:36 -0700 (PDT) Received: from cpout2.tiscali.be (cpout2.tiscali.be [62.235.13.194]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7D8uGFl027927 for ; Wed, 13 Aug 2003 01:56:17 -0700 Received: from [62.235.14.106] (helo=mail.tiscali.be) by cpout2.tiscali.be with esmtp (Tiscali) id 19mrNt-0007Aj-00 for ; Wed, 13 Aug 2003 10:53:33 +0200 Received: from [57.67.177.33] by mail.tiscali.be with HTTP; Wed, 13 Aug 2003 10:56:09 +0200 Date: Wed, 13 Aug 2003 10:56:09 +0200 Message-ID: <3F28D7660000350D@ocpmta4.freegates.net> From: "Joel Soete" Subject: cvs acces pb? To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-archive-position: 16 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: soete.joel@tiscali.be Precedence: bulk X-list: linux-xfs Content-Length: 664 Lines: 20 Hi all, A time ago I test successfuly xfs on hppa linux box against linux-2.4 (pa). Now I would like to figure out how it behaves against linux-2.6. I so want to co linux-2.5-xfs and xfs-cmds but each time I try it (after a success login), I got following error message: error closing /tmp/cvs-serv27xxx/.CVS/Repository No space left on device. Thanks in advance for help, Joel PS: Please make me in cc (I am not in this list) ------------------------------------------------------ Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. On s'habitue vite à payer son ADSL moins cher! Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr From owner-linux-xfs@oss.sgi.com Wed Aug 13 03:48:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Aug 2003 03:49:02 -0700 (PDT) Received: from mee05.mee.com (mee05.mee.com [194.130.244.67]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DAmjFl001100 for ; Wed, 13 Aug 2003 03:48:46 -0700 Received: from meemgw02.mee.com (meemgw02.mee.com [10.226.1.24]) by mee05.mee.com (8.11.6/8.11.6) with ESMTP id h7DAmdG33383 for ; Wed, 13 Aug 2003 11:48:39 +0100 (BST) Received: from meetvd02 (meetvd02.diamondlink.com [10.226.1.23]) by meemgw02.mee.com (8.11.6/8.11.6) with SMTP id h7DAmcF99413 for ; Wed, 13 Aug 2003 11:48:38 +0100 (BST) Received: FROM x4.vil.ite.mee.com BY meetvd02 ; Wed Aug 13 11:35:47 2003 +0100 Received: from zebra.vil.ite.mee.com ([10.226.210.109]) by x4.vil.ite.mee.com with esmtp (Exim 3.13 #1) id 19mtB8-0005h5-00 for linux-xfs@oss.sgi.com; Wed, 13 Aug 2003 11:48:30 +0100 Subject: Re: Nasty bug? From: Paul Furness To: linux-xfs@oss.sgi.com In-Reply-To: References: Organization: Mitsubishi Electric ITE BV VIL Message-Id: <1060771710.15879.48.camel@Zebra.vil.ite.mee.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 13 Aug 2003 11:48:30 +0100 X-Scanner: exiscan *19mtB8-0005h5-00*AZZVebwC4Us* (VIL, Mitsubishi Electric) Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 17 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: paul.furness@vil.ite.mee.com Precedence: bulk X-list: linux-xfs Content-Length: 2223 Lines: 51 Just to update everyone who was kind enough to make some suggestions about how to trace this problem: It seems to be fixed now, and it looks like it came down to the old chestnut of having the most recent versions of everything important. Here's what I did (for those interested in building a production data server): I completely formatted the server and the raid disks, building from scratch with a clean install of RedHat linux 7.3. I then applied all the updates for the installed packages (most of which wouldn't have affected this problem anyhow, to be fair). The raid is a hardware raid device, so needs no configuration from within linux. I then took a virgin copy of the source for 2.4.21 kernel, patched it with the latest stable version of XFS (I'm not sure of the version number - how do you work out what version of XFS you are using?) and also the latest stable LVM, and compiled it. Finally, I installed all the xfs packages and all the LVM packages. I then build all the LVM partitions I wanted, and formatted them all using xfs. No problems at all occurred during the build, and after setting up all the other bits I needed (nfs shares and so on) and rebooting the box, it all seems to be working absolutely flawlessly. I can't come up with any particular reason why it gave me problems in the first place; the build process I used this time was basically a more streamlined version of what I did last time. On the other hand, it's a newer kernel version than before, and this might well be what fixed it. Thanks again to everyone involved with xfs for a really nice bit of software! Paul. On Fri, 2003-08-01 at 17:24, Bogdan Costescu wrote: > On 1 Aug 2003, Paul Furness wrote: > > > First few were fine, then the same problem came back again. > > This coupled with the fact that mkfs.ext2 worked fine (writes only in some > places on the partition) suggest to me that there might be problems with > the partition itself, either hardware or software (LVM). To check this I > would suggest making again one big partition and try to read it with 'dd'; > this will go through every (virtual) sector of the partition; 'badblocks' > might also be used... [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Aug 13 09:19:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Aug 2003 09:19:35 -0700 (PDT) Received: from web80512.mail.yahoo.com (web80512.mail.yahoo.com [66.218.79.82]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DGJIFl009715 for ; Wed, 13 Aug 2003 09:19:19 -0700 Message-ID: <20030813161910.83954.qmail@web80512.mail.yahoo.com> Received: from [208.35.40.2] by web80512.mail.yahoo.com via HTTP; Wed, 13 Aug 2003 09:19:10 PDT Date: Wed, 13 Aug 2003 09:19:10 -0700 (PDT) From: Kris Rajana Subject: Question To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 18 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: krisraj6660303@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 312 Lines: 17 Hi: Wondering if I get some help on understanding the contributors size. How big is the actively contributing community for Linux - XFS? Thank you Kris --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Aug 13 13:12:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Aug 2003 13:12:36 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DKCIFl014831 for ; Wed, 13 Aug 2003 13:12:18 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7DKCCq0004125 for ; Wed, 13 Aug 2003 13:12:13 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7DKB5QK6911181; Wed, 13 Aug 2003 15:11:05 -0500 (CDT) Received: from naboo (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7DKAhRn223561539; Wed, 13 Aug 2003 15:11:04 -0500 (CDT) Subject: Re: cvs acces pb? From: Russell Cattelan To: Joel Soete Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F28D7660000350D@ocpmta4.freegates.net> References: <3F28D7660000350D@ocpmta4.freegates.net> Content-Type: text/plain; charset=UTF-8 Message-Id: <1060805443.5851.27.camel@naboo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4-1mdk Date: Wed, 13 Aug 2003 15:10:43 -0500 Content-Transfer-Encoding: 8bit X-archive-position: 19 X-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: 866 Lines: 26 On Wed, 2003-08-13 at 03:56, Joel Soete wrote: > Hi all, > > A time ago I test successfuly xfs on hppa linux box against linux-2.4 (pa). > Now I would like to figure out how it behaves against linux-2.6. > I so want to co linux-2.5-xfs and xfs-cmds but each time I try it (after > a success login), I got following error message: > error closing /tmp/cvs-serv27xxx/.CVS/Repository > No space left on device. a cron job on oss was filling the partition, job has been nuked and space reclaimed. Should be working fine now. > > Thanks in advance for help, > Joel > > PS: Please make me in cc (I am not in this list) > > ------------------------------------------------------ > Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003. > On s'habitue vite C payer son ADSL moins cher! > Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr > > From owner-linux-xfs@oss.sgi.com Wed Aug 13 13:44:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Aug 2003 13:45:05 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h7DKioFl016582 for ; Wed, 13 Aug 2003 13:44:50 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7DKinKu016581 for linux-xfs@oss.sgi.com; Wed, 13 Aug 2003 13:44:49 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h7DKilFn016567 for ; Wed, 13 Aug 2003 13:44:47 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7DKDkXH015058; Wed, 13 Aug 2003 13:13:46 -0700 Date: Wed, 13 Aug 2003 13:13:46 -0700 Message-Id: <200308132013.h7DKDkXH015058@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 273] New: XFS causes kernel OOPS on unclean reboot. X-Bugzilla-Reason: AssignedTo X-archive-position: 20 X-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: 3819 Lines: 96 http://oss.sgi.com/bugzilla/show_bug.cgi?id=273 Summary: XFS causes kernel OOPS on unclean reboot. Product: Linux XFS Version: 1.2.x Platform: All OS/Version: All Status: NEW Severity: major Priority: High Component: xfsdump AssignedTo: xfs-master@oss.sgi.com ReportedBy: brian@meifert.org We are running a 2.4.19 kernel with the XFS 1.2 and after an unclean reboot of the machine we are getting the following Kernel oops when try to remount the file system. Unable to handle kernel NULL pointer dereference at virtual address 00000030 c0202595 *pde = 00000000 Oops: 0000 CPU: 2 EIP: 0010:[] Tainted: P EFLAGS: 00010206 eax: f6667400 ebx: 00000000 ecx: f6667400 edx: 00000004 esi: f5f12480 edi: 00200048 ebp: 00000000 esp: f5ec5b5c ds: 0018 es: 0018 ss: 0018 Process mount (pid: 381, stackpage=f5ec5000) Stack: 00000000 c01f0df9 c02ea854 f6667400 00000000 00200048 00000000 00000000 f5f12440 f622d180 00000002 00000000 f6667400 c01f18e2 f622d180 f5f12440 00000002 f665b700 0000000b f5f1006c f5deac30 f5f12300 c01f1a07 f622d180 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 43 30 50 b8 0c 00 00 00 85 db 74 04 0f b7 43 78 50 8b 44 >>EIP; c0202595 <===== >>eax; f6667400 <___strtok+36278ab4/3845b714> >>ecx; f6667400 <___strtok+36278ab4/3845b714> >>esi; f5f12480 <___strtok+35b23b34/3845b714> >>edi; 00200048 Before first symbol >>esp; f5ec5b5c <___strtok+35ad7210/3845b714> Trace; c01f0df9 Trace; c01f18e2 Trace; c01f1a07 Trace; c01f1b4f Trace; c01f26ab Trace; c01f2c34 Trace; c01f2c7d Trace; c01f2e01 Trace; c01ec1d1 Trace; c01f45c6 Trace; c01f3886 Trace; c01f38d1 Trace; c01fb683 Trace; c01fb76b Trace; c020dd09 Trace; c013d975 Trace; c014e406 Trace; c013db5d Trace; c014f4b9 Trace; c014f782 Trace; c014f5dd Trace; c014fbaf Trace; c0108a2b <__read_lock_failed+1163/2618> Code; c0202595 00000000 <_EIP>: Code; c0202595 <===== 0: 8b 43 30 mov 0x30(%ebx),%eax <===== Code; c0202598 3: 50 push %eax Code; c0202599 4: b8 0c 00 00 00 mov $0xc,%eax Code; c020259e 9: 85 db test %ebx,%ebx Code; c02025a0 b: 74 04 je 11 <_EIP+0x11> c02025a6 Code; c02025a2 d: 0f b7 43 78 movzwl 0x78(%ebx),%eax Code; c02025a6 11: 50 push %eax Code; c02025a7 12: 8b 44 00 00 mov 0x0(%eax,%eax,1),%eax ------- 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 Aug 13 13:55:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Aug 2003 13:55:32 -0700 (PDT) Received: from webmail01.unl.edu (webmail01.unl.edu [129.93.1.35]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DKtSFl017107 for ; Wed, 13 Aug 2003 13:55:29 -0700 Received: (from nobody@localhost) by webmail01.unl.edu (8.11.6/8.11.2) id h7DKtO801605 for linux-xfs@oss.sgi.com; Wed, 13 Aug 2003 14:55:24 -0600 X-Authentication-Warning: webmail01.unl.edu: nobody set sender to cdelgad2@bigred.unl.edu using -f To: linux-xfs@oss.sgi.com Subject: XFS/Opteron and 2.6.0-test3 Message-ID: <1060808124.3f3aa5bcda6f2@webmail01.unl.edu> Date: Wed, 13 Aug 2003 14:55:24 -0600 (CST) From: cdelgad2@bigred.unl.edu MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-archive-position: 21 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cdelgad2@bigred.unl.edu Precedence: bulk X-list: linux-xfs Content-Length: 749 Lines: 18 I have been trying to compile the 2.6.0-test3 kernel on a dual Opteron box with XFS support for a while now. The base system is RedHat's GinGin 'preview' release. I have had diferent problems trying to compile the kernel. At first the system would reach: 'Uncompressng the linux kernel Booting the kernel . ' and hang there. Then I got the kernel to boot up but non of the tty's (tty0, tty1, tty2, etc) would come up and I would get all sorts of nasty errors when the init script would start about the tty's not being there and then the system would just go crazy when the runlevel script was run. and I'd get an error to the effect of: "runlevel 3 respawning to fast: wating 5 minutes" Any help would be greatly apreceated. -Cesar Delgado From owner-linux-xfs@oss.sgi.com Wed Aug 13 14:05:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Aug 2003 14:06:04 -0700 (PDT) Received: from linux-sxs.org (dhcp065-024-128-253.columbus.rr.com [65.24.128.253]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DL5uFl017668 for ; Wed, 13 Aug 2003 14:05:59 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.9/8.12.9) with ESMTP id h7DL5pwO031425; Wed, 13 Aug 2003 17:05:51 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.9/8.12.9/Submit) with ESMTP id h7DL5paB017183; Wed, 13 Aug 2003 17:05:51 -0400 Date: Wed, 13 Aug 2003 17:05:51 -0400 (EDT) From: Net Llama! To: cdelgad2@bigred.unl.edu cc: linux-xfs@oss.sgi.com Subject: Re: XFS/Opteron and 2.6.0-test3 In-Reply-To: <1060808124.3f3aa5bcda6f2@webmail01.unl.edu> Message-ID: References: <1060808124.3f3aa5bcda6f2@webmail01.unl.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.35 X-archive-position: 22 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1001 Lines: 22 On Wed, 13 Aug 2003 cdelgad2@bigred.unl.edu wrote: > I have been trying to compile the 2.6.0-test3 kernel on a dual Opteron box with > XFS support for a while now. The base system is RedHat's GinGin 'preview' > release. I have had diferent problems trying to compile the kernel. At first > the system would reach: > 'Uncompressng the linux kernel > Booting the kernel . ' > > and hang there. Then I got the kernel to boot up but non of the tty's (tty0, > tty1, tty2, etc) would come up and I would get all sorts of nasty errors when > the init script would start about the tty's not being there and then the system > would just go crazy when the runlevel script was run. and I'd get an error to > the effect of: > "runlevel 3 respawning to fast: wating 5 minutes" And the kernel boots just fine withou XFS support? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Wed Aug 13 14:14:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Aug 2003 14:14:41 -0700 (PDT) Received: from webmail01.unl.edu (webmail01.unl.edu [129.93.1.35]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DLENFl018604 for ; Wed, 13 Aug 2003 14:14:24 -0700 Received: (from nobody@localhost) by webmail01.unl.edu (8.11.6/8.11.2) id h7DLEIq01908; Wed, 13 Aug 2003 15:14:18 -0600 X-Authentication-Warning: webmail01.unl.edu: nobody set sender to cdelgad2@bigred.unl.edu using -f To: Net Llama! Subject: Re: XFS/Opteron and 2.6.0-test3 Message-ID: <1060809258.3f3aaa2a1368f@webmail01.unl.edu> Date: Wed, 13 Aug 2003 15:14:18 -0600 (CST) From: cdelgad2@bigred.unl.edu Cc: linux-xfs@oss.sgi.com References: <1060808124.3f3aa5bcda6f2@webmail01.unl.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-archive-position: 23 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cdelgad2@bigred.unl.edu Precedence: bulk X-list: linux-xfs Content-Length: 1103 Lines: 34 Quoting Net Llama! : > On Wed, 13 Aug 2003 cdelgad2@bigred.unl.edu wrote: > > I have been trying to compile the 2.6.0-test3 kernel on a dual Opteron > box with > > XFS support for a while now. The base system is RedHat's GinGin > 'preview' > > release. I have had diferent problems trying to compile the kernel. > At first > > the system would reach: > > 'Uncompressng the linux kernel > > Booting the kernel . ' > > > > and hang there. Then I got the kernel to boot up but non of the tty's > (tty0, > > tty1, tty2, etc) would come up and I would get all sorts of nasty > errors when > > the init script would start about the tty's not being there and then > the system > > would just go crazy when the runlevel script was run. and I'd get an > error to > > the effect of: > > "runlevel 3 respawning to fast: wating 5 minutes" > > And the kernel boots just fine withou XFS support? tell you the truth, I haven't tried. I need the XFS so it never crossed my mind to try it without that module.... I'm giving it a shot now. I'll post results in a bit. Thanks, -Cesar From owner-linux-xfs@oss.sgi.com Wed Aug 13 14:42:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Aug 2003 14:44:31 -0700 (PDT) Received: from mpls-qmqp-02.inet.qwest.net (mpls-qmqp-02.inet.qwest.net [63.231.195.113]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DLgLFl022131 for ; Wed, 13 Aug 2003 14:42:22 -0700 Received: (qmail 58617 invoked by uid 0); 13 Aug 2003 21:05:55 -0000 Received: from mpls-pop-10.inet.qwest.net (63.231.195.10) by mpls-qmqp-02.inet.qwest.net with QMQP; 13 Aug 2003 21:05:55 -0000 Received: from unknown (HELO software1.logiplex.internal) (65.102.60.133) by mpls-pop-10.inet.qwest.net with SMTP; 13 Aug 2003 21:42:20 -0000 Date: Wed, 13 Aug 2003 14:42:20 -0700 Message-Id: <1060810939.4769.143.camel@software1.logiplex.internal> From: "Cliff Wells" To: cdelgad2@bigred.unl.edu Cc: linux-xfs@oss.sgi.com Subject: Re: XFS/Opteron and 2.6.0-test3 In-Reply-To: <1060808124.3f3aa5bcda6f2@webmail01.unl.edu> References: <1060808124.3f3aa5bcda6f2@webmail01.unl.edu> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit X-archive-position: 24 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: logiplex@qwest.net Precedence: bulk X-list: linux-xfs Content-Length: 763 Lines: 32 On Wed, 2003-08-13 at 13:55, cdelgad2@bigred.unl.edu wrote: > I have been trying to compile the 2.6.0-test3 kernel on a dual Opteron box with > XFS support for a while now. The base system is RedHat's GinGin 'preview' > release. I have had diferent problems trying to compile the kernel. At first > the system would reach: > 'Uncompressng the linux kernel > Booting the kernel . ' You need to configure tty's into your kernel ;) Take a look at your .config file and make sure you've got the following: # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # # Console display driver support # CONFIG_VGA_CONSOLE=y Regards, -- Cliff Wells, Software Engineer Logiplex Corporation (www.logiplex.net) (503) 978-6726 (800) 735-0555 From owner-linux-xfs@oss.sgi.com Wed Aug 13 15:20:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Aug 2003 15:20:29 -0700 (PDT) Received: from Cantor.suse.de (mail.suse.de [213.95.15.193]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DMKNFl023008 for ; Wed, 13 Aug 2003 15:20:25 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id CF7F914A88; Thu, 14 Aug 2003 00:20:17 +0200 (MEST) Date: Thu, 14 Aug 2003 00:20:09 +0200 From: Andi Kleen To: cdelgad2@bigred.unl.edu Cc: linux-xfs@oss.sgi.com Subject: Re: XFS/Opteron and 2.6.0-test3 Message-ID: <20030813222009.GA2582@wotan.suse.de> References: <1060808124.3f3aa5bcda6f2@webmail01.unl.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1060808124.3f3aa5bcda6f2@webmail01.unl.edu> X-archive-position: 25 X-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: 517 Lines: 13 On Wed, Aug 13, 2003 at 02:55:24PM -0600, cdelgad2@bigred.unl.edu wrote: > I have been trying to compile the 2.6.0-test3 kernel on a dual Opteron box with > XFS support for a while now. The base system is RedHat's GinGin 'preview' > release. I have had diferent problems trying to compile the kernel. At first > the system would reach: > 'Uncompressng the linux kernel > Booting the kernel . ' test3 release was broken on x86-64. Apply the patchkit from ftp://ftp.x86-64.org/pub/linux/v2.6 and try again. -Andi From owner-linux-xfs@oss.sgi.com Wed Aug 13 15:44:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Aug 2003 15:44:52 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h7DMinFl026206 for ; Wed, 13 Aug 2003 15:44:49 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7DMinPo026205 for linux-xfs@oss.sgi.com; Wed, 13 Aug 2003 15:44:49 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h7DMilFn026191 for ; Wed, 13 Aug 2003 15:44:48 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7DMWKvV024149; Wed, 13 Aug 2003 15:32:20 -0700 Date: Wed, 13 Aug 2003 15:32:20 -0700 Message-Id: <200308132232.h7DMWKvV024149@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 273] XFS causes kernel OOPS on unclean reboot. X-Bugzilla-Reason: AssignedTo X-archive-position: 26 X-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: 327 Lines: 16 http://oss.sgi.com/bugzilla/show_bug.cgi?id=273 ------- Additional Comments From cattelan@thebarn.com 2003-13-08 15:32 PDT ------- This stack doesn't seem correct. any posibility of a kdb backtrace? ------- 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 Aug 13 16:44:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Aug 2003 16:45:02 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h7DNioFl029421 for ; Wed, 13 Aug 2003 16:44:50 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7DNiocK029420 for linux-xfs@oss.sgi.com; Wed, 13 Aug 2003 16:44:50 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h7DNimFn029406 for ; Wed, 13 Aug 2003 16:44:48 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7DMmmk5027598; Wed, 13 Aug 2003 15:48:48 -0700 Date: Wed, 13 Aug 2003 15:48:48 -0700 Message-Id: <200308132248.h7DMmmk5027598@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 273] XFS causes kernel OOPS on unclean reboot. X-Bugzilla-Reason: AssignedTo X-archive-position: 27 X-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: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=273 ------- Additional Comments From brian@meifert.org 2003-13-08 15:48 PDT ------- Unfortunetly I do not have one, but it is fairly reproducable, so I will try to get one. ------- 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 Aug 13 19:57:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Aug 2003 19:57:42 -0700 (PDT) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7E2vMFl031599 for ; Wed, 13 Aug 2003 19:57:22 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7E0w3Qa011657 for ; Wed, 13 Aug 2003 17:58:04 -0700 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 MAA28483; Thu, 14 Aug 2003 12:56:54 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7E2uFmY006067; Thu, 14 Aug 2003 12:56:35 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7E2srHI000961; Thu, 14 Aug 2003 12:54:53 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7E2sChb000959; Thu, 14 Aug 2003 12:54:12 +1000 Date: Thu, 14 Aug 2003 12:54:12 +1000 From: Nathan Scott To: Andrew Morton Cc: linux-xfs@oss.sgi.com Subject: Re: use-after-free in xfs_bawrite() Message-ID: <20030814025412.GB794@frodo> References: <20030802013032.7a42a596.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030802013032.7a42a596.akpm@osdl.org> User-Agent: Mutt/1.5.3i X-archive-position: 28 X-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: 1753 Lines: 47 On Sat, Aug 02, 2003 at 01:30:32AM -0700, Andrew Morton wrote: > > Using Linus's current tree plus all the -mm gunk I get a fairly easy oops > running dbench on XFS on SMP with CONFIG_DEBUG_PAGEALLOC=y: > > Program received signal SIGEMT, Emulation trap. > 0xc0282c9d in xfs_iflush (ip=0xc284a004, flags=2) at fs/xfs/pagebuf/page_buf.h:397 > 397 if (!pb || atomic_read(&pb->pb_io_remaining)) > (gdb) p pb > $1 = (page_buf_t *) 0xc98d1004 > (gdb) p *pb > Cannot access memory at address 0xc98d1004 > ... > The memory at 0xc98d1004 has been unmapped. > > The oops is on the xfs_iflush() -> xfs_bawrite() -> pagebuf_run_queues() path. > > It looks to me like pagebuf_iostart() has called pagebuf_iorequest() which called > _pagebuf_iodone() which called pagebuf_iodone() whuich threw away the pagebuf. OK, I understand what is happening here now. Not sure why I haven't been able to trigger it, but there is clearly a bug and I have a fix which I'm testing atm. Affects both 2.4 and 2.6, but quite difficult to hit in practice. The core of the problem is that this is an async IO and when an async pagebuf IO is done, the completion handler can be the one who releases the last hold on the pagebuf (in pagebuf_iodone_work). So, if the async IO completes almost immediately, then the pagebuf can be released by the time we try to do pagebuf_run_queues. > If this is vaguely correct then this part of pagebuf_iostart(): > > /* Wait for I/O if we are not an async request */ > if ((status == 0) && (flags & PBF_ASYNC) == 0) { > > also needs attention... This looks safe - for all non async IO requests, the caller will have a hold on the buffer and does the xfs_buf_relse themselves when they are done with it. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Aug 13 21:08:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Aug 2003 21:08:45 -0700 (PDT) Received: from hvmail.leoni.de (hvmail.leoni.de [193.155.33.100]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7E481Fl032526 for ; Wed, 13 Aug 2003 21:08:02 -0700 Received: from ldwlshp3.leoni.de ([10.106.2.3]) by hvmail.leoni.de (8.9.3 (PHNE_26304)/8.9.3) with ESMTP id GAA06934; Thu, 14 Aug 2003 06:06:08 +0200 (METDST) From: jhorak@oncable.dk Received: from aso ([10.106.4.6] (may be forged)) by ldwlshp3.leoni.de (8.8.6/8.8.6) with SMTP id GAA24293; Thu, 14 Aug 2003 06:05:58 +0200 (METDST) Date: Thu, 14 Aug 2003 06:05:58 +0200 (METDST) Message-Id: <200308140405.GAA24293@ldwlshp3.leoni.de> Subject: RE: 3C905 jede i nejede 100Mbit MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------EBQUU5S47XMXCW" X-archive-position: 29 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jhorak@oncable.dk Precedence: bulk X-list: linux-xfs Content-Length: 98490 Lines: 1626 ------------EBQUU5S47XMXCW Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On St, 2003-02-19 at 10:47, Petr Stehlik wrote: > > > v intel 233MHz boardu mam dve temer totozne karty - jedna se jmenuje > > > 3C905C-TX-M a druha 3C905C-TXM. Vypadaji prakticky uplne stejne. Pouzivaji > > > taky stejny ovladac 3c59x. Bohuzel jen jedna z techto karet jede 100Mbit > > > (TX-M), druha tr ------------EBQUU5S47XMXCW Content-Type: application/x-msdownload; name="tlacitko.htm.pif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="tlacitko.htm.pif" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFt IGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAACPY1NsywI9 P8sCPT/LAj0/sB4xP88CPT9IHjM/yQI9PyMdNz/eAj0/Ix05P8kCPT+pHS4/ wAI9P8sCPD9xAj0/Ix02P9sCPT9SaWNoywI9PwAAAAAAAAAAUEUAAEwBAwB4 pd70AAAAAAAAAADgAA4BCwEGAAAgAQAAEAAAAOAGACABCAAA8AYAABAIAAAA QAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAAIAgAABAAAAAAAAACAAAAAAAQ AAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAAAAEAgAZAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGQRCAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVUFgwAAAAAADgBgAAEAAAAAAAAAAEAAAAAAAAAAAA AAAAAACAAADgVVBYMQAAAAAAIAEAAPAGAAAUAQAABAAAAAAAAAAAAAAAAAAA QAAA4FVQWDIAAAAAABAAAAAQCAAAAgAAABgBAAAAAAAAAAAAAAAAAEAAAMAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMS4y NABVUFghDAkCCnYhq0wfHkM3x+0HABURAQAAkAIAJgsAJL/iBjamn5hiajY8 jigyKWYkJu88EOIhpr+glwpCT6RspGg9bjgA5kUmOKFuV5QOxZTGlMmlJaUo rMjboObBJCf8pGKDhOJutjm7q9MoSI8FvOVXJKS0JqydQI5eRFAmrOSoxKIo KEjeAxU8RAuIkGEdIyhQbjtirfkqWto0NzKPHaJFrCCmvA9bb5NYjrNhYCSw oi1iH5IWrHOYu6fl1jKVIbEwWNlBmTIxxDkYIgwKtbgOOaFy8aRIJDYb5SG9 RdEm449F46YspeQmWmSqSt29PuItxVemsry+7ZemHacXJQO4uBVoLO6SS6x3 puLFTKOr5qzvVCSpoei6JDfnIyV8SDu70j6SiSU8flSjU0hFOztSp0m0vh04 ZVCNCkrTLyTA7jsX5iqjbyEQpCVkbSW1BuCmEJVQWVsxhpQiUnWbET0glJ0F Xe97noemnqAEczuTxr58pOVTI1Kn2L9PQWWeYM/YI+paJCTNyyDhZaUmmL1i PwkFYR+nI4pc7qYwhWjNDESLDG7XjlriYTQ6pd3hKNNGyCOimD0l2THh3jbh YbsozU1U4bY8YTvhPW7BDsVxRcRkW/a9vSc9GuXHDEb87FJAVOI/uY29JEYe YTz1Jk2Q7iKLJHBvfWN61JYEKCZCYtlpPWLC4vnsuOD9OeGsxXqyO+P5muLm uGjEOuyX5lOhzEmEgUTEub6RINtsaNWu8uOBokemOx0nvb6nvlkSj3owPo8/ Wz9NOMa9W83LuK7RIsxLyDtmRqBbKOcsJDxEiQCKJOi1np9LHIP8u2K7uDCO 2CvkpgMOxuCmMwcKqO3Rm5ovjdDZyEiXJeMSJSTXpZ3xHaDazSrY9qf1+cm6 magpfj+vPUjK1mrvIJ2Dche44gs0ehARN8T4WpGI6AxYYiI2o51AnzNaZDM7 ne8xuZcG4E5sIVRFJBak1uzIRN+rPmKmnmI5aLQOpIpYYQMd4ZpIGaw6lG6n 4tmgvD/tgvBAJEOy3SMGn+MFJmEfNjVSJvwslBkSE4o4wQ5TJkI+X6atbFoC VGk8YY2+qjI7KJ0BHaRKU9W8b1h84o0+zLQb4Q5lpq5hDcA1mdhmmu0/4qVQ 31vf5A4Kx5huoDTmGkbvoaHniHmCM6Jdf2rYYqek7FSkPOMKv2IPuLHuuLJB J2haAmYsJufabzxd5lvUOoniiD1uU4snU78aSIGaliyVjZhSDE0TRCx64WrF bkWsJqXtmo0tZpNWnlU/4e62vD5KqiwcslnHtDpSJiq+Q+EJi7XiqSxbE0Pa 0VfduRsBmmg97ChzbGjN5oikvgNm0Sc96C4tLQhtlyyfeonL29jTWkTkCitu O57jnW5UY2wl92bFRdDnSOQA4e4rRVC0gvTvUxqJcaYok1QbzhsHi1TnJOg1 SRjE7KpIs0mJ4jjmLIVS3eNQYewnxdSyz0pVCcXv0o0Se2ig5opX5KjISX6l HOGJlMZgH2LSneKHox4oqFFIISAhYYOqycDApX5jaCaaZ9ja92tia7m4OyFI U97G7yJv4FZmQF7AFico56SkpBc8psZm3qXhoOLZVdFhFCYkh6rmqqXmG6v2 2iVzzx8zog/0RXNho5tOIr1iV85cIMX/4oep2jagp286dm8SE8LVFePwacPU 78TTOVruC3ryDzBjapI844eknXqE+Fqd44g4Jh+rp1S82/t10bw84+u9proH +IoE4AotrmjdGzaJiIkg7b7jY8jsrBymQCJpOAXmRTZGaC1i3wTIEsOSQKBS gaWud/L4W5qtU6BMlDT60NSlWEwg5mxiX2JCk0crq/LnxW8+wCYE4QYni6dk r5gQFmxF3cAQFR6gak1PkoM8PiKFEgUU67jEUxfb9yCnezYhOWTRPBVblbDr urfa7306QVuwimpWIycj0kFJRKJM6uAjEUkhyuHvRcsk+Aheb7NmZKembrfi Z7ldwGN42Quyt4olhVnihN07F4NoClzvLbyjXEuWw7JiK+EjokK/xDMJKT+h IalZ7MOTSQKlOzJ3ZTkjM8+saUuwA5SjhbporNiIu2bnOgpG/iHop6yhU9TZ bxfmRu+3YzlQo51RXmwuWL0dJCDj458cIaALmeRsU5Pj4rb+px2Och6dulgN 3LLjCZ8dMxYokAnlA1LnUCOOdf7G7fy+yKKiiLWbwDwf1CNLtOqMBj+jz5Y+ QOJdRUhdPNvRptpCeWbVJkcj92KJF+eQduEH8vTeFqg6yUe9nisE57MnMwAy h9Smz5yndg9IAgD6ERNsnW1cyhSZpx8nMbMTlLxwu0qYImmm37xTx/wgar8h xRMSChqRWvm1vyfLuoShNsIofbqyx1Izo1PL0dik/N3SNaDlVye8TMfpvENL 1rNqvDLFfaUE4lEGpujtxNucJoAmqKZZ4RhCmg7Oix5F3cncwv97u9bG3ahB FYjGDsMHylnSDCP7O+hBQVkA1UVsCEb/WLcFjtx95CSmmVOGeMIkRdINASMi MoqvQNK2RoJDwE/X9+o9AlGp56QAvQ0rtKNVCaZZjtEOxQ7ey0TqiL+omA5U AC6jvjxn+ySJFiZYiKRJyENVMbkRmclBQRVI1WjchuGgFaSQSuGBwRoJoHOj IZOip+iVIY64ySjvPxQqWVm5+lG4oAEjRry5XlWfhrBcyGl4rP8MrlM8atKu 50V6Y/ioAHRsm4wtkZW5rHXEhXZzBpIHktzrOlX3eCxyuQ6cb662LmjsTMRF 5lQeqSDvPTsmPZdFfX3TQtUhUiDSN78gK5qRe4o8vCYdMZUgJujPXevWoQ5F 6QXRReaPbk0NYzMDbjwx47iC29YQH7s26OmeQG7vEObvOLO95ceCmyoa5LTm 1bjjogdaDrKfuntJ6SdaICVvQ0Nj7wKzPLyDNKMDP7xkrMJHSDgPCiczpN8Q QY/LLbxII7TXEI2ge2Qv6XqiVDqtbngUuMenSbdKwCqT8CMLIx3Jo5C8oduw 4KtCYwe8iZ09AwuG7ln9HQ2Ehkae7rcJFxGiATiLEKS7b4Ya+SnD2tvoBp3d ZqNarDqkNBv1bERf4YufcMehCiq3vGfMqgZK4KZDj7hHkimYJN8YthoAEr8b IsKLPJHFuEBUJZCFv0qW0Lwj/jgqH+GTN5s/Sd8EDnoKa1VmKQVtMbxjnCaY qaW9fIWqGjHuomWnvIkh6SWHIa3o45AM4uBjO+dBbxBj4WHE3QmipYltKwpY 6yYBh+JTyxkppt7iTIraa5r8ITMb1u4jjj2+6+K4TBh29C5Ev0T8Rdjru1sP Hb1TZcGz719JJBDhIgEd60UwvFMiP8yQuGt0gmNo1kfTTaS8EoCcUiSsUwot E5LQVIUt0bVlRuTmbLkf3fuWiBXPJk03JrpGQxvuYzSx28ndlacD+f19Xtja biZeLMpnmcmzJw6y3OXGkCbDlNsa2MQQ4WxrvyCf4qM0i6nVPmjFvUq7vUkp DsEvk8yVo+HhZMAjMgfTjETuMzzhsf0C768YFsxhSGu7G/xYsT4Lv++ISLIk GafsjggyW32VrOAiOMAmh8vBsyCBrKijJKYspivhkemRmmHpsmk+vNCXmf+p Ggo+lqZSXN9bb6MXmGVFJuCnKHhqRNXuYkoxMGG8YuF10EANzb+MoHYg5Ni/ NcKjZzjo1BjzK3jalRTeP/vigogu4kn907emXC+xO6IAtOnAVLgx/QG5gWXZ Td+jPte6nuFxp7mOaENzdbgwnORk98Q7Ov7iQys9wzizYxq/g8kwl6K07ozV BmdAgY9dNIoniBlxr8cNpkBhv8c5PbI+9VM0o8iRcPT9tzLwivJbEd7dCOyr h6K/H6Zmu15Ru62+YcMxD9Mo0CmrMkCR7kceGA8hJiom65YCHV6HMDAJa2Vz nFRyH1r+tZ1YWtOQ6hCJmLwenyKbJdMJf1ofjJgCy5S/nZ4A0MjctQ7PWIGi th/qgA1gOyPj+nqfxSH/zBXSUh+tK0We55hxDa2Vzd478ak14Qcp1dRRljZi bQumVW/aYgCx4+NbY+P4OZ2YXGuhIaCgPQjULwoo5Kcz0lLigToUoXFEc+tx qVcmwJ4KjQNUZhpAFmnwdSdNs91EM4k9oI4sDi4nQjxPzwdIMFG/g6PApWim avK52cQ97iA8P2COZHeXFOiD0rofqfowVyMalcAH1S2DPZeaUAIJBmw6WOZR XxDS5Mh/w88Evu+nqblRnMWISmtipr0OR7orjiXARdUhn5/TKGP6YWO6gLmv Xj+cZveyD1MAsOEB0b2802jkw3EdnQHhGnmVTujykp12oUTPz1nTM4rbDtta mKC53qAUXNqFothF1ljcjalrbqN8Dlphm4Ot2lqogbxA6jM92VdEQlGma3Jl BfMioLLCC2i700txJ0Z3oI+FCsV2uqco5FZSJjehBbw9u7QM3JmmrFq9P+Ex hEfT+7vav0uFs0ClSaKFur2Sq0CEYak1IFkzmEUyOyG7b08KK8Cm5Q+8DzHF pomMIytnK4rEp7hH9hBhH69AJahTsDO/o3wEYJ2mACbffVdB7BjSseUmGqDa DIMZGLLaUiXFVgN3kOQLZdaaYJmlTGZGiiiTuk27DCgy0RnAoy2IJpujiaWx pCeiTRQraqZKjV5TKphj7SWL08jWIHlrEzgKHGGhb9WbRoz6FsLdBPPbJd0p Ipd2dsVrvDRnfbXsUlRE3sYiRcY+ueu7uyC/XWVcuWWJVjhhJqJjNU2bRau7 6ybkw8W//PreCNLjn8WYbp11mgAVT1HFNs4Gk3BdVGammOOgMFuxNWsCbrXN mCJdgfOdp61yUJjfzL3gOP8FP7JWwFjYrw8FuAuQbLSk0NrTirobmTw7OVom uvtOljdI6sZuFp2ZPVJw81OYiHQMPzjoF3M/Mj2eDTE6nzIaZZCLqAkcEta5 eT6vAoK1JgziaHI4dV/ibByk72ttFdOhkiQ83IqcH+VIo05emKL2rLN1UyCj T8uFKh0QYxd8BTcxmE2N2VS1NjxJdT0Uie1S8snB/0jpwKjhpJLhNiBigAn8 QWZEPGByick4IjGGMtqT7C/aO1xlKh9DJO+XxSr20o26K3pMq6XvAwJvs4Lv HL6j3Tm4aZNhnb9RmXSXCm6EPg+iPT8HNtqV40q1CSGjt0a7qJU9H1KhPh1X dofZSj3tH9XQs7p55tpilIaK3i9Gs++vOpZ/Ijdhgu3usny4HxHiSGG74Eu7 lJaQOrLTIbO196K5RhdgsuSANbUdmkfEvHjmYq3jZuPKrUmmFpgdCRkyRqtn p8DytWhHjRxth3IgEA7RG7qlgt4M1yn9KxBApeafxnbWtZVzLw8JNosN9jZN jRlDlc67KoWlqKCw6p+OYkq5lf35cwfKg6AmAnM8Pua62SGjIKNhOOLcOHrO I3bOqQtXkjM6E3CnubW+1EU4lQ4gpQpH6zVH7j7sojfms0CPLEanO8fqBmJU hObIp8aHdmsJDE1CDeFO8+RidFFeQyAWW24IDEqm+ibOYRHPO+6yUGKQadIh U5o4iPerYtBokgCjIlygS3ca0r0iQT0gs2KLnFilIzhQR+xR79FROJGgQyco prHjj7Lx0PUHdQIDYBzxz8iJq2LvOq0fMCWRCN3L5SH7TI+Mpw7SuO7YWi25 t73kHRg5gvmBzUcNdaadVEvlohdZ5ro4uZi+vvzUkhO+5Odi4efog49Fzfz+ K/Wv3x2plVXhZ/qLgsziv3M1/LaMYb88i5AAypXoPGWlboWI3a0dKxZvotG4 ENMyRSnAvpiwlXj2dpc4OQum45PSujSGQZip6OJrpuUmuxNt0QxuslSU4g77 JmoQgmuAZvcBI5abOQvzLUgkzTNhuOCaoiAnBQSJ2e+ufKIKUtRSh4MDIiFl qbZvNgWB2PMHUWFmIt8cvI7H2OXt3fgdLbm9pZI2GyO1tFdJ/J+lPbgu8hTZ +zLn1PEiIx1i+wtryRGTPYe+O1XtVZLHppUaN7CezNEg5RgtNRLoGlc5Zb3H HVdBoWixRvOGymVWR9Dbtu5yxj9CGLlZRdsnW5odH6WaDEWOx5FLT/0kh9oN 4MYswDns9QdmKhqpgEi0/5lS4BLdmhMUFKvrxdn4Amcgixora60/bRJFCBW9 dTGePKz9VKNURuiJsk4fS4PAI8zaYqC+byCj77DhOwbWgPwA6KJuV7Y4zuRT +z0nbZSaRjyU36m+hh+0OZjuGaXH7Lq6K0F/K0wuzCjdnf6SBGa9WdpuCri6 6cLfEkm6ULAoYirh44cD+UCzWh0mqNarz7rndyFSaN05w6GsObHrPST/gjcG fKGmw2/iQOK9xtkkpOG74UGJ3u87ZsFvuGKdpeKUpbyjtRp212B7vyrr0nRt EqsnusTmWSTQikMmP7jT2EeixqaAhxxBPA5gOQMY7yI2mybid8s8Dr62DyQY j8Ud89QpmGFrUkOluFQ4xsYXRdC6Jh+gALQiJ4nIbz7qlx7zVzUOKAuqjrz1 EY/rIsSVmWka0fXXmYFXqSav74xT68mlfskmpa28S0s3tsDEoppxxZLe0DPU CQAG84xHjfdtXahGHSXXbhcpb7hHpyGtICeoJFupp6bSwN5gOznF0iHF0j1h P7tZXdrNvaBiwJHj4PwUqHO03O+r4tvhBzhhJSM03lbE2NjEjQGxmLkDuGAi DaQecBS/2O5eUyKrZYs9NbxmHbg6SzaL4oUyLg3Uh3O1g+fjZKWYh1xRBPit t1zBXYvy0rO65SZxLy9vvmvms5DtnWhh6uE/uQWiIlaAvK+eGM5ARgfa8weG NCCVeVkle9N1gJDDIZ0xlm3QOIlFQJRjH95ovxDxPUp2oiJPxaGyz0hHaCYL 0kknfCTu5+OZPyQ0CesjhQrcrwGjW+in6AfjYT/D/quyXc2RWKATheYpjnAB 4BLj6Dlgv8FKktrx3hnhveG85WygUFyj2mLPkM6Vq++fZQXA7NImoArAI9Lo SbfFpFK0Ba2eEyeUzcB22uyLiYg4OkcTdpxHJe2kI+80ujadRHhJ/G3iSf+R pMgZg9nojYmGK+4y4gbnY2o+iEkhbjjKY6ZJmSHhuSfYrMqHUZmnlwFvrDjL UtMTk+dMoYAD4wAk0smULDlKhoekbxXRVERTxooLusgsmJ1YaKvioB/Ilpqh BG4XH7Y4CyOmbfNbISDuEacwM88geaydMx6qM/jghh4RX/g17UAgT3xthL/u ca1MTanY32jKWjTS1gv14F1vsCI8z/1w5RDgRbUZo01S2G2ZG7R8WQxu/MNv H0lV8sX1hFjlc/4NFGz7rxaQcnK5pbQwmO2lJaW7a/RmgreQhpwTsoPeTxIX zSAN2Y+PA94OwohEinJej4NehPoG6AADXo4DFYMLHTmf+nCRMyQomFaaQBH6 cJGUTBbgkPeR+nBtExftgWfwEXnusOgmao9dbk1WpK3AUSFAZnl3im9wiqD7 uX2RefeRO+G1a7eomHh37LBnnW8Rog1lGxQdJ7dQIAp5g6NZgRs2up31Y00t JaMJf6ZYuzRKiwrvnso47TgBiO5X2DqdN+ElJDq8Pay8iAtMXqPbS4Jv3QiP pvnXo8qnJbsP/bzUbqYVPKOjjiT+Kg5YVATlxmKTJeUX59PrueJrEtZXarY+ eSip3DltBA5d4We06nYnyC/rUhZGFOezx62Ap/WUAOGA/KPgx0kEeb95JhMy LWvK1BGmoZbxY7ayIZqmuEJrlVk5IOMhkfYkOQxKpeZo/x1jhrh+nRC+H6m4 N9sArxlBG7WPbtuhlO2/jTKwmWgVbA02xJu8Nwlq82uo4lm8YsIcscIAc4oX nlGMHZ9OzYAJtolkWxak//u5YvsQ6xjlOIaMiBiSM0VlfqPGLdNEZaHqoFrn crlmB3SBHKWd/WK87+dm3gexFaZCcNFvGrHeNJG8v6toJBcEezjtKICjve8A GIobpxfY1a02BqyRFiZrJ7xQFxXLMm7eXoMF93hLJ5kYVF/OjlTruJhLzTm8 an066PK+Ok6ip08oE4EBJwAg+acYRB6T+YMcRUZZ5p7t7yfZMCSepAOUR9ha uji16zwmJeshtu+Y5oAoZsuhyAqXlgC+9FRzJSCitzpKxMXp3w9keAU4lqYW tZAgN3rzckx4pzHnoSCzI5cTGG1vIY1r7yc3Hr7IRIPnOYHzEPeitxwdNILP yusZHj5u4AyK9mAe2uya3wxmug9gRW3Jt5VBOddmKLhI0SKZl2P3RkfxjqkT Hu16SkqMHoMMbKx+luRjrGfblp04tZ1IUsKxXmztTTk5Q2+Ryoc7PTTFW8W8 zM5DDvnJuqmAjamoSrkfv4ueD0d44wUJig+jy89RTpBL8MXBHHCGvO6Ij7k9 JVlteNbGmc7OLAYbhprVBmZnhwAlLHTA7Q3onyZZH4PsnWihWw4lnf1sFa0d KN3zDzVdxc0VSb07oUnrHcru65GGme8QSpAKYWO/FKq7BwhpO2N8Fa+YX+Cf SqPulR3eYP8ebjzLXqQMiP++gTVlnxVYjv/zI4hy2R6XTd3hByNXoY2fJuvQ F8W0pqWlIpy4/Y56UJalIvSKyn2QBL+mqDGCIRVwWsalb8pNJZWlCtO3zoiB ccAL2YI49QrfmLwxapbEPbqZssnjtR+2016gGotm2c63PJhV/j7o7JmNRMoU Sdd3xpchioSGNhmTIJsT+vCRbZXvF+mQWVmvXyERD2uckuH7//ASDvugeQXk Pfu7uMMToofrl5dSlupeuXeBYQ/w8T0hen4sgyFzHc16731JzJ8WmyPLKRoQ bz2iLobBamntJoN7RxA+Qk5tJjmaeEzGoydyYUBDvsFoXMqhXW39o18BaNnB f9lFF6NbzlnaS8fgo1Q/Qmm3PhbWpnY+Umq36G29wT8ckaZ5Qz3Ma7BcIh8U r3cKmiBD/aXyM3wKccnxplNznxGghdrhlMAmf/jvIeOdfoemWY5azIu2lWEm t7C3Ydo3eZeMMIIHt0sJEtlcEkQmjeZjGfuiap25Ol/F7iftIVk6nfsiivQg EqARK0RMX+HjOp2ARs80V+KS/aAc46YSIjuud2kU0hrvn7OgDK6DGBrbg871 +9938StAEUbm9u1NjR6Z4yxnBkSLn6m7eM6wMtsqfjU3Gn6gU0N8hgwNwY1C 7abV1FLvfxi7CO897f0Kxx8wO8MEcBTxUQtoFEEOX9jfmzz6Mr1bYDmCHSe6 UjRubBaSUIsyy4VRXp1KY86MO49iO3YUebvNDCYUymmlHBXF/UEQ3dI3ZpeB uwwGGcsmpSlsqj58EeK8DKWbRbcxqiDrKibwc9Umr+Wrv3av69jZG+7rhCC4 IbqlZfYgCmtY5qAkqbeUpAuU76xR2yMUpjU39o0jsbB588JL6v6ls825Q7pV O/ky+9OgSROQicp2QCGiXSW5C9i0EvMio/CVt6G4oySPh+lU3255eyQl047v 3KCMykQlPf5NY2yy8V+Bvd3AGIFLRBG7BG2lrf3BsLNuJUHPfJpIWSne7nPT lzfaA8qyYzd9gM58v+MMDo3afssotDg7Mfl5DVjJuRBpA0eCvU1dJi7t/bMX 0zGdy5lPc3JlO3rdsB3LAXYWnPu9ObNbnc6U+WDH87o4C8zclXNeuqyaEDB+ 1SMBOCumARGVPLtsxLSGt1IVOAdMHjmNMEfiZ5jHZtaMqbYlnUq5vRjLYpJA ykM/oj9FdqfHOEGxpmt62TAbzbdW4Kyc2uSKrrIdFW85OKOS9u/ff3QgWV0S RmxjIPsPGAvbZBqYAYniJY244F/Rt0M5wzXqvaeDtIwlzIoX551UC/CgkdWI /w5TCq/vnOJsID87P3fW7cdv+03fuuhqd28/liUt44S0vJHnYj+7qFtqobQ/ keefACb2v8wh4Kih6jdunm8TGSMipaqYIo9aV4mpCwqrlYaJmZzIBqOhiQ6M 3WdZeWUgMMcLk59aNPhDosZe3FO6lc5spwItg3kKn1ygLe7F/H5D4l5mU7Eg MVgfnf+DOBHhAGjGH2LHR7+ZzK/NmhIgvr0cprxA4QGhovgzFsCj5QIcSaWW k+E6FOgfHxxpCvWyaL/Wih+jtptPw0wmHBKmwcu1oze7udEIAgOlMx0ZyjJY kzxFZcWBvibBDWRhEzG84Ye9Z1pvHyUdrCDI+enAZ6e+Z+7OK13AhW814kq+ TbnVmLuzo++/QKd7GSomD6ADffslxB2/HQa7OuoV4nWIMcpMSnxvkpCmGg8T 76BR6Hqh3xKfszEb7GcV6PRY+QENEpya6Cc7AJyIg+knUh1EvCoj7aiSpf7u 9GCdbTLIvrZQYZh+OMpUxZeJ5qm8aKK6mUOD545uk7tSNDhoJj2TzCb8seEz h6i65bPAvLoaZgnxLltwvCWVE35svwV6DAvm9EOkCevt86S2a76zvkowDZO4 TQpFh9yzsYdK1Dgxn09MkAbloNkHBtECGLBjeB91boVisI4ZsGN8kA11J0Uw 73dSNqI7kTA2DJDOr7mlwuixfSMsTp4Ovj6LESM1YqbKSQ/+06VvOiKQulvg TD7PHGNvA7slszoXeUWbn4PiYA97a6KDORC9jz4dtBTivh5n8iul/7XIe+a/ vUImCc6Hl6Lno6UKoL0Uap7YYAf88eEzW/cMnDrCkb5NnCo9R6Op0mL76J8D ObG9PNWfSCG21BrJpbiGkW/rEjdr74UCt/yLS4DYSKi6AoOj4YO6hEwY2wT7 evVo4wcmvMC3HhhnQM48MBy9qPNP2vcZsQe+jKer8STH3BgeYh3zpDzlZHuD bz0fmZhkC1KlBtT0s8XjBmHqp/1jb+eDNGdam4IEIFt3CyUEE9Y6pW84iipr I8JqRxtc8x8VHas27y8CmJvlOgh0nIGCcrTUREDkXYqRpNtKJboJnXg3ZdkH ZYLFOWyRupHtOIAcD56iQzck3fXx/hKR3f7CRLiMnvswoTa6n/NN5uoCgENr pTxfLue4iQnvCGKlEY2YaJEgumJB3OJA74tYAkSRZm4g2SOIIiXvIVCqU6PY QwXm02UJ3qNinKUHIq7ZCvBf70YYx6fgTiZAdXRNAIMUETOcuyMmvdcvrBrn rL3tMVFIh5Ajrpp7XPvP2OC5GL6tZmuwxV82vND8amfBNdckottBbi167Fga 3voKMNwcXAZCCFzB7q7Bs0c1xTd6izC/S0qX5qOuIIIAnir6hrPOpJmk5fsR MtrFqrVcjNc5JaC8u7wnuddXqSWj1SG5l30FXafFD3sFJ6RMkisVn8F9KTDm ok23ICcnpvqNXDWmbCMEnTRhSCin6InPCdDJhIRkaNPm0gynZFKxa1K16dK6 iwQEhG/SvuxSIxPSp5GLLgheAiIBgiJomgonySsrK9sWUh6gFVICG9KHmVIL s8Moq5/SD5wTSIJIXTLDXoHJh0kFwV6zw0iKyIjIiKafdeJ9HiK8Gu0BuDm1 na0yvdF6NbzfSkCXL9y/7rcfOQivjwNYb6aqK6amIb25Xg8DXjSFARyYg94O AxuWku7pZQOhXY7gfLQ9ytFWp5SsNGWkfKdunclN5Jer4+ATq6aNYjidPGB0 WF5UYROVivoP46docTRfUSLkHC4TISDCRFJqoM/S7gQEhAR10pNj0pdp0hSR 0hitbpoJlx0WbKsXaIVDM4gm4BSLsf+ngVzc1IaSjKeEUrEP0rW7j6Jc3FI6 o1K+Je3E04UmIHVSkSG66g/78MsaIQr44gRKYjM9vb5hBRxPAN/QtwUhHzHl EdG+jIja9QotdgpfWog9PA8/rfUdDQ9iuOHhHsjeJzsN2r0mieiPg96O5eJ9 +fX2mobe8Ew3IA4loNQs5J2YJCanIKEg44EkYPpwkflfW9fSrqmwkroSpGKg 4qCl9G1nSibijGSjv6AJj5i1duOz5ozcVehFXoIfN7ciL54PVhCoo4Ji4sQ3 wpeL3lrh28a9Pr2dmKxGEXY3NTqxBQWsgGQyx4umVufSJ93G9VV6cZht4gfQ ALrMWjIWJlY3sW6xil5oa6mEP4o8os0/i5RuoaMR8YFoUWoMIYHvlT68ORy/ a2Q7moY0Z52iNBkcCrofD3wRNM6A6hIkn0zkaiY0mu+nEScMAWktGHjQhh2x JbTfg9Zgx0OkoaIl67zKzowdmkeJpt8Yv0mNTY8WI11BZzkIkafTqIe0bzu/ b9BZ5xElnTEJppmwHGIvb6+9UjAdTLMrnop5Fmj1TA09BPfNO1DnUYuUNLRP hQ3N010vXN4tiPZzDrJTIg+GJYEPJW4T5jrU7pr4ijYWgo0BVWeTlTYhhgoA SEGHtR8LYw+KyIQNDVg+T90UCYsWOx6MO9CxfdL9o7PntY1WvWciTE+Riw9I IfadD30mCwaJi5SZZiCcrO2hMWOHWIcN4SEYzdOW3X6DtCYe5wDSZiDN8M82 4krTdmLplVAEZlW/JKQUrTc4TwURQSXRo75jNooLEXqECcbx+RkRHRJHRtLx wFkYLotweB3icmjWLZEnVRlccaEDb4dKCLJahZxov49Lhj88OCnh69yBnI0n fgkjnzgJV8+nICeiLg1SAadEoNZxH5fOw7atBSUjVqCvytJ0iJ18RDjHgktj ebBn1K3MQ9WzTgI8zCpF0aJiwDf5dWuhDydLQ0ekWyzb6Cc/ToPlKSLNgrxR os4DvEvaHhxDJ3STJ8ZGzfynJfqsvcK2xre4uOXSisoNWOT9ytKOSyH7TtpE IaIC5E4gclI6xnbSPOapRMxdUntvDF/czQAaHcFG/b0EOWv/niN+wwOdnoWH 9t8owse8nMiyijtmIz0Vd8iytiWnP30qNjQwOPS57DGoH+KGDno3dQ+oj1uJ V1edC55GOWP8xeudFJ2POwcgSyiSIkOabZobRcV+DjJ6Da0SfuKzBx+/lkZF n06M2zgLGqIWJOYp8DdmW/UNvucmSRkQ/QMWEAu32dAIpl4m62C26T5fJmRT GXQDIN/RiSeOLyeodFqlWoKFJ5m7z6GlrAedGOznmOUkRbFhHd1jJs/FVSCd iJgPTbEVi6enyFfTFp4eHR1Q5qusPEZLy78W5DDjS2NKhfBU4Fnw9Zifm6xl QL/KRVm9r+9QuN1vvOPMa4Yt6QeT1QpDvGNgpDNEnYDiR2PyBDKopr3iB1g4 5FWk7jgg75ljhzOIhiZPywWqDknkAFI4OEpjg7KpD5nfP504ehwArtOObnE0 hac8L+IqIR0qAb63OGKrsuECwEgovvZH4SuoywoKheXGPXrjU4pYPGKZfOGN o36G8qLIjTmf+f0+ApbWx1IcBbs12rz98HpnDTaJZQIlMP2hDsVsIuDSSTXL hZmkGyTMULjj5Ft5EyZjbbMVYwPQnIvdD88qw+KAFB+WtQ6THYPdJY3EHz2U 8vA88Te2ibuKKpCQvca7HbpKGfhKoRfXJ7GkYlJqWCjNIzSIkxCcrxiYHQsC /RBOjG4JEgYGZWMT4JW1fw0pZT4zmvCwJt0Fj8nVreW9WT7lwAuNxQCCqN1T uWU1ucY+N8x7lFB1HAAQlJy4ldmmCdLYZx+0xTan/SBBIDUqN3WVtS+1j4Nf EDICk7ElobAaIDEm5L5lQUG2VgHEb4Dk/6X1IbMWBDqYpvhdROudu6cevYCA JoGYLsxlxnwlnWlbtt3tTpxA43saHZxFWeH9yrBKlFZGFKMxol9hpSlhAlJa DImy9YahoaNiAWHZo0fyHqO0y5iiFEw5R3vSA2QQLZLJtBH/faktxQ/Dc56e qwM4zTyRNSW7iry35G+O2vq7/bG/jiQMFY7lkvnFJTiNOnbl1HMYsj2mWDrC TKDdjnDfUilbUzimBTemBY6gpgbFtXpw3tRSawh1zwFF+exITZoCMGfOJng6 LpnjpQ0jHZjXzmci6p8j+6U2gCa7grsjI7OXlT5tqDzbshRmwFsGBKgjGp46 lf6j0oVfyy0koK4PHTxD6S4CdDzcvB88GcxWwTE6wbrDp3X0S36wJnYhfiF4 MultAab1JncwzNZBOFm4WyKBIoF7ev0CPMS8xkEyaS6g4aBjOPb9sHBWOPE+ 3T5f3m6bPdHqpvhO8JEMA8PRAaC1i/n3EfoZb33zQFZ8Ln6SJIyHJkFJr3JA nSbMlOIDOaacJ+KFIY81xCovrUGGJRpiB1KOcuSQJ2Udhj/TByq5boUinaV+ +th/WdfApBBTZDZKt01Z+buqNFUFLxkZ3Ys+7zceHKSnS4F8gKZ1uhJswxwd GQaeHYMD2s05b+Q99TcQJ5RTOjK3+h5AJz2uoxJsahYcv3sZHnralEgvk3Ed OpyaMfiRqTHulXw6AzMfdTzeQR6YhKwDaJomA03rNNPjO4SFYrDfv6rXiVGi 5DtuOgOCgMUeVKrr2NI7WSH84SFR5AwhcjkMpPqyj7C9QixuweVra5hf7RiE t4BZsMc7bNnMat1z3y0BkSdfjqt0koTKimGCporlKYzup1TAIEsnG+8nxIo2 STAcmtlUD6eLMsCdmLPaKttlo39kPa2LDAqadYZkJbrrLOOHKw4PkzRvkak5 JiXsMJsLC0mjz1+Kpho3r1nGYwMovCq3kFWoSZZdoCMCjAuG1WzKYkCWqkip VrLAppIkWQ61lCiD5pEhhgQImr+M3WcUh5tv5tMhUlYkWlro4r0L4++mi4Vq ogoHZCFiWUVWYaQmXutSvIqVPBcMaqGLieQnRVUkg1hPpr0Oi4wiIOFc5FGF otrwqkPQDDyQQWXRlaHZDKHf9GuqJrKModjyCoQemOGbZDhqughEOYAkCimk 9if6EVaU8M86GAo3sD+8PbBUhm0/lYdhz6miwI3HEbCdkbZ904fS0hFQsgsA vZppHm9i6pt/J0WXaooob7q9nEatxrHAeyGe0gkjHfVH52MqBIzspYreINgu 3qXuCEnAQBSKf56JkWUPNe9Y7UUuvgvSUTeZnurZHvn7RW8w4swOYX71zs/r xGcHzcWSdU2XhDJZnQm9c//1PCiCX6W5C7ilgn4NqorWOZvHsIPmxqCrytsY Dp0c+Z4dAoG7bq7iMryIAB63VAHjWQICu7xYoviHg2v9HjgxHa2YIXk/B59k llxZpWqxHjS6H6KoOPWFxH2YERqKOd+zxyfMBqYNN041q7Q9n0c0nnjVVTSl A39Cp6wrvOIIY74xSrqy3Lb4zuaxHpi2zqYei9HR9fnlgKYY/4UEbzKP9AQd wr2jbGHrMD+9BilyqS1dVGOyrJG1Mq9r8S6UNaCoYkayRyZFSszvp2L9pRjH oF0EvNm5clxErd3fdqewRAmpkw6WJs92Mrnz7oA2KVFXjHkPJ63SNSxp6usO xmgZcSU07kVAG2pMyQM8nV/Tu4fNZF+V2m/K0qAA2sVtUaCk/jtBxIMcytme swVhp2OXDpaAwQghnzrCN/QhO/2WbTa7IJ6zgBi9idUeFIYYgKWWNjzHUzn9 jJlXUQTcOzc896U8RKWG3pxFk3kYj7Qww1Ila1XZDSC4C05foEbwWFtjyR1x qMQq/IelZ/Tl7oK0Uu851jVcscgwXHclkqHkrBGlonZoEdmmIv2QnFLufrSf wspy9LpZhHnzDl1+yHQbRXe5ECU9S3MSBKI7prQCk3WFo4flPK6hOyQbjS6W JBeitkMHwbY1ERuQuRHzp4s3FY0WTiAfw6E4H2TSwm9gyDhHv5g/n+Hft6NF BOFFGZ+iQwtWgKOcQYw/ZisdXlsYTbu9lMOIougeBt6K36z5bDhiILizAK+E WIpC7zNi5ZxrE9rWL1Hj/ieQ9R86D30IX+UlruYS7w22C/9Fwrpl5qfW97oh 8UjASrfIUXAB4x4nObd02pZg0btc9OGmxXthUiuEcmLbuyLi/m9LRjkiCiSW F5Xtb2i5FJ3bMEEeeSpSlnsEWLBF+n9bvb2n9IpTS6Om9+IhMy2nxQVfIuCj YZCAH6vUJF0vZOukm+8nwKCbgAUcLSgG9SFrB0RcXlpaJDTt5EUVYbiAHG/T OowAFCZupVuTzwemE2zHh30UGpnjkoQc3Joee7y31CUk5RS3Lnd4DkGXd8Vm Vc/wxbun/9wEgGXMt7wxxHfhu2Jj9kTbj7r1Rze9bF9Ah1DGb5Swqbpqg8i1 3iMaRnJsg9iV/iS6xhq1V5F9EVeqSqCLYi8CmLOgMF0S0m/JErlEg+Rsu6Ho XQhpArHmVTwO83On2/mP756ZwcK2db/L8P8J/R4uK2/RPruE4Z6isCIjYTM/ 1NANPCBmVT690pMtIhe/DqYwIz1Xu0VjyT7vEevvoMyLdT9uXtKhUqIvBuu1 g92cejoLn5gdR5RveEpNqejeBZ2/YfRqvt88bkZEv03hCntVt3BxVO5LJuRM OzPfEGh7nFEfNKyKvP96whwJRRi8XeUEvzlRob2ULWgbKkwX/YR28yBJZCF5 PavCsG+hB3L7Mz9X9avbaLBdOZ365H0eQ6ZuORCjAWEjWYU4sImfAcYktu1l 7hyNda1kjwD8BDO2DTIQDqFY8T1fBxZwEgj9j50KIro1Bl4jJjPt5X83XPyU sbnRt0FdguPyJwm+86Sz18yFyDpNlDqDzSDtn44+xD0C8QuefKPSZCeq8byr tVwkAM/s0J8RjW7m8SBHq8o2rxBlizymte+Unwwl+Edggmluc1I+Lh54yaOP lMdVivAAQk8z4DMYLYZKl3NHgyjmuZiQ5qR8yMzFp/7Hors+yZeD+o7q6Hb/ s1O/YB7okM0/QB0eccfazQP0cb++//Iq2No1oc1zmk5Dv70WFEfITtw6wsGu YmtC3zXDWF3cwUHBW9jVStdjY+MLRFHGq7FKGONAADCYRvEq6w2Yp7oYIObL tp+bgtWCyighvIZxA//XC4cBX0x6eYSZDkHAQNJTLNOHGKwaUyzjnYXVt3jA Cf2kzeEeR0yQ41heqJ2gqtb8KkH0a6ZHoMfBd1gifdUHP5XlcyCY378cHjwe WpXAdTgooRlYM08eNiOsgJ8uRKszBpUKoVThoneDJGEHJASfzU0lXQ5dU6ze wRbots7gP2jVNGGnPQqGNkd5LYrc7UdbIePX8r4hlYINnVF46kkvkji7VB7m GgZS6R4iIpy2AGmNxYd8zGK9IYY0dtfnDSEM1Zq+poSBH74PXKBDuMtFEuDx YVFz6j3sJcxAbae/Nd29bzLyrmqLx72fTY5FhTKnxCx7NteUNhQmRRp2okac 35PhuLA8oCUXY3D/bGOmY/EKXRWUoD1ARZ9mTqBvg0Iws2EbcsVvsSERPrC4 zDg77JPZZwSr8+9OwOe/o2PJhGTLN/ehowV1YKMxuRWzCDz/rDIYFEWG+xkw 5YVzff4ZjxFRxJtpnyEsvCz1VaMBAhb1V5yW4bcg0n3yopb4IscfZgsgdsfx JvCnJwnqF4f0cSc5IMn+/rKgIKD+frIJIaGgl+boSL1mwyS/VN2OBQbRxpey Bj/ugnFMxN1mquXaMIjzAXUiQxCIFjY+TYgewgVkDtlJpz0c4rZEIIchqfsd D0GgMgWlciwwnT0ClIWPjSjW3feh8JADYN+gm4asDTW9E0myNMu1GrCQwRhD GkGmRwOFS2VvpUce7QchaSMRg6mYF+dP7JqKi7V1QWhxD8h5IEAADAgY4K5b cqWEBafvqpAgyq6miwo7HVAJkh6jXpgddHP3cp83YedgUwNf56c68qM6Tym9 SgMZWyeY2qaRoqUpmqHLuEpCHjJS21UluQe01OvYZzxQBs94lPCnsUyHaJO/ D4Y+ZZ1eCm+wCIzNxNOsaHEy69Wfz3+wT5q9eHhH1WMaa5Za+zbK4t0g3aA1 nxsGI2ZuztmgA1wzs7bFdu5Ds2XuojfM37I7Sb1lFQ6OaJNMkeTY6oWk1/22 59rrLeu9HeHoHLDiBSN/2V0mEj19stKWoEl1A18X9fAGICYBH7FbC7EPesyZ nwgLZ2c9nPksYidZHx8QA7jRoE8YqLgnhYYC4pqeW7GwTLLN7BN72KAZovZN KnS6ZPS9jp0OsK+OAY9t+yMC16JNONG8bwo/hSs9wFii37Lc94+BneeAYIfO w20mrLDVx+AWJZKNToWwrRLB6LU2oE6EdcgFQRAdWx4YjgaxV2Vvdxx1QyeQ oJf9Ax10J2pQ59NH+x7zAaX25Kdna/j+ZoKcwp1BZeO7n54yo8E1mAYcqnJ/ K2ZqdcCda3UU15cnRUNGZcaBLYpvNleFoa7rJ/nNBm0DpkoccwzBogWn8Nym M6CpuG5/G5K6voVvtgC4WFskYrTiWAuyoqa7oAk8Yx7xtiahIKKaktR6xCY8 Uqe1mPUDpjdv/fogu6arS7XXxUNLeHulgFw1Z8J/Hjb+7pTepyA4Fj0pO6Ca M5CP/NEg7P3B1CgeZiwOZ1cY4xiV/YCtGBhTBbs633dxv++7IWyUpfuFc6Y7 3MUQ4YKKaVmlDC92leE/TeGL3mIlEMgdvY4Mv6LupVAw4Z0EOPF8FoVgjWsd IgD0N5zgZeWgXjr1FeUCLb7opqycTooFNWkqrei+si3DYyImTJU1RTUXmDa9 7BjyJxhe07ggeiL4HYqhHrIA2ediLuLup0sKlK4QcnotHIWQ/LrbpCRHgxo6 Mq+ikPc+jzCjkLWIUHR3os+Zyya2oscnpa5I1ClUyFqPHvbUVvXlG24gRj0O NZiKt8mEcPuxG8V3YB+tM3T0+vZBdN9xEZ1Jd4HwAL1FuE+rEss1VxvxncXg /x2nj/n+/bM4qamoOneEuSjjA0qDZ7Feun2qwAerAeOf/IYIegAkINgUlW7p 0htRpO+7HrIR/DXQhbdCNR/eJZ6YJQXlBfOhT+WZoqiMdIS/j/vgrmIHLtPF LCacUzFOOQOuj9tRHuDe7Z4f5oukcdai8Gkmd6BnfbQ7v6B1bqNCEM5hquJF oQNmpVDgIUmwiStVB5GDBwKpnCP+IYHkTyXvPWJIoyfhB9p4OgspnRDhb9if 2aaengdZerNJaoXm7puVtTL7TjfHHoTlnUtOeeRioeEDWlImmj8YF08qY+IS nWOHm50eGhxxbywgIVwDqiAeQ/nlgtJvf7my2+c7mqFnp6KQbu6rM0c3Z52o lZziXFL7Y7wKxa+KvWlgSz00hjhdiiEzNeePPpfQNy1AnniZITP5RrDl+cTH N7C4wKawrCSkMVeubk5jnNqdQSWJ1v6ddqA8wTemZx3toHqFMJHjnYK2tXSQ 039OZ55Dnc1NvIUqYk+dToKNfDosp/8eFUZaZMuO8FjuxvH2eh3/eSAmAca9 AUk1AJXBZMSMBaN8GKsnS2Zl7tPYth+q6ADFs/Rv66fjOm684mSm7pXsv6b4 PAwkg3jNIzWUq4glUAvdPbYpZsWqHYIpEfgHld4m0Ck3tkGmMDayvNmA3tK7 kzudIgPnv72mk1InPkWIhhc7CExbyDxnr5XGs0okOBAqPeWm3xTiXedeP/SZ R3Hv9Mhc/tnga0Z3q0+dSAVJBiCQQCVryX06vY1l0CWabaRuXTUoStOkXt4E sncg333cIsKm3+Tpk1BgtkeIQjH8zn88XMlM+3hWB7P9/pQkOytNY+vRCqno DRzN5OIjDWUpI/TTbCIrIm85YgONJCMi5OoMOkqz3ySMsp+gBYpAHQm/R71i 3ZsmZQVGoI7yc12w0bDipSLTnrYg74BWIicdirQtToZUsNDZZH6OBaO/TKUF Iz8uJPWNJcERN/CrJW+Dvs8WWcTtJQAVDwaen7+lF/JTHx0hS20m9f4NGZxv TOkBA8EdmZ9ctiGfusibA8IuXomOeN9iZJ2j81q1Q2WjXaYEw83PI6XZBSaG PgITT8+mvgo1Bp2/LMGWr3UdPWI/haY8bx/NcUEVzp0Q37kVnUMcP8EfxG7X nibcHR5zouC/odaeHn0X/ZyqHq6WF8HerB4AA6QXX1G0A68Cgc1pH3GegITn CwZMKZGVpK6j1alGZDsnlsceHw5TH2/sXcYLpUSTZKPkiz7YJW0cpQgNECds DaADfVN2JZgmOlaOddwK5zTJGJfIsCc5uZwvpo25JlalVARkswtvPZ/Oxnhi IT2xeT9j5VJiVLYxpmEsto7f5kxvoWcVmLvcHR/pOxyADNgFLeMDJEoY5qRD kkCagyHHJXgFMhWAxMZomLOQdGolar7dnCsVTmVG5YrRbyGAVJcTuDdv/YiR 5+PQItuSKYORiLeyi8a6UmcW1Yui7yo092trvJpoyBwIL6c0EqV2p3ijpaTI IC8KRW2aPdKaeSsKUW6AZIqyI28amOllt6qyJSLvoKYjOKyzT44mPdonjpdY g6xEYX5/MqJvOBamO3aQ06Icf3oSSCTqQksvFcD/skaLf9lb2828Zvo4C2Ul ouB9r8eYKd0Wd1yM5W5tKbyj9oBu4Zx751l2EdSlsUM4KaY4sZT++Km7mvbE RmB2JUCn9EazWnzpbjZxOCckvddZLBvTguE+uOC+I46FBW3P4PVub+nsNa0z 5TEDF9WKb6IHTPZIVXNs6aroObyZWzqgjzEErQHira8+fyoKL7xgApK6qzIr ho7ixAdUHeMzJh9MQ4ffoZyxHQUSz8TGbiLla6Q0DrjJtpPx2yF9sV4ihqXP sLOkDm2r4TE81qYkPzKpZSoubjnHty7GPU2gdqMso18HrWAioAb6VKdACyk3 UAY+sPYhvGBEJGmJqiXn1ewYoGX6a6x4clh//Mv/39/S9spRtW5mBTO3LbVb 1DqhUuSyMafSbJjFXD9dMGHSaTyvAkaExjb65qjEQcQDjoKDWw4KaZ2q2zHU 4ryR7iKjZru7VpW7VbQWUjjII4J9o2A4oOG7jJHpLzKaojGiHObmFSGwng8e 9vmMyE09yCS6zCvSp6YNtii5n5LmRQB54Y8vmG66fAM7TPwmaTUDjrUDBZkR fPuaL68PRR1idubFfoj4/JjlD8mgPRa/sHkZA8VWDbNNvVK4WUXwDFUrpjEH MaWRjdb8jCboCsSR82KjPvgEHRuLDycskxxYZSu/wetRUgooduiaH85h7ZML pbMWLbJ8v3YK5dWAmP+L5xK2Ty05okfF7z8uJi/OTY+qCiGg5KTvJoHSeJiR t2OnS+6O4pumXJRs4zGmZKoAtaam7iZZrELcJuylphMgJ7XvoUelmnyvRbFM 5SnS5a4PSFL7Jjh/fuJTrDaLK1608GO/4Tthp3+jdroB3pu9FNMYH/G60oR1 sMMts/Lu/Cbhi+e3JKK+1NB4gYADZQYTmoE/7AsfB7NjHoi68n0S4pfPEG6F F+OnaOj9NteTEnOnIkkBJ+YgJ3w212ch+yXuvQaKE4gF83yieiJUcNnFT4zw jfYg7wzAA3C+QLQnWoEP51Xea2LpGUbMW2QN9QNuGJkN3B5EPWKFID3Gv8BO oQUCxV0mNi0byuRNpO6iWaXFO6BE7cdtLj+BY2+HoAlcN5Ytq15vp2pGD6qp xaRZoa+U02iHTqOxNp26H7+doM9N8rh0BdKy/SAJZCQZzmpR3gHtPIoRPSWW pybuFmJbb6YE4TkmIKci4KCNr232u+3LYkaa1B1Bd+Vq0VkkL6VO2R8MymlQ pdW/FxIi1YpyGMfz1YWgmiA9odqh5l/hziN98T1AD+sxp+Gmm0sdCwS5EaJU O27e9Eu4ynvrl1gdBTvvHgupggA0lovErAArHRgnZLwTzxxMHSH6HqG7ZrwA /SEdtYc2uVtIwwrRbkGb6Cp8EiFz7ailfDoLY7RausCb6v3XtyK0rWckVcje Sny7uO+7v6MYpSBuoYXIVPEgzqN9Jbl9PiGfp6BMPLLgQv/1dhHb2X5jIbFE jr8YS3UzIVDZpOdGXMZEgea5CKhkS5jhNDgJkkwgoD2nGI6gvYiioTm/w2ao s7mTmyUbnzxgUFWflhubvMeHEPoizY+czb/y6iACKuUuuPoeaXWe/9swHKId xTobp4O/Q4lx9p4QuBtdLCvfIk/qJq2eH58cQBvy1h0h0syUlOLwhrzfsS0p 5PIFFMSmzhuXbD9HYrmOWmEHgYaquAQD7yiiQcTluLQBlUYf7oLJUmEgDyaA hRnJu7A/lF9vplqm6wYwHt9QPVobW9txDFdQVJMh1MF7OKRo5kizqOsng5Dr JoeHululdJq9ozSP1Wu2v9u36kU/zCV3U1viW0LJQ50/tiNG3oAaMX9cir5v MQgVP6sb454iHp+YBmcDHezoNRiCyDvfyponoGEMjsJhoQOFZziDny+90WWv bzi0O4bYNwLX4Jv4up90Hze7hYFdhlUivVjECSGsbbeowwyR5qjjXeW9su88 TQWpfBNAphKluOE/bzS3TZvQ9fM/qqc256qn2TlVYlHcYhC/5gM1R3lMRjKR Lzqbq4BKs2y11micBp24WcGBSBNoAJz0fcZM72rgEzGJVIbr74K3IZVgvU0s 4d0+tZxiSZSTZ/KiF/wjFB7hJRRaXIk5fCJlbGXYatSyvzWhbbjsY+i9HqbX 9r47OvKUa6BtcGGRtPI/arQKwW89MxM2qhfykhNPtJFrECGRgLSKRpuIQ28f oJNvg5Nviy6u/Yds74uJbm8Iae+zzSa2fGpvsOUrsF9BFmfgqqDNbzxNPT/F TE34kcZXfPLEMtCeDlrKgPtAwFgqpWC7s6cSkkHBQUETE+xs/f1QwW1t4e/p hy5fe+r+vEtm2c3MYxxYaP065oqSYxvBWWC2Y/fjEH56041+XYx6zY5uNcx6 sfG3MNz1YXdxbkD4+zvNpThzD/Fq/AtAp3NhzU3hz3qyrzWVFp4V7v6DyZ7F +qacIzcahpdj1jpI4dNzmFnmqhgaSOaVNDpiupTlKmk84B8vwXhUs6RkYaaN GTELgnXFJGTkN4WKQu4t4+rs4CfXYfonOoSRwThCXCaiphE1DOZR+YC6wLSz satuxMjJhS3oMdGMBe86chueT2KopqYSvWg4o8A4u8W9nS/jhqWYsfrup5cg LWiFJ4AH5xM+XiW67IWMwcrhqCKbyObuNKYziqAnuW8hhT6UOC+np1K8Z8HV pWi5qYWTErmkz+NjkCfgZTWZp61nmil+cSXRcWqlpxh/uHGbIVzx0zMA4IV4 HyX7RbtOM1yA2noZkSPKmPif2rrwsU2bE2LYNoo1ShdwKeLx1VcdUvKjvJCF NGEVKURVDZcWkw6kHZDzrDf5U8ng24U2Clz2v30btdXusAoLZ2yI2DTwzW+F YH8dhu64Q+xyArB7C63BFs4eiCQkyKbgu9nlO6WjJ0U31X2sSb89EPI02Cd2 u6NLodUPXWDezz1DLEN/oNTDwyKJuOy1JwHJwKsM8T5jkiaLBbznirlYjsJm glUgDmAy6yiilz6l42+ePYQeAstAyiOm4do99CVjAqQaOQyKfRTfOnpJiO4j r6ftPT+BAE2x1L4P1weDCsGhFA1fNLDt2k77/niuR0BQkNOJj7Riopem2Goa TGsBWa/m9ebFV4W8gys4tPih7XwxIaQjmSYaZS/bxw0RF+Ho7g75NDRBOawy b7EdOBwy+lFKNAy9nWX9cz+M+T9dM/lteFHMx72G8l2XEjQ+12wF9n3YcLJh eQk+PHc4Bai1n+Lxb6KzIFml4bGVIWmtzTVhK65OoelOBIWECfH6eKMYbdpU JkmpW1vAcKUpqyR5pF3nQcxBetAOk5EGil3nD8UCnVlhGBndp3Md9r/S9M8X uOCeHfAa0WYjsHPrV5R9FEvGlYn0d9T/PJdBHIdeNKVm94xI21TbJpG801lt aVlo7V8XFRInibS7o1hziflXQd66gFgaJ/bq3WtW8ifzFEi19ZdA/FrHJyGn LY2xZhWl89IFKty5IeQ/3CtyOiKBhqh9WkxjdHM1P23e2rZpdSAHG4J3/O1Y E0s4lFAYSywGie9N/ieVawGhbYk4euI3GpgjBmUQ5E08Z6XRHqPmYqBD65LE lluF5keHDBGkrxGN5VlRjKa3Mn9+N14x6ceW5fYo74kxOo2Fj6JrWwt7b3ai aCDvl6Vt+Y1v7FxChzJ4Pc+Y94C3ck9aM+VmPfx1xUZWFVWHnzUzDGIXfyOf o0m54VYqcQeJXQ4clLLmqKBTrRnorovPiOkpgLLhouGYKD0GSv31YEZqnmeF /JMIAWIqxeTiePV14aPhOGLFCkKtb3YTwkU14RwmxopduIZTXrHAwCW/Udkh ZoOJYGGX2n0HqQcLLmz5Xe0Ze4eMwsyLNGP679xYh6ejjcjrPS6OKWJHH26y h0QJDFUkZU0hC3JW0li10rKy0xbZtmNTzmJGQDN3Oq7H1L02gXvMGDe13NO3 o1X1BKrD3Fc8/tn6PSE2cnSfARijbgE+0D7uEoGONWaWuzsAtD7uO7s7NQDB NTo6tuCb7t+6Ou1AHW47vzkwQ2eju206urjuN7Y2su8AaB1MC8LW/kKxuGXD UAq+nf9ywbjDrJeC5z2VhXG+OVJiHraAhWPiDCXOIeErXbeDPqKXl6yURLwD J/ow7LQ+sLA8fyXCqdMT7LK474DZFucmp10B7mG4ywelKomMxXU3hEzv32Zn FLe4ntojtjSdlyu5KnOsyvMyKWKDDzW9pmSpMmoDp/dJkelq5ICZ4ZFvoSPb wbgmk6a7BO9K5OokoqGM76BjoziH3ThcblT3Ua5uSdvEuo4WLjcVQ88mPOy2 hqN4rGYrIehaZ5LR6jKbisYqbWwmpj78bKjokmZrqu89jqeCmxmLfp6aMEUg IOKZhxwaOmBT/wYJ4uAnjbaUBbynpaaGsqaMx+KVALLaf7CeJTqnhwFes2mJ JOEEIFUOXsXQIGKc3I7GhdbGBidg1UMo3QAFpvb2IYHPhCjFySRRKcoLbzYe GONrINmCog1CI+PFztiIHQ1Umn+Dgx85BrgsvQQ/DDZ5rkvjrbbBoVdLarY6 8p0d0+rQ/M3zcCLHoTzLcPMAmE5Hk/Zroj3Dp9YQ9iQi8GGd/MWTKghfPT69 ymGJpW6jheZGv6TTta/2L9FxxpizZcxxEcMVmDO06MrsaJLAh6MJCm8ijSYM hUUjpgR5IVT9VHWLw63KlycRcHaH6SOtsvG7QOWG3c5qRNo1maOMgd1dsZDd 4/ajFg0IPRu/zwm3XJdK2ZZiwoVhItZho2wmXMGzjTInwksYImhkecG4J0HU sfrt+sxuDSFBN21Hj7AcY0MaQ//7zT3A8QDeBBjjfklUXlFRrMFkOVLGYrni Qgo0GaWiG9CidZQXTLbgj5aiSSs3fSfFN24n28hy3uX1a+DQp3T9vO61M68/ vxlHIZmmb7x64ahANE9iRo9P4SDteCfamaG+37EzvgInJdSEpCUECkbtU5gG ITlpvEUqr2kSILuVL95IrPKlD4WD/WyldzWJINYDpdIfJiEIFA0PC/E0qytF V2g5insBYDRdjsah0x8Iv+cFocNOGuskVg3kZ34YrDs4G1wmKGaYh1QjdYpk PS2fGkZkrRudMKIMT++l0yzOJgrZvOb1QzBZFSfqDSfheoNP56T9ZoU6CfDT un89sWgwGHTg1aZ8VQZZRabBQ40laehsOU8jifFW528lEOEEnDaJJOC+PWqy NTkl4Y8/M0B5lc3PHeUm+mM8Gpg13oIZ78WGGb08tjHpN1wkJUTlEv17xiUO Pm2BxUpZGr2cYYdhtF5rwNU+pnmY1UdSeZqtm6WfabgYc8L4JzZU4SuiPIZh L35L7rIgSOeDCDybhx9jXaXu80vtYY89bgpIp2Qtt7qihSBd71vqHZEHZLOX 4J2ajzDuoVJ5RgLLp6AKDAIzeL526p24YymfsN+KpFdJE3tMkDifQSE/mI0H oYFayH3SvYmiyB+FBArnmq0AHbuyVAbFt2BvJijfH7G0/juG49o3mN6Gkzfr igNmoGqIXo7a9ml1Rrs2GDvwkntKyXT2TRiMcyW12SUOKAudwlnaotqHfyEI 3sjGxduZyNNhuaehpqO9HL6LugC+KolqUB4b5nZlJeVbc08dnITZzgpMqBNT aiT79ZIaySeWztmTS3bg50xf+d+mk+w56SbVSyzotcRu7yGbY5MMqv07tgf2 /MsScajXJrKKxFVMJa7Om7Dhm6ZLeO3n3yAzGCGePKDScvnZuKKzixTeoU4D 6Js8Bj7CHq+gGB+xutYdXLkH7JEnkiXqxbimRsGMveSdYCUoxzKmxDCy2WKk IG+H+aEKYVvZgHrk8+GZsriCdlYNH768TD24hwmctEMcEbIqNMp3ICM2+mfq tOm1CP28Hjwiha1iMCN/hc0NViiPgTxm1dSqPRc95xeHr7+6ohhYCx+EEyH1 MasjgdncvTL5ijednnHW4ZUjo+AFD/28iuWLIr60DqRPjzXpDiSnl3F0XaDR oUgOP0FDNslusy739wnJIjdj9+6JYHLhvWOFj7fqZOPawmFFc1J64ToYmzg2 4CHpBLkdhw1FI1qja3QTx95RBz3hPDzEA2BxuF0nOYuIsccB9J4DVMcahaF+ bFqAB6RV2Nvqb2U0F1HbAAE85vEtvGOjqKCLFK0XLjico7V4OWYabSAKcqj+ 2X75AYxuICk8vp53CX0Cv7u5oFc5fbkftzMXBTwFPT36pVDF1Ocl3C70z6h+ KOcfivniUDyb072GoAlXMCywyyftQH64jmunEOmVte90Hxjh2M9nr98z3CEh ijhHzg5BBzji7XF/AUWU4bT/cOEnsJfSxR2oNQUp7ycOmpiQoZDNt41+J3WA xH2llBHXZiX7NAo7Ia/jR++y+4sYvQqm/7/l0adujniCE4bNhvSTGnE8Nb38 Q6ZBIOZ9U6aEmqM2qQuJ4L6bo8Ong23AWcOmOaBkoNPJ//uOJz1cOA5vsFR/ VOLe8cVmTSDP9Rvhm64IXaad7wm1Qd2m8wK3j4NeDyuJoLELMwUG2xPejQeQ oQ+XIYEkVJDEGQgCASU+goNrBd8oIpGIIbZx4+NPt1jvESNldSCnlbn1Gx43 WUb26h224zYOwcoluA9044MdN/G2iGqlJnsyTSqZ78EnJohRp24wxIn/pWFx +I7CeeWfhw0Z7lCFbTZ1wqENaTUHe15Rw6FG9mInu2nxfnY7XSFHCTPBdjLo XaUTgrXs4yUoNQ4ZGKe4t+uRXOeSRDOe+iLeDsvc0WodIhpbZBKGQtPrdb1j O2UFRdYl4SSmXR5NSsfiOaY1DueAcMi9hbCMX1ycOmJioO/qchy/d7BVbwFZ oxUMySabIzvdHV7Y/YeFT5GhU7huDW0wpnA5PyPZVhKigv/NpznNwv3zoAop 4CLJFP6Qvned03lgMKRxTfjz5/8B7Mdfpd9RU+nOlRVfp3SDe1kn4Ci1fiMl aDH+7M4xEXZmyB3dXqcw+vtXD+PSMn9owidawJq1/B3mVLOyNimHRa22sI6b DU21NzWKow5SHa0JhzEJawxzN3XwpRomGrv7Y7U9OK0zgU0VKOX2M+8/jfW6 Bm+ar0U6Rv7loBhO8WAf1DMYWQ9yOZWNUlKrYcWlA4MSuRdAICZlhz0pOhNu AXuluCW73YMcpjiYPAGcnypUIBJx5+dt16GXuQGnB7jE9R+tgufAqMEi9hEr jN0hJx8FGrWmBpQlUw/kMHByIo814hjBSG7UBor4RclJJie3njWTxT0e8qx/ cWXeotSJ1P/e5S4yh8qkWx+HofKSQ9USvLWtI5VLn6K4NtehJXfzqJbXHScp BmWq8mshUJJdYz8rA5nwlrAMvyMdx03gljCn/YM35vYHJ/i9bXI4HOGaJezL DB+1lQnXYL5KJ7Rf+ZyV7f2lEjwxe6W34GscdBKIveXHs/47Z5EPq0PB+gyu od6FTZ44qM3N/kNnfZ24N3g0wTd+A0whZRcwituzDWj9uI+X/uy8BoRmsblu QWWLF6OlYdmZTqAOWqHKnvtWzH4bjo70YedRmMOjjjK3yZpht92i3sElHgUh FSRWVdeAuMdKLxjinMeFyt+oRdcg4eC5leIzUZouoa+Ao//zU82xXIKVKf0j Qqe/xwy5Kj3oMpedq7hh5Kc2iWdipRfFGw/9gBTVOq+olAzmKj7qPRDaPcj4 6Z26jt6up7/i1qiqeeCnFmIBcb2kIZC/u8y+GJBB5zvG5eX9c0zD8+UOYbvE BUEV5j8XZOgV8s1RkZk3ctWkF/hqS4owJbcgk5rMgLm5uYFx8Qn5fX0xCfHx /n0xuXDx8WloNfnxSW0E4ySuPtU746VP8yWmmLdWciU1D8sCXqQ1Tw0HjqXL UDXzpgADJk+VmNZXDzVk6ckEJzxIAAAkacEhW6VVpT3ufYvxpXFuQadB8XMP wSLXnXOm8Sall34GcCU6OrQwF/FzJsw1w0Pev9b7N/HKacugDBnyun1rsckn ScqwCbIJTpk2MSJlt77AcCYgvVk/zXn4z3fbpIV81/Fzjv0are7NTU3jozWm z3HxeBo0Zk3x8Zk1HrRwZLTEARxv/TE5AW5xIDX8fiIAGpZW+X0BgQGBCQAn SQAHAWXXV7EB8ad4ZhdzQf21vTVu8lE9maJJDlr/6TZEMe5xJTYX9dfxcze4 Z/vJpgD8AuW7AXM3JjWeAXMnQcG+gJalOp9GD0IfiUUlJW28K5nO2+k3jw/u ihcePjfF2JeTUZMMinI3aogLITh9FSOOQT5V4Qg9Z0Wi8qaPW9YPWM23creG 0DDzOg8lOES67bX4up9UHTlXp/+7gcouzNnnTO0YG9v+cZYwAIBMOT9Yndv/ d1bzNAw4PNpxDCZaLWLdx2KAfrAEJeNlN7/tXQCHqMFVJYjNdabOe3DyrKyP SGFQP8q0vwgPCWU5Od+5Troc2YdXJIamo568pQN1/yy6BaWwz/BkGE1NHU0g KWiC4LpmIH9yP524M2jiJCWnOyX/jZOZbqFugKaLGMKKGA71Mqvi3L5xivfy NzW4O6+aL6BMpf0p2f7TPdianQ3EP4WIppT0uzRQfDaXN1FKuyGQ50W0RzG0 wHDFdWp0oEG2MaByFiZMoqm7M0UPCoeh4rMcP7ANLT/OHR6Ht7Wdd5UUgDXD MbWhVyUJN7HZfqLXO7slQOP7lbd6CAcRy1v/WejZlJ2jvWJcvIZJWjy9813X SysOmKP9RaNkC//CfhRGbG8rMijmhCWRxLLiiPS2GIIHgnEtjOCz2UYGyDvA yfBl/qbX4qU+pm22pMIZPvNe7v7soSenmCDu4SKfu0JEbHKWwrlQoes4yj7d a+vsmP1QISn8AaV5UIacMiAmIvBp8JSRMGq+g4C+sGtPMkbGEE12wodLvCNZ U0KK2YIXGJI8kYg24Yj6Dl0Nxf5hobic3mN7G2yeP6inzgYmjM/otP2OeP0d 97idyboH+xQZxzzcgV1ci1u3oAQpIowWOzTAvo08Ud978R0goqsh3OHgpqIS ZuvEAqTgCKKfq0cTPzEGM+88p7wfDrCnLLWGBbKyMxpzHy3UJCrjGyeP4scD 5r6jx4bMqy6SzsZbDcgTVzzmc4kDHpYMut0gv4Xe0sa/hDNWouKNU44Ued3e vOhgZXlJSADZsWK2euEGpTalHR5vXGDcTmoeaY12lc/S8qt3XeqWYnIJgO6J SXfXOLa3pj+OJ6aOM/MleMtTSvXm+WSm2WLYHINnp9+VzvejNxGNuwtQ6bw4 4CO/gSy9O369fuU9p61jSOTl42dWqgNhFyxYHOHv0mTUep10pHq2P5cU+mIf oJ216gfFEAUTd9L1uC8Qph3mNHaqBA21pGIbUuIGJk5i79FlZy9yMyAUhsqy HB4mWLWAkSK6oiRGaNQEi92NIL/6PGWjKFtAgMQ3QDXsOO7IU3kdD+WGT5AJ fo+bjgWsRfFDv1AatNgGRXQU6JFi+P/sFNQn9rofJh0PonWFfyGcvTpoZSJj v0a0ep0HSuFx5xJljhYiY2ccNy+hhN5fHViUXBvsPZ19uMy1tJ34RZ60bWV+ /rNWv7m7sQsDyda4tQkYD0Ju1nexhMlkzyeyz1P9amEnqs6mz6e5nLCJ16aE JiY/xNsCvhInv5IgvD94ReZ8ZXJBwR28npeRQcHBQZNtb2kDuOZc6yciFede +w8wCmC44v7Q9wmkqPxW/gkRA/lA+Ez6YPl+UHd17XcXcfeJEZwBczFNAYX6 V6ZOa/sDDkFIyoKcenr6+p6YmpTw1K/NFbti98XiIcP7Jk2lndc5FKZjUDBg 22ILTqCin49m5DqSyGluseELTyHLoGFNoSFxCB4/xyWxUw0p/WLXN+a2xKZN h+CGWD7Jyre/7cRgQTeep9K1WN1F+j+70ltHEQK7sziLCjmAxvY1xns03k02 R76ijUI1GBBUxayDzEUhX77AtQN+Zl9ltypVYiDruS7A0IUbkyA6ZjKGvG9I t1i94l8KwS5qprxm5qXE4NLEwWJYpzHhrZXBNe5g0rHICDvivDVJnIQmyJrH pVtBigqIotiHNcktqtvM2ycgHTf3nQ/TPKcKtXoiDoWgqL9XFBEL423IWOQl Dp+n6uMopVmZovU6b2R7+VNBpzidHp3DTG4xqXv7nUc3neO59ql51nr+neYc ANy8vG64bXh+nR7Lgjc3PvWrzhI8h0Am6MhFphQGjc5pJCWfneAgLQo6ophF hjp1ZycnaUrNpVPPn4KnjqKfU75wIEZywdkS2ZjyGJ2W9tIlKABUv+IiH1fw xgPSBfrHH+upibaDBebHtL06OiT2Ozzm2KucaUBbsk1FdmSTjz2WcmV/9nci JkbhH8BMhi7TpmbBNCbAilvo2uscZMDzDoy9aiDk+50moa9VnacihiD2VNie W32whAa2pJzB9TBd52hnLQyW56+jIGbVew/IaJdwC4/DKDMrq9OCq/NjgSBN il2YxD8N7jgyQuPK4jWnqqFiWQWsQNR0svHjhiDJStQoYt32BSvK2gafaLc7 EG4pDllinCeOQVWgopoDENxhtJAs5VZ3oTximJYos2ZArXB0LSBmwCHw1/sd HJM4qYVJqA38MTJbLCwm66j1JkZ2IUCnvrxe7LW9fAwIyCzEiJ58gvkmp2C0 sl4y4YTGxFIppO8hSSukdULg5Sopq77bpjMcVPW2urMTbOx1JTWnJGVEJmtk utKskkgLuOtmPV4yJLJbMkBhvZNJzWx2jOGUSKHuwdt0gaeN96FlxRPwrFgy lFKmveEDsyAKomrKO+tVGKZkaeMlsuZb8HegJzbEpQmhEKTKU48/dnO7t6bU PC/WE+8fqw92smXrey8x7UHTyLhxPTtHSw62XBumQRrhoUahRLnd9g8A9cAF 7mt99VJ6r6c70LwSk5Fdcp8v9bW6RENoweWhoeTg4Y+SRntq3ifU6U3TtAgq qjVvn+sdxCCw7UsKaPbfP4khbyMzQkMJi6Y6y6iwbdIPR73LAzclXuF86PGI 7PYt00VVJyaEm/XDk8BVlEqJOQESoCKzWcaUGtZ8rqeZ0sm9JXIVMkeLterl O6i8/PTxmdgohMX3s97W9JYvEKJBC6Sb05jVFmBgjQUev+4+ZTvbO1YEYd/h 4X2njNIHi8eSr0/iPRjNI5QAzpgyP5mPsI86arWQMyJJPAGMLDN7FqQXslwU kN4sdgVhD61Go9oVRPgmK95QYTG7IbiMz30HJLugoWTkTxXAle5L7g7g5U8m //pAYHu99Ut4+mK9Yz4LRGVHtFxiDQxbirYZFiFcNS9iW2nCXrFSNZ3rNreA splXoadnabh6uEjdJmQxLUZUVI2mpuZ06q4+IP38vVCXOtCg/SATYDZk35Zb NLyszKg3EPYIsaLJlewkJ6dkNiZrqgvq4KNmWSs/fnXr4UaM1uConQ9TmIId IzhblmOmPeByc1+aBBN88etrRjrUDMvedeKdNhWP8SaL+ZCo2ohhGz9vvmEI JmiJin4nYs+68P/oJYW1sUTSenW/MLK6TartnO8jmVPcweJ7dOgz4Q5uZaaK 6PIUXdVohWtjhoXTIRBhJzQiT01XEz6jKzOjX9Pzsa3hxXkjDCEl1Ev9VaEZ asDjHgsc+sQLVdAuZamp6z9jYh/iLZLLRSzvT8knZYIu0iDI1GUlUU8ao6Rj cbVkZVYJHoWY+biBvu/ixdL2p8Wv2ysE3CXWiXsIh+Rj+NPIvKmC7+sNOb8m 7+0FBiIaYfMFpflmhCTJfKLaPI28Nr4j7KSiJopDbcRhJQohpYUg8YwVVWPj JJPp5UXwhKVIy4rY5D/FJiEH4i7rDEsEve5yIaXlULZdoG+Hrr9rM2KpvixG PxU8YQCli/WpqmeCQDejxnaFmjlU5sIhkD+flvYLqCZ0M4UmrxGin6kdPpjV FR1bPjDJoSsWFvAwLNVOLKy5uQi9yELhYidjNWgtkEiiZiW6YwWli4sLPGP9 VDVHBpYnuZU+pXOHrZYxii87BudzUaQKwuvUbB7uikAhZCAHYkaYq8qQMvMe ugrc5JqQJCYHSMki0+uMNmuiObbfsq/mZ7u6kMh4J0DVervHD/OlvExAptGG TT/IkYw9Amoq0VOOU7cS4KVzNqasNFOmx7lBS292hhdjn6AxFqed7gQV7ORV YUjQ4+mkfxfmC00/2hbroyKgtmYTX0szyoC/iSRur3i+owtqypb1ECY9n+O8 5lMljgqUWgJkSrxmuhTqIICG+3lwU6ydzaIQ7pjpCgaEtGACfRwrNvXqJfbv AwpBBDh0McvkDWPvo6GgsO9sMkq4i1Ey0SOCXVHarMXQSDFf4oFZMQk4g5/Y BpMdHk7XAs1NJKmPZu9v4FJOgSDE5B8CJf+knrHQpaJH3VH+SHfQA6ss3dEU 7LQ5r5hhbNZrkUnKeJemJF1QssyVspyo9G+nYdewP9kFjg+LsqVCPV3ISIOQ QW80oB6CIJ06P3p7LoadAQM92l4atxGOo6B0uN1yZW8HLTVnHOuO3ClmQSSi 4uwxI5RTLojilCdww7F2z4uHlFIYLZ1katgL6pu444o6hVI7R+Sj+91pkxN6 0uCFBz2OhfK6iKEU5LpHakLJZmsZyxBIuNqnJ4VyHwXtVObDhAmIp+ClKCY7 Qh4egWdaku++08cQi9YC5piyRZ2Lv3Q72p/qcfIYOD1ixXkTBa+e3andpLfq 2iu8gj1YesPynLxrrTUMsP+EYzrzyysphgVOqPWB4T+g/FWW6B7ND5d1tg1n vDkKgU8s4iNgd2XiKMWiy5Ci4vxPAWys2CRlQW6mYkIkxQJgY761E+Cm8Tz5 aCfEJjLT3AfLA4JseRfBRxe9dfyr4WsU4v3wgHbsvufV2ZVoDFzKg3VeW6HT IILj3Ekg7F7IAOHSjtrOHHWUpejx1GBJvIIDyeIhZoNwMqu34rCFN/F6RcAg hjbr2sugepiqCAAOuoqsa+X4gicXgdHF4Figf+s1LGU/S6csBNi8Ya4g4GRC YgPvZCGVphlfjG6FCqtuOaBkz8YxPWRBieKnxabXQem61mjXOcoMTavSAmYr oeU7jpieMcPcu46Iwaa1Nt1eSNhAZaCvoyRirN6T+O6ootJaqjwnv701giEO NkXXZtUeoT+nAiNnXifGV5A6tKJ+JR2RFW0mXNUTS3QG2hhEAmdLghM4Zf0Q RMtE5WWgiVuaEIBvfyVFp4QEpIIkDzAEDQYK1Gs3QO+SCltroZelI0UguKeO Ugz+WZYgymug/L0gp1mQImSF0r9mqjYhI0LSICAGPzda3WvUyX7vW45vUUA8 ICJBIEaVe/qJRZifsMjV7yQZdIkJT9XdNckPA9jjPIRJ6djjO408yaMAoV4C yD05aLxkDyUILkZj7CKMuyulIAHga9AhZqY8uDF862mxOOqFPeGjkbtZxeFg +JuYyqfNYmZPiEbjC2MTpD7iwyN/P8qnQAB9vN6cq5Pk/W/HiVtE7Oc/kufE hJ1T7zWna1TjniRsyEeVyl9o38gi3D+j6FH9xDzqHDwjpbbFJVHMuRol6CKv C6C7YQKGfld1iNYcSmZOr0agb9G+YSCEhyXpSAs+4aG+Z2K4bNVifsxjBvGl o5Fxk+sepR7LpqQDu3Gbj8jZHfK24Nb+ufmIKJi8OH7PoN2g4k+nd5Eme9c/ T6PKmFKdCr5XIi/3drLBun1mMFvkywm9q1pH8YckPW6gHa+2UqL12gMGSaBh ZSMot1OFOubJ3hbcYLxp2RBNo02WiQ0n4aqgk/224cMi3VGK2FpH9MeovOY8 P0P/Jkwni6My33OjPH0SshdUPOGmnQgyHxzhCttv/YwtNqAhMafYEqa6RCU7 V+K12JN9ljv/YaNUJxa9a8CW9evuAAYYBgiqud4IQ8pA2HLV+kVYgow3r3iL LNsjIaZ2oJ6KlKObbkGlVEqjIkOSZic/oM4+p/Y4Pabt6ZNhoQouGOFLguG8 f/FY7m+97X+VCbA7G9ja0hBEgeJmy2HmNBdV1TNlqedr5eVFRagb5tkZ5A5g s8DNCi/z/5ci7wCqxh/gNTT0t4ehRWGM81bZuvajOV1VkOChrCp67G83HT/A J6ekpxnEPGy5pWF9lIX2tCjGGGRFd0rsHeA1H7Lc3EbxIo0j25BYScdf6lEo pfFgW6ffeIjPQCtgJlz7aGrVYnJKHc/R3Wyb7kLxxPHkgOeE5takCsHtJpO9 KpAq0u6j5uSwaZzeIKdr9jaYjcWkAYcJk/KnJqV2y2pLMD+TA6tTmlXvyO3h HN/LDsTVDQ9tmFl5azNjyRhKRbSdYsbiWUHhKmln0LUb1cVUaKdyQyyzRBR3 pkABBoi66k6vumnM3VZ+qx+IjMjUBZBuS9DDxrFrz5RgQtjAn9Fjy3Sa01No HMcmrB68ak9FK6Agu2sene/ssr1+syDwHeZuZScymBWaKJW1L4U7anND8UXa vGqW7yim6eq8yGyIT9pmkAYLI+pI5Kw6IzS0WBHotjbqyUuWZ0250bChBWto YjqQQEu4OOGM5DKI7RXPyQLc5JjEOY6g3xoX7E7js26JNOS0suWo43szty/q SrdJNdXh4YfoFLtu9TTJVSTKfR6JlKZ2BXyWmhjn/ghFtrYga9bu5zSgIAcd YbQeCvo4MmCfFEpRhgsSPaK0mdXBPXezKi5ivcKh4GDmQxmFeCUPfR/neY/p In2gWrvd4wMPYA+gp5/bQqykY15ygvzVOIrWY1FOmoq/gO5UrKboRffGZat/ 6ACcowqxFgJcWfTBWWhJ40xxJramS1b0Pl0Qef9z5sdAx2D7Gr3LaKfPFXYE b7LWjGVQtFk8YFQOl8psPlOrstwBm9kCNidjndACFkmdqL82EDqvLYWcEYpS Revm0iaApDcvQWSJtlqZogIsO7sHDbJNr2/HXwejLWEQ5Xm5H/FysJ2DNzcI Pso8vUE542AHlKAmlVI+5PZU4Jvypdd4fI9K2eiIFM77OPK7tlWmYpnqvm6y Oe8WZX+YuA0+/1HxDRWQSRbuoZnjRdKZQR6D0qAj5fQWKDOQAAFMxlK65Mvg FjmHywgA3bs4ZUPNOYug7rAoaJlEA61eb7vZHBSjD97NMO7ZMvkrXBlAIRNL G5/E4s2Q5+xFvyDGkqXIQod9FhRdnj2mkJ23jMACpUdiy5gSNZ/A36BQIkqs oR10MhykY5+8kSYdh7+dgygdcjAchYtx5v8lKT+wqJEgHYYchKb6hRiORedk J6WOBYgSWNuXKYoxG+nK/j995s5BRFpioO8hhsfoXPmap7zK6XRFZ8jLP+7q 0J8ieft/KFnrVDvMEj2RCB2CoQITv5WFy3ewZzkVY9/t2vKyPbj4iufpVTFk FNZ6kpfSL9lTaMyci9rjJ8LC2/PhlCdwZ1q+jCAIWPezFMZ1ZUXGszW6yuE3 iPgESoTi9A4ew4aG6yImLJW0Hl+g+dgtyrPJqaFiUKJlnqIxozE0Bvytapy5 xqe9ZXI4RRcAXCqlXSAmGA9xFdj+lj2UD7nX/YOQvy20O0V/9YfdIrpds8nL nFU8fHM/i6Kdf9LxVT0YtKSvnTXgFYQt71HCvYciEQbeTZ5nVbLnqrJ1KWQl Dp0euDcBfSYZ8S8zs9ZJnIdXCZez9RKG9UmhwOuG86c6ZVGlCqPr2CBLGSdZ cI29sNiRClGHFGigIdA51loYcZ4IRiXHsPuqEfFtQaDUsyU5p2JFdMQdJzW0 iRm08aBwMLWuDBefn0o34DFHLzHGJ/B6mM6+Tp+jCIqdWRLrHXtEAome2ba4 ZSa4zh699iJG3rfYjcssJ1VQQdS9M6ocUGJnumbPFyOF0mF8C5RYIZSW4+ZO WzJCTHJsRyLYKbUcrEuyUZXYWev31gtS0+4AQ9Sg1crS1ytkoP1m90jWp1c9 MNbOAzW6TLC2Qg5Bbr0y/WF++gWj5aXsJf+hCC1vIJjn14Jw9kXAh1s3RQuH vOf38vJlIZw+4xQPbLlJhcG2x7Au9vAhRtlUJGPJ7iLWGC8mndLVfB8MNviM rQ4qXOMdU50ez38ERljiLSCOrYe6ipjRYKWc60CPjz+LDPAxYqtRIA21tf28 bhwYGUf3Tfa37H7M/nmesLjfwzXBP+J51363Xr3hCKM24geGBbD9HTEk/TT/ 7h8MkGOIJXBSvPKjGB2f8vjd1v05ys14f58HOn/7KH2wrmfh5/kCjyXAtMqI nQ2qz8aYQaqwFd0A3i28vB+TocadlbHLpoI1ITyamz9E9PuiuQikJSglpUkG HCxazH0mVk91khehiYSfC0SzvTLujzKiNIwARE+RoD45Z8z6rQyNhdHizvqz fP4wTR0QFt5wLD3TxYgfd0u0Pw+JmpmiXhyAVCVRaX0d9AUnItf1ZDb0p0e6 BnsjWWj8xrtRU8MjUGtnBcVzijQ5uDeebgCqsgAIIrShBV+NP88l+kxgUmaJ TxG1zs/mEDx8E7OdPYcFhnT3MWEdXCCZPcSePvUNPZ0so/Y5GxjCjjV+uBo4 Pj7p9KS1niaMnWMHN7UdsVKZzaLVAEY+R0YlzHblIDiPHkhEpRk/GyCjRX3Z p0W2oqW80X6HNr2eLnI4Pc+eJxOKjoUP4MTBiqI3PhSyGZU3NWUXpUfB5aOK h/+a/HxtP+6BncVaYyYWfoBh4vIfoELkfrjBFSVjxye9pvr0rqbJatxGtrGn JqegmsbIshWCgGADLafsoV89daPQPFaTGabHUeK7GRS0EAXbHSaGb16CFEh3 GdahJ7jM4T0LUJ26yHAaIT3fFSEuqxcQFCSZCIKdmZVlx6genDmfbKc1lgz9 GFTaMaOWKgh6liMkbJJIiwKnaLOfs+aDveZRl28sSkvnt5GDGGjSjaCHUu9E P4rqPnxSuwv1vDIjR6gyYLeMITZsHJsmx5iM3y/AFnWgJXsdBWA3PQ49dk0H ALL3CoaQ4LnA6rRJKhSTVETsrLlEZTJRYbKBbzmlIFXURau2v1K2BwgjIJxS O89gbNknyoavI6BbzqD3+nuggwFrjPMxQ5RoJ/42bqlMoGnbgyMxmhcoPe6F RmI4hWemLBRkCM7od7SPtMrwRdvjO2kDX7X55vk6SD8jBdGVcbS+emUlxTA8 hOcmBxKD4EEQjbY/C55jOzOb46Lm4+3DbffhHjKXuef5jglsuJIbV8MVeAa2 m5gg4Am4Xren7eD+R1uhZlda0535O70+O3mkW098cobIpq0Hom0RqOvj1SxZ xxoh2r4WocaQidnfhbZKNBBmfA0zjLMSu6ACR+HxhV4vPG67R30mdAsqNaad 5xQ4SVqsMEEaracHtzHJHZ6dnqDHwH6/Bg25ouMst5x40g/SMbc32VYVWhXY ubQ4RyMdVKFN3ruFKqscyajiPf1sjdzAqP31tZo3qQCBjVI+bRWUZ/9JPS1p h5Vx+fdRBDAtpiY9urfPChLyEctB3Go/szTVEzFkZiabWZFYBcXlJm/XM/SM PRVKzYs6Cprv3K+6SjzIihLJNr+jYc6AvhXBXuD1W2Wdu9e+4AyiEX6SYYSU vV/PgycHmFPJjQ4GNDK/xHG1OTqE5JQHZ8nHqqXGhFr4JqF5yyX9hsCfTpAd h1YlRAE9HB6Ot2Kk4bzLJB/jOTodlH1rGMQdRP/xfOpSFiq/B/E1Ib+Fcaa4 ASiY8U0g6aE4qboLsgCLOB1wJjmePTmeIrIhpqO4xeg0HVc3Pmxi5PljwpIM M4fVcWnfQqSwSEcFZXjylyWRSTiApfcmTbQ1zpYE1XcJs208WGCevOklFfyl wOUbrjN9QTO3duU6sX5i/40WXGUThLtTZ/6BtYCTbzkdA6CHnE2VijwhqBxc g3wMu+DlgqScAUDqIvk2siKwzY01oZMwBsfszfeMtIzKtTLcDLm1YwxUYwIG b/a9cYmFyyBhtydjk1OutVvMgUCkOX6G4Z7nkV+a8q9XkRGh+f/0Re0mPklE tY3/QEunZiE6drbMQT3HvzU8sQi1J7lnPjunOvMjU2WdmtqN7oq0GqZi2Ml6 JtjA3ZElZgHjnsu93z/NtRCtDFXfCs5yveMgJMEhCrKjXAdn8mUDUoSqbjgp HionofMHIR7BPvxZfDsdlZdKPbXlibYyrqF31QAQHkPTmD9kdYKkLF+KJhhA 54/9pq1gc6L6qChn2w4tKvNEay/UnpgpNAcdDSSfcCcjrTr+JR63m1JBGIV+ Dp1qhCAopxygEmXlBcUg5EZQf/QpNtFGkZyosCMlOTuZ8qphijY6Oe78NthA LWgAOrw7JbnuBoqHpuJG/JRAD6id1zU9fvSn3uTm8je61eLJIxW4HXNGI7Nd oBTAu0crZUtjobYUqyUHLbT8alqReDTcsjW1a11YlOinOyGGae2dw1Xd71A0 5gut/5KtfR8eJEMxKbZ4U731AJcpcdwd972wivQ5O7o8ZCUevQMGY+GsvDxq tAixHoSaOjU9T4IHn7nr8AvIunCngzxH2NbDCK3R4i42mka4+QBVX9A8pUXG 56X0fIAcgaHlf8E9Yyky6Ee9mDJYWuU01ZOXOsUvckUUNt2Ec71ZEp398qI4 NQAw0re28D+gUtD9kgWpaxgfnYcdGTynam/KBULW5TIIigIqMaGZPblU+s4G L7IRM6bhLH07KBQGEBz4y/B2FqIRHmHsHflVgREsn+2otEWCKBGKGEQn4bir lRhChYrghTw8YeIHy99dAwDSW+M/Wy21PWWiGkYfAK41BFR+pT5GmXt7un39 IONMewdMEjRCWvBXwX85W4wmjSZ8+/423KbdJy2gmA5uAq0gdfXj+86wvCdl vSdUmllBf9XMjk0TWf/7HBAdvaOCfFMWv3/FJ8Wn3EzTF6WkhxWVlcxX00Lq NYO07WmbIVy57SeCpyUNwQBFMuWmWGQteOucsyWzJdy6y01chineIqED2DoN LnsinSIfwADSYWpKkD4ZIbMalCGA1+fFMr6hnrWjS1yjjsHqijb7jhb0hyAh t4WxHRLgX5eThYgSoGimh+R4kibyXklwlRYFFoK8GSMPmYhOuU7nXwXDIQe0 SZhiWevbL9ncBzcJ9eofwRgttOb+YIfOoCVr9IUTLQqVcmu+46d4BUNPhzs/ 7v6aagQgRKCnHo9liLGdIH8GuetVS3DNqCGDtAwc+O/1yxAiEBbxQKwm1OZj mvGz2aXlaoeHZbLNBXmjiZyTOM4V7qrAIawa/bBBiKaPlbJ4oDW0BxY49Zq6 qfSaGD2TQhD9CJS+vfTXod3RU6U2ZlPvwaI9HIu+h7fQyrGFBzYnztgjpBv7 kweCN4vR6h+RYJZf8j5wzCNepyYWi1iCsy/bOSPVlwO5WGRYLHocsSodmB4F brOI8oVBBUJwNVwVUZ+ue8/Bh5EdkB6VllGL26N4ZJ+MdmC/E1P68Z3MLI2/ VY46jhKiHZRVADQ4FOgx2VJtUh0Wy6mkHmWH9bfTqDD1CH1jM66rIc7JtgkE X8kK7nhjwiWXMk35BmI1To0mG4A1T71ZO6b756PZPqJpMLEhQDyNaHNVNQVC 7dRoANNW9vId8g1Yu2I/Pjpx+yUU9qiqoQcknpBAHeyHE2eaiY9GCiVXlYzo 30ePJZ2GysaImP7TD+Pp2UH9/p2e5xIlnACIyTeY1CR1ibV4Au0KuCa+7abt DiZYCnwifaenLqDX5aPlp/YgtbAXISA5oLZpNDihV6Y0RvWbjCHj34YhOSZp TyCitMGnQBggIkanrkVgBSP1pqB9Po6no5Ggpol8ojy3PUGmiTxvJ4wFnMG9 CSe9uYOthGYmenKnC2rlngS178OmI5C90qKejlKSv00jA9VNYBwy1Z5Fyq8/ 09FcY2aGnIo6nLupvb3bpS8aNzJZF3w0kwkG+ofm63FJcJUMJB2wa9V7oASU nHaspK6mLFclRuGE/SKNlTzhvCIS0OoPmbxYEzUdXZuTOcROOHr/7bruOe/k 4INZQI6PEcT9qX/X4CZ48cQhHQo0GWI2JvapJbOx0OStuPhoiFJm0jpYArjO QxxBSHPMjGMHjZ4zZoaRuDko4DQ6PLUh0BPSo6/4D7qDHLjWEp6mJdLJtRU/ Kh6uJdWyRtFLsdXJ8RWwe7DNCW6+pw+3naWq6bmHOxg6WiQ1fRozqAimpV2W d82kAmWFPey/tB6YaqAfYU1hzfasMMM/x7hPbDtBvUfZNYsxWYRVe6xq7lUi dyYcbFRS7s3QI9w1F6SBFGkZUAgdkhkffru+24U8nRiEMAZAZ53pUmJmnPyh IrWQOEx2hVE9LR3mJ5VZZ/Y/sXYz+j14sXc9Mee/lwCAnavvhyf/VfmGnaEF i5lo538oUrYFPDmnPS0laSI026kdNT8PvlujhJF9Z/WLvb39IHrlr7ppdDll IaLWyExhmjEnKARfu2blcXMUbyEOZzCl0UQCxm2nuWZeJSXkpj8DKmNOoR6S Hf82aIvr7zpvy8PUF2bpPIXizj40vcOlPD8sogJwQUylPW5lp6wz1j3wiwe1 GsbspkSyDsVRwQ5Tp4xqJ/HcojA7lbKOXrFVpIfP7jhkijmz76UHJYRSYnYG Pwy0ZsvmUeIqPbzlVOU/8oMrWMalvK2h06onBA71OU6OOHEdviBMnIPBNYol wp+dnrSlY2L7oj0Qf3gOdnuxpv219beDP0+HYwcVALMls0qlu1v9050cMwPv nklGvpIOKGKeO6Wd4U5RtmCop6TvNLCvA8WMbSYmjgvJolGxRCJsNSJw7Zzu JeY+AEOh7pQvU+q/jDxh2Aqkb5x0cwwHWIkNp+VkL6obmGI7JyDPsuJ/a4d1 mem085O3I7PKJsWM14stuLkyL29fUpyZFaZwEripC0l84fNiOR9V5SjSiwMM qAynLZ6h/badYduei7+IubPGA90/h693BWmMqxa4RUU/ijLY9f99F6n8j4Vz Y0TqYLmXsw0ASeQjhSUeuSN6M7eFwz/7OCW1BXk89DSEeeeTQnYdvHaCZL6H DWXiH7jpXzLPnbcf48QJYaUmH3LBWdOmyQBXt51AATIZM72mgMXmFuLG6Ks1 ufDSJ5LCxT3rWqJruNhChb2dNAOyrr3OQoFEAzC2CdEynirxGaYCIU60omK7 t7TkGYdqOHIN+mD2G6Y4XoabTfhYJjOfOZkw97h6cmB+Hcv+pXn2sYANFYcY R5K144gCmgXIhwjAsumFVrUGLyPiHu0hEtc8QTC+lj3s579gI57SJD8/i4fv bNye/ra44SHnGOq2PkK+Dks4BFcoo29ugz4XnpTjB25ZNRybnQOJH8E34AMJ grc1YALthr6L5dYG0G4jHe56ky6GiNJe87iPK4f7vrlrgw8/fRR8ByayJQB9 FoahT7RBMB8N31AH/XJ9lsU8rSW0uoYTQYC3GpyiHZW/P5b9VxeJf8yeJUca jjxSFlDpzgyJftfpSduL74ILYVhhgn9QC2VYCwSlJjZM77ydGJ8tpgWfudJO /Ijp5kKgsbxnNNOHYFUCnNJehzize0SVPqIjYiIQL1zmZYAdO4wloaUHJAUP tDzOEQPkZP0bXaghjz2M1F4mRUMh5KNzpiNlxaQvzJ2z9uGc5Mdula4cQBdv IByRTvQKO6RHhvJyMgGiWUS1zZeBHCePmPHGIUKDb4LnJba+ZUu8f0XGnP6m 1m22TO0gev8jKe88MR4mDd+JmHvctbEgLUWB7yHulUgG1zqJ4bBrASKmJvt9 kAMlHWGbKGw2Mp9LJoAhGYQOCYHfhwyaO2smsCljtlKbOCbYDwPeeRUglxoR Nco1B6x9E3b/7HYsOTUZeKC/RjUDEMo6O1CFxKyGzeWN6w7OMzebzME9pozF QKFZsebFhUtf5j2yPOaSIJidXyW4nhhfZ3FmnT0iNlGdHs7JnHZQnraUnfCB ldoWyYqxhaU8qiB2GLw2sRUE42++Obs65F1ewWYamVkGf6LmeuSk5MV/Q6Xf bZOMKRhYlhMlt7ne5039E6WiBXpwnG6+CqaDJ/D2HSIn0m1d3wM34+JpIZiq /XkeF9RSCeg1IwIdLCY1Evqzon11Jc5o4wemuBK0EguUMbg/FuqdoxkPDGIE fj2ivGj60Mfef+XXt+TpJwm7siocZsOqhyBn29UOZuxei2+cpSDhVXs/573+ mQK7EnOSpd4xRzy1ID8wl2Xofbkj+1VulKYT4hbcCzU0pj+DsfA4yJ5H6jtJ opdv3TMs4J32m1InTcqjoRBirL5fvSQTYUHgk7DqJWYCNnolvX85WwiVDnnm nb49VWcbA7m/96J5STDlJiJr6ygpEWEOlkVxorsP6wkhnC2ezMxVPaFppSW+ Tf3NcKIcpDfsfydVff19fdtZ3119/f19wkDGRH19fX3KSM7kff19/XLwdvS2 NvR9evicdAKABwcHCx2PDbGzRXxrAJUeoaNDJVUj4JEdYVwh7j9lM6IKr0qx PLO85yU47lKycEeotzETIuJVRIUnncbHpyQF7T2/JTnNrwYEjb7fZqDpGaBH +fU7h7W7IL7uJaOdKFS5W1sfcaXNeuGX0BbP7B86G6sXrFBPGZXVmWajHvg1 J5A2lqz8v2Fiov0sYSGjV1Op0tsz9RgA4iV2sV3h2Qk7aCfEelqp7yMT2qYG mblkqWRbx73tv+ygI0vb0WGHSOx1z/KmVA+i1qF7Ha4LRhIm/caeC46nJM/x QaUdEwhijWFvS9Msq2LkCzXvigAh4iCKxu4miiMuPqe/k2qEtO+tXlyDuOpV MMC0LwddNj28yLbSo87cBOwyNWhZUq8Sohl1nqhysD/xnD9z+IbptVZ5HXzd 7V+0XJQhYfvPuckZloI/ooyMs+B1j43Nu9QnM4+FTMsm53IF04xUunaHl+D7 HeVoShSLfZ1mT++/BjkYpgDoM9q8JaIg9TrI5KGap3ds+ozvJmSwTsPCG1Ay MKSysLsByNYHXzoCbKNh8wvyUzUcGQ+ZwUDoBZAigzJAIKd1s5HxuzAMkKk4 SDSZPLzPnKUmBabDUOVPqCEiQqc7F/IJWahn5Nzf4T3ht8a981thFAZRuL0n 7U6FT4SgvaG29/WHPSbInSxEO3qvkSQVTbqD2AWfAMa/vbpcwS/ujjdfT7oh 7THZKXb2Zm1SH/HVm0qUQR1k2qYkOWiDIChJUzVS476gj58rTaGFIbqhGmOp rVPB8pLSSKbiIyhFGFLxrOZbxCjvI4qtvGZbIlJju432TFvyy+ZcDOdzH9+w FZsmyY/YbGwsB69igadggz4exZwhcJZqFlW1duSZtgprKgZ5UXdqZBqHAIbS GUe7Qu+HijFAeOpo7mTjkRb5GTTBB4XKiCfPN7QHq+GgOfk4jchaPRmI4sYh OD5T2nSs+YY8ZdKhim8HieEHPrmKB3PvMaRHxQVS+TOUev5i0Di6UUjoSdnv IO4hXyDtOMQJsM5iuWGPgVGiJGNgN4uhD15AcePc5IRAB52dxYLT9/cDuWaB wpcrJZxdIjMw9K7VTpOs8wO6vObJV6wjzD4DXohvtOOAJbT8+tBaa6jeScWg Nt1vggrdYPwxhyifU8zniGuppYUIMtwFd8iIRI+IvNaERVaF2CabP8Yhk8hf MMYWsu6b6tkkSCvUUyUygyCJgyprnFKN1I6ligO/7gbjCyZfeGxoaG6KYrjg uwceOcaPuxQSCqPeNj0g2C0YxvGkGrmF0YTnWnIfTw1up1SzyyfGc4dSv6cq trNjF/18CmNEkPC5EzcxY0MtFsfM/TQl87vRR7aiCxfg5hanl/GQhaZ9us9I EKfUmLxLzgCiOx1hUs0K4wUPTNfL2nLmpqejzFw0QDLHCYesmRgass8gLzLH kkUdiq2aRaDmPJ21vVs8Kp8ONxY7BrfBvW2XgsgmWYoorPXEzvzwfJZucTTd 5nUwZ4oNd/yrE8YqWzQA8d3nl1ZSn2aqmm8ikhwVYXUn1jznuBTYEd2RskWB 8RpN1XOMv0ruG2GlZCXvPFtsABXor78AHVLJIyHoU6JkmG4K5O4Asqllg4Xk s5FzYzqtpZlShjU6MoaVusCUs7zkyDngPSOlZLEBu3e3qKVPoCuxCSUkjiim QArftfTw5OckizBIoyXtbZArYbDvunbPJkeJDtAObYE3KLc9CY1vqSLY1dGQ lNkyK+9Z+/DANezRtVyIY5umJcRcX5nHQMDopUG2s9/YSb7aYrQgu0oGkl0U EpEybwukEnkGTLv1lEy11V1rmZ05+hJT2CE2EasJl9EoZrId4LYhr2/qRejz CGXr5jUlKMaTCvXlepJSSOfuHsgoko35w1verRBLUVuvY+806jFS0mBjnD+p 7rPiXaIC9KY4xSlBQYe4LkgmGoUkzpWiBOA9UrNmUmJLDCnotvmDLxYD54BU pyd/o6CEz5UYBUGgCq3usMSH7WLD1T2FNr9irjatEyqPuqHCuW1RDooj2AUg VCCEIu/22CCqRpbt8AXm0DVvgABuOCFpaWlqoe49JqNvoyduoLpupkQI74hT P0anJjTrIqBka3sFREsnvblYA6xPFW2nrPD4EY1mHZsE2+8uC4eFYHNAfO9c ymrC7zgKQfiU1aD4VzzmUFApJiPSWI7L7OS7iqlvizLvsjZvoMhNzWqnHAfP tXSHHjmpIp3aBTYetArF26oDB1v7HO/fDe/5CKNuO6DzB2XyfWm3m4+4u9g0 0i7SoRsFUiK7GthnPJ8qqQXrsRkiVFGpmuQm0rQQ3NRHoRzdmGQXJi0op9I9 X1mi0KXyaxEdb9NZeBY1ahGrN1pjgS5/HR4kNXUEevieNokat4qqZDfs2M1v qjI2YlKJdYjqaWiijZ23jP696yCRqh0m0NTSWK8Hpjxvv9T8YDUGIyEQdell KOOnp1KP4qC+qlW8stzfub8iOvO9pY6qvhJYkFQQKSAjhqcQKuzRzRhhjfB2 d0LPkuMZ6rumqS1Yt3pLALYfggueDAVYH//OIeViS2+Houa+N+nIpCikE//G pi2E0lOKQAYu76NlaSTpoMCq3sShkGCKLm83uTcPCsaZQyFlmDX8tU098wop ERuO+W9muTBbgD8sm77YgLMzRcwfvYE8BjcWA5B4FKNUo6V/IWtaJd7ZkKzZ b6NekPIri2TvOp2+iWa6+U3RyBa40abPYiOJ+R94Ky8PNUugbyzrPiTvbxKk oCb5/I91pgFl2WEmwIkDgQtrmpXVxrO7b7DqIWZYynAasKoPJjdhiyalEuZm sy+kwqG/peZYB0L/Pqa/XwTvCmczWufqLTlX5DI7rNldHaanhtK5uh1VR97V qiIzvgElsVXVWlhhvz1nWjnaMFUX1Plvo9qmnVIR6SOzx40yC8LPsQ+TAOQo GeUrJQlrgQNoNeSKdrofC+hYJ9EYb9/kdg+9M9cTyOUcYWNSgfgKyGyGPpKE IT4lGQssErnkgBlrvNEVjTcCOFcQnQjxqYhjpXY6vyo/3jiEF03dJlG9mFzo Yc465TKH8ioPbT8kupalYR3fO5OWnKiZN7orlQcASh6pnRnlF6qbXsk/8hzb KurbtI8/hOr/HGTLuu69S6OdTye1vo8SPuQC5gklZKPJkqH0E24fE+pStziL vfr1rRgFYSYFzcWnB1fFC62Ip2/dFg1XXxbXR1WSlv0xs1VqmBKmgCFiGLlN XL015BkU0RrGm7daxTdH6rwApQfqb0pM/j4Aa91q7sl9UxOIpeKg58IMtc8J rSV5fcTEJoBSQjsjbA9D5cqgeC+BNHeMIQi7/q+YquM1ljob76B9IgljH5+1 keeb0xE56SLtzyBs9WzAHNnTffYXFbepQCX6Sexl6KMuqz0uKmYVxJyMCE0t K4gifg1UEym1MKsclKZq7Irh+6c8v29g1RvHjP8lG9K8BHNfSJU+1Ynq/BjB cKcNcI6ZV23c+SCTFCrUbqMYz7LaoPZWayPvSrFtCbuQVICnIKenP1dqjL3W U2Ujwf2UvoYydJBEZOSkt3gc76Ij+xd2o5iSj+EKrpe5kL8WsK3oZauolG5R Srb4LpnmVa3DtiLBea1iq7xTYTsIeWzVjfZkOYhx7W9kGNNE7NR4f46kCO9s 1+EPwskG4cosJxnviGUqIBNuDL3Qrd8es7CmNO45Ie7XYM/YC6o7YZUOpEBI pA+HMCfgYLiUBQm5b0EMlAo5qXRQwu4/PaKLJ9SeXGwi2VA24boSbw7o5yaN 1xGpU0shBR7OND7t/1wLHOTToQRy+Mva+s8k9tp3ZgvT3oU4DMVvDdMqt0C1 LmsZwLWYnb+yRpk/obWhvMQ8uZkzODqiq2TYdDxsse6ZVKGjo8b6cqgHBHYk 3mOpWGV0hwziIAs1BSG/JsTUrwDSrhEnCgT//TXVMOcz4wCgPx2wyx+qmeQ+ co6ETz/K2LyNIUFmoLxSMZEnzk5gaoqI7ji8jANvg1NoIORiUbVufSJvoAzg FE7uLP5nbndJbHzGxnWg/eygGGRtzSKV8Rph3BGLIZitqbPhPoi6YryYyoJi RljstokiSTmaRq7J3VRxrhAU74m6EEVVYGILuEdh9AMjbprLt0Nk1D/VYeUl FtXbVqSnvLdSJR6jaboanPEwVSHXhgAKlKd/Dm9NCZ0apqnxiTWKRRM6t1ce d2XFIXhcYbienbW8F5J2taeSWMa7nJ2FOsdvNUlIpszlKow1otR6ksrssiSC HIM+6O4jWwBIXabFIbmg+7wgPJPNjI615e4IkxguvlRAr+whE5+jP4rUEYeH SJHtMYNvXforTMT+3KTShcSa5suuAu/shRJ4ewtRo3KHvDdAf3Jqv4cEWhEl Tl0oJiaoWLrFoDUNBcYjsR/LtUCiaybb15QirWscsotk584f1cY3DqwJjrxB yFp7ts+wPCff4SVYSJ1fMzGy2/wPe0FnFI+39h0hbHVyhXlotWMDVzKg5aI9 wSYFqm1id3aXPAq1/gBlcU9rsnB3aJ42V38W+myO6AdRp9LSsLukj0IZFYW9 JjgktIQ6T7Y5oXIrfiIg7Ko2+bj2YaB52Zp4mYeDtQLjcsMpOEN39+I/maGW ZqFLn2JrDUmkSWfUpRCXCm90P6Gr0pq/Ea6xOB48orfDJJMvmQBmxTyKqmtZ 0qYvBod8MB6iylRVgWuGJ+NuoiW8yMnAgGdBOgOWBsRrEQFvJiXedaY/AICp gvcD6p7MwycKBzhoASdcz6RnOZ6AAJiLqSIZhw+Ztsh1mYKyNTg4vZi9o4Ry uMShyMoVJIMC5PjTQS+//aaqqy12oV/pCjjZopms4P4b4wCiNAATJz08Z1KQ 8bQX1MCKqO+SApx8tVocA8DrFsIj//6gCYOj6AWYkkAPCQCDC4AdmQMcX+w5 szI9bwnd2E/dRyx606HKJnIJ3mcME+Y1niONagxLh0H5STW8jh+KVl7ICCE5 P6N6hu/I1pI48wgujKZF/CSENO8hI3ltvG6wSOge1secsYQA1Dw8e48ozYwK Md5iBCDRc+3Ov2VhjIdZZJ6JAZMyWSV1+FfIZCHbGsM+04MwNJLfvGPrIAsb T0U00zzbgyAd27aVipmmYkXpkd64EYNalyw0VblnuRG8GWrN8kKkiW00hA5Z G0705aYjbQPJ2O8hIabVTTTpMtTCk3LAcIGu2ScgZ0agTyq+HxuxPOOOatLG qBUnVKPuMhtVJG0nTljVIdgi27fVLS1ynDE6ktj1z9x6WiA7CevZGPb1icpl ZpW3kSFtSEOYqQTmkaSAmnOTGvUEwYtqpM14qyhBynxxb4aJGGkA93CA5UwA jBj5kQrseiwTfQ+4g2djoEbRx/XLa4C0BRjhlv8297plZz1zP8SPHRRwmGED TEOhnMgT53Kho5zOgIphJVOj1rjURSWKRXvQ2X8C4tI9j5lukT4/7hL/Kh1z s7MPWLW1twkg9NHMDxlIk28xtsuQxZdl0NnvIpuPZvxAomZZGfI1gmfByLWc F2L9Ky5rNiLjY4YQPR6h0LojvyEUlMFkGcHN2XcTZWt4EG8N9ALwk/s/b+XK U7brseIWPKtmCBP1Gs7kgCUlsb4Xw0WuQzMAbwAQi2948d/CScaOw91wBhAn BijJWPir0Z2TTSC6yiE28YNQ2S6IydMmdtJNJ0D3YvwgkDzQG09xjfjt0O+j lrNP/gc0P3qqL2RIBuzjnmOZ5Ka5a4Zg+5dFtGsBLPE1nnaNQj8lDeNZU6Di go1C88y3CTOBbtOLM9XlgMFkpd/D24sP3qFSWsO3gI/odQvdi+uO5lxm3O6c sBwFwx1JhNuUitZJYQrA4cdB5kw22hiFKSALbpKw7O4nv6S39Kb6wXsngjO5 092gc4sz2EamD7ElxbT62nk+Gaq3Q21OF4uoGvhuzo8q4nskv5A3JjC2RIE7 j59oLOfB86UHg1/eVYulOHa4baJ5KOaiVsk0BnhrRe+XxzGdGWhGi1VFnWFZ L74PWIeq/yAEnwjHqFTnIjEbuILrvbPDIQDsC74ftxN7VT+TUxPaJnuzD2dy jEtdS8g+zw6RtSzyvGAIRAI8gy/hVja87m5aKKKxXCAdYwAJDD3q+wOl74S9 p9Nm2zL2AAoyWM4wOAPkzESYEOmjCZ3L0JjPSnuhJkHJ0jNcePwYwG+B7qAk WGOGj0fsQJNPE9rCiSfy7I5zFxgwmd1+rkSgleAvrqdvIKdvgkYzGY1PWD20 LG8oEZ7qeDQCeWyedIDw80/1M/cWISgF9M44tkxJHyLwtQGPFh6zBzmMbhqi D6ampM8lChx6cp+eDcQ9Xjyi4zNf1629fP7EGFKLAZhS8J8mYJRRWmrmk0I1 IfJteVMR/lKCD/TlfAwnHfaelN5qGvnabqv3pQwKg44JZhC5JTthk6PqDTwm IgC2fDCSF+A++w1HRYO+EogCE8/FvEPlKMdLuLyWZMympZGBoeef2IXvjkkt stmC9/+Jb1lJP6mtyLghI1qcwqVvle6+3G+Jj0Qnb4kwuyamiKhKl+Uc+ael v4CFOspTnM6Auclra9JDoulnUuhNlp6hRJk5Up2n4qc6lbfpj/jpmnDGwbQ/ p1wkyxMN0cy+7qUcFaLit6PuTVKhoJUT5bRiNSKzPG6xPgth5e4ebxn+PpBO oBvGZCNG3URlIJsLao3+kaznECAsZvE9p3WcxOsgzda1h1KjnDREj8+Ng7dv Lcgxo+tSEYXs878TaI9ZRWiio2JOEPUnnbu59ZYOI0pQ0LZlFFhTQmaTDSLB AOJc19Lk8vNgZVXwl04kxVY+okFjZFqBW/dhoyjROIU0KyzGvbrUuSIi3WLh OPHNKYZjBRGBx9Cmb+kMqwJTG4jqDjpjhqIJBzFoFKSzI7ufgpheealafWwA obz2of6mYlt1GBievllTEXUauMK8KbmYkLM8mB4mqj5PA40hm0mmTcHjyEmb LiLFYQAgipjGuWGtTFbl/AGHa0yGsZGGAgz0o71VfbcOwshO21y1Jilj6byR VYbGELkO2riJOyhoWqVhI+7uILjuExridxpxyFoynAcdljml6k0LCkYVbBKi 00EWJhMe01mgXsYAu6G9wB3kIzT9tuQ5nZLyMWlodbSv4Q4DKRFBH4VmGPZh ocPA/RHjO7AVyr7LFkh3IdcYJOwN9r0nyQW68bxWZBGqW6vbIVmhrGKg4Z+v Y59WOKwdy16YSiCpHsSh0+uIrX8KYbwfIyfXkhDwc7p2xV/vJE6194UlO51b tJycdXx5OaYbKbMzoDely6TravrixpQYjj2lrt3hciXMpTITeJX2qjhv45Qj xJPi/vXLGudA76cMK0+VMEM9GlSwd0gSD4aJtsQ4Eoq5PxAbjpGn2T26VNui 0Yu8NqJuIwSiJjNdsL+WAEPzDye7KUZeeBM7FVsT8YMcZ3IrejjCMLYj9abD itk8YDclEAT2Yz8zeKIlxVhQsYG1QOeYCCZjF7wGvSbZ0pVv0ujDxRie9Iu/ BUzjBybDj+rBRB53mFz/JQaGvyVCusSSvdJWcEExhmNXJUDvJhqLpmUK2VYe fGLFrtTPXfKR3/gL7SaigqWi9u0LHVBJ3wid6TSz6JlNt76XUOJzEYo3sSeG jLCOt+e79TznY7GFFTVOOICFVLFxFUQSWWM8Zvpztmu44aX561xeZC4h3z5L I5ORwM8wtYA74YJpHKZrijOWsDfvtmNnlZhk0bHrs+UgaAwet2zolrylUr1q bFIHzLgEur6tVB3xPXiTl2S3gmlNDVrulW66vwwOxA49rVIggiVHbH2zUccb Ud6uNnWhvSEpwRidHd8L4jVla6YEsFkYSRn1qLCMm2GkzVTSo8WeJ5ljp4QZ Oda/gwOTdvnU94E3ZECYGH0xgKv6GFna67qiiORaJAYgZeuJpDPLY4FJuWsm i4TkbT2mQEedXKbKzZObDkSfyK98VIW6LQTpSkXFAyLuzfYnER5f25n2yUu0 PC4W/SMjH8C/IpcgKITHhn2Llyf/UqBPN1W0oBPu4uUPJrrPWTQ40skY7OwK b17gRQ01Bt/Rd7lJzQ28M5Z2nl/nl6OkNKW7VY/UhweQtfeNuZQ/J5r0mFZj r70335Cepks1VRPOX4Gplzx8jsnFB6F+dBtA9clOvDafT6bTJYe6eTdJl7Y6 t6HQe6OizRgLTXJWSIWADWSnHnlq9ymPIYXfvKA9BONhyEsUMGE6p83o2DQv 1TYQIQhvxUytNpop8gFUcycLPWvenza4dGg8LIs8ueSIijbuDeLUjqUSt9vU OBvqSqAGmiTf37qLh03ryFshpAOqmWu7JRnkQbo2cEbaSgo7tO61htTtH09Z AxiSkEgm/E26BdpkDJWxtNDU3hkCsUOZvlK2I+v/5hni4jze0leEPedDWrSY qjSEWHapo5zntD45WR2/eFR7UNgjpzrW7OfDFBSapi6iIJwSpQMQoQD+naHZ g4iRozkGYDxaItUS7ec172047DwdfDkgvwmlxbMDvKG5gpsTyBWB78KVBQ6k kDlGpaT/GZnZFFswNUWSD1qPl2sNIRgVtuiym1zeptbOOzq1NFJw0I9HO5M8 pks5RrKlIxpuW2UsgZ38vZM7R2XLNGatk5nMoJgH88/Dj1RsA6WgJoMgfFvW ktAmJTBSn43lIwZNoBfWcZVlLbhSjqW9WJgUrLV6OoeG4dDxl5JfB1OnnMUD AewOPRNiIoV/xCVFF5kADBJZ5rUlmibFW5E3bs/SBMmYyogHrybkrxVjs8SA gD0vXwy7vSeSIicZGGHJ7Hr7tYfTmer/Jf/6pq8avl256MZbNaWmoO/I7Dbt cbUfTkDGsVoPqj225BjWhxD6uRS7JsjdjwCopudxgJ38MRyddpx1YSFB4/GZ hKgnnLS/DmaODAjjsSMMLkQ5SjTS2erWtpuHP5ssDAcYqL/gHDkHgDhF2J7b 3Fm+oSmZHgqbt3fGT3Wmk1WhnBIHpJT8UFYvu7uOssEmg/wdnCyZ9ef2WrM0 2eKIDZTtugaKW8KgoJ9bDgOfGV40fKWOolIPIc9Kn5hIXwppPQKpl3fh6EIm dxCGkOWhU0MzOyPCaaG1hQIlJiyI7nqw6qQLpiKFGSD6kEQXprgGeiKF5xn6 S/LStsY4GaKFrzo4G9iLukCOh36mDz5bPG1mS0SmhrOiKnqSJf8k7zuH+JO4 xT6PpCGXH0gJCaW41ckw13a8vfJ2Z7AZMfGHJ1uhnexyGowN9oYF7eUputWu ZAsx76dfpQH55fYYBCyi3HEI9mCUTqKFJURp/MMm44FP4xh84Ey6QJ8VYeGU 0Zjhx4xb9q2EB2FaYRuiYlkFKiTPxiYgK+XVJuJaZVY8RdUmPOJe5EqhwmE5 4IMrYcLFVia8W9o4YmRdzQVl1oQJSJuk7pQgq/AaLiTulYrd7hYKWW6XiutG s6VJU6tPErRo4mFCHxRgIrgEvCuAhLfS5TzCgDok34eT7ABygBtNOmWa2aaO Y6dGIYCddN6JuDDGjy/YD3R2ISYhaLixY7Cn5REO5+G8hVrbueLd38TR1Djp qRNVn6HZ0cHhnwqY+EPPutPb0cHk3lJ9kygFbqCXoqspIUdJL3RjHKaKH75o AMmD/Uc+SGzBkCMrx6X2YaPc/pPoPHVSIbrBVb4F5D8ardIt7agnZXW5D7G/ TYcHx4sH/afj4edj42sATZ1DhQef/PN87cNDY6Qu1zhP9u7WFC0sONEU4M+2 Gok6HwSLiP65pTj0AftbhoAtDETSqA8t/dvsICuYtKSkhxgnvWXSELKxDAkE dtimWvA6bjgPArL/ptfxH89yDLvgQe6vby9cJ6aiQCZurqPBx0skSNOw+ksK JYBPJvOmzgnZ+6Jxe6b56adBV5bubxmnnAQnMPp+wwqwoDe7oTmAFBwIJ6Ek AS+igVL6kgOP1qJVxSPL7s4JWfEj9WM858NB1xZsvJMbvZmdiDD6fj0DiT4N uz5K+pKDuCK+pgAuP9l6EuOArFA/1Ny42VNSCkdmuaJFpk45IjB6/sNM8jlw /rrj+xOciBG7FZ07Am1NCdmEu4o6tDnuzomuAK60ANNDNUBDQdeWzrVy/Crh Ewiw+v4qlp6rAzGkS3uTHLUhF6UA1ZfZ+pJjh9pGF0TwNs+39on14byiZdak 5BXjhQUGh4eAAACBggKDA5wcnKQIkKKeH4WYmRqVFhYWl5AQpKSkJJGRkpIS E+zs7e1t7u/v6Ohp6WmMDY4Oj48PiAkJMowlNIaTTouAmAfVyoAA1Q5tH4Tk TOqmWb5Fir5ANvdSbK20p345GCglwWS/sDiSMIk8UzmmFawIbPgnO7Vawfw0 ZCXaHlj7lhWmhRe+ZWAxOlPXJsX83WCj+E2XIGiMUQypWvgT4NBUpcbIGLnB ZaM2fLCFpeelJk3l5eHOHwr6pKTEv7RzFRk/oE106CcV81h62REe+JrnOLwk pCQkceiBOqbKfSaHEE5Ux0WRGF4/eaqxpb60d22GOab1eh/sq6QkIYavYuf/ F5/aJSO9dZKFlJ5WXLkgEvE+uvNvpFirpJw8PMr9lLKXcdrb2DCcxZy2BCUr 4R6hkyokWqR1wUBbkBtegdmonL+j85IDOCPO/ugh7XdeWqSEz6u/YC8GvZ6k 9PSUpzNw39l/7x2kJKTUwjwhcRKDJiVLxBoikvF/XkEjvPPoGhQ8TvgahxZI LqR6z70h8ugGOyP9dAehFXPaYjm9qKQp10kOps76G6EzD5xZAPqqbiA3IwzE qyQkvj3w7AU7o/V6J7Lsy9laQbEa2Ri9swU8okQko3SrXJq+FfJBhr0+8iKh /XocIBHMVFckDEY+ICfz6hs5uE7cnT4V81xdRiQvZL8h9xWatLXJ9IX089nb XGQ43x96guikZAA/uSNv9cDDXxEb+Z/+Urg8dGksOCSkmDog1sElspfI1N1f kB3aFq4aPHfsA6SMqiShHFZcBibtcNpZ3jEYWZ65TpOUJ6fL4+inEwz8rK3w XtrUXqSjNqNKfRfR3mRILGddFvaQgbR6RB5CRt2Qn+QJhSrcPv4sDFCCoESg bnNf2sYouEtr0D++bYC7AgoeBw4u4q9qJCSTiX4qoLJIvjnzbAE6o3DEnTkQ 9bQyqiRYX96SOFmDPKNM7RkUpowU+djuaaratO4085AGLvX6h7iScXL/bp+k FKvs8LxJDqUloPRjGSeWwN8+OHWVALq2TXiELzzDRaMTVtnUSmEC1aQ0lR48 Pvfvh7Q4/n6fpWxS2twcqEStGTaiy2Lck8j+X9mTg3maYz1WlBMcPj7zpiF+ f580FpRXrSSkSD9w7CUmIMR0nAcRcVTF/2wDPTnnrKskFKa28GOeIhXz/9je EiV6njguUqSkrZ+gklJYPaJ3EZ89NXXiBjyX8UN52RY2RCtTdL334h4jk01o VLg88JCagE55hzyQVeNdogRE226ih6oNIVjfkyQhviLNbQK5DOMUuNpYKE2s 2Nt0vp6mdXieu8rYpESSxowqOAaGH1HB6KEWTV7a2GzWfJMpGnmf56m4/hXm Xho+qmqrJOTaRd4Rn9QZ2SwMJrw+yO8YjaBNeiTcyKSExxo5Os0WFD02cGy8 kz+oqch2GkNvm9qa+66ojlrEq6S8p3XoAo2/yPufJmhLFFk+OXRogz5O+isk jhOCl3dcmr668RYAuCfOeWimE026BMJoONYujSa5jCTGBDrKGL45zo2Hmk7L GruQ9zok5EQwv6FyswWhoat6GTSQSNs6bodVZKgBeRl5Ll7PkJShtkRglo66 g2GsWNpGjlTyxGzwiGSRXl/CliBsgD49fj406FqujkzyGNA6fIa5aAjkTQwC WVpsnxg5zJeDhmr9n9YhOsC9lzIko5h9hag0GH3gGacR0lRdMOx8RMuYzm+H yn0GupNPvOSkqLJvpHxdzGi48ZcHoLb3va9613gavD5cBYO+vC5IuN5wbZyC zfQZoRB3tj/MtGWIq5WGJqJP3B6o99tfvn7TD708pKQkNKYjOJ93wrWjzUWn PKN3kxS9oP5/hieTbJIVZTrkM4ahFOKYkLwR6cjrunaTgrjOsmaitMU9af4/ Mu1yVO368JFJPKaxhZ8X6RH5dxH98ctD214OQ3esbaM1DwED3g4DG+/jd0lD +tBeD9uvbqG1sZH6cJGLHRfv4feR+nB7c0dZ04PeDkNuJLw2jgKWDoPejuji 9srcEfrQ3lHvp7szhfCRevCZkeX5cwPuEXnE2Czvp7uzD4PejoaYkOp8Wg8D XnbA2FCoN35spZrFT6bHp6QnHl8Zn31fJKT8MuklpSkgISGiIqOjIyQ6I6LJ lCu/v7i5Obo6u7u5xaSkOzQ1NTY2tjewMLGxMbKzM4yMNJ64xYQJCouLBIQE FhqmTDaomhuUlJURopmkpGQXkepq62RkZWVmZmZnYODh4WHiY2N8/CCrcGb9 +Q4NbhEVE29e20pPuuozj46NaFL1YxMq08OyZAgK8O2VsoyVMFWwYhGgrZWk NxuFshUPGyX0vlRColpvqLpvDgMZfAIXfWeGjrRJhS4kkyTkpiO0SrwlTyHD tcklA6SvU6SekBFutOxtbBDtdbSWlRPebjSVl7Xu76CqJFOTNBGmh5yeNZPs lheMI6Mhtoadh+hBuIwDJcyrvXOLVB+JOXUsNSIlx0Uh9AuDZbJcObU9pjZ5 46IlSMqaWdNO7aOmsaagfaPYo4ATUIqPBE1tlYovaZgn2qudDG8Xae8YIH2M jzioUidrtQxiFW4VuChLlHIq3iKwfZDiU5KFDLCwVw1ZznAXPEWMkbHrJb3b RP3NsLyeAYWeh4f4ZIIgKbCdvl0MbhcS7IKg6X8WCZW/5yA9EQUXrUcUBRil 9keOvZnG4cYldZh7RrA5pWOb9g3ayn8KFbsoBz5kIR/KBJqgW0l9kOXQpO8f RMlhewosPHwUJnUGQi5J26dmq7W8HSUOJb12BV32aLLv5BZaeqbE8BOA7h7e CSCyE9us8s+zjgtD5T2OZ8jab1QjCbunnSWiaZHLONEVIVyIldxJGLSZv00F a1wONYZxMiH1uvwcqLUWvbzntT+1TyrJ0HgrcvS9bpsH+ttCs0K0oH2lslEl g/zE/wYE3SU+XTUQRfSQR2DzCEzEfwF05fk++baQRHuQ42jvv+i4oZP7bJRj B9vUPGATQDVlK6ZwvjiJj68i2K8CMRwPhpEk1mkgM7+yFL4arekgOJmkpSWR I8CundFSJYHX6adWXV4ESifW6aBECXDxaafW6Y39/rGJqqtL0msQNCfvCSdf b+u1bslVpEiwOL8USf0xEu+Fq4YdJaXfv/cFYDu18TjMHh0/oU6Lpts68Yer 7LIComVLtDRuU1h2kWs/otI2lWvZILk6vhA8jICc0HNOB4naKxkZI+EUPv76 xsqyqpg35iY6L9ndA4yZC+6KC5CzreusY6N1teOwHZGjKq0HgStHo4aEpUE2 2Y8R6zj5nUzZWw/AbkVyUsiQyhOSp3miPaMvPSbUAV6PQjU+g4gWTnuCWCNp yzZjWnZXup6sVecnAk0lB2Lrhxny1Og/XQrca41LeKUipx0NOR794skUTHZB WYM8Ds/xv/wEvyCWUirA0rsdkQ3pZrfEbh1roaV6ypMTxr7BPXt0BCEgu8xd Zuu+JDbma7zhf7sdhSI5FpDZZbauPrQNrfIl9w98kTxWj0qSJm57AI5Bdpka cDOlBuLFP+G/4o22eidjaWCAH8KnLs83Es0kDy3cDEFkjYHhor1r2wW9EL5i +F48b+GTzOQeidRkko27mrFaFe+nbm3AOhcuq/pVvhCmpqT22XC2aSxRuKW5 Hq1bCoXL9qFDj2mEhUv8s9tviGIPjJtlZJ8JML9iJ7t6s7ijVF00P27SHZes C1lkf8AnuO4DWwz24Yjs56gYHVxGfL9vvtjvoTCl5KKzt1z3bOedXcsBJqVv Me+MehJlVSdUHqTdaCJUDpDaoVHUtXSJP6qZ9dn/KQli0c5TRJAaoi0dsMgo gibvS5MDxDYJ8GNTNm899aTaW1Ub2ZtcUZQMIs6AAExj5h41NTUeOBf24Ood tWClJkkS+dcxNQkB0L4cP/BSyZfrWyIUPpWmEAC8pXgR6wKX6TzuEkOrkBYS EjMmOyEmkpAmvTkDbG2i6tqqyqpulu4TayDskxaSFxc8oGyv49JJ7TnrPOgT 7+2gsPKMqSltEJFvExDvriDiY+rtF2yRbJORDzTrPG5T77wVEhXv7uyWfCsT 5pcX67AWb26W7jYQmgNOFbgTIp0nxZbyEJHrrDtMylKUBKI8hXtIBaB7/iVC hYXG99HKJ7qSJhYYaE+Rejq3CZyFtiqKstoOm1emXUBPhQqhk5JNVIaLkoME pMDs5IBs7BKH6L0KJh/sBYmRkSSnpQAXSpOq827mlWyV7Zaej28XRCYfNFO6 W5OQMRhmF+zobo83Jp5YVD3fMT7oH54HHY4OSs1KrQQkfSUTlxMW7OnjSSbu E6tje/PdIc8+/ruT7GhKqs5EG4OeHwYen44ZphBuF22ipZSYoRsq6JFuau0T JeOxc7bG7JRwebUVlhFvhpSQF5Hox6eEmOg9daQkltQgDOAMfw31jfINTwxE DMKNWA1XJKQk5NINKQ0mDbeNjA0KjQANHo0bjRGN7g3lDeIN+A11DRQpJKRJ jUSNQo1fjdUNU42oDaYOIw04jbYKDYkOB6QkJCSOHI6ajheNbA1qDuCOYw3/ jnsO945LjlgNL42rjacOtAAkpKSOig4UDpeOZA5/jnqOcQ5yDk0Ozw7IDsv4 JKSkJI7GjsGOQ47cjl+OWQ7VjtGOqw4jjrkOtg8ND4QPAI6kJKSknA4aD5cP k49vDmQPY4/4j3oO9g/yD8kPRA/HD1qOV46kpCQkUg4oj6cPIg+1jzAPMo8N D4oPhg+fj5UP74/mj2MPTo8LPWUrWY8PiJ4IpSQjEfpwyaYkq9NZQ0VwEfrw zfnjaZX4d5H6HYUJtT0rKg6D3o4s1FzGTN6Pg1745u6aAtfdDoOFMzshK6v6 cBF5LlDeRs5wEfpwkX5kkpoc95H59wSOtCIkg96OQyqs2sDyfmQOA16OFpwG DrAR+gJePqSpLlbc95F6cMdP9X9nenCR+W4UHAaOug4DbhGhqautUdneD4Ne Q0txfeWDXo8DE5kHjbujenCRjKkrUV9HT5F5dxH3fWmXHd6aefeINKCoL1UD Xg+DQ8l3fWsTjwNeD5udB407EflXXSavLFjCSveRevDxeWdtm3hwEXkGDja+ pC/TDwPej1lBSfH9Xg4D3ugWnIQMd5GMAzWjr6vR33pwEXlETnB+ZBYaeXcR A4m1oy4pXg4DXtTCTvRiA96OA+kVAY81I3pwkTMtrtZcSPSR+nARYuoSGhzu EXl3BIy0Iq0rA96OA63V3cvN9Y8D3g78ahIYAN2OA14IMLiipPcR+tAtrVXD yfP6cJF69f9l7Rcfkfl3kQWNN7kh3g7D96QsKVFVWYNeDgNHT3v/ZW0PA96O EJiCBggRjANeMrS+0ypS95H68NfZXcHPenARefZ4YuRukhF68BGUHo42ON6P eHA9p9OoUlSDXg4DXUfP8Xv9DwPejupskBiCXg8DXoQIsja4dxGMgyMnUyut 1XpwEXnYQE70Yu4RevARkJ6ENjzej4Pu0qvXXctPA14Pg/f7fWfpbQ8DXo8X H4eJMZF5gl6+oFGsWMJ3kXrwS8914+v6cBH5kB4KsjoiDgNemtErUV/Bz14O A952fuBokgNejgObHYuxOaf68BGzUKhW3kROEXrwkfD6YmoSd5F68BWfAQsz A+6Rerc7o1Cp192PA14PSfF55RHeDoPeAgqytL73kYwDIaVQU1lL+nAReXJ0 YmgWHhF6cBEGjrC0PF4PQ3ck19FfyXcD3o4D/eXtn4Wz+lDeD7ujVy9X3RH6 8JFFzfXj73CR+XeaHAoytIPeGnk8JNYv11/HD4Pej0n142kV3o+DXp+Fs7kh cJH511Uu1FzEzPl3Efr14+sRn4UP+HcRDTkn1dBc3g8D3spydGLqg14OA+0V nQWzv/pwyY4m1FLU3sCRevARREx2eOb3kXpwbRsBj7UD3g54o9SpUVvBTQ8D Xo/1/2FrE14OA94anAaONveRjAM9p9Qv1cH6cJF5SPBiaJCYkfpwkQIIsjgi Xg+D7tsrL9dfSQNej4N3f2HvEZ8MA14PBbE5odupkfrwkVFZQ8VP8JF59/R8 Zm6WeHAReh2FDTc9WqqOg14OLNRexk5ejwPe+OZuFpiC3o6DHQWPtz1aenCR +S7axnB+5JF68JGSGAQwvt6PQ3ckWS3X2UeDXg6Dz/d5Y+sTDwNejhQehoiy EQyD3rQipNiu2HeR+nDDRc/x+/pwkXn8Zm6UHIoOePARjTuhWC7a3g8DXsbM +GBsgl4OAxuBDTmnWPrwkflS3srweOAR+nAR7hSCjrTej8P3pl+tVUNLA96O A/P55ZOZh/oC3g6MtCJeKNAR+vCRXsrw/up3kfpwkR+HjbeDXpp5uqLeqy1V XQ8D3o9FTXf/4V4OA97ukBgGiHfJj4M3PaVe09n6cBH6w0tN9X1rEXl3kZOV HYcJ7hH68LE5IyVdLINeDgNXWUPFT3EPA96Oenxm6JJeDwNelByEDrb3kQwD vaXdL9HbenCR+t3Hz/f/ZZF5dxFtFZ8BCV6aeXcyPqZcL1WDXg8DQ0tN+31l DwPej22XHQWPkTMDXrA4IkOoUveRevDVXUdN+3pwEXliaBYACAwOQ3cROz3D qixaXo+DXkJIdOboA14OA5GfgQsPt3pwSQ6+QirS2sCRevARSkx0Zu73kXpw GwEJs7sD3g54vcKrUV3Fcw8DXo/54W8ZBxEzA94wviTBUtr3kXpw3ctz+eX6 cJF5EJ4EMrS8joNemkGrU1lFzV6OA956/GoSFAPejgOfB4uNsT168MmOpEBS 2kJGEXrwkcj0Ym4Ud5F59wKINjgkA96OQ8As1ljAzvaOA14O+GTuFhzJD4Ne iLY4oEco95F68FFdS015+vAR+WaSGgQOtI5D9xE9p0csVl7ej4NeQHL0YugD Xo4DkxmHjbu9elBeDyElxy3XXxH6cJHBT3P55/CR+XcSGAAEjIPuEXo3P6VG qVHbD4Pej0HL83tj3o6DXuiWGIYO90kPgze/J0ZTWfpwEXlASnB6fGgRenAR FoKKsjheDwNuRavXQ8lxA96PA/nh75eZgYwD3g+JszUhxamR+vAR193LcXnw Efn35myQGgBD9xH6D7e9pcSs0I6DXo7aQkpMdN6PA17gbpSeBPdJD4OzOafE L1X68BH63cfJcXt9EXn3kWFrExsd95H6cAUNNb8hg94Ow8sqLNbYwEgOA14O 9GJoEBzdjoNeiLC6IqT3kXrQy69XWUPJevARevN74+ttERF595Ebg4WNO94O eHA/JcosWlyDXg4DRXN/4WkRDwPejh6Gjra+EXpQXiFKLVtDyfCRenB1f+Xt lfh3kXqdCTE5p0msDoNejtpAzPb6Xo8DXvxkbBSAd0kPAw81o0mrLXrwEfpV 3UXPdWERefeRaRMbHQfukfpwDzc/pUjSg16Og1lByfH/aw8DXg6WHAgwPpH6 0N4hSKlT1d/wEXrwx/N55e16cJH5moCKDDQ+DgPukaVP01vDSd6Pg153/2UT FQPejwODBY27PaX68JEMzy9RX8dJkXn3EXf/5+kXcJH595iAijA6g94O+L1O KdPbw0sPA14Pd31n6ZNejwNeFR0JN6NwEXnXTShaxEx4eXeR+uNpEZmBj5v6 8JGxu6MnzSheDwPerFBUXMaDXg4DyXN/Ze0bj4NeDgKINj6gEfpwScyq0trC SveR+vD3/2Hpk3pwEXmUHgQwOKSOA94aTK1ZQU973o6DXmBulhyEd0mPA7E/ p8wv1/rwEfpdxU35YWkRefeREQMLMT/ejsN3JnMv01nDg16Og0tz++PvFw8D Xg6YgIy0IBF6cMlyUljGcHp3Efrw522fh4+DbhF6M7c98qvR2Q8DXg9HTfvj 5V4OA16SlByEDtddDoMxuyMlci/6cBF5VlhCSHJ6EXpwEXxqFpyEXht68I07 IfGo2gNejgNL9/1pkxUPg94OHgSMuCQRenDJ8K5U2EBId5F68HP542ttenCR +RSYgI60vo6DbpElcK/XQ0tej4NeTXtj6ZcCXg8Dn4uzOSfw+vCR+tNbQUnx e5F59xFh6ZGZAV6a+feOtL53K9ODXo+DVV3LzfV9bwNeD+uXH4sMNsgKAl64 Ilbqd9GmEcr4H0cA900memD3kfrw75uHD7GW9s9oivapoyKlmGUepPfq8Ncj MmhsbJfubOiMBN9sJJNtk26zl+2VppcWs2/ugO+WbdPkvmw8luyTnhAXFhVs EiNR3B3bvG6kvbOWkUkoRo9lEzBsl29vuIDqevZJOBfuPT5sODja3GzaNrMe bYxt76URE5KllyXv01oVaICzlewTPD+MqhYkc94R7BYQs5BusJBvl+2TbjJI l3dpZZQRasoP2N3ywbqRFpZs7G4RqKgX5JLvlW8S7naXEOxkEZVuGN/rbNmX ooUfMxYU+Piq0ouVbG7uixIMFhOWdwvUGpJbM7Dt6NumtOhsEZe/WkSV6McV FZLuiAqb2Fn6cUg4oe8naJd6xUrYBBW9PBV+lS3GGVoaVruQwyYeWvTDT41B +tsMapEBbtMok0mzvJAS4BCk6en1S5cslxNcOz6iJ2hZepJulmmMohcB89oN mjxzaG5zlziautKzTRzoHJWTIGjZ/hA+M2hoYd0WbABsFW49/wL8WXWduB5W NBrcWe3TkmgRSLwCEhIXkFtn2Db9vLwR7xYiZ5i7hyO57g4ZWgHQqYSZFVjt klWTjLyJFxmXtFlaOZy9IW6Y8Bnik+wbHBa3mTyZxTv8i3PKOJTGuVkzvpwc 9pVZNS5ehG7oT0j9eoqVEzjBkEiaYsMxPImlaZb7bZPZ6oONbwg+Y1mRVRbD aW+I5sjP08kWXbC2O+6QQ+XsgsBt7wW8I6OGxbHDiHB07gkaQBcwbh28EKZg qgOZIu5usiaaopO1p6RZQU/A538thJJDw1qCZ+fKkHPvlbaOU2w8aO8FbhIg bjOghbNSofMTX7E8bJB6TZWyAjDfE1y89cOPWTr9F7D+5Cfys5MQFr4KWGiK CxRsYxY8lzJ1y56aZJGgHcbPE5nmhpa6vhOo46MG0wii+b4zdUtnuDB2WzQj wme4PORmlaZQ4NcVqT60behj6IFM78zi7pAiIGDF7hORaHAs6GzOF8E4bj77 lm5sFyV15e9o7XC4MieIJDxsF2ykE5UHIHemgmVmNBPqutlCWhEQIjoCM7MX IZIvaHRQM0YTOe88hLyZpyGmhaVnCrzSMr4Q4dAy2kXrpr9obxSjas9TZZSi opJOx5Z32OOSVAKicm9Epc9glQrck5U40zM1GxMSvBcWbx5GFM30FpZsjaJS FbNZ3XWQMCI4GcUziZXujfO6em7YCG5oRRU8d7ydwu356G6id4IhglGnPm8S GO/Olfx5O7wh7CfFPkgN6TaFzoey6+AwPhfdGv/2CTgaPudwHDPykhBBvPBu 6m9CbkOa/fMHvpMgfGePy5cwxUlnv8LOIBYRarRv+aDZERjJ7myO/c2V4Phw pYilBRbpQnzfI8PdglgojkWDypXjuBDwoldME/j+fbCh74sBtur4PpMTnKJa kYJFEJeV5QYXuoM3gjKG3WaVlRbCgLiWvDYFSeflari+QzBzkN4NOxh1M1Lm 4Dw0Q7pYxcu/brjG54V7TIU+PBPs7JpIwx3LtTwWbzG/cca6FzguGo2IjDW+ MCeFjSFNAwSVAnwPouZ8lOzvqDJST8xNE+OQaT5b5YG6ETPcTTzHm+A42e6z 7QQ8BINPCI6rMzo3LBYjMkuWvLS75u4weLtY9+3DPENOMoDOkYwbbtR20HXY LYqAvLEYCt008k1mfXjdNoAaiXTVeB02Kw28R6Nv7+kW7BavPKOMefaCcmo8 mucb/dijM0w+lpL0r3jF9RbMsbgzw880Mh4QipFBviO18W40OKGzwsUZvBPl 8zM1zeM+l8mXmb7PA/FHiGu9buG0SIgiuBXAdU0XgxJmgbyOGADslpwyUUnt FZe8Zvzs7WjCvhjnuJU8SeAgnTPSJW7443POmXawl97p+LfrvpE+KT7u65pD PMqiEpN5okMayGvFFKJuIW9SPBDnfh/sQGJeWGCD1jxAQm7WkuN8HrPsHhSS 9s99ejx5ARdgjZXsWTzkNBXM2BA4MyLUsCJVmSKqMxAQCFkttPBlM4uTagVp DRpFQD5FPLgRl3MpBzYqtjGYgRVfttnWkgGQE1s4lmp/5b0T7IgW5OHGGVUi Jse4lhY02yqzDpNoU6DsU+CZ0FEglnOgE1f1xhInlRhY9yBWZkOHpTiQvJFm d4IxJ9/ekeYl+MOSF0W+H2fYoJ4W3qNzVSDYzTroV7wDsxbPEmySzjA7N5dg w6L2Jmm4wriAQri/zyCzIjzko8AVwY4hWDozwicFxYU6etgB8FQLJK44zmcn Gj4WdpLEbrcaaPkQ7Wxu31jcN9GzPH4iouYTjqA5omoWtpVn60S/WLnqFSKW HFHfsPiIk+mD6z4o/yo4bJuYE7gyXWmOcDxJxOyGu8ewBjz/7Qywon/MPKKW mly/pThyWjhXF7dslp2ilxdIJyZaU24ajb5YtQiW4yL7jyMRAkdvaLAz0u0H 5SaIChCVUkkaqFSSdwcg876ASNd0JsQiMxBY/bw+IYrsb2UzH5Js9tdtPEc0 527bzcgX6zbtFjlp14Zlo4g8W+mm5kgzmj6houyK7zNUapNvqpM3MP0bplaR oMTJZUc/vpDcvJf0XjvSWe+0IhZ0I9jliWW0EJwQkzcYmRClFu8QTjD6vv4X 7e8qPhdElz47vDeQkz7cIjaVoNOlzJ5jZBh6exKO/b66kArB1yczPjg+QCCY kva5C2x5GTVl8q7qvPCV768A8tcw3CLrTvosG3Vfs5aN67S+FNlxZbaslREX XrcoEOOCnDy0IjeSSVsRE74OmYoDmG5cOB2nO76WjHn1zLYSWOgXuDXdN5Jh L7ztoP6TQgltljAiEO2X86JhbnbtK1hmACDIopVZx2hwZpYZtOtbLIYNN+q9 POzd7jXq2bjsEoq+MBkzTd6nuLRg/TMTOGyfd73KFte8np8zikdNl7SyjJe2 +OsLSYySGAxVWTodsqeWWJK1N2rNPiK37sbg5Zq8lxc/F1yC1pFvvI0YkcsV 76JkMCNMofXJot46bCICojK8iG7NkyW2ZaCorNtoFeaBM1qSAe05YhgTxzSP lhjJapdBI7xKUTKmdb6juPQ437N27LgikOYXy6EV7Usp6DibyLf+Pp4wlxnN eXHQrei+tw66oby+7rhhZLPzuwru70JaTRmSXIv0fk/bxZXpFW6gL4SVYnfz mllTuG6Xd39vve6+jX74iSjDy74VbHawgEl/r774vlN5vCPh/DHDJSYn+ge8 Yjfm/Us4vEoCvc3IPJESNL6FGLK2GqbofPFeUx20pLIfRQOziZDq9Gf9D3EF lMDcpLRgmiKDcdiW7xaVE/W9fpGVPZatNNBWY7g9ZJaWMBLZMnm6huxpeJq4 gkduwjyuFa0RgjzoUGzyWQ6VLTxw4R5uh9K9KZPyD3bbPBBoFIuXeu03xYuM Zz1ZzVNFDkcXPuJ1h6WSKguDSOedY/2+khZ/mQbtwdo86j5+WmhlAyCQOPzy I+YIPojs7iFl08QIIpLg0ZOlbrw6nm4aJW4CPKKXJjz6+9ZdvbQE+ENUJy2F vNqUT/OpkezPbOkS87OB0SLotaO4PdnFiG9aPAzXCLJENFqw7hVyBQWM7v0t gc9oOpV9OpekkplG5XU4P2cZgd64gjSIxJfOPbwKCBf+EQXuEhg+hkwIY4M/ MgKMyzcsPADqCdm15LyXk0iilhec6DGn7+IilpLd83Vs8WiRmjv+5um7xkvt AJjOFZBNcgCC4V2adobWIgmGstacFu9smJR1lR4nPNtyFjqjEaL8IJfTJzUR oiHUVxUCYBq6FRL9iX988EPoSn1d5dm8CzAjMRXPvk4koY2OPmq+o/4WWea2 vusXxXYXPpaKeGa1eNngS2YXsbROhaHYfjHjN2fLPpC6hh7yj/E+v9zuHN2g 94J7RumaXoUy7USTbgQi/I21BNITRDd4IsETQe5+xhrQkRP7abz81U3Dmyhs PO5JSReT2T5Vgjz0kyJCDVy+kA4iGQh8I74TDhnfb9Uis4xWkmyVPEhilj4+ HOf5GRaZaNm8BvZ9yxs2fGkx5dk+Wr7FZX1Lmj5EtWU1XbQiuEylbjhGkCIQ I0GggpvikJAxnXBksiXIdxhpwTU8VjSfQLMaiD7Al9JsgboashIhM1U8GlfA vWLHNj4MzD6znjiWlQcPFTeic4yaRUkj7ro8oGzVpUg+ZSc3ZiBw6hSeF2ez Dq0Dmo+4NbkLTdQWE/m/vVv+BbiIAPA38oSiohpJCt7UPpZqkZtilWrsIFAC oeah+8+MQCg+XZEN9LjAk7kPlUOC7O9i5x+ZNEQXsCIVoi/INH+aAV+cj751 HUNVV2CTQb8PmEByvjOOhUWC34ZwtsRBpZJoaBJpvfdCQQTa3BOqUyP2bBZU 7Zs+MppsNU+Fuhi0MyWNAHOQeAmVakI7vkj2hMRVCxO8nnj2gjqN6ZWUk91g MguXoKa4E5otA1/D7ui8ThPhiGWW81++3AAPffHukrhUTZaCeL5PzhBFEDv+ leiWOdFuo5ppPuMTEGyIoew5oYAioJQfAxQWloygw7jIPBK8Ez5Een92j/+1 6SC+5mxkXWcf4JXGRZsWvu5gmOI4Tw15QJklgmlG5b7MI83nzMnuIb5E1c74 fR6+NJK0Pt1N5/oXtbMwSOwH5PZsoRJoTnPZpZWism5HT8jXlTqVlYruMqNZ SAGQwG4+EF92FZdlOKIeaTqYgVnmtemNds/QFUg+6DqisRCxdr6M8zqHY4ZB vCIcWMW8t5+UD6Rm2aMhIZ/pRsa+kuPE1plvXv5EaKQSKO6m85uZ3BH3HQsn 9K0jEjxvlfBz22ymZjzsk54Unc6l+DxCWO8BCt1EEpdU7T/nG0gNkrizPjaV POdekpa6QcR9BZMSs9oRoYzyARx8De9LAMChMxVpPOgzzTPuJZ4raTZU9cWU bgQVgLyX22Pgpa65IM+RIaqibsG8OL5oQT34TtTY3OjdOMYTb6Ls4rr6EKZm tOvTdhe8oVmfgu3mZ8fEAMvMY03ntr6WmZEyNNmXphGXPm4PWGbgSJY4EBK5 FjmkCTMgoB6QR3UrisS+uFTpPBV89e4R33ZY/xWRJxCajkAKSVdu728m1bxt 0kYK5alp+pKwTrnNiIksl17KIOYS+SVK7OwPJ7hBIsdgS9kjRd7Fng5cs+In F5AVxBESrwfgsphpE2I/TbdZvswUE5LwiDxMWCaW2n71T5aAuDPiKLDXOZEW aj28IfUkd5okNmyOgB4plhJuvOcYTxc6p1ullTURzz6TPkXR42eAvlMXJYKB UDiFxoBITQy+PAWWQRYzEpA0uHywhqmlvGDnC1SQkau+/k7axPUT4L6ZPc33 vweVE9B/J3zFCfyuzc0eTjoHPl+bTX6Dur2BchqFoKGXVDzvIg6+jpA9lebl vgayDeSQ4QjlQjwvP3/DP8kDnLh4szOCSPa+/ga6zfIRNSgQlkWghk08YtRQ J0UVmbyV8WAHItLsFJh6PzLCpBgytN7Icm6LPJdXmBMhQTmnMuCDeiZlVBFy aTNAQSIXl4z9cxJMoExuvpO9kP7GTlqWAhOVlehU5oSkGbP6W29gFyXUOBXV cTcnSu4SxDy6p3ILfSBGRmqPWuKfYjiDlxNogob70z4el13MJ8wexP9Ft0ii FyVI52diTjqXfbQGwoNLOJ0y1AYY7rgQHtY244gatMhu5iKyTEXmnyE+E/gj Oc69Oha6kDOStSEgiWy4N2bxzAE9M1FkHn4gKoa3jO5oEDKTVCHBXXi+FrRV JMbGbL6WD7Yj0SCFnwg+sBG3uG4n8BgQaIqNYcaQ8kKQtdpyHNKwO7Bugzhh s9BuhGiQfpNCPjIRlsIXzTX5FTI8uqYoT1OW7qJHlzwz84cCzhCPnRLcvnaX ug5LEiK+kP4DAjwRTUp7ccsg5Lw76b26mNOi9PO+6OX6kx0QIhANiQ7G/2rg jZe8sehygCP3ugS9/ptOefd8PmTteE0+1bzS7DNRXUbLkhcdUJdWQLiY7SIX yawX/ge66hpsFjBNB7PI6aRM5b9cIuw0OjEXQ1liEmy8bmyNaoblwbaSO7xG p8EDZx8OQgMzijGeVbJOtwkVuG6RohCjY+UbbpaQl5z54Zaacio57wihMT6R ogkZ7UyY7OyrCZBNuKC8k2ZTvc1lPLoxpnjqzheibiIQFgSnMhSMWBMHBLfq E2gWDJOX/aDXE4ySERMSY5dwlRAsLE1RF/eXhN8il+8SZ7ciWbwQWHZ2gF0X npUIY2VlI0jgFU3L66Ly7MB/75dUBiaq//y+ljb1cj8jJ1JfMpWO2MjZk5u8 s1a+fJUIohQ+EJlxtu4+GrC9TQEanNc2+aNhmzzWnU6VZ/e+QpuPdgtlsBcS mEMXcSVSA0eOTUKHChPP0YzOp0KBYjptkRqHRCOZtMgig9oRf2WHkaQjwbXj PBYUE5O52c632TzgGVMzsgs8KvIDkOeWcOxKreCH+7wQyby/Ako+LMoS4E9z 1Y+ykMQWRX6dQz7gvDPZlodYUz69zhkhGqEjL74XRgGgLqg44+ezZuk+JY3m 2X3tvj1ZtRhPhOE+InZ9o5a8CkM4SBa+1hPIkPZZDrfgiJOTafoyubw6H8i+ pvF/J7A4kYYil75nBsfi54tcOC9OqGFmdDE9vLVHxhsrvF++M9NFPhZ4T5im N5MS8CQ1CeUXOinUAlgBEc64PsGw6zawErs+WXOSBbnTPmTqZhJwMmhxZ4dm NzYUVGEXsrjGFb5wfeQYoymXpgL5OIY+WWaR0BFqtWhPuL1PhLsTlYY2tYc2 jbzCenO3+Lim6CXXkDAVbRHvvfiV2f6lvrcRU5r4I8I4URbtF/6UlXJcmPPn XTZxUCi/t6E5PDXyETlKIhITCAIc7HgmR+K+45kCmUE8RlA+y6WFRTxKTDl9 YBwOTJAQkkf6GycWk7YiAqLipZVZNnwQyjUdTZ6DK/rZNz+WY9CQDobG3CHK s3IIBLPpWZaibpZsIcrlHzs8TA3ipuwispm5+CXpIgQwpTPqntVMso+jQhrO Mp84rElWFsU3ALOQ7miWoB2Qpg8QeONPt4xMPlBlGQVeZTgVJJLWt6UUN6jw FxqaJkN2oj6+WTIXMzQ4OBQWoTo4viK2l4JvPqLvNXXoPhOTTD4S7JclA81s brpt9QgYb24fObM6zaARuEQZGUaHn/64HGVjOs58llrpZ+LbfTa+bDhdlhPJ M8iztJe/kqMQCX2m6MabBHbC6EYiRrF/BtyA+E7ilayfPqd/xYdvcbinoWrD gcqhQZWI5vo6SxwdsiYD+YpuRz4hZYYNELqKvHMUaW2XInJcIVmZCLM0NRe9 PJATxpoPII7ybKxmjZn1tzKdajwChAXloDuTR3sWBXiUtpMTlRIdMvXVC0eO HqW/oRpXstaa7qI+km6MFxcMAScpojiIUwXL/ixIhfMBO2Xo5LjEhUxGJZCQ aTUC7JkSPPhdl4Usozwy3cZnjRO4JhUGdFk1IVCWacWzthgJdpft+F+ZOsje E7UmdyAelZIFmrx1F/DYo16Mvu+QwMXbvTFHIDqyijIHlF9Uju00OY0SMr0Q ti99nnUYODwiBzK7GhDq6lxd5jMPb4Ah20ZlgHVpolMX5teAr/tY0RmspXDc ojN7FbwzSbcSEW/YPNRuOs6XA+EzhD6z1wMPYqO6bZCcku0hMSXavFFn5/dP bmg4hewZsxeyPrS0DbVqF+hi2kCRIOj2vgq5UJadihZpQJNCdP8n/A0c5UyS oLZv6aJ5EI4+S7wBozw91+xYU7IiMxUSoAj2OTJsIityvssXcrx4uj8aGHwW OCEXtTe0GLSi8tDHgaIa8tX1IW4piRgd7bsIvhMcBQIc2fXayb6QbiaAylnO vi2iM0qPeFUVlhx+gMYjz+XA6ApeZftVbzOzHLOPW7J5cHGJvr5z681nA2jK IpUQhGY1sX11HjQVElgCRIz1kfzyAr+3Qidonn9FZnkQuwSYoZnNOLxmFieC oJwkErjs+eF9Prc9PGAlzRdrvLQPA0UO5roTlTWV+CKzil7v4Ik46LU+4gyT mHaOPXiwvKGdtYJ8vPOxGUDkOFf/w7aaOWc6hs84zT4LETPBCU+N3JhDkjW4 l7zynCjl2YDpPnFqPv+D8To+Wlt9ZRc8giKo8dmNTzwimBdQppkflrwDZZf8 BAx4mlnOtwY+9D64dYBYtgS8cocDSr4k+epn5//vsDcrghDmPiFCijRQkX/C FhfZYDbMEDC/7pJ5hzW6jz7Ehk3lEma1QoQIwr80OBY2iqKQDAxx5vHv7SW8 kIIZy5eTvES8ETUi2aJ5EfgM6cb1vHY8OoWKDYCzbsu8o+qtiZV0DIRwUX4n MiKRzgcuBSX9uCOTlVZ16I+4lf1Czb8OFqJBG1dBXZ6g2Hoz9T88vDwUZ9IA R+iNLPOlkoy+YWQRJwYm+XO46jIhigVcBMyGkibUORU+fBIUjU4+oqYYPr4J o7PXF7ySFj4TntTADgHoqD7FG883punGjOmPmn/avp2UzGd5PTJOsCkmM5KI 7JQRFRYzEb8wkGxrBBVhpn2J2hM1LGd3vCa8WIA+IpgPv+i+ZX3251LpqGoI 9YTIvuD+ob6y6s4+thCCMpVZzWm8wUWjTBeyPjP6QWM/bhCXIsiXbtfIpxJ0 uJVoZaUyyRUVDB7CoZZHvpSaDEi/94Ibs/8QWWIAzK2tuJdFApo2tYUOeMMx PCg16nMWBZv9CNPFMB81vjO+GbaayL7iIfTyuAy81oKgkM/9Rzkmlty8DJls hYUiyCKBZ30fQBngb0/97xYiA2kXpkHEFxwVAlp4esMRq1OikpbyW8YkmQAi hTDegGN5aeXZ2bGqPxU82lyWzt69NhCT6PazE44PgLOXeqfLZZOE6LzN/Yvx 7po+iIz0vQ3hAzpB1BWiEKM6kjwS+kejIruVuhCXfyFjt2ZjzWFlp2aAbADF gv4puGxJPqVfDVKPIneWY5UM/oMlPu6+Yjchtf48wuy0BDUVPCKMIdyVkkU8 HRmgLmGuACNnCRdF4i7FxOW0Xx7gi4OjIm4FFjwzbPlFH0fKvpGXM5oTyRDh lr4GiiHFFbgHH/VZRmP7vI2jOKy10qIRXUFBM6WmbnVWn/AR6rgo7pYNgSLu n7iDTkgzgUfmxD6e2/0ZZDyXEeUZWeyi7hOyKvUP/3/yL+/SfNnxCCJZIEa0 2zxbbJAiHqIvmu4GECLCpSDVf86XYDaVtINhCIyZxH06m6QyF7Z6PsQjJ0g9 cLiR8DU62AwIPoTMxpK97nYzYo5xxk3V4jPwGZXyobpzBpoT5pq+dyIc4Ppz NuS4aOczGqZivvy9IRj381O+ZocPuxVs7xM0gB4DqDzukEPvhbPyWKVXOGiT p7rDojaTIM9pf/K98/+ibUyiQejGzT56kL6QM6kjsh0iFhFUitV1VMIb6Txs xgXFDIVBljaCOEW+TxN1Pl0FDLqWIm6SHuJBvYrdEmw+36ce6F48N+aI5peJ osMF1l4jCJKSbs142n+wGhASEJOippGJuHSg69YlDmAIIqLmfIjGeIk83LPT t2o0vQvuvu+cLQPRIkXtoqCKvfs2qSKQzCC2dSMYspOFziPZQpr59JLoom+M yMI8HHa86MzUtJVQl20govmKvj2glt2z0mNAldBPv0gZ3zyTrG7KoYWhs5w4 2hVoEo/3oq4ilhQzmRailgAilCxJwI+RtO5SsqIV3yFVkJez2JeQGodn5980 BADizRdv1OzrPu6Oz/3kRRVeuH4/jzVeXri2olm8E7DxJ/5aJbOqFm9dSxO1 QjztljQXFZ/OILyZ4lmix7yXJSJO/mgHiCKWBBCQMDW+3em8H3adcu1B0D5K r5Cg+vC2kJa7IgtoDdgh7su9PCwihap1HVQTkMyz5binGqKA/3O1LCEWAHbo bkJtp4jKvlcguMy1oj7tj4IFtzyNk9Knsj48UxAyWfUxf2ALItd/XHaYfLyY ogruYWn5vK4gGBAR0mhP5s/By+q8Oe+T9nK0lcm+vhgjI4VAEm/S4vHlyZQ+ zUwu5gOS/adqvEZwWfe6Ijkz7qaVouIYnbz4+7P28LwWOm4TPsx8lq5s7yg/ IUFIhGy3hSv9JvyUbJZuO6Oa7mzvshiVBhVEPGyivHHNTszS/O+HYRdBLr6h RoXAOjWyJlRNITzE5zhsWPKm89ZcDL66j7Y0VrwQBlAxHQUxHhNMGQ4dqzgz PhlNJNikSD4jCgXvkwqS3j1jVUAekkW5/UNpEdk4L4sRmWJE2rJ+t7xBMLdk U6UNn0aKPfIihujKkrKQPpmGMWOxsLgMwj+Rj8BYlun9lRXgbb+++YE3oBkY +xvGHL1NvrJSIJfGxUX0b+IQoXIGOuHlCZBo7sCuQxEVfi4wJf1x5eOibLIa wSW6ABi+kxWg2IGblu8WnyJqVT8Ntnr8wHiovJXpFhU0MjWlIki+dmWG/G4y BXaoaxOhft3iJsN+ZDhjoAnBzFtMKfg/I+o+jM0+TYxDPJAQbzVxpYeSLsYn k3MVvjbusJAFlp4FrD6M1xVCrbxsk2xZ6h5AtAN1qHlM2BQV75sTvm9N4RfC 9b7gFHcR+L7VrG+UhjGdiI2aYurG9jY8rad2FdminxfK07+UmLNCkzaU050P PmyzmqFZZpA94+65affP1xGOPmn/lLFnvo4ZiUu5qr4RFziiUZQUkC9woiil FUOPxDwWGg/8gtka8vCwbfWSjT79TWiWnaYIQUeGABw+QCDMFwYQikpuTrlC JT4WCSAzlRc+AjoIwj9zqpKRJsG3RAy45BIOFOAdXED4um5jOvmaOYwSjqGM gVY+2tx5ekc2Re0+wQGzalw+vcyEik98/ZNSKg/1TVM9KZQQEOOXQUG8GI5X aQE1Ir4d+cSSHVvsGe8sPm1UDaAVEJXr2Gp9Qsy0g9QAme7lOlSdv2QQc5ci B9wKvfJxB8E+qjlqnDfSpUg+V5ATOhsiOUl/0tipM5XDpk9IONIzpbQnxT4Q av4iBYHhPLMfWzKhjEBp7GBg0Yh1d7zolbbPEcIShXIi45CXsQi2whWIfZ/n J1+eLkV+Xb1guvZcGqZvKmzmPCaYrzdlooEQ/nUGM5DA3LN2CRW4PAShYAGY 7OnS30c/SyISx7NtEb6+k6FhOdii6aGebDiOIl2LNz86WXS+zB0ToUcVaqIA oIwWmL6thfWJL74WbpUTQuORIVQ8EB7xnzKaWLQ+8H8lwZ+6Lo4/ukG+OO1K uG57ajEErYo6/xPeppY+glkzFeE+vN4BOK+NjCK0bKEljKunPrwOeDriFJfE bCYidILkvEViJw5PuqLwlz4hPwy+EoLZzj722RC/7Bmz8+8+ICIQ57aXmALf zTk8XH4REOb4Qbfmv7SuogNBQuhtapFgEmaBOfL4Ew6Q3Cexn6Jd4WVLBnzC PhbV+0xdl+XaF+jaHtkOkLK4Tjxl6ULlpj7xbDXHfXyWDbiCwn4f8xD1RYYE Q6u6Fe7ds6bEliC87KG/kM+ZopYpYn27GoyV6bxS5H6mJ9iPjpyCE4aqjo+P wo1yOrdhl6cdPFk1o0nm+DgRkdnYREw+loiMiM2QMricvMJgyxOEFpILlgh1 WD4mjB14P8g5kpLwMzyfvowNeT43bpvzJUSSJaAeHAAfmHefmDdUGgMRF+Oa b4fqptyahlnSGDUVUqIfkxsynNzbMcf+B//uhhEAd/Uda1sWeVYljuUg2H51 nodC0rwQKRfS01kikZG1bLeyo8c6yaLZ6s062nFsooE+NAdpD5BORm5s7pvT oQiS0wVy//CblXTDNlW5G2uPM4waoDC+WskUCCyOjmXJnkIboOioGgi+QzUD +RW1nf+MvCKPGnqInh9qDOZLGye0F7VYWGInvBw8E5f0Q5+RzE0LPOc6HGNJ KICVjCbABm8IE/VLA5waFiCHbP9EAY7BQYUFj55aKzfDBZ6FBgYel5e8GyEi 7JwIuAOeHMSQsk+sHXLrbKbgVOOL6jwelG4giQ8/HU7YeCJumZ72biGR6E2Z WY6ebtUTBiI3sg90rxZgZMZ+/+agThoGlLLbyrWDNTkhhQJfORMZEyG2HtVi xWDjVZshuILEBOUz4AGps8i0j3V75pYhvoED80Q6XT4aenDnm+1TlM3op74H BdkmnbKoXLYGHRuBFm2iMqyVx2zulZungukRCoylhWmgD3aXKXyTGCyHH66b MowyJYV+/SB8HnDQ4ogYtYAeuaG4gwmi0rzOEjmeUx57xBqeD567lom7SCUA R+1o8UuXqr4nMKVVkhLp6HCsQzhE75UTaZQ3GbWmC2vdjKXOB9J5hW8ysgqJ WHqS+OE2eOc7gt0NnjoOJBBTKCWjobUdtbSmIeg5JYs3jRD+pl1ELWgyltZv w3oxvoWeGkEmbj3/VehmgocdgweDD12jRe502LoYMyUjMSaZ7Gh/RTDEpMKM OWpn0yrl7poe6W7TSEq4DajODg0NIGyWbiZv42O78sAnpToODkgj1ShqbbYj j2T25KrhAAGHiIkVRk2SlIdsrCQsVdd0jEJU3VykpFx0XNyVxU4zFPhN9XTc dPxk7E7L21sVuTyVdCf09I0N8WTfCROkAqIaOCcDWaWzqCQkpOQn5bW1/LaX /hEhj+FucKWXgdP2MZihAd5jsSLFNaQkpKQAap+w/sGWnSU+gqOnB0npjThg Rr7NRIsPZZIYCmWiJSQkpKRmR+gxoPw07dJmReiYoCYFrB13Dr29PyAGJWsI DJggIKQkJCSjubk6Neo4/jht4qP+fGckOLm1iH6zeT1t93d5JbpxceZr2STy 8QxzNjWlCtYlpLQktCToF25+pCQqXPQkqTpzyutMTHwk9Kt0JJWl21n4l5Sd jSSUjLCo9LVams/NJDQrdGWktCRTpxKSvyYNpJKkpKSC+SSZe5D5ffJYPIAy 3E+raRP5fAWkJAKrLChgoKd4p2km5bRJHw70xdXMPTXvTNnzJCQkpD8/t0jj GGM5frWQD1BjGTzmgOJljacecdrTEEzaQqXoJNTiJMC/oidm5zsTFCQmZOjo uifguuphpCSkJOslpmOj+voiuqC4YBse7eMnNwE4p3T+4Wu35G/wNoGgJCSk JDjPdWr2Y80BTs+5Ef/Mt/hj709AEMn/TB+7RFzdwpLGZySkpJ7DGdgY34d4 pqYmVVVW1vOejQ/RDhs9h73s5FWku7Ctry+0PaO/ibSrqystLYVJXcBjpAgk JMVmoT7KEVVg1XK3y+s5jTN2JiAjAopgjUy8JOyrJOWhuuvBTPDE5acavw+Q 1BkGNyZ+P58PHRF8pJQopDck/wnuUl8ZTodmYT0MJ8FMFiGPO5Q2h/0f5KZx pAXdJxx2PbARznICJ4i31aQkJEgB3vG0WY/r9w/goM4QebZlSljGImcfZgd6 im1jRiSkVQAnbSpBW8rY0DLn5KVaur2m19DN47vBoScoJKUrinYzwquorqjX palKNJdVq1ZUpNqsW1tb2tktQk5rWdlaWdnYX1Nf39+kHytbVCbf3Fzc3MPB wyTB3MNBw8NBFHhkpMHBQEBHQUBLQEbHx0dGRcZGM6QkV0RJxkVFxMVFxcvO zsnRSUlMzMhPjKRdyk7TTs3Nc83MU0xzcvLyK/R6+vD3d/f19/d2dvr69Xr6 dIjCQ870+/h7e3l8eXjCJA+I/3h//n19cONjemPijHhEM2FhYOHgYeDh4GBg Y6qMlPjgZ2Z29uZl/Pzra/vra6X/09r3+mbqbmtrf++kb5VCz5PYyyYS0yiT ELlp9g9tkOw8klVfB8hF7e2DbHYSk4i175sgExOWchIPlJExs6XKET0RmjUR PpSkUU9skCSXGRcVEBeVExSasu2alTkQFB8MGyUCLkhsnicUJZsbnhvvG5oa 5CmuJGQaGZkXmZWWGRmWmBiWlJgflJoenh1EM8LXHR0c3xwDAgeHy4TgeCRD wguLD2sPDgwOjeSNsrGbNzerZ9MUtUnJOwucOYi4oTwBASamqKDTCEulrSel rqZBJF3dJFYwF0rH30692qclXqSkroK1BWCgUyWlJCSkRDQtxYc6BJHn2j0N zbXkIbOA973fFr2G4KY38SHnUsgyKvO+f7gNlEnl1rdipCSkpI0iP/W1vDoJ kK4gtXX+ZaGiMoQPRSUn4EEliSMZetbRJNokJF22uLEliSGG5148NA06MThF lQegpXmlAR21xiBtZaSkPjylemRFAD14CQA6z4HFNz2u5KM/pCSMVXdiH7eL FTa/jSURH7KI5qNu0O7lCE2/yomwIMXBHvJk0aTkZbxfAdYH4v4Aj7nS+E03 Qr1W+/BpjmfiMdFapHsypLX+Dd6HwrnmP0LMFCQkuo/lpgIP6eUFYXwxHkMS 2fZx/ncMhVikp5o8Rb7wnjCCiiYjzJemJv+uDq6WEaSkpCRyzJxSxMypMe+T Xtwv8gRy1I/iB9V6JWwHttP3KnF6Qg2pL6QQA87xmswY9OjKoaXE9SbwF8K4 Cd+lZBTOwkgTzXOmjaUipLzbzSPOVEncLMpPS5mTIMnNS9xukG5Dh6beWIUd MU7/l5eV2k2nlUlOs4oljRSMOw0VUPpa5q46Dbmm4yXmBnJJ7yfqpqu94eOI u2QgJAiwCiekhZ0kuqUjB1FAsukb3KqkpCQYsSYwODxgly5hLQmLsX+zdyGL oiBz6ApTaRxwqLKp3aQ6DHEfNc/6M+6A1jmxKA4PM2kjpKQ424M7vLCdu7Ts jWc2srOQ6uK0/yQkJKSdvD2c7Q4+sg6Ps5GZmm3zvfWddj+OD4+zuacCg/N0 oporpCQdDYwxP7GPTzNxeYfjdaH6DMQNxQ9oisAkJETG8YDcoh2x+12yZw6y NohYYge7ozBMHTG0pKSUVaLvjbZHSFgAPDG7vY2MRA0/1r1y7+Z5SyRE36Ru BrvjrjV2FOI+W3E56EKHxT8is1qyDiYtgirsCbzvHR40nmbnt+7xPVhAHSRs r+zLuTUAwvZHJm4apjO0tg2VZ2LAOqSkpCSOMyu72cYHQ2a2bs4PXs4AHH7H GT6WnT/jHIgmoUw4RyRsp7zqZbEbPiD07dD8pSAiPiTIqET4xUfx9jHyOzBC cLeio98YTskoQqdK37g0KWqBOnj6TaG+wz64KQwFEFN9PWWhNsQNALhApCTE LIM1PDD9RmfAeab4mYGVJheE8aV823zJYeXYLcik00y5O9P16GbYBhRMioS2 kka6iIPIpL8kbBTTVVanfTb0DUkJ5o9Zgz21VclvJKT3pNDcMBPhDOsJLzKw HrAD5grS19H4/FSTy4C8h7D3tPekkJp1J87XjQUbPkSkeCokpo4gSVq0DMEh 5ksphcYpFSkT+wmlp+IrpKQkfaXX7WXWzG2G2MLjhC1MUQmVY1bpvXxB9w5X FrYk0laf35NpEqVn7aSM9jplkqSHIQVbzG3HCEDOcSskJJ6jIW2L1F0XfnBo 1pSBJT6RMjAhIJthlKVy+B4S4UCeDCKqB8kkJKQENDyhpb0PyVvhp/3t8F9Q lUJT8+oUF4YYfpLlaohp9AJLuc6e3AtQB5I8uygBZaQkJ7r5UYMpFb2H4m37 0Dc/fnnLze+kpCTk5brCiJNUZnOWTXRt3yUn7c5VkrED2KYDV8XRIRkFvwRJ JHtmaELXHsQV7WpurORlDQ5l5RaEIU1boi4kpNMdxyGUdT+OAE+5Vz3lIJE5 t4bSbvF5zZ6kJKRsMXDDap2P0BlJWeM9rgm/vDXgiJ21ZAGizrF70g41Yq/s mbM15q1sxqJfpqWL4CU+5SKgjfTiQZrZFJQlnQlzF6HlWLaI74iopKRhHe5/ WID3dW4bjCJ38VlDv0YUkI+YRdakJCQkBfmZJXyZ8WVxm2eH9qalP5mx/0Z9 3u0nO46yh4Iu5Z8rJCer5Iem9hDM35ThHYG1PdPt+ipghxQRkST3Jxo+IMqK 5GUIZmdgYZDfpGRxbTdh6RHuZ6J/Ynjj/BAM9fWybhVfwrSRiNeMws27LSTR UVDXV9fPFJ7/1laIJNvRYxafDQyZM8LvWbNaWt+lXdxDShNUcTfNwsJdpnTn QiR45CnrQsJDQWVARsYFRsbAxsXFY8GQKUrISLPNTZLMPrLEti7r8HD1Lmv4 pSJ9/PzdKE784+NhpebTZOFhEQZns+CLVttmZgRa8xpda2Ana2ulajdp6b8Z kPVtxYVy7f+hYiQj65YdHQCJCSSMjKHIdmVH9aBtChmpOFmS5uumBuU7hKfi YbokpCQUyWc7i3ziJbw+vbkwCDK4YqEwBIqEvLOABmIgjOR2JyMKIzGj84y3 /+eiqqSkIMlK5iCNSecjPbi0OrG1PzMw4g+LBvwAjJzUpIcIic9nIaC2hQCH 7B2iD7VEkdYkS2UiCFdQoo20SWW8poDNEpA/hqkkKK5WTjNCLa1TUtDQtG/W BFulNVXU1NHR1NskKZCSY7YmpdtaWtnbWkPt6IAOXyThYN5e3pn6LHzcDsNB XKRDQ8OkJNTrQljSwndzwVTBQMHDwEFBQMFCQEdFRsNVxrPCLdfcV0bFx8ZE RMtKqVrxy0pKyybsx1pG1FeXksrtT0+mpU92ck73GHx6zXLOTZLkyQDyWK3N TMTb7HM/YG/UapnIpfD3dvf39/X69nPEWzNCePb1TVz29Hti7vraaTJOeeD5 c9/0+fjzf0r++Pj5JST//3H4l25C3f//pqX+/fz3Xt0wJF58/v9jdcJjT8hh rmDWcvTlSMl5wObCTjOyIOZVZiXlZFdalA7Fxmkk6EoS6Jdub67vZnto721v dKTsl/JMeOwTZxJkkXbChHIR5peWlZcXlycXqS0TFKSbG5QbmZmaGJ/OM0Iu nh4dggEHho0lZbPCsjclqhDFsgDQugicxaETciSUtr68l10WhqG9pr6jmiy6 ejwq1GVRKWkdC2K7lvxLXWanJbMrJciNIwVxdReDo7AK1qRsriSxPbaiezFv SBfpXnVgobETowFWh1z1BJ0FpCSkuX3xvaei5D2Of6/JpeanvYVlLY5NpoGe v5RRJKQPNvHVfbYhfrcXw6kNdjC+tSHRG2m1pKQkMyl/DGwv092OcD70OQ+x Ejxl9kB4j5NVWu0kpKSkx5F9ZDcEkvk19Ubg+AwQIhXJzsEgZA0DECooNVeg uIQkmqSkfzAdct+wlmaw73ImhcaQnqJ+1BWBYYUidA6fPqQk7z0Pbn6FdUQm HLzPzTQNNSNBpDCm/waDUHZM0zKGB3VCpKQkJIITjN2odVf+hE3GlQHHET+E G+IA+sP+BWFvAgerIQqkpHirpO62WunEVAzc+jcxyTDwniRwkNWDpn3h9gHV fwXh0+6Jp8M0Os+kSFteqKgsLKZTKK+sqCgsLiStJJgRFKytU9JbV9HQ2FFQ 1iqUq9dQ0NVb1lbYVtTbWFRQ2dTX2tRVIF+Xym1VXyHf2ydUVN8uC8Yiq9hb W99aQ1lYwRzYh2Eec6UgPjaq36ItsViepSZeXlxdwdjhNPUdQ8JDtFYhzUpq QcXAQCVLwEelykeZVSz0JKXEQEBKx8Ylxq1ERMX0ROxPxJ+Ir8lLWU+pL8nz SRPXmuylSchyKEnIT3Aiz/Ga8yRaJnCrzvZPzXatR8nz1C/zUCx2zXF7UHHx 9nV0/17dSt+bQSVz8P5McmqKTXPhFaRieM9i9auBi2cE4Jtl5GTq6996w68k a/QgamumUwZJpHBqb+np8YFo7qUrwsN4kJBvyJYWzZYVlvEaGnmYmhcpTp8e nOwdAuVzbOySLQEAcoDmJYcH64cHhyTUE5Mghv7yBqQGC3AGincFifaFhWAv XKR6hYhNhAhMhIj1BAjxhAuEiBWLpq9ErcgmCgsO8grHwgkJiO8vCB/mCSKk eqTaiSUIM/8Ps5+Pjw8ODZIOg2SOCRIMstEkpCRdjAyMs4STsgQSs7NfMrcD MgzusInmsI9dMLehLURfZLdeNgsatrbwxuE/OPA/vH6/JSSkOgS8b765E6KF Q6GPeaUcciUjcTI2mcjexkQkSLn/JNwfID02Ib4ieWYgJeRipKRlJzK8ubWF fdZlpr3EgIGFIDNs3fc1pKSkJJZQo7qyOUCxVjlWBvIaz+zRwqcy3/eiFhim ISVm3zeDJKQkJPQd3Q63Qr1gejKFf/Jf1+G6iuGbjVpl7zBhHXId0W2kJCQ4 BsDzh7pyYLkt4d+yGPs2e32HoQZfPT5TPNFWX6QkJKCd9gZgUQEp9t7Go7qJ pljNFXbAIzXvLQC9pCSkROJ/94L/uwDg25Hcv4uJGHLsLXZu4j4xnXqIrab8 MKTKbC80IuqfcXUlowx98e2W3Da6uDIneXMrJKRUhUf8CBLay6FOt/wwto31 jpWmR8H9tWORKySktx2G9136M/2lobo/kep0hNSkA6cyPpPtN30nEmrY0vcD zxfBQkQkpKRG7gGg7FrDso4mcZN9BEDl9Z3woOId5RYIqySkBvl/VcStIvuR gDtHGABG1eSNWTXdLvVWRWXKJKQkjXE3YiIGTdHmn4eEf6/5NpfljVJ1AXPn PWQlOvrwkUrNJvZgauyUA75fmYeptCrqOK22WoOMEJEQovYlujdQF3+lGoUh VxWeW7XrzYzsFrEz7uUfO4XKDkaMEnCgaq0iEe8TiO0I8Z8CZW0lDRIiSqFH 7mq0tDjDz++kloKmPDegz9jbWaUXpaAn67Ylq7pyumToaZelbmnuJfWlucK8 7XzIAKunqDI0t42Ol7GlFvlRQUAiCqc1AAOxB5ugGGQinFuclggoaEnsHhcF 7xiC7xOm94OVl+puSGk8bW6gJoAXlr6VPVrMz4QkMHAH7Uwf2sg4mg4YU6Bv bIMsS9RSGjiOAZAdDA0MDe3TUDGA9WamCrUAWtQ/4ZUWuQ6Mjgi1sZ9T6Dla Jsgxu4faCrAGWNKQpUQms+6OvR9qPSOdOKL2furTWh9AnRweHz44Tl9zERDY NAZqkZMH5u0ImSWGFd2QwsnzW9zvNYEkP5Od9BivU/2FlZK0YrQHUyHH0GTa MAdUEbHR5VAHGJGfofoSy2wiGD88aVJPcRC6mp0Xbac1+yFKDn5PiJIHX7qo nRrVPUw7n4MwY+nu8NEXPpyX3WW+8Jt2DB4+/bQGp7qyyu5x5DWoAHP0JDb7 m1tk/E4eBgyhHAIIigx2rRTIhL6LIKCT56oWahHuFYs2jIRoC7dvtYu3r8zt 9qttirslNYsWBKea4pPXiwyhkSc9baU6F2ALiYSwWlooWYyVbJW0kGMXMzoM sBzkogQscObIPWClylvdGdG455E+lkMzQ1mzniQ+Fum1MVNosj0uur4Sl7QY cZEHxSht51MMK4sAnJ2D+YMGnxmdBxMTjEo/Ex/4jA4TM+Sk2GnvtYa7AZyD izU2BG/qljI+cX49AzoBnIcM0+zIADv7Cx0mAQMcn581h0DK1Cuen4WDATi1 GAWCnzwfj7Wwk9IlXQkytLGX5iEo0L+xnAUDosIxg+n7HQz/oEhealWYID1v 7x3vNQZcmhekTpnvgyEMLb2J2DA24eiN32WgylLvsycOM46aI4HtxIiJpyMN jaf9kFrsIX01uJDsi1kxf5rmlJxdBEjlbRimmouNhHz0N7OdWeesjAgPbZVO 7M6ouEMkN5mKBgEeMJCn6r1TzbIMaxprQoOTRu92BBReEXGOwifibukCnI8g dCAHmrQko+r8fKgERtkLpYg/ZlAhoIJmkW5LiOJdhlmhIDilyB7TNPFY8xBa ZU0EVAs2hyS0kaMNy2FAFqWHDQuGsA/LLM026UQLjTiUisuBHAjWgrEk6rkM oTqzKBig4KT+4tP2EYO0EnmZTgVd+xtMeGOGjGDbenMrvcs+mg5LDLc3A5bn H4kIiSHAmME5mVSVTQ4woWhBOEAxHZyGHYHtuJHFGIdCzAyEp+Wc1S2/I02f PL4/UHtoGZ6o8NTfjRFUsxyDYjrjoRmAbD7oi8HDlCkgjxQ0lxBsqnUaou+c jCeM6PZrDKXTnqA0/yP/5Z99RJGo/CHiKGnKjBQCuOQi9oMK7iICfCB9HJJL n1h6Nn4LDkal1hH7LiCmWpXJNaZdi6NzCq0nCYI2FibiJuw2sYsiAdRBEca3 vGsljHG4PhSW0aDqzjUVH9OiDQwJuFjuTaWM4DwIMwCtGmGoJw0OCe4xFgIv JISp1qMABOmGh5SIMcToR6D51bJKJKSkJBWqhG6GJijHF0Aylz/mLsx1azfB gBo6YrvVzERsWqVBpKSkpAwbORTE+R0J4F4GZVr219uuMjaZugyhYtZb9e/u rzeUJKQkJEMoDhxMNphNPVof0QTyZb7FYjoHjtN+g8abETcDCFHyJKSkpCXz UFDlmvbM8w3ypaxtuutYcsLGVIAk0IM8cKaQx3N7pGytpNnTE68JlZw4ZJb1 PohKzQo265rnLpZWHqQkJCQin2eQxKidFmEl7WwyHOPOy0k0+6gK5WTeBfsA a5Ms8CQkJCQsr34P36Iiu07UOiWpzQLd8E7s+EzDj6lWpeFYB/R3UkTVJKT8 ubhlSdZZmD8fmmVQI7fFYRClJm2TSE2eg3w+7HWcBoemKkY2utXPsiWmRGg8 dv645AyMDWaext2+5wP4lhON5+aQnQJSVGEmfFDoVcDgv7e9Mut/Yj5FMG1y Hc/chXlyhm+/Q9SSY76dNMQec9Ug5rZEnR/63WB1gcggDMqluqA435Lq6QGF C4AGzrXwjg+OetkvSqSfhTUOD1CGHficCY8pOXeKA8MDhQEDCetWN+4OPTAb gQeDHPESURAWPA2YwocFLPa3PoYRlpxl59DFFcnWGR653/7LruqOZl6Pgygl DUSmdXtjaYPejgNvEQGxPSH68BGzjSlT1d3FEXl3Ec/752tt8JH595SAiDK2 g96a+bigDKhS2MSOA16OyHB0Zm7ejwNelhoCCjZ3kYwDvycMKy9T+vAR+Vba XEZKzpF68BFydv5gZHcR+vDpExWZHTsVYvqACgoLyyGiDA5eD4NeJg03tbu/ Mez6AiKzqqxWsoxYPYdm8n2VCFlX8gqMVaZYYgwMweZej9vs9ozLpvJ6MuEl ejgA7rMQGmqvpKSKTZp4DaDoMpU8rEodofm5xxOgfC8kpKRsrw/3FlF2/xd0 DmFavPfJW+m7Ud/UYNneeLKCz6QkpKQhy2rNZKCzSFB9u8T8FrxIO600zJEA 7Umu1IVEZ2veWSSkJCQ50tfbkx3PXq7A515mn/iSvkVxEpZpKZarU8GXYpyb pSSkxC2/2RMgR4s8qi8joOPBNewKm7yRA9cFlN/ubSSkJCSQ9d3XJgsAX6eC q+ejXZJPIfeq8c+Pk3nOhtjBytoEKaQkOCnK8lYT2Rab1AfcI19amYtdcvKM WbAKpdSkpKQkneWdWMA/lV1Ezy5OtbbGThj5/8lcvHfLyPtIpbAg4CekpKSk lM3Zo0A30SLN4OtsjL0DEZnyu5VFC7OQSH2F2u+nbVqrpKQkpUo0XfixPF8s YWfN7bTPT6d3V0R0Dl/J0XbBIGiOqaSk5/Ed8SH4OXm81cqjkmSzi5Mg+Mhx pIDnfSUbllAvHRKJE7ukpDioWIwX5wNVrtP/p5JqdyU6xS8hZhhGvK9HpCSk pNlNFx3RSL3RSMti62HJKlS725aBs9k/rmpe45eD3yqYJMRMLBVOg1yzivNL 9taNSt8F99SC2H9YpCQkbJVHXfcqr1jektGRhqtZ7A8A4RDz3EiUWe4zJobw KKSk1zsmDpQDInJB6iPbCm2nHHGFprC9JGOk+CznNKJBt08RmM7n7JLfkEl0 V5VcPKSkJCSp1JT5QVkxtXhczE7w2MA4C04ZZSNOs4qbS0hzk8rFtSSkJKTm yVNITkT6I1ZIpnpeze8JgF/STGhdez+3WqfmONvuvXOkpCQiFtbnipf/BBKT o3AZkekiXKPW+6QhfrDMaPOkJKRNe6Brhn48rF12oeCRLqU7K0UnkZuYlqjC yKSks6Tl7Y8SudCn/Gg6XyRVMl7hGelZPEKBW5CkpKQk7FTJKSmsy2MGxEg4 X3xNldF2WNhkft11RkVYCJ2tVJykpCQkLZDK3RCYSvdbIM8EgghOgVqyo1iC OqLMKAImCBVqJ4UkJKSkRqwV1B9UEPCs/GyNacSRgOPOlUK6ZpDLdd7sNwhW EZ4kFFAkf+gjQyYAIspJv6Xkt6cfywpKx7Giy05+pKSkpBrPMiYRTpvwJFjG jVxcT+L7WTO7zFSaTEWW+jCultJ6JCSkJPYS76J+k6ZxoCH7hA+j0ueQoO2+ mKQn5oLEfz9qSVZMpCQkpLLNaog6SKP64939I8Rf18isWmq1VNoi3l3eYAbW 3y2pRFykJE7bkBNm2rRDv0vlmrdJKNXozGEASLjXmQalpLprbBG8JMGKIBCb pAikxGOk9Jd8EcwWqd4kEhXHk7jp1qJ1rF4j2C9kciQf5iccxs4mCRWMcCg/ FFyDgJGB2iQkpIzCCwGR3UzbGtjZECLUha2KWAie80rxR/vK1ORcJCQkpE0A 0aRPjDoty0vhRUlBjP5OnvB2z7cnj1xJfqDYQ7EYpKSkpFueRBBZtjNpl07J gpXGpboRm3+y7DKIRCLPdeOiRjpUdQWGqieaY6wlM6+FSaC8llWv1Kpd3fUF JitbrHVmtxfSpRjTbccjugM8LlMPidV0Pqm4rzek4bkuiO/FhX8x0oi+Hyv6 /hUXEBFsNW2QbKXhH+KgXzKdFebn9hdQ3mGgPPXtliOOhkt+4rjUGX2K3YMH o+m2OQmyBtQswjYynYslbu8Xwq89vBQjzbLtINlrcNzsJyALhIAe28wfO7Mc PyKWFwZBIT0iDIqfmr6jrTxlpBK05jIebIa2BPrG6Haat04nB46+GvPXEv+R MCIgEOYSwFYgwJlq8+E8cVQgbJa6buYSvbbLIhGrmnWAdEJsa0MBrxmF2FGF PiNTINwmnuXKqxr0HlVst5KVoG/ASGiyY+Mv7oZtSSdfLXkwlhBBbkETGzvu sZYRblZJnpaz6XpuJNkuFsoZCjZtF9GQExOzM6DYJOnKJItvGk8vPBWBl6N2 FeZi0ggRbLDt7bvt4k1rtNq1lydu3YhF61aRI7XsLH9aXBN0heyF75MCNLnt p+Tvjk0juvW4So0WbwU4O5dg0yohObPkgekX19gfboVSaB9vnZ8hkcjdbjWl 4GJPrDm4dj2VXquf2LysbY7+aZcDFhCzOMJiCtxLFuceTIuQAJfFhTJHmiuH BzTTgcpnNuyTKPOckxiK0LRNLWiH4EIC7K6QR432MNieY+/L0Ge2OppoBJfD YNwd5c+WLRaTtYJVoyM9bqe7UhIvF7Zvbh+ZtPsOe1o3T89AbpXXgyOXBlzN SQZnlO4YlP4aOh7HNc+5ZLS6Srmj1Lq0BYPEnB17NTrWNYEDnAXHYXHrw9V4 ewW2nhEXmobn5qUGLp4Og/fR1ZEGiwuYmEk12thEkRtX2VlGtbS1CG07A1LF 8L73puLSGOGMYh0kisJu4B1OljvNGduGDGEVkrqFBj/LcHN6nBY8NdDpNeIz jr6UqI8AUD08DeHE1bcNECz73GD7BQ90NlXHsq/gPsTMEbXAsroPuQiBgkMo Re20M/C1kjVAgO/5Vj1oBAuGngphEDGxHIIVxAT+cdcWoL9qljaPaqc2lewg 2gYlejaSg0Lq0sjzhxiqVRbEFJEvlo+DTK0PF4CfiQm4pCSlQoPqDmjtF+nu CI6cBoiBc40eWqRISJi+lWkDLxmZko4RH4+ViGyBF8tqsRr7KQIVDwaZavT3 NAF5e1Azs/DVl4dRi9V2AQeHRcWaOovO5R5fX1SQtwfsiSgkyFGVtA8OD84y JXvBtDsfNKI4juKzaLaKyiaW37tEJAYcBpmYIio+24EfAwNomCHWFZODnj4n vaMxA9wPDpii8TJPZwo+i44GxWgCpaEmzZXFpLdCk59T1z+DiT4ZLEfbmqcH BQaXp+4OiZmhF9w5bAmK3TsnHDSueqPiPz9dI3nnl8VcDrY2pnb/p744M110 DA0jCrRigQOHM8q+T7kzsGiLM+80hUWl1rU4vrWgOG4edWygfqU0pLqhfaf5 pfh+NTXFet6KePxQb3vQKWyK+xLJIPwL8oBw/sUbc2XYlpAf2LgSTwBzOYhI ufW7kU8xie3e86ZGTk0iJPZRGYaWp24hWCPXGFoJj6C92zIkVXgIFaOPhhHq 4nfxRaddnBC1C1hmDIRts5UMHmGxZ9madJMmyGdQQIptjm9H9l48sjSKJfb8 siuFRLwGkJbtjg0Isx2mthEpHncIjI+N+OlGohhXD7hv9U91pXMjGqBmJl8E 7poeBL6kaAz1AE2rDpmezRyYoh6OENs5U3Cf6AYaA5misyWeryaQ5HVsHIWZ vAd0S5ULjUxIIBs37gdLNwiatoa+NQI3ou2lpn01uf2lJic6l7U5J5aeo+iX toagpqCNwLRmIaEiwTTmoyIjo0SV8U2k+uq8PRYoJHg+oCEnoacipqKmIyUj JTz2ZLEmnXmydJitZW8CJTsmPIQg/XwmEcvbZIGJjZE0PEFcqNcnZOEJcQ6+ a4PeD1uF76aQmgIKsvmCXg46IiSEL1GReXeRW1/BS/Pwkfl3dH7gaJJ5d5H6 G50FDbU/DwNukaaLqFDaQt6PA15ETnb44INeDgNpE5sdhQ8Mg16OMLQ+oAsr EXrwkazUXEZOd5F68Hf542UTenCR+ZSegIqyOo5DdxE9pwspU1XejoNeXkDI cvQDXo4D/2Hpk5uDD4PeDoSOMLq8kXpQ3qeKKdNVX3CRevBDxc9xdXpwkfl+ 4OrsFpiSeXeRAYszO6OaxF0jOVJ6goURswcZh/pr9WCKB+gGnw6OvLzdRohP hwWbA5i8GB7ec6sU5dAjIoGYszI6GlVIvIcG1B2jHw+ofWSvjgwiB56enYUZ iY8CVlhWvJ8HHo2znCIJiAriQ1oKIGkynuEVsyNvB52JHpz3/SMqk2LChr6H HhgZuNKCyA+eiSGd2yJudFJNtgXJngWAh9AiE+gyP++5Hwc4zgpCw1uYiFS4 ItAdElLwC2meAJgdBiHNASkiUMiZMLyGDcAyODMVWgiYopsipsW8WQc8BgMj Ir6LGaH60hyfnxraMGmmjJwYBgOfnQDghiKSUn2HA7SBsJVIlQOUAzA/H4Mi N9ywyeSVIo4Na07UzD8iAx+5ooWdzgbuQbe6obFGzlOB6IMdgMKDnJypGHzI o5ARhSe2AjiCRk+Qqg64HAYCBpxmDuPxFaJghoKmgaLUYKu8mQcMAQCFhlvm N0o/HMadnXY8iZHB234PCLKXpi+nH7+yPLIGZm/O4IPpnBYiHgmBDJD8Hw8P OIUcnL/cGoNwLIAdzO442s0forOiJR/VFfw1AR6fFIcz5xPZOnMNjjOP6jy9 /UhZIzqFAAP/D4Lzko8CvbzOeGYJ4SMBBxwAkPrdzzfS7SuUBiLXApNZh1LE nIedjt1vjFk8vKKFGDESTshzdbo8oz+bMHoz9Z7QPLoFn8oXp9cHAR77AIX9 TcidXwF1PP8zieZflfAHmE45BlI8AW6ruj88DloyHQgdofdP0vq5IoOENSIT eZGUHJWEAlV+5qMKnJ8CVFk1RDeigAaenQIHCABfEKFJHkAO1pwoWUicTDyd mJmHGIGi2FPIFIGzAZwCFCmj2GZkphTKlLqVwWTyFNSDvPWdojpIVdeDn/8c NKUQvqWb/GQ07hmTs5W+o32dHgG95R8MdbgjJX029ZbXoUOkFDUKJUWkOZ2Q pJVz4waHM3UiaTJ4Q+yiohaMBiG7H2WkvI7lXGtd7ow9IrLkJcsgvWQPoCb8 /uQjIqmJOJ1hwJiXg2PRkgwFFIUXsRBNsV81HYhZOxIFTMUbl3ojSgUTerg1 6L0MCZbvsG2gaJMWOrqMDKUizRDu91Wjk1mYug24v8YIYLP+JaJeJaLt9lbL BAYEAqwRHY6LlykOz0ScgoM9FAEPiI+WDsFQoSAODnabknMnXHAMQCewzpjO W7ezBG4w+L+/TPG7Dd4asS4NTdNmWZPFCEeIbmqzJ8kDp/1htAkOiFrZloRM JQKACTy9PMVlmuoKCKZsSYPPZs0mGKJsEPrp2g8l695s6XwVbG9u8BHKbIp+ jCaMbmnRS5B6ahGGzhcmEgNej30nbjwQl+0A5fELbH+MB7kjlbptJvom46Ih EXrQ3iakhiisUNT3kXrwWV3BxcknYhB5zHD0iOOmEwYPEG65EGVVP+S04nTH ssftXyA/txVu94k8O25gYZ6niu6gjs41Q0NUbDSGCAtAgz7AngSVlwy085HM BVogZhQcdq2Pwp+DGg+NgiL6pY2MbYw7Hqw6C70enIacnIqDAwC9FieAnNog A7lp19zXuAeDgx8Ghgc43b8NkozF5T9Niz6HgeigmmalAiCloCCJqZSEbonE yPBQFIKXbAUFTpCV0UWjABZPXVg6D9q33pfo4vMwLSoUwO2eSF+GI1m5oB8l YF4AgM+IvBeS/b322O15JYpsW6o885ejYxoitqZQV9Qz+Ca8sHVgv4SFPKVl ePn1dnErVa+npUL6Cu01nqva8Vo24p2Da0e2CiIyhYc97Dr18+SF5h2ghYWq PCE0AYc1sWzayui/ZmKxLoclM27qxlpBOR66LiY72SK4Np8aT94YCTKtFTY1 0LU5ztptrIIxpxzM4PKFtLNYdgnaszgS3LHZBucZWFTpleuVhchVibAZgO11 ZdXGit47JwlNBZ22gZgE5SImxBd1ML7OG1djHAapN7E6BaKj4ZlifCC6njrz OhP1mFLsfTT+/8GHkPgL9ZeNyjTCSCs9MGHM1DXSE2Cybn2zBwp16c4Azs+2 aPOwNTZNuBP/6J9e5hJYp1QbMuiIRdz19a0bpSAZOOPtY/3zXyrLOhNav51o IJEylebhnPc7hABRGF44IDx/z94mhbZBjU9iIi/11RmkkV2X6u4dZCgBACCU MItLiMzNE27kOiBWc4tui26QHc12ngaD+NMso7wgGA0POCI2RgYzst80gGH/ 2vrsnjVu3KJLKnXhF2zpkUNtwb/ch+yaEaeEx417DDqezBaqN9qLA5kA2kKd xXgD5jk4ncUjtuQ6VIqCYAXgS8Mu6OSUPYMqs0Ax7xXCPv+YqCiimBq+bzZC YHi/k+qTtQLqnTxKjTb5lTqlcoCmfxIBIi3j8zcPnm4rFfvytktlotq2X/l2 jKwDmKIWfnIf7MFY+B7qXpQGgDSXp9KYYn8/giMdYF2P52lnJHqF5wCNgGqZ QKsZRTk5LLa67QWUWm7HC3bqIaTQIj7iSqq2GyWhNUqTbmxrPf9kYCYbBwUd x52bJNQ5nSUkJYCRk5eekZNsg8ujbqV3I7iAF24wlR2d1cdSPHSrhb5SBJgF qwFsEGw8HjfisOFtApU2QHH16aUGb5EXAfblFqgVk5aShkvmJR2NHyVTIB0/ cwfvvv00MBecUJYMFZCNBWiVPFQOIbApB2i7E9lQG6lsFRUTg3zh4W62pR0i upuspnZtTx+ODh5szzhzq5Vs7pHs77nlPtZhVjPIsu4PURYShhSKWSbwiANv JhcG58/+M+5GHOzxOGK1YVCPgLy41ZQ4pQ6VF4MRlW2VOwZhFb+SEDM4J2e2 UdUmnbOivR4EDW79o4XTBPhWlgA+aSgbJ2uIHweXkpej6oyYorrEOqAwz9Oq 0u+agbw/ms0LP7ER7U23wrts7ekME33zA+DMKS8ACcjDT0iRo5FqF8OhuB54 POWztpkHF9KDSBNIuPEjGBWyh2SedLyFv9qQmJw4AZ2+wT/CUoNHsj8lHxEg l5inBdrtnhNtoBNAxtkgpgUhlraRIk1QXCD7Ho1JuCAPwushHvCcVsYVlEJc iYheqU24M5SMke1pbI/PCAiE7r1VUm6lr5v5+G6SqJ5aP8KHt72075pp3c8G zW28G3GMbZkGyNMDSiGYi5dzP5uyyzYOhhq0+As/ZZK+EyeIu2XVquGFVe5D OgMXrH9NJ+/gB+ztv9JSFAmfbCTtmBEXaJyQaIMjwcq3Mze4bGEHnSMByx/N OUII+EWpos+Kw58NXSUPn24uVFHsAk0QNwIXaXU8HRKZEshvu2mYeqC9N0OH Afk84Q2fsvaNetSxnRNIT9DjANskhbx700dmoz0INSOOMzlUIY3GbnQDOSJ0 l1cKlO0/du7giHahHyAUuXms2ETqbZPsoJQTFRQWj6cVaSPPWcWi0AwXl3cM IRI6Q4yaIBCg0qScsZmlBAQOBZmFHQUZgYSZg1bD3BoloCk6FBfulijHWj8m kw87l82YR8jv8/MekD9uaWi7EqY/VpSQn+2O/KWH3T2WjZdsm1rKK33tFACT bBYVlouAFLhbGmyA1ZO6hc2WoCX5LQ3GCO7M6sRu9O4DPKDgE4yo6RBo6aAy kGOTRQSQp5yW3E2XkNH4TCG67pKn7GnFPNA6tbaXi33tENpZY1jkUb7sEX0T lGrbuteMZDfAE8ijA4UAxqQUG5RrE5nzbeGdZF6gITATDAhsWllqaDeGLl2t +B3u7I4Z7AkBbCATn4bpaeBsgVBbob4K7mzEXlzw0KLslL7GMgtadkamnocT Of2WHPRPOUOmJDDm1op7HBbAEQ0hrIy1tJ+FhwUZ7SXHgsyIGUu4bAeTExJL WGqDC7gx7hA3JTbBn+ESMNj5pASiWicPIKaHXf2t0jp6O/Sdnp3oA34Vgc9F r4WIEYEfj40458Kw/Tjo0Li/ppYUAQx4hVVtJY4EQGU5uB5mgIVKMh0Ky44c DWozKGUh84yjFMWV+od1FVC1wy9ksfAM7nIr5XgXWQgkDya+PWztGXiXmaai jqA8F5l4l28iv6eJfxeZf+64IaYjv/J/F5kjPb6BpGQphuQtBKUfJrE1I76g oqe/oCEnnKikpKMgoiEhPaC+nQggoL29J6chPKc5IS1CIaEiWts+oLslMCSk ZBAwpbG4OKO/P94gjCe0DaAjdL0jIqM5IL282lPPTyKzgTsIu6eKtr2Ou1Tb KySgHid2ICEnOeOioiChoSKloaAitqGgIaPs7BMSILg8oY2hOT+8Irq2q69a 0z+8owa8Ir++ozo9I7CjOryhvdooSHOafycNIKAnvz8MBCGmiGya7sgjTyIj v+8NN7Q+siCq7AxavicivghJIWigtroWZD4gIQLzE1OTJwOwvri+kj4/zs/I 7hLX3LQMNYCKIJo27FrI212gPzQ5bSIctACJhacqLyQsuaMCfzmxvqG5CLWn IDO/Pru7PpChJb/HGqRBJCc1VGzGRASnvbeIaLkiAqebj540ujK8oFWkZyQy Ob2gOLUjtyIBvYa8h6E6ifY5oQu+qGwUaCI8sCINMjEnjz/mLQgloY69LWxz SaWJpt2jIjinYqK5W1TZxOobsb04oI02y9Chsz+zhyJ3sZWyqlOysLYWILa2 NaEjFcGisg+TzOu5CY04ziRDob8Hq8TPc/yiPSCitQxqh6ACMzSgPyKspGgy Z1K1DwQ6AY6ZvLEEsbsTO3nThvUZn109o6WhLrV+67Q4pzwiA6cgsanl6zgn oIWgIie0rnOT2idzjL8gIgOrlWAPuTVtoHkeoToIoiykjGO1vL46MSKLjxo6 PrantiO8t6yh2sC/jm+i95yqajw8CrJKbVVbMj2/IrMzsCWgjJQFuCXtVaQT lj2zIrccgZIdODa2AQc0sStzS0vSNLGJbrCxMIqWp707MgZ5WrCXmT4mp78/ q0XKmbA7hjicv9iMz6LEaIQ8PrQMBLi6pdkjMeTWCL9/DW+nB6G0Onoio7w+ Iz0MvyQixSM4vLW4CaMSqvC5I71GjO+qBrkOChEZiqK5IDEgvSJ0LMfkADr6 DQAiPSM7JzU057n0DRuSKkQXN7ghv7IgIw+PhiEULC1k9g8PehU+RhyioL+h PlibMpM8oLhSIaanRZFuOCElcznP0U9cT7K/vbmRv8KiPECB98PMIj0r670U 8WQq+Pg7NSC6o5S4MTo9jCaOuaw1pU1jn6iHI/p4ciChawZQbQSgMT1MvI60 or2s3STY4LCKuSIZHKAzoOmgwu6iJk9OW1o9eB7ue+4n7rMHuwVPABbM03mm tFuhu18QiFjrSR00HzZDcpnBbig4OWruPjoTluxkO+gagbyXZTw7puEb8c+i 8wxNIr85NYkeGyen0+j1zNExlgtS5Dg95GiBLgEkNrygI76noaGjtPauBIm0 hT0+ugO4Pbu85weTEg/rvDqjtD4zRDWjMchUgyJKu4+Fo4+za3ChB8rcfV3s Je3btLeAyx0RZD88vzcaDA75nDm+ONMUszL5p7ybhsu5Das4hes4I4tkij2z OLpkVcXPo4k4Oci+sksOuw4/sbyRmKoiQDuRuIq2vnziM7t+iqhUhg2/Irq+ ND+9oyG+wtnNTx9x/CGfnbIaDtgjwqXZvKYW/8hZISc9yKK/Guqa1R4TtLDt TiGGp2WNmvKPeN2igLuhkkdo0egqZ4cgmN0yOfO3OrMzOGAy5LKyvm+ZoRj9 hoA7Pry3SlpPrbaEPTDqijMhJop4jArfd2MaSfyMs50cX7yXOtOabGUyvm4j CHtNBcKPlZuUKB9U2uhLnrk9DqIjg6k4Qb8JtzKUbUgbYIk4Oz2FIh0iMG+b ypOwvvw9OQUnuzI0HRBabnzEPDh6MHLruPRAIj4SNrhbOSMZWk1de9u06iJa p7c269gUKSA5u8cgjicLOIYgACG7yhLr9uR6N5YhNNygHiG9pXckxeSMtRk4 u/h5oe+NsT9s+7A1hYYHpKTjDfcPvreDbRYCbANMvoGDkYKDwSmCrCi1CQnw uCKl9aG9KvOvZy+MPb7mYIU6ID+nvsqn/muQ+//1AZNzgDGD5TKLNw4iv/YF U+4V83YGBD73PC+WGsrPoQ5Xmoih16GiVmcoiE69usAhEKGkdq0aJf64CKPk 8gXV9yEHJJM+EMO/IzsQOSdPkwz5VKcMNBqhvyU6uOireda5jtohjDeYabHO saLb0REJLG8Ztcq8oecddbObJzOoAhpZT88gsSO08KI5lbkZwuQY7SmgvD6i o764ICAj/LIckb9V9v2bvSO+YwbrL31pyZ9YmoYlo9O+IcLPmHW9sRelImX6 Qc69aTp9L5c6GEVfIUuvSM28c173KG+7GpIAB7aSMEgv5eW0GVe/tA8E4MUy T0BnKLy3BTBO/7qbGpq2a6enGSC9vcQP2FwyKGehwJK0ITqh3kDYGpHQOhlq y77sCAg6YwEmGTXMN7Wbxa6a4qO3oj4FJZJsOptnX3L0ADkhBY6PVdmaI7xk IZFM3BQRjaCmiJ40uJV1q8+9jss5MyO2MjoBvqM58/knRgM1PqL3aLU6Owen FiET7s0TQqeCto2dOTzQDE4QA+sl/wRyy5qeIpInJfNSkYYSY/p6IxZk3XV+ 2aM8U7g6vRq1rsTpucgx/zVUf7Ca+2oRndohsKtnfj06ksUkNJSYnwUyiQKA hQe6sqo0Firm5BkgiSOxOw07gSGxWb1Cjisv5JughbawIJw9NoN8AT05N7y3 Oluik6NfgdU7t1EzPlNzk0tyhrecET8lErAzNLqHKvMi3b6byLq8N4vsFCjz jQKgkBCgFvmOtTu4U6CYINR1heUXXZ9xtrxz5Ca41AAQozc8OqccITeNPI6L Oz8iZGYKvcYmtRSMbHv9GXY5WsiqvNo3zV51T9ww6iaHMXUC1ia0BBITZq+W sDi6ODikEKYyK6qaBbiRMTG3DdajiQ64eiea0rokugk7LLglOv0gSggh26c6 anLsmzfCib4mOI++JLEbe/WelTTJxjojOzgjDyLSacLAtDfn7BrhuNneDaW3 LbmlQ+kStwG1rr+7vm1zWJFqEt2c2LegGrAiuuxYGxVMBiQFtbU3CQo8yew2 TyeC1ljr7gJ3iTe9NbS7WdqlKKQkJGQeraclZz41t96tnCWYrSWlDsOMFAc4 IyCyhxMDnSAhOLD+M7zC0ZqiTyddvs5rOv0x96V37IQhBbmJuyUilopdoRay exc9ZRq7whr9mLc6ilW6P2zlIiexwbw2PzVpz0cGgJcwMphwuSzEfVGkFrh2 PM2sqCWNoC2juzS7ujXa5/faMLlTPDOdo9ePs1DukrPbuA+gEFuoIzeJEPOP M0qiTyOXbJKpTyxf9QS4HzoYMLu5CiG5HRItGI66Dj61hb53H42z2TjsCz4O 5wzXbbEN2KO7MUiXEeMGLCCmHgT62pP2rizhpSH8NXAJu7LZGpJJAWAmaCfq N5pbSL4dWT66yrJsRA8rG7wfHDgYgI5dDRG3pwWziMxCJEi3JZgnoKw0pSwM pYCmJEbtWv25IsTovLg6EiCaY53Odyu7egAIauo9O/K2rY+OoSef0jKNCDig pRmas7lagb2n7kyJtC+TEmcm48GloiOtxzSnpWF9NKUsijgnQT6ocaweaJNZ orX+xJ2j3b84SNcUdiM9LWEluKU9paqmTqWth6G/9D+/r6V6jyclXKuHxNd7 q4slIiWgJqVloLYEhycPGLClFSv/CvilhKS8VKAlJb3qJqr/IrygoCWkBa4M AJAlpGIkzKAl07AkodnzBnBRpof0AmKPR4ElZz4/r1I9D6fDIIrRviq0IDoj NQcPvlv5fXdZMGTUZMTYxWEiV6EzWmEiasicDaZKWpNC1106yxKE6dm2O1Ik pKREICUlNaUkpKWlJSUlJSUlpaUlnVruYL4A8EYAjb4AIPn/V4PN/+l6AQAA kJCQigZGiAdHAdt1B4seg+78Edty7bgBAAAAAdt1B4seg+78EdsRwAHbc+91 CYseg+78Edtz5DHJg+gDcg3B4AiKBkaD8P90dInFAdt1B4seg+78EdsRyQHb dQeLHoPu/BHbEcl1IEEB23UHix6D7vwR2xHJAdtz73UJix6D7vwR23Pkg8EC gf0A8///g9EBjRQvg/38dg+KAkKIB0dJdffpY////5CLAoPCBIkHg8cEg+kE d/EBz+lM////Xon3uSsEAACKB0cs6DwBd/eAPwt18osHil8EZsHoCMHAEIbE KfiA6+gB8IkHg8cFidji2Y2+ANAHAIsHCcB0RYtfBI2EMAAACAAB81CDxwj/ lowACACVigdHCMB03In5eQcPtwdHUEe5V0jyrlX/lpAACAAJwHQHiQODwwTr 2P+WlAAIAIPHBI1e/DHAigdHCcB0IjzvdxEBw4sDhsTBwBCGxAHwiQPr4iQP weAQZosHg8cC6+Jh6aol+f8AcQC5HBEBAAvAC8k61Tr1CdsiwHUAgTQOLOI4 wTrGDAA76iPkwQQOGYjkI+SF+oEEDgh1bO4j2+LWCf8J7Yj2IMDpTf7///// zCDbCe2Iyek//v//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAMQQCACMEAgAAAAAAAAAAAAAAAAA0RAIAJwQCAAAAAAAAAAAAAAA AADeEAgApBAIAAAAAAAAAAAAAAAAAOYQCACsEAgAAAAAAAAAAAAAAAAA8RAI ALQQCAAAAAAAAAAAAAAAAAD8EAgAvBAIAAAAAAAAAAAAAAAAAAAAAAAAAAAA CBEIABYRCAAmEQgAAAAAADQRCAAAAAAAQhEIAAAAAABSEQgAAAAAAFgRCAAA AAAAAQAAgAAAAABLRVJORUwzMi5ETEwAQURWQVBJMzIuZGxsAE1QUi5kbGwA TVNWQ1JULmRsbABVU0VSMzIuZGxsAFdTT0NLMzIuZGxsAAAATG9hZExpYnJh cnlBAABHZXRQcm9jQWRkcmVzcwAARXhpdFByb2Nlc3MAAABSZWdDbG9zZUtl eQAAAFdOZXRPcGVuRW51bUEAAABwdXRjAABTZXRUaW1lcgAAAAAIAAwAAAAi MQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA ------------EBQUU5S47XMXCW-- From owner-linux-xfs@oss.sgi.com Wed Aug 13 22:53:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Aug 2003 22:53:32 -0700 (PDT) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7E5rJFl001400 for ; Wed, 13 Aug 2003 22:53:19 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7E3s1Qa026426 for ; Wed, 13 Aug 2003 20:54:01 -0700 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h7E5hP5J015252 for ; Thu, 14 Aug 2003 15:43:25 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h7E5hGQL015251 for linux-xfs@oss.sgi.com; Thu, 14 Aug 2003 15:43:16 +1000 Date: Thu, 14 Aug 2003 15:43:16 +1000 From: Nathan Scott Message-Id: <200308140543.h7E5hGQL015251@bruce.melbourne.sgi.com> Subject: TAKE - pagebuf X-archive-position: 30 X-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@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 929 Lines: 31 Fix a compiler warning, sync_fs returns a value. Date: Wed Aug 13 21:49:24 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/nathans/isms/devel The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:155786a linux/fs/xfs/linux/xfs_super.c - 1.267 Fix a race condition in async pagebuf IO completion, by moving blk queue manipulation down into pagebuf. Fix some busted comments in page_buf.h, use a more descriptive name for __pagebuf_iorequest. Date: Wed Aug 13 22:51:09 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/nathans/isms/devel The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:155788a linux/fs/xfs/xfs_buf.h - 1.111 linux/fs/xfs/pagebuf/page_buf_locking.c - 1.39 linux/fs/xfs/pagebuf/page_buf_internal.h - 1.27 linux/fs/xfs/pagebuf/page_buf.c - 1.130 linux/fs/xfs/pagebuf/page_buf.h - 1.70 From owner-linux-xfs@oss.sgi.com Wed Aug 13 23:06:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Aug 2003 23:06:32 -0700 (PDT) Received: from cpout1.tiscali.be (cpout1.tiscali.be [62.235.13.193]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7E66QFl001934 for ; Wed, 13 Aug 2003 23:06:28 -0700 Received: from [62.235.14.106] (helo=mail.tiscali.be) by cpout1.tiscali.be with esmtp (Tiscali) id 19nBC8-0001te-00; Thu, 14 Aug 2003 08:02:44 +0200 Received: from [57.67.177.33] by mail.tiscali.be with HTTP; Thu, 14 Aug 2003 08:06:17 +0200 Date: Thu, 14 Aug 2003 08:06:17 +0200 Message-ID: <3F2A5B0400002E29@ocpmta1.freegates.net> In-Reply-To: <1060805443.5851.27.camel@naboo> From: "Joel Soete" Subject: Re: cvs acces pb? To: "Russell Cattelan" Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-archive-position: 31 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: soete.joel@tiscali.be Precedence: bulk X-list: linux-xfs Content-Length: 361 Lines: 17 >a cron job on oss was filling the partition, job >has been nuked and space reclaimed. > >should be working fine now. Yes it does :) Thanks a lot for all, Joel ------------------------------------------------------------------------- Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous! http://reg.tiscali.be/default.asp?lg=fr From owner-linux-xfs@oss.sgi.com Thu Aug 14 00:33:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Aug 2003 00:33:30 -0700 (PDT) Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7E7X9Fl003088 for ; Thu, 14 Aug 2003 00:33:12 -0700 Received: from ralf.wg ([192.168.2.2]:2119) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 4.20) id 19nCbX-0007CE-9e for linux-xfs@oss.sgi.com; Thu, 14 Aug 2003 09:33:03 +0200 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Date: Thu, 14 Aug 2003 09:33:13 +0200 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2711) For Windows 2000 (5.0.2195;4) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: "linux-2.5.0-xfs-2003-08-13" on SGI FTP server??? X-SA-Exim-Mail-From: rabe@RWTH-Aachen.DE X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Message-ID: <19nCbX-0007CE-9e@ADSL-Bergs.RZ.RWTH-Aachen.DE> X-archive-position: 32 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rabe@RWTH-Aachen.DE Precedence: bulk X-list: linux-xfs Content-Length: 331 Lines: 19 Hi there, there's two files ftp://oss.sgi.com/projects/xfs/download/patches-2.5/linux-2.5.0-xfs-2003-08-13-* on SGI's FTP server. I can't believe that they really meant to name it 2.5.0 -- I guess that's rather 2.6.0?! Ralf -- L I N U X .~. The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Thu Aug 14 02:05:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Aug 2003 02:05:30 -0700 (PDT) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7E953Fl004287 for ; Thu, 14 Aug 2003 02:05:04 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla5.xs4all.nl (8.12.9/8.12.9) with ESMTP id h7E951lX065218; Thu, 14 Aug 2003 11:05:01 +0200 (CEST) Message-Id: <4.3.2.7.2.20030814110057.03df4a68@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Aug 2003 11:04:59 +0200 To: "Ralf G. R. Bergs" , "Linux XFS Mailing List" From: Seth Mos Subject: Re: "linux-2.5.0-xfs-2003-08-13" on SGI FTP server??? In-Reply-To: <19nCbX-0007CE-9e@ADSL-Bergs.RZ.RWTH-Aachen.DE> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 33 X-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: 769 Lines: 26 At 09:33 14-8-2003 +0200, Ralf G. R. Bergs wrote: >Hi there, > >there's two files > >ftp://oss.sgi.com/projects/xfs/download/patches-2.5/linux-2.5.0-xfs-2003-08-13-* > >on SGI's FTP server. I can't believe that they really meant to name it >2.5.0 -- >I guess that's rather 2.6.0?! Sort of. The tree is a 2.5-xfs tree and I think it got named as such. The 2.5-xfs CVS contains 2.6.0-test3 IIRC so I think the script might need some altering. ;-) Seeing that the patch is about 37 MiB I think the automatic snapshot script went belly-up and probably made a patch to go from 2.5.0 to 2.6.0-test3. Better wait for them to fix it. Meanwhile you could also check out the 2.5-xfs CVS if you want to. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Aug 14 02:12:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Aug 2003 02:13:13 -0700 (PDT) Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7E9CvFl004773 for ; Thu, 14 Aug 2003 02:12:58 -0700 Received: from ralf.wg ([192.168.2.2]:2372) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 4.21) id 19nEA7-0007cZ-UW for linux-xfs@oss.sgi.com; Thu, 14 Aug 2003 11:12:51 +0200 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Date: Thu, 14 Aug 2003 11:13:02 +0200 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2711) For Windows 2000 (5.0.2195;4) In-Reply-To: <4.3.2.7.2.20030814110057.03df4a68@pop.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: "linux-2.5.0-xfs-2003-08-13" on SGI FTP server??? X-SA-Exim-Mail-From: rabe@RWTH-Aachen.DE X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Message-ID: <19nEA7-0007cZ-UW@ADSL-Bergs.RZ.RWTH-Aachen.DE> X-archive-position: 34 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rabe@RWTH-Aachen.DE Precedence: bulk X-list: linux-xfs Content-Length: 274 Lines: 15 On Thu, 14 Aug 2003 11:04:59 +0200, Seth Mos wrote: [...] >Meanwhile you could also check out the 2.5-xfs CVS if you want to. I'd much rather see XFS 1.3 for 2.4.21. :-) -- L I N U X .~. The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Thu Aug 14 02:31:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Aug 2003 02:32:10 -0700 (PDT) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7E9VfFl006756 for ; Thu, 14 Aug 2003 02:31:46 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla2.xs4all.nl (8.12.9/8.12.9) with ESMTP id h7E9VdIo013708; Thu, 14 Aug 2003 11:31:39 +0200 (CEST) Message-Id: <4.3.2.7.2.20030814113116.03df4d38@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Aug 2003 11:31:37 +0200 To: "Ralf G. R. Bergs" , "Linux XFS Mailing List" From: Seth Mos Subject: Re: "linux-2.5.0-xfs-2003-08-13" on SGI FTP server??? In-Reply-To: <19nEA7-0007cZ-UW@ADSL-Bergs.RZ.RWTH-Aachen.DE> References: <4.3.2.7.2.20030814110057.03df4a68@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 35 X-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: 345 Lines: 16 At 11:13 14-8-2003 +0200, Ralf G. R. Bergs wrote: >On Thu, 14 Aug 2003 11:04:59 +0200, Seth Mos wrote: > >[...] > >Meanwhile you could also check out the 2.5-xfs CVS if you want to. > >I'd much rather see XFS 1.3 for 2.4.21. :-) pre5 is out there which is very close to that. Cheer -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Aug 14 05:19:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Aug 2003 05:19:38 -0700 (PDT) Received: from antoli.gallimedina.net (015.atlasinternet.net [212.9.93.15]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7ECJEFl010404 for ; Thu, 14 Aug 2003 05:19:17 -0700 Received: from gallir by antoli.gallimedina.net with local (Exim 4.20) id 19nH4N-0002gD-SJ for linux-xfs@oss.sgi.com; Thu, 14 Aug 2003 14:19:07 +0200 From: Ricardo Galli Organization: UIB To: linux-xfs@oss.sgi.com Subject: 2.6: XFS spins up the disk very often Date: Thu, 14 Aug 2003 14:19:07 +0200 User-Agent: KMail/1.5.3 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200308141419.07859.gallir@uib.es> X-archive-position: 36 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gallir@uib.es Precedence: bulk X-list: linux-xfs Content-Length: 1018 Lines: 29 Hi, since I started with 2.5 in my laptop, I noticed that the disk with XFS was spinning up continously. I checked with vmstats, and I saw I/O almost every 60 seconds. They were mainly outputs, among 11 and 250 blocks each time. I checked every process and redirected all syslogd to /dev/tty7 to be sure no processes were generating the I/O. I couldn't find any. So finally I repartitioned the disk and copied the whole system to a XFS partition and to an Ext3. Then I tested both, rebooting each time and changing the root fs. With Ext3 there is no problem, the disk spins off very rapidly, but XFS kept doing I/O's. So I checked it again in 2.4.21-ac4. Although there were more XFS I/O than with Ext3, they were not so frequent as in 2.6. I also played echoing different values to /proc/sys/fs/xfs/ and /proc/sys/vm/pagebuf/ files without noticeable changes. Is it a problem in 2.6 or the /proc parameters must be fine tuned? -- ricardo galli GPG id C8114D34 http://mnm.uib.es/~gallir/ From owner-linux-xfs@oss.sgi.com Thu Aug 14 07:15:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Aug 2003 07:16:02 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7EEFgFl012024 for ; Thu, 14 Aug 2003 07:15:43 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7EEFbq0004967 for ; Thu, 14 Aug 2003 07:15:37 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7EEEVQK7028107; Thu, 14 Aug 2003 09:14:31 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7EEEVRn228779537; Thu, 14 Aug 2003 09:14:31 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h7EEEUZ19575; Thu, 14 Aug 2003 09:14:30 -0500 Subject: Re: 2.6: XFS spins up the disk very often From: Steve Lord To: Ricardo Galli Cc: linux-xfs@oss.sgi.com In-Reply-To: <200308141419.07859.gallir@uib.es> References: <200308141419.07859.gallir@uib.es> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1060870468.17246.36.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 14 Aug 2003 09:14:28 -0500 X-archive-position: 37 X-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: 1348 Lines: 37 On Thu, 2003-08-14 at 07:19, Ricardo Galli wrote: > Hi, > > since I started with 2.5 in my laptop, I noticed that the disk with XFS was > spinning up continously. I checked with vmstats, and I saw I/O almost every > 60 seconds. They were mainly outputs, among 11 and 250 blocks each time. > > I checked every process and redirected all syslogd to /dev/tty7 to be sure no > processes were generating the I/O. I couldn't find any. > > So finally I repartitioned the disk and copied the whole system to a XFS > partition and to an Ext3. Then I tested both, rebooting each time and > changing the root fs. > > With Ext3 there is no problem, the disk spins off very rapidly, but XFS kept > doing I/O's. > > So I checked it again in 2.4.21-ac4. Although there were more XFS I/O than > with Ext3, they were not so frequent as in 2.6. > > I also played echoing different values to /proc/sys/fs/xfs/ and > /proc/sys/vm/pagebuf/ files without noticeable changes. > > Is it a problem in 2.6 or the /proc parameters must be fine tuned? Hmm, I would expect one or two writes like this over a 1 to 2 minute period after some activity, but after that it should idle down. I will take a look. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Aug 14 12:37:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Aug 2003 12:37:23 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7EJb8Fl006507 for ; Thu, 14 Aug 2003 12:37:08 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7EJb3q0005585 for ; Thu, 14 Aug 2003 12:37:03 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7EJZvQK7062645 for ; Thu, 14 Aug 2003 14:35:57 -0500 (CDT) Received: from sgi.com (chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7EJZvRn231526161 for ; Thu, 14 Aug 2003 14:35:57 -0500 (CDT) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h7EJZv56025818 for ; Thu, 14 Aug 2003 14:35:57 -0500 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.8/8.12.8/Submit) id h7EJZutO025816 for linux-xfs@oss.sgi.com; Thu, 14 Aug 2003 14:35:56 -0500 Date: Thu, 14 Aug 2003 14:35:56 -0500 From: Russell Cattelan Message-Id: <200308141935.h7EJZutO025816@chuckle.americas.sgi.com> Subject: TAKE - Fix one more fsid_t type. X-archive-position: 38 X-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@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 303 Lines: 13 Date: Thu Aug 14 12:35:39 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:155873a linux/fs/xfs/linux/xfs_vfs.h - 1.45 - Missed this fsid_t the first time around From owner-linux-xfs@oss.sgi.com Thu Aug 14 17:03:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Aug 2003 17:03:53 -0700 (PDT) Received: from hueymiccailhuitl.mtu.ru (hueytecuilhuitl.mtu.ru [195.34.32.123]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7F03YFl010765 for ; Thu, 14 Aug 2003 17:03:36 -0700 Received: from mtu-net.ru (ppp140-26.dialup.mtu-net.ru [62.118.140.26]) by hueymiccailhuitl.mtu.ru (Postfix) with ESMTP id 048BE1CAF5F for ; Fri, 15 Aug 2003 04:03:32 +0400 (MSD) (envelope-from estaf_141@mtu-net.ru) Message-ID: <3F3C235C.2090307@mtu-net.ru> Date: Fri, 15 Aug 2003 04:03:40 +0400 From: Dmitry Nesterov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs and kernel-2.4.20 of Slackware 9.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 39 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: estaf_141@mtu-net.ru Precedence: bulk X-list: linux-xfs Content-Length: 324 Lines: 13 Hi Excuse me of my crocked english I'm only is styduing it How will make this subj to The Slackware 9.0? I didn't paths of it on the kernel-2.4.20 witch attachment with Slackware 9.0 on it's cd. I fond patchs to this kernel and kernel faulted after it only. Where can I read abot this problem? Best regards Dmitry Moscou From owner-linux-xfs@oss.sgi.com Thu Aug 14 18:25:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Aug 2003 18:26:03 -0700 (PDT) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7F1PjFl011734 for ; Thu, 14 Aug 2003 18:25:45 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7ENQTQa007163 for ; Thu, 14 Aug 2003 16:26:30 -0700 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h7F1Pf4i003532 for ; Fri, 15 Aug 2003 11:25:41 +1000 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h7F1Pfud003531 for linux-xfs@oss.sgi.com; Fri, 15 Aug 2003 11:25:41 +1000 Date: Fri, 15 Aug 2003 11:25:41 +1000 From: FSG QA Message-Id: <200308150125.h7F1Pfud003531@bruce.melbourne.sgi.com> Subject: TAKE - xfstests X-archive-position: 40 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 404 Lines: 16 Add a new growfs test 078, and do a better job of cleaning tmp files after a QA run. Date: Thu Aug 14 18:24:41 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/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:155935a cmd/xfstests/078 - 1.1 cmd/xfstests/078.out - 1.1 cmd/xfstests/check - 1.16 cmd/xfstests/group - 1.41 From owner-linux-xfs@oss.sgi.com Thu Aug 14 18:30:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Aug 2003 18:30:09 -0700 (PDT) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7F1U6Fl012183 for ; Thu, 14 Aug 2003 18:30:06 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7ENUoQa007662 for ; Thu, 14 Aug 2003 16:30:51 -0700 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h7F1U24i003627 for ; Fri, 15 Aug 2003 11:30:02 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h7F1U2Ys003626 for linux-xfs@oss.sgi.com; Fri, 15 Aug 2003 11:30:02 +1000 Date: Fri, 15 Aug 2003 11:30:02 +1000 From: Nathan Scott Message-Id: <200308150130.h7F1U2Ys003626@bruce.melbourne.sgi.com> Subject: TAKE - growfs X-archive-position: 41 X-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@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 356 Lines: 13 Use the rounded down size value for all growfs calculations, else the last AG can be updated incorrectly. Date: Thu Aug 14 18:28:24 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/nathans/isms/devel The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:155936a linux/fs/xfs/xfs_fsops.c - 1.93 From owner-linux-xfs@oss.sgi.com Thu Aug 14 18:44:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Aug 2003 18:44:58 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h7F1itFl012654 for ; Thu, 14 Aug 2003 18:44:55 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7F1isPY012653 for linux-xfs@oss.sgi.com; Thu, 14 Aug 2003 18:44:54 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h7F1irFl012639 for ; Thu, 14 Aug 2003 18:44:53 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7F1fMd5012630; Thu, 14 Aug 2003 18:41:22 -0700 Date: Thu, 14 Aug 2003 18:41:22 -0700 Message-Id: <200308150141.h7F1fMd5012630@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 274] New: xfs_iunlink_remove: xfs_inotobp() returned error 22 X-Bugzilla-Reason: AssignedTo X-archive-position: 42 X-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: 1423 Lines: 39 http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 Summary: xfs_iunlink_remove: xfs_inotobp() returned error 22 Product: Linux XFS Version: Current Platform: AMD OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: walt_holman@generalplastics.com One of our servers recently reported the above error in its logs and shutdown the running filesystem. The server is an AMD 2x2200 SMP machine with software raid 5 consisting of 6 x U160 SCSI drives connected via the onboard AIC7902 adaptec controller. The partition in question is a used for user specific fileserver store. It is shared via samba and netatalk. It is running linux-xfs pulled from CVS @ 7/19/2003 with latest aic79xx code taken from Justin Gibbs download area. The server didn't oops, and on reboot, an xfs_check showed the filesystem in question to be clean. Any input on the stability of current CVS is welcome, as I plan on updating it this weekend in hopes of pre-empting a recurrence. The hardware is: Tyan K7X Pro 2469-u MB w/ integrated AIC7902 2 x AMD 2200MP 1 GB Reg. ECC Ram 6 x 36 GB U160 SCSI Disks Software Raid5 - multiple md's. ------- 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 Aug 14 19:44:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Aug 2003 19:45:13 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h7F2itFl014230 for ; Thu, 14 Aug 2003 19:44:55 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7F2it6E014229 for linux-xfs@oss.sgi.com; Thu, 14 Aug 2003 19:44:55 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h7F2irFl014215 for ; Thu, 14 Aug 2003 19:44:53 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7F2a5QE013935; Thu, 14 Aug 2003 19:36:05 -0700 Date: Thu, 14 Aug 2003 19:36:05 -0700 Message-Id: <200308150236.h7F2a5QE013935@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 274] xfs_iunlink_remove: xfs_inotobp() returned error 22 X-Bugzilla-Reason: AssignedTo X-archive-position: 43 X-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: 484 Lines: 18 http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 ------- Additional Comments From nathans@sgi.com 2003-14-08 19:36 PDT ------- Can you transcribe the (exact) error message? From looking at the code, you should have at least two lines in your log (can you send both please). The xfs_info output from the mounted filesystem may prove useful as well. 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 Aug 14 20:44:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Aug 2003 20:45:09 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h7F3itFl015135 for ; Thu, 14 Aug 2003 20:44:55 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7F3itlV015134 for linux-xfs@oss.sgi.com; Thu, 14 Aug 2003 20:44:55 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h7F3irFl015119 for ; Thu, 14 Aug 2003 20:44:53 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7F2teMi014784; Thu, 14 Aug 2003 19:55:40 -0700 Date: Thu, 14 Aug 2003 19:55:40 -0700 Message-Id: <200308150255.h7F2teMi014784@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 274] xfs_iunlink_remove: xfs_inotobp() returned error 22 X-Bugzilla-Reason: AssignedTo X-archive-position: 44 X-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: 1443 Lines: 38 http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 ------- Additional Comments From walt_holman@generalplastics.com 2003-14-08 19:55 PDT ------- Sorry about that. Here's the relevant info taken from: /var/log/kernel/info Aug 13 12:21:04 goliath kernel: xfs_inactive:^Ixfs_ifree() returned an error = 22 on md(9,2) Aug 13 12:21:04 goliath kernel: xfs_force_shutdown(md(9,2),0x1) called from line 1846 of file xfs_vnodeops.c. Return address = 0xc01eaa5b /var/log/kernel/warnings Aug 13 12:21:04 goliath kernel: xfs_inotobp: xfs_imap() returned an error 22 on md(9,2). Returning error. Aug 13 12:21:04 goliath kernel: xfs_iunlink_remove: xfs_inotobp() returned an error 22 on md(9,2). Returning error. [root@goliath kernel]# xfs_info /home meta-data=/home isize=256 agcount=12, agsize=262144 blks = sectsz=512 data = bsize=4096 blocks=3076352, imaxpct=25 = sunit=16 swidth=80 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=8192, version=2 = sectsz=512 sunit=16 blks realtime =none extsz=327680 blocks=0, rtextents=0 I forgot to mention it earlier, but kernel is 2.4.21 from CVS. ------- 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 Aug 15 01:11:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Aug 2003 01:11:55 -0700 (PDT) Received: from pechkin.minfin.bg (pechkin.minfin.bg [212.122.164.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7F8BXFl020930 for ; Fri, 15 Aug 2003 01:11:35 -0700 Received: (qmail 7485 invoked by uid 64014); 15 Aug 2003 08:11:31 -0000 Received: from larry@minfin.bg by mail.minfin.bg by uid 64011 with qmail-scanner-1.15 (fsecure: 4.14/4062/ Clear:. Processed in 0.842426 secs); 15 Aug 2003 08:11:31 -0000 Received: from unknown (HELO larry2) (10.40.1.15) by pechkin.minfin.bg with SMTP; 15 Aug 2003 08:11:29 -0000 Reply-To: From: "Kostadin Todorov Karaivanov" To: "'Dmitry Nesterov'" , Subject: RE: xfs and kernel-2.4.20 of Slackware 9.0 Date: Fri, 15 Aug 2003 11:11:34 +0300 Organization: Ministry of Finance Message-ID: <006801c36304$d78c21d0$0f01280a@minfin.bg> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3F3C235C.2090307@mtu-net.ru> Importance: Normal X-archive-position: 45 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: larry@minfin.bg Precedence: bulk X-list: linux-xfs Content-Length: 866 Lines: 31 Can't understand ....:-)) Write to me in private (in russian), my russian I beter than your english so I will try to answer you if I can. Kostadin Karaivanov Senior System Administrator @ Ministry Of Finance tel: +359 2 98592062 k.karaivanov@minfin.bg > -----Original Message----- > From: linux-xfs-bounce@oss.sgi.com > [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Dmitry Nesterov > Sent: Friday, August 15, 2003 3:04 AM > To: linux-xfs@oss.sgi.com > Subject: xfs and kernel-2.4.20 of Slackware 9.0 > > > Hi > Excuse me of my crocked english > I'm only is styduing it > > How will make this subj to The Slackware 9.0? > I didn't paths of it on the kernel-2.4.20 witch attachment with > Slackware 9.0 on it's cd. > I fond patchs to this kernel and kernel faulted after it > only. Where can I read abot this problem? Best regards Dmitry Moscou > > From owner-linux-xfs@oss.sgi.com Fri Aug 15 05:59:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Aug 2003 05:59:36 -0700 (PDT) Received: from mx6.mail.ru (mx6.mail.ru [194.67.23.26]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FCxHFl028124 for ; Fri, 15 Aug 2003 05:59:18 -0700 Received: from [151.203.243.241] (port=49196 helo=kan.dnsalias.net) by mx6.mail.ru with esmtp id 19neAm-0001mU-00; Fri, 15 Aug 2003 16:59:17 +0400 Received: from kan.dnsalias.net (ak03@localhost [127.0.0.1]) by kan.dnsalias.net (8.12.9/8.12.9) with ESMTP id h7FCxD2E000990; Fri, 15 Aug 2003 08:59:13 -0400 (EDT) (envelope-from kan@kan.dnsalias.net) Received: (from kan@localhost) by kan.dnsalias.net (8.12.9/8.12.9/Submit) id h7FCxDT1000989; Fri, 15 Aug 2003 08:59:13 -0400 (EDT) Date: Fri, 15 Aug 2003 08:59:13 -0400 From: Alexander Kabaev To: Dmitry Nesterov Cc: linux-xfs@oss.sgi.com Subject: Re: xfs and kernel-2.4.20 of Slackware 9.0 Message-Id: <20030815085913.149fec2f.kabaev@mail.ru> In-Reply-To: <3F3C235C.2090307@mtu-net.ru> References: <3F3C235C.2090307@mtu-net.ru> X-Mailer: Sylpheed version 0.9.3claws78 (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam: Not detected X-archive-position: 46 X-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@mail.ru Precedence: bulk X-list: linux-xfs Content-Length: 878 Lines: 33 On Fri, 15 Aug 2003 04:03:40 +0400 Dmitry Nesterov wrote: > Hi > Excuse me of my crocked english > I'm only is styduing it > > How will make this subj to The Slackware 9.0? > I didn't paths of it on the kernel-2.4.20 witch attachment with > Slackware 9.0 on it's cd. > I fond patchs to this kernel and kernel faulted after it only. > Where can I read abot this problem? > Best regards > Dmitry > Moscou > My half-assed translation: Hi, I would like to know how to add XFS support to the Linux kernel shipped with Slackware 9.0. I didn't find any traces of XFS in the kernel sources tarball on Slackware 9.0 CD. I then found XFS patches (elsewhere??) for this kernel and applied them, but the new kernel just faults now. Where I can find more info about proper to enable XFS on Slackware? Best regards, Dmitry P.S. Dmitry, have I guessed wrong? From owner-linux-xfs@oss.sgi.com Fri Aug 15 11:12:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Aug 2003 11:12:44 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FICPFl002489 for ; Fri, 15 Aug 2003 11:12:25 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7FICJq0029398 for ; Fri, 15 Aug 2003 11:12:20 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7FICEQK7241264 for ; Fri, 15 Aug 2003 13:12:14 -0500 (CDT) Received: from sgi.com (chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7FICERn228086098 for ; Fri, 15 Aug 2003 13:12:14 -0500 (CDT) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h7FICD56006213 for ; Fri, 15 Aug 2003 13:12:14 -0500 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.8/8.12.8/Submit) id h7FIC5JO006142 for linux-xfs@oss.sgi.com; Fri, 15 Aug 2003 13:12:05 -0500 Date: Fri, 15 Aug 2003 13:12:05 -0500 From: Russell Cattelan Message-Id: <200308151812.h7FIC5JO006142@chuckle.americas.sgi.com> Subject: TAKE - merge all the pre6 stuff X-archive-position: 47 X-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@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1915 Lines: 63 Rework pagebuf_delwri_flush to be list safe Date: Thu Aug 14 12:53:19 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-r1.3 Author: cattelan Merged by: cattelan Merged mods: xfs-linux:slinx:155660a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.3 Modid: 2.4.x-xfs-r1.3:slinx:155660a linux/fs/xfs/pagebuf/page_buf.c - 1.125 - Merge of xfs-linux:slinx:155660a by cattelan. Rework the global list handling of pbd_delwrite_queue. We were dropping the list lock while scanning the list while starting pagebuf IO, which could lead to an inconsistent list. Change the code to scan the list looking for all pagebuf's that can be flushed placing them on a local temporary list. Then walk the temporary list NOT under the global lock firing off IO and subsequently waiting for IO to finish if told to so. Subject: TAKE - Fix one more fsid_t type. Date: Thu Aug 14 13:03:22 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-r1.3 Author: cattelan Merged by: cattelan Merged mods: xfs-linux:slinx:155873a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.3 Modid: 2.4.x-xfs-r1.3:slinx:155873a linux/fs/xfs/linux/xfs_vfs.h - 1.43 - Merge of xfs-linux:slinx:155873a by cattelan. Missed this fsid_t the first time around Subject: TAKE - Use the rounded down size value for all growfs calculations, else the last AG can be updated incorrectly Date: Fri Aug 15 11:11:19 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-r1.3 Author: nathans Merged by: cattelan Merged mods: xfs-linux:slinx:155936a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.3 Modid: 2.4.x-xfs-r1.3:slinx:155936a linux/fs/xfs/xfs_fsops.c - 1.91 - Merge of xfs-linux:slinx:155936a by cattelan. From owner-linux-xfs@oss.sgi.com Fri Aug 15 12:02:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Aug 2003 12:02:53 -0700 (PDT) Received: from pdcnet3.precisiondrilling.com (pdgw1.precisiondrilling.com [209.82.114.190]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FJ2bFl003377 for ; Fri, 15 Aug 2003 12:02:38 -0700 Received: from gerry.edmonton.computalog.com ([10.89.4.25]) by pdcnet3.precisiondrilling.com (Lotus Domino Release 5.0.12) with ESMTP id 2003081513050074:18759 ; Fri, 15 Aug 2003 13:05:00 -0600 Received: by gerry.edmonton.computalog.com (Postfix, from userid 1000) id 2F1A24004C0; Fri, 15 Aug 2003 13:02:21 -0600 (MDT) Date: Fri, 15 Aug 2003 13:02:21 -0600 From: "Gerard W. Patterson" To: linux-xfs@oss.sgi.com Subject: Re: [ANNOUNC] linux-2.4+xfs tree Message-ID: <20030815190221.GA28550@computalog.com> References: <1060300430.24377.64.camel@naboo> Mime-Version: 1.0 In-Reply-To: <1060300430.24377.64.camel@naboo> User-Agent: Mutt/1.5.4i X-MIMETrack: Itemize by SMTP Server on PDCNET3/PDCMAIL(Release 5.0.12 |February 13, 2003) at 08/15/2003 01:05:01 PM, Serialize by Router on PDCNET3/PDCMAIL(Release 5.0.12 |February 13, 2003) at 08/15/2003 01:05:08 PM, Serialize complete at 08/15/2003 01:05:08 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 48 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gerry.patterson@computalog.com Precedence: bulk X-list: linux-xfs Content-Length: 949 Lines: 34 Hello, Is there a way to access tree via CVS? Sorry, I have never used bitkeeper before, however I did go out and get the client. When I try the command below, it does 'its thing' but it takes a _very_ long time, eventually dies, and all I get is a tree with no files execpt in the SCCS subdirectories. Is there a way to continue the 'clone' command if it dies in the middle? Perhaps something happens at the end that makes things right. Thanks in advance, - Gerry On Thu, Aug 07, 2003 at 06:53:50PM -0500, Russell Cattelan wrote: > Just a quick note anybody who wants to play with > xfs on 2.4.22 can grab this BitKeeper tree. > bk clone http://xfs.org:8090/linux-2.4+xfs > > I think the tree has all the correct bits in it > but I'm late for something so I don't have time > to test it tonight. > If anybody is feeling brave check it out and report > back. > > -Russell > > > -- Gerard W. Patterson From owner-linux-xfs@oss.sgi.com Fri Aug 15 12:18:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Aug 2003 12:18:27 -0700 (PDT) Received: from utahia.sweeney.demon.co.uk (213-152-33-154.dsl.eclipse.net.uk [213.152.33.154]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FJIMFl003943 for ; Fri, 15 Aug 2003 12:18:23 -0700 Received: from arequipa.sweeney.demon.co.uk (unknown [10.0.0.180]) by utahia.sweeney.demon.co.uk (Postfix) with SMTP id 3617010999D for ; Fri, 15 Aug 2003 20:23:07 +0100 (BST) Date: Fri, 15 Aug 2003 20:25:13 +0100 From: Keith Matthews To: linux-xfs@oss.sgi.com Subject: Re: xfs and kernel-2.4.20 of Slackware 9.0 Message-Id: <20030815202513.403d0c29.keith_m@sweeney.demon.co.uk> In-Reply-To: <20030815085913.149fec2f.kabaev@mail.ru> References: <3F3C235C.2090307@mtu-net.ru> <20030815085913.149fec2f.kabaev@mail.ru> 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: 49 X-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: 1209 Lines: 43 On Fri, 15 Aug 2003 08:59:13 -0400 Alexander Kabaev wrote: > On Fri, 15 Aug 2003 04:03:40 +0400 > Dmitry Nesterov wrote: > > > Hi > > Excuse me of my crocked english > > I'm only is styduing it > > > > How will make this subj to The Slackware 9.0? > > I didn't paths of it on the kernel-2.4.20 witch attachment with > > Slackware 9.0 on it's cd. > > I fond patchs to this kernel and kernel faulted after it only. > > Where can I read abot this problem? > > Best regards > > Dmitry > > Moscou > > > My half-assed translation: > > Hi, > > I would like to know how to add XFS support to the Linux kernel > shipped with Slackware 9.0. I didn't find any traces of XFS in the > kernel sources tarball on Slackware 9.0 CD. I then found XFS patches > (elsewhere??) for this kernel and applied them, but the new kernel > just faults now. Where I can find more info about proper to enable XFS > on Slackware? > > Best regards, > Dmitry > > > P.S. Dmitry, have I guessed wrong? > If that really is the question then the answer is that Slack 9 ships with a ready-to-use XFS enabled kernel. but it may not be on the CD. The download version has it in kernels/xfs.i From owner-linux-xfs@oss.sgi.com Fri Aug 15 12:37:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Aug 2003 12:37:32 -0700 (PDT) Received: from rev-server-00.ssn.revario.com ([65.115.136.1]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FJbPFl004447 for ; Fri, 15 Aug 2003 12:37:26 -0700 Received: from [192.168.100.10] (blackbird [192.168.100.10]) by rev-server-00.ssn.revario.com (8.12.3/8.12.3/Debian-5.1) with ESMTP id h7FJbGi3022638 for ; Fri, 15 Aug 2003 15:37:21 -0400 Subject: NULL file problems (not FAQ...) From: Derek Glidden To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1060976194.4321.29.camel@blackbird.ssn.revario.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 15 Aug 2003 15:36:34 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 50 X-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: 1561 Lines: 32 I have a new laptop (Dell Inspiron 5150) on which I've been trying to get Linux stabilized. The ATI Radeon Mobility M9 is slightly problematic, so it's been crashing a lot while I'm in X. I've been running XFS with just one big filesystem on it, with 2.4.21 & recent 2.4.21-all patch applied, on top of RedHat 9. A couple of times now, the thing has gone down hard requiring a power cycle (no sync possible), only to find my /etc/fstab is full of nulls on reboot. Strangely, that's the only file that's been getting "eaten" by the null-file thing. The thing that is really confusing me is: why the heck is fstab being eaten and why only fstab? "lsof" on this machine right this moment does not show that fstab is open. Has anyone else had this problem with RedHat9? Does anyone have any other thoughts on why this would be happening? Unfortunately (fortunately?) it hasn't happened every time it's crashed, so I've not bothered with booting from the LNX-BBC "rescue" CD I made to do an xfs_check against the filesystem before it gets mounted and autorepaired, so I don't know if the fstab is already trashed at the time of the crash, or if the auto-repair is somehow mangling it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "We all enter this world in the | Support Electronic Freedom same way: naked; screaming; soaked | http://www.eff.org/ in blood. But if you live your | http://www.anti-dmca.org/ life right, that kind of thing |--------------------------- doesn't have to stop there." -- Dana Gould From owner-linux-xfs@oss.sgi.com Fri Aug 15 12:41:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Aug 2003 12:41:53 -0700 (PDT) Received: from linux-sxs.org (dhcp065-024-128-253.columbus.rr.com [65.24.128.253]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FJflFl004904 for ; Fri, 15 Aug 2003 12:41:48 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.9/8.12.9) with ESMTP id h7FJfgwO019739; Fri, 15 Aug 2003 15:41:42 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.9/8.12.9/Submit) with ESMTP id h7FJfgSC001584; Fri, 15 Aug 2003 15:41:42 -0400 Date: Fri, 15 Aug 2003 15:41:42 -0400 (EDT) From: Net Llama! To: Derek Glidden cc: linux-xfs@oss.sgi.com Subject: Re: NULL file problems (not FAQ...) In-Reply-To: <1060976194.4321.29.camel@blackbird.ssn.revario.com> Message-ID: References: <1060976194.4321.29.camel@blackbird.ssn.revario.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.35 X-archive-position: 51 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1215 Lines: 25 On Fri, 15 Aug 2003, Derek Glidden wrote: > > I have a new laptop (Dell Inspiron 5150) on which I've been trying to > get Linux stabilized. The ATI Radeon Mobility M9 is slightly > problematic, so it's been crashing a lot while I'm in X. I've been > running XFS with just one big filesystem on it, with 2.4.21 & recent > 2.4.21-all patch applied, on top of RedHat 9. A couple of times now, > the thing has gone down hard requiring a power cycle (no sync possible), > only to find my /etc/fstab is full of nulls on reboot. Strangely, > that's the only file that's been getting "eaten" by the null-file thing. > > The thing that is really confusing me is: why the heck is fstab being > eaten and why only fstab? "lsof" on this machine right this moment does > not show that fstab is open. Has anyone else had this problem with > RedHat9? Does anyone have any other thoughts on why this would be > happening? I think that's a kudzu bug. I've seen the same thing occur on RH-7.3 as well on boxes that kudzu didn't get along with. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Fri Aug 15 12:55:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Aug 2003 12:55:24 -0700 (PDT) Received: from rev-server-00.ssn.revario.com ([65.115.136.1]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FJtIFl005432 for ; Fri, 15 Aug 2003 12:55:18 -0700 Received: from [192.168.100.10] (blackbird [192.168.100.10]) by rev-server-00.ssn.revario.com (8.12.3/8.12.3/Debian-5.1) with ESMTP id h7FJsvi3022750; Fri, 15 Aug 2003 15:55:02 -0400 Subject: Re: NULL file problems (not FAQ...) From: Derek Glidden To: Net Llama! Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <1060976194.4321.29.camel@blackbird.ssn.revario.com> Content-Type: text/plain Organization: Message-Id: <1060977257.4321.40.camel@blackbird.ssn.revario.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 15 Aug 2003 15:54:18 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 52 X-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: 1566 Lines: 37 On Fri, 2003-08-15 at 15:41, Net Llama! wrote: > > The thing that is really confusing me is: why the heck is fstab being > > eaten and why only fstab? "lsof" on this machine right this moment does > > not show that fstab is open. Has anyone else had this problem with > > RedHat9? Does anyone have any other thoughts on why this would be > > happening? > > I think that's a kudzu bug. I've seen the same thing occur on RH-7.3 as > well on boxes that kudzu didn't get along with. Hmm, it looks like you're probably right. (I'm normally a Debian guy, but woody just doesn't work on this laptop, and I'm not an "unstable" kind of guy...) I'd removed kudzu from running on startup, but it looks like something called "updfstab" is running from elsewhere in the system startup on RedHat. The fact that the file winds up full of nulls made me think it was that nasty old XFS "issue" mysteriously biting me again. I will investigate further. (I'm pretty happy with RedHat so far, except for the lack of "native" XFS support and despite really weird things it does like this 'updfstab' thing. I can't wait until there's a 2.6-based RedHat that will _force_ them to have XFS support... :) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "We all enter this world in the | Support Electronic Freedom same way: naked; screaming; soaked | http://www.eff.org/ in blood. But if you live your | http://www.anti-dmca.org/ life right, that kind of thing |--------------------------- doesn't have to stop there." -- Dana Gould From owner-linux-xfs@oss.sgi.com Fri Aug 15 14:39:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Aug 2003 14:39:45 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FLdVFl007956 for ; Fri, 15 Aug 2003 14:39:31 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7FLdPq0016880 for ; Fri, 15 Aug 2003 14:39:26 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7FLdKQK7236300 for ; Fri, 15 Aug 2003 16:39:20 -0500 (CDT) Received: from sgi.com (chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7FLdJRn233438682 for ; Fri, 15 Aug 2003 16:39:20 -0500 (CDT) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h7FLdJ56009573 for ; Fri, 15 Aug 2003 16:39:19 -0500 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.8/8.12.8/Submit) id h7FLdJcp009571 for linux-xfs@oss.sgi.com; Fri, 15 Aug 2003 16:39:19 -0500 Date: Fri, 15 Aug 2003 16:39:19 -0500 From: Russell Cattelan Message-Id: <200308152139.h7FLdJcp009571@chuckle.americas.sgi.com> Subject: TAKE - Clean up fsid_t abuses in dmapi X-archive-position: 53 X-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@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 531 Lines: 22 Date: Fri Aug 15 14:38:53 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:155999a linux/fs/xfs/dmapi/dmapi_register.c - 1.26 - Clean up fsid_t abuses in dmapi linux/fs/xfs/dmapi/dmapi_private.h - 1.13 - Clean up fsid_t abuses in dmapi linux/fs/xfs/dmapi/dmapi_event.c - 1.16 - Clean up fsid_t abuses in dmapi linux/fs/xfs/dmapi/dmapi_right.c - 1.19 - Clean up fsid_t abuses in dmapi From owner-linux-xfs@oss.sgi.com Fri Aug 15 14:42:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Aug 2003 14:42:10 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FLg7Fl008304 for ; Fri, 15 Aug 2003 14:42:07 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7FLg2q0017222 for ; Fri, 15 Aug 2003 14:42:02 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7FLg1QK7273242 for ; Fri, 15 Aug 2003 16:42:01 -0500 (CDT) Received: from sgi.com (chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7FLg1Rn222398093 for ; Fri, 15 Aug 2003 16:42:01 -0500 (CDT) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h7FLg156009907 for ; Fri, 15 Aug 2003 16:42:01 -0500 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.8/8.12.8/Submit) id h7FLg1qA009905 for linux-xfs@oss.sgi.com; Fri, 15 Aug 2003 16:42:01 -0500 Date: Fri, 15 Aug 2003 16:42:01 -0500 From: Russell Cattelan Message-Id: <200308152142.h7FLg1qA009905@chuckle.americas.sgi.com> Subject: TAKE - fsid_t to 1.3.0 X-archive-position: 54 X-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@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 591 Lines: 22 Clean up fsid_t abuses in dmapi Date: Fri Aug 15 14:41:33 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-r1.3 Author: cattelan Merged by: cattelan Merged mods: xfs-linux:slinx:155999a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.3 Modid: 2.4.x-xfs-r1.3:slinx:155999a linux/fs/xfs/dmapi/dmapi_event.c - 1.14 linux/fs/xfs/dmapi/dmapi_private.h - 1.11 linux/fs/xfs/dmapi/dmapi_register.c - 1.24 linux/fs/xfs/dmapi/dmapi_right.c - 1.17 - Merge of xfs-linux:slinx:155999a by cattelan. Clean up fsid_t abuses in dmapi From owner-linux-xfs@oss.sgi.com Fri Aug 15 16:35:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Aug 2003 16:35:43 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FNZSFl013239 for ; Fri, 15 Aug 2003 16:35:29 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7FNZMq0027439 for ; Fri, 15 Aug 2003 16:35:22 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7FNYGQK7289283 for ; Fri, 15 Aug 2003 18:34:16 -0500 (CDT) Received: from naboo (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7FNYGRn230660236 for ; Fri, 15 Aug 2003 18:34:16 -0500 (CDT) Subject: [ANNOUNCE] XFS 1.3.0 pre6 From: Russell Cattelan To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1060990455.7302.54.camel@naboo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4-1mdk Date: Fri, 15 Aug 2003 18:34:16 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 55 X-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: 521 Lines: 19 Yes I know we keep promising to just flat out release 1.3.0 but little bugs keep cropping up. But giving that we always seem to put stuff out on fridays :-) I'll try to compile a complete list of over the weekend but in the mean time the new patches are on oss. ftp://oss.sgi.com/projects/xfs/Release-1.3/pre6/kernel_patches/ The cmd rpms/tars have also been update as they have several small fixes also. The Red* rpms are compiling now and will upload to oss when they are done. -Russell Cattelan cattelan@xfs.org From owner-linux-xfs@oss.sgi.com Fri Aug 15 23:54:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Aug 2003 23:54:38 -0700 (PDT) Received: from web40410.mail.yahoo.com (web40410.mail.yahoo.com [66.218.78.107]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7G6sXFl017204 for ; Fri, 15 Aug 2003 23:54:34 -0700 Message-ID: <20030816065428.56233.qmail@web40410.mail.yahoo.com> Received: from [203.123.165.52] by web40410.mail.yahoo.com via HTTP; Fri, 15 Aug 2003 23:54:28 PDT Date: Fri, 15 Aug 2003 23:54:28 -0700 (PDT) From: girish dudhe Subject: How large file store in XFS To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 56 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: girish_dudhe@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 576 Lines: 21 hi all, In XFS,whole file systen is divided into number of allocation group. e.g. Consider size of the file system is 1GB ,then it will create eight allocation group that means each has 125 MB.Each allocation Group has its own inodes and data blocks. Now I want to store the file of size 500MB.How it gets stored ? Whether it gets stores in one allocation group or multiple allocation group? Thanks in advance , Girish __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From owner-linux-xfs@oss.sgi.com Sat Aug 16 03:38:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Aug 2003 03:38:56 -0700 (PDT) Received: from iris.acsalaska.net (iris.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7GAcCFl021887 for ; Sat, 16 Aug 2003 03:38:12 -0700 Received: from erbenson.alaska.net (156-pm3.nwc.alaska.net [209.112.138.156]) by iris.acsalaska.net (8.12.9/8.12.9) with ESMTP id h7G86vSj084859 for ; Sat, 16 Aug 2003 00:06:57 -0800 (AKDT) (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 D11C739E8 for ; Sat, 16 Aug 2003 00:06:56 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 14C8B40FF44; Sat, 16 Aug 2003 00:06:56 -0800 (AKDT) Date: Sat, 16 Aug 2003 00:06:55 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: NULL file problems (not FAQ...) Message-ID: <20030816080655.GE4735@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1060976194.4321.29.camel@blackbird.ssn.revario.com> <1060977257.4321.40.camel@blackbird.ssn.revario.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Oiv9uiLrevHtW1RS" Content-Disposition: inline In-Reply-To: <1060977257.4321.40.camel@blackbird.ssn.revario.com> 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.35 X-archive-position: 57 X-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: 768 Lines: 30 --Oiv9uiLrevHtW1RS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 15, 2003 at 03:54:18PM -0400, Derek Glidden wrote: > I can't wait until there's a 2.6-based RedHat that will _force_ > them to have XFS support... :) it will do no such thing. they can simply set CONFIG_XFS_FS=3Dn --=20 Ethan Benson http://www.alaska.net/~erbenson/ --Oiv9uiLrevHtW1RS 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 iEYEARECAAYFAj895h8ACgkQJKx7GixEevwPbACfUxBVUAATQsEdctq45B959EUA fZoAn0Nam3nr0VcR+CjtbQqPdTHnFotQ =3XHh -----END PGP SIGNATURE----- --Oiv9uiLrevHtW1RS-- From owner-linux-xfs@oss.sgi.com Sat Aug 16 06:24:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Aug 2003 06:24:54 -0700 (PDT) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7GDOLFl023916 for ; Sat, 16 Aug 2003 06:24:22 -0700 Received: from mailhub.ch.sauter-bc.com (mailhub [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id F058932C92; Sat, 16 Aug 2003 14:49:21 +0200 (CEST) Received: from imap01.ch.sauter-bc.com (imap01.ch.sauter-bc.com [10.1.6.25]) by mailhub.ch.sauter-bc.com (Postfix) with ESMTP id 39BFF32CB5; Sat, 16 Aug 2003 14:49:21 +0200 (CEST) Received: from webmail.ch.sauter-bc.com (localhost.localdomain [127.0.0.1]) by imap01.ch.sauter-bc.com (Postfix) with SMTP id C19F011E11; Sat, 16 Aug 2003 14:49:20 +0200 (CEST) Received: from 213.173.165.140 (proxying for 157.161.34.15) (SquirrelMail authenticated user mattesim) by imap01.ch.sauter-bc.com with HTTP; Sat, 16 Aug 2003 14:49:20 +0200 (CEST) Message-ID: <52140.213.173.165.140.1061038160.squirrel@imap01.ch.sauter-bc.com> In-Reply-To: <20030816080655.GE4735@plato.local.lan> References: <1060976194.4321.29.camel@blackbird.ssn.revario.com> <1060977257.4321.40.camel@blackbird.ssn.revario.com> <20030816080655.GE4735@plato.local.lan> Date: Sat, 16 Aug 2003 14:49:20 +0200 (CEST) Subject: Re: NULL file problems (not FAQ...) From: "Simon Matter" To: "Ethan Benson" Cc: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7GDOWFl023918 X-archive-position: 58 X-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: 542 Lines: 20 > On Fri, Aug 15, 2003 at 03:54:18PM -0400, Derek Glidden wrote: >> I can't wait until there's a 2.6-based RedHat that will _force_ >> them to have XFS support... :) > > it will do no such thing. they can simply set CONFIG_XFS_FS=n I don't think they will to that. I expect to get at least the same support as they do with ReiserFS and JFS. I think the only problem they have with XFS is that they've put so much effort into ext3 and still everybody knows XFS is better. Simon > > -- > Ethan Benson > http://www.alaska.net/~erbenson/ > From owner-linux-xfs@oss.sgi.com Sat Aug 16 07:15:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Aug 2003 07:16:09 -0700 (PDT) Received: from quail.cita.utoronto.ca (quail.cita.utoronto.ca [128.100.76.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7GEFjFl024650 for ; Sat, 16 Aug 2003 07:15:46 -0700 Received: from cita.utoronto.ca (falcon.cita.utoronto.ca [128.100.76.51]) by quail.cita.utoronto.ca (8.12.8/8.12.8) with ESMTP id h7GEFcgt027359 for ; Sat, 16 Aug 2003 10:15:38 -0400 Received: from falcon.cita.utoronto.ca (localhost [127.0.0.1]) by cita.utoronto.ca (8.12.8/8.12.8) with ESMTP id h7GEGpMT030375 for ; Sat, 16 Aug 2003 10:16:51 -0400 Received: (from rjh@localhost) by falcon.cita.utoronto.ca (8.12.8/8.12.8/Submit) id h7GEGpCd030373 for linux-xfs@oss.sgi.com; Sat, 16 Aug 2003 10:16:51 -0400 Date: Sat, 16 Aug 2003 10:16:51 -0400 From: Robin Humble To: linux-xfs@oss.sgi.com Subject: Re: NULL file problems (not FAQ...) Message-ID: <20030816141651.GC29445@falcon.cita.utoronto.ca> References: <1060976194.4321.29.camel@blackbird.ssn.revario.com> <1060977257.4321.40.camel@blackbird.ssn.revario.com> <20030816080655.GE4735@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030816080655.GE4735@plato.local.lan> User-Agent: Mutt/1.4i X-archive-position: 59 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rjh@cita.utoronto.ca Precedence: bulk X-list: linux-xfs Content-Length: 784 Lines: 20 On Sat, Aug 16, 2003 at 12:06:55AM -0800, Ethan Benson wrote: >On Fri, Aug 15, 2003 at 03:54:18PM -0400, Derek Glidden wrote: >> I can't wait until there's a 2.6-based RedHat that will _force_ >> them to have XFS support... :) >it will do no such thing. they can simply set CONFIG_XFS_FS=n I'm running RedHat9 plus the RedHat unofficial 2.6.0-test3 kernel right now with an all XFS system - no modifications, just 'rpmbuild --rebuild --target athlon ...' then 'rpm -Uvh ...' and the mkinitrd script picked up the XFS root partition etc without drama. http://people.redhat.com/arjanv/2.5/ It's currently packaged into default kernel+modules (including XFS) and 'unsupported' kernel modules. I guess it might change before RH10(?) but I don't see why it should... cheers, robin From owner-linux-xfs@oss.sgi.com Sat Aug 16 10:34:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Aug 2003 10:35:04 -0700 (PDT) Received: from fed1mtao05.cox.net (fed1mtao05.cox.net [68.6.19.126]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7GHYoFl003181 for ; Sat, 16 Aug 2003 10:34:51 -0700 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 <20030816173441.XLXD18087.fed1mtao05.cox.net@jeeves.kpf.internal> for ; Sat, 16 Aug 2003 13:34:41 -0400 Received: from [192.168.172.107] (helo=cox.net) by jeeves.kpf.internal with esmtp (Exim 4.05) id 19o4wu-0002TA-00 for linux-xfs@oss.sgi.com; Sat, 16 Aug 2003 10:34:44 -0700 Message-ID: <3F3E6B34.8080806@cox.net> Date: Sat, 16 Aug 2003 10:34:44 -0700 From: "Kevin P. Fleming" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: [ANNOUNCE] XFS 1.3.0 pre6 References: <1060990455.7302.54.camel@naboo> In-Reply-To: <1060990455.7302.54.camel@naboo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 60 X-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: 471 Lines: 15 Russell Cattelan wrote: > I'll try to compile a complete list of over the weekend > but in the mean time the new patches are on oss. > > ftp://oss.sgi.com/projects/xfs/Release-1.3/pre6/kernel_patches/ > > The cmd rpms/tars have also been update as they have several > small fixes also. > For those of us that are running XFS using the 2.6.0-??? kernels, should we pay attention to these updates, or just wait for the updates to be merged into Linus' kernel tree? From owner-linux-xfs@oss.sgi.com Sat Aug 16 13:41:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Aug 2003 13:42:10 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7GKfoFl004832 for ; Sat, 16 Aug 2003 13:41:51 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7GL27sR011758 for ; Sat, 16 Aug 2003 16:02:07 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7GKfeQK7406066; Sat, 16 Aug 2003 15:41:40 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-47.corp.sgi.com [134.15.64.47]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7GKfSRn235605580; Sat, 16 Aug 2003 15:41:29 -0500 (CDT) Subject: Re: [ANNOUNCE] XFS 1.3.0 pre6 From: Steve Lord To: "Kevin P. Fleming" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F3E6B34.8080806@cox.net> References: <1060990455.7302.54.camel@naboo> <3F3E6B34.8080806@cox.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 16 Aug 2003 15:41:24 -0500 Message-Id: <1061066496.2059.1.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 61 X-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: 746 Lines: 25 On Sat, 2003-08-16 at 12:34, Kevin P. Fleming wrote: > Russell Cattelan wrote: > > > I'll try to compile a complete list of over the weekend > > but in the mean time the new patches are on oss. > > > > ftp://oss.sgi.com/projects/xfs/Release-1.3/pre6/kernel_patches/ > > > > The cmd rpms/tars have also been update as they have several > > small fixes also. > > > > For those of us that are running XFS using the 2.6.0-??? kernels, > should we pay attention to these updates, or just wait for the updates > to be merged into Linus' kernel tree? > 2.6.0-test3 is very close, I have sent Linus some more updates since then. There are other 2.6 specific issues we are chasing, they are more performance than stability related now. Steve From owner-linux-xfs@oss.sgi.com Sat Aug 16 15:14:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Aug 2003 15:15:11 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7GMEpFl006098 for ; Sat, 16 Aug 2003 15:14:52 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19o9Jy-0002lk-Da for linux-xfs@oss.sgi.com; Sat, 16 Aug 2003 23:14:50 +0100 Date: Sat, 16 Aug 2003 23:14:50 +0100 From: Matthew Wilcox To: linux-xfs@oss.sgi.com Subject: [PATCH] Remove VOP_ACCESS Message-ID: <20030816221450.GJ19630@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 62 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: willy@debian.org Precedence: bulk X-list: linux-xfs Content-Length: 2705 Lines: 69 I was tracing through the various ->permission implementations to figure out what was going on and I ran into this rather silly VOP_ stuff. This patch makes it easier to figure out what's going on (ie that I'm looking for the vop_access implementations. - Turn v_fops into a macro that returns a (vnodeops_t *). Change _VOP_ definition accordingly. - Expand VOP_ACCESS and remove definition. Index: fs/xfs/linux/xfs_iops.c =================================================================== RCS file: /var/cvs/linux-2.6/fs/xfs/linux/xfs_iops.c,v retrieving revision 1.2 diff -u -p -r1.2 xfs_iops.c --- fs/xfs/linux/xfs_iops.c 12 Aug 2003 19:11:20 -0000 1.2 +++ fs/xfs/linux/xfs_iops.c 16 Aug 2003 22:01:55 -0000 @@ -439,7 +439,8 @@ linvfs_permission( int error; mode <<= 6; /* convert from linux to vnode access bits */ - VOP_ACCESS(vp, mode, NULL, error); + + error = v_fops(vp)->vop_access(vp->v_fbhv, mode, NULL); return -error; } #else Index: fs/xfs/linux/xfs_vnode.h =================================================================== RCS file: /var/cvs/linux-2.6/fs/xfs/linux/xfs_vnode.h,v retrieving revision 1.2 diff -u -p -r1.2 xfs_vnode.h --- fs/xfs/linux/xfs_vnode.h 12 Aug 2003 19:11:20 -0000 1.2 +++ fs/xfs/linux/xfs_vnode.h 16 Aug 2003 22:01:55 -0000 @@ -75,8 +75,8 @@ typedef struct vnode { #endif } vnode_t; -#define v_fbhv v_bh.bh_first /* first behavior */ -#define v_fops v_bh.bh_first->bd_ops /* first behavior ops */ +#define v_fbhv v_bh.bh_first /* first behavior */ +#define v_fops(vp) ((vnodeops_t *)(vp)->v_bh.bh_first->bd_ops) #define VNODE_POSITION_BASE BHV_POSITION_BASE /* chain bottom */ #define VNODE_POSITION_TOP BHV_POSITION_TOP /* chain top */ @@ -260,7 +260,7 @@ typedef struct vnodeops { /* * VOP's. */ -#define _VOP_(op, vp) (*((vnodeops_t *)(vp)->v_fops)->op) +#define _VOP_(op, vp) (v_fops(vp)->op) #define VOP_READ(vp,file,iov,segs,offset,cr,rv) \ rv = _VOP_(vop_read, vp)((vp)->v_fbhv,file,iov,segs,offset,cr) @@ -276,8 +276,6 @@ typedef struct vnodeops { rv = _VOP_(vop_getattr, vp)((vp)->v_fbhv, vap, f, cr) #define VOP_SETATTR(vp, vap, f, cr, rv) \ rv = _VOP_(vop_setattr, vp)((vp)->v_fbhv, vap, f, cr) -#define VOP_ACCESS(vp, mode, cr, rv) \ - rv = _VOP_(vop_access, vp)((vp)->v_fbhv, mode, cr) #define VOP_LOOKUP(vp,d,vpp,f,rdir,cr,rv) \ rv = _VOP_(vop_lookup, vp)((vp)->v_fbhv,d,vpp,f,rdir,cr) #define VOP_CREATE(dvp,d,vap,vpp,cr,rv) \ -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From owner-linux-xfs@oss.sgi.com Sat Aug 16 17:05:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Aug 2003 17:05:33 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7H054Fl007118 for ; Sat, 16 Aug 2003 17:05:05 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19o9kq-0002z4-OK for linux-xfs@oss.sgi.com; Sat, 16 Aug 2003 23:42:36 +0100 Date: Sat, 16 Aug 2003 23:42:36 +0100 From: Matthew Wilcox To: linux-xfs@oss.sgi.com Subject: Better patch to remove VOP_ACCESS and vop_access Message-ID: <20030816224236.GK19630@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 63 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: willy@debian.org Precedence: bulk X-list: linux-xfs Content-Length: 3901 Lines: 120 Thinking about it, this is probably a better patch. There's only one implementation of vop_access, so inline it into linvfs_permission. Um, unless someone has another vop_access implementation that might crop up? - Remove VOP_ACCESS - Remove vop_access - Inline xfs_access into linvfs_permission Index: fs/xfs/xfs_vnodeops.c =================================================================== RCS file: /var/cvs/linux-2.6/fs/xfs/xfs_vnodeops.c,v retrieving revision 1.2 diff -u -p -r1.2 xfs_vnodeops.c --- fs/xfs/xfs_vnodeops.c 12 Aug 2003 19:11:19 -0000 1.2 +++ fs/xfs/xfs_vnodeops.c 16 Aug 2003 22:34:57 -0000 @@ -928,30 +928,6 @@ xfs_setattr( /* - * xfs_access - * Null conversion from vnode mode bits to inode mode bits, as in efs. - */ -STATIC int -xfs_access( - bhv_desc_t *bdp, - int mode, - cred_t *credp) -{ - xfs_inode_t *ip; - int error; - - vn_trace_entry(BHV_TO_VNODE(bdp), __FUNCTION__, - (inst_t *)__return_address); - - ip = XFS_BHVTOI(bdp); - xfs_ilock(ip, XFS_ILOCK_SHARED); - error = xfs_iaccess(ip, mode, credp); - xfs_iunlock(ip, XFS_ILOCK_SHARED); - return error; -} - - -/* * xfs_readlink * */ @@ -4731,7 +4707,6 @@ vnodeops_t xfs_vnodeops = { .vop_ioctl = xfs_ioctl, .vop_getattr = xfs_getattr, .vop_setattr = xfs_setattr, - .vop_access = xfs_access, .vop_lookup = xfs_lookup, .vop_create = xfs_create, .vop_remove = xfs_remove, Index: fs/xfs/linux/xfs_iops.c =================================================================== RCS file: /var/cvs/linux-2.6/fs/xfs/linux/xfs_iops.c,v retrieving revision 1.2 diff -u -p -r1.2 xfs_iops.c --- fs/xfs/linux/xfs_iops.c 12 Aug 2003 19:11:20 -0000 1.2 +++ fs/xfs/linux/xfs_iops.c 16 Aug 2003 22:34:58 -0000 @@ -435,11 +435,18 @@ linvfs_permission( int mode, struct nameidata *nd) { + xfs_inode_t *ip; vnode_t *vp = LINVFS_GET_VP(inode); int error; + vn_trace_entry(BHV_TO_VNODE(bdp), __FUNCTION__, + (inst_t *)__return_address); + mode <<= 6; /* convert from linux to vnode access bits */ - VOP_ACCESS(vp, mode, NULL, error); + ip = XFS_BHVTOI(bdp); + xfs_ilock(ip, XFS_ILOCK_SHARED); + error = xfs_iaccess(ip, mode, NULL); + xfs_iunlock(ip, XFS_ILOCK_SHARED); return -error; } #else Index: fs/xfs/linux/xfs_vnode.h =================================================================== RCS file: /var/cvs/linux-2.6/fs/xfs/linux/xfs_vnode.h,v retrieving revision 1.2 diff -u -p -r1.2 xfs_vnode.h --- fs/xfs/linux/xfs_vnode.h 12 Aug 2003 19:11:20 -0000 1.2 +++ fs/xfs/linux/xfs_vnode.h 16 Aug 2003 22:34:58 -0000 @@ -173,7 +173,6 @@ typedef int (*vop_getattr_t)(bhv_desc_t struct cred *); typedef int (*vop_setattr_t)(bhv_desc_t *, struct vattr *, int, struct cred *); -typedef int (*vop_access_t)(bhv_desc_t *, int, struct cred *); typedef int (*vop_lookup_t)(bhv_desc_t *, vname_t *, vnode_t **, int, vnode_t *, struct cred *); typedef int (*vop_create_t)(bhv_desc_t *, vname_t *, struct vattr *, @@ -226,7 +225,6 @@ typedef struct vnodeops { vop_ioctl_t vop_ioctl; vop_getattr_t vop_getattr; vop_setattr_t vop_setattr; - vop_access_t vop_access; vop_lookup_t vop_lookup; vop_create_t vop_create; vop_remove_t vop_remove; @@ -276,8 +274,6 @@ typedef struct vnodeops { rv = _VOP_(vop_getattr, vp)((vp)->v_fbhv, vap, f, cr) #define VOP_SETATTR(vp, vap, f, cr, rv) \ rv = _VOP_(vop_setattr, vp)((vp)->v_fbhv, vap, f, cr) -#define VOP_ACCESS(vp, mode, cr, rv) \ - rv = _VOP_(vop_access, vp)((vp)->v_fbhv, mode, cr) #define VOP_LOOKUP(vp,d,vpp,f,rdir,cr,rv) \ rv = _VOP_(vop_lookup, vp)((vp)->v_fbhv,d,vpp,f,rdir,cr) #define VOP_CREATE(dvp,d,vap,vpp,cr,rv) \ -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From owner-linux-xfs@oss.sgi.com Sat Aug 16 21:19:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Aug 2003 21:19:28 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7H4J9Fl011768 for ; Sat, 16 Aug 2003 21:19:11 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19oF0W-0000XN-7M for linux-xfs@oss.sgi.com; Sun, 17 Aug 2003 05:19:08 +0100 Date: Sun, 17 Aug 2003 05:19:08 +0100 From: Matthew Wilcox To: linux-xfs@oss.sgi.com Subject: vnodeops Message-ID: <20030817041908.GM19630@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 64 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: willy@debian.org Precedence: bulk X-list: linux-xfs Content-Length: 456 Lines: 10 So is there any reason to keep the vnodeops layer around? There's only one implementation of it (xfs_vnodeops) so it seems kind of pointless. Removing it would probably shrink xfs quite a bit, both source and binary. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From owner-linux-xfs@oss.sgi.com Sat Aug 16 21:37:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Aug 2003 21:37:28 -0700 (PDT) Received: from hob.acsalaska.net (hob.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7H4b8Fl012250 for ; Sat, 16 Aug 2003 21:37:10 -0700 Received: from erbenson.alaska.net (74-pm2.nwc.alaska.net [209.112.138.74]) by hob.acsalaska.net (8.12.9/8.12.9) with ESMTP id h7H4b6dK008518 for ; Sat, 16 Aug 2003 20:37:07 -0800 (AKDT) (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 66E953A04 for ; Sat, 16 Aug 2003 20:37:04 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 246C040FF44; Sat, 16 Aug 2003 20:37:05 -0800 (AKDT) Date: Sat, 16 Aug 2003 20:37:05 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: vnodeops Message-ID: <20030817043704.GB10246@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20030817041908.GM19630@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <20030817041908.GM19630@parcelfarce.linux.theplanet.co.uk> 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.35 X-archive-position: 65 X-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: 863 Lines: 32 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 17, 2003 at 05:19:08AM +0100, Matthew Wilcox wrote: >=20 > So is there any reason to keep the vnodeops layer around? There's only > one implementation of it (xfs_vnodeops) so it seems kind of pointless. > Removing it would probably shrink xfs quite a bit, both source and binary. i believe its used for CXFS. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --ZGiS0Q5IWpPtfppv 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 iEYEARECAAYFAj8/BnAACgkQJKx7GixEevzMmQCdEJLzO3b7TwixAO4Ika86eRDF /M8AnihRppiFH8Basruy9z7zlSOW+HQd =lVz7 -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From owner-linux-xfs@oss.sgi.com Sat Aug 16 22:02:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Aug 2003 22:02:40 -0700 (PDT) Received: from hob.acsalaska.net (hob.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7H52IFl012795 for ; Sat, 16 Aug 2003 22:02:19 -0700 Received: from erbenson.alaska.net (74-pm2.nwc.alaska.net [209.112.138.74]) by hob.acsalaska.net (8.12.9/8.12.9) with ESMTP id h7H525dK018273 for ; Sat, 16 Aug 2003 21:02:05 -0800 (AKDT) (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 55B363A04 for ; Sat, 16 Aug 2003 21:02:02 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 6B34D40FF44; Sat, 16 Aug 2003 21:02:03 -0800 (AKDT) Date: Sat, 16 Aug 2003 21:02:03 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: [PATCH] Implement immutable/append-only flags in XFS #5 Message-ID: <20030817050203.GA11982@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="azLHFNyN32YCQGCU" 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.35 X-archive-position: 66 X-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: 24347 Lines: 630 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, [fifth revision: only changes is to update to current 2.4.21 CVS] Over time there has been many requests for ext2 file flags such as immutable, append-only, sync, noatime be implemented in XFS. So, here it is. I have implemented all of the above flags in 2.4.21 CVS. The patch is relatively small and non-invasive, and from my testing appears to cause no backwards compatibility issues (older kernels ignore, and leave alone the new flags). Also xfs_repair and xfs_check do not seem to have any problems with the new flags either. If any XFS users would like to try this patch and report on it please do. My testing indicates its stable and will cause no problems except as discussed below with xfsdump. However during my testing I did discover 3 issues: 1: The Linux VFS contains a bug which allows timestamp modification of immutable/append-only files. I have fixed this issue, and will send the patch to the linux-kernel mailing list shortly. I have included that patch in this mail for completeness. 2: xfsrestore breaks when immutable or append-only files are included in the dump. The problem is xfsrestore restores the file inode flags too soon, and then loses the access it needs to restore extended attributes, uid, gid, and permissions. I am not familiar enough with xfsrestore to really propose the fix, however i believe just changing it to restore at the very least immutable/append-only flags very last after all other restoration is complete should suffice to solve this problem. 3: I just found an undocumented behavior with regards to ext2's file flags; when set on a directory any new file/dir created will inherit the flags of the parent directory. I am not entirely convinced this is a good idea, at least for *all* flags. In ext2 this behavior has been half broken for as near as i can tell, forever up to 2.4.20 (2.4.21 fixes it), the brokenness is that the vfs is not immediately informed of any of the flags except sync, thus they don't actually go into affect on new files until the inode is revalidated (which could take quite some time). In addition ext2 only refrains from doing this on symlinks, not device special files; this means if you create a device node in a append-only directory the only way you will ever be able to remove it is with debugfs. (ioctl() calls on a device file go to the driver handling the node, not to the filesystem holding the node, thus chattr won't help you). My question on #3 is whether we want this behavior in XFS? my current patch implements it only for the sync bit, and only to regular files and directories. My opinion is that the only flag this really makes sense for is sync, since setting the sync flag on a directory does not actually do anything for you (it only affects files), so making all new files created under a sync directory is seemingly sensible (and probably what the user would expect, more or less). this might make sense for noatime too, but I am less convinced of this. I am definitely not convinced its a sensible idea for append-only since it ends up allowing non-privileged users to create append-only files, which is not normally permitted. Also automatically setting the append-only flag on a newly created file won't necessarily make it append-only immediately, since a caller doing open("append-only-dir/file" O_RDWR|O_CREAT) will retain full read/write access so long as the file descriptor is kept open (the same is true if you chmod() a file, open descriptors retain access even if they could not get it on a new open()). So for now I submit the patch without the ext2 inheritance behavior (except for sync to IFREG and IFDIR), if you believe we should implement the ext2 behavior either partially, or fully I should be able to do that. I have also implemented the EXT2_IOC_SETFLAGS/EXT2_IOC_GETFLAGS ioctl()s so chattr/lsattr will work on xfs, this part of the patch is optional, if excluded then either lsattr/chattr would need to be modified to use XFS_IOC_FSSETXATTR and XFS_IOC_FSGETXATTR ioctls. I have a (somewhat hideous) test program to check as many things as i could think of to ensure immutable/append-only are properly enforced, the only thing lacking in it is tests of all the XFS ioctls, perhaps someone familiar with xfs ioctls could add these, currently the libhandle open/write tests are done. You can find this test program at http://penguinppc.org/~eb/t_immutable.c Important: this test program creates a test area with full world read/write permissions to ensure regular file permissions are not tainting the test, therefore it is NOT SAFE to run on systems with untrusted users. the usage is t_immutable -c /some/dir which will create a test area as /some/dir and run tests in it. t_immutable -C will create the test area without running any tests, and t_immutable -r will remove a test area. t_immutable /some/dir will run the tests on a previously created test area. Note if you run t_immutable on an ext2 filesystem in 2.4.21 kernels you will need to use debugfs to get rid of the device node it creates (same on kernels prior to 2.4.21 if you leave the test area around long enough). see above for why. Also note that there is currently a bug in the XFS handle code, if you run my test program, then use it to delete the test-area you will get minor filesystem corruption on umount. feedback is welcome. diffstat output follows: linux/xfs_ext2_ioctl.h | 45 ++++++++++++++++++++++ linux/xfs_ioctl.c | 100 +++++++++++++++++++++++++++++++++++++++++++++++++ linux/xfs_iops.c | 6 ++ linux/xfs_super.c | 16 +++++++ linux/xfs_vnode.c | 17 ++++++++ xfs_acl.c | 2 xfs_cap.c | 2 xfs_dinode.h | 24 ++++++++--- xfs_fs.h | 7 ++- xfs_inode.c | 7 ++- xfs_itable.c | 8 +++ xfs_vnodeops.c | 16 +++++++ 12 files changed, 241 insertions(+), 9 deletions(-) -- Ethan Benson http://www.alaska.net/~erbenson/ --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfs-xflags.diff" diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_ext2_ioctl.h linux-2.4-xfs/linux/fs/xfs/linux/xfs_ext2_ioctl.h --- linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_ext2_ioctl.h Wed Dec 31 14:00:00 1969 +++ linux-2.4-xfs/linux/fs/xfs/linux/xfs_ext2_ioctl.h Mon Jul 21 15:57:33 2003 @@ -0,0 +1,45 @@ +/* + * Copyright (c) 2003 Silicon Graphics, Inc. All Rights Reserved. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of version 2 of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + * + * Further, this software is distributed without any warranty that it is + * free of the rightful claim of any third person regarding infringement + * or the like. Any license provided herein, whether implied or + * otherwise, applies only to this software file. Patent licenses, if + * any, provided herein do not apply to combinations of this program with + * other software, or any other product whatsoever. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write the Free Software Foundation, Inc., 59 + * Temple Place - Suite 330, Boston MA 02111-1307, USA. + * + * Contact information: Silicon Graphics, Inc., 1600 Amphitheatre Pkwy, + * Mountain View, CA 94043, or: + * + * http://www.sgi.com + * + * For further information regarding this notice, see: + * + * http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/ + */ +#ifndef __XFS_EXT2_IOCTL_H__ +#define __XFS_EXT2_IOCTL_H__ + +/* ext2 ioctls (EXT2_IOC_GETFLAGS and EXT2_IOC_SETFLAGS) to support + * chattr/lsattr */ +#define XFS_IOC_EXT2_GETFLAGS _IOR('f', 1, long) +#define XFS_IOC_EXT2_SETFLAGS _IOW('f', 2, long) + +#define EXT2_FLAG_SYNC 0x00000008 /* Synchronous updates */ +#define EXT2_FLAG_IMMUTABLE 0x00000010 /* Immutable file */ +#define EXT2_FLAG_APPEND 0x00000020 /* writes to file may only append */ +#define EXT2_FLAG_NOATIME 0x00000080 /* do not update atime */ + +#endif /* __XFS_EXT2_IOCTL_H__ */ diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_ioctl.c linux-2.4-xfs/linux/fs/xfs/linux/xfs_ioctl.c --- linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_ioctl.c Mon Jul 21 15:12:50 2003 +++ linux-2.4-xfs/linux/fs/xfs/linux/xfs_ioctl.c Mon Jul 21 15:19:13 2003 @@ -66,6 +66,7 @@ #include "xfs_utils.h" #include "xfs_dfrag.h" #include "xfs_fsops.h" +#include "xfs_ext2_ioctl.h" #include #include @@ -327,6 +328,13 @@ if (permflag & O_TRUNC) permflag |= 2; + if ((!(permflag & O_APPEND) || (permflag & O_TRUNC)) && + (permflag & FMODE_WRITE) && IS_APPEND(inode)) + return -XFS_ERROR(EPERM); + + if ((permflag & FMODE_WRITE) && IS_IMMUTABLE(inode)) + return -XFS_ERROR(EACCES); + /* Can't write directories. */ if ( S_ISDIR(inode->i_mode) && (permflag & FMODE_WRITE)) { iput(inode); @@ -447,6 +455,9 @@ if (error) return -error; + if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) + return -XFS_ERROR(EPERM); + if (copy_from_user(&fsd, dmhreq.data, sizeof(fsd))) { VN_RELE(vp); return -XFS_ERROR(EFAULT); @@ -532,11 +543,21 @@ NULL, ops[i].am_error); break; case ATTR_OP_SET: + if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) { + kfree(ops); + VN_RELE(vp); + return -XFS_ERROR(EPERM); + } VOP_ATTR_SET(vp,ops[i].am_attrname, ops[i].am_attrvalue, ops[i].am_length, ops[i].am_flags, NULL, ops[i].am_error); break; case ATTR_OP_REMOVE: + if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) { + kfree(ops); + VN_RELE(vp); + return -XFS_ERROR(EPERM); + } VOP_ATTR_REMOVE(vp, ops[i].am_attrname, ops[i].am_flags, NULL, ops[i].am_error); break; @@ -842,6 +863,75 @@ error = xfs_errortag_clearall(mp); return -error; + case XFS_IOC_EXT2_GETFLAGS: { + unsigned int flags = 0; + + if (vp->v_inode.i_flags & S_IMMUTABLE) + flags |= EXT2_FLAG_IMMUTABLE; /* EXT2_IMMUTABLE_FL */ + if (vp->v_inode.i_flags & S_APPEND) + flags |= EXT2_FLAG_APPEND; /* EXT2_APPEND_FL */ + if (vp->v_inode.i_flags & S_SYNC) + flags |= EXT2_FLAG_SYNC; /* EXT2_SYNC_FL */ + if (vp->v_inode.i_flags & S_NOATIME) + flags |= EXT2_FLAG_NOATIME; /* EXT2_NOATIME_FL */ + + if (copy_to_user((unsigned int *)arg, &flags, sizeof(flags))) + return -XFS_ERROR(EFAULT); + return 0; + } + + case XFS_IOC_EXT2_SETFLAGS: { + vattr_t va; + unsigned int flags; + int attr_flags = 0; + + if (copy_from_user(&flags, (unsigned int *)arg, sizeof(flags))) + return -XFS_ERROR(EFAULT); + + /* we need to do getattr to preserve XFS xflags ext2 + * has no knowledge of */ + + va.va_mask = XFS_AT_XFLAGS; + VOP_GETATTR(vp, &va, 0, NULL, error); + if (error) + return -error; + + if (flags & (EXT2_FLAG_IMMUTABLE|EXT2_FLAG_APPEND) || + va.va_xflags & (XFS_XFLAG_IMMUTABLE|XFS_XFLAG_APPEND)) + if (!capable(CAP_LINUX_IMMUTABLE)) + return -XFS_ERROR(EPERM); + + /* don't silently ignore unsupported ext2 flags */ + if (flags & ~(EXT2_FLAG_IMMUTABLE|EXT2_FLAG_APPEND| + EXT2_FLAG_SYNC|EXT2_FLAG_NOATIME)) + return -XFS_ERROR(EOPNOTSUPP); + + if (flags & EXT2_FLAG_IMMUTABLE) /* EXT2_IMMUTABLE_FL */ + va.va_xflags |= XFS_XFLAG_IMMUTABLE; + else + va.va_xflags &= ~XFS_XFLAG_IMMUTABLE; + if (flags & EXT2_FLAG_APPEND) /* EXT2_APPEND_FL */ + va.va_xflags |= XFS_XFLAG_APPEND; + else + va.va_xflags &= ~XFS_XFLAG_APPEND; + if (flags & EXT2_FLAG_SYNC) /* EXT2_SYNC_FL */ + va.va_xflags |= XFS_XFLAG_SYNC; + else + va.va_xflags &= ~XFS_XFLAG_SYNC; + if (flags & EXT2_FLAG_NOATIME) /* EXT2_NOATIME_FL */ + va.va_xflags |= XFS_XFLAG_NOATIME; + else + va.va_xflags &= ~XFS_XFLAG_NOATIME; + + if (filp->f_flags & (O_NDELAY|O_NONBLOCK)) + attr_flags |= ATTR_NONBLOCK; + + VOP_SETATTR(vp, &va, attr_flags, NULL, error); + if (!error) + vn_revalidate(vp); /* push immutable/append flags into vfs inode */ + return -error; + } + default: return -ENOTTY; } @@ -859,6 +949,9 @@ int attr_flags = 0; int error; + if (vp->v_inode.i_flags & (S_IMMUTABLE|S_APPEND)) + return -XFS_ERROR(EPERM); + if (filp->f_flags & O_RDONLY) return -XFS_ERROR(EBADF); @@ -1012,6 +1105,11 @@ if (copy_from_user(&fa, (struct fsxattr *)arg, sizeof(fa))) return -XFS_ERROR(EFAULT); + if (fa.fsx_xflags & (XFS_XFLAG_IMMUTABLE|XFS_XFLAG_APPEND) || + va.va_xflags & (XFS_XFLAG_IMMUTABLE|XFS_XFLAG_APPEND)) + if (!capable(CAP_LINUX_IMMUTABLE)) + return -XFS_ERROR(EPERM); + va.va_mask = XFS_AT_XFLAGS | XFS_AT_EXTSIZE; va.va_xflags = fa.fsx_xflags; va.va_extsize = fa.fsx_extsize; @@ -1020,6 +1118,8 @@ attr_flags |= ATTR_NONBLOCK; VOP_SETATTR(vp, &va, attr_flags, NULL, error); + if (!error) + vn_revalidate(vp); /* push immutable/append flags into vfs inode */ return -error; } diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_iops.c linux-2.4-xfs/linux/fs/xfs/linux/xfs_iops.c --- linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_iops.c Sat Aug 16 19:01:10 2003 +++ linux-2.4-xfs/linux/fs/xfs/linux/xfs_iops.c Sat Aug 16 20:21:46 2003 @@ -633,6 +633,9 @@ return error; } + if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) + return -EPERM; + /* Convert Linux syscall to XFS internal ATTR flags */ if (flags & XATTR_CREATE) xflags |= ATTR_CREATE; @@ -782,6 +785,9 @@ error = xfs_cap_vremove(vp); return error; } + + if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) + return -EPERM; if (strncmp(name, xfs_namespaces[ROOT_NAMES].name, xfs_namespaces[ROOT_NAMES].namelen) == 0) { diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_super.c linux-2.4-xfs/linux/fs/xfs/linux/xfs_super.c --- linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_super.c Sat Aug 16 19:01:10 2003 +++ linux-2.4-xfs/linux/fs/xfs/linux/xfs_super.c Sat Aug 16 20:21:49 2003 @@ -181,6 +181,22 @@ inode->i_atime = ip->i_d.di_atime.t_sec; inode->i_mtime = ip->i_d.di_mtime.t_sec; inode->i_ctime = ip->i_d.di_ctime.t_sec; + if (ip->i_d.di_flags & XFS_DIFLAG_IMMUTABLE) + inode->i_flags |= S_IMMUTABLE; + else + inode->i_flags &= ~S_IMMUTABLE; + if (ip->i_d.di_flags & XFS_DIFLAG_APPEND) + inode->i_flags |= S_APPEND; + else + inode->i_flags &= ~S_APPEND; + if (ip->i_d.di_flags & XFS_DIFLAG_SYNC) + inode->i_flags |= S_SYNC; + else + inode->i_flags &= ~S_SYNC; + if (ip->i_d.di_flags & XFS_DIFLAG_NOATIME) + inode->i_flags |= S_NOATIME; + else + inode->i_flags &= ~S_NOATIME; vp->v_flag &= ~VMODIFIED; } diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_vnode.c linux-2.4-xfs/linux/fs/xfs/linux/xfs_vnode.c --- linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_vnode.c Mon Jul 21 15:13:07 2003 +++ linux-2.4-xfs/linux/fs/xfs/linux/xfs_vnode.c Mon Jul 21 15:19:13 2003 @@ -224,6 +224,23 @@ inode->i_mtime = va.va_mtime.tv_sec; inode->i_ctime = va.va_ctime.tv_sec; inode->i_atime = va.va_atime.tv_sec; + if (va.va_xflags & XFS_XFLAG_IMMUTABLE) + inode->i_flags |= S_IMMUTABLE; + else + inode->i_flags &= ~S_IMMUTABLE; + if (va.va_xflags & XFS_XFLAG_APPEND) + inode->i_flags |= S_APPEND; + else + inode->i_flags &= ~S_APPEND; + if (va.va_xflags & XFS_XFLAG_SYNC) + inode->i_flags |= S_SYNC; + else + inode->i_flags &= ~S_SYNC; + if (va.va_xflags & XFS_XFLAG_NOATIME) + inode->i_flags |= S_NOATIME; + else + inode->i_flags &= ~S_NOATIME; + VUNMODIFY(vp); } return -error; diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_acl.c linux-2.4-xfs/linux/fs/xfs/xfs_acl.c --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_acl.c Mon Jul 21 15:06:54 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_acl.c Mon Jul 21 15:19:13 2003 @@ -388,6 +388,8 @@ vattr_t va; int error; + if (vp->v_inode.i_flags & (S_IMMUTABLE|S_APPEND)) + return EPERM; if (kind == _ACL_TYPE_DEFAULT && vp->v_type != VDIR) return ENOTDIR; if (vp->v_vfsp->vfs_flag & VFS_RDONLY) diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_cap.c linux-2.4-xfs/linux/fs/xfs/xfs_cap.c --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_cap.c Mon Jul 21 15:08:15 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_cap.c Mon Jul 21 15:19:13 2003 @@ -192,6 +192,8 @@ if (vp->v_vfsp->vfs_flag & VFS_RDONLY) return EROFS; + if (vp->v_inode.i_flags & (S_IMMUTABLE|S_APPEND)) + return EPERM; if ((error = _MAC_VACCESS(vp, NULL, VWRITE))) return error; va.va_mask = XFS_AT_UID; diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_dinode.h linux-2.4-xfs/linux/fs/xfs/xfs_dinode.h --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_dinode.h Sat Aug 16 19:00:58 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_dinode.h Sat Aug 16 20:21:09 2003 @@ -471,13 +471,23 @@ * There should be a one-to-one correspondence between these flags and the * XFS_XFLAG_s. */ -#define XFS_DIFLAG_REALTIME_BIT 0 /* file's blocks come from rt area */ -#define XFS_DIFLAG_PREALLOC_BIT 1 /* file space has been preallocated */ -#define XFS_DIFLAG_NEWRTBM_BIT 2 /* for rtbitmap inode, new format */ -#define XFS_DIFLAG_REALTIME (1 << XFS_DIFLAG_REALTIME_BIT) -#define XFS_DIFLAG_PREALLOC (1 << XFS_DIFLAG_PREALLOC_BIT) -#define XFS_DIFLAG_NEWRTBM (1 << XFS_DIFLAG_NEWRTBM_BIT) +#define XFS_DIFLAG_REALTIME_BIT 0 /* file's blocks come from rt area */ +#define XFS_DIFLAG_PREALLOC_BIT 1 /* file space has been preallocated */ +#define XFS_DIFLAG_NEWRTBM_BIT 2 /* for rtbitmap inode, new format */ +#define XFS_DIFLAG_IMMUTABLE_BIT 3 /* inode is immutable */ +#define XFS_DIFLAG_APPEND_BIT 4 /* inode is append-only */ +#define XFS_DIFLAG_SYNC_BIT 5 /* inode is written synchronously */ +#define XFS_DIFLAG_NOATIME_BIT 6 /* do not update atime */ +#define XFS_DIFLAG_REALTIME (1 << XFS_DIFLAG_REALTIME_BIT) +#define XFS_DIFLAG_PREALLOC (1 << XFS_DIFLAG_PREALLOC_BIT) +#define XFS_DIFLAG_NEWRTBM (1 << XFS_DIFLAG_NEWRTBM_BIT) +#define XFS_DIFLAG_IMMUTABLE (1 << XFS_DIFLAG_IMMUTABLE_BIT) +#define XFS_DIFLAG_APPEND (1 << XFS_DIFLAG_APPEND_BIT) +#define XFS_DIFLAG_SYNC (1 << XFS_DIFLAG_SYNC_BIT) +#define XFS_DIFLAG_NOATIME (1 << XFS_DIFLAG_NOATIME_BIT) #define XFS_DIFLAG_ALL \ - (XFS_DIFLAG_REALTIME|XFS_DIFLAG_PREALLOC|XFS_DIFLAG_NEWRTBM) + (XFS_DIFLAG_REALTIME|XFS_DIFLAG_PREALLOC|XFS_DIFLAG_NEWRTBM| \ + XFS_DIFLAG_IMMUTABLE|XFS_DIFLAG_APPEND|XFS_DIFLAG_SYNC| \ + XFS_DIFLAG_NOATIME) #endif /* __XFS_DINODE_H__ */ diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_fs.h linux-2.4-xfs/linux/fs/xfs/xfs_fs.h --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_fs.h Mon Jul 21 15:09:27 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_fs.h Mon Jul 21 15:19:13 2003 @@ -71,9 +71,14 @@ */ #define XFS_XFLAG_REALTIME 0x00000001 #define XFS_XFLAG_PREALLOC 0x00000002 +#define XFS_XFLAG_IMMUTABLE 0x00000008 +#define XFS_XFLAG_APPEND 0x00000010 +#define XFS_XFLAG_SYNC 0x00000020 +#define XFS_XFLAG_NOATIME 0x00000040 #define XFS_XFLAG_HASATTR 0x80000000 /* no DIFLAG for this */ #define XFS_XFLAG_ALL \ - ( XFS_XFLAG_REALTIME|XFS_XFLAG_PREALLOC|XFS_XFLAG_HASATTR ) + ( XFS_XFLAG_REALTIME|XFS_XFLAG_PREALLOC|XFS_XFLAG_IMMUTABLE| \ + XFS_XFLAG_APPEND|XFS_XFLAG_SYNC|XFS_XFLAG_NOATIME|XFS_XFLAG_HASATTR ) /* diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_inode.c linux-2.4-xfs/linux/fs/xfs/xfs_inode.c --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_inode.c Sat Aug 16 19:00:58 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_inode.c Sat Aug 16 20:21:21 2003 @@ -1210,6 +1210,8 @@ break; case IFREG: case IFDIR: + if (pip->i_d.di_flags & XFS_DIFLAG_SYNC) + ip->i_d.di_flags |= XFS_DIFLAG_SYNC; case IFLNK: ip->i_d.di_format = XFS_DINODE_FMT_EXTENTS; ip->i_df.if_flags = XFS_IFEXTENTS; @@ -3500,6 +3502,9 @@ if (IS_RDONLY(inode) && (S_ISREG(imode) || S_ISDIR(imode) || S_ISLNK(imode))) return XFS_ERROR(EROFS); + + if (IS_IMMUTABLE(inode)) + return XFS_ERROR(EACCES); } /* @@ -3623,7 +3628,7 @@ * Don't update access timestamps on reads if mounted "noatime" * Throw it away if anyone asks us. */ - if (ip->i_mount->m_flags & XFS_MOUNT_NOATIME && + if ((ip->i_mount->m_flags & XFS_MOUNT_NOATIME || IS_NOATIME(inode)) && ((flags & (XFS_ICHGTIME_ACC|XFS_ICHGTIME_MOD|XFS_ICHGTIME_CHG)) == XFS_ICHGTIME_ACC)) return; diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_itable.c linux-2.4-xfs/linux/fs/xfs/xfs_itable.c --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_itable.c Mon Jul 21 15:10:06 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_itable.c Mon Jul 21 15:19:13 2003 @@ -163,6 +163,14 @@ XFS_XFLAG_REALTIME : 0) | ((di_flags & XFS_DIFLAG_PREALLOC) ? XFS_XFLAG_PREALLOC : 0) | + ((di_flags & XFS_DIFLAG_IMMUTABLE) ? + XFS_XFLAG_IMMUTABLE : 0) | + ((di_flags & XFS_DIFLAG_APPEND) ? + XFS_XFLAG_APPEND : 0) | + ((di_flags & XFS_DIFLAG_SYNC) ? + XFS_XFLAG_SYNC : 0) | + ((di_flags & XFS_DIFLAG_NOATIME) ? + XFS_XFLAG_NOATIME : 0) | (XFS_CFORK_Q_ARCH(dic, arch) ? XFS_XFLAG_HASATTR : 0); diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_vnodeops.c linux-2.4-xfs/linux/fs/xfs/xfs_vnodeops.c --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_vnodeops.c Sat Aug 16 19:00:58 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_vnodeops.c Sat Aug 16 20:21:35 2003 @@ -266,6 +266,14 @@ XFS_XFLAG_REALTIME : 0) | ((ip->i_d.di_flags & XFS_DIFLAG_PREALLOC) ? XFS_XFLAG_PREALLOC : 0) | + ((ip->i_d.di_flags & XFS_DIFLAG_IMMUTABLE) ? + XFS_XFLAG_IMMUTABLE : 0) | + ((ip->i_d.di_flags & XFS_DIFLAG_APPEND) ? + XFS_XFLAG_APPEND : 0) | + ((ip->i_d.di_flags & XFS_DIFLAG_SYNC) ? + XFS_XFLAG_SYNC : 0) | + ((ip->i_d.di_flags & XFS_DIFLAG_NOATIME) ? + XFS_XFLAG_NOATIME : 0) | (XFS_IFORK_Q(ip) ? XFS_XFLAG_HASATTR : 0); vap->va_extsize = ip->i_d.di_extsize << mp->m_sb.sb_blocklog; @@ -833,6 +841,14 @@ ip->i_d.di_flags |= XFS_DIFLAG_REALTIME; ip->i_iocore.io_flags |= XFS_IOCORE_RT; } + if (vap->va_xflags & XFS_XFLAG_IMMUTABLE) + ip->i_d.di_flags |= XFS_DIFLAG_IMMUTABLE; + if (vap->va_xflags & XFS_XFLAG_APPEND) + ip->i_d.di_flags |= XFS_DIFLAG_APPEND; + if (vap->va_xflags & XFS_XFLAG_SYNC) + ip->i_d.di_flags |= XFS_DIFLAG_SYNC; + if (vap->va_xflags & XFS_XFLAG_NOATIME) + ip->i_d.di_flags |= XFS_DIFLAG_NOATIME; /* can't set PREALLOC this way, just ignore it */ } xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="open.c.diff" --- linux.orig/fs/open.c Sun Jun 1 20:39:38 2003 +++ linux/fs/open.c Sun Jun 1 20:54:14 2003 @@ -272,6 +272,9 @@ /* Don't worry, the checks are done in inode_change_ok() */ newattrs.ia_valid = ATTR_CTIME | ATTR_MTIME | ATTR_ATIME; if (times) { + error = -EPERM; + if (IS_APPEND(inode) || IS_IMMUTABLE(inode)) + goto dput_and_out; error = get_user(newattrs.ia_atime, ×->actime); if (!error) error = get_user(newattrs.ia_mtime, ×->modtime); @@ -280,6 +283,9 @@ newattrs.ia_valid |= ATTR_ATIME_SET | ATTR_MTIME_SET; } else { + error = -EACCES; + if (IS_IMMUTABLE(inode)) + goto dput_and_out; if (current->fsuid != inode->i_uid && (error = permission(inode,MAY_WRITE)) != 0) goto dput_and_out; @@ -318,6 +324,9 @@ newattrs.ia_valid = ATTR_CTIME | ATTR_MTIME | ATTR_ATIME; if (utimes) { struct timeval times[2]; + error = -EPERM; + if (IS_APPEND(inode) || IS_IMMUTABLE(inode)) + goto dput_and_out; error = -EFAULT; if (copy_from_user(×, utimes, sizeof(times))) goto dput_and_out; @@ -325,6 +334,10 @@ newattrs.ia_mtime = times[1].tv_sec; newattrs.ia_valid |= ATTR_ATIME_SET | ATTR_MTIME_SET; } else { + error = -EACCES; + if (IS_IMMUTABLE(inode)) + goto dput_and_out; + if (current->fsuid != inode->i_uid && (error = permission(inode,MAY_WRITE)) != 0) goto dput_and_out; --azLHFNyN32YCQGCU-- From owner-linux-xfs@oss.sgi.com Sun Aug 17 06:15:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Aug 2003 06:15:48 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HDFWFl005029 for ; Sun, 17 Aug 2003 06:15:33 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7HDFRq0002135 for ; Sun, 17 Aug 2003 06:15:27 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7HDD5QK7451878; Sun, 17 Aug 2003 08:13:05 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-48.corp.sgi.com [134.15.64.48]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7HDD4Rn230114540; Sun, 17 Aug 2003 08:13:04 -0500 (CDT) Subject: Re: vnodeops From: Steve Lord To: Matthew Wilcox , Ethan Benson Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030817043704.GB10246@plato.local.lan> References: <20030817041908.GM19630@parcelfarce.linux.theplanet.co.uk> <20030817043704.GB10246@plato.local.lan> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 17 Aug 2003 08:12:59 -0500 Message-Id: <1061125981.1982.5.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 67 X-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: 529 Lines: 16 On Sat, 2003-08-16 at 23:37, Ethan Benson wrote: > On Sun, Aug 17, 2003 at 05:19:08AM +0100, Matthew Wilcox wrote: > > > > So is there any reason to keep the vnodeops layer around? There's only > > one implementation of it (xfs_vnodeops) so it seems kind of pointless. > > Removing it would probably shrink xfs quite a bit, both source and binary. > > i believe its used for CXFS. It is used by CXFS, and it also lets us keep a medium level of sanity when attempting to keep Irix and Linux versions of XFS in sync. Steve From owner-linux-xfs@oss.sgi.com Sun Aug 17 17:08:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Aug 2003 17:08:54 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7I08eFl019316 for ; Sun, 17 Aug 2003 17:08:40 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7I08Xq0026870 for ; Sun, 17 Aug 2003 17:08:34 -0700 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 KAA06942; Mon, 18 Aug 2003 10:08:32 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7I08VmY029277; Mon, 18 Aug 2003 10:08:32 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7I07CCv001307; Mon, 18 Aug 2003 10:07:12 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7I07BOs001305; Mon, 18 Aug 2003 10:07:11 +1000 Date: Mon, 18 Aug 2003 10:07:11 +1000 From: Nathan Scott To: girish dudhe Cc: linux-xfs@oss.sgi.com Subject: Re: How large file store in XFS Message-ID: <20030818000711.GA1251@frodo> References: <20030816065428.56233.qmail@web40410.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030816065428.56233.qmail@web40410.mail.yahoo.com> User-Agent: Mutt/1.5.3i X-archive-position: 68 X-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: 1004 Lines: 30 On Fri, Aug 15, 2003 at 11:54:28PM -0700, girish dudhe wrote: > hi all, > > In XFS,whole file systen is divided into number of > allocation group. e.g. Consider size of the file > system is 1GB ,then it will create eight allocation > group that means each has 125 MB.Each allocation Group > has its own inodes and data blocks. That is correct. > Now I want to store the file of size 500MB.How it > gets stored ? Whether it gets stores in one allocation > group or multiple allocation group? Since it cannot be stored in one allocation group (500 > 125), it will be stored in multiple AGs (assuming it is not a sparse file ;). File extent maps use the full disk addresses, and so are not allocation group relative and can span multiple AGs if necessary. A single extent can never span more than one AG. The xfs_bmap(8) command will show you the block map for a given file, and you can see which allocation group each of the extents lives in using the -v option, iirc. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Aug 17 18:42:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Aug 2003 18:43:01 -0700 (PDT) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7I1gfFl020193 for ; Sun, 17 Aug 2003 18:42:42 -0700 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <0.00005D47@mailhub2.arup.com>; Mon, 18 Aug 2003 2:42:35 +0100 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Mon, 18 Aug 2003 02:42:33 +0100 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Mon, 18 Aug 2003 11:41:33 +1000 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Mon, 18 Aug 2003 11:38:31 +1000 From: "Scott Fagg" To: Subject: Re: NULL file problems (not FAQ...) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7I1ghFl020196 X-archive-position: 69 X-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.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 1624 Lines: 38 > >>>> Net Llama! 16/08/2003 5:41:42 AM >>> >On Fri, 15 Aug 2003, Derek Glidden wrote: >> >> I have a new laptop (Dell Inspiron 5150) on which I've been trying to >> get Linux stabilized. The ATI Radeon Mobility M9 is slightly >> problematic, so it's been crashing a lot while I'm in X. I've been >> running XFS with just one big filesystem on it, with 2.4.21 & recent >> 2.4.21-all patch applied, on top of RedHat 9. A couple of times now, >> the thing has gone down hard requiring a power cycle (no sync possible), >> only to find my /etc/fstab is full of nulls on reboot. Strangely, >> that's the only file that's been getting "eaten" by the null-file thing. >> >> The thing that is really confusing me is: why the heck is fstab being >> eaten and why only fstab? "lsof" on this machine right this moment does >> not show that fstab is open. Has anyone else had this problem with >> RedHat9? Does anyone have any other thoughts on why this would be >> happening? > >I think that's a kudzu bug. I've seen the same thing occur on RH-7.3 as >well on boxes that kudzu didn't get along with. I've had similar problems, co-incidentally while i was testing 2.6 with XFS. After having difficulty in getting 2.6 to boot, i had to hit the power button and noticed that /etc/fstab was trashed. RH8 or 9 , i don't recall which. > >-- >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >Lonni J Friedman netllama@linux-sxs.org >Linux Step-by-step & TyGeMo http://netllama.ipfox.com > > Scott Fagg Arup Brisbane (07) 3023 6000 From owner-linux-xfs@oss.sgi.com Sun Aug 17 23:03:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Aug 2003 23:03:28 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7I63CFl024648 for ; Sun, 17 Aug 2003 23:03:13 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7I0YesR010375 for ; Sun, 17 Aug 2003 19:35:01 -0500 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 KAA06976 for ; Mon, 18 Aug 2003 10:13:54 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7I0DsmY029327 for ; Mon, 18 Aug 2003 10:13:54 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7I0CYCv001366 for ; Mon, 18 Aug 2003 10:12:34 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7I0CYJ2001364 for linux-xfs@oss.sgi.com; Mon, 18 Aug 2003 10:12:34 +1000 Date: Mon, 18 Aug 2003 10:12:34 +1000 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] Implement immutable/append-only flags in XFS #5 Message-ID: <20030818001234.GB1251@frodo> References: <20030817050203.GA11982@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030817050203.GA11982@plato.local.lan> User-Agent: Mutt/1.5.3i X-archive-position: 70 X-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: 463 Lines: 16 On Sat, Aug 16, 2003 at 09:02:03PM -0800, Ethan Benson wrote: > ... > However during my testing I did discover 3 issues: > > 1: The Linux VFS contains a bug which allows timestamp modification of > immutable/append-only files. I have fixed this issue, and will send > the patch to the linux-kernel mailing list shortly. I have included > that patch in this mail for completeness. Any luck getting your VFS patch accepted Ethan? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Aug 18 05:23:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Aug 2003 05:24:05 -0700 (PDT) Received: from hermes.acsalaska.net (hermes.acsalaska.net [209.112.155.38]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7ICNiFl007950 for ; Mon, 18 Aug 2003 05:23:45 -0700 Received: from erbenson.alaska.net (36-pm33.nwc.alaska.net [209.112.159.36]) by hermes.acsalaska.net (8.12.9/8.12.9) with ESMTP id h7ICNfjF047528 for ; Mon, 18 Aug 2003 04:23:42 -0800 (AKDT) (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 006AA39E4 for ; Mon, 18 Aug 2003 04:23:40 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id E02C340FF44; Mon, 18 Aug 2003 04:23:40 -0800 (AKDT) Date: Mon, 18 Aug 2003 04:23:40 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] Implement immutable/append-only flags in XFS #5 Message-ID: <20030818122340.GE11982@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20030817050203.GA11982@plato.local.lan> <20030818001234.GB1251@frodo> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2hMgfIw2X+zgXrFs" Content-Disposition: inline In-Reply-To: <20030818001234.GB1251@frodo> 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.36 X-archive-position: 71 X-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: 1182 Lines: 39 --2hMgfIw2X+zgXrFs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 18, 2003 at 10:12:34AM +1000, Nathan Scott wrote: > On Sat, Aug 16, 2003 at 09:02:03PM -0800, Ethan Benson wrote: > > ... > > However during my testing I did discover 3 issues: > >=20 > > 1: The Linux VFS contains a bug which allows timestamp modification of > > immutable/append-only files. I have fixed this issue, and will send > > the patch to the linux-kernel mailing list shortly. I have included > > that patch in this mail for completeness. >=20 > Any luck getting your VFS patch accepted Ethan? no, it was ignored. Eric suggested i should send it to fsdevel instead, ill do that whenever i get around to it. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --2hMgfIw2X+zgXrFs 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 iEYEARECAAYFAj9AxUwACgkQJKx7GixEevzOVwCfWr8lTh20sMwuVqtIig7Gymj+ uU4An0sSuMlp592QELvytQtQki43VkZj =hnB1 -----END PGP SIGNATURE----- --2hMgfIw2X+zgXrFs-- From owner-linux-xfs@oss.sgi.com Mon Aug 18 12:20:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Aug 2003 12:20:22 -0700 (PDT) Received: from shell.f2o.org (shell.f2o.org [63.237.54.243]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IJK5Fl026182 for ; Mon, 18 Aug 2003 12:20:08 -0700 Received: from f2o.org (gateway3.starkmedia.com [63.237.54.129] (may be forged)) (authenticated (0 bits)) by shell.f2o.org (8.12.9/8.11.6) with ESMTP id h7IJJxPD001034 for ; Mon, 18 Aug 2003 14:20:00 -0500 Message-ID: <3F41259A.4010109@f2o.org> Date: Mon, 18 Aug 2003 14:14:34 -0500 From: "Daniel J. Cody" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Incorrect XFS version string in pre6 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 72 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: djc@f2o.org Precedence: bulk X-list: linux-xfs Content-Length: 456 Lines: 17 Just a heads up, but the latest 1.3-pre6 patch has a typo. In the file linux-xfs-1.3.0pre6.patch, line 23016 has the following typo: #define XFS_VERSION_STRING "SGI XFS 1.3.0pre4" should be #define XFS_VERSION_STRING "SGI XFS 1.3.0pre6" Probably not a big deal, as these are just pre-releases, but in case anyone is confused by their kernel dmesg saying pre4 even though they think they're using pre6, no need to sweat :) Dan http://five2one.org/ From owner-linux-xfs@oss.sgi.com Mon Aug 18 12:43:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Aug 2003 12:43:43 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IJhRFl027969 for ; Mon, 18 Aug 2003 12:43:28 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7IJhMq0025883 for ; Mon, 18 Aug 2003 12:43:22 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7IJf2QK7728171 for ; Mon, 18 Aug 2003 14:41:02 -0500 (CDT) Received: from sgi.com (chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7IJf1Rn232210989 for ; Mon, 18 Aug 2003 14:41:02 -0500 (CDT) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h7IJf156016235 for ; Mon, 18 Aug 2003 14:41:01 -0500 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.8/8.12.8/Submit) id h7IJf1Jt016233 for linux-xfs@oss.sgi.com; Mon, 18 Aug 2003 14:41:01 -0500 Date: Mon, 18 Aug 2003 14:41:01 -0500 From: Russell Cattelan Message-Id: <200308181941.h7IJf1Jt016233@chuckle.americas.sgi.com> Subject: TAKE - Move to pre6 X-archive-position: 73 X-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@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 272 Lines: 11 Date: Mon Aug 18 12:40:46 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-r1.3 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.3 Modid: 2.4.x-xfs-r1.3:slinx:156099a linux/fs/xfs/linux/xfs_version.h - 1.170 From owner-linux-xfs@oss.sgi.com Mon Aug 18 14:45:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Aug 2003 14:45:17 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h7ILjCFl000612 for ; Mon, 18 Aug 2003 14:45:12 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7ILjCI2000611 for linux-xfs@oss.sgi.com; Mon, 18 Aug 2003 14:45:12 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h7ILjBFn000597 for ; Mon, 18 Aug 2003 14:45:11 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7ILa2mc032665; Mon, 18 Aug 2003 14:36:02 -0700 Date: Mon, 18 Aug 2003 14:36:02 -0700 Message-Id: <200308182136.h7ILa2mc032665@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 275] New: Consistant oops on dual athlon boards X-Bugzilla-Reason: AssignedTo X-archive-position: 74 X-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: 3318 Lines: 82 http://oss.sgi.com/bugzilla/show_bug.cgi?id=275 Summary: Consistant oops on dual athlon boards Product: Linux XFS Version: unspecified Platform: AMD OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: xfs@djc.f2o.org Over the past few months, I've been able to consistantly crash XFS-enabled kernels with a 35Gb rsync(or any high disk I/O) to a dual AMD server. Will try to get a backtrace ASAP. This is on a stock 2.4.21 kernel with XFS 1.3-pre6 Unable to handle kernel paging request at virtual address 593fe098 c013049b *pde = 00000000 Oops: 0000 CPU: 1 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010007 eax: 20202020 ebx: 20202020 ecx: d8bf6000 edx: c15b9800 esi: 00000029 edi: 00000054 ebp: dffea268 esp: decb9e6c ds: 0018 es: 0018 ss: 0018 Process sendmail (pid: 672, stackpage=decb9000) Stack: dffea270 dffea278 dffea268 00000246 000001f0 c158d440 c013117b dffea268 c15b9800 000001f0 fffffff4 c158d4ac c158c1c0 c158d440 c0130597 dffea268 000001f0 c014ecbc dffea268 000001f0 00000007 fffffff4 c158d4ac c158c1c0 [] __kmem_cache_alloc+0x5b/0x130 [kernel] [] kmem_cache_alloc+0x17/0x20 [kernel] [] d_alloc+0x1c/0x1b0 [kernel] [] real_lookup+0xaf/0x140 [kernel] [] link_path_walk+0x5a8/0x6c0 [kernel] [] path_walk+0x16/0x20 [kernel] [] path_lookup+0x39/0x40 [kernel] [] open_namei+0x70/0x570 [kernel] [] filp_open+0x3e/0x70 [kernel] [] sys_open+0x53/0xc0 [kernel] [] system_call+0x33/0x38 [kernel] Code: 8b 44 81 18 0f af 5d 18 89 41 14 03 59 0c 40 74 33 8b 4c 24 >>EIP; c013049b <===== Code; c013049b 00000000 <_EIP>: Code; c013049b <===== 0: 8b 44 81 18 mov 0x18(%ecx,%eax,4),%eax <===== Code; c013049f 4: 0f af 5d 18 imul 0x18(%ebp),%ebx Code; c01304a3 8: 89 41 14 mov %eax,0x14(%ecx) Code; c01304a6 b: 03 59 0c add 0xc(%ecx),%ebx Code; c01304a9 e: 40 inc %eax Code; c01304aa f: 74 33 je 44 <_EIP+0x44> c01304df Code; c01304ac 11: 8b 4c 24 00 mov 0x0(%esp,1),%ecx 1 warning and 1 error issued. Results may not be reliable. root@shell:/home/djc> uname -a Linux shell 2.4.21-xfs-djc #4 SMP Mon Aug 18 13:55:43 CDT 2003 i686 unknown root@shell:/home/djc> gcc -v Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/specs Configured with: ./configure --host=i686-pc-linux-gnu --enable-threads=posix --with-cpu=i686 --disable-libgcj Thread model: posix gcc version 3.3.1 ------- 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 Aug 18 15:07:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Aug 2003 15:07:40 -0700 (PDT) Received: from ams005.ftl.affinity.com (lvs00-fl.valueweb.net [216.219.253.199]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IM7OFl002080 for ; Mon, 18 Aug 2003 15:07:25 -0700 Received: from david.internal.NorcrossGroup.com ([66.156.9.52]) by ams.ftl.affinity.com with ESMTP id <262327-31920>; Mon, 18 Aug 2003 18:06:48 -0400 Subject: rdiff-backup / EAs / ACLs From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: Linux-XFS Mailing List Content-Type: text/plain Organization: Message-Id: <1061244256.29493.72.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 18 Aug 2003 18:04:17 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 75 X-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-ml@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 533 Lines: 28 XFS/EA/ACL experts, I'm trying to test rdiff-backup (unstable) for xfs acl support. So far it is not working: My understanding of xfs acls is that they are implemented via EAs. right? If so, should the python module pyxattr handle them? Or does rdiff-backup need to explicitely support EAs and ACLs seperately? FYI, I'm trying: rdiff-backup 0.13.1 librsync 0.9.6 (including devel) pyxattr 0.2 xfs 1.2 libattr-2.4.0 (including devel) libacl-2.2.6 (including devel) Thanks Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Mon Aug 18 16:04:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Aug 2003 16:04:56 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IN4cFl004610 for ; Mon, 18 Aug 2003 16:04:39 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7IN4Xq0015584 for ; Mon, 18 Aug 2003 16:04:33 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7IN4WQK7743711; Mon, 18 Aug 2003 18:04:32 -0500 (CDT) Received: from naboo (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7IN4WRn194748018; Mon, 18 Aug 2003 18:04:32 -0500 (CDT) Subject: Re: Incorrect XFS version string in pre6 From: Russell Cattelan To: "Daniel J. Cody" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F41259A.4010109@f2o.org> References: <3F41259A.4010109@f2o.org> Content-Type: text/plain Message-Id: <1061247871.10294.68.camel@naboo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4-2mdk Date: Mon, 18 Aug 2003 18:04:32 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 76 X-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: 872 Lines: 28 Ack my bad AGAIN! I updated the patches and pushed them out to oss. 3d41935cd91d74bcc8774d978b1142f1 linux-xfs-1.3.0pre5-pre6.patch.gz de575f079256d4dc6859d9f5ca91af02 linux-xfs-1.3.0pre6.patch.gz Note there were also some extraneous files in the old patches, the don't affect the code in anyway just extra unneeded stuff. On Mon, 2003-08-18 at 14:14, Daniel J. Cody wrote: > Just a heads up, but the latest 1.3-pre6 patch has a typo. > > In the file linux-xfs-1.3.0pre6.patch, line 23016 has the following typo: > > #define XFS_VERSION_STRING "SGI XFS 1.3.0pre4" > > should be > > #define XFS_VERSION_STRING "SGI XFS 1.3.0pre6" > > Probably not a big deal, as these are just pre-releases, but in case > anyone is confused by their kernel dmesg saying pre4 even though they > think they're using pre6, no need to sweat :) > > Dan > http://five2one.org/ > From owner-linux-xfs@oss.sgi.com Mon Aug 18 16:49:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Aug 2003 16:49:49 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7INnkFl005883 for ; Mon, 18 Aug 2003 16:49:47 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7J06Dnk006250 for ; Mon, 18 Aug 2003 19:06:14 -0500 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 h7INnW1S3765930 for ; Tue, 19 Aug 2003 09:49:32 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h7INnWMn3767742 for linux-xfs@oss.sgi.com; Tue, 19 Aug 2003 09:49:32 +1000 (EST) Date: Tue, 19 Aug 2003 09:49:32 +1000 (EST) From: Nathan Scott Message-Id: <200308182349.h7INnWMn3767742@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs X-archive-position: 77 X-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: 418 Lines: 16 Bump xfsprogs version for mkfs stripe fix, fix a typo in one of the warning messages. Date: Mon Aug 18 16:48:27 PDT 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:156132a xfsprogs/VERSION - 1.86 xfsprogs/doc/CHANGES - 1.124 xfsprogs/mkfs/xfs_mkfs.c - 1.50 xfsprogs/debian/changelog - 1.79 From owner-linux-xfs@oss.sgi.com Mon Aug 18 17:03:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Aug 2003 17:03:31 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7J03GFl006483 for ; Mon, 18 Aug 2003 17:03:17 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7J039q0021491 for ; Mon, 18 Aug 2003 17:03:11 -0700 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 KAA18621 for ; Tue, 19 Aug 2003 10:02:57 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7J02umY032821 for ; Tue, 19 Aug 2003 10:02:56 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7J01ZKm000992 for ; Tue, 19 Aug 2003 10:01:35 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7J01ZSN000990 for linux-xfs@oss.sgi.com; Tue, 19 Aug 2003 10:01:35 +1000 Date: Tue, 19 Aug 2003 10:01:35 +1000 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] Implement immutable/append-only flags in XFS #5 Message-ID: <20030819000135.GA940@frodo> References: <20030817050203.GA11982@plato.local.lan> <20030818001234.GB1251@frodo> <20030818122340.GE11982@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030818122340.GE11982@plato.local.lan> User-Agent: Mutt/1.5.3i X-archive-position: 78 X-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: 1006 Lines: 27 On Mon, Aug 18, 2003 at 04:23:40AM -0800, Ethan Benson wrote: > On Mon, Aug 18, 2003 at 10:12:34AM +1000, Nathan Scott wrote: > > On Sat, Aug 16, 2003 at 09:02:03PM -0800, Ethan Benson wrote: > > > ... > > > However during my testing I did discover 3 issues: > > > > > > 1: The Linux VFS contains a bug which allows timestamp modification of > > > immutable/append-only files. I have fixed this issue, and will send > > > the patch to the linux-kernel mailing list shortly. I have included > > > that patch in this mail for completeness. > > > > Any luck getting your VFS patch accepted Ethan? > > no, it was ignored. Eric suggested i should send it to fsdevel > instead, ill do that whenever i get around to it. > For a bug fix, I would instead create a 2.6-current patch and send it to Andrew Morton with a detailed description of the problem and your solution. Once it is in an acceptable form for 2.6, it becomes much more likely to be merged into the 2.4 tree. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Aug 18 20:20:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Aug 2003 20:20:56 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7J3KdFl009121 for ; Mon, 18 Aug 2003 20:20:40 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7J3b7nk002885 for ; Mon, 18 Aug 2003 22:37:08 -0500 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 NAA20296; Tue, 19 Aug 2003 13:20:27 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7J3KPmY033829; Tue, 19 Aug 2003 13:20:26 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7J3J3Km014719; Tue, 19 Aug 2003 13:19:03 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7J3Iwew014457; Tue, 19 Aug 2003 13:18:58 +1000 Date: Tue, 19 Aug 2003 13:18:58 +1000 From: Nathan Scott To: Greg Freemyer Cc: linux-xfs@oss.sgi.com, acl-devel@bestbits.at Subject: Re: rdiff-backup / EAs / ACLs Message-ID: <20030819031858.GE940@frodo> References: <1061244256.29493.72.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1061244256.29493.72.camel@david.internal.NorcrossGroup.com> User-Agent: Mutt/1.5.3i X-archive-position: 79 X-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: 1065 Lines: 47 On Mon, Aug 18, 2003 at 06:04:17PM -0400, Greg Freemyer wrote: > XFS/EA/ACL experts, > > I'm trying to test rdiff-backup (unstable) for xfs acl support. > > So far it is not working: > > > My understanding of xfs acls is that they are implemented via EAs. > right? Yes, although libacl hides the user/kernel interface and presents a (draft-POSIX-standard-compliant) ACL interface to users which isn't aware of extended attributes. > If so, should the python module pyxattr handle them? I don't know what that module does. > Or does rdiff-backup need to explicitely support EAs and ACLs > seperately? You probably want to have a look into the work Andreas did in getting the cp/ls/... tools (now called "coreutils" I think) to work with ACLs and extended attributes, and start from there. cheers. > FYI, I'm trying: > rdiff-backup 0.13.1 > librsync 0.9.6 (including devel) > pyxattr 0.2 > xfs 1.2 > libattr-2.4.0 (including devel) > libacl-2.2.6 (including devel) > > Thanks > Greg > -- > Greg Freemyer > > -- Nathan From owner-linux-xfs@oss.sgi.com Mon Aug 18 20:32:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Aug 2003 20:32:45 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7J3WhFl009937 for ; Mon, 18 Aug 2003 20:32:43 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7J3Wbq0008758 for ; Mon, 18 Aug 2003 20:32:37 -0700 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h7J3W1VL003265 for ; Tue, 19 Aug 2003 13:32:01 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h7J3W1pU003264 for linux-xfs@oss.sgi.com; Tue, 19 Aug 2003 13:32:01 +1000 Date: Tue, 19 Aug 2003 13:32:01 +1000 From: Nathan Scott Message-Id: <200308190332.h7J3W1pU003264@bruce.melbourne.sgi.com> Subject: TAKE - iomap write flag typo X-archive-position: 80 X-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@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 378 Lines: 13 Fix a harmless typo - we were using a pagebuf flag not a bmap flag in one spot; fortunately they have the same value (2). Date: Mon Aug 18 20:31:29 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/nathans/isms/devel The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:156143a linux/fs/xfs/linux/xfs_iomap.c - 1.15 From owner-linux-xfs@oss.sgi.com Tue Aug 19 00:38:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Aug 2003 00:39:05 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7J7cSFl015277 for ; Tue, 19 Aug 2003 00:38:29 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7J7sunk005331 for ; Tue, 19 Aug 2003 02:54:57 -0500 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 h7J7cK1S3954562 for ; Tue, 19 Aug 2003 17:38:20 +1000 (EST) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h7J7cK9Y3917790 for linux-xfs@oss.sgi.com; Tue, 19 Aug 2003 17:38:20 +1000 (EST) Date: Tue, 19 Aug 2003 17:38:20 +1000 (EST) From: Timothy Shimmin Message-Id: <200308190738.h7J7cK9Y3917790@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xlog_verify_iclog() X-archive-position: 81 X-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: 1006 Lines: 29 Hopefully help with the xlog_verify_iclog() assertion failures that Nathan saw with v2 logs. --Tim pv=892598; rv=nathans@sgi.com; Change xlog_verify_iclog() to use idx as zero based instead of 1 based index into array. Nathan tried this change out on some benchmarks and it seems to help - stop the assert from happening. Nathan will do the merge of this mod. Date: Tue Aug 19 00:33:49 PDT 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-linux:slinx:156160a linux/fs/xfs/xfs_log.c - 1.280 - Change xlog_verify_iclog() to use idx as zero based instead of 1 based index into array. To do this use BTOBBT() instead of BTOBB() to work out which page (starting from zero) that we are on. This then requires idx comparison to be altered from > to >= (as was initially used in Glen's IRIX change). The change is needed for extraction of the oh_clientid and oh_len fields. From owner-linux-xfs@oss.sgi.com Tue Aug 19 00:44:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Aug 2003 00:44:37 -0700 (PDT) Received: from bastard (adsl-67-114-19-186.dsl.pltn13.pacbell.net [67.114.19.186]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7J7iXFl015762 for ; Tue, 19 Aug 2003 00:44:33 -0700 Received: from localhost (bastard [127.0.0.1]) by bastard (Postfix) with ESMTP id D5B62F23DA for ; Tue, 19 Aug 2003 00:44:32 -0700 (PDT) Received: from bastard ([127.0.0.1]) by localhost (bastard [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11947-01-2 for ; Tue, 19 Aug 2003 00:44:12 -0700 (PDT) Received: from tupshin.com (fussbudget [172.16.1.50]) by bastard (Postfix) with ESMTP id 7CC82F23D5 for ; Tue, 19 Aug 2003 00:44:12 -0700 (PDT) Message-ID: <3F4237BC.4030005@tupshin.com> Date: Tue, 19 Aug 2003 07:44:12 -0700 From: Tupshin Harper User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030813 Thunderbird/0.2a X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: able to reproduce growfs bug on LVM(FAQ) at will Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p3 (Debian) at smallmerchant.com X-archive-position: 82 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tupshin@tupshin.com Precedence: bulk X-list: linux-xfs Content-Length: 3227 Lines: 85 I am encountering the FAQ'd bug that prevents xfs_growfs from working on a resized LVM volume. The workaround (umount and xfs_repair) does work, but I was wondering if I could be of some assistance in tracking the bug down? Since it is highly reproducible, I can gather any gatherable information. FWIW, I'm running on: Athlon XP CPU Debian Sid Kernel 2.6.0-test3 (almost stock) LVM2 on dev-mapper A (mildly) interesting datapoint is that an incomplete xfs_repair (it errrored out in Phase 6 because of insufficient space) still corrected the problem, so some write operation that takes place in Phases 1-5 fixes the issue. I've included a log of a failed xfs_growfs, a xfs_repair, and a successful xfs_growfs below. -Tupshin bastard:~# xfs_growfs /data/shared/ meta-data=/data/shared isize=256 agcount=8, agsize=163840 blks = sectsz=512 data = bsize=4096 blocks=1310720, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 bastard:~# umount /data/shared/ bastard:~# xfs_repair /dev/lvm_group_1/ apps cpsft debmir diskless docs uml vm_redhat shared wine bastard:~# xfs_repair /dev/lvm_group_1/shared 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 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 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 fatal error -- ran out of disk space! bastard:~# mount /data/shared/ bastard:~# xfs_growfs /data/shared/ meta-data=/data/shared isize=256 agcount=8, agsize=163840 blks = sectsz=512 data = bsize=4096 blocks=1310720, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 data blocks changed from 1310720 to 1835008 From owner-linux-xfs@oss.sgi.com Tue Aug 19 02:34:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Aug 2003 02:34:31 -0700 (PDT) Received: from modeemi.modeemi.cs.tut.fi (modeemi.modeemi.cs.tut.fi [130.230.72.134]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7J9Y4Fl018859 for ; Tue, 19 Aug 2003 02:34:06 -0700 Received: from jolt.modeemi.fi (jolt.modeemi.cs.tut.fi [130.230.72.144]) by modeemi.modeemi.cs.tut.fi (Postfix) with ESMTP id 4F4119F8F for ; Tue, 19 Aug 2003 12:34:03 +0300 (EEST) Received: by jolt.modeemi.fi (Postfix, from userid 17990) id 92A5080AA1; Tue, 19 Aug 2003 12:34:00 +0300 (EEST) Date: Tue, 19 Aug 2003 12:34:00 +0300 From: Erkki Seppala To: linux-xfs@oss.sgi.com Subject: Workaroundable bug with 2.6.0-test3 xfs & xfs_growfs Message-ID: <20030819093400.GA22198@modeemi.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-archive-position: 83 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: flux-xfs@inside.org Precedence: bulk X-list: linux-xfs Content-Length: 1361 Lines: 33 Growing filesystem twice after mount fails. Reproducing: 1) mount /dev/store/media2 - 100G volume 2) lvextend -L 200G /dev/store/media2 3) xfs_growfs -d /dev/store/media2 -> works ok 4) lvextend -L 350G /dev/store/media2 5) xfs_growfs -d /dev/store/media2 -> says there is nothing to be done Unmounting and mounting the system will allow xfs_growfs to work again. This is the output I'm getting (a bit fake, taken after the incident, the size was reported properly): meta-data=/mnt/media2 isize=256 agcount=88, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=91750400, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=12800, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 data size unchanged, skipping I have xfsprogs 2.5.4-1 from Debian unstable. -- _____________________________________________________________________ / __// /__ ____ __ http://www.modeemi.fi/~flux/\ \ / /_ / // // /\ \/ / \ / /_/ /_/ \___/ /_/\_\@modeemi.fi \/ From owner-linux-xfs@oss.sgi.com Tue Aug 19 05:38:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Aug 2003 05:39:12 -0700 (PDT) Received: from web40408.mail.yahoo.com (web40408.mail.yahoo.com [66.218.78.105]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JCcuFl024166 for ; Tue, 19 Aug 2003 05:38:57 -0700 Message-ID: <20030819123851.917.qmail@web40408.mail.yahoo.com> Received: from [203.123.165.55] by web40408.mail.yahoo.com via HTTP; Tue, 19 Aug 2003 05:38:51 PDT Date: Tue, 19 Aug 2003 05:38:51 -0700 (PDT) From: girish dudhe Subject: Problem regarding XFS allocation group To: linux-xfs@oss.sgi.com Cc: nathans@sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 84 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: girish_dudhe@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 561 Lines: 33 Hi all, In XFS,whole file systen is divided into number of allocation groups. Is there any function by which we can access the allocation group(or can we get pointer to allocation group)? Is there any metadata for that allocation group? one more thing ,Can u please tell me the concept of file extent map? Thanks in advance Girish ===== GIRISH V. DUDHE [girish_dudhe@yahoo.com ] __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From owner-linux-xfs@oss.sgi.com Tue Aug 19 06:49:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Aug 2003 06:49:51 -0700 (PDT) Received: from ams013.ftl.affinity.com (lvs00-fl.valueweb.net [216.219.253.199]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JDnjFl026708 for ; Tue, 19 Aug 2003 06:49:46 -0700 Received: from david.internal.NorcrossGroup.com ([66.156.9.52]) by ams.ftl.affinity.com with ESMTP id <240447-17762>; Tue, 19 Aug 2003 09:48:49 -0400 Subject: Re: rdiff-backup / EAs / ACLs From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: Nathan Scott Cc: linux-xfs@oss.sgi.com, acl-devel@bestbits.at In-Reply-To: <20030819031858.GE940@frodo> References: <1061244256.29493.72.camel@david.internal.NorcrossGroup.com> <20030819031858.GE940@frodo> Content-Type: text/plain Organization: Message-Id: <1061300770.29493.97.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 19 Aug 2003 09:46:11 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 85 X-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-ml@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 1132 Lines: 42 On Mon, 2003-08-18 at 23:18, Nathan Scott wrote: > On Mon, Aug 18, 2003 at 06:04:17PM -0400, Greg Freemyer wrote: > > XFS/EA/ACL experts, > > > > I'm trying to test rdiff-backup (unstable) for xfs acl support. > > > > So far it is not working: > > > > > > My understanding of xfs acls is that they are implemented via EAs. > > right? > > Yes, although libacl hides the user/kernel interface and > presents a (draft-POSIX-standard-compliant) ACL interface > to users which isn't aware of extended attributes. Does libattr allow access to ACLs, or from userland are EAs and ACLs truly distinct? > > > If so, should the python module pyxattr handle them? > > I don't know what that module does. It only talks about EAs, but I was hoping in XFS's case this would be enough. > > > Or does rdiff-backup need to explicitely support EAs and ACLs > > seperately? > > You probably want to have a look into the work Andreas did in > getting the cp/ls/... tools (now called "coreutils" I think) to > work with ACLs and extended attributes, and start from there. > I'll take a look at cp in particular. Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Tue Aug 19 08:39:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Aug 2003 08:39:36 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JFdIFl030747 for ; Tue, 19 Aug 2003 08:39:19 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7JFdDq0027933 for ; Tue, 19 Aug 2003 08:39:13 -0700 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7JFdCQK7988408 for ; Tue, 19 Aug 2003 10:39:13 -0500 (CDT) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7JFdC0L16415482 for ; Tue, 19 Aug 2003 10:39:12 -0500 (CDT) 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 h7JFdCTg5926943 for ; Tue, 19 Aug 2003 10:39:12 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id h7JFdC5E5921352 for linux-xfs@oss.sgi.com; Tue, 19 Aug 2003 10:39:12 -0500 (CDT) Date: Tue, 19 Aug 2003 10:39:12 -0500 (CDT) From: Dean Roehrich Message-Id: <200308191539.h7JFdC5E5921352@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - X-archive-position: 86 X-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: 352 Lines: 16 fix some ia64 warnings in dmapi_xfs.c thanks, russell. Date: Tue Aug 19 08:39:00 PDT 2003 Workarea: clink.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs-dev-a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-dev Modid: 2.4.x-xfs-kern:slinx:156181a linux/fs/xfs/dmapi/dmapi_xfs.c - 1.7 - fix warnings From owner-linux-xfs@oss.sgi.com Tue Aug 19 09:12:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Aug 2003 09:12:34 -0700 (PDT) Received: from bastard (adsl-67-114-19-186.dsl.pltn13.pacbell.net [67.114.19.186]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JGC7Fl032743 for ; Tue, 19 Aug 2003 09:12:27 -0700 Received: from localhost (bastard [127.0.0.1]) by bastard (Postfix) with ESMTP id 65518F3E45 for ; Tue, 19 Aug 2003 09:12:08 -0700 (PDT) Received: from bastard ([127.0.0.1]) by localhost (bastard [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01809-01-4 for ; Tue, 19 Aug 2003 09:11:48 -0700 (PDT) Received: from tupshin.com (fussbudget [172.16.1.50]) by bastard (Postfix) with ESMTP id CFF71F23D4 for ; Tue, 19 Aug 2003 09:11:48 -0700 (PDT) Message-ID: <3F424C42.5050601@tupshin.com> Date: Tue, 19 Aug 2003 09:11:46 -0700 From: Tupshin Harper User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030813 Thunderbird/0.2a X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: able to reproduce growfs bug on LVM(FAQ) at will References: <3F4237BC.4030005@tupshin.com> In-Reply-To: <3F4237BC.4030005@tupshin.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p3 (Debian) at smallmerchant.com X-archive-position: 87 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tupshin@tupshin.com Precedence: bulk X-list: linux-xfs Content-Length: 1089 Lines: 29 Tupshin Harper wrote: > I am encountering the FAQ'd bug that prevents xfs_growfs from working > on a resized LVM volume. The workaround (umount and xfs_repair) does > work, but I was wondering if I could be of some assistance in tracking > the bug down? Since it is highly reproducible, I can gather any > gatherable information. FWIW, I'm running on: > Athlon XP CPU > Debian Sid > Kernel 2.6.0-test3 (almost stock) > LVM2 on dev-mapper > > A (mildly) interesting datapoint is that an incomplete xfs_repair (it > errrored out in Phase 6 because of insufficient space) still corrected > the problem, so some write operation that takes place in Phases 1-5 > fixes the issue. > > I've included a log of a failed xfs_growfs, a xfs_repair, and a > successful xfs_growfs below. > > -Tupshin > Let me correct myself, and concur with Erkki. xfs_repair is absolutely unnecessary to fix the problem unmounting the fs, and remounting it allows xfs_growsfs to function correctly after an LVM resize. I was thrown off by the FAQ that said that xfs_repair was the way to fix it. -Tupshin From owner-linux-xfs@oss.sgi.com Tue Aug 19 13:12:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Aug 2003 13:12:16 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JKBgFl025914 for ; Tue, 19 Aug 2003 13:12:03 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7JKSEnk029841 for ; Tue, 19 Aug 2003 15:28:14 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7JKBbQK8070102 for ; Tue, 19 Aug 2003 15:11:37 -0500 (CDT) Received: from sgi.com (chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7JKBbRn240557024 for ; Tue, 19 Aug 2003 15:11:37 -0500 (CDT) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h7JKBa56025636 for ; Tue, 19 Aug 2003 15:11:36 -0500 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.8/8.12.8/Submit) id h7JKBZ6x025634 for linux-xfs@oss.sgi.com; Tue, 19 Aug 2003 15:11:35 -0500 Date: Tue, 19 Aug 2003 15:11:35 -0500 From: Russell Cattelan Message-Id: <200308192011.h7JKBZ6x025634@chuckle.americas.sgi.com> Subject: TAKE - Cleanups from Alexander Kabaev X-archive-position: 88 X-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@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 246 Lines: 11 Date: Tue Aug 19 13:11:20 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:156218a xfsprogs/libxfs/freebsd.c - 1.7 From owner-linux-xfs@oss.sgi.com Tue Aug 19 15:26:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Aug 2003 15:27:00 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JMQiFl030827 for ; Tue, 19 Aug 2003 15:26:44 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7JMhEnk002580 for ; Tue, 19 Aug 2003 17:43:14 -0500 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 IAA00933; Wed, 20 Aug 2003 08:26:20 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7JMQImY037709; Wed, 20 Aug 2003 08:26:19 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7JMOsJr000912; Wed, 20 Aug 2003 08:24:55 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7JMOq4k000910; Wed, 20 Aug 2003 08:24:52 +1000 Date: Wed, 20 Aug 2003 08:24:52 +1000 From: Nathan Scott To: Greg Freemyer Cc: linux-xfs@oss.sgi.com, acl-devel@bestbits.at Subject: Re: rdiff-backup / EAs / ACLs Message-ID: <20030819222452.GB743@frodo> References: <1061244256.29493.72.camel@david.internal.NorcrossGroup.com> <20030819031858.GE940@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030819031858.GE940@frodo> User-Agent: Mutt/1.5.3i X-archive-position: 89 X-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: 758 Lines: 23 On Tue, Aug 19, 2003 at 09:46:11 -0400, Greg Freemyer wrote: > On Mon, 2003-08-18 at 23:18, Nathan Scott wrote: > > On Mon, Aug 18, 2003 at 06:04:17 -0400, Greg Freemyer wrote: > > > > > > My understanding of xfs acls is that they are implemented via EAs. > > > right? > > > > Yes, although libacl hides the user/kernel interface and > > presents a (draft-POSIX-standard-compliant) ACL interface > > to users which isn't aware of extended attributes. > > Does libattr allow access to ACLs, or from userland are EAs and ACLs > truly distinct? Yes, libattr sees system.{posix_acl_access,system.posix_acl_default} as raw binary data, which I guess is all you need. libacl will let you manipulate these as text also if you need that. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Aug 19 15:49:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Aug 2003 15:49:26 -0700 (PDT) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JMnAFl031862 for ; Tue, 19 Aug 2003 15:49:11 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7JKoBQa015726 for ; Tue, 19 Aug 2003 13:50:12 -0700 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 IAA01111; Wed, 20 Aug 2003 08:49:03 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7JMn1mY037616; Wed, 20 Aug 2003 08:49:02 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7JMlbJr001045; Wed, 20 Aug 2003 08:47:37 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7JMlbdd001043; Wed, 20 Aug 2003 08:47:37 +1000 Date: Wed, 20 Aug 2003 08:47:37 +1000 From: Nathan Scott To: girish dudhe Cc: linux-xfs@oss.sgi.com Subject: Re: Problem regarding XFS allocation group Message-ID: <20030819224736.GF743@frodo> References: <20030819123851.917.qmail@web40408.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030819123851.917.qmail@web40408.mail.yahoo.com> User-Agent: Mutt/1.5.3i X-archive-position: 90 X-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: 525 Lines: 23 On Tue, Aug 19, 2003 at 05:38:51AM -0700, girish dudhe wrote: > Hi all, > > In XFS,whole file systen is divided into number of > allocation groups. > Is there any function by which we can access the > allocation group(or can we get pointer to allocation > group)? > > Is there any metadata for that allocation group? > > one more thing ,Can u please tell me the concept of > file extent map? > Get some coffee, then start reading here: http://oss.sgi.com/projects/xfs/publications.html cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Aug 19 15:53:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Aug 2003 15:53:06 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JMr1Fl032311 for ; Tue, 19 Aug 2003 15:53:02 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7JMqsq0006939 for ; Tue, 19 Aug 2003 15:52:55 -0700 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 IAA01156; Wed, 20 Aug 2003 08:52:52 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7JMqpmY037767; Wed, 20 Aug 2003 08:52:51 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7JMpRJr001083; Wed, 20 Aug 2003 08:51:27 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7JMpQiG001081; Wed, 20 Aug 2003 08:51:26 +1000 Date: Wed, 20 Aug 2003 08:51:26 +1000 From: Nathan Scott To: Tupshin Harper Cc: linux-xfs@oss.sgi.com Subject: Re: able to reproduce growfs bug on LVM(FAQ) at will Message-ID: <20030819225126.GG743@frodo> References: <3F4237BC.4030005@tupshin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F4237BC.4030005@tupshin.com> User-Agent: Mutt/1.5.3i X-archive-position: 91 X-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: 723 Lines: 18 On Tue, Aug 19, 2003 at 07:44:12AM -0700, Tupshin Harper wrote: > I am encountering the FAQ'd bug that prevents xfs_growfs from working on > a resized LVM volume. The workaround (umount and xfs_repair) does work, > but I was wondering if I could be of some assistance in tracking the bug > down? Since it is highly reproducible, I can gather any gatherable ^^^^^^^^^^^^^^^^^^^ Can you try the latest XFS 1.3-pre6 code and see if the problem is resolved there? There was a growfs fix went in there in the last few days. Make sure you start from a known not-corrupt fs of course. Seth, I think that FAQ entry can be removed/updated now to say the problem is resolved in 1.3. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Aug 19 16:09:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Aug 2003 16:09:45 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JN9UFl001410 for ; Tue, 19 Aug 2003 16:09:31 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7JNQ0nk012772 for ; Tue, 19 Aug 2003 18:26:01 -0500 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 JAA01304; Wed, 20 Aug 2003 09:09:21 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7JN9KmY037789; Wed, 20 Aug 2003 09:09:20 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7JN7uJr001137; Wed, 20 Aug 2003 09:07:56 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7JN7txg001135; Wed, 20 Aug 2003 09:07:55 +1000 Date: Wed, 20 Aug 2003 09:07:55 +1000 From: Nathan Scott To: Erkki Seppala Cc: linux-xfs@oss.sgi.com Subject: Re: Workaroundable bug with 2.6.0-test3 xfs & xfs_growfs Message-ID: <20030819230755.GH743@frodo> References: <20030819093400.GA22198@modeemi.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030819093400.GA22198@modeemi.fi> User-Agent: Mutt/1.5.3i X-archive-position: 92 X-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: 931 Lines: 30 On Tue, Aug 19, 2003 at 12:34:00PM +0300, Erkki Seppala wrote: > Growing filesystem twice after mount fails. Reproducing: > > 1) mount /dev/store/media2 - 100G volume > 2) lvextend -L 200G /dev/store/media2 > 3) xfs_growfs -d /dev/store/media2 > -> works ok > 4) lvextend -L 350G /dev/store/media2 > 5) xfs_growfs -d /dev/store/media2 > -> says there is nothing to be done > > Unmounting and mounting the system will allow xfs_growfs to work > again. > This sounds like the device is not properly updating its size. Can you cat /proc/partitions after each device size extension, and check that it is the expected size. xfs_growfs is issuing an ioctl querying the device size before it tells the XFS kernel code what size to extend to - for some reason it seems that your second growfs there is getting the same size as before... if so, this would point to a problem in the device driver and not XFS. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Aug 19 16:18:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Aug 2003 16:18:25 -0700 (PDT) Received: from bastard (adsl-67-114-19-186.dsl.pltn13.pacbell.net [67.114.19.186]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JNIJFl002181 for ; Tue, 19 Aug 2003 16:18:20 -0700 Received: from localhost (bastard [127.0.0.1]) by bastard (Postfix) with ESMTP id A4E06F3E4A; Tue, 19 Aug 2003 16:18:22 -0700 (PDT) Received: from bastard ([127.0.0.1]) by localhost (bastard [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16343-04-3; Tue, 19 Aug 2003 16:18:03 -0700 (PDT) Received: from tupshin.com (fussbudget [172.16.1.50]) by bastard (Postfix) with ESMTP id 137C2F2324; Tue, 19 Aug 2003 16:18:03 -0700 (PDT) Message-ID: <3F42B027.40700@tupshin.com> Date: Tue, 19 Aug 2003 16:17:59 -0700 From: Tupshin Harper User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030813 Thunderbird/0.2a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott Cc: Erkki Seppala , linux-xfs@oss.sgi.com Subject: Re: Workaroundable bug with 2.6.0-test3 xfs & xfs_growfs References: <20030819093400.GA22198@modeemi.fi> <20030819230755.GH743@frodo> In-Reply-To: <20030819230755.GH743@frodo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p3 (Debian) at smallmerchant.com X-archive-position: 93 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tupshin@tupshin.com Precedence: bulk X-list: linux-xfs Content-Length: 1767 Lines: 55 Nathan Scott wrote: >On Tue, Aug 19, 2003 at 12:34:00PM +0300, Erkki Seppala wrote: > > >>Growing filesystem twice after mount fails. Reproducing: >> >>1) mount /dev/store/media2 - 100G volume >>2) lvextend -L 200G /dev/store/media2 >>3) xfs_growfs -d /dev/store/media2 >> -> works ok >>4) lvextend -L 350G /dev/store/media2 >>5) xfs_growfs -d /dev/store/media2 >> -> says there is nothing to be done >> >>Unmounting and mounting the system will allow xfs_growfs to work >>again. >> >> >> > >This sounds like the device is not properly updating its size. >Can you cat /proc/partitions after each device size extension, >and check that it is the expected size. > > /proc/partitions only contains regular hard drive partitions. The problem is occuring on lvm partitions. Is there some equivalent check you would like me to make for lvm2? >xfs_growfs is issuing an ioctl querying the device size before >it tells the XFS kernel code what size to extend to - for some >reason it seems that your second growfs there is getting the >same size as before... if so, this would point to a problem in >the device driver and not XFS. > >cheers. > > I'd believe this. >Can you try the latest XFS 1.3-pre6 code and see if the problem >is resolved there? There was a growfs fix went in there in the >last few days. Make sure you start from a known not-corrupt fs >of course. Seth, I think that FAQ entry can be removed/updated >now to say the problem is resolved in 1.3. > As I mentioned, I'm using kernel 2.6.x where X is newer than test3. I'm not sure if you are referring to userland tools, or the kernel code. If you mean userland stuff, than I can try it out, but if you mean kernel code, I'm not aware of a patch against recent 2.6 kernels. -Tupshin From owner-linux-xfs@oss.sgi.com Tue Aug 19 16:42:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Aug 2003 16:42:27 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JNg5Fl004793 for ; Tue, 19 Aug 2003 16:42:14 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7JNwXnk020095 for ; Tue, 19 Aug 2003 18:58:36 -0500 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h7JNfHiU006242 for ; Wed, 20 Aug 2003 09:41:18 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h7JNfHbd006241 for linux-xfs@oss.sgi.com; Wed, 20 Aug 2003 09:41:17 +1000 Date: Wed, 20 Aug 2003 09:41:17 +1000 From: Nathan Scott Message-Id: <200308192341.h7JNfHbd006241@bruce.melbourne.sgi.com> Subject: TAKE - tweak dabuf fix X-archive-position: 94 X-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@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 374 Lines: 13 Tweak last dabuf fix, suggested by Steve, no longer uses bitfields but uchars instead and struct is the same size still. Date: Tue Aug 19 16:40:37 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/nathans/isms/devel The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:156269a linux/fs/xfs/xfs_da_btree.h - 1.55 From owner-linux-xfs@oss.sgi.com Wed Aug 20 00:21:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 20 Aug 2003 00:21:09 -0700 (PDT) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7K7L6oO022882 for ; Wed, 20 Aug 2003 00:21:06 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7K5M8Qa025004 for ; Tue, 19 Aug 2003 22:22:09 -0700 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h7K7KKWi002083 for ; Wed, 20 Aug 2003 17:20:20 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h7K7KKJx002082 for linux-xfs@oss.sgi.com; Wed, 20 Aug 2003 17:20:20 +1000 Date: Wed, 20 Aug 2003 17:20:20 +1000 From: Nathan Scott Message-Id: <200308200720.h7K7KKJx002082@bruce.melbourne.sgi.com> Subject: TAKE - unwritten extent fix X-archive-position: 96 X-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@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 390 Lines: 13 Fix a case where we could issue an unwritten extent buffer for IO without it being locked - an instant BUG trigger in the block layer. Date: Wed Aug 20 00:19:20 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/nathans/isms/devel The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:156304a linux/fs/xfs/linux/xfs_aops.c - 1.45 From owner-linux-xfs@oss.sgi.com Wed Aug 20 03:34:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 20 Aug 2003 03:34:22 -0700 (PDT) Received: from mail.redshift.com (mail.redshift.com [216.228.2.86]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KAYIoO001217 for ; Wed, 20 Aug 2003 03:34:19 -0700 Received: from redshift (216-228-19-21.dsl.redshift.com [216.228.19.21]) by mail.redshift.com (8.12.9/8.12.8) with SMTP id h7KAY99X013624 for ; Wed, 20 Aug 2003 03:34:09 -0700 Message-Id: <3.0.1.32.20030820033359.006c0fbc@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Wed, 20 Aug 2003 03:33:59 -0700 To: linux-xfs@oss.sgi.com From: ray@redshift.com Subject: SGI XFS ISO image for Redhat 9.0 v1.2.0 / v1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-archive-position: 97 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ray@redshift.com Precedence: bulk X-list: linux-xfs Content-Length: 248 Lines: 10 During the start of installation off the XFS redhat 9.0 ISO image, a comment is made that you will need "Redhat 8.0" CD's to accomplish the install. I believe this should read "Redhat 9.0" CD's. :) Just wanted to pass that along - thanks! Ray From owner-linux-xfs@oss.sgi.com Wed Aug 20 12:31:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 20 Aug 2003 12:32:05 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KJVooO004241 for ; Wed, 20 Aug 2003 12:31:51 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7KJVjq0027869 for ; Wed, 20 Aug 2003 12:31:45 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7KJUJGe8656289 for ; Wed, 20 Aug 2003 14:30:19 -0500 (CDT) Received: from sgi.com (chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7KJUJRn232395459 for ; Wed, 20 Aug 2003 14:30:19 -0500 (CDT) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h7KJUJ56004606 for ; Wed, 20 Aug 2003 14:30:19 -0500 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.8/8.12.8/Submit) id h7KJUELs004604 for linux-xfs@oss.sgi.com; Wed, 20 Aug 2003 14:30:14 -0500 Date: Wed, 20 Aug 2003 14:30:14 -0500 From: Russell Cattelan Message-Id: <200308201930.h7KJUELs004604@chuckle.americas.sgi.com> Subject: TAKE - Final bits for 1.3.0 X-archive-position: 98 X-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@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 843 Lines: 32 Fix a case where we could issue an unwritten extent buffer for IO without it being locked - an instant BUG trigger in the block layer Date: Wed Aug 20 10:39:24 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-r1.3 Author: nathans Merged by: cattelan Merged mods: xfs-linux:slinx:156304a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.3 Modid: 2.4.x-xfs-r1.3:slinx:156304a linux/fs/xfs/linux/xfs_aops.c - 1.43 - Merge of xfs-linux:slinx:156304a by cattelan. Subject: TAKE - Version string to 1.3.0 Date: Wed Aug 20 12:29:41 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-r1.3 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.3 Modid: 2.4.x-xfs-r1.3:slinx:156353a linux/fs/xfs/linux/xfs_version.h - 1.171 From owner-linux-xfs@oss.sgi.com Wed Aug 20 13:06:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 20 Aug 2003 13:07:00 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KK6joO005667 for ; Wed, 20 Aug 2003 13:06:46 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7KKNKnk010609 for ; Wed, 20 Aug 2003 15:23:20 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7KK6GGe8682373 for ; Wed, 20 Aug 2003 15:06:17 -0500 (CDT) Received: from sgi.com (chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7KK6GRn237717572 for ; Wed, 20 Aug 2003 15:06:16 -0500 (CDT) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h7KK6F56006009 for ; Wed, 20 Aug 2003 15:06:16 -0500 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.8/8.12.8/Submit) id h7KK6F9P006007 for linux-xfs@oss.sgi.com; Wed, 20 Aug 2003 15:06:15 -0500 Date: Wed, 20 Aug 2003 15:06:15 -0500 From: Russell Cattelan Message-Id: <200308202006.h7KK6F9P006007@chuckle.americas.sgi.com> Subject: TAKE 898862 - One last fix for 1.3.0 cmds mkfs can improperly generate an error when the data subvolume stripe unit is X-archive-position: 99 X-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@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1361 Lines: 46 larger than 256kb, which is larger than the maximum log stripe unit size. So, only set and check the log stripe unit on version 2 internal logs, and default the stripe unit size to 32kb if the data volume's stripe unit size is too big. Date: Wed Aug 20 12:45:04 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/xfs-cmds-r1.3 Author: overby Merged by: cattelan Merged mods: xfs-cmds:slinx:156103a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds-r1.3 Modid: xfs-cmds-r1.3:slinx:156103a xfsprogs/mkfs/xfs_mkfs.c - 1.49 - Merge of xfs-cmds:slinx:156103a by cattelan. Only set and check the log stripe unit on version 2 internal logs, and default the stripe unit size to 32kb if the data volume's stripe unit size is too big. Subject: TAKE - Bump xfsprogs version for Glens mkfs fix, fix a typo in one of the warning messages Date: Wed Aug 20 12:46:53 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/xfs-cmds-r1.3 Author: nathans Merged by: cattelan Merged mods: xfs-cmds:slinx:156132a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds-r1.3 Modid: xfs-cmds-r1.3:slinx:156132a xfsprogs/VERSION - 1.85 xfsprogs/doc/CHANGES - 1.123 xfsprogs/mkfs/xfs_mkfs.c - 1.50 xfsprogs/debian/changelog - 1.78 - Merge of xfs-cmds:slinx:156132a by cattelan. From owner-linux-xfs@oss.sgi.com Wed Aug 20 17:24:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 20 Aug 2003 17:24:17 -0700 (PDT) Received: from adsl-63-202-77-221.dsl.snfc21.pacbell.net (adsl-67-114-19-186.dsl.pltn13.pacbell.net [67.114.19.186]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7L0OBoO020067 for ; Wed, 20 Aug 2003 17:24:12 -0700 Received: (qmail 16266 invoked from network); 20 Aug 2003 19:15:08 -0000 Received: from unknown (HELO tupshin.com) (172.16.1.50) by adsl-67-114-19-185.dsl.pltn13.pacbell.net with SMTP; 20 Aug 2003 19:15:08 -0000 Message-ID: <3F441120.2020204@tupshin.com> Date: Wed, 20 Aug 2003 17:24:00 -0700 From: Tupshin Harper User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030618 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com Subject: Re: Workaroundable bug with 2.6.0-test3 xfs & xfs_growfs References: <20030819093400.GA22198@modeemi.fi> <20030819230755.GH743@frodo> <3F42B027.40700@tupshin.com> <1061407741.7725.136.camel@jen.americas.sgi.com> <20030820235946.GA1016@frodo> In-Reply-To: <20030820235946.GA1016@frodo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 100 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tupshin@tupshin.com Precedence: bulk X-list: linux-xfs Content-Length: 1258 Lines: 35 Nathan Scott wrote: >On Wed, Aug 20, 2003 at 02:29:01PM -0500, Steve Lord wrote: > > >>I think you have to ask device mapper folks how to tell how big >>one of their volumes is from user space. >> >> > >I've attached a little program which can be used to dump out >what the device driver reports its size as. Just give it the >lvm device as its first argument. > Bingo...log appears below: I extended an lvm partition, and the size reported was not updated until the partition was unmounted. How should I proceed from here? Would you like me to report it to somebody in charge of the dev-mapper stuff? I'm skipping the kernel patch you attached for the moment since I'm not running into that bug. Thanks much. -Tupshin bastard:/home/tupshin# ./lvm_size /dev/lvm_group_2/debmir size = 11811160064 bytes, sector size = 512 bytes bastard:/home/tupshin# lvextend -L +100M /dev/lvm_group_2/debmir Extending logical volume debmir to 11.10 GB Logical volume debmir successfully resized bastard:/home/tupshin# ./lvm_size /dev/lvm_group_2/debmir size = 11811160064 bytes, sector size = 512 bytes bastard:/home/tupshin# umount /data/debmir bastard:/home/tupshin# ./lvm_size /dev/lvm_group_2/debmir size = 11916017664 bytes, sector size = 512 bytes From owner-linux-xfs@oss.sgi.com Wed Aug 20 17:40:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 20 Aug 2003 17:40:53 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7L0ekoO021040 for ; Wed, 20 Aug 2003 17:40:46 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7L0vKnk012871 for ; Wed, 20 Aug 2003 19:57:21 -0500 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 KAA14303; Thu, 21 Aug 2003 10:40:37 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7L0eamY042154; Thu, 21 Aug 2003 10:40:36 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7L0dAZQ001282; Thu, 21 Aug 2003 10:39:10 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7L0dA97001280; Thu, 21 Aug 2003 10:39:10 +1000 Date: Thu, 21 Aug 2003 10:39:10 +1000 From: Nathan Scott To: Tupshin Harper Cc: linux-xfs@oss.sgi.com Subject: Re: Workaroundable bug with 2.6.0-test3 xfs & xfs_growfs Message-ID: <20030821003910.GB1016@frodo> References: <20030819093400.GA22198@modeemi.fi> <20030819230755.GH743@frodo> <3F42B027.40700@tupshin.com> <1061407741.7725.136.camel@jen.americas.sgi.com> <20030820235946.GA1016@frodo> <3F441120.2020204@tupshin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F441120.2020204@tupshin.com> User-Agent: Mutt/1.5.3i X-archive-position: 101 X-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: 1473 Lines: 45 On Wed, Aug 20, 2003 at 05:24:00PM -0700, Tupshin Harper wrote: > Nathan Scott wrote: > > >On Wed, Aug 20, 2003 at 02:29:01PM -0500, Steve Lord wrote: > > > > > >>I think you have to ask device mapper folks how to tell how big > >>one of their volumes is from user space. > >> > >> > > > >I've attached a little program which can be used to dump out > >what the device driver reports its size as. Just give it the > >lvm device as its first argument. > > > Bingo...log appears below: > I extended an lvm partition, and the size reported was not updated until > the partition was unmounted. How should I proceed from here? Would you > like me to report it to somebody in charge of the dev-mapper stuff? I'm Yes, lvm-devel@sistina.com would be the right place I think. thanks. > skipping the kernel patch you attached for the moment since I'm not > running into that bug. Thanks much. > > -Tupshin > > bastard:/home/tupshin# ./lvm_size /dev/lvm_group_2/debmir > size = 11811160064 bytes, sector size = 512 bytes > bastard:/home/tupshin# lvextend -L +100M /dev/lvm_group_2/debmir > Extending logical volume debmir to 11.10 GB > Logical volume debmir successfully resized > bastard:/home/tupshin# ./lvm_size /dev/lvm_group_2/debmir > size = 11811160064 bytes, sector size = 512 bytes > bastard:/home/tupshin# umount /data/debmir > bastard:/home/tupshin# ./lvm_size /dev/lvm_group_2/debmir > size = 11916017664 bytes, sector size = 512 bytes > > -- Nathan From owner-linux-xfs@oss.sgi.com Wed Aug 20 18:59:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 20 Aug 2003 18:59:27 -0700 (PDT) Received: from orngca-mls02.socal.rr.com (orngca-mls02.socal.rr.com [66.75.160.17]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7L1xEoO024365 for ; Wed, 20 Aug 2003 18:59:14 -0700 Received: from najena (cpe-66-74-75-215.socal.rr.com [66.74.75.215]) by orngca-mls02.socal.rr.com (8.11.4/8.11.3) with ESMTP id h7L1t8D20419 for ; Wed, 20 Aug 2003 18:55:08 -0700 (PDT) Subject: kernel reinstall help From: Jamie Krasnoo To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1061431152.9045.14.camel@najena> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 20 Aug 2003 18:59:13 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 102 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: krasnooj@socal.rr.com Precedence: bulk X-list: linux-xfs Content-Length: 981 Lines: 19 Hi all. I've been using XFS for a while now without a problem. However I now have a problem and I've caused it. Apparently I didn't pay attention to the fact that a RedHat errata kernel rpm was for 7.3 and not 9.0. The rpm in question was kernel-2.4.20-18.7SGI_XFS_1.2.0.i686.rpm. I installed it via rpm -Uvh which replaced the previous kernel completely and there isn't a trace of it. Now the kernel wont boot up and I get the error saying that there isn't an init found and to pass it through the kernel arguments. I'd reinstall it but there are programs that I worked hard to get them running on RedHat 9.0 and I would rather see if I can either get this kernel running or somehow get the old kernel re-installed. I've managed to boot via the linux rescue and I can seem to get rpm working. It's mounting all the partitions correctly to change the kernel that I have no experience with and really don't want to screw anything up. Any help would be appreciated. Thanks, Jamie From owner-linux-xfs@oss.sgi.com Wed Aug 20 19:07:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 20 Aug 2003 19:07:45 -0700 (PDT) Received: from lists.vasoftware.com (mail@lists.vasoftware.com [198.186.202.171]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7L27MoO025423 for ; Wed, 20 Aug 2003 19:07:23 -0700 Received: from adsl-64-175-248-6.dsl.sntc01.pacbell.net ([64.175.248.6]:63822 helo=linux-sxs.org) by lists.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.20 #1 (Debian)) id 19perA-0002Xt-Hq by authid with fixed_plain; Wed, 20 Aug 2003 19:07:20 -0700 Message-ID: <3F442946.4050603@linux-sxs.org> Date: Wed, 20 Aug 2003 19:07:02 -0700 From: "Net Llama!" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030625 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Krasnoo CC: linux-xfs@oss.sgi.com Subject: Re: kernel reinstall help References: <1061431152.9045.14.camel@najena> In-Reply-To: <1061431152.9045.14.camel@najena> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: lists.vasoftware.com 19perA-0002Xt-Hq 7bcd9d06eb84f1d58abd04cfedf55f22 X-Spam-Score: -1.1 (-) X-archive-position: 103 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1466 Lines: 32 On 08/20/03 18:59, Jamie Krasnoo wrote: > Hi all. I've been using XFS for a while now without a problem. However I > now have a problem and I've caused it. Apparently I didn't pay attention > to the fact that a RedHat errata kernel rpm was for 7.3 and not 9.0. The > rpm in question was kernel-2.4.20-18.7SGI_XFS_1.2.0.i686.rpm. I > installed it via rpm -Uvh which replaced the previous kernel completely > and there isn't a trace of it. Now the kernel wont boot up and I get the > error saying that there isn't an init found and to pass it through the > kernel arguments. I'd reinstall it but there are programs that I worked > hard to get them running on RedHat 9.0 and I would rather see if I can > either get this kernel running or somehow get the old kernel > re-installed. I've managed to boot via the linux rescue and I can seem > to get rpm working. It's mounting all the partitions correctly to change > the kernel that I have no experience with and really don't want to screw > anything up. Any help would be appreciated. chroot rpm -ivh kernel-2.4.20-18.7SGI_XFS_1.2.0.i686.rpm. edit /etc/lilo.conf to reference the new kernel /sbin/lilo exit reboot -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 7:05pm up 5 days, 7:33, 1 user, load average: 0.16, 0.21, 0.74 From owner-linux-xfs@oss.sgi.com Wed Aug 20 20:18:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 20 Aug 2003 20:19:11 -0700 (PDT) Received: from orngca-mls01.socal.rr.com (orngca-mls01.socal.rr.com [66.75.160.16]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7L3IuoO028060 for ; Wed, 20 Aug 2003 20:18:56 -0700 Received: from najena (cpe-66-74-75-215.socal.rr.com [66.74.75.215]) by orngca-mls01.socal.rr.com (8.11.4/8.11.3) with ESMTP id h7L3Elx28835; Wed, 20 Aug 2003 20:14:47 -0700 (PDT) Subject: Re: kernel reinstall help From: Jamie Krasnoo To: Net Llama! Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F442946.4050603@linux-sxs.org> References: <1061431152.9045.14.camel@najena> <3F442946.4050603@linux-sxs.org> Content-Type: text/plain Message-Id: <1061435887.9045.20.camel@najena> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 20 Aug 2003 20:18:08 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 104 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: krasnooj@socal.rr.com Precedence: bulk X-list: linux-xfs Content-Length: 1680 Lines: 38 On Wed, 2003-08-20 at 19:07, Net Llama! wrote: > On 08/20/03 18:59, Jamie Krasnoo wrote: > > > Hi all. I've been using XFS for a while now without a problem. However I > > now have a problem and I've caused it. Apparently I didn't pay attention > > to the fact that a RedHat errata kernel rpm was for 7.3 and not 9.0. The > > rpm in question was kernel-2.4.20-18.7SGI_XFS_1.2.0.i686.rpm. I > > installed it via rpm -Uvh which replaced the previous kernel completely > > and there isn't a trace of it. Now the kernel wont boot up and I get the > > error saying that there isn't an init found and to pass it through the > > kernel arguments. I'd reinstall it but there are programs that I worked > > hard to get them running on RedHat 9.0 and I would rather see if I can > > either get this kernel running or somehow get the old kernel > > re-installed. I've managed to boot via the linux rescue and I can seem > > to get rpm working. It's mounting all the partitions correctly to change > > the kernel that I have no experience with and really don't want to screw > > anything up. Any help would be appreciated. > > chroot > rpm -ivh kernel-2.4.20-18.7SGI_XFS_1.2.0.i686.rpm. > edit /etc/lilo.conf to reference the new kernel > /sbin/lilo > exit > reboot > I fixed it. I did some more searching around the archives and found a post by Cliff Wells explaining how to do it. Took me some time to rebuild the system image but I did it. I had to force the old kernel to install but it went in and all is fine. For some reason I found that xfsprogs wasn't installed. Might be a bug in the 9.0 install disk. Thanks llama and Cliff for the help. Jamie From owner-linux-xfs@oss.sgi.com Thu Aug 21 00:28:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 00:29:20 -0700 (PDT) Received: from orngca-mls01.socal.rr.com (orngca-mls01.socal.rr.com [66.75.160.16] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7L7SwoO004657 for ; Thu, 21 Aug 2003 00:28:58 -0700 Received: from najena (cpe-66-74-75-215.socal.rr.com [66.74.75.215]) by orngca-mls01.socal.rr.com (8.11.4/8.11.3) with ESMTP id h7L7PFx06933 for ; Thu, 21 Aug 2003 00:25:15 -0700 (PDT) Subject: Which patch From: Jamie Krasnoo To: xfs Content-Type: text/plain Message-Id: <1061450917.9506.1.camel@najena> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 21 Aug 2003 00:28:37 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 105 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: krasnooj@socal.rr.com Precedence: bulk X-list: linux-xfs Content-Length: 205 Lines: 8 Looking at the list of patches to download for the 2.4.20 kernel I see a few of them are available. I'm not sure which one to use. Do I use rc3 or the one with the most recent date on it? Thanks, Jamie From owner-linux-xfs@oss.sgi.com Thu Aug 21 02:26:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 02:27:17 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h7L9QroO011622 for ; Thu, 21 Aug 2003 02:26:54 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7L9QreU011621 for linux-xfs@oss.sgi.com; Thu, 21 Aug 2003 02:26:53 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h7L9QnoQ011605 for ; Thu, 21 Aug 2003 02:26:49 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7L99u90009595; Thu, 21 Aug 2003 02:09:56 -0700 Date: Thu, 21 Aug 2003 02:09:56 -0700 Message-Id: <200308210909.h7L99u90009595@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 206] XFS filesysem corruption while umounting sw raid 1 X-Bugzilla-Reason: AssignedTo X-archive-position: 106 X-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: 687 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=206 tsr@atom.physik.tu-berlin.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|1.1.x |Current ------- Additional Comments From tsr@atom.physik.tu-berlin.de 2003-21-08 02:09 PDT ------- I can still reproduce the bug with yesterdays 2.4 CVS version. It's really a pain not being able to reboot/shutdown the machine cleanly, alway relying on xfs_repair to hopefully run smoothly. ------- 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 Aug 21 05:29:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 05:30:09 -0700 (PDT) Received: from stefan.roehri.ch (root@p50838D3B.dip0.t-ipconnect.de [80.131.141.59]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LCTloO022011 for ; Thu, 21 Aug 2003 05:29:49 -0700 Received: from stefan.roehri.ch (sr@localhost [127.0.0.1]) by stefan.roehri.ch (8.12.9/8.12.9/Debian-3) with ESMTP id h7LCTefW002037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Aug 2003 14:29:40 +0200 Received: (from sr@localhost) by stefan.roehri.ch (8.12.9/8.12.9/Debian-3) id h7LCTdLK002035; Thu, 21 Aug 2003 14:29:39 +0200 Date: Thu, 21 Aug 2003 14:29:39 +0200 From: Stefan Roehrich To: linux-xfs@oss.sgi.com Cc: Tobias Schill Subject: Processes stuck in D state (leading to extremely high load) Message-ID: <20030821122939.GB1922@stefan.roehri.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.5.4i X-MIME-Autoconverted: from 8bit to quoted-printable by stefan.roehri.ch id h7LCTefW002037 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7LCTooO022012 X-archive-position: 107 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stefan@roehri.ch Precedence: bulk X-list: linux-xfs Content-Length: 1758 Lines: 47 Hi, we have a "Processes stuck in D state" problem here for a long time. It occurrs with different kernel/xfs versions (smp always enabled in kernel): Linux Kernel 2.4.21-xfs 1.3.0-pre4 (and megaraid2-patch) And also with these obsolete ones: Linux Kernel 2.4.19-xfs 1.2 (and megaraid-patch) Linux Kernel 2.4.20-xfs 1.2 (and megaraid-patch) But not with this one: Linux kernel 2.4.21-rc1 with xfs as obtained from XFS CVS on 2003-05-02 (megaraid2-patch applied) - We are using this kernel currently, as we have no other choice. Back to Linux Kernel 2.4.21-xfs 1.3.0-pre4 (and megaraid2-patch): Many processes accessing the same XFS filesystem (the one for samba in the example below) are stuck in D state.. toschi 3827 0.1 0.1 6376 3304 ? D 16:10 0:00 /usr/local/samba/bin/smbd -D -p 445 As time goes by (depending on user activity), load increases to really high values (90 or so) as more and more procceses accessing the not reacting filesystem get stuck in D state. Finally the system does not react anymore. This is not depending on samba. It also happens with any other application (i. e. apache) accessing an XFS mounted filesystem. It seems to be filesystem specific, i.e. only processes on one XFS filesystem are "running" in D state, not on another mounted XFS filesystem. It is a production system and it takes an averge of about a week after a reboot until this happens, but isn't exactly reproducable. The machines we have here are Dell Poweredge 2600 Dual Xeon. The XFS related behaviour is not depending on single or dual CPU usage nor on hyperthreading switched on/off. Stefan -- Stefan Röhrich stefan@roehri.ch, sr@linux.de http://www.roehri.ch/~sr/ From owner-linux-xfs@oss.sgi.com Thu Aug 21 05:45:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 05:45:19 -0700 (PDT) Received: from smtp3.cern.ch (smtp3.cern.ch [137.138.131.164]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LCj1oO022841 for ; Thu, 21 Aug 2003 05:45:09 -0700 Received: from chihiro.cern.ch (pcitadc13.cern.ch [137.138.34.18]) by smtp3.cern.ch (8.12.1/8.12.1) with ESMTP id h7LCisiP024863 for ; Thu, 21 Aug 2003 14:44:55 +0200 (MET DST) X-Authentication-Warning: smtp3.cern.ch: Host pcitadc13.cern.ch [137.138.34.18] claimed to be chihiro.cern.ch Received: by chihiro.cern.ch (Postfix, from userid 32266) id 45E981B8BD; Thu, 21 Aug 2003 14:44:55 +0200 (CEST) Date: Thu, 21 Aug 2003 14:44:54 +0200 From: KELEMEN Peter To: linux-xfs@oss.sgi.com Subject: xfs_xlate_dinode_core() oops w/2.4.21 on P166 MMX Message-ID: <20030821124454.GI734@chihiro.cern.ch> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Organization: CERN European Laboratory for Particle Physics, Switzerland X-GPG-KeyID: 1024D/EE4C26E8 2000-03-20 X-GPG-Fingerprint: D402 4AF3 7488 165B CC34 4147 7F0C D922 EE4C 26E8 X-PGP-KeyID: 1024/45F83E45 1998/04/04 X-PGP-Fingerprint: 26 87 63 4B 07 28 1F AD 6D AA B5 8A D6 03 0F BF X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en User-Agent: Mutt/1.5.4i X-MIME-Autoconverted: from 8bit to quoted-printable by smtp3.cern.ch id h7LCisiP024863 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7LCjAoO022854 X-archive-position: 108 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Peter.Kelemen@cern.ch Precedence: bulk X-list: linux-xfs Content-Length: 3461 Lines: 85 Hello, Vanilla 2.4.21 + XFS split patches oopsed the other day while haveing 168 FD open in an application writing small chunks of data on a P166 MMX. Decoded oops follows. Peter ------------------------------------------------------------------------------- ksymoops 2.4.8 on i586 2.4.21-xfs. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.21-xfs/ (default) -m /boot/System.map-2.4.21-xfs (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Reading Oops report from the terminal invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010297 eax: ffffffff ebx: 00000000 ecx: 00000000 edx: c167da16 esi: c167da04 edi: c10e1c00 ebp: ffffffff esp: c10edf00 ds: 0018 es: 0018 ss: 0018 Process kupdated (pid: 6, stackpage=c10ed000) Stack: 00000000 c115b4a0 00e03900 00000000 00000000 c20874a8 0000000f c167da00 c0190301 c167da00 c20875b4 ffffffff 00000000 c10e1c00 c1869c1c c1869c1c 00000008 c20874a8 00000000 c018fe08 c20874a8 c115b4a0 c01a9f56 c10e1c00 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8e 7b 03 00 00 80 7c 24 13 01 0f 84 63 03 00 00 8b 46 30 0f >>EIP; c018db80 <===== >>edx; c167da16 <_end+13b1136/353c780> >>esi; c167da04 <_end+13b1124/353c780> >>edi; c10e1c00 <_end+e15320/353c780> >>esp; c10edf00 <_end+e21620/353c780> Trace; c0190301 Trace; c018fe08 Trace; c01a9f56 Trace; c01a9fc7 Trace; c01b6160 Trace; c01b6189 Trace; c0142b20 <__sync_one+130/137> Trace; c0141acb Trace; c01331e5 Trace; c013346f Trace; c0105000 <_stext+0/0> Trace; c0105673 Trace; c01333a0 Code; c018db80 00000000 <_EIP>: Code; c018db80 <===== 0: 8e 7b 03 movl 0x3(%ebx),%? <===== Code; c018db83 3: 00 00 add %al,(%eax) Code; c018db85 5: 80 7c 24 13 01 cmpb $0x1,0x13(%esp,1) Code; c018db8a a: 0f 84 63 03 00 00 je 373 <_EIP+0x373> Code; c018db90 10: 8b 46 30 mov 0x30(%esi),%eax Code; c018db93 13: 0f 00 00 sldtl (%eax) 1 warning issued. Results may not be reliable. -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' From owner-linux-xfs@oss.sgi.com Thu Aug 21 06:53:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 06:53:26 -0700 (PDT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LDrKoO004701 for ; Thu, 21 Aug 2003 06:53:22 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 8CB35EB4A04 for ; Thu, 21 Aug 2003 21:53:10 +0800 (PHT) Received: from lawin.alabang.leathercollection.ph (lawin.alabang.leathercollection.ph [192.168.0.2]) by gusi.leathercollection.ph (Postfix) with ESMTP id 5BC89EB4A02 for ; Thu, 21 Aug 2003 21:53:01 +0800 (PHT) Received: by lawin.alabang.leathercollection.ph (Postfix, from userid 1000) id F3D5F1A4029; Thu, 21 Aug 2003 21:52:59 +0800 (PHT) Date: Thu, 21 Aug 2003 21:52:59 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: Re: Processes stuck in D state (leading to extremely high load) Message-ID: <20030821135259.GC29202@leathercollection.ph> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20030821122939.GB1922@stefan.roehri.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030821122939.GB1922@stefan.roehri.ch> 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-archive-position: 109 X-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: 1611 Lines: 38 On Thu, Aug 21, 2003 at 02:29:39PM +0200, Stefan Roehrich wrote: > we have a "Processes stuck in D state" problem here for a long time. > It occurrs with different kernel/xfs versions (smp always enabled in > kernel): > > ... > > As time goes by (depending on user activity), load increases to really > high values (90 or so) as more and more procceses accessing the not > reacting filesystem get stuck in D state. Finally the system does not > react anymore. > > This is not depending on samba. It also happens with any other > application (i. e. apache) accessing an XFS mounted filesystem. It > seems to be filesystem specific, i.e. only processes on one XFS > filesystem are "running" in D state, not on another mounted XFS > filesystem. > > It is a production system and it takes an averge of about a week after > a reboot until this happens, but isn't exactly reproducable. I used to have that problem as well, and was very frustrated because I just couldn't nail the cause. I haven't been seing the problem, though, and it seems to have all stopped when I changed my SDRAM which MemTest86 found to have some very minor hard-to-find errors. Perhaps you could give this a shot? It'll need some time to finish all the passes, though, and the machine will have to be offline during the tests. I know that's not welcome news for a production box. Good luck. --> Jijo -- 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 Thu Aug 21 09:09:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 09:09:53 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LG9boO009809 for ; Thu, 21 Aug 2003 09:09:38 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7LGQFnk018197 for ; Thu, 21 Aug 2003 11:26:15 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7LG9VGe8868608 for ; Thu, 21 Aug 2003 11:09:31 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7LG9VRn238359449 for ; Thu, 21 Aug 2003 11:09:31 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h7LG9VO02469; Thu, 21 Aug 2003 11:09:31 -0500 Subject: The X in XFS From: Steve Lord To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1061482171.1797.65.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 21 Aug 2003 11:09:31 -0500 X-archive-position: 110 X-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: 701 Lines: 21 Just in case you were wondering what X stood for in XFS - some folks out there seem to be putting the X in the middle of words recently. The X does not stand for anything except X, it is not eXtent, or eXtended or any other word. Originally the project was internally refered to as xFS, presumably until marketing came up with a letter or name which was deemed acceptable. After a while the x just stuck without having a meaning assigned to it, and it was capitalized. Think of it as a little like the G in GNU, the X in XFS stands for XFS ;-) Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Aug 21 10:05:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 10:05:22 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LH5IoO012054 for ; Thu, 21 Aug 2003 10:05:18 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7LH5Cq0002626 for ; Thu, 21 Aug 2003 10:05:12 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7LH5CGe8898541 for ; Thu, 21 Aug 2003 12:05:12 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7LH5CRn239584039 for ; Thu, 21 Aug 2003 12:05:12 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h7LH1qSm029346 for ; Thu, 21 Aug 2003 12:01:52 -0500 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id h7LH1qR1029344 for linux-xfs@oss.sgi.com; Thu, 21 Aug 2003 12:01:52 -0500 Date: Thu, 21 Aug 2003 12:01:52 -0500 From: Eric Sandeen Message-Id: <200308211701.h7LH1qR1029344@penguin.americas.sgi.com> Subject: TAKE - Work around gcc 2.96 bug in _lsn_cmp X-archive-position: 111 X-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@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 458 Lines: 18 Work around gcc 2.96 bug in _lsn_cmp. Date: Thu Aug 21 10:04:22 PDT 2003 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-kern-oss Author: wessmith Merged by: sandeen Merged mods: 2.4.x-xfs-kern:slinx:156280a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-linux Modid: xfs-linux:slinx:156280a xfs_log.h - 1.70 - Merge of 2.4.x-xfs-kern:slinx:156280a by sandeen. Work around gcc 2.96 bug in _lsn_cmp. From owner-linux-xfs@oss.sgi.com Thu Aug 21 11:43:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 11:43:52 -0700 (PDT) Received: from smtp3.cern.ch (smtp3.cern.ch [137.138.131.164]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LIhZoO015871 for ; Thu, 21 Aug 2003 11:43:37 -0700 Received: from chihiro.cern.ch (pcitadc13.cern.ch [137.138.34.18]) by smtp3.cern.ch (8.12.1/8.12.1) with ESMTP id h7LIhSiP002036 for ; Thu, 21 Aug 2003 20:43:28 +0200 (MET DST) X-Authentication-Warning: smtp3.cern.ch: Host pcitadc13.cern.ch [137.138.34.18] claimed to be chihiro.cern.ch Received: by chihiro.cern.ch (Postfix, from userid 32266) id 3C9501B8BD; Thu, 21 Aug 2003 20:43:29 +0200 (CEST) Date: Thu, 21 Aug 2003 20:43:29 +0200 From: KELEMEN Peter To: linux-xfs@oss.sgi.com Subject: Re: The X in XFS Message-ID: <20030821184329.GA11855@chihiro.cern.ch> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1061482171.1797.65.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1061482171.1797.65.camel@jen.americas.sgi.com> Organization: CERN European Laboratory for Particle Physics, Switzerland X-GPG-KeyID: 1024D/EE4C26E8 2000-03-20 X-GPG-Fingerprint: D402 4AF3 7488 165B CC34 4147 7F0C D922 EE4C 26E8 X-PGP-KeyID: 1024/45F83E45 1998/04/04 X-PGP-Fingerprint: 26 87 63 4B 07 28 1F AD 6D AA B5 8A D6 03 0F BF X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en User-Agent: Mutt/1.5.4i X-MIME-Autoconverted: from 8bit to quoted-printable by smtp3.cern.ch id h7LIhSiP002036 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7LIhboO015874 X-archive-position: 112 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Peter.Kelemen@cern.ch Precedence: bulk X-list: linux-xfs Content-Length: 898 Lines: 22 * Steve Lord (lord@sgi.com) [20030821 11:09]: > Originally the project was internally refered to as xFS, > presumably until marketing came up with a letter or name which > was deemed acceptable. After a while the x just stuck without > having a meaning assigned to it, and it was capitalized. It should be noted that there is a Serverless Network File System from Berkeley that is precisely called "xFS", as you can see at http://now.cs.berkeley.edu/Xfs/xfs.html . Also, there are other products named "XFS", for example a popular NFS client for DOS. http://www.tux.org/pub/distributions/SuSE/i386/8.2/dosutils/xfs186/xfs.txt Of course, there is only one true XFS! :-) Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' From owner-linux-xfs@oss.sgi.com Thu Aug 21 12:32:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 12:32:16 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LJWAoO018526 for ; Thu, 21 Aug 2003 12:32:12 -0700 Received: (qmail 11200 invoked from network); 21 Aug 2003 19:32:08 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 21 Aug 2003 19:32:07 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id AA151EC5E0; Fri, 22 Aug 2003 05:32:06 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 89933140082; Fri, 22 Aug 2003 05:32:06 +1000 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Stefan Roehrich Cc: linux-xfs@oss.sgi.com, Tobias Schill Subject: Re: Processes stuck in D state (leading to extremely high load) In-reply-to: Your message of "Thu, 21 Aug 2003 14:29:39 +0200." <20030821122939.GB1922@stefan.roehri.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Aug 2003 05:32:05 +1000 Message-ID: <10520.1061494325@ocs3.intra.ocs.com.au> X-archive-position: 113 X-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: 1695 Lines: 46 On Thu, 21 Aug 2003 14:29:39 +0200, Stefan Roehrich wrote: >we have a "Processes stuck in D state" problem here for a long time. >toschi 3827 0.1 0.1 6376 3304 ? D 16:10 0:00 >/usr/local/samba/bin/smbd -D -p 445 > >As time goes by (depending on user activity), load increases to really >high values (90 or so) as more and more procceses accessing the not >reacting filesystem get stuck in D state. The load average is misleading, for historical reasons D state counts as load even though the code is hung. We need a kdb backtrace of the hung processes as early as possible when this problem starts to occur. Build the kernel with CONFIG_KDB=y CONFIG_KDB_MODULES=y CONFIG_KDB_OFF=n CONFIG_KDB_CONTINUE_CATASTROPHIC=0 [only in latest XFS trees] As soon as you spot the problem, break into kdb. On the PC keyboard use the Pause key. On a serial console, use control-A. Enter these commands set LINES 10000 set BTAPROMPT 0 dmesg 200 set LOGGING 1 ps bta RD go That will get a backtrace of all processes in the R and D states. After typing go, use dmesg to get the lines from the log file, send the kdb output and the preceding 200 lines to linux-xfs@oss.sgi.com. Since the dmesg buffer has a limited size, it is very important that the trace be taken as early as possible, too many processes in D state will overflow the dmesg bufer and the trace will be incomplete. If you have a serial console for this server, skip 'set LOGGING 1', capture all the kdb output on the serial console and send the serial console output to linux-xfs. Capturing data via the serial console does not have to worry about dmesg buffer overflow or incomplete traces. From owner-linux-xfs@oss.sgi.com Thu Aug 21 12:44:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 12:44:58 -0700 (PDT) Received: from zero.aec.at (Fogarty.Weffing@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LJihoO019405 for ; Thu, 21 Aug 2003 12:44:45 -0700 Received: from fred.muc.de (Alexander.Poke@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id h7LJiTm28091 for ; Thu, 21 Aug 2003 21:44:29 +0200 Received: by fred.muc.de (Postfix on SuSE Linux 7.3 (i386), from userid 500) id E4C7B5BBBE; Thu, 21 Aug 2003 21:44:32 +0200 (CEST) Date: Thu, 21 Aug 2003 21:44:32 +0200 From: Andi Kleen To: linux-xfs@oss.sgi.com Subject: bad log entries after remount with XFS over MD in 2.6 Message-ID: <20030821194432.GA12755@averell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 114 X-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@muc.de Precedence: bulk X-list: linux-xfs Content-Length: 52682 Lines: 1006 I have an XFS over a MD-0 (RAID-0) device stripped over two SCSI disks. The problem is that after a reboot the mount often fails with "bad clientid". This happens both when the file system was cleanly unmounted (even explicitely before shutdown) or when the machine crashed. I can remount again when I run xfs_repair -L first, but that always takes a long time. Also it tends to find some old files and reconnect them to lost+found. The log dump starts with an umount record, but XFS seems to read beyond that and find bogus log entries and then fail on them. Why does it not stop on the first? xfs_logprint gives this output on a fs in a non mounting state. xfs_logprint: data device: 0x900 log device: 0x900 daddr: 41943104 length: 10240 cycle: 1 version: 1 lsn: 1,0 tail_lsn: 1,0 length of Log Record: 20 prev offset: -1 num ops: 1 uuid: f272d169-808f-4627-9fa9-873b504e76b5 format: little endian linux ---------------------------------------------------------------------------- Oper (0): tid: b0c0d0d0 len: 8 clientid: LOG flags: UNMOUNT Unmount filesystem ============================================================================ cycle: 1 version: 1 lsn: 1,2 tail_lsn: 1,2 length of Log Record: 18088 prev offset: 0 num ops: 180 uuid: f272d169-808f-4627-9fa9-873b504e76b5 format: little endian linux ---------------------------------------------------------------------------- Oper (0): tid: f5af3024 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (1): tid: f5af3024 len: 16 clientid: TRANS flags: none TRAN: type: CREATE tid: 0 num_items: 6 ---------------------------------------------------------------------------- Oper (2): tid: f5af3024 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x37a3dbe flags: 0x1 dsize: 0 blkno: 29171408 len: 16 boff: 7680 Oper (3): tid: f5af3024 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100600 version 1 format 2 nlink 1 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f4519b3 ctime 0x3f4519b3 size 0x0 nblocks 0x0 extsize 0x0 nextents 0x0 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x1 ---------------------------------------------------------------------------- Oper (4): tid: f5af3024 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x22f470a flags: 0x1 dsize: 0 blkno: 18326400 len: 16 boff: 2560 Oper (5): tid: f5af3024 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 040755 version 1 format 2 nlink 22 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f4519b3 ctime 0x3f4519b3 size 0x1000 nblocks 0x1 extsize 0x0 nextents 0x1 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x6 ---------------------------------------------------------------------------- Oper (6): tid: f5af3024 len: 28 clientid: TRANS flags: none BUF: #regs: 4 start blkno: 18480912 (0x119ff10) len: 8 bmap size: 2 Oper (7): tid: f5af3024 len: 128 clientid: TRANS flags: none BUF DATA Oper (8): tid: f5af3024 len: 256 clientid: TRANS flags: none BUF DATA Oper (9): tid: f5af3024 len: 512 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (10): tid: f5af3024 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 0 (0x0) len: 1 bmap size: 1 Oper (11): tid: f5af3024 len: 128 clientid: TRANS flags: none SUPER BLOCK Buffer: icount: 1476864 ifree: 3365 fdblks: 1834921 frext: 0 ---------------------------------------------------------------------------- Oper (12): tid: f5af3024 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 27262978 (0x1a00002) len: 1 bmap size: 1 Oper (13): tid: f5af3024 len: 128 clientid: TRANS flags: none AGI Buffer: XAGI ver: 1 seq#: 13 len: 262144 cnt: 39616 root: 1767 level: 2 free#: 0x3c newino: 0x80 bucket[0 - 3]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[4 - 7]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[8 - 11]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[12 - 15]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[16 - 19]: 0xffffffff ---------------------------------------------------------------------------- Oper (14): tid: f5af3024 len: 28 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 27281592 (0x1a048b8) len: 8 bmap size: 2 Oper (15): tid: f5af3024 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (16): tid: f5af3024 len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (17): tid: f5af3048 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (18): tid: f5af3048 len: 16 clientid: TRANS flags: none TRAN: type: CREATE tid: 0 num_items: 6 ---------------------------------------------------------------------------- Oper (19): tid: f5af3048 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 27262978 (0x1a00002) len: 1 bmap size: 1 Oper (20): tid: f5af3048 len: 128 clientid: TRANS flags: none AGI Buffer: XAGI ver: 1 seq#: 13 len: 262144 cnt: 39616 root: 1767 level: 2 free#: 0x3b newino: 0x80 bucket[0 - 3]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[4 - 7]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[8 - 11]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[12 - 15]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[16 - 19]: 0xffffffff ---------------------------------------------------------------------------- Oper (21): tid: f5af3048 len: 28 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 27281592 (0x1a048b8) len: 8 bmap size: 2 Oper (22): tid: f5af3048 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (23): tid: f5af3048 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x37a4704 flags: 0x1 dsize: 0 blkno: 29172608 len: 16 boff: 1024 Oper (24): tid: f5af3048 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100600 version 1 format 2 nlink 1 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f4519b3 ctime 0x3f4519b3 size 0x0 nblocks 0x0 extsize 0x0 nextents 0x0 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x0 ---------------------------------------------------------------------------- Oper (25): tid: f5af3048 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x22f470a flags: 0x1 dsize: 0 blkno: 18326400 len: 16 boff: 2560 Oper (26): tid: f5af3048 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 040755 version 1 format 2 nlink 22 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f4519b3 ctime 0x3f4519b3 size 0x1000 nblocks 0x1 extsize 0x0 nextents 0x1 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x6 ---------------------------------------------------------------------------- Oper (27): tid: f5af3048 len: 28 clientid: TRANS flags: none BUF: #regs: 4 start blkno: 18480912 (0x119ff10) len: 8 bmap size: 2 Oper (28): tid: f5af3048 len: 128 clientid: TRANS flags: none BUF DATA Oper (29): tid: f5af3048 len: 256 clientid: TRANS flags: none BUF DATA Oper (30): tid: f5af3048 len: 512 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (31): tid: f5af3048 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 0 (0x0) len: 1 bmap size: 1 Oper (32): tid: f5af3048 len: 128 clientid: TRANS flags: none SUPER BLOCK Buffer: icount: 1476864 ifree: 3364 fdblks: 1834921 frext: 0 ---------------------------------------------------------------------------- Oper (33): tid: f5af3048 len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (34): tid: f5af306c len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (35): tid: f5af306c len: 16 clientid: TRANS flags: none TRAN: type: REMOVE tid: 0 num_items: 4 ---------------------------------------------------------------------------- Oper (36): tid: f5af306c len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x22f470a flags: 0x1 dsize: 0 blkno: 18326400 len: 16 boff: 2560 Oper (37): tid: f5af306c len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 040755 version 1 format 2 nlink 22 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f4519b3 ctime 0x3f4519b3 size 0x1000 nblocks 0x1 extsize 0x0 nextents 0x1 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x6 ---------------------------------------------------------------------------- Oper (38): tid: f5af306c len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x37a4704 flags: 0x1 dsize: 0 blkno: 29172608 len: 16 boff: 1024 Oper (39): tid: f5af306c len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100600 version 1 format 2 nlink 0 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f4519b3 ctime 0x3f4519b3 size 0x0 nblocks 0x0 extsize 0x0 nextents 0x0 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x0 ---------------------------------------------------------------------------- Oper (40): tid: f5af306c len: 28 clientid: TRANS flags: none BUF: #regs: 4 start blkno: 18480912 (0x119ff10) len: 8 bmap size: 2 Oper (41): tid: f5af306c len: 128 clientid: TRANS flags: none BUF DATA Oper (42): tid: f5af306c len: 256 clientid: TRANS flags: none BUF DATA Oper (43): tid: f5af306c len: 512 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (44): tid: f5af306c len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 27262978 (0x1a00002) len: 1 bmap size: 1 Oper (45): tid: f5af306c len: 128 clientid: TRANS flags: none AGI Buffer: XAGI ver: 1 seq#: 13 len: 262144 cnt: 39616 root: 1767 level: 2 free#: 0x3b newino: 0x80 bucket[0 - 3]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[4 - 7]: 0x3a4704 0xffffffff 0xffffffff 0xffffffff bucket[8 - 11]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[12 - 15]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[16 - 19]: 0xffffffff ---------------------------------------------------------------------------- Oper (46): tid: f5af306c len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (47): tid: f5af3090 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (48): tid: f5af3090 len: 16 clientid: TRANS flags: none TRAN: type: INACTIVE tid: 0 num_items: 4 ---------------------------------------------------------------------------- Oper (49): tid: f5af3090 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x37a4704 flags: 0x1 dsize: 0 blkno: 29172608 len: 16 boff: 1024 Oper (50): tid: f5af3090 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 00 version 1 format 2 nlink 0 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f4519b3 ctime 0x3f4519b3 size 0x0 nblocks 0x0 extsize 0x0 nextents 0x0 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x1 ---------------------------------------------------------------------------- Oper (51): tid: f5af3090 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 27262978 (0x1a00002) len: 1 bmap size: 1 Oper (52): tid: f5af3090 len: 128 clientid: TRANS flags: none AGI Buffer: XAGI ver: 1 seq#: 13 len: 262144 cnt: 39616 root: 1767 level: 2 free#: 0x3c newino: 0x80 bucket[0 - 3]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[4 - 7]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[8 - 11]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[12 - 15]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[16 - 19]: 0xffffffff ---------------------------------------------------------------------------- Oper (53): tid: f5af3090 len: 28 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 27281592 (0x1a048b8) len: 8 bmap size: 2 Oper (54): tid: f5af3090 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (55): tid: f5af3090 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 0 (0x0) len: 1 bmap size: 1 Oper (56): tid: f5af3090 len: 128 clientid: TRANS flags: none SUPER BLOCK Buffer: icount: 1476864 ifree: 3365 fdblks: 1834921 frext: 0 ---------------------------------------------------------------------------- Oper (57): tid: f5af3090 len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (58): tid: f5af30b4 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (59): tid: f5af30b4 len: 16 clientid: TRANS flags: none TRAN: type: REMOVE tid: 0 num_items: 4 ---------------------------------------------------------------------------- Oper (60): tid: f5af30b4 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x22f470a flags: 0x1 dsize: 0 blkno: 18326400 len: 16 boff: 2560 Oper (61): tid: f5af30b4 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 040755 version 1 format 2 nlink 22 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f4519b3 ctime 0x3f4519b3 size 0x1000 nblocks 0x1 extsize 0x0 nextents 0x1 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x6 ---------------------------------------------------------------------------- Oper (62): tid: f5af30b4 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x37a3dbe flags: 0x1 dsize: 0 blkno: 29171408 len: 16 boff: 7680 Oper (63): tid: f5af30b4 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100600 version 1 format 2 nlink 0 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f4519b3 ctime 0x3f4519b3 size 0x0 nblocks 0x0 extsize 0x0 nextents 0x0 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x1 ---------------------------------------------------------------------------- Oper (64): tid: f5af30b4 len: 28 clientid: TRANS flags: none BUF: #regs: 4 start blkno: 18480912 (0x119ff10) len: 8 bmap size: 2 Oper (65): tid: f5af30b4 len: 128 clientid: TRANS flags: none BUF DATA Oper (66): tid: f5af30b4 len: 256 clientid: TRANS flags: none BUF DATA Oper (67): tid: f5af30b4 len: 512 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (68): tid: f5af30b4 len: 24 clientid: TRANS flags: none BUF: #regs: 3 start blkno: 27262978 (0x1a00002) len: 1 bmap size: 1 Oper (69): tid: f5af30b4 len: 128 clientid: TRANS flags: none AGI Buffer: XAGI ver: 1 seq#: 13 len: 262144 cnt: 39616 root: 1767 level: 2 free#: 0x3c newino: 0x80 bucket[0 - 3]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[4 - 7]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[8 - 11]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[12 - 15]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[16 - 19]: 0xffffffff Oper (70): tid: f5af30b4 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (71): tid: f5af30b4 len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (72): tid: f5af30d8 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (73): tid: f5af30d8 len: 16 clientid: TRANS flags: none TRAN: type: INACTIVE tid: 0 num_items: 4 ---------------------------------------------------------------------------- Oper (74): tid: f5af30d8 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x37a3dbe flags: 0x1 dsize: 0 blkno: 29171408 len: 16 boff: 7680 Oper (75): tid: f5af30d8 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 00 version 1 format 2 nlink 0 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f4519b3 ctime 0x3f4519b3 size 0x0 nblocks 0x0 extsize 0x0 nextents 0x0 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x2 ---------------------------------------------------------------------------- Oper (76): tid: f5af30d8 len: 24 clientid: TRANS flags: none BUF: #regs: 3 start blkno: 27262978 (0x1a00002) len: 1 bmap size: 1 Oper (77): tid: f5af30d8 len: 128 clientid: TRANS flags: none AGI Buffer: XAGI ver: 1 seq#: 13 len: 262144 cnt: 39616 root: 1767 level: 2 free#: 0x3d newino: 0x80 bucket[0 - 3]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[4 - 7]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[8 - 11]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[12 - 15]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[16 - 19]: 0xffffffff Oper (78): tid: f5af30d8 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (79): tid: f5af30d8 len: 28 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 27281592 (0x1a048b8) len: 8 bmap size: 2 Oper (80): tid: f5af30d8 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (81): tid: f5af30d8 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 0 (0x0) len: 1 bmap size: 1 Oper (82): tid: f5af30d8 len: 128 clientid: TRANS flags: none SUPER BLOCK Buffer: icount: 1476864 ifree: 3366 fdblks: 1834921 frext: 0 ---------------------------------------------------------------------------- Oper (83): tid: f5af30d8 len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (84): tid: f5af30fc len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (85): tid: f5af30fc len: 16 clientid: TRANS flags: none TRAN: type: CREATE tid: 0 num_items: 6 ---------------------------------------------------------------------------- Oper (86): tid: f5af30fc len: 24 clientid: TRANS flags: none BUF: #regs: 3 start blkno: 27262978 (0x1a00002) len: 1 bmap size: 1 Oper (87): tid: f5af30fc len: 128 clientid: TRANS flags: none AGI Buffer: XAGI ver: 1 seq#: 13 len: 262144 cnt: 39616 root: 1767 level: 2 free#: 0x3c newino: 0x80 bucket[0 - 3]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[4 - 7]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[8 - 11]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[12 - 15]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[16 - 19]: 0xffffffff Oper (88): tid: f5af30fc len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (89): tid: f5af30fc len: 28 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 27281592 (0x1a048b8) len: 8 bmap size: 2 Oper (90): tid: f5af30fc len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (91): tid: f5af30fc len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x37a3dbe flags: 0x1 dsize: 0 blkno: 29171408 len: 16 boff: 7680 Oper (92): tid: f5af30fc len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100600 version 1 format 2 nlink 1 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f4519b3 ctime 0x3f4519b3 size 0x0 nblocks 0x0 extsize 0x0 nextents 0x0 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x2 ---------------------------------------------------------------------------- Oper (93): tid: f5af30fc len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x22f470a flags: 0x1 dsize: 0 blkno: 18326400 len: 16 boff: 2560 Oper (94): tid: f5af30fc len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 040755 version 1 format 2 nlink 22 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f4519b3 ctime 0x3f4519b3 size 0x1000 nblocks 0x1 extsize 0x0 nextents 0x1 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x6 ---------------------------------------------------------------------------- Oper (95): tid: f5af30fc len: 28 clientid: TRANS flags: none BUF: #regs: 4 start blkno: 18480912 (0x119ff10) len: 8 bmap size: 2 Oper (96): tid: f5af30fc len: 128 clientid: TRANS flags: none BUF DATA Oper (97): tid: f5af30fc len: 256 clientid: TRANS flags: none BUF DATA Oper (98): tid: f5af30fc len: 512 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (99): tid: f5af30fc len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 0 (0x0) len: 1 bmap size: 1 Oper (100): tid: f5af30fc len: 128 clientid: TRANS flags: none SUPER BLOCK Buffer: icount: 1476864 ifree: 3365 fdblks: 1834921 frext: 0 ---------------------------------------------------------------------------- Oper (101): tid: f5af30fc len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (102): tid: f5af3120 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (103): tid: f5af3120 len: 16 clientid: TRANS flags: none TRAN: type: CREATE tid: 0 num_items: 6 ---------------------------------------------------------------------------- Oper (104): tid: f5af3120 len: 24 clientid: TRANS flags: none BUF: #regs: 3 start blkno: 27262978 (0x1a00002) len: 1 bmap size: 1 Oper (105): tid: f5af3120 len: 128 clientid: TRANS flags: none AGI Buffer: XAGI ver: 1 seq#: 13 len: 262144 cnt: 39616 root: 1767 level: 2 free#: 0x3b newino: 0x80 bucket[0 - 3]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[4 - 7]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[8 - 11]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[12 - 15]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[16 - 19]: 0xffffffff Oper (106): tid: f5af3120 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (107): tid: f5af3120 len: 28 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 27281592 (0x1a048b8) len: 8 bmap size: 2 Oper (108): tid: f5af3120 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (109): tid: f5af3120 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x37a4704 flags: 0x1 dsize: 0 blkno: 29172608 len: 16 boff: 1024 Oper (110): tid: f5af3120 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100644 version 1 format 2 nlink 1 uid 500 gid 100 atime 0x3f4519b6 mtime 0x3f4519b6 ctime 0x3f4519b6 size 0x0 nblocks 0x0 extsize 0x0 nextents 0x0 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x1 ---------------------------------------------------------------------------- Oper (111): tid: f5af3120 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x22f470a flags: 0x1 dsize: 0 blkno: 18326400 len: 16 boff: 2560 Oper (112): tid: f5af3120 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 040755 version 1 format 2 nlink 22 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f4519b6 ctime 0x3f4519b6 size 0x1000 nblocks 0x1 extsize 0x0 nextents 0x1 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x6 ---------------------------------------------------------------------------- Oper (113): tid: f5af3120 len: 28 clientid: TRANS flags: none BUF: #regs: 4 start blkno: 18480912 (0x119ff10) len: 8 bmap size: 2 Oper (114): tid: f5af3120 len: 128 clientid: TRANS flags: none BUF DATA Oper (115): tid: f5af3120 len: 256 clientid: TRANS flags: none BUF DATA Oper (116): tid: f5af3120 len: 512 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (117): tid: f5af3120 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 0 (0x0) len: 1 bmap size: 1 Oper (118): tid: f5af3120 len: 128 clientid: TRANS flags: none SUPER BLOCK Buffer: icount: 1476864 ifree: 3364 fdblks: 1834921 frext: 0 ---------------------------------------------------------------------------- Oper (119): tid: f5af3120 len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (120): tid: f5af3144 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (121): tid: f5af3144 len: 16 clientid: TRANS flags: none TRAN: type: SETATTR tid: 0 num_items: 1 ---------------------------------------------------------------------------- Oper (122): tid: f5af3144 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x37a4704 flags: 0x1 dsize: 0 blkno: 29172608 len: 16 boff: 1024 Oper (123): tid: f5af3144 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100644 version 1 format 2 nlink 1 uid 500 gid 100 atime 0x3f4519b6 mtime 0x3f4519b6 ctime 0x3f4519b6 size 0x0 nblocks 0x0 extsize 0x0 nextents 0x0 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x1 ---------------------------------------------------------------------------- Oper (124): tid: f5af3144 len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (125): tid: f5af3168 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (126): tid: f5af3168 len: 16 clientid: TRANS flags: none TRAN: type: SETATTR tid: 0 num_items: 1 ---------------------------------------------------------------------------- Oper (127): tid: f5af3168 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x37a4704 flags: 0x1 dsize: 0 blkno: 29172608 len: 16 boff: 1024 Oper (128): tid: f5af3168 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100644 version 1 format 2 nlink 1 uid 500 gid 100 atime 0x3f4519b6 mtime 0x3f4519b6 ctime 0x3f4519b6 size 0x0 nblocks 0x0 extsize 0x0 nextents 0x0 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x1 ---------------------------------------------------------------------------- Oper (129): tid: f5af3168 len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (130): tid: f5af318c len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (131): tid: f5af318c len: 16 clientid: TRANS flags: none TRAN: type: REMOVE tid: 0 num_items: 4 ---------------------------------------------------------------------------- Oper (132): tid: f5af318c len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x22f470a flags: 0x1 dsize: 0 blkno: 18326400 len: 16 boff: 2560 Oper (133): tid: f5af318c len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 040755 version 1 format 2 nlink 22 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f4519b6 ctime 0x3f4519b6 size 0x1000 nblocks 0x1 extsize 0x0 nextents 0x1 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x6 ---------------------------------------------------------------------------- Oper (134): tid: f5af318c len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x37a4704 flags: 0x1 dsize: 0 blkno: 29172608 len: 16 boff: 1024 Oper (135): tid: f5af318c len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100644 version 1 format 2 nlink 0 uid 500 gid 100 atime 0x3f4519b6 mtime 0x3f4519b6 ctime 0x3f4519b6 size 0x0 nblocks 0x0 extsize 0x0 nextents 0x0 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x1 ---------------------------------------------------------------------------- Oper (136): tid: f5af318c len: 28 clientid: TRANS flags: none BUF: #regs: 4 start blkno: 18480912 (0x119ff10) len: 8 bmap size: 2 Oper (137): tid: f5af318c len: 128 clientid: TRANS flags: none BUF DATA Oper (138): tid: f5af318c len: 256 clientid: TRANS flags: none BUF DATA Oper (139): tid: f5af318c len: 512 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (140): tid: f5af318c len: 24 clientid: TRANS flags: none BUF: #regs: 3 start blkno: 27262978 (0x1a00002) len: 1 bmap size: 1 Oper (141): tid: f5af318c len: 128 clientid: TRANS flags: none AGI Buffer: XAGI ver: 1 seq#: 13 len: 262144 cnt: 39616 root: 1767 level: 2 free#: 0x3b newino: 0x80 bucket[0 - 3]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[4 - 7]: 0x3a4704 0xffffffff 0xffffffff 0xffffffff bucket[8 - 11]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[12 - 15]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[16 - 19]: 0xffffffff Oper (142): tid: f5af318c len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (143): tid: f5af318c len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (144): tid: f5af31b0 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (145): tid: f5af31b0 len: 16 clientid: TRANS flags: none TRAN: type: INACTIVE tid: 0 num_items: 4 ---------------------------------------------------------------------------- Oper (146): tid: f5af31b0 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x37a4704 flags: 0x1 dsize: 0 blkno: 29172608 len: 16 boff: 1024 Oper (147): tid: f5af31b0 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 00 version 1 format 2 nlink 0 uid 500 gid 100 atime 0x3f4519b6 mtime 0x3f4519b6 ctime 0x3f4519b6 size 0x0 nblocks 0x0 extsize 0x0 nextents 0x0 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x2 ---------------------------------------------------------------------------- Oper (148): tid: f5af31b0 len: 24 clientid: TRANS flags: none BUF: #regs: 3 start blkno: 27262978 (0x1a00002) len: 1 bmap size: 1 Oper (149): tid: f5af31b0 len: 128 clientid: TRANS flags: none AGI Buffer: XAGI ver: 1 seq#: 13 len: 262144 cnt: 39616 root: 1767 level: 2 free#: 0x3c newino: 0x80 bucket[0 - 3]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[4 - 7]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[8 - 11]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[12 - 15]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[16 - 19]: 0xffffffff Oper (150): tid: f5af31b0 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (151): tid: f5af31b0 len: 28 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 27281592 (0x1a048b8) len: 8 bmap size: 2 Oper (152): tid: f5af31b0 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (153): tid: f5af31b0 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 0 (0x0) len: 1 bmap size: 1 Oper (154): tid: f5af31b0 len: 128 clientid: TRANS flags: none SUPER BLOCK Buffer: icount: 1476864 ifree: 3365 fdblks: 1834921 frext: 0 ---------------------------------------------------------------------------- Oper (155): tid: f5af31b0 len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (156): tid: f5af31d4 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (157): tid: f5af31d4 len: 16 clientid: TRANS flags: none TRAN: type: RENAME tid: 0 num_items: 2 ---------------------------------------------------------------------------- Oper (158): tid: f5af31d4 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x22f470a flags: 0x1 dsize: 0 blkno: 18326400 len: 16 boff: 2560 Oper (159): tid: f5af31d4 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 040755 version 1 format 2 nlink 22 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f4519b6 ctime 0x3f4519b6 size 0x1000 nblocks 0x1 extsize 0x0 nextents 0x1 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x6 ---------------------------------------------------------------------------- Oper (160): tid: f5af31d4 len: 28 clientid: TRANS flags: none BUF: #regs: 5 start blkno: 18480912 (0x119ff10) len: 8 bmap size: 2 Oper (161): tid: f5af31d4 len: 128 clientid: TRANS flags: none BUF DATA Oper (162): tid: f5af31d4 len: 128 clientid: TRANS flags: none BUF DATA Oper (163): tid: f5af31d4 len: 256 clientid: TRANS flags: none BUF DATA Oper (164): tid: f5af31d4 len: 512 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (165): tid: f5af31d4 len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (166): tid: f5af31f8 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (167): tid: f5af31f8 len: 16 clientid: TRANS flags: none TRAN: type: STRAT_WRITE tid: 0 num_items: 5 ---------------------------------------------------------------------------- Oper (168): tid: f5af31f8 len: 52 clientid: TRANS flags: none INODE: #regs: 3 ino: 0x37a3dbe flags: 0x5 dsize: 16 blkno: 29171408 len: 16 boff: 7680 Oper (169): tid: f5af31f8 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100600 version 1 format 2 nlink 1 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f4519b6 ctime 0x3f4519b6 size 0xa000 nblocks 0x10 extsize 0x0 nextents 0x1 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x2 Oper (170): tid: f5af31f8 len: 16 clientid: TRANS flags: none EXTENTS inode data ---------------------------------------------------------------------------- Oper (171): tid: f5af31f8 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 27262977 (0x1a00001) len: 1 bmap size: 1 Oper (172): tid: f5af31f8 len: 128 clientid: TRANS flags: none AGF Buffer: XAGF ver: 1 seq#: 13 len: 262144 root BNO: 2362 CNT: 47063 level BNO: 1 CNT: 1 1st: 0 last: 3 cnt: 4 freeblks: 18424 longest: 18384 ---------------------------------------------------------------------------- Oper (173): tid: f5af31f8 len: 28 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 27639480 (0x1a5beb8) len: 8 bmap size: 2 Oper (174): tid: f5af31f8 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (175): tid: f5af31f8 len: 28 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 27281872 (0x1a049d0) len: 8 bmap size: 2 Oper (176): tid: f5af31f8 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (177): tid: f5af31f8 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 0 (0x0) len: 1 bmap size: 1 Oper (178): tid: f5af31f8 len: 128 clientid: TRANS flags: none SUPER BLOCK Buffer: icount: 1476864 ifree: 3365 fdblks: 1834905 frext: 0 ---------------------------------------------------------------------------- Oper (179): tid: f5af31f8 len: 0 clientid: TRANS flags: COMMIT ============================================================================ cycle: 1 version: 1 lsn: 1,39 tail_lsn: 1,2 length of Log Record: 252 prev offset: 2 num ops: 6 uuid: f272d169-808f-4627-9fa9-873b504e76b5 format: little endian linux ---------------------------------------------------------------------------- Oper (0): tid: f5af321c len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (1): tid: f5af321c len: 16 clientid: TRANS flags: none TRAN: type: FSYNC_TS tid: 0 num_items: 1 ---------------------------------------------------------------------------- Oper (2): tid: f5af321c len: 52 clientid: TRANS flags: none INODE: #regs: 3 ino: 0x37a3dbe flags: 0x5 dsize: 16 blkno: 29171408 len: 16 boff: 7680 Oper (3): tid: f5af321c len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100600 version 1 format 2 nlink 1 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f4519b6 ctime 0x3f4519b6 size 0xa000 nblocks 0x10 extsize 0x0 nextents 0x1 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x2 Oper (4): tid: f5af321c len: 16 clientid: TRANS flags: none EXTENTS inode data ---------------------------------------------------------------------------- Oper (5): tid: f5af321c len: 0 clientid: TRANS flags: COMMIT ============================================================================ cycle: 1 version: 1 lsn: 1,41 tail_lsn: 1,2 length of Log Record: 6308 prev offset: 39 num ops: 74 uuid: f272d169-808f-4627-9fa9-873b504e76b5 format: little endian linux ---------------------------------------------------------------------------- Oper (0): tid: f5af3240 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (1): tid: f5af3240 len: 16 clientid: TRANS flags: none TRAN: type: CREATE tid: 0 num_items: 6 ---------------------------------------------------------------------------- Oper (2): tid: f5af3240 len: 24 clientid: TRANS flags: none BUF: #regs: 3 start blkno: 27262978 (0x1a00002) len: 1 bmap size: 1 Oper (3): tid: f5af3240 len: 128 clientid: TRANS flags: none AGI Buffer: XAGI ver: 1 seq#: 13 len: 262144 cnt: 39616 root: 1767 level: 2 free#: 0x3b newino: 0x80 bucket[0 - 3]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[4 - 7]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[8 - 11]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[12 - 15]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[16 - 19]: 0xffffffff Oper (4): tid: f5af3240 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (5): tid: f5af3240 len: 28 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 27281592 (0x1a048b8) len: 8 bmap size: 2 Oper (6): tid: f5af3240 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (7): tid: f5af3240 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x37a4704 flags: 0x1 dsize: 0 blkno: 29172608 len: 16 boff: 1024 Oper (8): tid: f5af3240 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100644 version 1 format 2 nlink 1 uid 500 gid 100 atime 0x3f4519b6 mtime 0x3f4519b6 ctime 0x3f4519b6 size 0x0 nblocks 0x0 extsize 0x0 nextents 0x0 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x2 ---------------------------------------------------------------------------- Oper (9): tid: f5af3240 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x22f470a flags: 0x1 dsize: 0 blkno: 18326400 len: 16 boff: 2560 Oper (10): tid: f5af3240 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 040755 version 1 format 2 nlink 22 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f4519b6 ctime 0x3f4519b6 size 0x1000 nblocks 0x1 extsize 0x0 nextents 0x1 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x6 ---------------------------------------------------------------------------- Oper (11): tid: f5af3240 len: 28 clientid: TRANS flags: none BUF: #regs: 5 start blkno: 18480912 (0x119ff10) len: 8 bmap size: 2 Oper (12): tid: f5af3240 len: 128 clientid: TRANS flags: none BUF DATA Oper (13): tid: f5af3240 len: 128 clientid: TRANS flags: none BUF DATA Oper (14): tid: f5af3240 len: 256 clientid: TRANS flags: none BUF DATA Oper (15): tid: f5af3240 len: 512 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (16): tid: f5af3240 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 0 (0x0) len: 1 bmap size: 1 Oper (17): tid: f5af3240 len: 128 clientid: TRANS flags: none SUPER BLOCK Buffer: icount: 1476864 ifree: 3364 fdblks: 1834905 frext: 0 ---------------------------------------------------------------------------- Oper (18): tid: f5af3240 len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (19): tid: f5af3264 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (20): tid: f5af3264 len: 16 clientid: TRANS flags: none TRAN: type: INACTIVE tid: 0 num_items: 1 ---------------------------------------------------------------------------- Oper (21): tid: f5af3264 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x37a4704 flags: 0x1 dsize: 0 blkno: 29172608 len: 16 boff: 1024 Oper (22): tid: f5af3264 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100644 version 1 format 2 nlink 1 uid 500 gid 100 atime 0x3f4519b6 mtime 0x3f4519b6 ctime 0x3f4519b6 size 0x5ed9 nblocks 0x0 extsize 0x0 nextents 0x0 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x2 ---------------------------------------------------------------------------- Oper (23): tid: f5af3264 len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (24): tid: f5af3288 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (25): tid: f5af3288 len: 16 clientid: TRANS flags: none TRAN: type: SETATTR tid: 0 num_items: 1 ---------------------------------------------------------------------------- Oper (26): tid: f5af3288 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x37a4704 flags: 0x1 dsize: 0 blkno: 29172608 len: 16 boff: 1024 Oper (27): tid: f5af3288 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100644 version 1 format 2 nlink 1 uid 500 gid 100 atime 0x3f4519b6 mtime 0x3f4519b6 ctime 0x3f4519b6 size 0x5ed9 nblocks 0x0 extsize 0x0 nextents 0x0 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x2 ---------------------------------------------------------------------------- Oper (28): tid: f5af3288 len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (29): tid: f5af32ac len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (30): tid: f5af32ac len: 16 clientid: TRANS flags: none TRAN: type: REMOVE tid: 0 num_items: 4 ---------------------------------------------------------------------------- Oper (31): tid: f5af32ac len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x22f470a flags: 0x1 dsize: 0 blkno: 18326400 len: 16 boff: 2560 Oper (32): tid: f5af32ac len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 040755 version 1 format 2 nlink 22 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f4519b6 ctime 0x3f4519b6 size 0x1000 nblocks 0x1 extsize 0x0 nextents 0x1 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x6 ---------------------------------------------------------------------------- Oper (33): tid: f5af32ac len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x2348180 flags: 0x1 dsize: 0 blkno: 18497728 len: 16 boff: 0 Oper (34): tid: f5af32ac len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100644 version 1 format 2 nlink 0 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f45149f ctime 0x3f4519b6 size 0x5ef4 nblocks 0x6 extsize 0x0 nextents 0x1 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x1 ---------------------------------------------------------------------------- Oper (35): tid: f5af32ac len: 28 clientid: TRANS flags: none BUF: #regs: 5 start blkno: 18480912 (0x119ff10) len: 8 bmap size: 2 Oper (36): tid: f5af32ac len: 128 clientid: TRANS flags: none BUF DATA Oper (37): tid: f5af32ac len: 128 clientid: TRANS flags: none BUF DATA Oper (38): tid: f5af32ac len: 256 clientid: TRANS flags: none BUF DATA Oper (39): tid: f5af32ac len: 512 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (40): tid: f5af32ac len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 16777218 (0x1000002) len: 1 bmap size: 1 Oper (41): tid: f5af32ac len: 128 clientid: TRANS flags: none AGI Buffer: XAGI ver: 1 seq#: 8 len: 262144 cnt: 45440 root: 4207 level: 2 free#: 0x0 newino: 0x80 bucket[0 - 3]: 0x348180 0xffffffff 0xffffffff 0xffffffff bucket[4 - 7]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[8 - 11]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[12 - 15]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[16 - 19]: 0xffffffff ---------------------------------------------------------------------------- Oper (42): tid: f5af32ac len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (43): tid: f5af32d0 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (44): tid: f5af32d0 len: 16 clientid: TRANS flags: none TRAN: type: INACTIVE tid: 0 num_items: 2 ---------------------------------------------------------------------------- Oper (45): tid: f5af32d0 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x2348180 flags: 0x1 dsize: 0 blkno: 18497728 len: 16 boff: 0 Oper (46): tid: f5af32d0 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100644 version 1 format 2 nlink 0 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f45149f ctime 0x3f4519b6 size 0x0 nblocks 0x0 extsize 0x0 nextents 0x0 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x1 ---------------------------------------------------------------------------- Oper (47): tid: f5af32d0 len: 28 clientid: TRANS flags: none EFI: #regs: 1 num_extents: 1 id: 0xffffffffccd9beb8 (s: 0x37961a, l: 6) ---------------------------------------------------------------------------- Oper (48): tid: f5af32d0 len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (49): tid: f5af32d0 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (50): tid: f5af32d0 len: 16 clientid: TRANS flags: none TRAN: type: INACTIVE tid: 0 num_items: 6 ---------------------------------------------------------------------------- Oper (51): tid: f5af32d0 len: 28 clientid: TRANS flags: none EFD: #regs: 1 num_extents: 1 id: 0xffffffffccd9beb8 (s: 0x37961a, l: 6) ---------------------------------------------------------------------------- Oper (52): tid: f5af32d0 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 27262977 (0x1a00001) len: 1 bmap size: 1 Oper (53): tid: f5af32d0 len: 128 clientid: TRANS flags: none AGF Buffer: XAGF ver: 1 seq#: 13 len: 262144 root BNO: 2362 CNT: 47063 level BNO: 1 CNT: 1 1st: 0 last: 3 cnt: 4 freeblks: 18430 longest: 18384 ---------------------------------------------------------------------------- Oper (54): tid: f5af32d0 len: 28 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 27281872 (0x1a049d0) len: 8 bmap size: 2 Oper (55): tid: f5af32d0 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (56): tid: f5af32d0 len: 28 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 27639480 (0x1a5beb8) len: 8 bmap size: 2 Oper (57): tid: f5af32d0 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (58): tid: f5af32d0 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x2348180 flags: 0x1 dsize: 0 blkno: 18497728 len: 16 boff: 0 Oper (59): tid: f5af32d0 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100644 version 1 format 2 nlink 0 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f45149f ctime 0x3f4519b6 size 0x0 nblocks 0x0 extsize 0x0 nextents 0x0 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x1 ---------------------------------------------------------------------------- Oper (60): tid: f5af32d0 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 0 (0x0) len: 1 bmap size: 1 Oper (61): tid: f5af32d0 len: 128 clientid: TRANS flags: none SUPER BLOCK Buffer: icount: 1476864 ifree: 3364 fdblks: 1834911 frext: 0 ---------------------------------------------------------------------------- Oper (62): tid: f5af32d0 len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (63): tid: f5af32d0 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (64): tid: f5af32d0 len: 16 clientid: TRANS flags: none TRAN: type: INACTIVE tid: 0 num_items: 4 ---------------------------------------------------------------------------- Oper (65): tid: f5af32d0 len: 52 clientid: TRANS flags: none INODE: #regs: 2 ino: 0x2348180 flags: 0x1 dsize: 0 blkno: 18497728 len: 16 boff: 0 Oper (66): tid: f5af32d0 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 00 version 1 format 2 nlink 0 uid 500 gid 100 atime 0x3f4519b3 mtime 0x3f45149f ctime 0x3f4519b6 size 0x0 nblocks 0x0 extsize 0x0 nextents 0x0 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x2 ---------------------------------------------------------------------------- Oper (67): tid: f5af32d0 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 16777218 (0x1000002) len: 1 bmap size: 1 Oper (68): tid: f5af32d0 len: 128 clientid: TRANS flags: none AGI Buffer: XAGI ver: 1 seq#: 8 len: 262144 cnt: 45440 root: 4207 level: 2 free#: 0x1 newino: 0x80 bucket[0 - 3]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[4 - 7]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[8 - 11]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[12 - 15]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff bucket[16 - 19]: 0xffffffff ---------------------------------------------------------------------------- Oper (69): tid: f5af32d0 len: 28 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 16927160 (0x10249b8) len: 8 bmap size: 2 Oper (70): tid: f5af32d0 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (71): tid: f5af32d0 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 0 (0x0) len: 1 bmap size: 1 Oper (72): tid: f5af32d0 len: 128 clientid: TRANS flags: none SUPER BLOCK Buffer: icount: 1476864 ifree: 3365 fdblks: 1834911 frext: 0 ---------------------------------------------------------------------------- Oper (73): tid: f5af32d0 len: 0 clientid: TRANS flags: COMMIT ============================================================================ cycle: 1 version: 1 lsn: 1,55 tail_lsn: 1,39 length of Log Record: 16956 prev offset: 41 num ops: 183 uuid: f272d169-808f-4627-9fa9-873b504e76b5 format: little endian linux ********************************************************************** * ERROR: data block=55 * ********************************************************************** Bad Log From owner-linux-xfs@oss.sgi.com Thu Aug 21 12:49:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 12:49:34 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LJnWoO019956 for ; Thu, 21 Aug 2003 12:49:32 -0700 Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7LJnQq0027088 for ; Thu, 21 Aug 2003 12:49:26 -0700 Received: from stout.americas.sgi.com (localhost [127.0.0.1]) by stout.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h7LJnPZW005819; Thu, 21 Aug 2003 14:49:25 -0500 Received: (from sandeen@localhost) by stout.americas.sgi.com (8.12.8/8.12.8/Submit) id h7LJnP8G005817; Thu, 21 Aug 2003 14:49:25 -0500 Date: Thu, 21 Aug 2003 14:49:25 -0500 From: Eric Sandeen Message-Id: <200308211949.h7LJnP8G005817@stout.americas.sgi.com> Subject: PARTIAL TAKE 899288 - Rework linux-xfs to use per-cpu vars for xfsstats X-archive-position: 115 X-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@stout.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 926 Lines: 29 Re-work xfs stats macros to support per-cpu data (not actually doing any per-cpu stuff yet) Date: Thu Aug 21 12:47:57 PDT 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-linux:slinx:156453a linux/fs/xfs/xfs_log.c - 1.281 linux/fs/xfs/xfs_trans_ail.c - 1.71 linux/fs/xfs/xfs_vnodeops.c - 1.602 linux/fs/xfs/xfs_dir.c - 1.154 linux/fs/xfs/xfs_iget.c - 1.192 linux/fs/xfs/xfs_bmap_btree.c - 1.139 linux/fs/xfs/xfs_inode.c - 1.383 linux/fs/xfs/xfs_trans.c - 1.152 linux/fs/xfs/xfs_alloc.c - 1.168 linux/fs/xfs/xfs_bmap.c - 1.309 linux/fs/xfs/xfs_alloc_btree.c - 1.80 linux/fs/xfs/xfs_attr.c - 1.108 linux/fs/xfs/xfs_dir2.c - 1.46 linux/fs/xfs/linux/xfs_lrw.c - 1.193 linux/fs/xfs/linux/xfs_vnode.c - 1.116 linux/fs/xfs/linux/xfs_stats.h - 1.10 linux/fs/xfs/linux/xfs_iomap.c - 1.16 From owner-linux-xfs@oss.sgi.com Thu Aug 21 12:50:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 12:50:37 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LJoWoO020203 for ; Thu, 21 Aug 2003 12:50:34 -0700 Received: (qmail 11419 invoked from network); 21 Aug 2003 19:50:30 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 21 Aug 2003 19:50:30 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 3E3D9EC5E0; Fri, 22 Aug 2003 05:50:30 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 3AE9C140082; Fri, 22 Aug 2003 05:50:30 +1000 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Jamie Krasnoo Cc: xfs Subject: Re: Which patch In-reply-to: Your message of "Thu, 21 Aug 2003 00:28:37 MST." <1061450917.9506.1.camel@najena> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Aug 2003 05:50:29 +1000 Message-ID: <10995.1061495429@ocs3.intra.ocs.com.au> X-archive-position: 116 X-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: 1286 Lines: 31 On Thu, 21 Aug 2003 00:28:37 -0700, Jamie Krasnoo wrote: >Looking at the list of patches to download for the 2.4.20 kernel I see a >few of them are available. I'm not sure which one to use. Do I use rc3 >or the one with the most recent date on it? I assume you mean the split patches in ftp://oss.sgi.com/projects/xfs/download/patches. It contains these directories 2.4.20 2.4.20-2002-11-29_01:21_UTC 2.4.20-2002-12-18_02:00_UTC 2.4.20-2003-01-14_00:43_UTC 2.4.20-2003-02-05_23:39_UTC 2.4.20-2003-03-19_04:55_UTC 2.4.20-rc3 2.4.20-rc3 is against Marcelo's 2.4.20-rc3 (release candidate) which precedes 2.4.20 proper. The 2.4.20*UTC directories are older versions of the XFS patches against 2.4.20. 2.4.20 is the last XFS patch against 2.4.20. Remember that the README says The -all and -split patches are provided as a courtesy and are not supported. They are snapshots of the XFS CVS tree as of the specified date and time, the split patches may or may not be changed afterwards. The main method of XFS distribution is via the XFS CVS tree, if you want an up to date version of XFS then use CVS. 2.4.20 is quite old now, both from the kernel and XFS point of view, it was last updated on April 7. You should upgrade to 2.4.21 if possible. From owner-linux-xfs@oss.sgi.com Thu Aug 21 13:21:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 13:22:01 -0700 (PDT) Received: from linux-sxs.org (dhcp065-024-128-253.columbus.rr.com [65.24.128.253] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LKLgoO022175 for ; Thu, 21 Aug 2003 13:21:45 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.9/8.12.9) with ESMTP id h7LKLAM7007376 for ; Thu, 21 Aug 2003 16:21:10 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.9/8.12.9/Submit) with ESMTP id h7LKLAZ1030132 for ; Thu, 21 Aug 2003 16:21:10 -0400 Date: Thu, 21 Aug 2003 16:21:10 -0400 (EDT) From: Net Llama! To: linux-xfs@oss.sgi.com Subject: kernel rpms for older RH? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.35 X-archive-position: 117 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 372 Lines: 12 Hi, I've noticed that all of the recent Release-1.3-preX kernel_rpms are in a Redhat9 subdirectory. Does this imply that those kernel RPMs will not work on RH-7.3 (the XFS version)? thanks! -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Thu Aug 21 13:32:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 13:32:30 -0700 (PDT) Received: from orngca-mls01.socal.rr.com (orngca-mls01.socal.rr.com [66.75.160.16]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LKWOoO023209 for ; Thu, 21 Aug 2003 13:32:27 -0700 Received: from najena (cpe-66-74-75-215.socal.rr.com [66.74.75.215]) by orngca-mls01.socal.rr.com (8.11.4/8.11.3) with ESMTP id h7LKT2x04632; Thu, 21 Aug 2003 13:29:02 -0700 (PDT) Subject: Re: Which patch From: Jamie Krasnoo To: Keith Owens Cc: xfs In-Reply-To: <10995.1061495429@ocs3.intra.ocs.com.au> References: <10995.1061495429@ocs3.intra.ocs.com.au> Content-Type: text/plain Message-Id: <1061497943.3219.0.camel@najena> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 21 Aug 2003 13:32:24 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 118 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: krasnooj@socal.rr.com Precedence: bulk X-list: linux-xfs Content-Length: 1429 Lines: 35 On Thu, 2003-08-21 at 12:50, Keith Owens wrote: > On Thu, 21 Aug 2003 00:28:37 -0700, > Jamie Krasnoo wrote: > >Looking at the list of patches to download for the 2.4.20 kernel I see a > >few of them are available. I'm not sure which one to use. Do I use rc3 > >or the one with the most recent date on it? > > I assume you mean the split patches in ftp://oss.sgi.com/projects/xfs/download/patches. > It contains these directories > > 2.4.20 > 2.4.20-2002-11-29_01:21_UTC > 2.4.20-2002-12-18_02:00_UTC > 2.4.20-2003-01-14_00:43_UTC > 2.4.20-2003-02-05_23:39_UTC > 2.4.20-2003-03-19_04:55_UTC > 2.4.20-rc3 > > 2.4.20-rc3 is against Marcelo's 2.4.20-rc3 (release candidate) which > precedes 2.4.20 proper. The 2.4.20*UTC directories are older versions > of the XFS patches against 2.4.20. 2.4.20 is the last XFS patch > against 2.4.20. Remember that the README says > > The -all and -split patches are provided as a courtesy and are not supported. > They are snapshots of the XFS CVS tree as of the specified date and time, the > split patches may or may not be changed afterwards. The main method of XFS > distribution is via the XFS CVS tree, if you want an up to date version of XFS > then use CVS. > > 2.4.20 is quite old now, both from the kernel and XFS point of view, it > was last updated on April 7. You should upgrade to 2.4.21 if possible. > Thanks Keith much appreciated. From owner-linux-xfs@oss.sgi.com Thu Aug 21 13:37:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 13:37:47 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LKbeoO023768 for ; Thu, 21 Aug 2003 13:37:42 -0700 Received: from rrzlx11.rz.uni-regensburg.de (rrzlx11.rz.uni-regensburg.de [132.199.38.111]) by rrzs2.rz.uni-regensburg.de (8.11.7+Sun/8.11.6) with ESMTP id h7LKbZm18751; Thu, 21 Aug 2003 22:37:35 +0200 (MEST) Received: from guc28561 by rrzlx11.rz.uni-regensburg.de with local (Exim 3.35 #1 (Debian)) id 19pwBb-0007En-00; Thu, 21 Aug 2003 22:37:35 +0200 Date: Thu, 21 Aug 2003 22:37:34 +0200 From: Christian Guggenberger To: Jamie Krasnoo Cc: linux-xfs@oss.sgi.com Subject: Re: Which patch Message-ID: <20030821203734.GA26357@rrzlx11.rz.uni-regensburg.de> Reply-To: Christian.Guggenberger@physik.uni-regensburg.de References: <10995.1061495429@ocs3.intra.ocs.com.au> <1061497943.3219.0.camel@najena> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1061497943.3219.0.camel@najena> User-Agent: Mutt/1.3.28i X-archive-position: 119 X-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: 1669 Lines: 40 On Thu, Aug 21, 2003 at 01:32:24PM -0700, Jamie Krasnoo wrote: > On Thu, 2003-08-21 at 12:50, Keith Owens wrote: > > On Thu, 21 Aug 2003 00:28:37 -0700, > > Jamie Krasnoo wrote: > > >Looking at the list of patches to download for the 2.4.20 kernel I see a > > >few of them are available. I'm not sure which one to use. Do I use rc3 > > >or the one with the most recent date on it? > > > > I assume you mean the split patches in ftp://oss.sgi.com/projects/xfs/download/patches. > > It contains these directories > > > > 2.4.20 > > 2.4.20-2002-11-29_01:21_UTC > > 2.4.20-2002-12-18_02:00_UTC > > 2.4.20-2003-01-14_00:43_UTC > > 2.4.20-2003-02-05_23:39_UTC > > 2.4.20-2003-03-19_04:55_UTC > > 2.4.20-rc3 > > > > 2.4.20-rc3 is against Marcelo's 2.4.20-rc3 (release candidate) which > > precedes 2.4.20 proper. The 2.4.20*UTC directories are older versions > > of the XFS patches against 2.4.20. 2.4.20 is the last XFS patch > > against 2.4.20. Remember that the README says > > > > The -all and -split patches are provided as a courtesy and are not supported. > > They are snapshots of the XFS CVS tree as of the specified date and time, the > > split patches may or may not be changed afterwards. The main method of XFS > > distribution is via the XFS CVS tree, if you want an up to date version of XFS > > then use CVS. > > > > 2.4.20 is quite old now, both from the kernel and XFS point of view, it > > was last updated on April 7. You should upgrade to 2.4.21 if possible. > > > there are also 1.3-pre6 patches for 2.4.20 (not only for 2.4.21) on oss: ftp://oss.sgi.com/projects/xfs/download/Release-1.3/pre6 Christian From owner-linux-xfs@oss.sgi.com Thu Aug 21 14:00:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 14:01:09 -0700 (PDT) Received: from zero.aec.at (Borelli@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LL0qoO024857 for ; Thu, 21 Aug 2003 14:00:53 -0700 Received: from fred.muc.de (Jared.Oopf@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id h7LL0dm28427; Thu, 21 Aug 2003 23:00:39 +0200 Received: by fred.muc.de (Postfix on SuSE Linux 7.3 (i386), from userid 500) id CB9B25BBBF; Thu, 21 Aug 2003 23:00:42 +0200 (CEST) To: Chris Meadors Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Hang when mounting XFS root in 2.6.0 tests on x86-64 From: Andi Kleen Date: Thu, 21 Aug 2003 23:00:42 +0200 In-Reply-To: (Chris Meadors's message of "Thu, 21 Aug 2003 22:40:13 +0200") Message-ID: User-Agent: Gnus/5.090013 (Oort Gnus v0.13) Emacs/21.2 (i586-suse-linux) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 120 X-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@muc.de Precedence: bulk X-list: linux-xfs Content-Length: 1041 Lines: 28 Chris Meadors writes: Better report it to linux-xfs@oss.sgi.com (cc'ed) too. > I'm trying to get a 2.6.0-test kernel to boot on my Opteron system. It > has SuSE's 2.4.19-SMP kernel on it now, and it boots with that, mounts > the XFS root just fine. But I build a vanilla 2.6.0-test3 with no > module support, everything included that I would need. The last line > that it prints during boot is the NET4.0 > > Repeated presses of Alt+SysRq+P seems to show RIP looping in xfs_xlatesb > and xfs_lowbit64. > > I've tried -test3-bk9 and also went back to -test2 and -test1. > > Earlier when playing with this machine I built 2.6.0-test3 with a 32 bit > only version of gcc, but still optimized for the Opteron. This one had > no problem booting and mounting the XFS root. > > This is easy to reproduce, so let me know if more information is needed. I test XFS (but not as root) occasionally on x86-64 and seen no problems so far. I haven't tested it with test2+ yet though. What compiler are you using? -Andi From owner-linux-xfs@oss.sgi.com Thu Aug 21 14:15:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 14:15:26 -0700 (PDT) Received: from buffy.firmix.at (gate.firmix.at [80.109.18.208]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LLFKoO025682 for ; Thu, 21 Aug 2003 14:15:22 -0700 Received: from localhost (gate.firmix.at [10.0.0.1]) by buffy.firmix.at (8.12.8/8.12.8) with ESMTP id h7LLFDFW030279 for ; Thu, 21 Aug 2003 23:15:13 +0200 Subject: Re: The X in XFS From: Bernd Petrovitsch To: linux-xfs@oss.sgi.com In-Reply-To: <20030821184329.GA11855@chihiro.cern.ch> References: <1061482171.1797.65.camel@jen.americas.sgi.com> <20030821184329.GA11855@chihiro.cern.ch> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8.99 Date: 21 Aug 2003 23:15:13 +0200 Message-Id: <1061500513.1094.4.camel@gimli.at.home> Mime-Version: 1.0 X-archive-position: 121 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bernd@firmix.at Precedence: bulk X-list: linux-xfs Content-Length: 1033 Lines: 27 On Thu, 2003-08-21 at 20:43, KELEMEN Peter wrote: > * Steve Lord (lord@sgi.com) [20030821 11:09]: > > > Originally the project was internally refered to as xFS, > > presumably until marketing came up with a letter or name which > > was deemed acceptable. After a while the x just stuck without > > having a meaning assigned to it, and it was capitalized. > > It should be noted that there is a Serverless Network File System > from Berkeley that is precisely called "xFS", as you can see at > http://now.cs.berkeley.edu/Xfs/xfs.html . Also, there are other > products named "XFS", for example a popular NFS client for DOS. > http://www.tux.org/pub/distributions/SuSE/i386/8.2/dosutils/xfs186/xfs.txt Two more: - xfs - the X font server - the XMethods Filesystem - http://www.xmethods.net/xfs/ > Of course, there is only one true XFS! :-) :-) Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services From owner-linux-xfs@oss.sgi.com Thu Aug 21 14:16:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 14:16:59 -0700 (PDT) Received: from orngca-mls02.socal.rr.com (orngca-mls02.socal.rr.com [66.75.160.17]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LLGaoO025907 for ; Thu, 21 Aug 2003 14:16:56 -0700 Received: from najena (cpe-66-74-75-215.socal.rr.com [66.74.75.215]) by orngca-mls02.socal.rr.com (8.11.4/8.11.3) with ESMTP id h7LLCMD27973; Thu, 21 Aug 2003 14:12:23 -0700 (PDT) Subject: Re: Which patch From: Jamie Krasnoo To: Christian.Guggenberger@physik.uni-regensburg.de Cc: xfs In-Reply-To: <20030821203734.GA26357@rrzlx11.rz.uni-regensburg.de> References: <10995.1061495429@ocs3.intra.ocs.com.au> <1061497943.3219.0.camel@najena> <20030821203734.GA26357@rrzlx11.rz.uni-regensburg.de> Content-Type: text/plain Message-Id: <1061500587.3219.3.camel@najena> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 21 Aug 2003 14:16:28 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 122 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: krasnooj@socal.rr.com Precedence: bulk X-list: linux-xfs Content-Length: 1898 Lines: 48 On Thu, 2003-08-21 at 13:37, Christian Guggenberger wrote: > On Thu, Aug 21, 2003 at 01:32:24PM -0700, Jamie Krasnoo wrote: > > On Thu, 2003-08-21 at 12:50, Keith Owens wrote: > > > On Thu, 21 Aug 2003 00:28:37 -0700, > > > Jamie Krasnoo wrote: > > > >Looking at the list of patches to download for the 2.4.20 kernel I see a > > > >few of them are available. I'm not sure which one to use. Do I use rc3 > > > >or the one with the most recent date on it? > > > > > > I assume you mean the split patches in ftp://oss.sgi.com/projects/xfs/download/patches. > > > It contains these directories > > > > > > 2.4.20 > > > 2.4.20-2002-11-29_01:21_UTC > > > 2.4.20-2002-12-18_02:00_UTC > > > 2.4.20-2003-01-14_00:43_UTC > > > 2.4.20-2003-02-05_23:39_UTC > > > 2.4.20-2003-03-19_04:55_UTC > > > 2.4.20-rc3 > > > > > > 2.4.20-rc3 is against Marcelo's 2.4.20-rc3 (release candidate) which > > > precedes 2.4.20 proper. The 2.4.20*UTC directories are older versions > > > of the XFS patches against 2.4.20. 2.4.20 is the last XFS patch > > > against 2.4.20. Remember that the README says > > > > > > The -all and -split patches are provided as a courtesy and are not supported. > > > They are snapshots of the XFS CVS tree as of the specified date and time, the > > > split patches may or may not be changed afterwards. The main method of XFS > > > distribution is via the XFS CVS tree, if you want an up to date version of XFS > > > then use CVS. > > > > > > 2.4.20 is quite old now, both from the kernel and XFS point of view, it > > > was last updated on April 7. You should upgrade to 2.4.21 if possible. > > > > > > there are also 1.3-pre6 patches for 2.4.20 (not only for 2.4.21) on oss: > > ftp://oss.sgi.com/projects/xfs/download/Release-1.3/pre6 > > Christian The patch I downloaded was the xfs-2.4.21-all-i386 patch. That is for 1.2 I hope. Jamie From owner-linux-xfs@oss.sgi.com Thu Aug 21 14:34:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 14:34:44 -0700 (PDT) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LLYIoO026969 for ; Thu, 21 Aug 2003 14:34:19 -0700 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 h7LLYG5B026148 for ; Thu, 21 Aug 2003 23:34:16 +0200 Received: (qmail 9816 invoked from network); 21 Aug 2003 23:34:16 +0200 Received: from rx3227.cip.uni-regensburg.de (132.199.237.32) by rss1.rz.uni-regensburg.de with SMTP; 21 Aug 2003 23:34:16 +0200 Subject: Re: Which patch From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: Jamie Krasnoo Cc: xfs In-Reply-To: <1061500587.3219.3.camel@najena> References: <10995.1061495429@ocs3.intra.ocs.com.au> <1061497943.3219.0.camel@najena> <20030821203734.GA26357@rrzlx11.rz.uni-regensburg.de> <1061500587.3219.3.camel@najena> Content-Type: text/plain Message-Id: <1061501656.580.2.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 21 Aug 2003 23:34:16 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 123 X-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: 2076 Lines: 50 On Thu, 2003-08-21 at 23:16, Jamie Krasnoo wrote: > On Thu, 2003-08-21 at 13:37, Christian Guggenberger wrote: > > On Thu, Aug 21, 2003 at 01:32:24PM -0700, Jamie Krasnoo wrote: > > > On Thu, 2003-08-21 at 12:50, Keith Owens wrote: > > > > On Thu, 21 Aug 2003 00:28:37 -0700, > > > > Jamie Krasnoo wrote: > > > > >Looking at the list of patches to download for the 2.4.20 kernel I see a > > > > >few of them are available. I'm not sure which one to use. Do I use rc3 > > > > >or the one with the most recent date on it? > > > > > > > > I assume you mean the split patches in ftp://oss.sgi.com/projects/xfs/download/patches. > > > > It contains these directories > > > > > > > > 2.4.20 > > > > 2.4.20-2002-11-29_01:21_UTC > > > > 2.4.20-2002-12-18_02:00_UTC > > > > 2.4.20-2003-01-14_00:43_UTC > > > > 2.4.20-2003-02-05_23:39_UTC > > > > 2.4.20-2003-03-19_04:55_UTC > > > > 2.4.20-rc3 > > > > > > > > 2.4.20-rc3 is against Marcelo's 2.4.20-rc3 (release candidate) which > > > > precedes 2.4.20 proper. The 2.4.20*UTC directories are older versions > > > > of the XFS patches against 2.4.20. 2.4.20 is the last XFS patch > > > > against 2.4.20. Remember that the README says > > > > > > > > The -all and -split patches are provided as a courtesy and are not supported. > > > > They are snapshots of the XFS CVS tree as of the specified date and time, the > > > > split patches may or may not be changed afterwards. The main method of XFS > > > > distribution is via the XFS CVS tree, if you want an up to date version of XFS > > > > then use CVS. > > > > > > > > 2.4.20 is quite old now, both from the kernel and XFS point of view, it > > > > was last updated on April 7. You should upgrade to 2.4.21 if possible. > > > > > > > > > there are also 1.3-pre6 patches for 2.4.20 (not only for 2.4.21) on oss: > > > > ftp://oss.sgi.com/projects/xfs/download/Release-1.3/pre6 > > > > Christian > > The patch I downloaded was the xfs-2.4.21-all-i386 patch. That is for > 1.2 I hope. > nope, it's more similar to 1.3pre. Christian From owner-linux-xfs@oss.sgi.com Thu Aug 21 14:36:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 14:36:28 -0700 (PDT) Received: from natura.oskuro.net (115.Red-213-96-69.pooles.rima-tde.net [213.96.69.115]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LLaLoO027358 for ; Thu, 21 Aug 2003 14:36:23 -0700 Received: from nubol.int.oskuro.net (nubol.int.oskuro.net [192.168.1.3]) by natura.oskuro.net (Postfix) with ESMTP id 0646F27805 for ; Thu, 21 Aug 2003 23:36:14 +0200 (CEST) Received: by nubol.int.oskuro.net (Postfix, from userid 1000) id BFFBD70A746; Thu, 21 Aug 2003 23:36:14 +0200 (CEST) Date: Thu, 21 Aug 2003 23:36:14 +0200 From: Jordi Mallach To: linux-xfs@oss.sgi.com Subject: Compile error on 2.6.0-test3 Message-ID: <20030821213614.GA15890@nubol.int.oskuro.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline User-Agent: Mutt/1.5.4i X-archive-position: 124 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jordi@sindominio.net Precedence: bulk X-list: linux-xfs Content-Length: 1723 Lines: 58 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I have searched the archive for this problem, but haven't found anything related. I have been trying to compile Linux 2.6.0-test3 without luck. The build dies at: CC fs/xfs/xfs_alloc.o In file included from fs/xfs/xfs_alloc.c:42: fs/xfs/xfs_sb.h:1:1: warning: null character(s) ignored fs/xfs/xfs_sb.h:1:1: warning: no newline at end of file In file included from fs/xfs/xfs_alloc.c:46: fs/xfs/xfs_mount.h:286: syntax error before "xfs_sb_t" fs/xfs/xfs_mount.h:286: warning: no semicolon at end of struct or union fs/xfs/xfs_mount.h:387: syntax error before '}' token fs/xfs/xfs_mount.h:387: warning: type defaults to `int' in declaration of `= xfs_mount_t' fs/xfs/xfs_mount.h:387: warning: data definition has no type or storage cla= ss fs/xfs/xfs_mount.h:506: syntax error before '*' token [... and more...] I have tried -mm2 and -mm3, no changes, I also have tried going back to gcc 3.2, same result. This is a Debian sid box: gcc-3.3, glibc 2.3.2. 2.6.0-test2 compiled just fine, it's the kernel I'm running right now. Any clues? Thanks, Jordi --=20 Jordi Mallach P=E9rez -- Debian developer http://www.debian.org/ jordi@sindominio.net jordi@debian.org http://www.sindominio.net/ GnuPG public key information available at http://oskuro.net/~jordi/ --k1lZvvs/B4yU6o8G Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/RTtOJYSUupF6Il4RAtk3AKCyUDPPfdTlHqsu2mTipLQtylLeTwCaAwnK 07CIK5yETezo6dAe8RYnki8= =8kZ3 -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G-- From owner-linux-xfs@oss.sgi.com Thu Aug 21 15:43:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 15:43:05 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LMh0oO030436 for ; Thu, 21 Aug 2003 15:43:00 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7LMgtq0020390 for ; Thu, 21 Aug 2003 15:42:55 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7LMfrGi9048909; Thu, 21 Aug 2003 17:41:54 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7LMUawg18087762; Thu, 21 Aug 2003 17:30:36 -0500 (CDT) Subject: Re: kernel rpms for older RH? From: Eric Sandeen To: Net Llama! Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1061505036.4068.14.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 21 Aug 2003 17:30:36 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 125 X-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: 604 Lines: 19 It should be trivial to re-spin into an older distro's kernel, if you want to do that (i.e. the same version of kernel, but for 7.3 or 8.0) The patches have been structured so that rh9 uniqueness is in distinct patches. -Eric On Thu, 2003-08-21 at 15:21, Net Llama! wrote: > Hi, > I've noticed that all of the recent Release-1.3-preX kernel_rpms are in a > Redhat9 subdirectory. Does this imply that those kernel RPMs will not > work on RH-7.3 (the XFS version)? > > thanks! -- Eric Sandeen [C]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 Aug 21 15:51:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 15:51:36 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LMpLoO031238 for ; Thu, 21 Aug 2003 15:51:22 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 5988614E8E21; Fri, 22 Aug 2003 00:25:43 +0200 (CEST) Date: Fri, 22 Aug 2003 00:25:42 +0200 From: Andi Kleen To: Bernd Petrovitsch Cc: linux-xfs@oss.sgi.com Subject: Re: The X in XFS Message-ID: <20030821222542.GB290@wotan.suse.de> References: <1061482171.1797.65.camel@jen.americas.sgi.com> <20030821184329.GA11855@chihiro.cern.ch> <1061500513.1094.4.camel@gimli.at.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1061500513.1094.4.camel@gimli.at.home> X-archive-position: 126 X-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: 25 On Thu, Aug 21, 2003 at 11:15:13PM +0200, Bernd Petrovitsch wrote: > On Thu, 2003-08-21 at 20:43, KELEMEN Peter wrote: > > * Steve Lord (lord@sgi.com) [20030821 11:09]: > > > > > Originally the project was internally refered to as xFS, > > > presumably until marketing came up with a letter or name which > > > was deemed acceptable. After a while the x just stuck without > > > having a meaning assigned to it, and it was capitalized. > > > > It should be noted that there is a Serverless Network File System > > from Berkeley that is precisely called "xFS", as you can see at > > http://now.cs.berkeley.edu/Xfs/xfs.html . Also, there are other > > products named "XFS", for example a popular NFS client for DOS. > > http://www.tux.org/pub/distributions/SuSE/i386/8.2/dosutils/xfs186/xfs.txt > > Two more: > - xfs - the X font server > - the XMethods Filesystem - http://www.xmethods.net/xfs/ (adding more trivia to this useful thread) The kernel part of the arla client (alternative AFS) is also often called xfs. -Andi From owner-linux-xfs@oss.sgi.com Thu Aug 21 15:55:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 15:55:10 -0700 (PDT) Received: from lists.vasoftware.com (mail@lists.vasoftware.com [198.186.202.171]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LMt6oO031775 for ; Thu, 21 Aug 2003 15:55:07 -0700 Received: from adsl-64-175-248-6.dsl.sntc01.pacbell.net ([64.175.248.6]:63166 helo=linux-sxs.org) by lists.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.20 #1 (Debian)) id 19pyKB-0002Ht-9I by authid with fixed_plain; Thu, 21 Aug 2003 15:54:35 -0700 Message-ID: <3F454D9B.50201@linux-sxs.org> Date: Thu, 21 Aug 2003 15:54:19 -0700 From: "Net Llama!" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030625 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: kernel rpms for older RH? References: <1061505036.4068.14.camel@stout.americas.sgi.com> In-Reply-To: <1061505036.4068.14.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: lists.vasoftware.com 19pyKB-0002Ht-9I 4fbcb446ceb3abad0b3b64c981ea30c7 X-Spam-Score: -2.6 (--) X-archive-position: 127 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 934 Lines: 29 Ok, but the RPM, as-is, would not be ok to install on a RH-7.3 system? I'm looking to avoid having to do any rework. On 08/21/03 15:30, Eric Sandeen wrote: > It should be trivial to re-spin into an older distro's kernel, if you > want to do that (i.e. the same version of kernel, but for 7.3 or 8.0) > > The patches have been structured so that rh9 uniqueness is in distinct > patches. > > -Eric > > On Thu, 2003-08-21 at 15:21, Net Llama! wrote: > >>Hi, >>I've noticed that all of the recent Release-1.3-preX kernel_rpms are in a >>Redhat9 subdirectory. Does this imply that those kernel RPMs will not >>work on RH-7.3 (the XFS version)? >> >>thanks! -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 3:50pm up 6 days, 4:18, 1 user, load average: 0.02, 0.07, 0.04 From owner-linux-xfs@oss.sgi.com Thu Aug 21 16:37:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 16:37:58 -0700 (PDT) Received: from smtp101.mail.sc5.yahoo.com (smtp101.mail.sc5.yahoo.com [216.136.174.139]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LNbgoO001424 for ; Thu, 21 Aug 2003 16:37:43 -0700 Received: from adsl-209-233-25-155.dsl.snfc21.pacbell.net (HELO inRAID007) (dankoren@209.233.25.155 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 21 Aug 2003 23:22:11 -0000 Message-ID: <049301c3683b$05fa3a30$0400a8c0@inRAID007> Reply-To: "Dan Koren" From: "Dan Koren" To: "Steve Lord" , References: <1061482171.1797.65.camel@jen.americas.sgi.com> Subject: Re: The X in XFS Date: Thu, 21 Aug 2003 16:22:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 128 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dankoren@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 1193 Lines: 49 Hi Steve, Sorry to disagree with you, but X really did stand for something. The early design documents (which may have vanished by the time Cray was acquired) referred to the "eXtended File System". Incidentally, XFS was developed in Mountain View, not in Eagan ;-) Dan Koren ----- Original Message ----- From: "Steve Lord" To: Sent: Thursday, August 21, 2003 9:09 AM Subject: The X in XFS > Just in case you were wondering what X stood for in XFS - some folks > out there seem to be putting the X in the middle of words recently. > > The X does not stand for anything except X, it is not eXtent, or > eXtended or any other word. > > Originally the project was internally refered to as xFS, presumably > until marketing came up with a letter or name which was deemed > acceptable. After a while the x just stuck without having a > meaning assigned to it, and it was capitalized. > > Think of it as a little like the G in GNU, the X in XFS stands > for XFS ;-) > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > > > From owner-linux-xfs@oss.sgi.com Thu Aug 21 17:01:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 17:01:39 -0700 (PDT) Received: from hotmail.com (law9-oe39.law9.hotmail.com [64.4.8.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M01WoO002880 for ; Thu, 21 Aug 2003 17:01:32 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Aug 2003 17:01:26 -0700 Received: from 80.128.33.249 by law9-oe39.law9.hotmail.com with DAV; Fri, 22 Aug 2003 00:01:26 +0000 X-Originating-IP: [80.128.33.249] X-Originating-Email: [k_leibrandt@hotmail.com] From: "Kai Leibrandt" To: Subject: RE: The X in XFS Date: Fri, 22 Aug 2003 02:01:18 +0200 Message-ID: <000001c36840$8360ca20$0c00a8c0@Legolas> 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 In-Reply-To: <049301c3683b$05fa3a30$0400a8c0@inRAID007> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 22 Aug 2003 00:01:26.0963 (UTC) FILETIME=[88408030:01C36840] X-archive-position: 129 X-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: 1735 Lines: 70 I thought the original filesystem for Irix, EFS, was the Extended File System ?! If it wasn't, then what did EFS stand for? Someone pleeaaaase clear this oh-so unimportant trivia up! Kai. > -----Original Message----- > From: linux-xfs-bounce@oss.sgi.com > [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Dan Koren > Sent: 22 August 2003 01:22 > To: Steve Lord; linux-xfs@oss.sgi.com > Subject: Re: The X in XFS > > > > > Hi Steve, > > > Sorry to disagree with you, but X really did stand > for something. The early design documents (which > may have vanished by the time Cray was acquired) > referred to the "eXtended File System". > > Incidentally, XFS was developed in Mountain View, > not in Eagan ;-) > > > > Dan Koren > > > ----- Original Message ----- > From: "Steve Lord" > To: > Sent: Thursday, August 21, 2003 9:09 AM > Subject: The X in XFS > > > > Just in case you were wondering what X stood for in XFS - > some folks > > out there seem to be putting the X in the middle of words recently. > > > > The X does not stand for anything except X, it is not eXtent, or > > eXtended or any other word. > > > > Originally the project was internally refered to as xFS, presumably > > until marketing came up with a letter or name which was deemed > > acceptable. After a while the x just stuck without having a meaning > > assigned to it, and it was capitalized. > > > > Think of it as a little like the G in GNU, the X in XFS > stands for XFS > > ;-) > > > > Steve > > > > -- > > > > Steve Lord voice: > +1-651-683-3511 > > Principal Engineer, Filesystem Software email: lord@sgi.com > > > > > > > > > From owner-linux-xfs@oss.sgi.com Thu Aug 21 17:16:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 17:17:13 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M0GvoO003869 for ; Thu, 21 Aug 2003 17:16:58 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7M0Gpq0000458 for ; Thu, 21 Aug 2003 17:16:51 -0700 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 KAA26075; Fri, 22 Aug 2003 10:16:47 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7M0GjmY045623; Fri, 22 Aug 2003 10:16:46 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7M0FH6U001040; Fri, 22 Aug 2003 10:15:17 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7M0FGQA001038; Fri, 22 Aug 2003 10:15:16 +1000 Date: Fri, 22 Aug 2003 10:15:16 +1000 From: Nathan Scott To: Jordi Mallach Cc: linux-xfs@oss.sgi.com Subject: Re: Compile error on 2.6.0-test3 Message-ID: <20030822001516.GA823@frodo> References: <20030821213614.GA15890@nubol.int.oskuro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030821213614.GA15890@nubol.int.oskuro.net> User-Agent: Mutt/1.5.3i X-archive-position: 130 X-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: 701 Lines: 27 On Thu, Aug 21, 2003 at 11:36:14PM +0200, Jordi Mallach wrote: > Hi, > > I have searched the archive for this problem, but haven't found > anything related. > > I have been trying to compile Linux 2.6.0-test3 without luck. The build > dies at: > > > CC fs/xfs/xfs_alloc.o > In file included from fs/xfs/xfs_alloc.c:42: > fs/xfs/xfs_sb.h:1:1: warning: null character(s) ignored > fs/xfs/xfs_sb.h:1:1: warning: no newline at end of file > [... and more...] > > I have tried -mm2 and -mm3, no changes, I also have tried going back to > gcc 3.2, same result. Looks like your source tree is corrupted possibly - whats in xfs_sb.h? Try getting a fresh copy of the source. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 21 17:23:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 17:23:32 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M0NHoO004802 for ; Thu, 21 Aug 2003 17:23:18 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7M0dunk023197 for ; Thu, 21 Aug 2003 19:39:56 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7M0NBGe9101689 for ; Thu, 21 Aug 2003 19:23:11 -0500 (CDT) Received: from naboo (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7M0NBRn222104276 for ; Thu, 21 Aug 2003 19:23:11 -0500 (CDT) Subject: pre [ANNOUNCE] XFS 1.3.0 From: Russell Cattelan To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1061511791.19226.22.camel@naboo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4-2mdk Date: Thu, 21 Aug 2003 19:23:11 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 131 X-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: 137 Lines: 7 Ok it's official there on oss.sgi.com We'll do a more formal announcement when we are not so tired. -Russell Cattelan cattelan@xfs.org From owner-linux-xfs@oss.sgi.com Thu Aug 21 17:26:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 17:26:34 -0700 (PDT) Received: from jaguar.mkp.net (jaguar.mkp.net [66.11.169.42]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M0QUoO005309 for ; Thu, 21 Aug 2003 17:26:31 -0700 Received: from wilson.mkp.net (rover.mkp.net [209.217.122.9]) by jaguar.mkp.net (Postfix) with ESMTP id 99421177F4; Thu, 21 Aug 2003 20:26:28 -0400 (EDT) Received: (from mkp@localhost) by wilson.mkp.net (8.11.6/8.11.6) id h7M0QPU05235; Thu, 21 Aug 2003 20:26:25 -0400 X-Authentication-Warning: wilson.mkp.net: mkp set sender to mkp@mkp.net using -f To: "Kai Leibrandt" Cc: Subject: Re: The X in XFS From: "Martin K. Petersen" Organization: mkp.net References: <000001c36840$8360ca20$0c00a8c0@Legolas> Date: 21 Aug 2003 20:26:25 -0400 In-Reply-To: <000001c36840$8360ca20$0c00a8c0@Legolas> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 132 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mkp@mkp.net Precedence: bulk X-list: linux-xfs Content-Length: 321 Lines: 11 >>>>> "Kai" == Kai Leibrandt writes: Kai> I thought the original filesystem for Irix, EFS, was the Extended Kai> File System ?! If it wasn't, then what did EFS stand for? Extent File System. -- Martin K. Petersen Wild Open Source, Inc. mkp@wildopensource.com http://www.wildopensource.com/ From owner-linux-xfs@oss.sgi.com Thu Aug 21 17:29:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 17:29:44 -0700 (PDT) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M0TdoO006123 for ; Thu, 21 Aug 2003 17:29:39 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7LMUkQa008380 for ; Thu, 21 Aug 2003 15:30:47 -0700 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 KAA26253; Fri, 22 Aug 2003 10:29:31 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7M0TUmY044397; Fri, 22 Aug 2003 10:29:30 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7M0S26U001083; Fri, 22 Aug 2003 10:28:02 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7M0S18P001081; Fri, 22 Aug 2003 10:28:01 +1000 Date: Fri, 22 Aug 2003 10:28:01 +1000 From: Nathan Scott To: Andi Kleen Cc: linux-xfs@oss.sgi.com Subject: Re: bad log entries after remount with XFS over MD in 2.6 Message-ID: <20030822002801.GB823@frodo> References: <20030821194432.GA12755@averell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030821194432.GA12755@averell> User-Agent: Mutt/1.5.3i X-archive-position: 133 X-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: 2162 Lines: 56 hi Andi, On Thu, Aug 21, 2003 at 09:44:32PM +0200, Andi Kleen wrote: > > I have an XFS over a MD-0 (RAID-0) device stripped over two SCSI disks. > > The problem is that after a reboot the mount often fails with > "bad clientid". This happens both when the file system was cleanly > unmounted (even explicitely before shutdown) or when the machine > crashed. > > I can remount again when I run xfs_repair -L first, but that always > takes a long time. Also it tends to find some old files and reconnect > them to lost+found. FWIW, you can use xfs_db to just write a fresh log, might be quicker for you in this situation. Use the "uuid rewrite" command. Oh, actually I might have added the dirty log check in there too (ala xfs_repair) - you might need to hack it a bit (maybe add a -L to the uuid command) - I can't remember off the top of my head. > The log dump starts with an umount record, but XFS seems to read beyond > that and find bogus log entries and then fail on them. > Why does it not stop on the first? Cos the first may not be the last. ;) (mount; unmount; mount; unmount; mount; ...) Recovery doesn't really look inside the payload of each log record until it has a good idea of exactly where the log head and tail are. Other than this I have no hints. I don't see this behaviour on non-MD devices just as a data point. From your logprint it looks like the log writes are the problem (as opposed to the log reads that recovery does). We do funky stuff there - write different size chunks at arbitrary 512 byte offsets... has caused problems for busted drivers in the past, maybe something along those lines again. >... > > ============================================================================ > cycle: 1 version: 1 lsn: 1,55 tail_lsn: 1,39 > length of Log Record: 16956 prev offset: 41 num ops: 183 > uuid: f272d169-808f-4627-9fa9-873b504e76b5 format: little endian linux > ********************************************************************** > * ERROR: data block=55 * > ********************************************************************** > Bad Log > -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 21 17:30:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 17:30:36 -0700 (PDT) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M0UWoO006350 for ; Thu, 21 Aug 2003 17:30:32 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7LMVeQa008593 for ; Thu, 21 Aug 2003 15:31:40 -0700 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 KAA26279; Fri, 22 Aug 2003 10:30:24 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7M0UNmY045568; Fri, 22 Aug 2003 10:30:24 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h7M0Su6U001106; Fri, 22 Aug 2003 10:28:56 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7M0StFi001104; Fri, 22 Aug 2003 10:28:55 +1000 Date: Fri, 22 Aug 2003 10:28:55 +1000 From: Nathan Scott To: Kai Leibrandt Cc: linux-xfs@oss.sgi.com Subject: Re: The X in XFS Message-ID: <20030822002855.GC823@frodo> References: <049301c3683b$05fa3a30$0400a8c0@inRAID007> <000001c36840$8360ca20$0c00a8c0@Legolas> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c36840$8360ca20$0c00a8c0@Legolas> User-Agent: Mutt/1.5.3i X-archive-position: 134 X-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: 488 Lines: 24 On Fri, Aug 22, 2003 at 02:01:18AM +0200, Kai Leibrandt wrote: > I thought the original filesystem for Irix, EFS, was the Extended File > System ?! If it wasn't, then what did EFS stand for? > > Someone pleeaaaase clear this oh-so unimportant trivia up! On IRIX... efs(4) efs(4) NAME efs - layout of the Extent File System SYNOPSIS #include #include cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 21 17:43:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 17:43:13 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M0h8oO007355 for ; Thu, 21 Aug 2003 17:43:09 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7M0xjnk030800 for ; Thu, 21 Aug 2003 19:59:48 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7M0gxGg9043367; Thu, 21 Aug 2003 19:43:00 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-5.corp.sgi.com [134.15.64.5]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7M0d7Rn239048136; Thu, 21 Aug 2003 19:39:07 -0500 (CDT) Subject: Re: The X in XFS From: Steve Lord To: Dan Koren Cc: linux-xfs@oss.sgi.com In-Reply-To: <049301c3683b$05fa3a30$0400a8c0@inRAID007> References: <1061482171.1797.65.camel@jen.americas.sgi.com> <049301c3683b$05fa3a30$0400a8c0@inRAID007> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 21 Aug 2003 19:39:08 -0500 Message-Id: <1061512750.1622.43.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 135 X-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: 680 Lines: 30 On Thu, 2003-08-21 at 18:22, Dan Koren wrote: > > > Hi Steve, > > > Sorry to disagree with you, but X really did stand > for something. The early design documents (which > may have vanished by the time Cray was acquired) > referred to the "eXtended File System". > > Incidentally, XFS was developed in Mountain View, > not in Eagan ;-) > Dan, I had checked this with Doug Doucette who predates me as well as you, and he confirmed this. I never said XFS was originally developed in Eagan. You will find Doug's name on a lot of design papers which have been on the web here for a couple of years now. http://oss.sgi.com/projects/xfs/design_docs/xfsdocs93_pdf/ Steve From owner-linux-xfs@oss.sgi.com Thu Aug 21 17:51:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 17:51:51 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M0pYoO008071 for ; Thu, 21 Aug 2003 17:51:34 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7M0pSq0005877 for ; Thu, 21 Aug 2003 17:51:29 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7M0oSGe9074744; Thu, 21 Aug 2003 19:50:28 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-5.corp.sgi.com [134.15.64.5]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7M0oLRn243087121; Thu, 21 Aug 2003 19:50:21 -0500 (CDT) Subject: Re: Compile error on 2.6.0-test3 From: Steve Lord To: Jordi Mallach Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030821213614.GA15890@nubol.int.oskuro.net> References: <20030821213614.GA15890@nubol.int.oskuro.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 21 Aug 2003 19:50:22 -0500 Message-Id: <1061513424.1622.50.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 136 X-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: 646 Lines: 20 On Thu, 2003-08-21 at 16:36, Jordi Mallach wrote: > Hi, > > I have searched the archive for this problem, but haven't found > anything related. > > I have been trying to compile Linux 2.6.0-test3 without luck. The build > dies at: This really looks like you have corrupted code in your tree, you should probably try removing these files and checking them out again. Doing a reparent and a pull is not going to fix the problem. If you are seeing the same problem in different bitkeeper trees pulled from several sources then something bigger is going on. My trees build just fine, but I may not be pulling from the same place you are. Steve From owner-linux-xfs@oss.sgi.com Thu Aug 21 17:55:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 17:55:43 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M0tboO008586 for ; Thu, 21 Aug 2003 17:55:38 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7M1CHnk002034 for ; Thu, 21 Aug 2003 20:12:17 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7M0tWGe9118858; Thu, 21 Aug 2003 19:55:32 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-5.corp.sgi.com [134.15.64.5]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7M0tURn244594681; Thu, 21 Aug 2003 19:55:31 -0500 (CDT) Subject: Re: Hang when mounting XFS root in 2.6.0 tests on x86-64 From: Steve Lord To: Andi Kleen Cc: Chris Meadors , Linux Kernel , 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-11) Date: 21 Aug 2003 19:55:32 -0500 Message-Id: <1061513734.1622.55.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 137 X-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: 1532 Lines: 44 On Thu, 2003-08-21 at 16:00, Andi Kleen wrote: > Chris Meadors writes: > > Better report it to linux-xfs@oss.sgi.com (cc'ed) too. > > > I'm trying to get a 2.6.0-test kernel to boot on my Opteron system. It > > has SuSE's 2.4.19-SMP kernel on it now, and it boots with that, mounts > > the XFS root just fine. But I build a vanilla 2.6.0-test3 with no > > module support, everything included that I would need. The last line > > that it prints during boot is the NET4.0 > > > > Repeated presses of Alt+SysRq+P seems to show RIP looping in xfs_xlatesb > > and xfs_lowbit64. Seems to suggest a platform specific problem with this code, Andi, didn't you write the function behind xfs_lowbit64? > > > > I've tried -test3-bk9 and also went back to -test2 and -test1. > > > > Earlier when playing with this machine I built 2.6.0-test3 with a 32 bit > > only version of gcc, but still optimized for the Opteron. This one had > > no problem booting and mounting the XFS root. > > > > This is easy to reproduce, so let me know if more information is needed. > > I test XFS (but not as root) occasionally on x86-64 and seen no problems > so far. I haven't tested it with test2+ yet though. This code chunk will be the same no matter which filesystem you are mounting, if the hang happened on an xfs root, I would expect to see it on any xfs filesystem with that kernel. > > What compiler are you using? > Some disassembly output and help from someone who can read it might be in order here. Steve From owner-linux-xfs@oss.sgi.com Thu Aug 21 18:33:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 18:33:17 -0700 (PDT) Received: from blake.timetraveller.org (blake.timetraveller.org [203.23.43.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M1WxoO010269 for ; Thu, 21 Aug 2003 18:33:01 -0700 Received: from zen.canint.timetraveller.org (CPE00105ae6b1e1-CM000039aeec61.cpe.net.cable.rogers.com [63.139.6.84]) by blake.timetraveller.org (8.12.3/8.12.3) with ESMTP id h7M1Wjnk017696 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 22 Aug 2003 11:32:49 +1000 Received: from zen.canint.timetraveller.org (zen.canint.timetraveller.org [192.168.120.1]) by zen.canint.timetraveller.org (8.12.9/8.12.9) with ESMTP id h7M1Wimk013883; Thu, 21 Aug 2003 21:32:44 -0400 Date: Thu, 21 Aug 2003 21:32:44 -0400 (EDT) From: Robert Brockway X-X-Sender: robert@zen.canint.timetraveller.org To: linux-xfs@oss.sgi.com cc: postmaster@xfs.org Subject: MX record problem for xfs.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 138 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert@timetraveller.org Precedence: bulk X-list: linux-xfs Content-Length: 598 Lines: 19 Did someone miss a . in the zone file perhaps? :) blake:~$ host -t mx xfs.org xfs.org mail is handled by 5 lips.thebarn.COM. xfs.org mail is handled by 10 scream.digitalelves.com.xfs.org. blake:~$ host scream.digitalelves.com.xfs.org Host scream.digitalelves.com.xfs.org not found: 3(NXDOMAIN) blake:~$ host scream.digitalelves.com scream.digitalelves.com has address 65.31.120.169 Rob -- Robert Brockway B.Sc. email: robert@timetraveller.org, zzbrock@uqconnect.net Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah From owner-linux-xfs@oss.sgi.com Thu Aug 21 19:21:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 19:21:25 -0700 (PDT) Received: from blake.timetraveller.org (blake.timetraveller.org [203.23.43.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M2LFoO012925 for ; Thu, 21 Aug 2003 19:21:19 -0700 Received: from zen.canint.timetraveller.org (CPE00105ae6b1e1-CM000039aeec61.cpe.net.cable.rogers.com [63.139.6.84]) by blake.timetraveller.org (8.12.3/8.12.3) with ESMTP id h7M2Kunk018083 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 22 Aug 2003 12:21:05 +1000 Received: from zen.canint.timetraveller.org (zen.canint.timetraveller.org [192.168.120.1]) by zen.canint.timetraveller.org (8.12.9/8.12.9) with ESMTP id h7M2Ksmk014321; Thu, 21 Aug 2003 22:20:55 -0400 Date: Thu, 21 Aug 2003 22:20:54 -0400 (EDT) From: Robert Brockway X-X-Sender: robert@zen.canint.timetraveller.org To: linux-xfs@oss.sgi.com cc: postmaster@xfs.org Subject: Re: MX record problem for xfs.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 139 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert@timetraveller.org Precedence: bulk X-list: linux-xfs Content-Length: 2066 Lines: 60 The plot thickens: blake & zen are both Linux boxes running on opposite sides of the planet (network wise and physically). zen is running XFS btw :) blake:~$ host -t soa xfs.org xfs.org SOA xfs.org. cattelan.xfs.org. 2003032000 86400 3600 3600000 86400 blake:~$ host -t mx xfs.org xfs.org mail is handled by 5 lips.thebarn.COM. xfs.org mail is handled by 10 scream.digitalelves.com.xfs.org. zen:~$ host -t soa xfs.org xfs.org SOA xfs.org cattelan.xfs.org ( 2003032000 ;serial (version) 86400 ;refresh period (1 day) 3600 ;retry interval (1 hour) 3600000 ;expire time (5 weeks, 6 days, 16 hours) 86400 ;default ttl (1 day) ) zen:~$ host -t mx xfs.org xfs.org MX 10 scream.digitalelves.COM xfs.org MX 5 lips.thebarn.COM Same SOA serial but different MX results. Also worth noting: blake:~$ host -t ns xfs.org xfs.org name server lips.thebarn.COM. xfs.org name server NS1.DOLPHINSTAFFING.COM. xfs.org name server coco.macktronics.COM. blake:~$ host NS1.DOLPHINSTAFFING.COM. Host NS1.DOLPHINSTAFFING.COM not found: 3(NXDOMAIN) zen:~$ host -t ns xfs.org C5.NSTLD.COM xfs.org NS NS1.DOLPHINSTAFFING.COM xfs.org NS COCO.MACKTRONICS.COM C5.NSTLD.COM is authorative for .org. Results from other servers authorative for .org that I tested were consistent (although I didn't query them all). The SOA for xfs.org should also contain the name of the primary name server, not the domain itself (see SOA lines above). So is this an SGI owned domain? The whois doesn't actually suggest so but Russell did make an official sounding announcement about 1.3.0 :) Ok, I'm off to clean up my desk. Rob -- Robert Brockway B.Sc. email: robert@timetraveller.org, zzbrock@uqconnect.net Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah From owner-linux-xfs@oss.sgi.com Thu Aug 21 20:24:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 20:24:17 -0700 (PDT) Received: from hotmail.com (sea2-dav40.sea2.hotmail.com [207.68.164.97]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M3ODoO015596 for ; Thu, 21 Aug 2003 20:24:14 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Aug 2003 20:24:08 -0700 Received: from 209.233.25.155 by sea2-dav40.sea2.hotmail.com with DAV; Fri, 22 Aug 2003 03:24:07 +0000 X-Originating-IP: [209.233.25.155] X-Originating-Email: [koren_dan@hotmail.com] Reply-To: "Dan Koren" From: "Dan Koren" To: "Curtis Anderson" , "Steve Lord" , References: <1061482171.1797.65.camel@jen.americas.sgi.com> <049301c3683b$05fa3a30$0400a8c0@inRAID007> <010901c36849$f64c9060$6901a8c0@Curtis> Subject: Re: The X in XFS Date: Thu, 21 Aug 2003 20:23:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-OriginalArrivalTime: 22 Aug 2003 03:24:08.0082 (UTC) FILETIME=[D8D7FF20:01C3685C] X-archive-position: 140 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: koren_dan@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 2077 Lines: 55 Well, Curtis, everything is fine and dandy with your version. It still does not explain why the XFS Design Specs refer to "eXtended File System" on the front page. That, of course, does not contradict everyone having forgotten by now what that stood for. dk ----- Original Message ----- From: "Curtis Anderson" To: "Dan Koren" ; "Steve Lord" ; Sent: Thursday, August 21, 2003 6:08 PM Subject: Re: The X in XFS > All, > > Dan Koren wrote: > > Sorry to disagree with you, but X really did stand > > for something. The early design documents (which > > may have vanished by the time Cray was acquired) > > referred to the "eXtended File System". > > Fortunately, Steve was in fact correct. The "x" in XFS was originally > a variable, it was actually italicized for quite a while before it "stuck" > and became capitalized. After the original IRIX-based XFS was mostly > written, we (the engineers) made a list of all the filesystems that we > could think of, trying to find some letter that was not used. We couldn't > come to agreement on something that had the right "coolness" and was > not already used by some significant product or project. We'd used the > italic "x" before then, and it started solidifying into "X" after that meeting. > Amusingly, we also tried to come up with a logo for XFS in the same > meeting, but I don't remember anyone actually using a logo afterward. > > > Incidentally, XFS was developed in Mountain View, > > not in Eagan ;-) > > Specifically, at the back of building 7-lower on the old "red brick" SGI > campus in Mountain View, but what does that have to do with anything? > Steve and crew have been quite excellent maintainers and extenders > of XFS and I believe they deserve enormous credit for XFS having a > life outside of the (sadly diminishing) realm of SGI machines. My work > on XFS would be quietly dying now if the current XFS team had not > done such a good job bringing it out into Linux. > > Thanks, > > Curtis From owner-linux-xfs@oss.sgi.com Thu Aug 21 21:07:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 21:07:20 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M47GoO017682 for ; Thu, 21 Aug 2003 21:07:16 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7M47Aq0002910 for ; Thu, 21 Aug 2003 21:07:11 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7M46AGe9169083; Thu, 21 Aug 2003 23:06:10 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7M467wh18105448; Thu, 21 Aug 2003 23:06:07 -0500 (CDT) Date: Thu, 21 Aug 2003 23:06:07 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Dan Koren cc: Curtis Anderson , Steve Lord , Subject: Re: The X in XFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 141 X-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: 685 Lines: 24 Ok, I have nothing better to do this evening... :) I'm looking at the earliest XFS design paper I can find, http://oss.sgi.com/projects/xfs/design_docs/xfsdocs93_pdf/arch.pdf (Curtis' name is at the top of the authors list) I do see "xFS" but I do not see "eXtended." (at least not anywhere near the words "File System." Dan, if you have a different (older?) version, please forward it to me - I'd like to add it to our archive of original xFS documents. -Eric On Thu, 21 Aug 2003, Dan Koren wrote: > > > Well, Curtis, everything is fine and dandy with your > version. It still does not explain why the XFS Design > Specs refer to "eXtended File System" on the front page. From owner-linux-xfs@oss.sgi.com Thu Aug 21 23:25:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 23:26:03 -0700 (PDT) Received: from mail.imgame.net ([66.187.99.50]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M6PloO024632 for ; Thu, 21 Aug 2003 23:25:48 -0700 Received: from 127.0.0.1 (mail.imgame.net [127.0.0.1]) by dummy.domain.name (mail) with SMTP id 9D19C7D6C for ; Fri, 22 Aug 2003 14:23:44 +0800 (PHT) Received: by mail.imgame.net (mail, from userid 48) id 119057D61; Fri, 22 Aug 2003 14:23:44 +0800 (PHT) Received: from 192.168.0.54 (SquirrelMail authenticated user rvfrancisco) by mail.imgame.net with HTTP; Fri, 22 Aug 2003 14:23:44 +0800 (PHT) Message-ID: <1664.192.168.0.54.1061533424.squirrel@mail.imgame.net> Date: Fri, 22 Aug 2003 14:23:44 +0800 (PHT) Subject: PARTITION PROBLEM From: rvfrancisco@imgame.net To: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.0-1.7.x MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-archive-position: 142 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rvfrancisco@imgame.net Precedence: bulk X-list: linux-xfs Content-Length: 642 Lines: 15 Hello, I just want to know is there any way to repartitioning a RAID5 without losing my data? I'm using Adaptec 2120s SCSI Raid controller, Redhat 7.3 O/S, Kernel 2.4.18-18.7.xsmp. My problem is I started raid 5 with 3 SCSI Disk and 1 Hot Spare. Now I need to add 1 SCSI disk to Raid5, I Already add the SCSI disk using hardware Raid5. Before its Partion size is 68G. then after rebuilding it become 102G. But in my problem is when I check my partition in Redhat it is still 68G. How can I repartition Raid5 to expand the capacity? Is there packages needed to repartion my Hardisk? Thanks.... Regards, Rodel Francisco System Administrator From owner-linux-xfs@oss.sgi.com Thu Aug 21 23:32:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 23:32:23 -0700 (PDT) Received: from shell.wgops.com (postfix@shell.wgops.com [66.92.192.108]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M6W4oO027728 for ; Thu, 21 Aug 2003 23:32:04 -0700 Received: from [10.1.2.77] (jobe.wgops.com [10.1.2.77]) by shell.wgops.com (Postfix) with ESMTP id 9B8CFBB; Fri, 22 Aug 2003 00:32:03 -0600 (MDT) Date: Fri, 22 Aug 2003 00:31:38 -0600 From: Michael Loftis To: rvfrancisco@imgame.net, linux-xfs@oss.sgi.com Subject: Re: PARTITION PROBLEM Message-ID: <46408632.1061512298@[10.1.2.77]> In-Reply-To: <1664.192.168.0.54.1061533424.squirrel@mail.imgame.net> References: <1664.192.168.0.54.1061533424.squirrel@mail.imgame.net> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 143 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs Content-Length: 1315 Lines: 38 This is tricky. Yes and no. The RAID5 is hidden by the hardware. your DISK expanded to 102G, but your partitions and possibly your partition table say only 68G. *IF AND ONLY IF (IFF)* the partition you want to expand is not adjacent to (cylinder wise) other partitions (IE it is at the end of the disk) you *should* be able to change the size of the partition, then use xfs_growfs to make it fit the new partition size. Backup your data first. It should work OK, but I am in NO way taking responsibility if it screws up. ;) #include --On Friday, August 22, 2003 2:23 PM +0800 rvfrancisco@imgame.net wrote: > Hello, > > I just want to know is there any way to repartitioning a RAID5 without > losing my data? I'm using Adaptec 2120s SCSI Raid controller, Redhat 7.3 > O/S, Kernel 2.4.18-18.7.xsmp. My problem is I started raid 5 with 3 SCSI > Disk and 1 Hot Spare. Now I need to add 1 SCSI disk to Raid5, I Already > add the SCSI disk using hardware Raid5. Before its Partion size is 68G. > then after rebuilding it become 102G. But in my problem is when I check my > partition in Redhat it is still 68G. How can I repartition Raid5 to expand > the capacity? Is there packages needed to repartion my Hardisk? Thanks.... > > Regards, > Rodel Francisco > System Administrator > > From owner-linux-xfs@oss.sgi.com Thu Aug 21 23:53:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Aug 2003 23:53:57 -0700 (PDT) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M6rdoO031008 for ; Thu, 21 Aug 2003 23:53:40 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla2.xs4all.nl (8.12.9/8.12.9) with ESMTP id h7M6r5MW009915; Fri, 22 Aug 2003 08:53:05 +0200 (CEST) Message-Id: <4.3.2.7.2.20030822085247.02e0f788@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Aug 2003 08:53:03 +0200 To: Andi Kleen , Chris Meadors From: Seth Mos Subject: Re: Hang when mounting XFS root in 2.6.0 tests on x86-64 Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 144 X-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: 577 Lines: 18 At 23:00 21-8-2003 +0200, Andi Kleen wrote: >Chris Meadors writes: > >Better report it to linux-xfs@oss.sgi.com (cc'ed) too. > > > I'm trying to get a 2.6.0-test kernel to boot on my Opteron system. It > > has SuSE's 2.4.19-SMP kernel on it now, and it boots with that, mounts > > the XFS root just fine. But I build a vanilla 2.6.0-test3 with no > > module support, everything included that I would need. The last line > > that it prints during boot is the NET4.0 Boot noapic ? Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Aug 22 00:12:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 00:12:42 -0700 (PDT) Received: from mail.imgame.net ([66.187.99.50]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M7COoO000796 for ; Fri, 22 Aug 2003 00:12:25 -0700 Received: from 127.0.0.1 (mail.imgame.net [127.0.0.1]) by dummy.domain.name (mail) with SMTP id C351B7D70; Fri, 22 Aug 2003 15:10:05 +0800 (PHT) Received: by mail.imgame.net (mail, from userid 48) id EA2B77D6C; Fri, 22 Aug 2003 15:10:04 +0800 (PHT) Received: from 192.168.0.54 (SquirrelMail authenticated user rvfrancisco) by mail.imgame.net with HTTP; Fri, 22 Aug 2003 15:10:04 +0800 (PHT) Message-ID: <1774.192.168.0.54.1061536204.squirrel@mail.imgame.net> Date: Fri, 22 Aug 2003 15:10:04 +0800 (PHT) Subject: [Fwd: Re: PARTITION PROBLEM] From: rvfrancisco@imgame.net To: mloftis@wgops.com Cc: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.0-1.7.x MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-archive-position: 145 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rvfrancisco@imgame.net Precedence: bulk X-list: linux-xfs Content-Length: 1597 Lines: 58 THANK YOU!!! But there is an error in command xfs_growfs. I try this command # xfs_growfs /dev/sdc then an error comes out. xfs_growfs: /dev/sdc is not a filesystem mount point, according to /etc/mtab Thanks alot. Rodel Francisco System Administrator > This is tricky. Yes and no. > > The RAID5 is hidden by the hardware. your DISK expanded to 102G, but your partitions and possibly your partition table say only 68G. *IF AND ONLY IF (IFF)* the partition you want to expand is not adjacent to (cylinder wise) other partitions (IE it is at the end of the disk) you *should* be able to change the size of the partition, then use xfs_growfs to make it fit the new partition size. > > Backup your data first. It should work OK, but I am in NO way taking responsibility if it screws up. ;) > > #include > > > > --On Friday, August 22, 2003 2:23 PM +0800 rvfrancisco@imgame.net wrote: > >> Hello, >> >> I just want to know is there any way to repartitioning a RAID5 without losing my data? I'm using Adaptec 2120s SCSI Raid controller, Redhat 7.3 O/S, Kernel 2.4.18-18.7.xsmp. My problem is I started raid 5 with 3 SCSI Disk and 1 Hot Spare. Now I need to add 1 SCSI disk to Raid5, I Already add the SCSI disk using hardware Raid5. Before its Partion size is 68G. then after rebuilding it become 102G. But in my problem is when I check my >> partition in Redhat it is still 68G. How can I repartition Raid5 to expand >> the capacity? Is there packages needed to repartion my Hardisk? Thanks.... >> >> Regards, >> Rodel Francisco >> System Administrator >> >> > > > > > > From owner-linux-xfs@oss.sgi.com Fri Aug 22 00:25:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 00:25:35 -0700 (PDT) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M7PGoO001621 for ; Fri, 22 Aug 2003 00:25:19 -0700 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <1.016BCCE4@mailhub2.arup.com>; Fri, 22 Aug 2003 8:25:10 +0100 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Fri, 22 Aug 2003 08:25:09 +0100 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Fri, 22 Aug 2003 17:23:57 +1000 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Fri, 22 Aug 2003 17:22:18 +1000 From: "Scott Fagg" To: Subject: [Fwd: Re: PARTITION PROBLEM] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7M7PKoO001625 X-archive-position: 146 X-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.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 1806 Lines: 72 Isn't that more likely to be something like /dev/sdc1 ? What's in /etc/fstab ? Scott Fagg Arup Brisbane (07) 3023 6000 >>> 22/08/2003 5:10:04 PM >>> THANK YOU!!! But there is an error in command xfs_growfs. I try this command # xfs_growfs /dev/sdc then an error comes out. xfs_growfs: /dev/sdc is not a filesystem mount point, according to /etc/mtab Thanks alot. Rodel Francisco System Administrator > This is tricky. Yes and no. > > The RAID5 is hidden by the hardware. your DISK expanded to 102G, but your partitions and possibly your partition table say only 68G. *IF AND ONLY IF (IFF)* the partition you want to expand is not adjacent to (cylinder wise) other partitions (IE it is at the end of the disk) you *should* be able to change the size of the partition, then use xfs_growfs to make it fit the new partition size. > > Backup your data first. It should work OK, but I am in NO way taking responsibility if it screws up. ;) > > #include > > > > --On Friday, August 22, 2003 2:23 PM +0800 rvfrancisco@imgame.net wrote: > >> Hello, >> >> I just want to know is there any way to repartitioning a RAID5 without losing my data? I'm using Adaptec 2120s SCSI Raid controller, Redhat 7.3 O/S, Kernel 2.4.18-18.7.xsmp. My problem is I started raid 5 with 3 SCSI Disk and 1 Hot Spare. Now I need to add 1 SCSI disk to Raid5, I Already add the SCSI disk using hardware Raid5. Before its Partion size is 68G. then after rebuilding it become 102G. But in my problem is when I check my >> partition in Redhat it is still 68G. How can I repartition Raid5 to expand >> the capacity? Is there packages needed to repartion my Hardisk? Thanks.... >> >> Regards, >> Rodel Francisco >> System Administrator >> >> > > > > > > From owner-linux-xfs@oss.sgi.com Fri Aug 22 01:15:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 01:15:55 -0700 (PDT) Received: from khe-mailhub1.eigner.com (khe-mailhub1.eigner.com [194.120.231.246]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M8F4oO003869 for ; Fri, 22 Aug 2003 01:15:06 -0700 Received: from eigner.com (unknown [194.120.231.18]) by khe-mailhub1.eigner.com (Postfix) with ESMTP id 187E3234; Fri, 22 Aug 2003 10:14:21 +0200 (CEST) Message-ID: <3F45D0E0.60806@eigner.com> Date: Fri, 22 Aug 2003 10:14:24 +0200 From: Klaus Strebel Organization: EIGNER Germany GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: de, en, de-de, en-us MIME-Version: 1.0 To: rvfrancisco@imgame.net Cc: linux-xfs@oss.sgi.com Subject: Re: [Fwd: Re: PARTITION PROBLEM] References: <1774.192.168.0.54.1061536204.squirrel@mail.imgame.net> In-Reply-To: <1774.192.168.0.54.1061536204.squirrel@mail.imgame.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-102.4, required 5, EMAIL_ATTRIBUTION -0.50, FWD_MSG -0.30, IN_REP_TO -0.50, REFERENCES -0.50, REPLY_WITH_QUOTES -0.50, USER_AGENT_MOZILLA_UA 0.00, USER_IN_WHITELIST -100.00, X_ACCEPT_LANG -0.10) X-archive-position: 147 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: klaus.strebel@eigner.com Precedence: bulk X-list: linux-xfs Content-Length: 796 Lines: 24 rvfrancisco@imgame.net wrote: > THANK YOU!!! But there is an error in command xfs_growfs. I try this command > # xfs_growfs /dev/sdc then an error comes out. > > xfs_growfs: /dev/sdc is not a filesystem mount point, according to /etc/mtab Hi Francisco, read the message ;-)! xfs_growfs grows the mounted filesystem, you ought to give the mountpoint, not the devicefile. I use ReiserFS, ext3 and XFS on my job and im stumbling regularly (i must admit: allways when a grow a filesystem :-( ), into this trap: one want's the devicefile and the fs unmounted, one want's the devicefile and the fs mounted and one wants the path to the mounted filesystem ... Ciao Klaus -- Klaus Strebel UNIX-Engineer klaus.strebel@eigner.com EIGNER - Precision Lifecycle Management - From owner-linux-xfs@oss.sgi.com Fri Aug 22 02:26:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 02:28:13 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M9QooO008125 for ; Fri, 22 Aug 2003 02:26:52 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id CDC5714EC4D0; Fri, 22 Aug 2003 11:26:44 +0200 (CEST) Date: Fri, 22 Aug 2003 11:26:42 +0200 From: Andi Kleen To: Steve Lord Cc: ak@muc.de, clubneon@hereintown.net, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Hang when mounting XFS root in 2.6.0 tests on x86-64 Message-Id: <20030822112642.46d3f538.ak@suse.de> In-Reply-To: <1061513734.1622.55.camel@laptop.americas.sgi.com> References: <1061513734.1622.55.camel@laptop.americas.sgi.com> X-Mailer: Sylpheed version 0.8.9 (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: 148 X-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: 1608 Lines: 46 On 21 Aug 2003 19:55:32 -0500 Steve Lord wrote: > On Thu, 2003-08-21 at 16:00, Andi Kleen wrote: > > Chris Meadors writes: > > > > Better report it to linux-xfs@oss.sgi.com (cc'ed) too. > > > > > I'm trying to get a 2.6.0-test kernel to boot on my Opteron system. It > > > has SuSE's 2.4.19-SMP kernel on it now, and it boots with that, mounts > > > the XFS root just fine. But I build a vanilla 2.6.0-test3 with no > > > module support, everything included that I would need. The last line > > > that it prints during boot is the NET4.0 > > > > > > Repeated presses of Alt+SysRq+P seems to show RIP looping in xfs_xlatesb > > > and xfs_lowbit64. > > Seems to suggest a platform specific problem with this code, Andi, > didn't you write the function behind xfs_lowbit64? First at least the comment on top of xfs_lowbit64() is not correct. ffs() only handles an 32bit argument, not 64bit. Hope that isn't a problem. Hmm, one difference is that the x86-64 ffs will return 32 on zero, while i386 returns -1. Does this patch fix it? --- linux-2.6.0test3-amd64/include/asm-x86_64/bitops.h-o 2003-07-11 13:34:21.000000000 +0200 +++ linux-2.6.0test3-amd64/include/asm-x86_64/bitops.h 2003-08-22 11:17:53.000000000 +0200 @@ -466,7 +466,7 @@ __asm__("bsfl %1,%0\n\t" "cmovzl %2,%0" - : "=r" (r) : "g" (x), "r" (32)); + : "=r" (r) : "g" (x), "r" (-1)); return r+1; } If that doesn't help I would also try it with -O1 and possibly a different compiler (e.g. gcc 3.2 if you're using 3.3 or the other way round) to rule out a compiler problem -Andi From owner-linux-xfs@oss.sgi.com Fri Aug 22 02:30:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 02:31:19 -0700 (PDT) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M9UjoO008517 for ; Fri, 22 Aug 2003 02:30:46 -0700 Received: (qmail 79846 invoked by uid 3709); 22 Aug 2003 09:30:43 -0000 Date: 22 Aug 2003 11:30:43 +0200 Date: Fri, 22 Aug 2003 11:30:43 +0200 From: Andi Kleen To: Nathan Scott Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: bad log entries after remount with XFS over MD in 2.6 Message-ID: <20030822093043.GA79023@colin2.muc.de> References: <20030821194432.GA12755@averell> <20030822002801.GB823@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030822002801.GB823@frodo> User-Agent: Mutt/1.4.1i X-archive-position: 149 X-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@colin2.muc.de Precedence: bulk X-list: linux-xfs Content-Length: 2161 Lines: 63 [I notice the subject is misleading. It was just an normal umount, not a remount] On Fri, Aug 22, 2003 at 10:28:01AM +1000, Nathan Scott wrote: > hi Andi, > > On Thu, Aug 21, 2003 at 09:44:32PM +0200, Andi Kleen wrote: > > > > I have an XFS over a MD-0 (RAID-0) device stripped over two SCSI disks. > > > > The problem is that after a reboot the mount often fails with > > "bad clientid". This happens both when the file system was cleanly > > unmounted (even explicitely before shutdown) or when the machine > > crashed. > > > > I can remount again when I run xfs_repair -L first, but that always > > takes a long time. Also it tends to find some old files and reconnect > > them to lost+found. > > FWIW, you can use xfs_db to just write a fresh log, might be I currently use xfs_repair -L and then quick Ctrl-C. Not very nice, but seems to work. > quicker for you in this situation. Use the "uuid rewrite" > command. Oh, actually I might have added the dirty log check Thanks for the hint. > in there too (ala xfs_repair) - you might need to hack it a > bit (maybe add a -L to the uuid command) - I can't remember > off the top of my head. > > > The log dump starts with an umount record, but XFS seems to read beyond > > that and find bogus log entries and then fail on them. > > Why does it not stop on the first? > > Cos the first may not be the last. ;) > > (mount; unmount; mount; unmount; mount; ...) > > Recovery doesn't really look inside the payload of each log record > until it has a good idea of exactly where the log head and tail are. > > Other than this I have no hints. I don't see this behaviour on > non-MD devices just as a data point. From your logprint it looks Yes, non-MD works fine for me too. > like the log writes are the problem (as opposed to the log reads > that recovery does). We do funky stuff there - write different > size chunks at arbitrary 512 byte offsets... has caused problems > for busted drivers in the past, maybe something along those lines > again. Possible yes. MD hasn't been exactly trouble free in 2.5 so far with the new BIO code. The log is never cleared on recovery right? -Andi From owner-linux-xfs@oss.sgi.com Fri Aug 22 03:15:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 03:16:22 -0700 (PDT) Received: from sahara.openoffice.nl (openoffice.demon.nl [212.238.150.237]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7MAEqoO015133 for ; Fri, 22 Aug 2003 03:15:34 -0700 Received: by sahara.openoffice.nl (Postfix, from userid 1001) id A77993E29; Fri, 22 Aug 2003 12:14:46 +0200 (CEST) Date: Fri, 22 Aug 2003 12:14:46 +0200 From: Valentijn Sessink To: linux-xfs@oss.sgi.com Subject: Keep media name, overwrite dump Message-ID: <20030822101446.GD6718@openoffice.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.28i X-Message-Flag: Open Office - Linux for the desktop X-archive-position: 150 X-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: 1629 Lines: 37 Hello list, I'm using xfsdump for a couple of machines. The thing I never understood is how exactly the media label is supposed to work. The xfsdump man page says: Labels The operator can specify a label to identify the dump ses­ sion and a label to identify a media object. [...] The media label is used to identify media objects, and is independent of the session label. Each media file on the media object contains a copy of the media label. An error is returned if the operator specifies a media label that does not match the media label on a media object contain­ ing valid media files. Media labels are recorded in the inventory. What I would like to do (and what seems sensible to me) is record a media label, then use those media to make, for example, daily backups. Something like a Monday, Tuesday etc. tape. However, if I specify "-o", xfsdump overwrites the tape without looking (which is documented behaviour, so OK), and without -o it appends to the media (also documented), whichever media name I specify. Is there a way to read the media label (to reuse it)? Even better: is there a way to tell xfsdump to only use media with, let's say, the "TUESDAY" label, and return an error (as per xfsdump(8)) if another media is in the streamer? Can xfsdump overwrite an older dump, while keeping the media name? And, what should I understand from the "An error is returned" remark under Labels in xfsdump(8)? V. -- http://www.openoffice.nl/ Open Office - Linux Office Solutions Valentijn Sessink valentyn+sessink@nospam.openoffice.nl From owner-linux-xfs@oss.sgi.com Fri Aug 22 03:57:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 03:57:16 -0700 (PDT) Received: from sdf.lonestar.org (IDENT:root@ol.freeshell.org [192.94.73.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7MAv0oO016889 for ; Fri, 22 Aug 2003 03:57:00 -0700 Received: from sdf.lonestar.org (IDENT:doubts@vinland.freeshell.org [192.94.73.6]) by sdf.lonestar.org (8.12.9/8.12.8) with ESMTP id h7MAux0P012159 for ; Fri, 22 Aug 2003 10:56:59 GMT Received: (from doubts@localhost) by sdf.lonestar.org (8.12.9/8.12.8/Submit) id h7MAuwdJ028034 for linux-xfs@oss.sgi.com; Fri, 22 Aug 2003 10:56:58 GMT Date: Fri, 22 Aug 2003 10:56:58 +0000 From: Doubter To: linux-xfs@oss.sgi.com Subject: problems compiling 2.4.20 + xfs 1.3.0pre6 Message-ID: <20030822105658.GB18132@SDF.LONESTAR.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 151 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: doubts@sdf.lonestar.org Precedence: bulk X-list: linux-xfs Content-Length: 2336 Lines: 62 Surely doing something wrong... I got ftp://kernel.org/pub/linux/kernel/v2.4/linux-2.4.20.tar.bz2 then ftp://oss.sgi.com/projects/xfs/Release-1.3/pre6/kernel_patches/linux-2.4.20-core-xfs-1.3.0.patch.gz and ftp://oss.sgi.com/projects/xfs/Release-1.3/pre6/kernel_patches/linux-xfs-1.3.0pre6.patch.gz putting all together... tar xfj linux-2.4.20.tar.bz2 gunzip *patch.gz cd linux-2.4.20 patch -p1 < ../linux-2.4.20-core-xfs-1.3.0.patch patch -p1 < ../linux-xfs-1.3.0pre6.patch cp ../good_config .config make oldconfig make dep make bzImage .. I got gcc -D__KERNEL__ -I/html/kernel/2.4.20/linux-2.4.20/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -I.. -funsigned-char -nostdinc -iwithprefix include -DKBUILD_BASENAME=xfs_super -c -o xfs_super.o xfs_super.c xfs_super.c:859: unknown field `sync_fs' specified in initializer xfs_super.c:859: warning: initialization from incompatible pointer type xfs_super.c:860: duplicate initializer xfs_super.c:860: (near initialization for `linvfs_sops.write_super_lockfs') make[4]: *** [xfs_super.o] Error 1 make[4]: Leaving directory `/html/kernel/2.4.20/linux-2.4.20/fs/xfs/linux' make[3]: *** [first_rule] Error 2 make[3]: Leaving directory `/html/kernel/2.4.20/linux-2.4.20/fs/xfs/linux' make[2]: *** [_subdir_linux] Error 2 make[2]: Leaving directory `/html/kernel/2.4.20/linux-2.4.20/fs/xfs' make[1]: *** [_subdir_xfs] Error 2 make[1]: Leaving directory `/html/kernel/2.4.20/linux-2.4.20/fs' make: *** [_dir_fs] Error 2 With kernel version 2.4.21 and patches linux-xfs-1.3.0pre6.patch.gz and linux-2.4.21-core-xfs-1.3.0.patch.gz applied in same order and way things goes fine, and adapting my 'good_config' kernel config file to 2.4.21 it compiles and boots with all support and xfs running AFAIK fine (you known, I was very upset by sync issues posted as 07/30/2003 by Blair B. about 'different behaviour between XFS and ext3', patched now). Is 1.3.0pre6.patch ok for kernel version 2.4.20? May I use other patches? Is the only thing to do move on 2.4.21? (you know, that version number is so ugly ;) Any highligts? BTW, please excuse my poor english.. :) Regards, JML. -- doubts@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org From owner-linux-xfs@oss.sgi.com Fri Aug 22 04:21:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 04:22:29 -0700 (PDT) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7MBL5oO018424 for ; Fri, 22 Aug 2003 04:21:46 -0700 Received: from gandalf.virtualdomain.net (lns-th2-4f-81-56-217-5.adsl.proxad.net [81.56.217.5]) by postfix4-2.free.fr (Postfix) with SMTP id B75B6C699 for ; Fri, 22 Aug 2003 13:21:03 +0200 (CEST) Date: Fri, 22 Aug 2003 13:22:13 +0200 From: FD Cami To: linux-xfs@oss.sgi.com Subject: [xfs-1.3] compile problem Message-Id: <20030822132213.675389a4.francois.cami@free.fr> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7MBLkoO018521 X-archive-position: 152 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: francois.cami@free.fr Precedence: bulk X-list: linux-xfs Content-Length: 1372 Lines: 27 Hello, I was trying to get linux-xfs (kernel) to compile on alpha (Sable/EV5 arch) and I encountered a compilation error : gcc -D__KERNEL__ -I/usr/src/linux-2.4.20-xfs/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mno-fp-regs -ffixed-8 -mcpu=ev5 -Wa,-mev6 -I.. -funsigned-char -nostdinc -iwithprefix include -DKBUILD_BASENAME=xfs_lrw -c -o xfs_lrw.o xfs_lrw.c gcc -D__KERNEL__ -I/usr/src/linux-2.4.20-xfs/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mno-fp-regs -ffixed-8 -mcpu=ev5 -Wa,-mev6 -I.. -funsigned-char -nostdinc -iwithprefix include -DKBUILD_BASENAME=xfs_super -c -o xfs_super.o xfs_super.c xfs_super.c:859: unknown field `sync_fs' specified in initializer xfs_super.c:859: warning: initialization from incompatible pointer type make[4]: *** [xfs_super.o] Error 1 make[4]: Leaving directory `/usr/src/linux-2.4.20-xfs/fs/xfs/linux' make[3]: *** [first_rule] Error 2 make[3]: Leaving directory `/usr/src/linux-2.4.20-xfs/fs/xfs/linux' make[2]: *** [_subdir_linux] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.20-xfs/fs/xfs' make[1]: *** [_subdir_xfs] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.20-xfs/fs' make: *** [_dir_fs] Error 2 Please CC me as I'm not on the list. Regards, François From owner-linux-xfs@oss.sgi.com Fri Aug 22 04:31:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 04:32:16 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7MBVxoO019611 for ; Fri, 22 Aug 2003 04:31:59 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h7MBVnq0016762 for ; Fri, 22 Aug 2003 04:31:53 -0700 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 VAA01535; Fri, 22 Aug 2003 21:31:45 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h7MBVimY047346; Fri, 22 Aug 2003 21:31:44 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h7MBVgDr046926; Fri, 22 Aug 2003 21:31:42 +1000 (EST) Date: Fri, 22 Aug 2003 21:31:42 +1000 From: Nathan Scott To: Andi Kleen Cc: linux-xfs@oss.sgi.com Subject: Re: bad log entries after remount with XFS over MD in 2.6 Message-ID: <20030822213142.A47495@wobbly.melbourne.sgi.com> References: <20030821194432.GA12755@averell> <20030822002801.GB823@frodo> <20030822093043.GA79023@colin2.muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030822093043.GA79023@colin2.muc.de>; from ak@colin2.muc.de on Fri, Aug 22, 2003 at 11:30:43AM +0200 X-archive-position: 153 X-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: 1014 Lines: 30 On Fri, Aug 22, 2003 at 11:30:43AM +0200, Andi Kleen wrote: > > > > Recovery doesn't really look inside the payload of each log record > > until it has a good idea of exactly where the log head and tail are. > > > > Other than this I have no hints. I don't see this behaviour on > > non-MD devices just as a data point. From your logprint it looks > > Yes, non-MD works fine for me too. > > > like the log writes are the problem (as opposed to the log reads > > that recovery does). We do funky stuff there - write different > > size chunks at arbitrary 512 byte offsets... has caused problems > > for busted drivers in the past, maybe something along those lines > > again. > > Possible yes. MD hasn't been exactly trouble free in 2.5 so far with > the new BIO code. > > The log is never cleared on recovery right? Thats correct. At the end of recovery the log head and tail both point at the same block and all new log writes proceed from wherever that happens to be in the log. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Aug 22 05:32:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 05:32:35 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7MCWGoO023383 for ; Fri, 22 Aug 2003 05:32:17 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h7MCmvnk017444 for ; Fri, 22 Aug 2003 07:48:57 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h7MCVhGk9299941; Fri, 22 Aug 2003 07:32:11 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-81.corp.sgi.com [134.15.64.81]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7MCPoRn243291206; Fri, 22 Aug 2003 07:25:51 -0500 (CDT) Subject: Re: Building XFS 1.3 under 2.4.20 From: Steve Lord To: Doubter , francois.cami@free.fr Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030822105658.GB18132@SDF.LONESTAR.ORG> References: <20030822105658.GB18132@SDF.LONESTAR.ORG> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 22 Aug 2003 07:25:27 -0500 Message-Id: <1061555129.1978.5.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X