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-archive-position: 154 X-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: 2541 Lines: 76 Responding to two different emails here, both look like the same problem. On Fri, 2003-08-22 at 05:56, Doubter wrote: > 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 > When I wrote that code originally, it was ifdefed for different kernel versions, the sync_fs call does not exist in 2.4.20, this is your problem. You can delete the reference to sync_fs and it should build. Make it look like this in fs/xfs/linux/xfs_super.c #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,21) STATIC int linvfs_sync_super( struct super_block *sb) { vfs_t *vfsp = LINVFS_GET_VFS(sb); int error; VFS_SYNC(vfsp, SYNC_FSDATA|SYNC_WAIT, NULL, error); return -error; } #endif #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,21) .sync_fs = linvfs_sync_super, #endif It looks like this code was not carried forwards when it was merged into 1.3. Steve From owner-linux-xfs@oss.sgi.com Fri Aug 22 05:35:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 05:36:01 -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 h7MCYOoO023679 for ; Fri, 22 Aug 2003 05:35:11 -0700 Received: from nubol.int.oskuro.net (nubol.int.oskuro.net [192.168.1.3]) by natura.oskuro.net (Postfix) with ESMTP id 8890B27870 for ; Fri, 22 Aug 2003 14:34:13 +0200 (CEST) Received: by nubol.int.oskuro.net (Postfix, from userid 1000) id 3246F70A746; Fri, 22 Aug 2003 14:34:12 +0200 (CEST) Date: Fri, 22 Aug 2003 14:34:12 +0200 From: Jordi Mallach To: linux-xfs@oss.sgi.com Subject: Re: Compile error on 2.6.0-test3 Message-ID: <20030822123412.GA20700@nubol.int.oskuro.net> References: <20030821213614.GA15890@nubol.int.oskuro.net> <1061513424.1622.50.camel@laptop.americas.sgi.com> <20030821213614.GA15890@nubol.int.oskuro.net> <20030822001516.GA823@frodo> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline In-Reply-To: <1061513424.1622.50.camel@laptop.americas.sgi.com> <20030822001516.GA823@frodo> Organization: SinDominio X-Operating-System: Debian GNU/Linux sid (Linux 2.6.0-test2 i686) User-Agent: Mutt/1.5.4i X-archive-position: 155 X-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: 1263 Lines: 39 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 22, 2003 at 10:15:16AM +1000, Nathan Scott wrote: > Looks like your source tree is corrupted possibly - whats in xfs_sb.h? > Try getting a fresh copy of the source. On Thu, Aug 21, 2003 at 07:50:22PM -0500, Steve Lord wrote: > This really looks like you have corrupted code in your tree. Thanks. I'm sure I had untarred the stuff at least two times, and was beginning to suspect on a bad patch file (I have a 2.5.50 tarball and a zillion of patch files), but apparently doing it again worked and my build is past the fs/xfs/ stage. Sorry for the annoyance and keep up the good work :) 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/ --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Rg3EJYSUupF6Il4RAo9lAKCFFW96LyK9iE6ej0svFj/wocZbCACg3xs5 lBVMIVhmTasaiFcyQOX21No= =uQpm -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- From owner-linux-xfs@oss.sgi.com Fri Aug 22 09:27:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 09:27: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 h7MGRaoO001296 for ; Fri, 22 Aug 2003 09:27: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 h7MGRUq0026854 for ; Fri, 22 Aug 2003 09:27: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 h7MGQTGe9227968; Fri, 22 Aug 2003 11:26: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 h7MGQRRn244659435; Fri, 22 Aug 2003 11:26:29 -0500 (CDT) Subject: Re: problems compiling 2.4.20 + xfs 1.3.0pre6 From: Russell Cattelan To: Doubter Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030822105658.GB18132@SDF.LONESTAR.ORG> References: <20030822105658.GB18132@SDF.LONESTAR.ORG> Content-Type: text/plain Message-Id: <1061569586.19227.39.camel@naboo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4-2mdk Date: Fri, 22 Aug 2003 11:26:27 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 156 X-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: 2700 Lines: 73 Hmm always something that slips through the cracks. ftp://oss.sgi.com/projects/xfs/Release-1.3/kernel_patches/linux-2.4.20-xfs-1.3.0fixup.patch.gz Guess we haven't built 2.4.20 in a while. On Fri, 2003-08-22 at 05:56, Doubter wrote: > 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 12:58:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 12:58:27 -0700 (PDT) Received: from zero.aec.at (Mowbray.Myles@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7MJvvoO021640 for ; Fri, 22 Aug 2003 12:58:07 -0700 Received: from fred.muc.de (Jomater.Abemy@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id h7MJvmm01073 for ; Fri, 22 Aug 2003 21:57:48 +0200 Received: by fred.muc.de (Postfix on SuSE Linux 7.3 (i386), from userid 500) id AB2625BBBF; Fri, 22 Aug 2003 21:57:51 +0200 (CEST) Date: Fri, 22 Aug 2003 21:57:51 +0200 From: Andi Kleen To: linux-xfs@oss.sgi.com Subject: [PATCH] Fix xfs_lowbit64 Message-ID: <20030822195751.GA18889@averell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 157 X-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: 320 Lines: 17 ffs(0) returns -1, not 0. -Andi --- linux-2.6.0test3/fs/xfs/xfs_bit.c-o 2003-05-27 03:00:41.000000000 +0200 +++ linux-2.6.0test3/fs/xfs/xfs_bit.c 2003-08-22 21:54:53.000000000 +0200 @@ -156,7 +156,7 @@ { int n; n = ffs((unsigned)v); - if (n == 0) { + if (n < 0) { n = ffs(v >> 32); if (n >= 0) n+=32; From owner-linux-xfs@oss.sgi.com Fri Aug 22 13:10:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 13:11:16 -0700 (PDT) Received: from zero.aec.at (Jared.Macphester@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7MKAFoO023827 for ; Fri, 22 Aug 2003 13:10:56 -0700 Received: from fred.muc.de (Joel.Buxter@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id h7MKA8m01121 for ; Fri, 22 Aug 2003 22:10:08 +0200 Received: by fred.muc.de (Postfix on SuSE Linux 7.3 (i386), from userid 500) id 129C85BBBF; Fri, 22 Aug 2003 22:10:13 +0200 (CEST) Date: Fri, 22 Aug 2003 22:10:13 +0200 From: Andi Kleen To: linux-xfs@oss.sgi.com Subject: [PATCH] One more bugfix for xfs_lowbit64 Message-ID: <20030822201012.GA19026@averell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 158 X-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: 583 Lines: 27 (mea culpa). The error return was broken too, it would return -2, not -1 for errors. Makes no difference in the callers, they never check for -1, but is still better to conform to the spec. Includes the previous fix for bits > 32. -Andi --- linux-2.6.0test3/fs/xfs/xfs_bit.c-o 2003-05-27 03:00:41.000000000 +0200 +++ linux-2.6.0test3/fs/xfs/xfs_bit.c 2003-08-22 22:08:14.000000000 +0200 @@ -156,12 +156,12 @@ { int n; n = ffs((unsigned)v); - if (n == 0) { + if (n < 0) { n = ffs(v >> 32); if (n >= 0) n+=32; } - return n-1; + return (n < 0) ? n : n-1; } /* From owner-linux-xfs@oss.sgi.com Fri Aug 22 14:00:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 14:01:02 -0700 (PDT) Received: from stefan.roehri.ch (root@p50838CB5.dip0.t-ipconnect.de [80.131.140.181]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7ML0CoO032405 for ; Fri, 22 Aug 2003 14:00:14 -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 h7ML08LF002414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Aug 2003 23:00:08 +0200 Received: (from sr@localhost) by stefan.roehri.ch (8.12.9/8.12.9/Debian-3) id h7ML08G7002412; Fri, 22 Aug 2003 23:00:08 +0200 Date: Fri, 22 Aug 2003 23:00:08 +0200 From: Stefan Roehrich To: linux-xfs@oss.sgi.com Cc: Tobias Schill Subject: Re: Processes stuck in D state (leading to extremely high load) Message-ID: <20030822210008.GC2270@stefan.roehri.ch> References: <20030821122939.GB1922@stefan.roehri.ch> <20030821135259.GC29202@leathercollection.ph> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20030821135259.GC29202@leathercollection.ph> User-Agent: Mutt/1.5.4i X-MIME-Autoconverted: from 8bit to quoted-printable by stefan.roehri.ch id h7ML08LF002414 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7ML0FoO032422 X-archive-position: 159 X-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: 838 Lines: 20 On 2003-08-21 21:52:59, Federico Sevilla III wrote: > 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 Thank you for the hint, but the XFS filesystems are on an external SCSI storage and we tried with two machines (of the same type) and different memory and processor constellations, so we think a hardware failure (if it's not a design bug in the servers) is not so likely. And it works with the 2.4.21-rc1-xfs kernel CVS version from May, so if it would be a hardware issue, there must be another access pattern or similar things. Stefan -- Stefan Röhrich stefan@roehri.ch, sr@linux.de http://www.roehri.ch/~sr/ From owner-linux-xfs@oss.sgi.com Fri Aug 22 14:05:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 14:06:18 -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 h7ML5ZoO001137 for ; Fri, 22 Aug 2003 14:05: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 h7ML5Uq0005653 for ; Fri, 22 Aug 2003 14:05: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 h7ML4RGo9498517; Fri, 22 Aug 2003 16:04:29 -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 h7ML2DRn245865873; Fri, 22 Aug 2003 16:02:13 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h7ML2Db08006; Fri, 22 Aug 2003 16:02:13 -0500 Subject: Re: [PATCH] One more bugfix for xfs_lowbit64 From: Steve Lord To: Andi Kleen Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030822201012.GA19026@averell> References: <20030822201012.GA19026@averell> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1061586133.6479.6.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 22 Aug 2003 16:02:13 -0500 X-archive-position: 160 X-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: 543 Lines: 18 On Fri, 2003-08-22 at 15:10, Andi Kleen wrote: > (mea culpa). The error return was broken too, it would return -2, > not -1 for errors. Makes no difference in the callers, they never check > for -1, but is still better to conform to the spec. Thanks Andi, this did have to happen one day after 1.3 didn't it. I will push it around various places, time for another push to Linus I guess. 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 22 14:10:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 14:10:24 -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 h7MLA8oO002062 for ; Fri, 22 Aug 2003 14:10:08 -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 h7MLQonk015983 for ; Fri, 22 Aug 2003 16:26:50 -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 h7ML9sGe9487629; Fri, 22 Aug 2003 16:09:54 -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 h7ML9rRn245416181; Fri, 22 Aug 2003 16:09:54 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h7ML9rd08055; Fri, 22 Aug 2003 16:09:53 -0500 Subject: Re: [PATCH] One more bugfix for xfs_lowbit64 From: Steve Lord To: Andi Kleen Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030822201012.GA19026@averell> References: <20030822201012.GA19026@averell> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1061586593.6476.9.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 22 Aug 2003 16:09:53 -0500 X-archive-position: 161 X-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: 939 Lines: 38 On Fri, 2003-08-22 at 15:10, Andi Kleen wrote: > (mea culpa). The error return was broken too, it would return -2, > not -1 for errors. Makes no difference in the callers, they never check > for -1, but is still better to conform to the spec. > > Includes the previous fix for bits > 32. > > -Andi > > --- linux-2.6.0test3/fs/xfs/xfs_bit.c-o 2003-05-27 03:00:41.000000000 +0200 > +++ linux-2.6.0test3/fs/xfs/xfs_bit.c 2003-08-22 22:08:14.000000000 +0200 > @@ -156,12 +156,12 @@ > { > int n; > n = ffs((unsigned)v); > - if (n == 0) { > + if (n < 0) { > n = ffs(v >> 32); > if (n >= 0) > n+=32; > } > - return n-1; > + return (n < 0) ? n : n-1; > } > > /* You know, on second thoughts, are you sure about that? generic_ffs and man ffs seem to suggest otherwise. 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 22 14:49:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 14:49:36 -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 h7MLmVoO008932 for ; Fri, 22 Aug 2003 14:49:10 -0700 Received: (qmail 58147 invoked by uid 3709); 22 Aug 2003 21:48:30 -0000 Date: 22 Aug 2003 23:48:30 +0200 Date: Fri, 22 Aug 2003 23:48:30 +0200 From: Andi Kleen To: Steve Lord Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: [PATCH] One more bugfix for xfs_lowbit64 Message-ID: <20030822214830.GA55918@colin2.muc.de> References: <20030822201012.GA19026@averell> <1061586133.6479.6.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1061586133.6479.6.camel@jen.americas.sgi.com> User-Agent: Mutt/1.4.1i X-archive-position: 162 X-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: 655 Lines: 19 On Fri, Aug 22, 2003 at 04:02:13PM -0500, Steve Lord wrote: > On Fri, 2003-08-22 at 15:10, Andi Kleen wrote: > > (mea culpa). The error return was broken too, it would return -2, > > not -1 for errors. Makes no difference in the callers, they never check > > for -1, but is still better to conform to the spec. > > Thanks Andi, this did have to happen one day after 1.3 didn't it. ;-) I don't think it's very critical, From a quick look none of the callers ever pass in anything more than 32bits. It's used for the number of super block fields, which is < 32 and for some bmap, which seems to be limited to 21 bits by the extractor function. -Andi From owner-linux-xfs@oss.sgi.com Fri Aug 22 14:51:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 14:51:36 -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 h7MLpToO009971 for ; Fri, 22 Aug 2003 14:51:30 -0700 Received: (qmail 58742 invoked by uid 3709); 22 Aug 2003 21:51:28 -0000 Date: 22 Aug 2003 23:51:28 +0200 Date: Fri, 22 Aug 2003 23:51:28 +0200 From: Andi Kleen To: Steve Lord Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: [PATCH] One more bugfix for xfs_lowbit64 Message-ID: <20030822215128.GB55918@colin2.muc.de> References: <20030822201012.GA19026@averell> <1061586593.6476.9.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1061586593.6476.9.camel@jen.americas.sgi.com> User-Agent: Mutt/1.4.1i X-archive-position: 163 X-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: 1506 Lines: 55 On Fri, Aug 22, 2003 at 04:09:53PM -0500, Steve Lord wrote: > On Fri, 2003-08-22 at 15:10, Andi Kleen wrote: > > (mea culpa). The error return was broken too, it would return -2, > > not -1 for errors. Makes no difference in the callers, they never check > > for -1, but is still better to conform to the spec. > > > > Includes the previous fix for bits > 32. > > > > -Andi > > > > --- linux-2.6.0test3/fs/xfs/xfs_bit.c-o 2003-05-27 03:00:41.000000000 +0200 > > +++ linux-2.6.0test3/fs/xfs/xfs_bit.c 2003-08-22 22:08:14.000000000 +0200 > > @@ -156,12 +156,12 @@ > > { > > int n; > > n = ffs((unsigned)v); > > - if (n == 0) { > > + if (n < 0) { > > n = ffs(v >> 32); > > if (n >= 0) > > n+=32; > > } > > - return n-1; > > + return (n < 0) ? n : n-1; > > } > > > > /* > > You know, on second thoughts, are you sure about that? generic_ffs > and man ffs seem to suggest otherwise. The i386 ffs does not agree with the man page. Manpage says 0 for no bit set, but i386 returns -1: static __inline__ int ffs(int x) { int r; __asm__("bsfl %1,%0\n\t" "jnz 1f\n\t" /* zero flag set when zero */ "movl $-1,%0\n" /* -1 for zero */ "1:" : "=r" (r) : "rm" (x)); return r+1; } That's probably a bug in itself, but would be a bit risky to change. If generic_ffs disagrees with that it's very bad. That would be a generic bug. It would be probably safer to use __ffs which has better defined semantics. -Andi From owner-linux-xfs@oss.sgi.com Fri Aug 22 15:21:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Aug 2003 15:21:44 -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 h7MMKOoO012580 for ; Fri, 22 Aug 2003 15:21:05 -0700 Received: (qmail 65305 invoked by uid 3709); 22 Aug 2003 22:20:23 -0000 Date: 23 Aug 2003 00:20:23 +0200 Date: Sat, 23 Aug 2003 00:20:23 +0200 From: Andi Kleen To: linux-xfs@oss.sgi.com Cc: lord@sgi.com Subject: Fixed xfs_lowbit, try 3 Message-ID: <20030822222023.GA64594@colin2.muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 164 X-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: 488 Lines: 26 This xfs_lowbit version should work for everybody now including generic_ffs (except parisc apparently which has a totally broken ffs) -Andi --- linux-2.6.0test3/fs/xfs/xfs_bit.c-o 2003-05-27 03:00:41.000000000 +0200 +++ linux-2.6.0test/fs/xfs/xfs_bit.c 2003-08-23 00:15:38.000000000 +0200 @@ -156,12 +156,12 @@ { int n; n = ffs((unsigned)v); - if (n == 0) { + if (n <= 0) { n = ffs(v >> 32); if (n >= 0) n+=32; } - return n-1; + return (n <= 0) ? n : n-1; } /* From owner-linux-xfs@oss.sgi.com Sun Aug 24 06:55:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 24 Aug 2003 06:55:35 -0700 (PDT) Received: from hotmail.com (law9-f124.law9.hotmail.com [64.4.9.124]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7ODtWoO028088 for ; Sun, 24 Aug 2003 06:55:32 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 24 Aug 2003 06:55:26 -0700 Received: from 80.128.41.64 by lw9fd.law9.hotmail.msn.com with HTTP; Sun, 24 Aug 2003 13:55:26 GMT X-Originating-IP: [80.128.41.64] X-Originating-Email: [k_leibrandt@hotmail.com] From: "Kai Leibrandt" To: linux-xfs@oss.sgi.com Subject: Patch 1300 & rpm issue with 1.3.0 Date: Sun, 24 Aug 2003 15:55:26 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Aug 2003 13:55:26.0951 (UTC) FILETIME=[5F3C3770:01C36A47] X-archive-position: 165 X-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: 726 Lines: 19 Hi all, I just got the 2.4.20-19.9_XFS1.3.0.src.rpm from oss.sgi.com and after building, installing and rebooting I noticed the same issue with rpm that hit me with 2.4.20-18.9... Of course after adding patch 1300 back in all is fine again, so just a quick question; is this going to be the standard way the .src.rpm are packaged, or am I doing something else wrong? Also, is there a howto or readme somewhere where I can find out how to build my own .src.rpm kernel packages from the redhat errata and the XFS patches? Many thanks in advance, Kai. _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus From owner-linux-xfs@oss.sgi.com Sun Aug 24 09:27:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 24 Aug 2003 09:27:32 -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 h7OGRFoO002056 for ; Sun, 24 Aug 2003 09:27: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 h7OGRAq0013577 for ; Sun, 24 Aug 2003 09:27:10 -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 h7OGR9Ge9937488; Sun, 24 Aug 2003 11:27: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 h7OGR6wh18434179; Sun, 24 Aug 2003 11:27:06 -0500 (CDT) Date: Sun, 24 Aug 2003 11:27:05 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Kai Leibrandt cc: linux-xfs@oss.sgi.com Subject: Re: Patch 1300 & rpm issue with 1.3.0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 166 X-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: 1182 Lines: 32 On Sun, 24 Aug 2003, Kai Leibrandt wrote: > Hi all, > > I just got the 2.4.20-19.9_XFS1.3.0.src.rpm from oss.sgi.com and after > building, installing and rebooting I noticed the same issue with rpm that > hit me with 2.4.20-18.9... Of course after adding patch 1300 back in all is > fine again, so just a quick question; is this going to be the standard way > the .src.rpm are packaged, or am I doing something else wrong? Boy, that's an annoying bug... it's somewhere in the guts of Red Hat's kernel + nptl patches + O_DIRECT + rpm. I think that Red Hat will eventually have a new version of RPM that works with this kernel. In the meantime, I'd either: a) rebuild with patch 1300 in place, if you don't care about using O_DIRECT or b) set up an alias for "rpm" to prefix it with LD_ASSUME_KERNEL=2.2.5 > Also, is there a howto or readme somewhere where I can find out how to build > my own .src.rpm kernel packages from the redhat errata and the XFS patches? No docs... best documentation is probably the spec file itself. Which xfs patches, and which Red Hat kernel packages, do you want to combine? > MSN 8 helps eliminate e-mail viruses. really? ;-) -Eric From owner-linux-xfs@oss.sgi.com Mon Aug 25 01:01:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Aug 2003 01:01:34 -0700 (PDT) Received: from hotmail.com (sea2-f33.sea2.hotmail.com [207.68.165.33]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7P81DoO022348 for ; Mon, 25 Aug 2003 01:01:14 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Aug 2003 01:01:08 -0700 Received: from 209.233.25.155 by sea2fd.sea2.hotmail.msn.com with HTTP; Mon, 25 Aug 2003 08:01:08 GMT X-Originating-IP: [209.233.25.155] X-Originating-Email: [koren_dan@hotmail.com] Reply-To: dk@inraid.com From: "Dan Koren" To: sandeen@sgi.com Cc: curtisanderson1@comcast.net, lord@sgi.com, linux-xfs@oss.sgi.com Subject: Re: The X in XFS Date: Mon, 25 Aug 2003 01:01:08 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Aug 2003 08:01:08.0620 (UTC) FILETIME=[0AB214C0:01C36ADF] X-archive-position: 167 X-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: 1442 Lines: 51 I'm sorry, but I do not have any XFS design specs or documentation in my hands. I returned all the documents in my posession when I left SGI 3 years ago -- even though the XFS ones were technically no longer confidential. I was relying entirely on my memory when I posted my earlier comments. dk >From: Eric Sandeen >To: Dan Koren >CC: Curtis Anderson , Steve Lord >, >Subject: Re: The X in XFS >Date: Thu, 21 Aug 2003 23:06:07 -0500 (CDT) > >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. > > _________________________________________________________________ Get MSN 8 and enjoy automatic e-mail virus protection. http://join.msn.com/?page=features/virus From owner-linux-xfs@oss.sgi.com Mon Aug 25 08:51:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Aug 2003 08:51:42 -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 h7PFpEoO032151 for ; Mon, 25 Aug 2003 08:51:35 -0700 Received: from puariko.homeip.net (r9acci-a89-53.acci.gr [195.167.89.53]) by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id h7PFoxHl031524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Aug 2003 17:51:08 +0200 Received: (from thimm@localhost) by pua.nirvana (8.12.9/8.12.9/Submit) id h7PFoctr004456; Mon, 25 Aug 2003 18:50:38 +0300 Date: Mon, 25 Aug 2003 18:50:28 +0300 From: Axel Thimm To: Eric Sandeen Cc: Kai Leibrandt , linux-xfs@oss.sgi.com Subject: Re: Patch 1300 & rpm issue with 1.3.0 Message-ID: <20030825155028.GA4049@pua.nirvana> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 168 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 2339 Lines: 65 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 24, 2003 at 11:27:05AM -0500, Eric Sandeen wrote: > On Sun, 24 Aug 2003, Kai Leibrandt wrote: > > I just got the 2.4.20-19.9_XFS1.3.0.src.rpm from oss.sgi.com and after= =20 > > building, installing and rebooting I noticed the same issue with rpm th= at=20 > > hit me with 2.4.20-18.9... Of course after adding patch 1300 back in al= l is=20 > > fine again, so just a quick question; is this going to be the standard = way=20 > > the .src.rpm are packaged, or am I doing something else wrong? >=20 > Boy, that's an annoying bug... it's somewhere in the guts of Red Hat's > kernel + nptl patches + O_DIRECT + rpm. I think that Red Hat will eventu= ally > have a new version of RPM that works with this kernel. In the meantime, > I'd either: >=20 > a) rebuild with patch 1300 in place, if you don't care about using O_DIRE= CT > or > b) set up an alias for "rpm" to prefix it with LD_ASSUME_KERNEL=3D2.2.5 The good news is that the current rawhide kernel has commented out that patch (named 1140 there). Unfortunatley there is no changelog entry as to why and how this was done. > > Also, is there a howto or readme somewhere where I can find out how to = build=20 > > my own .src.rpm kernel packages from the redhat errata and the XFS patc= hes? >=20 > No docs... best documentation is probably the spec file itself. Which xfs > patches, and which Red Hat kernel packages, do you want to combine? I played a bit with rawhide (which is still the same as severn's, I think). Other than the _nolock patch the rest looked trivial. I haven't got a complete build yet, but it looked quite promising (I'm on vacation, so it will take me some time). Whoever cares to look at the current bits can contact me in private. I was told to better skip 1.3.0 and go straight for the CVS bits for 2.4.22, but I wouldn't like to desync from the XFS release points. --=20 Axel.Thimm@physik.fu-berlin.de --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/SjBEQBVS1GOamfERAkDDAJ9BrhQNnJCXtm6ROU3YXK3uMO/kRQCfU0CC /1jiCUkWcQhvboISs4ys4eE= =1uz3 -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From owner-linux-xfs@oss.sgi.com Mon Aug 25 09:27:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Aug 2003 09:28: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 h7PGQvoO004624 for ; Mon, 25 Aug 2003 09:27:37 -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 h7PGQoq0020714 for ; Mon, 25 Aug 2003 09:26:52 -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 h7PGP9jq10427782; Mon, 25 Aug 2003 11:25:09 -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 h7PGP9Rn250200407; Mon, 25 Aug 2003 11:25:09 -0500 (CDT) Subject: Re: Patch 1300 & rpm issue with 1.3.0 From: Russell Cattelan To: Axel Thimm Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030825155028.GA4049@pua.nirvana> References: <20030825155028.GA4049@pua.nirvana> Content-Type: text/plain Message-Id: <1061828708.16561.4.camel@naboo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4-2mdk Date: Mon, 25 Aug 2003 11:25:09 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 169 X-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: 2379 Lines: 46 On Mon, 2003-08-25 at 10:50, Axel Thimm wrote: > On Sun, Aug 24, 2003 at 11:27:05AM -0500, Eric Sandeen wrote: > > On Sun, 24 Aug 2003, Kai Leibrandt wrote: > > > I just got the 2.4.20-19.9_XFS1.3.0.src.rpm from oss.sgi.com and after > > > building, installing and rebooting I noticed the same issue with rpm that > > > hit me with 2.4.20-18.9... Of course after adding patch 1300 back in all is > > > fine again, so just a quick question; is this going to be the standard way > > > the .src.rpm are packaged, or am I doing something else wrong? > > > > Boy, that's an annoying bug... it's somewhere in the guts of Red Hat's > > kernel + nptl patches + O_DIRECT + rpm. I think that Red Hat will eventually > > have a new version of RPM that works with this kernel. In the meantime, > > I'd either: > > > > a) rebuild with patch 1300 in place, if you don't care about using O_DIRECT > > or > > b) set up an alias for "rpm" to prefix it with LD_ASSUME_KERNEL=2.2.5 > > The good news is that the current rawhide kernel has commented out > that patch (named 1140 there). Unfortunatley there is no changelog > entry as to why and how this was done. > > > > Also, is there a howto or readme somewhere where I can find out how to build > > > my own .src.rpm kernel packages from the redhat errata and the XFS patches? > > > > No docs... best documentation is probably the spec file itself. Which xfs > > patches, and which Red Hat kernel packages, do you want to combine? > > I played a bit with rawhide (which is still the same as severn's, I > think). Other than the _nolock patch the rest looked trivial. I > haven't got a complete build yet, but it looked quite promising (I'm > on vacation, so it will take me some time). Whoever cares to look at > the current bits can contact me in private. Try using this change from the 2.4.22 tree http://xfs.org:8090/linux-2.4+xfs/diffs/fs/xfs/linux/xfs_lrw.c@1.167?nav=index.html|src/|src/fs|src/fs/xfs|src/fs/xfs/linux|hist/fs/xfs/linux/xfs_lrw.c I think the RH beta tree has do_generic_file_write at this point so you should be able to call it directly and drop the whole _nolock change all together. You might need to export do_generic_file_write ... can't remember off hand. > > I was told to better skip 1.3.0 and go straight for the CVS bits for > 2.4.22, but I wouldn't like to desync from the XFS release points. From owner-linux-xfs@oss.sgi.com Mon Aug 25 11:01:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Aug 2003 11:01: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 h7PI0loO012738 for ; Mon, 25 Aug 2003 11:01:05 -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 h7PI0fq0003963 for ; Mon, 25 Aug 2003 11:00:42 -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 h7PHwajq10450488 for ; Mon, 25 Aug 2003 12:58:36 -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 h7PHwaRn249105267 for ; Mon, 25 Aug 2003 12:58:36 -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 h7PHkLKN001240 for ; Mon, 25 Aug 2003 12:46:21 -0500 Received: (from lord@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id h7PHkKW5001202 for linux-xfs@oss.sgi.com; Mon, 25 Aug 2003 12:46:20 -0500 Date: Mon, 25 Aug 2003 12:46:20 -0500 From: Steve Lord Message-Id: <200308251746.h7PHkKW5001202@penguin.americas.sgi.com> Subject: TAKE - fix up xfs_lowbit's use of ffs To: linux-xfs@oss.sgi.com X-archive-position: 170 X-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: 269 Lines: 12 Thanks to Andi Kleen Date: Mon Aug 25 10:58:07 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:156655a linux/fs/xfs/xfs_bit.c - 1.24 From owner-linux-xfs@oss.sgi.com Mon Aug 25 13:01:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Aug 2003 13:02:35 -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 h7PK1uoO022333 for ; Mon, 25 Aug 2003 13:01:56 -0700 Received: from dhcp-140-218.pao.digeo.com (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7PK1Eo00893; Mon, 25 Aug 2003 13:01:14 -0700 Date: Mon, 25 Aug 2003 12:45:43 -0700 From: Andrew Morton To: "Barry K. Nathan" Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@oss.sgi.com Subject: Re: [BUG] 2.6.0-test4-mm1: NFS+XFS=data corruption Message-Id: <20030825124543.413187a5.akpm@osdl.org> In-Reply-To: <20030825193717.GC3562@ip68-4-255-84.oc.oc.cox.net> References: <20030824171318.4acf1182.akpm@osdl.org> <20030825193717.GC3562@ip68-4-255-84.oc.oc.cox.net> 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: 171 X-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: 1986 Lines: 44 "Barry K. Nathan" wrote: > > I'm really short on time right now, so this bug report might be vague, > but it's important enough for me to try: > > I have an NFS fileserver (running 2.6.0-test4-mm1) exporting stuff from > three filesystems: ReiserFS, ext3, and XFS. I'm seeing no problems with > my ReiserFS and ext3 filesystems. XFS is a different story. > > My client machine is running 2.4.21bkn1 (my own kernel, not released to > the public; the differences from vanilla 2.4.21 are XFS and Win4Lin). > > If I use my client machine to sign RPM packages (rpm --addsign ...), > using rpm-4.2-16mdk, and the packages are on the XFS partition on the > NFS server, about half of the packages are truncated by a couple hundred > bytes afterwards (and GPG sig verification fails on those packages). > > It's always the same packages that get truncated by the same amounts of > data. This is 100% reproducible. It doesn't matter whether I compile the > kernel with gcc 2.95.3 or 3.1.1. If I perform the operation on my non-XFS > filesystem the problem doesn't happen. If I run 2.6.0-test4-bk2 instead of > test4-mm1 on the NFS server, the problem goes away. (I have never run > any previous -mm kernels on this server.) > > Hmmm... If I sign the packages on the NFS server itself, even with > test4-mm1 on the XFS partition, I can't reproduce the problem. > *However*, that's a different version of RPM (4.0.4). > > Is this enough information to help find the cause of the bug? If not, > it might be several days (if I'm unlucky, maybe even a week or two) > before I have time to do anything more... > -mm kernels have O_DIRECT-for-NFS patches in them. And some versions of RPM use O_DIRECT. Whether O_DIRECT makes any difference at the server end I do not know, but it would be useful if you could repeat the test on stock 2.6.0-test4. Alternatively, run export LD_ASSUME_KERNEL=2.2.5 before running RPM. I think that should tell RPM to not try O_DIRECT. From owner-linux-xfs@oss.sgi.com Mon Aug 25 13:42:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Aug 2003 13:42:34 -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 h7PKgSoO026039 for ; Mon, 25 Aug 2003 13:42:29 -0700 Received: from puariko.homeip.net (r9acci-a89-53.acci.gr [195.167.89.53]) by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id h7PIUXHl025872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Aug 2003 20:30:43 +0200 Received: (from thimm@localhost) by pua.nirvana (8.12.9/8.12.9/Submit) id h7PIUN1F006661; Mon, 25 Aug 2003 21:30:23 +0300 Date: Mon, 25 Aug 2003 21:30:21 +0300 From: Axel Thimm To: Russell Cattelan Cc: linux-xfs@oss.sgi.com Subject: Re: Patch 1300 & rpm issue with 1.3.0 Message-ID: <20030825183021.GA6608@pua.nirvana> References: <20030825155028.GA4049@pua.nirvana> <1061828708.16561.4.camel@naboo> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+pHx0qQiF2pBVqBT" Content-Disposition: inline In-Reply-To: <1061828708.16561.4.camel@naboo> User-Agent: Mutt/1.4.1i X-archive-position: 172 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 5195 Lines: 160 --+pHx0qQiF2pBVqBT Content-Type: multipart/mixed; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 25, 2003 at 11:25:09AM -0500, Russell Cattelan wrote: > On Mon, 2003-08-25 at 10:50, Axel Thimm wrote: > > On Sun, Aug 24, 2003 at 11:27:05AM -0500, Eric Sandeen wrote: > > > On Sun, 24 Aug 2003, Kai Leibrandt wrote: > > > > Also, is there a howto or readme somewhere where I can find > > > > out how to build my own .src.rpm kernel packages from the > > > > redhat errata and the XFS patches? > > >=20 > > > No docs... best documentation is probably the spec file itself. > > > Which xfs patches, and which Red Hat kernel packages, do you > > > want to combine? > >=20 > > I played a bit with rawhide (which is still the same as severn's, > > I think). Other than the _nolock patch the rest looked trivial. I > > haven't got a complete build yet, but it looked quite promising > > (I'm on vacation, so it will take me some time). Whoever cares to > > look at the current bits can contact me in private. > Try using this change from the 2.4.22 tree=20 > http://xfs.org:8090/linux-2.4+xfs/diffs/fs/xfs/linux/xfs_lrw.c@1.167?nav= =3Dindex.html|src/|src/fs|src/fs/xfs|src/fs/xfs/linux|hist/fs/xfs/linux/xfs= _lrw.c Thanks, I'll look into it. > I think the RH beta tree has do_generic_file_write at this point so > you should be able to call it directly and drop the whole _nolock > change all together. The old patch was doing more (or less) than the new do_generic_* stuff, e.g. it also did not call invalidate_inode_pages2. Have a look at the rewritten _nolock patch I ended up for the rawhide kernel & XFS 1.3.0. Is this still needed or not? > You might need to export do_generic_file_write ... can't remember > off hand. They are already exported. :) > > I was told to better skip 1.3.0 and go straight for the CVS bits > > for 2.4.22, but I wouldn't like to desync from the XFS release > > points. --=20 Axel.Thimm@physik.fu-berlin.de --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="linux-2.4.21-nolock_write-atrpms.patch" Content-Transfer-Encoding: quoted-printable --- linux-2.4.21/include/linux/fs.h.org 2003-08-22 16:46:25.000000000 +0200 +++ linux-2.4.21/include/linux/fs.h 2003-08-22 16:55:50.000000000 +0200 @@ -1520,6 +1520,7 @@ extern int precheck_file_write(struct file *, struct inode *, size_t *, lo= ff_t *); extern ssize_t generic_file_write(struct file *, const char *, size_t, lof= f_t *); extern ssize_t do_generic_file_write(struct file *, const char *, size_t, = loff_t *); +extern ssize_t generic_file_write_nolock(struct file *, const char *, size= _t, loff_t *); extern void do_generic_file_read(struct file *, loff_t *, read_descriptor_= t *, read_actor_t); extern loff_t no_llseek(struct file *file, loff_t offset, int origin); extern loff_t generic_file_llseek(struct file *file, loff_t offset, int or= igin); --- linux-2.4.21/mm/filemap.c.org 2003-08-22 16:46:26.000000000 +0200 +++ linux-2.4.21/mm/filemap.c 2003-08-22 17:26:13.000000000 +0200 @@ -3266,7 +3266,7 @@ } =20 ssize_t -do_generic_direct_write(struct file *file,const char *buf,size_t count, lo= ff_t *ppos) +do_generic_direct_write_noinvalidate(struct file *file,const char *buf,siz= e_t count, loff_t *ppos) { struct address_space *mapping =3D file->f_dentry->d_inode->i_mapping; struct inode *inode =3D mapping->host; @@ -3297,7 +3297,6 @@ mark_inode_dirty(inode); } *ppos =3D end; - invalidate_inode_pages2(mapping); } /* * Sync the fs metadata but not the minor inode changes and @@ -3311,6 +3310,19 @@ return err; } =20 +ssize_t +do_generic_direct_write(struct file *file,const char *buf,size_t count, lo= ff_t *ppos) +{ + int err; + + err =3D do_generic_direct_write_noinvalidate(file, buf, count, ppos); + + if (err > 0) + invalidate_inode_pages2(file->f_dentry->d_inode->i_mapping); + + return err; +} + static int do_odirect_fallback(struct file *file, struct inode *inode, const char *buf, size_t count, loff_t *ppos) { @@ -3328,6 +3340,23 @@ } =20 ssize_t +generic_file_write_nolock(struct file *file,const char *buf,size_t count, = loff_t *ppos) +{ + struct inode *inode =3D file->f_dentry->d_inode->i_mapping->host; + int err; + + if (file->f_flags & O_DIRECT) { + err =3D do_generic_direct_write_noinvalidate(file, buf, count, ppos); + if (unlikely(err =3D=3D -ENOTBLK)) + err =3D do_odirect_fallback(file, inode, buf, count, ppos); + } else { + err =3D do_generic_file_write(file, buf, count, ppos); + } + + return err; +} + +ssize_t generic_file_write(struct file *file,const char *buf,size_t count, loff_t = *ppos) { struct inode *inode =3D file->f_dentry->d_inode->i_mapping->host; --IJpNTDwzlM2Ie8A6-- --+pHx0qQiF2pBVqBT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/SlW9QBVS1GOamfERAoibAJ9ogbLheMoU9CdNFAtnF6pT0iae2ACfdH3m eusEnMPLCDBRh1679HCu/GU= =p994 -----END PGP SIGNATURE----- --+pHx0qQiF2pBVqBT-- From owner-linux-xfs@oss.sgi.com Mon Aug 25 15:55:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Aug 2003 15:55: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 h7PMtMoO001772 for ; Mon, 25 Aug 2003 15:55:22 -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 h7PMtGq0003619 for ; Mon, 25 Aug 2003 15:55:16 -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 h7PMsGjq10549260; Mon, 25 Aug 2003 17:54:16 -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 h7PMsCRn220307979; Mon, 25 Aug 2003 17:54:16 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h7PMsBL01467; Mon, 25 Aug 2003 17:54:11 -0500 Subject: Re: [BUG] 2.6.0-test4-mm1: NFS+XFS=data corruption From: Steve Lord To: Andrew Morton Cc: "Barry K. Nathan" , Linux Kernel , linux-mm@kvack.org, linux-xfs@oss.sgi.com In-Reply-To: <20030825124543.413187a5.akpm@osdl.org> References: <20030824171318.4acf1182.akpm@osdl.org> <20030825193717.GC3562@ip68-4-255-84.oc.oc.cox.net> <20030825124543.413187a5.akpm@osdl.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1061852050.25892.195.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 25 Aug 2003 17:54:11 -0500 X-archive-position: 173 X-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: 2499 Lines: 58 On Mon, 2003-08-25 at 14:45, Andrew Morton wrote: > "Barry K. Nathan" wrote: > > > > I'm really short on time right now, so this bug report might be vague, > > but it's important enough for me to try: > > > > I have an NFS fileserver (running 2.6.0-test4-mm1) exporting stuff from > > three filesystems: ReiserFS, ext3, and XFS. I'm seeing no problems with > > my ReiserFS and ext3 filesystems. XFS is a different story. > > > > My client machine is running 2.4.21bkn1 (my own kernel, not released to > > the public; the differences from vanilla 2.4.21 are XFS and Win4Lin). > > > > If I use my client machine to sign RPM packages (rpm --addsign ...), > > using rpm-4.2-16mdk, and the packages are on the XFS partition on the > > NFS server, about half of the packages are truncated by a couple hundred > > bytes afterwards (and GPG sig verification fails on those packages). > > > > It's always the same packages that get truncated by the same amounts of > > data. This is 100% reproducible. It doesn't matter whether I compile the > > kernel with gcc 2.95.3 or 3.1.1. If I perform the operation on my non-XFS > > filesystem the problem doesn't happen. If I run 2.6.0-test4-bk2 instead of > > test4-mm1 on the NFS server, the problem goes away. (I have never run > > any previous -mm kernels on this server.) > > > > Hmmm... If I sign the packages on the NFS server itself, even with > > test4-mm1 on the XFS partition, I can't reproduce the problem. > > *However*, that's a different version of RPM (4.0.4). > > > > Is this enough information to help find the cause of the bug? If not, > > it might be several days (if I'm unlucky, maybe even a week or two) > > before I have time to do anything more... > > > > -mm kernels have O_DIRECT-for-NFS patches in them. And some versions of > RPM use O_DIRECT. Whether O_DIRECT makes any difference at the server end > I do not know, but it would be useful if you could repeat the test on stock > 2.6.0-test4. > > Alternatively, run > > export LD_ASSUME_KERNEL=2.2.5 > > before running RPM. I think that should tell RPM to not try O_DIRECT. I doubt the NFS client is O_DIRECT capable here, I have run some rpm builds over nfs to 2.6.0-test4 and an xfs filesystem, everything is behaving so far. I will try mm1 tomorrow. Do we know if this NFS V3 or V2 by the way? 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 26 03:11:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 03:12:14 -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 h7QABvoO025393 for ; Tue, 26 Aug 2003 03:11:58 -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 h7QABGo10766; Tue, 26 Aug 2003 03:11:16 -0700 Date: Tue, 26 Aug 2003 03:14:12 -0700 From: Andrew Morton To: Steve Lord Cc: barryn@pobox.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@oss.sgi.com, Suparna Bhattacharya Subject: Re: [BUG] 2.6.0-test4-mm1: NFS+XFS=data corruption Message-Id: <20030826031412.72785b15.akpm@osdl.org> In-Reply-To: <1061852050.25892.195.camel@jen.americas.sgi.com> References: <20030824171318.4acf1182.akpm@osdl.org> <20030825193717.GC3562@ip68-4-255-84.oc.oc.cox.net> <20030825124543.413187a5.akpm@osdl.org> <1061852050.25892.195.camel@jen.americas.sgi.com> 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: 174 X-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: 1783 Lines: 52 Steve Lord wrote: > > > > Is this enough information to help find the cause of the bug? If not, > > > it might be several days (if I'm unlucky, maybe even a week or two) > > > before I have time to do anything more... > > > > > > > -mm kernels have O_DIRECT-for-NFS patches in them. And some versions of > > RPM use O_DIRECT. Whether O_DIRECT makes any difference at the server end > > I do not know, but it would be useful if you could repeat the test on stock > > 2.6.0-test4. > > > > Alternatively, run > > > > export LD_ASSUME_KERNEL=2.2.5 > > > > before running RPM. I think that should tell RPM to not try O_DIRECT. > > I doubt the NFS client is O_DIRECT capable here, I have run some rpm > builds over nfs to 2.6.0-test4 and an xfs filesystem, everything is > behaving so far. I will try mm1 tomorrow. > > Do we know if this NFS V3 or V2 by the way? OK, sorry for the noise. It appears that this is due to the AIO patches in -mm. fsx-linux fails instantly on nfsv3 to localhost on XFS. It's OK on ext2 for some reason. Binary searching reveals that the offending patch is O_SYNC-speedup-nolock-fix.patch testcase: mkfs.xfs -f /dev/hda5 mount /dev/hda5 /mnt/hda5 chmod a+rw /mnt/hda5 service nfs start mount localhost:/mnt/hda5 /mnt/localhost cd /mnt/localhost fsx-linux foo truncating to largest ever: 0x13e76 READ BAD DATA: offset = 0x18f13, size = 0xee06, fname = foo OFFSET GOOD BAD RANGE 0x26000 0x02eb 0x0000 0x 0 operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops 0x26001 0xeb02 0x0000 0x 1 operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops 0x26002 0x0228 0x0000 0x 2 operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops From owner-linux-xfs@oss.sgi.com Tue Aug 26 03:30:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 03:30:29 -0700 (PDT) Received: from server4.nfra.nl (fwuser@firebox.nfra.nl [192.87.1.200]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QAU5oO026417 for ; Tue, 26 Aug 2003 03:30:06 -0700 Received: from wop07.astron.nl (wop07.nfra.nl [195.169.63.27]) by server4.nfra.nl; Tue, 26 Aug 2003 12:29:46 +0200 Date: Tue, 26 Aug 2003 12:29:49 +0200 (CEST) From: K Ramesh To: Subject: problems with real-time option. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 175 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kram@astron.nl Precedence: bulk X-list: linux-xfs Content-Length: 1166 Lines: 29 Hi, I'm trying to create a real-time subvolume in my Linux System, running SuSE 8.1 (Kernel: 2.4.19-64GB-SMP) on a dual-xeon PC. The system has a 3ware ATA-Raid controller. When I try to create a real-time subvolume, this what I get: wop18:~ # mkfs -t xfs -f -r rtdev=/dev/sda6 /dev/sda5 meta-data=/dev/sda5 isize=256 agcount=49, agsize=1048576 blks data = bsize=4096 blocks=51201147, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=6250, version=1 = sunit=0 blks realtime =/dev/sda6 extsz=65536 blocks=183237382, rtextents=11452336 XFS: This FS has an RT subvol - specify -o rtdev on mount mkfs.xfs: real-time device init failed mkfs.xfs: filesystem failed to initialize Does this mean that the realtime subvolume is not usable? Can you please tell me the status of realtime subvolume status of XFS in Linux? I checked the archives, and found similar questions raised in early 2002. Wonder if we have anything new now. Regards Ramesh From owner-linux-xfs@oss.sgi.com Tue Aug 26 03:55:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 03:56:02 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QAtloO028026 for ; Tue, 26 Aug 2003 03:55:48 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7QAtZbe094522; Tue, 26 Aug 2003 06:55:35 -0400 Received: from sparklet2.in.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7QAtIa2080610; Tue, 26 Aug 2003 06:55:28 -0400 Received: by sparklet2.in.ibm.com (Postfix, from userid 500) id 76418192E7; Tue, 26 Aug 2003 16:31:11 +0530 (IST) Date: Tue, 26 Aug 2003 16:31:11 +0530 From: Suparna Bhattacharya To: Andrew Morton Cc: Steve Lord , barryn@pobox.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@oss.sgi.com Subject: Re: [BUG] 2.6.0-test4-mm1: NFS+XFS=data corruption Message-ID: <20030826110111.GA4750@in.ibm.com> Reply-To: suparna@in.ibm.com References: <20030824171318.4acf1182.akpm@osdl.org> <20030825193717.GC3562@ip68-4-255-84.oc.oc.cox.net> <20030825124543.413187a5.akpm@osdl.org> <1061852050.25892.195.camel@jen.americas.sgi.com> <20030826031412.72785b15.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030826031412.72785b15.akpm@osdl.org> User-Agent: Mutt/1.4i X-archive-position: 176 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: suparna@in.ibm.com Precedence: bulk X-list: linux-xfs Content-Length: 1982 Lines: 58 On Tue, Aug 26, 2003 at 03:14:12AM -0700, Andrew Morton wrote: > Steve Lord wrote: > > > > > > Is this enough information to help find the cause of the bug? If not, > > > > it might be several days (if I'm unlucky, maybe even a week or two) > > > > before I have time to do anything more... > > > > > > > > > > -mm kernels have O_DIRECT-for-NFS patches in them. And some versions of > > > RPM use O_DIRECT. Whether O_DIRECT makes any difference at the server end > > > I do not know, but it would be useful if you could repeat the test on stock > > > 2.6.0-test4. > > > > > > Alternatively, run > > > > > > export LD_ASSUME_KERNEL=2.2.5 > > > > > > before running RPM. I think that should tell RPM to not try O_DIRECT. > > > > I doubt the NFS client is O_DIRECT capable here, I have run some rpm > > builds over nfs to 2.6.0-test4 and an xfs filesystem, everything is > > behaving so far. I will try mm1 tomorrow. > > > > Do we know if this NFS V3 or V2 by the way? > > OK, sorry for the noise. It appears that this is due to the AIO patches in > -mm. fsx-linux fails instantly on nfsv3 to localhost on XFS. It's OK on > ext2 for some reason. > > Binary searching reveals that the offending patch is > O_SYNC-speedup-nolock-fix.patch > I'm not sure if this would help here, but there is one bug which I just spotted which would affect writev from XFS. I wasn't passing the nr_segs down properly. Regards Suparna -- Suparna Bhattacharya (suparna@in.ibm.com) Linux Technology Center IBM Software Labs, India --- linux-2.6.0-test4-mm1/mm/filemap.c 2003-08-26 10:09:50.000000000 +0530 +++ fix-mm/mm/filemap.c 2003-08-26 16:23:55.000000000 +0530 @@ -1942,7 +1942,7 @@ generic_file_aio_write_nolock(struct kio goto osync; } - ret = __generic_file_aio_write_nolock(iocb, iov, 1, ppos); + ret = __generic_file_aio_write_nolock(iocb, iov, nr_segs, ppos); /* * Avoid doing a sync in parts for aio - its more efficient to From owner-linux-xfs@oss.sgi.com Tue Aug 26 05:10:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 05:11: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 h7QCAaoO009303 for ; Tue, 26 Aug 2003 05:10:37 -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 h7QCAVq0010565 for ; Tue, 26 Aug 2003 05:10:31 -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 h7QCAUaK10568185; Tue, 26 Aug 2003 07:10:30 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-55.corp.sgi.com [134.15.64.55]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7QCATRn249058692; Tue, 26 Aug 2003 07:10:29 -0500 (CDT) Subject: Re: problems with real-time option. From: Steve Lord To: K Ramesh 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: 26 Aug 2003 07:10:02 -0500 Message-Id: <1061899804.2030.3.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 177 X-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: 1402 Lines: 34 On Tue, 2003-08-26 at 05:29, K Ramesh wrote: > > Hi, > I'm trying to create a real-time subvolume in my Linux System, running > SuSE 8.1 (Kernel: 2.4.19-64GB-SMP) on a dual-xeon PC. The system has a 3ware > ATA-Raid controller. > > When I try to create a real-time subvolume, this what I get: > > wop18:~ # mkfs -t xfs -f -r rtdev=/dev/sda6 /dev/sda5 > meta-data=/dev/sda5 isize=256 agcount=49, agsize=1048576 blks > data = bsize=4096 blocks=51201147, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=6250, version=1 > = sunit=0 blks > realtime =/dev/sda6 extsz=65536 blocks=183237382, > rtextents=11452336 > XFS: This FS has an RT subvol - specify -o rtdev on mount > mkfs.xfs: real-time device init failed > mkfs.xfs: filesystem failed to initialize > > Does this mean that the realtime subvolume is not usable? Can you please > tell me the status of realtime subvolume status of XFS in Linux? I checked the > archives, and found similar questions raised in early 2002. Wonder if we have > anything new now. Your kernel is almost that old ;-) Realtime should be working in recent kernels, be aware you need to use O_DIRECT to write to realtime subvolumes. Steve From owner-linux-xfs@oss.sgi.com Tue Aug 26 07:23:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 07:24:11 -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 h7QENnoO017430 for ; Tue, 26 Aug 2003 07:23:52 -0700 Received: from puariko.homeip.net (r10acci-a15-47.acci.gr [195.170.15.47]) by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id h7QENYHl024948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Aug 2003 16:23:44 +0200 Received: (from thimm@localhost) by pua.nirvana (8.12.9/8.12.9/Submit) id h7QENTin004737; Tue, 26 Aug 2003 17:23:29 +0300 Date: Tue, 26 Aug 2003 17:23:27 +0300 From: Axel Thimm To: Eric Sandeen Cc: Kai Leibrandt , linux-xfs@oss.sgi.com Subject: Re: Patch 1300 & rpm issue with 1.3.0 Message-ID: <20030826142327.GB3818@pua.nirvana> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PmA2V3Z32TCmWXqI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 178 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1870 Lines: 58 --PmA2V3Z32TCmWXqI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 24, 2003 at 11:27:05AM -0500, Eric Sandeen wrote: > On Sun, 24 Aug 2003, Kai Leibrandt wrote: >=20 > > Hi all, > >=20 > > I just got the 2.4.20-19.9_XFS1.3.0.src.rpm from oss.sgi.com and after= =20 > > building, installing and rebooting I noticed the same issue with rpm th= at=20 > > hit me with 2.4.20-18.9... Of course after adding patch 1300 back in al= l is=20 > > fine again, so just a quick question; is this going to be the standard = way=20 > > the .src.rpm are packaged, or am I doing something else wrong? >=20 > Boy, that's an annoying bug... it's somewhere in the guts of Red Hat's > kernel + nptl patches + O_DIRECT + rpm. This also bit me with the 20.9 kernel patched to XFS 1.3.0. It seems 100% reproducible. :( Why doesn't this show up with the binary kernels for 19.9? Or does it but nobody reported it yet? It also didn't show up with XFS 1.2.0. > I think that Red Hat will eventually have a new version of RPM that > works with this kernel. In the meantime, I'd either: >=20 > a) rebuild with patch 1300 in place, if you don't care about using O_DIRE= CT > or > b) set up an alias for "rpm" to prefix it with LD_ASSUME_KERNEL=3D2.2.5 What are the drawbacks of these methods? Simply performance? a) seems bad, because it will degrade overall system performance, b) is difficult, because the used rpm application is not under control of the kernel packager. :( --=20 Axel.Thimm@physik.fu-berlin.de --PmA2V3Z32TCmWXqI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/S21fQBVS1GOamfERAm5gAKCNt41sxQp4S4zSUNmpcukc6YY4eQCgmX5s qkGgOoOdN5UlAmveBEmQQGY= =J5aD -----END PGP SIGNATURE----- --PmA2V3Z32TCmWXqI-- From owner-linux-xfs@oss.sgi.com Tue Aug 26 07:58:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 07:58:56 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QEwooO019699 for ; Tue, 26 Aug 2003 07:58: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 h7QFFNxZ019683 for ; Tue, 26 Aug 2003 10:15:23 -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 h7QEwjaK10586089; Tue, 26 Aug 2003 09:58:45 -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 h7QEwjwh18742552; Tue, 26 Aug 2003 09:58:45 -0500 (CDT) Date: Tue, 26 Aug 2003 09:58:44 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Axel Thimm cc: Kai Leibrandt , Subject: Re: Patch 1300 & rpm issue with 1.3.0 In-Reply-To: <20030826142327.GB3818@pua.nirvana> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 179 X-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: 1355 Lines: 36 On Tue, 26 Aug 2003, Axel Thimm wrote: > > Boy, that's an annoying bug... it's somewhere in the guts of Red Hat's > > kernel + nptl patches + O_DIRECT + rpm. > > This also bit me with the 20.9 kernel patched to XFS 1.3.0. It seems > 100% reproducible. :( > > Why doesn't this show up with the binary kernels for 19.9? Or does it > but nobody reported it yet? It also didn't show up with XFS 1.2.0. I think it does show up in 19.9. For XFS 1.2.0, that was on a different underlying kernel - or have you merged 1.2.0 up to 2.4.20-19.9? > > I think that Red Hat will eventually have a new version of RPM that > > works with this kernel. In the meantime, I'd either: > > > > a) rebuild with patch 1300 in place, if you don't care about using O_DIRECT > > or > > b) set up an alias for "rpm" to prefix it with LD_ASSUME_KERNEL=2.2.5 > > What are the drawbacks of these methods? Simply performance? a) seems > bad, because it will degrade overall system performance, Not many things use O_DIRECT, actually. And, well, it won't be any worse than what Red Hat ships originally - wihch turns off O_DIRECT completely with 1300. We'd just be putting that back in place. > b) is > difficult, because the used rpm application is not under control of > the kernel packager. :( not sure what you mean? That not everything will pick up the alias? -Eric From owner-linux-xfs@oss.sgi.com Tue Aug 26 08:21:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 08:21:28 -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 h7QFL4oO008637 for ; Tue, 26 Aug 2003 08:21:05 -0700 Received: from mailhub.ch.sauter-bc.com (mailhub [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 7578F32CA0; Tue, 26 Aug 2003 16:51:32 +0200 (CEST) Received: from mx-05-bsl.ch.sauter-bc.com (mx-05-bsl.ch.sauter-bc.com [10.1.6.20]) by mailhub.ch.sauter-bc.com (Postfix) with ESMTP id 5104E32CB5; Tue, 26 Aug 2003 16:51:31 +0200 (CEST) Received: from ch.sauter-bc.com (sup.ch.sauter-bc.com [10.1.200.117]) by mx-05-bsl.ch.sauter-bc.com (Postfix) with ESMTP id 42F574E20E; Tue, 26 Aug 2003 16:51:31 +0200 (CEST) Message-ID: <3F4B73F3.1A08113B@ch.sauter-bc.com> Date: Tue, 26 Aug 2003 16:51:31 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.24-6.2.3 i686) X-Accept-Language: de-CH, de, en-US, en MIME-Version: 1.0 To: Eric Sandeen Cc: Kai Leibrandt , linux-xfs@oss.sgi.com Subject: Re: Patch 1300 & rpm issue with 1.3.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 180 X-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: 847 Lines: 24 Eric Sandeen schrieb: > > On Sun, 24 Aug 2003, Kai Leibrandt wrote: > > Boy, that's an annoying bug... it's somewhere in the guts of Red Hat's > kernel + nptl patches + O_DIRECT + rpm. I think that Red Hat will eventually > have a new version of RPM that works with this kernel. In the meantime, > I'd either: Hmm, can somebody explain what the patch 1300 problem is? I have built my own 2.4.20-20.7.XFS1.3.0 and 2.4.20-20.9.XFS1.3.0 rpms and I'm using the 20.7 version on RedHat 7.2 without any problem. Did I miss something? Is there a problem when using in on RedHat 9? Of course 20.9 has the nptl patches so should I expect any problems which are not present in 20.7? Simon > > a) rebuild with patch 1300 in place, if you don't care about using O_DIRECT > or > b) set up an alias for "rpm" to prefix it with LD_ASSUME_KERNEL=2.2.5 > From owner-linux-xfs@oss.sgi.com Tue Aug 26 08:39:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 08:39:33 -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 h7QFd5oO010246 for ; Tue, 26 Aug 2003 08:39:06 -0700 Received: from puariko.homeip.net (r10acci-a15-94.acci.gr [195.170.15.94]) by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id h7QFbnHl030507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Aug 2003 17:38:55 +0200 Received: (from thimm@localhost) by pua.nirvana (8.12.9/8.12.9/Submit) id h7QFbE8v006102; Tue, 26 Aug 2003 18:37:14 +0300 Date: Tue, 26 Aug 2003 18:37:08 +0300 From: Axel Thimm To: Eric Sandeen Cc: Kai Leibrandt , linux-xfs@oss.sgi.com Subject: Re: Patch 1300 & rpm issue with 1.3.0 Message-ID: <20030826153708.GG3818@pua.nirvana> References: <20030826142327.GB3818@pua.nirvana> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5UGlQXeG3ziZS81+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 181 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 2575 Lines: 72 --5UGlQXeG3ziZS81+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 26, 2003 at 09:58:44AM -0500, Eric Sandeen wrote: > On Tue, 26 Aug 2003, Axel Thimm wrote: > > > Boy, that's an annoying bug... it's somewhere in the guts of Red Hat= 's > > > kernel + nptl patches + O_DIRECT + rpm. > >=20 > > This also bit me with the 20.9 kernel patched to XFS 1.3.0. It seems > > 100% reproducible. :( > >=20 > > Why doesn't this show up with the binary kernels for 19.9? Or does it > > but nobody reported it yet? It also didn't show up with XFS 1.2.0. >=20 > I think it does show up in 19.9. For XFS 1.2.0, that was on a different > underlying kernel - or have you merged 1.2.0 up to 2.4.20-19.9? Yes, the atrpms kernels track latest RH errata and had (up to now) XFS 1.2.0. > > > I think that Red Hat will eventually have a new version of RPM that > > > works with this kernel. In the meantime, I'd either: > > >=20 > > > a) rebuild with patch 1300 in place, if you don't care about using O_= DIRECT > > > or > > > b) set up an alias for "rpm" to prefix it with LD_ASSUME_KERNEL=3D2.2= .5 > >=20 > > What are the drawbacks of these methods? Simply performance? a) seems > > bad, because it will degrade overall system performance, >=20 > Not many things use O_DIRECT, actually. And, well, it won't be any worse > than what Red Hat ships originally - wihch turns off O_DIRECT completely > with 1300. We'd just be putting that back in place. Hm, worth considering it for the 2.4.20 series (the actual errata kernels). Latest rawhide/severn kernels have removed that patch. I'll respin a test kernel with O_DIRECT disabled. > > b) is difficult, because the used rpm application is not under > > control of the kernel packager. :( >=20 > not sure what you mean? That not everything will pick up the alias? Yes, for instance. Delivering a kernel rpm does not guarantee that people will read any accompanying documentation. So the next best stab to the problem would be to build rpm without O_DIRECT support. Then the kernel rpm would have to depend on a capability provided by the fixed rpm rpm (yes, it's double ;). But this opens a pit without an end ... :( --=20 Axel.Thimm@physik.fu-berlin.de --5UGlQXeG3ziZS81+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/S36jQBVS1GOamfERAsRhAJwM/8btV/cxjMvgsWHRnIqbwBtuTQCgiSn+ FxfKoufdxM0hN4vXK63Mo6U= =B2/j -----END PGP SIGNATURE----- --5UGlQXeG3ziZS81+-- From owner-linux-xfs@oss.sgi.com Tue Aug 26 08:45:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 08:45:15 -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 h7QFjAoO011024 for ; Tue, 26 Aug 2003 08:45:11 -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 h7QFj5q0012655 for ; Tue, 26 Aug 2003 08:45:05 -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 h7QFi5aK10598662; Tue, 26 Aug 2003 10:44:05 -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 h7QFi4wg18821777; Tue, 26 Aug 2003 10:44:05 -0500 (CDT) Subject: Re: Patch 1300 & rpm issue with 1.3.0 From: Eric Sandeen To: Simon Matter Cc: Kai Leibrandt , linux-xfs@oss.sgi.com In-Reply-To: <3F4B73F3.1A08113B@ch.sauter-bc.com> References: <3F4B73F3.1A08113B@ch.sauter-bc.com> Content-Type: text/plain Organization: Message-Id: <1061912643.13459.1.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 26 Aug 2003 10:44:04 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 183 X-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: 936 Lines: 24 Simon - the RH9 kernels, where we turned O_DIRECT back on -only- for xfs, together with the nptl patches in the RH9 kernel, seems to cause problems with RPM - even if the RPM db is not on xfs. FWIW, the other solution seems to be to get the latest RPMs from rpm.org (4.2.x) which turn off O_DIRECT in the rpm source. I still don't know what the underlying problem actually is. -Eric On Tue, 2003-08-26 at 09:51, Simon Matter wrote: > Hmm, can somebody explain what the patch 1300 problem is? I have built > my own 2.4.20-20.7.XFS1.3.0 and 2.4.20-20.9.XFS1.3.0 rpms and I'm using > the 20.7 version on RedHat 7.2 without any problem. Did I miss > something? Is there a problem when using in on RedHat 9? Of course 20.9 > has the nptl patches so should I expect any problems which are not > present in 20.7? -- 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 Tue Aug 26 08:45:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 08:45: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 h7QFj2oO011010 for ; Tue, 26 Aug 2003 08:45:02 -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 h7QFiuq0012638 for ; Tue, 26 Aug 2003 08:44:57 -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 h7QFhuaK10562313; Tue, 26 Aug 2003 10:43:56 -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 h7QFhsRn247177361; Tue, 26 Aug 2003 10:43:54 -0500 (CDT) Subject: Re: Patch 1300 & rpm issue with 1.3.0 From: Russell Cattelan To: Simon Matter Cc: Kai Leibrandt , linux-xfs@oss.sgi.com In-Reply-To: <3F4B73F3.1A08113B@ch.sauter-bc.com> References: <3F4B73F3.1A08113B@ch.sauter-bc.com> Content-Type: text/plain Message-Id: <1061912624.16685.24.camel@naboo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4-2mdk Date: Tue, 26 Aug 2003 10:43:45 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 182 X-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: 1178 Lines: 32 On Tue, 2003-08-26 at 09:51, Simon Matter wrote: > Eric Sandeen schrieb: > > > > On Sun, 24 Aug 2003, Kai Leibrandt wrote: > > > > Boy, that's an annoying bug... it's somewhere in the guts of Red Hat's > > kernel + nptl patches + O_DIRECT + rpm. I think that Red Hat will eventually > > have a new version of RPM that works with this kernel. In the meantime, > > I'd either: > > Hmm, can somebody explain what the patch 1300 problem is? I have built > my own 2.4.20-20.7.XFS1.3.0 and 2.4.20-20.9.XFS1.3.0 rpms and I'm using > the 20.7 version on RedHat 7.2 without any problem. Did I miss > something? Is there a problem when using in on RedHat 9? Of course 20.9 > has the nptl patches so should I expect any problems which are not > present in 20.7? Yes, this only shows up with the nptl patch applied, and only the RH9 kernels apply that patch. The same srpm build for a RH7.x or RH8 system won't have the nptl patch applied. The problem appears to be someplace in the db4 code. > > Simon > > > > > a) rebuild with patch 1300 in place, if you don't care about using O_DIRECT > > or > > b) set up an alias for "rpm" to prefix it with LD_ASSUME_KERNEL=2.2.5 > > > From owner-linux-xfs@oss.sgi.com Tue Aug 26 08:57:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 08:57:24 -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 h7QFv5oO012580 for ; Tue, 26 Aug 2003 08:57: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 h7QFv0q0014570 for ; Tue, 26 Aug 2003 08:57:00 -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 h7QFuxaK10602500; Tue, 26 Aug 2003 10:56:59 -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 h7QFuxwg18811667; Tue, 26 Aug 2003 10:56:59 -0500 (CDT) Subject: Re: Patch 1300 & rpm issue with 1.3.0 From: Eric Sandeen To: Axel Thimm Cc: Kai Leibrandt , linux-xfs@oss.sgi.com In-Reply-To: <20030826153708.GG3818@pua.nirvana> References: <20030826142327.GB3818@pua.nirvana> <20030826153708.GG3818@pua.nirvana> Content-Type: text/plain Organization: Message-Id: <1061913418.13459.13.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 26 Aug 2003 10:56:59 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 184 X-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: 1322 Lines: 35 On Tue, 2003-08-26 at 10:37, Axel Thimm wrote: > > underlying kernel - or have you merged 1.2.0 up to 2.4.20-19.9? > > Yes, the atrpms kernels track latest RH errata and had (up to now) XFS > 1.2.0. Ah, but I'm sure in your latest errata kernel, patch 1300 was still in place, and this takes out O_DIRECT very early. > Hm, worth considering it for the 2.4.20 series (the actual errata > kernels). Latest rawhide/severn kernels have removed that patch. I'll > respin a test kernel with O_DIRECT disabled. yes, they have different O_DIRECT handling now, actually a fix for a security problem I think. > Yes, for instance. Delivering a kernel rpm does not guarantee that > people will read any accompanying documentation. So the next best stab > to the problem would be to build rpm without O_DIRECT support. Then > the kernel rpm would have to depend on a capability provided by the > fixed rpm rpm (yes, it's double ;). > > But this opens a pit without an end ... :( Still not following... :) But for your kernels, I'd leave patch 1300 in place, disabling O_DIRECT entirely. This is no worse than the original RH kernel. Yes, it cripples XFS, but it's probably the simplest path. -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 Tue Aug 26 09:20:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 09:20:58 -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 h7QGKdoO014579 for ; Tue, 26 Aug 2003 09:20:40 -0700 Received: from puariko.homeip.net (r10acci-a15-222.acci.gr [195.170.15.222]) by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id h7QGKJHl031524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Aug 2003 18:20:33 +0200 Received: (from thimm@localhost) by pua.nirvana (8.12.9/8.12.9/Submit) id h7QGJssh006889; Tue, 26 Aug 2003 19:19:55 +0300 Date: Tue, 26 Aug 2003 19:19:53 +0300 From: Axel Thimm To: Eric Sandeen Cc: Simon Matter , Kai Leibrandt , linux-xfs@oss.sgi.com Subject: Re: Patch 1300 & rpm issue with 1.3.0 Message-ID: <20030826161953.GB6163@pua.nirvana> References: <20030826142327.GB3818@pua.nirvana> <20030826153708.GG3818@pua.nirvana> <1061913418.13459.13.camel@stout.americas.sgi.com> <3F4B73F3.1A08113B@ch.sauter-bc.com> <1061912643.13459.1.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JP+T4n/bALQSJXh8" Content-Disposition: inline In-Reply-To: <1061913418.13459.13.camel@stout.americas.sgi.com> <1061912643.13459.1.camel@stout.americas.sgi.com> User-Agent: Mutt/1.4.1i X-archive-position: 185 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1749 Lines: 53 --JP+T4n/bALQSJXh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 26, 2003 at 10:44:04AM -0500, Eric Sandeen wrote: > FWIW, the other solution seems to be to get the latest RPMs from rpm.org > (4.2.x) which turn off O_DIRECT in the rpm source. So using rpm-4.2, 4.1.1 or 4.0.5 should be fine (see: http://www.geocrawler.com/lists/3/Red-Hat-Linux/87/0/10430019/) > I still don't know what the underlying problem actually is. On Tue, Aug 26, 2003 at 10:56:59AM -0500, Eric Sandeen wrote: > On Tue, 2003-08-26 at 10:37, Axel Thimm wrote: > > > underlying kernel - or have you merged 1.2.0 up to 2.4.20-19.9? > >=20 > > Yes, the atrpms kernels track latest RH errata and had (up to now) XFS > > 1.2.0. >=20 > Ah, but I'm sure in your latest errata kernel, patch 1300 was still in > place, and this takes out O_DIRECT very early. That's true and makes sense. > But for your kernels, I'd leave patch 1300 in place, disabling > O_DIRECT entirely. This is no worse than the original RH kernel. > Yes, it cripples XFS, but it's probably the simplest path. If rpm >=3D 4.2 does the job, I'd rather put a Requires: line in the kernel specfile than crippling XFS. After all I have backported rpm 4.2 for RH8.0 and RH7.3, so it is available from the same source. I'll do some more testing with rpm 4.2. Kai, could you also try it out? --=20 Axel.Thimm@physik.fu-berlin.de --JP+T4n/bALQSJXh8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/S4ioQBVS1GOamfERAiBPAKCbKLSMx7hMaIUhkCnzOcv23SQiogCfWzny IIck5YJJgGZdmibNY94h7D0= =NOPZ -----END PGP SIGNATURE----- --JP+T4n/bALQSJXh8-- From owner-linux-xfs@oss.sgi.com Tue Aug 26 09:43:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 09:43:53 -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 h7QGhWoO016214 for ; Tue, 26 Aug 2003 09:43:34 -0700 Received: from puariko.homeip.net (r10acci-a15-222.acci.gr [195.170.15.222]) by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id h7QGhJHl001455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Aug 2003 18:43:30 +0200 Received: (from thimm@localhost) by pua.nirvana (8.12.9/8.12.9/Submit) id h7QGhFCp007515; Tue, 26 Aug 2003 19:43:15 +0300 Date: Tue, 26 Aug 2003 19:43:14 +0300 From: Axel Thimm To: linux-xfs@oss.sgi.com Cc: radus@rdsor.ro Subject: XFS internal error: RH 2.4.20-20.9 & XFS 1.3.0 & others Message-ID: <20030826164314.GA7257@pua.nirvana> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 186 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 2745 Lines: 85 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I got a bug report by radus using the atrpms kernels on Debian (the kernels are for RedHat and he takes the kernel-source rpm and uses it for building on Debian with some workarounds for gcc 3.3). The kernel in question has o Red Hat 2.4.20-20.9 base sources o XFS 1.3.0 merged in o Updated lvm to 1.0.7 also some further patches that should not overlap with XFS: o i2c/lm_sensors 2.8.0 o v4l2 api o 3ware driver updates. Here is the user's oops: > Aug 26 06:25:14 stark kernel: Filesystem "ide0(3,2)": XFS internal error > xfs_iformat(6) at line 544 of file xfs_inode.c. Caller 0xc01b8472 > Aug 26 06:25:14 stark kernel: c09dfd0c c01b6f11 c02d37d0 00000001 c1ad4c00 > c02d3790 00000220 c01b8472 > Aug 26 06:25:14 stark kernel: c3c95a16 00000008 c1ad4c00 99a49e15 > 159e4e82 00000000 00000000 00000000 > Aug 26 06:25:14 stark kernel: 00000000 c1ad4c00 c671ac00 c01b8472 > c671ac00 c3c95a00 00000001 00000000 >=20 > Trace; c01b6f11 > Trace; c01b8472 > Trace; c01b8472 > Trace; c01b5ac6 > Trace; c01b5ff3 > Trace; c01cfb64 > Trace; c01d54b5 > Trace; c01e3ff7 > Trace; c014f857 > Trace; c014fda9 > Trace; c0150249 > Trace; c01504d9 <__user_walk+49/60> > Trace; c014bf5f > Trace; c014c59b > Trace; c0140001 > Trace; c010939f > Trace; c01b6f11 > Trace; c01b8472 > Trace; c01b8472 > Trace; c01b5ac6 > Trace; c01b5ff3 > Trace; c01cfb64 > Trace; c01d54b5 > Trace; c01e3ff7 > Trace; c014f857 > Trace; c014fda9 > Trace; c0150249 > Trace; c01504d9 <__user_walk+49/60> > Trace; c014bf5f > Trace; c014eaf2 > Trace; c014c59b > Trace; c0144859 > Trace; c010939f Any idea what caused the oops? Thanks! --=20 Axel.Thimm@physik.fu-berlin.de =20 --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/S44iQBVS1GOamfERApX3AJ9vubdc1ddWL+QNG7q73dAcL4sWZACeMger jBlEOu3zC7AJoBr+b9iOJds= =RNJf -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-linux-xfs@oss.sgi.com Tue Aug 26 10:11:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 10:11: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 h7QHBLoO018488 for ; Tue, 26 Aug 2003 10:11:22 -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 h7QHBGq0027273 for ; Tue, 26 Aug 2003 10:11:16 -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 h7QHAFaK10533966; Tue, 26 Aug 2003 12:10: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 h7QHAFRn251075614; Tue, 26 Aug 2003 12:10:15 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h7QHAF822543; Tue, 26 Aug 2003 12:10:15 -0500 Subject: Re: XFS internal error: RH 2.4.20-20.9 & XFS 1.3.0 & others From: Steve Lord To: Axel Thimm Cc: linux-xfs@oss.sgi.com, radus@rdsor.ro In-Reply-To: <20030826164314.GA7257@pua.nirvana> References: <20030826164314.GA7257@pua.nirvana> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1061917814.25889.1328.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 26 Aug 2003 12:10:15 -0500 X-archive-position: 187 X-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: 1408 Lines: 41 On Tue, 2003-08-26 at 11:43, Axel Thimm wrote: > Hi, > > I got a bug report by radus using the atrpms kernels on Debian (the > kernels are for RedHat and he takes the kernel-source rpm and uses it > for building on Debian with some workarounds for gcc 3.3). > > The kernel in question has > o Red Hat 2.4.20-20.9 base sources > o XFS 1.3.0 merged in > o Updated lvm to 1.0.7 > > also some further patches that should not overlap with XFS: > > o i2c/lm_sensors 2.8.0 > o v4l2 api > o 3ware driver updates. > > Here is the user's oops: > > Aug 26 06:25:14 stark kernel: Filesystem "ide0(3,2)": XFS internal error > > xfs_iformat(6) at line 544 of file xfs_inode.c. Caller 0xc01b8472 > > Aug 26 06:25:14 stark kernel: c09dfd0c c01b6f11 c02d37d0 00000001 c1ad4c00 > > c02d3790 00000220 c01b8472 > > Aug 26 06:25:14 stark kernel: c3c95a16 00000008 c1ad4c00 99a49e15 > > 159e4e82 00000000 00000000 00000000 > > Aug 26 06:25:14 stark kernel: 00000000 c1ad4c00 c671ac00 c01b8472 > > c671ac00 c3c95a00 00000001 00000000 > > That is a corrupt inode on the disk, time to break out xfs_repair. Do a quick mount and unmount of the fs first, then run xfs_check and save the output, finally run xfs_repair and send us the output of both commands. 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 26 10:42:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 10:43:01 -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 h7QHgQoO021531 for ; Tue, 26 Aug 2003 10:42:46 -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 h7QHfxo16649; Tue, 26 Aug 2003 10:42:00 -0700 Date: Tue, 26 Aug 2003 10:44:58 -0700 From: Andrew Morton To: suparna@in.ibm.com Cc: lord@sgi.com, barryn@pobox.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@oss.sgi.com Subject: Re: [BUG] 2.6.0-test4-mm1: NFS+XFS=data corruption Message-Id: <20030826104458.448d1eea.akpm@osdl.org> In-Reply-To: <20030826110111.GA4750@in.ibm.com> References: <20030824171318.4acf1182.akpm@osdl.org> <20030825193717.GC3562@ip68-4-255-84.oc.oc.cox.net> <20030825124543.413187a5.akpm@osdl.org> <1061852050.25892.195.camel@jen.americas.sgi.com> <20030826031412.72785b15.akpm@osdl.org> <20030826110111.GA4750@in.ibm.com> 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: 188 X-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: 349 Lines: 12 Suparna Bhattacharya wrote: > > > Binary searching reveals that the offending patch is > > O_SYNC-speedup-nolock-fix.patch > > > > I'm not sure if this would help here, but there is > one bug which I just spotted which would affect writev from > XFS. I wasn't passing the nr_segs down properly. That fixes it, thanks. From owner-linux-xfs@oss.sgi.com Tue Aug 26 10:52:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 10:52:21 -0700 (PDT) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QHq6oO022596 for ; Tue, 26 Aug 2003 10:52:06 -0700 Received: (qmail 21312 invoked from network); 26 Aug 2003 20:52:05 +0300 Received: from unknown (HELO localhost) (62.231.85.236) by mail.rdsor.ro with SMTP; 26 Aug 2003 20:52:02 +0300 From: radus To: Steve Lord Subject: Re: XFS internal error: RH 2.4.20-20.9 & XFS 1.3.0 & others Date: Tue, 26 Aug 2003 20:52:17 +0300 User-Agent: KMail/1.5.9 References: <20030826164314.GA7257@pua.nirvana> <1061917814.25889.1328.camel@jen.americas.sgi.com> In-Reply-To: <1061917814.25889.1328.camel@jen.americas.sgi.com> Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_R55S/4i37ta5h7P" Message-Id: <200308262052.18157.radus@rdsor.ro> X-archive-position: 189 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: radus@rdsor.ro Precedence: bulk X-list: linux-xfs Content-Length: 47471 Lines: 1043 --Boundary-00=_R55S/4i37ta5h7P Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello! I hope that fixed it, there quite a few errors.. However i find it weird that on another partition which is double in size and almost all the time writes or reads something, didn't have any errors... Also couldn't there be implemented instead of a kernel error a message or something ? Radu On Tuesday 26 August 2003 20:10, you wrote: > On Tue, 2003-08-26 at 11:43, Axel Thimm wrote: > > Hi, > > > > I got a bug report by radus using the atrpms kernels on Debian (the > > kernels are for RedHat and he takes the kernel-source rpm and uses it > > for building on Debian with some workarounds for gcc 3.3). > > > > The kernel in question has > > o Red Hat 2.4.20-20.9 base sources > > o XFS 1.3.0 merged in > > o Updated lvm to 1.0.7 > > > > also some further patches that should not overlap with XFS: > > > > o i2c/lm_sensors 2.8.0 > > o v4l2 api > > o 3ware driver updates. > > > > Here is the user's oops: > > > Aug 26 06:25:14 stark kernel: Filesystem "ide0(3,2)": XFS internal > > > error xfs_iformat(6) at line 544 of file xfs_inode.c. Caller > > > 0xc01b8472 Aug 26 06:25:14 stark kernel: c09dfd0c c01b6f11 c02d37d0 > > > 00000001 c1ad4c00 c02d3790 00000220 c01b8472 > > > Aug 26 06:25:14 stark kernel: c3c95a16 00000008 c1ad4c00 > > > 99a49e15 159e4e82 00000000 00000000 00000000 > > > Aug 26 06:25:14 stark kernel: 00000000 c1ad4c00 c671ac00 > > > c01b8472 c671ac00 c3c95a00 00000001 00000000 > > That is a corrupt inode on the disk, time to break out xfs_repair. Do > a quick mount and unmount of the fs first, then run xfs_check and save > the output, finally run xfs_repair and send us the output of both > commands. > > Steve --Boundary-00=_R55S/4i37ta5h7P Content-Type: text/plain; charset="iso-8859-1"; name="errors.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="errors.txt" agi unlinked bucket 0 is 20544 in ag 0 (inode=20544) bad version number 0xffffffeb for inode 4208698 bad magic number 0xe7ac for inode 4208699 bad magic number 0 for inode 4208700 bad magic number 0 for inode 4208701 bad magic number 0 for inode 4208702 bad magic number 0 for inode 4208703 agi unlinked bucket 3 is 2499 in ag 1 (inode=4196803) agi unlinked bucket 9 is 26249 in ag 1 (inode=4220553) agi unlinked bucket 10 is 14474 in ag 1 (inode=4208778) agi unlinked bucket 12 is 14476 in ag 1 (inode=4208780) agi unlinked bucket 13 is 16013 in ag 1 (inode=4210317) agi unlinked bucket 14 is 16014 in ag 1 (inode=4210318) agi unlinked bucket 15 is 26255 in ag 1 (inode=4220559) agi unlinked bucket 17 is 26257 in ag 1 (inode=4220561) agi unlinked bucket 19 is 16659 in ag 1 (inode=4210963) agi unlinked bucket 28 is 26204 in ag 1 (inode=4220508) agi unlinked bucket 29 is 14493 in ag 1 (inode=4208797) agi unlinked bucket 30 is 23902 in ag 1 (inode=4218206) agi unlinked bucket 32 is 2208 in ag 1 (inode=4196512) agi unlinked bucket 33 is 2209 in ag 1 (inode=4196513) agi unlinked bucket 41 is 7465 in ag 1 (inode=4201769) agi unlinked bucket 42 is 4394 in ag 1 (inode=4198698) agi unlinked bucket 43 is 26219 in ag 1 (inode=4220523) agi unlinked bucket 44 is 26220 in ag 1 (inode=4220524) agi unlinked bucket 46 is 26222 in ag 1 (inode=4220526) agi unlinked bucket 47 is 2287 in ag 1 (inode=4196591) agi unlinked bucket 49 is 26225 in ag 1 (inode=4220529) agi unlinked bucket 50 is 7474 in ag 1 (inode=4201778) agi unlinked bucket 52 is 40948 in ag 1 (inode=4235252) agi unlinked bucket 53 is 147061 in ag 1 (inode=4341365) agi unlinked bucket 54 is 26230 in ag 1 (inode=4220534) agi unlinked bucket 57 is 14521 in ag 1 (inode=4208825) agi unlinked bucket 58 is 40954 in ag 1 (inode=4235258) agi unlinked bucket 59 is 26235 in ag 1 (inode=4220539) agi unlinked bucket 60 is 14524 in ag 1 (inode=4208828) agi unlinked bucket 61 is 26237 in ag 1 (inode=4220541) agi unlinked bucket 62 is 2302 in ag 1 (inode=4196606) agi unlinked bucket 63 is 14527 in ag 1 (inode=4208831) agi unlinked bucket 1 is 657857 in ag 2 (inode=9046465) agi unlinked bucket 2 is 657858 in ag 2 (inode=9046466) agi unlinked bucket 4 is 657860 in ag 2 (inode=9046468) agi unlinked bucket 5 is 657861 in ag 2 (inode=9046469) agi unlinked bucket 6 is 657862 in ag 2 (inode=9046470) agi unlinked bucket 7 is 657863 in ag 2 (inode=9046471) agi unlinked bucket 8 is 657864 in ag 2 (inode=9046472) agi unlinked bucket 9 is 657865 in ag 2 (inode=9046473) agi unlinked bucket 10 is 657866 in ag 2 (inode=9046474) agi unlinked bucket 0 is 256 in ag 3 (inode=12583168) agi unlinked bucket 1 is 257 in ag 3 (inode=12583169) agi unlinked bucket 2 is 258 in ag 3 (inode=12583170) agi unlinked bucket 3 is 259 in ag 3 (inode=12583171) agi unlinked bucket 4 is 5508 in ag 3 (inode=12588420) agi unlinked bucket 5 is 6213 in ag 3 (inode=12589125) agi unlinked bucket 6 is 6214 in ag 3 (inode=12589126) agi unlinked bucket 7 is 6215 in ag 3 (inode=12589127) agi unlinked bucket 8 is 6216 in ag 3 (inode=12589128) agi unlinked bucket 9 is 27721 in ag 3 (inode=12610633) agi unlinked bucket 10 is 27722 in ag 3 (inode=12610634) agi unlinked bucket 11 is 27723 in ag 3 (inode=12610635) agi unlinked bucket 13 is 20301 in ag 3 (inode=12603213) agi unlinked bucket 15 is 22799 in ag 3 (inode=12605711) agi unlinked bucket 16 is 6224 in ag 3 (inode=12589136) agi unlinked bucket 17 is 5521 in ag 3 (inode=12588433) agi unlinked bucket 18 is 22802 in ag 3 (inode=12605714) agi unlinked bucket 19 is 5523 in ag 3 (inode=12588435) agi unlinked bucket 20 is 63700 in ag 3 (inode=12646612) agi unlinked bucket 21 is 5525 in ag 3 (inode=12588437) agi unlinked bucket 22 is 5526 in ag 3 (inode=12588438) agi unlinked bucket 23 is 6231 in ag 3 (inode=12589143) agi unlinked bucket 24 is 5528 in ag 3 (inode=12588440) agi unlinked bucket 25 is 6233 in ag 3 (inode=12589145) agi unlinked bucket 27 is 20379 in ag 3 (inode=12603291) agi unlinked bucket 28 is 5532 in ag 3 (inode=12588444) agi unlinked bucket 29 is 27293 in ag 3 (inode=12610205) agi unlinked bucket 30 is 6238 in ag 3 (inode=12589150) agi unlinked bucket 31 is 5535 in ag 3 (inode=12588447) agi unlinked bucket 32 is 27616 in ag 3 (inode=12610528) agi unlinked bucket 33 is 2401 in ag 3 (inode=12585313) agi unlinked bucket 34 is 63906 in ag 3 (inode=12646818) agi unlinked bucket 35 is 63715 in ag 3 (inode=12646627) agi unlinked bucket 36 is 63908 in ag 3 (inode=12646820) agi unlinked bucket 37 is 70245 in ag 3 (inode=12653157) agi unlinked bucket 38 is 70246 in ag 3 (inode=12653158) agi unlinked bucket 39 is 70247 in ag 3 (inode=12653159) agi unlinked bucket 40 is 67688 in ag 3 (inode=12650600) agi unlinked bucket 41 is 67689 in ag 3 (inode=12650601) agi unlinked bucket 42 is 67690 in ag 3 (inode=12650602) agi unlinked bucket 44 is 5484 in ag 3 (inode=12588396) agi unlinked bucket 45 is 67693 in ag 3 (inode=12650605) agi unlinked bucket 46 is 67694 in ag 3 (inode=12650606) agi unlinked bucket 47 is 67695 in ag 3 (inode=12650607) agi unlinked bucket 50 is 242 in ag 3 (inode=12583154) agi unlinked bucket 51 is 5491 in ag 3 (inode=12588403) agi unlinked bucket 52 is 2420 in ag 3 (inode=12585332) agi unlinked bucket 54 is 246 in ag 3 (inode=12583158) agi unlinked bucket 55 is 20279 in ag 3 (inode=12603191) agi unlinked bucket 56 is 20280 in ag 3 (inode=12603192) agi unlinked bucket 57 is 5497 in ag 3 (inode=12588409) agi unlinked bucket 58 is 250 in ag 3 (inode=12583162) agi unlinked bucket 59 is 251 in ag 3 (inode=12583163) agi unlinked bucket 60 is 252 in ag 3 (inode=12583164) agi unlinked bucket 61 is 253 in ag 3 (inode=12583165) agi unlinked bucket 62 is 254 in ag 3 (inode=12583166) agi unlinked bucket 63 is 255 in ag 3 (inode=12583167) agi unlinked bucket 0 is 16640 in ag 4 (inode=16793856) agi unlinked bucket 2 is 16642 in ag 4 (inode=16793858) agi unlinked bucket 4 is 16644 in ag 4 (inode=16793860) agi unlinked bucket 5 is 16645 in ag 4 (inode=16793861) agi unlinked bucket 7 is 16647 in ag 4 (inode=16793863) agi unlinked bucket 11 is 28683 in ag 4 (inode=16805899) agi unlinked bucket 12 is 28684 in ag 4 (inode=16805900) agi unlinked bucket 14 is 28686 in ag 4 (inode=16805902) agi unlinked bucket 15 is 28687 in ag 4 (inode=16805903) agi unlinked bucket 16 is 1104 in ag 4 (inode=16778320) agi unlinked bucket 17 is 28689 in ag 4 (inode=16805905) agi unlinked bucket 22 is 26582 in ag 4 (inode=16803798) agi unlinked bucket 24 is 28696 in ag 4 (inode=16805912) agi unlinked bucket 26 is 26586 in ag 4 (inode=16803802) agi unlinked bucket 27 is 22427 in ag 4 (inode=16799643) agi unlinked bucket 28 is 28700 in ag 4 (inode=16805916) agi unlinked bucket 29 is 28701 in ag 4 (inode=16805917) agi unlinked bucket 30 is 95390 in ag 4 (inode=16872606) agi unlinked bucket 31 is 1119 in ag 4 (inode=16778335) agi unlinked bucket 32 is 1120 in ag 4 (inode=16778336) agi unlinked bucket 35 is 26531 in ag 4 (inode=16803747) agi unlinked bucket 39 is 227239 in ag 4 (inode=17004455) agi unlinked bucket 42 is 22442 in ag 4 (inode=16799658) agi unlinked bucket 43 is 23595 in ag 4 (inode=16800811) agi unlinked bucket 44 is 22444 in ag 4 (inode=16799660) agi unlinked bucket 45 is 22445 in ag 4 (inode=16799661) agi unlinked bucket 46 is 22446 in ag 4 (inode=16799662) agi unlinked bucket 47 is 22447 in ag 4 (inode=16799663) agi unlinked bucket 50 is 22450 in ag 4 (inode=16799666) agi unlinked bucket 52 is 16308 in ag 4 (inode=16793524) agi unlinked bucket 53 is 22453 in ag 4 (inode=16799669) agi unlinked bucket 59 is 22331 in ag 4 (inode=16799547) agi unlinked bucket 61 is 15485 in ag 4 (inode=16792701) agi unlinked bucket 63 is 15487 in ag 4 (inode=16792703) agi unlinked bucket 8 is 3976 in ag 5 (inode=20975496) agi unlinked bucket 10 is 10698 in ag 5 (inode=20982218) agi unlinked bucket 20 is 10708 in ag 5 (inode=20982228) agi unlinked bucket 25 is 4121 in ag 5 (inode=20975641) agi unlinked bucket 27 is 155 in ag 5 (inode=20971675) agi unlinked bucket 33 is 6881 in ag 5 (inode=20978401) agi unlinked bucket 35 is 6883 in ag 5 (inode=20978403) agi unlinked bucket 36 is 10724 in ag 5 (inode=20982244) agi unlinked bucket 38 is 10726 in ag 5 (inode=20982246) agi unlinked bucket 42 is 129194 in ag 5 (inode=21100714) agi unlinked bucket 46 is 27502 in ag 5 (inode=20999022) agi unlinked bucket 47 is 104495 in ag 5 (inode=21076015) agi unlinked bucket 49 is 32369 in ag 5 (inode=21003889) agi unlinked bucket 51 is 32371 in ag 5 (inode=21003891) agi unlinked bucket 52 is 10676 in ag 5 (inode=20982196) agi unlinked bucket 53 is 32373 in ag 5 (inode=21003893) agi unlinked bucket 54 is 94518 in ag 5 (inode=21066038) agi unlinked bucket 55 is 32375 in ag 5 (inode=21003895) agi unlinked bucket 58 is 10554 in ag 5 (inode=20982074) agi unlinked bucket 59 is 10747 in ag 5 (inode=20982267) agi unlinked bucket 60 is 28348 in ag 5 (inode=20999868) agi unlinked bucket 1 is 68353 in ag 6 (inode=25234177) agi unlinked bucket 10 is 36106 in ag 6 (inode=25201930) agi unlinked bucket 11 is 971 in ag 6 (inode=25166795) agi unlinked bucket 25 is 36121 in ag 6 (inode=25201945) agi unlinked bucket 30 is 36126 in ag 6 (inode=25201950) agi unlinked bucket 37 is 36517 in ag 6 (inode=25202341) agi unlinked bucket 57 is 36537 in ag 6 (inode=25202361) agi unlinked bucket 38 is 38758 in ag 8 (inode=33593190) agi unlinked bucket 8 is 21832 in ag 9 (inode=37770568) agi unlinked bucket 58 is 45690 in ag 9 (inode=37794426) agi unlinked bucket 45 is 151533 in ag 12 (inode=50483181) agi unlinked bucket 32 is 7520 in ag 14 (inode=58727776) agi unlinked bucket 35 is 23587 in ag 16 (inode=67132451) agi unlinked bucket 40 is 25640 in ag 16 (inode=67134504) agi unlinked bucket 43 is 25643 in ag 16 (inode=67134507) agi unlinked bucket 36 is 91940 in ag 18 (inode=75589412) allocated inode 20544 has 0 link count block 1/871 type unknown not expected block 1/872 type unknown not expected block 1/878 type unknown not expected block 1/881 type unknown not expected block 1/882 type unknown not expected block 1/888 type unknown not expected allocated inode 4200767 has 0 link count allocated inode 4196512 has 0 link count allocated inode 4196513 has 0 link count allocated inode 4235252 has 0 link count allocated inode 4235258 has 0 link count allocated inode 4235259 has 0 link count allocated inode 4235260 has 0 link count allocated inode 4235261 has 0 link count allocated inode 4235262 has 0 link count allocated inode 4196540 has 0 link count allocated inode 4196541 has 0 link count allocated inode 4198698 has 0 link count allocated inode 4196553 has 0 link count allocated inode 4196554 has 0 link count allocated inode 4196591 has 0 link count allocated inode 4196606 has 0 link count allocated inode 4218206 has 0 link count allocated inode 4196803 has 0 link count allocated inode 4220493 has 0 link count allocated inode 4220508 has 0 link count allocated inode 4220509 has 0 link count allocated inode 4220523 has 0 link count allocated inode 4220524 has 0 link count allocated inode 4220526 has 0 link count allocated inode 4220527 has 0 link count allocated inode 4220529 has 0 link count allocated inode 4220533 has 0 link count allocated inode 4220534 has 0 link count link count mismatch for inode 4208698 (name ?), nlink 0, counted 1 link count mismatch for inode 4208699 (name ?), nlink 0, counted 1 link count mismatch for inode 4208700 (name ?), nlink 0, counted 1 allocated inode 4220537 has 0 link count link count mismatch for inode 4208701 (name ?), nlink 0, counted 1 link count mismatch for inode 4208702 (name ?), nlink 0, counted 1 allocated inode 4220539 has 0 link count link count mismatch for inode 4208703 (name ?), nlink 0, counted 1 allocated inode 4220541 has 0 link count allocated inode 4220553 has 0 link count allocated inode 4220557 has 0 link count allocated inode 4220559 has 0 link count allocated inode 4220561 has 0 link count allocated inode 4208778 has 0 link count allocated inode 4208780 has 0 link count allocated inode 4208781 has 0 link count allocated inode 4208787 has 0 link count allocated inode 4208797 has 0 link count allocated inode 4210963 has 0 link count allocated inode 4208825 has 0 link count allocated inode 4208828 has 0 link count allocated inode 4208831 has 0 link count allocated inode 4212064 has 0 link count allocated inode 4341365 has 0 link count allocated inode 4210317 has 0 link count allocated inode 4210318 has 0 link count allocated inode 4201769 has 0 link count allocated inode 4201778 has 0 link count allocated inode 9046465 has 0 link count allocated inode 9046466 has 0 link count allocated inode 9046468 has 0 link count allocated inode 9046469 has 0 link count allocated inode 9046470 has 0 link count allocated inode 9046471 has 0 link count allocated inode 9046472 has 0 link count allocated inode 9046473 has 0 link count allocated inode 9046474 has 0 link count allocated inode 12585084 has 0 link count allocated inode 12585160 has 0 link count allocated inode 12588396 has 0 link count allocated inode 12588400 has 0 link count allocated inode 12588401 has 0 link count allocated inode 12588402 has 0 link count allocated inode 12588403 has 0 link count allocated inode 12588406 has 0 link count allocated inode 12588407 has 0 link count allocated inode 12588408 has 0 link count allocated inode 12588409 has 0 link count allocated inode 12588410 has 0 link count allocated inode 12588411 has 0 link count allocated inode 12588412 has 0 link count allocated inode 12588413 has 0 link count allocated inode 12588414 has 0 link count allocated inode 12588415 has 0 link count allocated inode 12588416 has 0 link count allocated inode 12588417 has 0 link count allocated inode 12588418 has 0 link count allocated inode 12588419 has 0 link count allocated inode 12588420 has 0 link count allocated inode 12588421 has 0 link count allocated inode 12588433 has 0 link count allocated inode 12588434 has 0 link count allocated inode 12588435 has 0 link count allocated inode 12588437 has 0 link count allocated inode 12588438 has 0 link count allocated inode 12588440 has 0 link count allocated inode 12588441 has 0 link count allocated inode 12588442 has 0 link count allocated inode 12588443 has 0 link count allocated inode 12588444 has 0 link count allocated inode 12588445 has 0 link count allocated inode 12588446 has 0 link count allocated inode 12583066 has 0 link count allocated inode 12588447 has 0 link count allocated inode 12613216 has 0 link count allocated inode 12613218 has 0 link count allocated inode 12613220 has 0 link count allocated inode 12613227 has 0 link count allocated inode 12613229 has 0 link count allocated inode 12613230 has 0 link count allocated inode 12613231 has 0 link count allocated inode 12613239 has 0 link count allocated inode 12613240 has 0 link count allocated inode 12605711 has 0 link count allocated inode 12605714 has 0 link count allocated inode 12613249 has 0 link count allocated inode 12613250 has 0 link count allocated inode 12613251 has 0 link count allocated inode 12631544 has 0 link count allocated inode 12613252 has 0 link count allocated inode 12631546 has 0 link count allocated inode 12613254 has 0 link count allocated inode 12646612 has 0 link count allocated inode 12631548 has 0 link count allocated inode 12646613 has 0 link count allocated inode 12613257 has 0 link count allocated inode 12646615 has 0 link count allocated inode 12646616 has 0 link count allocated inode 12646617 has 0 link count allocated inode 12646618 has 0 link count allocated inode 12613265 has 0 link count allocated inode 12585292 has 0 link count allocated inode 12646626 has 0 link count allocated inode 12646627 has 0 link count allocated inode 12583147 has 0 link count allocated inode 12583153 has 0 link count allocated inode 12583154 has 0 link count allocated inode 12583158 has 0 link count allocated inode 12585313 has 0 link count allocated inode 12585314 has 0 link count allocated inode 12583162 has 0 link count allocated inode 12585315 has 0 link count allocated inode 12583163 has 0 link count allocated inode 12585316 has 0 link count allocated inode 12583164 has 0 link count allocated inode 12585317 has 0 link count allocated inode 12583165 has 0 link count allocated inode 12585318 has 0 link count allocated inode 12583166 has 0 link count allocated inode 12583167 has 0 link count allocated inode 12585320 has 0 link count allocated inode 12583168 has 0 link count allocated inode 12585321 has 0 link count allocated inode 12583169 has 0 link count allocated inode 12583170 has 0 link count allocated inode 12583171 has 0 link count allocated inode 12585328 has 0 link count allocated inode 12585332 has 0 link count allocated inode 12653157 has 0 link count allocated inode 12653158 has 0 link count allocated inode 12653159 has 0 link count allocated inode 12585382 has 0 link count allocated inode 12610205 has 0 link count allocated inode 12646818 has 0 link count allocated inode 12646820 has 0 link count allocated inode 12646823 has 0 link count allocated inode 12610278 has 0 link count allocated inode 12610287 has 0 link count allocated inode 12610288 has 0 link count allocated inode 12610289 has 0 link count allocated inode 12646900 has 0 link count allocated inode 12646934 has 0 link count allocated inode 12646935 has 0 link count allocated inode 12646936 has 0 link count allocated inode 12646937 has 0 link count allocated inode 12646940 has 0 link count allocated inode 12646941 has 0 link count allocated inode 12592101 has 0 link count allocated inode 12592105 has 0 link count allocated inode 12592107 has 0 link count allocated inode 12592108 has 0 link count allocated inode 12592109 has 0 link count allocated inode 12610528 has 0 link count allocated inode 12647114 has 0 link count allocated inode 12647118 has 0 link count allocated inode 12647119 has 0 link count allocated inode 12610633 has 0 link count allocated inode 12610634 has 0 link count allocated inode 12610635 has 0 link count allocated inode 12589125 has 0 link count allocated inode 12589126 has 0 link count allocated inode 12589127 has 0 link count allocated inode 12589128 has 0 link count allocated inode 12589129 has 0 link count allocated inode 12589130 has 0 link count allocated inode 12589131 has 0 link count allocated inode 12589132 has 0 link count allocated inode 12589133 has 0 link count allocated inode 12589134 has 0 link count allocated inode 12589135 has 0 link count allocated inode 12589136 has 0 link count allocated inode 12589137 has 0 link count allocated inode 12589139 has 0 link count allocated inode 12589141 has 0 link count allocated inode 12589142 has 0 link count allocated inode 12589143 has 0 link count allocated inode 12589144 has 0 link count allocated inode 12589145 has 0 link count allocated inode 12589146 has 0 link count allocated inode 12589147 has 0 link count allocated inode 12589149 has 0 link count allocated inode 12589150 has 0 link count allocated inode 12610688 has 0 link count allocated inode 12610689 has 0 link count allocated inode 12610690 has 0 link count allocated inode 12610692 has 0 link count allocated inode 12610693 has 0 link count allocated inode 12610694 has 0 link count allocated inode 12610695 has 0 link count allocated inode 12610697 has 0 link count allocated inode 12610698 has 0 link count allocated inode 12610699 has 0 link count allocated inode 12610700 has 0 link count allocated inode 12610709 has 0 link count allocated inode 12603191 has 0 link count allocated inode 12603192 has 0 link count allocated inode 12603195 has 0 link count allocated inode 12603196 has 0 link count allocated inode 12603197 has 0 link count allocated inode 12603198 has 0 link count allocated inode 12603209 has 0 link count allocated inode 12603210 has 0 link count allocated inode 12596755 has 0 link count allocated inode 12603213 has 0 link count allocated inode 12650600 has 0 link count allocated inode 12650601 has 0 link count allocated inode 12650602 has 0 link count allocated inode 12650605 has 0 link count allocated inode 12650606 has 0 link count allocated inode 12650607 has 0 link count allocated inode 12650608 has 0 link count allocated inode 12610797 has 0 link count allocated inode 12610798 has 0 link count allocated inode 12610799 has 0 link count allocated inode 12610802 has 0 link count allocated inode 12603290 has 0 link count allocated inode 12603291 has 0 link count allocated inode 12629125 has 0 link count allocated inode 12603306 has 0 link count allocated inode 16778320 has 0 link count allocated inode 16778335 has 0 link count allocated inode 16778336 has 0 link count allocated inode 16793524 has 0 link count allocated inode 17004455 has 0 link count allocated inode 16792701 has 0 link count allocated inode 16792703 has 0 link count allocated inode 16792747 has 0 link count allocated inode 16792748 has 0 link count allocated inode 16793856 has 0 link count allocated inode 16793858 has 0 link count allocated inode 16793860 has 0 link count allocated inode 16793861 has 0 link count allocated inode 16793863 has 0 link count allocated inode 16793880 has 0 link count allocated inode 16791827 has 0 link count allocated inode 16872599 has 0 link count allocated inode 16872606 has 0 link count allocated inode 16805899 has 0 link count allocated inode 16803747 has 0 link count allocated inode 16805900 has 0 link count allocated inode 16805902 has 0 link count allocated inode 16805903 has 0 link count allocated inode 16805904 has 0 link count allocated inode 16805905 has 0 link count allocated inode 16805907 has 0 link count allocated inode 16805912 has 0 link count allocated inode 16805916 has 0 link count allocated inode 16805917 has 0 link count allocated inode 16803798 has 0 link count allocated inode 16803799 has 0 link count allocated inode 16803800 has 0 link count allocated inode 16803802 has 0 link count allocated inode 16803803 has 0 link count allocated inode 16803805 has 0 link count allocated inode 16799547 has 0 link count allocated inode 16799643 has 0 link count allocated inode 16799658 has 0 link count allocated inode 16799660 has 0 link count allocated inode 16799661 has 0 link count allocated inode 16799662 has 0 link count allocated inode 16799663 has 0 link count allocated inode 16799666 has 0 link count allocated inode 16799669 has 0 link count allocated inode 16800811 has 0 link count allocated inode 21100714 has 0 link count allocated inode 21003889 has 0 link count allocated inode 21003891 has 0 link count allocated inode 21003893 has 0 link count allocated inode 21003895 has 0 link count allocated inode 21076010 has 0 link count allocated inode 21076015 has 0 link count allocated inode 20971675 has 0 link count allocated inode 20977126 has 0 link count allocated inode 20999868 has 0 link count allocated inode 20978401 has 0 link count allocated inode 20978403 has 0 link count allocated inode 20999022 has 0 link count allocated inode 20975496 has 0 link count allocated inode 20982074 has 0 link count allocated inode 20975641 has 0 link count allocated inode 21066038 has 0 link count allocated inode 21066042 has 0 link count allocated inode 20982196 has 0 link count allocated inode 20982218 has 0 link count allocated inode 20982228 has 0 link count allocated inode 20982244 has 0 link count allocated inode 20982246 has 0 link count allocated inode 20982267 has 0 link count allocated inode 25234113 has 0 link count allocated inode 25234177 has 0 link count allocated inode 25201930 has 0 link count allocated inode 25201945 has 0 link count allocated inode 25201950 has 0 link count allocated inode 25166795 has 0 link count allocated inode 25202341 has 0 link count allocated inode 25202361 has 0 link count allocated inode 33593190 has 0 link count allocated inode 37770568 has 0 link count allocated inode 37794426 has 0 link count allocated inode 50483181 has 0 link count allocated inode 58727776 has 0 link count allocated inode 67134504 has 0 link count allocated inode 67134507 has 0 link count allocated inode 67132451 has 0 link count allocated inode 75589412 has 0 link count --Boundary-00=_R55S/4i37ta5h7P Content-Type: text/plain; charset="iso-8859-1"; name="repair1.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="repair1.txt" 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... error following ag 1 unlinked list error following ag 3 unlinked list error following ag 4 unlinked list error following ag 5 unlinked list error following ag 6 unlinked list - process known inodes and perform inode discovery... - agno = 0 - agno = 1 bad version number 0xffffffeb on inode 4208698 bad (negative) size -4657346330688474654 on inode 4208698 bad magic number 0xe7ac on inode 4208699 bad version number 0xfffffffa on inode 4208699 bad (negative) size -2464258877832455921 on inode 4208699 bad magic number 0x0 on inode 4208700 bad version number 0x0 on inode 4208700 bad magic number 0x0 on inode 4208701 bad version number 0x0 on inode 4208701 bad magic number 0x0 on inode 4208702 bad version number 0x0 on inode 4208702 bad magic number 0x0 on inode 4208703 bad version number 0x0 on inode 4208703 bad version number 0xffffffeb on inode 4208698, resetting version number bad (negative) size -4657346330688474654 on inode 4208698 cleared inode 4208698 bad magic number 0xe7ac on inode 4208699, resetting magic number bad version number 0xfffffffa on inode 4208699, resetting version number bad (negative) size -2464258877832455921 on inode 4208699 cleared inode 4208699 bad magic number 0x0 on inode 4208700, resetting magic number bad version number 0x0 on inode 4208700, resetting version number imap claims a free inode 4208700 is in use, correcting imap and clearing inode cleared inode 4208700 bad magic number 0x0 on inode 4208701, resetting magic number bad version number 0x0 on inode 4208701, resetting version number imap claims a free inode 4208701 is in use, correcting imap and clearing inode cleared inode 4208701 bad magic number 0x0 on inode 4208702, resetting magic number bad version number 0x0 on inode 4208702, resetting version number imap claims a free inode 4208702 is in use, correcting imap and clearing inode cleared inode 4208702 bad magic number 0x0 on inode 4208703, resetting magic number bad version number 0x0 on inode 4208703, resetting version number imap claims a free inode 4208703 is in use, correcting imap and clearing inode cleared inode 4208703 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - 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 entry "menubox" at block 0 offset 296 in directory inode 4208689 references free inode 4208698 clearing inode number in entry at offset 296... entry "menubox1" at block 0 offset 352 in directory inode 4208689 references free inode 4208699 clearing inode number in entry at offset 352... entry "menubox2" at block 0 offset 408 in directory inode 4208689 references free inode 4208700 clearing inode number in entry at offset 408... entry "infobox" at block 0 offset 464 in directory inode 4208689 references free inode 4208701 clearing inode number in entry at offset 464... entry "textbox" at block 0 offset 520 in directory inode 4208689 references free inode 4208702 clearing inode number in entry at offset 520... entry "radiolist" at block 0 offset 576 in directory inode 4208689 references free inode 4208703 clearing inode number in entry at offset 576... - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 4208689 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected inode 20544, moving to lost+found disconnected inode 4196512, moving to lost+found disconnected inode 4196513, moving to lost+found disconnected inode 4196540, moving to lost+found disconnected inode 4196541, moving to lost+found disconnected inode 4196553, moving to lost+found disconnected inode 4196554, moving to lost+found disconnected inode 4196591, moving to lost+found disconnected inode 4196606, moving to lost+found disconnected inode 4196803, moving to lost+found disconnected inode 4198698, moving to lost+found disconnected inode 4200767, moving to lost+found disconnected inode 4201769, moving to lost+found disconnected inode 4201778, moving to lost+found disconnected inode 4208778, moving to lost+found disconnected inode 4208780, moving to lost+found disconnected inode 4208781, moving to lost+found disconnected inode 4208787, moving to lost+found disconnected inode 4208797, moving to lost+found disconnected inode 4208825, moving to lost+found disconnected inode 4208828, moving to lost+found disconnected inode 4208831, moving to lost+found disconnected inode 4210317, moving to lost+found disconnected inode 4210318, moving to lost+found disconnected inode 4210963, moving to lost+found disconnected inode 4212064, moving to lost+found disconnected inode 4218206, moving to lost+found disconnected inode 4220493, moving to lost+found disconnected inode 4220508, moving to lost+found disconnected inode 4220509, moving to lost+found disconnected inode 4220523, moving to lost+found disconnected inode 4220524, moving to lost+found disconnected inode 4220526, moving to lost+found disconnected inode 4220527, moving to lost+found disconnected inode 4220529, moving to lost+found disconnected inode 4220533, moving to lost+found disconnected inode 4220534, moving to lost+found disconnected inode 4220537, moving to lost+found disconnected inode 4220539, moving to lost+found disconnected inode 4220541, moving to lost+found disconnected inode 4220553, moving to lost+found disconnected inode 4220557, moving to lost+found disconnected inode 4220559, moving to lost+found disconnected inode 4220561, moving to lost+found disconnected inode 4235252, moving to lost+found disconnected inode 4235258, moving to lost+found disconnected inode 4235259, moving to lost+found disconnected inode 4235260, moving to lost+found disconnected inode 4235261, moving to lost+found disconnected inode 4235262, moving to lost+found disconnected inode 4341365, moving to lost+found disconnected inode 9046465, moving to lost+found disconnected inode 9046466, moving to lost+found disconnected inode 9046468, moving to lost+found disconnected inode 9046469, moving to lost+found disconnected inode 9046470, moving to lost+found disconnected inode 9046471, moving to lost+found disconnected inode 9046472, moving to lost+found disconnected inode 9046473, moving to lost+found disconnected inode 9046474, moving to lost+found disconnected inode 12583066, moving to lost+found disconnected inode 12583147, moving to lost+found disconnected inode 12583153, moving to lost+found disconnected inode 12583154, moving to lost+found disconnected inode 12583158, moving to lost+found disconnected inode 12583162, moving to lost+found disconnected inode 12583163, moving to lost+found disconnected inode 12583164, moving to lost+found disconnected inode 12583165, moving to lost+found disconnected inode 12583166, moving to lost+found disconnected inode 12583167, moving to lost+found disconnected inode 12583168, moving to lost+found disconnected inode 12583169, moving to lost+found disconnected inode 12583170, moving to lost+found disconnected inode 12583171, moving to lost+found disconnected inode 12585084, moving to lost+found disconnected inode 12585160, moving to lost+found disconnected inode 12585292, moving to lost+found disconnected inode 12585313, moving to lost+found disconnected inode 12585314, moving to lost+found disconnected inode 12585315, moving to lost+found disconnected inode 12585316, moving to lost+found disconnected inode 12585317, moving to lost+found disconnected inode 12585318, moving to lost+found disconnected inode 12585320, moving to lost+found disconnected inode 12585321, moving to lost+found disconnected inode 12585328, moving to lost+found disconnected inode 12585332, moving to lost+found disconnected inode 12585382, moving to lost+found disconnected inode 12588396, moving to lost+found disconnected inode 12588400, moving to lost+found disconnected inode 12588401, moving to lost+found disconnected inode 12588402, moving to lost+found disconnected inode 12588403, moving to lost+found disconnected inode 12588406, moving to lost+found disconnected inode 12588407, moving to lost+found disconnected inode 12588408, moving to lost+found disconnected inode 12588409, moving to lost+found disconnected inode 12588410, moving to lost+found disconnected inode 12588411, moving to lost+found disconnected inode 12588412, moving to lost+found disconnected inode 12588413, moving to lost+found disconnected inode 12588414, moving to lost+found disconnected inode 12588415, moving to lost+found disconnected inode 12588416, moving to lost+found disconnected inode 12588417, moving to lost+found disconnected inode 12588418, moving to lost+found disconnected inode 12588419, moving to lost+found disconnected inode 12588420, moving to lost+found disconnected inode 12588421, moving to lost+found disconnected inode 12588433, moving to lost+found disconnected inode 12588434, moving to lost+found disconnected inode 12588435, moving to lost+found disconnected inode 12588437, moving to lost+found disconnected inode 12588438, moving to lost+found disconnected inode 12588440, moving to lost+found disconnected inode 12588441, moving to lost+found disconnected inode 12588442, moving to lost+found disconnected inode 12588443, moving to lost+found disconnected inode 12588444, moving to lost+found disconnected inode 12588445, moving to lost+found disconnected inode 12588446, moving to lost+found disconnected inode 12588447, moving to lost+found disconnected inode 12589125, moving to lost+found disconnected inode 12589126, moving to lost+found disconnected inode 12589127, moving to lost+found disconnected inode 12589128, moving to lost+found disconnected inode 12589129, moving to lost+found disconnected inode 12589130, moving to lost+found disconnected inode 12589131, moving to lost+found disconnected inode 12589132, moving to lost+found disconnected inode 12589133, moving to lost+found disconnected inode 12589134, moving to lost+found disconnected inode 12589135, moving to lost+found disconnected inode 12589136, moving to lost+found disconnected inode 12589137, moving to lost+found disconnected inode 12589139, moving to lost+found disconnected inode 12589141, moving to lost+found disconnected inode 12589142, moving to lost+found disconnected inode 12589143, moving to lost+found disconnected inode 12589144, moving to lost+found disconnected inode 12589145, moving to lost+found disconnected inode 12589146, moving to lost+found disconnected inode 12589147, moving to lost+found disconnected inode 12589149, moving to lost+found disconnected inode 12589150, moving to lost+found disconnected inode 12592101, moving to lost+found disconnected inode 12592105, moving to lost+found disconnected inode 12592107, moving to lost+found disconnected inode 12592108, moving to lost+found disconnected inode 12592109, moving to lost+found disconnected inode 12596755, moving to lost+found disconnected inode 12603191, moving to lost+found disconnected inode 12603192, moving to lost+found disconnected inode 12603195, moving to lost+found disconnected inode 12603196, moving to lost+found disconnected inode 12603197, moving to lost+found disconnected inode 12603198, moving to lost+found disconnected inode 12603209, moving to lost+found disconnected inode 12603210, moving to lost+found disconnected inode 12603213, moving to lost+found disconnected inode 12603290, moving to lost+found disconnected inode 12603291, moving to lost+found disconnected inode 12603306, moving to lost+found disconnected inode 12605711, moving to lost+found disconnected inode 12605714, moving to lost+found disconnected inode 12610205, moving to lost+found disconnected inode 12610278, moving to lost+found disconnected inode 12610287, moving to lost+found disconnected inode 12610288, moving to lost+found disconnected inode 12610289, moving to lost+found disconnected inode 12610528, moving to lost+found disconnected inode 12610633, moving to lost+found disconnected inode 12610634, moving to lost+found disconnected inode 12610635, moving to lost+found disconnected inode 12610688, moving to lost+found disconnected inode 12610689, moving to lost+found disconnected inode 12610690, moving to lost+found disconnected inode 12610692, moving to lost+found disconnected inode 12610693, moving to lost+found disconnected inode 12610694, moving to lost+found disconnected inode 12610695, moving to lost+found disconnected inode 12610697, moving to lost+found disconnected inode 12610698, moving to lost+found disconnected inode 12610699, moving to lost+found disconnected inode 12610700, moving to lost+found disconnected inode 12610709, moving to lost+found disconnected inode 12610797, moving to lost+found disconnected inode 12610798, moving to lost+found disconnected inode 12610799, moving to lost+found disconnected inode 12610802, moving to lost+found disconnected inode 12613216, moving to lost+found disconnected inode 12613218, moving to lost+found disconnected inode 12613220, moving to lost+found disconnected inode 12613227, moving to lost+found disconnected inode 12613229, moving to lost+found disconnected inode 12613230, moving to lost+found disconnected inode 12613231, moving to lost+found disconnected inode 12613239, moving to lost+found disconnected inode 12613240, moving to lost+found disconnected inode 12613249, moving to lost+found disconnected inode 12613250, moving to lost+found disconnected inode 12613251, moving to lost+found disconnected inode 12613252, moving to lost+found disconnected inode 12613254, moving to lost+found disconnected inode 12613257, moving to lost+found disconnected inode 12613265, moving to lost+found disconnected inode 12629125, moving to lost+found disconnected inode 12631544, moving to lost+found disconnected inode 12631546, moving to lost+found disconnected inode 12631548, moving to lost+found disconnected inode 12646612, moving to lost+found disconnected inode 12646613, moving to lost+found disconnected inode 12646615, moving to lost+found disconnected inode 12646616, moving to lost+found disconnected inode 12646617, moving to lost+found disconnected inode 12646618, moving to lost+found disconnected inode 12646626, moving to lost+found disconnected inode 12646627, moving to lost+found disconnected inode 12646818, moving to lost+found disconnected inode 12646820, moving to lost+found disconnected inode 12646823, moving to lost+found disconnected inode 12646900, moving to lost+found disconnected inode 12646934, moving to lost+found disconnected inode 12646935, moving to lost+found disconnected inode 12646936, moving to lost+found disconnected inode 12646937, moving to lost+found disconnected inode 12646940, moving to lost+found disconnected inode 12646941, moving to lost+found disconnected inode 12647114, moving to lost+found disconnected inode 12647118, moving to lost+found disconnected inode 12647119, moving to lost+found disconnected inode 12650600, moving to lost+found disconnected inode 12650601, moving to lost+found disconnected inode 12650602, moving to lost+found disconnected inode 12650605, moving to lost+found disconnected inode 12650606, moving to lost+found disconnected inode 12650607, moving to lost+found disconnected inode 12650608, moving to lost+found disconnected inode 12653157, moving to lost+found disconnected inode 12653158, moving to lost+found disconnected inode 12653159, moving to lost+found disconnected inode 16778320, moving to lost+found disconnected inode 16778335, moving to lost+found disconnected inode 16778336, moving to lost+found disconnected inode 16791827, moving to lost+found disconnected inode 16792701, moving to lost+found disconnected inode 16792703, moving to lost+found disconnected inode 16792747, moving to lost+found disconnected inode 16792748, moving to lost+found disconnected inode 16793524, moving to lost+found disconnected inode 16793856, moving to lost+found disconnected inode 16793858, moving to lost+found disconnected inode 16793860, moving to lost+found disconnected inode 16793861, moving to lost+found disconnected inode 16793863, moving to lost+found disconnected inode 16793880, moving to lost+found disconnected inode 16799547, moving to lost+found disconnected inode 16799643, moving to lost+found disconnected inode 16799658, moving to lost+found disconnected inode 16799660, moving to lost+found disconnected inode 16799661, moving to lost+found disconnected inode 16799662, moving to lost+found disconnected inode 16799663, moving to lost+found disconnected inode 16799666, moving to lost+found disconnected inode 16799669, moving to lost+found disconnected inode 16800811, moving to lost+found disconnected inode 16803747, moving to lost+found disconnected inode 16803798, moving to lost+found disconnected inode 16803799, moving to lost+found disconnected inode 16803800, moving to lost+found disconnected inode 16803802, moving to lost+found disconnected inode 16803803, moving to lost+found disconnected inode 16803805, moving to lost+found disconnected inode 16805899, moving to lost+found disconnected inode 16805900, moving to lost+found disconnected inode 16805902, moving to lost+found disconnected inode 16805903, moving to lost+found disconnected inode 16805904, moving to lost+found disconnected inode 16805905, moving to lost+found disconnected inode 16805907, moving to lost+found disconnected inode 16805912, moving to lost+found disconnected inode 16805916, moving to lost+found disconnected inode 16805917, moving to lost+found disconnected inode 16872599, moving to lost+found disconnected inode 16872606, moving to lost+found disconnected inode 17004455, moving to lost+found disconnected inode 20971675, moving to lost+found disconnected inode 20975496, moving to lost+found disconnected inode 20975641, moving to lost+found disconnected inode 20977126, moving to lost+found disconnected inode 20978401, moving to lost+found disconnected inode 20978403, moving to lost+found disconnected inode 20982074, moving to lost+found disconnected inode 20982196, moving to lost+found disconnected inode 20982218, moving to lost+found disconnected inode 20982228, moving to lost+found disconnected inode 20982244, moving to lost+found disconnected inode 20982246, moving to lost+found disconnected inode 20982267, moving to lost+found disconnected inode 20999022, moving to lost+found disconnected inode 20999868, moving to lost+found disconnected inode 21003889, moving to lost+found disconnected inode 21003891, moving to lost+found disconnected inode 21003893, moving to lost+found disconnected inode 21003895, moving to lost+found disconnected inode 21066038, moving to lost+found disconnected inode 21066042, moving to lost+found disconnected inode 21076010, moving to lost+found disconnected inode 21076015, moving to lost+found disconnected inode 21100714, moving to lost+found disconnected inode 25166795, moving to lost+found disconnected inode 25201930, moving to lost+found disconnected inode 25201945, moving to lost+found disconnected inode 25201950, moving to lost+found disconnected inode 25202341, moving to lost+found disconnected inode 25202361, moving to lost+found disconnected inode 25234113, moving to lost+found disconnected inode 25234177, moving to lost+found disconnected inode 33593190, moving to lost+found disconnected inode 37770568, moving to lost+found disconnected inode 37794426, moving to lost+found disconnected inode 50483181, moving to lost+found disconnected inode 58727776, moving to lost+found disconnected inode 67132451, moving to lost+found disconnected inode 67134504, moving to lost+found disconnected inode 67134507, moving to lost+found disconnected inode 75589412, moving to lost+found Phase 7 - verify and correct link counts... done --Boundary-00=_R55S/4i37ta5h7P-- From owner-linux-xfs@oss.sgi.com Tue Aug 26 10:57:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 10:57:31 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QHvRoO023274 for ; Tue, 26 Aug 2003 10:57:27 -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 h7QIE0xZ003645 for ; Tue, 26 Aug 2003 13:14:00 -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 h7QHvLaK10648086; Tue, 26 Aug 2003 12:57: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 h7QHvLRn241034590; Tue, 26 Aug 2003 12:57:21 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h7QHvLt22625; Tue, 26 Aug 2003 12:57:21 -0500 Subject: Re: [BUG] 2.6.0-test4-mm1: NFS+XFS=data corruption From: Steve Lord To: Andrew Morton Cc: suparna@in.ibm.com, barryn@pobox.com, Linux Kernel , linux-mm@kvack.org, linux-xfs@oss.sgi.com In-Reply-To: <20030826104458.448d1eea.akpm@osdl.org> References: <20030824171318.4acf1182.akpm@osdl.org> <20030825193717.GC3562@ip68-4-255-84.oc.oc.cox.net> <20030825124543.413187a5.akpm@osdl.org> <1061852050.25892.195.camel@jen.americas.sgi.com> <20030826031412.72785b15.akpm@osdl.org> <20030826110111.GA4750@in.ibm.com> <20030826104458.448d1eea.akpm@osdl.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1061920640.25889.1404.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 26 Aug 2003 12:57:21 -0500 X-archive-position: 190 X-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: 699 Lines: 23 On Tue, 2003-08-26 at 12:44, Andrew Morton wrote: > Suparna Bhattacharya wrote: > > > > > Binary searching reveals that the offending patch is > > > O_SYNC-speedup-nolock-fix.patch > > > > > > > I'm not sure if this would help here, but there is > > one bug which I just spotted which would affect writev from > > XFS. I wasn't passing the nr_segs down properly. > > That fixes it, thanks. Does rpm use readv/writev though? Or does the nfs server? not sure how this change would affect the original problem report. 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 26 11:31:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 11:32:10 -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 h7QIVsoO025064 for ; Tue, 26 Aug 2003 11:31:55 -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 h7QIVVo29638; Tue, 26 Aug 2003 11:31:31 -0700 Date: Tue, 26 Aug 2003 11:34:29 -0700 From: Andrew Morton To: Steve Lord Cc: suparna@in.ibm.com, barryn@pobox.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@oss.sgi.com Subject: Re: [BUG] 2.6.0-test4-mm1: NFS+XFS=data corruption Message-Id: <20030826113429.1440b0d0.akpm@osdl.org> In-Reply-To: <1061920640.25889.1404.camel@jen.americas.sgi.com> References: <20030824171318.4acf1182.akpm@osdl.org> <20030825193717.GC3562@ip68-4-255-84.oc.oc.cox.net> <20030825124543.413187a5.akpm@osdl.org> <1061852050.25892.195.camel@jen.americas.sgi.com> <20030826031412.72785b15.akpm@osdl.org> <20030826110111.GA4750@in.ibm.com> <20030826104458.448d1eea.akpm@osdl.org> <1061920640.25889.1404.camel@jen.americas.sgi.com> 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: 191 X-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: 323 Lines: 9 Steve Lord wrote: > > Does rpm use readv/writev though? Or does the nfs server? not sure > how this change would affect the original problem report. The NFS server uses multisegment writev. RPM was running at the other end of the ethernet, so it doesn't really matter what sort of write RPM is issuing. From owner-linux-xfs@oss.sgi.com Tue Aug 26 13:12:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 13:13:05 -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 h7QKCloO030964 for ; Tue, 26 Aug 2003 13:12:49 -0700 Received: from mailhub.ch.sauter-bc.com (mailhub [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id EAAAD32CA4; Tue, 26 Aug 2003 22:12:41 +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 7A89532CB5; Tue, 26 Aug 2003 22:12:40 +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 C7DA911E0F; Tue, 26 Aug 2003 22:12:39 +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; Tue, 26 Aug 2003 22:12:40 +0200 (CEST) Message-ID: <35485.213.173.165.140.1061928760.squirrel@imap01.ch.sauter-bc.com> In-Reply-To: <1061912643.13459.1.camel@stout.americas.sgi.com> References: <3F4B73F3.1A08113B@ch.sauter-bc.com> <1061912643.13459.1.camel@stout.americas.sgi.com> Date: Tue, 26 Aug 2003 22:12:40 +0200 (CEST) Subject: Re: Patch 1300 & rpm issue with 1.3.0 From: "Simon Matter" To: "Eric Sandeen" Cc: "Kai Leibrandt" , 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 h7QKCnoO030965 X-archive-position: 192 X-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: 2040 Lines: 56 > Simon - the RH9 kernels, where we turned O_DIRECT back on -only- for > xfs, together with the nptl patches in the RH9 kernel, seems to cause > problems with RPM - even if the RPM db is not on xfs. Hmm, and this happens on all x86 platforms? I'm the maintainer of cyrus-imapd rpms and there was already a big surprise with nptl kernels in combination with db4. Interestingly the problem appeared only on AMD K6 and Athlon CPU's. The following error from cyrus-imapd showed up in syslog: May 15 13:51:25 co ctl_cyrusdb[10520]: DBERROR: dbenv->open '/var/lib/imap/db' failed: Function not implemented This was with the original RedHat kernels as well as on XFS enabled ones. The solution was to rebuild db4 without --enable-posixmutexes. A modified spec to rebuild db4 from RedHat is here http://home.teleport.ch/simix/RPMS/Cyrus-imapd/DB4_for_RH-9/db4.spec Is it possible that the nonnptl db4 package is a solution for the problem discussed here? I'll just try it but can someone tell me what problem I should expect if this fix doesn't work. Does rpm not work at all? Simon > > FWIW, the other solution seems to be to get the latest RPMs from rpm.org > (4.2.x) which turn off O_DIRECT in the rpm source. > > I still don't know what the underlying problem actually is. > > -Eric > > On Tue, 2003-08-26 at 09:51, Simon Matter wrote: > >> Hmm, can somebody explain what the patch 1300 problem is? I have built >> my own 2.4.20-20.7.XFS1.3.0 and 2.4.20-20.9.XFS1.3.0 rpms and I'm using >> the 20.7 version on RedHat 7.2 without any problem. Did I miss >> something? Is there a problem when using in on RedHat 9? Of course 20.9 >> has the nptl patches so should I expect any problems which are not >> present in 20.7? > > -- > Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 > > -- Simon Matter Tel: +41 61 695 57 35 Fr.Sauter AG / CIT Fax: +41 61 695 53 30 Im Surinam 55 CH-4016 Basel [mailto:simon.matter@ch.sauter-bc.com] From owner-linux-xfs@oss.sgi.com Tue Aug 26 14:18:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 14:18:57 -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 h7QLIfoO002865 for ; Tue, 26 Aug 2003 14:18:41 -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 h7QLIaq0003108 for ; Tue, 26 Aug 2003 14:18:36 -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 h7QLIZaK10544215; Tue, 26 Aug 2003 16:18:35 -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 h7QLIZwg18820227; Tue, 26 Aug 2003 16:18:35 -0500 (CDT) Subject: Re: Patch 1300 & rpm issue with 1.3.0 From: Eric Sandeen To: Axel Thimm Cc: Simon Matter , Kai Leibrandt , linux-xfs@oss.sgi.com In-Reply-To: <20030826161953.GB6163@pua.nirvana> References: <20030826142327.GB3818@pua.nirvana> <20030826153708.GG3818@pua.nirvana> <1061913418.13459.13.camel@stout.americas.sgi.com> <3F4B73F3.1A08113B@ch.sauter-bc.com> <1061912643.13459.1.camel@stout.americas.sgi.com> <20030826161953.GB6163@pua.nirvana> Content-Type: text/plain Organization: Message-Id: <1061932714.13459.71.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 26 Aug 2003 16:18:34 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 193 X-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: 1033 Lines: 30 Argh, here's one thing that went wrong... my cscope database did not index fs/ext3/file.c, for some reason... so I did not modify it, and O_DIRECT was not getting turned off for ext3 - hence the problem on ext3 roots. I'll test it again on xfs roots... it is probably still a problem there. But at least we can make it behave on "stock" ext3 roots, now. And the failure is a -little- less mysterious. Adding this to the bottom of "linux-2.4.20-xfs-directio-ok.patch" will get ext3 going again --- linux-2.4.20-19.9.XFS1.3.0/fs/ext3/file.c 2002-11-28 17:53:15.000000000 -0600 +++ linux/fs/ext3/file.c 2003-08-26 15:23:43.000000000 -0500 @@ -46,6 +46,7 @@ */ static int ext3_open_file (struct inode * inode, struct file * filp) { + filp->f_flags &= ~O_DIRECT; if (!(filp->f_flags & O_LARGEFILE) && inode->i_size > 0x7FFFFFFFLL) return -EFBIG; -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 Tue Aug 26 15:07:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 15:08: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 h7QM7JoO006500 for ; Tue, 26 Aug 2003 15:07:20 -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 h7QM7Dq0011282 for ; Tue, 26 Aug 2003 15:07:14 -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 IAA19669; Wed, 27 Aug 2003 08:07: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 h7QM7AmY071838; Wed, 27 Aug 2003 08:07:10 +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 h7QM5Y5g000781; Wed, 27 Aug 2003 08:05:34 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7QM5Xn8000778; Wed, 27 Aug 2003 08:05:33 +1000 Date: Wed, 27 Aug 2003 08:05:32 +1000 From: Nathan Scott To: Steve Lord Cc: K Ramesh , linux-xfs@oss.sgi.com Subject: Re: problems with real-time option. Message-ID: <20030826220532.GA769@frodo> References: <1061899804.2030.3.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1061899804.2030.3.camel@laptop.americas.sgi.com> User-Agent: Mutt/1.5.3i X-archive-position: 194 X-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: 1337 Lines: 35 On Tue, Aug 26, 2003 at 07:10:02AM -0500, Steve Lord wrote: > On Tue, 2003-08-26 at 05:29, K Ramesh wrote: > > > > Hi, > > I'm trying to create a real-time subvolume in my Linux System, running > > SuSE 8.1 (Kernel: 2.4.19-64GB-SMP) on a dual-xeon PC. The system has a 3ware > > ATA-Raid controller. > > > > When I try to create a real-time subvolume, this what I get: > > > > wop18:~ # mkfs -t xfs -f -r rtdev=/dev/sda6 /dev/sda5 > > meta-data=/dev/sda5 isize=256 agcount=49, agsize=1048576 blks > > data = bsize=4096 blocks=51201147, imaxpct=25 > > = sunit=0 swidth=0 blks, unwritten=0 > > naming =version 2 bsize=4096 > > log =internal log bsize=4096 blocks=6250, version=1 > > = sunit=0 blks > > realtime =/dev/sda6 extsz=65536 blocks=183237382, > > rtextents=11452336 > > XFS: This FS has an RT subvol - specify -o rtdev on mount > > mkfs.xfs: real-time device init failed > > mkfs.xfs: filesystem failed to initialize Get a new xfsprogs while you're at it, that'll resolve this error. > ... > Your kernel is almost that old ;-) Realtime should be working in recent > kernels, be aware you need to use O_DIRECT to write to realtime > subvolumes. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Aug 26 20:58:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 20:59:07 -0700 (PDT) Received: from mail.imgame.net ([203.177.81.34]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7R3wjoO005544 for ; Tue, 26 Aug 2003 20:58:49 -0700 Received: from 127.0.0.1 (mail.imgame.net [127.0.0.1]) by dummy.domain.name (mail) with SMTP id C64D27D62 for ; Wed, 27 Aug 2003 11:57:02 +0800 (PHT) Received: by mail.imgame.net (mail, from userid 48) id 953EC7D5C; Wed, 27 Aug 2003 11:57:01 +0800 (PHT) Received: from 192.168.0.54 (SquirrelMail authenticated user rvfrancisco) by mail.imgame.net with HTTP; Wed, 27 Aug 2003 11:57:01 +0800 (PHT) Message-ID: <3850.192.168.0.54.1061956621.squirrel@mail.imgame.net> Date: Wed, 27 Aug 2003 11:57:01 +0800 (PHT) Subject: EXPANSION 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: 195 X-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: 715 Lines: 20 GOOD DAY!, I just want to know is there any way to expand a RAID5 partition 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 my raid5 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 expand my partion in Raid5 to expand the capacity? Is there packages needed to repartion my Hardisk? or is their any particular command do i need to run? Thanks.... Regards, Rodel Francisco System Administrator From owner-linux-xfs@oss.sgi.com Tue Aug 26 20:58:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 20:59:07 -0700 (PDT) Received: from mail.imgame.net ([203.177.81.34]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7R3wjoO005545 for ; Tue, 26 Aug 2003 20:58:49 -0700 Received: from 127.0.0.1 (mail.imgame.net [127.0.0.1]) by dummy.domain.name (mail) with SMTP id 93EA67D5C for ; Wed, 27 Aug 2003 11:57:03 +0800 (PHT) Received: by mail.imgame.net (mail, from userid 48) id F02427D5F; Wed, 27 Aug 2003 11:57:01 +0800 (PHT) Received: from 192.168.0.54 (SquirrelMail authenticated user rvfrancisco) by mail.imgame.net with HTTP; Wed, 27 Aug 2003 11:57:01 +0800 (PHT) Message-ID: <3851.192.168.0.54.1061956621.squirrel@mail.imgame.net> Date: Wed, 27 Aug 2003 11:57:01 +0800 (PHT) Subject: EXPANSION 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: 195 X-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: 715 Lines: 20 GOOD DAY!, I just want to know is there any way to expand a RAID5 partition 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 my raid5 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 expand my partion in Raid5 to expand the capacity? Is there packages needed to repartion my Hardisk? or is their any particular command do i need to run? Thanks.... Regards, Rodel Francisco System Administrator From owner-linux-xfs@oss.sgi.com Tue Aug 26 22:21:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 22:21:24 -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 h7R5L7oO009927 for ; Tue, 26 Aug 2003 22:21:08 -0700 Received: from mailhub.ch.sauter-bc.com (mailhub [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id C8C8032CB7; Wed, 27 Aug 2003 07:21:00 +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 780F632CB5; Wed, 27 Aug 2003 07:20:46 +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 122C711E0F; Wed, 27 Aug 2003 07:20:46 +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, 27 Aug 2003 07:20:46 +0200 (CEST) Message-ID: <35976.213.173.165.140.1061961646.squirrel@imap01.ch.sauter-bc.com> In-Reply-To: <3850.192.168.0.54.1061956621.squirrel@mail.imgame.net> References: <3850.192.168.0.54.1061956621.squirrel@mail.imgame.net> Date: Wed, 27 Aug 2003 07:20:46 +0200 (CEST) Subject: Re: EXPANSION PARTITION PROBLEM From: "Simon Matter" To: rvfrancisco@imgame.net 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 h7R5L9oO009932 X-archive-position: 196 X-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: 1645 Lines: 49 > > GOOD DAY!, Rodel, Don't use so many capital letters, this makes your mail look like spam! > > I just want to know is there any way to expand a RAID5 partition 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 my raid5 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 expand my partion in Raid5 > to expand the capacity? Is there packages needed to repartion my Hardisk? > or is their any particular command do i need to run? How did the RAID adapter enlarge the partition? In fact partition is not the right name because it has enlarged the block device on which you partitions are stored. If it simplay appended more blocks at the end of the device, you have to modify your partition table to respect the new physical size. Then you have to grow the partition where you XFS filesystems sits on. And then, you can grow the XFS filesystem with xfs_growfs. You can do the first two steps with fdisk, but maybe there is an easier way. I'm sure there is someone on this list who can tell you exactly how to do it with fdisk, sfdisk or whatever. Simon > Thanks.... > > Regards, > Rodel Francisco > System Administrator > > > > > -- Simon Matter Tel: +41 61 695 57 35 Fr.Sauter AG / CIT Fax: +41 61 695 53 30 Im Surinam 55 CH-4016 Basel [mailto:simon.matter@ch.sauter-bc.com] From owner-linux-xfs@oss.sgi.com Tue Aug 26 22:24:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 22:24:38 -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 h7R5OYoO010449 for ; Tue, 26 Aug 2003 22:24:34 -0700 Received: from mailhub.ch.sauter-bc.com (mailhub [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id A540332CBE; Wed, 27 Aug 2003 07:24:28 +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 705AB32CB5; Wed, 27 Aug 2003 07:24:27 +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 7F56111E0F; Wed, 27 Aug 2003 07:24:26 +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, 27 Aug 2003 07:24:26 +0200 (CEST) Message-ID: <35984.213.173.165.140.1061961866.squirrel@imap01.ch.sauter-bc.com> In-Reply-To: <1061932714.13459.71.camel@stout.americas.sgi.com> References: <20030826142327.GB3818@pua.nirvana> <20030826153708.GG3818@pua.nirvana> <1061913418.13459.13.camel@stout.americas.sgi.com> <3F4B73F3.1A08113B@ch.sauter-bc.com> <1061912643.13459.1.camel@stout.americas.sgi.com> <20030826161953.GB6163@pua.nirvana> <1061932714.13459.71.camel@stout.americas.sgi.com> Date: Wed, 27 Aug 2003 07:24:26 +0200 (CEST) Subject: Re: Patch 1300 & rpm issue with 1.3.0 From: "Simon Matter" To: "Eric Sandeen" Cc: "Axel Thimm" , "Simon Matter" , "Kai Leibrandt" , 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 h7R5OZoO010457 X-archive-position: 197 X-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: 414 Lines: 12 > Argh, here's one thing that went wrong... my cscope database did not > index fs/ext3/file.c, for some reason... so I did not modify it, and > O_DIRECT was not getting turned off for ext3 - hence the problem on ext3 > roots. My question remains, how does the problem discussed here show up. I have installed 20.9.XFS1.3.0 on RedHat 9 with my nonnptl db4 package and couldn't find any problem using rpm. Simon From owner-linux-xfs@oss.sgi.com Tue Aug 26 22:41:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Aug 2003 22:41:59 -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 h7R5fioO011431 for ; Tue, 26 Aug 2003 22:41:46 -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 h7R5fcq0024832 for ; Tue, 26 Aug 2003 22:41:38 -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 h7R5fbJd031160; Wed, 27 Aug 2003 15:41:37 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h7R5faNx031159; Wed, 27 Aug 2003 15:41:36 +1000 Date: Wed, 27 Aug 2003 15:41:36 +1000 From: Nathan Scott Message-Id: <200308270541.h7R5faNx031159@bruce.melbourne.sgi.com> Subject: TAKE - acl/attr X-archive-position: 198 X-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: 506 Lines: 19 Merge acl/attr libmisc fixes from Ben Escoto via AndreasG. Date: Tue Aug 26 22:40:58 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:157419a cmd/acl/VERSION - 1.55 cmd/acl/doc/CHANGES - 1.63 cmd/acl/debian/changelog - 1.49 cmd/attr/VERSION - 1.38 cmd/attr/doc/CHANGES - 1.47 cmd/attr/debian/changelog - 1.41 cmd/attr/libmisc/quote.c - 1.4 cmd/acl/libmisc/quote.c - 1.5 From owner-linux-xfs@oss.sgi.com Wed Aug 27 06:24:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Aug 2003 06:25:05 -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 h7RDNfoO028384 for ; Wed, 27 Aug 2003 06:24:22 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.9/8.12.9) with ESMTP id h7RDNbMn020716 for ; Wed, 27 Aug 2003 09:23:37 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.9/8.12.9/Submit) with ESMTP id h7RDNblZ003386 for ; Wed, 27 Aug 2003 09:23:37 -0400 Date: Wed, 27 Aug 2003 09:23:37 -0400 (EDT) From: Net Llama! To: linux-xfs@oss.sgi.com Subject: 2.4.22 in cvs? 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: 199 X-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: 250 Lines: 7 Anyone know if the code in cvs will apply cleanly on 2.4.22? thanks! -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 27 09:14:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Aug 2003 09:14:28 -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 h7RGDPoO006345 for ; Wed, 27 Aug 2003 09:14:06 -0700 Received: from puariko.homeip.net (r10acci-a15-204.acci.gr [195.170.15.204]) by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id h7RGD2Hl019210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Aug 2003 18:13:08 +0200 Received: (from thimm@localhost) by pua.nirvana (8.12.9/8.12.9/Submit) id h7RGCvgW004446; Wed, 27 Aug 2003 19:12:57 +0300 Date: Wed, 27 Aug 2003 19:12:57 +0300 From: Axel Thimm To: Simon Matter Cc: Eric Sandeen , Kai Leibrandt , linux-xfs@oss.sgi.com Subject: Re: Patch 1300 & rpm issue with 1.3.0 Message-ID: <20030827161257.GD2864@pua.nirvana> References: <20030826142327.GB3818@pua.nirvana> <20030826153708.GG3818@pua.nirvana> <1061913418.13459.13.camel@stout.americas.sgi.com> <3F4B73F3.1A08113B@ch.sauter-bc.com> <1061912643.13459.1.camel@stout.americas.sgi.com> <20030826161953.GB6163@pua.nirvana> <1061932714.13459.71.camel@stout.americas.sgi.com> <35984.213.173.165.140.1061961866.squirrel@imap01.ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cHMo6Wbp1wrKhbfi" Content-Disposition: inline In-Reply-To: <35984.213.173.165.140.1061961866.squirrel@imap01.ch.sauter-bc.com> User-Agent: Mutt/1.4.1i X-archive-position: 200 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1429 Lines: 45 --cHMo6Wbp1wrKhbfi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Aug 27, 2003 at 07:24:26AM +0200, Simon Matter wrote: > > Argh, here's one thing that went wrong... my cscope database did not > > index fs/ext3/file.c, for some reason... so I did not modify it, and > > O_DIRECT was not getting turned off for ext3 - hence the problem on ext3 > > roots. >=20 > My question remains, how does the problem discussed here show up. I have > installed 20.9.XFS1.3.0 on RedHat 9 with my nonnptl db4 package and > couldn't find any problem using rpm. I think (haven't rebuild rpm for some time), that db4 is not linked against, but has been embedded into rpm's sources. Try ldd on /bin/rpm, you'll find it depending on librpmdb-4.2.so, and not libdb-4.*.so It was said that latest rpm bits (4.2, 4.1.1 and 4.0.5) had O_DIRECT disabled in their db4 code. But someone reported this failure on an rpm 4.2 system, so I am puzzled again ... :( I guess I need to rebuild rpm for RH9/8.0/7.3, maybe go straight to 4.2.1. --=20 Axel.Thimm@physik.fu-berlin.de --cHMo6Wbp1wrKhbfi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/TNiJQBVS1GOamfERAiDrAJ4nvg4xAG9/qq1/nd+z6Xic6+l/4ACdFNmz 3H/tXlK3Q5N9oUBGlRY3N0c= =rztG -----END PGP SIGNATURE----- --cHMo6Wbp1wrKhbfi-- From owner-linux-xfs@oss.sgi.com Wed Aug 27 10:05:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Aug 2003 10:05:47 -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 h7RH4JoO009716 for ; Wed, 27 Aug 2003 10:04:59 -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 h7RHKtxZ026864 for ; Wed, 27 Aug 2003 12:20:55 -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 h7RH4DaK10686884; Wed, 27 Aug 2003 12:04:13 -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 h7RH4DRn247515699; Wed, 27 Aug 2003 12:04:13 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h7RH4Cd26614; Wed, 27 Aug 2003 12:04:12 -0500 Subject: Re: 2.4.22 in cvs? From: Steve Lord To: Net Llama! Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1062003852.22690.1247.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 27 Aug 2003 12:04:12 -0500 X-archive-position: 201 X-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: 479 Lines: 14 On Wed, 2003-08-27 at 08:23, Net Llama! wrote: > Anyone know if the code in cvs will apply cleanly on 2.4.22? thanks! It won't. Right now we have 2.4.22 available via bitkeeper from xfs.org, Russell posted this on the list a while ago. The crypto merge into 2.4.22 means hosting it on an SGI web site takes some approvals. 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 27 11:15:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Aug 2003 11:16:14 -0700 (PDT) Received: from mail.blazebox.homeip.net (postfix@pool-162-84-136-131.ny5030.east.verizon.net [162.84.136.131]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7RIEooO012058 for ; Wed, 27 Aug 2003 11:15:31 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.blazebox.homeip.net (Postfix) with ESMTP id 7552C9F05; Wed, 27 Aug 2003 14:14:49 -0400 (EDT) Received: from mail.blazebox.homeip.net (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.14) id 10977-768EDC71; Wed, 27 Aug 2003 14:14:48 -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 892579EF3; Wed, 27 Aug 2003 14:14:48 -0400 (EDT) Subject: Re: 2.4.22 in cvs? From: Paul Blazejowski To: Net Llama! Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-AsLwYfK2GZ435Rkh9ea8" Message-Id: <1062008140.5313.5.camel@blaze.homeip.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 (Slackware Linux) Date: Wed, 27 Aug 2003 14:15:40 -0400 X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.14; AVE: 6.21.0.1; VDF: 6.21.0.28; host: blazebox.homeip.net) X-archive-position: 202 X-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: 905 Lines: 33 --=-AsLwYfK2GZ435Rkh9ea8 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2003-08-27 at 09:23, Net Llama! wrote: > Anyone know if the code in cvs will apply cleanly on 2.4.22? thanks! It did not for me when i tried IRC (had a problem with do_generic_write in xfs_llrw)... Russell announced a while ago tree on http://xfs.org:8090/linux-2.4+xfs in BK format. If you feel brave :-) you could try XFS only diff of above tree on 2.4.22 from http://www.blazebox.homeip.net:81/diffie/linux/ . Hope this helps. --=-AsLwYfK2GZ435Rkh9ea8 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/TPVMIymMQsXoRDARApPhAJ9G4O2kcba+ITfVp0jaHP6Ri69mLACghl6m 7XohJHj78kYCMZCpAUzCZf4= =MUU8 -----END PGP SIGNATURE----- --=-AsLwYfK2GZ435Rkh9ea8-- From owner-linux-xfs@oss.sgi.com Wed Aug 27 15:43:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Aug 2003 15:44:40 -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 h7RMhGoO022175 for ; Wed, 27 Aug 2003 15:43:57 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Aug 2003 15:43:11 -0700 Received: from 80.128.32.162 by law9-oe39.law9.hotmail.com with DAV; Wed, 27 Aug 2003 22:43:11 +0000 X-Originating-IP: [80.128.32.162] X-Originating-Email: [k_leibrandt@hotmail.com] From: "Kai Leibrandt" To: "'Axel Thimm'" , "'Eric Sandeen'" Cc: "'Simon Matter'" , Subject: RE: Patch 1300 & rpm issue with 1.3.0 Date: Thu, 28 Aug 2003 00:43:06 +0200 Message-ID: <003001c36cec$94ca3f70$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 Importance: Normal In-Reply-To: <20030826161953.GB6163@pua.nirvana> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 27 Aug 2003 22:43:11.0564 (UTC) FILETIME=[980DF8C0:01C36CEC] X-archive-position: 203 X-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: 1184 Lines: 35 > -----Original Message----- > From: Axel Thimm [mailto:Axel.Thimm@physik.fu-berlin.de] > Sent: 26 August 2003 18:20 > To: Eric Sandeen > Cc: Simon Matter; Kai Leibrandt; linux-xfs@oss.sgi.com > Subject: Re: Patch 1300 & rpm issue with 1.3.0 > > > On Tue, Aug 26, 2003 at 10:44:04AM -0500, Eric Sandeen wrote: > > FWIW, the other solution seems to be to get the latest RPMs from > > rpm.org > > (4.2.x) which turn off O_DIRECT in the rpm source. > > So using rpm-4.2, 4.1.1 or 4.0.5 should be fine (see: > http://www.geocrawler.com/lists/3/Red-Hat-Linux/87/0/10430019/) > > > I still don't know what the underlying problem actually is. > > If rpm >= 4.2 does the job, I'd rather put a Requires: line > in the kernel specfile than crippling XFS. After all I have > backported rpm 4.2 for RH8.0 and RH7.3, so it is available > from the same source. I agree totally, although some people may get thworn off by a kernel spec having a Requires: in it. > I'll do some more testing with rpm 4.2. Kai, could you also > try it out? Yes I will but I won't be able to get back to you with results until the weekend... But the referenced message looks very encouraging. K. From owner-linux-xfs@oss.sgi.com Wed Aug 27 16:43:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Aug 2003 16:43:49 -0700 (PDT) Received: from mail.imgame.net ([203.177.81.34]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7RNh2WZ024449 for ; Wed, 27 Aug 2003 16:43:07 -0700 Received: from 127.0.0.1 (mail.imgame.net [127.0.0.1]) by dummy.domain.name (mail) with SMTP id 40A767D60 for ; Thu, 28 Aug 2003 07:41:26 +0800 (PHT) Received: by mail.imgame.net (mail, from userid 48) id CF6937D58; Thu, 28 Aug 2003 07:41:24 +0800 (PHT) Received: from 192.168.0.54 (SquirrelMail authenticated user rvfrancisco) by mail.imgame.net with HTTP; Thu, 28 Aug 2003 07:41:24 +0800 (PHT) Message-ID: <1356.192.168.0.54.1062027684.squirrel@mail.imgame.net> Date: Thu, 28 Aug 2003 07:41:24 +0800 (PHT) Subject: EXPANSION 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: 204 X-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: 720 Lines: 25 GOOD DAY!, I just want to know is there any way to expand a RAID5 partition 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 my raid5 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 expand my partion in Raid5 to expand the capacity? Is there packages needed to repartion my Hardisk? or is their any particular command do i need to run? Thanks.... Regards, Rodel Francisco System Administrator From owner-linux-xfs@oss.sgi.com Wed Aug 27 16:51:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Aug 2003 16:51:36 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7RNoxWZ025440 for ; Wed, 27 Aug 2003 16:50: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 h7RNoqq0019421 for ; Wed, 27 Aug 2003 16:50: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 JAA03536 for ; Thu, 28 Aug 2003 09:49:36 +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 h7RNnZmY068394 for ; Thu, 28 Aug 2003 09:49: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 h7RNlvRh001106 for ; Thu, 28 Aug 2003 09:47:57 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h7RNlvSA001104 for linux-xfs@oss.sgi.com; Thu, 28 Aug 2003 09:47:57 +1000 Date: Thu, 28 Aug 2003 09:47:57 +1000 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Re: 2.4.22 in cvs? (fwd) Message-ID: <20030827234757.GD922@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7RNp0WZ025444 X-archive-position: 205 X-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: 613 Lines: 25 resending, last attempt bounced. ----- Forwarded message from Nathan Scott ----- Date: Thu, 28 Aug 2003 09:19:08 +1000 To: Net Llama! Cc: linux-xfs@oss.sgi.com User-Agent: Mutt/1.5.3i From: Nathan Scott Subject: Re: 2.4.22 in cvs? On Wed, Aug 27, 2003 at 09:23:37AM -0400, Net Llama! wrote: > Anyone know if the code in cvs will apply cleanly on 2.4.22? thanks! > I don't think it will work unchanged - there were some vfs inode locking changes between 2.4.21 and 2.4.22 which affect XFS. cheers. -- Nathan ----- End forwarded message ----- From owner-linux-xfs@oss.sgi.com Wed Aug 27 16:53:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Aug 2003 16:54:25 -0700 (PDT) Received: from hermod.acsalaska.net (hermod.acsalaska.net [209.112.155.45]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7RNroWZ025922 for ; Wed, 27 Aug 2003 16:53:50 -0700 Received: from erbenson.alaska.net (16-pm5.nwc.alaska.net [209.112.139.16]) by hermod.acsalaska.net (8.12.9/8.12.9) with ESMTP id h7RLoHsV081095 for ; Wed, 27 Aug 2003 13:50:18 -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 139E839E4 for ; Wed, 27 Aug 2003 13:50:15 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 47A6F40FF44; Wed, 27 Aug 2003 13:50:16 -0800 (AKDT) Date: Wed, 27 Aug 2003 13:50:16 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: 2.4.22 in cvs? Message-ID: <20030827215016.GA12362@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1062003852.22690.1247.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <1062003852.22690.1247.camel@jen.americas.sgi.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.36 X-archive-position: 206 X-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: 1075 Lines: 35 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 27, 2003 at 12:04:12PM -0500, Steve Lord wrote: > On Wed, 2003-08-27 at 08:23, Net Llama! wrote: > > Anyone know if the code in cvs will apply cleanly on 2.4.22? thanks! >=20 > It won't. Right now we have 2.4.22 available via bitkeeper from xfs.org, > Russell posted this on the list a while ago. The crypto merge into=20 > 2.4.22 means hosting it on an SGI web site takes some approvals. so do the merge leaving out the crpyto dir until you get approval. or is the approval not expected to take more then a day or two? --=20 Ethan Benson http://www.alaska.net/~erbenson/ --Kj7319i9nmIyA2yE 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 iEYEARECAAYFAj9NJ5gACgkQJKx7GixEevzWvACfbLHv6r75NSQCrHH7mbNwkbTa mKEAniYm+xxDJLJH9fq4pQ17BNTDH/T3 =Tryq -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From owner-linux-xfs@oss.sgi.com Wed Aug 27 16:59:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Aug 2003 16:59:52 -0700 (PDT) Received: from lists.vasoftware.com (mail@lists.vasoftware.com [198.186.202.171]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7RNxDWZ026572 for ; Wed, 27 Aug 2003 16:59:14 -0700 Received: from adsl-64-175-248-6.dsl.sntc01.pacbell.net ([64.175.248.6]:61822 helo=linux-sxs.org) by lists.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.20 #1 (Debian)) id 19sABz-00046O-Pe by VAauthid with fixed_plain for ; Wed, 27 Aug 2003 16:59:11 -0700 Message-ID: <3F4D45B7.7020106@linux-sxs.org> Date: Wed, 27 Aug 2003 16:58:47 -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: linux-xfs@oss.sgi.com Subject: Re: 2.4.22 in cvs? References: <1062003852.22690.1247.camel@jen.americas.sgi.com> <20030827215016.GA12362@plato.local.lan> In-Reply-To: <20030827215016.GA12362@plato.local.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: lists.vasoftware.com 19sABz-00046O-Pe 1768f94aab2235869636bc6acfddd8ad X-Spam-Score: -102.6 (---------------------------------------------------) X-archive-position: 207 X-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: 1163 Lines: 29 On 08/27/03 14:50, Ethan Benson wrote: > On Wed, Aug 27, 2003 at 12:04:12PM -0500, Steve Lord wrote: > >>On Wed, 2003-08-27 at 08:23, Net Llama! wrote: >> >>>Anyone know if the code in cvs will apply cleanly on 2.4.22? thanks! >> >>It won't. Right now we have 2.4.22 available via bitkeeper from xfs.org, >>Russell posted this on the list a while ago. The crypto merge into >>2.4.22 means hosting it on an SGI web site takes some approvals. > > > so do the merge leaving out the crpyto dir until you get approval. or > is the approval not expected to take more then a day or two? Yea, i'm kinda wondering that too. I know asking when a kernel patch will be released is frowned upon and all, but I've got quite a few production boxes, and I've been holding off kernel upgrades on them since 2.4.19 was released, so I'd like a rough idea of how long the wait might be. thanks. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 4:55pm up 12 days, 5:22, 1 user, load average: 0.18, 0.18, 0.13 From owner-linux-xfs@oss.sgi.com Wed Aug 27 20:59:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Aug 2003 21:00:10 -0700 (PDT) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7S3xSWZ003998 for ; Wed, 27 Aug 2003 20:59:29 -0700 Received: from [10.0.0.10] (c-24-118-121-167.mn.client2.attbi.com [24.118.121.167]) by lips.thebarn.com (8.12.9/8.12.9) with ESMTP id h7S3wanF005211; Wed, 27 Aug 2003 22:58:36 -0500 (CDT) (envelope-from cattelan@thebarn.com) Subject: Re: 2.4.22 in cvs? From: Russell Cattelan To: Net Llama! Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/mixed; boundary="=-xOCcTQIDnL6ppaQvlLY+" Message-Id: <1062043039.90958.7.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 28 Aug 2003 03:57:20 +0000 X-archive-position: 209 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs Content-Length: 61671 Lines: 1947 --=-xOCcTQIDnL6ppaQvlLY+ Content-Type: text/plain Content-Transfer-Encoding: 7bit Opps forgot to attach the patches --=-xOCcTQIDnL6ppaQvlLY+ Content-Disposition: attachment; filename=core-xfs2.4.22.patch Content-Type: text/plain; name=core-xfs2.4.22.patch; charset=iso-8859-1 Content-Transfer-Encoding: 7bit # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1066 -> 1.1067 # arch/ppc/configs/mbx_defconfig 1.12 -> 1.13 # arch/s390x/defconfig 1.9 -> 1.10 # include/linux/sysctl.h 1.27 -> 1.28 # kernel/ksyms.c 1.78 -> 1.79 # arch/m68k/defconfig 1.1 -> 1.2 # include/linux/mm.h 1.42 -> 1.43 # arch/parisc/defconfig 1.3 -> 1.4 # arch/ppc/configs/oak_defconfig 1.12 -> 1.13 # arch/ia64/defconfig 1.9 -> 1.10 # fs/xattr.c 1.1 -> 1.2 # include/linux/sched.h 1.38 -> 1.39 # kernel/sysctl.c 1.23 -> 1.24 # drivers/block/ll_rw_blk.c 1.48 -> 1.49 # arch/ppc/configs/IVMS8_defconfig 1.12 -> 1.13 # arch/i386/defconfig 1.51 -> 1.52 # include/asm-sh/ioctl.h 1.2 -> 1.3 # arch/mips/defconfig 1.7 -> 1.8 # drivers/md/raid5.c 1.15 -> 1.16 # arch/ppc/configs/TQM823L_defconfig 1.11 -> 1.12 # arch/ppc/configs/rpxlite_defconfig 1.13 -> 1.14 # arch/mips64/defconfig 1.9 -> 1.10 # arch/ppc/configs/bseip_defconfig 1.12 -> 1.13 # arch/ppc/configs/spruce_defconfig 1.5 -> 1.6 # arch/ppc/configs/power3_defconfig 1.12 -> 1.13 # include/linux/fs.h 1.85 -> 1.86 # arch/ppc/configs/pmac_defconfig 1.6 -> 1.7 # arch/arm/defconfig 1.2 -> 1.3 # arch/cris/defconfig 1.8 -> 1.9 # arch/ppc/configs/common_defconfig 1.14 -> 1.15 # arch/ppc/configs/TQM860L_defconfig 1.12 -> 1.13 # fs/intermezzo/vfs.c 1.8 -> 1.9 # arch/sparc64/defconfig 1.52 -> 1.53 # mm/filemap.c 1.86 -> 1.87 # fs/namei.c 1.27 -> 1.28 # arch/ppc/configs/SM850_defconfig 1.11 -> 1.12 # mm/mprotect.c 1.4 -> 1.5 # arch/ppc/configs/gemini_defconfig 1.12 -> 1.13 # arch/sparc64/kernel/systbls.S 1.6 -> 1.7 # arch/ppc/configs/ibmchrp_defconfig 1.12 -> 1.13 # arch/ppc/configs/pal4_defconfig 1.5 -> 1.6 # arch/alpha/defconfig 1.6 -> 1.7 # arch/ppc/configs/est8260_defconfig 1.13 -> 1.14 # arch/sh/defconfig 1.2 -> 1.3 # arch/ppc/configs/TQM850L_defconfig 1.11 -> 1.12 # fs/buffer.c 1.91 -> 1.92 # fs/Makefile 1.19 -> 1.20 # MAINTAINERS 1.103 -> 1.103.1.1 # arch/ppc/configs/briq_defconfig 1.3 -> 1.4 # fs/Config.in 1.26 -> 1.27 # arch/sparc/defconfig 1.11 -> 1.12 # arch/ppc/configs/apus_defconfig 1.14 -> 1.15 # arch/ppc/configs/rpxcllf_defconfig 1.13 -> 1.14 # arch/ppc/defconfig 1.14 -> 1.15 # arch/ppc/configs/walnut_defconfig 1.13 -> 1.14 # arch/s390/defconfig 1.9 -> 1.10 # Documentation/Changes 1.17 -> 1.18 # Documentation/Configure.help 1.176 -> 1.177 # arch/ppc/configs/SPD823TS_defconfig 1.11 -> 1.12 # fs/inode.c 1.38 -> 1.39 # Documentation/filesystems/00-INDEX 1.5 -> 1.6 # (new) -> 1.1 include/linux/posix_cap_xattr.h # (new) -> 1.1 Documentation/filesystems/xfs.txt # (new) -> 1.1 include/linux/posix_acl_xattr.h # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/08/07 cattelan@naboo.eagan 1.1067 # xfs.patch # -------------------------------------------- # diff -Nru a/Documentation/Changes b/Documentation/Changes --- a/Documentation/Changes Wed Aug 27 22:47:38 2003 +++ b/Documentation/Changes Wed Aug 27 22:47:38 2003 @@ -56,6 +56,7 @@ o e2fsprogs 1.25 # tune2fs o jfsutils 1.0.12 # fsck.jfs -V o reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep reiserfsprogs +o xfsprogs 2.1.0 # xfs_db -V o pcmcia-cs 3.1.21 # cardmgr -V o PPP 2.4.0 # pppd --version o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version @@ -190,6 +191,17 @@ versions of mkreiserfs, resize_reiserfs, debugreiserfs and reiserfsck. These utils work on both i386 and alpha platforms. +Xfsprogs +-------- + +The latest version of xfsprogs contains mkfs.xfs, xfs_db, and the +xfs_repair utilities, among others, for the XFS filesystem. It is +architecture independent and any version from 2.0.0 onward should +work correctly with this version of the XFS kernel code. For the new +(v2) log format that has better support for stripe-size aligning on +LVM and MD devices at least xfsprogs 2.1.0 is needed. + + Pcmcia-cs --------- @@ -326,6 +338,10 @@ Reiserfsprogs ------------- o + +Xfsprogs +-------- +o LVM toolset ----------- diff -Nru a/Documentation/Configure.help b/Documentation/Configure.help --- a/Documentation/Configure.help Wed Aug 27 22:47:38 2003 +++ b/Documentation/Configure.help Wed Aug 27 22:47:38 2003 @@ -16387,6 +16387,102 @@ Say Y here if you want to try writing to UFS partitions. This is experimental, so you should back up your UFS partitions beforehand. +XFS filesystem support +CONFIG_XFS_FS + XFS is a high performance journaling filesystem which originated + on the SGI IRIX platform. It is completely multi-threaded, can + support large files and large filesystems, extended attributes, + variable block sizes, is extent based, and makes extensive use of + Btrees (directories, extents, free space) to aid both performance + and scalability. + + Refer to the documentation at + for complete details. This implementation is on-disk compatible + with the IRIX version of XFS. + + If you want to compile this file system as a module ( = code which + can be inserted in and removed from the running kernel whenever you + want), say M here and read . The + module will be called xfs.o. Be aware, however, that if the file + system of your root partition is compiled as a module, you'll need + to use an initial ramdisk (initrd) to boot. + +DMAPI support +CONFIG_XFS_DMAPI + The Data Management API is a system interface used to implement + the interface defined in the X/Open document: + "Systems Management: Data Storage Management (XDSM) API", + dated February 1997. This interface is used by hierarchical + storage management systems. + + If XFS is built as module (= code which can be inserted in and + removed from the running kernel whenever you want), this code will + also be built as module. It is called xfs_dmapi.o. + + If unsure, say N. + +Quota support +CONFIG_XFS_QUOTA + If you say Y here, you will be able to set limits for disk usage on + a per user and/or per group basis under XFS. XFS considers quota + information as filesystem metadata and uses journaling to provide a + higher level guarantee of consistency. The on-disk data format for + quota is also compatible with the IRIX version of XFS, allowing a + filesystem to be migrated between Linux and IRIX without any need + for conversion. + + If unsure, say N. More comprehensive documentation can be found in + README.quota in the xfsprogs package. XFS quota can be used either + with or without the generic quota support enabled (CONFIG_QUOTA) - + they are completely independent subsystems. + +Realtime support (EXPERIMENTAL) +CONFIG_XFS_RT + If you say Y here you will be able to mount and use XFS filesystems + which contain a realtime subvolume. The realtime subvolume is a + separate area of disk space where only file data is stored. The + realtime subvolume is designed to provide very deterministic + data rates suitable for media streaming applications. + + See the xfs man page in section 5 for a bit more information. + + This feature is unsupported at this time, is not yet fully + functional, and may cause serious problems. + + If unsure, say N. + +ACL support +CONFIG_XFS_POSIX_ACL + Posix Access Control Lists (ACLs) support permissions for users and + groups beyond the owner/group/world scheme. + + To learn more about Access Control Lists, visit the Posix ACLs for + Linux website . + + If you don't know what Access Control Lists are, say N + +Debugging support (EXPERIMENTAL) +CONFIG_XFS_DEBUG + Say Y here to get an XFS build with many debugging features, + including ASSERT checks, function wrappers around macros, + and extra sanity-checking functions in various code paths. + + Note that the resulting code will be HUGE and SLOW, and probably + not useful unless you are debugging a particular problem. + + Say N unless you are an XFS developer, or play one on TV. + +Pagebuf debugging support (EXPERIMENTAL) +CONFIG_PAGEBUF_DEBUG + Say Y here to get an XFS build which may help you debug pagebuf + problems. Enabling this option will attach tracing information + to pagebufs, which can be read with the kdb kernel debugger. + + Note that you will also have to enable the sysctl in + /proc/sys/vm/pagebuf/debug for this to work. + + Say N unless you're interested in debugging pagebuf. + Advanced partition selection CONFIG_PARTITION_ADVANCED Say Y here if you would like to use hard disks under Linux which diff -Nru a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX --- a/Documentation/filesystems/00-INDEX Wed Aug 27 22:47:38 2003 +++ b/Documentation/filesystems/00-INDEX Wed Aug 27 22:47:38 2003 @@ -48,3 +48,5 @@ - info on using the VFAT filesystem used in Windows NT and Windows 95 vfs.txt - Overview of the Virtual File System +xfs.txt + - info and mount options for the XFS filesystem. diff -Nru a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/Documentation/filesystems/xfs.txt Wed Aug 27 22:47:38 2003 @@ -0,0 +1,191 @@ + +The SGI XFS Filesystem +====================== + +XFS is a high performance journaling filesystem which originated +on the SGI IRIX platform. It is completely multi-threaded, can +support large files and large filesystems, extended attributes, +variable block sizes, is extent based, and makes extensive use of +Btrees (directories, extents, free space) to aid both performance +and scalability. + +Refer to the documentation at http://oss.sgi.com/projects/xfs/ +for further details. This implementation is on-disk compatible +with the IRIX version of XFS. + + +Mount Options +============= + +When mounting an XFS filesystem, the following options are accepted. + + biosize=size + Sets the preferred buffered I/O size (default size is 64K). + "size" must be expressed as the logarithm (base2) of the + desired I/O size. + Valid values for this option are 14 through 16, inclusive + (i.e. 16K, 32K, and 64K bytes). On machines with a 4K + pagesize, 13 (8K bytes) is also a valid size. + The preferred buffered I/O size can also be altered on an + individual file basis using the ioctl(2) system call. + + dmapi + Enable the DMAPI (Data Management API) event callouts. + Use with the "mtpt" option. + + logbufs=value + Set the number of in-memory log buffers. Valid numbers range + from 2-8 inclusive. + The default value is 8 buffers for filesystems with a + blocksize of 64K, 4 buffers for filesystems with a blocksize + of 32K, 3 buffers for filesystems with a blocksize of 16K + and 2 buffers for all other configurations. Increasing the + number of buffers may increase performance on some workloads + at the cost of the memory used for the additional log buffers + and their associated control structures. + + logbsize=value + Set the size of each in-memory log buffer. + Size may be specified in bytes, or in kilobytes with a "k" suffix. + Valid sizes for version 1 and version 2 logs are 16384 (16k) and + 32768 (32k). Valid sizes for version 2 logs also include + 65536 (64k), 131072 (128k) and 262144 (256k). + The default value for machines with more than 32MB of memory + is 32768, machines with less memory use 16384 by default. + + logdev=device and rtdev=device + Use an external log (metadata journal) and/or real-time device. + An XFS filesystem has up to three parts: a data section, a log + section, and a real-time section. The real-time section is + optional, and the log section can be separate from the data + section or contained within it. + + mtpt=mountpoint + Use with the "dmapi" option. The value specified here will be + included in the DMAPI mount event, and should be the path of + the actual mountpoint that is used. + + noalign + Data allocations will not be aligned at stripe unit boundaries. + + noatime + Access timestamps are not updated when a file is read. + + norecovery + The filesystem will be mounted without running log recovery. + If the filesystem was not cleanly unmounted, it is likely to + be inconsistent when mounted in "norecovery" mode. + Some files or directories may not be accessible because of this. + Filesystems mounted "norecovery" must be mounted read-only or + the mount will fail. + + osyncisosync + Make O_SYNC writes implement true O_SYNC. WITHOUT this option, + Linux XFS behaves as if an "osyncisdsync" option is used, + which will make writes to files opened with the O_SYNC flag set + behave as if the O_DSYNC flag had been used instead. + This can result in better performance without compromising + data safety. + However if this option is not in effect, timestamp updates from + O_SYNC writes can be lost if the system crashes. + If timestamp updates are critical, use the osyncisosync option. + + quota/usrquota/uqnoenforce + User disk quota accounting enabled, and limits (optionally) + enforced. + + grpquota/gqnoenforce + Group disk quota accounting enabled and limits (optionally) + enforced. + + sunit=value and swidth=value + Used to specify the stripe unit and width for a RAID device or + a stripe volume. "value" must be specified in 512-byte block + units. + If this option is not specified and the filesystem was made on + a stripe volume or the stripe width or unit were specified for + the RAID device at mkfs time, then the mount system call will + restore the value from the superblock. For filesystems that + are made directly on RAID devices, these options can be used + to override the information in the superblock if the underlying + disk layout changes after the filesystem has been created. + The "swidth" option is required if the "sunit" option has been + specified, and must be a multiple of the "sunit" value. + + nouuid + Don't check for double mounted file systems using the file system uuid. + This is useful to mount LVM snapshot volumes. + +sysctls +======= + +The following sysctls are available for the XFS filesystem: + + fs.xfs.stats_clear (Min: 0 Default: 0 Max: 1) + Setting this to "1" clears accumulated XFS statistics + in /proc/fs/xfs/stat. It then immediately reset to "0". + + fs.xfs.sync_interval (Min: HZ Default: 30*HZ Max: 60*HZ) + The interval at which the xfssyncd thread for xfs filesystems + flushes metadata out to disk. This thread will flush log + activity out, and do some processing on unlinked inodes + + fs.xfs.error_level (Min: 0 Default: 3 Max: 11) + A volume knob for error reporting when internal errors occur. + This will generate detailed messages & backtraces for filesystem + shutdowns, for example. Current threshold values are: + + XFS_ERRLEVEL_OFF: 0 + XFS_ERRLEVEL_LOW: 1 + XFS_ERRLEVEL_HIGH: 5 + + fs.xfs.panic_mask (Min: 0 Default: 0 Max: 127) + Causes certain error conditions to call BUG(). Value is a bitmask; + AND together the tags which represent errors which should cause panics: + + XFS_NO_PTAG 0LL + XFS_PTAG_IFLUSH 0x0000000000000001LL + XFS_PTAG_LOGRES 0x0000000000000002LL + XFS_PTAG_AILDELETE 0x0000000000000004LL + XFS_PTAG_ERROR_REPORT 0x0000000000000008LL + XFS_PTAG_SHUTDOWN_CORRUPT 0x0000000000000010LL + XFS_PTAG_SHUTDOWN_IOERROR 0x0000000000000020LL + XFS_PTAG_SHUTDOWN_LOGERROR 0x0000000000000040LL + + This option is intended for debugging only. + + fs.xfs.irix_symlink_mode (Min: 0 Default: 0 Max: 1) + Controls whether symlinks are created with mode 0777 (default) + or whether their mode is affected by the umask (irix mode). + + fs.xfs.irix_sgid_inherit (Min: 0 Default: 0 Max: 1) + Controls files created in SGID directories. + If the group ID of the new file does not match the effective group + ID or one of the supplementary group IDs of the parent dir, the + ISGID bit is cleared if the irix_sgid_inherit compatibility sysctl + is set. + + fs.xfs.restrict_chown (Min: 0 Default: 1 Max: 1) + Controls whether unprivileged users can use chown to "give away" + a file to another user. + + fs.xfs.refcache_size (Min: 0 Default: 128 Max: 512) + Controls the size of the NFS refcache, which holds references + on files opened via NFS to improve performance. The value + is the maximum number of files which can be in the cache at + any one time. + + fs.xfs.refcache_purge (Min: 0 Default: 32 Max: 512) + Controls the number of entries purged from the NFS refcache + every sync interval. + + vm.pagebuf.stats_clear (Min: 0 Default: 0 Max: 1) + Setting this to "1" clears accumulated pagebuf statistics + in /proc/fs/pagebuf/stat. It then immediately reset to "0". + + vm.pagebuf.flush_age (Min: 1*HZ Default: 15*HZ Max: 300*HZ) + The age at which dirty metadata buffers are flushed to disk + + vm.pagebuf.flush_int (Min: HZ/2 Default: HZ Max: 30*HZ) + The interval at which the list of dirty metadata buffers is + scanned. diff -Nru a/MAINTAINERS b/MAINTAINERS --- a/MAINTAINERS Wed Aug 27 22:47:37 2003 +++ b/MAINTAINERS Wed Aug 27 22:47:37 2003 @@ -2116,6 +2116,14 @@ L: linux-x25@vger.kernel.org S: Maintained +XFS FILESYSTEM +P: Silicon Graphics Inc +M: owner-xfs@oss.sgi.com +M: lord@sgi.com +L: linux-xfs@oss.sgi.com +W: http://oss.sgi.com/projects/xfs +S: Supported + X86 3-LEVEL PAGING (PAE) SUPPORT P: Ingo Molnar M: mingo@redhat.com diff -Nru a/arch/alpha/defconfig b/arch/alpha/defconfig --- a/arch/alpha/defconfig Wed Aug 27 22:47:37 2003 +++ b/arch/alpha/defconfig Wed Aug 27 22:47:37 2003 @@ -796,3 +796,12 @@ CONFIG_MATHEMU=y # CONFIG_DEBUG_SLAB is not set CONFIG_MAGIC_SYSRQ=y + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set diff -Nru a/arch/arm/defconfig b/arch/arm/defconfig --- a/arch/arm/defconfig Wed Aug 27 22:47:36 2003 +++ b/arch/arm/defconfig Wed Aug 27 22:47:36 2003 @@ -509,3 +509,12 @@ # CONFIG_DEBUG_INFO is not set CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_LL=y + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set diff -Nru a/arch/cris/defconfig b/arch/cris/defconfig --- a/arch/cris/defconfig Wed Aug 27 22:47:36 2003 +++ b/arch/cris/defconfig Wed Aug 27 22:47:36 2003 @@ -518,3 +518,12 @@ # Kernel hacking # # CONFIG_PROFILE is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set diff -Nru a/arch/i386/defconfig b/arch/i386/defconfig --- a/arch/i386/defconfig Wed Aug 27 22:47:36 2003 +++ b/arch/i386/defconfig Wed Aug 27 22:47:36 2003 @@ -879,3 +879,16 @@ # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set + +CONFIG_KDB=y +CONFIG_KDB_OFF=n +CONFIG_FRAME_POINTER=n + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set diff -Nru a/arch/ia64/defconfig b/arch/ia64/defconfig --- a/arch/ia64/defconfig Wed Aug 27 22:47:35 2003 +++ b/arch/ia64/defconfig Wed Aug 27 22:47:35 2003 @@ -978,3 +978,16 @@ # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_IA64_DEBUG_CMPXCHG is not set # CONFIG_IA64_DEBUG_IRQ is not set + +CONFIG_KDB=y +CONFIG_KDB_OFF=n +CONFIG_FRAME_POINTER=n + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set diff -Nru a/arch/m68k/defconfig b/arch/m68k/defconfig --- a/arch/m68k/defconfig Wed Aug 27 22:47:35 2003 +++ b/arch/m68k/defconfig Wed Aug 27 22:47:35 2003 @@ -327,3 +327,13 @@ # Kernel hacking # # CONFIG_MAGIC_SYSRQ is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/mips/defconfig b/arch/mips/defconfig --- a/arch/mips/defconfig Wed Aug 27 22:47:36 2003 +++ b/arch/mips/defconfig Wed Aug 27 22:47:36 2003 @@ -642,3 +642,13 @@ # # CONFIG_ZLIB_INFLATE is not set # CONFIG_ZLIB_DEFLATE is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/mips64/defconfig b/arch/mips64/defconfig --- a/arch/mips64/defconfig Wed Aug 27 22:47:36 2003 +++ b/arch/mips64/defconfig Wed Aug 27 22:47:36 2003 @@ -588,3 +588,13 @@ # # CONFIG_ZLIB_INFLATE is not set # CONFIG_ZLIB_DEFLATE is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/parisc/defconfig b/arch/parisc/defconfig --- a/arch/parisc/defconfig Wed Aug 27 22:47:35 2003 +++ b/arch/parisc/defconfig Wed Aug 27 22:47:35 2003 @@ -787,3 +787,13 @@ # Kernel hacking # CONFIG_MAGIC_SYSRQ=y + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/IVMS8_defconfig b/arch/ppc/configs/IVMS8_defconfig --- a/arch/ppc/configs/IVMS8_defconfig Wed Aug 27 22:47:35 2003 +++ b/arch/ppc/configs/IVMS8_defconfig Wed Aug 27 22:47:35 2003 @@ -542,3 +542,13 @@ # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/SM850_defconfig b/arch/ppc/configs/SM850_defconfig --- a/arch/ppc/configs/SM850_defconfig Wed Aug 27 22:47:37 2003 +++ b/arch/ppc/configs/SM850_defconfig Wed Aug 27 22:47:37 2003 @@ -510,3 +510,13 @@ # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/SPD823TS_defconfig b/arch/ppc/configs/SPD823TS_defconfig --- a/arch/ppc/configs/SPD823TS_defconfig Wed Aug 27 22:47:38 2003 +++ b/arch/ppc/configs/SPD823TS_defconfig Wed Aug 27 22:47:38 2003 @@ -509,3 +509,13 @@ # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/TQM823L_defconfig b/arch/ppc/configs/TQM823L_defconfig --- a/arch/ppc/configs/TQM823L_defconfig Wed Aug 27 22:47:36 2003 +++ b/arch/ppc/configs/TQM823L_defconfig Wed Aug 27 22:47:36 2003 @@ -510,3 +510,13 @@ # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/TQM850L_defconfig b/arch/ppc/configs/TQM850L_defconfig --- a/arch/ppc/configs/TQM850L_defconfig Wed Aug 27 22:47:37 2003 +++ b/arch/ppc/configs/TQM850L_defconfig Wed Aug 27 22:47:37 2003 @@ -510,3 +510,13 @@ # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/TQM860L_defconfig b/arch/ppc/configs/TQM860L_defconfig --- a/arch/ppc/configs/TQM860L_defconfig Wed Aug 27 22:47:36 2003 +++ b/arch/ppc/configs/TQM860L_defconfig Wed Aug 27 22:47:36 2003 @@ -551,3 +551,13 @@ # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/apus_defconfig b/arch/ppc/configs/apus_defconfig --- a/arch/ppc/configs/apus_defconfig Wed Aug 27 22:47:37 2003 +++ b/arch/ppc/configs/apus_defconfig Wed Aug 27 22:47:37 2003 @@ -913,3 +913,13 @@ # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/briq_defconfig b/arch/ppc/configs/briq_defconfig --- a/arch/ppc/configs/briq_defconfig Wed Aug 27 22:47:37 2003 +++ b/arch/ppc/configs/briq_defconfig Wed Aug 27 22:47:37 2003 @@ -806,3 +806,13 @@ # CONFIG_BDI_SWITCH is not set # CONFIG_MORE_COMPILE_OPTIONS is not set CONFIG_BOOTX_TEXT=y + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/bseip_defconfig b/arch/ppc/configs/bseip_defconfig --- a/arch/ppc/configs/bseip_defconfig Wed Aug 27 22:47:36 2003 +++ b/arch/ppc/configs/bseip_defconfig Wed Aug 27 22:47:36 2003 @@ -509,3 +509,13 @@ # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/common_defconfig b/arch/ppc/configs/common_defconfig --- a/arch/ppc/configs/common_defconfig Wed Aug 27 22:47:36 2003 +++ b/arch/ppc/configs/common_defconfig Wed Aug 27 22:47:36 2003 @@ -1065,3 +1065,13 @@ # CONFIG_BDI_SWITCH is not set # CONFIG_MORE_COMPILE_OPTIONS is not set CONFIG_BOOTX_TEXT=y + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/est8260_defconfig b/arch/ppc/configs/est8260_defconfig --- a/arch/ppc/configs/est8260_defconfig Wed Aug 27 22:47:37 2003 +++ b/arch/ppc/configs/est8260_defconfig Wed Aug 27 22:47:37 2003 @@ -480,3 +480,13 @@ # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/gemini_defconfig b/arch/ppc/configs/gemini_defconfig --- a/arch/ppc/configs/gemini_defconfig Wed Aug 27 22:47:37 2003 +++ b/arch/ppc/configs/gemini_defconfig Wed Aug 27 22:47:37 2003 @@ -585,3 +585,13 @@ CONFIG_XMON=y # CONFIG_BDI_SWITCH is not set # CONFIG_MORE_COMPILE_OPTIONS is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/ibmchrp_defconfig b/arch/ppc/configs/ibmchrp_defconfig --- a/arch/ppc/configs/ibmchrp_defconfig Wed Aug 27 22:47:37 2003 +++ b/arch/ppc/configs/ibmchrp_defconfig Wed Aug 27 22:47:37 2003 @@ -795,3 +795,13 @@ # CONFIG_BDI_SWITCH is not set # CONFIG_MORE_COMPILE_OPTIONS is not set # CONFIG_BOOTX_TEXT is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/mbx_defconfig b/arch/ppc/configs/mbx_defconfig --- a/arch/ppc/configs/mbx_defconfig Wed Aug 27 22:47:35 2003 +++ b/arch/ppc/configs/mbx_defconfig Wed Aug 27 22:47:35 2003 @@ -505,3 +505,13 @@ # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/oak_defconfig b/arch/ppc/configs/oak_defconfig --- a/arch/ppc/configs/oak_defconfig Wed Aug 27 22:47:35 2003 +++ b/arch/ppc/configs/oak_defconfig Wed Aug 27 22:47:35 2003 @@ -462,3 +462,13 @@ # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/pal4_defconfig b/arch/ppc/configs/pal4_defconfig --- a/arch/ppc/configs/pal4_defconfig Wed Aug 27 22:47:37 2003 +++ b/arch/ppc/configs/pal4_defconfig Wed Aug 27 22:47:37 2003 @@ -581,3 +581,13 @@ # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/pmac_defconfig b/arch/ppc/configs/pmac_defconfig --- a/arch/ppc/configs/pmac_defconfig Wed Aug 27 22:47:36 2003 +++ b/arch/ppc/configs/pmac_defconfig Wed Aug 27 22:47:36 2003 @@ -1175,3 +1175,13 @@ # CONFIG_BDI_SWITCH is not set # CONFIG_MORE_COMPILE_OPTIONS is not set CONFIG_BOOTX_TEXT=y + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/power3_defconfig b/arch/ppc/configs/power3_defconfig --- a/arch/ppc/configs/power3_defconfig Wed Aug 27 22:47:36 2003 +++ b/arch/ppc/configs/power3_defconfig Wed Aug 27 22:47:36 2003 @@ -807,3 +807,13 @@ # CONFIG_BDI_SWITCH is not set # CONFIG_MORE_COMPILE_OPTIONS is not set # CONFIG_BOOTX_TEXT is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/rpxcllf_defconfig b/arch/ppc/configs/rpxcllf_defconfig --- a/arch/ppc/configs/rpxcllf_defconfig Wed Aug 27 22:47:37 2003 +++ b/arch/ppc/configs/rpxcllf_defconfig Wed Aug 27 22:47:37 2003 @@ -545,3 +545,13 @@ # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/rpxlite_defconfig b/arch/ppc/configs/rpxlite_defconfig --- a/arch/ppc/configs/rpxlite_defconfig Wed Aug 27 22:47:36 2003 +++ b/arch/ppc/configs/rpxlite_defconfig Wed Aug 27 22:47:36 2003 @@ -542,3 +542,13 @@ # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/spruce_defconfig b/arch/ppc/configs/spruce_defconfig --- a/arch/ppc/configs/spruce_defconfig Wed Aug 27 22:47:36 2003 +++ b/arch/ppc/configs/spruce_defconfig Wed Aug 27 22:47:36 2003 @@ -517,3 +517,13 @@ # # CONFIG_DEBUG_KERNEL is not set # CONFIG_SERIAL_TEXT_DEBUG is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/ppc/configs/walnut_defconfig b/arch/ppc/configs/walnut_defconfig --- a/arch/ppc/configs/walnut_defconfig Wed Aug 27 22:47:37 2003 +++ b/arch/ppc/configs/walnut_defconfig Wed Aug 27 22:47:37 2003 @@ -486,3 +486,11 @@ # # CONFIG_DEBUG_KERNEL is not set # CONFIG_SERIAL_TEXT_DEBUG is not set +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set diff -Nru a/arch/ppc/defconfig b/arch/ppc/defconfig --- a/arch/ppc/defconfig Wed Aug 27 22:47:37 2003 +++ b/arch/ppc/defconfig Wed Aug 27 22:47:37 2003 @@ -1065,3 +1065,13 @@ # CONFIG_BDI_SWITCH is not set # CONFIG_MORE_COMPILE_OPTIONS is not set CONFIG_BOOTX_TEXT=y + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/s390/defconfig b/arch/s390/defconfig --- a/arch/s390/defconfig Wed Aug 27 22:47:37 2003 +++ b/arch/s390/defconfig Wed Aug 27 22:47:38 2003 @@ -419,3 +419,11 @@ # # CONFIG_ZLIB_INFLATE is not set # CONFIG_ZLIB_DEFLATE is not set +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set diff -Nru a/arch/s390x/defconfig b/arch/s390x/defconfig --- a/arch/s390x/defconfig Wed Aug 27 22:47:35 2003 +++ b/arch/s390x/defconfig Wed Aug 27 22:47:35 2003 @@ -363,3 +363,11 @@ # # CONFIG_ZLIB_INFLATE is not set # CONFIG_ZLIB_DEFLATE is not set +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set diff -Nru a/arch/sh/defconfig b/arch/sh/defconfig --- a/arch/sh/defconfig Wed Aug 27 22:47:37 2003 +++ b/arch/sh/defconfig Wed Aug 27 22:47:37 2003 @@ -202,3 +202,13 @@ # CONFIG_MAGIC_SYSRQ is not set CONFIG_SH_STANDARD_BIOS=y CONFIG_SH_EARLY_PRINTK=y + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/sparc/defconfig b/arch/sparc/defconfig --- a/arch/sparc/defconfig Wed Aug 27 22:47:37 2003 +++ b/arch/sparc/defconfig Wed Aug 27 22:47:37 2003 @@ -416,3 +416,13 @@ # Kernel hacking # # CONFIG_MAGIC_SYSRQ is not set + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set + diff -Nru a/arch/sparc64/defconfig b/arch/sparc64/defconfig --- a/arch/sparc64/defconfig Wed Aug 27 22:47:36 2003 +++ b/arch/sparc64/defconfig Wed Aug 27 22:47:37 2003 @@ -1055,3 +1055,12 @@ CONFIG_CRC32=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y + +# +# XFS addons +# +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_FS=y +CONFIG_XFS_QUOTA=y +# CONFIG_XFS_RT is not set +# CONFIG_XFS_DMAPI is not set diff -Nru a/arch/sparc64/kernel/systbls.S b/arch/sparc64/kernel/systbls.S --- a/arch/sparc64/kernel/systbls.S Wed Aug 27 22:47:37 2003 +++ b/arch/sparc64/kernel/systbls.S Wed Aug 27 22:47:37 2003 @@ -194,7 +194,7 @@ .word sunos_getdirentries, sys32_statfs, sys32_fstatfs .word sys_oldumount, sunos_nosys, sunos_nosys .word sys_getdomainname, sys_setdomainname - .word sunos_nosys, sys32_quotactl, sunos_nosys + .word sunos_nosys, sys_quotactl, sunos_nosys .word sunos_mount, sys_ustat, sunos_semsys .word sunos_nosys, sunos_shmsys, sunos_audit .word sunos_nosys, sunos_getdents, sys_setsid diff -Nru a/drivers/block/ll_rw_blk.c b/drivers/block/ll_rw_blk.c --- a/drivers/block/ll_rw_blk.c Wed Aug 27 22:47:35 2003 +++ b/drivers/block/ll_rw_blk.c Wed Aug 27 22:47:35 2003 @@ -1275,6 +1275,9 @@ if (!test_bit(BH_Lock, &bh->b_state)) BUG(); + if (buffer_delay(bh) || !buffer_mapped(bh)) + BUG(); + set_bit(BH_Req, &bh->b_state); set_bit(BH_Launder, &bh->b_state); diff -Nru a/drivers/md/raid5.c b/drivers/md/raid5.c --- a/drivers/md/raid5.c Wed Aug 27 22:47:36 2003 +++ b/drivers/md/raid5.c Wed Aug 27 22:47:36 2003 @@ -282,7 +282,7 @@ } if (conf->buffer_size != size) { - printk("raid5: switching cache buffer size, %d --> %d\n", oldsize, size); + PRINTK("raid5: switching cache buffer size, %d --> %d\n", oldsize, size); shrink_stripe_cache(conf); if (size==0) BUG(); conf->buffer_size = size; diff -Nru a/fs/Config.in b/fs/Config.in --- a/fs/Config.in Wed Aug 27 22:47:37 2003 +++ b/fs/Config.in Wed Aug 27 22:47:37 2003 @@ -97,6 +97,14 @@ tristate 'UFS file system support (read only)' CONFIG_UFS_FS dep_mbool ' UFS file system write support (DANGEROUS)' CONFIG_UFS_FS_WRITE $CONFIG_UFS_FS $CONFIG_EXPERIMENTAL +tristate 'XFS filesystem support' CONFIG_XFS_FS +dep_mbool ' ACL support' CONFIG_XFS_POSIX_ACL $CONFIG_XFS_FS +dep_mbool ' Realtime support (EXPERIMENTAL)' CONFIG_XFS_RT $CONFIG_XFS_FS $CONFIG_EXPERIMENTAL +dep_mbool ' Quota support' CONFIG_XFS_QUOTA $CONFIG_XFS_FS +dep_mbool ' DMAPI support' CONFIG_XFS_DMAPI $CONFIG_XFS_FS +dep_mbool ' Debugging support (EXPERIMENTAL)' CONFIG_XFS_DEBUG $CONFIG_XFS_FS $CONFIG_EXPERIMENTAL +dep_mbool ' Pagebuf debugging support (EXPERIMENTAL)' CONFIG_PAGEBUF_DEBUG $CONFIG_XFS_FS $CONFIG_EXPERIMENTAL + if [ "$CONFIG_NET" = "y" ]; then mainmenu_option next_comment diff -Nru a/fs/Makefile b/fs/Makefile --- a/fs/Makefile Wed Aug 27 22:47:37 2003 +++ b/fs/Makefile Wed Aug 27 22:47:37 2003 @@ -8,7 +8,7 @@ O_TARGET := fs.o export-objs := filesystems.o open.o dcache.o buffer.o dquot.o -mod-subdirs := nls +mod-subdirs := nls xfs obj-y := open.o read_write.o devices.o file_table.o buffer.o \ super.o block_dev.o char_dev.o stat.o exec.o pipe.o namei.o \ @@ -66,7 +66,7 @@ subdir-$(CONFIG_SUN_OPENPROMFS) += openpromfs subdir-$(CONFIG_BEFS_FS) += befs subdir-$(CONFIG_JFS_FS) += jfs - +subdir-$(CONFIG_XFS_FS) += xfs obj-$(CONFIG_BINFMT_AOUT) += binfmt_aout.o obj-$(CONFIG_BINFMT_EM86) += binfmt_em86.o diff -Nru a/fs/buffer.c b/fs/buffer.c --- a/fs/buffer.c Wed Aug 27 22:47:37 2003 +++ b/fs/buffer.c Wed Aug 27 22:47:37 2003 @@ -123,6 +123,36 @@ int bdflush_min[N_PARAM] = { 0, 1, 0, 0, 0, 1*HZ, 0, 0, 0}; int bdflush_max[N_PARAM] = {100,50000, 20000, 20000,10000*HZ, 10000*HZ, 100, 100, 0}; +static inline int write_buffer_delay(struct buffer_head *bh) +{ + struct page *page = bh->b_page; + + if (!TryLockPage(page)) { + spin_unlock(&lru_list_lock); + unlock_buffer(bh); + page->mapping->a_ops->writepage(page); + return 1; + } + + return 0; +} + +static inline void write_buffer(struct buffer_head *bh) +{ + if (buffer_delay(bh)) { + struct page *page = bh->b_page; + + lock_page(page); + if (buffer_delay(bh)) { + page->mapping->a_ops->writepage(page); + return; + } + unlock_page(page); + } + + ll_rw_block(WRITE, 1, &bh); +} + void unlock_buffer(struct buffer_head *bh) { clear_bit(BH_Wait_IO, &bh->b_state); @@ -226,7 +256,13 @@ continue; if (test_and_set_bit(BH_Lock, &bh->b_state)) continue; - if (atomic_set_buffer_clean(bh)) { + if (buffer_delay(bh)) { + if (write_buffer_delay(bh)) { + if (count) + write_locked_buffers(array, count); + return -EAGAIN; + } + } else if (atomic_set_buffer_clean(bh)) { __refile_buffer(bh); get_bh(bh); array[count++] = bh; @@ -612,7 +648,7 @@ if (buffer_attached(bh)) list_del(&bh->b_inode_buffers); set_buffer_attached(bh); - list_add(&bh->b_inode_buffers, list); + list_add_tail(&bh->b_inode_buffers, list); spin_unlock(&lru_list_lock); } @@ -758,7 +794,7 @@ bh->b_private = private; } -static void end_buffer_io_async(struct buffer_head * bh, int uptodate) +void end_buffer_io_async(struct buffer_head * bh, int uptodate) { static spinlock_t page_uptodate_lock = SPIN_LOCK_UNLOCKED; unsigned long flags; @@ -873,7 +909,7 @@ * a noop) */ wait_on_buffer(bh); - ll_rw_block(WRITE, 1, &bh); + write_buffer(bh); brelse(bh); spin_lock(&lru_list_lock); } @@ -1320,13 +1356,14 @@ */ static void discard_buffer(struct buffer_head * bh) { - if (buffer_mapped(bh)) { + if (buffer_mapped(bh) || buffer_delay(bh)) { mark_buffer_clean(bh); lock_buffer(bh); clear_bit(BH_Uptodate, &bh->b_state); clear_bit(BH_Mapped, &bh->b_state); clear_bit(BH_Req, &bh->b_state); clear_bit(BH_New, &bh->b_state); + clear_bit(BH_Delay, &bh->b_state); remove_from_queues(bh); unlock_buffer(bh); } @@ -1618,7 +1655,7 @@ set_bit(BH_Uptodate, &bh->b_state); continue; } - if (!buffer_uptodate(bh) && + if (!buffer_uptodate(bh) && !buffer_delay(bh) && (block_start < from || block_end > to)) { ll_rw_block(READ, 1, &bh); *wait_bh++=bh; @@ -2015,7 +2052,7 @@ if (Page_Uptodate(page)) set_bit(BH_Uptodate, &bh->b_state); - if (!buffer_uptodate(bh)) { + if (!buffer_uptodate(bh) && !buffer_delay(bh)) { err = -EIO; ll_rw_block(READ, 1, &bh); wait_on_buffer(bh); @@ -2744,7 +2781,7 @@ { #ifdef CONFIG_SMP struct buffer_head * bh; - int found = 0, locked = 0, dirty = 0, used = 0, lastused = 0; + int delalloc = 0, found = 0, locked = 0, dirty = 0, used = 0, lastused = 0; int nlist; static char *buf_types[NR_LIST] = { "CLEAN", "LOCKED", "DIRTY", }; #endif @@ -2759,7 +2796,7 @@ if (!spin_trylock(&lru_list_lock)) return; for(nlist = 0; nlist < NR_LIST; nlist++) { - found = locked = dirty = used = lastused = 0; + delalloc = found = locked = dirty = used = lastused = 0; bh = lru_list[nlist]; if(!bh) continue; @@ -2769,6 +2806,8 @@ locked++; if (buffer_dirty(bh)) dirty++; + if (buffer_delay(bh)) + delalloc++; if (atomic_read(&bh->b_count)) used++, lastused = found; bh = bh->b_next_free; @@ -2779,10 +2818,10 @@ printk("%9s: BUG -> found %d, reported %d\n", buf_types[nlist], found, tmp); } - printk("%9s: %d buffers, %lu kbyte, %d used (last=%d), " - "%d locked, %d dirty\n", + printk("%7s: %d buffers, %lu kbyte, %d used (last=%d), " + "%d locked, %d dirty %d delay\n", buf_types[nlist], found, size_buffers_type[nlist]>>10, - used, lastused, locked, dirty); + used, lastused, locked, dirty, delalloc); } spin_unlock(&lru_list_lock); #endif diff -Nru a/fs/inode.c b/fs/inode.c --- a/fs/inode.c Wed Aug 27 22:47:38 2003 +++ b/fs/inode.c Wed Aug 27 22:47:38 2003 @@ -140,6 +140,11 @@ void inode_init_once(struct inode *inode) { memset(inode, 0, sizeof(*inode)); + _inode_init_once(inode); +} + +void _inode_init_once(struct inode *inode) +{ init_waitqueue_head(&inode->i_wait); INIT_LIST_HEAD(&inode->i_hash); INIT_LIST_HEAD(&inode->i_data.clean_pages); @@ -834,6 +839,20 @@ return inode; } +void unlock_new_inode(struct inode *inode) +{ + /* + * This is special! We do not need the spinlock + * when clearing I_LOCK, because we're guaranteed + * that nobody else tries to do anything about the + * state of the inode when it is locked, as we + * just created it (so there can be no old holders + * that haven't tested I_LOCK). + */ + inode->i_state &= ~(I_LOCK|I_NEW); + wake_up(&inode->i_wait); +} + /* * This is called without the inode lock held.. Be careful. * @@ -856,20 +875,9 @@ list_add(&inode->i_list, &inode_in_use); list_add(&inode->i_hash, head); inode->i_ino = ino; - inode->i_state = I_LOCK; + inode->i_state = I_LOCK|I_NEW; spin_unlock(&inode_lock); - /* reiserfs specific hack right here. We don't - ** want this to last, and are looking for VFS changes - ** that will allow us to get rid of it. - ** -- mason@suse.com - */ - if (sb->s_op->read_inode2) { - sb->s_op->read_inode2(inode, opaque) ; - } else { - sb->s_op->read_inode(inode); - } - /* * This is special! We do not need the spinlock * when clearing I_LOCK, because we're guaranteed @@ -878,9 +886,6 @@ * just created it (so there can be no old holders * that haven't tested I_LOCK). */ - inode->i_state &= ~I_LOCK; - wake_up(&inode->i_wait); - return inode; } @@ -960,8 +965,7 @@ return inode; } - -struct inode *iget4(struct super_block *sb, unsigned long ino, find_inode_t find_actor, void *opaque) +struct inode *iget4_locked(struct super_block *sb, unsigned long ino, find_inode_t find_actor, void *opaque) { struct list_head * head = inode_hashtable + hash(sb,ino); struct inode * inode; @@ -1203,9 +1207,9 @@ /* Functions back in dquot.c */ void put_dquot_list(struct list_head *); -int remove_inode_dquot_ref(struct inode *, short, struct list_head *); +int remove_inode_dquot_ref(struct inode *, int, struct list_head *); -void remove_dquot_ref(struct super_block *sb, short type) +void remove_dquot_ref(struct super_block *sb, int type) { struct inode *inode; struct list_head *act_head; diff -Nru a/fs/intermezzo/vfs.c b/fs/intermezzo/vfs.c --- a/fs/intermezzo/vfs.c Wed Aug 27 22:47:36 2003 +++ b/fs/intermezzo/vfs.c Wed Aug 27 22:47:36 2003 @@ -74,7 +74,7 @@ #ifdef CONFIG_FS_EXT_ATTR # include -# ifdef CONFIG_FS_POSIX_ACL +# if 0 /* was a broken check for Posix ACLs */ # include # endif #endif @@ -466,7 +466,7 @@ struct dentry *dentry; struct presto_file_set *fset; int error; -#ifdef CONFIG_FS_POSIX_ACL +#if 0 /* was a broken check for Posix ACLs */ int (*set_posix_acl)(struct inode *, int type, posix_acl_t *)=NULL; #endif @@ -507,7 +507,7 @@ (dentry->d_inode->i_mode & ~S_IALLUGO); CDEBUG(D_PIOCTL, "chmod: orig %#o, set %#o, result %#o\n", dentry->d_inode->i_mode, set_mode, iattr->ia_mode); -#ifdef CONFIG_FS_POSIX_ACL +#if 0 /* was a broken check for Posix ACLs */ /* ACl code interacts badly with setattr * since it tries to modify the ACL using * set_ext_attr which recurses back into presto. @@ -535,7 +535,7 @@ } } -#ifdef CONFIG_FS_POSIX_ACL +#if 0 /* was a broken check for Posix ACLs */ /* restore the inode_operations if we changed them*/ if (iattr->ia_valid & ATTR_MODE) dentry->d_inode->i_op->set_posix_acl=set_posix_acl; @@ -2271,7 +2271,7 @@ #ifdef CONFIG_FS_EXT_ATTR -#ifdef CONFIG_FS_POSIX_ACL +#if 0 /* was a broken check for Posix ACLs */ /* Posix ACL code changes i_mode without using a notify_change (or * a mark_inode_dirty!). We need to duplicate this at the reintegrator * which is done by this function. This function also takes care of @@ -2414,7 +2414,7 @@ goto exit; } -#ifdef CONFIG_FS_POSIX_ACL +#if 0 /* was a broken check for Posix ACLs */ /* Reset mode if specified*/ /* XXX: when we do native acl support, move this code out! */ if (mode != NULL) { diff -Nru a/fs/namei.c b/fs/namei.c --- a/fs/namei.c Wed Aug 27 22:47:37 2003 +++ b/fs/namei.c Wed Aug 27 22:47:37 2003 @@ -1048,8 +1048,9 @@ /* Negative dentry, just create the file */ if (!dentry->d_inode) { - error = vfs_create(dir->d_inode, dentry, - mode & ~current->fs->umask); + if (!IS_POSIXACL(dir->d_inode)) + mode &= ~current->fs->umask; + error = vfs_create(dir->d_inode, dentry, mode); up(&dir->d_inode->i_sem); dput(nd->dentry); nd->dentry = dentry; @@ -1280,7 +1281,8 @@ dentry = lookup_create(&nd, 0); error = PTR_ERR(dentry); - mode &= ~current->fs->umask; + if (!IS_POSIXACL(nd.dentry->d_inode)) + mode &= ~current->fs->umask; if (!IS_ERR(dentry)) { switch (mode & S_IFMT) { case 0: case S_IFREG: @@ -1348,8 +1350,9 @@ dentry = lookup_create(&nd, 1); error = PTR_ERR(dentry); if (!IS_ERR(dentry)) { - error = vfs_mkdir(nd.dentry->d_inode, dentry, - mode & ~current->fs->umask); + if (!IS_POSIXACL(nd.dentry->d_inode)) + mode &= ~current->fs->umask; + error = vfs_mkdir(nd.dentry->d_inode, dentry, mode); dput(dentry); } up(&nd.dentry->d_inode->i_sem); diff -Nru a/fs/xattr.c b/fs/xattr.c --- a/fs/xattr.c Wed Aug 27 22:47:35 2003 +++ b/fs/xattr.c Wed Aug 27 22:47:35 2003 @@ -8,7 +8,6 @@ */ #include #include -#include #include #include #include @@ -17,7 +16,7 @@ /* * Extended attribute memory allocation wrappers, originally * based on the Intermezzo PRESTO_ALLOC/PRESTO_FREE macros. - * The vmalloc use here is very uncommon - extended attributes + * Values larger than a page are uncommon - extended attributes * are supposed to be small chunks of metadata, and it is quite * unusual to have very many extended attributes, so lists tend * to be quite short as well. The 64K upper limit is derived @@ -34,10 +33,8 @@ if (!size) /* size request, no buffer is needed */ return NULL; - else if (size <= PAGE_SIZE) - ptr = kmalloc((unsigned long) size, GFP_KERNEL); - else - ptr = vmalloc((unsigned long) size); + + ptr = kmalloc((unsigned long) size, GFP_KERNEL); if (!ptr) return ERR_PTR(-ENOMEM); return ptr; @@ -46,12 +43,8 @@ static void xattr_free(void *ptr, size_t size) { - if (!size) /* size request, no buffer was needed */ - return; - else if (size <= PAGE_SIZE) + if (size) /* for a size request, no buffer was needed */ kfree(ptr); - else - vfree(ptr); } /* diff -Nru a/include/asm-sh/ioctl.h b/include/asm-sh/ioctl.h --- a/include/asm-sh/ioctl.h Wed Aug 27 22:47:36 2003 +++ b/include/asm-sh/ioctl.h Wed Aug 27 22:47:36 2003 @@ -1,4 +1,4 @@ -/* $Id: ioctl.h,v 1.1 2000/04/14 16:48:21 mjd Exp $ +/* $Id: ioctl.h,v 1.1 1999/09/18 17:29:53 gniibe Exp $ * * linux/ioctl.h for Linux by H.H. Bergman. */ diff -Nru a/include/linux/fs.h b/include/linux/fs.h --- a/include/linux/fs.h Wed Aug 27 22:47:36 2003 +++ b/include/linux/fs.h Wed Aug 27 22:47:36 2003 @@ -111,6 +111,7 @@ #define MS_MOVE 8192 #define MS_REC 16384 #define MS_VERBOSE 32768 +#define MS_POSIXACL 65536 /* VFS does not apply the umask */ #define MS_ACTIVE (1<<30) #define MS_NOUSER (1<<31) @@ -161,6 +162,7 @@ #define IS_IMMUTABLE(inode) ((inode)->i_flags & S_IMMUTABLE) #define IS_NOATIME(inode) (__IS_FLG(inode, MS_NOATIME) || ((inode)->i_flags & S_NOATIME)) #define IS_NODIRATIME(inode) __IS_FLG(inode, MS_NODIRATIME) +#define IS_POSIXACL(inode) __IS_FLG(inode, MS_POSIXACL) #define IS_DEADDIR(inode) ((inode)->i_flags & S_DEAD) @@ -222,6 +224,7 @@ BH_Attached, /* 1 if b_inode_buffers is linked into a list */ BH_JBD, /* 1 if it has an attached journal_head */ BH_Sync, /* 1 if the buffer is a sync read */ + BH_Delay, /* 1 if the buffer is delayed allocate */ BH_PrivateStart,/* not a state bit, but the first bit available * for private allocation by other entities @@ -284,6 +287,7 @@ #define buffer_new(bh) __buffer_state(bh,New) #define buffer_async(bh) __buffer_state(bh,Async) #define buffer_launder(bh) __buffer_state(bh,Launder) +#define buffer_delay(bh) __buffer_state(bh,Delay) #define bh_offset(bh) ((unsigned long)(bh)->b_data & ~PAGE_MASK) @@ -966,6 +970,7 @@ #define I_LOCK 8 #define I_FREEING 16 #define I_CLEAR 32 +#define I_NEW 64 #define I_DIRTY (I_DIRTY_SYNC | I_DIRTY_DATASYNC | I_DIRTY_PAGES) @@ -1144,6 +1149,7 @@ extern void refile_buffer(struct buffer_head * buf); extern void create_empty_buffers(struct page *, kdev_t, unsigned long); extern void end_buffer_io_sync(struct buffer_head *bh, int uptodate); +extern void end_buffer_io_async(struct buffer_head *bh, int uptodate); /* reiserfs_writepage needs this */ extern void set_buffer_async_io(struct buffer_head *bh) ; @@ -1390,16 +1396,52 @@ #define user_path_walk_link(name,nd) __user_walk(name, LOOKUP_POSITIVE, nd) extern void inode_init_once(struct inode *); +extern void _inode_init_once(struct inode *); extern void iput(struct inode *); extern void force_delete(struct inode *); extern struct inode * igrab(struct inode *); extern ino_t iunique(struct super_block *, ino_t); +extern void unlock_new_inode(struct inode *); typedef int (*find_inode_t)(struct inode *, unsigned long, void *); -extern struct inode * iget4(struct super_block *, unsigned long, find_inode_t, void *); + +extern struct inode * iget4_locked(struct super_block *, unsigned long, + find_inode_t, void *); + +static inline struct inode *iget4(struct super_block *sb, unsigned long ino, + find_inode_t find_actor, void *opaque) +{ + struct inode *inode = iget4_locked(sb, ino, find_actor, opaque); + + if (inode && (inode->i_state & I_NEW)) { + /* + * reiserfs-specific kludge that is expected to go away ASAP. + */ + if (sb->s_op->read_inode2) + sb->s_op->read_inode2(inode, opaque); + else + sb->s_op->read_inode(inode); + unlock_new_inode(inode); + } + + return inode; +} + static inline struct inode *iget(struct super_block *sb, unsigned long ino) { - return iget4(sb, ino, NULL, NULL); + struct inode *inode = iget4_locked(sb, ino, NULL, NULL); + + if (inode && (inode->i_state & I_NEW)) { + sb->s_op->read_inode(inode); + unlock_new_inode(inode); + } + + return inode; +} + +static inline struct inode *iget_locked(struct super_block *sb, unsigned long ino) +{ + return iget4_locked(sb, ino, NULL, NULL); } extern void clear_inode(struct inode *); diff -Nru a/include/linux/mm.h b/include/linux/mm.h --- a/include/linux/mm.h Wed Aug 27 22:47:35 2003 +++ b/include/linux/mm.h Wed Aug 27 22:47:35 2003 @@ -134,6 +134,8 @@ void (*open)(struct vm_area_struct * area); void (*close)(struct vm_area_struct * area); struct page * (*nopage)(struct vm_area_struct * area, unsigned long address, int unused); +#define HAVE_VMOP_MPROTECT + int (*mprotect)(struct vm_area_struct * area, unsigned int newflags); }; /* diff -Nru a/include/linux/posix_acl_xattr.h b/include/linux/posix_acl_xattr.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/linux/posix_acl_xattr.h Wed Aug 27 22:47:38 2003 @@ -0,0 +1,67 @@ +/* + File: linux/posix_acl_xattr.h + + Extended attribute system call representation of Access Control Lists. + + Copyright (C) 2000 by Andreas Gruenbacher + Copyright (C) 2002 SGI - Silicon Graphics, Inc + */ +#ifndef _POSIX_ACL_XATTR_H +#define _POSIX_ACL_XATTR_H + +/* Extended attribute names */ +#define POSIX_ACL_XATTR_ACCESS "system.posix_acl_access" +#define POSIX_ACL_XATTR_DEFAULT "system.posix_acl_default" + +/* Supported ACL a_version fields */ +#define POSIX_ACL_XATTR_VERSION 0x0002 + + +/* An undefined entry e_id value */ +#define ACL_UNDEFINED_ID (-1) + +/* ACL entry e_tag field values */ +#define ACL_USER_OBJ (0x01) +#define ACL_USER (0x02) +#define ACL_GROUP_OBJ (0x04) +#define ACL_GROUP (0x08) +#define ACL_MASK (0x10) +#define ACL_OTHER (0x20) + +/* ACL entry e_perm bitfield values */ +#define ACL_READ (0x04) +#define ACL_WRITE (0x02) +#define ACL_EXECUTE (0x01) + + +typedef struct { + __u16 e_tag; + __u16 e_perm; + __u32 e_id; +} posix_acl_xattr_entry; + +typedef struct { + __u32 a_version; + posix_acl_xattr_entry a_entries[0]; +} posix_acl_xattr_header; + + +static inline size_t +posix_acl_xattr_size(int count) +{ + return (sizeof(posix_acl_xattr_header) + + (count * sizeof(posix_acl_xattr_entry))); +} + +static inline int +posix_acl_xattr_count(size_t size) +{ + if (size < sizeof(posix_acl_xattr_header)) + return -1; + size -= sizeof(posix_acl_xattr_header); + if (size % sizeof(posix_acl_xattr_entry)) + return -1; + return size / sizeof(posix_acl_xattr_entry); +} + +#endif /* _POSIX_ACL_XATTR_H */ diff -Nru a/include/linux/posix_cap_xattr.h b/include/linux/posix_cap_xattr.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/linux/posix_cap_xattr.h Wed Aug 27 22:47:38 2003 @@ -0,0 +1,27 @@ +/* + File: linux/posix_cap_xattr.h + + Extended attribute representation of capabilities +*/ +#ifndef _POSIX_CAP_XATTR_H +#define _POSIX_CAP_XATTR_H + +#define POSIX_CAP_XATTR "system.posix_capabilities" +#define POSIX_CAP_XATTR_VERSION 0x0001 + +typedef __u64 posix_cap_xattr_value; + +typedef struct { + __u32 c_version; + __u32 c_abiversion; + posix_cap_xattr_value c_effective; + posix_cap_xattr_value c_permitted; + posix_cap_xattr_value c_inheritable; +} posix_cap_xattr; + +static inline size_t posix_cap_xattr_size(void) +{ + return (sizeof(posix_cap_xattr)); +} + +#endif /* _POSIX_CAP_XATTR_H */ diff -Nru a/include/linux/sched.h b/include/linux/sched.h --- a/include/linux/sched.h Wed Aug 27 22:47:35 2003 +++ b/include/linux/sched.h Wed Aug 27 22:47:35 2003 @@ -432,6 +432,7 @@ #define PF_MEMDIE 0x00001000 /* Killed for out-of-memory */ #define PF_FREE_PAGES 0x00002000 /* per process page freeing */ #define PF_NOIO 0x00004000 /* avoid generating further I/O */ +#define PF_FSTRANS 0x00008000 /* inside a filesystem transaction */ #define PF_USEDFPU 0x00100000 /* task used FPU this quantum (SMP) */ diff -Nru a/include/linux/sysctl.h b/include/linux/sysctl.h --- a/include/linux/sysctl.h Wed Aug 27 22:47:35 2003 +++ b/include/linux/sysctl.h Wed Aug 27 22:47:35 2003 @@ -124,6 +124,7 @@ KERN_CORE_USES_PID=52, /* int: use core or core.%pid */ KERN_TAINTED=53, /* int: various kernel tainted flags */ KERN_CADPID=54, /* int: PID of the process to notify on CAD */ + KERN_KDB=55, /* int: kdb on/off */ KERN_CORE_PATTERN=56, /* string: pattern for core-files */ KERN_PPC_L3CR=57, /* l3cr register on PPC */ KERN_EXCEPTION_TRACE=58, /* boolean: exception trace */ @@ -146,6 +147,7 @@ VM_MAX_MAP_COUNT=11, /* int: Maximum number of active map areas */ VM_MIN_READAHEAD=12, /* Min file readahead */ VM_MAX_READAHEAD=13, /* Max file readahead */ + VM_PAGEBUF=17, /* struct: Control pagebuf parameters */ }; diff -Nru a/kernel/ksyms.c b/kernel/ksyms.c --- a/kernel/ksyms.c Wed Aug 27 22:47:35 2003 +++ b/kernel/ksyms.c Wed Aug 27 22:47:35 2003 @@ -143,15 +143,18 @@ EXPORT_SYMBOL(fget); EXPORT_SYMBOL(igrab); EXPORT_SYMBOL(iunique); -EXPORT_SYMBOL(iget4); +EXPORT_SYMBOL(iget4_locked); +EXPORT_SYMBOL(unlock_new_inode); EXPORT_SYMBOL(iput); EXPORT_SYMBOL(inode_init_once); +EXPORT_SYMBOL(_inode_init_once); EXPORT_SYMBOL(force_delete); EXPORT_SYMBOL(follow_up); EXPORT_SYMBOL(follow_down); EXPORT_SYMBOL(lookup_mnt); EXPORT_SYMBOL(path_init); EXPORT_SYMBOL(path_walk); +EXPORT_SYMBOL(path_lookup); EXPORT_SYMBOL(path_release); EXPORT_SYMBOL(__user_walk); EXPORT_SYMBOL(lookup_one_len); @@ -171,6 +174,7 @@ EXPORT_SYMBOL(__d_path); EXPORT_SYMBOL(mark_buffer_dirty); EXPORT_SYMBOL(set_buffer_async_io); /* for reiserfs_writepage */ +EXPORT_SYMBOL(end_buffer_io_async); EXPORT_SYMBOL(__mark_buffer_dirty); EXPORT_SYMBOL(__mark_inode_dirty); EXPORT_SYMBOL(fd_install); @@ -249,6 +253,7 @@ EXPORT_SYMBOL(find_inode_number); EXPORT_SYMBOL(is_subdir); EXPORT_SYMBOL(get_unused_fd); +EXPORT_SYMBOL(put_unused_fd); EXPORT_SYMBOL(vfs_create); EXPORT_SYMBOL(vfs_mkdir); EXPORT_SYMBOL(vfs_mknod); @@ -266,6 +271,7 @@ EXPORT_SYMBOL(ROOT_DEV); EXPORT_SYMBOL(__find_get_page); EXPORT_SYMBOL(__find_lock_page); +EXPORT_SYMBOL(find_trylock_page); EXPORT_SYMBOL(find_or_create_page); EXPORT_SYMBOL(grab_cache_page_nowait); EXPORT_SYMBOL(read_cache_page); diff -Nru a/kernel/sysctl.c b/kernel/sysctl.c --- a/kernel/sysctl.c Wed Aug 27 22:47:35 2003 +++ b/kernel/sysctl.c Wed Aug 27 22:47:35 2003 @@ -28,6 +28,9 @@ #include #include #include +#ifdef CONFIG_KDB +#include +#endif /* CONFIG_KDB */ #include #include diff -Nru a/mm/filemap.c b/mm/filemap.c --- a/mm/filemap.c Wed Aug 27 22:47:37 2003 +++ b/mm/filemap.c Wed Aug 27 22:47:37 2003 @@ -3315,6 +3315,9 @@ return err; } +EXPORT_SYMBOL(do_generic_file_write); +EXPORT_SYMBOL(do_generic_direct_write); + void __init page_cache_init(unsigned long mempages) { unsigned long htable_size, order; diff -Nru a/mm/mprotect.c b/mm/mprotect.c --- a/mm/mprotect.c Wed Aug 27 22:47:37 2003 +++ b/mm/mprotect.c Wed Aug 27 22:47:37 2003 @@ -300,6 +300,11 @@ goto out; } + if (vma->vm_ops && vma->vm_ops->mprotect) { + error = vma->vm_ops->mprotect(vma, newflags); + if (error < 0) + goto out; + } if (vma->vm_end > end) { error = mprotect_fixup(vma, &prev, nstart, end, newflags); goto out; --=-xOCcTQIDnL6ppaQvlLY+ Content-Disposition: attachment; filename=xfs2.4.22.patch Content-Type: text/plain; name=xfs2.4.22.patch; charset=iso-8859-1 Content-Transfer-Encoding: 7bit # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1067 -> 1.1068 # fs/xfs/linux/xfs_lrw.c 1.166 -> 1.167 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/08/07 cattelan@naboo.eagan 1.1068 # Call generic_* functions directly rather than using generic_file_write # -------------------------------------------- # diff -Nru a/fs/xfs/linux/xfs_lrw.c b/fs/xfs/linux/xfs_lrw.c --- a/fs/xfs/linux/xfs_lrw.c Wed Aug 27 22:49:47 2003 +++ b/fs/xfs/linux/xfs_lrw.c Wed Aug 27 22:49:47 2003 @@ -586,12 +586,29 @@ } } + + if ((ssize_t) size < 0) + return -EINVAL; + + if (!access_ok(VERIFY_READ, buf, size)) + return -EFAULT; + retry: if (direct) { + struct inode *inode = file->f_dentry->d_inode->i_mapping->host; xfs_inval_cached_pages(vp, &xip->i_iocore, *offset, 1, 1); + + down_read(&inode->i_alloc_sem); + ret = do_generic_direct_write(file, buf, size, offset); + up_read(&inode->i_alloc_sem); + if (unlikely(ret == -ENOTBLK)) + goto fallback; + } else { +fallback: + ret = do_generic_file_write(file, buf, size, offset); } - ret = generic_file_write_nolock(file, buf, size, offset); +/* ret = generic_file_write_nolock(file, buf, size, offset); */ if (unlikely(file->f_mode & FINVIS)) { /* generic_file_write updates the mtime/ctime but we need --=-xOCcTQIDnL6ppaQvlLY+-- From owner-linux-xfs@oss.sgi.com Wed Aug 27 20:58:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Aug 2003 20:59:28 -0700 (PDT) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7S3wnWZ003941 for ; Wed, 27 Aug 2003 20:58:50 -0700 Received: from [10.0.0.10] (c-24-118-121-167.mn.client2.attbi.com [24.118.121.167]) by lips.thebarn.com (8.12.9/8.12.9) with ESMTP id h7S3w1nF005208; Wed, 27 Aug 2003 22:58:01 -0500 (CDT) (envelope-from cattelan@thebarn.com) Subject: Re: 2.4.22 in cvs? From: Russell Cattelan To: Net Llama! Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1062043004.90958.5.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 28 Aug 2003 03:56:44 +0000 Content-Transfer-Encoding: 7bit X-archive-position: 208 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs Content-Length: 694 Lines: 21 On Wed, 2003-08-27 at 13:23, Net Llama! wrote: > Anyone know if the code in cvs will apply cleanly on 2.4.22? thanks! This is the easiest way to get xfs running in 2.4.22 clone the bk tree at http://xfs.org:8090/linux-2.4+xfs If that doesn't work for you check out the xfs-linux tree on oss cvs -d :pserver:cvs@oss.sgi.com:/cvs co xfs-linux apply this patch to your 2.4.22 tree core-xfs2.4.22.patch then apply this patch to your freshly checked out xfs tree xfs2.4.22.patch cd xfs and you have a xfs 2.4.22 tree. And you can keep cvs updating your xfs-linux tree to stay current. -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Wed Aug 27 22:01:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Aug 2003 22:02:25 -0700 (PDT) Received: from mail.blazebox.homeip.net (postfix@pool-162-84-136-131.ny5030.east.verizon.net [162.84.136.131]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7S51gWZ006746 for ; Wed, 27 Aug 2003 22:01:42 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.blazebox.homeip.net (Postfix) with ESMTP id 4CF829F0D; Thu, 28 Aug 2003 01:01:41 -0400 (EDT) Received: from mail.blazebox.homeip.net (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.14) id 14074-5DF07CD3; Thu, 28 Aug 2003 01:01:41 -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 E947B9E99; Thu, 28 Aug 2003 01:01:40 -0400 (EDT) Subject: Re: 2.4.22 in cvs? From: Paul Blazejowski To: Russell Cattelan Cc: Net Llama! , linux-xfs In-Reply-To: <1062012498.10618.32.camel@naboo> References: <1062008140.5313.5.camel@blaze.homeip.net> <1062012498.10618.32.camel@naboo> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/A2GyHkr5tffCym2lbC3" Message-Id: <1062046956.1132.14.camel@blaze.homeip.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 (Slackware Linux) Date: Thu, 28 Aug 2003 01:02:36 -0400 X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.14; AVE: 6.21.0.1; VDF: 6.21.0.29; host: blazebox.homeip.net) X-archive-position: 210 X-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: 1068 Lines: 41 --=-/A2GyHkr5tffCym2lbC3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2003-08-27 at 15:28, Russell Cattelan wrote: > what kind of problems? No problems related to filesystem itself.I had an issue generating a diff out of linux-2.4-xfs tree against 2.4.22-pre and -rc kernels.I had asked on #xfs a while ago...It was related to a O_DIRECT change i think, which 2.4.22 kernel introduced. > I ran fsx on 2.4.22 a couple of days ago for a couple of hours=20 > with out problems. >=20 No problems here either. > This tree is being keep current so please test it, > and report problems. (via bugzilla preferably)=20 >=20 That's what i am using right now. Thanks. Paul --=-/A2GyHkr5tffCym2lbC3 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/TYzsIymMQsXoRDARAuXrAJ9ma0l1zr5uSHFB4PONgPXIev8XAACeK8fL IkOnA3IJZL0s2FXzs3dqqUk= =NugN -----END PGP SIGNATURE----- --=-/A2GyHkr5tffCym2lbC3-- From owner-linux-xfs@oss.sgi.com Wed Aug 27 22:33:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Aug 2003 22:34:09 -0700 (PDT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7S5XSWZ009181 for ; Wed, 27 Aug 2003 22:33:29 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 01E0DEB4A0E for ; Thu, 28 Aug 2003 13:33:22 +0800 (PHT) Received: from lawin.alabang.leathercollection.ph (lawin.alabang.leathercollection.ph [192.168.0.2]) by gusi.leathercollection.ph (Postfix) with ESMTP id 170DEEB4A05 for ; Thu, 28 Aug 2003 13:33:12 +0800 (PHT) Received: by lawin.alabang.leathercollection.ph (Postfix, from userid 1000) id 58A9B1A4036; Thu, 28 Aug 2003 13:33:11 +0800 (PHT) Date: Thu, 28 Aug 2003 13:33:11 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List Subject: Re: 2.4.22 in cvs? Message-ID: <20030828053311.GB2510@leathercollection.ph> Mail-Followup-To: Linux-XFS Mailing List References: <1062003852.22690.1247.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1062003852.22690.1247.camel@jen.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: 211 X-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: 819 Lines: 19 On Wed, Aug 27, 2003 at 12:04:12PM -0500, Steve Lord wrote: > It won't. Right now we have 2.4.22 available via bitkeeper from > xfs.org, Russell posted this on the list a while ago. The crypto merge > into 2.4.22 means hosting it on an SGI web site takes some approvals. I'm curious: will it make sense to release split patches for 2.4.22 like those available for 2.4.21, even if CVS doesn't have the full 2.4.22-xfs yet while waiting for the approval due to the crypto merge? Or will split patches for 2.4.22 require the same approval anyway? Thank you for your time. :) --> 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 Wed Aug 27 22:54:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Aug 2003 22:55:18 -0700 (PDT) Received: from iris.acsalaska.net (iris.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7S5sYWZ010219 for ; Wed, 27 Aug 2003 22:54:35 -0700 Received: from erbenson.alaska.net (232-pm16.nwc.alaska.net [209.112.141.232]) by iris.acsalaska.net (8.12.9/8.12.9) with ESMTP id h7S5sWE5060948 for ; Wed, 27 Aug 2003 21:54:32 -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 374B739E4 for ; Wed, 27 Aug 2003 21:54:30 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 78C3D40FF44; Wed, 27 Aug 2003 21:54:31 -0800 (AKDT) Date: Wed, 27 Aug 2003 21:54:31 -0800 From: Ethan Benson To: Linux-XFS Mailing List Subject: Re: 2.4.22 in cvs? Message-ID: <20030828055431.GB12362@plato.local.lan> Mail-Followup-To: Linux-XFS Mailing List References: <1062003852.22690.1247.camel@jen.americas.sgi.com> <20030828053311.GB2510@leathercollection.ph> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ADZbWkCsHQ7r3kzd" Content-Disposition: inline In-Reply-To: <20030828053311.GB2510@leathercollection.ph> 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: 212 X-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: 1334 Lines: 41 --ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 28, 2003 at 01:33:11PM +0800, Federico Sevilla III wrote: > On Wed, Aug 27, 2003 at 12:04:12PM -0500, Steve Lord wrote: > > It won't. Right now we have 2.4.22 available via bitkeeper from > > xfs.org, Russell posted this on the list a while ago. The crypto merge > > into 2.4.22 means hosting it on an SGI web site takes some approvals. >=20 > I'm curious: will it make sense to release split patches for 2.4.22 like > those available for 2.4.21, even if CVS doesn't have the full 2.4.22-xfs it would make a lot of sense, it would allow people to easily upgrade to 2.4.22 now. > yet while waiting for the approval due to the crypto merge? Or will > split patches for 2.4.22 require the same approval anyway? the patches won't contain any crypto, thus don't require any approval. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --ADZbWkCsHQ7r3kzd 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 iEYEARECAAYFAj9NmRcACgkQJKx7GixEevyn2gCfbtaazBKTLNKGF9HTq80bgGjs I7YAn0Q3Kvhr6OJY1B88U5yXwsKbaH0M =K+dQ -----END PGP SIGNATURE----- --ADZbWkCsHQ7r3kzd-- From owner-linux-xfs@oss.sgi.com Wed Aug 27 23:10:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Aug 2003 23:11:35 -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.5) with SMTP id h7S6ArWZ011282 for ; Wed, 27 Aug 2003 23:10:54 -0700 Received: from mailhub.ch.sauter-bc.com (mailhub [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 94EB232CC4; Thu, 28 Aug 2003 08:10:47 +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 9F22632CB5; Thu, 28 Aug 2003 08:10:46 +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 A433711E08; Thu, 28 Aug 2003 08:10:45 +0200 (CEST) Received: from 10.1.200.117 (SquirrelMail authenticated user mattesim) by imap01.ch.sauter-bc.com with HTTP; Thu, 28 Aug 2003 08:10:46 +0200 (CEST) Message-ID: <1055.10.1.200.117.1062051046.squirrel@imap01.ch.sauter-bc.com> In-Reply-To: <20030827161257.GD2864@pua.nirvana> References: <20030826142327.GB3818@pua.nirvana> <20030826153708.GG3818@pua.nirvana> <1061913418.13459.13.camel@stout.americas.sgi.com> <3F4B73F3.1A08113B@ch.sauter-bc.com> <1061912643.13459.1.camel@stout.americas.sgi.com> <20030826161953.GB6163@pua.nirvana> <1061932714.13459.71.camel@stout.americas.sgi.com> <35984.213.173.165.140.1061961866.squirrel@imap01.ch.sauter-bc.com> <20030827161257.GD2864@pua.nirvana> Date: Thu, 28 Aug 2003 08:10:46 +0200 (CEST) Subject: Re: Patch 1300 & rpm issue with 1.3.0 From: "Simon Matter" To: "Axel Thimm" Cc: "Simon Matter" , "Eric Sandeen" , "Kai Leibrandt" , 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 h7S6AtWZ011283 X-archive-position: 213 X-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: 1276 Lines: 34 > Hi, > > On Wed, Aug 27, 2003 at 07:24:26AM +0200, Simon Matter wrote: >> > Argh, here's one thing that went wrong... my cscope database did not >> > index fs/ext3/file.c, for some reason... so I did not modify it, and >> > O_DIRECT was not getting turned off for ext3 - hence the problem on >> ext3 >> > roots. >> >> My question remains, how does the problem discussed here show up. I have >> installed 20.9.XFS1.3.0 on RedHat 9 with my nonnptl db4 package and >> couldn't find any problem using rpm. > > I think (haven't rebuild rpm for some time), that db4 is not linked > against, but has been embedded into rpm's sources. Try ldd on > /bin/rpm, you'll find it depending on librpmdb-4.2.so, and not > libdb-4.*.so > > It was said that latest rpm bits (4.2, 4.1.1 and 4.0.5) had O_DIRECT > disabled in their db4 code. But someone reported this failure on an > rpm 4.2 system, so I am puzzled again ... :( > > I guess I need to rebuild rpm for RH9/8.0/7.3, maybe go straight to > 4.2.1. Well, RH 7.2 is also widely used here and there is quite a big difference between 7.2 ... 9. On 7.2, rpm is statically linked. And then, if an application like rpm breaks with a certain kernel/filesystem, I expect it not to be the only application that breaks. Am I paranoid? Simon From owner-linux-xfs@oss.sgi.com Wed Aug 27 23:19:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Aug 2003 23:20:30 -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.5) with SMTP id h7S6JlWZ011969 for ; Wed, 27 Aug 2003 23:19:48 -0700 Received: from mailhub.ch.sauter-bc.com (mailhub [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 4C6DD32CC6; Thu, 28 Aug 2003 08:19:42 +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 DEBEC32CD0; Thu, 28 Aug 2003 08:19:24 +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 75FDF11E08; Thu, 28 Aug 2003 08:19:24 +0200 (CEST) Received: from 10.1.200.117 (SquirrelMail authenticated user mattesim) by imap01.ch.sauter-bc.com with HTTP; Thu, 28 Aug 2003 08:19:24 +0200 (CEST) Message-ID: <1088.10.1.200.117.1062051564.squirrel@imap01.ch.sauter-bc.com> In-Reply-To: <1356.192.168.0.54.1062027684.squirrel@mail.imgame.net> References: <1356.192.168.0.54.1062027684.squirrel@mail.imgame.net> Date: Thu, 28 Aug 2003 08:19:24 +0200 (CEST) Subject: Re: EXPANSION PARTITION PROBLEM From: "Simon Matter" To: rvfrancisco@imgame.net 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 h7S6JnWZ011970 X-archive-position: 214 X-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: 1595 Lines: 58 > > > GOOD DAY!, > > I just want to know is there any way to expand a RAID5 partition 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 my raid5 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 expand my partion in Raid5 > to expand the capacity? Is there packages needed to repartion my Hardisk? > or is their any particular command do i need to run? > Thanks.... Did you read the reply I sent yesterday. The problem is that we can't know how your RAID controller expands an RAID5 array. If the old device looks like this: +-----------------------+ +-----------------------+ and after growing it looks like this: +--------------------------------------+ +--------------------------------------+ then you can use fdisk in expert mode to change the size of your drive in the partition table and change the partition in this table. Then use xfs_grows to grow the filesystem on the growed partition. I don't know how to change the partition table because I have to read the fdisk docs before I do it. Simon > > Regards, > Rodel Francisco > System Administrator > > > > > > > > > -- Simon Matter Tel: +41 61 695 57 35 Fr.Sauter AG / CIT Fax: +41 61 695 53 30 Im Surinam 55 CH-4016 Basel [mailto:simon.matter@ch.sauter-bc.com] From owner-linux-xfs@oss.sgi.com Thu Aug 28 00:26:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 00:27:27 -0700 (PDT) Received: from hotmail.com (law9-oe64.law9.hotmail.com [64.4.8.199]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7S7QlWZ026460 for ; Thu, 28 Aug 2003 00:26:47 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 28 Aug 2003 00:26:42 -0700 Received: from 80.128.32.149 by law9-oe64.law9.hotmail.com with DAV; Thu, 28 Aug 2003 07:26:42 +0000 X-Originating-IP: [80.128.32.149] X-Originating-Email: [k_leibrandt@hotmail.com] From: "Kai Leibrandt" To: "'Simon Matter'" , "'Axel Thimm'" Cc: "'Eric Sandeen'" , Subject: RE: Patch 1300 & rpm issue with 1.3.0 Date: Thu, 28 Aug 2003 09:26:36 +0200 Message-ID: <001601c36d35$b6957bd0$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 Importance: Normal In-Reply-To: <1055.10.1.200.117.1062051046.squirrel@imap01.ch.sauter-bc.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 28 Aug 2003 07:26:42.0400 (UTC) FILETIME=[BA5F2E00:01C36D35] X-archive-position: 215 X-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: 506 Lines: 16 > Well, RH 7.2 is also widely used here and there is quite a > big difference between 7.2 ... 9. On 7.2, rpm is statically > linked. And then, if an application like rpm breaks with a > certain kernel/filesystem, I expect it not to be the only > application that breaks. Am I paranoid? > > Simon That's just what I was thinking; is rpm only an indication that other apps might have issues as well? If so, how do we identify them and rectify the problems? In the kernel, or in the app? Kai. From owner-linux-xfs@oss.sgi.com Thu Aug 28 03:55:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 03:55:43 -0700 (PDT) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SAt1WZ011083 for ; Thu, 28 Aug 2003 03:55:04 -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 h7SAsjXA049655; Thu, 28 Aug 2003 12:54:50 +0200 (CEST) Message-Id: <4.3.2.7.2.20030828125339.02e089f0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Aug 2003 12:54:43 +0200 To: rvfrancisco@imgame.net, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: EXPANSION PARTITION PROBLEM In-Reply-To: <1356.192.168.0.54.1062027684.squirrel@mail.imgame.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 216 X-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: 497 Lines: 20 At 07:41 28-8-2003 +0800, rvfrancisco@imgame.net wrote: >partition in Redhat it is still 68G. How can I expand my partion in Raid5 >to expand the capacity? Is there packages needed to repartion my Hardisk? >or is their any particular command do i need to run? >Thanks.... Use GNU parted and extend the partition to the rest of the device. After that mount the filesystem and perform xfs_growfs. That should basically work. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Aug 28 05:49:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 05:50:33 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SCnqWZ017478 for ; Thu, 28 Aug 2003 05:49:52 -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 h7SCnlq0013321 for ; Thu, 28 Aug 2003 05:49:47 -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 h7SCmkCh10900141 for ; Thu, 28 Aug 2003 07:48:46 -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 h7SCmk0L17272557 for ; Thu, 28 Aug 2003 07:48:46 -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 h7SCmkTg8510082 for ; Thu, 28 Aug 2003 07:48:46 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id h7SCmk6l10239164 for linux-xfs@oss.sgi.com; Thu, 28 Aug 2003 07:48:46 -0500 (CDT) Date: Thu, 28 Aug 2003 07:48:46 -0500 (CDT) From: Dean Roehrich Message-Id: <200308281248.h7SCmk6l10239164@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 899682 - X-archive-position: 217 X-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: 1059 Lines: 33 Change dm_send_namesp_event to take vnode ptrs rather than bhv ptrs. Date: Thu Aug 28 05:48:31 PDT 2003 Workarea: clink.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:157475a linux/fs/xfs/xfs_vnodeops.c - 1.603 - Change dm_send_namesp_event to take vnode ptrs rather than bhv ptrs. linux/fs/xfs/xfs_vfsops.c - 1.428 - Change dm_send_namesp_event to take vnode ptrs rather than bhv ptrs. linux/fs/xfs/xfs_mount.h - 1.178 - Change dm_send_namesp_event to take vnode ptrs rather than bhv ptrs. linux/fs/xfs/xfs_rename.c - 1.53 - Change dm_send_namesp_event to take vnode ptrs rather than bhv ptrs. linux/fs/xfs/dmapi/dmapi_kern.h - 1.5 - Change dm_send_namesp_event to take vnode ptrs rather than bhv ptrs. linux/fs/xfs/dmapi/dmapi_event.c - 1.17 - Change dm_send_namesp_event to take vnode ptrs rather than bhv ptrs. linux/fs/xfs/linux/xfs_lrw.c - 1.194 - Change dm_send_namesp_event to take vnode ptrs rather than bhv ptrs. From owner-linux-xfs@oss.sgi.com Thu Aug 28 06:12:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 06:13:09 -0700 (PDT) Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SDCQWZ019252 for ; Thu, 28 Aug 2003 06:12:27 -0700 Received: (qmail 7123 invoked by uid 1000); 28 Aug 2003 13:12:44 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Aug 2003 13:12:44 -0000 Date: Thu, 28 Aug 2003 16:12:41 +0300 (EEST) From: Mihai RUSU X-X-Sender: To: Simon Matter cc: , Subject: Re: EXPANSION PARTITION PROBLEM In-Reply-To: <1088.10.1.200.117.1062051564.squirrel@imap01.ch.sauter-bc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 218 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Content-Length: 1180 Lines: 34 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 28 Aug 2003, Simon Matter wrote: > > then you can use fdisk in expert mode to change the size of your drive in > the partition table and change the partition in this table. Then use > xfs_grows to grow the filesystem on the growed partition. > I don't know how to change the partition table because I have to read the > fdisk docs before I do it. > > Simon Hi Simon I have did several such extends without loosing any data with Mylex DAC960 based controllers and I always used normal mode of fdisk. Just entered fdisk, deleted the current partition, recreated another one wich covers the new space too (and which starts from the same position, THIS IS VERY IMPORTANT), and exited with 'w'. Then mount the XFS partition, xfs_growfs on it and all was fine :) - ---------------------------- Mihai RUSU Email: dizzy@roedu.net GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/Tf/MPZzOzrZY/1QRAqHnAKDZ4QToFiLt/oqJvl67gx1Wk1SkwQCcDZuO nDJ2NJ0dZ6NRoR6j2vpktFk= =nfrn -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Thu Aug 28 07:16:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 07:17:40 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SEGxWZ023501 for ; Thu, 28 Aug 2003 07:16:59 -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 h7SEXcxZ017722 for ; Thu, 28 Aug 2003 09:33: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 h7SEGrCh10896610; Thu, 28 Aug 2003 09:16:53 -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 h7SEGrwh19256420; Thu, 28 Aug 2003 09:16:53 -0500 (CDT) Date: Thu, 28 Aug 2003 09:16:52 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Kai Leibrandt cc: "'Simon Matter'" , "'Axel Thimm'" , Subject: RE: Patch 1300 & rpm issue with 1.3.0 In-Reply-To: <001601c36d35$b6957bd0$0c00a8c0@Legolas> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 219 X-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: 450 Lines: 12 On Thu, 28 Aug 2003, Kai Leibrandt wrote: > That's just what I was thinking; is rpm only an indication that other > apps might have issues as well? If so, how do we identify them and > rectify the problems? In the kernel, or in the app? That's not clear to me yet, but we have dome some O_DIRECT stresstesting and it's all been fine. So this doesn't seem to be a problem with O_DIRECT in general, which makes me think it might be the app. -Eric From owner-linux-xfs@oss.sgi.com Thu Aug 28 07:36:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 07:36:45 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.5) with ESMTP id h7SEaTWZ024922 for ; Thu, 28 Aug 2003 07:36:29 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7SEaTkD024921 for linux-xfs@oss.sgi.com; Thu, 28 Aug 2003 07:36:29 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.5) with ESMTP id h7SEaQWb024903 for ; Thu, 28 Aug 2003 07:36:27 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h7SDjZUA021322; Thu, 28 Aug 2003 06:45:35 -0700 Date: Thu, 28 Aug 2003 06:45:35 -0700 Message-Id: <200308281345.h7SDjZUA021322@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 267] pwrite64 failed on 1.2 TB evms volume X-Bugzilla-Reason: AssignedTo X-archive-position: 220 X-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: 8080 Lines: 177 http://oss.sgi.com/bugzilla/show_bug.cgi?id=267 ------- Additional Comments From dg@ethx.de 2003-28-08 06:45 PDT ------- got the same Problem on an evms volume (/dev/evms/cache 1.7 TB). mkfs.xfs on the partition (DOS and also GPT) itself (/dev/sdb1) works fine. kernel - 2.4.21 snapshot-xfs-2.4.21-2003-08-06_04:46_UTC evms-2.1.1 (older version too) device-mapper.1.00.04 (older version too) vfs-lock-xfs.patch (evms-2.1.1 included) mkfs.xfs version 2.4.12 ---cut--- fs0-2:~# strace mkfs.xfs -f /dev/evms/cache execve("/sbin/mkfs.xfs", ["mkfs.xfs", "-f", "/dev/evms/cache"], [/* 14 vars */]) = 0 uname({sys="Linux", node="fs0-2", ...}) = 0 brk(0) = 0x808fc7c 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=12570, ...}) = 0 old_mmap(NULL, 12570, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000 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\30\222"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=1153784, ...}) = 0 old_mmap(NULL, 1166560, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40018000 mprotect(0x4012b000, 40160, PROT_NONE) = 0 old_mmap(0x4012b000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x113000) = 0x4012b000 old_mmap(0x40131000, 15584, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40131000 close(3) = 0 munmap(0x40014000, 12570) = 0 brk(0) = 0x808fc7c brk(0x808fca4) = 0x808fca4 brk(0x8090000) = 0x8090000 stat64("/dev/evms/cache", {st_mode=S_IFBLK|0640, st_rdev=makedev(254, 6), ...}) = 0 open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 read(3, "Character devices:\n 1 mem\n 2 p"..., 4096) = 207 close(3) = 0 munmap(0x40014000, 4096) = 0 open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 read(3, "Character devices:\n 1 mem\n 2 p"..., 4096) = 207 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40014000, 4096) = 0 open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 read(3, "Character devices:\n 1 mem\n 2 p"..., 4096) = 207 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40014000, 4096) = 0 open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 read(3, "Character devices:\n 1 mem\n 2 p"..., 4096) = 207 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40014000, 4096) = 0 getcwd("/root", 4096) = 6 stat64("/dev/evms/cache", {st_mode=S_IFBLK|0640, st_rdev=makedev(254, 6), ...}) = 0 stat64("/dev/evms/cache", {st_mode=S_IFBLK|0640, st_rdev=makedev(254, 6), ...}) = 0 ustat(0xfe06, 0xbfffe728) = -1 EINVAL (Invalid argument) open("/dev/evms/cache", O_RDONLY|O_LARGEFILE) = 3 stat64("/dev/evms/cache", {st_mode=S_IFBLK|0640, st_rdev=makedev(254, 6), ...}) = 0 stat64("/dev/evms/cache", {st_mode=S_IFBLK|0640, st_rdev=makedev(254, 6), ...}) = 0 ustat(0xfe06, 0xbfffe728) = -1 EINVAL (Invalid argument) open("/dev/evms/cache", O_RDWR|O_LARGEFILE) = 4 stat64("/dev/evms/cache", {st_mode=S_IFBLK|0640, st_rdev=makedev(254, 6), ...}) = 0 ioctl(4, 0x40041271, 0xbfffe75c) = 0 fstat64(4, {st_mode=S_IFBLK|0640, st_rdev=makedev(254, 6), ...}) = 0 ioctl(4, 0x80041272, 0xbfffe774) = 0 ioctl(4, BLKSSZGET, 0xbffffb40) = 0 chdir("/root") = 0 close(3) = 0 stat64("/dev/evms/cache", {st_mode=S_IFBLK|0640, st_rdev=makedev(254, 6), ...}) = 0 open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 read(3, "Character devices:\n 1 mem\n 2 p"..., 4096) = 207 close(3) = 0 munmap(0x40014000, 4096) = 0 open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 read(3, "Character devices:\n 1 mem\n 2 p"..., 4096) = 207 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40014000, 4096) = 0 open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 read(3, "Character devices:\n 1 mem\n 2 p"..., 4096) = 207 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40014000, 4096) = 0 open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 read(3, "Character devices:\n 1 mem\n 2 p"..., 4096) = 207 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40014000, 4096) = 0 fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 write(1, "meta-data=/dev/evms/cache "..., 86meta-data=/dev/evms/cache isize=256 agcount=4294967215 , agsize=1048576 blks ) = 86 write(1, " = "..., 46 = sectsz=512 ) = 46 write(1, "data = "..., 82data = bsize=4096 blocks=45035995421 85124, imaxpct=25 ) = 82 write(1, " = "..., 73 = sunit=0 swidth=0 blks, unw ritten=1 ) = 73 write(1, "naming =version 2 "..., 46naming =version 2 bsize=4096 ) = 46 write(1, "log =internal log "..., 70log =internal log bsize=4096 blocks=32768, vers ion=1 ) = 70 write(1, " = "..., 59 = sectsz=512 sunit=0 blks ) = 59 write(1, "realtime =none "..., 68realtime =none extsz=65536 blocks=0, rtextent s=0 ) = 68 gettimeofday({1062076139, 575323}, NULL) = 0 open("/dev/urandom", O_RDONLY) = 3 getpid() = 374 getuid32() = 0 gettimeofday({1062076139, 575461}, NULL) = 0 gettimeofday({1062076139, 575499}, NULL) = 0 read(3, "\232\271\222\316J\237\246\200PU\252\27186R\323", 16) = 16 brk(0x80a2000) = 0x80a2000 pwrite(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 69632, 0) = 69632 pwrite(4, "XFSB\0\0\20\0\0\17\377\377\372\354,\244\0\0\0\0\0\0\0\0"..., 512, 0) = 512 pwrite(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536, 18446743724790202368) = -1 EINVAL (I nvalid argument) write(2, "mkfs.xfs: pwrite64 failed: Inval"..., 44mkfs.xfs: pwrite64 failed: Invalid argument ) = 44 munmap(0x40014000, 4096) = 0 _exit(1) = ? ---cut--- -DG ------- 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 28 08:06:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 08:07:27 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SF6nWZ026888 for ; Thu, 28 Aug 2003 08:06: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 h7SFNSxZ003680 for ; Thu, 28 Aug 2003 10:23:28 -0500 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 h7SF6hCh10863828 for ; Thu, 28 Aug 2003 10:06:43 -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 h7SF6h0L17455138 for ; Thu, 28 Aug 2003 10:06:43 -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 h7SF6hTg10334185 for ; Thu, 28 Aug 2003 10:06:43 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id h7SF6hkZ10313900 for linux-xfs@oss.sgi.com; Thu, 28 Aug 2003 10:06:43 -0500 (CDT) Date: Thu, 28 Aug 2003 10:06:43 -0500 (CDT) From: Dean Roehrich Message-Id: <200308281506.h7SF6hkZ10313900@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 899682 - X-archive-position: 221 X-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: 620 Lines: 21 Change dm_send_mount_event to use vnode ptrs rather than bhv ptrs Date: Thu Aug 28 08:06:30 PDT 2003 Workarea: clink.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:157485a linux/fs/xfs/dmapi/dmapi_kern.h - 1.6 - Change dm_send_mount_event to use vnode ptrs rather than bhv ptrs linux/fs/xfs/dmapi/dmapi_xfs.c - 1.12 - Change dm_send_mount_event to use vnode ptrs rather than bhv ptrs linux/fs/xfs/dmapi/dmapi_event.c - 1.18 - Change dm_send_mount_event to use vnode ptrs rather than bhv ptrs From owner-linux-xfs@oss.sgi.com Thu Aug 28 08:16:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 08:17:28 -0700 (PDT) Received: from THOR.goeci.com (thor.goeci.com [66.28.220.99]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SFGsWZ027884 for ; Thu, 28 Aug 2003 08:16:54 -0700 Received: by THOR.goeci.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Aug 2003 11:16:48 -0400 Message-ID: <2D92FEBFD3BE1346A6C397223A8DD3FC0923BF@THOR.goeci.com> From: Murthy Kambhampaty To: linux-xfs@oss.sgi.com Subject: Raid expansion and xfs Date: Thu, 28 Aug 2003 11:16:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 222 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs Content-Length: 445 Lines: 10 If I start with a 5-disk raid-5 array and mkfs.xfs with options "-d su=64k,sw=4 [-l version=2]", then expand that array with another disk, will XFS still correctly align the data, after expansion? My tentative conclusion is that XFS will continue to write data in 4x64k "chunks" though it could now write in 5x64k ones, and the data will still be properly aligned but not optimally sized. Is this right? (am I even close ...) Thanks, Murthy From owner-linux-xfs@oss.sgi.com Thu Aug 28 08:25:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 08:26:32 -0700 (PDT) Received: from mail.dkp.com (hidden-user@mail.dkp.com [204.191.16.3]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SFPmWZ028877 for ; Thu, 28 Aug 2003 08:25:51 -0700 Received: by mail.dkp.com (Postfix, from userid 20001) id C21F42AF5E; Thu, 28 Aug 2003 11:25:47 -0400 (EDT) Received: from wallace.dkp.com (wallace.dkp.com [10.0.0.81]) by mail.dkp.com (Postfix) with ESMTP id 1528F2AEC9 for ; Thu, 28 Aug 2003 11:25:47 -0400 (EDT) Received: by wallace.dkp.com (Postfix, from userid 168) id 75BCC6F380; Thu, 28 Aug 2003 11:25:46 -0400 (EDT) Date: Thu, 28 Aug 2003 11:25:46 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Detect block size? Message-ID: <20030828152546.GF16632@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: $Id: Sanitizer.pm,v 1.54 2002/02/15 16:59:07 bre Exp $ X-archive-position: 223 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@dkp.com Precedence: bulk X-list: linux-xfs Content-Length: 112 Lines: 5 Is there any utility I can use to detect the block size of an already created XFS filesystem? Andrew Klaassen From owner-linux-xfs@oss.sgi.com Thu Aug 28 08:41:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 08:41:55 -0700 (PDT) Received: from server4.nfra.nl (fwuser@firebox.nfra.nl [192.87.1.200]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SFfFWZ030229 for ; Thu, 28 Aug 2003 08:41:16 -0700 Received: from wop07.astron.nl (wop07.nfra.nl [195.169.63.27]) by server4.nfra.nl; Thu, 28 Aug 2003 17:41:05 +0200 Date: Thu, 28 Aug 2003 17:41:06 +0200 (CEST) From: K Ramesh To: Nathan Scott cc: Steve Lord , Subject: Re: problems with real-time option. In-Reply-To: <20030826220532.GA769@frodo> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 224 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kram@astron.nl Precedence: bulk X-list: linux-xfs Content-Length: 2241 Lines: 60 Hello, Thanks Nathan, the version of xfsprogs works just fine. I have yet another question on realtime subvolumes: Is XFS realtime subvolume in Linux comparable to "raw" device binding that's avaliable in linux now? Both seem to have the same alignment constraints. Can someone throw light on this issue? Say if I expected only to write data in to the disk, does using raw I/O or realtime subvolumes increases throughput? Regards Ramesh > On Tue, Aug 26, 2003 at 07:10:02AM -0500, Steve Lord wrote: > > On Tue, 2003-08-26 at 05:29, K Ramesh wrote: > > > > > > Hi, > > > I'm trying to create a real-time subvolume in my Linux System, running > > > SuSE 8.1 (Kernel: 2.4.19-64GB-SMP) on a dual-xeon PC. The system has a 3ware > > > ATA-Raid controller. > > > > > > When I try to create a real-time subvolume, this what I get: > > > > > > wop18:~ # mkfs -t xfs -f -r rtdev=/dev/sda6 /dev/sda5 > > > meta-data=/dev/sda5 isize=256 agcount=49, agsize=1048576 blks > > > data = bsize=4096 blocks=51201147, imaxpct=25 > > > = sunit=0 swidth=0 blks, unwritten=0 > > > naming =version 2 bsize=4096 > > > log =internal log bsize=4096 blocks=6250, version=1 > > > = sunit=0 blks > > > realtime =/dev/sda6 extsz=65536 blocks=183237382, > > > rtextents=11452336 > > > XFS: This FS has an RT subvol - specify -o rtdev on mount > > > mkfs.xfs: real-time device init failed > > > mkfs.xfs: filesystem failed to initialize > > Get a new xfsprogs while you're at it, that'll resolve this error. > > > ... > > Your kernel is almost that old ;-) Realtime should be working in recent > > kernels, be aware you need to use O_DIRECT to write to realtime > > subvolumes. > > cheers. > > -- > Nathan > > ************************************************************************** Ramesh K (Mo/Tu): Radiosterrenwacht Westerbork, Schattenburg 1, 9433 TA Zwiggelte. ph: +31-(0)593-598755 fax:+31-(0)593-592486 (We/Th/Fr): Stitching Astron, Oude Hoogeveensedijk 4, 7991 PD Dwingeloo. ph: +31-(0)521-595255 fax:+31-(0)521-597332 ************************************************************************** From owner-linux-xfs@oss.sgi.com Thu Aug 28 09:45:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 09:46:21 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SGjfWZ001689 for ; Thu, 28 Aug 2003 09:45:41 -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 h7SH2LxZ025565 for ; Thu, 28 Aug 2003 12:02:21 -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 h7SGjZCh10879059; Thu, 28 Aug 2003 11:45:35 -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 h7SGjZwh19623952; Thu, 28 Aug 2003 11:45:35 -0500 (CDT) Date: Thu, 28 Aug 2003 11:45:35 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Andrew Klaassen cc: linux-xfs@oss.sgi.com Subject: Re: Detect block size? In-Reply-To: <20030828152546.GF16632@dkp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 225 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 302 Lines: 19 Sure - xfs_info /path/to/mount/point and look for "bsize" in the data section. (if this is on Irix, use xfs_growfs -n) -Eric On Thu, 28 Aug 2003, Andrew Klaassen wrote: > Is there any utility I can use to detect the block size of an > already created XFS filesystem? > > Andrew Klaassen > > From owner-linux-xfs@oss.sgi.com Thu Aug 28 09:57:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 09:57:53 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SGvJWZ002694 for ; Thu, 28 Aug 2003 09:57:20 -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 h7SGvEq0012716 for ; Thu, 28 Aug 2003 09:57:14 -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 h7SGuECh10886543; Thu, 28 Aug 2003 11:56:14 -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 h7SGuERn251104739; Thu, 28 Aug 2003 11:56:14 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h7SGuDe30021; Thu, 28 Aug 2003 11:56:13 -0500 Subject: Re: Detect block size? From: Steve Lord To: Andrew Klaassen Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030828152546.GF16632@dkp.com> References: <20030828152546.GF16632@dkp.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1062089773.22919.1267.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 28 Aug 2003 11:56:13 -0500 X-archive-position: 226 X-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: 375 Lines: 17 On Thu, 2003-08-28 at 10:25, Andrew Klaassen wrote: > Is there any utility I can use to detect the block size of an > already created XFS filesystem? > > Andrew Klaassen xfs_info /mnt where /mnt is where it is mounted. 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 28 10:12:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 10:13:04 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SHCkWZ003933 for ; Thu, 28 Aug 2003 10:12: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 h7SHTQxZ030222 for ; Thu, 28 Aug 2003 12:29:26 -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 h7SHCbCh10925947; Thu, 28 Aug 2003 12:12:37 -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 h7SHCbRn255070756; Thu, 28 Aug 2003 12:12:37 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h7SHCbD30049; Thu, 28 Aug 2003 12:12:37 -0500 Subject: Re: problems with real-time option. From: Steve Lord To: K Ramesh Cc: Nathan Scott , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1062090756.22693.1274.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 28 Aug 2003 12:12:37 -0500 X-archive-position: 227 X-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: 1498 Lines: 37 On Thu, 2003-08-28 at 10:41, K Ramesh wrote: > Hello, > Thanks Nathan, the version of xfsprogs works just fine. I have yet > another question on realtime subvolumes: Is XFS realtime subvolume in Linux > comparable to "raw" device binding that's avaliable in linux now? Both seem to > have the same alignment constraints. Can someone throw light on this issue? > Say if I expected only to write data in to the disk, does using raw I/O > or realtime subvolumes increases throughput? > > Regards > Ramesh > The difference between raw and the realtime subvolume is that with a raw partition you get no naming, and you get one data stream - the device. With realtime, you get similar access rates, but you can use the filesystem to manage naming and placement of multiple streams. An XFS filesystem with a realtime subvolume still has a data subvolume, and this is where ALL the metadata lives, there is nothing on the realtime subvol except for the contents of files. The allocator used to manage the space is wasteful - it basically binary chops the space when laying things out, but this makes it very hard to fragment the files. You also get to use standard utilities to manage files (at least to rename them, remove them, list them, etc). So if you only have one data stream, and one set of data to manage, then raw will be just as good. 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 28 15:22:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 15:23:17 -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.5) with SMTP id h7SMMeWZ028353 for ; Thu, 28 Aug 2003 15:22:41 -0700 Received: (qmail 6322 invoked from network); 28 Aug 2003 22:22:38 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 28 Aug 2003 22:22:38 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 08B78C00A8; Fri, 29 Aug 2003 08:22:32 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 0560E14009F; Fri, 29 Aug 2003 08:22:32 +1000 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Federico Sevilla III Cc: Linux-XFS Mailing List Subject: Re: 2.4.22 in cvs? In-reply-to: Your message of "Thu, 28 Aug 2003 13:33:11 +0800." <20030828053311.GB2510@leathercollection.ph> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Aug 2003 08:22:30 +1000 Message-ID: <22786.1062109350@ocs3.intra.ocs.com.au> X-archive-position: 228 X-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: 719 Lines: 15 On Thu, 28 Aug 2003 13:33:11 +0800, Federico Sevilla III wrote: >I'm curious: will it make sense to release split patches for 2.4.22 like >those available for 2.4.21, even if CVS doesn't have the full 2.4.22-xfs >yet while waiting for the approval due to the crypto merge? Or will >split patches for 2.4.22 require the same approval anyway? Both CVS and the split patches are generated from the SGI internal XFS tree. That tree is still at 2.4.21, I cannot generate split patches for 2.4.22 until there is an official[*] SGI internal version of XFS for 2.4.22. [*] I know about Russell Cattelan's patches for 2.4.22 XFS but AFAIK they have not been blessed by the SGI XFS team. Hint, hint. From owner-linux-xfs@oss.sgi.com Thu Aug 28 15:39:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 15:40:09 -0700 (PDT) Received: from ext-ch1gw-2.online-age.net (ext-ch1gw-2.online-age.net [216.34.191.36]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SMdVWZ030569 for ; Thu, 28 Aug 2003 15:39:32 -0700 Received: from int-ch1gw-4.online-age.net (int-ch1gw-4 [3.159.232.68]) by ext-ch1gw-2.online-age.net (8.12.9/8.12.9/030701) with ESMTP id h7SKpBgX023321; Thu, 28 Aug 2003 16:51:12 -0400 (EDT) Received: from uswaumsxb4medge.med.ge.com (localhost [127.0.0.1]) by int-ch1gw-4.online-age.net (8.12.9/8.12.3/990426-RLH) with ESMTP id h7SKp9dS013764; Thu, 28 Aug 2003 16:51:10 -0400 (EDT) Received: by USWAUMSXB4MEDGE with Internet Mail Service (5.5.2656.59) id ; Thu, 28 Aug 2003 15:50:20 -0500 Received: from ct.ct.med.ge.com ([3.70.56.18]) by uswaumsxbhmedge.med.ge.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RRVB4NAL; Thu, 28 Aug 2003 15:50:57 -0500 Received: from med.ge.com ([3.57.108.2]) by ct.ct.med.ge.com (8.8.8+Sun/8.8.8) with ESMTP id PAA23269; Thu, 28 Aug 2003 15:50:51 -0500 (CDT) From: "Foris, Jim (MED)" Reply-To: "Foris, Jim (MED)" To: Eric Sandeen Cc: Kai Leibrandt , "'Simon Matter'" , "'Axel Thimm'" , linux-xfs@oss.sgi.com Message-ID: <3F4E5AD3.80101@med.ge.com> Date: Thu, 28 Aug 2003 14:41:07 -0500 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: Patch 1300 & rpm issue with 1.3.0 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 229 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: foris@mr.mr.med.ge.com Precedence: bulk X-list: linux-xfs Content-Length: 5195 Lines: 122 Eric Sandeen wrote: > On Thu, 28 Aug 2003, Kai Leibrandt wrote: > > >>That's just what I was thinking; is rpm only an indication that other >>apps might have issues as well? If so, how do we identify them and >>rectify the problems? In the kernel, or in the app? > > > That's not clear to me yet, but we have dome some O_DIRECT stresstesting > and it's all been fine. So this doesn't seem to be a problem with > O_DIRECT in general, which makes me think it might be the app. > Using "strace" on a RH 2.4.20-20.9.XFS1.3.0 system to follow what "rpm" does during an install, the key difference seems to be the following sequence: WORKS (created a EXT3 partition, copied /var/lib/rpm/* to it, then mounted it at /var/lib/rpm) 4217 access("/var/lib/rpm", W_OK) = 0 <0.000011> 4217 access("/var/lib/rpm/__db.001", F_OK) = -1 ENOENT (No such file or directory) <0.000011> 4217 access("/var/lib/rpm/Packages", F_OK) = 0 <0.000011> 4217 stat64("/var/lib/rpm/DB_CONFIG", 0xbffeeb60) = -1 ENOENT (No such file or directory) <0.000019> 4217 brk(0) = 0x807e000 <0.000006> 4217 brk(0x807f000) = 0x807f000 <0.000008> 4217 open("/var/lib/rpm/DB_CONFIG", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) <0.000011> 4217 stat64("/var/lib/rpm/__db.001", 0xbffeeb90) = -1 ENOENT (No such file or directory) <0.000010> 4217 open("/var/lib/rpm/__db.001", O_RDWR|O_CREAT|O_EXCL|O_DIRECT|O_LARGEFILE, 0644) = 4 <0.000044> 4217 fcntl64(4, F_SETFD, FD_CLOEXEC) = 0 <0.000007> 4217 open("/var/lib/rpm/__db.001", O_RDWR|O_CREAT|O_DIRECT|O_LARGEFILE, 0644) = 5 <0.000011> 4217 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 <0.000006> 4217 _llseek(5, 0, [0], SEEK_END) = 0 <0.000006> 4217 _llseek(5, 8192, [8192], SEEK_CUR) = 0 <0.000007> 4217 write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192 <0.000137> 4217 mmap2(NULL, 16384, PROT_READ|PROT_WRITE, MAP_SHARED, 5, 0) = 0x40019000 <0.000011> 4217 close(5) = 0 <0.000007> FAILS (/var/lib/rpm resides on a XFS partition) 4144 access("/var/lib/rpm/__db.001", F_OK) = -1 ENOENT (No such file or directory) <0.000010> 4144 access("/var/lib/rpm/Packages", F_OK) = 0 <0.000011> 4144 stat64("/var/lib/rpm/DB_CONFIG", 0xbffef0e0) = -1 ENOENT (No such file or directory) <0.000010> 4144 brk(0) = 0x807e000 <0.000006> 4144 brk(0x807f000) = 0x807f000 <0.000008> 4144 open("/var/lib/rpm/DB_CONFIG", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) <0.000012> 4144 stat64("/var/lib/rpm/__db.001", 0xbffef110) = -1 ENOENT (No such file or directory) <0.000010> 4144 open("/var/lib/rpm/__db.001", O_RDWR|O_CREAT|O_EXCL|O_DIRECT|O_LARGEFILE, 0644) = 4 <0.000103> 4144 fcntl64(4, F_SETFD, FD_CLOEXEC) = 0 <0.000006> 4144 open("/var/lib/rpm/__db.001", O_RDWR|O_CREAT|O_DIRECT|O_LARGEFILE, 0644) = 5 <0.000012> 4144 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 <0.000006> 4144 _llseek(5, 0, [0], SEEK_END) = 0 <0.000006> 4144 _llseek(5, 8192, [8192], SEEK_CUR) = 0 <0.000006> 4144 write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = -1 EINVAL (Invalid argument) <0.000007> 4144 open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000016> 4144 open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000011> 4144 open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000013> 4144 open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000011> 4144 open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000010> 4144 open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000013> 4144 write(2, "rpmdb: ", 7) = 7 <0.000017> 4144 write(2, "write: 0xbffed120, 8192: Invalid"..., 41) = 41 <0.000012> 4144 write(2, "\n", 1) = 1 <0.000012> 4144 close(5) = 0 <0.000008> From the RPM 4.2 source, the file "__db.001" contains database environment information and is used also used to syncronize between multiple threads/processes. But the details of how/why "rpm" uses this file is not as significant as the different behavior shown in the example above: There is a difference in behavior between XFS and EXT3 with how sparse files are created/handled. From the above example it looks like XFS+O_DIRECT+sparse file creation is broken/not supported. (Things work if LD_ASSUME_KERNEL is set because then "rpm" uses a different method to control its database accesses..... it never runs through the above offending code. Although it finds that __db.001 is not there, it does not try to create it.) Does this ring any bells with anyone ? On the bright side, it DOES look like it is an application-specific combination of factors that cause the failure..... so the problem is not likely to be widely seen. Jim Foris > -Eric > > From owner-linux-xfs@oss.sgi.com Thu Aug 28 15:52:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 15:52:24 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SMq8WZ032240 for ; Thu, 28 Aug 2003 15:52: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 h7SMq1q0007503 for ; Thu, 28 Aug 2003 15:52: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 h7SMq0Ch10953255; Thu, 28 Aug 2003 17:52:00 -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 h7SMpoRn253853493; Thu, 28 Aug 2003 17:51:55 -0500 (CDT) Subject: Re: Patch 1300 & rpm issue with 1.3.0 From: Russell Cattelan To: "Foris, Jim (MED)" Cc: Eric Sandeen , Kai Leibrandt , "'Simon Matter'" , "'Axel Thimm'" , linux-xfs@oss.sgi.com In-Reply-To: <3F4E5AD3.80101@med.ge.com> References: <3F4E5AD3.80101@med.ge.com> Content-Type: text/plain Message-Id: <1062111109.4318.6.camel@naboo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4-2mdk Date: Thu, 28 Aug 2003 17:51:50 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 230 X-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: 5919 Lines: 137 On Thu, 2003-08-28 at 14:41, Foris, Jim (MED) wrote: > Eric Sandeen wrote: > > On Thu, 28 Aug 2003, Kai Leibrandt wrote: > > > > > >>That's just what I was thinking; is rpm only an indication that other > >>apps might have issues as well? If so, how do we identify them and > >>rectify the problems? In the kernel, or in the app? > > > > > > That's not clear to me yet, but we have dome some O_DIRECT stresstesting > > and it's all been fine. So this doesn't seem to be a problem with > > O_DIRECT in general, which makes me think it might be the app. > > > > Using "strace" on a RH 2.4.20-20.9.XFS1.3.0 system to follow what "rpm" does > during an install, the key difference seems to be the following sequence: > > WORKS (created a EXT3 partition, copied /var/lib/rpm/* to it, then mounted it at > /var/lib/rpm) I this ext2 or ext3? ext2 will turn off O_DIRECT after the open call ext3 was suppose to, eric has a new patch to fix that. > > 4217 access("/var/lib/rpm", W_OK) = 0 <0.000011> > 4217 access("/var/lib/rpm/__db.001", F_OK) = -1 ENOENT (No such file or > directory) <0.000011> > 4217 access("/var/lib/rpm/Packages", F_OK) = 0 <0.000011> > 4217 stat64("/var/lib/rpm/DB_CONFIG", 0xbffeeb60) = -1 ENOENT (No such file or > directory) <0.000019> > 4217 brk(0) = 0x807e000 <0.000006> > 4217 brk(0x807f000) = 0x807f000 <0.000008> > 4217 open("/var/lib/rpm/DB_CONFIG", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such > file or directory) <0.000011> > 4217 stat64("/var/lib/rpm/__db.001", 0xbffeeb90) = -1 ENOENT (No such file or > directory) <0.000010> > 4217 open("/var/lib/rpm/__db.001", O_RDWR|O_CREAT|O_EXCL|O_DIRECT|O_LARGEFILE, > 0644) = 4 <0.000044> > 4217 fcntl64(4, F_SETFD, FD_CLOEXEC) = 0 <0.000007> > 4217 open("/var/lib/rpm/__db.001", O_RDWR|O_CREAT|O_DIRECT|O_LARGEFILE, 0644) = > 5 <0.000011> > 4217 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 <0.000006> > 4217 _llseek(5, 0, [0], SEEK_END) = 0 <0.000006> > 4217 _llseek(5, 8192, [8192], SEEK_CUR) = 0 <0.000007> > 4217 write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., > 8192) = 8192 <0.000137> > 4217 mmap2(NULL, 16384, PROT_READ|PROT_WRITE, MAP_SHARED, 5, 0) = 0x40019000 > <0.000011> > 4217 close(5) = 0 <0.000007> > > > FAILS (/var/lib/rpm resides on a XFS partition) XFS does not turn of O_DIRECT ... that is the point of this. It appears db4 is breaking some O_DIRECT rule that is causing it to fail. fsx with directio support runs just fine on this kernel on and xfs partition doing all sorts of things strange things to a file including creating lots of holes. > > 4144 access("/var/lib/rpm/__db.001", F_OK) = -1 ENOENT (No such file or > directory) <0.000010> > 4144 access("/var/lib/rpm/Packages", F_OK) = 0 <0.000011> > 4144 stat64("/var/lib/rpm/DB_CONFIG", 0xbffef0e0) = -1 ENOENT (No such file or > directory) <0.000010> > 4144 brk(0) = 0x807e000 <0.000006> > 4144 brk(0x807f000) = 0x807f000 <0.000008> > 4144 open("/var/lib/rpm/DB_CONFIG", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such > file or directory) <0.000012> > 4144 stat64("/var/lib/rpm/__db.001", 0xbffef110) = -1 ENOENT (No such file or > directory) <0.000010> > 4144 open("/var/lib/rpm/__db.001", O_RDWR|O_CREAT|O_EXCL|O_DIRECT|O_LARGEFILE, > 0644) = 4 <0.000103> > 4144 fcntl64(4, F_SETFD, FD_CLOEXEC) = 0 <0.000006> > 4144 open("/var/lib/rpm/__db.001", O_RDWR|O_CREAT|O_DIRECT|O_LARGEFILE, 0644) = > 5 <0.000012> > 4144 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 <0.000006> > 4144 _llseek(5, 0, [0], SEEK_END) = 0 <0.000006> > 4144 _llseek(5, 8192, [8192], SEEK_CUR) = 0 <0.000006> > 4144 write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., > 8192) = -1 EINVAL (Invalid argument) <0.000007> > 4144 open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 > ENOENT (No such file or directory) <0.000016> > 4144 open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 > ENOENT (No such file or directory) <0.000011> > 4144 open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT > (No such file or directory) <0.000013> > 4144 open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 > ENOENT (No such file or directory) <0.000011> > 4144 open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 > ENOENT (No such file or directory) <0.000010> > 4144 open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No > such file or directory) <0.000013> > 4144 write(2, "rpmdb: ", 7) = 7 <0.000017> > 4144 write(2, "write: 0xbffed120, 8192: Invalid"..., 41) = 41 <0.000012> > 4144 write(2, "\n", 1) = 1 <0.000012> > 4144 close(5) = 0 <0.000008> > > > From the RPM 4.2 source, the file "__db.001" contains database environment > information and is used also > used to syncronize between multiple threads/processes. But the details of > how/why "rpm" uses this file > is not as significant as the different behavior shown in the example above: > There is a difference > in behavior between XFS and EXT3 with how sparse files are created/handled. > From the above example > it looks like XFS+O_DIRECT+sparse file creation is broken/not supported. > > (Things work if LD_ASSUME_KERNEL is set because then "rpm" uses a different > method to control > its database accesses..... it never runs through the above offending code. > Although it finds that __db.001 > is not there, it does not try to create it.) > > Does this ring any bells with anyone ? > > On the bright side, it DOES look like it is an application-specific combination > of factors that cause > the failure..... so the problem is not likely to be widely seen. > > Jim Foris > > > > > > > > > -Eric > > > > > From owner-linux-xfs@oss.sgi.com Thu Aug 28 15:54:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 15:54:40 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SMsbWZ000329 for ; Thu, 28 Aug 2003 15:54:37 -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 h7SMsWq0007716 for ; Thu, 28 Aug 2003 15:54:32 -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 h7SMsNCh10942311; Thu, 28 Aug 2003 17:54:23 -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 h7SMsORn246646070; Thu, 28 Aug 2003 17:54:24 -0500 (CDT) Subject: Re: 2.4.22 in cvs? From: Russell Cattelan To: Keith Owens Cc: Federico Sevilla III , Linux-XFS Mailing List In-Reply-To: <22786.1062109350@ocs3.intra.ocs.com.au> References: <22786.1062109350@ocs3.intra.ocs.com.au> Content-Type: text/plain Message-Id: <1062111262.6301.10.camel@naboo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4-2mdk Date: Thu, 28 Aug 2003 17:54:23 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 231 X-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: 1084 Lines: 24 On Thu, 2003-08-28 at 17:22, Keith Owens wrote: > On Thu, 28 Aug 2003 13:33:11 +0800, > Federico Sevilla III wrote: > >I'm curious: will it make sense to release split patches for 2.4.22 like > >those available for 2.4.21, even if CVS doesn't have the full 2.4.22-xfs > >yet while waiting for the approval due to the crypto merge? Or will > >split patches for 2.4.22 require the same approval anyway? > > Both CVS and the split patches are generated from the SGI internal XFS > tree. That tree is still at 2.4.21, I cannot generate split patches > for 2.4.22 until there is an official[*] SGI internal version of XFS > for 2.4.22. > > [*] I know about Russell Cattelan's patches for 2.4.22 XFS but AFAIK > they have not been blessed by the SGI XFS team. Hint, hint. What I'm still part of the XFS team, well for another month anyways. :-) There has been some question of the directio support in 2.4.22 but it involved parallel access to the same file via different threads, at this point it has not proved to be broken just not as fast as it could be. From owner-linux-xfs@oss.sgi.com Thu Aug 28 16:02:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 16:02:33 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SN1xWZ001153 for ; Thu, 28 Aug 2003 16:01:59 -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 h7SN1rq0008642 for ; Thu, 28 Aug 2003 16:01:53 -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 h7SN1kmb010590; Fri, 29 Aug 2003 09:01:47 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h7SN1kc0010589; Fri, 29 Aug 2003 09:01:46 +1000 Date: Fri, 29 Aug 2003 09:01:46 +1000 From: Nathan Scott Message-Id: <200308282301.h7SN1kc0010589@bruce.melbourne.sgi.com> Subject: TAKE - acl/attr fix X-archive-position: 232 X-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: 536 Lines: 20 attr/acl nftw error handling fix from AndreasG. Date: Thu Aug 28 15:59: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:157519a cmd/acl/VERSION - 1.56 cmd/acl/doc/CHANGES - 1.64 cmd/acl/debian/changelog - 1.50 cmd/attr/VERSION - 1.39 cmd/attr/doc/CHANGES - 1.48 cmd/attr/debian/changelog - 1.42 cmd/attr/getfattr/getfattr.c - 1.22 cmd/acl/setfacl/setfacl.c - 1.11 cmd/acl/getfacl/getfacl.c - 1.13 From owner-linux-xfs@oss.sgi.com Thu Aug 28 17:01:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 17:01:50 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7T01BWZ005213 for ; Thu, 28 Aug 2003 17:01:12 -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 h7T014q0017336 for ; Thu, 28 Aug 2003 17:01:05 -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 KAA14512; Fri, 29 Aug 2003 10:01:03 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 34357C00A8; Fri, 29 Aug 2003 10:00:59 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 2FDB11400A8; Fri, 29 Aug 2003 10:00:59 +1000 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Russell Cattelan Cc: Linux-XFS Mailing List Subject: Re: 2.4.22 in cvs? In-reply-to: Your message of "Thu, 28 Aug 2003 17:54:23 EST." <1062111262.6301.10.camel@naboo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Aug 2003 10:00:58 +1000 Message-ID: <2751.1062115258@kao2.melbourne.sgi.com> X-archive-position: 233 X-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: 1155 Lines: 26 On Thu, 28 Aug 2003 17:54:23 -0500, Russell Cattelan wrote: >On Thu, 2003-08-28 at 17:22, Keith Owens wrote: >> Both CVS and the split patches are generated from the SGI internal XFS >> tree. That tree is still at 2.4.21, I cannot generate split patches >> for 2.4.22 until there is an official[*] SGI internal version of XFS >> for 2.4.22. >> >> [*] I know about Russell Cattelan's patches for 2.4.22 XFS but AFAIK >> they have not been blessed by the SGI XFS team. Hint, hint. >What I'm still part of the XFS team, well for another month anyways. :-) > >There has been some question of the directio support in 2.4.22 but it >involved parallel access to the same file via different threads, >at this point it has not proved to be broken just not as fast as it >could be. I am happy to generate split patches for 2.4.22 against Russell's patches, being very careful to mark them as unofficial 2.4.22 patches. With one proviso, that the code actually works. I have not run any QA tests on Russell's patches. If any of the SGI XFS team tell me that these patches pass QA then I will generate unofficial 2.4.22 split patches. From owner-linux-xfs@oss.sgi.com Thu Aug 28 17:06:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 17:06:45 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7T06UWZ006205 for ; Thu, 28 Aug 2003 17:06: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 h7T06Oq0017973 for ; Thu, 28 Aug 2003 17:06: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 h7T06OCh10983870; Thu, 28 Aug 2003 19:06:24 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-57.corp.sgi.com [134.15.64.57]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h7T06GRn213203366; Thu, 28 Aug 2003 19:06:17 -0500 (CDT) Subject: Re: Patch 1300 & rpm issue with 1.3.0 From: Steve Lord To: Russell Cattelan Cc: "Foris, Jim (MED)" , Eric Sandeen , Kai Leibrandt , "'Simon Matter'" , "'Axel Thimm'" , linux-xfs@oss.sgi.com In-Reply-To: <1062111109.4318.6.camel@naboo> References: <3F4E5AD3.80101@med.ge.com> <1062111109.4318.6.camel@naboo> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 28 Aug 2003 19:06:15 -0500 Message-Id: <1062115583.1695.25.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 234 X-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: 1323 Lines: 33 On Thu, 2003-08-28 at 17:51, Russell Cattelan wrote: > On Thu, 2003-08-28 at 14:41, Foris, Jim (MED) wrote: > > Eric Sandeen wrote: > > > On Thu, 28 Aug 2003, Kai Leibrandt wrote: > > > > > > > > >>That's just what I was thinking; is rpm only an indication that other > > >>apps might have issues as well? If so, how do we identify them and > > >>rectify the problems? In the kernel, or in the app? > > > > > > > > > That's not clear to me yet, but we have dome some O_DIRECT stresstesting > > > and it's all been fine. So this doesn't seem to be a problem with > > > O_DIRECT in general, which makes me think it might be the app. > > > > > > > Using "strace" on a RH 2.4.20-20.9.XFS1.3.0 system to follow what "rpm" does > > during an install, the key difference seems to be the following sequence: > > > > WORKS (created a EXT3 partition, copied /var/lib/rpm/* to it, then mounted it at > > /var/lib/rpm) > I this ext2 or ext3? > ext2 will turn off O_DIRECT after the open call > ext3 was suppose to, eric has a new patch to fix that. This looks like memory alignment of the write buffer. The alignment of the memory may be constrained differently, possibly ext3 is not doing O_DIRECT so is not constraining I/O alignment. It would be good to see the address of the buffer passed into the write call. Steve From owner-linux-xfs@oss.sgi.com Thu Aug 28 21:26:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 21:27:30 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7T4QvWZ020124 for ; Thu, 28 Aug 2003 21:26:57 -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 h7T4hbxZ032217 for ; Thu, 28 Aug 2003 23:43:38 -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 h7T4Qh8h029586 for ; Fri, 29 Aug 2003 14:26:43 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h7T4Qh8o029585 for linux-xfs@oss.sgi.com; Fri, 29 Aug 2003 14:26:43 +1000 Date: Fri, 29 Aug 2003 14:26:43 +1000 From: Nathan Scott Message-Id: <200308290426.h7T4Qh8o029585@bruce.melbourne.sgi.com> Subject: TAKE acl-out-of-space fix reworked X-archive-position: 235 X-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: 408 Lines: 15 Alternate, cleaner fix for the ENOSPC/ACL lookup problem. Date: Thu Aug 28 21:24:27 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:157531a linux/fs/xfs/Makefile - 1.51 linux/fs/xfs/xfs_da_btree.c - 1.146 linux/fs/xfs/xfs_da_btree.h - 1.56 linux/fs/xfs/xfs_attr.c - 1.109 From owner-linux-xfs@oss.sgi.com Thu Aug 28 21:44:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 21:44:47 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7T4iDWZ021361 for ; Thu, 28 Aug 2003 21:44:13 -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 h7T50rxZ008933 for ; Fri, 29 Aug 2003 00:00:54 -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 h7T4hx8h002608 for ; Fri, 29 Aug 2003 14:43:59 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h7T4hxbA002565 for linux-xfs@oss.sgi.com; Fri, 29 Aug 2003 14:43:59 +1000 Date: Fri, 29 Aug 2003 14:43:59 +1000 From: Nathan Scott Message-Id: <200308290443.h7T4hxbA002565@bruce.melbourne.sgi.com> Subject: TAKE - autosize logbsize for v2 logs X-archive-position: 236 X-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: 723 Lines: 27 Remove xfs_attr_fetch.c - the one routine was a copy of another, so instead of fixing a bug in two places I merged the two routines and this file is now redundant. Date: Thu Aug 28 21:35:36 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:157533a linux/fs/xfs/xfs_attr_fetch.c - 1.17 Automatically set logbsize for larger stripe units Date: Thu Aug 28 21:39: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:157534a linux/fs/xfs/xfs_vfsops.c - 1.429 From owner-linux-xfs@oss.sgi.com Thu Aug 28 22:52:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 22:52:56 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7T5qLWZ025972 for ; Thu, 28 Aug 2003 22:52:23 -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 h7T690xZ010572 for ; Fri, 29 Aug 2003 01:09:02 -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 h7T5q48h007232 for ; Fri, 29 Aug 2003 15:52:04 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h7T5q4h5007231 for linux-xfs@oss.sgi.com; Fri, 29 Aug 2003 15:52:04 +1000 Date: Fri, 29 Aug 2003 15:52:04 +1000 From: Nathan Scott Message-Id: <200308290552.h7T5q4h5007231@bruce.melbourne.sgi.com> Subject: TAKE - minor xfsprogs update X-archive-position: 237 X-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: 1187 Lines: 38 Date: Thu Aug 28 22:50:07 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:157536a cmd/xfsprogs/db/xfs_check64.sh - 1.9 cmd/xfsprogs/db/xfs_check.sh - 1.9 cmd/xfsprogs/db/check.c - 1.17 cmd/xfsprogs/repair/globals.h - 1.10 cmd/xfsprogs/repair/xfs_repair.c - 1.14 - Add a "test" option for large filesystem testing. cmd/xfsprogs/VERSION - 1.87 cmd/xfsprogs/doc/CHANGES - 1.125 cmd/xfsprogs/debian/changelog - 1.80 - Bump version - minor update. cmd/xfsprogs/include/xfs_log.h - 1.16 cmd/xfsprogs/include/xfs_da_btree.h - 1.15 cmd/xfsprogs/include/xfs_dir2_leaf.h - 1.9 cmd/xfsprogs/libxfs/xfs_da_btree.c - 1.22 cmd/xfsprogs/libxfs/xfs_dir.c - 1.14 cmd/xfsprogs/libxfs/xfs_bmap_btree.c - 1.17 cmd/xfsprogs/libxfs/xfs_inode.c - 1.25 cmd/xfsprogs/libxfs/xfs_alloc.c - 1.20 cmd/xfsprogs/libxfs/xfs_bmap.c - 1.22 cmd/xfsprogs/libxfs/xfs_alloc_btree.c - 1.11 cmd/xfsprogs/libxfs/xfs_dir2.c - 1.14 - Sync with recent changes in the kernel code. cmd/xfsprogs/copy/xfs_copy.c - 1.5 - Make it a bit more portable, still some work here though (pthreads). From owner-linux-xfs@oss.sgi.com Thu Aug 28 22:58:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 22:58:32 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7T5vxWZ026698 for ; Thu, 28 Aug 2003 22:58:00 -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 h7T5vrq0008829 for ; Thu, 28 Aug 2003 22:57:54 -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 PAA17942 for ; Fri, 29 Aug 2003 15:56:37 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 7CAC4C00A8; Fri, 29 Aug 2003 15:56:33 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 796571400AA for ; Fri, 29 Aug 2003 15:56:33 +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: Fri, 29 Aug 2003 15:56:32 +1000 Message-ID: <9497.1062136592@kao2.melbourne.sgi.com> X-archive-position: 238 X-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-29_05:36_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 Thu Aug 28 23:07:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Aug 2003 23:07:52 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7T67CWZ027627 for ; Thu, 28 Aug 2003 23:07:12 -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 h7T676q0010607 for ; Thu, 28 Aug 2003 23:07:06 -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 h7T66x8h013403 for ; Fri, 29 Aug 2003 16:06:59 +1000 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h7T66w81013395 for linux-xfs@oss.sgi.com; Fri, 29 Aug 2003 16:06:58 +1000 Date: Fri, 29 Aug 2003 16:06:58 +1000 From: FSG QA Message-Id: <200308290606.h7T66w81013395@bruce.melbourne.sgi.com> Subject: TAKE - xfstests update X-archive-position: 239 X-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: 1667 Lines: 66 Fix fdblocks accounting, need to consider cleared agfl blocks too; add shortcut (-c) to clear all but the last AG. Date: Thu Aug 28 17:36:39 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:157524a cmd/xfstests/tools/ag-wipe - 1.2 Rework test 018 slightly so that its more user friendly when it fails. Date: Thu Aug 28 17:40:24 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:157525a cmd/xfstests/018.out - 1.1 cmd/xfstests/018 - 1.21 cmd/xfstests/018.ugquota - 1.4 cmd/xfstests/018.usrquota - 1.6 cmd/xfstests/018.grpquota - 1.4 cmd/xfstests/018.noquota - 1.5 Report platform details in the bench script output as well. Date: Thu Aug 28 17:41:36 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:157526a cmd/xfstests/bench - 1.21 QA updates to enable simplified large filesystem testing. Date: Thu Aug 28 23:04:54 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:157537a cmd/xfstests/common.rc - 1.30 cmd/xfstests/017 - 1.12 cmd/xfstests/030 - 1.10 cmd/xfstests/031 - 1.12 cmd/xfstests/032 - 1.10 cmd/xfstests/033 - 1.13 cmd/xfstests/049 - 1.12 cmd/xfstests/tools/auto-qa - 1.42 cmd/xfstests/setup - 1.4 cmd/xfstests/075 - 1.3 From owner-linux-xfs@oss.sgi.com Fri Aug 29 06:07:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Aug 2003 06:08:33 -0700 (PDT) Received: from ext-nj2gw-3.online-age.net (ext-nj2gw-3.online-age.net [216.35.73.165]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TD7oWZ022703 for ; Fri, 29 Aug 2003 06:07:51 -0700 Received: from int-nj2gw-3.online-age.net (int-nj2gw-3 [3.159.236.67]) by ext-nj2gw-3.online-age.net (8.12.9/8.12.8/990426-RLH) with ESMTP id h7TD7Ute020712; Fri, 29 Aug 2003 09:07:30 -0400 (EDT) Received: from uswaumsxb4medge.med.ge.com (localhost [127.0.0.1]) by int-nj2gw-3.online-age.net (8.12.9/8.12.8/990426-RLH) with ESMTP id h7TD7J6w004631; Fri, 29 Aug 2003 09:07:20 -0400 (EDT) Received: by USWAUMSXB4MEDGE with Internet Mail Service (5.5.2656.59) id ; Fri, 29 Aug 2003 08:06:30 -0500 Received: from ct.ct.med.ge.com ([3.70.56.18]) by uswaumsxbhmedge.med.ge.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RRVB5J38; Fri, 29 Aug 2003 08:07:07 -0500 Received: from med.ge.com ([3.57.108.2]) by ct.ct.med.ge.com (8.8.8+Sun/8.8.8) with ESMTP id IAA04838; Fri, 29 Aug 2003 08:07:01 -0500 (CDT) From: "Foris, Jim (MED)" Reply-To: "Foris, Jim (MED)" To: Steve Lord Cc: Russell Cattelan , "Foris, Jim (MED)" , Eric Sandeen , Kai Leibrandt , "'Simon Matter'" , "'Axel Thimm'" , linux-xfs@oss.sgi.com Message-ID: <3F4F3F97.9010701@med.ge.com> Date: Fri, 29 Aug 2003 06:57:11 -0500 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: Patch 1300 & rpm issue with 1.3.0 References: <3F4E5AD3.80101@med.ge.com> <1062111109.4318.6.camel@naboo> <1062115583.1695.25.camel@laptop.americas.sgi.com> In-Reply-To: <1062115583.1695.25.camel@laptop.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 241 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: foris@mr.mr.med.ge.com Precedence: bulk X-list: linux-xfs Content-Length: 2613 Lines: 78 Steve Lord wrote: > On Thu, 2003-08-28 at 17:51, Russell Cattelan wrote: > >>On Thu, 2003-08-28 at 14:41, Foris, Jim (MED) wrote: >> >>>Eric Sandeen wrote: >>> >>>>On Thu, 28 Aug 2003, Kai Leibrandt wrote: >>>> >>>> >>>> >>>>>That's just what I was thinking; is rpm only an indication that other >>>>>apps might have issues as well? If so, how do we identify them and >>>>>rectify the problems? In the kernel, or in the app? >>>> >>>> >>>>That's not clear to me yet, but we have dome some O_DIRECT stresstesting >>>>and it's all been fine. So this doesn't seem to be a problem with >>>>O_DIRECT in general, which makes me think it might be the app. >>>> >>> >>>Using "strace" on a RH 2.4.20-20.9.XFS1.3.0 system to follow what "rpm" does >>>during an install, the key difference seems to be the following sequence: >>> >>>WORKS (created a EXT3 partition, copied /var/lib/rpm/* to it, then mounted it at >>>/var/lib/rpm) >> >>I this ext2 or ext3? >>ext2 will turn off O_DIRECT after the open call >>ext3 was suppose to, eric has a new patch to fix that. As stated above, it was EXT3 (I forgot to mention that Eric's patch had been applied :-) ). > > > This looks like memory alignment of the write buffer. The alignment of > the memory may be constrained differently, possibly ext3 is not doing > O_DIRECT so is not constraining I/O alignment. It would be good to see > the address of the buffer passed into the write call. Turns out that information is in my original posting: 4144 write(2, "write: 0xbffed120, 8192: Invalid"..., 41) = 41 <0.000012> So the buffer address, 0xbffed120, is NOT correctly alligned. AND THE MYSTERY IS SOLVED; RPM fails because the person who tried to use O_DIRECT file access to an internal database file did not check for/guarantee correct buffer address alignment. This bug did not show up to Red Hat because they never tested it (RPM) on a file system that actually supports O_DIRECT (because they don't have any). The options to solve the problem become clear: 1. Build the kernel w/o O_DIRECT support (leave in patch 1300). 2. Build a kernel with Erics patch and always have "/var/lib/rpm" reside on a non-XFS partition. 3. Put LD_ASSUME_KERNEL into the environment when any "rpm" call is made. 4. Fix "rpm-4.2" (either by removing the ability to set O_DIRECT , or by adding the necessary buffer boundry checks). Personally, I think I will probably patch "rpm-4.2" since that is where the bug is. Thanks to everyone, Jim Foris (And, by the way, there is no use of O_DIRECT in the db-4 code. This is a pure RPM bug). > > Steve > > > From owner-linux-xfs@oss.sgi.com Fri Aug 29 07:02:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Aug 2003 07:02:55 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TE2eWZ025765 for ; Fri, 29 Aug 2003 07:02:40 -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 h7TE2Yq0031000 for ; Fri, 29 Aug 2003 07:02:34 -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 h7TE1mCh11215874; Fri, 29 Aug 2003 09:01:49 -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 h7TE1mRn220326413; Fri, 29 Aug 2003 09:01:48 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h7TE1ml32721; Fri, 29 Aug 2003 09:01:48 -0500 Subject: Re: Patch 1300 & rpm issue with 1.3.0 From: Steve Lord To: "Foris, Jim (MED)" Cc: Russell Cattelan , "Foris, Jim (MED)" , Eric Sandeen , Kai Leibrandt , "'Simon Matter'" , "'Axel Thimm'" , linux-xfs@oss.sgi.com In-Reply-To: <3F4F3F97.9010701@med.ge.com> References: <3F4E5AD3.80101@med.ge.com> <1062111109.4318.6.camel@naboo> <1062115583.1695.25.camel@laptop.americas.sgi.com> <3F4F3F97.9010701@med.ge.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1062165707.22918.1292.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 29 Aug 2003 09:01:47 -0500 X-archive-position: 242 X-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: 831 Lines: 28 On Fri, 2003-08-29 at 06:57, Foris, Jim (MED) wrote: > > Turns out that information is in my original posting: > > 4144 write(2, "write: 0xbffed120, 8192: Invalid"..., 41) = 41 <0.000012> > > So the buffer address, 0xbffed120, is NOT correctly alligned. > > > AND THE MYSTERY IS SOLVED; RPM fails because the person who tried to use > O_DIRECT file access to an internal database file did not check for/guarantee > correct buffer address alignment. This bug did not show up to Red Hat because > they never tested it (RPM) on a file system that actually supports O_DIRECT > (because they don't have any). > Can someone bug ;-) redhat about this one then? 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 29 09:22:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Aug 2003 09:23:18 -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.5) with SMTP id h7TGMYWZ002780 for ; Fri, 29 Aug 2003 09:22:35 -0700 Received: from puariko.homeip.net (r10acci-a15-245.acci.gr [195.170.15.245]) by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id h7TGLvq2023150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Aug 2003 18:22:11 +0200 Received: (from thimm@localhost) by pua.nirvana (8.12.9/8.12.9/Submit) id h7TGLTrl003142; Fri, 29 Aug 2003 19:21:29 +0300 Date: Fri, 29 Aug 2003 19:21:28 +0300 From: Axel Thimm To: Steve Lord Cc: "Foris, Jim (MED)" , Russell Cattelan , "Foris, Jim (MED)" , Eric Sandeen , Kai Leibrandt , "'Simon Matter'" , linux-xfs@oss.sgi.com Subject: Re: Patch 1300 & rpm issue with 1.3.0 Message-ID: <20030829162128.GA3125@pua.nirvana> References: <3F4E5AD3.80101@med.ge.com> <1062111109.4318.6.camel@naboo> <1062115583.1695.25.camel@laptop.americas.sgi.com> <3F4F3F97.9010701@med.ge.com> <1062165707.22918.1292.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: <1062165707.22918.1292.camel@jen.americas.sgi.com> User-Agent: Mutt/1.4.1i X-archive-position: 243 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1503 Lines: 51 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 29, 2003 at 09:01:47AM -0500, Steve Lord wrote: > On Fri, 2003-08-29 at 06:57, Foris, Jim (MED) wrote: >=20 > >=20 > > Turns out that information is in my original posting: > >=20 > > 4144 write(2, "write: 0xbffed120, 8192: Invalid"..., 41) =3D 41 <= 0.000012> > >=20 > > So the buffer address, 0xbffed120, is NOT correctly alligned. > >=20 > >=20 > > AND THE MYSTERY IS SOLVED; RPM fails because the person who tried to use > > O_DIRECT file access to an internal database file did not check for/gua= rantee > > correct buffer address alignment. This bug did not show up to Red Hat = because > > they never tested it (RPM) on a file system that actually supports O_DI= RECT > > (because they don't have any). > >=20 >=20 > Can someone bug ;-) redhat about this one then? Already known problem there. Solution is to hack out O_DIRECT support in rpm in the specfile. Unfortunately this leaves the tarball itself with the buggy O_DIRECT calls in place. See a forward from the rpm-list to this list in a minute. --=20 Axel.Thimm@physik.fu-berlin.de --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/T32IQBVS1GOamfERAhzlAJ9HYLJr5WT8eCsbL1MFEk/EB6naTwCggrGH wyqmgxdCG+Ykf1lUpXb3zO0= =P02n -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From owner-linux-xfs@oss.sgi.com Fri Aug 29 09:30:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Aug 2003 09:30:53 -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.5) with SMTP id h7TGUHWZ004153 for ; Fri, 29 Aug 2003 09:30:17 -0700 Received: from puariko.homeip.net (r10acci-a15-245.acci.gr [195.170.15.245]) by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id h7TGTXq2017023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Aug 2003 18:29:42 +0200 Received: (from thimm@localhost) by pua.nirvana (8.12.9/8.12.9/Submit) id h7TGTT2u003153; Fri, 29 Aug 2003 19:29:29 +0300 Date: Fri, 29 Aug 2003 19:29:28 +0300 From: Axel Thimm To: Jeff Johnson Cc: linux-xfs@oss.sgi.com Subject: O_DIRECT & rpm (for xfs) Message-ID: <20030829162928.GB2911@pua.nirvana> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oTHb8nViIGeoXxdp" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 244 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 7192 Lines: 194 --oTHb8nViIGeoXxdp Content-Type: multipart/mixed; boundary="QTprm0S8XgL7H0Dt" Content-Disposition: inline --QTprm0S8XgL7H0Dt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Jeff, thanks for the background on the O_DIRECT problem. As I wrote, there is some active discussion on the xfs-list about how to deal with O_DIRECT/ext3/xfs/rpm, and your explanation will be very valuable to the XFS community, especially since it comes from the rpm master himself :) For your background: The hanging of rpm with recent XFS patches due to enabled O_DIRECT support generated some confusion about where this bug came from. Current XFS policy is to enable O_DIRECT only for XFS partitions. Thanks! --=20 Axel.Thimm@physik.fu-berlin.de --QTprm0S8XgL7H0Dt Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from hormel.redhat.com (hormel.redhat.com [66.187.233.30]) by up.physik.fu-berlin.de (8.9.3/8.9.1) with ESMTP id PAA988045 for ; Fri, 29 Aug 2003 15:30:26 +0200 (CEST) X-Envelope-From: rpm-list-admin@redhat.com X-Envelope-To: Received: from listman.back-rdu.redhat.com (listman.back-rdu.redhat.com [10.10.2.136]) by hormel.redhat.com (Postfix) with ESMTP id 368A2783C9; Fri, 29 Aug 2003 09:27:59 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by listman.back-rdu.redhat.com (8.11.6/8.11.6) with ESMTP id h7TDR5g29471 for ; Fri, 29 Aug 2003 09:27:05 -0400 Received: (from mail@localhost) by int-mx1.corp.redhat.com (8.11.6/8.11.6) id h7TDTMt24900 for rpm-list@listman.back-rdu.redhat.com; Fri, 29 Aug 2003 09:29:22 -0400 Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with SMTP id h7TDTMs24888 for ; Fri, 29 Aug 2003 09:29:22 -0400 Received: from ms-smtp-03.southeast.rr.com (ms-smtp-03.southeast.rr.com [24.93.67.84]) by mx1.redhat.com (8.11.6/8.11.6) with SMTP id h7TDTMl15901 for ; Fri, 29 Aug 2003 09:29:22 -0400 Received: from nc.rr.com (rdu26-59-021.nc.rr.com [66.26.59.21]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h7TDRExk009075 for ; Fri, 29 Aug 2003 09:27:15 -0400 (EDT) Message-ID: <3F4F5530.4070306@nc.rr.com> From: Jeff Johnson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rpm-list@redhat.com Subject: Re: Backward and forward compatibility References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Loop: rpm-list@redhat.com Sender: rpm-list-admin@redhat.com Errors-To: rpm-list-admin@redhat.com X-BeenThere: rpm-list@redhat.com X-Mailman-Version: 2.0.13 Precedence: junk Reply-To: rpm-list@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: RPM Package Manager List-Unsubscribe: , List-Archive: Date: Fri, 29 Aug 2003 09:29:20 -0400 X-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA,X_LOOP version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Pyzor: Reported 0 times. X-DCC-dmv.com-Metrics: heretic.physik.fu-berlin.de 1181; Body=4 Fuz1=3 Fuz2=3 James Olin Oden wrote: >On Fri, 29 Aug 2003, Jeff Johnson wrote: > > > >>>Well, O_DIRECT is being ripped out by force in the specfiles (BTW when >>>you decided to rip it out, you forgot to change the release tag, so >>>there are some versions of rpm-4.2-1 floating around with enabled >>>O_DIRECT support). BTW2 there is some discussion on the xfs lists on >>>the background of db4/O_DIRECT/sparse files bug. If you like I can add >>>you to the discussion. >>> >>> >>> >>> >>Um, I'm less than happy about O_DIRECT: stupid interface, arcane problem. >>The killer is/was that O_DIRECT was unleashed in the kernel with hardly >>any warning, >>certainly not enough to do something rational in distributing rpm. >> >>Sure there are are versions around. I have the (ahem) joy of developing >>without >>a release plan or schedule, with whatever I just built released through >>Raw Hide >>and betas. >> >>Ready or not, here's rpm! >> >> >> >So is O_DIRECT something you have to use, or is it something that is good >to use if you can for rpm? I just googled for this, because I was not >sure what it was all about, and in effect it causes a file opened with >this flag to avoid the kernels cache and go directly to the disk? So, >I guess I am wondering, at a high level, why does rpm use this (i.e. I >am looking for clue)? > > O_DIRECT is similar to a "charcater device" in unix, i.e. DMA to/from user space. Berkeley DB uses (used) O_DIRECT to "harden" the behavior of an intrinsic file creation race opening __db.001 while establishing a dbenv. The implementation is sane, and O_DIRECT is reasonable hardening. O_DIRECT -- as instantiated in linux -- is goofy and under development. The behavior before was just to ignore O_DIRECT, it did not matter whether it was used or not. Life was good. O_DIRECT imposes size and alignment constraints on the I/O request, just like character devices. The painful constraint is page aligned address, necessitating valloc, not just any buffer address. The other pain with O_DIRECT is that the EINVAL returned with alignment failure comes from read/write, not from the open. This is different than most syscalls, which either fail immediately, or the cause of failure is obvious for other reasons. What is/was really, really broken is that O_DIRECT came out of no place, was released without adequate warning, and even kernel folks disagree on the implementation, and the implementation is not complete. Very not good. Works on some file systems, not on others, etc etc. Sure I can avoid O_DIRECT use in rpm, that's the only sane use of O_DIRECT afaict. But I cannot dictate what kernel users choose to run. 73 de Jeff _______________________________________________ Rpm-list mailing list Rpm-list@redhat.com https://www.redhat.com/mailman/listinfo/rpm-list --QTprm0S8XgL7H0Dt-- --oTHb8nViIGeoXxdp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/T39oQBVS1GOamfERApz+AJ9bX1mFTZhOo9UYvMI4f/5hDCx6hgCeNU+7 m9YWoGMa8JDlvexXYcAhHE4= =ItvR -----END PGP SIGNATURE----- --oTHb8nViIGeoXxdp-- From owner-linux-xfs@oss.sgi.com Fri Aug 29 10:12:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Aug 2003 10:13:32 -0700 (PDT) Received: from phoenix.infradead.org (pub234.cambridge.redhat.com [213.86.99.234] (may be forged)) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7THCpWZ006660 for ; Fri, 29 Aug 2003 10:12:52 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.22) id 19smnk-0008GS-SX; Fri, 29 Aug 2003 18:12:44 +0100 Date: Fri, 29 Aug 2003 18:12:44 +0100 From: Christoph Hellwig To: Axel Thimm Cc: Jeff Johnson , linux-xfs@oss.sgi.com Subject: Re: O_DIRECT & rpm (for xfs) Message-ID: <20030829181244.A31567@infradead.org> References: <20030829162928.GB2911@pua.nirvana> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030829162928.GB2911@pua.nirvana>; from Axel.Thimm@physik.fu-berlin.de on Fri, Aug 29, 2003 at 07:29:28PM +0300 X-archive-position: 245 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 711 Lines: 16 On Fri, Aug 29, 2003 at 07:29:28PM +0300, Axel Thimm wrote: > O_DIRECT -- as instantiated in linux -- is goofy and under development. > The behavior before was > just to ignore O_DIRECT, it did not matter whether it was used or not. > Life was good. Umm, that's wrong. O_DIRECT went into Linux 2.4.10 (and was in the XFS patches earlier) and never was ignored. Someone during the last year Red Hat decided to just clear the O_DIRECT flag in their kernels instead of returning an error. That's where this crap comes from. It's a genuine Red Hat bug. The alignment was blocksize previously and got down to sector size these days - but that's lessing the requirement, nothing that can harm an application. From owner-linux-xfs@oss.sgi.com Fri Aug 29 11:22:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Aug 2003 11:22:53 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TIMDWZ012610 for ; Fri, 29 Aug 2003 11:22:13 -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 h7TIM7q0006952 for ; Fri, 29 Aug 2003 11:22:07 -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 h7TIHPX311288162; Fri, 29 Aug 2003 13:17:27 -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 h7TIHQRn236978531; Fri, 29 Aug 2003 13:17:26 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h7TIHPm00846; Fri, 29 Aug 2003 13:17:25 -0500 Subject: Re: O_DIRECT & rpm (for xfs) From: Steve Lord To: Axel Thimm Cc: Jeff Johnson , linux-xfs@oss.sgi.com In-Reply-To: <20030829162928.GB2911@pua.nirvana> References: <20030829162928.GB2911@pua.nirvana> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1062181044.760.13.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 29 Aug 2003 13:17:25 -0500 X-archive-position: 246 X-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: 3671 Lines: 85 On Fri, 2003-08-29 at 11:29, Axel Thimm wrote: > Hi Jeff, > > thanks for the background on the O_DIRECT problem. As I wrote, there > is some active discussion on the xfs-list about how to deal with > O_DIRECT/ext3/xfs/rpm, and your explanation will be very valuable to > the XFS community, especially since it comes from the rpm master > himself :) > > For your background: The hanging of rpm with recent XFS patches due to > enabled O_DIRECT support generated some confusion about where this bug > came from. > > Current XFS policy is to enable O_DIRECT only for XFS partitions. > > Thanks! Having had O_DIRECT in the filesystems I have worked on for the last decade (thats getting scary ;-), I might comment on some of Jeff's message: > O_DIRECT -- as instantiated in linux -- is goofy and under development. > The behavior before was > just to ignore O_DIRECT, it did not matter whether it was used or not. > Life was good. I tend to agree with this to some extent, although O_DIRECT has been there for some filesystems in linux for a few years now. > O_DIRECT imposes size and alignment constraints on the I/O request, just > like character > devices. The painful constraint is page aligned address, necessitating > valloc, not just any buffer > address. The missing link here is a standard call to determine what the alignment constraints are for a particular filesystem. XFS has one of these, but it is XFS specific and not generally provided. The memory alignment one is someone difficult to justify in its current version, since the only real reason I know for constraining the alignment is the capabilities of the hardware to do dma. A page is way too large, a cache line is more likely to be the true boundary, a sector is also a possible contstraint. Again, the real issue is the lack of an interface to determine the allowed alignment. > The other pain with O_DIRECT is that the EINVAL returned with alignment > failure comes from > read/write, not from the open. This is different than most syscalls, > which either fail immediately, > or the cause of failure is obvious for other reasons. Since the open does not constrain what you do with read and write calls afterwards, you cannot really expect the open to predict that you will disobey the rules later. If you pass an invalid buffer address into a read or a write you get the error on that call, not the open. What might be a better approach, and what some of the big players probably expect (read Oracle here), is that O_DIRECT fall back to buffered I/O when the alignment constraints are not met on a call. You can conceive of two forms of open call - a hard and a soft form of O_DIRECT. The hard one would behave as it does now - if you disobey the rules, your I/O fails, the soft one would be more forgiving and do buffered I/O. This comes from the solaris implementation by the way. We are definitely getting pushback from database folks to follow this model - since the apps do not want to special case for different operating systems. > What is/was really, really broken is that O_DIRECT came out of no place, > was released without adequate > warning, and even kernel folks disagree on the implementation, and the > implementation is not > complete. Very not good. Works on some file systems, not on others, etc > etc. See Christoph's response for this one. But the reason it is on for XFS and not the other filesystems is that the bug in O_DIRECT which made them turn it off does not affect the XFS implementation. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Sun Aug 31 04:41:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 31 Aug 2003 04:42:01 -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.5) with SMTP id h7VBfGWZ021108 for ; Sun, 31 Aug 2003 04:41:18 -0700 Received: from mailhub.ch.sauter-bc.com (mailhub [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 5C93D32CA9 for ; Sun, 31 Aug 2003 13:41:10 +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 EFF6932CB5 for ; Sun, 31 Aug 2003 13:41:09 +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 B717611E0A for ; Sun, 31 Aug 2003 13:41:09 +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; Sun, 31 Aug 2003 13:41:09 +0200 (CEST) Message-ID: <41782.213.173.165.140.1062330069.squirrel@imap01.ch.sauter-bc.com> Date: Sun, 31 Aug 2003 13:41:09 +0200 (CEST) Subject: XFS shutdown with 1.3.0 From: "Simon Matter" To: 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 h7VBfIWZ021128 X-archive-position: 249 X-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: 3673 Lines: 97 I have upgraded one of my servers some days ago to my own kernel-2.4.20-20.7.XFS1.3.0. This is the kernel-2.4.20-19.9.XFS1.3.0 from oss, upgraded to the RedHat 2.4.20-20 release and nptl disabled (for RH7.x). I'm running RedHat 7.2, upgraded to the latest errata level. All xfs tools are the most current. Yesterday, my /home filesystem was shut down with the following error: xfs_inotobp: xfs_imap() returned an error 22 on md(9,8). Returning error. xfs_iunlink_remove: xfs_inotobp() returned an error 22 on md(9,8). Returning error. xfs_inactive: xfs_ifree() returned an error = 22 on md(9,8) xfs_force_shutdown(md(9,8),0x1) called from line 1846 of file xfs_vnodeops.c. Return address = 0xd08bd8c6 Filesystem "md(9,8)": I/O Error Detected. Shutting down filesystem: md(9,8) Please umount the filesystem, and rectify the problem(s) This box is running since the XFS1.0 days and I never ever had a filesystem shutdown. That's why I came to think it could be related to the recent XFS1.3.0 upgrade. But now, look at this: [root@xxl root]# xfs_check /dev/md8 xfs_check: warning - cannot get sector size from block device /dev/md8: Invalid argument agf_freeblks 22053, counted 30629 in ag 6 agi_freecount 332, counted 331 in ag 153 [root@xxl root]# xfs_repair -n -l /dev/md9 /dev/md8 xfs_repair: warning - cannot get sector size from block device /dev/md8: Invalid argument xfs_repair: warning - cannot get sector size from block device /dev/md9: Invalid argument Phase 1 - find and verify superblock... sb root inode value 128 inconsistent with calculated value 512 would reset superblock root inode pointer to 512 sb realtime bitmap inode 129 inconsistent with calculated value 513 would reset superblock realtime bitmap ino pointer to 513 sb realtime summary inode 130 inconsistent with calculated value 514 would reset superblock realtime summary ino pointer to 514 Phase 2 - using external log on /dev/md9 - scan filesystem freespace and inode maps... root inode chunk not found avl_insert: Warning! duplicate range [512,576] add_inode - duplicate inode range Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 bad .. entry in directory inode 128, points to self: would clear entry data fork in inode 170 claims metadata block 32 bad data fork in inode 170 would have cleared inode 170 data fork in inode 171 claims metadata block 33 bad data fork in inode 171 would have cleared inode 171 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 156 - agno = 157 - agno = 158 - agno = 159 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... Segmentation fault [root@xxl root]# xfs_repair -V xfs_repair version 2.5.6 I never considered the following a problem but wanted to mention it anyways. While running xfs_check and xfs_repair, I also get this in the logs: md: xfs_db(pid 9985) used obsolete MD ioctl, upgrade your software to use new ictls. md: xfs_repair(pid 10280) used obsolete MD ioctl, upgrade your software to use new ictls. md: xfs_repair(pid 10280) used obsolete MD ioctl, upgrade your software to use new ictls. md: xfs_repair(pid 10295) used obsolete MD ioctl, upgrade your software to use new ictls. md: xfs_repair(pid 10295) used obsolete MD ioctl, upgrade your software to use new ictls. I have then tried to mount the filesystem again and all seems well. Umounting and running xfs_repair again segfaults again. What's wrong here? Regards, Simon From owner-linux-xfs@oss.sgi.com Sun Aug 31 23:49:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 31 Aug 2003 23:50:35 -0700 (PDT) Received: from eyou.com ([61.136.62.76]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h816nnWZ006801 for ; Sun, 31 Aug 2003 23:49:53 -0700 Received: (EYOU MX PROGRAM); Mon, 01 Sep 2003 14:36:10 +0800 Message-ID: Received: from unknown (HELO eyou.com) (unknown@172.16.2.2) by 172.16.1.2 with SMTP; Mon, 01 Sep 2003 14:36:10 +0800 Received: (qmail 9797 invoked by uid 65534); 1 Sep 2003 14:29:19 +0800 Date: 1 Sep 2003 14:29:19 +0800 Message-ID: <20030901142919.9796.qmail@eyou.com> From: "yaoaiguo" To: linux-xfs@oss.sgi.com Reply-To: "yaoaiguo" Subject: nfs+acl Content-Type: text/plain X-archive-position: 250 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yaoaic_eyou@eyou.com Precedence: bulk X-list: linux-xfs Content-Length: 372 Lines: 16 Hello How can I make my linux2.4.20 support xfs+acl+nfs? The site "http://acl.bestbits.at" provide patch for ext/ext3 filesystem, where can I find patch for xfs? I find someone ask this question before, but I did not find the answer.Who can tell me? Thanks. --http://www.eyou.com --Îȶ¨¿É¿¿µÄÃâ·Ñµç×ÓÐÅÏä ÓïÒôÓʼþ Òƶ¯ÊéÇ© ÈÕÀú·þÎñ ÍøÂç´æ´¢...ÒÚÓÊδ¾¡