From owner-linux-xfs@oss.sgi.com Fri Jun 1 00:18:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f517Ico17089 for linux-xfs-outgoing; Fri, 1 Jun 2001 00:18:38 -0700 Received: from df.unipi.it (mail.df.unipi.it [131.114.19.77]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f517IWh17077 for ; Fri, 1 Jun 2001 00:18:33 -0700 Received: from [131.114.19.37] (account mau HELO df.unipi.it) by df.unipi.it (CommuniGate Pro SMTP 3.4.6) with ESMTP id 980860 for linux-xfs@oss.sgi.com; Fri, 01 Jun 2001 09:22:46 +0200 Message-ID: <3B1741AF.7C27288D@df.unipi.it> Date: Fri, 01 Jun 2001 09:18:07 +0200 From: maurizio.davini@df.unipi.it Organization: Department of Physics University of Pisa X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: problems compiling xfsdump Content-Type: multipart/mixed; boundary="------------70B9DEECC06C66B132E1E797" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------70B9DEECC06C66B132E1E797 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Compiling the last CVS code on RedHat 7.1 I have the problems reported in the log file attached. Can help ? Maurizio Davini --------------70B9DEECC06C66B132E1E797 Content-Type: text/plain; charset=us-ascii; name="log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="log" === dump === gcc -O1 -g -DDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -I/usr/include/xfs -I/usr/include/attr '-DVERSION="1.0.9"' -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -o xfsdump arch_xlate.o cldmgr.o content_common.o dlog.o drive.o drive_scsitape.o drive_simple.o drive_minrmt.o fs.o getdents.o global.o lock.o main.o mlog.o openutil.o qlock.o path.o ring.o stkchk.o stream.o util.o sproc.o attr.o inv_api.o inv_core.o inv_fstab.o inv_idx.o inv_mgr.o inv_stobj.o content.o inomap.o var.o -lhandle /usr/lib/libuuid.a ../librmt/librmt.a /usr/lib/libattr.a arch_xlate.o: In function `xlate_global_hdr': /root/xfs/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:67: undefined reference to `__fswab64' /root/xfs/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:67: undefined reference to `__fswab64' arch_xlate.o: In function `xlate_content_inode_hdr': /root/xfs/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:252: undefined reference to `__fswab64' /root/xfs/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:252: undefined reference to `__fswab64' /root/xfs/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:253: undefined reference to `__fswab64' arch_xlate.o:/root/xfs/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:253: more undefined references to `__fswab64' follow collect2: ld returned 1 exit status make[1]: *** [xfsdump] Error 1 make: *** [default] Error 2 --------------70B9DEECC06C66B132E1E797 Content-Type: text/x-vcard; charset=us-ascii; name="maurizio.davini.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Content-Disposition: attachment; filename="maurizio.davini.vcf" begin:vcard n:Davini;Maurizio tel;fax:+39-050-844634 tel;work:+39-050-844633 x-mozilla-html:FALSE url:http://www.df.unipi.it/ org:University of Pisa;Physics adr:;;Via Buonarroti 2;Pisa;;56100;ITALY version:2.1 email;internet:maurizio.davini@df.unipi.it title:System Manager x-mozilla-cpt:;0 fn:Maurizio Davini end:vcard --------------70B9DEECC06C66B132E1E797-- From owner-linux-xfs@oss.sgi.com Fri Jun 1 01:10:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f518ADc25075 for linux-xfs-outgoing; Fri, 1 Jun 2001 01:10:13 -0700 Received: from bastjon.mgm-net.de (bastjon.mgm-net.de [195.254.50.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f518A8h25059 for ; Fri, 1 Jun 2001 01:10:08 -0700 Received: from cepheus.mgm-net.de (IDENT:root@cepheus.mgm-net.de [192.168.1.2]) by bastjon.mgm-net.de (8.9.3/8.9.3) with ESMTP id KAA00685; Fri, 1 Jun 2001 10:10:04 +0200 (CEST) Received: from gilmour.mgm-net.de (IDENT:root@gilmour.mgm-net.de [192.168.1.37]) by cepheus.mgm-net.de (8.9.3/8.9.3) with ESMTP id KAA06772; Fri, 1 Jun 2001 10:10:00 +0200 Received: (from js@localhost) by gilmour.mgm-net.de (8.11.0/8.11.0) id f518A0d19971; Fri, 1 Jun 2001 10:10:00 +0200 From: Jochen Scharrlach MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15127.19928.888633.844437@gilmour.mgm-net.de> Date: Fri, 1 Jun 2001 10:10:00 +0200 (CEST) To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: New files on xfs ftp site In-Reply-To: <200105312312.f4VNCpB20388@jen.americas.sgi.com> References: <200105312312.f4VNCpB20388@jen.americas.sgi.com> X-Mailer: VM 6.75 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord writes: > This just patch a vanilla 2.5.4 kernel with the xfs code base, they do > not contain cvs files, or the command source. The existing cvs seed > patch can still be used to setup an initial cvs tree. Maybe I miss something very obvious, but I'm a bit confused, esp. I don't know what you exactly mean with "they do not contain cvs files": - are these Patches simply XFS-1.0-for-2.4.5? - are they some kind of XFS-1.0.1-beta? - are they bleeding-edge CVS code? - is a 2.4.5+XFS expected to work better than the patched 2.4.2 (which contains AFAIR XFS-1.0 plus several bugfixes) that comes with RH7.1-XFS? Thanks, Jochen -- ---------------------------------------------------------------- Nextra Baden-Wuerttemberg | Jochen Scharrlach Communication Service Provider GmbH | Technik Sophienstr.26 | Tel.: +49 (0)711 96683-5 D-70178 Stuttgart | Fax: +49 (0)711 96683-99 ---------------------------------------------------------------- "An innovation a day keeps the monopolist away" -- Alan Cox From owner-linux-xfs@oss.sgi.com Fri Jun 1 01:47:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f518lIL31198 for linux-xfs-outgoing; Fri, 1 Jun 2001 01:47:18 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f518lDh31179 for ; Fri, 1 Jun 2001 01:47:13 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id KAA1260934 for ; Fri, 1 Jun 2001 10:46:59 +0200 (CEST) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA50508; Fri, 1 Jun 2001 18:45:40 +1000 (EST) Date: Fri, 1 Jun 2001 18:45:39 +1000 From: Timothy Shimmin To: maurizio.davini@df.unipi.it Cc: linux-xfs@oss.sgi.com Subject: Re: problems compiling xfsdump Message-ID: <20010601184539.P97441@boing.melbourne.sgi.com> References: <3B1741AF.7C27288D@df.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3B1741AF.7C27288D@df.unipi.it>; from maurizio.davini@df.unipi.it on Fri, Jun 01, 2001 at 09:18:07AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Maurizio, On Fri, Jun 01, 2001 at 09:18:07AM +0200, maurizio.davini@df.unipi.it wrote: > Compiling the last CVS code on RedHat 7.1 > I have the problems reported in the log file attached. > Can help ? > Maurizio Davini > === dump === > gcc -O1 -g -DDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -I/usr/include/xfs -I/usr/include/attr '-DVERSION="1.0.9"' -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -o xfsdump arch_xlate.o cldmgr.o content_common.o dlog.o drive.o drive_scsitape.o drive_simple.o drive_minrmt.o fs.o getdents.o global.o lock.o main.o mlog.o openutil.o qlock.o path.o ring.o stkchk.o stream.o util.o sproc.o attr.o inv_api.o inv_core.o inv_fstab.o inv_idx.o inv_mgr.o inv_stobj.o content.o inomap.o var.o -lhandle /usr/lib/libuuid.a ../librmt/librmt.a /usr/lib/libattr.a > arch_xlate.o: In function `xlate_global_hdr': > /root/xfs/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:67: undefined reference to `__fswab64' > /root/xfs/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:67: undefined reference to `__fswab64' > arch_xlate.o: In function `xlate_content_inode_hdr': > /root/xfs/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:252: undefined reference to `__fswab64' > /root/xfs/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:252: undefined reference to `__fswab64' > /root/xfs/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:253: undefined reference to `__fswab64' > arch_xlate.o:/root/xfs/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:253: more undefined references to `__fswab64' follow > collect2: ld returned 1 exit status > make[1]: *** [xfsdump] Error 1 > make: *** [default] Error 2 Need to have the latest headers from cmd/xfsprogs installed. Which means you'll need a "make install-dev" in the cmd/xfsprogs directory. --Tim From owner-linux-xfs@oss.sgi.com Fri Jun 1 05:25:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51CPxQ13690 for linux-xfs-outgoing; Fri, 1 Jun 2001 05:25:59 -0700 Received: from studsv07.studserv.uni-stuttgart.de (studsv07.studserv.uni-stuttgart.de [129.69.21.37]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51CPuh13683 for ; Fri, 1 Jun 2001 05:25:56 -0700 Received: from ysabell.wh.vaih [129.69.166.244] by studsv07.studserv.uni-stuttgart.de with ESMTP (SMTPD32-6.06) id A9D1527033C; Fri, 01 Jun 2001 14:25:53 +0200 Received: from marcelo by ysabell.wh.vaih with local (Exim 3.22 #1 (Debian)) id 155o03-00015o-00; Fri, 01 Jun 2001 14:25:55 +0200 Date: Fri, 1 Jun 2001 14:25:55 +0200 From: "Marcelo E. Magallon" To: Jochen Scharrlach Cc: linux-xfs@oss.sgi.com Subject: Re: New files on xfs ftp site Message-ID: <20010601142555.C4150@ysabell.wh.vaih> Mail-Followup-To: Jochen Scharrlach , linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15127.19928.888633.844437@gilmour.mgm-net.de> User-Agent: Mutt/1.3.18i X-Operating-System: Linux ysabell 2.4.4-xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> Jochen Scharrlach writes: > - are they bleeding-edge CVS code? It's taken off the CVS tree and diff'ed against a fresh 2.4.5 tree. It applies cleanly (just checked this to be sure). AFAICT (don't take my word for this, I use neither RH nor the SGI release) the "1.0" release is 2.4.2 + XFS at that time + "this really needs to be fixed" kind of patches. HTH, -- Marcelo From owner-linux-xfs@oss.sgi.com Fri Jun 1 05:52:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51CqTk15909 for linux-xfs-outgoing; Fri, 1 Jun 2001 05:52:29 -0700 Received: from studsv07.studserv.uni-stuttgart.de (studsv07.studserv.uni-stuttgart.de [129.69.21.37]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51CqOh15906 for ; Fri, 1 Jun 2001 05:52:25 -0700 Received: from ysabell.wh.vaih [129.69.166.244] by studsv07.studserv.uni-stuttgart.de with ESMTP (SMTPD32-6.06) id A002B500374; Fri, 01 Jun 2001 14:52:18 +0200 Received: from marcelo by ysabell.wh.vaih with local (Exim 3.22 #1 (Debian)) id 155oPc-000162-00; Fri, 01 Jun 2001 14:52:20 +0200 Date: Fri, 1 Jun 2001 14:52:20 +0200 From: "Marcelo E. Magallon" To: Austin Gonyou Cc: Chuck Rouillard , georgeb@unitbv.ro, linux-xfs@oss.sgi.com Subject: Re: does it work on 2.4.4 Message-ID: <20010601145220.D4150@ysabell.wh.vaih> Mail-Followup-To: Austin Gonyou , Chuck Rouillard , georgeb@unitbv.ro, linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i X-Operating-System: Linux ysabell 2.4.4-xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> Austin Gonyou writes: > Well, a good question posed to me was Why in the hell is it 3 MB. I > like a single patch myself, but it's not quite right for accuracy, > with the different kinds of things this patch touches. You've got > tools, then core linux/xfs, then xfs/fs. That's potentially 3 patches > all together. The other day I was looking at this. I learned that the XFS patch includes: * XFS for Linux proper (this is about 50% of the patch) * Delayed write buffers * POSIX ACLs * DMAPI (Data Management API) * Guaranteed datarate * KDB (the Kernel Debugger) * NMI patches * LVM patches * I'm missing something... Some of these are interwoven... The tools are included in a separate file (that is, I'm talking about the linux-whatever-xfs.patch). I'm not sure what you mean by linux/xfs and xfs/fs. -- Marcelo From owner-linux-xfs@oss.sgi.com Fri Jun 1 06:25:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51DPan19048 for linux-xfs-outgoing; Fri, 1 Jun 2001 06:25:36 -0700 Received: from amoa.org (amoa.org [207.207.51.226]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51DPWh19041 for ; Fri, 1 Jun 2001 06:25:32 -0700 Received: by amoa.org(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256A5E.0049BCB2 ; Fri, 1 Jun 2001 08:25:24 -0500 X-Lotus-FromDomain: AMOA From: ctooley@amoa.org To: linux-xfs@oss.sgi.com Message-ID: <86256A5E.0049BC33.00@amoa.org> Date: Fri, 1 Jun 2001 08:25:22 -0500 Subject: Re: New files on xfs ftp site Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk So if I want to upgrade to 2.4.5 via building a kernel RPM (I know this seems odd, but I've got 4 machines running XFS and would just like to keep them consistent) what all would I have to apply to 2.4.5 code to be able to repace the 2.4.2 code in the SRPM? Chris Tooley "Marcelo E. Magallon" on 06/01/2001 07:25:55 AM To: Jochen Scharrlach cc: linux-xfs@oss.sgi.com(bcc: Chris Tooley/AMOA) Subject Re: New files on xfs ftp site : >> Jochen Scharrlach writes: > - are they bleeding-edge CVS code? It's taken off the CVS tree and diff'ed against a fresh 2.4.5 tree. It applies cleanly (just checked this to be sure). AFAICT (don't take my word for this, I use neither RH nor the SGI release) the "1.0" release is 2.4.2 + XFS at that time + "this really needs to be fixed" kind of patches. HTH, -- Marcelo From owner-linux-xfs@oss.sgi.com Fri Jun 1 06:44:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51Dipi20918 for linux-xfs-outgoing; Fri, 1 Jun 2001 06:44:51 -0700 Received: from sa-bwmail1.storageapps.com (smtp.storageapps.com [63.101.83.13]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51Dilh20914 for ; Fri, 1 Jun 2001 06:44:47 -0700 Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Jun 2001 09:44:49 -0400 Message-ID: <23D04BDBA646D411BDDD00D0B774B53902963A5B@SA-BWMAIL1> From: "Christian, Chip" To: Austin Gonyou Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: Path failover with xfs on linux Date: Fri, 1 Jun 2001 09:44:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In make menuconfig, it's Multi-device support (RAID and LVM) ---> Multiple devices driver support (RAID and LVM) Multipath I/O support Under drivers/md there's a multipath.c. Usage can be found in /usr/share/doc/raidtools/multipath.conf.sample. There's no method to automatically re-enable a failed path (concious decision) but it's trivial to do from usermode by using raidhotremove and raidhotadd. -----Original Message----- From: Austin Gonyou [mailto:austin@coremetrics.com] Sent: Friday, June 01, 2001 2:29 To: Christian, Chip Cc: 'Steve Lord'; Coumoul, Philippe; 'linux-xfs@oss.sgi.com' Subject: RE: Path failover with xfs on linux Whoa, it does have that? Well shut my mouth. :) What's the driver named? -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com On Thu, 31 May 2001, Christian, Chip wrote: > RedHat 7.1 has a multipath block driver that has worked well in our testing. We put XFS on top. > > -----Original Message----- > From: Steve Lord [mailto:lord@sgi.com] > Sent: Thursday, May 31, 2001 13:19 > To: Coumoul, Philippe > Cc: 'linux-xfs@oss.sgi.com' > Subject: Re: Path failover with xfs on linux > > > > Hi, > > > > I m looking for a path failover software solution to secure acces from Red > > Hat 7.x server to an external Raid Storage Subsystem. > > I ve seen that there is not XLV on XFS for Linux, but is there a failover > > possibility without XLV ? > > > > Thanks > > > > Phil > > This question might be better directed at the linux kernel list, hardware > failover is usually invisible to the filesystem, being handled at the > block layer. SGI does have ports of some of the Irix SCSI code which > includes failover capability for certain device types, but I cannot > say when or how this would be available. > > Steve > From owner-linux-xfs@oss.sgi.com Fri Jun 1 07:35:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51EZRi24818 for linux-xfs-outgoing; Fri, 1 Jun 2001 07:35:27 -0700 Received: from akira.ep-ka.de (akira.ep-ag.com [194.120.231.250]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51EZHh24812 for ; Fri, 1 Jun 2001 07:35:22 -0700 Received: from ep-ag.com (sol10.ep-ka.de [194.120.231.11]) by akira.ep-ka.de (8.9.1/8.9.3) with ESMTP id QAA03666 for ; Fri, 1 Jun 2001 16:35:07 +0200 Received: from ep-ag.com (stb@crusher.ep-ka.de [194.120.231.18]) by ep-ag.com (8.9.3/8.9.3) with ESMTP id QAA17739 for ; Fri, 1 Jun 2001 16:35:07 +0200 (MET DST) Message-ID: <3B17A81B.104@ep-ag.com> Date: Fri, 01 Jun 2001 16:35:07 +0200 From: "Klaus Strebel,ITS,204" Organization: EIGNER+PARTNER AG User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-XFS i686; en-US; rv:0.9) Gecko/20010505 X-Accept-Language: de, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Hanging around with 2.4.5-xfs from cvs Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi everybody, yesterday i updated my linux-2.4-xfs cvs-tree (after waiting anxiously for oss.sgi.com to be reachable again, sigh :-) ), compliled it, installed it, booted and ... by box kept hanging at the 'ifconfig lo 127.0.0.1 netmask 255.0.0.0 dev lo'. I unconfigured START_LOOPBACK (i'm using SuSE 7. almost 1, couldn't find a way to do the SuSE-upgrade procedure with a xfs-enabled kernel, only / and /boot are ext2), tried it again, an by box hang at loading the next network driver :-(. First i expected that my cvs tree was corrupt, rm'ed it and recheck it out. Same result. Hm, is it possible that 2.4.5 doesn't work on my box at all? Pulled a vanilla kernel source from kernel.org and tried it out. Well it started and all what could be seen (without xfs-filesystems) worked just fine. So i downloaded linux-2.4.5-xfs-05312001.patch.bz2 from oss.sgi.com, removed everything not necessary for xfs from it (kernel debugger, ac-patch things, lvm upgrades - upgraded myself to 0.9.1beta7 ...) and no it works! Is KDB broken ?? Ciao Klaus From owner-linux-xfs@oss.sgi.com Fri Jun 1 08:29:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51FTu328863 for linux-xfs-outgoing; Fri, 1 Jun 2001 08:29:56 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51FTsh28860 for ; Fri, 1 Jun 2001 08:29:55 -0700 Received: (qmail 24027 invoked from network); 1 Jun 2001 15:29:51 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 1 Jun 2001 15:29:51 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Klaus Strebel,ITS,204" cc: linux-xfs@oss.sgi.com Subject: Re: Hanging around with 2.4.5-xfs from cvs In-reply-to: Your message of "Fri, 01 Jun 2001 16:35:07 +0200." <3B17A81B.104@ep-ag.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 02 Jun 2001 01:29:50 +1000 Message-ID: <7922.991409390@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 01 Jun 2001 16:35:07 +0200, "Klaus Strebel,ITS,204" wrote: >yesterday i updated my linux-2.4-xfs cvs-tree (after waiting anxiously >for oss.sgi.com to be reachable again, sigh :-) ), compliled it, >installed it, booted and ... by box kept hanging at the 'ifconfig lo >127.0.0.1 netmask 255.0.0.0 dev lo'. I unconfigured START_LOOPBACK (i'm >using SuSE 7. almost 1, couldn't find a way to do the SuSE-upgrade >procedure with a xfs-enabled kernel, only / and /boot are ext2), tried >it again, an by box hang at loading the next network driver :-(. > >So i downloaded linux-2.4.5-xfs-05312001.patch.bz2 from oss.sgi.com, >removed everything not necessary for xfs from it (kernel debugger, >ac-patch things, lvm upgrades - upgraded myself to 0.9.1beta7 ...) and >no it works! Is KDB broken ?? Works for me :). This is top of tree as of Fri Jun 1 15:10:23 UTC 2001, configured with xfs and kdb. Linux ocs4 2.4.5-xfs #1 SMP Sat Jun 2 01:10:01 EST 2001 i686 unknown Entering non-interactive startup Setting network parameters: [ OK ] Bringing up interface lo: [ OK ] Bringing up interface eth0: [ OK ] Your problem sounds like a generic network problem, not XFS. There have been some recent patches by Jeff Garzick for timing related problems with network drivers on 2.4.5. Try linux-kernel. From owner-linux-xfs@oss.sgi.com Fri Jun 1 08:42:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51FgMT30037 for linux-xfs-outgoing; Fri, 1 Jun 2001 08:42:22 -0700 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51FgLh30034 for ; Fri, 1 Jun 2001 08:42:21 -0700 Received: (from hch@localhost) by ns.caldera.de (8.11.1/8.11.1) id f51FfxL06539; Fri, 1 Jun 2001 17:41:59 +0200 Date: Fri, 1 Jun 2001 17:41:59 +0200 From: Christoph Hellwig To: "Christian, Chip" Cc: Austin Gonyou , "'linux-xfs@oss.sgi.com'" Subject: Re: Path failover with xfs on linux Message-ID: <20010601174159.A6517@caldera.de> References: <23D04BDBA646D411BDDD00D0B774B53902963A5B@SA-BWMAIL1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <23D04BDBA646D411BDDD00D0B774B53902963A5B@SA-BWMAIL1>; from chip.christian@storageapps.com on Fri, Jun 01, 2001 at 09:44:43AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Jun 01, 2001 at 09:44:43AM -0400, Christian, Chip wrote: > In make menuconfig, it's > Multi-device support (RAID and LVM) ---> > Multiple devices driver support (RAID and LVM) > Multipath I/O support > Under drivers/md there's a multipath.c. Usage can be found in /usr/share/doc/raidtools/multipath.conf.sample. > Not part of the stock kernel. (Though I hope it will be merged soon). Christoph -- Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Fri Jun 1 09:39:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51Gdng00979 for linux-xfs-outgoing; Fri, 1 Jun 2001 09:39:49 -0700 Received: from mail.tiscali.be (mail.tiscali.be [212.35.2.8]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51Gdlh00974 for ; Fri, 1 Jun 2001 09:39:47 -0700 Received: from ogwit.freegates.net ([172.16.1.254] helo=lladm.net) by mail.tiscali.be with esmtp (Tiscali) id 155rxg-0005Fx-00 for ; Fri, 01 Jun 2001 18:39:44 +0200 Message-ID: <3B17C54F.1030407@lladm.net> Date: Fri, 01 Jun 2001 18:39:43 +0200 From: Christopher Bodenstein Reply-To: cb@tiscali.be Organization: Tiscali SA/NV User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-xfs i686; en-US; rv:0.9+) Gecko/20010531 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: System crashes with 2.4.5-xfs Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan *155rxg-0005Fx-00*aJBCx5Jjea2* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, I've been using CVS kernels since 2.4.2 without major problems on my workstation. I just compiled a brand new 2.4.5 and it seems my system just hangs as soon as the swap memory is full. Any idea why? I run a Debian unstable on a Celeron 400 with 128Mb RAM and 128Mb swap memory. BTW, thanks for providing us with this marvellous journalling file system :-) Kind regards, Chris -- Christopher Bodenstein - mailto:cb@tiscali.be System Administrator Manager - Tiscali Belgium NV/SA Keep the Internet Free with Tiscalinet - phone: +3224000888 http://www.tiscalinet.be/ - fax: +3224000899 From owner-linux-xfs@oss.sgi.com Fri Jun 1 09:51:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51GpjU01435 for linux-xfs-outgoing; Fri, 1 Jun 2001 09:51:45 -0700 Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51Gpih01432 for ; Fri, 1 Jun 2001 09:51:44 -0700 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA28936 for ; Fri, 1 Jun 2001 09:51:32 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id JAA24076 for ; Fri, 1 Jun 2001 09:51:42 -0700 (PDT) Received: from pipcws.ca.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 1 Jun 2001 09:51:35 -0700 Received: from pipcws.ca.boeing.com (e218766.evt.boeing.com [136.203.14.68]) by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id JAA52954; Fri, 1 Jun 2001 09:51:35 -0700 Message-Id: <3B17C812.6010507@pipcws.ca.boeing.com> Date: Fri, 01 Jun 2001 09:51:30 -0700 From: Ric Tibbetts User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9) Gecko/20010505 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Daniel Moore CC: ctooley@amoa.org, linux-xfs@oss.sgi.com Subject: Re: xfs_growfs References: <200106010308.NAA88906@clouds.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Daniel Moore wrote: > ctooley@amoa.org writes: > => > => > => I'm looking for a good howto on the situations in which growfs works. I ha > => ve a > => partition that is too small, there is free space after it, and I want XFS t > => o > => consume the rest of that space. Any help would be appreciated. > > This is exactly what xfs_growfs does. Read the man page for extra details > and don't forget to backup first. True, but only IF you're running LVM. You need to "grow" the partition, and that is not possible. You need LVM to manage this kind of thing AFAIK. Ric From owner-linux-xfs@oss.sgi.com Fri Jun 1 10:05:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51H5X001964 for linux-xfs-outgoing; Fri, 1 Jun 2001 10:05:33 -0700 Received: from msg.ecetra.com (dollar.ecetra.com [193.164.224.209]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51H5Wh01961 for ; Fri, 1 Jun 2001 10:05:32 -0700 Received: from vie-ac.office.ecetra.com (vie-ac.office.ecetra.com [10.251.148.147] (may be forged)) by msg.ecetra.com (8.9.3/8.9.3) with ESMTP id TAA10012; Fri, 1 Jun 2001 19:05:10 +0200 Received: from localhost (localhost [127.0.0.1]) by vie-ac.office.ecetra.com (8.11.3/8.11.3) with ESMTP id f51H5AS18420; Fri, 1 Jun 2001 19:05:10 +0200 Date: Fri, 1 Jun 2001 19:05:10 +0200 (CEST) From: Adam Cioccarelli To: cc: Subject: Re: System crashes with 2.4.5-xfs In-Reply-To: <3B17C54F.1030407@lladm.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, mine hasn't crashed but 2.4.5 seems a lot more aggressive with it's memory consumption! This seems to be a kernel problem though from what I've seen on the kernel mailing list... ------------------------------------------------------------------------------- Adam Cioccarelli (B.E Mechanical) Adam.Cioccarelli@ecetra.com Database Administrator Phone: +43 1 536 89 7725 Fax: +43 1 536 89 7719 ecetra Central European e-Finance AG Mobile:+43 664 181 4195 ------------------------------------------------------------------------------- On Fri, 1 Jun 2001, Christopher Bodenstein wrote: > Hi all, > > I've been using CVS kernels since 2.4.2 without major problems on my > workstation. > I just compiled a brand new 2.4.5 and it seems my system just hangs as > soon as the swap memory is full. Any idea why? > > I run a Debian unstable on a Celeron 400 with 128Mb RAM and 128Mb swap > memory. > > BTW, thanks for providing us with this marvellous journalling file > system :-) > > Kind regards, > > Chris > > -- > Christopher Bodenstein - mailto:cb@tiscali.be > System Administrator Manager - Tiscali Belgium NV/SA > Keep the Internet Free with Tiscalinet - phone: +3224000888 > http://www.tiscalinet.be/ - fax: +3224000899 > From owner-linux-xfs@oss.sgi.com Fri Jun 1 10:31:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51HVYw02858 for linux-xfs-outgoing; Fri, 1 Jun 2001 10:31:34 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51HVXh02849 for ; Fri, 1 Jun 2001 10:31:33 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA1300658 for ; Fri, 1 Jun 2001 19:31:31 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2032777; Fri, 1 Jun 2001 12:29:55 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA78712; Fri, 1 Jun 2001 12:29:55 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f51HWa721084; Fri, 1 Jun 2001 12:32:36 -0500 Message-Id: <200106011732.f51HWa721084@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Martin Stricker cc: linux-xfs@oss.sgi.com Subject: Re: redhat 7.1 In-Reply-To: Message from Martin Stricker of "Fri, 01 Jun 2001 02:19:46 +0200." <3B16DFA0.AEFA4C50@gmx.de> Date: Fri, 01 Jun 2001 12:32:36 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Not the compiler is broken but the source code! See > http://www.bero.org/gcc296.html for more information. After a close look > of some of my own source and contemplating about Beros comments I > finally got to the conclusion Red Hat did a Good Thing (TM) deciding to > use gcc 2.96-RH. But decide yourself. It may take *some* fixing in the > XFS code but after that you're standards compliant, so your code should > work with any compiler (that is, if that compilers is ANSI C compliant! > Not all are...) > > FWIW I asked on the Red Hat mailing list about XFS and RHL, but no > employee of Red Hat shed any light to the issue... > > Best regards, > Martin Stricker Actually, the examples given on this page do not apply to xfs, what does appear to be the case with xfs is that it exercises the 64 bit handling of the compiler more than most things do. 90% of the code base is also the Irix code which works just fine with the SGI compilers on a 64 bit architecture. The challenging problem is going from a kernel that crashes due to code not being compiled as expected, to finding the line of code in the 122 thousand lines which make up XFS and it support code (comments not stripped in that number). Oh and add to that the fact that some build types seem to run fine and some do not, that suggests bad code generation to me. Unfortunately, getting to the bottom of this is a big task, and there are compilers which are: a) still the recommended kernel compiler b) do not exhibit problems with xfs. Steve From owner-linux-xfs@oss.sgi.com Fri Jun 1 10:35:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51HZoO03226 for linux-xfs-outgoing; Fri, 1 Jun 2001 10:35:50 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51HZjh03222 for ; Fri, 1 Jun 2001 10:35:45 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA1272816 for ; Fri, 1 Jun 2001 19:35:43 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2031592; Fri, 1 Jun 2001 12:34:24 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA43279; Fri, 1 Jun 2001 12:34:24 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f51Hb5c21095; Fri, 1 Jun 2001 12:37:05 -0500 Message-Id: <200106011737.f51Hb5c21095@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jochen Scharrlach cc: linux-xfs@oss.sgi.com Subject: Re: New files on xfs ftp site In-Reply-To: Message from Jochen Scharrlach of "Fri, 01 Jun 2001 10:10:00 +0200." <15127.19928.888633.844437@gilmour.mgm-net.de> Date: Fri, 01 Jun 2001 12:37:05 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The new files are as you put it 'bleeding edge cvs code', which happens to be a lot more stable than the 1.0 release was, pretty much everything which has happened to the code base since then has been a bug fix. Originally we shipped code in three forms: o rpm packages - updated very infrequently o cvs tree - updated every hour to pick up development changes o a patch to turn a base linux tree into a cvs tree which can be used to keep upto date with the development cvs tree. I put out something more traditional in the linux world - a kernel patch. Steve > Steve Lord writes: > > This just patch a vanilla 2.5.4 kernel with the xfs code base, they do > > not contain cvs files, or the command source. The existing cvs seed > > patch can still be used to setup an initial cvs tree. > > Maybe I miss something very obvious, but I'm a bit confused, esp. I > don't know what you exactly mean with "they do not contain cvs files": > > - are these Patches simply XFS-1.0-for-2.4.5? > > - are they some kind of XFS-1.0.1-beta? > > - are they bleeding-edge CVS code? > > - is a 2.4.5+XFS expected to work better than the patched 2.4.2 > (which contains AFAIR XFS-1.0 plus several bugfixes) that > comes with RH7.1-XFS? > > Thanks, > Jochen > > -- > ---------------------------------------------------------------- > Nextra Baden-Wuerttemberg | Jochen Scharrlach > Communication Service Provider GmbH | Technik > Sophienstr.26 | Tel.: +49 (0)711 96683-5 > D-70178 Stuttgart | Fax: +49 (0)711 96683-99 > ---------------------------------------------------------------- > > "An innovation a day keeps the monopolist away" -- Alan Cox From owner-linux-xfs@oss.sgi.com Fri Jun 1 10:41:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51HfDs03644 for linux-xfs-outgoing; Fri, 1 Jun 2001 10:41:13 -0700 Received: from noth.n0th.org (root@c999639-a.carneg1.pa.home.com [24.180.243.111]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51HfCh03636 for ; Fri, 1 Jun 2001 10:41:12 -0700 Received: (from www-data@localhost) by noth.n0th.org (8.9.3/8.9.3/Debian 8.9.3-21) id NAA22273; Fri, 1 Jun 2001 13:40:35 -0400 X-Authentication-Warning: noth.n0th.org: www-data set sender to noth@noth.is.eleet.ca using -f To: Ric Tibbetts Subject: Re: xfs_growfs Message-ID: <991417235.3b17d39358f42@noth.is.eleet.ca> Date: Fri, 01 Jun 2001 13:40:35 -0400 (EDT) From: Jim Crilly Cc: Daniel Moore , ctooley@amoa.org, linux-xfs@oss.sgi.com References: <200106010308.NAA88906@clouds.melbourne.sgi.com> <3B17C812.6010507@pipcws.ca.boeing.com> In-Reply-To: <3B17C812.6010507@pipcws.ca.boeing.com> 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.3 X-Originating-IP: 206.181.95.130 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Quoting Ric Tibbetts : > Daniel Moore wrote: > > > ctooley@amoa.org writes: > > => > > => > > => I'm looking for a good howto on the situations in which growfs > works. I ha > > => ve a > > => partition that is too small, there is free space after it, and I > want XFS t > > => o > > => consume the rest of that space. Any help would be appreciated. > > > > This is exactly what xfs_growfs does. Read the man page for extra > details > > and don't forget to backup first. > > > True, but only IF you're running LVM. You need to "grow" the partition, > and that is not possible. You need LVM to manage this kind of thing > AFAIK. > > Ric > If there is unpartitioned space after the XFS partition you should be able to delete the XFS partition and recreate it bigger since fdisk only changes the partiton table entry. The important part is making sure the partition starts on exactly the same cylinder and the new partition is larger, since there is no way to shrink an XFS partition. Jim From owner-linux-xfs@oss.sgi.com Fri Jun 1 10:49:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51Hn3n04522 for linux-xfs-outgoing; Fri, 1 Jun 2001 10:49:03 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51Hn2h04519 for ; Fri, 1 Jun 2001 10:49:03 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA07192 for ; Fri, 1 Jun 2001 10:49:11 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2019377; Fri, 1 Jun 2001 12:47:45 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA56715; Fri, 1 Jun 2001 12:47:43 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f51HoPE21138; Fri, 1 Jun 2001 12:50:25 -0500 Message-Id: <200106011750.f51HoPE21138@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com, Chris Szilagyi Subject: Re: xfs mount warning Date: Fri, 01 Jun 2001 12:50:25 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ctooley@amoa.org said: >> Hello, I have a question. When my system boots, it reports the >> following errors when it mounts my xfs volumes: >> kernel: Partition check: >> kernel: /dev/scsi/host1/bus0/target0/lun0: p1 p2 >> kernel: Start mounting filesystem: sd(8,1) >> kernel: XFS: WARNING: recovery required on readonly filesystem. >> kernel: >> kernel: XFS: write access will be enabled during mount. >> kernel: >> kernel: Starting XFS recovery on filesystem: sd(8,1) (dev: 8/1) >> kernel: Ending XFS recovery on filesystem: sd (8,1) (dev: 8/1) >> kernel: VFS: Mounted root (xfs filesystem) readonly. >> Just wondering why it has to do a recovery, and if this is common and >> if it can be fixed. When I shutdown it unmounts the volumes ok... >> Thanks, -- Chris This does actually mean it was not successfully unmounted, the last phase of system shutdown is to remount the root filesystem readonly, it is possible that this is not working. If you are running a redhat based system, then look at /etc/rc.d/init.d/halt for this code: #echo "Remounting remaining filesystems (if any) readonly" mount | awk '/ext2/ { print $3 }' | while read line; do mount -n -o ro,remount $line done Try adding: mount | awk '/xfs/ { print $3 }' | while read line; do mount -n -o ro,remount $line done and see if that helps. I think someone else also reported that devfs was getting in the way during shutdown. Steve p.s. this was cut and pasted from the archive since we had an email outage here and I didn't actually get this message. From owner-linux-xfs@oss.sgi.com Fri Jun 1 14:55:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51LtM523741 for linux-xfs-outgoing; Fri, 1 Jun 2001 14:55:22 -0700 Received: from mtiwmhc28.worldnet.att.net (mtiwmhc28.worldnet.att.net [204.127.131.36]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51LtLh23737 for ; Fri, 1 Jun 2001 14:55:21 -0700 Received: from 233.newark-18-19rs.nj.dial-access.att.net ([12.89.135.233]) by mtiwmhc28.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010601215455.QYVZ2093.mtiwmhc28.worldnet.att.net@233.newark-18-19rs.nj.dial-access.att.net> for ; Fri, 1 Jun 2001 21:54:55 +0000 Received: from photino.sid.rice.edu (mail@localhost [127.0.0.1]) by localhost (8.12.0.Beta10/8.12.0.Beta10/Debian 8.12.0.Beta10-1) with ESMTP id f51LiIZB002404 for ; Fri, 1 Jun 2001 17:44:18 -0400 Received: (from rjain@localhost) by photino.sid.rice.edu (8.12.0.Beta10/8.12.0.Beta10/Debian 8.12.0.Beta10-1) id f51LFHCr002154 for linux-xfs@oss.sgi.com; Fri, 1 Jun 2001 17:15:17 -0400 Date: Fri, 1 Jun 2001 17:15:17 -0400 From: Rahul Jain To: linux-xfs@oss.sgi.com Subject: Guaranteed datarate (Was: Re: does it work on 2.4.4) Message-ID: <20010601171517.B2037@rice.edu> Reply-To: Rahul Jain Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010601145220.D4150@ysabell.wh.vaih> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Jun 01, 2001 at 02:52:20PM +0200, Marcelo E. Magallon wrote: > > The other day I was looking at this. I learned that the XFS patch > includes: > * Guaranteed datarate Is there any chance that I can get cdrecord and cdrdao to use this feature? Burns seem to go fine even at 8x now, but a little extra security can't hurt. -- -> -/- - Rahul Jain - -\- <- -> -\- http://linux.rice.edu/~rahul -=- mailto:rahul-jain@usa.net -/- <- -> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <- |--|--------|--------------|----|-------------|------|---------|-----|-| Version 11.423.999.220020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request. From owner-linux-xfs@oss.sgi.com Fri Jun 1 17:16:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f520GC316804 for linux-xfs-outgoing; Fri, 1 Jun 2001 17:16:12 -0700 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f520GBh16797 for ; Fri, 1 Jun 2001 17:16:11 -0700 Received: from localhost (austin@localhost) by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f520DHx04695; Fri, 1 Jun 2001 19:13:17 -0500 X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs Date: Fri, 1 Jun 2001 19:13:17 -0500 (CDT) From: Austin Gonyou To: Rahul Jain cc: Subject: Re: Guaranteed datarate (Was: Re: does it work on 2.4.4) In-Reply-To: <20010601171517.B2037@rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hells' yeah. with XFS, I can burn a CD, while playing MP3's and using mozilla all at the same time, and after a little hdparm tweakage, I almost never go below 90% in the buffer. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com On Fri, 1 Jun 2001, Rahul Jain wrote: > > On Fri, Jun 01, 2001 at 02:52:20PM +0200, Marcelo E. Magallon wrote: > > > > The other day I was looking at this. I learned that the XFS patch > > includes: > > > * Guaranteed datarate > > > Is there any chance that I can get cdrecord and cdrdao to use this feature? > Burns seem to go fine even at 8x now, but a little extra security can't hurt. > > From owner-linux-xfs@oss.sgi.com Sat Jun 2 01:22:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f528Msa02857 for linux-xfs-outgoing; Sat, 2 Jun 2001 01:22:54 -0700 Received: from bbnmg1.net.external.hp.com (bbnmg1.net.external.hp.com [192.6.76.73]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f528Mnh02833 for ; Sat, 2 Jun 2001 01:22:53 -0700 Received: from isoit213.bbn.hp.com (isoit213.bbn.hp.com [15.136.193.32]) by bbnmg1.net.external.hp.com (Postfix) with ESMTP id 9F13A54; Sat, 2 Jun 2001 10:22:44 +0200 (METDST) Received: from meuse.BELGIUM.HP.COM (meuse.belgium.hp.com [15.160.6.250]) by isoit213.bbn.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id KAA28067; Sat, 2 Jun 2001 10:22:42 +0200 (METDST) Received: from 15.160.6.250 by meuse.BELGIUM.HP.COM (InterScan E-Mail VirusWall NT); Sat, 02 Jun 2001 10:22:42 +0200 (W. Europe Daylight Time) Received: by meuse.belgium.hp.com with Internet Mail Service (5.5.2653.19) id ; Sat, 2 Jun 2001 10:22:42 +0200 Message-ID: From: "SCHOENWETTER,SEBASTIAN (HP-Belgium,ex1)" To: "'Austin Gonyou'" , Rahul Jain Cc: linux-xfs@oss.sgi.com Subject: RE: Guaranteed datarate (Was: Re: does it work on 2.4.4) Date: Sat, 2 Jun 2001 10:22:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk But is that due to a good CPU which is able to handle all those tasks, good scsi setup, ... ? I do not see the value of XFS in this matter, MP3 and Mozilla or CPU/Memory intensive applications no ? -----Oorspronkelijk bericht----- Van: Austin Gonyou [mailto:austin@coremetrics.com] Verzonden: zaterdag 2 juni 2001 2:13 Aan: Rahul Jain CC: linux-xfs@oss.sgi.com Onderwerp: Re: Guaranteed datarate (Was: Re: does it work on 2.4.4) Hells' yeah. with XFS, I can burn a CD, while playing MP3's and using mozilla all at the same time, and after a little hdparm tweakage, I almost never go below 90% in the buffer. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com On Fri, 1 Jun 2001, Rahul Jain wrote: > > On Fri, Jun 01, 2001 at 02:52:20PM +0200, Marcelo E. Magallon wrote: > > > > The other day I was looking at this. I learned that the XFS patch > > includes: > > > * Guaranteed datarate > > > Is there any chance that I can get cdrecord and cdrdao to use this feature? > Burns seem to go fine even at 8x now, but a little extra security can't hurt. > > From owner-linux-xfs@oss.sgi.com Sat Jun 2 04:38:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f52BcPw04009 for linux-xfs-outgoing; Sat, 2 Jun 2001 04:38:25 -0700 Received: from studsv07.studserv.uni-stuttgart.de (studsv07.studserv.uni-stuttgart.de [129.69.21.37]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f52BcOh03998 for ; Sat, 2 Jun 2001 04:38:24 -0700 Received: from ysabell.wh.vaih [129.69.166.244] by studsv07.studserv.uni-stuttgart.de with ESMTP (SMTPD32-6.06) id AFC219A50364; Sat, 02 Jun 2001 13:36:34 +0200 Received: from marcelo by ysabell.wh.vaih with local (Exim 3.22 #1 (Debian)) id 1569hr-0000KK-00; Sat, 02 Jun 2001 13:36:35 +0200 Date: Sat, 2 Jun 2001 13:36:35 +0200 From: "Marcelo E. Magallon" To: "SCHOENWETTER,SEBASTIAN (HP-Belgium,ex1)" Cc: "'Austin Gonyou'" , Rahul Jain , linux-xfs@oss.sgi.com Subject: Re: Guaranteed datarate (Was: Re: does it work on 2.4.4) Message-ID: <20010602133635.A914@ysabell.wh.vaih> Mail-Followup-To: "SCHOENWETTER,SEBASTIAN (HP-Belgium,ex1)" , 'Austin Gonyou' , Rahul Jain , linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i X-Operating-System: Linux ysabell 2.4.4-xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> "SCHOENWETTER,SEBASTIAN (HP-Belgium,ex1)" writes: > But is that due to a good CPU which is able to handle all those > tasks, good scsi setup, ... ? That's likely. Guaranteed rate I/O (GRIO) works only with XFS filesystems (this is true on IRIX) and not on Linux. Just to clarify: Someone asked why the XFS patch is so large. I just said the XFS patch also includes some GRIO stuff. I didn't mean to say that the feature is implemented on Linux (in fact, it's not, if you use the corresponding ioctl it will return ENOSYS). Remember that XFS is not Linux specific, and it'd be a nightmare to maintain two completely different source trees, one for Linux and one for IRIX. -- Marcelo From owner-linux-xfs@oss.sgi.com Sat Jun 2 10:21:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f52HLus18341 for linux-xfs-outgoing; Sat, 2 Jun 2001 10:21:56 -0700 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f52HLth18338 for ; Sat, 2 Jun 2001 10:21:56 -0700 Received: from localhost (austin@localhost) by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f52HEh211188; Sat, 2 Jun 2001 12:14:43 -0500 X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs Date: Sat, 2 Jun 2001 12:14:42 -0500 (CDT) From: Austin Gonyou To: "Marcelo E. Magallon" cc: "SCHOENWETTER,SEBASTIAN (HP-Belgium,ex1)" , Rahul Jain , Subject: Re: Guaranteed datarate (Was: Re: does it work on 2.4.4) In-Reply-To: <20010602133635.A914@ysabell.wh.vaih> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Points well taken! -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com On Sat, 2 Jun 2001, Marcelo E. Magallon wrote: > >> "SCHOENWETTER,SEBASTIAN (HP-Belgium,ex1)" writes: > > > But is that due to a good CPU which is able to handle all those > > tasks, good scsi setup, ... ? > > That's likely. Guaranteed rate I/O (GRIO) works only with XFS > filesystems (this is true on IRIX) and not on Linux. > > Just to clarify: Someone asked why the XFS patch is so large. I just > said the XFS patch also includes some GRIO stuff. I didn't mean to say > that the feature is implemented on Linux (in fact, it's not, if you use > the corresponding ioctl it will return ENOSYS). Remember that XFS is > not Linux specific, and it'd be a nightmare to maintain two completely > different source trees, one for Linux and one for IRIX. > > From owner-linux-xfs@oss.sgi.com Sat Jun 2 10:20:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f52HK3r18280 for linux-xfs-outgoing; Sat, 2 Jun 2001 10:20:03 -0700 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f52HK2h18277 for ; Sat, 2 Jun 2001 10:20:02 -0700 Received: from localhost (austin@localhost) by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f52HDjo11180; Sat, 2 Jun 2001 12:13:46 -0500 X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs Date: Sat, 2 Jun 2001 12:13:45 -0500 (CDT) From: Austin Gonyou To: "SCHOENWETTER,SEBASTIAN (HP-Belgium,ex1)" cc: Rahul Jain , Subject: RE: Guaranteed datarate (Was: Re: does it work on 2.4.4) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk MP3= Decoding : uses Cpu about 15% Mozilla= Java : uses cpu about 5-25%, uses more RAM than anything else Burning= IO/Memory/CPU utilization : my CPU while burning and nothing else is about 5-20% depending on how much IO is going on. Memory utilization is about 20M, not much, but constant. Considering I have good harware and all I'd expect it to be the case that it's just a lot of good hardware working well. However, without any tweaks applied to my hardware, running on ext2, and attempting the same thing, I almost get to about 65% FIFO all the time with the same setup. No tweaks and XFS yeilds about 85% all the time, and Tweaks with XFS yields about 90-100% all the time. So I'd say there's something to it for sure. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com On Sat, 2 Jun 2001, SCHOENWETTER,SEBASTIAN (HP-Belgium,ex1) wrote: > But is that due to a good CPU which is able to handle all those tasks, good > scsi setup, ... ? > > I do not see the value of XFS in this matter, MP3 and Mozilla or CPU/Memory > intensive applications no ? > > -----Oorspronkelijk bericht----- > Van: Austin Gonyou [mailto:austin@coremetrics.com] > Verzonden: zaterdag 2 juni 2001 2:13 > Aan: Rahul Jain > CC: linux-xfs@oss.sgi.com > Onderwerp: Re: Guaranteed datarate (Was: Re: does it work on 2.4.4) > > > Hells' yeah. with XFS, I can burn a CD, while playing MP3's and using > mozilla all at the same time, and after a little hdparm tweakage, I almost > never go below 90% in the buffer. > > From owner-linux-xfs@oss.sgi.com Sat Jun 2 13:10:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f52KA3L21269 for linux-xfs-outgoing; Sat, 2 Jun 2001 13:10:03 -0700 Received: from proxy.lpconsul.net (IDENT:root@[62.110.183.14]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f52KA1h21266 for ; Sat, 2 Jun 2001 13:10:02 -0700 Received: from lpconsul.net (wopr.lpconsul.net [62.110.183.2]) by proxy.lpconsul.net (8.11.0/8.8.7) with ESMTP id f52L9Cc00766 for ; Sat, 2 Jun 2001 21:09:12 GMT Message-ID: <3B199D06.4050000@lpconsul.net> Date: Sat, 02 Jun 2001 22:12:22 -0400 From: Piergiorgio Betti Organization: LP Consulting User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-7jld i686; en-US; 0.8.1) Gecko/20010328 X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: A new distro with a new filesystem Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi XFS folks. I hope you'll be glad to know that a new italian distribution called J-Linux (based on Mandrake) include full support for XFS, which is the filesystem installed by default. Packages are available at ftp://ftp.j-linux.it/pub/jld. So, thanks to all for this great piece of software. With my best regards. Piergiorgio Betti From owner-linux-xfs@oss.sgi.com Sun Jun 3 09:25:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f53GP1004990 for linux-xfs-outgoing; Sun, 3 Jun 2001 09:25:01 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f53GP0h04987 for ; Sun, 3 Jun 2001 09:25:00 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f53GOhaJ096614; Sun, 3 Jun 2001 11:24:43 -0500 (CDT) Message-ID: <3B1A64C5.AF1D7DDA@thebarn.com> Date: Sun, 03 Jun 2001 11:24:38 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: "Klaus Strebel,ITS,204" , linux-xfs@oss.sgi.com Subject: Re: Hanging around with 2.4.5-xfs from cvs References: <7922.991409390@ocs3.ocs-net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: And of course the question to ask which version of the compiler are you using? I've had problems with kdb and everything but 2.91.66 for the compiler. Although it never failed to boot. > On Fri, 01 Jun 2001 16:35:07 +0200, > "Klaus Strebel,ITS,204" wrote: > >yesterday i updated my linux-2.4-xfs cvs-tree (after waiting anxiously > >for oss.sgi.com to be reachable again, sigh :-) ), compliled it, > >installed it, booted and ... by box kept hanging at the 'ifconfig lo > >127.0.0.1 netmask 255.0.0.0 dev lo'. I unconfigured START_LOOPBACK (i'm > >using SuSE 7. almost 1, couldn't find a way to do the SuSE-upgrade > >procedure with a xfs-enabled kernel, only / and /boot are ext2), tried > >it again, an by box hang at loading the next network driver :-(. > > > >So i downloaded linux-2.4.5-xfs-05312001.patch.bz2 from oss.sgi.com, > >removed everything not necessary for xfs from it (kernel debugger, > >ac-patch things, lvm upgrades - upgraded myself to 0.9.1beta7 ...) and > >no it works! Is KDB broken ?? > > Works for me :). This is top of tree as of Fri Jun 1 15:10:23 UTC > 2001, configured with xfs and kdb. > > Linux ocs4 2.4.5-xfs #1 SMP Sat Jun 2 01:10:01 EST 2001 i686 unknown > > Entering non-interactive startup > Setting network parameters: [ OK ] > Bringing up interface lo: [ OK ] > Bringing up interface eth0: [ OK ] > > Your problem sounds like a generic network problem, not XFS. There > have been some recent patches by Jeff Garzick for timing related > problems with network drivers on 2.4.5. Try linux-kernel. -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Sun Jun 3 09:34:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f53GYPe05365 for linux-xfs-outgoing; Sun, 3 Jun 2001 09:34:25 -0700 Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f53GYOh05362 for ; Sun, 3 Jun 2001 09:34:24 -0700 Received: (qmail 19021 invoked by uid 0); 3 Jun 2001 16:34:17 -0000 Received: from f-83-209.cvx-koln.ipdial.viaginterkom.de (HELO gmx.de) (62.180.209.83) by mail.gmx.net (mail01) with SMTP; 3 Jun 2001 16:34:17 -0000 Message-ID: <3B1A672C.8E98B355@gmx.de> Date: Sun, 03 Jun 2001 18:34:52 +0200 From: Martin Stricker Organization: http://martin-stricker.de/ http://www.surfo.net/ http://www.masterportal24.com/cgi-bin/YaBB.cgi X-Mailer: Mozilla 4.75 [en]C-CCK-MCD BDP81800 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: redhat 7.1 References: <200106011732.f51HWa721084@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > Actually, the examples given on this page do not apply to xfs, what > does appear to be the case with xfs is that it exercises the 64 bit > handling of the compiler more than most things do. 90% of the code > base is also the Irix code which works just fine with the SGI > compilers on a 64 bit architecture. > > The challenging problem is going from a kernel that crashes due to > code not being compiled as expected, to finding the line of code in > the 122 thousand lines which make up XFS and it support code (comments > not stripped in that number). > > Oh and add to that the fact that some build types seem to run fine and > some do not, that suggests bad code generation to me. I stand corrected. > Unfortunately, getting to the bottom of this is a big task, and there > are compilers which are: > > a) still the recommended kernel compiler > b) do not exhibit problems with xfs. a) is true in RHL 7.0 only, because kernel 2.2.x doesn't compile with gcc 2.96-RH due to problems found in http://www.bero.org/gcc296.html . Kernel 2.4.x which is used in RHL 7.1 does compile nicely with gcc 2.96-RH. Therefore the old gcc is no longer called kgcc but is found in the package egcs-compat. But I don't know what happend if you do an upgrade, maybe kgcc still remains. Best regards, Martin Stricker -- Homepage: http://www.martin-stricker.de/ Registered Linux user #210635: http://counter.li.org/ From owner-linux-xfs@oss.sgi.com Sun Jun 3 09:49:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f53GnZ005928 for linux-xfs-outgoing; Sun, 3 Jun 2001 09:49:35 -0700 Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f53GnYh05924 for ; Sun, 3 Jun 2001 09:49:34 -0700 Received: from darkstar.ee.washington.edu (darkstar.ee.washington.edu [128.95.196.85]) by maxwell.ee.washington.edu (8.12.0.Beta7/8.12.0) with ESMTP id f53GnYWc017658 for ; Sun, 3 Jun 2001 09:49:34 -0700 Date: Sun, 3 Jun 2001 09:49:33 -0700 (PDT) From: To: linux-xfs@oss.sgi.com Subject: permission problems.. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am using the latest CVS tree, one from Friday, and I noticed a strange problem. Every once in a while permissions get reset for some directories, I mean all permissions are removed. Has anyone noticed this problem and is this XFS related? ***************************** Walter Marchuk Senior Computer Specialist University of Washington Electrical Engineering Room: 307g 206-221-5421 marchuk@ee.washington.edu ***************************** From owner-linux-xfs@oss.sgi.com Sun Jun 3 10:37:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f53HbVQ06726 for linux-xfs-outgoing; Sun, 3 Jun 2001 10:37:31 -0700 Received: from wisdom.myplace.net (cc19815-a.zwoll1.ov.nl.home.com [212.204.138.247]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f53HbTh06723 for ; Sun, 3 Jun 2001 10:37:30 -0700 Received: from ws1 (ws1.myplace.net [192.168.1.15]) by wisdom.myplace.net (Postfix) with SMTP id CCD8A2008B for ; Sun, 3 Jun 2001 18:44:31 +0200 (CEST) Message-ID: <005e01c0ec4c$713c49e0$0f01a8c0@ws1> From: "Bas" To: Subject: 2.4.5 & Adaptec 7890 U2W Controller. Date: Sun, 3 Jun 2001 18:44:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I read this is an general 2.4.5 issue and I should contact the maintainer. But does anybody know if it has been fixed already and where I can get the patch. An URL would be great ! Thanks, Bas. From owner-linux-xfs@oss.sgi.com Sun Jun 3 16:41:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f53NfAj17675 for linux-xfs-outgoing; Sun, 3 Jun 2001 16:41:10 -0700 Received: from babel.spoiled.org (babel.spoiled.org [212.84.234.227]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f53Nf8h17672 for ; Sun, 3 Jun 2001 16:41:08 -0700 Received: (qmail 28849 invoked by uid 8); 3 Jun 2001 23:41:06 -0000 From: Juri Haberland Reply-To: Juri Haberland X-Newsgroups: spoiled.linux.sgi.xfs Subject: Re: redhat 7.1 Date: Sun, 3 Jun 2001 23:41:06 +0000 (UTC) Organization: spoiled dot org Lines: 32 Distribution: local Message-ID: References: <200106011732.f51HWa721084@jen.americas.sgi.com> <3B1A672C.8E98B355@gmx.de> X-Complaints-To: newsmaster@spoiled.org User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (OpenBSD/2.9 (i386)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Martin Stricker wrote: > Steve Lord wrote: >> are compilers which are: >> >> a) still the recommended kernel compiler >> b) do not exhibit problems with xfs. > > a) is true in RHL 7.0 only, because kernel 2.2.x doesn't compile with > gcc 2.96-RH due to problems found in http://www.bero.org/gcc296.html . > Kernel 2.4.x which is used in RHL 7.1 does compile nicely with gcc > 2.96-RH. Therefore the old gcc is no longer called kgcc but is found in > the package egcs-compat. But I don't know what happend if you do an > upgrade, maybe kgcc still remains. Well, kgcc is still called kgcc and is in the package compat-egcs. Concerning the compile issues you mentioned I had a very interesting expierence: Kernel 2.4.3 and newer doesn't do the network auto media detection right using the 3c59x driver if compiled with gcc 2.96. If I use the kgcc from the compat-egcs package it works without a problem. It took me a loooong time to realize that it isn't a kernel nor a user issue... Let's all say: I will never compile my kernel with anything other than egcs! Juri -- Juri Haberland From owner-linux-xfs@oss.sgi.com Sun Jun 3 18:44:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f541iOT29968 for linux-xfs-outgoing; Sun, 3 Jun 2001 18:44:24 -0700 Received: from digitaltux.com (zoltan@24.68.90.83.on.wave.home.com [24.68.90.83]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f541iNh29965 for ; Sun, 3 Jun 2001 18:44:23 -0700 Received: from zoltan by digitaltux.com with local (Exim 3.22 #1 (Debian)) id 156jPe-0000MD-00 for ; Sun, 03 Jun 2001 21:44:10 -0400 Date: Sun, 3 Jun 2001 21:44:10 -0400 To: linux-xfs@oss.sgi.com Subject: Debian Woody XFS Install Disks Message-ID: <20010603214410.A1369@digitaltux.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline User-Agent: Mutt/1.3.18i From: "Zoltan D. Kraus" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Yup, they are finally here, very experimental and not recommended for critical machines (because of the nature of woody). Please use them with caution =D url: http://markybobdeb.sourceforge.net/zoltan or http://debianboot.digitaltux.com Scroll to the very bottom and you shall see the notes - Zoltan Kraus P.S. Sourceforge is having technical difficulities, if no files appear, refresh it a couple of times. --/04w6evG8XlLl3ft 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 iD8DBQE7Gufqp0iq+lfR+9YRAnDYAJ9QTzFR51Q/8jz7UZYWDcmpTL9OkwCePZSs OTxU7gU5rWe+xVcw9C+NuzE= =epz2 -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From owner-linux-xfs@oss.sgi.com Sun Jun 3 23:32:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f546WVZ07497 for linux-xfs-outgoing; Sun, 3 Jun 2001 23:32:31 -0700 Received: from beauty.binarix.com (beauty.binarix.com [203.41.202.9]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f546WSh07486 for ; Sun, 3 Jun 2001 23:32:29 -0700 Received: from meowth.binarix.com (meowth.binarix.com [10.0.0.10]) by beauty.binarix.com (8.9.3/8.9.3) with ESMTP id QAA14791 for ; Mon, 4 Jun 2001 16:53:24 +1000 Received: from binarix.com (beast.binarix.com [10.0.0.20]) by meowth.binarix.com (8.9.3/8.9.3) with ESMTP id QAA23494 for ; Mon, 4 Jun 2001 16:55:42 +1000 Message-ID: <3B1B2C4D.B124282E@binarix.com> Date: Mon, 04 Jun 2001 16:35:57 +1000 From: Bojan Smojver Organization: Binarix Corporation Pty Ltd X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS in kernel tree Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk First, a thank you note to all people at SGI that were involved with XFS and made it possible under Linux! Great stuff! Any idea when XFS is going to become an official part of the 2.4 kernel tree? Bojan From owner-linux-xfs@oss.sgi.com Sun Jun 3 23:45:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f546jYt09599 for linux-xfs-outgoing; Sun, 3 Jun 2001 23:45:34 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f546jWh09594 for ; Sun, 3 Jun 2001 23:45:33 -0700 Received: (qmail 11487 invoked from network); 4 Jun 2001 06:45:28 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 4 Jun 2001 06:45:28 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Bojan Smojver cc: linux-xfs@oss.sgi.com Subject: Re: XFS in kernel tree In-reply-to: Your message of "Mon, 04 Jun 2001 16:35:57 +1000." <3B1B2C4D.B124282E@binarix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Jun 2001 16:45:27 +1000 Message-ID: <26020.991637127@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 04 Jun 2001 16:35:57 +1000, Bojan Smojver wrote: >Any idea when XFS is going to become an official part of the 2.4 kernel >tree? It depends on Linus, who is travelling at the moment. From owner-linux-xfs@oss.sgi.com Mon Jun 4 02:10:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f549AHB24670 for linux-xfs-outgoing; Mon, 4 Jun 2001 02:10:17 -0700 Received: from yowie.cc.uq.edu.au (root@yowie.cc.uq.edu.au [130.102.2.2]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f549AEh24665 for ; Mon, 4 Jun 2001 02:10:15 -0700 Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1]) by yowie.cc.uq.edu.au (8.9.3/8.9.3) with ESMTP id TAA23417; Mon, 4 Jun 2001 19:10:05 +1000 (GMT+1000) Received: from nut.csee.uq.edu.au (nut.csee.uq.edu.au [130.102.66.13]) by gum.csee.uq.edu.au (8.11.3/8.11.3) with ESMTP id f549A2508191; Mon, 4 Jun 2001 19:10:03 +1000 (EST) Received: from mango.csee.uq.edu.au (mango.csee.uq.edu.au [130.102.66.4]) by nut.csee.uq.edu.au (8.11.3/8.11.3) with ESMTP id f549A2o00584; Mon, 4 Jun 2001 19:10:02 +1000 (EST) Date: Mon, 4 Jun 2001 19:10:02 +1000 (EST) From: Chris Pascoe To: Steve Lord cc: Subject: Re: Crashes in various ext2 functions while running xfstest/check In-Reply-To: <200105241434.f4OEY6214966@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 1.1 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve, Further to my last emails on this, I think I've tracked down why the crashes occur, but don't know how to fix it. I eliminated the scsi hardware, ethernet card, etc, that Seth Mos suggested might be the problem (got loans of completely different hardware). I can reliably crash my test machine in under an hour by running test 013 in a loop, and letting the "/etc/cron.hourly/sysstat" cron job run. Doing some random other commands during the process helps speed the crash up. The crashes I see are related to the machine having highmem support, and buffers allocated with pages in high memory making their way onto the (fs/buffer.c) free_list. I added an extra field to struct buffer_head that records in the buffer head who created it (in create_empty_buffers), and what function called put_last_free. In every instance, the buffer_head that causes the crash was created by hook_buffers_to_page_delay, and put onto the free list later by a call to __invalidate_buffers. (Adding code to record in the bh who called that.... done.... crashed, - the caller was blkdev_put this time, but I'll run a few more tests). When one of these bh's with bh->b_page in high memory is given to ext2 by getblk, and a "bread" performed, bh->b_data gets set to values < PAGE_SIZE by a call to set_bh_page. This is why it looked like the bh's were corrupted in my previous backtraces. The actual disk IO that was performed on these pages proceeds okay though, as ll_rw_blk() does create_bounce's for the real disk I/O (which is why the dereferences you saw came after a successful call to bread). I can seemingly (no crashes after a weekend of repeats) make the crashes go away by replacing GFP_HIGHUSER with GFP_USER in clean_inode (fs/inode.c), and _pagebuf_lookup_pages (fs/pagebuf/page_buf.c). Changing one alone doesn't make any difference. Hope that this makes some sense to you, and you can just say aha, and wave the magic wand :). I hope you can replicate it locally with this information. Regards, Chris From owner-linux-xfs@oss.sgi.com Mon Jun 4 02:56:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f549usD30415 for linux-xfs-outgoing; Mon, 4 Jun 2001 02:56:54 -0700 Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f549ukh30400 for ; Mon, 4 Jun 2001 02:56:47 -0700 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.2/8.11.2) with ESMTP id f549tpZ10070 for ; Mon, 4 Jun 2001 11:55:51 +0200 Date: Mon, 4 Jun 2001 11:55:51 +0200 (CEST) From: Matteo Centonza To: Subject: LVM+RAID5 Oops on snapshot creation Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1702689938-1161906648-991648551=:9508" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1702689938-1161906648-991648551=:9508 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, thanks again for this great filesystem. I'm running CVS code (2.4.5) as of 2001-05-30 patched with: - VFS lock patch - LVM 0.9.1beta7 - rw SNAPSHOT patch (Dale Stephenson, 2001-05-21) I've also applied changes in lvm.c (get_hardsect_size). I'm running LVM on top of RAID 5 array (XFS, no mkfs options used, QUOTA enabled) of three disks: WDC AC36400L (6.4 Gb) QUANTUM FIREBALL540A (540 Mb) QUANTUM LP120A GM120A01X (120 Mb) on a dual channel controller (ASUS P2B motherboard, Celeron). The system seems to be very stable, even under heavy load, mixing local and remote access, except for the snapshot that triggers the Oops in attachment. This problem seems not to affect a bare LVM configuration. I've also tested with ext2 and seems to run fine. Hope this helps, Ciao -m ---1702689938-1161906648-991648551=:9508 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="lvm-snap.ksymoops" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="lvm-snap.ksymoops" SnVuICAxIDIwOjU2OjIzIHNwZWVkc3RlciBrZXJuZWw6IFVuYWJsZSB0byBo YW5kbGUga2VybmVsIHBhZ2luZyByZXF1ZXN0IGF0IHZpcnR1YWwgYWRkcmVz cyAxNDAwMDAwMA0KSnVuICAxIDIwOjU2OjIzIHNwZWVkc3RlciBrZXJuZWw6 ICBwcmludGluZyBlaXA6DQpKdW4gIDEgMjA6NTY6MjMgc3BlZWRzdGVyIGtl cm5lbDogYzAyODZmMDkNCkp1biAgMSAyMDo1NjoyMyBzcGVlZHN0ZXIga2Vy bmVsOiAqcGRlID0gMDAwMDAwMDANCkp1biAgMSAyMDo1NjoyMyBzcGVlZHN0 ZXIga2VybmVsOiBPb3BzOiAwMDAyDQpKdW4gIDEgMjA6NTY6MjMgc3BlZWRz dGVyIGtlcm5lbDogQ1BVOiAgICAwDQpKdW4gIDEgMjA6NTY6MjMgc3BlZWRz dGVyIGtlcm5lbDogRUlQOiAgICAwMDEwOltyZW1vdmVfaGFzaCsyNS80OF0N Ckp1biAgMSAyMDo1NjoyMyBzcGVlZHN0ZXIga2VybmVsOiBFSVA6ICAgIDAw MTA6WzxjMDI4NmYwOT5dDQpKdW4gIDEgMjA6NTY6MjMgc3BlZWRzdGVyIGtl cm5lbDogRUZMQUdTOiAwMDAxMDA0Ng0KSnVuICAxIDIwOjU2OjIzIHNwZWVk c3RlciBrZXJuZWw6IGVheDogMDAwMDAwMDAgICBlYng6IDAwMDAwMDAxICAg ZWN4OiBjM2RiYmMwMCAgIGVkeDogMTQwMDAwMDANCkp1biAgMSAyMDo1Njoy MyBzcGVlZHN0ZXIga2VybmVsOiBlc2k6IGMxMTNlYzAwICAgZWRpOiBjMzZm MGJhMCAgIGVicDogMDAwMDAwMDAgICBlc3A6IGMzZmMxYzZjDQpKdW4gIDEg MjA6NTY6MjMgc3BlZWRzdGVyIGtlcm5lbDogZHM6IDAwMTggICBlczogMDAx OCAgIHNzOiAwMDE4DQpKdW4gIDEgMjA6NTY6MjMgc3BlZWRzdGVyIGtlcm5l bDogUHJvY2VzcyBrdXBkYXRlZCAocGlkOiA3LCBzdGFja3BhZ2U9YzNmYzEw MDApDQpKdW4gIDEgMjA6NTY6MjMgc3BlZWRzdGVyIGtlcm5lbDogU3RhY2s6 IGMwMjg3MGI2IGMzZGJiYzAwIDAwMDAwMjAwIGMxMTNlYzAwIGMwMjg3MzA4 IGMxMTNlYzAwIGMzZmMxYzg4IGMwMjkyY2RkIA0KSnVuICAxIDIwOjU2OjIz IHNwZWVkc3RlciBrZXJuZWw6ICAgICAgICBjMTUyNzgwMCBjM2ZjMDAwMCAw MDAzMzhmMyBjMDI5MmNlZiBjMzI3ODAwMCBjMTUyNzgwMCAwMDAwMDA0MCAw MDAwMDAzMyANCkp1biAgMSAyMDo1NjoyMyBzcGVlZHN0ZXIga2VybmVsOiAg ICAgICAgYzExM2VjMDAgMDAwMDAwMDEgYzExM2VjMDAgMDAwMDAwMDEgYzM2 ZjBiYTAgMDAwMDAwMDAgYzAyODkwYTIgYzExM2VjMDAgDQpKdW4gIDEgMjA6 NTY6MjMgc3BlZWRzdGVyIGtlcm5lbDogQ2FsbCBUcmFjZTogW3Nocmlua19z dHJpcGVfY2FjaGUrNTQvODBdIFtnZXRfYWN0aXZlX3N0cmlwZSs0NzIvMTMy OF0gW2x2bV9tYXArMTA4NS8xMjgwXSBbbHZtX21hcCsxMTAzLzEyODBdIFty YWlkNV9tYWtlX3JlcXVlc3QrODIvMTYwXSBbbWRfbWFrZV9yZXF1ZXN0Kzc3 LzEyOF0gW2x2bV9tYWtlX3JlcXVlc3RfZm4rMTUvMzJdIA0KSnVuICAxIDIw OjU2OjIzIHNwZWVkc3RlciBrZXJuZWw6IENhbGwgVHJhY2U6IFs8YzAyODcw YjY+XSBbPGMwMjg3MzA4Pl0gWzxjMDI5MmNkZD5dIFs8YzAyOTJjZWY+XSBb PGMwMjg5MGEyPl0gWzxjMDI4YzJjZD5dIFs8YzAyOTJkYWY+XSANCkp1biAg MSAyMDo1NjoyMyBzcGVlZHN0ZXIga2VybmVsOiAgICAgICAgW2dlbmVyaWNf bWFrZV9yZXF1ZXN0KzI3NC8zMDRdIFtlbmRfdGhhdF9yZXF1ZXN0X2ZpcnN0 KzEyMy8yMDhdIFtfcGFnZWJ1Zl9wYWdlX2lvKzU0My83MzZdIFt4bG9nX3N0 YXRlX3JlbGVhc2VfaWNsb2crMzMvMTc2XSBbX3BhZ2VfYnVmX3BhZ2VfYXBw bHkrNDM5LzQ2NF0gW3BhZ2VidWZfc2VnbWVudF9hcHBseSsxMjgvMjI0XSBb cGFnZWJ1Zl9pb3JlcXVlc3QrMjU0LzMzNl0gW19wYWdlX2J1Zl9wYWdlX2Fw cGx5KzAvNDY0XSANCkp1biAgMSAyMDo1NjoyMyBzcGVlZHN0ZXIga2VybmVs OiAgICAgICAgWzxjMDI0MzUxMj5dIFs8YzAyNDM5MGI+XSBbPGMwMWIzMThm Pl0gWzxjMDIwMzZlMT5dIFs8YzAxYjM0MDc+XSBbPGMwMWIzODkwPl0gWzxj MDFiMzUxZT5dIFs8YzAxYjMyNTA+XSANCkp1biAgMSAyMDo1NjoyMyBzcGVl ZHN0ZXIga2VybmVsOiAgICAgICAgW3hsb2dfYmRzdHJhdF9jYisyMC82NF0g W3hsb2dfc3luYyszNzUvODQ4XSBbX19tYWtlX3JlcXVlc3QrMjk4LzE2ODBd IFt4ZnNfdHJhbnNfdGFpbF9haWwrMTcvNDhdIFt4bG9nX2Fzc2lnbl90YWls X2xzbisyNy8xNDRdIFt4bG9nX3N0YXRlX3JlbGVhc2VfaWNsb2crMTQ4LzE3 Nl0gW3hsb2dfc3RhdGVfc3luY19hbGwrMTg4LzM1Ml0gW3hmc19sb2dfZm9y Y2UrNTcvOTZdIA0KSnVuICAxIDIwOjU2OjIzIHNwZWVkc3RlciBrZXJuZWw6 ICAgICAgICBbPGMwMjAxYzA0Pl0gWzxjMDIwMjMxNz5dIFs8YzAyNDJlOWE+ XSBbPGMwMjBlNWExPl0gWzxjMDIwMWFiYj5dIFs8YzAyMDM3NTQ+XSBbPGMw MjAzOGFjPl0gWzxjMDIwMTUyOT5dIA0KSnVuICAxIDIwOjU2OjIzIHNwZWVk c3RlciBrZXJuZWw6ICAgICAgICBbeGZzX3N5bmNzdWIrMjI3LzI5NzZdIFtz dGFydF9yZXF1ZXN0KzM4NC80OTZdIFtzY2hlZHVsZSs2MTkvOTQ0XSBbeGZz X3N5bmMrMjEvMzJdIFtsaW52ZnNfd3JpdGVfc3VwZXIrMzkvNDhdIFtzeW5j X3N1cGVycysxMTEvMTQ0XSBbc3luY19vbGRfYnVmZmVycysxMC82NF0gW2t1 cGRhdGUrMjI2LzI0MF0gDQpKdW4gIDEgMjA6NTY6MjMgc3BlZWRzdGVyIGtl cm5lbDogICAgICAgIFs8YzAyMTE3ZDM+XSBbPGMwMjY0MWUwPl0gWzxjMDEx MGQ3Yj5dIFs8YzAyMTE2ZTU+XSBbPGMwMjIxY2Y3Pl0gWzxjMDEzM2UxZj5d IFs8YzAxMzJmY2E+XSBbPGMwMTMzMjgyPl0gDQpKdW4gIDEgMjA6NTY6MjMg c3BlZWRzdGVyIGtlcm5lbDogICAgICAgIFtwcmVwYXJlX25hbWVzcGFjZSsw LzE2XSBba2VybmVsX3RocmVhZCszOC80OF0gW2t1cGRhdGUrMC8yNDBdIA0K SnVuICAxIDIwOjU2OjIzIHNwZWVkc3RlciBrZXJuZWw6ICAgICAgICBbPGMw MTA1MDAwPl0gWzxjMDEwNTRiNj5dIFs8YzAxMzMxYTA+XQ0KSnVuICAxIDIw OjU2OjIzIHNwZWVkc3RlciBrZXJuZWw6IA0KSnVuICAxIDIwOjU2OjIzIHNw ZWVkc3RlciBrZXJuZWw6IENvZGU6IDg5IDAyIGM3IDQxIDA0IDAwIDAwIDAw IDAwIGMzIDhkIGI2IDAwIDAwIDAwIDAwIDhkIGJjIDI3IDAwIA0KDQprc3lt b29wcyAyLjQuMCBvbiBpNjg2IDIuNC41LXhmcy0yLiAgT3B0aW9ucyB1c2Vk DQogICAgIC1WIChkZWZhdWx0KQ0KICAgICAtayAvcHJvYy9rc3ltcyAoZGVm YXVsdCkNCiAgICAgLWwgL3Byb2MvbW9kdWxlcyAoZGVmYXVsdCkNCiAgICAg LW8gL2xpYi9tb2R1bGVzLzIuNC41LXhmcy0yLyAoZGVmYXVsdCkNCiAgICAg LW0gL2Jvb3QvU3lzdGVtLm1hcCAoc3BlY2lmaWVkKQ0KDQpObyBtb2R1bGVz IGluIGtzeW1zLCBza2lwcGluZyBvYmplY3RzDQpXYXJuaW5nIChyZWFkX2xz bW9kKTogbm8gc3ltYm9scyBpbiBsc21vZCwgaXMgL3Byb2MvbW9kdWxlcyBh IHZhbGlkIGxzbW9kIGZpbGU/DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBr c3ltc19iYXNlIHN5bWJvbCBfX1ZFUlNJT05FRF9TWU1CT0woc2htZW1fZmls ZV9zZXR1cCkgbm90IGZvdW5kIGluIFN5c3RlbS5tYXAuICBJZ25vcmluZyBr c3ltc19iYXNlIGVudHJ5DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNt YXRjaCBvbiBzeW1ib2wgcGFydGl0aW9uX25hbWUgICwga3N5bXNfYmFzZSBz YXlzIGMwMjhjNGIwLCBTeXN0ZW0ubWFwIHNheXMgYzAxNGViMDAuICBJZ25v cmluZyBrc3ltc19iYXNlIGVudHJ5DQpKdW4gIDEgMjA6NTY6MjMgc3BlZWRz dGVyIGtlcm5lbDogVW5hYmxlIHRvIGhhbmRsZSBrZXJuZWwgcGFnaW5nIHJl cXVlc3QgYXQgdmlydHVhbCBhZGRyZXNzIDE0MDAwMDAwDQpKdW4gIDEgMjA6 NTY6MjMgc3BlZWRzdGVyIGtlcm5lbDogYzAyODZmMDkNCkp1biAgMSAyMDo1 NjoyMyBzcGVlZHN0ZXIga2VybmVsOiAqcGRlID0gMDAwMDAwMDANCkp1biAg MSAyMDo1NjoyMyBzcGVlZHN0ZXIga2VybmVsOiBPb3BzOiAwMDAyDQpKdW4g IDEgMjA6NTY6MjMgc3BlZWRzdGVyIGtlcm5lbDogQ1BVOiAgICAwDQpKdW4g IDEgMjA6NTY6MjMgc3BlZWRzdGVyIGtlcm5lbDogRUlQOiAgICAwMDEwOlty ZW1vdmVfaGFzaCsyNS80OF0NCkp1biAgMSAyMDo1NjoyMyBzcGVlZHN0ZXIg a2VybmVsOiBFSVA6ICAgIDAwMTA6WzxjMDI4NmYwOT5dDQpVc2luZyBkZWZh dWx0cyBmcm9tIGtzeW1vb3BzIC10IGVsZjMyLWkzODYgLWEgaTM4Ng0KSnVu ICAxIDIwOjU2OjIzIHNwZWVkc3RlciBrZXJuZWw6IEVGTEFHUzogMDAwMTAw NDYNCkp1biAgMSAyMDo1NjoyMyBzcGVlZHN0ZXIga2VybmVsOiBlYXg6IDAw MDAwMDAwICAgZWJ4OiAwMDAwMDAwMSAgIGVjeDogYzNkYmJjMDAgICBlZHg6 IDE0MDAwMDAwDQpKdW4gIDEgMjA6NTY6MjMgc3BlZWRzdGVyIGtlcm5lbDog ZXNpOiBjMTEzZWMwMCAgIGVkaTogYzM2ZjBiYTAgICBlYnA6IDAwMDAwMDAw ICAgZXNwOiBjM2ZjMWM2Yw0KSnVuICAxIDIwOjU2OjIzIHNwZWVkc3RlciBr ZXJuZWw6IGRzOiAwMDE4ICAgZXM6IDAwMTggICBzczogMDAxOA0KSnVuICAx IDIwOjU2OjIzIHNwZWVkc3RlciBrZXJuZWw6IFByb2Nlc3Mga3VwZGF0ZWQg KHBpZDogNywgc3RhY2twYWdlPWMzZmMxMDAwKQ0KSnVuICAxIDIwOjU2OjIz IHNwZWVkc3RlciBrZXJuZWw6IFN0YWNrOiBjMDI4NzBiNiBjM2RiYmMwMCAw MDAwMDIwMCBjMTEzZWMwMCBjMDI4NzMwOCBjMTEzZWMwMCBjM2ZjMWM4OCBj MDI5MmNkZCANCkp1biAgMSAyMDo1NjoyMyBzcGVlZHN0ZXIga2VybmVsOiAg ICAgICAgYzE1Mjc4MDAgYzNmYzAwMDAgMDAwMzM4ZjMgYzAyOTJjZWYgYzMy NzgwMDAgYzE1Mjc4MDAgMDAwMDAwNDAgMDAwMDAwMzMgDQpKdW4gIDEgMjA6 NTY6MjMgc3BlZWRzdGVyIGtlcm5lbDogICAgICAgIGMxMTNlYzAwIDAwMDAw MDAxIGMxMTNlYzAwIDAwMDAwMDAxIGMzNmYwYmEwIDAwMDAwMDAwIGMwMjg5 MGEyIGMxMTNlYzAwIA0KSnVuICAxIDIwOjU2OjIzIHNwZWVkc3RlciBrZXJu ZWw6IENhbGwgVHJhY2U6IFtzaHJpbmtfc3RyaXBlX2NhY2hlKzU0LzgwXSBb Z2V0X2FjdGl2ZV9zdHJpcGUrNDcyLzEzMjhdIFtsdm1fbWFwKzEwODUvMTI4 MF0gW2x2bV9tYXArMTEwMy8xMjgwXSBbcmFpZDVfbWFrZV9yZXF1ZXN0Kzgy LzE2MF0gW21kX21ha2VfcmVxdWVzdCs3Ny8xMjhdIFtsdm1fbWFrZV9yZXF1 ZXN0X2ZuKzE1LzMyXSANCkp1biAgMSAyMDo1NjoyMyBzcGVlZHN0ZXIga2Vy bmVsOiBDYWxsIFRyYWNlOiBbPGMwMjg3MGI2Pl0gWzxjMDI4NzMwOD5dIFs8 YzAyOTJjZGQ+XSBbPGMwMjkyY2VmPl0gWzxjMDI4OTBhMj5dIFs8YzAyOGMy Y2Q+XSBbPGMwMjkyZGFmPl0gDQpKdW4gIDEgMjA6NTY6MjMgc3BlZWRzdGVy IGtlcm5lbDogICAgICAgIFs8YzAyNDM1MTI+XSBbPGMwMjQzOTBiPl0gWzxj MDFiMzE4Zj5dIFs8YzAyMDM2ZTE+XSBbPGMwMWIzNDA3Pl0gWzxjMDFiMzg5 MD5dIFs8YzAxYjM1MWU+XSBbPGMwMWIzMjUwPl0gDQpKdW4gIDEgMjA6NTY6 MjMgc3BlZWRzdGVyIGtlcm5lbDogICAgICAgIFs8YzAyMDFjMDQ+XSBbPGMw MjAyMzE3Pl0gWzxjMDI0MmU5YT5dIFs8YzAyMGU1YTE+XSBbPGMwMjAxYWJi Pl0gWzxjMDIwMzc1ND5dIFs8YzAyMDM4YWM+XSBbPGMwMjAxNTI5Pl0gDQpK dW4gIDEgMjA6NTY6MjMgc3BlZWRzdGVyIGtlcm5lbDogICAgICAgIFs8YzAy MTE3ZDM+XSBbPGMwMjY0MWUwPl0gWzxjMDExMGQ3Yj5dIFs8YzAyMTE2ZTU+ XSBbPGMwMjIxY2Y3Pl0gWzxjMDEzM2UxZj5dIFs8YzAxMzJmY2E+XSBbPGMw MTMzMjgyPl0gDQpKdW4gIDEgMjA6NTY6MjMgc3BlZWRzdGVyIGtlcm5lbDog ICAgICAgIFs8YzAxMDUwMDA+XSBbPGMwMTA1NGI2Pl0gWzxjMDEzMzFhMD5d IA0KSnVuICAxIDIwOjU2OjIzIHNwZWVkc3RlciBrZXJuZWw6IENvZGU6IDg5 IDAyIGM3IDQxIDA0IDAwIDAwIDAwIDAwIGMzIDhkIGI2IDAwIDAwIDAwIDAw IDhkIGJjIDI3IDAwIA0KDQo+PkVJUDsgYzAyODZmMDkgPHJlbW92ZV9oYXNo KzE5LzMwPiAgIDw9PT09PQ0KVHJhY2U7IGMwMjg3MGI2IDxzaHJpbmtfc3Ry aXBlX2NhY2hlKzM2LzUwPg0KVHJhY2U7IGMwMjg3MzA4IDxnZXRfYWN0aXZl X3N0cmlwZSsxZDgvNTMwPg0KVHJhY2U7IGMwMjkyY2RkIDxsdm1fbWFwKzQz ZC81MDA+DQpUcmFjZTsgYzAyOTJjZWYgPGx2bV9tYXArNDRmLzUwMD4NClRy YWNlOyBjMDI4OTBhMiA8cmFpZDVfbWFrZV9yZXF1ZXN0KzUyL2EwPg0KVHJh Y2U7IGMwMjhjMmNkIDxtZF9tYWtlX3JlcXVlc3QrNGQvODA+DQpUcmFjZTsg YzAyOTJkYWYgPGx2bV9tYWtlX3JlcXVlc3RfZm4rZi8yMD4NClRyYWNlOyBj MDI0MzUxMiA8Z2VuZXJpY19tYWtlX3JlcXVlc3QrMTEyLzEzMD4NClRyYWNl OyBjMDI0MzkwYiA8ZW5kX3RoYXRfcmVxdWVzdF9maXJzdCs3Yi9kMD4NClRy YWNlOyBjMDFiMzE4ZiA8X3BhZ2VidWZfcGFnZV9pbysyMWYvMmUwPg0KVHJh Y2U7IGMwMjAzNmUxIDx4bG9nX3N0YXRlX3JlbGVhc2VfaWNsb2crMjEvYjA+ DQpUcmFjZTsgYzAxYjM0MDcgPF9wYWdlX2J1Zl9wYWdlX2FwcGx5KzFiNy8x ZDA+DQpUcmFjZTsgYzAxYjM4OTAgPHBhZ2VidWZfc2VnbWVudF9hcHBseSs4 MC9lMD4NClRyYWNlOyBjMDFiMzUxZSA8cGFnZWJ1Zl9pb3JlcXVlc3QrZmUv MTUwPg0KVHJhY2U7IGMwMWIzMjUwIDxfcGFnZV9idWZfcGFnZV9hcHBseSsw LzFkMD4NClRyYWNlOyBjMDIwMWMwNCA8eGxvZ19iZHN0cmF0X2NiKzE0LzQw Pg0KVHJhY2U7IGMwMjAyMzE3IDx4bG9nX3N5bmMrMTc3LzM1MD4NClRyYWNl OyBjMDI0MmU5YSA8X19tYWtlX3JlcXVlc3QrMTJhLzY5MD4NClRyYWNlOyBj MDIwZTVhMSA8eGZzX3RyYW5zX3RhaWxfYWlsKzExLzMwPg0KVHJhY2U7IGMw MjAxYWJiIDx4bG9nX2Fzc2lnbl90YWlsX2xzbisxYi85MD4NClRyYWNlOyBj MDIwMzc1NCA8eGxvZ19zdGF0ZV9yZWxlYXNlX2ljbG9nKzk0L2IwPg0KVHJh Y2U7IGMwMjAzOGFjIDx4bG9nX3N0YXRlX3N5bmNfYWxsK2JjLzE2MD4NClRy YWNlOyBjMDIwMTUyOSA8eGZzX2xvZ19mb3JjZSszOS82MD4NClRyYWNlOyBj MDIxMTdkMyA8eGZzX3N5bmNzdWIrZTMvYmEwPg0KVHJhY2U7IGMwMjY0MWUw IDxzdGFydF9yZXF1ZXN0KzE4MC8xZjA+DQpUcmFjZTsgYzAxMTBkN2IgPHNj aGVkdWxlKzI2Yi8zYjA+DQpUcmFjZTsgYzAyMTE2ZTUgPHhmc19zeW5jKzE1 LzIwPg0KVHJhY2U7IGMwMjIxY2Y3IDxsaW52ZnNfd3JpdGVfc3VwZXIrMjcv MzA+DQpUcmFjZTsgYzAxMzNlMWYgPHN5bmNfc3VwZXJzKzZmLzkwPg0KVHJh Y2U7IGMwMTMyZmNhIDxzeW5jX29sZF9idWZmZXJzK2EvNDA+DQpUcmFjZTsg YzAxMzMyODIgPGt1cGRhdGUrZTIvZjA+DQpUcmFjZTsgYzAxMDUwMDAgPHBy ZXBhcmVfbmFtZXNwYWNlKzAvMTA+DQpUcmFjZTsgYzAxMDU0YjYgPGtlcm5l bF90aHJlYWQrMjYvMzA+DQpUcmFjZTsgYzAxMzMxYTAgPGt1cGRhdGUrMC9m MD4NCkNvZGU7ICBjMDI4NmYwOSA8cmVtb3ZlX2hhc2grMTkvMzA+DQowMDAw MDAwMCA8X0VJUD46DQpDb2RlOyAgYzAyODZmMDkgPHJlbW92ZV9oYXNoKzE5 LzMwPiAgIDw9PT09PQ0KICAgMDogICA4OSAwMiAgICAgICAgICAgICAgICAg ICAgIG1vdiAgICAlZWF4LCglZWR4KSAgIDw9PT09PQ0KQ29kZTsgIGMwMjg2 ZjBiIDxyZW1vdmVfaGFzaCsxYi8zMD4NCiAgIDI6ICAgYzcgNDEgMDQgMDAg MDAgMDAgMDAgICAgICBtb3ZsICAgJDB4MCwweDQoJWVjeCkNCkNvZGU7ICBj MDI4NmYxMiA8cmVtb3ZlX2hhc2grMjIvMzA+DQogICA5OiAgIGMzICAgICAg ICAgICAgICAgICAgICAgICAgcmV0ICAgIA0KQ29kZTsgIGMwMjg2ZjEzIDxy ZW1vdmVfaGFzaCsyMy8zMD4NCiAgIGE6ICAgOGQgYjYgMDAgMDAgMDAgMDAg ICAgICAgICBsZWEgICAgMHgwKCVlc2kpLCVlc2kNCkNvZGU7ICBjMDI4NmYx OSA8cmVtb3ZlX2hhc2grMjkvMzA+DQogIDEwOiAgIDhkIGJjIDI3IDAwIDAw IDAwIDAwICAgICAgbGVhICAgIDB4MCglZWRpLDEpLCVlZGkNCg0KDQozIHdh cm5pbmdzIGlzc3VlZC4gIFJlc3VsdHMgbWF5IG5vdCBiZSByZWxpYWJsZS4N Cg0KDQoNCg0KDQoNCg0K ---1702689938-1161906648-991648551=:9508-- From owner-linux-xfs@oss.sgi.com Mon Jun 4 03:37:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54Abhj03767 for linux-xfs-outgoing; Mon, 4 Jun 2001 03:37:43 -0700 Received: from guardian.hermes.si (guardian.hermes.si [193.77.5.150]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54Abfh03764 for ; Mon, 4 Jun 2001 03:37:42 -0700 Received: from hermes.si (primus.hermes.si [193.77.5.98]) by guardian.hermes.si (8.9.3/8.9.3) with ESMTP id MAA22978 for ; Mon, 4 Jun 2001 12:37:32 +0200 (METDST) Received: (from uucp@localhost) by hermes.si (8.9.3/8.9.3) id MAA22113 for ; Mon, 4 Jun 2001 12:37:28 +0200 Received: from oreh.hermes.si(10.65.207.12) by primus.hermes.si via smap (V2.1) id xma020638; Mon, 4 Jun 01 12:36:14 +0200 Received: by oreh.hermes.si with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 12:36:16 +0200 Message-ID: <8DA212D53DEFD211A5E70060979801B41B8712@oreh.hermes.si> From: Andrej Jamsek To: linux-xfs@oss.sgi.com Subject: How to obtain CVS tree Date: Mon, 4 Jun 2001 12:35:11 +0200 Deferred-Delivery: Mon, 4 Jun 2001 12:36:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello everybody. I use XFS from RedHat 7.1 installation CD for kernel 2.4.2, but I want to build a new kernel 2.4.5. I try to download latest CVS tree with Cusp as instruction on web says but it didn't work. I got every time connection time-out respond. I make all types of "sup file" as described on web and got the same response. Please, can anybody explain me how to download latest version. Thanks in advance Andrej ---------------------------------------------------------------------------- Jamsek Andrej Hermes SoftLab d.d. Office Nova Gorica Litijska 51, 1000 Ljubljana, Slovenia phone: (++386 1) 5865 705 E-mail: andrej.jamsek@hermes.si ---------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Jun 4 03:54:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54AsEm07535 for linux-xfs-outgoing; Mon, 4 Jun 2001 03:54:14 -0700 Received: from tux.mkp.net (tux.mkp.net [130.225.60.11]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54AsDh07531 for ; Mon, 4 Jun 2001 03:54:13 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net) by tux.mkp.net with esmtp (Exim 3.16 #1) id 156rzp-0004nK-00; Mon, 04 Jun 2001 12:54:11 +0200 Received: (from mkp@localhost) by jcb.mkp.net (8.11.0/8.9.3) id f54Art711173; Mon, 4 Jun 2001 06:53:55 -0400 X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f To: Matteo Centonza Cc: Subject: Re: LVM+RAID5 Oops on snapshot creation References: From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 04 Jun 2001 06:53:55 -0400 In-Reply-To: Message-ID: Lines: 39 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Matteo" == Matteo Centonza writes: Matteo> I've also applied changes in lvm.c (get_hardsect_size). The sector size changes in recent kernels are likely to be the culprit. Just got back from a couple of weeks on vacation, so I haven't followed the merge closely. I'll have a look later today. If you could mail me your lvm.c that would be great. Matteo> The system seems to be very stable, even under heavy load, Matteo> mixing local and remote access, except for the snapshot that Matteo> triggers the Oops in attachment. This problem seems not to Matteo> affect a bare LVM configuration. Every time we switch block sizes, the RAID5 code has to flush its stripe cache. And there seem to be something nasty going on there after the merge. Matteo> I've also tested with ext2 and seems to run fine. ext2 sticks to one block size, while XFS switches between 512 bytes and the fs block size all the time. Before I went on vacation I had a cunning plan of revamping the stripe cache so it would stick to one size and handle merging internally. That way we could avoid flushing the cache all the time at the cost of copying things around a bit. I'll probably try and hack this up and measure whether it is a win or not. In any case I'll poke a bit at the block size changes in the 2.4.5 tree and see what happens... -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Mon Jun 4 03:57:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54AvA208491 for linux-xfs-outgoing; Mon, 4 Jun 2001 03:57:10 -0700 Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54AvAh08485 for ; Mon, 4 Jun 2001 03:57:10 -0700 Received: from qn-212-58-163-247.quicknet.nl ([212.58.163.247]:61856 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Mon, 4 Jun 2001 12:57:01 +0200 Message-Id: <4.3.2.7.2.20010604125501.03570328@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Jun 2001 12:56:56 +0200 To: Andrej Jamsek , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: How to obtain CVS tree In-Reply-To: <8DA212D53DEFD211A5E70060979801B41B8712@oreh.hermes.si> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:35 4-6-2001 +0200, Andrej Jamsek wrote: >Hello everybody. > >I use XFS from RedHat 7.1 installation CD for kernel 2.4.2, but I want to >build a new kernel 2.4.5. I try to download latest CVS tree with Cusp as >instruction on web says but it didn't work. I got every time connection >time-out respond. I make all types of "sup file" as described on web and got >the same response. > >Please, can anybody explain me how to download latest version. It is possible that cvsup is not avalaible at the moment due to a misconfigured firewall in front of oss.sgi.com. Use a normal cvs checkout instead. The normal cvs download is also described on the webpage. Cheers Seth -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Jun 4 04:53:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54Bria17169 for linux-xfs-outgoing; Mon, 4 Jun 2001 04:53:44 -0700 Received: from guardian.hermes.si (guardian.hermes.si [193.77.5.150]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54Brgh17154 for ; Mon, 4 Jun 2001 04:53:43 -0700 Received: from hermes.si (primus.hermes.si [193.77.5.98]) by guardian.hermes.si (8.9.3/8.9.3) with ESMTP id NAA24989 for ; Mon, 4 Jun 2001 13:53:33 +0200 (METDST) Received: (from uucp@localhost) by hermes.si (8.9.3/8.9.3) id NAA31229 for ; Mon, 4 Jun 2001 13:53:30 +0200 Received: from oreh.hermes.si(10.65.207.12) by primus.hermes.si via smap (V2.1) id xma028346; Mon, 4 Jun 01 13:52:24 +0200 Received: by oreh.hermes.si with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 13:52:25 +0200 Message-ID: <8DA212D53DEFD211A5E70060979801B41B8713@oreh.hermes.si> From: Andrej Jamsek To: linux-xfs@oss.sgi.com Subject: RE: How to obtain CVS tree Date: Mon, 4 Jun 2001 13:51:16 +0200 Deferred-Delivery: Mon, 4 Jun 2001 13:52:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks guys. It works perfectly Andrej > -----Original Message----- > From: Seth Mos [mailto:knuffie@xs4all.nl] > Sent: 4. junij 2001 12:57 > To: Andrej Jamsek; linux-xfs@oss.sgi.com > Subject: Re: How to obtain CVS tree > > > At 12:35 4-6-2001 +0200, Andrej Jamsek wrote: > >Hello everybody. > > > >I use XFS from RedHat 7.1 installation CD for kernel 2.4.2, > but I want to > >build a new kernel 2.4.5. I try to download latest CVS tree > with Cusp as > >instruction on web says but it didn't work. I got every time > connection > >time-out respond. I make all types of "sup file" as > described on web and got > >the same response. > > > >Please, can anybody explain me how to download latest version. > > It is possible that cvsup is not avalaible at the moment due to a > misconfigured firewall in front of oss.sgi.com. > > Use a normal cvs checkout instead. The normal cvs download is also > described on the webpage. > > Cheers > Seth > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. > From owner-linux-xfs@oss.sgi.com Mon Jun 4 05:58:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54Cwou26520 for linux-xfs-outgoing; Mon, 4 Jun 2001 05:58:50 -0700 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54Cwnh26516 for ; Mon, 4 Jun 2001 05:58:49 -0700 Received: from [195.20.224.209] (helo=mrvdom02.schlund.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 156twV-00044a-00 for linux-xfs@oss.sgi.com; Mon, 4 Jun 2001 14:58:47 +0200 Received: from pd954cb64.dip.t-dialin.net ([217.84.203.100] helo=educators.de) by mrvdom02.schlund.de with esmtp (Exim 2.12 #2) id 156tvz-0004Qv-00 for linux-xfs@oss.sgi.com; Mon, 4 Jun 2001 14:58:16 +0200 Message-ID: <3B1B85D8.D8A694BE@educators.de> Date: Mon, 04 Jun 2001 14:58:00 +0200 From: Felix Ide X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.3-XFS i686) X-Accept-Language: de, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: permission problems.. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk marchuk@ee.washington.edu wrote: > > I am using the latest CVS tree, one from Friday, and I noticed a strange > problem. Every once in a while permissions get reset for some > directories, I mean all permissions are removed. Has anyone noticed this > problem and is this XFS related? > I have the same problem here using the cvs tree from today (monday) ! After installation and reboot some files and directories are chmod'ed to 000 ! Felix From owner-linux-xfs@oss.sgi.com Mon Jun 4 07:00:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54E0pi31309 for linux-xfs-outgoing; Mon, 4 Jun 2001 07:00:51 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54E0nh31306 for ; Mon, 4 Jun 2001 07:00:49 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f54E0caJ001782; Mon, 4 Jun 2001 09:00:39 -0500 (CDT) Message-ID: <3B1B9480.9E73FE6F@thebarn.com> Date: Mon, 04 Jun 2001 09:00:33 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Andrej Jamsek CC: linux-xfs@oss.sgi.com Subject: Re: How to obtain CVS tree References: <8DA212D53DEFD211A5E70060979801B41B8712@oreh.hermes.si> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andrej Jamsek wrote: > Hello everybody. > > I use XFS from RedHat 7.1 installation CD for kernel 2.4.2, but I want to > build a new kernel 2.4.5. I try to download latest CVS tree with Cusp as > instruction on web says but it didn't work. I got every time connection > time-out respond. I make all types of "sup file" as described on web and got > the same response. > > Please, can anybody explain me how to download latest version. The firewall hasn't been configed to allow the cvsup port to pass. I'm not sure when they are going to open it up. The last work I got was they were having problems with the firewall and they won't make changes to the config until the problem is resolved. I'll set a linux-xfs cvsup tree at thebarn.com as a stop gap I have a meeting this mooring so it will be sometime this afternoon before I get to it. > > > Thanks in advance > Andrej > > ---------------------------------------------------------------------------- > Jamsek Andrej > Hermes SoftLab d.d. > Office Nova Gorica > > Litijska 51, 1000 Ljubljana, Slovenia > phone: (++386 1) 5865 705 > E-mail: andrej.jamsek@hermes.si > ---------------------------------------------------------------------------- -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Mon Jun 4 07:02:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54E2gA31594 for linux-xfs-outgoing; Mon, 4 Jun 2001 07:02:42 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54E2eh31591 for ; Mon, 4 Jun 2001 07:02:40 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA09557 for ; Mon, 4 Jun 2001 07:02:52 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2051841; Mon, 4 Jun 2001 09:01:22 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA91020; Mon, 4 Jun 2001 09:01:15 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f54E3SQ29627; Mon, 4 Jun 2001 09:03:28 -0500 Message-Id: <200106041403.f54E3SQ29627@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Felix Ide cc: linux-xfs@oss.sgi.com Subject: Re: permission problems.. In-Reply-To: Message from Felix Ide of "Mon, 04 Jun 2001 14:58:00 +0200." <3B1B85D8.D8A694BE@educators.de> Date: Mon, 04 Jun 2001 09:03:28 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > marchuk@ee.washington.edu wrote: > > > > I am using the latest CVS tree, one from Friday, and I noticed a strange > > problem. Every once in a while permissions get reset for some > > directories, I mean all permissions are removed. Has anyone noticed this > > problem and is this XFS related? > > > > I have the same problem here using the cvs tree from today (monday) ! > After installation and reboot some files and directories are chmod'ed to > 000 ! > > Felix Hmm, there was an 'optimization' a couple of weeks back which could explain this. Do you have any pointers to what coincides with this, and what the first operation is that causes you to discover missing permissions? Steve From owner-linux-xfs@oss.sgi.com Mon Jun 4 07:33:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54EXEi00457 for linux-xfs-outgoing; Mon, 4 Jun 2001 07:33:14 -0700 Received: from revere3.musc.edu (revere3.musc.edu [128.23.203.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54EXDh00454 for ; Mon, 4 Jun 2001 07:33:13 -0700 Received: from D8H1FF01 ([128.23.211.115]) by revere3.musc.edu (8.8.8/8.8.8) with ESMTP id KAA18575 for ; Mon, 4 Jun 2001 10:33:12 -0400 (EDT) Date: Mon, 04 Jun 2001 10:34:53 -0400 From: Stephen VanPelt To: linux-xfs@oss.sgi.com Subject: Setting Permissions with ACLs Message-ID: <3808415888.991650893@D8H1FF01> Originator-Info: login-id=vanpelts; server=imap.musc.edu X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello there, I'm running Redhat 7.1 with XFS, and I've got a quick question about setting permissions using the ACLs. I tried many different configurations when setting permissions on a directory and on a file, but I found that the ACLs can only grant permissions on files that I've chmod'ed to 777. Basically I'm finding that the ACLs cannot grant a right that has not already been granted by chmod, although the ACLs will in fact restrict access that has been authorized by chmod. I'm just making sure that I'm doing everything in the best possible manner, and that I have not missed a step here. I'm very new to the linux ACL game (never touched an Irix machine in my life), and I'm a little wary :) Thanks for any help or suggestions you might have, Stephen VanPelt Stephen VanPelt Information Technology Consultant MUSC Center for Drug and Alcohol Programs PH: 843-792-5558 Internet: vanpelts@musc.edu __________________BEGIN FOOTER___________________ **The Views Expressed by the Author of this Message are not ** **necessarily those of the Medical University of South Carolina** From owner-linux-xfs@oss.sgi.com Mon Jun 4 07:36:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54EalY00915 for linux-xfs-outgoing; Mon, 4 Jun 2001 07:36:47 -0700 Received: from marraco.udl.es (gardeny.udl.es [193.144.12.130]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54Eajh00912 for ; Mon, 4 Jun 2001 07:36:46 -0700 Received: from eup.udl.es (fermat.udl.net [10.50.54.28]) by marraco.udl.es (8.9.3/8.8.5) with ESMTP id PAA20559 for ; Mon, 4 Jun 2001 15:36:12 +0200 Received: by eup.udl.es (8.8.8+Sun/SMI-SVR4) id QAA12734; Mon, 4 Jun 2001 16:36:36 +0200 (MET DST) Date: Mon, 4 Jun 2001 16:36:36 +0200 (MET DST) From: fermin@eup.udl.es (Fermin Molina) Message-Id: <200106041436.QAA12734@eup.udl.es> To: linux-xfs@oss.sgi.com Subject: Re: permission problems.. X-Sun-Charset: US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, > > I am using the latest CVS tree, one from Friday, and I noticed a strange > > problem. Every once in a while permissions get reset for some > > directories, I mean all permissions are removed. Has anyone noticed this > > problem and is this XFS related? > > > > I have the same problem here using the cvs tree from today (monday) ! > After installation and reboot some files and directories are chmod'ed to > 000 ! I have the same problem. I don't get this strange behaviour using a cvs from early May (8-9 May). With a cvs from May 29, some directories and files get mode 000. Also, some files get 4xxx (suid) and 2xxx (sgid) modes!!! (very dangerous!!) All these files are accesed via NFS by normal users. I must to boot with old cvs kernels. [...] I get this message from Steve now: > Hmm, there was an 'optimization' a couple of weeks back which could explain > this. Do you have any pointers to what coincides with this, and what the > first operation is that causes you to discover missing permissions? I begin to see this as soon as I rebooted the machine with the new (May 29) cvs kernel. Another point I want to let you know is that I have the "problem" commented early on the list, "xfs mount warning". Maybe my filesystem was incorrectly unmounted (not remounted read-only before halt), and then, when booted with new kernel, the recovery has made incorrectly? (it's only a guess...) TIA & Thanx! /Fermin From owner-linux-xfs@oss.sgi.com Mon Jun 4 07:41:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54EfFb01411 for linux-xfs-outgoing; Mon, 4 Jun 2001 07:41:15 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54EfEh01407 for ; Mon, 4 Jun 2001 07:41:14 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA17637 for ; Mon, 4 Jun 2001 07:41:13 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2052740; Mon, 4 Jun 2001 09:39:56 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA61417; Mon, 4 Jun 2001 09:39:56 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f54Eg9f29808; Mon, 4 Jun 2001 09:42:09 -0500 Message-Id: <200106041442.f54Eg9f29808@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Chris Pascoe cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: Crashes in various ext2 functions while running xfstest/check In-Reply-To: Message from Chris Pascoe of "Mon, 04 Jun 2001 19:10:02 +1000." Date: Mon, 04 Jun 2001 09:42:09 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Chris, Thanks for the detailed analysis, this gives me a couple of ideas. The changes you describe will work - since you have effectively disabled highmem by doing so. I think the problem is more along the lines of xfs not cleaning up these pages correctly in some situation. Steve > Hi Steve, > > Further to my last emails on this, I think I've tracked down why the > crashes occur, but don't know how to fix it. I eliminated the scsi > hardware, ethernet card, etc, that Seth Mos suggested might be the problem > (got loans of completely different hardware). I can reliably crash my > test machine in under an hour by running test 013 in a loop, and letting > the "/etc/cron.hourly/sysstat" cron job run. Doing some random other > commands during the process helps speed the crash up. > > The crashes I see are related to the machine having highmem support, and > buffers allocated with pages in high memory making their way onto the > (fs/buffer.c) free_list. I added an extra field to struct buffer_head > that records in the buffer head who created it (in create_empty_buffers), > and what function called put_last_free. In every instance, the > buffer_head that causes the crash was created by > hook_buffers_to_page_delay, and put onto the free list later by a call to > __invalidate_buffers. (Adding code to record in the bh who called > that.... done.... crashed, - the caller was blkdev_put this time, but I'll > run a few more tests). > > When one of these bh's with bh->b_page in high memory is given to ext2 by > getblk, and a "bread" performed, bh->b_data gets set to values < PAGE_SIZE > by a call to set_bh_page. This is why it looked like the bh's were > corrupted in my previous backtraces. The actual disk IO that was > performed on these pages proceeds okay though, as ll_rw_blk() does > create_bounce's for the real disk I/O (which is why the dereferences > you saw came after a successful call to bread). > > I can seemingly (no crashes after a weekend of repeats) make the crashes > go away by replacing GFP_HIGHUSER with GFP_USER in clean_inode > (fs/inode.c), and _pagebuf_lookup_pages (fs/pagebuf/page_buf.c). > Changing one alone doesn't make any difference. > > Hope that this makes some sense to you, and you can just say aha, and wave > the magic wand :). I hope you can replicate it locally with this > information. > > Regards, > Chris From owner-linux-xfs@oss.sgi.com Mon Jun 4 07:50:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54EoGn02165 for linux-xfs-outgoing; Mon, 4 Jun 2001 07:50:16 -0700 Received: from FW2.dt.navy.mil (FW2.dt.navy.mil [192.5.27.136]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54EoEh02160 for ; Mon, 4 Jun 2001 07:50:14 -0700 Received: by FW2.dt.navy.mil; id KAA07243; Mon, 4 Jun 2001 10:52:06 -0400 (EDT) Received: from unknown(130.46.225.16) by FW2.dt.navy.mil via smap (V5.5) id xma006752; Mon, 4 Jun 01 10:51:32 -0400 Received: from NAVGATE.dt.navy.mil (navgate.dt.navy.mil [130.46.225.15]) by smtprelay.dt.navy.mil (8.9.3/8.9.3) with SMTP id KAA28961 for ; Mon, 4 Jun 2001 10:49:24 -0400 Received: from crbeex01.nswccd.navy.mil ([130.46.5.84]) by NAVGATE.dt.navy.mil (NAVIEG 2.1 bld 63) with SMTP id M2001060410492312941 ; Mon, 04 Jun 2001 10:49:23 -0400 Received: from PROFESSOR.dt.navy.mil ([157.187.160.235]) by crbeex01.nswccd.navy.mil with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M21X7GQB; Mon, 4 Jun 2001 10:49:23 -0400 Received: from jtsdell (Bayview162-40.dt.navy.mil [157.187.162.40]) by professor.dt.navy.mil (8.8.8+Sun/8.8.8) with ESMTP id HAA16719; Mon, 4 Jun 2001 07:39:48 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.4.8 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3808415888.991650893@D8H1FF01> Date: Mon, 04 Jun 2001 10:48:49 -0400 (EDT) Reply-To: jtrostel@connex.com Organization: Connex From: John Trostel To: Stephen VanPelt Subject: RE: Setting Permissions with ACLs Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Are you the original owner of the files you are trying to change the ACLs of? Try this and tell me what you see: 1. In an XFS directory you own, create a file: $ touch a_file 2. check the permissions (assuming a standard umask) $ ls -l a_file -rw-rw-r-- 1 jt jt 0 Jun 4 10:38 a_file $ 3. check the permission with 'chacl' (no ACL applied yet) $ chacl -l a_file a_file [] 4. change the ACL using 'chacl' and check again $ chacl u::rwx,g::r-x,o::r--,u:user1:r--,m::r-x a_file $ chacl -l a_file a_file [u::rwx,g::r-x,o::r--,u:user1:r--,m::r-x] On 04-Jun-2001 Stephen VanPelt wrote: > Hello there, > > I'm running Redhat 7.1 with XFS, and I've got a quick question about > setting permissions using the ACLs. I tried many different configurations > when setting permissions on a directory and on a file, but I found that the > ACLs can only grant permissions on files that I've chmod'ed to 777. > Basically I'm finding that the ACLs cannot grant a right that has not > already been granted by chmod, although the ACLs will in fact restrict > access that has been authorized by chmod. > > I'm just making sure that I'm doing everything in the best possible manner, > and that I have not missed a step here. I'm very new to the linux ACL game > (never touched an Irix machine in my life), and I'm a little wary :) > > Thanks for any help or suggestions you might have, > > Stephen VanPelt > > > > Stephen VanPelt > Information Technology Consultant > MUSC Center for Drug and Alcohol Programs > PH: 843-792-5558 Internet: vanpelts@musc.edu > > > __________________BEGIN FOOTER___________________ > **The Views Expressed by the Author of this Message are not ** > **necessarily those of the Medical University of South Carolina** -- John M. Trostel Linux OS Engineer Connex jtrostel@connex.com From owner-linux-xfs@oss.sgi.com Mon Jun 4 07:55:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54EtMk02733 for linux-xfs-outgoing; Mon, 4 Jun 2001 07:55:22 -0700 Received: from mailout04.sul.t-online.de (mailout04.sul.t-online.com [194.25.134.18]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54EtLh02728 for ; Mon, 4 Jun 2001 07:55:21 -0700 Received: from fwd02.sul.t-online.de by mailout04.sul.t-online.de with smtp id 156vkU-0005Fn-01; Mon, 04 Jun 2001 16:54:30 +0200 Received: from t-online.de (340024412816-0001@[217.81.137.174]) by fwd02.sul.t-online.com with esmtp id 156vkE-09EmsCC; Mon, 4 Jun 2001 16:54:14 +0200 Message-ID: <3B1BA119.827B38CB@t-online.de> Date: Mon, 04 Jun 2001 16:54:17 +0200 From: Hasch@t-online.de (Juergen Hasch) X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 To: Stephen VanPelt CC: linux-xfs@oss.sgi.com Subject: Re: Setting Permissions with ACLs References: <3808415888.991650893@D8H1FF01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: 340024412816-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Stephen VanPelt schrieb: > > Hello there, > > I'm running Redhat 7.1 with XFS, and I've got a quick question about > setting permissions using the ACLs. I tried many different configurations > when setting permissions on a directory and on a file, but I found that the > ACLs can only grant permissions on files that I've chmod'ed to 777. > Basically I'm finding that the ACLs cannot grant a right that has not > already been granted by chmod, although the ACLs will in fact restrict > access that has been authorized by chmod. > > I'm just making sure that I'm doing everything in the best possible manner, > and that I have not missed a step here. I'm very new to the linux ACL game > (never touched an Irix machine in my life), and I'm a little wary :) > It works for me, here is a simple example: bash-2.04$ ls -al total 16 drwxr-xr-x 2 hasch users 29 Jun 4 16:52 . drwxr-xr-x 72 hasch users 8192 Jun 4 16:50 .. -rwxrwx---+ 1 hasch users 0 Jun 4 16:50 test -rwxr-x--- 1 hasch users 0 Jun 4 16:52 test1 bash-2.04$ chacl -l test test [] bash-2.04$ chacl u::rwx,u:postgres:rw--,g::r--,o::---,m::rwx test bash-2.04$ chacl -l test test [u::rwx,u:postgres:rw-,g::r--,o::---,m::rwx] postgres@linux:/home/hasch/acl_t > cat test postgres@linux:/home/hasch/acl_t > cat test1 cat: test1: Keine Berechtigung (means access denied) ...Juergen From owner-linux-xfs@oss.sgi.com Mon Jun 4 08:09:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54F9qE03781 for linux-xfs-outgoing; Mon, 4 Jun 2001 08:09:52 -0700 Received: from revere3.musc.edu (revere3.musc.edu [128.23.203.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54F9mh03771 for ; Mon, 4 Jun 2001 08:09:48 -0700 Received: from D8H1FF01 ([128.23.211.115]) by revere3.musc.edu (8.8.8/8.8.8) with ESMTP id LAA04028; Mon, 4 Jun 2001 11:03:58 -0400 (EDT) Date: Mon, 04 Jun 2001 11:05:29 -0400 From: Stephen VanPelt To: jtrostel@connex.com cc: linux-xfs@oss.sgi.com Subject: RE: Setting Permissions with ACLs Message-ID: <3810251117.991652729@D8H1FF01> In-Reply-To: Originator-Info: login-id=vanpelts; server=imap.musc.edu X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk see comments below --On Monday, June 04, 2001 10:48 AM -0400 John Trostel wrote: > Are you the original owner of the files you are trying to change the ACLs > of? Yes, and I'm able to change the ACLs. > > Try this and tell me what you see: > > 1. In an XFS directory you own, create a file: > > $ touch a_file > > 2. check the permissions (assuming a standard umask) > > $ ls -l a_file > -rw-rw-r-- 1 jt jt 0 Jun 4 10:38 a_file > $ -rw-r--r-- 1 peltman peltman 0 Jun 4 09:53 a_file > > 3. check the permission with 'chacl' (no ACL applied yet) > > $ chacl -l a_file > a_file [] > Yup, looks good... > 4. change the ACL using 'chacl' and check again > > $ chacl u::rwx,g::r-x,o::r--,u:user1:r--,m::r-x a_file > $ chacl -l a_file > a_file [u::rwx,g::r-x,o::r--,u:user1:r--,m::r-x] > This part looks good too - but here's where I find problems... If I have a user that I've specified (user1, in this instance) with write access log into the server (using netatalk - but this doesn't seem to matter), they cannot open the file if the file isn't chmod'ed to give "other" write access. Even though the user is given write access in the ACL, they cannot exercise that access unless it is also allowed in "chmod" (the file belongs to peltman:peltman - and of course the user is not in either of those groups - so unless they are set to chmod 006 or 007, then the ACL doesn't seem to be able to grant any access that the chmod denies). > > On 04-Jun-2001 Stephen VanPelt wrote: >> Hello there, >> >> I'm running Redhat 7.1 with XFS, and I've got a quick question about >> setting permissions using the ACLs. I tried many different >> configurations when setting permissions on a directory and on a file, >> but I found that the ACLs can only grant permissions on files that I've >> chmod'ed to 777. Basically I'm finding that the ACLs cannot grant a >> right that has not already been granted by chmod, although the ACLs >> will in fact restrict access that has been authorized by chmod. >> >> I'm just making sure that I'm doing everything in the best possible >> manner, and that I have not missed a step here. I'm very new to the >> linux ACL game (never touched an Irix machine in my life), and I'm a >> little wary :) >> >> Thanks for any help or suggestions you might have, >> >> Stephen VanPelt >> >> >> >> Stephen VanPelt >> Information Technology Consultant >> MUSC Center for Drug and Alcohol Programs >> PH: 843-792-5558 Internet: vanpelts@musc.edu >> >> >> __________________BEGIN FOOTER___________________ >> **The Views Expressed by the Author of this Message are not ** >> **necessarily those of the Medical University of South Carolina** > > -- > John M. Trostel > Linux OS Engineer > Connex > jtrostel@connex.com Stephen VanPelt Information Technology Consultant MUSC Center for Drug and Alcohol Programs PH: 843-792-5558 Internet: vanpelts@musc.edu __________________BEGIN FOOTER___________________ **The Views Expressed by the Author of this Message are not ** **necessarily those of the Medical University of South Carolina** From owner-linux-xfs@oss.sgi.com Mon Jun 4 08:16:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54FGZ504451 for linux-xfs-outgoing; Mon, 4 Jun 2001 08:16:35 -0700 Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54FGZh04448 for ; Mon, 4 Jun 2001 08:16:35 -0700 Received: from darkstar.ee.washington.edu (darkstar.ee.washington.edu [128.95.196.85]) by maxwell.ee.washington.edu (8.12.0.Beta7/8.12.0) with ESMTP id f54FFnWc002443; Mon, 4 Jun 2001 08:15:50 -0700 Date: Mon, 4 Jun 2001 08:15:50 -0700 (PDT) From: To: Steve Lord cc: Felix Ide , linux-xfs@oss.sgi.com Subject: Re: permission problems.. In-Reply-To: <200106041403.f54E3SQ29627@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk It changes permissions which seems to be at random. It doesnt just change a single file but will change permissions in the whole directory. So it doesnt change random files just random directories and inside those random directories. All I can say is that my users randomly see permissions change and sometimes several times a day. ***************************** Walter Marchuk Senior Computer Specialist University of Washington Electrical Engineering Room: 307g 206-221-5421 marchuk@ee.washington.edu ***************************** On Mon, 4 Jun 2001, Steve Lord wrote: > > marchuk@ee.washington.edu wrote: > > > > > > I am using the latest CVS tree, one from Friday, and I noticed a strange > > > problem. Every once in a while permissions get reset for some > > > directories, I mean all permissions are removed. Has anyone noticed this > > > problem and is this XFS related? > > > > > > > I have the same problem here using the cvs tree from today (monday) ! > > After installation and reboot some files and directories are chmod'ed to > > 000 ! > > > > Felix > > Hmm, there was an 'optimization' a couple of weeks back which could explain > this. Do you have any pointers to what coincides with this, and what the > first operation is that causes you to discover missing permissions? > > Steve > > From owner-linux-xfs@oss.sgi.com Mon Jun 4 08:20:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54FKZJ04933 for linux-xfs-outgoing; Mon, 4 Jun 2001 08:20:35 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54FKZh04930 for ; Mon, 4 Jun 2001 08:20:35 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA01673 for ; Mon, 4 Jun 2001 08:20:47 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2054315; Mon, 4 Jun 2001 10:19:17 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA82799; Mon, 4 Jun 2001 10:19:17 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f54FLTW29906; Mon, 4 Jun 2001 10:21:29 -0500 Message-Id: <200106041521.f54FLTW29906@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: marchuk@ee.washington.edu cc: Steve Lord , Felix Ide , linux-xfs@oss.sgi.com Subject: Re: permission problems.. In-Reply-To: Message from marchuk@ee.washington.edu of "Mon, 04 Jun 2001 08:15:50 PDT." Date: Mon, 04 Jun 2001 10:21:29 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is this happening via NFS access, or local access? If I cannot find a quick fix I can back out the change which is probably at the back of this. Steve > It changes permissions which seems to be at random. It doesnt just change > a single file but will change permissions in the whole directory. So it > doesnt change random files just random directories and inside those random > directories. All I can say is that my users randomly see permissions > change and sometimes several times a day. > > ***************************** > Walter Marchuk > Senior Computer Specialist > University of Washington > Electrical Engineering > Room: 307g > 206-221-5421 > marchuk@ee.washington.edu > ***************************** > > On Mon, 4 Jun 2001, Steve Lord wrote: > > > > marchuk@ee.washington.edu wrote: > > > > > > > > I am using the latest CVS tree, one from Friday, and I noticed a strang > e > > > > problem. Every once in a while permissions get reset for some > > > > directories, I mean all permissions are removed. Has anyone noticed th > is > > > > problem and is this XFS related? > > > > > > > > > > I have the same problem here using the cvs tree from today (monday) ! > > > After installation and reboot some files and directories are chmod'ed to > > > 000 ! > > > > > > Felix > > > > Hmm, there was an 'optimization' a couple of weeks back which could explain > > this. Do you have any pointers to what coincides with this, and what the > > first operation is that causes you to discover missing permissions? > > > > Steve > > > > From owner-linux-xfs@oss.sgi.com Mon Jun 4 08:23:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54FNAu05388 for linux-xfs-outgoing; Mon, 4 Jun 2001 08:23:10 -0700 Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54FN9h05383 for ; Mon, 4 Jun 2001 08:23:09 -0700 Received: from darkstar.ee.washington.edu (darkstar.ee.washington.edu [128.95.196.85]) by maxwell.ee.washington.edu (8.12.0.Beta7/8.12.0) with ESMTP id f54FN7Wc003775; Mon, 4 Jun 2001 08:23:07 -0700 Date: Mon, 4 Jun 2001 08:23:07 -0700 (PDT) From: To: Steve Lord cc: Felix Ide , linux-xfs@oss.sgi.com Subject: Re: permission problems.. In-Reply-To: <200106041521.f54FLTW29906@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The xfs raid we have is nfsd to all our application servers. Yes, it is happening through NFS access since users do not have direct access to the file server. ***************************** Walter Marchuk Senior Computer Specialist University of Washington Electrical Engineering Room: 307g 206-221-5421 marchuk@ee.washington.edu ***************************** On Mon, 4 Jun 2001, Steve Lord wrote: > > Is this happening via NFS access, or local access? If I cannot find a quick > fix I can back out the change which is probably at the back of this. > > Steve > > > It changes permissions which seems to be at random. It doesnt just change > > a single file but will change permissions in the whole directory. So it > > doesnt change random files just random directories and inside those random > > directories. All I can say is that my users randomly see permissions > > change and sometimes several times a day. > > > > ***************************** > > Walter Marchuk > > Senior Computer Specialist > > University of Washington > > Electrical Engineering > > Room: 307g > > 206-221-5421 > > marchuk@ee.washington.edu > > ***************************** > > > > On Mon, 4 Jun 2001, Steve Lord wrote: > > > > > > marchuk@ee.washington.edu wrote: > > > > > > > > > > I am using the latest CVS tree, one from Friday, and I noticed a strang > > e > > > > > problem. Every once in a while permissions get reset for some > > > > > directories, I mean all permissions are removed. Has anyone noticed th > > is > > > > > problem and is this XFS related? > > > > > > > > > > > > > I have the same problem here using the cvs tree from today (monday) ! > > > > After installation and reboot some files and directories are chmod'ed to > > > > 000 ! > > > > > > > > Felix > > > > > > Hmm, there was an 'optimization' a couple of weeks back which could explain > > > this. Do you have any pointers to what coincides with this, and what the > > > first operation is that causes you to discover missing permissions? > > > > > > Steve > > > > > > > > From owner-linux-xfs@oss.sgi.com Mon Jun 4 08:58:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54Fwde07625 for linux-xfs-outgoing; Mon, 4 Jun 2001 08:58:39 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54Fwch07622 for ; Mon, 4 Jun 2001 08:58:38 -0700 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA07799 for ; Mon, 4 Jun 2001 08:58:32 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2054790; Mon, 4 Jun 2001 10:57:15 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA76920; Mon, 4 Jun 2001 10:57:15 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f54FxRq30715; Mon, 4 Jun 2001 10:59:27 -0500 Message-Id: <200106041559.f54FxRq30715@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: marchuk@ee.washington.edu cc: Steve Lord , Felix Ide , linux-xfs@oss.sgi.com Subject: Re: permission problems.. In-Reply-To: Message from marchuk@ee.washington.edu of "Mon, 04 Jun 2001 08:23:07 PDT." Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-3338402560" Date: Mon, 04 Jun 2001 10:59:27 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multipart MIME message. --==_Exmh_-3338402560 Content-Type: text/plain > The xfs raid we have is nfsd to all our application servers. Yes, it is > happening through NFS access since users do not have direct access to the > file server. > Can someone who is seeing this problem try the following small patch and let me know if this fixes the problem. Thanks, Steve --==_Exmh_-3338402560 Content-Type: application/x-patch ; name="nfs.patch" Content-Description: nfs.patch Content-Disposition: attachment; filename="nfs.patch" =========================================================================== Index: linux/fs/xfs/linux/xfs_iops.c =========================================================================== --- /usr/tmp/TmpDir.30694-0/linux/fs/xfs/linux/xfs_iops.c_1.106 Mon Jun 4 10:55:14 2001 +++ linux/fs/xfs/linux/xfs_iops.c Mon Jun 4 10:50:14 2001 @@ -605,7 +605,7 @@ vnode_t *vp; vp = LINVFS_GET_VP(dentry->d_inode); - if (vp->v_flag & VMODIFIED) { + if (1 /* vp->v_flag & VMODIFIED */) { return linvfs_revalidate_core(dentry->d_inode, 0); } return 0; =========================================================================== Index: linux/fs/xfs/linux/xfs_vnode.c =========================================================================== --- /usr/tmp/TmpDir.30694-0/linux/fs/xfs/linux/xfs_vnode.c_1.64 Mon Jun 4 10:55:13 2001 +++ linux/fs/xfs/linux/xfs_vnode.c Mon Jun 4 10:40:22 2001 @@ -196,6 +196,7 @@ make_bad_inode(inode); } else { linvfs_set_inode_ops(inode); + linvfs_revalidate_core(inode, ATTR_COMM); } VN_UNLOCK(vp, s); } --==_Exmh_-3338402560-- From owner-linux-xfs@oss.sgi.com Mon Jun 4 09:07:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54G7RM09027 for linux-xfs-outgoing; Mon, 4 Jun 2001 09:07:27 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54G7Rh09024 for ; Mon, 4 Jun 2001 09:07:27 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA29178 for ; Mon, 4 Jun 2001 09:07:25 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA2055838; Mon, 4 Jun 2001 11:06:09 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA57383; Mon, 4 Jun 2001 11:06:09 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f54G8L630757; Mon, 4 Jun 2001 11:08:21 -0500 Message-Id: <200106041608.f54G8L630757@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: marchuk@ee.washington.edu cc: Steve Lord , Felix Ide , linux-xfs@oss.sgi.com Subject: Re: permission problems.. In-Reply-To: Message from marchuk@ee.washington.edu of "Mon, 04 Jun 2001 08:23:07 PDT." Date: Mon, 04 Jun 2001 11:08:21 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Following up my own message - forget the patch, it does not work. I have replicated something here, more later. Steve From owner-linux-xfs@oss.sgi.com Mon Jun 4 09:35:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54GZUE09967 for linux-xfs-outgoing; Mon, 4 Jun 2001 09:35:30 -0700 Received: from FW2.dt.navy.mil (FW2.dt.navy.mil [192.5.27.136]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54GZPh09964 for ; Mon, 4 Jun 2001 09:35:25 -0700 Received: by FW2.dt.navy.mil; id MAA16338; Mon, 4 Jun 2001 12:37:26 -0400 (EDT) Received: from unknown(130.46.225.16) by FW2.dt.navy.mil via smap (V5.5) id xma015457; Mon, 4 Jun 01 12:36:22 -0400 Received: from NAVGATE.dt.navy.mil (navgate.dt.navy.mil [130.46.225.15]) by smtprelay.dt.navy.mil (8.9.3/8.9.3) with SMTP id MAA04535 for ; Mon, 4 Jun 2001 12:34:14 -0400 Received: from crbeex01.nswccd.navy.mil ([130.46.5.84]) by NAVGATE.dt.navy.mil (NAVIEG 2.1 bld 63) with SMTP id M2001060412341404124 ; Mon, 04 Jun 2001 12:34:14 -0400 Received: from PROFESSOR.dt.navy.mil ([157.187.160.235]) by crbeex01.nswccd.navy.mil with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M21X7K0W; Mon, 4 Jun 2001 12:34:12 -0400 Received: from jtsdell (Bayview162-40.dt.navy.mil [157.187.162.40]) by professor.dt.navy.mil (8.8.8+Sun/8.8.8) with ESMTP id JAA16765; Mon, 4 Jun 2001 09:24:45 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.4.8 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3810251117.991652729@D8H1FF01> Date: Mon, 04 Jun 2001 12:33:30 -0400 (EDT) Reply-To: jtrostel@connex.com Organization: Connex From: John Trostel To: Stephen VanPelt Subject: RE: Setting Permissions with ACLs Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 04-Jun-2001 Stephen VanPelt wrote: > see comments below > ... snip ... > This part looks good too - but here's where I find problems... If I have a > user that I've specified (user1, in this instance) with write access log > into the server (using netatalk - but this doesn't seem to matter), they > cannot open the file if the file isn't chmod'ed to give "other" write > access. Even though the user is given write access in the ACL, they cannot > exercise that access unless it is also allowed in "chmod" (the file > belongs to peltman:peltman - and of course the user is not in either of > those groups - so unless they are set to chmod 006 or 007, then the ACL > doesn't seem to be able to grant any access that the chmod denies). Netatalk has no conception of ACLs. I'm fairly sure it just looks at the standard permission structure to determine access. Therefore, Netatalk doesn't know that there is an added user (or group) with access priviledges. Try with Samba (version 2.20 or ,even better, the latest CVS download) or with a unix user telneted in. Those should work -- John M. Trostel Linux OS Engineer Connex jtrostel@connex.com From owner-linux-xfs@oss.sgi.com Mon Jun 4 09:48:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54Gm0710594 for linux-xfs-outgoing; Mon, 4 Jun 2001 09:48:00 -0700 Received: from revere3.musc.edu (revere3.musc.edu [128.23.203.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54Gm0h10590 for ; Mon, 4 Jun 2001 09:48:00 -0700 Received: from D8H1FF01 ([128.23.211.115]) by revere3.musc.edu (8.8.8/8.8.8) with ESMTP id MAA26035; Mon, 4 Jun 2001 12:47:57 -0400 (EDT) Date: Mon, 04 Jun 2001 12:49:38 -0400 From: Stephen VanPelt To: jtrostel@connex.com cc: linux-xfs@oss.sgi.com Subject: RE: Setting Permissions with ACLs Message-ID: <3816500554.991658978@D8H1FF01> In-Reply-To: Originator-Info: login-id=vanpelts; server=imap.musc.edu X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Actually, though, netatalk is using the system's permission structure, and since the system is recognizing the ACLs, the ACLs are working with netatalk - I just have to make sure that I've run "chmod 667" on the file, and then using the ACLs to limit access. When I do it that way, it works just fine - I just wanted to make sure that there wasn't something that I was missing, or some other better way to do things. -Stephen --On Monday, June 04, 2001 12:33 PM -0400 John Trostel wrote: > > On 04-Jun-2001 Stephen VanPelt wrote: >> see comments below >> > > ... snip ... > >> This part looks good too - but here's where I find problems... If I >> have a user that I've specified (user1, in this instance) with write >> access log into the server (using netatalk - but this doesn't seem to >> matter), they cannot open the file if the file isn't chmod'ed to give >> "other" write access. Even though the user is given write access in >> the ACL, they cannot exercise that access unless it is also allowed in >> "chmod" (the file belongs to peltman:peltman - and of course the user >> is not in either of those groups - so unless they are set to chmod 006 >> or 007, then the ACL doesn't seem to be able to grant any access that >> the chmod denies). > > Netatalk has no conception of ACLs. I'm fairly sure it just looks at the > standard permission structure to determine access. Therefore, Netatalk > doesn't know that there is an added user (or group) with access > priviledges. Try with Samba (version 2.20 or ,even better, the latest > CVS download) or with a unix user telneted in. Those should work > > -- > John M. Trostel > Linux OS Engineer > Connex > jtrostel@connex.com Stephen VanPelt Information Technology Consultant MUSC Center for Drug and Alcohol Programs PH: 843-792-5558 Internet: vanpelts@musc.edu __________________BEGIN FOOTER___________________ **The Views Expressed by the Author of this Message are not ** **necessarily those of the Medical University of South Carolina** From owner-linux-xfs@oss.sgi.com Mon Jun 4 12:26:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54JQCM24408 for linux-xfs-outgoing; Mon, 4 Jun 2001 12:26:12 -0700 Received: from rogue.tripp.org (fdsl9.slkc.uswest.net [209.181.83.9]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54JQ9h24399 for ; Mon, 4 Jun 2001 12:26:09 -0700 Received: from localhost (justin@localhost) by rogue.tripp.org (8.9.3/8.9.3) with ESMTP id NAA05009 for ; Mon, 4 Jun 2001 13:26:08 -0600 (MDT) (envelope-from justin@tripp.org) Date: Mon, 4 Jun 2001 13:26:08 -0600 (MDT) From: X-X-Sender: To: Subject: Backing up a "live" file system. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks for fixing my problem with NF and backups, Steve. After I got caught up with all of the Email, I updated to the 2.4.5 kernel and have returned to testing to see if I can get it to break. So far, it seems like everything is working great. I have a few questions and concerns, though. When I do a backup now, I get lots of warnings from xfsdump, that look like: /usr/sbin/xfsdump: version 3.0 - Running single-threaded /usr/sbin/xfsdump: level 0 dump of fpga:/ibm1 /usr/sbin/xfsdump: dump date: Mon Jun 4 08:54:53 2001 /usr/sbin/xfsdump: session id: a2de6a1b-bdff-4989-abf9-5da1b3d7654e /usr/sbin/xfsdump: session label: "" /usr/sbin/xfsdump: ino map phase 1: skipping (no subtrees specified) /usr/sbin/xfsdump: ino map phase 2: constructing initial dump list /usr/sbin/xfsdump: ino map phase 3: skipping (no pruning necessary) /usr/sbin/xfsdump: ino map phase 4: skipping (size estimated in phase 2) /usr/sbin/xfsdump: ino map phase 5: skipping (only one dump stream) /usr/sbin/xfsdump: ino map construction complete /usr/sbin/xfsdump: estimated dump size: 1455549376 bytes /usr/sbin/xfsdump: creating dump session media file 0 (media 0, file 0) /usr/sbin/xfsdump: dumping ino map /usr/sbin/xfsdump: dumping directories /usr/sbin/xfsdump: dumping non-directory files /usr/sbin/xfsdump: WARNING: could not open regular file ino 38931 mode 0x000081b4: No such file or directory: not dumped /usr/sbin/xfsdump: WARNING: could not open regular file ino 4235279 mode 0x000081b4: No such file or directory: not dumped /usr/sbin/xfsdump: WARNING: could not open regular file ino 4235286 mode 0x000081b4: No such file or directory: not dumped /usr/sbin/xfsdump: WARNING: could not open regular file ino 4235334 mode 0x000081b4: No such file or directory: not dumped /usr/sbin/xfsdump: WARNING: could not open regular file ino 8431240 mode 0x000081b4: No such file or directory: not dumped /usr/sbin/xfsdump: WARNING: could not open regular file ino 37787402 mode 0x000081b4: No such file or directory: not dumped /usr/sbin/xfsdump: WARNING: could not open regular file ino 67149350 mode 0x000081b4: No such file or directory: not dumped /usr/sbin/xfsdump: WARNING: could not open regular file ino 79731656 mode 0x000081b4: No such file or directory: not dumped /usr/sbin/xfsdump: WARNING: could not open regular file ino 79732162 mode 0x000081b4: No such file or directory: not dumped /usr/sbin/xfsdump: ending media file /usr/sbin/xfsdump: media file size 876457568 bytes /usr/sbin/xfsdump: dump size (non-dir files) : 770291976 bytes /usr/sbin/xfsdump: dump complete: 10565 seconds elapsed It says that it could not open a regular file and it was not dumped. I wonder if that is all the information that is available, or if I could find out what the name of the file is that corresponds to that inode. It could be that xfsdump sees inodes and then has to map those to names, which might make sense why it would not dump the inode -- since it did not correlate to an actual file. Is that what is going or is it something different. Also when I xfsrestore from the dump file, it says that it has many more inodes that were stored on the dump file that are not referenced and they end up into the orphanage directory: xfsrestore: version 3.0 - Running single-threaded xfsrestore: searching media for dump xfsrestore: examining media file 0 xfsrestore: dump description: xfsrestore: hostname: fpga xfsrestore: mount point: /ibm1 xfsrestore: volume: /dev/sda1 xfsrestore: session time: Sun Jun 3 14:23:52 2001 xfsrestore: level: 0 xfsrestore: session label: "" xfsrestore: media label: "" xfsrestore: file system id: 11c2b403-b066-4d54-bc6b-2999de0b0192 xfsrestore: session id: da423fc8-eae5-4ddb-8dc5-c8d03f4ae9d1 xfsrestore: media id: 1fbb2b7e-68e8-4831-a3a5-c480e6db44e3 xfsrestore: searching media for directory dump xfsrestore: reading directories xfsrestore: directory post-processing xfsrestore: restoring non-directory files xfsrestore: NOTE: ino 37978 gen 3 not referenced: placing in orphanage xfsrestore: NOTE: ino 33592109 gen 3 not referenced: placing in orphanage xfsrestore: NOTE: ino 33593217 gen 4 not referenced: placing in orphanage xfsrestore: NOTE: ino 37785398 gen 4 not referenced: placing in orphanage xfsrestore: NOTE: ino 41983155 gen 5 not referenced: placing in orphanage xfsrestore: NOTE: ino 46176727 gen 3 not referenced: placing in orphanage xfsrestore: NOTE: ino 50373364 gen 4 not referenced: placing in orphanage xfsrestore: NOTE: ino 50373834 gen 1 not referenced: placing in orphanage xfsrestore: NOTE: ino 50373863 gen 1 not referenced: placing in orphanage xfsrestore: NOTE: ino 54565523 gen 3 not referenced: placing in orphanage xfsrestore: NOTE: ino 54565749 gen 4 not referenced: placing in orphanage xfsrestore: NOTE: ino 54565800 gen 2 not referenced: placing in orphanage xfsrestore: NOTE: ino 54565813 gen 1 not referenced: placing in orphanage xfsrestore: NOTE: ino 58757929 gen 7 not referenced: placing in orphanage xfsrestore: NOTE: ino 58758899 gen 3 not referenced: placing in orphanage xfsrestore: NOTE: ino 58758977 gen 2 not referenced: placing in orphanage xfsrestore: NOTE: ino 58759034 gen 2 not referenced: placing in orphanage xfsrestore: NOTE: ino 62952384 gen 1 not referenced: placing in orphanage xfsrestore: NOTE: ino 62952430 gen 3 not referenced: placing in orphanage ... xfsrestore: NOTE: ino 184588623 gen 1 not referenced: placing in orphanage xfsrestore: NOTE: ino 184588682 gen 2 not referenced: placing in orphanage xfsrestore: NOTE: ino 184588691 gen 1 not referenced: placing in orphanage xfsrestore: NOTE: ino 184588708 gen 3 not referenced: placing in orphanage xfsrestore: NOTE: ino 184588709 gen 2 not referenced: placing in orphanage xfsrestore: NOTE: ino 184588718 gen 1 not referenced: placing in orphanage xfsrestore: WARNING: unable to rmdir /ibm3/test/orphanage: Directory not empty xfsrestore: restore complete: 9559 seconds elapsed My backup consists of two actively updated news spools of the comp.* hierarchy. They are on the order of 500,000 files. The backup happens as the spools are being updated so that files can change during the course of the backup. It seems odd that although 8-10 inodes could not be backed up, the xfsrestore could not restore 305 inodes that ?probably? were okay at xfsdump time? 305 files out of 500,000 is not that much, but does not seem too tolerable. If these files are files that disappeared during the backup process, it might be okay. Can anyone comment on this? Also if you look at the above xfdump report, it says that the filesystem was about 1.4G and the resultant backup was 860M. When I did the restore, it was back to about the correct original 1.4G, can anyone comment on why xfsdump is able to get such good compression? Thanks for you help and thanks for the good filesystem. .justin. ------------------------------------------------------------------------ Justin Leonard Tripp justin@ee.byu.edu Configurable Computing Laboratory Research Assistant CB 461 x8-7206 Electrical and Computer Engineering Department Brigham Young University From owner-linux-xfs@oss.sgi.com Mon Jun 4 12:55:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54JtKk28760 for linux-xfs-outgoing; Mon, 4 Jun 2001 12:55:20 -0700 Received: from rogue.tripp.org (fdsl9.slkc.uswest.net [209.181.83.9]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54JtIh28749 for ; Mon, 4 Jun 2001 12:55:18 -0700 Received: from localhost (justin@localhost) by rogue.tripp.org (8.9.3/8.9.3) with ESMTP id NAA05274; Mon, 4 Jun 2001 13:55:12 -0600 (MDT) (envelope-from justin@ee.byu.edu) X-Authentication-Warning: rogue.tripp.org: justin owned process doing -bs Date: Mon, 4 Jun 2001 13:55:12 -0600 (MDT) From: X-X-Sender: To: Bas cc: Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. In-Reply-To: <005e01c0ec4c$713c49e0$0f01a8c0@ws1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a known issue in the 2.4.5 kernel. And has already come up in this list. When selecting the AIC7xxx support you need to mark that you should: [ ] Build Adapter Firmware with Kernel Build (NEW) It is the last option under Adaptec AIC7xxx support. The firmware included in the 2.4.5 release is out of sync with the kernel driver. I have not done this myself, since my current XFS machine does not have a SCSI controller, but see the below email for more info. .justin. From lord@sgi.com Mon Jun 4 13:54:17 2001 Date: Wed, 30 May 2001 13:03:51 -0500 From: Steve Lord To: linux-xfs@oss.sgi.com Subject: Re: 2.4.5 panic while starting aic7xxx (fwd) Forwarded from linux-kernel, since this was originally asked on the xfs list. Steve ------- Forwarded Message Date: Wed, 30 May 2001 09:19:02 -0600 From: "Justin T. Gibbs" To: Michael David cc: linux-kernel@vger.kernel.org Subject: Re: 2.4.5 panic while starting aic7xxx >SCSI subsystem driver Revision: 1.00 >PCI: Found IRQ 11 for device 00:0c.0 >scsi0: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.13 > > aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/255 SCBs >ahc_intr: AWAITING_MSG for an SCB that does not have a waiting message >SCSIID = 7, target_mask = 1 >Kernel panic: SCB = 3, SCB Control = 40, MSG_OUT = 80 SCB flags = 6000 >In interrupt handler - not syncing This looks like the firmware file is not in sync with the rest of the driver. Depending on the host environment, you may be able to rebuild the firmware yourself. Just check the box in the kernel config section for the aic7xxx driver to rebuild the firmware. - -- Justin - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ------- End of Forwarded Message ------------------------------------------------------------------------ Justin Leonard Tripp justin@ee.byu.edu Configurable Computing Laboratory Research Assistant CB 461 x8-7206 Electrical and Computer Engineering Department Brigham Young University On Sun, 3 Jun 2001, Bas wrote: > Hi, > > I read this is an general 2.4.5 issue and I should contact the maintainer. > But does anybody know if it has been fixed already and where I can get the > patch. An URL would be great ! > > Thanks, > Bas. > > From owner-linux-xfs@oss.sgi.com Mon Jun 4 13:31:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54KVWE02457 for linux-xfs-outgoing; Mon, 4 Jun 2001 13:31:32 -0700 Received: from best.micron.net (best.micron.net [204.229.122.199]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54KVVh02454 for ; Mon, 4 Jun 2001 13:31:31 -0700 Received: from 10.224.0.199 ([10.224.0.199]) by best.micron.net (Netscape Messaging Server 4.1) with SMTP id GEFACI00.629 for ; Mon, 4 Jun 2001 14:31:30 -0600 Received: from garfield.linux.localdomain (1Cust115.tnt5.lax3.da.uu.net [63.23.66.115]) by with SMTP (MailShield v1.5); Mon, 04 Jun 2001 14:31:29 -0600 Content-Type: text/plain; charset="iso-8859-1" From: J Hayward To: linux-xfs@oss.sgi.com Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. Date: Mon, 4 Jun 2001 13:28:56 -0700 X-Mailer: KMail [version 1.2] References: In-Reply-To: MIME-Version: 1.0 Message-Id: <01060413285600.09944@garfield.linux.localdomain> Content-Transfer-Encoding: 8bit X-SMTP-HELO: garfield.linux.localdomain X-SMTP-MAIL-FROM: jhayward@micron.net X-SMTP-PEER-INFO: 1Cust115.tnt5.lax3.da.uu.net [63.23.66.115] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, > > [ ] Build Adapter Firmware with Kernel Build (NEW) > > It is the last option under Adaptec AIC7xxx support. The firmware > included in the 2.4.5 release is out of sync with the kernel driver. > > I have not done this myself, since my current XFS machine does not have a > SCSI controller, but see the below email for more info. Has anyone had any success using this option? Didn't work for me. Problem isn't isolated to just the 7890 it seems, I get the same error on a Adaptec 2930CU. It still produced: >In interrupt handler - not syncing I also tried using the old aic7xxx driver, which did load the module. However it produced a kernel oops immediately after. I don't remember the exact point in the boot sequence, I believe it was at "Trying to unmount old root". Regards, Jim H From owner-linux-xfs@oss.sgi.com Mon Jun 4 13:39:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54Kd5N04257 for linux-xfs-outgoing; Mon, 4 Jun 2001 13:39:05 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54Kd4h04252 for ; Mon, 4 Jun 2001 13:39:04 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA1453885 for ; Mon, 4 Jun 2001 22:39:01 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2057952; Mon, 4 Jun 2001 15:37:44 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA39368; Mon, 4 Jun 2001 15:37:44 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f54Kdsk01023; Mon, 4 Jun 2001 15:39:54 -0500 Message-Id: <200106042039.f54Kdsk01023@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: J Hayward cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. In-Reply-To: Message from J Hayward of "Mon, 04 Jun 2001 13:28:56 PDT." <01060413285600.09944@garfield.linux.localdomain> Date: Mon, 04 Jun 2001 15:39:54 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hello, > > > > > [ ] Build Adapter Firmware with Kernel Build (NEW) > > > > It is the last option under Adaptec AIC7xxx support. The firmware > > included in the 2.4.5 release is out of sync with the kernel driver. > > > > I have not done this myself, since my current XFS machine does not have a > > SCSI controller, but see the below email for more info. > > Has anyone had any success using this option? Didn't work for me. Problem > isn't isolated to just the 7890 it seems, I get the same error on a Adaptec > 2930CU. It still produced: > > >In interrupt handler - not syncing > > I also tried using the old aic7xxx driver, which did load the module. However > > it produced a kernel oops immediately after. I don't remember the exact point > > in the boot sequence, I believe it was at "Trying to unmount old root". Wait, that might not be the adaptec at all, there was some thread about an initrd problem in the 2.4.5 kernel. You might want to try this patch: --- linux/fs/block_dev.c.orig Mon May 28 12:40:12 2001 +++ linux/fs/block_dev.c Mon May 28 12:40:12 2001 @@ -602,6 +602,7 @@ if (!bdev->bd_op->ioctl) return -EINVAL; inode_fake.i_rdev=rdev; + inode_fake.i_bdev=bdev; init_waitqueue_head(&inode_fake.i_wait); set_fs(KERNEL_DS); res = bdev->bd_op->ioctl(&inode_fake, NULL, cmd, arg); Note my mail tool may have messed that up when I cut and pasted it. Steve > > Regards, > Jim H From owner-linux-xfs@oss.sgi.com Mon Jun 4 13:45:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54KjFC05646 for linux-xfs-outgoing; Mon, 4 Jun 2001 13:45:15 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54KjCh05631 for ; Mon, 4 Jun 2001 13:45:12 -0700 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA00879 for ; Mon, 4 Jun 2001 13:45:11 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2057700; Mon, 4 Jun 2001 15:43:55 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA74022; Mon, 4 Jun 2001 15:43:54 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f54Kk4k01040; Mon, 4 Jun 2001 15:46:04 -0500 Message-Id: <200106042046.f54Kk4k01040@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: justin@ee.byu.edu cc: linux-xfs@oss.sgi.com Subject: Re: Backing up a "live" file system. In-Reply-To: Message from of "Mon, 04 Jun 2001 13:26:08 MDT." Date: Mon, 04 Jun 2001 15:46:04 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Thanks for fixing my problem with NF and backups, Steve. After I got > caught up with all of the Email, I updated to the 2.4.5 kernel and have > returned to testing to see if I can get it to break. So far, it seems > like everything is working great. > > I have a few questions and concerns, though. > > When I do a backup now, I get lots of warnings from xfsdump, that look > like: Someone who understands xfs dump better than I can probably give you a more reasonable explaination, but basically, the first pass of the dump is an inode scan of the whole filesystem. This is used to decide what to dump. We then take the list of inodes and go open them in turn, if they have gone missing in the meantime then you get warnings about not being able to open them. Note that pathnames are not used in the dump process to look up the inodes, or to open them. On the restore end I suspect you are seeing more results of files changing underneath you - these were inodes which could be opened by dump, but which were in unlinked state at dump time. Finally, the amount of space to be used is only an estimate, I do not know how accurate it normally is on Irix, but a factor of 2 looks a bit large. Steve > > /usr/sbin/xfsdump: version 3.0 - Running single-threaded > /usr/sbin/xfsdump: level 0 dump of fpga:/ibm1 > /usr/sbin/xfsdump: dump date: Mon Jun 4 08:54:53 2001 > /usr/sbin/xfsdump: session id: a2de6a1b-bdff-4989-abf9-5da1b3d7654e > /usr/sbin/xfsdump: session label: "" > /usr/sbin/xfsdump: ino map phase 1: skipping (no subtrees specified) > /usr/sbin/xfsdump: ino map phase 2: constructing initial dump list > /usr/sbin/xfsdump: ino map phase 3: skipping (no pruning necessary) > /usr/sbin/xfsdump: ino map phase 4: skipping (size estimated in phase 2) > /usr/sbin/xfsdump: ino map phase 5: skipping (only one dump stream) > /usr/sbin/xfsdump: ino map construction complete > /usr/sbin/xfsdump: estimated dump size: 1455549376 bytes > /usr/sbin/xfsdump: creating dump session media file 0 (media 0, file 0) > /usr/sbin/xfsdump: dumping ino map > /usr/sbin/xfsdump: dumping directories > /usr/sbin/xfsdump: dumping non-directory files > /usr/sbin/xfsdump: WARNING: could not open regular file ino 38931 mode > 0x000081b4: No such file or directory: not dumped > /usr/sbin/xfsdump: WARNING: could not open regular file ino 4235279 mode > 0x000081b4: No such file or directory: not dumped > /usr/sbin/xfsdump: WARNING: could not open regular file ino 4235286 mode > 0x000081b4: No such file or directory: not dumped > /usr/sbin/xfsdump: WARNING: could not open regular file ino 4235334 mode > 0x000081b4: No such file or directory: not dumped > /usr/sbin/xfsdump: WARNING: could not open regular file ino 8431240 mode > 0x000081b4: No such file or directory: not dumped > /usr/sbin/xfsdump: WARNING: could not open regular file ino 37787402 mode > 0x000081b4: No such file or directory: not dumped > /usr/sbin/xfsdump: WARNING: could not open regular file ino 67149350 mode > 0x000081b4: No such file or directory: not dumped > /usr/sbin/xfsdump: WARNING: could not open regular file ino 79731656 mode > 0x000081b4: No such file or directory: not dumped > /usr/sbin/xfsdump: WARNING: could not open regular file ino 79732162 mode > 0x000081b4: No such file or directory: not dumped > /usr/sbin/xfsdump: ending media file > /usr/sbin/xfsdump: media file size 876457568 bytes > /usr/sbin/xfsdump: dump size (non-dir files) : 770291976 bytes > /usr/sbin/xfsdump: dump complete: 10565 seconds elapsed > > It says that it could not open a regular file and it was not dumped. I > wonder if that is all the information that is available, or if I could > find out what the name of the file is that corresponds to that inode. It > could be that xfsdump sees inodes and then has to map those to names, > which might make sense why it would not dump the inode -- since it did not > correlate to an actual file. Is that what is going or is it something > different. > > Also when I xfsrestore from the dump file, it says that it has many more > inodes that were stored on the dump file that are not referenced and they > end up into the orphanage directory: > > xfsrestore: version 3.0 - Running single-threaded > xfsrestore: searching media for dump > xfsrestore: examining media file 0 > xfsrestore: dump description: > xfsrestore: hostname: fpga > xfsrestore: mount point: /ibm1 > xfsrestore: volume: /dev/sda1 > xfsrestore: session time: Sun Jun 3 14:23:52 2001 > xfsrestore: level: 0 > xfsrestore: session label: "" > xfsrestore: media label: "" > xfsrestore: file system id: 11c2b403-b066-4d54-bc6b-2999de0b0192 > xfsrestore: session id: da423fc8-eae5-4ddb-8dc5-c8d03f4ae9d1 > xfsrestore: media id: 1fbb2b7e-68e8-4831-a3a5-c480e6db44e3 > xfsrestore: searching media for directory dump > xfsrestore: reading directories > xfsrestore: directory post-processing > xfsrestore: restoring non-directory files > xfsrestore: NOTE: ino 37978 gen 3 not referenced: placing in orphanage > xfsrestore: NOTE: ino 33592109 gen 3 not referenced: placing in orphanage > xfsrestore: NOTE: ino 33593217 gen 4 not referenced: placing in orphanage > xfsrestore: NOTE: ino 37785398 gen 4 not referenced: placing in orphanage > xfsrestore: NOTE: ino 41983155 gen 5 not referenced: placing in orphanage > xfsrestore: NOTE: ino 46176727 gen 3 not referenced: placing in orphanage > xfsrestore: NOTE: ino 50373364 gen 4 not referenced: placing in orphanage > xfsrestore: NOTE: ino 50373834 gen 1 not referenced: placing in orphanage > xfsrestore: NOTE: ino 50373863 gen 1 not referenced: placing in orphanage > xfsrestore: NOTE: ino 54565523 gen 3 not referenced: placing in orphanage > xfsrestore: NOTE: ino 54565749 gen 4 not referenced: placing in orphanage > xfsrestore: NOTE: ino 54565800 gen 2 not referenced: placing in orphanage > xfsrestore: NOTE: ino 54565813 gen 1 not referenced: placing in orphanage > xfsrestore: NOTE: ino 58757929 gen 7 not referenced: placing in orphanage > xfsrestore: NOTE: ino 58758899 gen 3 not referenced: placing in orphanage > xfsrestore: NOTE: ino 58758977 gen 2 not referenced: placing in orphanage > xfsrestore: NOTE: ino 58759034 gen 2 not referenced: placing in orphanage > xfsrestore: NOTE: ino 62952384 gen 1 not referenced: placing in orphanage > xfsrestore: NOTE: ino 62952430 gen 3 not referenced: placing in orphanage > ... > > xfsrestore: NOTE: ino 184588623 gen 1 not referenced: placing in orphanage > xfsrestore: NOTE: ino 184588682 gen 2 not referenced: placing in orphanage > xfsrestore: NOTE: ino 184588691 gen 1 not referenced: placing in orphanage > xfsrestore: NOTE: ino 184588708 gen 3 not referenced: placing in orphanage > xfsrestore: NOTE: ino 184588709 gen 2 not referenced: placing in orphanage > xfsrestore: NOTE: ino 184588718 gen 1 not referenced: placing in orphanage > xfsrestore: WARNING: unable to rmdir /ibm3/test/orphanage: Directory not empt > y > xfsrestore: restore complete: 9559 seconds elapsed > > My backup consists of two actively updated news spools of the comp.* > hierarchy. They are on the order of 500,000 files. The backup happens > as the spools are being updated so that files can change during the course > of the backup. It seems odd that although 8-10 inodes could not be > backed up, the xfsrestore could not restore 305 inodes that ?probably? > were okay at xfsdump time? 305 files out of 500,000 is not that much, but > does not seem too tolerable. If these files are files that disappeared > during the backup process, it might be okay. Can anyone comment on this? > > Also if you look at the above xfdump report, it says that the filesystem > was about 1.4G and the resultant backup was 860M. When I did the restore, > it was back to about the correct original 1.4G, can anyone comment on why > xfsdump is able to get such good compression? > > Thanks for you help and thanks for the good filesystem. > > .justin. > > > ------------------------------------------------------------------------ > Justin Leonard Tripp justin@ee.byu.edu > Configurable Computing Laboratory Research Assistant CB 461 x8-7206 > Electrical and Computer Engineering Department Brigham Young University From owner-linux-xfs@oss.sgi.com Mon Jun 4 13:48:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54Km0r06368 for linux-xfs-outgoing; Mon, 4 Jun 2001 13:48:00 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54Klxh06361 for ; Mon, 4 Jun 2001 13:47:59 -0700 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA00451 for ; Mon, 4 Jun 2001 13:47:58 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2060203; Mon, 4 Jun 2001 15:46:41 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA75530; Mon, 4 Jun 2001 15:46:41 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f54KmpT01053; Mon, 4 Jun 2001 15:48:51 -0500 Message-Id: <200106042048.f54KmpT01053@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: ctooley@amoa.org cc: linux-xfs@oss.sgi.com Subject: Re: New files on xfs ftp site In-Reply-To: Message from ctooley@amoa.org of "Fri, 01 Jun 2001 08:25:22 CDT." <86256A5E.0049BC33.00@amoa.org> Date: Mon, 04 Jun 2001 15:48:51 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > > So if I want to upgrade to 2.4.5 via building a kernel RPM (I know this seems > odd, but I've got 4 machines running XFS and would just like to keep them > consistent) what all would I have to apply to 2.4.5 code to be able to repace > the 2.4.2 code in the SRPM? > > Chris Tooley > > How good are you with RPM? The spec file for the kernel rpm is from redhat and has a couple of hundred patches it applies to the kernel before building it. Some of these patches are necessary if you want anaconda to run on your kernel, and some are new features and enhancements. Most of them probably do not work with 2.4.5. So you probably need to rip the guts out of the spec file, and change it to use a 2.4.5 tar file, and the xfs patch. Note that the patch on the ftp site has been updated to not include aic driver files. Once you have the spec files, patches and tar files in the correct place, all you really need to do is type rpm -bb spec-file-path. Steve From owner-linux-xfs@oss.sgi.com Mon Jun 4 13:56:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54Ku5U08157 for linux-xfs-outgoing; Mon, 4 Jun 2001 13:56:05 -0700 Received: from wisdom.myplace.net (cc19815-a.zwoll1.ov.nl.home.com [212.204.138.247]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54Ku4h08146 for ; Mon, 4 Jun 2001 13:56:04 -0700 Received: from ws1 (ws1.myplace.net [192.168.1.15]) by wisdom.myplace.net (Postfix) with SMTP id D60972008B for ; Mon, 4 Jun 2001 22:56:02 +0200 (CEST) Message-ID: <011501c0ed31$58a54360$0f01a8c0@ws1> From: "Bas" To: References: <01060413285600.09944@garfield.linux.localdomain> Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. Date: Mon, 4 Jun 2001 22:02:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ----- Original Message ----- From: "J Hayward" To: Sent: Monday, June 04, 2001 10:28 PM Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. > Hello, > > > > > [ ] Build Adapter Firmware with Kernel Build (NEW) > > > > It is the last option under Adaptec AIC7xxx support. The firmware > > included in the 2.4.5 release is out of sync with the kernel driver. > > > > I have not done this myself, since my current XFS machine does not have a > > SCSI controller, but see the below email for more info. > > Has anyone had any success using this option? Didn't work for me. Problem > isn't isolated to just the 7890 it seems, I get the same error on a Adaptec > 2930CU. It still produced: > > >In interrupt handler - not syncing > > I also tried using the old aic7xxx driver, which did load the module. However > it produced a kernel oops immediately after. I don't remember the exact point > in the boot sequence, I believe it was at "Trying to unmount old root". > > Regards, > Jim H > > Tried the firmware option too, but didn't work for me. Thanks, Bas. From owner-linux-xfs@oss.sgi.com Mon Jun 4 14:21:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54LLBP12905 for linux-xfs-outgoing; Mon, 4 Jun 2001 14:21:11 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54LLAh12902 for ; Mon, 4 Jun 2001 14:21:10 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f54LL4aJ006463 for ; Mon, 4 Jun 2001 16:21:05 -0500 (CDT) Message-ID: <3B1BFBB7.1A1AC540@thebarn.com> Date: Mon, 04 Jun 2001 16:20:57 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: CVSup now available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've added ftp.thebarn.com to the list of machines that receives the hourly cvs push. I've also added linux-xfs and linux-xfs-r1.0 to the list of packaged served by the cvsupd server. So until the firewall situation is worked out the XFS source tree may one again be obtained via CVSup. Simply change the sup config file to *default host=ftp.thebarn.com *default base=. *default release=cvs tag=. *default delete use-rel-suffix *default prefix=/tmp/cvsupit *default compress linux-xfs -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Mon Jun 4 15:53:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54MrXm26428 for linux-xfs-outgoing; Mon, 4 Jun 2001 15:53:33 -0700 Received: from hotmail.com (oe54.law9.hotmail.com [64.4.8.47]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54MrWh26425 for ; Mon, 4 Jun 2001 15:53:32 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 4 Jun 2001 15:53:27 -0700 X-Originating-IP: [212.144.219.60] From: "Kai Leibrandt" To: Subject: mkfs.xfs options for DAC960 RAID volumes (long) Date: Tue, 5 Jun 2001 00:53:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Message-ID: X-OriginalArrivalTime: 04 Jun 2001 22:53:27.0228 (UTC) FILETIME=[2AC457C0:01C0ED49] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, I just have a small (?) question regarding the following extract from man mkfs.xfs, about the -d options: "The sunit suboption is used to specify the stripe unit for a RAID device or a logical volume. The suboption value has to be specified in 512­byte block units. This suboption ensures that data allocations will be stripe unit aligned when the current end of file is being extended and the file size is larger than 512KB. Also inode allocations and the internal log will be stripe unit aligned. The swidth suboption is used to specify the stripe width for a RAID device or a striped logical volume. The suboption value has to be specified in 512­byte block units. This suboption is required if -d sunit has been specified and it has to be a multiple of the -d sunit suboption. The stripe width will be the preferred iosize returned in the stat(2) system call." My question is about the block sizes in particular. As my DAC960 has a segment size of 8k and a stripe size of 64, it seems to me as though these valuse should be matched by the sunit and swidth options (I'm assuming these will align io transfers to the respective sizes). In the man page it says that these are to be specified in 512byte units, so I'm guessing that I should use -d sunit=16,swidth=128 to achieve vaues of 8Kbyte and 64Kbyte respectively, but the output of mkfs and xfs_info then tell me sunit is then actually 2 and swidth=16blks... Is the blocking size really 512byte as stated in the man page or is it actually the size of a page (i.e. 4Kb with ia32 linux)? In that case it would suddenly all fit - 16 blocks of 4Kb make 64Kb stripe size... So what values of sunit and swidth should be used for 8k segment /64k stripe size ahrdware RAID volumes on ia32? Tomorrow I'll be running some bonnie benchmarks to see what the difference may be... many thanks for any info! Kai. From owner-linux-xfs@oss.sgi.com Mon Jun 4 16:32:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54NWUd00862 for linux-xfs-outgoing; Mon, 4 Jun 2001 16:32:30 -0700 Received: from tux.mkp.net (tux.mkp.net [130.225.60.11]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f54NWTh00858 for ; Mon, 4 Jun 2001 16:32:29 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net) by tux.mkp.net with esmtp (Exim 3.16 #1) id 1573pi-0005b1-00; Tue, 05 Jun 2001 01:32:27 +0200 Received: (from mkp@localhost) by jcb.mkp.net (8.11.0/8.9.3) id f54NWFB11470; Mon, 4 Jun 2001 19:32:15 -0400 X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f To: "Kai Leibrandt" Cc: Subject: Re: mkfs.xfs options for DAC960 RAID volumes (long) References: From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 04 Jun 2001 19:32:15 -0400 In-Reply-To: Message-ID: Lines: 34 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f54NWUh00860 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Kai" == Kai Leibrandt writes: Kai> In the man page it says that these are to be specified in 512byte Kai> units, so I'm guessing that I should use -d sunit,swidth8 to Kai> achieve vaues of 8Kbyte and 64Kbyte respectively, but the output Kai> of mkfs and xfs_info then tell me sunit is then actually 2 and Kai> swidthblks... Is the blocking size really 512byte as stated in Kai> the man page or is it actually the size of a page (i.e. 4Kb with Kai> ia32 linux)? In that case it would suddenly all fit - 16 blocks Kai> of 4Kb make 64Kb stripe size... You have to specify the width in 512 byte sectors while mkfs reports the values back in terms of the filesystem block size. So 4KB blocks in your case. A bit confusing, yes. Nathan and I talked about changing it or making it more obvious at some point but never got around to do it. komatsu# mkfs.xfs -f /dev/vg00/lv00 meta-data=/dev/vg00/lv00 isize=256 agcount=10, agsize=262144 blks data = bsize=4096 blocks=2621440, imaxpct=25 = sunit=16 swidth=80 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=327680 blocks=0, rtextents=0 I.e. "blks" after swidth=80 above actually refer to bsize sized blocks. Just like on the first line containing the allocation group size. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Mon Jun 4 17:27:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f550RJo08653 for linux-xfs-outgoing; Mon, 4 Jun 2001 17:27:19 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f550RHh08650 for ; Mon, 4 Jun 2001 17:27:17 -0700 Received: from boing.melbourne.sgi.com ([134.14.55.141]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA06364 for ; Mon, 4 Jun 2001 17:27:11 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA06391; Tue, 5 Jun 2001 10:25:51 +1000 (EST) Date: Tue, 5 Jun 2001 10:25:51 +1000 From: Timothy Shimmin To: Bas Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. Message-ID: <20010605102551.Z97441@boing.melbourne.sgi.com> References: <01060413285600.09944@garfield.linux.localdomain> <011501c0ed31$58a54360$0f01a8c0@ws1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <011501c0ed31$58a54360$0f01a8c0@ws1>; from list@showme.wox.org on Mon, Jun 04, 2001 at 10:02:56PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Jun 04, 2001 at 10:02:56PM +0200, Bas wrote: > > From: "J Hayward" > Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. > > > > [ ] Build Adapter Firmware with Kernel Build (NEW) > > > > > > It is the last option under Adaptec AIC7xxx support. The firmware > > > included in the 2.4.5 release is out of sync with the kernel driver. > > > > > > I have not done this myself, since my current XFS machine does not have > a > > > SCSI controller, but see the below email for more info. > > > > Has anyone had any success using this option? Didn't work for me. Problem > > isn't isolated to just the 7890 it seems, I get the same error on a > Adaptec > > 2930CU. It still produced: > > > > >In interrupt handler - not syncing > > > > I also tried using the old aic7xxx driver, which did load the module. > However > > it produced a kernel oops immediately after. I don't remember the exact > point > > in the boot sequence, I believe it was at "Trying to unmount old root". > > Tried the firmware option too, but didn't work for me. > Tried the firmware option too, and it did work for me. scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.13 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/255 SCBs --Tim From owner-linux-xfs@oss.sgi.com Mon Jun 4 19:38:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f552cO725645 for linux-xfs-outgoing; Mon, 4 Jun 2001 19:38:24 -0700 Received: from westerdale.org (IDENT:root@ool-18be8920.dyn.optonline.net [24.190.137.32]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f552cNh25641 for ; Mon, 4 Jun 2001 19:38:23 -0700 Received: from westerdale.org (IDENT:westerj@fw.westerdale.org [10.1.1.1]) by westerdale.org (8.11.0/8.11.0) with ESMTP id f552ciD00372 for ; Mon, 4 Jun 2001 22:38:44 -0400 Message-ID: <3B1C4634.C108F972@westerdale.org> Date: Mon, 04 Jun 2001 22:38:44 -0400 From: John Westerdale Reply-To: john@westerdale.org Organization: Long Pond Industries X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS and Kernel People! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Folks, What are the chances that XFS will make it into the kernel tree? Will it take some of Alan's or Linus's time? Have a couple machines running RHL 7.1 and XFS , and it rocks! But the Philips USB Camera is in Kernel source now, and that puts me wanting 2.4.5, but not sure what will happen if XFS remains a patch. Thanks very very much for putting in the Hurculean Effort. Hope it pays of soon! John Westerdale -- # When walking in the steps of another, you learn what # # you never knew, you never knew. # From owner-linux-xfs@oss.sgi.com Mon Jun 4 22:01:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f5551H112021 for linux-xfs-outgoing; Mon, 4 Jun 2001 22:01:17 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f5551Gh12018 for ; Mon, 4 Jun 2001 22:01:16 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id WAA25110 for ; Mon, 4 Jun 2001 22:01:09 -0700 (PDT) mail_from (ivanr@melbourne.sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA07636; Tue, 5 Jun 2001 14:59:39 +1000 From: ivanr@melbourne.sgi.com (Ivan Rayner) Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id OAA77480; Tue, 5 Jun 2001 14:59:38 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Tue, 5 Jun 2001 14:59:38 +1000 To: cc: Subject: Re: Backing up a "live" file system. In-Reply-To: <200106042046.f54Kk4k01040@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 4 Jun 2001, Steve Lord wrote: > > > > Thanks for fixing my problem with NF and backups, Steve. After I got > > caught up with all of the Email, I updated to the 2.4.5 kernel and have > > returned to testing to see if I can get it to break. So far, it seems > > like everything is working great. > > > > I have a few questions and concerns, though. > > > > When I do a backup now, I get lots of warnings from xfsdump, that look > > like: > > Someone who understands xfs dump better than I can probably give you a > more reasonable explaination, but basically, the first pass of the dump is > an inode scan of the whole filesystem. This is used to decide what to > dump. We then take the list of inodes and go open them in turn, if they > have gone missing in the meantime then you get warnings about not being > able to open them. Note that pathnames are not used in the dump process > to look up the inodes, or to open them. Unfortunately, while xfsdump does need to store the directory structure in the dump, when xfsdump gets around to actually dumping the file data, this information is long gone, so there is no way to output the name of those files which didn't get dumped. You could use 'find / -inum xxx' to find the file after the dump, but of course this would be too late ... :) 'course if you did find the file afterwards then we'd have a more serious problem! > On the restore end I suspect you are seeing more results of files changing > underneath you - these were inodes which could be opened by dump, but which > were in unlinked state at dump time. > > Finally, the amount of space to be used is only an estimate, I do not know > how accurate it normally is on Irix, but a factor of 2 looks a bit large. The size estimate is based on the blocksize multiplied by the number of blocks used for each file. The problem here is that there is a huge number (500,000) of small files, and given that the estimate is off by about 1k per file, I'd say the difference is just blocksize vs. filesize. Ivan > > My backup consists of two actively updated news spools of the comp.* > > hierarchy. They are on the order of 500,000 files. The backup happens > > as the spools are being updated so that files can change during the course > > of the backup. It seems odd that although 8-10 inodes could not be > > backed up, the xfsrestore could not restore 305 inodes that ?probably? > > were okay at xfsdump time? 305 files out of 500,000 is not that much, but > > does not seem too tolerable. If these files are files that disappeared > > during the backup process, it might be okay. Can anyone comment on this? > > > > Also if you look at the above xfdump report, it says that the filesystem > > was about 1.4G and the resultant backup was 860M. When I did the restore, > > it was back to about the correct original 1.4G, can anyone comment on why > > xfsdump is able to get such good compression? > > > > Thanks for you help and thanks for the good filesystem. > > > > .justin. > > > > > > ------------------------------------------------------------------------ > > Justin Leonard Tripp justin@ee.byu.edu > > Configurable Computing Laboratory Research Assistant CB 461 x8-7206 > > Electrical and Computer Engineering Department Brigham Young University > > -- Ivan Rayner ivanr@melbourne.sgi.com From owner-linux-xfs@oss.sgi.com Mon Jun 4 22:48:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f555m1j15767 for linux-xfs-outgoing; Mon, 4 Jun 2001 22:48:01 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f555m0h15763 for ; Mon, 4 Jun 2001 22:48:00 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA01556 for ; Mon, 4 Jun 2001 22:48:12 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA34146; Tue, 5 Jun 2001 15:46:41 +1000 (EST) Date: Tue, 5 Jun 2001 15:46:41 +1000 From: Timothy Shimmin To: justin@ee.byu.edu Cc: linux-xfs@oss.sgi.com Subject: Re: Backing up a "live" file system. Message-ID: <20010605154641.D185588@boing.melbourne.sgi.com> References: <200106042046.f54Kk4k01040@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from ivanr@melbourne.sgi.com on Tue, Jun 05, 2001 at 02:59:38PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jun 05, 2001 at 02:59:38PM +1000, Ivan Rayner wrote: > On Mon, 4 Jun 2001, Steve Lord wrote: > > > > Finally, the amount of space to be used is only an estimate, I do not know > > how accurate it normally is on Irix, but a factor of 2 looks a bit large. > > The size estimate is based on the blocksize multiplied by the number of > blocks used for each file. The problem here is that there is a huge > number (500,000) of small files, and given that the estimate is off by > about 1k per file, I'd say the difference is just blocksize vs. filesize. > > > Ivan > > > > Also if you look at the above xfdump report, it says that the filesystem > > > was about 1.4G and the resultant backup was 860M. When I did the restore, > > > it was back to about the correct original 1.4G, can anyone comment on why > > > xfsdump is able to get such good compression? > > > So reiterating on what Ivan said, the "compression" is likely to be because we do not dump the empty data in the data blocks - and for a lot of small files this can add up. I presume from your above statement that you weren't actually querying the accuracy of the dump estimate - it was just the dump size was surprisingly small. FYI some notes on estimate of dump size below. --Tim -------------------------------------------------------------------- How does it compute estimated dump size ? A dump consists of media files (only 1 in the case of a dump to a file, and usually many when dumped to a tape (depending on device type)). A media file consists of: global header inode map (inode# + state(e.g.dump or not?) ) directories non-directory files A directory consists of a header, directory-entry-headers for its entries and extended-attribute header and attributes. A non-directory file consists of a file header, extent-headers (for each extent), file data and extended-attribute header and attributes. Some types of files don't have extent headers or data. The xfsdump code says: size_estimate = GLOBAL_HDR_SZ + inomap_getsz( ) + inocnt * ( u_int64_t )( FILEHDR_SZ + EXTENTHDR_SZ ) + inocnt * ( u_int64_t )( DIRENTHDR_SZ + 8 ) + datasz; So this accounts for the: global header inode map all the files all the direntory entries ( "+8" presumably to account for average file name length range, where 8 chars already included in header; as this structure is padded to the next 8 byte boundary, it accounts for names with lengths between 8-15 chars) data What estimate doesn't seem to account for (that I can think of): no extended attributes assumes that a file will only have one extent no tape block headers (for tape media) "Datasz" is calculated by adding up for every regular inode file, its (number of data blocks) * (block size). However, if "-a" is used, then instead of doing this, if the file is dualstate/offline then the file's data won't be dumped and it adds zero for it. From owner-linux-xfs@oss.sgi.com Tue Jun 5 01:56:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f558ugr27843 for linux-xfs-outgoing; Tue, 5 Jun 2001 01:56:42 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f558ueh27836 for ; Tue, 5 Jun 2001 01:56:41 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id BAA13159 for ; Tue, 5 Jun 2001 01:56:38 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA58788; Tue, 5 Jun 2001 18:55:20 +1000 (EST) Date: Tue, 5 Jun 2001 18:55:20 +1000 From: Timothy Shimmin To: Stephen VanPelt Cc: jtrostel@connex.com, linux-xfs@oss.sgi.com Subject: Re: Setting Permissions with ACLs Message-ID: <20010605185519.D237728@boing.melbourne.sgi.com> References: <3816500554.991658978@D8H1FF01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3816500554.991658978@D8H1FF01>; from vanpelts@musc.edu on Mon, Jun 04, 2001 at 12:49:38PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Stephen, Certainly if you are just using XFS files with ACLs, then the ACLs do not need the standard permissions to be set to allow access to a user. e.g. tes@sagan /mnt/xfs0/testdir> chacl -l ./test1 ./test1 [u::rw-,g::---,o::---,u:ajag:rw-,m::rwx] tes@sagan /mnt/xfs0/testdir> su ajag ajag@sagan /mnt/xfs0/testdir>cat test1 hi there ajag@sagan /mnt/xfs0/testdir>touch test1 ajag@sagan /mnt/xfs0/testdir>su nathans nathans@sagan /mnt/xfs0/testdir>cat test1 cat: test1: Permission denied nathans@sagan /mnt/xfs0/testdir> touch test1 touch: test1: Permission denied This has group and other permissions turned off and yet ajag (who is _not_ the owner) is granted access. Any other FS's permission function is not going to know how to access/use the XFS ACL - well I guess except the work going on in Samba. --Tim On Mon, Jun 04, 2001 at 12:49:38PM -0400, Stephen VanPelt wrote: > Actually, though, netatalk is using the system's permission structure, and > since the system is recognizing the ACLs, the ACLs are working with > netatalk - I just have to make sure that I've run "chmod 667" on the file, > and then using the ACLs to limit access. When I do it that way, it works > just fine - I just wanted to make sure that there wasn't something that I > was missing, or some other better way to do things. > > -Stephen > > --On Monday, June 04, 2001 12:33 PM -0400 John Trostel > wrote: > > > > > On 04-Jun-2001 Stephen VanPelt wrote: > >> see comments below > >> > > > > ... snip ... > > > >> This part looks good too - but here's where I find problems... If I > >> have a user that I've specified (user1, in this instance) with write > >> access log into the server (using netatalk - but this doesn't seem to > >> matter), they cannot open the file if the file isn't chmod'ed to give > >> "other" write access. Even though the user is given write access in > >> the ACL, they cannot exercise that access unless it is also allowed in > >> "chmod" (the file belongs to peltman:peltman - and of course the user > >> is not in either of those groups - so unless they are set to chmod 006 > >> or 007, then the ACL doesn't seem to be able to grant any access that > >> the chmod denies). > > > > Netatalk has no conception of ACLs. I'm fairly sure it just looks at the > > standard permission structure to determine access. Therefore, Netatalk > > doesn't know that there is an added user (or group) with access > > priviledges. Try with Samba (version 2.20 or ,even better, the latest > > CVS download) or with a unix user telneted in. Those should work > > > > -- > > John M. Trostel > > Linux OS Engineer > > Connex > > jtrostel@connex.com > > > > > > Stephen VanPelt > Information Technology Consultant > MUSC Center for Drug and Alcohol Programs > PH: 843-792-5558 Internet: vanpelts@musc.edu > > > __________________BEGIN FOOTER___________________ > **The Views Expressed by the Author of this Message are not ** > **necessarily those of the Medical University of South Carolina** From owner-linux-xfs@oss.sgi.com Tue Jun 5 03:21:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55ALoM08955 for linux-xfs-outgoing; Tue, 5 Jun 2001 03:21:50 -0700 Received: from akira.ep-ka.de (akira.ep-ag.com [194.120.231.250]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55ALmh08951 for ; Tue, 5 Jun 2001 03:21:49 -0700 Received: from ep-ag.com (sol10.ep-ka.de [194.120.231.11]) by akira.ep-ka.de (8.9.1/8.9.3) with ESMTP id MAA06380; Tue, 5 Jun 2001 12:21:46 +0200 Received: from ep-ag.com (stb@crusher.ep-ka.de [194.120.231.18]) by ep-ag.com (8.9.3/8.9.3) with ESMTP id MAA08760; Tue, 5 Jun 2001 12:21:45 +0200 (MET DST) Message-ID: <3B1CB2B9.4090308@ep-ag.com> Date: Tue, 05 Jun 2001 12:21:45 +0200 From: "Klaus Strebel,ITS,204" Reply-To: linux-xfs@oss.sgi.com Organization: EIGNER+PARTNER AG User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-XFS i686; en-US; rv:0.9) Gecko/20010505 X-Accept-Language: de, en MIME-Version: 1.0 To: Russell Cattelan CC: Keith Owens , linux-xfs@oss.sgi.com Subject: Re: Hanging around with 2.4.5-xfs from cvs References: <7922.991409390@ocs3.ocs-net> <3B1A64C5.AF1D7DDA@thebarn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Russell Cattelan wrote: > Keith Owens wrote: > > And of course the question to ask which version of the compiler are you > using? I've had problems with kdb and everything but 2.91.66 for the > compiler. > > Although it never failed to boot. Tried both gcc-2.95.2 and kgcc alias egsc-2.91.66. >>On Fri, 01 Jun 2001 16:35:07 +0200, >>"Klaus Strebel,ITS,204" wrote: >> >>>yesterday i updated my linux-2.4-xfs cvs-tree (after waiting anxiously >>>for oss.sgi.com to be reachable again, sigh :-) ), compliled it, >>>installed it, booted and ... by box kept hanging at the 'ifconfig lo >>>127.0.0.1 netmask 255.0.0.0 dev lo'. I unconfigured START_LOOPBACK (i'm >>>using SuSE 7. almost 1, couldn't find a way to do the SuSE-upgrade >>>procedure with a xfs-enabled kernel, only / and /boot are ext2), tried >>>it again, an by box hang at loading the next network driver :-(. >>> >>>So i downloaded linux-2.4.5-xfs-05312001.patch.bz2 from oss.sgi.com, >>>removed everything not necessary for xfs from it (kernel debugger, >>>ac-patch things, lvm upgrades - upgraded myself to 0.9.1beta7 ...) and >>>no it works! Is KDB broken ?? >>> >>Works for me :). This is top of tree as of Fri Jun 1 15:10:23 UTC >>2001, configured with xfs and kdb. >> >>Linux ocs4 2.4.5-xfs #1 SMP Sat Jun 2 01:10:01 EST 2001 i686 unknown >> >>Entering non-interactive startup >>Setting network parameters: [ OK ] >>Bringing up interface lo: [ OK ] >>Bringing up interface eth0: [ OK ] >> >>Your problem sounds like a generic network problem, not XFS. There >>have been some recent patches by Jeff Garzick for timing related >>problems with network drivers on 2.4.5. Try linux-kernel. I think its because of patches to the 2.4.5-tree applied to linux-xfs cvs tree. Vanilla kernel with only (i hope all) patches needed for xfs from linux-2.4.5-xfs-05312001.patch.bz2 works. Ciao Klaus From owner-linux-xfs@oss.sgi.com Tue Jun 5 04:07:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55B7Sp20940 for linux-xfs-outgoing; Tue, 5 Jun 2001 04:07:28 -0700 Received: from studsv07.studserv.uni-stuttgart.de (studsv07.studserv.uni-stuttgart.de [129.69.21.37]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55B7Qh20936 for ; Tue, 5 Jun 2001 04:07:26 -0700 Received: from ysabell.wh.vaih [129.69.166.244] by studsv07.studserv.uni-stuttgart.de with ESMTP (SMTPD32-6.06) id AD5F9BE02CC; Tue, 05 Jun 2001 13:07:11 +0200 Received: from marcelo by ysabell.wh.vaih with local (Exim 3.22 #1 (Debian)) id 157Eg5-0000HD-00; Tue, 05 Jun 2001 13:07:13 +0200 Date: Tue, 5 Jun 2001 13:07:13 +0200 From: "Marcelo E. Magallon" To: Bojan Smojver Cc: linux-xfs@oss.sgi.com Subject: Re: XFS in kernel tree Message-ID: <20010605130713.A1017@ysabell.wh.vaih> Mail-Followup-To: Bojan Smojver , linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B1B2C4D.B124282E@binarix.com> User-Agent: Mutt/1.3.18i X-Operating-System: Linux ysabell 2.4.4-xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> Bojan Smojver writes: > Any idea when XFS is going to become an official part of the 2.4 kernel > tree? This is becoming a FAQ. (When reading this, please note I'm not involved with XFS beyond being an early adopter, and someone who's got a few systems using XFS for some time now) You have to consider two things: a) 2.4 isn't supposed to get any major patches (and it'd be nice if that was true for once); b) there's probably still some bug fixing to do on the XFS side. I have had some trouble with XFS on one NFS server[1], but other than that, it's rock solid. Do notice this is the same lame argumentation presented by people who wanted ReiserFS on the kernel, and you know what happened with that one. That said, it's very unlikely that XFS will ever go in the 2.4 kernel, but it will probably go on the 2.5 at some time. HTH, Marcelo [1] I'm not 100% sure this was an XFS problem, but other people panicked and pulled the plug without proper investigation of the problem. The machine was doing a very small ammount of NFS serving (15-20 mounts tops scattered among 5-8 clients) out of a 150 GB external RAID (IDE) system hooked to a SCSI controller. The kernel oops'ed a couple of times, but because of a configuration error on my part, I couldn't get a decent call trace and the oops log alone was useless. Ever since the RAID was moved to another box (XFS/IRIX) I haven't been able to reproduce the problem. I suspect the problem was the SCSI controller (which is also gone), but I haven't been able to test this... From owner-linux-xfs@oss.sgi.com Tue Jun 5 04:16:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55BGl122290 for linux-xfs-outgoing; Tue, 5 Jun 2001 04:16:47 -0700 Received: from smtp.euronet.nl (smtp1.euronet.nl [194.134.35.133]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55BGkh22287 for ; Tue, 5 Jun 2001 04:16:47 -0700 Received: from lowlands.euro.net (lowlands.euronet.nl [194.134.32.225]) by smtp.euronet.nl (Postfix) with ESMTP id 4730A67247 for ; Tue, 5 Jun 2001 13:16:44 +0200 (MEST) X-NCC-RegID: nl.euronet Message-Id: <5.1.0.14.2.20010605131632.03b489e0@pop.euronet.nl> X-Sender: sengaia@pop.euronet.nl X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Jun 2001 13:18:38 +0200 To: linux-xfs@oss.sgi.com From: Arjen Wolfs Subject: Re: XFS in kernel tree In-Reply-To: <20010605130713.A1017@ysabell.wh.vaih> References: <3B1B2C4D.B124282E@binarix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 01:07 PM 6/5/01 +0200, you wrote: > >> Bojan Smojver writes: > > > Any idea when XFS is going to become an official part of the 2.4 kernel > > tree? > > This is becoming a FAQ. (When reading this, please note I'm not > involved with XFS beyond being an early adopter, and someone who's got > a few systems using XFS for some time now) > > You have to consider two things: a) 2.4 isn't supposed to get any major > patches (and it'd be nice if that was true for once); b) there's > probably still some bug fixing to do on the XFS side. I have had some > trouble with XFS on one NFS server[1], but other than that, it's rock > solid. Do notice this is the same lame argumentation presented by > people who wanted ReiserFS on the kernel, and you know what happened > with that one. That said, it's very unlikely that XFS will ever go in > the 2.4 kernel, but it will probably go on the 2.5 at some time. Linux 2.4.x with HIGHMEM support is still extremely unstable (read: completely broken), I wouldn't expect something as invasive as a new filesystem to go in until the kernel's core is stable (then again, i didn't expect 2.4.0 either until it was stable...who knows). /Arjen From owner-linux-xfs@oss.sgi.com Tue Jun 5 05:47:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55ClAP03746 for linux-xfs-outgoing; Tue, 5 Jun 2001 05:47:10 -0700 Received: from mail.network.de (owl.web2cad.de [62.225.10.125]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55Cl8h03740 for ; Tue, 5 Jun 2001 05:47:08 -0700 Received: from domino02.web2cad.de ([10.10.0.6]) by mail.network.de (8.9.3/8.9.3) with ESMTP id OAA24121 for ; Tue, 5 Jun 2001 14:47:02 +0200 Subject: help To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: robert.gehr@web2cad.de Date: Tue, 5 Jun 2001 14:47:00 +0200 X-MIMETrack: Serialize by Router on domino02/GENIUS/DE(Release 5.0.4 |June 8, 2000) at 06/05/2001 02:47:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello there I just tried to install XFS support here on a machine. I patched the kernel sources 2.4.3 without a hitch and compiled the beast, even installed the lvm stuff to work around some error make was spitting up when I tried to build xfsprogs I installed modutils 2.4.6 and all the other goodies you recommend. I can boot my system all right but never get those modules loaded I usually use e.g. network drivers etc. I always get: "unresolved symbols in /lib/modules/2.4.3-XFS/kernel/xxxx" I checked out those mailinglist archives to no avail so what is there to do. Before I was running kernel 2.4.4 on that machine and had no trouble at all with them modules and still have none when I boot that kernel only when I boot that patched XFS kernel I get those lovely messages Ever heard of something like that before?????? Thanks for helping Best regards Robert Gehr "A ship in a harbour is safe, but that's not what ships are built for" ======================================== web2CAD AG Emailfabrikstrs. 12 92224 Amberg / Germany visit: http://www.web2cad.com From owner-linux-xfs@oss.sgi.com Tue Jun 5 05:56:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55Cu4U05398 for linux-xfs-outgoing; Tue, 5 Jun 2001 05:56:04 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55Cu3h05393 for ; Tue, 5 Jun 2001 05:56:03 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f55Ctsc19207; Tue, 5 Jun 2001 14:55:54 +0200 Message-Id: <4.3.2.7.2.20010605145434.032e4a40@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Jun 2001 14:56:00 +0200 To: robert.gehr@web2cad.de, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: help In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 14:47 5-6-2001 +0200, robert.gehr@web2cad.de wrote: >Hello there > >I just tried to install XFS support here on a machine. >I patched the kernel sources 2.4.3 without a hitch and compiled the beast, >even installed the lvm stuff to work around some error make was spitting up >when I tried to build xfsprogs >I installed modutils 2.4.6 and all the other goodies you recommend. > >I can boot my system all right but never get those modules loaded I usually >use e.g. network drivers etc. >I always get: "unresolved symbols in /lib/modules/2.4.3-XFS/kernel/xxxx" > >I checked out those mailinglist archives to no avail so what is there to >do. >Before I was running kernel 2.4.4 on that machine and had no trouble at all >with them modules and still have none when I boot that kernel only when I >boot that patched XFS kernel I get those lovely messages > >Ever heard of something like that before?????? Yes save your .config file in tree you are working in. make mrproper copy your .config back make oldconfig And try again. You have been bitten by broken Makfiles. This is a general 2.4 problem. Bye -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Jun 5 06:33:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55DXEZ11314 for linux-xfs-outgoing; Tue, 5 Jun 2001 06:33:14 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55DXCh11311 for ; Tue, 5 Jun 2001 06:33:13 -0700 Received: (qmail 27218 invoked from network); 5 Jun 2001 13:33:08 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 5 Jun 2001 13:33:08 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: robert.gehr@web2cad.de cc: linux-xfs@oss.sgi.com Subject: Re: help In-reply-to: Your message of "Tue, 05 Jun 2001 14:47:00 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Jun 2001 23:33:07 +1000 Message-ID: <17103.991747987@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 5 Jun 2001 14:47:00 +0200, robert.gehr@web2cad.de wrote: >I just tried to install XFS support here on a machine. >I patched the kernel sources 2.4.3 without a hitch and compiled the beast, >I always get: "unresolved symbols in /lib/modules/2.4.3-XFS/kernel/xxxx" FAQ: http://www.tux.org/lkml/#s8-8 From owner-linux-xfs@oss.sgi.com Tue Jun 5 06:50:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55Dorf15106 for linux-xfs-outgoing; Tue, 5 Jun 2001 06:50:53 -0700 Received: from zofo.niehs.nih.gov (zofo.niehs.nih.gov [157.98.8.245]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55Doqh15103 for ; Tue, 5 Jun 2001 06:50:52 -0700 Received: from niehs.nih.gov (IDENT:krahn@xenon.niehs.nih.gov [157.98.12.34]) by zofo.niehs.nih.gov (SGI-8.9.3/8.9.3) with ESMTP id JAA49521; Tue, 5 Jun 2001 09:51:06 -0400 (EDT) Message-ID: <3B1CE383.DCFED687@niehs.nih.gov> Date: Tue, 05 Jun 2001 09:49:55 -0400 From: Joe Krahn X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Timothy Shimmin CC: Bas , linux-xfs@oss.sgi.com Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. References: <01060413285600.09944@garfield.linux.localdomain> <011501c0ed31$58a54360$0f01a8c0@ws1> <20010605102551.Z97441@boing.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Timothy Shimmin wrote: > > On Mon, Jun 04, 2001 at 10:02:56PM +0200, Bas wrote: > > > > From: "J Hayward" > > Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. > > > > > > [ ] Build Adapter Firmware with Kernel Build (NEW) > > > > > > > > It is the last option under Adaptec AIC7xxx support. The firmware > > > > included in the 2.4.5 release is out of sync with the kernel driver. > > > > > > > > I have not done this myself, since my current XFS machine does not have > > a > > > > SCSI controller, but see the below email for more info. > > > > > > Has anyone had any success using this option? Didn't work for me. Problem > > > isn't isolated to just the 7890 it seems, I get the same error on a > > Adaptec > > > 2930CU. It still produced: > > > > > > >In interrupt handler - not syncing > > > > > > I also tried using the old aic7xxx driver, which did load the module. > > However > > > it produced a kernel oops immediately after. I don't remember the exact > > point > > > in the boot sequence, I believe it was at "Trying to unmount old root". > > > > Tried the firmware option too, but didn't work for me. > > > > Tried the firmware option too, and it did work for me. > > scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.13 > > aic7880: Ultra Wide Channel A, SCSI Id=7, 16/255 SCBs > > --Tim The problem is that linux-2.4.5-xfs-05312001.patch.bz2 includes the files aic7xxx_seq.h and aic7xxx_reg.h which are out of date, but which get a newer timestamp. Also the binary aicasm/aicasm is included in the patch, but patch creates it non-executable. Try touching aic7xxx.seq and removing aicasm/aicasm, then rebuilding the aic7xxx module with the build-firmware option. This is actually a problem with "make clean" and "make mrproper" not knowing about some of the aic7xxx files. Joe Krahn From owner-linux-xfs@oss.sgi.com Tue Jun 5 07:01:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55E1gH17006 for linux-xfs-outgoing; Tue, 5 Jun 2001 07:01:42 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55E1fh17002 for ; Tue, 5 Jun 2001 07:01:42 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA05331 for ; Tue, 5 Jun 2001 07:01:53 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2062687; Tue, 5 Jun 2001 09:00:04 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA78111; Tue, 5 Jun 2001 09:00:04 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f55E3WH01345; Tue, 5 Jun 2001 09:03:32 -0500 Message-Id: <200106051403.f55E3WH01345@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Marcelo E. Magallon" cc: Bojan Smojver , linux-xfs@oss.sgi.com Subject: Re: XFS in kernel tree In-Reply-To: Message from "Marcelo E. Magallon" of "Tue, 05 Jun 2001 13:07:13 +0200." <20010605130713.A1017@ysabell.wh.vaih> Date: Tue, 05 Jun 2001 09:03:32 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > >> Bojan Smojver writes: > > > Any idea when XFS is going to become an official part of the 2.4 kernel > > tree? > > This is becoming a FAQ. (When reading this, please note I'm not > involved with XFS beyond being an early adopter, and someone who's got > a few systems using XFS for some time now) > > You have to consider two things: a) 2.4 isn't supposed to get any major > patches (and it'd be nice if that was true for once); b) there's > probably still some bug fixing to do on the XFS side. I have had some > trouble with XFS on one NFS server[1], but other than that, it's rock > solid. Do notice this is the same lame argumentation presented by > people who wanted ReiserFS on the kernel, and you know what happened > with that one. That said, it's very unlikely that XFS will ever go in > the 2.4 kernel, but it will probably go on the 2.5 at some time. We will see about that, XFS itself sits on the side, it is the core kernel changes which have impact elsewhere, and these are a lot smaller than some of the gyrations 2.4 has gone through so far. Most of Alan's patches are probably bigger than the whole of XFS. Steve > > HTH, > > Marcelo > > [1] I'm not 100% sure this was an XFS problem, but other people > panicked and pulled the plug without proper investigation of the > problem. The machine was doing a very small ammount of NFS serving > (15-20 mounts tops scattered among 5-8 clients) out of a 150 GB > external RAID (IDE) system hooked to a SCSI controller. The kernel > oops'ed a couple of times, but because of a configuration error on > my part, I couldn't get a decent call trace and the oops log alone > was useless. Ever since the RAID was moved to another box > (XFS/IRIX) I haven't been able to reproduce the problem. I suspect > the problem was the SCSI controller (which is also gone), but I > haven't been able to test this... From owner-linux-xfs@oss.sgi.com Tue Jun 5 07:56:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55Euki25914 for linux-xfs-outgoing; Tue, 5 Jun 2001 07:56:46 -0700 Received: from revere3.musc.edu (revere3.musc.edu [128.23.203.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55Eujh25908 for ; Tue, 5 Jun 2001 07:56:45 -0700 Received: from D8H1FF01 ([128.23.211.115]) by revere3.musc.edu (8.8.8/8.8.8) with ESMTP id KAA04846 for ; Tue, 5 Jun 2001 10:56:44 -0400 (EDT) Date: Tue, 05 Jun 2001 10:58:21 -0400 From: Stephen VanPelt To: linux-xfs@oss.sgi.com Subject: Backing up Message-ID: <3896223470.991738701@D8H1FF01> Originator-Info: login-id=vanpelts; server=imap.musc.edu X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is anyone using Arkeia to back up their XFS system? I'm running RedHat 7.1 with XFS, and was wondering if Arkeia would back up the ACLs with the files. -Stephen Stephen VanPelt Information Technology Consultant MUSC Center for Drug and Alcohol Programs PH: 843-792-5558 Internet: vanpelts@musc.edu __________________BEGIN FOOTER___________________ **The Views Expressed by the Author of this Message are not ** **necessarily those of the Medical University of South Carolina** From owner-linux-xfs@oss.sgi.com Tue Jun 5 08:10:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55FAhG28337 for linux-xfs-outgoing; Tue, 5 Jun 2001 08:10:43 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55FAfh28333 for ; Tue, 5 Jun 2001 08:10:41 -0700 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA09151 for ; Tue, 5 Jun 2001 08:10:40 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2042166; Tue, 5 Jun 2001 10:09:23 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA94552; Tue, 5 Jun 2001 10:09:22 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f55FCoA32591; Tue, 5 Jun 2001 10:12:50 -0500 Message-Id: <200106051512.f55FCoA32591@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Stephen VanPelt cc: linux-xfs@oss.sgi.com Subject: Re: Backing up In-Reply-To: Message from Stephen VanPelt of "Tue, 05 Jun 2001 10:58:21 EDT." <3896223470.991738701@D8H1FF01> Date: Tue, 05 Jun 2001 10:12:50 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Is anyone using Arkeia to back up their XFS system? > > I'm running RedHat 7.1 with XFS, and was wondering if Arkeia would back up > the ACLs with the files. > > -Stephen > > I doubt it, since we introduced new interfaces for access to these features of the filesystem, xfsdump is about the only tool capable of dumping them and xfsrestore is the only thing capable of restoring them. Amanda can drive xfsdump, but unless Arkeia does similar things by wrapping around filesystem specific dump programs I don't think it will help you. Steve > > > Stephen VanPelt > Information Technology Consultant > MUSC Center for Drug and Alcohol Programs > PH: 843-792-5558 Internet: vanpelts@musc.edu > > > __________________BEGIN FOOTER___________________ > **The Views Expressed by the Author of this Message are not ** > **necessarily those of the Medical University of South Carolina** From owner-linux-xfs@oss.sgi.com Tue Jun 5 08:29:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55FTdU31417 for linux-xfs-outgoing; Tue, 5 Jun 2001 08:29:39 -0700 Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55FTbh31413 for ; Tue, 5 Jun 2001 08:29:37 -0700 Received: (qmail 20411 invoked by uid 0); 5 Jun 2001 15:29:30 -0000 Received: from f-16-212.cvx-leipzig.ipdial.viaginterkom.de (HELO temple) (62.180.212.16) by mail.gmx.net (mp002-rz3) with SMTP; 5 Jun 2001 15:29:30 -0000 Message-ID: <00d201c0edd4$daf23550$01000001@temple> Reply-To: "Andreas Piesk" From: "Andreas Piesk" To: "Stephen VanPelt" , References: <3896223470.991738701@D8H1FF01> Subject: Re: Backing up Date: Tue, 5 Jun 2001 17:21:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Is anyone using Arkeia to back up their XFS system? > > I'm running RedHat 7.1 with XFS, and was wondering if Arkeia would back up > the ACLs with the files. > not yet, i was told by the arkeia support, that the next version will recognize xfs as a normal filesystem. the ACLs will not be backed up by arkeia for now, but this is work in progress. ciao -ap -- Andreas Piesk a.piesk@gmx.net PGP-Fingerprint: 23CB A7E2 2E53 373C DBCD 8EFC 7777 61C1 From owner-linux-xfs@oss.sgi.com Tue Jun 5 09:05:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55G5fn04660 for linux-xfs-outgoing; Tue, 5 Jun 2001 09:05:41 -0700 Received: from hitchcock.eng.uiowa.edu (hitchcock.eng.uiowa.edu [128.255.22.64]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55G5dh04657 for ; Tue, 5 Jun 2001 09:05:40 -0700 Received: from eng.uiowa.edu (eyeball.eng.uiowa.edu [128.255.22.246]) by hitchcock.eng.uiowa.edu (8.9.3/8.9.3) with ESMTP id LAA03249 for sent by ; Tue, 5 Jun 2001 11:05:36 -0500 (CDT) Message-ID: <3B1D0316.30737C2D@eng.uiowa.edu> Date: Tue, 05 Jun 2001 11:04:38 -0500 From: pedretti@eng.uiowa.edu X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: permission problems.. References: <200106041521.f54FLTW29906@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We are seeing the same problem here. I believe it is caused by mixed nfs and local access to files but haven't been able to isolate anything reproducible. Is there anything I can fall back to that doesn't have this problem? -- but keeps the improved nfs under load characteristics of the current cvs. Thanks, Kevin Steve Lord wrote: > Is this happening via NFS access, or local access? If I cannot find a quick > fix I can back out the change which is probably at the back of this. > > Steve > > > It changes permissions which seems to be at random. It doesnt just change > > a single file but will change permissions in the whole directory. So it > > doesnt change random files just random directories and inside those random > > directories. All I can say is that my users randomly see permissions > > change and sometimes several times a day. > > > > ***************************** > > Walter Marchuk > > Senior Computer Specialist > > University of Washington > > Electrical Engineering > > Room: 307g > > 206-221-5421 > > marchuk@ee.washington.edu > > ***************************** > > > > On Mon, 4 Jun 2001, Steve Lord wrote: > > > > > > marchuk@ee.washington.edu wrote: > > > > > > > > > > I am using the latest CVS tree, one from Friday, and I noticed a strang > > e > > > > > problem. Every once in a while permissions get reset for some > > > > > directories, I mean all permissions are removed. Has anyone noticed th > > is > > > > > problem and is this XFS related? > > > > > > > > > > > > > I have the same problem here using the cvs tree from today (monday) ! > > > > After installation and reboot some files and directories are chmod'ed to > > > > 000 ! > > > > > > > > Felix > > > > > > Hmm, there was an 'optimization' a couple of weeks back which could explain > > > this. Do you have any pointers to what coincides with this, and what the > > > first operation is that causes you to discover missing permissions? > > > > > > Steve > > > > > > From owner-linux-xfs@oss.sgi.com Tue Jun 5 09:14:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55GEKB05159 for linux-xfs-outgoing; Tue, 5 Jun 2001 09:14:20 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55GEJh05156 for ; Tue, 5 Jun 2001 09:14:19 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA09745 for ; Tue, 5 Jun 2001 09:14:32 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA2066913; Tue, 5 Jun 2001 11:12:58 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA23735; Tue, 5 Jun 2001 11:12:58 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f55GGP305555; Tue, 5 Jun 2001 11:16:25 -0500 Message-Id: <200106051616.f55GGP305555@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: pedretti@eng.uiowa.edu cc: linux-xfs@oss.sgi.com Subject: Re: permission problems.. In-Reply-To: Message from pedretti@eng.uiowa.edu of "Tue, 05 Jun 2001 11:04:38 CDT." <3B1D0316.30737C2D@eng.uiowa.edu> Date: Tue, 05 Jun 2001 11:16:25 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk OK, I was incorrect yesterday in saying that the patch I sent out did not fix it, I managed to install the kernel under the wrong name and I was not testing the patch. Can someone please try this patch and report back if it makes a difference or not. When I realized this and tried the patch, I could not reproduce the problem with or without it. The patch is archived here: http://oss.sgi.com/projects/xfs/mail_archive/0106/msg00050.html Thanks, Steve > We are seeing the same problem here. I believe it is caused by mixed nfs and > local access to files but haven't been able to isolate anything reproducible. > Is > there anything I can fall back to that doesn't have this problem? -- but kee > ps > the improved nfs under load characteristics of the current cvs. > > Thanks, > Kevin > > Steve Lord wrote: > > > Is this happening via NFS access, or local access? If I cannot find a quick > > fix I can back out the change which is probably at the back of this. > > > > Steve > > > > > It changes permissions which seems to be at random. It doesnt just chang > e > > > a single file but will change permissions in the whole directory. So it > > > doesnt change random files just random directories and inside those rando > m > > > directories. All I can say is that my users randomly see permissions > > > change and sometimes several times a day. > > > > > > ***************************** > > > Walter Marchuk > > > Senior Computer Specialist > > > University of Washington > > > Electrical Engineering > > > Room: 307g > > > 206-221-5421 > > > marchuk@ee.washington.edu > > > ***************************** > > > > > > On Mon, 4 Jun 2001, Steve Lord wrote: > > > > > > > > marchuk@ee.washington.edu wrote: > > > > > > > > > > > > I am using the latest CVS tree, one from Friday, and I noticed a st > rang > > > e > > > > > > problem. Every once in a while permissions get reset for some > > > > > > directories, I mean all permissions are removed. Has anyone notice > d th > > > is > > > > > > problem and is this XFS related? > > > > > > > > > > > > > > > > I have the same problem here using the cvs tree from today (monday) ! > > > > > After installation and reboot some files and directories are chmod'ed > to > > > > > 000 ! > > > > > > > > > > Felix > > > > > > > > Hmm, there was an 'optimization' a couple of weeks back which could exp > lain > > > > this. Do you have any pointers to what coincides with this, and what th > e > > > > first operation is that causes you to discover missing permissions? > > > > > > > > Steve > > > > > > > > From owner-linux-xfs@oss.sgi.com Tue Jun 5 10:00:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55H0Tb06561 for linux-xfs-outgoing; Tue, 5 Jun 2001 10:00:29 -0700 Received: from main.braxis.co.uk (root@main.braxis.co.uk [213.77.40.29]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55H0Qh06558 for ; Tue, 5 Jun 2001 10:00:27 -0700 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.9.3/8.9.3) id UAA02240 for linux-xfs@oss.sgi.com; Tue, 5 Jun 2001 20:03:47 +0200 Date: Tue, 5 Jun 2001 20:03:47 +0200 From: Krzysztof Rusocki To: linux-xfs@oss.sgi.com Subject: 2.4.5-xfs (CVS 2001-06-01) Ooops & crash Message-ID: <20010605200347.A1890@main.braxis.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Yesterday's evening i issued oopses and crash.... Machine is Celeron 366(Mendocino) / 128MB RAM / PIIX4E & PDC20262 & HPT366 / Davicom Dm9102 ethernet System is generic RH6.2 with vital upgrades needed for 2.4 series... These oops were noticed about 17:00 CEST next day... (2001-06-05)... I tried to Sync by Alt+SysRQ but i got just more oopses (actually didn't get them - no serial console at the moment ;( ) then i did Alt+SysRQ+U - after reboot i noticed that all xfs partitions were clearly unmounted but ext2 - ones were NOT. Actually the output i got is what syslogd managed to write on the disk but i hope that files i provide will be sufficient... http://braxis.co.uk/~kszysiu/xfs/ Can it be connected with VM problems in 2.4 series - not related to xfs? Cheers, Krzysztof From owner-linux-xfs@oss.sgi.com Tue Jun 5 10:10:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55HA6007072 for linux-xfs-outgoing; Tue, 5 Jun 2001 10:10:06 -0700 Received: from epithumia.math.uh.edu (IDENT:root@epithumia.math.uh.edu [129.7.128.2]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55HA5h07069 for ; Tue, 5 Jun 2001 10:10:05 -0700 Received: (from tibbs@localhost) by epithumia.math.uh.edu (8.11.0/8.11.1) id f55HA4c09396; Tue, 5 Jun 2001 12:10:04 -0500 To: linux-xfs@oss.sgi.com Subject: Re: XFS in kernel tree References: <3B1B2C4D.B124282E@binarix.com> <5.1.0.14.2.20010605131632.03b489e0@pop.euronet.nl> From: Jason L Tibbitts III Date: 05 Jun 2001 12:10:04 -0500 In-Reply-To: Arjen Wolfs's message of "Tue, 05 Jun 2001 13:18:38 +0200" Message-ID: Lines: 15 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "AW" == Arjen Wolfs writes: AW> I wouldn't expect something as invasive as a new filesystem to go in AW> until the kernel's core is stable (then again, i didn't expect 2.4.0 AW> either until it was stable...who knows). I believe a new filesystem went in in 2.4.5. See fs/freevxfs. The salient point is that adding this FS didn't require changes anywhere else in the kernel; it just added some files. If XFS did the same, or if the non-localized parts could be fed in slowly until all of the infrastructure is in place, then it would probably be accepted without issue. - J< From owner-linux-xfs@oss.sgi.com Tue Jun 5 10:22:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55HMcn07742 for linux-xfs-outgoing; Tue, 5 Jun 2001 10:22:38 -0700 Received: from roujin.gargoylecc.com (roujin.gargoylecc.com [65.100.85.34]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55HMbh07739 for ; Tue, 5 Jun 2001 10:22:37 -0700 Received: from roujin.gargoylecc.com ([65.100.85.34] ident=ringram) by roujin.gargoylecc.com with esmtp (Exim 3.13 #1) id 157YFJ-0001OO-00 for linux-xfs@oss.sgi.com; Wed, 06 Jun 2001 02:00:53 -0600 Date: Wed, 6 Jun 2001 02:00:52 -0600 (MDT) From: Russel Ingram To: Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. In-Reply-To: <3B1CE383.DCFED687@niehs.nih.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 5 Jun 2001, Joe Krahn wrote: > The problem is that linux-2.4.5-xfs-05312001.patch.bz2 > includes the files aic7xxx_seq.h and aic7xxx_reg.h which > are out of date, but which get a newer timestamp. Also > the binary aicasm/aicasm is included in the patch, but > patch creates it non-executable. Try touching aic7xxx.seq > and removing aicasm/aicasm, then rebuilding the > aic7xxx module with the build-firmware option. > > This is actually a problem with "make clean" and > "make mrproper" not knowing about some of the aic7xxx > files. I'm seeing a problem with some of this same driver code on an older RH6.2 based system. I'm trying to compile the latest cvs tree and can't seem to get past this: make[5]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/scsi/aic7xxx/aicasm' gcc -I/usr/include -I. -ldb aicasm_gram.c aicasm_scan.c aicasm.c aicasm_symbol.c -o aicasm /tmp/ccJ1BOkT.o: In function `symtable_open': /tmp/ccJ1BOkT.o(.text+0x1b5): undefined reference to `__db185_open' collect2: ld returned 1 exit status make[5]: *** [aicasm] Error 1 I thought originally that it might be a problem with the compiler version I have, but gcc on this system is still the original gcc that installed with Red Hat 6.2 -- "gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)". Any ideas? Thanx, Russ -- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Tue Jun 5 10:31:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55HVki08155 for linux-xfs-outgoing; Tue, 5 Jun 2001 10:31:46 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55HVih08152 for ; Tue, 5 Jun 2001 10:31:44 -0700 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA02411 for ; Tue, 5 Jun 2001 10:31:35 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2032423; Tue, 5 Jun 2001 12:29:21 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA39368; Tue, 5 Jun 2001 12:29:21 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f55HWmE05695; Tue, 5 Jun 2001 12:32:48 -0500 Message-Id: <200106051732.f55HWmE05695@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jason L Tibbitts III cc: linux-xfs@oss.sgi.com Subject: Re: XFS in kernel tree In-Reply-To: Message from Jason L Tibbitts III of "05 Jun 2001 12:10:04 CDT." Date: Tue, 05 Jun 2001 12:32:48 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > >>>>> "AW" == Arjen Wolfs writes: > > AW> I wouldn't expect something as invasive as a new filesystem to go in > AW> until the kernel's core is stable (then again, i didn't expect 2.4.0 > AW> either until it was stable...who knows). > > I believe a new filesystem went in in 2.4.5. See fs/freevxfs. > > The salient point is that adding this FS didn't require changes anywhere > else in the kernel; it just added some files. If XFS did the same, or if > the non-localized parts could be fed in slowly until all of the > infrastructure is in place, then it would probably be accepted without > issue. > This is in fact happening to a certain extent, 2.4.6-pre1 removes the need for one particular change we had in the core kernel for example. Steve > - J< From owner-linux-xfs@oss.sgi.com Tue Jun 5 10:33:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55HXfk08466 for linux-xfs-outgoing; Tue, 5 Jun 2001 10:33:41 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55HXeh08462 for ; Tue, 5 Jun 2001 10:33:40 -0700 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA03946 for ; Tue, 5 Jun 2001 10:33:39 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2068911; Tue, 5 Jun 2001 12:32:22 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA10940; Tue, 5 Jun 2001 12:32:22 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f55HZmb05812; Tue, 5 Jun 2001 12:35:48 -0500 Message-Id: <200106051735.f55HZmb05812@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Russel Ingram cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. In-Reply-To: Message from Russel Ingram of "Wed, 06 Jun 2001 02:00:52 MDT." Date: Tue, 05 Jun 2001 12:35:48 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You need to go to the aic configuration options, tell it you want to build the adapter firmware - it looks like you may have done this. Then you need to install the development package for the db database, it wants to use this for the firmware generator program. Steve > On Tue, 5 Jun 2001, Joe Krahn wrote: > > > The problem is that linux-2.4.5-xfs-05312001.patch.bz2 > > includes the files aic7xxx_seq.h and aic7xxx_reg.h which > > are out of date, but which get a newer timestamp. Also > > the binary aicasm/aicasm is included in the patch, but > > patch creates it non-executable. Try touching aic7xxx.seq > > and removing aicasm/aicasm, then rebuilding the > > aic7xxx module with the build-firmware option. > > > > This is actually a problem with "make clean" and > > "make mrproper" not knowing about some of the aic7xxx > > files. > > I'm seeing a problem with some of this same driver code on an older RH6.2 > based system. I'm trying to compile the latest cvs tree and can't seem to > get past this: > > make[5]: Entering directory > `/usr/src/linux-2.4-xfs/linux/drivers/scsi/aic7xxx/aicasm' > gcc -I/usr/include -I. -ldb aicasm_gram.c aicasm_scan.c aicasm.c > aicasm_symbol.c -o aicasm > /tmp/ccJ1BOkT.o: In function `symtable_open': > /tmp/ccJ1BOkT.o(.text+0x1b5): undefined reference to `__db185_open' > collect2: ld returned 1 exit status > make[5]: *** [aicasm] Error 1 > > I thought originally that it might be a problem with the compiler version > I have, but gcc on this system is still the original gcc that installed > with Red Hat 6.2 -- "gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 > release)". Any ideas? > > Thanx, > Russ > > -- > Russ Ingram > Gargoyle Computer Consulting > (307)742-1361 > www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Tue Jun 5 10:35:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55HZeN08805 for linux-xfs-outgoing; Tue, 5 Jun 2001 10:35:40 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55HZch08801 for ; Tue, 5 Jun 2001 10:35:39 -0700 Received: (qmail 29247 invoked from network); 5 Jun 2001 17:35:36 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 5 Jun 2001 17:35:36 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Russel Ingram cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. In-reply-to: Your message of "Wed, 06 Jun 2001 02:00:52 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Jun 2001 03:35:36 +1000 Message-ID: <20007.991762536@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 6 Jun 2001 02:00:52 -0600 (MDT), Russel Ingram wrote: >make[5]: Entering directory >`/usr/src/linux-2.4-xfs/linux/drivers/scsi/aic7xxx/aicasm' >gcc -I/usr/include -I. -ldb aicasm_gram.c aicasm_scan.c aicasm.c >aicasm_symbol.c -o aicasm >/tmp/ccJ1BOkT.o: In function `symtable_open': >/tmp/ccJ1BOkT.o(.text+0x1b5): undefined reference to `__db185_open' >collect2: ld returned 1 exit status >make[5]: *** [aicasm] Error 1 > >I thought originally that it might be a problem with the compiler version >I have, but gcc on this system is still the original gcc that installed >with Red Hat 6.2 -- "gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 >release)". Any ideas? (1) Shoot the aic7xxx maintainer. (2) Hack drivers/scsi/aic7xxx/aicasm to set the correct version of libdb installed on your system. The script got it wrong. (3) Shoot the aic7xxx maintainer. (4) This is a general kernel problem, everybody is hitting it. Followups to linux-kernel and the aic7xxx maintainer please, not XFS. (5) Shoot the aic7xxx maintainer (do you detect a pattern here?). From owner-linux-xfs@oss.sgi.com Tue Jun 5 11:13:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55ID2C13006 for linux-xfs-outgoing; Tue, 5 Jun 2001 11:13:02 -0700 Received: from itcampus.de (www.itcampus.de [194.45.97.156]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55ID1h12999 for ; Tue, 5 Jun 2001 11:13:01 -0700 Received: from [62.208.91.238] (HELO itcampus.de) by itcampus.de (CommuniGate Pro SMTP 3.3.1) with ESMTP id 98188 for linux-xfs@oss.sgi.com; Tue, 05 Jun 2001 20:15:32 +0200 Message-ID: <3B1D19A8.5CF2A415@itcampus.de> Date: Tue, 05 Jun 2001 19:40:56 +0200 From: Thomas Winkler X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.2.16 i686) X-Accept-Language: ex-MX MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: acls with samba on xfs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk i know that there have been some questions concerning samba and xfs, but until now i just can't get it to work the way i want it to. since i am a member of the tng and head mailing lists i asked there first, but didn't get a helpful reply on solving this one. we are running a linux server using a recent samba tng checkout as pdc and a recent samba head checkout as fileserver. the head is a member server of the domain and uses of course the pdc as password server. the pdc and fileserver are running on the same machine. the used filesystem is xfs (version 1.0). xfs works really fine and acls work. just the combination of samba and xfs is not working. what we want is changing the share/directory/file permissions of the fileserver via acl support from the client. we tried with different combinations (xfs-1.0 / xfs-2.4.4 / head / 2.2.0 / tng ). some combinations even crashed our entire system. using 2.2.0 kind of works but only with local groups no domain users/groups. with the head we get all wanted users and groups but the chosen acls are not mapped on the system files (setting acls fails). i'd like to know if this is possible at all and what combination xfs/samba others are using and is known to work. could it become a problem that the fileserver is a member of the domain and should use domain users instead of local users? is someone actually running a samba/xfs system and is able to change acls from client? thank you and i hope i am not too off topic thomas winkler -------------------------------------- itCampus Software- und Systemhaus GmbH Leipzig - Halle - Wittenberg http://www.itcampus.de From owner-linux-xfs@oss.sgi.com Tue Jun 5 11:18:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55IILf13705 for linux-xfs-outgoing; Tue, 5 Jun 2001 11:18:21 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55IIKh13702 for ; Tue, 5 Jun 2001 11:18:20 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f55IIHaJ013813; Tue, 5 Jun 2001 13:18:18 -0500 (CDT) Message-ID: <3B1D2264.975D5DF4@thebarn.com> Date: Tue, 05 Jun 2001 13:18:12 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: Russel Ingram , linux-xfs@oss.sgi.com Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. References: <20007.991762536@ocs3.ocs-net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > On Wed, 6 Jun 2001 02:00:52 -0600 (MDT), > Russel Ingram wrote: > >make[5]: Entering directory > >`/usr/src/linux-2.4-xfs/linux/drivers/scsi/aic7xxx/aicasm' > >gcc -I/usr/include -I. -ldb aicasm_gram.c aicasm_scan.c aicasm.c > >aicasm_symbol.c -o aicasm > >/tmp/ccJ1BOkT.o: In function `symtable_open': > >/tmp/ccJ1BOkT.o(.text+0x1b5): undefined reference to `__db185_open' > >collect2: ld returned 1 exit status > >make[5]: *** [aicasm] Error 1 > > > >I thought originally that it might be a problem with the compiler version > >I have, but gcc on this system is still the original gcc that installed > >with Red Hat 6.2 -- "gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 > >release)". Any ideas? > > (1) Shoot the aic7xxx maintainer. > (2) Hack drivers/scsi/aic7xxx/aicasm to set the correct version of > libdb installed on your system. The script got it wrong. > (3) Shoot the aic7xxx maintainer. > (4) This is a general kernel problem, everybody is hitting it. > Followups to linux-kernel and the aic7xxx maintainer please, not > XFS. > (5) Shoot the aic7xxx maintainer (do you detect a pattern here?). In some defense of Justin here: He has done some amazing work with SCSI and the cam layer of FreeBSD. The linux community should be quite thankful he is on board. -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Tue Jun 5 11:29:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55ITCU14776 for linux-xfs-outgoing; Tue, 5 Jun 2001 11:29:12 -0700 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55ITBh14771 for ; Tue, 5 Jun 2001 11:29:11 -0700 Received: from localhost (austin@localhost) by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f55IQPc13529 for ; Tue, 5 Jun 2001 13:26:25 -0500 X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs Date: Tue, 5 Jun 2001 13:26:25 -0500 (CDT) From: Austin Gonyou To: Subject: USB and XFS source tree. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I don't have anything in my /proc/bus/usb. Anyone know why? Is it cause I need hotplug or something. Any info on this would be a great help!!! -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com From owner-linux-xfs@oss.sgi.com Tue Jun 5 11:30:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55IUq015143 for linux-xfs-outgoing; Tue, 5 Jun 2001 11:30:52 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55IUnh15134 for ; Tue, 5 Jun 2001 11:30:50 -0700 Received: (qmail 29657 invoked from network); 5 Jun 2001 18:30:18 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 5 Jun 2001 18:30:18 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Russell Cattelan cc: Russel Ingram , linux-xfs@oss.sgi.com Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. In-reply-to: Your message of "Tue, 05 Jun 2001 13:18:12 EST." <3B1D2264.975D5DF4@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Jun 2001 04:30:17 +1000 Message-ID: <21043.991765817@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 05 Jun 2001 13:18:12 -0500, Russell Cattelan wrote: >In some defense of Justin here: >He has done some amazing work with SCSI and the cam layer of FreeBSD. >The linux community should be quite thankful he is on board. Unfortunately he does not understand how the linux kernel is built. What is worse is that he ignores suggestions from people who do understand how kbuild works, instead he does his own thing. The SCSI code for aic7xxx may be great but if when stuffs up kbuild then it is a pain in the neck. From owner-linux-xfs@oss.sgi.com Tue Jun 5 12:40:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55JesI21688 for linux-xfs-outgoing; Tue, 5 Jun 2001 12:40:54 -0700 Received: from dorian.fokus.gmd.de (dorian.fokus.gmd.de [193.175.135.179]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55Jeph21685 for ; Tue, 5 Jun 2001 12:40:52 -0700 Received: from fokus.gmd.de (localhost [127.0.0.1]) by dorian.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id 157Mgz-0000er-00; Tue, 05 Jun 2001 21:40:41 +0200 Message-ID: <3B1D35B9.505CB33@fokus.gmd.de> Date: Tue, 05 Jun 2001 21:40:41 +0200 From: Andrei Pelinescu - Onciul X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-pre8-dorian i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: permission problems.. References: <200106051616.f55GGP305555@jen.americas.sgi.com> Content-Type: multipart/mixed; boundary="------------6FB88F8DEC4A1CDE2E8CB503" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------6FB88F8DEC4A1CDE2E8CB503 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve Lord wrote: > > OK, I was incorrect yesterday in saying that the patch I sent out did not > fix it, I managed to install the kernel under the wrong name and I was not > testing the patch. Can someone please try this patch and report back if > it makes a difference or not. When I realized this and tried the patch, > I could not reproduce the problem with or without it. > > The patch is archived here: > > http://oss.sgi.com/projects/xfs/mail_archive/0106/msg00050.html With the patch and 30 May xfs cvs I get an oops in nfsd (bonnie++ over nfs mounted xfs). Without the patch, if I have a directory with the sticky bit set it will clear all the permissions on it: 1. export/sticky_dir/ mounted in /mnt/test; PWD=/mnt/test/sticky_dir, bonnie++ -s 2048 => persmissions on sticky are cleared. 2. same as above, but PWD =/mnt/test/sticky_dir/subdir, (subdir is not sticky) => persmissions on the files in subdir are reset. If I try only file creations tests everything seems ok (bonnie++ -s0 -n 200). Also, if sticky_dir is not sticky it seems to work ok (after 1 day of bonnie). Andrei --------------6FB88F8DEC4A1CDE2E8CB503 Content-Type: application/octet-stream; name="xfs_nfs_patch-oops.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="xfs_nfs_patch-oops.txt" a3N5bW9vcHMgMi40LjEgb24gaTY4NiAyLjQuNS14ZnMtbmZzLiAgT3B0aW9ucyB1c2VkCiAg ICAgLVYgKGRlZmF1bHQpCiAgICAgLWsgL3Byb2Mva3N5bXMgKGRlZmF1bHQpCiAgICAgLWwg L3Byb2MvbW9kdWxlcyAoZGVmYXVsdCkKICAgICAtbyAvbGliL21vZHVsZXMvMi40LjUteGZz LW5mcy8gKGRlZmF1bHQpCiAgICAgLW0gL2Jvb3QvU3lzdGVtLm1hcC0yLjQuNS14ZnMtbmZz IChkZWZhdWx0KQoKV2FybmluZzogWW91IGRpZCBub3QgdGVsbCBtZSB3aGVyZSB0byBmaW5k IHN5bWJvbCBpbmZvcm1hdGlvbi4gIEkgd2lsbAphc3N1bWUgdGhhdCB0aGUgbG9nIG1hdGNo ZXMgdGhlIGtlcm5lbCBhbmQgbW9kdWxlcyB0aGF0IGFyZSBydW5uaW5nCnJpZ2h0IG5vdyBh bmQgSSdsbCB1c2UgdGhlIGRlZmF1bHQgb3B0aW9ucyBhYm92ZSBmb3Igc3ltYm9sIHJlc29s dXRpb24uCklmIHRoZSBjdXJyZW50IGtlcm5lbCBhbmQvb3IgbW9kdWxlcyBkbyBub3QgbWF0 Y2ggdGhlIGxvZywgeW91IGNhbiBnZXQKbW9yZSBhY2N1cmF0ZSBvdXRwdXQgYnkgdGVsbGlu ZyBtZSB0aGUga2VybmVsIHZlcnNpb24gYW5kIHdoZXJlIHRvIGZpbmQKbWFwLCBtb2R1bGVz LCBrc3ltcyBldGMuICBrc3ltb29wcyAtaCBleHBsYWlucyB0aGUgb3B0aW9ucy4KCk5NSSBX YXRjaGRvZyBkZXRlY3RlZCBMT0NLVVAgb24gQ1BVMCwgcmVnaXN0ZXJzOgpDUFU6ICAgIDAK RUlQOiAgICAwMDEwOls8YzAyYTYxYjY+XQpVc2luZyBkZWZhdWx0cyBmcm9tIGtzeW1vb3Bz IC10IGVsZjMyLWkzODYgLWEgaTM4NgpFRkxBR1M6IDAwMDAwMDg2CmVheDogMDAwMDAyMDIg ICBlYng6IGNmZDI3Y2VjICAgZWN4OiBjZmQyN2JlMCAgIGVkeDogMDAwMDAwMDQKZXNpOiAw MDAwMDAwMCAgIGVkaTogMDAwMDAwMDQgICBlYnA6IDAwMDA0M2ZmICAgZXNwOiBjOWQyZmNh OApkczogMDAxOCAgIGVzOiAwMDE4ICAgc3M6IDAwMTgKUHJvY2VzcyBuZnNkIChwaWQ6IDIz Niwgc3RhY2twYWdlPWM5ZDJmMDAwKQpTdGFjazogMDAwMDAwMDQgY2ZkMjdjZWMgMDAwMDAy MDIgMDAwMDAwMDEgMTQwMDNmZmYgMDAwMDAwMDIgMDAwMDAzZmYgMDAwMDAwMDAKICAgICAg IDAwMDAwMDAwIDAwMDAwODBiIDAwY2M5ZDAwIDAwMDAwMDAwIGMwMWMwMDAzIDAwMDAwMDNh IDAwMDAwMDAwIDNiMWQyOGJjCiAgICAgICAyNzk2NmUxMCAzYjFkMjhjZiAzMDk5OTJmOCAz YjFkMjhjZiAzMDk5OTJmOCBjZGNmMDAwMCAwMDAzMDAwMCAwMDAwMDAwMApDYWxsIFRyYWNl OiBbPGMwMWMwMDAzPl0gWzxjMDFlYjc2Nj5dIFs8YzAxZjBlMmU+XSBbPGMwMWYwMzM2Pl0g WzxjMDE0ODk2NT5dIFs8YzAxNDhjZjU+XSBbPGQwOGIxY2ZkPl0KICAgICAgIFs8ZDA4YjIy ZmQ+XSBbPGQwOGIyN2E0Pl0gWzxkMDhiMzdlZD5dIFs8ZDA4YjNkNzA+XSBbPGMwMjVlODVl Pl0gWzxjMDExMjMwNz5dIFs8ZDA4YjkwMTM+XSBbPGQwOGMwZTQwPl0KICAgICAgIFs8ZDA4 YjA1YTM+XSBbPGQwOGMwZTQwPl0gWzxkMDg5NzcwOD5dIFs8ZDA4YzBkMDA+XSBbPGQwOGMw N2Q4Pl0gWzxkMDhiMDM0OT5dIFs8YzAxMDU1MGI+XQpDb2RlOiA3ZSBmOCBlOSAwNiBhZSBm NCBmZiA4MCA3YiAxOCAwMCBmMyA5MCA3ZSBmOCBlOSAyYiBhZSBmNCBmZgoKPj5FSVA7IGMw MmE2MWI2IDxzdGV4dF9sb2NrKzQwZmEvNzQ4Zj4gICA8PT09PT0KVHJhY2U7IGMwMWMwMDAz IDx4ZnNfZGlyX2xlYWZfZ2V0ZGVudHNfaW50KzJjNy81NGM+ClRyYWNlOyBjMDFlYjc2NiA8 bGludmZzX3JldmFsaWRhdGVfY29yZSsxNi8xYz4KVHJhY2U7IGMwMWYwZTJlIDx2bl9pbml0 aWFsaXplK2QyL2U0PgpUcmFjZTsgYzAxZjAzMzYgPGxpbnZmc19yZWFkX2lub2RlKzFlLzUw PgpUcmFjZTsgYzAxNDg5NjUgPGdldF9uZXdfaW5vZGUrZjUvMTg4PgpUcmFjZTsgYzAxNDhj ZjUgPGlnZXQ0K2U1L2YwPgpUcmFjZTsgZDA4YjFjZmQgPFtuZnNkXW5mc2RfaWdldCsxOS9m MD4KVHJhY2U7IGQwOGIyMmZkIDxbbmZzZF1maW5kX2ZoX2RlbnRyeSsxNWQvM2EwPgpUcmFj ZTsgZDA4YjI3YTQgPFtuZnNkXWZoX3ZlcmlmeSsyNjQvNDY4PgpUcmFjZTsgZDA4YjM3ZWQg PFtuZnNkXW5mc2Rfb3BlbisyZC8xY2M+ClRyYWNlOyBkMDhiM2Q3MCA8W25mc2RdbmZzZF93 cml0ZSszOC8yYTg+ClRyYWNlOyBjMDI1ZTg1ZSA8bmV0X3J4X2FjdGlvbisxN2UvMjc4PgpU cmFjZTsgYzAxMTIzMDcgPHJlc2NoZWR1bGVfaWRsZSsyM2YvMjRjPgpUcmFjZTsgZDA4Yjkw MTMgPFtuZnNkXW5mc2QzX3Byb2Nfd3JpdGUrMTJiLzE0Yz4KVHJhY2U7IGQwOGMwZTQwIDxb bmZzZF1uZnNkX3Byb2NlZHVyZXMzK2UwLzJjMD4KVHJhY2U7IGQwOGIwNWEzIDxbbmZzZF1u ZnNkX2Rpc3BhdGNoK2NiLzE2OD4KVHJhY2U7IGQwOGMwZTQwIDxbbmZzZF1uZnNkX3Byb2Nl ZHVyZXMzK2UwLzJjMD4KVHJhY2U7IGQwODk3NzA4IDxbc3VucnBjXXN2Y19wcm9jZXNzKzJh Yy81NDQ+ClRyYWNlOyBkMDhjMGQwMCA8W25mc2RdbmZzZF9zdmNzdGF0cyswLzQwPgpUcmFj ZTsgZDA4YzA3ZDggPFtuZnNkXW5mc2RfdmVyc2lvbjMrMC8xMD4KVHJhY2U7IGQwOGIwMzQ5 IDxbbmZzZF1uZnNkKzFiOS8zNDg+ClRyYWNlOyBjMDEwNTUwYiA8a2VybmVsX3RocmVhZCsy My8zMD4KQ29kZTsgIGMwMmE2MWI2IDxzdGV4dF9sb2NrKzQwZmEvNzQ4Zj4KMDAwMDAwMDAg PF9FSVA+OgpDb2RlOyAgYzAyYTYxYjYgPHN0ZXh0X2xvY2srNDBmYS83NDhmPiAgIDw9PT09 PQogICAwOiAgIDdlIGY4ICAgICAgICAgICAgICAgICAgICAgamxlICAgIGZmZmZmZmZhIDxf RUlQKzB4ZmZmZmZmZmE+IGMwMmE2MWIwIDxzdGV4dF9sb2NrKzQwZjQvNzQ4Zj4gICA8PT09 PT0KQ29kZTsgIGMwMmE2MWI4IDxzdGV4dF9sb2NrKzQwZmMvNzQ4Zj4KICAgMjogICBlOSAw NiBhZSBmNCBmZiAgICAgICAgICAgIGptcCAgICBmZmY0YWUwZCA8X0VJUCsweGZmZjRhZTBk PiBjMDFmMGZjMyA8dm5fcmV2YWxpZGF0ZStlZi8xMTA+CkNvZGU7ICBjMDJhNjFiZCA8c3Rl eHRfbG9jays0MTAxLzc0OGY+CiAgIDc6ICAgODAgN2IgMTggMDAgICAgICAgICAgICAgICBj bXBiICAgJDB4MCwweDE4KCVlYngpCkNvZGU7ICBjMDJhNjFjMSA8c3RleHRfbG9jays0MTA1 Lzc0OGY+CiAgIGI6ICAgZjMgOTAgICAgICAgICAgICAgICAgICAgICByZXB6IG5vcCAKQ29k ZTsgIGMwMmE2MWMzIDxzdGV4dF9sb2NrKzQxMDcvNzQ4Zj4KICAgZDogICA3ZSBmOCAgICAg ICAgICAgICAgICAgICAgIGpsZSAgICA3IDxfRUlQKzB4Nz4gYzAyYTYxYmQgPHN0ZXh0X2xv Y2srNDEwMS83NDhmPgpDb2RlOyAgYzAyYTYxYzUgPHN0ZXh0X2xvY2srNDEwOS83NDhmPgog ICBmOiAgIGU5IDJiIGFlIGY0IGZmICAgICAgICAgICAgam1wICAgIGZmZjRhZTNmIDxfRUlQ KzB4ZmZmNGFlM2Y+IGMwMWYwZmY1IDx2bl9wdXJnZSsxMS9kYz4KCgoxIHdhcm5pbmcgaXNz dWVkLiAgUmVzdWx0cyBtYXkgbm90IGJlIHJlbGlhYmxlLgo= --------------6FB88F8DEC4A1CDE2E8CB503-- From owner-linux-xfs@oss.sgi.com Tue Jun 5 13:14:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55KE9w24386 for linux-xfs-outgoing; Tue, 5 Jun 2001 13:14:09 -0700 Received: from bobas.nowytarg.top.pl (ghostwheel.underley.eu.org [217.97.235.9]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55KDsh24365 for ; Tue, 5 Jun 2001 13:13:58 -0700 Received: by bobas.nowytarg.top.pl with BSMTP id ; Tue, 5 Jun 2001 22:14:41 +0200 Received: by witch.underley.eu.org id ; Tue, 5 Jun 2001 22:12:53 +0200 Received: by bobas.nowytarg.top.pl id ; Tue, 5 Jun 2001 20:34:18 +0200 Received: from oss.sgi.com ([216.32.174.27]:15625 "EHLO oss.sgi.com") by bobas.nowytarg.top.pl with ESMTP id ; Tue, 5 Jun 2001 20:34:11 +0200 Received: from localhost (mail@localhost) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55IUrp15164; Tue, 5 Jun 2001 11:30:53 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Tue, 5 Jun 2001 11:30:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55IUq015143 for linux-xfs-outgoing; Tue, 5 Jun 2001 11:30:52 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55IUnh15134 for ; Tue, 5 Jun 2001 11:30:50 -0700 Received: (qmail 29657 invoked from network); 5 Jun 2001 18:30:18 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 5 Jun 2001 18:30:18 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Russell Cattelan cc: Russel Ingram , linux-xfs@oss.sgi.com Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. In-reply-to: Your message of "Tue, 05 Jun 2001 13:18:12 EST." <3B1D2264.975D5DF4@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Jun 2001 04:30:17 +1000 Message-ID: <21043.991765817@ocs3.ocs-net> X-Orcpt: rfc822;underley@underley.eu.org Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 05 Jun 2001 13:18:12 -0500, Russell Cattelan wrote: >In some defense of Justin here: >He has done some amazing work with SCSI and the cam layer of FreeBSD. >The linux community should be quite thankful he is on board. Unfortunately he does not understand how the linux kernel is built. What is worse is that he ignores suggestions from people who do understand how kbuild works, instead he does his own thing. The SCSI code for aic7xxx may be great but if when stuffs up kbuild then it is a pain in the neck. . From owner-linux-xfs@oss.sgi.com Tue Jun 5 13:18:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55KIlF25073 for linux-xfs-outgoing; Tue, 5 Jun 2001 13:18:47 -0700 Received: from wisdom.myplace.net (cc19815-a.zwoll1.ov.nl.home.com [212.204.138.247]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55KIkh25069 for ; Tue, 5 Jun 2001 13:18:46 -0700 Received: from ws1 (ws1.myplace.net [192.168.1.15]) by wisdom.myplace.net (Postfix) with SMTP id 6A5AD2008B for ; Tue, 5 Jun 2001 22:18:44 +0200 (CEST) Message-ID: <00ce01c0edf5$4b926670$0f01a8c0@ws1> From: "Bas" To: References: <20007.991762536@ocs3.ocs-net> <3B1D2264.975D5DF4@thebarn.com> Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. Date: Tue, 5 Jun 2001 21:25:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ----- Original Message ----- From: "Russell Cattelan" To: "Keith Owens" Cc: "Russel Ingram" ; Sent: Tuesday, June 05, 2001 8:18 PM Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. > Keith Owens wrote: > > > On Wed, 6 Jun 2001 02:00:52 -0600 (MDT), > > Russel Ingram wrote: > > >make[5]: Entering directory > > >`/usr/src/linux-2.4-xfs/linux/drivers/scsi/aic7xxx/aicasm' > > >gcc -I/usr/include -I. -ldb aicasm_gram.c aicasm_scan.c aicasm.c > > >aicasm_symbol.c -o aicasm > > >/tmp/ccJ1BOkT.o: In function `symtable_open': > > >/tmp/ccJ1BOkT.o(.text+0x1b5): undefined reference to `__db185_open' > > >collect2: ld returned 1 exit status > > >make[5]: *** [aicasm] Error 1 > > > > > >I thought originally that it might be a problem with the compiler version > > >I have, but gcc on this system is still the original gcc that installed > > >with Red Hat 6.2 -- "gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 > > >release)". Any ideas? > > > > (1) Shoot the aic7xxx maintainer. > > (2) Hack drivers/scsi/aic7xxx/aicasm to set the correct version of > > libdb installed on your system. The script got it wrong. > > (3) Shoot the aic7xxx maintainer. > > (4) This is a general kernel problem, everybody is hitting it. > > Followups to linux-kernel and the aic7xxx maintainer please, not > > XFS. > > (5) Shoot the aic7xxx maintainer (do you detect a pattern here?). > > In some defense of Justin here: > He has done some amazing work with SCSI and the cam layer of FreeBSD. > The linux community should be quite thankful he is on board. > I believe you, and I'm not the one to judge him. But how can I get my adaptec 7890 to work in 2.4.5 - I know this is not a XFS related question, but I'm sure somebody can tell me how to get that controller to work. I'm using gcc 2.95.3 glibc 2.2.3 and binutils 2.11. It has never been a problem to compile an XFS kernel up to today. Thanks again, Bas. From owner-linux-xfs@oss.sgi.com Tue Jun 5 13:42:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55KgBw27815 for linux-xfs-outgoing; Tue, 5 Jun 2001 13:42:11 -0700 Received: from bobas.nowytarg.top.pl (ghostwheel.underley.eu.org [217.97.235.9]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55Kfuh27788 for ; Tue, 5 Jun 2001 13:42:08 -0700 Received: by bobas.nowytarg.top.pl with BSMTP id ; Tue, 5 Jun 2001 22:42:36 +0200 Received: by witch.underley.eu.org id ; Tue, 5 Jun 2001 22:41:17 +0200 Date: Tue, 5 Jun 2001 22:41:17 +0200 From: Daniel Podlejski To: linux-xfs@oss.sgi.com Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. Message-ID: <20010605224117.A8294@witch.underley.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21043.991765817@ocs3.ocs-net> User-Agent: Mutt/1.3.18i X-PGP-Fingerprint: 4D 72 53 F8 FE 8C 53 B9 66 AD F6 EA C9 17 CD 82 X-GPG-Fingerprint: 299F 1820 582B 283A 5F50 37D9 AA0B 6E10 03D4 EA5D X-Homepage: http://www.underley.eu.org/ X-Cert: http://www.brainbench.com/transcript.jsp?pid=124954 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sorry, this duplicate is my fault - little mistake durning bsmtpd upgrade on my home machine. -- Daniel Podlejski ... You can check out any time you like But you can never leave ... From owner-linux-xfs@oss.sgi.com Tue Jun 5 14:10:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55LATH00479 for linux-xfs-outgoing; Tue, 5 Jun 2001 14:10:29 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55LAMh00449 for ; Tue, 5 Jun 2001 14:10:22 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA1562520 for ; Tue, 5 Jun 2001 23:10:20 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2069901; Tue, 5 Jun 2001 16:09:02 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA22139; Tue, 5 Jun 2001 16:09:02 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f55LCR408302; Tue, 5 Jun 2001 16:12:27 -0500 Message-Id: <200106052112.f55LCR408302@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andrei Pelinescu - Onciul cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: permission problems.. In-Reply-To: Message from Andrei Pelinescu - Onciul of "Tue, 05 Jun 2001 21:40:41 +0200." <3B1D35B9.505CB33@fokus.gmd.de> Date: Tue, 05 Jun 2001 16:12:27 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > This is a multi-part message in MIME format. > --------------6FB88F8DEC4A1CDE2E8CB503 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Steve Lord wrote: > > > > OK, I was incorrect yesterday in saying that the patch I sent out did not > > fix it, I managed to install the kernel under the wrong name and I was not > > testing the patch. Can someone please try this patch and report back if > > it makes a difference or not. When I realized this and tried the patch, > > I could not reproduce the problem with or without it. > > > > The patch is archived here: > > > > http://oss.sgi.com/projects/xfs/mail_archive/0106/msg00050.html > > > With the patch and 30 May xfs cvs I get an oops in nfsd (bonnie++ over > nfs mounted xfs). > > Without the patch, if I have a directory with the sticky bit set it will > clear all the permissions on it: > > 1. export/sticky_dir/ mounted in /mnt/test; > PWD=/mnt/test/sticky_dir, bonnie++ -s 2048 => persmissions on sticky > are cleared. > > 2. same as above, but PWD =/mnt/test/sticky_dir/subdir, (subdir is not > sticky) => persmissions on the files in subdir are reset. > > If I try only file creations tests everything seems ok (bonnie++ -s0 -n > 200). > Also, if sticky_dir is not sticky it seems to work ok (after 1 day of > bonnie). > > > Andrei OK, thanks for the update, I can duplicate now, and I understand what is going wrong here. I also understand why you get the nmi oops with the patch, I have that fixed. I just checked the fix in internally, it should show up in cvs soon. Steve From owner-linux-xfs@oss.sgi.com Tue Jun 5 14:10:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55LA2i00322 for linux-xfs-outgoing; Tue, 5 Jun 2001 14:10:02 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55LA0h00313 for ; Tue, 5 Jun 2001 14:10:00 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA1557138 for ; Tue, 5 Jun 2001 23:09:54 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2072092 for ; Tue, 5 Jun 2001 16:08:36 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA19287 for ; Tue, 5 Jun 2001 16:08:36 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f55LC1u08291; Tue, 5 Jun 2001 16:12:01 -0500 Message-Id: <200106052112.f55LC1u08291@jen.americas.sgi.com> Date: Tue, 5 Jun 2001 16:12:01 -0500 Subject: TAKE - fix nfs permissions problems with XFS Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sorry this took a few days to find, blindingly obvious once I saw it. Steve Date: Tue Jun 5 14:06:24 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-base The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:96360a linux/fs/xfs/linux/xfs_vnode.c - 1.65 - Fix nfs permissions problem From owner-linux-xfs@oss.sgi.com Tue Jun 5 15:39:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55MdnS14933 for linux-xfs-outgoing; Tue, 5 Jun 2001 15:39:49 -0700 Received: from smtpgate.pcquote.com (smtpgate.hyperfeed.com [206.217.179.196]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55Mdmh14930 for ; Tue, 5 Jun 2001 15:39:48 -0700 Received: by smtpgate.hyperfeed.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 17:39:32 -0500 Received: from coredump.pcqt.com (198.206.236.19 [198.206.236.19]) by smtpgate.pcquote.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MJ7D77S0; Tue, 5 Jun 2001 17:39:30 -0500 Received: (qmail 11247 invoked by uid 1006); 5 Jun 2001 22:39:25 -0000 From: John Palkovic To: linux-xfs@oss.sgi.com Subject: cmd/*/configure.in shell scripting bug Date: 05 Jun 2001 17:39:25 -0500 Message-ID: <81lmn6o8ki.fsf@coredump.pcqt.com> Lines: 29 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I suggest replacing dnl Set version . VERSION with dnl Set version . ./VERSION ^^ in the configure.in scripts. Otherwise the (debian) package build fails, unless one has '.' in one's PATH (I don't, nor will I ever): coredump:/u/palkovic/linux-2.4-xfs/cmd/attr> fakeroot ./debian/rules == dpkg-buildpackage: build test -f debian/rules autoconf DEBUG="-DNDEBUG"; OPTIMIZER="-O1 -g"; DISTRIBUTION="debian"; export DEBUG OPTIMIZER DISTRIBUTION; ./configure creating cache ./config.cache .: VERSION: not found make: *** [built] Error 2 -John -- John Palkovic Software Engineer HyperFeed Technologies From owner-linux-xfs@oss.sgi.com Tue Jun 5 15:43:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55Mhgx15772 for linux-xfs-outgoing; Tue, 5 Jun 2001 15:43:42 -0700 Received: from smtp-server1.tampabay.rr.com (smtp-server1.tampabay.rr.com [65.32.1.34]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55Mhfh15767 for ; Tue, 5 Jun 2001 15:43:41 -0700 Received: from cfl.rr.com (ubr-35.87.175.wmelbourne.cfl.rr.com [65.35.87.175]) by smtp-server1.tampabay.rr.com (8.11.2/8.11.2) with ESMTP id f55Mhc511311; Tue, 5 Jun 2001 18:43:38 -0400 (EDT) Message-ID: <3B1D61F3.C44E451D@cfl.rr.com> Date: Tue, 05 Jun 2001 18:49:23 -0400 From: Mark Hounschell Reply-To: dmarkh@cfl.rr.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bas CC: linux-xfs@oss.sgi.com Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. References: <20007.991762536@ocs3.ocs-net> <3B1D2264.975D5DF4@thebarn.com> <00ce01c0edf5$4b926670$0f01a8c0@ws1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Bas wrote: > > I believe you, and I'm not the one to judge him. But how can I get my > adaptec 7890 to work in 2.4.5 - I know this is not a XFS related question, > but I'm sure somebody can tell me how to get that controller to work. > > I'm using gcc 2.95.3 glibc 2.2.3 and binutils 2.11. It has never been a > problem to compile an XFS kernel up to today. > > Thanks again, > Bas. Have you tried it with a vanilla kernel with no patches?? -- Mark Hounschell dmarkh@cfl.rr.com From owner-linux-xfs@oss.sgi.com Tue Jun 5 15:54:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55MsKD17858 for linux-xfs-outgoing; Tue, 5 Jun 2001 15:54:20 -0700 Received: from helpdesk.cieem.rpi.edu (helpdesk.cieem.rpi.edu [128.113.60.130]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55MsJh17855 for ; Tue, 5 Jun 2001 15:54:19 -0700 Received: from yua (alb-66-24-184-112.nycap.rr.com [66.24.184.112]) (authenticated) by helpdesk.cieem.rpi.edu (8.11.0/8.11.0) with ESMTP id f55MsGo09581 for ; Tue, 5 Jun 2001 18:54:16 -0400 From: "Alex Yu" To: Subject: GUI - acl/chacl? Date: Tue, 5 Jun 2001 18:54:18 -0400 Message-ID: <000401c0ee12$741a0c20$0301000a@yua> 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.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, Is there a GUI acl/chacl utility? Alex From owner-linux-xfs@oss.sgi.com Tue Jun 5 16:21:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55NLFS21570 for linux-xfs-outgoing; Tue, 5 Jun 2001 16:21:15 -0700 Received: from yog-sothoth.sgi.com ([192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55NLEh21565 for ; Tue, 5 Jun 2001 16:21:14 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id BAA1546877 for ; Wed, 6 Jun 2001 01:19:49 +0200 (CEST) mail_from (ajag@fudge.melbourne.sgi.com) Received: from fudge.melbourne.sgi.com (fudge.melbourne.sgi.com [134.14.55.184]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA13778; Wed, 6 Jun 2001 09:18:31 +1000 Received: (from ajag@localhost) by fudge.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA33375; Wed, 6 Jun 2001 09:18:29 +1000 (EST) Date: Wed, 6 Jun 2001 09:18:29 +1000 From: Andrew Gildfind To: Alex Yu Cc: linux-xfs@oss.sgi.com Subject: Re: GUI - acl/chacl? Message-ID: <20010606091829.B30006@fudge.melbourne.sgi.com> References: <000401c0ee12$741a0c20$0301000a@yua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <000401c0ee12$741a0c20$0301000a@yua>; from yua@yudesigns.com on Tue, Jun 05, 2001 at 06:54:18PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jun 05, 2001 at 06:54:18PM -0400, Alex Yu wrote: > Hello, > > Is there a GUI acl/chacl utility? > Not as part of the xfs distribution, and I'm not aware of any other GUI packages that currently support xfs... Andrew -- Andrew Gildfind - R&D Software Engineer - SGI Melbourne Australia email: ajag@sgi.com - work: +61.3.9834.8200 mobile: 0412.834.183 From owner-linux-xfs@oss.sgi.com Tue Jun 5 20:13:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f563DMT20390 for linux-xfs-outgoing; Tue, 5 Jun 2001 20:13:22 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f563DLh20379 for ; Tue, 5 Jun 2001 20:13:21 -0700 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA09823 for ; Tue, 5 Jun 2001 20:13:20 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id WAA2073594 for ; Tue, 5 Jun 2001 22:12:04 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA09817 for ; Tue, 5 Jun 2001 22:12:03 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f563FQI09007; Tue, 5 Jun 2001 22:15:26 -0500 Message-Id: <200106060315.f563FQI09007@jen.americas.sgi.com> Date: Tue, 5 Jun 2001 22:15:26 -0500 Subject: TAKE - merge XFS up to 2.4.6-pre1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hold on folks, we are going for a ride - the xfs development branch is going to be tracking Linus's pre series for a little while. Date: Tue Jun 5 20:10:14 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-base The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:96392a linux/net/core/dev.c - 1.34 linux/mm/vmscan.c - 1.55 linux/mm/page_alloc.c - 1.42 linux/mm/filemap.c - 1.75 linux/kernel/softirq.c - 1.9 linux/kernel/sched.c - 1.35 linux/kernel/ksyms.c - 1.92 linux/include/linux/slab.h - 1.14 linux/include/linux/mm.h - 1.54 linux/include/linux/interrupt.h - 1.12 linux/include/linux/ext2_fs.h - 1.14 linux/include/asm-i386/softirq.h - 1.6 linux/fs/lockd/mon.c - 1.8 linux/fs/ext2/namei.c - 1.20 linux/fs/ext2/inode.c - 1.27 linux/fs/ext2/ialloc.c - 1.15 linux/fs/ext2/dir.c - 1.14 linux/fs/buffer.c - 1.63 linux/drivers/usb/usb.c - 1.49 linux/drivers/usb/Config.in - 1.40 linux/drivers/scsi/scsi_ioctl.c - 1.18 linux/arch/i386/kernel/irq.c - 1.34 linux/arch/i386/kernel/io_apic.c - 1.26 linux/arch/i386/kernel/entry.S - 1.32 linux/arch/alpha/kernel/sys_rawhide.c - 1.11 linux/arch/alpha/kernel/sys_dp264.c - 1.15 linux/arch/alpha/kernel/core_tsunami.c - 1.18 linux/Makefile - 1.88 linux/Documentation/Configure.help - 1.81 linux/drivers/i2o/i2o_lan.c - 1.19 linux/mm/numa.c - 1.7 linux/include/linux/mmzone.h - 1.15 linux/drivers/usb/ov511.c - 1.22 linux/arch/i386/kernel/apic.c - 1.16 linux/arch/i386/kernel/mpparse.c - 1.9 linux/drivers/video/matrox/matroxfb_base.c - 1.9 linux/drivers/usb/pegasus.c - 1.17 linux/arch/i386/kernel/pci-irq.c - 1.14 linux/drivers/usb/serial/visor.h - 1.4 linux/drivers/usb/serial/visor.c - 1.16 linux/drivers/char/rio/rioroute.c - 1.4 linux/fs/pagebuf/page_buf.c - 1.84 linux/drivers/usb/bluetooth.c - 1.10 linux/include/linux/irq_cpustat.h - 1.2 linux/arch/cris/drivers/ide.c - 1.3 linux/fs/xfs_support/kmem.c - 1.7 linux/drivers/usb/serial/io_edgeport.c - 1.4 From owner-linux-xfs@oss.sgi.com Tue Jun 5 21:46:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f564kw032607 for linux-xfs-outgoing; Tue, 5 Jun 2001 21:46:58 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f564kvh32603 for ; Tue, 5 Jun 2001 21:46:57 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA21972 for ; Tue, 5 Jun 2001 15:51:50 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2071171; Tue, 5 Jun 2001 17:50:34 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA51107; Tue, 5 Jun 2001 17:50:34 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f55MrwT08654; Tue, 5 Jun 2001 17:53:58 -0500 Message-Id: <200106052253.f55MrwT08654@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Austin Gonyou cc: linux-xfs@oss.sgi.com Subject: Re: USB and XFS source tree. In-Reply-To: Message from Austin Gonyou of "Tue, 05 Jun 2001 13:26:25 CDT." Date: Tue, 05 Jun 2001 17:53:58 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I don't have anything in my /proc/bus/usb. Anyone know why? Is it cause I > need hotplug or something. Any info on this would be a great help!!! > We are not big usb people around here, otherwise I might be able to help more. Do you have devfs turned on? Part of me wonders if this is not at the back of things. Also I think you need the usb device filesystem built and loaded into the kernel for this directory to have contents. Steve > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-796-9023 > email: austin@coremetrics.com From owner-linux-xfs@oss.sgi.com Tue Jun 5 21:57:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f564vj001840 for linux-xfs-outgoing; Tue, 5 Jun 2001 21:57:45 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f564vih01837 for ; Tue, 5 Jun 2001 21:57:44 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA02457 for ; Tue, 5 Jun 2001 21:57:57 -0700 (PDT) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA03510 for linux-xfs@oss.sgi.com; Wed, 6 Jun 2001 14:56:25 +1000 (EST) Date: Wed, 6 Jun 2001 14:56:25 +1000 (EST) From: Timothy Shimmin Message-Id: <200106060456.OAA03510@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - libacl Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Adopt some Juergen Hasch suggestions. --Tim Date: Tue Jun 5 21:55:01 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:96396a cmd/acl/libacl/acl.c - 1.10 - Allow acl_to_text to output an empty string for an empty ACL. Apparently this brings it into line with Andreas code. Code suggestion by Juergen Hasch. cmd/acl/include/acl.h - 1.6 - Add ACL_OTHER (defined same as ACL_OTHER_OBJ). cmd/xfstests/src/acl_test.c - 1.2 - Test acl_to_text handling of emtpy ACL (i.e. acl_cnt of zero). cmd/xfstests/058.out - 1.2 - Update for extra output from src/acl_test. linux/fs/xfs/linux/acl.h - 1.2 - Sync with user-space acl.h. Addition of ACL_OTHER. From owner-linux-xfs@oss.sgi.com Wed Jun 6 00:13:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f567DPY17595 for linux-xfs-outgoing; Wed, 6 Jun 2001 00:13:25 -0700 Received: from idun.neukum.org (root@[195.206.156.217]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f567DNh17592 for ; Wed, 6 Jun 2001 00:13:23 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by idun.neukum.org (8.11.0/8.9.3/SuSE Linux 8.9.3-0.1) id f567CYO01593; Wed, 6 Jun 2001 09:12:34 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Oliver Neukum To: Subject: Re: USB and XFS source tree. Date: Wed, 6 Jun 2001 09:12:34 +0200 X-Mailer: KMail [version 1.2] References: <200106052253.f55MrwT08654@jen.americas.sgi.com> In-Reply-To: <200106052253.f55MrwT08654@jen.americas.sgi.com> Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Message-Id: <01060609123401.01541@idun> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wednesday, 6. June 2001 00:53, you wrote: > > I don't have anything in my /proc/bus/usb. Anyone know why? Is it cause I > > need hotplug or something. Any info on this would be a great help!!! > > We are not big usb people around here, otherwise I might be able to help > more. Do you have devfs turned on? Part of me wonders if this is not at > the back of things. Also I think you need the usb device filesystem > built and loaded into the kernel for this directory to have contents. Not only need you have to have it available, you need to mount it, too. usbdevfs /proc/bus/usb usbdevfs defaults 0 0 in /etc/fstab, after the line for proc of course HTH Oliver From owner-linux-xfs@oss.sgi.com Wed Jun 6 01:31:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f568VEs27957 for linux-xfs-outgoing; Wed, 6 Jun 2001 01:31:14 -0700 Received: from msg.ecetra.com (dollar.ecetra.com [193.164.224.209]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f568VBh27940 for ; Wed, 6 Jun 2001 01:31:11 -0700 Received: from vie-ac.office.ecetra.com (vie-ac.office.ecetra.com [10.251.148.147] (may be forged)) by msg.ecetra.com (8.9.3/8.9.3) with ESMTP id JAA25536; Wed, 6 Jun 2001 09:46:21 +0200 Received: from localhost (localhost [127.0.0.1]) by vie-ac.office.ecetra.com (8.11.4/8.11.3) with ESMTP id f567kGg21787; Wed, 6 Jun 2001 09:46:21 +0200 Date: Wed, 6 Jun 2001 09:46:16 +0200 (CEST) From: Adam Cioccarelli To: Steve Lord cc: Subject: Re: TAKE - merge XFS up to 2.4.6-pre1 In-Reply-To: <200106060315.f563FQI09007@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve, is this because of fixes to the VM? At least on my PC 2.4.5 is very hungry for my RAM! ------------------------------------------------------------------------------- Adam Cioccarelli (B.E Mechanical) Adam.Cioccarelli@ecetra.com Database Administrator Phone: +43 1 536 89 7725 Fax: +43 1 536 89 7719 ecetra Central European e-Finance AG Mobile:+43 664 181 4195 ------------------------------------------------------------------------------- On Tue, 5 Jun 2001, Steve Lord wrote: > Hold on folks, we are going for a ride - the xfs development branch is > going to be tracking Linus's pre series for a little while. > > Date: Tue Jun 5 20:10:14 PDT 2001 > Workarea: jen.americas.sgi.com:/src/lord/xfs-base > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > Modid: 2.4.x-xfs:slinx:96392a > linux/net/core/dev.c - 1.34 > linux/mm/vmscan.c - 1.55 > linux/mm/page_alloc.c - 1.42 > linux/mm/filemap.c - 1.75 > linux/kernel/softirq.c - 1.9 > linux/kernel/sched.c - 1.35 > linux/kernel/ksyms.c - 1.92 > linux/include/linux/slab.h - 1.14 > linux/include/linux/mm.h - 1.54 > linux/include/linux/interrupt.h - 1.12 > linux/include/linux/ext2_fs.h - 1.14 > linux/include/asm-i386/softirq.h - 1.6 > linux/fs/lockd/mon.c - 1.8 > linux/fs/ext2/namei.c - 1.20 > linux/fs/ext2/inode.c - 1.27 > linux/fs/ext2/ialloc.c - 1.15 > linux/fs/ext2/dir.c - 1.14 > linux/fs/buffer.c - 1.63 > linux/drivers/usb/usb.c - 1.49 > linux/drivers/usb/Config.in - 1.40 > linux/drivers/scsi/scsi_ioctl.c - 1.18 > linux/arch/i386/kernel/irq.c - 1.34 > linux/arch/i386/kernel/io_apic.c - 1.26 > linux/arch/i386/kernel/entry.S - 1.32 > linux/arch/alpha/kernel/sys_rawhide.c - 1.11 > linux/arch/alpha/kernel/sys_dp264.c - 1.15 > linux/arch/alpha/kernel/core_tsunami.c - 1.18 > linux/Makefile - 1.88 > linux/Documentation/Configure.help - 1.81 > linux/drivers/i2o/i2o_lan.c - 1.19 > linux/mm/numa.c - 1.7 > linux/include/linux/mmzone.h - 1.15 > linux/drivers/usb/ov511.c - 1.22 > linux/arch/i386/kernel/apic.c - 1.16 > linux/arch/i386/kernel/mpparse.c - 1.9 > linux/drivers/video/matrox/matroxfb_base.c - 1.9 > linux/drivers/usb/pegasus.c - 1.17 > linux/arch/i386/kernel/pci-irq.c - 1.14 > linux/drivers/usb/serial/visor.h - 1.4 > linux/drivers/usb/serial/visor.c - 1.16 > linux/drivers/char/rio/rioroute.c - 1.4 > linux/fs/pagebuf/page_buf.c - 1.84 > linux/drivers/usb/bluetooth.c - 1.10 > linux/include/linux/irq_cpustat.h - 1.2 > linux/arch/cris/drivers/ide.c - 1.3 > linux/fs/xfs_support/kmem.c - 1.7 > linux/drivers/usb/serial/io_edgeport.c - 1.4 > From owner-linux-xfs@oss.sgi.com Wed Jun 6 03:23:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56ANnS11644 for linux-xfs-outgoing; Wed, 6 Jun 2001 03:23:49 -0700 Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56ANmh11629 for ; Wed, 6 Jun 2001 03:23:48 -0700 Received: from heppcl.ph.qmw.ac.uk ([138.37.50.187]) by zeta.qmw.ac.uk with esmtp (Exim 3.16 #1) id 157aTZ-0003Wg-00 for linux-xfs@oss.sgi.com; Wed, 06 Jun 2001 11:23:45 +0100 Received: from heppct.ph.qmw.ac.uk (heppct.ph.qmw.ac.uk [138.37.50.246]) by heppcl.ph.qmw.ac.uk (8.9.3/8.9.3) with ESMTP id LAA08114 for ; Wed, 6 Jun 2001 11:23:46 +0100 Received: from localhost (pd@localhost) by heppct.ph.qmw.ac.uk (8.11.2/8.9.3) with ESMTP id f56ANkg19049 for ; Wed, 6 Jun 2001 11:23:46 +0100 X-Authentication-Warning: heppct.ph.qmw.ac.uk: pd owned process doing -bs Date: Wed, 6 Jun 2001 11:23:45 +0100 (BST) From: "P.Dixon" To: Subject: Red Hat 7.1 and quotas Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I've just upgraded to Red Hat 7.1 from Red Hat 6.2 and have all my file systems using xfs. Unfortunately, I can no longer get quota running: [root@hepserv /root]# quotaon /export/users quotaon: /dev/sdb1: Invalid argument quotaon: /dev/sdb1: Invalid argument Does the kernel that is installed by the SGI XFS 1.0 Red Hat 7.1 CD have quota support enabled? Perhaps there is something obvious that I am not doing...? Cheerio, Paul ------------------------------------------------------------------------------- Paul Dixon Email: P.Dixon@qmw.ac.uk Department of Physics Phone: (020) 7882 5054 Queen Mary, University of London Fax : (020) 7882 5054 Mile End Road, London E1 4NS URL : http://hepwww.ph.qmw.ac.uk/~pd ------------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Jun 6 03:42:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56Agnd14717 for linux-xfs-outgoing; Wed, 6 Jun 2001 03:42:49 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56Aglh14706 for ; Wed, 6 Jun 2001 03:42:48 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f56Agiq01737; Wed, 6 Jun 2001 12:42:44 +0200 Message-Id: <4.3.2.7.2.20010606124009.03171c08@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Jun 2001 12:42:49 +0200 To: "P.Dixon" , From: Seth Mos Subject: Re: Red Hat 7.1 and quotas In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:23 6-6-2001 +0100, P.Dixon wrote: >Hi, > >I've just upgraded to Red Hat 7.1 from Red Hat 6.2 and have all my file >systems using xfs. Unfortunately, I can no longer get quota running: > >[root@hepserv /root]# quotaon /export/users >quotaon: /dev/sdb1: Invalid argument >quotaon: /dev/sdb1: Invalid argument > >Does the kernel that is installed by the SGI XFS 1.0 Red Hat 7.1 CD have >quota support enabled? Perhaps there is something obvious that I am not >doing...? Do you mount the drive with the usrquota and grpquota options? Quotas with XFS are enabled at mount time not by quotaon Check your dmesg output for the line that says it is enabling quotas. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Jun 6 04:03:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56B3Fg18471 for linux-xfs-outgoing; Wed, 6 Jun 2001 04:03:15 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56B3Dh18465 for ; Wed, 6 Jun 2001 04:03:13 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f56B35q01907; Wed, 6 Jun 2001 13:03:05 +0200 Message-Id: <4.3.2.7.2.20010606125817.031dcff8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Jun 2001 13:03:10 +0200 To: "P.Dixon" From: Seth Mos Subject: Re: Red Hat 7.1 and quotas Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <4.3.2.7.2.20010606124009.03171c08@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:49 6-6-2001 +0100, you wrote: >Hi, > > > Do you mount the drive with the usrquota and grpquota options? > > >Yes. From my fstab: >/dev/sdb1 /export/users xfs defaults,usrquota 1 2 > >(I'm not interested in group quotas) > > > Quotas with XFS are enabled at mount time not by quotaon > > Check your dmesg output for the line that says it is enabling quotas. > > >[root@hepserv /root]# dmesg|grep quota >VFS: Diskquotas version dquot_6.5.0 initialized From the thread "XFS 1.0/Quota" on the mailinglist: [root@gauss quota-tools]# quotaon -v /users/raid2 quotaon: Enable XFS group quota during mount quotaon: Enable XFS user quota during mount From the thread "Problem setting up quotas": # repquota -v /dev/hda4 this will tell for sure whether quota are enabled. when you mount with quota for the first time, you should see a console message - "XFS doing a quotacheck", or something along those lines. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Jun 6 04:13:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56BDMU20507 for linux-xfs-outgoing; Wed, 6 Jun 2001 04:13:22 -0700 Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56BDLh20504 for ; Wed, 6 Jun 2001 04:13:21 -0700 Received: from heppcl.ph.qmw.ac.uk ([138.37.50.187]) by zeta.qmw.ac.uk with esmtp (Exim 3.16 #1) id 157bFO-00045n-00; Wed, 06 Jun 2001 12:13:10 +0100 Received: from heppct.ph.qmw.ac.uk (heppct.ph.qmw.ac.uk [138.37.50.246]) by heppcl.ph.qmw.ac.uk (8.9.3/8.9.3) with ESMTP id MAA08959; Wed, 6 Jun 2001 12:13:11 +0100 Received: from localhost (pd@localhost) by heppct.ph.qmw.ac.uk (8.11.2/8.9.3) with ESMTP id f56BDBK19370; Wed, 6 Jun 2001 12:13:11 +0100 X-Authentication-Warning: heppct.ph.qmw.ac.uk: pd owned process doing -bs Date: Wed, 6 Jun 2001 12:13:11 +0100 (BST) From: "P.Dixon" To: Seth Mos cc: Subject: Re: Red Hat 7.1 and quotas In-Reply-To: <4.3.2.7.2.20010606125817.031dcff8@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > [root@gauss quota-tools]# quotaon -v /users/raid2 > quotaon: Enable XFS group quota during mount > quotaon: Enable XFS user quota during mount > It would be nice if I got that message. > From the thread "Problem setting up quotas": > > # repquota -v /dev/hda4 > > this will tell for sure whether quota are enabled. when you > mount with quota for the first time, you should see a console > message - "XFS doing a quotacheck", or something along those > lines. > [root@hepserv /root]# repquota -v /dev/sdb1 Not all specified mountpoints are using quota Damn. I will go and try a test system... Cheers, Paul From owner-linux-xfs@oss.sgi.com Wed Jun 6 04:27:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56BRkG23164 for linux-xfs-outgoing; Wed, 6 Jun 2001 04:27:46 -0700 Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56BReh23154 for ; Wed, 6 Jun 2001 04:27:40 -0700 Received: from heppcl.ph.qmw.ac.uk ([138.37.50.187]) by zeta.qmw.ac.uk with esmtp (Exim 3.16 #1) id 157bTO-0004HL-00 for linux-xfs@oss.sgi.com; Wed, 06 Jun 2001 12:27:38 +0100 Received: from heppct.ph.qmw.ac.uk (heppct.ph.qmw.ac.uk [138.37.50.246]) by heppcl.ph.qmw.ac.uk (8.9.3/8.9.3) with ESMTP id MAA09291 for ; Wed, 6 Jun 2001 12:27:39 +0100 Received: from localhost (pd@localhost) by heppct.ph.qmw.ac.uk (8.11.2/8.9.3) with ESMTP id f56BRd719442 for ; Wed, 6 Jun 2001 12:27:39 +0100 X-Authentication-Warning: heppct.ph.qmw.ac.uk: pd owned process doing -bs Date: Wed, 6 Jun 2001 12:27:39 +0100 (BST) From: "P.Dixon" To: Subject: Re: Red Hat 7.1 and quotas In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk OK, I've had a play with a test machine.... Red Hat 7.1, installed from SGI XFS 1.0 CDROM [root@webpc2 /root]# cat /etc/fstab /dev/hde3 /home xfs defaults,usrquota,grpquota 1 2 [root@webpc2 /root]# quotaon -v /home quotaon: /dev/hde3: Invalid argument quotaon: /dev/hde3: Invalid argument I rebooted anyway, and after the reboot: [root@webpc2 /root]# dmesg|grep quota VFS: Diskquotas version dquot_6.5.0 initialized XFS quotacheck ide2(33,3): Please wait. XFS quotacheck ide2(33,3): Done. [root@webpc2 /root]# repquota -v /dev/hde3 Not all specified mountpoints are using quota. Doh! Paul From owner-linux-xfs@oss.sgi.com Wed Jun 6 07:06:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56E61J16707 for linux-xfs-outgoing; Wed, 6 Jun 2001 07:06:01 -0700 Received: from akira.ep-ka.de (akira.ep-ag.com [194.120.231.250]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56E5xh16704 for ; Wed, 6 Jun 2001 07:06:00 -0700 Received: from ep-ag.com (sol10.ep-ka.de [194.120.231.11]) by akira.ep-ka.de (8.9.1/8.9.3) with ESMTP id QAA00541 for ; Wed, 6 Jun 2001 16:05:51 +0200 Received: from ep-ag.com (stb@crusher.ep-ka.de [194.120.231.18]) by ep-ag.com (8.9.3/8.9.3) with ESMTP id QAA17437 for ; Wed, 6 Jun 2001 16:05:50 +0200 (MET DST) Message-ID: <3B1E38BE.5080402@ep-ag.com> Date: Wed, 06 Jun 2001 16:05:50 +0200 From: "Klaus Strebel,ITS,204" Reply-To: linux-xfs@oss.sgi.com Organization: EIGNER+PARTNER AG User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-XFS i686; en-US; rv:0.9) Gecko/20010505 X-Accept-Language: de, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Hanging around with 2.4.5-xfs from cvs References: <7922.991409390@ocs3.ocs-net> <3B1A64C5.AF1D7DDA@thebarn.com> <3B1CB2B9.4090308@ep-ag.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Klaus Strebel,ITS,204 wrote: > Russell Cattelan wrote: > >> Keith Owens wrote: >> >> And of course the question to ask which version of the compiler are you >> using? I've had problems with kdb and everything but 2.91.66 for the >> compiler. >> >> Although it never failed to boot. > > > Tried both gcc-2.95.2 and kgcc alias egsc-2.91.66. > . . . > > > I think its because of patches to the 2.4.5-tree applied to linux-xfs > cvs tree. Vanilla kernel with only (i hope all) patches needed for xfs > from linux-2.4.5-xfs-05312001.patch.bz2 works. > > Ciao > Klaus > Updated my cvs-tree and the birdie's flying again ! Perhaps a change i linux/net/core/dev.c|1.34 made it. So i'm going on xfssing ... Bye Klaus P.S.: Cheers to all who made XFS on Linux possible! From owner-linux-xfs@oss.sgi.com Wed Jun 6 07:10:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56EAhb17652 for linux-xfs-outgoing; Wed, 6 Jun 2001 07:10:43 -0700 Received: from sheffield.cnchost.com (sheffield.concentric.net [207.155.252.12]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56EAgh17649 for ; Wed, 6 Jun 2001 07:10:42 -0700 Received: from lal ([209.8.8.217]) by sheffield.cnchost.com id KAA11964; Wed, 6 Jun 2001 10:10:41 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] From: "Mark Pinto" To: Subject: 2.4.6-pre1 Date: Wed, 6 Jun 2001 10:08:49 -0400 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 In-Reply-To: <3B013BB2.8282698A@sgi.com> Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I was using yesterday's 2.4.5 cvs kernel just fine...today, I went to to try out 2.4.6-pre1. Everything works perfectly, except for iptables. How XFS has anything to iptables, I cant understand. The reason I believe it to be an issue with this new cvs kernel, is that when I boot from yesterday's cvs kernel iptables works fine. They're both configured exactly the same, with netfilter support built in and iptables (and all the other iptables goodies) as modules. After installing the 2.4.6-pre1 kernel and rebooting, iptables simply refuses to work. I look in /lib/modules/2.4.6-pre1-xfs and sure enough, the modules for them are there. modprobe ip_tables fails, saying unresolved symbols. depmod -a just spits out the same thing at me. Any suggestions? From owner-linux-xfs@oss.sgi.com Wed Jun 6 07:15:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56EFp418693 for linux-xfs-outgoing; Wed, 6 Jun 2001 07:15:51 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56EFph18690 for ; Wed, 6 Jun 2001 07:15:51 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA08753 for ; Wed, 6 Jun 2001 07:16:05 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2071868; Wed, 6 Jun 2001 09:14:34 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA51351; Wed, 6 Jun 2001 09:14:33 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f56EHjO09683; Wed, 6 Jun 2001 09:17:45 -0500 Message-Id: <200106061417.f56EHjO09683@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Mark Pinto" cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.6-pre1 In-Reply-To: Message from "Mark Pinto" of "Wed, 06 Jun 2001 10:08:49 EDT." Date: Wed, 06 Jun 2001 09:17:45 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I was using yesterday's 2.4.5 cvs kernel just fine...today, I went to to try > out 2.4.6-pre1. Everything works perfectly, except for iptables. How XFS > has anything to iptables, I cant understand. The reason I believe it to be > an issue with this new cvs kernel, is that when I boot from yesterday's cvs > kernel iptables works fine. They're both configured exactly the same, with > netfilter support built in and iptables (and all the other iptables goodies) > as modules. After installing the 2.4.6-pre1 kernel and rebooting, iptables > simply refuses to work. I look in /lib/modules/2.4.6-pre1-xfs and sure > enough, the modules for them are there. modprobe ip_tables fails, saying > unresolved symbols. depmod -a just spits out the same thing at me. > Any suggestions? Has to be a 2.4.6-pre1 bug, have you looked on linux kernel for anyone else with the same issues. I did incorporate one symbol export fix into the tree above and beyond those in the original patch from Linus, but that was for something else. The second question is which symbols? The third question is can you live with iptables built into the kernel? Steve From owner-linux-xfs@oss.sgi.com Wed Jun 6 07:33:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56EXCI21547 for linux-xfs-outgoing; Wed, 6 Jun 2001 07:33:12 -0700 Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56EXBh21534 for ; Wed, 6 Jun 2001 07:33:11 -0700 Received: by chiara.elte.hu (Postfix, from userid 17000) id 2D16A1FC7; Wed, 6 Jun 2001 16:33:06 +0200 (CEST) Date: Wed, 6 Jun 2001 16:33:05 +0200 From: KELEMEN Peter To: linux-xfs@oss.sgi.com Subject: Re: 2.4.6-pre1 Message-ID: <20010606163305.A1633@chiara.elte.hu> Reply-To: KELEMEN Peter Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200106061417.f56EHjO09683@jen.americas.sgi.com> User-Agent: Mutt/1.3.18i Organization: ELTE Eotvos Lorand University of Sciences, Budapest, Hungary 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 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk * Steve Lord (lord@sgi.com) [20010606 09:17]: > Has to be a 2.4.6-pre1 bug, have you looked on linux kernel for > anyone else with the same issues. [...] iptables works here without problems with 2.4.6-pre1-xfs, compiled as modules. No problem whatsoever. nope:~/bin/boot# lsmod Module Size Used by ipt_LOG 4210 2 (autoclean) ipt_limit 1884 2 (autoclean) ipt_multiport 1626 2 (autoclean) iptable_filter 2661 0 (autoclean) (unused) ip_tables 12700 4 [ipt_LOG ipt_limit ipt_multiport iptable_filter] nope:~/bin/boot# uname -a Linux nope 2.4.6-pre1-xfs #14 Wed Jun 6 13:46:22 CEST 2001 i686 unknown Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ / fuji@elte.hu .+' `+...+' `+...+' `+...+' `+...+' From owner-linux-xfs@oss.sgi.com Wed Jun 6 07:35:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56EZNe22096 for linux-xfs-outgoing; Wed, 6 Jun 2001 07:35:23 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56EZLh22092 for ; Wed, 6 Jun 2001 07:35:21 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f56EZ7q03550; Wed, 6 Jun 2001 16:35:07 +0200 Message-Id: <4.3.2.7.2.20010606162948.03169660@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Jun 2001 16:35:11 +0200 To: "Mark Pinto" , From: Seth Mos Subject: Re: 2.4.6-pre1 In-Reply-To: References: <3B013BB2.8282698A@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10:08 6-6-2001 -0400, Mark Pinto wrote: >I was using yesterday's 2.4.5 cvs kernel just fine...today, I went to to try >out 2.4.6-pre1. Everything works perfectly, except for iptables. How XFS >has anything to iptables, I cant understand. The reason I believe it to be >an issue with this new cvs kernel, is that when I boot from yesterday's cvs >kernel iptables works fine. They're both configured exactly the same, with >netfilter support built in and iptables (and all the other iptables goodies) >as modules. After installing the 2.4.6-pre1 kernel and rebooting, iptables >simply refuses to work. I look in /lib/modules/2.4.6-pre1-xfs and sure >enough, the modules for them are there. modprobe ip_tables fails, saying >unresolved symbols. depmod -a just spits out the same thing at me. >Any suggestions? Did you do a make mrproper before recompiling? It might just be that modversions is screwed up. Save your .config make mrproper and try again. I have disabled Module Versions on my iptables firewall just to be sure. On my testmachine I can succesfully load the modules with modversions. I suspect the broken Makefile system has bitten you (again, again?, yeah again.) Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Jun 6 07:43:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56Eh0X23377 for linux-xfs-outgoing; Wed, 6 Jun 2001 07:43:00 -0700 Received: from studsv07.studserv.uni-stuttgart.de (studsv07.studserv.uni-stuttgart.de [129.69.21.37]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56Egxh23370 for ; Wed, 6 Jun 2001 07:42:59 -0700 Received: from ysabell.wh.vaih [129.69.166.244] by studsv07.studserv.uni-stuttgart.de with ESMTP (SMTPD32-6.06) id A169E91E0314; Wed, 06 Jun 2001 16:42:49 +0200 Received: from marcelo by ysabell.wh.vaih with local (Exim 3.22 #1 (Debian)) id 157eWK-0000N2-00; Wed, 06 Jun 2001 16:42:52 +0200 Date: Wed, 6 Jun 2001 16:42:52 +0200 From: "Marcelo E. Magallon" To: Mark Pinto Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.6-pre1 Message-ID: <20010606164252.A1416@ysabell.wh.vaih> Mail-Followup-To: Mark Pinto , linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i X-Operating-System: Linux ysabell 2.4.4-xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> Mark Pinto writes: > I look in /lib/modules/2.4.6-pre1-xfs and sure enough, the modules > for them are there. modprobe ip_tables fails, saying unresolved > symbols. depmod -a just spits out the same thing at me. Any > suggestions? Try with the FAQ: http://www.tux.org/lkml/#s8-8 From owner-linux-xfs@oss.sgi.com Wed Jun 6 08:05:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56F5Vw25828 for linux-xfs-outgoing; Wed, 6 Jun 2001 08:05:31 -0700 Received: from sheffield.cnchost.com (sheffield.concentric.net [207.155.252.12]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56F5Sh25808 for ; Wed, 6 Jun 2001 08:05:28 -0700 Received: from lal ([209.8.8.217]) by sheffield.cnchost.com id LAA19501; Wed, 6 Jun 2001 11:05:27 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] From: "Mark Pinto" To: Subject: RE: 2.4.6-pre1 Date: Wed, 6 Jun 2001 11:03:31 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 In-Reply-To: <200106061417.f56EHjO09683@jen.americas.sgi.com> Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk To Krzysztof Rusocki: Thank you, but I had already tried that and it didnt work. It was actually a fresh tree to begin with, btw. To Steve Lord: I have searched the linux kernel mailing list, and didnt see anything related to this problem. poweredge:/home/markybob# depmod -a depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1-xfs/kernel/net/ipv4/netfilter/ip_conntrack.o depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1-xfs/kernel/net/ipv4/netfilter/ip_tables.o depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1-xfs/kernel/net/ipv4/netfilter/ipt_REJECT.o depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1-xfs/kernel/net/ipv4/netfilter/iptable_filter.o depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1-xfs/kernel/net/ipv4/netfilter/iptable_mangle.o depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1-xfs/kernel/net/ipv4/netfilter/iptable_nat.o poweredge:/home/markybob# But since Peter Kelemen has it working, it must be something on my box and not XFS nor the kernel. Thanks all for the help, anyway. I'll keep trying -----Original Message----- From: Steve Lord [mailto:lord@sgi.com] Sent: Wednesday, June 06, 2001 10:18 AM To: Mark Pinto Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.6-pre1 > I was using yesterday's 2.4.5 cvs kernel just fine...today, I went to to try > out 2.4.6-pre1. Everything works perfectly, except for iptables. How XFS > has anything to iptables, I cant understand. The reason I believe it to be > an issue with this new cvs kernel, is that when I boot from yesterday's cvs > kernel iptables works fine. They're both configured exactly the same, with > netfilter support built in and iptables (and all the other iptables goodies) > as modules. After installing the 2.4.6-pre1 kernel and rebooting, iptables > simply refuses to work. I look in /lib/modules/2.4.6-pre1-xfs and sure > enough, the modules for them are there. modprobe ip_tables fails, saying > unresolved symbols. depmod -a just spits out the same thing at me. > Any suggestions? Has to be a 2.4.6-pre1 bug, have you looked on linux kernel for anyone else with the same issues. I did incorporate one symbol export fix into the tree above and beyond those in the original patch from Linus, but that was for something else. The second question is which symbols? The third question is can you live with iptables built into the kernel? Steve From owner-linux-xfs@oss.sgi.com Wed Jun 6 08:13:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56FD6S27163 for linux-xfs-outgoing; Wed, 6 Jun 2001 08:13:06 -0700 Received: from main.braxis.co.uk (main.braxis.co.uk [213.77.40.29]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56F84h26459 for ; Wed, 6 Jun 2001 08:08:04 -0700 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.9.3/8.9.3) id QAA14963; Wed, 6 Jun 2001 16:13:45 +0200 Date: Wed, 6 Jun 2001 16:13:45 +0200 From: Krzysztof Rusocki To: Mark Pinto Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.6-pre1 Message-ID: <20010606161345.A14886@main.braxis.co.uk> References: <3B013BB2.8282698A@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mark.pinto@capitolcreag.com on Wed, Jun 06, 2001 at 10:08:49AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Jun 06, 2001 at 10:08:49AM -0400, Mark Pinto wrote: > I was using yesterday's 2.4.5 cvs kernel just fine...today, I went to to try > out 2.4.6-pre1. Everything works perfectly, except for iptables. How XFS > has anything to iptables, I cant understand. The reason I believe it to be > an issue with this new cvs kernel, is that when I boot from yesterday's cvs > kernel iptables works fine. They're both configured exactly the same, with > netfilter support built in and iptables (and all the other iptables goodies) > as modules. After installing the 2.4.6-pre1 kernel and rebooting, iptables > simply refuses to work. I look in /lib/modules/2.4.6-pre1-xfs and sure > enough, the modules for them are there. modprobe ip_tables fails, saying > unresolved symbols. depmod -a just spits out the same thing at me. > Any suggestions? Hi Mark, it's not xfs related problem, take a look at URL below http://www.tux.org/lkml/#s8-8 Cheers, Krzysztof From owner-linux-xfs@oss.sgi.com Wed Jun 6 08:18:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56FIqD28216 for linux-xfs-outgoing; Wed, 6 Jun 2001 08:18:52 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56FIoh28212 for ; Wed, 6 Jun 2001 08:18:51 -0700 Received: (qmail 6007 invoked from network); 6 Jun 2001 15:18:47 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 6 Jun 2001 15:18:47 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Mark Pinto" cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.6-pre1 In-reply-to: Your message of "Wed, 06 Jun 2001 11:03:31 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Jun 2001 01:18:47 +1000 Message-ID: <1016.991840727@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 6 Jun 2001 11:03:31 -0400, "Mark Pinto" wrote: >poweredge:/home/markybob# depmod -a >depmod: *** Unresolved symbols in >/lib/modules/2.4.6-pre1-xfs/kernel/net/ipv4/netfilter/ip_conntrack.o depmod -ae to list the offending symbols. grep /proc/ksyms for the missing symbols, after removing the smp/_Rxxxxxxx suffix. From owner-linux-xfs@oss.sgi.com Wed Jun 6 09:35:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56GZM104603 for linux-xfs-outgoing; Wed, 6 Jun 2001 09:35:22 -0700 Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56GZEh04600 for ; Wed, 6 Jun 2001 09:35:20 -0700 Received: from jtsdell (user-38lc55t.dialup.mindspring.com [209.86.20.189]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id MAA15431; Wed, 6 Jun 2001 12:35:02 -0400 (EDT) Message-ID: X-Mailer: XFMail 1.5.0 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3B1D19A8.5CF2A415@itcampus.de> Date: Wed, 06 Jun 2001 12:34:41 -0400 (EDT) Reply-To: jtrostel@connex.com Organization: Connex From: John Trostel To: Thomas Winkler Subject: RE: acls with samba on xfs Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Your best bet would be to try using the latest XFS CVS in combination with the latest SAMBA_2_2 CVS download. Both of these have had related improvements since the official releases of both XFS 1.0 and Samba 2.2.0. I know that we (Connex) are using this type of combination for allowing domain members to change NT-like ACLs on Samba 2.2.0 (using a 2.4.3 CVS of XFS and a more recent CVS of Samba). I also wonder if using the TNG as the PDC server is causing problems with the domain users/groups.... My truck is in the 'shop' and I am away from our PDC so I can't test how that all works today. I'll look at it tomorrow if you send me a reminder. On 05-Jun-2001 Thomas Winkler wrote: > i know that there have been some questions concerning samba and xfs, but > until now i just can't get it to work the way i want it to. since i am a > member of the tng and head mailing lists i asked there first, but didn't > get a helpful reply on solving this one. > > we are running a linux server using a recent samba tng checkout as pdc > and a recent samba head checkout as fileserver. the head is a member > server of the domain and uses of course the pdc as password server. the > pdc and fileserver are running on the same machine. the used filesystem > is xfs (version 1.0). > > xfs works really fine and acls work. just the combination of samba and > xfs is not working. > > what we want is changing the share/directory/file permissions of the > fileserver via acl support from the client. we tried with different > combinations (xfs-1.0 / xfs-2.4.4 / head / 2.2.0 / tng ). some > combinations even crashed our entire system. using 2.2.0 kind of works > but only with local groups no domain users/groups. with the head we get > all wanted users and groups but the chosen acls are not mapped on the > system files (setting acls fails). > > i'd like to know if this is possible at all and what combination > xfs/samba others are using and is known to work. > > could it become a problem that the fileserver is a member of the domain > and should use domain users instead of local users? > > is someone actually running a samba/xfs system and is able to change > acls from client? > > thank you and i hope i am not too off topic > thomas winkler > > > -------------------------------------- > itCampus Software- und Systemhaus GmbH > Leipzig - Halle - Wittenberg > http://www.itcampus.de -- John M. Trostel Linux OS Engineer Connex jtrostel@connex.com From owner-linux-xfs@oss.sgi.com Wed Jun 6 09:40:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56Gek805012 for linux-xfs-outgoing; Wed, 6 Jun 2001 09:40:46 -0700 Received: from biobio.vexcel.com (biobio.vexcel.com [192.92.90.108]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56Gejh05009 for ; Wed, 6 Jun 2001 09:40:45 -0700 Received: from [192.92.90.17] (binks.vexcel.com [192.92.90.17]) by biobio.vexcel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA17027 for ; Wed, 6 Jun 2001 10:40:38 -0600 (MDT) Mime-Version: 1.0 X-Sender: brissing@mail.vexcel.com (Unverified) Message-Id: Date: Wed, 6 Jun 2001 10:40:34 -0600 To: linux-xfs@oss.sgi.com From: Dean Brissinger Subject: Compiled 'xfsdump' Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm having a heck of a time dealing with a bug with SUID bits in 'xfsrestore' (or 'xfsdump' whichever it is that loses the bits). I read somewhere that others have had this problem and it was fixed in the devel tree. I have a firewall that is very disagreeable with CVS. Is there a place I can obtain a compiled copy of the current dump/restore binaries (and/or whatever I need to fix the lossy SUID bit problem)? Thanks in advance! From owner-linux-xfs@oss.sgi.com Wed Jun 6 10:11:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56HBdF06648 for linux-xfs-outgoing; Wed, 6 Jun 2001 10:11:39 -0700 Received: from wisdom.myplace.net (cc19815-a.zwoll1.ov.nl.home.com [212.204.138.247]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56HBbh06641 for ; Wed, 6 Jun 2001 10:11:38 -0700 Received: from ws1 (ws1.myplace.net [192.168.1.15]) by wisdom.myplace.net (Postfix) with SMTP id 6079E2008B; Wed, 6 Jun 2001 19:11:36 +0200 (CEST) Message-ID: <00ca01c0eea4$500ab4a0$0f01a8c0@ws1> From: "Bas" To: Cc: References: <01060413285600.09944@garfield.linux.localdomain> <011501c0ed31$58a54360$0f01a8c0@ws1> <20010605102551.Z97441@boing.melbourne.sgi.com> <3B1CE383.DCFED687@niehs.nih.gov> Subject: 2.4.5 & Adaptec 7890 U2W Controller solved, LVM 0.9.1 b7 FAILS. Date: Wed, 6 Jun 2001 18:18:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You're right. Today I downloaded the default kernel coming from ftp.kernel.org. Patched it using 06042001-xfs-patch. It compiled and it runs. But when I patch this kernel to 0.9.1 beta 7, (CVS or standard patch makes no difference) it fails to compile. Now this: drivers/md/mddev.o: In function `__update_hardblocksize': drivers/md/mddev.o(.text+0x22d6): undefined reference to `get_hardblocksize' drivers/md/mddev.o(.text+0x2312): undefined reference to `get_hardblocksize' make[1]: *** [kallsyms] Error 1 make: *** [vmlinux] Error 2 How can I fix this. Thanks again, Bas. ----- Original Message ----- From: "Joe Krahn" To: "Timothy Shimmin" Cc: "Bas" ; Sent: Tuesday, June 05, 2001 3:49 PM Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. > Timothy Shimmin wrote: > > > > On Mon, Jun 04, 2001 at 10:02:56PM +0200, Bas wrote: > > > > > > From: "J Hayward" > > > Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. > > > > > > > > [ ] Build Adapter Firmware with Kernel Build (NEW) > > > > > > > > > > It is the last option under Adaptec AIC7xxx support. The firmware > > > > > included in the 2.4.5 release is out of sync with the kernel driver. > > > > > > > > > > I have not done this myself, since my current XFS machine does not have > > > a > > > > > SCSI controller, but see the below email for more info. > > > > > > > > Has anyone had any success using this option? Didn't work for me. Problem > > > > isn't isolated to just the 7890 it seems, I get the same error on a > > > Adaptec > > > > 2930CU. It still produced: > > > > > > > > >In interrupt handler - not syncing > > > > > > > > I also tried using the old aic7xxx driver, which did load the module. > > > However > > > > it produced a kernel oops immediately after. I don't remember the exact > > > point > > > > in the boot sequence, I believe it was at "Trying to unmount old root". > > > > > > Tried the firmware option too, but didn't work for me. > > > > > > > Tried the firmware option too, and it did work for me. > > > > scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.13 > > > > aic7880: Ultra Wide Channel A, SCSI Id=7, 16/255 SCBs > > > > --Tim > > > The problem is that linux-2.4.5-xfs-05312001.patch.bz2 > includes the files aic7xxx_seq.h and aic7xxx_reg.h which > are out of date, but which get a newer timestamp. Also > the binary aicasm/aicasm is included in the patch, but > patch creates it non-executable. Try touching aic7xxx.seq > and removing aicasm/aicasm, then rebuilding the > aic7xxx module with the build-firmware option. > > This is actually a problem with "make clean" and > "make mrproper" not knowing about some of the aic7xxx > files. > > Joe Krahn > From owner-linux-xfs@oss.sgi.com Wed Jun 6 10:45:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56Hjtc08419 for linux-xfs-outgoing; Wed, 6 Jun 2001 10:45:55 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56Hjsh08415 for ; Wed, 6 Jun 2001 10:45:54 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA07761 for ; Wed, 6 Jun 2001 10:45:52 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA1288611; Wed, 6 Jun 2001 12:44:36 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA55034; Wed, 6 Jun 2001 12:44:36 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f56Hlkl10185; Wed, 6 Jun 2001 12:47:46 -0500 Message-Id: <200106061747.f56Hlkl10185@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Chris Pascoe cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: Crashes in various ext2 functions while running xfstest/check In-Reply-To: Message from Chris Pascoe of "Mon, 04 Jun 2001 19:10:02 +1000." Date: Wed, 06 Jun 2001 12:47:46 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just an update here, I have replicated this here, and this is not just a high mem issue - but highmem when you have mixed filesystems is the only place this will cause problems, ext2 cannot cope with the buffers it is getting which have been incorrectly returned to the buffer cache by XFS. The feature of XFS which appears to be behind this is the mixture of direct and buffered I/O on the same file. For most people this should not be an issue, but some of the xfs test suite running on a highmem box can trigger this. I am not sure if fixing this will clean up other peoples XFS highmem problems. Steve > Hi Steve, > > Further to my last emails on this, I think I've tracked down why the > crashes occur, but don't know how to fix it. I eliminated the scsi > hardware, ethernet card, etc, that Seth Mos suggested might be the problem > (got loans of completely different hardware). I can reliably crash my > test machine in under an hour by running test 013 in a loop, and letting > the "/etc/cron.hourly/sysstat" cron job run. Doing some random other > commands during the process helps speed the crash up. > > The crashes I see are related to the machine having highmem support, and > buffers allocated with pages in high memory making their way onto the > (fs/buffer.c) free_list. I added an extra field to struct buffer_head > that records in the buffer head who created it (in create_empty_buffers), > and what function called put_last_free. In every instance, the > buffer_head that causes the crash was created by > hook_buffers_to_page_delay, and put onto the free list later by a call to > __invalidate_buffers. (Adding code to record in the bh who called > that.... done.... crashed, - the caller was blkdev_put this time, but I'll > run a few more tests). > > When one of these bh's with bh->b_page in high memory is given to ext2 by > getblk, and a "bread" performed, bh->b_data gets set to values < PAGE_SIZE > by a call to set_bh_page. This is why it looked like the bh's were > corrupted in my previous backtraces. The actual disk IO that was > performed on these pages proceeds okay though, as ll_rw_blk() does > create_bounce's for the real disk I/O (which is why the dereferences > you saw came after a successful call to bread). > > I can seemingly (no crashes after a weekend of repeats) make the crashes > go away by replacing GFP_HIGHUSER with GFP_USER in clean_inode > (fs/inode.c), and _pagebuf_lookup_pages (fs/pagebuf/page_buf.c). > Changing one alone doesn't make any difference. > > Hope that this makes some sense to you, and you can just say aha, and wave > the magic wand :). I hope you can replicate it locally with this > information. > > Regards, > Chris From owner-linux-xfs@oss.sgi.com Wed Jun 6 10:52:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56Hqkh08905 for linux-xfs-outgoing; Wed, 6 Jun 2001 10:52:46 -0700 Received: from whitestar.auctionwatch.com (ns2.auctionwatch.com [64.14.24.2]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56Hqih08902 for ; Wed, 6 Jun 2001 10:52:44 -0700 Received: from exback.corp.auctionwatch.com (exback.corp.auctionwatch.com [10.128.0.20]) by whitestar.auctionwatch.com (8.9.3/8.9.3) with ESMTP id KAA03882; Wed, 6 Jun 2001 10:52:37 -0700 Received: by exback.corp.auctionwatch.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Jun 2001 10:53:53 -0700 Message-ID: <5179B27750A9D411B968009027E06E27012D729F@exback.corp.auctionwatch.com> From: "Michael S. Fischer" To: "'Bas '" , "'linux-xfs@oss.sgi.com '" Cc: "'linux-lvm@sistina.com '" Subject: RE: [linux-lvm] 2.4.5 & Adaptec 7890 U2W Controller solved, LVM 0 .9.1 b7 FAILS. Date: Wed, 6 Jun 2001 10:53:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) List-Help: List-Subscribe: , List-Unsubscribe: , Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Search the lvm-devel mailing list archives for "get_hardblocksize" for the solution -- you need to change the function call name as the name has changed. -----Original Message----- From: Bas To: linux-xfs@oss.sgi.com Cc: linux-lvm@sistina.com Sent: 6/6/01 9:18 AM Subject: [linux-lvm] 2.4.5 & Adaptec 7890 U2W Controller solved, LVM 0.9.1 b7 FAILS. You're right. Today I downloaded the default kernel coming from ftp.kernel.org. Patched it using 06042001-xfs-patch. It compiled and it runs. But when I patch this kernel to 0.9.1 beta 7, (CVS or standard patch makes no difference) it fails to compile. Now this: drivers/md/mddev.o: In function `__update_hardblocksize': drivers/md/mddev.o(.text+0x22d6): undefined reference to `get_hardblocksize' drivers/md/mddev.o(.text+0x2312): undefined reference to `get_hardblocksize' make[1]: *** [kallsyms] Error 1 make: *** [vmlinux] Error 2 How can I fix this. Thanks again, Bas. ----- Original Message ----- From: "Joe Krahn" To: "Timothy Shimmin" Cc: "Bas" ; Sent: Tuesday, June 05, 2001 3:49 PM Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. > Timothy Shimmin wrote: > > > > On Mon, Jun 04, 2001 at 10:02:56PM +0200, Bas wrote: > > > > > > From: "J Hayward" > > > Subject: Re: 2.4.5 & Adaptec 7890 U2W Controller. > > > > > > > > [ ] Build Adapter Firmware with Kernel Build (NEW) > > > > > > > > > > It is the last option under Adaptec AIC7xxx support. The firmware > > > > > included in the 2.4.5 release is out of sync with the kernel driver. > > > > > > > > > > I have not done this myself, since my current XFS machine does not have > > > a > > > > > SCSI controller, but see the below email for more info. > > > > > > > > Has anyone had any success using this option? Didn't work for me. Problem > > > > isn't isolated to just the 7890 it seems, I get the same error on a > > > Adaptec > > > > 2930CU. It still produced: > > > > > > > > >In interrupt handler - not syncing > > > > > > > > I also tried using the old aic7xxx driver, which did load the module. > > > However > > > > it produced a kernel oops immediately after. I don't remember the exact > > > point > > > > in the boot sequence, I believe it was at "Trying to unmount old root". > > > > > > Tried the firmware option too, but didn't work for me. > > > > > > > Tried the firmware option too, and it did work for me. > > > > scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.13 > > > > aic7880: Ultra Wide Channel A, SCSI Id=7, 16/255 SCBs > > > > --Tim > > > The problem is that linux-2.4.5-xfs-05312001.patch.bz2 > includes the files aic7xxx_seq.h and aic7xxx_reg.h which > are out of date, but which get a newer timestamp. Also > the binary aicasm/aicasm is included in the patch, but > patch creates it non-executable. Try touching aic7xxx.seq > and removing aicasm/aicasm, then rebuilding the > aic7xxx module with the build-firmware option. > > This is actually a problem with "make clean" and > "make mrproper" not knowing about some of the aic7xxx > files. > > Joe Krahn > _______________________________________________ linux-lvm mailing list linux-lvm@sistina.com http://lists.sistina.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html From owner-linux-xfs@oss.sgi.com Wed Jun 6 11:43:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56Ih3a11163 for linux-xfs-outgoing; Wed, 6 Jun 2001 11:43:03 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56Igwh11157 for ; Wed, 6 Jun 2001 11:42:58 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA06422 for ; Wed, 6 Jun 2001 11:42:56 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2077989; Wed, 6 Jun 2001 13:41:41 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA26591; Wed, 6 Jun 2001 13:41:41 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f56Iio115846; Wed, 6 Jun 2001 13:44:50 -0500 Message-Id: <200106061844.f56Iio115846@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com cc: thomas graichen Subject: Looking for a new FAQ maintainer Date: Wed, 06 Jun 2001 13:44:50 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Thomas Graichen who initiated the XFS FAQ now has a new job which means he no longer has as much time or as many resources to look after the FAQ. After asking Thomas he has said it is OK by him to ask if there is someone else out there willing to take over the FAQ and keep it upto date. We would host it on oss, and provide access to update it there (I am pretty sure we can do that). The FAQ is getting a little long in the tooth and there are a lot of questions which go by on the list which might be added to the FAQ. So any volunteers out there? Thanks Steve From owner-linux-xfs@oss.sgi.com Wed Jun 6 13:29:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56KTAO28852 for linux-xfs-outgoing; Wed, 6 Jun 2001 13:29:10 -0700 Received: from ente.berdmann.de (p3E9E7352.dip.t-dialin.net [62.158.115.82]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56KT9h28845 for ; Wed, 6 Jun 2001 13:29:09 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.16 #2) id 157jvG-00011J-00 for linux-xfs@oss.sgi.com; Wed, 06 Jun 2001 22:28:58 +0200 Message-ID: <3B1E928A.1B49C1E8@berdmann.de> Date: Wed, 06 Jun 2001 22:28:58 +0200 From: "Bernhard R. Erdmann" Organization: Bernhard Erdmann Communication & Network Solutions X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Linux XFS Mailing List Subject: find ./. file size > 2 GB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, using findutils-4.1: # find / -perm 0 -ls find: /proc/594/fd: No such file or directory find: /proc/3744/fd/4: No such file or directory find: /dumps/imap.dmp: Value too large for defined data type find: /dumps/usr.dmp: Value too large for defined data type # ll /dumps/imap.dmp /dumps/usr.dmp -rw-r--r-- 1 root root 2645278720 Jun 4 19:35 /dumps/imap.dmp -rw-r--r-- 1 root root 2498836480 Jun 4 20:23 /dumps/usr.dmp Is it find's problem with a filesize > 2 GB? From owner-linux-xfs@oss.sgi.com Wed Jun 6 13:40:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56KeRd30776 for linux-xfs-outgoing; Wed, 6 Jun 2001 13:40:27 -0700 Received: from pipt.oz.cc.utah.edu (jdr1529@pipt.oz.cc.utah.edu [155.99.2.7]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56KeQh30770 for ; Wed, 6 Jun 2001 13:40:26 -0700 Received: from localhost (jdr1529@localhost) by pipt.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id OAA25591; Wed, 6 Jun 2001 14:40:21 -0600 (MDT) Date: Wed, 6 Jun 2001 14:40:21 -0600 (MDT) From: james rich To: Steve Lord cc: linux-xfs@oss.sgi.com, thomas graichen Subject: Re: Looking for a new FAQ maintainer In-Reply-To: <200106061844.f56Iio115846@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 6 Jun 2001, Steve Lord wrote: > After asking Thomas he has said it is OK by him to ask if there is someone > else out there willing to take over the FAQ and keep it upto date. We would > host it on oss, and provide access to update it there (I am pretty sure > we can do that). > > The FAQ is getting a little long in the tooth and there are a lot of > questions which go by on the list which might be added to the FAQ. > > So any volunteers out there? Well I don't have *lot's* of time but I think this is something I can do. James Rich james.rich@m.cc.utah.edu From owner-linux-xfs@oss.sgi.com Wed Jun 6 13:43:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56KhfO31366 for linux-xfs-outgoing; Wed, 6 Jun 2001 13:43:41 -0700 Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56Kheh31360 for ; Wed, 6 Jun 2001 13:43:40 -0700 Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:61359 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Wed, 6 Jun 2001 22:38:28 +0200 Message-Id: <4.3.2.7.2.20010606223411.03458fb0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Jun 2001 22:38:27 +0200 To: "Bernhard R. Erdmann" , Linux XFS Mailing List From: Seth Mos Subject: Re: find ./. file size > 2 GB In-Reply-To: <3B1E928A.1B49C1E8@berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 22:28 6-6-2001 +0200, Bernhard R. Erdmann wrote: >Hi, > >using findutils-4.1: > ># find / -perm 0 -ls >find: /proc/594/fd: No such file or directory >find: /proc/3744/fd/4: No such file or directory >find: /dumps/imap.dmp: Value too large for defined data type >find: /dumps/usr.dmp: Value too large for defined data type ># ll /dumps/imap.dmp /dumps/usr.dmp >-rw-r--r-- 1 root root 2645278720 Jun 4 19:35 /dumps/imap.dmp >-rw-r--r-- 1 root root 2498836480 Jun 4 20:23 /dumps/usr.dmp > >Is it find's problem with a filesize > 2 GB? Not it is the problem of your Glibc. glibc 2.2 or higher has full LFS Large file support. See your favorite distribution hanguot for updates. Slackware Current contains glibc 2.2 Debian Woody/Unstable contains glibc 2.2 RedHat 6.2 has a patched 2.1 glibc with LFS support Redhat 7+ have glibc 2.2 Mandrake is unknown to me 8+ should be fine 7+ could be (confirm) Maybe something for the FAQ. Thomas are you still there? Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Jun 6 13:57:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56KvpN01588 for linux-xfs-outgoing; Wed, 6 Jun 2001 13:57:51 -0700 Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56Kvoh01584 for ; Wed, 6 Jun 2001 13:57:50 -0700 Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:61391 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Wed, 6 Jun 2001 22:57:36 +0200 Message-Id: <4.3.2.7.2.20010606225230.030a46a0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Jun 2001 22:57:38 +0200 To: Steve Lord , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Looking for a new FAQ maintainer Cc: thomas graichen In-Reply-To: <200106061844.f56Iio115846@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:44 6-6-2001 -0500, Steve Lord wrote: >Hi, > >Thomas Graichen who initiated the XFS FAQ now has a new job which means >he no longer has as much time or as many resources to look after the FAQ. > >After asking Thomas he has said it is OK by him to ask if there is someone >else out there willing to take over the FAQ and keep it upto date. We would >host it on oss, and provide access to update it there (I am pretty sure >we can do that). > >The FAQ is getting a little long in the tooth and there are a lot of >questions which go by on the list which might be added to the FAQ. > >So any volunteers out there? I think I can do that untill someone proves me wrong ;) Since we rely on XFS for a few of our production machines at work I have some project time to do that. English spell checker needed though. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Jun 6 14:09:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56L9QT03863 for linux-xfs-outgoing; Wed, 6 Jun 2001 14:09:26 -0700 Received: from ente.berdmann.de (p3E9E7352.dip.t-dialin.net [62.158.115.82]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56L9Ph03855 for ; Wed, 6 Jun 2001 14:09:25 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.16 #2) id 157kYF-0001FM-00 for linux-xfs@oss.sgi.com; Wed, 06 Jun 2001 23:09:15 +0200 Message-ID: <3B1E9BFB.BA39775C@berdmann.de> Date: Wed, 06 Jun 2001 23:09:15 +0200 From: "Bernhard R. Erdmann" Organization: Bernhard Erdmann Communication & Network Solutions X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Linux XFS Mailing List Subject: Re: find ./. file size > 2 GB References: <4.3.2.7.2.20010606223411.03458fb0@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > >Is it find's problem with a filesize > 2 GB? > > Not it is the problem of your Glibc. > glibc 2.2 or higher has full LFS Large file support. > > See your favorite distribution hanguot for updates. > Slackware Current contains glibc 2.2 > Debian Woody/Unstable contains glibc 2.2 > RedHat 6.2 has a patched 2.1 glibc with LFS support I'm using RHL 6.1 with glibc-2.1.3-22.i386.rpm from 6.2/updates (dated Jan, 16th). From owner-linux-xfs@oss.sgi.com Wed Jun 6 14:14:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56LEOt04937 for linux-xfs-outgoing; Wed, 6 Jun 2001 14:14:24 -0700 Received: from vortex.xnote.com ([65.105.237.130]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56LEOh04934 for ; Wed, 6 Jun 2001 14:14:24 -0700 Received: from xnote.com (slccheck01.firsthealth.com [209.180.88.28]) by vortex.xnote.com (8.11.0/8.8.7) with ESMTP id f56KKRA05610 for ; Wed, 6 Jun 2001 14:20:27 -0600 Message-ID: <3B1E9D2B.9030404@xnote.com> Date: Wed, 06 Jun 2001 15:14:19 -0600 From: Vernon McPherron Reply-To: vernon@xnote.com User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9) Gecko/20010505 X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: find ./. file size > 2 GB References: <4.3.2.7.2.20010606223411.03458fb0@pop.xs4all.nl> <3B1E9BFB.BA39775C@berdmann.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Bernhard R. Erdmann wrote: >>>Is it find's problem with a filesize > 2 GB? >>> >>Not it is the problem of your Glibc. >>glibc 2.2 or higher has full LFS Large file support. >> >>See your favorite distribution hanguot for updates. >>Slackware Current contains glibc 2.2 >>Debian Woody/Unstable contains glibc 2.2 >>RedHat 6.2 has a patched 2.1 glibc with LFS support >> > > I'm using RHL 6.1 with glibc-2.1.3-22.i386.rpm from 6.2/updates (dated > Jan, 16th). > Sounds like you need to upgrade then. :) You need >= glibc 2.2 that has LFS -- -=/Vernon McPherron/=- From owner-linux-xfs@oss.sgi.com Wed Jun 6 14:31:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56LV2208549 for linux-xfs-outgoing; Wed, 6 Jun 2001 14:31:02 -0700 Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56LV1h08544 for ; Wed, 6 Jun 2001 14:31:01 -0700 Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:61477 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Wed, 6 Jun 2001 23:30:52 +0200 Message-Id: <4.3.2.7.2.20010606232802.034d3980@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Jun 2001 23:30:51 +0200 To: vernon@xnote.com, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: find ./. file size > 2 GB In-Reply-To: <3B1E9D2B.9030404@xnote.com> References: <4.3.2.7.2.20010606223411.03458fb0@pop.xs4all.nl> <3B1E9BFB.BA39775C@berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:14 6-6-2001 -0600, Vernon McPherron wrote: >Bernhard R. Erdmann wrote: > >>>>Is it find's problem with a filesize > 2 GB? >>>Not it is the problem of your Glibc. >>>glibc 2.2 or higher has full LFS Large file support. >>> >>>See your favorite distribution hanguot for updates. >>>Slackware Current contains glibc 2.2 >>>Debian Woody/Unstable contains glibc 2.2 >>>RedHat 6.2 has a patched 2.1 glibc with LFS support >>I'm using RHL 6.1 with glibc-2.1.3-22.i386.rpm from 6.2/updates (dated >>Jan, 16th). > >Sounds like you need to upgrade then. :) > >You need >= glibc 2.2 that has LFS The updated glibc that is available for 6.0 6.1 and 6.2 does have LFS patches to the extent that most stuff works. Which you will need anyway because of a local root exploit in the old one. It works ok for listing files, but my memory recalls that lseek may show weird behaviour. It does not show in the QA tests AFAIK. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Jun 6 16:54:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f56NscC31346 for linux-xfs-outgoing; Wed, 6 Jun 2001 16:54:38 -0700 Received: from theirongiant.weebeastie.net (root@theirongiant.zip.net.au [61.8.0.198]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f56Nsah31335 for ; Wed, 6 Jun 2001 16:54:36 -0700 Received: (from hogarth@localhost) by theirongiant.weebeastie.net (8.9.3/8.9.3/Debian 8.9.3-21) id JAA22126; Thu, 7 Jun 2001 09:54:38 +1000 Date: Thu, 7 Jun 2001 09:54:38 +1000 From: CaT To: Seth Mos Cc: "Bernhard R. Erdmann" , Linux XFS Mailing List Subject: Re: find ./. file size > 2 GB Message-ID: <20010607095438.K499@zip.com.au> References: <3B1E928A.1B49C1E8@berdmann.de> <4.3.2.7.2.20010606223411.03458fb0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010606223411.03458fb0@pop.xs4all.nl>; from knuffie@xs4all.nl on Wed, Jun 06, 2001 at 10:38:27PM +0200 Organisation: Furball Inc. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Jun 06, 2001 at 10:38:27PM +0200, Seth Mos wrote: > See your favorite distribution hanguot for updates. > Slackware Current contains glibc 2.2 > Debian Woody/Unstable contains glibc 2.2 debian stable needs 2.4.x and a recompile of glibc and you're sweet. (currently running a >2gig mysql db on such a beastie. one of the files is >2gig and it's all sweet) -- CaT (cat@zip.com.au) *** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 From owner-linux-xfs@oss.sgi.com Wed Jun 6 17:08:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f5708Qa01624 for linux-xfs-outgoing; Wed, 6 Jun 2001 17:08:26 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f5708Ph01621 for ; Wed, 6 Jun 2001 17:08:25 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA24601 for ; Wed, 6 Jun 2001 17:08:23 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id TAA2083953; Wed, 6 Jun 2001 19:07:07 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id TAA74121; Wed, 6 Jun 2001 19:07:07 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f570AAk21738; Wed, 6 Jun 2001 19:10:10 -0500 Message-Id: <200106070010.f570AAk21738@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: CaT cc: Seth Mos , "Bernhard R. Erdmann" , Linux XFS Mailing List Subject: Re: find ./. file size > 2 GB In-Reply-To: Message from CaT of "Thu, 07 Jun 2001 09:54:38 +1000." <20010607095438.K499@zip.com.au> Date: Wed, 06 Jun 2001 19:10:10 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Wed, Jun 06, 2001 at 10:38:27PM +0200, Seth Mos wrote: > > See your favorite distribution hanguot for updates. > > Slackware Current contains glibc 2.2 > > Debian Woody/Unstable contains glibc 2.2 > > debian stable needs 2.4.x and a recompile of glibc and you're sweet. > > (currently running a >2gig mysql db on such a beastie. one of the files > is >2gig and it's all sweet) > Just to add to this discussion, even with an LFS enabled user space, there still appear to be some apps which have not been rebuilt with the correct compile options. tcsh is an example, I recall question about this a while back, and without rebuilding tcsh with some glibc 64 bit define it was incorrectly reporting information on files greater than 2Gbytes. Steve From owner-linux-xfs@oss.sgi.com Wed Jun 6 17:11:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f570BYW02363 for linux-xfs-outgoing; Wed, 6 Jun 2001 17:11:34 -0700 Received: from theirongiant.weebeastie.net (root@theirongiant.zip.net.au [61.8.0.198]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f570BXh02356 for ; Wed, 6 Jun 2001 17:11:33 -0700 Received: (from hogarth@localhost) by theirongiant.weebeastie.net (8.9.3/8.9.3/Debian 8.9.3-21) id KAA22812; Thu, 7 Jun 2001 10:11:27 +1000 Date: Thu, 7 Jun 2001 10:11:27 +1000 From: CaT To: Steve Lord Cc: Seth Mos , "Bernhard R. Erdmann" , Linux XFS Mailing List Subject: Re: find ./. file size > 2 GB Message-ID: <20010607101127.M499@zip.com.au> References: <200106070010.f570AAk21738@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106070010.f570AAk21738@jen.americas.sgi.com>; from lord@sgi.com on Wed, Jun 06, 2001 at 07:10:10PM -0500 Organisation: Furball Inc. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Jun 06, 2001 at 07:10:10PM -0500, Steve Lord wrote: > > debian stable needs 2.4.x and a recompile of glibc and you're sweet. > > > > (currently running a >2gig mysql db on such a beastie. one of the files > > is >2gig and it's all sweet) > > Just to add to this discussion, even with an LFS enabled user space, there > still appear to be some apps which have not been rebuilt with the correct > compile options. tcsh is an example, I recall question about this a while > back, and without rebuilding tcsh with some glibc 64 bit define it was > incorrectly reporting information on files greater than 2Gbytes. yup. forgot to add that after recompiling glibc you'll need to recompile any utils which will need to access >2gig files. -- CaT (cat@zip.com.au) *** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 From owner-linux-xfs@oss.sgi.com Wed Jun 6 17:20:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f570KC704257 for linux-xfs-outgoing; Wed, 6 Jun 2001 17:20:12 -0700 Received: from vertigo.incyte.com (master.incyte.com [198.31.37.253]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f570KCh04238 for ; Wed, 6 Jun 2001 17:20:12 -0700 Received: from vertigo.incyte.com (wfrancis@localhost) by vertigo.incyte.com (8.11.0/8.11.0) with ESMTP id f570JNS17321; Wed, 6 Jun 2001 17:19:23 -0700 Message-Id: <200106070019.f570JNS17321@vertigo.incyte.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: CaT cc: Steve Lord , Seth Mos , "Bernhard R. Erdmann" , Linux XFS Mailing List Subject: Re: find ./. file size > 2 GB In-Reply-To: Message from CaT of "Thu, 07 Jun 2001 10:11:27 +1000." <20010607101127.M499@zip.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Jun 2001 17:19:23 -0700 From: Will Francis Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > yup. forgot to add that after recompiling glibc you'll need to recompile > any utils which will need to access >2gig files. including perl I learned. However, it's _very_ easy to install the perl source RPM, change the -Uuselargefiles to -Duselargefiles in the spec file, rpm -bb perl.spec (don't forget to update the Release number) and you'll have a nice new perl RPM in a few minutes which works with large files perfectly. I'm sure debian has a similar mechanism someplace. /W From owner-linux-xfs@oss.sgi.com Wed Jun 6 17:58:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f570wbU09721 for linux-xfs-outgoing; Wed, 6 Jun 2001 17:58:37 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f570wZh09714 for ; Wed, 6 Jun 2001 17:58:35 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA04649 for ; Wed, 6 Jun 2001 17:58:28 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA64578; Thu, 7 Jun 2001 10:57:09 +1000 (EST) Date: Thu, 7 Jun 2001 10:57:09 +1000 From: Timothy Shimmin To: Dean Brissinger Cc: linux-xfs@oss.sgi.com Subject: Re: Compiled 'xfsdump' Message-ID: <20010607105708.J237728@boing.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from brissing@vexcel.com on Wed, Jun 06, 2001 at 10:40:34AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Dean, On Wed, Jun 06, 2001 at 10:40:34AM -0600, Dean Brissinger wrote: > I'm having a heck of a time dealing with a bug with SUID bits in > 'xfsrestore' (or 'xfsdump' whichever it is that loses the bits). The bits are stored correctly in the dump. It's just that xfsrestore does a chown after the chmod which clears the SUID/SGID bits. The fix is to do the chown before the chmod. > I > read somewhere that others have had this problem and it was fixed in > the devel tree. Yes, as mentioned above. > I have a firewall that is very disagreeable with > CVS. Is there a place I can obtain a compiled copy of the current > dump/restore binaries (and/or whatever I need to fix the lossy SUID > bit problem)? I could email you the binaries directly... Below are the diffs - which are just movements of code - a reordering of chmod and chown.... --Tim *** /usr/tmp/TmpDir.2419384-0/cmd/xfsdump/restore/content.c_1.6 Thu Jun 7 10:37:32 2001 --- /usr/tmp/TmpDir.2419384-0/cmd/xfsdump/restore/content.c_1.7 Thu Jun 7 10:37:32 2001 *************** *** 7398,7414 **** strerror( errno )); } - /* set the permissions/mode - */ - rval = fchmod( fd, ( mode_t )bstatp->bs_mode ); - if ( rval ) { - mlog( MLOG_VERBOSE | MLOG_WARNING, - "unable to set mode " - "of %s: %s\n", - path, - strerror( errno )); - } - /* set the owner and group (if enabled) */ if ( persp->a.ownerpr ) { --- 7398,7403 ---- *************** *** 7422,7427 **** --- 7411,7427 ---- path, strerror( errno )); } + } + + /* set the permissions/mode + */ + rval = fchmod( fd, ( mode_t )bstatp->bs_mode ); + if ( rval ) { + mlog( MLOG_VERBOSE | MLOG_WARNING, + "unable to set mode " + "of %s: %s\n", + path, + strerror( errno )); } rval = close( fd ); *** /usr/tmp/TmpDir.2728373-0/cmd/xfsdump/restore/tree.c_1.3 Thu Jun 7 10:38:22 2001 --- /usr/tmp/TmpDir.2728373-0/cmd/xfsdump/restore/tree.c_1.4 Thu Jun 7 10:38:22 2001 *************** *** 2446,2458 **** strerror( errno )); } mode = dirattr_get_mode( dah ); - rval = chmod( path, mode ); - if ( rval ) { - mlog( MLOG_NORMAL | MLOG_TREE, - "chmod %s failed: %s\n", - path, - strerror( errno )); - } if ( persp->p_ownerpr ) { rval = chown( path, dirattr_get_uid( dah ), --- 2446,2451 ---- *************** *** 2465,2470 **** --- 2458,2470 ---- path, strerror( errno )); } + } + rval = chmod( path, mode ); + if ( rval ) { + mlog( MLOG_NORMAL | MLOG_TREE, + "chmod %s failed: %s\n", + path, + strerror( errno )); } } From owner-linux-xfs@oss.sgi.com Wed Jun 6 18:43:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f571h2V16427 for linux-xfs-outgoing; Wed, 6 Jun 2001 18:43:02 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f571h2h16424 for ; Wed, 6 Jun 2001 18:43:02 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA06800 for ; Wed, 6 Jun 2001 18:43:16 -0700 (PDT) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA89110 for linux-xfs@oss.sgi.com; Thu, 7 Jun 2001 11:41:44 +1000 (EST) Date: Thu, 7 Jun 2001 11:41:44 +1000 (EST) From: Timothy Shimmin Message-Id: <200106070141.LAA89110@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - acl VERSION/CHANGES Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Forgot to update these again. Damn. --Tim Date: Wed Jun 6 18:40:53 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:96454a cmd/acl/VERSION - 1.6 - Bump the version number to 1.0.5 for a libacl function change. cmd/acl/doc/CHANGES - 1.6 - Describe libacl change for 1.0.5. From owner-linux-xfs@oss.sgi.com Wed Jun 6 22:11:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f575BsJ02662 for linux-xfs-outgoing; Wed, 6 Jun 2001 22:11:54 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f575Bkh02649 for ; Wed, 6 Jun 2001 22:11:46 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip33.idcomm.com [209.60.72.160]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f575KVU08332 for ; Wed, 6 Jun 2001 23:20:31 -0600 Message-ID: <3B1F0D31.3B7CCD1E@idcomm.com> Date: Wed, 06 Jun 2001 23:12:17 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: more aic7xxx Content-Type: multipart/mixed; boundary="------------E2933518D52FEF3360ECF256" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------E2933518D52FEF3360ECF256 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I realize that some earlier aic7xxx problem was solved, I'm trying to see what else might be the problem for a cvs from about an hour ago today (2.4.6-pre1). Config is attached, actual error pasted below. I am trying to compile aic7xxx in directly, since my whole system runs on it. I'm hoping this is some silly config issue, here is the "make bzImage" failure (I always run make mrproper and rerun make menuconfig and make dep each time): D. Stimits, stimits@idcomm.com make[2]: Leaving directory `/usr/src/linux-2.4.6-pre1-xfs/drivers/pnp' make -C scsi make[2]: Entering directory `/usr/src/linux-2.4.6-pre1-xfs/drivers/scsi' make -C aic7xxx make[3]: Entering directory `/usr/src/linux-2.4.6-pre1-xfs/drivers/scsi/aic7xxx' make all_targets make[4]: Entering directory `/usr/src/linux-2.4.6-pre1-xfs/drivers/scsi/aic7xxx' echo "Warning, generated aic7xxx firmware files may be out of date!\n" Warning, generated aic7xxx firmware files may be out of date!\n echo "Warning, generated aic7xxx firmware files may be out of date!\n" Warning, generated aic7xxx firmware files may be out of date!\n kgcc -D__KERNEL__ -I/usr/src/linux-2.4.6-pre1-xfs/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o aic7xxx_linux.o aic7xxx_linux.c In file included from aic7xxx_osm.h:343, from aic7xxx_linux.c:133: aic7xxx.h:40: aic7xxx_reg.h: No such file or directory aic7xxx_osm.h: In function `ahc_flush_device_writes': In file included from aic7xxx_linux.c:133: aic7xxx_osm.h:901: `INTSTAT' undeclared (first use in this function) aic7xxx_osm.h:901: (Each undeclared identifier is reported only once aic7xxx_osm.h:901: for each function it appears in.) aic7xxx_inline.h: In function `ahc_pause_bug_fix': In file included from aic7xxx_linux.c:134: aic7xxx_inline.h:57: `CCSCBCTL' undeclared (first use in this function) aic7xxx_inline.h: In function `ahc_is_paused': aic7xxx_inline.h:67: `HCNTRL' undeclared (first use in this function) aic7xxx_inline.h:67: `PAUSE' undeclared (first use in this function) aic7xxx_inline.h:68: warning: control reaches end of non-void function aic7xxx_inline.h: In function `ahc_pause': aic7xxx_inline.h:80: `HCNTRL' undeclared (first use in this function) aic7xxx_inline.h: In function `ahc_unpause': aic7xxx_inline.h:105: `INTSTAT' undeclared (first use in this function) aic7xxx_inline.h:105: `SCSIINT' undeclared (first use in this function) aic7xxx_inline.h:105: `SEQINT' undeclared (first use in this function) aic7xxx_inline.h:105: `BRKADRINT' undeclared (first use in this function) aic7xxx_inline.h:106: `HCNTRL' undeclared (first use in this function) aic7xxx_inline.h: In function `ahc_update_residual': aic7xxx_inline.h:220: `SG_RESID_VALID' undeclared (first use in this function) aic7xxx_inline.h: In function `ahc_queue_scb': aic7xxx_inline.h:337: `SCB_LIST_NULL' undeclared (first use in this function) aic7xxx_inline.h:346: `HNSCB_QOFF' undeclared (first use in this function) aic7xxx_inline.h:350: `KERNEL_QINPOS' undeclared (first use in this function) aic7xxx_inline.h: In function `ahc_check_cmdcmpltqueues': aic7xxx_inline.h:391: `SCB_LIST_NULL' undeclared (first use in this function) aic7xxx_inline.h: In function `ahc_intr': aic7xxx_inline.h:418: `CMDCMPLT' undeclared (first use in this function) aic7xxx_inline.h:420: `INTSTAT' undeclared (first use in this function) aic7xxx_inline.h:436: `ERROR' undeclared (first use in this function) aic7xxx_inline.h:436: `PCIERRSTAT' undeclared (first use in this function) aic7xxx_inline.h:445: `INT_PEND' undeclared (first use in this function) aic7xxx_inline.h:452: `CLRINT' undeclared (first use in this function) aic7xxx_inline.h:452: `CLRCMDINT' undeclared (first use in this function) aic7xxx_inline.h:472: `BRKADRINT' undeclared (first use in this function) aic7xxx_inline.h:478: `SEQINT' undeclared (first use in this function) aic7xxx_inline.h:478: `SCSIINT' undeclared (first use in this function) aic7xxx_linux.c: In function `ahc_print_path': aic7xxx_linux.c:288: `TWIN_CHNLB' undeclared (first use in this function) aic7xxx_linux.c:289: `TWIN_TID' undeclared (first use in this function) aic7xxx_linux.c:289: `TID' undeclared (first use in this function) aic7xxx_linux.c:289: `TID_SHIFT' undeclared (first use in this function) aic7xxx_linux.c: In function `ahc_platform_freeze_devq': aic7xxx_linux.c:1291: `TWIN_TID' undeclared (first use in this function) aic7xxx_linux.c:1291: `TID' undeclared (first use in this function) aic7xxx_linux.c:1291: `TID_SHIFT' undeclared (first use in this function) aic7xxx_linux.c:1292: `TWIN_CHNLB' undeclared (first use in this function) aic7xxx_linux.c:1293: `SCB_LIST_NULL' undeclared (first use in this function) aic7xxx_linux.c: In function `ahc_platform_abort_scbs': aic7xxx_linux.c:1352: `SCB_LIST_NULL' undeclared (first use in this function) aic7xxx_linux.c: In function `ahc_linux_run_device_queue': aic7xxx_linux.c:1576: `TID_SHIFT' undeclared (first use in this function) aic7xxx_linux.c:1576: `TID' undeclared (first use in this function) aic7xxx_linux.c:1576: `TWIN_CHNLB' undeclared (first use in this function) aic7xxx_linux.c:1578: `TWIN_TID' undeclared (first use in this function) aic7xxx_linux.c:1580: `OID' undeclared (first use in this function) aic7xxx_linux.c:1585: `ULTRAENB' undeclared (first use in this function) aic7xxx_linux.c:1588: `DISCENB' undeclared (first use in this function) aic7xxx_linux.c:1592: `MK_MESSAGE' undeclared (first use in this function) aic7xxx_linux.c:1642: `SG_FULL_RESID' undeclared (first use in this function) aic7xxx_linux.c:1689: `SG_LIST_NULL' undeclared (first use in this function) aic7xxx_linux.c:1707: `TARGET_SCB' undeclared (first use in this function) aic7xxx_linux.c:1707: `TAG_ENB' undeclared (first use in this function) aic7xxx_linux.c:1533: warning: `mask' might be used uninitialized in this function aic7xxx_linux.c:1710: warning: `target_offset' might be used uninitialized in this function aic7xxx_inline.h: In function `ahc_linux_isr': aic7xxx_inline.h:407: warning: `intstat' might be used uninitialized in this function aic7xxx_linux.c: In function `ahc_done': aic7xxx_linux.c:1961: `TWIN_TID' undeclared (first use in this function) aic7xxx_linux.c:1961: `TID' undeclared (first use in this function) aic7xxx_linux.c:1961: `TID_SHIFT' undeclared (first use in this function) aic7xxx_linux.c:1961: `TWIN_CHNLB' undeclared (first use in this function) aic7xxx_linux.c:1959: warning: `target_offset' might be used uninitialized in this function aic7xxx_linux.c: In function `ahc_linux_filter_command': aic7xxx_linux.c:2179: `TID_SHIFT' undeclared (first use in this function) aic7xxx_linux.c:2179: `TID' undeclared (first use in this function) aic7xxx_linux.c:2179: `TWIN_CHNLB' undeclared (first use in this function) aic7xxx_linux.c:2180: `OID' undeclared (first use in this function) aic7xxx_linux.c: In function `ahc_linux_queue_recovery_cmd': aic7xxx_linux.c:2406: `SCB_LIST_NULL' undeclared (first use in this function) aic7xxx_linux.c:2436: `INTSTAT' undeclared (first use in this function) aic7xxx_linux.c:2436: `INT_PEND' undeclared (first use in this function) aic7xxx_linux.c:2476: `LASTPHASE' undeclared (first use in this function) aic7xxx_linux.c:2477: `SCBPTR' undeclared (first use in this function) aic7xxx_linux.c:2478: `SCB_TAG' undeclared (first use in this function) aic7xxx_linux.c:2480: `P_BUSFREE' undeclared (first use in this function) aic7xxx_linux.c:2482: `SAVED_SCSIID' undeclared (first use in this function) aic7xxx_linux.c:2482: `TWIN_TID' undeclared (first use in this function) aic7xxx_linux.c:2482: `TID' undeclared (first use in this function) aic7xxx_linux.c:2482: `TID_SHIFT' undeclared (first use in this function) aic7xxx_linux.c:2490: `MSG_OUT' undeclared (first use in this function) aic7xxx_linux.c:2490: `HOST_MSG' undeclared (first use in this function) aic7xxx_linux.c:2491: `SCSISIGO' undeclared (first use in this function) aic7xxx_linux.c:2491: `ATNO' undeclared (first use in this function) aic7xxx_linux.c:2513: `MK_MESSAGE' undeclared (first use in this function) aic7xxx_linux.c:2513: `DISCONNECTED' undeclared (first use in this function) aic7xxx_linux.c:2538: `SCB_CONTROL' undeclared (first use in this function) aic7xxx_inline.h:407: warning: `intstat' might be used uninitialized in this function make[4]: *** [aic7xxx_linux.o] Error 1 make[4]: Leaving directory `/usr/src/linux-2.4.6-pre1-xfs/drivers/scsi/aic7xxx' make[3]: *** [first_rule] Error 2 make[3]: Leaving directory `/usr/src/linux-2.4.6-pre1-xfs/drivers/scsi/aic7xxx' make[2]: *** [_subdir_aic7xxx] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.6-pre1-xfs/drivers/scsi' make[1]: *** [_subdir_scsi] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.6-pre1-xfs/drivers' make: *** [_dir_drivers] Error 2 --------------E2933518D52FEF3360ECF256 Content-Type: text/plain; charset=us-ascii; name=".config" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=".config" # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # 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_MPENTIUMIII=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 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_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y 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_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # CONFIG_PM is not set # CONFIG_ACPI is not set # CONFIG_APM 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_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=y # CONFIG_ISAPNP 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 is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_NETLINK=y CONFIG_RTNETLINK=y # CONFIG_NETLINK_DEV is not set CONFIG_NETFILTER=y CONFIG_NETFILTER_DEBUG=y # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m # CONFIG_NET_IPGRE_BROADCAST is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set CONFIG_SYN_COOKIES=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_FTP=y CONFIG_IP_NF_QUEUE=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_LIMIT=y CONFIG_IP_NF_MATCH_MAC=y CONFIG_IP_NF_MATCH_MARK=y CONFIG_IP_NF_MATCH_MULTIPORT=y CONFIG_IP_NF_MATCH_TOS=y CONFIG_IP_NF_MATCH_TCPMSS=y CONFIG_IP_NF_MATCH_STATE=y CONFIG_IP_NF_MATCH_UNCLEAN=y CONFIG_IP_NF_MATCH_OWNER=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_TARGET_MIRROR=y CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_IP_NF_TARGET_REDIRECT=y CONFIG_IP_NF_NAT_FTP=y CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_TARGET_TOS=y CONFIG_IP_NF_TARGET_MARK=y CONFIG_IP_NF_TARGET_LOG=y CONFIG_IP_NF_TARGET_TCPMSS=y # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC 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=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_CSZ=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_POLICE=y # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set # CONFIG_BLK_DEV_IDEDISK_IBM is not set # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set # CONFIG_BLK_DEV_IDEDISK_WD is not set # CONFIG_BLK_DEV_COMMERIAL is not set # CONFIG_BLK_DEV_TIVO is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_AEC62XX_TUNING is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_WDC_ALI15X3 is not set # CONFIG_BLK_DEV_AMD7409 is not set # CONFIG_AMD7409_OVERRIDE is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_HPT34X_AUTODMA is not set # CONFIG_BLK_DEV_HPT366 is not set CONFIG_BLK_DEV_PIIX=y CONFIG_PIIX_TUNING=y # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_PDC202XX is not set # CONFIG_PDC202XX_BURST is not set # CONFIG_BLK_DEV_OSB4 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_IDEDMA_AUTO=y # CONFIG_IDEDMA_IVB is not set # CONFIG_DMA_NONPCI is not set CONFIG_BLK_DEV_IDE_MODES=y # # SCSI support # CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SD_EXTRA_DEVS=40 # 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 is not set # CONFIG_SCSI_DEBUG_QUEUES is not set # CONFIG_SCSI_MULTI_LUN is not set CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # # 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_AHA1740 is not set CONFIG_SCSI_AIC7XXX=y CONFIG_AIC7XXX_CMDS_PER_DEVICE=48 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 # CONFIG_AIC7XXX_BUILD_FIRMWARE 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_DMA 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_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_NCR53C7xx is not set # CONFIG_SCSI_NCR53C8XX 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_SIM710 is not set # CONFIG_SCSI_SYM53C416 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_DEBUG is not set # # IEEE 1394 (FireWire) support # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # CONFIG_I2O_PCI is not set # CONFIG_I2O_BLOCK is not set # CONFIG_I2O_LAN is not set # CONFIG_I2O_SCSI is not set # CONFIG_I2O_PROC is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_ETHERTAP is not set # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL 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_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_CS89x0 is not set # CONFIG_TULIP is not set # CONFIG_DE4X5 is not set # CONFIG_DGRS is not set # CONFIG_DM9102 is not set CONFIG_EEPRO100=y # CONFIG_EEPRO100_PM is not set # CONFIG_LNE390 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_NE3210 is not set # CONFIG_ES3210 is not set # CONFIG_8139TOO is not set # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 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_WINBOND_840 is not set # CONFIG_HAPPYMEAL is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_SK98LIN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=m # CONFIG_PPP_MULTILINK is not set # CONFIG_PPP_FILTER is not set CONFIG_PPP_ASYNC=m # CONFIG_PPP_SYNC_TTY is not set CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m # CONFIG_PPPOE is not set CONFIG_SLIP=m CONFIG_SLIP_COMPRESSED=y # CONFIG_SLIP_SMART is not set # CONFIG_SLIP_MODE_SLIP6 is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set CONFIG_SHAPER=m # # 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 is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Input core support # CONFIG_INPUT=y # CONFIG_INPUT_KEYBDEV is not set CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1600 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1280 CONFIG_INPUT_JOYDEV=m # CONFIG_INPUT_EVDEV is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y # CONFIG_SERIAL_CONSOLE is not set # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set CONFIG_PPDEV=m # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set CONFIG_MOUSE=y CONFIG_PSMOUSE=y # CONFIG_82C710_MOUSE is not set # CONFIG_PC110_PAD is not set # # Joysticks # CONFIG_JOYSTICK=y # CONFIG_INPUT_NS558 is not set # CONFIG_INPUT_LIGHTNING is not set # CONFIG_INPUT_PCIGAME is not set # CONFIG_INPUT_CS461X is not set CONFIG_INPUT_ANALOG=m # CONFIG_INPUT_A3D is not set CONFIG_INPUT_ADI=m # CONFIG_INPUT_COBRA is not set # CONFIG_INPUT_GF2K is not set # CONFIG_INPUT_GRIP is not set # CONFIG_INPUT_INTERACT is not set # CONFIG_INPUT_TMDC is not set # CONFIG_INPUT_SIDEWINDER is not set # CONFIG_INPUT_SERPORT is not set # CONFIG_INPUT_WARRIOR is not set # CONFIG_INPUT_MAGELLAN is not set # CONFIG_INPUT_SPACEORB is not set # CONFIG_INPUT_SPACEBALL is not set # CONFIG_INPUT_STINGER is not set # CONFIG_INPUT_IFORCE_232 is not set # CONFIG_INPUT_IFORCE_USB is not set # CONFIG_INPUT_DB9 is not set # CONFIG_INPUT_GAMECON is not set # CONFIG_INPUT_TURBOGRAFX is not set # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set CONFIG_INTEL_RNG=y # CONFIG_NVRAM is not set CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=m CONFIG_AGP_INTEL=y # CONFIG_AGP_I810 is not set # CONFIG_AGP_VIA is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_ALI is not set CONFIG_DRM=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_GAMMA is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set # CONFIG_DRM_I810 is not set # CONFIG_DRM_MGA is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # CONFIG_QUOTA=y # CONFIG_FS_POSIX_ACL is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y # CONFIG_UMSDOS_FS is not set CONFIG_VFAT_FS=y # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_CRAMFS is not set CONFIG_TMPFS=y # CONFIG_RAMFS is not set CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_MINIX_FS=y # CONFIG_VXFS_FS is not set CONFIG_NTFS_FS=y # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_SYSV_FS_WRITE is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set CONFIG_PAGE_BUF=y CONFIG_XFS_FS=y CONFIG_HAVE_ATTRCTL=y # CONFIG_XFS_DMAPI is not set CONFIG_XFS_QUOTA=y # # Network File Systems # CONFIG_CODA_FS=m CONFIG_NFS_FS=m CONFIG_NFS_V3=y # CONFIG_ROOT_NFS is not set CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_SUNRPC=m CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y # CONFIG_BSD_DISKLABEL is not set # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set CONFIG_SGI_PARTITION=y # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set CONFIG_SMB_NLS=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y # 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_1251 is not set CONFIG_NLS_ISO8859_1=y # 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 # # Console drivers # CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y # CONFIG_MDA_CONSOLE is not set # # Frame-buffer support # # CONFIG_FB is not set # # Sound # CONFIG_SOUND=m # CONFIG_SOUND_CMPCI is not set CONFIG_SOUND_EMU10K1=m # CONFIG_SOUND_FUSION is not set # CONFIG_SOUND_CS4281 is not set # CONFIG_SOUND_ES1370 is not set # CONFIG_SOUND_ES1371 is not set # CONFIG_SOUND_ESSSOLO1 is not set # CONFIG_SOUND_MAESTRO is not set # CONFIG_SOUND_MAESTRO3 is not set # CONFIG_SOUND_ICH is not set # CONFIG_SOUND_SONICVIBES is not set # CONFIG_SOUND_TRIDENT is not set # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set # CONFIG_SOUND_VIA82CXXX is not set # CONFIG_SOUND_OSS is not set # CONFIG_SOUND_TVMIXER is not set # # USB support # CONFIG_USB=y # CONFIG_USB_DEBUG is not set # CONFIG_USB_DEVICEFS is not set # CONFIG_USB_BANDWIDTH is not set CONFIG_USB_UHCI_ALT=y # CONFIG_USB_OHCI is not set # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH is not set # CONFIG_USB_STORAGE is not set # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set # CONFIG_USB_HID is not set # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_DC2XX is not set # CONFIG_USB_MDC800 is not set # CONFIG_USB_SCANNER is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_PWC is not set # CONFIG_USB_DSBR is not set # CONFIG_USB_DABUSB is not set # CONFIG_USB_PLUSB is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_NET1080 is not set # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # CONFIG_USB_RIO500 is not set # # Kernel hacking # CONFIG_MAGIC_SYSRQ=y # CONFIG_KDB is not set # CONFIG_KALLSYMS is not set # CONFIG_FRAME_POINTER is not set --------------E2933518D52FEF3360ECF256-- From owner-linux-xfs@oss.sgi.com Wed Jun 6 22:19:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f575JVD03750 for linux-xfs-outgoing; Wed, 6 Jun 2001 22:19:31 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f575JUh03747 for ; Wed, 6 Jun 2001 22:19:30 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id WAA02525 for ; Wed, 6 Jun 2001 22:19:22 -0700 (PDT) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA23976; Thu, 7 Jun 2001 15:18:07 +1000 Received: from clouds.melbourne.sgi.com (localhost [127.0.0.1]) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA06648; Thu, 7 Jun 2001 15:18:01 +1000 (EST) Message-Id: <200106070518.PAA06648@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: stimits@idcomm.com cc: linux-xfs@oss.sgi.com Subject: Re: more aic7xxx In-reply-to: Your message of "Wed, 06 Jun 2001 23:12:17 CST." <3B1F0D31.3B7CCD1E@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Jun 2001 15:18:01 +1000 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "D. Stimits" writes: => This is a multi-part message in MIME format. => --------------E2933518D52FEF3360ECF256 => Content-Type: text/plain; charset=us-ascii => Content-Transfer-Encoding: 7bit => => I realize that some earlier aic7xxx problem was solved, I'm trying to => see what else might be the problem for a cvs from about an hour ago => today (2.4.6-pre1). Config is attached, actual error pasted below. I am => trying to compile aic7xxx in directly, since my whole system runs on it. => I'm hoping this is some silly config issue, here is the "make bzImage" => failure (I always run make mrproper and rerun make menuconfig and make => dep each time): => D. Stimits, stimits@idcomm.com "make oldconfig" and make sure that CONFIG_AIC7XXX_BUILD_FIRMWARE is turned on - I think it was broken in 2.4.5, less sure about 2.4.6-pre1. Here's the extract from my config: CONFIG_SCSI_AIC7XXX=y CONFIG_AIC7XXX_CMDS_PER_DEVICE=8 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 CONFIG_AIC7XXX_BUILD_FIRMWARE=y CONFIG_SCSI_ADVANSYS=y ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Jun 6 23:36:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f576aOM11827 for linux-xfs-outgoing; Wed, 6 Jun 2001 23:36:24 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f576aMh11820 for ; Wed, 6 Jun 2001 23:36:23 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip33.idcomm.com [209.60.72.160]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f576jCU17174 for ; Thu, 7 Jun 2001 00:45:12 -0600 Message-ID: <3B1F210A.18F67BE9@idcomm.com> Date: Thu, 07 Jun 2001 00:36:58 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: more aic7xxx References: <200106070518.PAA06648@clouds.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sorry if this shows up twice, I'm not sure if the first reply made it in or not. Daniel Moore wrote: > > "D. Stimits" writes: > => This is a multi-part message in MIME format. > => --------------E2933518D52FEF3360ECF256 > => Content-Type: text/plain; charset=us-ascii > => Content-Transfer-Encoding: 7bit > => > => I realize that some earlier aic7xxx problem was solved, I'm trying to > => see what else might be the problem for a cvs from about an hour ago > => today (2.4.6-pre1). Config is attached, actual error pasted below. I am > => trying to compile aic7xxx in directly, since my whole system runs on it. > => I'm hoping this is some silly config issue, here is the "make bzImage" > => failure (I always run make mrproper and rerun make menuconfig and make > => dep each time): > => D. Stimits, stimits@idcomm.com > > "make oldconfig" and make sure that CONFIG_AIC7XXX_BUILD_FIRMWARE is > turned on - I think it was broken in 2.4.5, less sure about 2.4.6-pre1. I thought I was the only one that found "make menuconfig" broken in the 2.4.5 cvs. I had a lame theory about stale files keeping prior users from finding it broken. > > Here's the extract from my config: > > CONFIG_SCSI_AIC7XXX=y > CONFIG_AIC7XXX_CMDS_PER_DEVICE=8 On stock and ac series 2.4.5 kernels I see the device lock at 48 in the queue. Is 8 related to XFS changes? > CONFIG_AIC7XXX_RESET_DELAY_MS=15000 > CONFIG_AIC7XXX_BUILD_FIRMWARE=y This firmware delay is probably my problem, with just this change it compiles (I still need to install and test things). There is no help in the menu on it, I'm curious what it does? > CONFIG_SCSI_ADVANSYS=y My hardware is strictly integrated Adaptec. Should this matter in my case? > > ----------------------------------------------------- > Daniel Moore dxm@sgi.com > R&D Software Engineer Phone: +61-3-98348209 > SGI Performance Tools Group Fax: +61-3-98132378 > ----------------------------------------------------- FYI, now that it compiles, I see: warning: kernel is too big for standalone boot from floppy Is this strictly from too many non-module items, not necessarily XFS, or will compiling XFS directly in (no use of initial ramdisk) be enough to cause this? I saw the FAQ on needing to make the lilo initial ramdisk size as 25000 (rather than its usual 4096 or whatever the default is), which is obviously bigger than regular kernels. Do most people here with x86 intend to make a backup based on a CDROM ISO instead of floppy? Or is it reasonable to rearrange modules such that floppies become practical? D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Wed Jun 6 23:56:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f576uNx19359 for linux-xfs-outgoing; Wed, 6 Jun 2001 23:56:23 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f576uMh19355 for ; Wed, 6 Jun 2001 23:56:22 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id XAA01812 for ; Wed, 6 Jun 2001 23:56:31 -0700 (PDT) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA24560; Thu, 7 Jun 2001 16:54:58 +1000 Received: from clouds.melbourne.sgi.com (localhost [127.0.0.1]) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id QAA98342; Thu, 7 Jun 2001 16:54:56 +1000 (EST) Message-Id: <200106070654.QAA98342@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: stimits@idcomm.com Subject: Re: more aic7xxx In-reply-to: Your message of "Wed, 06 Jun 2001 23:59:56 CST." <3B1F185C.4E6BE983@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: linux-xfs@oss.sgi.com Date: Thu, 07 Jun 2001 16:54:56 +1000 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "D. Stimits" writes: => On stock and ac series 2.4.5 kernels I see the device lock at 48 in the => queue. Is 8 related to XFS changes? No - the example was for illustration only. => => > CONFIG_AIC7XXX_RESET_DELAY_MS=15000 => > CONFIG_AIC7XXX_BUILD_FIRMWARE=y => => This firmware delay is probably my problem, with just this change it => compiles (I still need to install and test things). There is no help in => the menu on it, I'm curious what it does? => => > CONFIG_SCSI_ADVANSYS=y => => My hardware is strictly integrated Adaptec. Should this matter in my => case? Aparently that's for our tapedrive. ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Jun 7 01:40:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f578eEr31816 for linux-xfs-outgoing; Thu, 7 Jun 2001 01:40:14 -0700 Received: from saturn.gjw.net (IDENT:qmailr@gateway.wildman.co.za [196.15.241.74]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f578eAh31813 for ; Thu, 7 Jun 2001 01:40:11 -0700 Received: (qmail 4649 invoked from network); 7 Jun 2001 08:19:51 -0000 Received: from charon.gjw.net (gregw@192.168.0.101) by saturn.gjw.net with SMTP; 7 Jun 2001 08:19:51 -0000 Subject: Re: Red Hat 7.1 and quotas From: Greg Wildman To: "P.Dixon" Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain X-Mailer: Evolution/0.10 (Preview Release) Date: 07 Jun 2001 10:19:51 +0200 Message-Id: <991901991.17518.13.camel@charon.gjw.net> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 06 Jun 2001 11:23:45 +0100, P.Dixon wrote: > Hi, > > I've just upgraded to Red Hat 7.1 from Red Hat 6.2 and have all my file > systems using xfs. Unfortunately, I can no longer get quota running: > > [root@hepserv /root]# quotaon /export/users > quotaon: /dev/sdb1: Invalid argument > quotaon: /dev/sdb1: Invalid argument > > Does the kernel that is installed by the SGI XFS 1.0 Red Hat 7.1 CD have > quota support enabled? Perhaps there is something obvious that I am not > doing...? > > Cheerio, > Paul There were a few problems running quotas using the SGI RedHat 7.1 iso. There is a patch for the kernel at http://linux-xfs.sgi.com/projects/xfs/mail_archive/0105/msg00246.html and a patch for the repquota command at http://linux-xfs.sgi.com/projects/xfs/mail_archive/0105/msg00252.html I have recompiled both SRPMS with the patches added and all is working great. I won't post the patches and spec file here as they are quite large, but drop me a note if you want me to make them available for download. -- Greg Kent's Heuristic: Look for it first where you'd most like to find it. From owner-linux-xfs@oss.sgi.com Thu Jun 7 03:17:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57AHKU09732 for linux-xfs-outgoing; Thu, 7 Jun 2001 03:17:20 -0700 Received: from ifi.informatik.uni-stuttgart.de (ifi.informatik.uni-stuttgart.de [129.69.211.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57AHIh09728 for ; Thu, 7 Jun 2001 03:17:18 -0700 Received: from bebop.informatik.uni-stuttgart.de (bebop [129.69.215.68]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id MAA21418; Thu, 7 Jun 2001 12:17:02 +0200 (MET DST) Received: from techno.informatik.uni-stuttgart.de (magallon@techno.informatik.uni-stuttgart.de [129.69.218.24]) by bebop.informatik.uni-stuttgart.de (8.11.0/2.2) with SMTP id f57AHFU08483; Thu, 7 Jun 2001 12:17:15 +0200 Received: by techno.informatik.uni-stuttgart.de (sSMTP sendmail emulation); Thu, 7 Jun 2001 12:17:15 +0200 Date: Thu, 7 Jun 2001 12:17:15 +0200 From: "Marcelo E. Magallon" To: Mark Pinto Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.6-pre1 Message-ID: <20010607121715.A2926@informatik.uni-stuttgart.de> Mail-Followup-To: "Marcelo E. Magallon" , Mark Pinto , linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i X-Operating-System: Linux techno 2.4.5-ac8 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> Mark Pinto writes: > I have searched the linux kernel mailing list, and didnt see anything > related to this problem. Try this: http://www.cs.helsinki.fi/linux/linux-kernel/2001-22/0237.html -- Marcelo From owner-linux-xfs@oss.sgi.com Thu Jun 7 04:25:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57BPJ619958 for linux-xfs-outgoing; Thu, 7 Jun 2001 04:25:19 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57BPFh19944 for ; Thu, 7 Jun 2001 04:25:15 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id NAA13232 for ; Thu, 7 Jun 2001 13:25:14 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id NAA01310 for linux-xfs@oss.sgi.com; Thu, 7 Jun 2001 13:25:13 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 0469257306 for ; Thu, 7 Jun 2001 13:34:12 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id D8DAB25835 for ; Thu, 7 Jun 2001 13:34:41 +0200 (CEST) Message-ID: <3B1F6564.EC904DF4@ch.sauter-bc.com> Date: Thu, 07 Jun 2001 13:28:36 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: linux-xfs Subject: Segmentation faults on i820 (Camino) chipset Content-Type: multipart/mixed; boundary="------------DD81C98F4F8AD0FAC2FDB998" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dies ist eine mehrteilige Nachricht im MIME-Format. --------------DD81C98F4F8AD0FAC2FDB998 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi everybody, I'm using XFS since 1.0 and it has worked perfectly everywhere. I used it on top of MD Raid5 and on LVM on top of MD Raid5. But now I came across a problem and I don't know how to solve it. I installed RH7.1-XFS on a new DELL Precision 220 Workstation, one PIII 933, 256M RDRAM, Intel Pro/100 ethernet. I removed the CDROM and installed 4 IBM IC35L060AVER07 60G HD's. The onboard Sound and USB is disabled. The chipset is i820 (Camino). Initial install went fine, using 180GB MD Raid5. Then I tired to update some RPM's and rpm segfaulted. Later after a reboot, it went fine. The next reboot I saw some messages that /sbin/mkkerneldoth segfaulted, another reboot went fine. I started to play with the noapic and pci=xxx options but no result. 1 of 5 times I boot the system, it doesn't work properly and many applications segfault. beside that everything seems okay. Any idea what I can do? Thanks Simon -- 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] --------------DD81C98F4F8AD0FAC2FDB998 Content-Type: application/octet-stream; name="dmesg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg" MDAwMDUwMDAwMCBAIDAwMDAwMDAwZmZiMDAwMDAgKHJlc2VydmVkKQogQklPUy1lODIwOiAw MDAwMDAwMDAwMDEwMDAwIEAgMDAwMDAwMDBmZWMwMDAwMCAocmVzZXJ2ZWQpCiBCSU9TLWU4 MjA6IDAwMDAwMDAwMDAwMTAwMDAgQCAwMDAwMDAwMGZlZTAwMDAwIChyZXNlcnZlZCkKT24g bm9kZSAwIHRvdGFscGFnZXM6IDY1NDM4CnpvbmUoMCk6IDQwOTYgcGFnZXMuCnpvbmUgRE1B IGhhcyBtYXggMzIgY2FjaGVkIHBhZ2VzLgp6b25lKDEpOiA2MTM0MiBwYWdlcy4Kem9uZSBO b3JtYWwgaGFzIG1heCA0NzkgY2FjaGVkIHBhZ2VzLgp6b25lKDIpOiAwIHBhZ2VzLgp6b25l IEhpZ2hNZW0gaGFzIG1heCAxIGNhY2hlZCBwYWdlcy4KaG0sIHBhZ2UgMDEwMDAwMDAgcmVz ZXJ2ZWQgdHdpY2UuCktlcm5lbCBjb21tYW5kIGxpbmU6IGF1dG8gQk9PVF9JTUFHRT1saW51 eCBybyByb290PTkwMCBCT09UX0ZJTEU9L2Jvb3Qvdm1saW51ei0yLjQuMi1TR0lfWEZTXzEu MCByYW1kaXNrX3NpemU9MjUwMCBub2FwaWMKSW5pdGlhbGl6aW5nIENQVSMwCkRldGVjdGVk IDkzMC45NzcgTUh6IHByb2Nlc3Nvci4KQ29uc29sZTogY29sb3VyIFZHQSsgODB4MjUKQ2Fs aWJyYXRpbmcgZGVsYXkgbG9vcC4uLiAxODU0LjY2IEJvZ29NSVBTCk1lbW9yeTogMjU0MTM2 ay8yNjE3NTJrIGF2YWlsYWJsZSAoMTkyNGsga2VybmVsIGNvZGUsIDcyMzJrIHJlc2VydmVk LCA5NmsgZGF0YSwgMjIwayBpbml0LCAwayBoaWdobWVtKQpEZW50cnktY2FjaGUgaGFzaCB0 YWJsZSBlbnRyaWVzOiAzMjc2OCAob3JkZXI6IDYsIDI2MjE0NCBieXRlcykKQnVmZmVyLWNh Y2hlIGhhc2ggdGFibGUgZW50cmllczogMTYzODQgKG9yZGVyOiA0LCA2NTUzNiBieXRlcykK UGFnZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDY1NTM2IChvcmRlcjogNywgNTI0Mjg4 IGJ5dGVzKQpJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDE2Mzg0IChvcmRlcjog NSwgMTMxMDcyIGJ5dGVzKQpWRlM6IERpc2txdW90YXMgdmVyc2lvbiBkcXVvdF82LjUuMCBp bml0aWFsaXplZApDUFU6IEJlZm9yZSB2ZW5kb3IgaW5pdCwgY2FwczogMDM4M2ZiZmYgMDAw MDAwMDAgMDAwMDAwMDAsIHZlbmRvciA9IDAKQ1BVOiBMMSBJIGNhY2hlOiAxNkssIEwxIEQg Y2FjaGU6IDE2SwpDUFU6IEwyIGNhY2hlOiAyNTZLCkludGVsIG1hY2hpbmUgY2hlY2sgYXJj aGl0ZWN0dXJlIHN1cHBvcnRlZC4KSW50ZWwgbWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5h YmxlZCBvbiBDUFUjMC4KQ1BVOiBBZnRlciB2ZW5kb3IgaW5pdCwgY2FwczogMDM4M2ZiZmYg MDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAKQ1BVOiBBZnRlciBnZW5lcmljLCBjYXBzOiAw MzgzZmJmZiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMApDUFU6IENvbW1vbiBjYXBzOiAw MzgzZmJmZiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMApDUFU6IEludGVsIFBlbnRpdW0g SUlJIChDb3BwZXJtaW5lKSBzdGVwcGluZyAwNgpFbmFibGluZyBmYXN0IEZQVSBzYXZlIGFu ZCByZXN0b3JlLi4uIGRvbmUuCkVuYWJsaW5nIHVubWFza2VkIFNJTUQgRlBVIGV4Y2VwdGlv biBzdXBwb3J0Li4uIGRvbmUuCkNoZWNraW5nICdobHQnIGluc3RydWN0aW9uLi4uIE9LLgpQ T1NJWCBjb25mb3JtYW5jZSB0ZXN0aW5nIGJ5IFVOSUZJWAptdHJyOiB2MS4zNyAoMjAwMDEx MDkpIFJpY2hhcmQgR29vY2ggKHJnb29jaEBhdG5mLmNzaXJvLmF1KQptdHJyOiBkZXRlY3Rl ZCBtdHJyIHR5cGU6IEludGVsClBDSTogUENJIEJJT1MgcmV2aXNpb24gMi4xMCBlbnRyeSBh dCAweGZjMDVlLCBsYXN0IGJ1cz0yClBDSTogVXNpbmcgY29uZmlndXJhdGlvbiB0eXBlIDEK UENJOiBQcm9iaW5nIFBDSSBoYXJkd2FyZQpVbmtub3duIGJyaWRnZSByZXNvdXJjZSAwOiBh c3N1bWluZyB0cmFuc3BhcmVudApVbmtub3duIGJyaWRnZSByZXNvdXJjZSAyOiBhc3N1bWlu ZyB0cmFuc3BhcmVudApQQ0k6IFVzaW5nIElSUSByb3V0ZXIgUElJWCBbODA4Ni8yNDEwXSBh dCAwMDoxZi4wCmlzYXBucDogU2Nhbm5pbmcgZm9yIFBuUCBjYXJkcy4uLgppc2FwbnA6IE5v IFBsdWcgJiBQbGF5IGRldmljZSBmb3VuZApMaW51eCBORVQ0LjAgZm9yIExpbnV4IDIuNApC YXNlZCB1cG9uIFN3YW5zZWEgVW5pdmVyc2l0eSBDb21wdXRlciBTb2NpZXR5IE5FVDMuMDM5 CkluaXRpYWxpemluZyBSVCBuZXRsaW5rIHNvY2tldAphcG06IEJJT1MgdmVyc2lvbiAxLjIg RmxhZ3MgMHgwMyAoRHJpdmVyIHZlcnNpb24gMS4xNCkKU3RhcnRpbmcga3N3YXBkIHYxLjgK cHR5OiAyNTYgVW5peDk4IHB0eXMgY29uZmlndXJlZApibG9jazogcXVldWVkIHNlY3RvcnMg bWF4L2xvdyAxNjg2NTNrQi81NjIxN2tCLCA1MTIgc2xvdHMgcGVyIHF1ZXVlClJBTURJU0sg ZHJpdmVyIGluaXRpYWxpemVkOiAxNiBSQU0gZGlza3Mgb2YgMjUwMEsgc2l6ZSAxMDI0IGJs b2Nrc2l6ZQpVbmlmb3JtIE11bHRpLVBsYXRmb3JtIEUtSURFIGRyaXZlciBSZXZpc2lvbjog Ni4zMQppZGU6IEFzc3VtaW5nIDMzTUh6IHN5c3RlbSBidXMgc3BlZWQgZm9yIFBJTyBtb2Rl czsgb3ZlcnJpZGUgd2l0aCBpZGVidXM9eHgKUElJWDQ6IElERSBjb250cm9sbGVyIG9uIFBD SSBidXMgMDAgZGV2IGY5ClBJSVg0OiBjaGlwc2V0IHJldmlzaW9uIDIKUElJWDQ6IG5vdCAx MDAlIG5hdGl2ZSBtb2RlOiB3aWxsIHByb2JlIGlycXMgbGF0ZXIKICAgIGlkZTA6IEJNLURN QSBhdCAweGZmYTAtMHhmZmE3LCBCSU9TIHNldHRpbmdzOiBoZGE6RE1BLCBoZGI6RE1BCiAg ICBpZGUxOiBCTS1ETUEgYXQgMHhmZmE4LTB4ZmZhZiwgQklPUyBzZXR0aW5nczogaGRjOkRN QSwgaGRkOkRNQQpoZGE6IElDMzVMMDYwQVZFUjA3LTAsIEFUQSBESVNLIGRyaXZlCmhkYjog SUMzNUwwNjBBVkVSMDctMCwgQVRBIERJU0sgZHJpdmUKaGRjOiBJQzM1TDA2MEFWRVIwNy0w LCBBVEEgRElTSyBkcml2ZQpoZGQ6IElDMzVMMDYwQVZFUjA3LTAsIEFUQSBESVNLIGRyaXZl CmlkZTAgYXQgMHgxZjAtMHgxZjcsMHgzZjYgb24gaXJxIDE0CmlkZTEgYXQgMHgxNzAtMHgx NzcsMHgzNzYgb24gaXJxIDE1CmhkYTogMTIwMTAzMjAwIHNlY3RvcnMgKDYxNDkzIE1CKSB3 LzE5MTZLaUIgQ2FjaGUsIENIUz03NDc2LzI1NS82MywgVURNQSg2NikKaGRiOiAxMjAxMDMy MDAgc2VjdG9ycyAoNjE0OTMgTUIpIHcvMTkxNktpQiBDYWNoZSwgQ0hTPTc0NzYvMjU1LzYz LCBVRE1BKDY2KQpoZGM6IDEyMDEwMzIwMCBzZWN0b3JzICg2MTQ5MyBNQikgdy8xOTE2S2lC IENhY2hlLCBDSFM9MTE5MTUwLzE2LzYzLCBVRE1BKDY2KQpoZGQ6IDEyMDEwMzIwMCBzZWN0 b3JzICg2MTQ5MyBNQikgdy8xOTE2S2lCIENhY2hlLCBDSFM9MTE5MTUwLzE2LzYzLCBVRE1B KDY2KQpQYXJ0aXRpb24gY2hlY2s6CiAvZGV2L2lkZS9ob3N0MC9idXMwL3RhcmdldDAvbHVu MDogcDEgcDIKIC9kZXYvaWRlL2hvc3QwL2J1czAvdGFyZ2V0MS9sdW4wOiBwMSBwMgogL2Rl di9pZGUvaG9zdDAvYnVzMS90YXJnZXQwL2x1bjA6IHAxIHAyCiAvZGV2L2lkZS9ob3N0MC9i dXMxL3RhcmdldDEvbHVuMDogcDEgcDIKRmxvcHB5IGRyaXZlKHMpOiBmZDAgaXMgMS40NE0K RkRDIDAgaXMgYSBOYXRpb25hbCBTZW1pY29uZHVjdG9yIFBDODczMDYKUkFNRElTSzogQ29t cHJlc3NlZCBpbWFnZSBmb3VuZCBhdCBibG9jayAwCkZyZWVpbmcgaW5pdHJkIG1lbW9yeTog MjY5ayBmcmVlZApTZXJpYWwgZHJpdmVyIHZlcnNpb24gNS4wMiAoMjAwMC0wOC0wOSkgd2l0 aCBNQU5ZX1BPUlRTIE1VTFRJUE9SVCBTSEFSRV9JUlEgU0VSSUFMX1BDSSBJU0FQTlAgZW5h YmxlZAp0dHlTMDAgYXQgMHgwM2Y4IChpcnEgPSA0KSBpcyBhIDE2NTUwQQp0dHlTMDEgYXQg MHgwMmY4IChpcnEgPSAzKSBpcyBhIDE2NTUwQQpSZWFsIFRpbWUgQ2xvY2sgRHJpdmVyIHYx LjEwZAptZCBkcml2ZXIgMC45MC4wIE1BWF9NRF9ERVZTPTI1NiwgTURfU0JfRElTS1M9MjcK bWQuYzogc2l6ZW9mKG1kcF9zdXBlcl90KSA9IDQwOTYKYXV0b2RldGVjdGluZyBSQUlEIGFy cmF5cwoocmVhZCkgaWRlL2hvc3QwL2J1czAvdGFyZ2V0MC9sdW4wL3BhcnQxJ3Mgc2Igb2Zm c2V0OiAxMDI4MDMyIFtldmVudHM6IDAwMDAwMDU3XQoocmVhZCkgaWRlL2hvc3QwL2J1czAv dGFyZ2V0MC9sdW4wL3BhcnQyJ3Mgc2Igb2Zmc2V0OiA1OTAyMjcyMCBbZXZlbnRzOiAwMDAw MDA1N10KKHJlYWQpIGlkZS9ob3N0MC9idXMwL3RhcmdldDEvbHVuMC9wYXJ0MSdzIHNiIG9m ZnNldDogMTAyODAzMiBbZXZlbnRzOiAwMDAwMDA1N10KKHJlYWQpIGlkZS9ob3N0MC9idXMw L3RhcmdldDEvbHVuMC9wYXJ0MidzIHNiIG9mZnNldDogNTkwMjI3MjAgW2V2ZW50czogMDAw MDAwNTddCihyZWFkKSBpZGUvaG9zdDAvYnVzMS90YXJnZXQwL2x1bjAvcGFydDIncyBzYiBv ZmZzZXQ6IDU5MDI3MzkyIFtldmVudHM6IDAwMDAwMDU3XQoocmVhZCkgaWRlL2hvc3QwL2J1 czEvdGFyZ2V0MS9sdW4wL3BhcnQyJ3Mgc2Igb2Zmc2V0OiA1OTAyNzM5MiBbZXZlbnRzOiAw MDAwMDA1N10KYXV0b3J1biAuLi4KY29uc2lkZXJpbmcgaWRlL2hvc3QwL2J1czEvdGFyZ2V0 MS9sdW4wL3BhcnQyIC4uLgogIGFkZGluZyBpZGUvaG9zdDAvYnVzMS90YXJnZXQxL2x1bjAv cGFydDIgLi4uCiAgYWRkaW5nIGlkZS9ob3N0MC9idXMxL3RhcmdldDAvbHVuMC9wYXJ0MiAu Li4KICBhZGRpbmcgaWRlL2hvc3QwL2J1czAvdGFyZ2V0MS9sdW4wL3BhcnQyIC4uLgogIGFk ZGluZyBpZGUvaG9zdDAvYnVzMC90YXJnZXQwL2x1bjAvcGFydDIgLi4uCmNyZWF0ZWQgbWQx CmJpbmQ8aWRlL2hvc3QwL2J1czAvdGFyZ2V0MC9sdW4wL3BhcnQyLDE+CmJpbmQ8aWRlL2hv c3QwL2J1czAvdGFyZ2V0MS9sdW4wL3BhcnQyLDI+CmJpbmQ8aWRlL2hvc3QwL2J1czEvdGFy Z2V0MC9sdW4wL3BhcnQyLDM+CmJpbmQ8aWRlL2hvc3QwL2J1czEvdGFyZ2V0MS9sdW4wL3Bh cnQyLDQ+CnJ1bm5pbmc6IDxpZGUvaG9zdDAvYnVzMS90YXJnZXQxL2x1bjAvcGFydDI+PGlk ZS9ob3N0MC9idXMxL3RhcmdldDAvbHVuMC9wYXJ0Mj48aWRlL2hvc3QwL2J1czAvdGFyZ2V0 MS9sdW4wL3BhcnQyPjxpZGUvaG9zdDAvYnVzMC90YXJnZXQwL2x1bjAvcGFydDI+CmlkZS9o b3N0MC9idXMxL3RhcmdldDEvbHVuMC9wYXJ0MidzIGV2ZW50IGNvdW50ZXI6IDAwMDAwMDU3 CmlkZS9ob3N0MC9idXMxL3RhcmdldDAvbHVuMC9wYXJ0MidzIGV2ZW50IGNvdW50ZXI6IDAw MDAwMDU3CmlkZS9ob3N0MC9idXMwL3RhcmdldDEvbHVuMC9wYXJ0MidzIGV2ZW50IGNvdW50 ZXI6IDAwMDAwMDU3CmlkZS9ob3N0MC9idXMwL3RhcmdldDAvbHVuMC9wYXJ0MidzIGV2ZW50 IGNvdW50ZXI6IDAwMDAwMDU3CnJlcXVlc3RfbW9kdWxlW21kLXBlcnNvbmFsaXR5LTRdOiBS b290IGZzIG5vdCBtb3VudGVkCm1kLmM6IHBlcnNvbmFsaXR5IDQgaXMgbm90IGxvYWRlZCEK ZG9fbWRfcnVuKCkgcmV0dXJuZWQgLTIyCm1kMSBzdG9wcGVkLgp1bmJpbmQ8aWRlL2hvc3Qw L2J1czEvdGFyZ2V0MS9sdW4wL3BhcnQyLDM+CmV4cG9ydF9yZGV2KGlkZS9ob3N0MC9idXMx L3RhcmdldDEvbHVuMC9wYXJ0MikKdW5iaW5kPGlkZS9ob3N0MC9idXMxL3RhcmdldDAvbHVu MC9wYXJ0MiwyPgpleHBvcnRfcmRldihpZGUvaG9zdDAvYnVzMS90YXJnZXQwL2x1bjAvcGFy dDIpCnVuYmluZDxpZGUvaG9zdDAvYnVzMC90YXJnZXQxL2x1bjAvcGFydDIsMT4KZXhwb3J0 X3JkZXYoaWRlL2hvc3QwL2J1czAvdGFyZ2V0MS9sdW4wL3BhcnQyKQp1bmJpbmQ8aWRlL2hv c3QwL2J1czAvdGFyZ2V0MC9sdW4wL3BhcnQyLDA+CmV4cG9ydF9yZGV2KGlkZS9ob3N0MC9i dXMwL3RhcmdldDAvbHVuMC9wYXJ0MikKY29uc2lkZXJpbmcgaWRlL2hvc3QwL2J1czAvdGFy Z2V0MS9sdW4wL3BhcnQxIC4uLgogIGFkZGluZyBpZGUvaG9zdDAvYnVzMC90YXJnZXQxL2x1 bjAvcGFydDEgLi4uCiAgYWRkaW5nIGlkZS9ob3N0MC9idXMwL3RhcmdldDAvbHVuMC9wYXJ0 MSAuLi4KY3JlYXRlZCBtZDAKYmluZDxpZGUvaG9zdDAvYnVzMC90YXJnZXQwL2x1bjAvcGFy dDEsMT4KYmluZDxpZGUvaG9zdDAvYnVzMC90YXJnZXQxL2x1bjAvcGFydDEsMj4KcnVubmlu ZzogPGlkZS9ob3N0MC9idXMwL3RhcmdldDEvbHVuMC9wYXJ0MT48aWRlL2hvc3QwL2J1czAv dGFyZ2V0MC9sdW4wL3BhcnQxPgppZGUvaG9zdDAvYnVzMC90YXJnZXQxL2x1bjAvcGFydDEn cyBldmVudCBjb3VudGVyOiAwMDAwMDA1NwppZGUvaG9zdDAvYnVzMC90YXJnZXQwL2x1bjAv cGFydDEncyBldmVudCBjb3VudGVyOiAwMDAwMDA1NwpSQUlEIGxldmVsIDEgZG9lcyBub3Qg bmVlZCBjaHVua3NpemUhIENvbnRpbnVpbmcgYW55d2F5LgpyZXF1ZXN0X21vZHVsZVttZC1w ZXJzb25hbGl0eS0zXTogUm9vdCBmcyBub3QgbW91bnRlZAptZC5jOiBwZXJzb25hbGl0eSAz IGlzIG5vdCBsb2FkZWQhCmRvX21kX3J1bigpIHJldHVybmVkIC0yMgptZDAgc3RvcHBlZC4K dW5iaW5kPGlkZS9ob3N0MC9idXMwL3RhcmdldDEvbHVuMC9wYXJ0MSwxPgpleHBvcnRfcmRl dihpZGUvaG9zdDAvYnVzMC90YXJnZXQxL2x1bjAvcGFydDEpCnVuYmluZDxpZGUvaG9zdDAv YnVzMC90YXJnZXQwL2x1bjAvcGFydDEsMD4KZXhwb3J0X3JkZXYoaWRlL2hvc3QwL2J1czAv dGFyZ2V0MC9sdW4wL3BhcnQxKQouLi4gYXV0b3J1biBET05FLgpORVQ0OiBMaW51eCBUQ1Av SVAgMS4wIGZvciBORVQ0LjAKSVAgUHJvdG9jb2xzOiBJQ01QLCBVRFAsIFRDUCwgSUdNUApJ UDogcm91dGluZyBjYWNoZSBoYXNoIHRhYmxlIG9mIDIwNDggYnVja2V0cywgMTZLYnl0ZXMK VENQOiBIYXNoIHRhYmxlcyBjb25maWd1cmVkIChlc3RhYmxpc2hlZCAxNjM4NCBiaW5kIDE2 Mzg0KQpMaW51eCBJUCBtdWx0aWNhc3Qgcm91dGVyIDAuMDYgcGx1cyBQSU0tU00KTkVUNDog VW5peCBkb21haW4gc29ja2V0cyAxLjAvU01QIGZvciBMaW51eCBORVQ0LjAuCmRldmZzOiB2 MC4xMDIgKDIwMDAwNjIyKSBSaWNoYXJkIEdvb2NoIChyZ29vY2hAYXRuZi5jc2lyby5hdSkK ZGV2ZnM6IGJvb3Rfb3B0aW9uczogMHgwClZGUzogTW91bnRlZCByb290IChleHQyIGZpbGVz eXN0ZW0pLgpNb3VudGVkIGRldmZzIG9uIC9kZXYKcmFpZDEgcGVyc29uYWxpdHkgcmVnaXN0 ZXJlZCBhcyBuciAzCnJhaWQ1OiBtZWFzdXJpbmcgY2hlY2tzdW1taW5nIHNwZWVkCiAgIDhy ZWdzICAgICA6ICAxMjU4LjgwMCBNQi9zZWMKICAgMzJyZWdzICAgIDogICA4NjcuMjAwIE1C L3NlYwogICBwSUlfbW14ICAgOiAgMjE3NC40MDAgTUIvc2VjCiAgIHA1X21teCAgICA6ICAy MzE5LjYwMCBNQi9zZWMKcmFpZDU6IHVzaW5nIGZ1bmN0aW9uOiBwNV9tbXggKDIzMTkuNjAw IE1CL3NlYykKcmFpZDUgcGVyc29uYWxpdHkgcmVnaXN0ZXJlZCBhcyBuciA0CmF1dG9kZXRl Y3RpbmcgUkFJRCBhcnJheXMKKHJlYWQpIGlkZS9ob3N0MC9idXMxL3RhcmdldDEvbHVuMC9w YXJ0MidzIHNiIG9mZnNldDogNTkwMjczOTIgW2V2ZW50czogMDAwMDAwNTddCihyZWFkKSBp ZGUvaG9zdDAvYnVzMS90YXJnZXQwL2x1bjAvcGFydDIncyBzYiBvZmZzZXQ6IDU5MDI3Mzky IFtldmVudHM6IDAwMDAwMDU3XQoocmVhZCkgaWRlL2hvc3QwL2J1czAvdGFyZ2V0MS9sdW4w L3BhcnQyJ3Mgc2Igb2Zmc2V0OiA1OTAyMjcyMCBbZXZlbnRzOiAwMDAwMDA1N10KKHJlYWQp IGlkZS9ob3N0MC9idXMwL3RhcmdldDAvbHVuMC9wYXJ0MidzIHNiIG9mZnNldDogNTkwMjI3 MjAgW2V2ZW50czogMDAwMDAwNTddCihyZWFkKSBpZGUvaG9zdDAvYnVzMC90YXJnZXQxL2x1 bjAvcGFydDEncyBzYiBvZmZzZXQ6IDEwMjgwMzIgW2V2ZW50czogMDAwMDAwNTddCihyZWFk KSBpZGUvaG9zdDAvYnVzMC90YXJnZXQwL2x1bjAvcGFydDEncyBzYiBvZmZzZXQ6IDEwMjgw MzIgW2V2ZW50czogMDAwMDAwNTddCmF1dG9ydW4gLi4uCmNvbnNpZGVyaW5nIGlkZS9ob3N0 MC9idXMwL3RhcmdldDAvbHVuMC9wYXJ0MSAuLi4KICBhZGRpbmcgaWRlL2hvc3QwL2J1czAv dGFyZ2V0MC9sdW4wL3BhcnQxIC4uLgogIGFkZGluZyBpZGUvaG9zdDAvYnVzMC90YXJnZXQx L2x1bjAvcGFydDEgLi4uCmNyZWF0ZWQgbWQwCmJpbmQ8aWRlL2hvc3QwL2J1czAvdGFyZ2V0 MS9sdW4wL3BhcnQxLDE+CmJpbmQ8aWRlL2hvc3QwL2J1czAvdGFyZ2V0MC9sdW4wL3BhcnQx LDI+CnJ1bm5pbmc6IDxpZGUvaG9zdDAvYnVzMC90YXJnZXQwL2x1bjAvcGFydDE+PGlkZS9o b3N0MC9idXMwL3RhcmdldDEvbHVuMC9wYXJ0MT4KaWRlL2hvc3QwL2J1czAvdGFyZ2V0MC9s dW4wL3BhcnQxJ3MgZXZlbnQgY291bnRlcjogMDAwMDAwNTcKaWRlL2hvc3QwL2J1czAvdGFy Z2V0MS9sdW4wL3BhcnQxJ3MgZXZlbnQgY291bnRlcjogMDAwMDAwNTcKUkFJRCBsZXZlbCAx IGRvZXMgbm90IG5lZWQgY2h1bmtzaXplISBDb250aW51aW5nIGFueXdheS4KbWQwOiBtYXgg dG90YWwgcmVhZGFoZWFkIHdpbmRvdyBzZXQgdG8gNTA4awptZDA6IDEgZGF0YS1kaXNrcywg bWF4IHJlYWRhaGVhZCBwZXIgZGF0YS1kaXNrOiA1MDhrCnJhaWQxOiBkZXZpY2UgaWRlL2hv c3QwL2J1czAvdGFyZ2V0MC9sdW4wL3BhcnQxIG9wZXJhdGlvbmFsIGFzIG1pcnJvciAwCnJh aWQxOiBkZXZpY2UgaWRlL2hvc3QwL2J1czAvdGFyZ2V0MS9sdW4wL3BhcnQxIG9wZXJhdGlv bmFsIGFzIG1pcnJvciAxCihjaGVja2luZyBkaXNrIDApCihjaGVja2luZyBkaXNrIDEpCnJh aWQxOiByYWlkIHNldCBtZDAgYWN0aXZlIHdpdGggMiBvdXQgb2YgMiBtaXJyb3JzCm1kOiB1 cGRhdGluZyBtZDAgUkFJRCBzdXBlcmJsb2NrIG9uIGRldmljZQppZGUvaG9zdDAvYnVzMC90 YXJnZXQwL2x1bjAvcGFydDEgW2V2ZW50czogMDAwMDAwNThdKHdyaXRlKSBpZGUvaG9zdDAv YnVzMC90YXJnZXQwL2x1bjAvcGFydDEncyBzYiBvZmZzZXQ6IDEwMjgwMzIKaWRlL2hvc3Qw L2J1czAvdGFyZ2V0MS9sdW4wL3BhcnQxIFtldmVudHM6IDAwMDAwMDU4XSh3cml0ZSkgaWRl L2hvc3QwL2J1czAvdGFyZ2V0MS9sdW4wL3BhcnQxJ3Mgc2Igb2Zmc2V0OiAxMDI4MDMyCi4K Y29uc2lkZXJpbmcgaWRlL2hvc3QwL2J1czAvdGFyZ2V0MC9sdW4wL3BhcnQyIC4uLgogIGFk ZGluZyBpZGUvaG9zdDAvYnVzMC90YXJnZXQwL2x1bjAvcGFydDIgLi4uCiAgYWRkaW5nIGlk ZS9ob3N0MC9idXMwL3RhcmdldDEvbHVuMC9wYXJ0MiAuLi4KICBhZGRpbmcgaWRlL2hvc3Qw L2J1czEvdGFyZ2V0MC9sdW4wL3BhcnQyIC4uLgogIGFkZGluZyBpZGUvaG9zdDAvYnVzMS90 YXJnZXQxL2x1bjAvcGFydDIgLi4uCmNyZWF0ZWQgbWQxCmJpbmQ8aWRlL2hvc3QwL2J1czEv dGFyZ2V0MS9sdW4wL3BhcnQyLDE+CmJpbmQ8aWRlL2hvc3QwL2J1czEvdGFyZ2V0MC9sdW4w L3BhcnQyLDI+CmJpbmQ8aWRlL2hvc3QwL2J1czAvdGFyZ2V0MS9sdW4wL3BhcnQyLDM+CmJp bmQ8aWRlL2hvc3QwL2J1czAvdGFyZ2V0MC9sdW4wL3BhcnQyLDQ+CnJ1bm5pbmc6IDxpZGUv aG9zdDAvYnVzMC90YXJnZXQwL2x1bjAvcGFydDI+PGlkZS9ob3N0MC9idXMwL3RhcmdldDEv bHVuMC9wYXJ0Mj48aWRlL2hvc3QwL2J1czEvdGFyZ2V0MC9sdW4wL3BhcnQyPjxpZGUvaG9z dDAvYnVzMS90YXJnZXQxL2x1bjAvcGFydDI+CmlkZS9ob3N0MC9idXMwL3RhcmdldDAvbHVu MC9wYXJ0MidzIGV2ZW50IGNvdW50ZXI6IDAwMDAwMDU3CmlkZS9ob3N0MC9idXMwL3Rhcmdl dDEvbHVuMC9wYXJ0MidzIGV2ZW50IGNvdW50ZXI6IDAwMDAwMDU3CmlkZS9ob3N0MC9idXMx L3RhcmdldDAvbHVuMC9wYXJ0MidzIGV2ZW50IGNvdW50ZXI6IDAwMDAwMDU3CmlkZS9ob3N0 MC9idXMxL3RhcmdldDEvbHVuMC9wYXJ0MidzIGV2ZW50IGNvdW50ZXI6IDAwMDAwMDU3Cm1k MTogbWF4IHRvdGFsIHJlYWRhaGVhZCB3aW5kb3cgc2V0IHRvIDMwNzJrCm1kMTogMyBkYXRh LWRpc2tzLCBtYXggcmVhZGFoZWFkIHBlciBkYXRhLWRpc2s6IDEwMjRrCnJhaWQ1OiBkZXZp Y2UgaWRlL2hvc3QwL2J1czAvdGFyZ2V0MC9sdW4wL3BhcnQyIG9wZXJhdGlvbmFsIGFzIHJh aWQgZGlzayAwCnJhaWQ1OiBkZXZpY2UgaWRlL2hvc3QwL2J1czAvdGFyZ2V0MS9sdW4wL3Bh cnQyIG9wZXJhdGlvbmFsIGFzIHJhaWQgZGlzayAyCnJhaWQ1OiBkZXZpY2UgaWRlL2hvc3Qw L2J1czEvdGFyZ2V0MC9sdW4wL3BhcnQyIG9wZXJhdGlvbmFsIGFzIHJhaWQgZGlzayAxCnJh aWQ1OiBkZXZpY2UgaWRlL2hvc3QwL2J1czEvdGFyZ2V0MS9sdW4wL3BhcnQyIG9wZXJhdGlv bmFsIGFzIHJhaWQgZGlzayAzCnJhaWQ1OiBhbGxvY2F0ZWQgNDMxMmtCIGZvciBtZDEKcmFp ZDU6IHJhaWQgbGV2ZWwgNSBzZXQgbWQxIGFjdGl2ZSB3aXRoIDQgb3V0IG9mIDQgZGV2aWNl cywgYWxnb3JpdGhtIDAKUkFJRDUgY29uZiBwcmludG91dDoKIC0tLSByZDo0IHdkOjQgZmQ6 MAogZGlzayAwLCBzOjAsIG86MSwgbjowIHJkOjAgdXM6MSBkZXY6aWRlL2hvc3QwL2J1czAv dGFyZ2V0MC9sdW4wL3BhcnQyCiBkaXNrIDEsIHM6MCwgbzoxLCBuOjEgcmQ6MSB1czoxIGRl djppZGUvaG9zdDAvYnVzMS90YXJnZXQwL2x1bjAvcGFydDIKIGRpc2sgMiwgczowLCBvOjEs IG46MiByZDoyIHVzOjEgZGV2OmlkZS9ob3N0MC9idXMwL3RhcmdldDEvbHVuMC9wYXJ0Mgog ZGlzayAzLCBzOjAsIG86MSwgbjozIHJkOjMgdXM6MSBkZXY6aWRlL2hvc3QwL2J1czEvdGFy Z2V0MS9sdW4wL3BhcnQyClJBSUQ1IGNvbmYgcHJpbnRvdXQ6CiAtLS0gcmQ6NCB3ZDo0IGZk OjAKIGRpc2sgMCwgczowLCBvOjEsIG46MCByZDowIHVzOjEgZGV2OmlkZS9ob3N0MC9idXMw L3RhcmdldDAvbHVuMC9wYXJ0MgogZGlzayAxLCBzOjAsIG86MSwgbjoxIHJkOjEgdXM6MSBk ZXY6aWRlL2hvc3QwL2J1czEvdGFyZ2V0MC9sdW4wL3BhcnQyCiBkaXNrIDIsIHM6MCwgbzox LCBuOjIgcmQ6MiB1czoxIGRldjppZGUvaG9zdDAvYnVzMC90YXJnZXQxL2x1bjAvcGFydDIK IGRpc2sgMywgczowLCBvOjEsIG46MyByZDozIHVzOjEgZGV2OmlkZS9ob3N0MC9idXMxL3Rh cmdldDEvbHVuMC9wYXJ0MgptZDogdXBkYXRpbmcgbWQxIFJBSUQgc3VwZXJibG9jayBvbiBk ZXZpY2UKaWRlL2hvc3QwL2J1czAvdGFyZ2V0MC9sdW4wL3BhcnQyIFtldmVudHM6IDAwMDAw MDU4XSh3cml0ZSkgaWRlL2hvc3QwL2J1czAvdGFyZ2V0MC9sdW4wL3BhcnQyJ3Mgc2Igb2Zm c2V0OiA1OTAyMjcyMAppZGUvaG9zdDAvYnVzMC90YXJnZXQxL2x1bjAvcGFydDIgW2V2ZW50 czogMDAwMDAwNThdKHdyaXRlKSBpZGUvaG9zdDAvYnVzMC90YXJnZXQxL2x1bjAvcGFydDIn cyBzYiBvZmZzZXQ6IDU5MDIyNzIwCmlkZS9ob3N0MC9idXMxL3RhcmdldDAvbHVuMC9wYXJ0 MiBbZXZlbnRzOiAwMDAwMDA1OF0od3JpdGUpIGlkZS9ob3N0MC9idXMxL3RhcmdldDAvbHVu MC9wYXJ0MidzIHNiIG9mZnNldDogNTkwMjczOTIKaWRlL2hvc3QwL2J1czEvdGFyZ2V0MS9s dW4wL3BhcnQyIFtldmVudHM6IDAwMDAwMDU4XSh3cml0ZSkgaWRlL2hvc3QwL2J1czEvdGFy Z2V0MS9sdW4wL3BhcnQyJ3Mgc2Igb2Zmc2V0OiA1OTAyNzM5MgouCi4uLiBhdXRvcnVuIERP TkUuCnN3YXBwZXIocGlkIDEpIHVzZWQgb2Jzb2xldGUgTUQgaW9jdGwsIHVwZ3JhZGUgeW91 ciBzb2Z0d2FyZSB0byB1c2UgbmV3IGljdGxzLgpTdGFydCBtb3VudGluZyBmaWxlc3lzdGVt OiBtZCg5LDApCkVuZGluZyBjbGVhbiBYRlMgbW91bnQgZm9yIGZpbGVzeXN0ZW06IG1kKDks MCkKVkZTOiBNb3VudGVkIHJvb3QgKHhmcyBmaWxlc3lzdGVtKSByZWFkb25seS4KY2hhbmdl X3Jvb3Q6IG9sZCByb290IGhhcyBkX2NvdW50PTMKTW91bnRlZCBkZXZmcyBvbiAvZGV2ClRy eWluZyB0byB1bm1vdW50IG9sZCByb290IC4uLiBva2F5CkZyZWVpbmcgdW51c2VkIGtlcm5l bCBtZW1vcnk6IDIyMGsgZnJlZWQKKHJlYWQpIGlkZS9ob3N0MC9idXMxL3RhcmdldDAvbHVu MC9wYXJ0MSdzIHNiIG9mZnNldDogMTAyNDAwMCBbZXZlbnRzOiAwMDAwMDA1NV0KKHJlYWQp IGlkZS9ob3N0MC9idXMxL3RhcmdldDEvbHVuMC9wYXJ0MSdzIHNiIG9mZnNldDogMTAyNDAw MCBbZXZlbnRzOiAwMDAwMDA1NV0KYXV0b3J1biAuLi4KY29uc2lkZXJpbmcgaWRlL2hvc3Qw L2J1czEvdGFyZ2V0MS9sdW4wL3BhcnQxIC4uLgogIGFkZGluZyBpZGUvaG9zdDAvYnVzMS90 YXJnZXQxL2x1bjAvcGFydDEgLi4uCiAgYWRkaW5nIGlkZS9ob3N0MC9idXMxL3RhcmdldDAv bHVuMC9wYXJ0MSAuLi4KY3JlYXRlZCBtZDIKYmluZDxpZGUvaG9zdDAvYnVzMS90YXJnZXQw L2x1bjAvcGFydDEsMT4KYmluZDxpZGUvaG9zdDAvYnVzMS90YXJnZXQxL2x1bjAvcGFydDEs Mj4KcnVubmluZzogPGlkZS9ob3N0MC9idXMxL3RhcmdldDEvbHVuMC9wYXJ0MT48aWRlL2hv c3QwL2J1czEvdGFyZ2V0MC9sdW4wL3BhcnQxPgppZGUvaG9zdDAvYnVzMS90YXJnZXQxL2x1 bjAvcGFydDEncyBldmVudCBjb3VudGVyOiAwMDAwMDA1NQppZGUvaG9zdDAvYnVzMS90YXJn ZXQwL2x1bjAvcGFydDEncyBldmVudCBjb3VudGVyOiAwMDAwMDA1NQpSQUlEIGxldmVsIDEg ZG9lcyBub3QgbmVlZCBjaHVua3NpemUhIENvbnRpbnVpbmcgYW55d2F5LgptZDI6IG1heCB0 b3RhbCByZWFkYWhlYWQgd2luZG93IHNldCB0byA1MDhrCm1kMjogMSBkYXRhLWRpc2tzLCBt YXggcmVhZGFoZWFkIHBlciBkYXRhLWRpc2s6IDUwOGsKcmFpZDE6IGRldmljZSBpZGUvaG9z dDAvYnVzMS90YXJnZXQxL2x1bjAvcGFydDEgb3BlcmF0aW9uYWwgYXMgbWlycm9yIDEKcmFp ZDE6IGRldmljZSBpZGUvaG9zdDAvYnVzMS90YXJnZXQwL2x1bjAvcGFydDEgb3BlcmF0aW9u YWwgYXMgbWlycm9yIDAKKGNoZWNraW5nIGRpc2sgMCkKKGNoZWNraW5nIGRpc2sgMSkKcmFp ZDE6IHJhaWQgc2V0IG1kMiBhY3RpdmUgd2l0aCAyIG91dCBvZiAyIG1pcnJvcnMKbWQ6IHVw ZGF0aW5nIG1kMiBSQUlEIHN1cGVyYmxvY2sgb24gZGV2aWNlCmlkZS9ob3N0MC9idXMxL3Rh cmdldDEvbHVuMC9wYXJ0MSBbZXZlbnRzOiAwMDAwMDA1Nl0od3JpdGUpIGlkZS9ob3N0MC9i dXMxL3RhcmdldDEvbHVuMC9wYXJ0MSdzIHNiIG9mZnNldDogMTAyNDAwMAppZGUvaG9zdDAv YnVzMS90YXJnZXQwL2x1bjAvcGFydDEgW2V2ZW50czogMDAwMDAwNTZdKHdyaXRlKSBpZGUv aG9zdDAvYnVzMS90YXJnZXQwL2x1bjAvcGFydDEncyBzYiBvZmZzZXQ6IDEwMjQwMDAKLgou Li4gYXV0b3J1biBET05FLgpTdGFydCBtb3VudGluZyBmaWxlc3lzdGVtOiBtZCg5LDEpCkVu ZGluZyBjbGVhbiBYRlMgbW91bnQgZm9yIGZpbGVzeXN0ZW06IG1kKDksMSkKU0NTSSBzdWJz eXN0ZW0gZHJpdmVyIFJldmlzaW9uOiAxLjAwCmkyYy1jb3JlLm86IGkyYyBjb3JlIG1vZHVs ZQppMmMtYWxnby1iaXQubzogaTJjIGJpdCBhbGdvcml0aG0gbW9kdWxlCkxpbnV4IHZpZGVv IGNhcHR1cmUgaW50ZXJmYWNlOiB2MS4wMApidHR2OiBkcml2ZXIgdmVyc2lvbiAwLjcuNTcg bG9hZGVkCmJ0dHY6IHVzaW5nIDIgYnVmZmVycyB3aXRoIDIwODBrICg0MTYwayB0b3RhbCkg Zm9yIGNhcHR1cmUKaTJjLWNvcmUubzogaTJjIGNvcmUgbW9kdWxlCmkyYy1hbGdvLWJpdC5v OiBpMmMgYml0IGFsZ29yaXRobSBtb2R1bGUKTGludXggdmlkZW8gY2FwdHVyZSBpbnRlcmZh Y2U6IHYxLjAwCmJ0dHY6IGRyaXZlciB2ZXJzaW9uIDAuNy41NyBsb2FkZWQKYnR0djogdXNp bmcgMiBidWZmZXJzIHdpdGggMjA4MGsgKDQxNjBrIHRvdGFsKSBmb3IgY2FwdHVyZQpBZGRp bmcgU3dhcDogMTAyMzk5Mmsgc3dhcC1zcGFjZSAocHJpb3JpdHkgLTEpCldpbmJvbmQgU3Vw ZXItSU8gZGV0ZWN0aW9uLCBub3cgdGVzdGluZyBwb3J0cyAzRjAsMzcwLDI1MCw0RSwyRSAu Li4KU01TQyBTdXBlci1JTyBkZXRlY3Rpb24sIG5vdyB0ZXN0aW5nIFBvcnRzIDJGMCwgMzcw IC4uLgoweDM3ODogRklGTyBpcyAxNiBieXRlcwoweDM3ODogd3JpdGVJbnRyVGhyZXNob2xk IGlzIDgKMHgzNzg6IHJlYWRJbnRyVGhyZXNob2xkIGlzIDgKMHgzNzg6IFBXb3JkIGlzIDgg Yml0cwoweDM3ODogSW50ZXJydXB0cyBhcmUgSVNBLVB1bHNlcwoweDM3ODogRUNQIHBvcnQg Y2ZnQT0weDE0IGNmZ0I9MHg0MAoweDM3ODogRUNQIHNldHRpbmdzIGlycT08bm9uZSBvciBz ZXQgYnkgb3RoZXIgbWVhbnM+IGRtYT08bm9uZSBvciBzZXQgYnkgb3RoZXIgbWVhbnM+CnBh cnBvcnQwOiBQQy1zdHlsZSBhdCAweDM3OCAoMHg3NzgpIFtQQ1NQUCxUUklTVEFURSxDT01Q QVQsRVBQLEVDUF0KcGFycG9ydDA6IGlycSA3IGRldGVjdGVkCnBhcnBvcnQwOiBjcHBfZGFp c3k6IGFhNTUwMGZmKDA4KQpwYXJwb3J0MDogYXNzaWduX2FkZHJzOiBhYTU1MDBmZigwOCkK cGFycG9ydDA6IGNwcF9kYWlzeTogYWE1NTAwZmYoMDgpCnBhcnBvcnQwOiBhc3NpZ25fYWRk cnM6IGFhNTUwMGZmKDA4KQppcF9jb25udHJhY2sgKDIwNDQgYnVja2V0cywgMTYzNTIgbWF4 KQplZXBybzEwMC5jOnYxLjA5ai10IDkvMjkvOTkgRG9uYWxkIEJlY2tlciBodHRwOi8vY2Vz ZGlzLmdzZmMubmFzYS5nb3YvbGludXgvZHJpdmVycy9lZXBybzEwMC5odG1sCmVlcHJvMTAw LmM6ICRSZXZpc2lvbjogMS4zNiAkIDIwMDAvMTEvMTcgTW9kaWZpZWQgYnkgQW5kcmV5IFYu IFNhdm9jaGtpbiA8c2F3QHNhdy5zdy5jb20uc2c+IGFuZCBvdGhlcnMKUENJOiBGb3VuZCBJ UlEgMTAgZm9yIGRldmljZSAwMjowOC4wClBDSTogVGhlIHNhbWUgSVJRIHVzZWQgZm9yIGRl dmljZSAwMDoxZi4zCmV0aDA6IEludGVsIENvcnBvcmF0aW9uIDgyNTU3IFtFdGhlcm5ldCBQ cm8gMTAwXSwgMDA6MDI6QjM6MkE6QjA6RUQsIEkvTyBhdCAweGVjYzAsIElSUSAxMC4KICBC b2FyZCBhc3NlbWJseSA3MjEzODMtMDE2LCBQaHlzaWNhbCBjb25uZWN0b3JzIHByZXNlbnQ6 IFJKNDUKICBQcmltYXJ5IGludGVyZmFjZSBjaGlwIGk4MjU1NSBQSFkgIzEuCiAgR2VuZXJh bCBzZWxmLXRlc3Q6IHBhc3NlZC4KICBTZXJpYWwgc3ViLXN5c3RlbSBzZWxmLXRlc3Q6IHBh c3NlZC4KICBJbnRlcm5hbCByZWdpc3RlcnMgc2VsZi10ZXN0OiBwYXNzZWQuCiAgUk9NIGNo ZWNrc3VtIHNlbGYtdGVzdDogcGFzc2VkICgweDA0ZjQ1MThiKS4KUENJOiBGb3VuZCBJUlEg NSBmb3IgZGV2aWNlIDAyOjBjLjAKM2M1OXguYzpMSzEuMS4xMyAyNyBKYW4gMjAwMSAgRG9u YWxkIEJlY2tlciBhbmQgb3RoZXJzLiBodHRwOi8vd3d3LnNjeWxkLmNvbS9uZXR3b3JrL3Zv cnRleC5odG1sClNlZSBEb2N1bWVudGF0aW9uL25ldHdvcmtpbmcvdm9ydGV4LnR4dApldGgx OiAzQ29tIFBDSSAzYzkwNUMgVG9ybmFkbyBhdCAweGVjMDAsICAwMDpiMDpkMDpkZToyMToy NSwgSVJRIDUKICBwcm9kdWN0IGNvZGUgMDAwMCByZXYgMDAuMTQgZGF0ZSAwNy0wMy05Nwog IDhLIGJ5dGUtd2lkZSBSQU0gNTozIFJ4OlR4IHNwbGl0LCBhdXRvc2VsZWN0L0F1dG9uZWdv dGlhdGUgaW50ZXJmYWNlLgogIE1JSSB0cmFuc2NlaXZlciBmb3VuZCBhdCBhZGRyZXNzIDI0 LCBzdGF0dXMgNzgwOS4KICBFbmFibGluZyBidXMtbWFzdGVyIHRyYW5zbWl0cyBhbmQgd2hv bGUtZnJhbWUgcmVjZWl2ZXMuCmV0aDE6IHNjYXR0ZXIvZ2F0aGVyIGRpc2FibGVkLiBoL3cg Y2hlY2tzdW1zIGVuYWJsZWQK --------------DD81C98F4F8AD0FAC2FDB998 Content-Type: application/octet-stream; name="lilo.conf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="lilo.conf" Ym9vdD0vZGV2L21kMAptYXA9L2Jvb3QvbWFwCmluc3RhbGw9L2Jvb3QvYm9vdC5iCnByb21w dAp0aW1lb3V0PTUwCm1lc3NhZ2U9L2Jvb3QvbWVzc2FnZQpsaW5lYXIKZGVmYXVsdD1saW51 eAoKaW1hZ2U9L2Jvb3Qvdm1saW51ei0yLjQuMi1TR0lfWEZTXzEuMAoJbGFiZWw9bGludXgK CWluaXRyZD0vYm9vdC9pbml0cmQtMi40LjItU0dJX1hGU18xLjAuaW1nCglyZWFkLW9ubHkK CXJvb3Q9L2Rldi9tZDAKCWFwcGVuZD0icmFtZGlza19zaXplPTI1MDAgbm9hcGljIgo= --------------DD81C98F4F8AD0FAC2FDB998-- From owner-linux-xfs@oss.sgi.com Thu Jun 7 06:53:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57Dr7s06367 for linux-xfs-outgoing; Thu, 7 Jun 2001 06:53:07 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57Dr6h06363 for ; Thu, 7 Jun 2001 06:53:06 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA19812 for ; Thu, 7 Jun 2001 06:53:03 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA2088926; Thu, 7 Jun 2001 08:51:48 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA48783; Thu, 7 Jun 2001 08:51:48 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f57Dskq26453; Thu, 7 Jun 2001 08:54:46 -0500 Message-Id: <200106071354.f57Dskq26453@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Stefan.Sommer@behrgroup.com (Stefan Sommer) cc: linux-xfs@oss.sgi.com Subject: Re: Vortex Raid Controller and XFS In-Reply-To: Message from Stefan.Sommer@behrgroup.com (Stefan Sommer) of "Thu, 07 Jun 2001 05:55:47 PDT." <200106071255.f57CtlD31872@oss.sgi.com> Date: Thu, 07 Jun 2001 08:54:46 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, You might try turning off devfs, this may be an issue with the raid driver not being devfs aware. You can do a quick test by using the devfs=nomount option at boot time. Going one step further, you can rebuild the kernel with devfs turned off. Hope this helps, Steve > > Hallo XFS Team > i tried to install XFS Redhat 7.1 on a PC Server with boot devices on a Vorte > x RAID Controller. > Install this configuration must be done by using the linux dd Installation mo > de. Doing so, the XFS Redhat loads the driver disk, \(it seems so\), but wh > en it has to create the file systems, it does not find any available disks. T > he normal Redhat distribution woirks correctly. Must I have special drivers f > or this Filesystem\? > I got this driver disk from > ftp.redhat.de/pub/rh-addons/driverdisks/rh71gdth.img.gz > > I hope, there is a solution, because i have to build a HA Linux File Server > with about 1 TB Filesystem in the next week > > Thanks in advance > > Regards > > Stefan Sommer From owner-linux-xfs@oss.sgi.com Thu Jun 7 07:44:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57EiLn13092 for linux-xfs-outgoing; Thu, 7 Jun 2001 07:44:21 -0700 Received: from webstor1.artstor.de ([195.243.248.130]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57EiJh13089 for ; Thu, 7 Jun 2001 07:44:20 -0700 Received: (qmail 30776 invoked from network); 7 Jun 2001 14:44:29 -0000 Received: from zerberus.artstor.de (HELO sokrates.artstor.de) (195.243.248.115) by www.artstor.de with SMTP; 7 Jun 2001 14:44:29 -0000 Date: Thu, 7 Jun 2001 16:43:25 +0200 (CEST) From: Jan Strohbehn X-X-Sender: To: Subject: Changing ACLs as non-owner Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi !! I just joined this mailing list, so I'm sorry if this question has been asked before. Is it possible to set ACLs on a file or directory if you are not the native owner (e.g. member of the primary group) ??? Thank you, Jan From owner-linux-xfs@oss.sgi.com Thu Jun 7 08:24:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57FOvN18547 for linux-xfs-outgoing; Thu, 7 Jun 2001 08:24:57 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57FOuh18541 for ; Thu, 7 Jun 2001 08:24:56 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f57FOpaJ030062; Thu, 7 Jun 2001 10:24:55 -0500 (CDT) Message-ID: <3B1F9CBE.701064E9@thebarn.com> Date: Thu, 07 Jun 2001 10:24:46 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Simon Matter CC: linux-xfs Subject: Re: Segmentation faults on i820 (Camino) chipset References: <3B1F6564.EC904DF4@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter wrote: > Hi everybody, > > I'm using XFS since 1.0 and it has worked perfectly everywhere. I used > it on top of MD Raid5 and on LVM on top of MD Raid5. > > But now I came across a problem and I don't know how to solve it. > > I installed RH7.1-XFS on a new DELL Precision 220 Workstation, one PIII > 933, 256M RDRAM, Intel Pro/100 ethernet. I removed the CDROM and > installed 4 IBM IC35L060AVER07 60G HD's. The onboard Sound and USB is > disabled. The chipset is i820 (Camino). > > Initial install went fine, using 180GB MD Raid5. Then I tired to update > some RPM's and rpm segfaulted. Later after a reboot, it went fine. The > next reboot I saw some messages that /sbin/mkkerneldoth segfaulted, > another reboot went fine. I started to play with the noapic and pci=xxx > options but no result. 1 of 5 times I boot the system, it doesn't work > properly and many applications segfault. beside that everything seems > okay. > > Any idea what I can do? Sounds like bad hardware. > > > Thanks > Simon > > -- > 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] > > ------------------------------------------------------------------------ > Name: dmesg > dmesg Type: unspecified type (application/octet-stream) > Encoding: base64 > > Name: lilo.conf > lilo.conf Type: unspecified type (application/octet-stream) > Encoding: base64 -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Thu Jun 7 08:27:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57FR9F19037 for linux-xfs-outgoing; Thu, 7 Jun 2001 08:27:09 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57FR8h19031 for ; Thu, 7 Jun 2001 08:27:08 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f57FR7aJ030077 for ; Thu, 7 Jun 2001 10:27:07 -0500 (CDT) Message-ID: <3B1F9D46.B75E0C0E@thebarn.com> Date: Thu, 07 Jun 2001 10:27:02 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Vortex Raid Controller and XFS References: <200106071255.f57CtlD31872@oss.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Stefan Sommer wrote: > This message was sent from http://linux-xfs.sgi.com/projects/xfs/index.html > > ---- > > Hallo XFS Team > i tried to install XFS Redhat 7.1 on a PC Server with boot devices on a Vortex RAID Controller. > Install this configuration must be done by using the linux dd Installation mode. Doing so, the XFS Redhat loads the driver disk, \(it seems so\), but when it has to create the file systems, it does not find any available disks. The normal Redhat distribution woirks correctly. Must I have special drivers for this Filesystem\? > I got this driver disk from > ftp.redhat.de/pub/rh-addons/driverdisks/rh71gdth.img.gz Which kernel did you boot for the installation? you must use the kernel from the XFS installer as it is XFS aware. I doubt the driver from the above driver disk will load as it was compiled for a different kernel. You will probably need to recompile the driver into an XFS kernel and use that kernel on a installer boot floppy. > > > I hope, there is a solution, because i have to build a HA Linux File Server with about 1 TB Filesystem in the next week > > Thanks in advance > > Regards > > Stefan Sommer -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Thu Jun 7 08:29:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57FTC719592 for linux-xfs-outgoing; Thu, 7 Jun 2001 08:29:12 -0700 Received: from main.braxis.co.uk (root@main.braxis.co.uk [213.77.40.29]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57FSth19521 for ; Thu, 7 Jun 2001 08:28:58 -0700 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.9.3/8.9.3) id OAA06913; Thu, 7 Jun 2001 14:27:02 +0200 Date: Thu, 7 Jun 2001 14:27:02 +0200 From: Krzysztof Rusocki To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - merge XFS up to 2.4.6-pre1 Message-ID: <20010607142702.C4568@main.braxis.co.uk> References: <200106060315.f563FQI09007@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106060315.f563FQI09007@jen.americas.sgi.com>; from lord@sgi.com on Tue, Jun 05, 2001 at 10:15:26PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve, And again i issued oopses ;-( - this time machine didn't even passed initscripts.. Unfortunately i'm quite far from that machine - about 200 miles (which is quite far for my native conditions), so i'll provide output as soon as it will be possible for me (in 3 days ca.)... Cheers, Krzysztof PS. mail me if you need so details about machine/os From owner-linux-xfs@oss.sgi.com Thu Jun 7 08:30:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57FUUV19944 for linux-xfs-outgoing; Thu, 7 Jun 2001 08:30:30 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57FUSh19940 for ; Thu, 7 Jun 2001 08:30:28 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f57FUOaJ030110; Thu, 7 Jun 2001 10:30:24 -0500 (CDT) Message-ID: <3B1F9E0B.B089759@thebarn.com> Date: Thu, 07 Jun 2001 10:30:19 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Stefan Sommer , linux-xfs@oss.sgi.com Subject: Re: Vortex Raid Controller and XFS References: <200106071354.f57Dskq26453@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > Hi, > > You might try turning off devfs, this may be an issue with the raid driver > not being devfs aware. You can do a quick test by using the > > devfs=nomount > > option at boot time. Going one step further, you can rebuild the kernel > with devfs turned off. Note devfs is not enabled in the "BOOT " kernel. Only in the installed kernels. > > > Hope this helps, > > Steve > > > > > Hallo XFS Team > > i tried to install XFS Redhat 7.1 on a PC Server with boot devices on a Vorte > > x RAID Controller. > > Install this configuration must be done by using the linux dd Installation mo > > de. Doing so, the XFS Redhat loads the driver disk, \(it seems so\), but wh > > en it has to create the file systems, it does not find any available disks. T > > he normal Redhat distribution woirks correctly. Must I have special drivers f > > or this Filesystem\? > > I got this driver disk from > > ftp.redhat.de/pub/rh-addons/driverdisks/rh71gdth.img.gz > > > > I hope, there is a solution, because i have to build a HA Linux File Server > > with about 1 TB Filesystem in the next week > > > > Thanks in advance > > > > Regards > > > > Stefan Sommer -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Thu Jun 7 08:41:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57FfAc22082 for linux-xfs-outgoing; Thu, 7 Jun 2001 08:41:10 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57Ff7h22078 for ; Thu, 7 Jun 2001 08:41:07 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id RAA27374 for ; Thu, 7 Jun 2001 17:41:05 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id RAA22377 for linux-xfs@oss.sgi.com; Thu, 7 Jun 2001 17:41:03 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id AA12D57306 for ; Thu, 7 Jun 2001 17:50:15 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 511E125835 for ; Thu, 7 Jun 2001 17:51:00 +0200 (CEST) Message-ID: <3B1FA176.A128B041@ch.sauter-bc.com> Date: Thu, 07 Jun 2001 17:44:54 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: linux-xfs Subject: Re: Segmentation faults on i820 (Camino) chipset References: <3B1F6564.EC904DF4@ch.sauter-bc.com> <3B1F9CBE.701064E9@thebarn.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sorry, sorry, I was 'tuning' the IDE chips in a wrong way. Since ever and on every machine (~ 50) I'm using hdparm -c1 /dev/ha[a-d] to enable fast 32-bit I/O. But with i820 chipsets, this will corrupt data!! After 100 tests and reboots I changed to hdparm -c3 /dev/ha[a-d] and the world is okay. Thank you Wintel once again, I have never seen this kind of problem with any ServerWorks or VIA chipset. Russell Cattelan schrieb: > > Simon Matter wrote: > > > Hi everybody, > > > > I'm using XFS since 1.0 and it has worked perfectly everywhere. I used > > it on top of MD Raid5 and on LVM on top of MD Raid5. > > > > But now I came across a problem and I don't know how to solve it. > > > > I installed RH7.1-XFS on a new DELL Precision 220 Workstation, one PIII > > 933, 256M RDRAM, Intel Pro/100 ethernet. I removed the CDROM and > > installed 4 IBM IC35L060AVER07 60G HD's. The onboard Sound and USB is > > disabled. The chipset is i820 (Camino). > > > > Initial install went fine, using 180GB MD Raid5. Then I tired to update > > some RPM's and rpm segfaulted. Later after a reboot, it went fine. The > > next reboot I saw some messages that /sbin/mkkerneldoth segfaulted, > > another reboot went fine. I started to play with the noapic and pci=xxx > > options but no result. 1 of 5 times I boot the system, it doesn't work > > properly and many applications segfault. beside that everything seems > > okay. > > > > Any idea what I can do? > > Sounds like bad hardware. > > > > > > > Thanks > > Simon > > > > -- > > 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] > > > > ------------------------------------------------------------------------ > > Name: dmesg > > dmesg Type: unspecified type (application/octet-stream) > > Encoding: base64 > > > > Name: lilo.conf > > lilo.conf Type: unspecified type (application/octet-stream) > > Encoding: base64 > > -- > Russell Cattelan > cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Thu Jun 7 10:50:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57HoMQ29750 for linux-xfs-outgoing; Thu, 7 Jun 2001 10:50:22 -0700 Received: from goku.engr.colostate.edu (goku.engr.colostate.edu [129.82.224.16]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57HoKh29747 for ; Thu, 7 Jun 2001 10:50:20 -0700 Received: from trunks (trunks.engr.colostate.edu [129.82.226.114]) by goku.engr.colostate.edu (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f57HoUOT028969 for ; Thu, 7 Jun 2001 11:50:30 -0600 (MDT) Date: Thu, 7 Jun 2001 11:50:18 -0600 (MDT) From: "Christopher \"C.J.\" Keist" X-Sender: cjay@trunks To: linux-xfs@oss.sgi.com Subject: quota support for xfs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I have installed RH7.1 using SGI installer CD. I have compiled the kernel to support RAID with Linear support, xfs , quota and xfs quota support. I then created a file system appending three disks together, the raidtab file follows: raiddev /dev/md0 raid-level linear nr-raid-disks 3 persistent-superblock 1 chunk-size 4 device /dev/sdb1 raid-disk 0 device /dev/sdc1 raid-disk 1 device /dev/sdd1 raid-disk 2 I was able to create the xfs file system with no problems. I'm now trying to get user quota to work, but having no luck. Here is how the file sytem is being mounted in the fstab file: /dev/md0 /test xfs rw,usrquota 1 1 I have tried just quota,userquota and usrquota for the mount options, all seem to work with no errors in mounting, but all behave the same in that quotas don't work. When I try repquota -v /test I get the following: repquota: Not all specified mountpoints are using quota. mount command shows the following: [root@strife /etc]# mount /dev/sda1 on / type ext2 (rw) none on /proc type proc (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) /dev/md0 on /test type xfs (rw,usrquota) setquota does the following: [root@strife /etc]# setquota jeremy 50000 55000 5000 5100 /test setquota: Not all specified mountpoints are using quota. I have also downloaded and compiled/install quota-tools-3.01-pre6, still no luck. Doing strings on the quota commands do show that xfs support is there: [root@strife quota]# strings /usr/sbin/setquota | egrep xfs xfs - XFS quota format /proc/fs/xfs/stat Is all this just telling me that quota support for XFS filesystem on a md raid device is not supported? C. J. Keist Email: cjay@engr.colostate.edu UNIX/Network Manager Phone: 970-491-0630 Engineering Network Services Fax: 970-491-2465 College of Engineering, CSU Ft. Collins, CO 80523-1301 From owner-linux-xfs@oss.sgi.com Thu Jun 7 10:49:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57HnLJ29686 for linux-xfs-outgoing; Thu, 7 Jun 2001 10:49:21 -0700 Received: from main.braxis.co.uk (root@main.braxis.co.uk [213.77.40.29]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57Hn8h29683 for ; Thu, 7 Jun 2001 10:49:09 -0700 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.9.3/8.9.3) id TAA00862 for linux-xfs@oss.sgi.com; Thu, 7 Jun 2001 19:46:58 +0200 Date: Thu, 7 Jun 2001 19:46:57 +0200 From: Krzysztof Rusocki To: linux-xfs@oss.sgi.com Subject: mounting xfs with specified access mode Message-ID: <20010607194657.A22964@main.braxis.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello. Is it possible to mount xfs fs with some access mode (i.e. 1777) using some mount option, just like it can be done for devpts ? (maybe there's other way...). Looked at Documentation/filesystems/xfs.txt - didn't find any... Cheers, Krzysztof From owner-linux-xfs@oss.sgi.com Thu Jun 7 11:00:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57I0b130512 for linux-xfs-outgoing; Thu, 7 Jun 2001 11:00:37 -0700 Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57I0ah30509 for ; Thu, 7 Jun 2001 11:00:36 -0700 Received: from darkstar.ee.washington.edu (darkstar.ee.washington.edu [128.95.196.85]) by maxwell.ee.washington.edu (8.12.0.Beta7/8.12.0) with ESMTP id f57I0Uga013049; Thu, 7 Jun 2001 11:00:30 -0700 Date: Thu, 7 Jun 2001 11:00:30 -0700 (PDT) From: To: "Christopher \"C.J.\" Keist" cc: linux-xfs@oss.sgi.com Subject: Re: quota support for xfs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Make sure you have xfs quota in kernel. Next get the latest patch/cvs from xfs. xfs 1.0 has problems with quota. ***************************** Walter Marchuk Senior Computer Specialist University of Washington Electrical Engineering Room: 307g 206-221-5421 marchuk@ee.washington.edu ***************************** On Thu, 7 Jun 2001, Christopher "C.J." Keist wrote: > Hello, > I have installed RH7.1 using SGI installer CD. I have compiled the > kernel to support RAID with Linear support, xfs , quota and xfs quota > support. I then created a file system appending three disks together, the > raidtab file follows: > > raiddev /dev/md0 > raid-level linear > nr-raid-disks 3 > persistent-superblock 1 > chunk-size 4 > device /dev/sdb1 > raid-disk 0 > device /dev/sdc1 > raid-disk 1 > device /dev/sdd1 > raid-disk 2 > > > I was able to create the xfs file system with no problems. I'm now trying > to get user quota to work, but having no luck. Here is how the file sytem > is being mounted in the fstab file: > > /dev/md0 /test xfs rw,usrquota 1 > 1 > > I have tried just quota,userquota and usrquota for the mount options, all > seem to work with no errors in mounting, but all behave the same in that > quotas don't work. When I try repquota -v /test I get the following: > > repquota: Not all specified mountpoints are using quota. > > mount command shows the following: > > [root@strife /etc]# mount > /dev/sda1 on / type ext2 (rw) > none on /proc type proc (rw) > none on /dev/pts type devpts (rw,gid=5,mode=620) > /dev/md0 on /test type xfs (rw,usrquota) > > setquota does the following: > > [root@strife /etc]# setquota jeremy 50000 55000 5000 5100 /test > setquota: Not all specified mountpoints are using quota. > > I have also downloaded and compiled/install quota-tools-3.01-pre6, still > no luck. Doing strings on the quota commands do show that xfs support is > there: > > [root@strife quota]# strings /usr/sbin/setquota | egrep xfs > xfs - XFS quota format > /proc/fs/xfs/stat > > Is all this just telling me that quota support for XFS filesystem on a md > raid device is not supported? > > > C. J. Keist Email: cjay@engr.colostate.edu > UNIX/Network Manager Phone: 970-491-0630 > Engineering Network Services Fax: 970-491-2465 > College of Engineering, CSU > Ft. Collins, CO 80523-1301 > From owner-linux-xfs@oss.sgi.com Thu Jun 7 11:03:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57I3TR30708 for linux-xfs-outgoing; Thu, 7 Jun 2001 11:03:29 -0700 Received: from saturn.gjw.net (IDENT:qmailr@gateway.wildman.co.za [196.15.241.74]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57I3Oh30666 for ; Thu, 7 Jun 2001 11:03:25 -0700 Received: (qmail 6655 invoked from network); 7 Jun 2001 18:03:17 -0000 Received: from charon.gjw.net (gregw@192.168.0.101) by saturn.gjw.net with SMTP; 7 Jun 2001 18:03:17 -0000 Subject: Re: quota support for xfs From: Greg Wildman To: Christopher "C.J." Keist Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain X-Mailer: Evolution/0.10 (Preview Release) Date: 07 Jun 2001 20:03:17 +0200 Message-Id: <991936997.17518.22.camel@charon.gjw.net> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 07 Jun 2001 11:50:18 -0600, Christopher "C.J." Keist wrote: > Hello, > I have installed RH7.1 using SGI installer CD. I have compiled the > kernel to support RAID with Linear support, xfs , quota and xfs quota > support. I then created a file system appending three disks together, the > raidtab file follows: > > ..snip.. > > > I was able to create the xfs file system with no problems. I'm now trying > to get user quota to work, but having no luck. Here is how the file sytem > is being mounted in the fstab file: > > /dev/md0 /test xfs rw,usrquota 1 > 1 > > I have tried just quota,userquota and usrquota for the mount options, all > seem to work with no errors in mounting, but all behave the same in that > quotas don't work. When I try repquota -v /test I get the following: > > repquota: Not all specified mountpoints are using quota. > > mount command shows the following: > > [root@strife /etc]# mount > /dev/sda1 on / type ext2 (rw) > none on /proc type proc (rw) > none on /dev/pts type devpts (rw,gid=5,mode=620) > /dev/md0 on /test type xfs (rw,usrquota) > > setquota does the following: > > [root@strife /etc]# setquota jeremy 50000 55000 5000 5100 /test > setquota: Not all specified mountpoints are using quota. > > I have also downloaded and compiled/install quota-tools-3.01-pre6, still > no luck. Doing strings on the quota commands do show that xfs support is > there: > > [root@strife quota]# strings /usr/sbin/setquota | egrep xfs > xfs - XFS quota format > /proc/fs/xfs/stat > > Is all this just telling me that quota support for XFS filesystem on a md > raid device is not supported? You must have missed my earlier post, so I will repeat it again below; There were a few problems running quotas using the SGI RedHat 7.1 iso. There is a patch for the kernel at http://linux-xfs.sgi.com/projects/xfs/mail_archive/0105/msg00246.html and a patch for the repquota command at http://linux-xfs.sgi.com/projects/xfs/mail_archive/0105/msg00252.html I have recompiled both SRPMS with the patches added and all is working great. I won't post the patches and spec file here as they are quite large, but drop me a note if you want me to make them available for download. -- Greg Kent's Heuristic: Look for it first where you'd most like to find it. From owner-linux-xfs@oss.sgi.com Thu Jun 7 11:03:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57I3iw30757 for linux-xfs-outgoing; Thu, 7 Jun 2001 11:03:44 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57I3hh30753 for ; Thu, 7 Jun 2001 11:03:43 -0700 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA1672836 for ; Thu, 7 Jun 2001 20:03:41 +0200 (CEST) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA29630 for ; Thu, 7 Jun 2001 11:07:41 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 9993815A451 for ; Thu, 7 Jun 2001 11:02:13 -0700 (PDT) Subject: growing a partition From: Florin Andrei To: linux-xfs@oss.sgi.com Content-Type: text/plain X-Mailer: Evolution/0.10 (Preview Release) Date: 07 Jun 2001 11:02:13 -0700 Message-Id: <991936933.3442.0.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is there any HOWTO on growing an XFS partition under Linux? Is is possible to do this for the / partition? -- Florin Andrei From owner-linux-xfs@oss.sgi.com Thu Jun 7 11:05:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57I5O530952 for linux-xfs-outgoing; Thu, 7 Jun 2001 11:05:24 -0700 Received: from cotse.com (packetderm.cotse.com [216.112.42.58]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57I5Nh30949 for ; Thu, 7 Jun 2001 11:05:23 -0700 Received: (from nobody@localhost) by cotse.com (5.7.4/5.7.4) id f57I49g26546 for linux-xfs@oss.sgi.com; Thu, 7 Jun 2001 14:04:09 -0400 (EDT) From: alan@cotse.com To: linux-xfs@oss.sgi.com Subject: Realtime Section - XFS Message-ID: <991937049.3b1fc21928278@public.webmail.cotse.com> Date: Thu, 07 Jun 2001 14:04:09 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: http://webmail.cotse.com/webmail/ - Public ad free privacy shield. X-Abuse: abuse@cotse.com X-Abuse-Info: http://www.cotse.com/abusepolicies.html Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Has anyone tried to use linux xfs's realtime section support? although not publicised, it is there, just manually add 'CONFIG_XFS_RT' to .config in the root of your kernel sources. I did finally get this to work, on an lvm, mounting /dev/vol/xfs with the option of rtdev=/dev/vol/xfsrt, and at mkfs creation time I did not specify extent size. The realtime device is the same size as the main volume, although I do not think this is necessary per se, they are small, 100M in size, just to test. So far I am looking for as much information I can find about realtime volumes, before building a system that would heavily use them. Would there be any issues with dumping this filesystem? I am not sure, but I believe some attribute needs to be set on files to use the realtime section, as far as speed is concerned. I am still confused a bit on this though, so if someone knows, please let me know. Compiling the kernel with this option went without event, some normal warnings is all. This seems stable, although I do not see why it is not enabled even experimentally in the regular configuration tools. Getting GRIO to work with linux would take more doing I suppose, and is maybe a 2.5.x kernel subject. On an IRIx 6.5 machine, I saw /dev/root mounted with the option 'raw=/dev/rroot'. Is this the realtime section of a IRIX system,.. what looks like a raw device? Any input or help in this arena would be appreciated, I have found precious little information on it. Alan Willis alan@cotse.com From owner-linux-xfs@oss.sgi.com Thu Jun 7 11:14:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57IE6w32333 for linux-xfs-outgoing; Thu, 7 Jun 2001 11:14:06 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57IE5h32323 for ; Thu, 7 Jun 2001 11:14:05 -0700 Received: from auto-nb1.xs4all.nl (perle-wan1.coltex.nl [10.0.1.177]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f57IDxq09331; Thu, 7 Jun 2001 20:13:59 +0200 Message-Id: <4.3.2.7.2.20010607200715.03317a60@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Jun 2001 20:14:03 +0200 To: "Christopher \"C.J.\" Keist" , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: quota support for xfs In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:50 7-6-2001 -0600, Christopher \"C.J.\" Keist wrote: >Hello, > I have installed RH7.1 using SGI installer CD. I have compiled the >kernel to support RAID with Linear support, xfs , quota and xfs quota >support. I then created a file system appending three disks together, the >raidtab file follows: > >raiddev /dev/md0 > raid-level linear > nr-raid-disks 3 > persistent-superblock 1 > chunk-size 4 > device /dev/sdb1 > raid-disk 0 > device /dev/sdc1 > raid-disk 1 > device /dev/sdd1 > raid-disk 2 > > >I was able to create the xfs file system with no problems. I'm now trying >to get user quota to work, but having no luck. Here is how the file sytem >is being mounted in the fstab file: > >/dev/md0 /test xfs rw,usrquota 1 >1 > >I have tried just quota,userquota and usrquota for the mount options, all >seem to work with no errors in mounting, but all behave the same in that >quotas don't work. When I try repquota -v /test I get the following: > >repquota: Not all specified mountpoints are using quota. > >mount command shows the following: According to the experience from someone else on the list in the thread "Red Hat 7.1 and quotas" it is explained. In short: OK, I've had a play with a test machine.... Red Hat 7.1, installed from SGI XFS 1.0 CDROM [root@webpc2 /root]# cat /etc/fstab /dev/hde3 /home xfs defaults,usrquota,grpquota 1 2 [root@webpc2 /root]# quotaon -v /home quotaon: /dev/hde3: Invalid argument quotaon: /dev/hde3: Invalid argument I rebooted anyway, and after the reboot: [root@webpc2 /root]# dmesg|grep quota VFS: Diskquotas version dquot_6.5.0 initialized XFS quotacheck ide2(33,3): Please wait. XFS quotacheck ide2(33,3): Done. [root@webpc2 /root]# repquota -v /dev/hde3 Not all specified mountpoints are using quota. You will need to see the XFS quotacheck in the dmesg output. Check if this helps. >Is all this just telling me that quota support for XFS filesystem on a md >raid device is not supported? It's a file system matter, md is a hardware abstraction layer which doesn't have any idea of what you are trying to write to disk. XFS thinks md is a disk, that is because md acts more or less like a disk. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Jun 7 11:14:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57IE0C32283 for linux-xfs-outgoing; Thu, 7 Jun 2001 11:14:00 -0700 Received: from blipvert.blank.org (blipvert.blank.org [216.112.239.86]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57IDxh32279 for ; Thu, 7 Jun 2001 11:13:59 -0700 Received: (qmail 1462 invoked by uid 500); 7 Jun 2001 18:13:57 -0000 Date: Thu, 7 Jun 2001 14:13:57 -0400 From: "Nathan J. Mehl" To: linux-xfs@oss.sgi.com Subject: RH7.1 ISO: panic on boot after install. Message-ID: <20010607141357.Z8330@blank.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Okay, a quick perusal of the last two months of the list and the FAQ didn't seem to turn up anything like this, so I'm throwing myself at the mercy of the list. The system: homebuilt Athlon 1ghz, Abit KT7 (Via KT133 chipset), IBM DTLA-307075 75Gb IDE hard drive. With a fresh "workstation" install from the SGI RH7.1+xfs 1.0 installer CD, the system panics semi-reliably on boot when it tries to mount the root fs read-write, just after the USB initialization. By "semi-", I mean that it seems to happen about 8 or 9 times out of ten -- every once in a while, I seem to catch a break, and the system actually comes up all the way. So far, I have no notion of what, other than luck, is causing the successful boots. A representative panic follows. If there's any additional information on the system's configuration I can prodide, just ask. CPU: 0 EIP: 0010:[] EFLAGS: 00010092 eax: 0000001b ebx: 00000000 ecx: 00000001 ex: 00000001 esi: 00000000 edi: c02fbe30 ebp: c02fbe18 esp: c02fbdc8 ds 0018 es: 0018 ss: 008 Process swapper (pid: , stackpage=c02fb000) Stack: c0286d3d c0286eb6 00002c3 c1425a84 c02fa000 c02fbe30 00000000 c02fa000 00000002 00000061 000f8920 c01db77f c144e9bc 0000086 00000082 c02fa000 00000046 00000000 c02fa000 c02fa000 c1425aac c01248b2 c1425a84 c1451e0 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [<020675f>] [] [] [] [] [] [] [] [] [] [] [] [] [] [][] Code: 0f 0b 8d 65 bc 5b 5e 5f 89 ec 5d c3 8d 76 00 55 89 e5 83 ec Kernel panic: Aiee,killing interrupt handler In interrupt handler - not syncing ------------------------------------------------------ "Because you humans are stupid, stupid, stupid, stupid, stupid STUPID!" (--Alien Commander, Plan 9 From Outer Space) ---------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Jun 7 11:15:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57IFbl32505 for linux-xfs-outgoing; Thu, 7 Jun 2001 11:15:37 -0700 Received: from amoa.org (amoa.org [207.207.51.226]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57IFah32501 for ; Thu, 7 Jun 2001 11:15:37 -0700 Received: by amoa.org(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256A64.0064511F ; Thu, 7 Jun 2001 13:15:43 -0500 X-Lotus-FromDomain: AMOA From: ctooley@amoa.org To: Florin Andrei cc: linux-xfs@oss.sgi.com Message-ID: <86256A64.00644FF1.00@amoa.org> Date: Thu, 7 Jun 2001 13:15:39 -0500 Subject: Re: growing a partition Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I grew the / partition on my harddrive. The key is that the beginning of the partition cannot move but the end can (I would love to be proven wrong). If you are using the x86 platform like I am and you want to make the partition you using larger, you need to create some empty disk space after your XFS partition. Then you can (I'm not going to write a HOWTO because this part is dangerous) just make your partition larger by using FDISK. Delete the partition with fdisk and create it, making sure to use the same starting point you had used before. Since this only changes the partition table you should be fine. Be forwarned though that editing the partition table can lead to lots of migraines. I had no trouble with mine. After you have rebooted (if you change the partition that / lives on it's going to not be reported right until you reboot) you can just type "xfs_growfs /" at the prompt and it will magically make space for you. It made my partition 4 gig larger in the span of a few seconds. Hope this helps Chris Tooley Florin Andrei on 06/07/2001 01:02:13 PM To: linux-xfs@oss.sgi.com cc: (bcc: Chris Tooley/AMOA) Subject growing a partition : Is there any HOWTO on growing an XFS partition under Linux? Is is possible to do this for the / partition? -- Florin Andrei From owner-linux-xfs@oss.sgi.com Thu Jun 7 11:25:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57IPHb01464 for linux-xfs-outgoing; Thu, 7 Jun 2001 11:25:17 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57IPEh01445 for ; Thu, 7 Jun 2001 11:25:14 -0700 Received: from auto-nb1.xs4all.nl (perle-wan1.coltex.nl [10.0.1.177]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f57IP4q09339; Thu, 7 Jun 2001 20:25:04 +0200 Message-Id: <4.3.2.7.2.20010607202155.03316008@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Jun 2001 20:25:08 +0200 To: Florin Andrei , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: growing a partition In-Reply-To: <991936933.3442.0.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:02 7-6-2001 -0700, Florin Andrei wrote: >Is there any HOWTO on growing an XFS partition under Linux? See the mail archive list. There are examples in there. >Is is possible to do this for the / partition? If there is free space behind it yes, otherwise no. It needs to be a contigous part of the disk. lvm makes this easier. There were some issues with resizing multiple times AFAIK. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Jun 7 11:37:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57IbKw02562 for linux-xfs-outgoing; Thu, 7 Jun 2001 11:37:20 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57IbJh02558 for ; Thu, 7 Jun 2001 11:37:19 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f57Ib7d28418 for linux-xfs@oss.sgi.com; Thu, 7 Jun 2001 14:37:07 -0400 Date: Thu, 7 Jun 2001 14:37:06 -0400 From: Alan Eldridge To: linux-xfs@oss.sgi.com Subject: Building RH kernel + patches Message-ID: <20010607143706.A28415@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'd like to rebuild RH's current rawhide kernel SRPM, but with the 2.4.5 XFS patches applied ... I'm getting sick of __alloc_pages() failed, and "Out of memory: Killing process nnnn". However, it appears that the XFS patch includes *some* of the RH patches. Is there any clear way to determine which RH patches I want to keep, and which are already applied, *and* where in the sequence I want to apply the XFS patch? I'm starting to look through the patches manually, but that's going to really suck. Please tell me there's a better way. -- Alan Eldridge "Uh, I think so, Brain, but isn't Regis Philbin already married?" From owner-linux-xfs@oss.sgi.com Thu Jun 7 11:48:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57ImIo03511 for linux-xfs-outgoing; Thu, 7 Jun 2001 11:48:18 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57Im5h03499 for ; Thu, 7 Jun 2001 11:48:05 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA1764567 for ; Thu, 7 Jun 2001 20:48:02 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2093628; Thu, 7 Jun 2001 13:46:45 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA00374; Thu, 7 Jun 2001 13:46:44 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f57IneL29201; Thu, 7 Jun 2001 13:49:40 -0500 Message-Id: <200106071849.f57IneL29201@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: alan@cotse.com cc: linux-xfs@oss.sgi.com Subject: Re: Realtime Section - XFS In-Reply-To: Message from alan@cotse.com of "Thu, 07 Jun 2001 14:04:09 EDT." <991937049.3b1fc21928278@public.webmail.cotse.com> Date: Thu, 07 Jun 2001 13:49:40 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The realtime subvolume is indeed there on Linux, you can make them, mount them, if you know the correct ioctl call you can make an inode realtime, it is XFS_IOC_FSSETXATTR, and you need to pass in a struct fsxattr with fsx_xflags set to XFS_XFLAG_REALTIME and fsx_extsize set to some value (the unit of allocation for realtime space). HOWEVER, if you do I/O to this inode then you will hit the wrong partition on the disk and corrupt your filesystem. I have some code which I think will fix this, but I have not had a chance to test it yet - it does not break the rest of xfs though. Even with this code you will have to use direct I/O. I can package up the code if someone wants to play with it - it should not corrupt other filesystems, but it could well crash your box. I am not ready to check it into the tree yet. And yes, GRIO is a lot more work, and I would debate it being worth the effort except as an academic exercise for people who like coding. Steve > > Has anyone tried to use linux xfs's realtime section support? although > not > publicised, it is there, just manually add 'CONFIG_XFS_RT' to .config in the > root of your kernel sources. I did finally get this to work, on an lvm, > mounting /dev/vol/xfs with the option of rtdev=/dev/vol/xfsrt, and at mkfs > creation time I did not specify extent size. The realtime device is the same > size as the main volume, although I do not think this is necessary per se, th > ey > are small, 100M in size, just to test. So far I am looking for as much > information I can find about realtime volumes, before building a system that > would heavily use them. Would there be any issues with dumping this filesyst > em? > I am not sure, but I believe some attribute needs to be set on files to use t > he > realtime section, as far as speed is concerned. I am still confused a bit on > this though, so if someone knows, please let me know. Compiling the kernel w > ith > this option went without event, some normal warnings is all. This seems stab > le, > although I do not see why it is not enabled even experimentally in the regula > r > configuration tools. Getting GRIO to work with linux would take more doing I > suppose, and is maybe a 2.5.x kernel subject. On an IRIx 6.5 machine, I saw > /dev/root mounted with the option 'raw=/dev/rroot'. Is this the realtime sect > ion > of a IRIX system,.. what looks like a raw device? > > Any input or help in this arena would be appreciated, I have found precious > little information on it. > > Alan Willis > alan@cotse.com From owner-linux-xfs@oss.sgi.com Thu Jun 7 12:11:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57JBk405881 for linux-xfs-outgoing; Thu, 7 Jun 2001 12:11:46 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57JBih05877 for ; Thu, 7 Jun 2001 12:11:45 -0700 Received: from auto-nb1.xs4all.nl (perle-wan1.coltex.nl [10.0.1.177]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f57JBZq09398; Thu, 7 Jun 2001 21:11:36 +0200 Message-Id: <4.3.2.7.2.20010607210041.033154a0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Jun 2001 21:11:39 +0200 To: Alan Eldridge , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Building RH kernel + patches Cc: cattelan@thebarn.com In-Reply-To: <20010607143706.A28415@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 14:37 7-6-2001 -0400, Alan Eldridge wrote: >I'd like to rebuild RH's current rawhide kernel SRPM, but with the 2.4.5 XFS >patches applied ... I'm getting sick of __alloc_pages() failed, and "Out of >memory: Killing process nnnn". > >However, it appears that the XFS patch includes *some* of the RH patches. >Is there any clear way to determine which RH patches I want to keep, and >which are already applied, *and* where in the sequence I want to apply the >XFS patch? > >I'm starting to look through the patches manually, but that's going to >really suck. Please tell me there's a better way. Good question, I believe Russel Catalan originally did the 2.4.2-XFS kernel that came on the 1.0 installer disk. I think he would be the one to ask. There were over 200 patches in the 2.4.2 RH 7.1 kernel so I have no idea were to begin. The 2.4.5 is a vanilla tree with xfs and things like kdb added. There might a few things duplicate. I can imagine that RH included some of the other SGI patches like High availabilty. Just guessing here. My best guess would be to start with a 2.4.5 xfs tree and start applying the more harmless patches like added drivers or obvious fixes and see what you end up with. Good luck -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Jun 7 12:19:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57JJkn06990 for linux-xfs-outgoing; Thu, 7 Jun 2001 12:19:46 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57JJjh06986 for ; Thu, 7 Jun 2001 12:19:45 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA01171 for ; Thu, 7 Jun 2001 12:19:43 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2090662; Thu, 7 Jun 2001 14:18:26 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA57869; Thu, 7 Jun 2001 14:18:26 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f57JLMI29668; Thu, 7 Jun 2001 14:21:22 -0500 Message-Id: <200106071921.f57JLMI29668@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Seth Mos cc: Alan Eldridge , linux-xfs@oss.sgi.com, cattelan@thebarn.com Subject: Re: Building RH kernel + patches In-Reply-To: Message from Seth Mos of "Thu, 07 Jun 2001 21:11:39 +0200." <4.3.2.7.2.20010607210041.033154a0@pop.xs4all.nl> Date: Thu, 07 Jun 2001 14:21:21 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Someone said rawhide now has 2.4.5 based kernel rpms, I have no idea what is in them. It is probably a lot simpler to do this from an xfs base which does not have kdb in it. You can get rid of kdb by reverse applying the latest kdb patch from oss.sgi.com/projects/kdb. Steve > At 14:37 7-6-2001 -0400, Alan Eldridge wrote: > >I'd like to rebuild RH's current rawhide kernel SRPM, but with the 2.4.5 XFS > >patches applied ... I'm getting sick of __alloc_pages() failed, and "Out of > >memory: Killing process nnnn". > > > >However, it appears that the XFS patch includes *some* of the RH patches. > >Is there any clear way to determine which RH patches I want to keep, and > >which are already applied, *and* where in the sequence I want to apply the > >XFS patch? > > > >I'm starting to look through the patches manually, but that's going to > >really suck. Please tell me there's a better way. > > Good question, I believe Russel Catalan originally did the 2.4.2-XFS kernel > that came on the 1.0 installer disk. I think he would be the one to ask. > There were over 200 patches in the 2.4.2 RH 7.1 kernel so I have no idea > were to begin. > > The 2.4.5 is a vanilla tree with xfs and things like kdb added. There might > a few things duplicate. > I can imagine that RH included some of the other SGI patches like High > availabilty. > Just guessing here. > > My best guess would be to start with a 2.4.5 xfs tree and start applying > the more harmless patches like added drivers or obvious fixes and see what > you end up with. > > Good luck > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Jun 7 12:20:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57JKVl07128 for linux-xfs-outgoing; Thu, 7 Jun 2001 12:20:31 -0700 Received: from cotse.com (packetderm.cotse.com [216.112.42.58]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57JKUh07125 for ; Thu, 7 Jun 2001 12:20:30 -0700 Received: (from nobody@localhost) by cotse.com (5.7.4/5.7.4) id f57JJFo03815 for linux-xfs@oss.sgi.com; Thu, 7 Jun 2001 15:19:15 -0400 (EDT) From: alan@cotse.com To: linux-xfs@oss.sgi.com Subject: Re: Realtime Section - XFS Message-ID: <991941555.3b1fd3b31a472@public.webmail.cotse.com> Date: Thu, 07 Jun 2001 15:19:15 -0400 (EDT) References: <200106071849.f57IneL29201@jen.americas.sgi.com> In-Reply-To: <200106071849.f57IneL29201@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: http://webmail.cotse.com/webmail/ - Public ad free privacy shield. X-Abuse: abuse@cotse.com X-Abuse-Info: http://www.cotse.com/abusepolicies.html Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Can I use and benefit from an rt section without making a specific inode realtime? Or does it only benefit inodes that have been made 'realtime'. Does it have any specific overall fs performance effect? My test is small, so it is fast anyway. also, is there any size guideline to the sizes of rt sections vs size of the data and log sections? Or does it only matter to the inodes that are used in a realtime fashion? Alan Willis alan@cotse.com Quoting Steve Lord : > > The realtime subvolume is indeed there on Linux, you can make them, > mount > them, if you know the correct ioctl call you can make an inode > realtime, > it is XFS_IOC_FSSETXATTR, and you need to pass in a struct fsxattr > with fsx_xflags set to XFS_XFLAG_REALTIME and fsx_extsize set to some > value (the unit of allocation for realtime space). > > HOWEVER, if you do I/O to this inode then you will hit the wrong > partition > on the disk and corrupt your filesystem. I have some code which I think > will > fix this, but I have not had a chance to test it yet - it does not break > the > rest of xfs though. Even with this code you will have to use direct > I/O. > > I can package up the code if someone wants to play with it - it should > not > corrupt other filesystems, but it could well crash your box. I am not > ready > to check it into the tree yet. > > And yes, GRIO is a lot more work, and I would debate it being worth the > effort > except as an academic exercise for people who like coding. > > Steve > > > > > Has anyone tried to use linux xfs's realtime section support? > although > > not > > publicised, it is there, just manually add 'CONFIG_XFS_RT' to .config > in the > > root of your kernel sources. I did finally get this to work, on an > lvm, > > mounting /dev/vol/xfs with the option of rtdev=/dev/vol/xfsrt, and at > mkfs > > creation time I did not specify extent size. The realtime device is > the same > > size as the main volume, although I do not think this is necessary per > se, th > > ey > > are small, 100M in size, just to test. So far I am looking for as > much > > information I can find about realtime volumes, before building a > system that > > would heavily use them. Would there be any issues with dumping this > filesyst > > em? > > I am not sure, but I believe some attribute needs to be set on files > to use t > > he > > realtime section, as far as speed is concerned. I am still confused a > bit on > > this though, so if someone knows, please let me know. Compiling the > kernel w > > ith > > this option went without event, some normal warnings is all. This > seems stab > > le, > > although I do not see why it is not enabled even experimentally in the > regula > > r > > configuration tools. Getting GRIO to work with linux would take more > doing I > > suppose, and is maybe a 2.5.x kernel subject. On an IRIx 6.5 machine, > I saw > > /dev/root mounted with the option 'raw=/dev/rroot'. Is this the > realtime sect > > ion > > of a IRIX system,.. what looks like a raw device? > > > > Any input or help in this arena would be appreciated, I have found > precious > > little information on it. > > > > Alan Willis > > alan@cotse.com > > > From owner-linux-xfs@oss.sgi.com Thu Jun 7 12:25:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57JPMh08267 for linux-xfs-outgoing; Thu, 7 Jun 2001 12:25:22 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57JPKh08263 for ; Thu, 7 Jun 2001 12:25:20 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f57JP8i29254 for linux-xfs@oss.sgi.com; Thu, 7 Jun 2001 15:25:08 -0400 Date: Thu, 7 Jun 2001 15:25:08 -0400 From: Alan Eldridge To: linux-xfs@oss.sgi.com Subject: Re: Building RH kernel + patches Message-ID: <20010607152508.A29178@wwweasel.geeksrus.net> References: <200106071921.f57JLMI29668@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106071921.f57JLMI29668@jen.americas.sgi.com>; from lord@sgi.com on Thu, Jun 07, 2001 at 02:21:21PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Jun 07, 2001 at 02:21:21PM -0500, Steve Lord wrote: > >Someone said rawhide now has 2.4.5 based kernel rpms, I have no idea what >is in them. It is probably a lot simpler to do this from an xfs base which >does not have kdb in it. You can get rid of kdb by reverse applying the >latest kdb patch from oss.sgi.com/projects/kdb. > FYI, yup it's 2.4.5. Here's the patch list from the spec: ---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<--- Patch1: ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/patch-2.4.5-ac4.bz2 Patch9: linux-2.4.0-test7-pre4-overflow.patch Patch10: linux-2.4.0-nonintconfig.patch Patch11: kernel-2.4-string.patch Patch12: linux-2.3.99-alpha.patch Patch13: linux-2.3.99p3p6-sparc.patch Patch14: linux-2.4.2-aviro-buffer.c.patch Patch15: linux-2.4.3-maxsectors.patch Patch16: linux-2.4.1-quiet.patch Patch17: linux-2.4.1-alphaksyms.patch Patch18: linux-2.4.0-alpha.patch Patch19: linux-2.4.1-brokenmptable.patch ##Patch20: linux-2.4.3-highmemthrottle.patch Patch21: linux-2.2.16-useio.patch Patch22: linux-2.4.0-nohighmemdebug.patch Patch23: linux-2.4.0-netfilter-cpp.patch Patch24: linux-2.4.3-reboot.patch Patch25: linux-2.2.16-rhconfig.patch Patch26: linux-2.4.2-bootmem.diff Patch27: linux-2.4.1-al-loop.patch Patch28: linux-2.4.2-changeloop.patch Patch29: linux-2.4.1-printkbuffer.patch Patch30: linux-2.4.1-realmodepoweroff.patch Patch31: linux-2.4.5-softirq.patch Patch32: linux-2.4.1-devfscross.patch Patch33: linux-2.4.2-req_finished_io.patch ##Patch34: linux-2.4.3-multipath.patch Patch35: linux-2.4.2-blkioctl-sector.patch Patch36: linux-2.4.3-alphaksyms.patch Patch37: linux-2.4.5-hotplug.patch Patch39: linux-2.4.1-scsi-reset.patch Patch43: linux-2.4.2-pge.patch Patch45: linux-2.4.3-irixnfs.patch Patch47: linux-2.4.2-scsi_scan.patch Patch49: linux-2.4.3-linux-abi.patch Patch50: linux-2.4.4-ia64-%{ia64version}-2.diff Patch51: linux-2.4.2-ia64-prototypes.patch Patch52: linux-2.4.4-ia64-fixes.patch Patch53: linux-2.4.1-ia64-swiotlb.patch Patch54: linux-2.4.3-ia64-timers.patch Patch55: linux-2.4.3-ia64-compile.patch Patch56: linux-2.4.3-ia64-unaligned.patch Patch59: linux-2.4.2-bootmem_oom.patch Patch61: linux-2.4.2-byteprofiling.patch Patch62: linux-2.4.2-pid-profiling.patch Patch63: linux-2.4.2-smptimers.patch Patch64: linux-2.4.2-pagecache.patch Patch65: linux-2.4.2-atomic-lookup.patch Patch67: linux-2.4.2-iput-free.patch Patch68: linux-2.4.2-exports-cleanup.patch Patch69: linux-2.4.2-tux-vfs.patch Patch70: linux-2.4.2-atomicalloc.patch Patch72: linux-2.4.2-per-cpu-pages.patch Patch73: linux-2.4.2-tux-process.patch Patch76: linux-2.4.2-vm-1-2-3-gbyte.patch Patch77: linux-2.4.2-vm-readahead.patch Patch78: linux-2.4.2-tux-sysctl.patch Patch79: linux-2.4.2-tux-kstat.patch Patch83: linux-2.4.2-net-exports.patch Patch84: linux-2.4.2-tux-syscall.patch Patch85: linux-2.4.3-bustspinlocks.patch Patch89: linux-2.4.2-cipe.patch Patch90: linux-2.4.2-tux2.patch Patch99: linux-2.4.0-lm_sensors.patch Patch101: linux-2.4.0-qla1280.patch Patch102: linux-2.4.0-sym53-64bit.patch Patch107: linux-2.4.2-drm-silence.patch Patch108: linux-2.4.3-r128-drm-do-wait-for-fifo.patch Patch109: linux-2.4.2-hexblocknumbers.patch Patch110: linux-2.4.1-e100.patch Patch111: linux-2.4.1-e1000.patch Patch114: linux-2.4.0-intelethernet.patch Patch115: linux-2.4.1-aacraid.patch Patch116: linux-2.4.0-test11-vidfail.patch Patch117: linux-2.4.0-e820.patch Patch118: linux-2.4.0-raid5xor.patch Patch124: linux-2.4.0-cipe-1.4.5.patch Patch126: linux-2.4.0-bcm5700.patch Patch128: linux-2.4.0-wvlan-cs.patch Patch135: linux-2.4.2-mem-setup-fix.patch Patch136: linux-2.4.2-page_bitmap.patch Patch143: linux-2.4.0-ide-floppy.patch Patch146: linux-2.4.0-apic-quiet.patch Patch152: linux-2.4.1-setup_delay.patch Patch160: linux-2.4.1-netfilter-addons.patch Patch174: linux-2.4.1-uhci-slab.patch Patch175: linux-2.4.2-i810_audio.patch Patch176: linux-2.4.3-ecc.patch Patch181: linux-2.4.3-rawio.patch Patch185: linux-2.4.3-i82365.patch Patch186: linux-2.4.3-ext3.patch Patch188: linux-2.4.3-elf.patch Patch192: linux-2.4.3-megaraid.patch Patch194: linux-2.4.3-dellmptable.patch Patch195: linux-2.4.1-hp8200.patch Patch196: linux-2.4.1-netdebug.patch Patch199: linux-2.4.3-450gx.patch Patch201: linux-2.4.3-latitudec600.patch Patch203: linux-2.4.2-eepro100-alpha.patch Patch204: linux-2.4.3-pcipenalty.patch Patch206: linux-2.4.3-wakeupspeed.patch Patch207: linux-2.4.3-ecn.patch Patch213: linux-2.4.2-alternateairo.patch Patch215: linux-2.4.3-brlock.patch ##Patch230: linux-2.4.3-ia64-tlb-shootdown-revert.patch Patch232: linux-2.4.3-nautilus.patch Patch233: linux-2.4.2-ideblacklist.patch ##Patch234: linux-2.4.3-page_table_races.patch ##Patch239: linux-2.4.2-usb-uhci-slab.patch Patch240: linux-2.4.5-lowlat.patch Patch241: linux-2.4.5-eepro100.patch Patch242: linux-2.4.5-vmloop.patch Patch248: linux-2.4.2-usb-scsiglue.patch Patch249: linux-2.4.2-keyboardsilence.patch Patch250: linux-2.4.3-dma-livelock.patch Patch255: linux-2.4.3-upapic.patch Patch257: linux-2.4.2-osb4.patch Patch258: linux-2.4.3-ac12-usb_ksem.patch Patch259: linux-2.4.2-viadma66.patch Patch261: linux-2.4.3-pcnet32.patch Patch263: linux-2.4.2-usbthrottle.patch Patch264: linux-2.4.3-sb.patch Patch265: linux-2.4.2-ohci-irq.patch Patch266: linux-2.4.3-sysrq.patch Patch269: linux-2.4.3-emu10k.patch Patch270: linux-2.4.2-llrwblk.patch Patch271: linux-2.4.3-usb.patch Patch272: linux-2.4.2-vmpoison.patch Patch273: linux-2.4.1-debugging.patch Patch274: linux-2.4.1-ikd.patch Patch275: linux-2.4.2-smbdebug.patch Patch276: linux-2.4.3-swapspeed.patch Patch278: linux-2.4.3-smp_call_function.patch Patch290: linux-2.4.0-ipvs.patch Patch291: linux-2.4.2-ipvs.patch Patch292: linux-2.4.3-ipvs-0.2.11.patch Patch296: linux-2.4.2-swapreclaim.patch Patch297: linux-2.4.3-vmlockup.patch Patch400: linux-2.4.0-sard.patch Patch401: linux-2.4.1-compilefailure.patch Patch402: linux-2.4.2-rqdebug.patch Patch403: linux-2.4.2-ia64-compilefix.patch Patch404: linux-2.4.3-sysrqT-cpu.patch ---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<--- -- Alan Eldridge "Uh, I think so, Brain, but isn't Regis Philbin already married?" From owner-linux-xfs@oss.sgi.com Thu Jun 7 12:26:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57JQ0d08407 for linux-xfs-outgoing; Thu, 7 Jun 2001 12:26:00 -0700 Received: from mercury.pricegrabber.com ([64.70.41.138]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57JPxh08403 for ; Thu, 7 Jun 2001 12:25:59 -0700 Received: from pricegrabber.com (noc.pricegrabber.com [24.8.138.101] (may be forged)) (authenticated) by mercury.pricegrabber.com (8.11.2/8.11.2) with ESMTP id f57JQfl05120 for ; Thu, 7 Jun 2001 12:26:41 -0700 Message-ID: <3B1FD546.4030105@pricegrabber.com> Date: Thu, 07 Jun 2001 12:25:58 -0700 From: Christopher McCrory Organization: PriceGrabber.com User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-0.2.9smp i686; en-US; rv:0.9.1+) Gecko/20010606 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Building RH kernel + patches References: <4.3.2.7.2.20010607210041.033154a0@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello... Seth Mos wrote: > At 14:37 7-6-2001 -0400, Alan Eldridge wrote: > >> I'd like to rebuild RH's current rawhide kernel SRPM, but with the >> 2.4.5 XFS > Good question, I believe Russel Catalan originally did the 2.4.2-XFS > kernel that came on the 1.0 installer disk. I think he would be the one > to ask. > There were over 200 patches in the 2.4.2 RH 7.1 kernel so I have no idea > were to begin. I was planing to give this a shot over the weekend. So, if anyone gets some initial answers, a post would be cool so everyone doen't have to reinvent the wheel. RedHat is keeping up on the latest kernels in their rawhide tree. The latest drop, IIRC, added ext3. If there was a set of patches and config changes, and several people asked real nice, maybe they would also put xfs in their next rawhide kernel. Is anyone from redhat on this list? -- Christopher McCrory "The guy that keeps the servers running" chrismcc@pricegrabber.com http://www.pricegrabber.com I don't make jokes in base 13. Anyone who does should get help. --Douglas Adams From owner-linux-xfs@oss.sgi.com Thu Jun 7 12:37:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57JbCm10348 for linux-xfs-outgoing; Thu, 7 Jun 2001 12:37:12 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57JbAh10341 for ; Thu, 7 Jun 2001 12:37:11 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f57Jawn29394 for linux-xfs@oss.sgi.com; Thu, 7 Jun 2001 15:36:58 -0400 Date: Thu, 7 Jun 2001 15:36:58 -0400 From: Alan Eldridge To: linux-xfs@oss.sgi.com Subject: Re: Building RH kernel + patches Message-ID: <20010607153658.A29391@wwweasel.geeksrus.net> References: <200106071921.f57JLMI29668@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106071921.f57JLMI29668@jen.americas.sgi.com>; from lord@sgi.com on Thu, Jun 07, 2001 at 02:21:21PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Jun 07, 2001 at 02:21:21PM -0500, Steve Lord wrote: > >Someone said rawhide now has 2.4.5 based kernel rpms, I have no idea what >is in them. It is probably a lot simpler to do this from an xfs base which >does not have kdb in it. You can get rid of kdb by reverse applying the >latest kdb patch from oss.sgi.com/projects/kdb. I'm using the 2.4.5 patch from 06042001 *not* cvs. latest kdb does not reverse apply. help? -- Alan Eldridge "Uh, I think so, Brain, but isn't Regis Philbin already married?" From owner-linux-xfs@oss.sgi.com Thu Jun 7 12:38:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57Jcro10744 for linux-xfs-outgoing; Thu, 7 Jun 2001 12:38:53 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57Jcqh10733 for ; Thu, 7 Jun 2001 12:38:52 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA10968 for ; Thu, 7 Jun 2001 12:38:50 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2091545; Thu, 7 Jun 2001 14:37:34 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA32272; Thu, 7 Jun 2001 14:37:34 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f57JeTH30113; Thu, 7 Jun 2001 14:40:29 -0500 Message-Id: <200106071940.f57JeTH30113@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: alan@cotse.com cc: linux-xfs@oss.sgi.com Subject: Re: Realtime Section - XFS In-Reply-To: Message from alan@cotse.com of "Thu, 07 Jun 2001 15:19:15 EDT." <991941555.3b1fd3b31a472@public.webmail.cotse.com> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-9316523520" Date: Thu, 07 Jun 2001 14:40:29 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multipart MIME message. --==_Exmh_-9316523520 Content-Type: text/plain > > Can I use and benefit from an rt section without making a specific inod > e > realtime? Or does it only benefit inodes that have been made 'realtime'. Do > es > it have any specific overall fs performance effect? My test is small, so it > is > fast anyway. also, is there any size guideline to the sizes of rt sections vs > size of the data and log sections? Or does it only matter to the inodes that > are used in a realtime fashion? > > Alan Willis > alan@cotse.com > The realtime subvolume is where data for realtime inodes is allocated, so yes it only applies to those. Create a new file, make it realtime, and then do I/O to it. Realtime is a little bit of a misnomer, the differences are: o There is only data in the partition, all metadata remains the the data subvolume. If you put the partitions in the correct place then the only time headseeks happen is to go and get actual data, no log or metadata I/O to get in the way. o A different space allocator is used, it uses a binary chop type approach to disk space which is wasteful, but which means it is very hard to fragment the files on realtime partitions. This allocator is also faster and tends to allocate space in a more deterministic amount of time. o When you make the filesystem, and when you create a realtime file via the ioctl call you can specify an extent size, all allocations will be a multiple of this. I have my doubts that this will work as advertised yet on linux. These are all supposed to add up to something which is good for doing streaming I/O, typically of very large files such as video data. Here are the changes I have to at least attempt to send disk I/O to the realtime device. Users of realtime on Irix would probably create a filesystem which was almost all realtime space, you still need the regular partition for the log and the metadata. Steve --==_Exmh_-9316523520 Content-Type: application/x-patch ; name="realtime.patch" Content-Description: realtime.patch Content-Disposition: attachment; filename="realtime.patch" =========================================================================== Index: linux/fs/pagebuf/page_buf_io.c =========================================================================== --- /usr/tmp/TmpDir.30093-0/linux/fs/pagebuf/page_buf_io.c_1.79 Thu Jun 7 14:35:09 2001 +++ linux/fs/pagebuf/page_buf_io.c Thu Jun 7 14:37:24 2001 @@ -349,6 +349,7 @@ return 0; } + pb->pb_dev = mp->pbm_dev; pb->pb_bn = mp->pbm_bn + (mp->pbm_delta >> inode->i_sb->s_blocksize_bits); @@ -767,7 +768,7 @@ BUG(); } if (!page->buffers) - create_empty_buffers(page, inode->i_dev, PAGE_CACHE_SIZE); + create_empty_buffers(page, mp->pbm_dev, PAGE_CACHE_SIZE); bh = page->buffers; /* * pbm_offset:pbm_bn :: (page's offset):??? =========================================================================== Index: linux/fs/xfs/linux/xfs_lrw.c =========================================================================== --- /usr/tmp/TmpDir.30093-0/linux/fs/xfs/linux/xfs_lrw.c_1.100 Thu Jun 7 14:35:09 2001 +++ linux/fs/xfs/linux/xfs_lrw.c Thu May 31 14:50:43 2001 @@ -336,6 +336,10 @@ XFS_ILOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD); return error; } + if (io->io_flags & XFS_IOCORE_RT) { + pb->pb_dev = mp->m_rtdev; + } + if ((imap.br_startblock > 0) && (imap.br_startblock != DELAYSTARTBLOCK)) { pb->pb_bn = XFS_FSB_TO_DB_IO(io, imap.br_startblock); @@ -1212,7 +1216,11 @@ nisize = io->io_new_size; for (im=0, pbm=0; im < imaps && pbm < pbmaps; im++,pbmapp++,imap++,pbm++) { - + if (io->io_flags & XFS_IOCORE_RT) { + pbmapp->pbm_dev = mp->m_rtdev; + } else { + pbmapp->pbm_dev = mp->m_dev; + } pbmapp->pbm_offset = XFS_FSB_TO_B(mp, imap->br_startoff); pbmapp->pbm_delta = offset - pbmapp->pbm_offset; pbmapp->pbm_bsize = XFS_FSB_TO_B(mp, imap->br_blockcount); =========================================================================== Index: linux/include/linux/page_buf.h =========================================================================== --- /usr/tmp/TmpDir.30093-0/linux/include/linux/page_buf.h_1.91 Thu Jun 7 14:35:10 2001 +++ linux/include/linux/page_buf.h Wed Jun 6 12:56:59 2001 @@ -77,7 +77,6 @@ * Base types */ -/* typedef unsigned long page_buf_daddr_t;*/ /* disk address in blocks */ /* daddr must be signed since -1 is used for bmaps that are not yet allocated */ typedef loff_t page_buf_daddr_t; @@ -125,6 +124,7 @@ typedef struct page_buf_bmap_s { page_buf_daddr_t pbm_bn; /* block number in file system */ + kdev_t pbm_dev; /* device for I/O */ loff_t pbm_offset; /* byte offset of mapping in file */ size_t pbm_delta; /* offset of request into bmap */ size_t pbm_bsize; /* size of this mapping in bytes */ --==_Exmh_-9316523520-- From owner-linux-xfs@oss.sgi.com Thu Jun 7 12:58:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57JwB912996 for linux-xfs-outgoing; Thu, 7 Jun 2001 12:58:11 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57JwAh12993 for ; Thu, 7 Jun 2001 12:58:10 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f57Jw1aJ032348; Thu, 7 Jun 2001 14:58:01 -0500 (CDT) Message-ID: <3B1FDCC3.2B9FE159@thebarn.com> Date: Thu, 07 Jun 2001 14:57:56 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: Alan Eldridge , linux-xfs@oss.sgi.com Subject: Re: Building RH kernel + patches References: <4.3.2.7.2.20010607210041.033154a0@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > At 14:37 7-6-2001 -0400, Alan Eldridge wrote: > >I'd like to rebuild RH's current rawhide kernel SRPM, but with the 2.4.5 XFS > >patches applied ... I'm getting sick of __alloc_pages() failed, and "Out of > >memory: Killing process nnnn". > > > >However, it appears that the XFS patch includes *some* of the RH patches. > >Is there any clear way to determine which RH patches I want to keep, and > >which are already applied, *and* where in the sequence I want to apply the > >XFS patch? All the RH are applied in the RH7.1 rpms > > > >I'm starting to look through the patches manually, but that's going to > >really suck. Please tell me there's a better way. > > Good question, I believe Russel Catalan originally did the 2.4.2-XFS kernel > that came on the 1.0 installer disk. I think he would be the one to ask. > There were over 200 patches in the 2.4.2 RH 7.1 kernel so I have no idea > were to begin. > > The 2.4.5 is a vanilla tree with xfs and things like kdb added. There might > a few things duplicate. > I can imagine that RH included some of the other SGI patches like High > availabilty. > Just guessing here. > > My best guess would be to start with a 2.4.5 xfs tree and start applying > the more harmless patches like added drivers or obvious fixes and see what > you end up with. OK so I was going to work on bathroom but hey what the hell. I have the devel tree and the RH rawhide merged I just have to walk through the files and resolve the conflicts. If I can get it done in an hour so I'll send a patch. > > > > Good luck > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Thu Jun 7 13:39:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57KdKl16169 for linux-xfs-outgoing; Thu, 7 Jun 2001 13:39:20 -0700 Received: from cotse.com (packetderm.cotse.com [216.112.42.58]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57KdJh16161 for ; Thu, 7 Jun 2001 13:39:19 -0700 Received: (from nobody@localhost) by cotse.com (5.7.4/5.7.4) id f57Kc1J08907; Thu, 7 Jun 2001 16:38:01 -0400 (EDT) From: alan@cotse.com To: Steve Lord Subject: Re: Realtime Section - XFS Message-ID: <991946281.3b1fe6299bd51@public.webmail.cotse.com> Date: Thu, 07 Jun 2001 16:38:01 -0400 (EDT) Cc: linux-xfs@oss.sgi.com References: <200106071940.f57JeTH30113@jen.americas.sgi.com> In-Reply-To: <200106071940.f57JeTH30113@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: http://webmail.cotse.com/webmail/ - Public ad free privacy shield. X-Abuse: abuse@cotse.com X-Abuse-Info: http://www.cotse.com/abusepolicies.html Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Are there userspace utilities to enable this realtime inode io behavior? Quoting Steve Lord : > > > > Can I use and benefit from an rt section without making a specific > inod > > e > > realtime? Or does it only benefit inodes that have been made > 'realtime'. Do > > es > > it have any specific overall fs performance effect? My test is small, > so it > > is > > fast anyway. also, is there any size guideline to the sizes of rt > sections vs > > size of the data and log sections? Or does it only matter to the > inodes that > > are used in a realtime fashion? > > > > Alan Willis > > alan@cotse.com > > > > The realtime subvolume is where data for realtime inodes is allocated, > so yes > it only applies to those. Create a new file, make it realtime, and then > do > I/O to it. Realtime is a little bit of a misnomer, the differences > are: > > o There is only data in the partition, all metadata remains the the > data > subvolume. If you put the partitions in the correct place then the > only > time headseeks happen is to go and get actual data, no log or > metadata > I/O to get in the way. > > o A different space allocator is used, it uses a binary chop type > approach > to disk space which is wasteful, but which means it is very hard to > > fragment the files on realtime partitions. This allocator is also > faster > and tends to allocate space in a more deterministic amount of > time. > > o When you make the filesystem, and when you create a realtime file > via the > ioctl call you can specify an extent size, all allocations will be > a > multiple of this. I have my doubts that this will work as > advertised yet > on linux. > > These are all supposed to add up to something which is good for doing > streaming > I/O, typically of very large files such as video data. > > Here are the changes I have to at least attempt to send disk I/O to the > > realtime device. > > Users of realtime on Irix would probably create a filesystem which was > almost > all realtime space, you still need the regular partition for the log and > the > metadata. > > Steve > > > > From owner-linux-xfs@oss.sgi.com Thu Jun 7 13:40:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57Kefe16316 for linux-xfs-outgoing; Thu, 7 Jun 2001 13:40:41 -0700 Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57Keeh16311 for ; Thu, 7 Jun 2001 13:40:40 -0700 Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA12336 for ; Thu, 7 Jun 2001 13:40:24 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id NAA11495 for ; Thu, 7 Jun 2001 13:40:39 -0700 (PDT) Received: from pipcws.ca.boeing.com by blv-hub-01.boeing.com with ESMTP; Thu, 7 Jun 2001 13:40:30 -0700 Received: from pipcws.ca.boeing.com (e218766.evt.boeing.com [136.203.14.68]) by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id NAA22126; Thu, 7 Jun 2001 13:40:29 -0700 Message-Id: <3B1FE6C0.6050609@pipcws.ca.boeing.com> Date: Thu, 07 Jun 2001 13:40:32 -0700 From: Ric Tibbetts User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9) Gecko/20010505 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Seth Mos CC: Florin Andrei , linux-xfs@oss.sgi.com Subject: Re: growing a partition References: <4.3.2.7.2.20010607202155.03316008@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > At 11:02 7-6-2001 -0700, Florin Andrei wrote: > >> Is there any HOWTO on growing an XFS partition under Linux? > > > See the mail archive list. There are examples in there. > >> Is is possible to do this for the / partition? > > > If there is free space behind it yes, otherwise no. > It needs to be a contigous part of the disk. > lvm makes this easier. There were some issues with resizing multiple LVM is the answer to this. This is exactly what it's designed for. But, there "were" issues with extending an xfs more than once. I'm hoping they are getting resolved (any word on that?). But that limitation is an XFS issue, not an LVM issue AFAIK. Ric PS: Do yourself a favor. Learn LVM, and convert to it. You'll never go back to partitions again! From owner-linux-xfs@oss.sgi.com Thu Jun 7 13:42:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57Kg9r16488 for linux-xfs-outgoing; Thu, 7 Jun 2001 13:42:09 -0700 Received: from goku.engr.colostate.edu (goku.engr.colostate.edu [129.82.224.16]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57Kg8h16481 for ; Thu, 7 Jun 2001 13:42:08 -0700 Received: from trunks (trunks.engr.colostate.edu [129.82.226.114]) by goku.engr.colostate.edu (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f57Kg5OT013173; Thu, 7 Jun 2001 14:42:06 -0600 (MDT) Date: Thu, 7 Jun 2001 14:41:53 -0600 (MDT) From: "Christopher \"C.J.\" Keist" X-Sender: cjay@trunks To: Greg Wildman cc: linux-xfs@oss.sgi.com Subject: Re: quota support for xfs In-Reply-To: <991936997.17518.22.camel@charon.gjw.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Still no luck. I put in the changes on the fs/dquot.c file, the repquota looks to be already patched with the 3.01-pre6 release. Here is the File system setup from the .config file in the Linux kernel source tree: # # File systems # CONFIG_QUOTA=y CONFIG_FS_POSIX_ACL=y CONFIG_AUTOFS_FS=y CONFIG_AUTOFS4_FS=y CONFIG_REISERFS_FS=y # CONFIG_REISERFS_CHECK is not set # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y # CONFIG_UMSDOS_FS is not set CONFIG_VFAT_FS=y # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_TMPFS is not set # CONFIG_RAMFS is not set CONFIG_ISO9660_FS=y # CONFIG_JOLIET is not set # CONFIG_MINIX_FS is not set CONFIG_NTFS_FS=y # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_UDF_FS is not set # CONFIG_UFS_FS is not set CONFIG_PAGE_BUF=y CONFIG_XFS_FS=y CONFIG_XFS_DMAPI=y CONFIG_XFS_QUOTA=y # CONFIG_XFS_DEBUG is not set # CONFIG_XFS_VNODE_TRACING is not set I don't seem to be getting any quotacheck on boot up: [root@strife linux-2.4.2]# dmesg | egrep -i quota VFS: Diskquotas version dquot_6.5.0 initialized C. J. Keist Email: cjay@engr.colostate.edu UNIX/Network Manager Phone: 970-491-0630 Engineering Network Services Fax: 970-491-2465 College of Engineering, CSU Ft. Collins, CO 80523-1301 On 7 Jun 2001, Greg Wildman wrote: > On 07 Jun 2001 11:50:18 -0600, Christopher "C.J." Keist wrote: > > Hello, > > I have installed RH7.1 using SGI installer CD. I have compiled the > > kernel to support RAID with Linear support, xfs , quota and xfs quota > > support. I then created a file system appending three disks together, the > > raidtab file follows: > > > > ..snip.. > > > > > > I was able to create the xfs file system with no problems. I'm now trying > > to get user quota to work, but having no luck. Here is how the file sytem > > is being mounted in the fstab file: > > > > /dev/md0 /test xfs rw,usrquota 1 > > 1 > > > > I have tried just quota,userquota and usrquota for the mount options, all > > seem to work with no errors in mounting, but all behave the same in that > > quotas don't work. When I try repquota -v /test I get the following: > > > > repquota: Not all specified mountpoints are using quota. > > > > mount command shows the following: > > > > [root@strife /etc]# mount > > /dev/sda1 on / type ext2 (rw) > > none on /proc type proc (rw) > > none on /dev/pts type devpts (rw,gid=5,mode=620) > > /dev/md0 on /test type xfs (rw,usrquota) > > > > setquota does the following: > > > > [root@strife /etc]# setquota jeremy 50000 55000 5000 5100 /test > > setquota: Not all specified mountpoints are using quota. > > > > I have also downloaded and compiled/install quota-tools-3.01-pre6, still > > no luck. Doing strings on the quota commands do show that xfs support is > > there: > > > > [root@strife quota]# strings /usr/sbin/setquota | egrep xfs > > xfs - XFS quota format > > /proc/fs/xfs/stat > > > > Is all this just telling me that quota support for XFS filesystem on a md > > raid device is not supported? > > You must have missed my earlier post, so I will repeat it again below; > > There were a few problems running quotas using the SGI RedHat 7.1 iso. > There is a patch for the kernel at > http://linux-xfs.sgi.com/projects/xfs/mail_archive/0105/msg00246.html > > and a patch for the repquota command at > http://linux-xfs.sgi.com/projects/xfs/mail_archive/0105/msg00252.html > > I have recompiled both SRPMS with the patches added and all is working > great. I won't post the patches and spec file here as they are quite > large, but drop me a note if you want me to make them available for > download. > > -- > Greg > > Kent's Heuristic: > Look for it first where you'd most like to find it. > From owner-linux-xfs@oss.sgi.com Thu Jun 7 14:33:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57LXZF20798 for linux-xfs-outgoing; Thu, 7 Jun 2001 14:33:35 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57LXYh20794 for ; Thu, 7 Jun 2001 14:33:34 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip89.idcomm.com [209.60.72.216] (may be forged)) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f57LgSU20369 for ; Thu, 7 Jun 2001 15:42:28 -0600 Message-ID: <3B1FF352.1584B604@idcomm.com> Date: Thu, 07 Jun 2001 15:34:10 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: mkinitrd.xfs, floppies Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Reading one of the HOWTO's out there, I gather that mkinitrd.xfs is only required when xfs is being used as a module, but not if xfs is compiled directly into the kernel. Is this correct? Will mkinitrd.xfs work on non-xfs kernels as well (excluding the fact that it wouldn't do anything useful)? The same HOWTO indicates the lilo.conf line: append="ramdisk_size=25000" I gather that this should only be done under the circumstances that the kernel will be using xfs as modules rather than built-in. There is also an initial ramdisk size as an option during kernel compile, for default size, which I recall was something like 4096. Will this work as a means to avoid having to add the "ramdisk_size=25000" line in lilo.conf when using xfs as a module? Second, when compiling and getting the note about the image being too large for a floppy, I'm wondering if compiling xfs as a module would make any difference in this, since the ramdisk would itself need to be part of the floppy as well? If a floppy is not possible, are most people using the CDROM ISO image as backup instead? Just wondering what the options are for having an alternate means of booting in case of failure. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Thu Jun 7 14:46:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57LkX821984 for linux-xfs-outgoing; Thu, 7 Jun 2001 14:46:33 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57LkVh21981 for ; Thu, 7 Jun 2001 14:46:32 -0700 Received: from auto-nb1.xs4all.nl (perle-wan1.coltex.nl [10.0.1.177]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f57LkJq09575; Thu, 7 Jun 2001 23:46:20 +0200 Message-Id: <4.3.2.7.2.20010607232317.033e6d10@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Jun 2001 23:46:22 +0200 To: Ric Tibbetts From: Seth Mos Subject: Re: growing a partition Cc: Florin Andrei , linux-xfs@oss.sgi.com In-Reply-To: <3B1FE6C0.6050609@pipcws.ca.boeing.com> References: <4.3.2.7.2.20010607202155.03316008@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:40 7-6-2001 -0700, Ric Tibbetts wrote: >Seth Mos wrote: > >>At 11:02 7-6-2001 -0700, Florin Andrei wrote: >> >>>Is there any HOWTO on growing an XFS partition under Linux? >> >>See the mail archive list. There are examples in there. >> >>>Is is possible to do this for the / partition? >> >>If there is free space behind it yes, otherwise no. >>It needs to be a contigous part of the disk. >>lvm makes this easier. There were some issues with resizing multiple > > >LVM is the answer to this. This is exactly what it's designed for. But, >there "were" issues with extending an xfs more than once. I'm hoping they >are getting resolved (any word on that?). But that limitation is an XFS >issue, not an LVM issue AFAIK. Workaround: after each xfs_growfs run xfs_repair. repeat. off topic: Still need to bite the bullet on using lvm myself. Oh well next new server on which I can practice this is not far away. It's either a server or a fat disk array that will be crossing my path so I can go practice. It will be hosting progress databases on a XFS filesystem. First tests with either Progress 8.3c or 9.1B under linux with XFS are a few months away. If those tests are positive it will be used for the production machine. It's because the old server is a NCR MP-RAS (yuk!) which is on ia32, has 2GB file limits, Uses a Veritas filesystem that magically changes owners on files, is dog slow, is near out of disk space, is a broken devel environment and gives me headache all day long getting openssh on it. I think that's about it :-/ But I have just gotten the imense satisfaction that is runs OpenSSH, I can sleep now. The out of disk space situation will be probably be solved by hooking a disk aray on one of our internal linux boxes and unsing NFS to use it for the static data and leave the databases local. Although the NFS share will probably outperform the local filesystem with a factor 4 These databases vary in size between 300MB and 1.92GB. Which means that it will mean that one of our pruduction databases is on the limit of going bust. Total size of all databases together is around 5+ GB in size. Of course I will let the list know what happens when you try to access that kind of databases on a linux box with XFS. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Jun 7 14:59:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57LxnZ23233 for linux-xfs-outgoing; Thu, 7 Jun 2001 14:59:49 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57Lxmh23227 for ; Thu, 7 Jun 2001 14:59:48 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA00946 for ; Thu, 7 Jun 2001 14:59:45 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2089791; Thu, 7 Jun 2001 16:58:30 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA16476; Thu, 7 Jun 2001 16:58:29 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f57M1OC00471; Thu, 7 Jun 2001 17:01:24 -0500 Message-Id: <200106072201.f57M1OC00471@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: alan@cotse.com cc: linux-xfs@oss.sgi.com Subject: Re: Realtime Section - XFS In-Reply-To: Message from alan@cotse.com of "Thu, 07 Jun 2001 16:38:01 EDT." <991946281.3b1fe6299bd51@public.webmail.cotse.com> Date: Thu, 07 Jun 2001 17:01:24 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Are there userspace utilities to enable this realtime inode io behavior > ? > > No, just the ioctl call I mentioned to set the state on a file (must be empty). If you look in cmd/xfstests/src you will find a few utilities with code which use the ioctl: alloc.c, fsstress.c and randholes.c. If you wanted to it would not be hard to extend lmdd (part of lmbench) to set the realtime flag on a file it created, it can already be built with direct I/O support. You can get the source of this from www.bitkeeper.com it would then give you a tool to experiment with real time I/O. Steve > > Quoting Steve Lord : > > > > > > > Can I use and benefit from an rt section without making a specific > > inod > > > e > > > realtime? Or does it only benefit inodes that have been made > > 'realtime'. Do > > > es > > > it have any specific overall fs performance effect? My test is small, > > so it > > > is > > > fast anyway. also, is there any size guideline to the sizes of rt > > sections vs > > > size of the data and log sections? Or does it only matter to the > > inodes that > > > are used in a realtime fashion? > > > > > > Alan Willis > > > alan@cotse.com > > > > > > > The realtime subvolume is where data for realtime inodes is allocated, > > so yes > > it only applies to those. Create a new file, make it realtime, and then > > do > > I/O to it. Realtime is a little bit of a misnomer, the differences > > are: > > > > o There is only data in the partition, all metadata remains the the > > data > > subvolume. If you put the partitions in the correct place then the > > only > > time headseeks happen is to go and get actual data, no log or > > metadata > > I/O to get in the way. > > > > o A different space allocator is used, it uses a binary chop type > > approach > > to disk space which is wasteful, but which means it is very hard to > > > > fragment the files on realtime partitions. This allocator is also > > faster > > and tends to allocate space in a more deterministic amount of > > time. > > > > o When you make the filesystem, and when you create a realtime file > > via the > > ioctl call you can specify an extent size, all allocations will be > > a > > multiple of this. I have my doubts that this will work as > > advertised yet > > on linux. > > > > These are all supposed to add up to something which is good for doing > > streaming > > I/O, typically of very large files such as video data. > > > > Here are the changes I have to at least attempt to send disk I/O to the > > > > realtime device. > > > > Users of realtime on Irix would probably create a filesystem which was > > almost > > all realtime space, you still need the regular partition for the log and > > the > > metadata. > > > > Steve > > > > > > > > From owner-linux-xfs@oss.sgi.com Thu Jun 7 15:52:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57Mq7W28212 for linux-xfs-outgoing; Thu, 7 Jun 2001 15:52:07 -0700 Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57Mq6h28209 for ; Thu, 7 Jun 2001 15:52:06 -0700 Received: (qmail 15549 invoked by uid 0); 7 Jun 2001 22:52:00 -0000 Received: from pd90082f2.dip.t-dialin.net (HELO powstat) (217.0.130.242) by mail.gmx.net (mail10) with SMTP; 7 Jun 2001 22:52:00 -0000 From: "christian mueller" To: stimits@idcomm.com Date: Fri, 8 Jun 2001 00:44:48 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Subject: Re: mkinitrd.xfs, floppies CC: linux-xfs@oss.sgi.com Message-ID: <3B202000.9787.1F70911@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by oss.sgi.com id f57Mq7h28210 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi >... >Second, when compiling and getting the note about the image >being too large for a floppy, I'm wondering if compiling xfs as a >module would make any difference in this, since the ramdisk >would itself need to be part of the floppy as well?... no. it is possible to put the ramdisk on a second floppy disk. have a look at ´Bootdisk-HOWTO´ Section 6.3 http://linuxdoc.org/ chris From owner-linux-xfs@oss.sgi.com Thu Jun 7 16:03:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f57N34N29373 for linux-xfs-outgoing; Thu, 7 Jun 2001 16:03:04 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f57N33h29370 for ; Thu, 7 Jun 2001 16:03:03 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA06942 for ; Thu, 7 Jun 2001 16:03:18 -0700 (PDT) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA46181 for linux-xfs@oss.sgi.com; Fri, 8 Jun 2001 09:01:45 +1000 (EST) Date: Fri, 8 Jun 2001 09:01:45 +1000 (EST) From: Timothy Shimmin Message-Id: <200106072301.JAA46181@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - CREDITS Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Jun 7 16:01:18 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:96533a cmd/xfsprogs/doc/CREDITS - 1.9 - Add Juergen Hasch to CREDITS for libacl fixes. From owner-linux-xfs@oss.sgi.com Thu Jun 7 17:11:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f580Bwp01106 for linux-xfs-outgoing; Thu, 7 Jun 2001 17:11:58 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f580Bth01102 for ; Thu, 7 Jun 2001 17:11:56 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f580CmI06857; Fri, 8 Jun 2001 10:12:49 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Nathan J. Mehl" cc: linux-xfs@oss.sgi.com Subject: Re: RH7.1 ISO: panic on boot after install. In-reply-to: Your message of "Thu, 07 Jun 2001 14:13:57 -0400." <20010607141357.Z8330@blank.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Jun 2001 10:12:48 +1000 Message-ID: <6856.991959168@ocs4.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 7 Jun 2001 14:13:57 -0400, "Nathan J. Mehl" wrote: >A representative panic follows. If there's any additional information >on the system's configuration I can prodide, just ask. > >CPU: 0 >EIP: 0010:[] >EFLAGS: 00010092 >eax: 0000001b ebx: 00000000 ecx: 00000001 ex: 00000001 >esi: 00000000 edi: c02fbe30 ebp: c02fbe18 esp: c02fbdc8 >ds 0018 es: 0018 ss: 008 >Process swapper (pid: , stackpage=c02fb000) >Stack: c0286d3d c0286eb6 00002c3 c1425a84 c02fa000 c02fbe30 00000000 c02fa000 > 00000002 00000061 000f8920 c01db77f c144e9bc 0000086 00000082 c02fa000 > 00000046 00000000 c02fa000 c02fa000 c1425aac c01248b2 c1425a84 c1451e0 >Call Trace: [] [] [] [] [] [] [] >[] [] [] [] [] [<020675f>] [] [] >[] [] [] [] [] [] [] [] >[] [] [] [][] > >Code: 0f 0b 8d 65 bc 5b 5e 5f 89 ec 5d c3 8d 76 00 55 89 e5 83 ec >Kernel panic: Aiee,killing interrupt handler Raw oops numbers are useless. You have to run that text through ksymoops to decode it, make sure that you point ksymoops at the System.map for the failing system. From owner-linux-xfs@oss.sgi.com Thu Jun 7 17:19:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f580JKT01894 for linux-xfs-outgoing; Thu, 7 Jun 2001 17:19:20 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f580JKh01890 for ; Thu, 7 Jun 2001 17:19:20 -0700 Received: from rattle.melbourne.sgi.com (rattle.melbourne.sgi.com [134.14.55.145]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA09602 for ; Thu, 7 Jun 2001 17:19:35 -0700 (PDT) mail_from (kenmcd@melbourne.sgi.com) Received: from localhost (kenmcd@localhost) by rattle.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA47567; Fri, 8 Jun 2001 10:17:58 +1000 (AEST) X-Authentication-Warning: rattle.melbourne.sgi.com: kenmcd owned process doing -bs Date: Fri, 8 Jun 2001 10:17:58 +1000 From: Ken McDonell Reply-To: To: "Christopher \"C.J.\" Keist" cc: Greg Wildman , Subject: Re: quota support for xfs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just a heads up for the list. The resident XFS quota guru within SGI (Nathan Scott) is taking a well-deserved vacation thru the end of June ... so his normally prompt and helpful responses in this area will not be forthcoming for a while. I'd ask that others on the list jump in of they can offer assistance with quota issues. Thanks for your patience. From owner-linux-xfs@oss.sgi.com Thu Jun 7 17:42:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f580g9u03913 for linux-xfs-outgoing; Thu, 7 Jun 2001 17:42:09 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f580g7h03909 for ; Thu, 7 Jun 2001 17:42:07 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id CAA1755607 for ; Fri, 8 Jun 2001 02:42:04 +0200 (CEST) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA73014; Fri, 8 Jun 2001 10:40:45 +1000 (EST) Date: Fri, 8 Jun 2001 10:40:45 +1000 From: Timothy Shimmin To: alan@cotse.com Cc: linux-xfs@oss.sgi.com Subject: Re: Realtime Section - XFS Message-ID: <20010608104045.T237728@boing.melbourne.sgi.com> References: <991937049.3b1fc21928278@public.webmail.cotse.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <991937049.3b1fc21928278@public.webmail.cotse.com>; from alan@cotse.com on Thu, Jun 07, 2001 at 02:04:09PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Alan, On Thu, Jun 07, 2001 at 02:04:09PM -0400, alan@cotse.com wrote: > > Has anyone tried to use linux xfs's realtime section support? > Would there be any issues with dumping this filesystem? ^^^^^^^ I have never done any stuff with realtime subvolumes and/or xfsdump'ing them. But looking in xfsdump/xfsrestore, there is code to handle these files .... so I guess it should work :) Let us know how you go. Cheers, Tim. From owner-linux-xfs@oss.sgi.com Thu Jun 7 18:58:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f581wlY08546 for linux-xfs-outgoing; Thu, 7 Jun 2001 18:58:47 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f581wkh08541 for ; Thu, 7 Jun 2001 18:58:46 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip91.idcomm.com [209.60.72.218] (may be forged)) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5827gU31619 for ; Thu, 7 Jun 2001 20:07:42 -0600 Message-ID: <3B20317B.DD9FADB2@idcomm.com> Date: Thu, 07 Jun 2001 19:59:23 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: mkinitrd.xfs, floppies References: <3B202000.9787.1F70911@localhost> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.idcomm.com id f5827gU31619 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f581wkh08542 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk christian mueller wrote: > > hi > > >... > >Second, when compiling and getting the note about the image > >being too large for a floppy, I'm wondering if compiling xfs as a > >module would make any difference in this, since the ramdisk > >would itself need to be part of the floppy as well?... > > no. it is possible to put the ramdisk on a second floppy disk. > have a look at ´Bootdisk-HOWTO´ Section 6.3 > > http://linuxdoc.org/ > > chris Excellent, I'll give that a check, I hadn't thought about the ability to split disks this way. Thanks also to those who answered off list. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Thu Jun 7 19:02:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f58229r09156 for linux-xfs-outgoing; Thu, 7 Jun 2001 19:02:09 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f58228h09152 for ; Thu, 7 Jun 2001 19:02:08 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id VAA10554; Thu, 7 Jun 2001 21:55:29 -0400 Message-ID: <3B2034D4.D6E17C42@ieee.org> Date: Thu, 07 Jun 2001 22:13:40 -0400 From: "Bryan J. Smith" Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jan Strohbehn CC: linux-xfs@oss.sgi.com Subject: Re: Changing ACLs as non-owner References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jan Strohbehn wrote: > Hi !! > I just joined this mailing list, so I'm sorry if this > question has been asked before. > Is it possible to set ACLs on a file or directory if > you are not the native owner (e.g. member of the primary > group) ??? > Thank you, > Jan Someone else correct me if I'm wrong in saying this but would consider such a "feature" to be a _gross_security_violation_. Any reason you need this? -- TheBS -- Bryan J. Smith, President mailto:b.j.smith@ieee.org (407)366-7013 pager:(888)694-5793 chat:thebs413@AOL/MS/Yho ========================================================== SmithConcepts, Inc. http://www.SmithConcepts.com Consulting Engineers and IT Professionals From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 10:03:52 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58H3qK1004393 for linux-xfs-outgoing; Fri, 8 Jun 2001 10:03:52 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: (from root@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58H3qdv004391 for linux-xfs@oss.sgi.com; Fri, 8 Jun 2001 10:03:52 -0700 Date: Fri, 8 Jun 2001 10:03:52 -0700 From: root Message-Id: <200106081703.f58H3qdv004391@linux-xfs.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk list test sorry folks new setup must test From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 10:06:38 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58H6c0o004495 for linux-xfs-outgoing; Fri, 8 Jun 2001 10:06:38 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from blipvert.blank.org (blipvert.blank.org [216.112.239.86]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58H6a3D004492 for ; Fri, 8 Jun 2001 10:06:36 -0700 Received: (qmail 9225 invoked by uid 500); 8 Jun 2001 17:06:33 -0000 Date: Fri, 8 Jun 2001 13:06:32 -0400 From: "Nathan J. Mehl" To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: RH7.1 ISO: panic on boot after install. Message-ID: <20010608130632.S8330@blank.org> References: <20010607141357.Z8330@blank.org> <4.3.2.7.2.20010607211301.0349d628@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010607211301.0349d628@pop.xs4all.nl>; from knuffie@xs4all.nl on Thu, Jun 07, 2001 at 09:15:39PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In the immortal words of Seth Mos (knuffie@xs4all.nl): > > Please run this through ksymoops please. If you can boot the machine > succesfully. If it does boot, does it panic or oops after some time > or stressing? > > That would be most helpful. > > Have you tried eliminating some of the attached hardware (usb > hardware for instance). Generally speaking, when the system _does_ boot, it appears to be stable. Here's what ksymoops has to say: ksymoops 2.4.0 on i686 2.4.2-SGI_XFS_1.0. Options used -v /boot/vmlinux-2.4.2-SGI_XFS_1.0 (specified) -k ./ksyms (specified) -l /proc/modules (specified) -o /lib/modules/2.4.2-SGI_XFS_1.0/ (default) -m /boot/System.map (specified) Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says c022d1e0, vmlinux says c0153790. Ignoring ksyms_base entry CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010092 eax: 0000001b ebx: 00000000 ecx: 00000001 ex: 00000001 esi: 00000000 edi: c02fbe30 ebp: c02fbe18 esp: c02fbdc8 Process swapper (pid: , stackpage=c02fb000) Stack: c0286d3d c0286eb6 00002c3 c1425a84 c02fa000 c02fbe30 00000000 c02fa000 00000002 00000061 000f8920 c01db77f c144e9bc 0000086 00000082 c02fa000 00000046 00000000 c02fa000 c02fa000 c1425aac c01248b2 c1425a84 c1451e0 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [<020675f>] [] [] [] [] [] [] [] [] [] [] [] [] [] [][] Code: 0f 0b 8d 65 bc 5b 5e 5f 89 ec 5d c3 8d 76 00 55 89 e5 83 ec >>EIP; c0113781 <===== Trace; c0286d3d Trace; c0286eb6 Trace; c01db77f Trace; c01248b2 <___wait_on_page+66/ac> Trace; c0123f37 Trace; c012419c Trace; c01d9335 <_xfs_incore_relse+15/1c> Trace; c01d1e4e Trace; c01b879a Trace; c01635ac Trace; c016374c <_end_pagebuf_page_io+90/98> Trace; c01e18db Trace; 0020675f Before first symbol Trace; c0210784 Trace; c02157a8 Trace; 0c020877 Before first symbol Trace; c0210718 Trace; 0c010a5d Before first symbol Trace; c010a1c7 Trace; 0c010740 Before first symbol Trace; c0107240 Trace; c0108f54 Trace; c0107240 Trace; c0107240 Trace; c0107263 Trace; c01072c4 Trace; c0105000 Trace; c0100191 Code; c0113781 00000000 <_EIP>: Code; c0113781 <===== 0: 0f 0b ud2a <===== Code; c0113783 2: 8d 65 bc lea 0xffffffbc(%ebp),%esp Code; c0113786 5: 5b pop %ebx Code; c0113787 6: 5e pop %esi Code; c0113788 7: 5f pop %edi Code; c0113789 8: 89 ec mov %ebp,%esp Code; c011378b a: 5d pop %ebp Code; c011378c b: c3 ret Code; c011378d c: 8d 76 00 lea 0x0(%esi),%esi Code; c0113790 <__wake_up+0/ac> f: 55 push %ebp Code; c0113791 <__wake_up+1/ac> 10: 89 e5 mov %esp,%ebp Code; c0113793 <__wake_up+3/ac> 12: 83 ec 00 sub $0x0,%esp Kernel panic: Aiee,killing interrupt handler 2 warnings issued. Results may not be reliable. ------------------------------------------------------ I've got more than one membership / to more than one club and I owe my life / to the people that I love. (--Ani DiFranco) ---------------------------------------------- From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 10:10:39 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58HAdOl004654 for linux-xfs-outgoing; Fri, 8 Jun 2001 10:10:39 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58HAa3D004650 for ; Fri, 8 Jun 2001 10:10:38 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA15689 for ; Fri, 8 Jun 2001 10:02:42 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from yog-sothoth.sgi.com (eugate.sgi.com [144.253.131.5]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id f58H1hj23483081 for ; Fri, 8 Jun 2001 10:01:43 -0700 (PDT) Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA1867623 for ; Fri, 8 Jun 2001 19:01:04 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA2100471; Fri, 8 Jun 2001 11:59:35 -0500 (CDT) Received: from sgi.com (eagdhcp-195-16.americas.sgi.com [128.162.195.186]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA13087; Fri, 8 Jun 2001 11:59:34 -0500 (CDT) Message-ID: <3B2103E3.23E5BEA5@sgi.com> Date: Fri, 08 Jun 2001 11:57:07 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Ric Tibbetts CC: linux-xfs@oss.sgi.com Subject: Re: growing a partition References: <4.3.2.7.2.20010607202155.03316008@pop.xs4all.nl> <3B1FE6C0.6050609@pipcws.ca.boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ric Tibbetts wrote: > But, > there "were" issues with extending an xfs more than once. I'm hoping > they are getting resolved (any word on that?). Austin was the only person to report this problem, AFAIK, and Andi at SuSE said he had no trouble... it's still on my list of things to look at, but I don't have any good info yet. Can anyone else verify the problem? -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 10:20:10 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58HKARC005024 for linux-xfs-outgoing; Fri, 8 Jun 2001 10:20:10 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from fozzie.eye-net.com.au (fozzie.eye-net.com.au [203.41.228.19]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58HK63D005019 for ; Fri, 8 Jun 2001 10:20:08 -0700 Received: by fozzie.eye-net.com.au (Postfix, from userid 1000) id 2E1A6D6214; Fri, 8 Jun 2001 22:31:51 +1000 (EST) Date: Fri, 8 Jun 2001 22:31:51 +1000 To: "Martin K. Petersen" Cc: linux-xfs@oss.sgi.com Subject: Re: XFS doesn't like my alpha Message-ID: <20010608223151.C3495@eye-net.com.au> References: <20010424220259.A9547@eye-net.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i From: csmall@eye-net.com.au (Craig Small) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Apr 24, 2001 at 10:31:31AM -0400, Martin K. Petersen wrote: > Hmmm. Looks like we trigger a bug in the RAID1 code. > > I'm working from home today, but will try and reproduce on my alpha at > the office tomorrow. If it makes you feel any better the kernel oops happens on all FS types including ext2 :< - Craig -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.eye-net.com.au/ MIEEE Debian developer From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 10:39:55 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58HdtiD005779 for linux-xfs-outgoing; Fri, 8 Jun 2001 10:39:55 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58Hds3D005771 for ; Fri, 8 Jun 2001 10:39:54 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip11.idcomm.com [209.60.72.138]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f58HmuU15988 for ; Fri, 8 Jun 2001 11:48:56 -0600 Message-ID: <3B210E12.CDA8E281@idcomm.com> Date: Fri, 08 Jun 2001 11:40:34 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: cmd compiles Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm trying to compile some of the cvs cmd items, and can't seem to find all the headers. I'm using RH 7.1, and wondering if the xfsprogs-devel is not part of cvs? Or perhaps I'm just installing out of order (I have the 2.4.6-pre1-xfs kernel up and running, the current xfs kernel is what /usr/src/linux/ has in it). Suggestions on where to get devel headers or what to move where when using the cvs tree? FATAL ERROR: could not find a valid XFS library header. Install either the xfsprogs-devel (rpm) or the xfslibs-dev (deb) package. make: *** [configure] Error 1 D. Stimits, stimits@idcomm.com From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 10:40:42 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58HegFP005809 for linux-xfs-outgoing; Fri, 8 Jun 2001 10:40:42 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58Hee3D005806 for ; Fri, 8 Jun 2001 10:40:40 -0700 Received: from qn-212-58-163-247.quicknet.nl ([212.58.163.247]:63526 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Fri, 8 Jun 2001 19:40:36 +0200 Message-Id: <4.3.2.7.2.20010608192839.033a1410@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Jun 2001 19:40:33 +0200 To: "Nathan J. Mehl" From: Seth Mos Subject: Re: RH7.1 ISO: panic on boot after install. Cc: linux-xfs@oss.sgi.com In-Reply-To: <20010608130632.S8330@blank.org> References: <4.3.2.7.2.20010607211301.0349d628@pop.xs4all.nl> <20010607141357.Z8330@blank.org> <4.3.2.7.2.20010607211301.0349d628@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:06 8-6-2001 -0400, Nathan J. Mehl wrote: >In the immortal words of Seth Mos (knuffie@xs4all.nl): > > > > Please run this through ksymoops please. If you can boot the machine > > succesfully. If it does boot, does it panic or oops after some time > > or stressing? > > > > That would be most helpful. > > > > Have you tried eliminating some of the attached hardware (usb > > hardware for instance). > >Generally speaking, when the system _does_ boot, it appears to be >stable. Ahh, I sea that it has a via chipset onboard. Include warning neon sign Firstly I would sugest updating your bios please. Via chipset have a grey history of doing funny things and in general behave in non yet to be described ways on things other then windows :-/ It looks like related to dma issues on the IDE controller. I could be wrong though, I am not well versed in reading ksymoops output. Here is a test of various via boards. http://www.linuxhardware.org/article.pl?sid=01/06/06/1821202&mode=thread Here is a Quote: "We've been in touch with Alan Cox, top-level Linux kernel developer, to see exactly what issues they've been seeing with this chipset and this is what we found out:" "We were seeing problems with large IDE loads on Linux for a long time yet VIA would not answer it. VIA still haven't provided good info to the Linux community. In fact most of what people know even in the non NDA'd BIOS writing world is by studying how the BIOS changes the behavior. So if your vendor doesn't have a fix, or you have a Intel/VIA combo setup with no known fix you are on rocky territory still." I suggest getting your newest bios and try to build and install a newer kernel. The newer kernels have better handling of the via chipset. Read the whole review if you want to know what the general issues are. I'm gonna wait for a nVIDIA nForce mainboard, yummi :P Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 10:49:42 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58Hngwe006157 for linux-xfs-outgoing; Fri, 8 Jun 2001 10:49:42 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58Hne3D006154 for ; Fri, 8 Jun 2001 10:49:40 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA04256 for ; Fri, 8 Jun 2001 10:49:33 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2101684; Fri, 8 Jun 2001 12:48:16 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA06459; Fri, 8 Jun 2001 12:48:16 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f58Hoxg12505; Fri, 8 Jun 2001 12:50:59 -0500 Message-Id: <200106081750.f58Hoxg12505@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: stimits@idcomm.com cc: "linux-xfs@oss.sgi.com" Subject: Re: cmd compiles In-Reply-To: Message from "D. Stimits" of "Fri, 08 Jun 2001 11:40:34 MDT." <3B210E12.CDA8E281@idcomm.com> Date: Fri, 08 Jun 2001 12:50:59 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I'm trying to compile some of the cvs cmd items, and can't seem to find > all the headers. I'm using RH 7.1, and wondering if the xfsprogs-devel > is not part of cvs? Or perhaps I'm just installing out of order (I have > the 2.4.6-pre1-xfs kernel up and running, the current xfs kernel is what > /usr/src/linux/ has in it). Suggestions on where to get devel headers or > what to move where when using the cvs tree? > > FATAL ERROR: could not find a valid XFS library header. > Install either the xfsprogs-devel (rpm) or the xfslibs-dev (deb) > package. > make: *** [configure] Error 1 > > D. Stimits, stimits@idcomm.com To get through a build of all the commands you need to install some of the earlier phases. You can do this either by building and installing the rpms, or by a make install. I think this sequence works (from memory): 0. install e2fsprogs-devel for uuid code 1. build acl and attr packages, install development rpms 2. build xfsprogs, install development rpms 3. build xfsdump Steve From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 10:57:12 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58HvCdJ006369 for linux-xfs-outgoing; Fri, 8 Jun 2001 10:57:12 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58HvA3D006365 for ; Fri, 8 Jun 2001 10:57:11 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f58Hv5L02742 for linux-xfs@oss.sgi.com; Fri, 8 Jun 2001 13:57:05 -0400 Date: Fri, 8 Jun 2001 13:57:05 -0400 From: Alan Eldridge To: linux-xfs@oss.sgi.com Subject: possibly stupid question... Message-ID: <20010608135705.A2739@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I don't need to rebuild the commands just because I'm changing kernel version (2.4.2 => 2.4.5), right? -- Alan Eldridge "Uh, I think so, Brain, but isn't Regis Philbin already married?" From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 11:07:40 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58I7eIm006772 for linux-xfs-outgoing; Fri, 8 Jun 2001 11:07:40 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from itcampus.de (www.itcampus.de [194.45.97.156]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58I7c3D006768 for ; Fri, 8 Jun 2001 11:07:39 -0700 Received: from [62.208.91.225] (HELO itcampus.de) by itcampus.de (CommuniGate Pro SMTP 3.3.1) with ESMTP id 99574; Fri, 08 Jun 2001 20:10:29 +0200 Message-ID: <3B210AB4.8C2986BE@itcampus.de> Date: Fri, 08 Jun 2001 19:26:12 +0200 From: Thomas Winkler X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.2.16 i686) X-Accept-Language: ex-MX MIME-Version: 1.0 To: jtrostel@connex.com, linux-xfs@oss.sgi.com Subject: Re: acls with samba on xfs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk John Trostel wrote: > Your best bet would be to try using the latest XFS CVS in combination with the > latest SAMBA_2_2 CVS download. Both of these have had related improvements > since the official releases of both XFS 1.0 and Samba 2.2.0. I know that we > (Connex) are using this type of combination for allowing domain members to > change NT-like ACLs on Samba 2.2.0 (using a 2.4.3 CVS of XFS and a more recent > CVS of Samba). did some testing with 2.4.4 CVS XFS in combination with CVS checkout of Head. i guess that should be working, but it's not. once again our system crashed and i had to reboot aour machine. i just can't switch our servers to using xfs until i got a solution on this one. imagine users trying to change acls on our server... by the way, the server doesn't crash every time. gotta do some more testing to tell the cause, but our test server is kind of broken right now. > I also wonder if using the TNG as the PDC server is causing problems with the > domain users/groups.... My truck is in the 'shop' and I am away from our PDC so > I can't test how that all works today. I'll look at it tomorrow if you send me > a reminder. the problem is that the head is not able to map the sid of the domain user to the right uid/gid. i looked through the code (not familiar with it at all) and found that the tagtype of 0 is not known. i guess the head just can't find the right sid to use. what is the tagtype 0 supposed to be, what should it be and what could be wrong with our setup. thank you for your help thomas -------------------------------------- itCampus Software- und Systemhaus GmbH Leipzig - Halle - Wittenberg http://www.itcampus.de From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 11:12:59 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58ICx2a006970 for linux-xfs-outgoing; Fri, 8 Jun 2001 11:12:59 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58ICv3D006964 for ; Fri, 8 Jun 2001 11:12:57 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip7.idcomm.com [209.60.72.134]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f58ILxU22625 for ; Fri, 8 Jun 2001 12:21:59 -0600 Message-ID: <3B2115D2.D776EEE6@idcomm.com> Date: Fri, 08 Jun 2001 12:13:38 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "linux-xfs@oss.sgi.com" Subject: Re: cmd compiles References: <200106081750.f58Hoxg12505@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > > > I'm trying to compile some of the cvs cmd items, and can't seem to find > > all the headers. I'm using RH 7.1, and wondering if the xfsprogs-devel > > is not part of cvs? Or perhaps I'm just installing out of order (I have > > the 2.4.6-pre1-xfs kernel up and running, the current xfs kernel is what > > /usr/src/linux/ has in it). Suggestions on where to get devel headers or > > what to move where when using the cvs tree? > > > > FATAL ERROR: could not find a valid XFS library header. > > Install either the xfsprogs-devel (rpm) or the xfslibs-dev (deb) > > package. > > make: *** [configure] Error 1 > > > > D. Stimits, stimits@idcomm.com > > To get through a build of all the commands you need to install some of the > earlier phases. You can do this either by building and installing the rpms, > or by a make install. For reference, I'm using the devel branch of cvs currently marked as 2.4.6-pre1-xfs. > > I think this sequence works (from memory): > > 0. install e2fsprogs-devel for uuid code I've done this via rpm. The rpm version listed: e2fsprogs-1.19-4 e2fsprogs-devel-1.19-4 > 1. build acl and attr packages, install development rpms I've compiled and installed the cvs version of acl and attr; however, I'm not aware of any development rpms...are these in addition to the cvs cmd/acl/ and cmd/attr/ make installs? If so, where do I find the development version, whether in rpm or tarball format? > 2. build xfsprogs, install development rpms I have done a make install for xfsprogs in the cmd/xfsprogs/ of cvs devel. Now comes a similar question from the prior paragraph...are there development rpms or tarballs that are separate from the build and install of xfsprogs? If so, where can I find them in either rpm or tarball format? > 3. build xfsdump This is the part that fails for me, and why I think the devel stuff must be separate from the cvs devel tree. Or at least requires more than a make install from the relevant cmd subdirectory. D. Stimits, stimits@idcomm.com > > Steve From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 11:16:52 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58IGq3U007168 for linux-xfs-outgoing; Fri, 8 Jun 2001 11:16:52 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58IGn3D007165 for ; Fri, 8 Jun 2001 11:16:50 -0700 Received: from auto-nb1.xs4all.nl (perle-wan1.coltex.nl [10.0.1.177]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f58IGiq14274; Fri, 8 Jun 2001 20:16:44 +0200 Message-Id: <4.3.2.7.2.20010608201354.0319cab0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Jun 2001 20:16:47 +0200 To: Alan Eldridge , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: possibly stupid question... In-Reply-To: <20010608135705.A2739@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:57 8-6-2001 -0400, Alan Eldridge wrote: >I don't need to rebuild the commands just because I'm changing kernel >version (2.4.2 => 2.4.5), right? No. The last time new tools were needed was around 2.4.1 I believe. But that was a change in log format if I recall. If you really tried hard enough you could not recover a dirty fs with a older kernel There was another change a time ago but that was announced on the list. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 11:28:06 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58IS6jj007469 for linux-xfs-outgoing; Fri, 8 Jun 2001 11:28:06 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58IS53D007466 for ; Fri, 8 Jun 2001 11:28:05 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA27757 for ; Fri, 8 Jun 2001 11:28:02 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2104023; Fri, 8 Jun 2001 13:26:47 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA83368; Fri, 8 Jun 2001 13:26:47 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f58ITUX13917; Fri, 8 Jun 2001 13:29:30 -0500 Message-Id: <200106081829.f58ITUX13917@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: stimits@idcomm.com cc: "linux-xfs@oss.sgi.com" Subject: Re: cmd compiles In-Reply-To: Message from "D. Stimits" of "Fri, 08 Jun 2001 12:13:38 MDT." <3B2115D2.D776EEE6@idcomm.com> Date: Fri, 08 Jun 2001 13:29:30 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > > > > I think this sequence works (from memory): > > > > 0. install e2fsprogs-devel for uuid code > > I've done this via rpm. The rpm version listed: > e2fsprogs-1.19-4 > e2fsprogs-devel-1.19-4 > > > 1. build acl and attr packages, install development rpms > > I've compiled and installed the cvs version of acl and attr; however, > I'm not aware of any development rpms...are these in addition to the cvs > cmd/acl/ and cmd/attr/ make installs? If so, where do I find the > development version, whether in rpm or tarball format? OK, if you use the Makepkgs command in each command directory it will build you rpms, if you do make install it should install all the correct headers (a make install is used to generate the rpms). All the code is in the cvs tree, there is nothing missing. However, it make be that make install is not doing everything it needs to > > > 2. build xfsprogs, install development rpms > > I have done a make install for xfsprogs in the cmd/xfsprogs/ of cvs > devel. Now comes a similar question from the prior paragraph...are there > development rpms or tarballs that are separate from the build and > install of xfsprogs? If so, where can I find them in either rpm or > tarball format? > > > 3. build xfsdump > > This is the part that fails for me, and why I think the devel stuff must > be separate from the cvs devel tree. Or at least requires more than a > make install from the relevant cmd subdirectory. Can you report exactly the failure you are seeing here (sorry I deleted your earlier email, I have to delete stuff otherwise I drown in email very quickly). Steve > > D. Stimits, stimits@idcomm.com > > > > > Steve From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 11:28:22 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58ISMaq007502 for linux-xfs-outgoing; Fri, 8 Jun 2001 11:28:22 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from blipvert.blank.org (blipvert.blank.org [216.112.239.86]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58ISL3D007496 for ; Fri, 8 Jun 2001 11:28:21 -0700 Received: (qmail 12379 invoked by uid 500); 8 Jun 2001 18:28:19 -0000 Date: Fri, 8 Jun 2001 14:28:19 -0400 From: "Nathan J. Mehl" To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: RH7.1 ISO: panic on boot after install. Message-ID: <20010608142818.Y8330@blank.org> References: <4.3.2.7.2.20010607211301.0349d628@pop.xs4all.nl> <20010607141357.Z8330@blank.org> <4.3.2.7.2.20010607211301.0349d628@pop.xs4all.nl> <20010608130632.S8330@blank.org> <4.3.2.7.2.20010608192839.033a1410@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010608192839.033a1410@pop.xs4all.nl>; from knuffie@xs4all.nl on Fri, Jun 08, 2001 at 07:40:33PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In the immortal words of Seth Mos (knuffie@xs4all.nl): > > Ahh, I sea that it has a via chipset onboard. Include warning neon sign Argh, I was afraid that was going to be the answer. Sigh. Unfortunatly, if you want to run a socket-A athlon system (which is by a long yard the best bang-for-buck solution out there), there really aren't too many alternatives at the moment. AMD makes their own chipsets, but they're basically only doing so under duress, and they have a tendency to pull them from the market the moment anybody else starts shipping in quantity. > I suggest getting your newest bios and try to build and install a newer > kernel. The newer kernels have better handling of the via chipset. Okay, BIOS update is easy. New kernel might be a bit harder, as all of the xfs patches on sgi's ftp site are for 2.4.2/2.4.3 -- can they be cleanly applied to 2.4.5? > I'm gonna wait for a nVIDIA nForce mainboard, yummi :P Heh, that'll probably be my next upgrade, but that's still a good six months out... -n ------------------------------------------------------ "Kids today only have to click a few buttons to get their porn, not go out there and shoplift porn like I did, and my father did before me, and his father before him." (--Dan Savage) ---------------------------------------------- From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 11:29:04 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58IT4ql007539 for linux-xfs-outgoing; Fri, 8 Jun 2001 11:29:04 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58IT33D007536 for ; Fri, 8 Jun 2001 11:29:03 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA02237 for ; Fri, 8 Jun 2001 11:05:01 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2100065; Fri, 8 Jun 2001 13:03:22 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA04834; Fri, 8 Jun 2001 13:03:22 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f58I64P12568; Fri, 8 Jun 2001 13:06:04 -0500 Message-Id: <200106081806.f58I64P12568@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Alan Eldridge cc: linux-xfs@oss.sgi.com Subject: Re: possibly stupid question... In-Reply-To: Message from Alan Eldridge of "Fri, 08 Jun 2001 13:57:05 EDT." <20010608135705.A2739@wwweasel.geeksrus.net> Date: Fri, 08 Jun 2001 13:06:04 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I don't need to rebuild the commands just because I'm changing kernel > version (2.4.2 => 2.4.5), right? > > -- > Alan Eldridge > "Uh, I think so, Brain, but isn't Regis Philbin already married?" No, you do not need to, there may be some features in newer commands you do not get, but you should be able to keep using the old ones. Steve From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 11:35:19 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58IZJgQ007955 for linux-xfs-outgoing; Fri, 8 Jun 2001 11:35:19 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58IZH3D007952 for ; Fri, 8 Jun 2001 11:35:17 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA06952 for ; Fri, 8 Jun 2001 11:35:34 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2101849; Fri, 8 Jun 2001 13:34:00 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA65134; Fri, 8 Jun 2001 13:33:59 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f58Iagj15709; Fri, 8 Jun 2001 13:36:42 -0500 Message-Id: <200106081836.f58Iagj15709@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Nathan J. Mehl" cc: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: RH7.1 ISO: panic on boot after install. In-Reply-To: Message from "Nathan J. Mehl" of "Fri, 08 Jun 2001 14:28:19 EDT." <20010608142818.Y8330@blank.org> Date: Fri, 08 Jun 2001 13:36:42 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > > I suggest getting your newest bios and try to build and install a newer > > kernel. The newer kernels have better handling of the via chipset. > > Okay, BIOS update is easy. New kernel might be a bit harder, as all > of the xfs patches on sgi's ftp site are for 2.4.2/2.4.3 -- can they > be cleanly applied to 2.4.5? > Take a look in the patches subdirectory - there is a 2.4.5 patch in there. Steve From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 11:39:39 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58IddC2008541 for linux-xfs-outgoing; Fri, 8 Jun 2001 11:39:39 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from msg.ecetra.com (dollar.ecetra.com [193.164.224.209]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58Idb3D008520 for ; Fri, 8 Jun 2001 11:39:37 -0700 Received: from vie-ac.office.ecetra.com (vie-ac.office.ecetra.com [10.251.148.147] (may be forged)) by msg.ecetra.com (8.9.3/8.9.3) with ESMTP id UAA11643; Fri, 8 Jun 2001 20:39:30 +0200 Received: from localhost (localhost [127.0.0.1]) by vie-ac.office.ecetra.com (8.11.4/8.11.3) with ESMTP id f58IdUN01442; Fri, 8 Jun 2001 20:39:30 +0200 Date: Fri, 8 Jun 2001 20:39:30 +0200 (CEST) From: Adam Cioccarelli To: "D. Stimits" cc: "linux-xfs@oss.sgi.com" Subject: Re: cmd compiles In-Reply-To: <3B2115D2.D776EEE6@idcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk go to the ..../cmd/xfsprogs/ directory and do a make install-dev then ../xfsdump/ make && make install works for me anyway! ------------------------------------------------------------------------------- Adam Cioccarelli (B.E Mechanical) Adam.Cioccarelli@ecetra.com Database Administrator Phone: +43 1 536 89 7725 Fax: +43 1 536 89 7719 ecetra Central European e-Finance AG Mobile:+43 664 181 4195 ------------------------------------------------------------------------------- On Fri, 8 Jun 2001, D. Stimits wrote: > Steve Lord wrote: > > > > > I'm trying to compile some of the cvs cmd items, and can't seem to find > > > all the headers. I'm using RH 7.1, and wondering if the xfsprogs-devel > > > is not part of cvs? Or perhaps I'm just installing out of order (I have > > > the 2.4.6-pre1-xfs kernel up and running, the current xfs kernel is what > > > /usr/src/linux/ has in it). Suggestions on where to get devel headers or > > > what to move where when using the cvs tree? > > > > > > FATAL ERROR: could not find a valid XFS library header. > > > Install either the xfsprogs-devel (rpm) or the xfslibs-dev (deb) > > > package. > > > make: *** [configure] Error 1 > > > > > > D. Stimits, stimits@idcomm.com > > > > To get through a build of all the commands you need to install some of the > > earlier phases. You can do this either by building and installing the rpms, > > or by a make install. > > For reference, I'm using the devel branch of cvs currently marked as > 2.4.6-pre1-xfs. > > > > > I think this sequence works (from memory): > > > > 0. install e2fsprogs-devel for uuid code > > I've done this via rpm. The rpm version listed: > e2fsprogs-1.19-4 > e2fsprogs-devel-1.19-4 > > > 1. build acl and attr packages, install development rpms > > I've compiled and installed the cvs version of acl and attr; however, > I'm not aware of any development rpms...are these in addition to the cvs > cmd/acl/ and cmd/attr/ make installs? If so, where do I find the > development version, whether in rpm or tarball format? > > > 2. build xfsprogs, install development rpms > > I have done a make install for xfsprogs in the cmd/xfsprogs/ of cvs > devel. Now comes a similar question from the prior paragraph...are there > development rpms or tarballs that are separate from the build and > install of xfsprogs? If so, where can I find them in either rpm or > tarball format? > > > 3. build xfsdump > > This is the part that fails for me, and why I think the devel stuff must > be separate from the cvs devel tree. Or at least requires more than a > make install from the relevant cmd subdirectory. > > D. Stimits, stimits@idcomm.com > > > > > Steve > From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 11:47:36 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58IlaFL009543 for linux-xfs-outgoing; Fri, 8 Jun 2001 11:47:36 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58IlX3D009525 for ; Fri, 8 Jun 2001 11:47:33 -0700 Received: from auto-nb1.xs4all.nl (perle-wan1.coltex.nl [10.0.1.177]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f58IlSq14302; Fri, 8 Jun 2001 20:47:29 +0200 Message-Id: <4.3.2.7.2.20010608204039.032154a0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Jun 2001 20:47:32 +0200 To: "Nathan J. Mehl" From: Seth Mos Subject: Re: RH7.1 ISO: panic on boot after install. Cc: linux-xfs@oss.sgi.com In-Reply-To: <20010608142818.Y8330@blank.org> References: <4.3.2.7.2.20010608192839.033a1410@pop.xs4all.nl> <4.3.2.7.2.20010607211301.0349d628@pop.xs4all.nl> <20010607141357.Z8330@blank.org> <4.3.2.7.2.20010607211301.0349d628@pop.xs4all.nl> <20010608130632.S8330@blank.org> <4.3.2.7.2.20010608192839.033a1410@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 14:28 8-6-2001 -0400, Nathan J. Mehl wrote: >In the immortal words of Seth Mos (knuffie@xs4all.nl): > > > > Ahh, I sea that it has a via chipset onboard. Include warning neon sign > > >Argh, I was afraid that was going to be the answer. Sigh. I'm sorry. If AC can't get VIA to cooperate, what's next? >Unfortunatly, if you want to run a socket-A athlon system (which is by >a long yard the best bang-for-buck solution out there), there really >aren't too many alternatives at the moment. AMD makes their own >chipsets, but they're basically only doing so under duress, and they >have a tendency to pull them from the market the moment anybody else >starts shipping in quantity. It's fairly undocumented. > > I suggest getting your newest bios and try to build and install a newer > > kernel. The newer kernels have better handling of the via chipset. > >Okay, BIOS update is easy. New kernel might be a bit harder, as all >of the xfs patches on sgi's ftp site are for 2.4.2/2.4.3 -- can they >be cleanly applied to 2.4.5? Checkout the CVS. That one is linux-2.4.6-pre1-xfs. There is also a patch against a vanilla 2.4.5 on the ftp server. Note: Oss.sgi.com was/is having a hard time could be unreachable for the moment. > > I'm gonna wait for a nVIDIA nForce mainboard, yummi :P > >Heh, that'll probably be my next upgrade, but that's still a good six >months out... Asus A7N266something boards could be showing up in stores around you in june/juli. Let's hope that nVIDIA will produce the same kind of performance drivers or patches that make it possible to play quake3 under linux ;-) There is a link to a 4 board nForce roundup on http://www.tweakers.net/ (in dutch but it has lot of links :-) I want one. Greetings -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 11:56:08 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58Iu8kS010677 for linux-xfs-outgoing; Fri, 8 Jun 2001 11:56:08 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from roujin.gargoylecc.com (roujin.gargoylecc.com [65.100.85.34]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58Iu63D010654 for ; Fri, 8 Jun 2001 11:56:06 -0700 Received: from roujin.gargoylecc.com ([65.100.85.34] ident=ringram) by roujin.gargoylecc.com with esmtp (Exim 3.13 #1) id 158f8v-0001kW-00 for linux-xfs@oss.sgi.com; Sat, 09 Jun 2001 03:34:53 -0600 Date: Sat, 9 Jun 2001 03:34:53 -0600 (MDT) From: Russel Ingram To: Subject: xfsdump, paride tape, and -m option Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm using xfsdump from cvs (I think it is from 5/30/01 but might be 6/5/01) to attempt to backup an xfs filesystem to an HP Colorado 8GBe parallel tape drive. Every time I try to use the -m option (the parallel tape driver is a very minimal tape device driver and suggests specifying 16k as the block size) xfsdump core dumps with the following error: drive_minrmt.c:1820: do_get_write_buf: Assertion 'contextp->dc_nextp < contextp->dc_recendp' failed. Is this a bug or just an incompatiblity with the minimalness of the pt driver? Thanx, Russ -- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 12:03:49 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58J3n6i011575 for linux-xfs-outgoing; Fri, 8 Jun 2001 12:03:49 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58J3k3D011563 for ; Fri, 8 Jun 2001 12:03:47 -0700 Received: from auto-nb1.xs4all.nl (perle-wan1.coltex.nl [10.0.1.177]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f58J3Zq14314; Fri, 8 Jun 2001 21:03:36 +0200 Message-Id: <4.3.2.7.2.20010608205643.033315e0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Jun 2001 21:03:39 +0200 To: Thomas Winkler , jtrostel@connex.com, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: acls with samba on xfs In-Reply-To: <3B210AB4.8C2986BE@itcampus.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 19:26 8-6-2001 +0200, Thomas Winkler wrote: >John Trostel wrote: > > Your best bet would be to try using the latest XFS CVS in combination > with the > > latest SAMBA_2_2 CVS download. Both of these have had related improvements > > since the official releases of both XFS 1.0 and Samba 2.2.0. I know that we > > (Connex) are using this type of combination for allowing domain members to > > change NT-like ACLs on Samba 2.2.0 (using a 2.4.3 CVS of XFS and a more > recent > > CVS of Samba). > >did some testing with 2.4.4 CVS XFS in combination with CVS checkout of >Head. i guess that should be working, but it's not. once again our >system crashed and i had to reboot aour machine. i just can't switch our >servers to using xfs until i got a solution on this one. imagine users >trying to change acls on our server... Try the most recent CVS of xfs. It's at 2.4.6-pre1 now which seems to do well in NFS serving btw. I just finished some tests with a linux server and linux/NCR MP-RAS clients. NCR MP-RAS SVR4 client Linux 2.4.6-pre1 server -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 8677 73.5 8386 27.4 9817 35.3 22555 99.8 102400 100.0 3305.8 139.7 1000 8664 77.1 7276 30.0 2722 14.9 6024 43.9 7146 21.2 96.3 12.4 2000 8677 77.6 7268 33.2 3107 16.4 6042 44.2 7148 20.7 73.8 10.6 Linux 2.4.4-xfs client Linux 2.4.6-pre1-xfs server -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 256 7574 98.7 11100 8.4 5402 6.9 8011 92.5 11029 7.7 344.6 4.4 2000 7461 96.7 11115 8.2 5054 6.5 8026 97.9 10065 7.1 100.6 1.4 Impressive! Our 3Com 3300 Switch was reading 99/100 procent usage :-) >by the way, the server doesn't crash every time. gotta do some more >testing to tell the cause, but our test server is kind of broken right >now. Dump some errors in the mailing list and maybe we can figure out what's going wrong. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 12:19:18 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58JJIG3013383 for linux-xfs-outgoing; Fri, 8 Jun 2001 12:19:18 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from itcampus.de (www.itcampus.de [194.45.97.156]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58JJC3D013369 for ; Fri, 8 Jun 2001 12:19:13 -0700 Received: from [195.252.153.111] (account ) by itcampus.de (CommuniGate Pro WebUser 3.3.1) with HTTP id 99628; Fri, 08 Jun 2001 21:22:05 +0200 From: "Thomas Winkler" Subject: Re: acls with samba on xfs To: linux-xfs@oss.sgi.com Cc: Seth Mos X-Mailer: CommuniGate Pro Web Mailer v.3.3.1 Date: Fri, 08 Jun 2001 21:22:05 +0200 Message-ID: In-Reply-To: <4.3.2.7.2.20010608205643.033315e0@pop.xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_===99628====itcampus.de===_" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part MIME message --_===99628====itcampus.de===_ Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit On Fri, 08 Jun 2001 21:03:39 +0200 Seth Mos wrote: > Try the most recent CVS of xfs. It's at 2.4.6-pre1 now > which seems to do > well in NFS serving btw. I just finished some tests with > a linux server and > linux/NCR MP-RAS clients. thats what i wanted to try today, but couldn't make a checkout. probably the cvs server was down. hopefully next week a can get my hands on this one. i had heavy troubles getting the 2.4.5 to work, because of the aic7xxx related bug. is this fixed in 2.4.6-prex release? > >by the way, the server doesn't crash every time. gotta > do some more > >testing to tell the cause, but our test server is kind > of broken right > >now. > > Dump some errors in the mailing list and maybe we can > figure out what's > going wrong. i'd like to, just couldn't find something usefull, up to now. hopefully next week i can do some more extensiv testing on our test servers. > Cheers > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. thank you, thomas ------------------------------- itCampus Software- und Systemhaus GmbH Leipzig - Halle - Wittenberg http://www.itcampus.de --_===99628====itcampus.de===_ Content-Type: text/plain Content-Disposition: attachment; filename="" Content-Transfer-Encoding: base64 DQo= --_===99628====itcampus.de===_ Content-Type: text/plain Content-Disposition: attachment; filename="" Content-Transfer-Encoding: base64 DQo= --_===99628====itcampus.de===_ Content-Type: text/plain Content-Disposition: attachment; filename="" Content-Transfer-Encoding: base64 DQo= --_===99628====itcampus.de===_-- From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 12:19:42 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58JJggw013458 for linux-xfs-outgoing; Fri, 8 Jun 2001 12:19:42 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58JJd3D013448 for ; Fri, 8 Jun 2001 12:19:39 -0700 Received: from server1.ss0.net ([207.215.127.247]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id AAA04966 for ; Fri, 8 Jun 2001 00:01:37 -0700 (PDT) mail_from (hiryu@microhost.net) Received: from hiryu (helo=localhost) by server1.ss0.net with local-esmtp (Exim 3.22 #1 (Debian)) id 158GCy-0003HB-00 for ; Thu, 07 Jun 2001 23:57:24 -0700 Date: Thu, 7 Jun 2001 23:57:24 -0700 (PDT) From: Cameron To: Subject: cvsup Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In regards to obtaining the xfs source tree: I've had trouble connecting via cvsup. Originally, it worked fine, I used it perfectly on two seperate systems. Was the cvsup service moved to another server? If so, could I please have the hostname? Thanks. -Cameron From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 12:26:23 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58JQNbp014368 for linux-xfs-outgoing; Fri, 8 Jun 2001 12:26:23 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58JQI3F014354 for ; Fri, 8 Jun 2001 12:26:21 -0700 Received: from webstor1.artstor.de ([195.243.248.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id WAA05847 for ; Thu, 7 Jun 2001 22:56:29 -0700 (PDT) mail_from (jstrohbehn@artstor.de) Received: (qmail 26082 invoked from network); 8 Jun 2001 05:52:42 -0000 Received: from zerberus.artstor.de (HELO sokrates.artstor.de) (195.243.248.115) by www.artstor.de with SMTP; 8 Jun 2001 05:52:42 -0000 Date: Fri, 8 Jun 2001 07:51:35 +0200 (CEST) From: Jan Strohbehn X-X-Sender: To: "Bryan J. Smith" cc: Subject: Re: Changing ACLs as non-owner In-Reply-To: <3B2034D4.D6E17C42@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 7 Jun 2001, Bryan J. Smith wrote: > > Is it possible to set ACLs on a file or directory if > > you are not the native owner (e.g. member of the primary > > group) ??? > > Thank you, > > Jan > > Someone else correct me if I'm wrong in saying this but would > consider such a "feature" to be a _gross_security_violation_. Any > reason you need this? The reason is, that in connection with samba you must have one admin user who is able to set acls. But you can't give the right to set acls to another user too (e.g. his home directory). Perhaps it's possible to do this anyway, bu I don't know how?! Thanks, Jan From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 12:26:33 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58JQXxf014405 for linux-xfs-outgoing; Fri, 8 Jun 2001 12:26:33 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58JQI3D014354 for ; Fri, 8 Jun 2001 12:26:19 -0700 Received: from webstor1.artstor.de ([195.243.248.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id XAA07450 for ; Thu, 7 Jun 2001 23:04:35 -0700 (PDT) mail_from (jstrohbehn@artstor.de) Received: (qmail 26336 invoked from network); 8 Jun 2001 06:00:20 -0000 Received: from zerberus.artstor.de (HELO sokrates.artstor.de) (195.243.248.115) by www.artstor.de with SMTP; 8 Jun 2001 06:00:20 -0000 Date: Fri, 8 Jun 2001 07:59:13 +0200 (CEST) From: Jan Strohbehn X-X-Sender: To: Timothy Shimmin cc: Subject: Re: Changing ACLs as non-owner In-Reply-To: <20010608142514.W237728@boing.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Tim!! Thanks for this hint! Just tried it and it works (altough I just know how to set caps for the whole system). A little bit off topic, but can anyone tell me how to set this for a single process (or just point me to any documentation about this ;-) Thank you, Jan > > Is it possible to set ACLs on a file or directory if you are not the > > native owner (e.g. member of the primary group) ??? > > > To change the ACL you need to be the owner or have > CAP_FOWNER capability. > > >From the code: > if (!error && va.va_uid != current->fsuid && > !capable(CAP_FOWNER)) > error = EACCES; > > --Tim > From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 12:27:17 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58JRHhV014509 for linux-xfs-outgoing; Fri, 8 Jun 2001 12:27:17 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58JRF3D014498 for ; Fri, 8 Jun 2001 12:27:15 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA04205 for ; Fri, 8 Jun 2001 12:27:31 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2098399; Fri, 8 Jun 2001 14:25:57 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA14804; Fri, 8 Jun 2001 14:25:57 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f58JSdw16453; Fri, 8 Jun 2001 14:28:39 -0500 Message-Id: <200106081928.f58JSdw16453@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Cameron cc: linux-xfs@oss.sgi.com Subject: Re: cvsup In-Reply-To: Message from Cameron of "Thu, 07 Jun 2001 23:57:24 PDT." Date: Fri, 08 Jun 2001 14:28:39 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > In regards to obtaining the xfs source tree: > > I've had trouble connecting via cvsup. > > Originally, it worked fine, I used it perfectly on two seperate systems. > > Was the cvsup service moved to another server? If so, could I please have > the hostname? > > Thanks. > > -Cameron oss was relocated behind a firewall, and the ports cvsup uses are not currently open, at the moment firewall configuration is frozen, so cvs itself is the only available mechanism. Steve From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 12:29:38 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58JTcX9014996 for linux-xfs-outgoing; Fri, 8 Jun 2001 12:29:38 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58JTX3D014983 for ; Fri, 8 Jun 2001 12:29:34 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip88.idcomm.com [209.60.72.215] (may be forged)) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f58JcZU04898 for ; Fri, 8 Jun 2001 13:38:35 -0600 Message-ID: <3B2127C7.53B703B@idcomm.com> Date: Fri, 08 Jun 2001 13:30:15 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "linux-xfs@oss.sgi.com" Subject: Re: cmd compiles References: <200106081829.f58ITUX13917@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, this and Adam's info reveal much, there was nothing missing or wrong at all. Based on Adam's info, I just didn't run the full make install to include devel. But it turns out that I had missed Makepkg rpm's completely, and this was the easiest way to install. All is right, I simply did broke the golden rule and did not read the INSTALL close enough to find the correct way. D. Stimits, stimits@idcomm.com Steve Lord wrote: > > > > > > > > > I think this sequence works (from memory): > > > > > > 0. install e2fsprogs-devel for uuid code > > > > I've done this via rpm. The rpm version listed: > > e2fsprogs-1.19-4 > > e2fsprogs-devel-1.19-4 > > > > > 1. build acl and attr packages, install development rpms > > > > I've compiled and installed the cvs version of acl and attr; however, > > I'm not aware of any development rpms...are these in addition to the cvs > > cmd/acl/ and cmd/attr/ make installs? If so, where do I find the > > development version, whether in rpm or tarball format? > > OK, if you use the Makepkgs command in each command directory it will > build you rpms, if you do make install it should install all the correct > headers (a make install is used to generate the rpms). All the code is in > the cvs tree, there is nothing missing. However, it make be that make > install is not doing everything it needs to > > > > > > 2. build xfsprogs, install development rpms > > > > I have done a make install for xfsprogs in the cmd/xfsprogs/ of cvs > > devel. Now comes a similar question from the prior paragraph...are there > > development rpms or tarballs that are separate from the build and > > install of xfsprogs? If so, where can I find them in either rpm or > > tarball format? > > > > > 3. build xfsdump > > > > This is the part that fails for me, and why I think the devel stuff must > > be separate from the cvs devel tree. Or at least requires more than a > > make install from the relevant cmd subdirectory. > > Can you report exactly the failure you are seeing here (sorry I deleted > your earlier email, I have to delete stuff otherwise I drown in email > very quickly). > > Steve > > > > > D. Stimits, stimits@idcomm.com > > > > > > > > Steve From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 12:51:33 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58JpXtg017247 for linux-xfs-outgoing; Fri, 8 Jun 2001 12:51:33 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58JpS3D017236 for ; Fri, 8 Jun 2001 12:51:29 -0700 Received: from auto-nb1.xs4all.nl (perle-wan1.coltex.nl [10.0.1.177]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f58JpPq14347; Fri, 8 Jun 2001 21:51:25 +0200 Message-Id: <4.3.2.7.2.20010608213046.0333c310@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Jun 2001 21:51:28 +0200 To: "Thomas Winkler" , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: acls with samba on xfs In-Reply-To: References: <4.3.2.7.2.20010608205643.033315e0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 21:22 8-6-2001 +0200, Thomas Winkler wrote: >On Fri, 08 Jun 2001 21:03:39 +0200 > Seth Mos wrote: > > Try the most recent CVS of xfs. It's at 2.4.6-pre1 now > > which seems to do > > well in NFS serving btw. I just finished some tests with > > a linux server and > > linux/NCR MP-RAS clients. > >thats what i wanted to try today, but couldn't make a >checkout. probably the cvs server was down. hopefully next >week a can get my hands on this one. i had heavy troubles >getting the 2.4.5 to work, because of the aic7xxx related >bug. is this fixed in 2.4.6-prex release? You can get the aic7xxx compiled by selecting the build firmware option. Try checking out using the linux-xfs.sgi.com host if it works. I'll upload my linux-2.4.6pre1-xfs to http://iserv.nl/files/xfs/ It's just the kernel tree make mrpropered, it's the best I can do. The weekend is coming so that's why I uploaded the tree for interested people. It's 20+MB so a fairly hefty download. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 13:01:49 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58K1nU8018439 for linux-xfs-outgoing; Fri, 8 Jun 2001 13:01:49 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chimta01.algx.net (chimta01.algx.net [216.99.233.34]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58K1k3D018421 for ; Fri, 8 Jun 2001 13:01:46 -0700 Received: from jtsdell (66-2-81-26.customer.algx.net [66.2.81.26]) by chimmx01.algx.net (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id <0GEM00I5WNMVUU@chimmx01.algx.net> for linux-xfs@oss.sgi.com; Fri, 08 Jun 2001 15:01:44 -0500 (CDT) Date: Fri, 08 Jun 2001 16:01:26 -0400 (EDT) From: John Trostel X-Face: ".6V0NI=XK8{EozgAb}ndjF9EZ9RSB'PC.>~*YmOPr7@^P|%!%lC*;-Y`DS?nFD%REA[zXg FK>`Z|a(nT-fRWIeM0l1G,cX#{"ZPnCsbvvxIR~!'N)3c50s6sE4=H}ys&~wpcA`E0Ak"hYeua=-f# B7A>bceFAFCL;`q1L(/D To: Thomas Winkler Cc: linux-xfs@oss.sgi.com Reply-to: jtrostel@connex.com Message-id: Organization: Connex MIME-version: 1.0 X-Mailer: XFMail 1.4.7p2 on Linux Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I don't think this is an XFS problem. I wouldn't be suprised if it was a Samba problem. Why are you using TNG for PDC and HEAD for the file server, when SAMBA_2_2 could run both functions for you? I would try using SAMBA_2_2 (CVS from yesterday or today) as both the file and PDC server and see if the problems go away. Then you would know that it was a problem strictly of using TNG and/or HEAD versions of Samba. -- John M. Trostel Linux OS Engineer Connex jtrostel@connex.com From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 13:01:50 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58K1oIZ018444 for linux-xfs-outgoing; Fri, 8 Jun 2001 13:01:50 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58K1i3D018419 for ; Fri, 8 Jun 2001 13:01:46 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA1820908 for ; Fri, 8 Jun 2001 22:01:38 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2106506 for ; Fri, 8 Jun 2001 15:00:21 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA74844 for ; Fri, 8 Jun 2001 15:00:21 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f58K33K16559; Fri, 8 Jun 2001 15:03:03 -0500 Message-Id: <200106082003.f58K33K16559@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com Subject: Re: Yet more oss breakage (fwd) Date: Fri, 08 Jun 2001 15:03:03 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is what is going on with the oss site right now. I do not really know when soon is. Steve ------- Forwarded Message Date: Fri, 08 Jun 2001 12:56:58 -0700 From: Trevor Hurst To: Steve Lord Subject: Re: Yet more oss breakage We're in the process of upgrading it right now. It will be back up soon. For now, linux-xfs is taking over temporarily for oss... - -- Trev From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 13:05:44 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58K5iMK019123 for linux-xfs-outgoing; Fri, 8 Jun 2001 13:05:44 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58K5e3D019103 for ; Fri, 8 Jun 2001 13:05:40 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA1646087 for ; Fri, 8 Jun 2001 22:05:38 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2103373 for ; Fri, 8 Jun 2001 15:04:21 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA45806 for ; Fri, 8 Jun 2001 15:04:21 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f58K73716567; Fri, 8 Jun 2001 15:07:03 -0500 Message-Id: <200106082007.f58K73716567@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com Subject: There is a book on XFS Date: Fri, 08 Jun 2001 15:07:03 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk So it turns out you can actually buy a book on XFS, it is somewhat spendy ($57), and contains much info which is Irix specific. It does however go into some detail on dump/restore and other stuff and has printed versions of the man pages. So for those of you with money to spare: http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=1400512638&vm= And for those of you who are cheapskates: http://techpubs.sgi.com:80/library/tpl/cgi-bin/download.cgi?coll=0530&db=bks&pth=/SGI_Admin/XFS_AG I think this is externally accessible, and you can get the pdf form of the book from here for the price of a 500K download. Steve From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 13:13:10 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58KDAeC019984 for linux-xfs-outgoing; Fri, 8 Jun 2001 13:13:10 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from itcampus.de (www.itcampus.de [194.45.97.156]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58KD63D019974 for ; Fri, 8 Jun 2001 13:13:07 -0700 Received: from [195.252.152.186] (account ) by itcampus.de (CommuniGate Pro WebUser 3.3.1) with HTTP id 99658; Fri, 08 Jun 2001 22:15:59 +0200 From: "Thomas Winkler" Subject: Re: acls with samba on xfs To: Cc: Seth Mos X-Mailer: CommuniGate Pro Web Mailer v.3.3.1 Date: Fri, 08 Jun 2001 22:15:59 +0200 Message-ID: In-Reply-To: <4.3.2.7.2.20010608213046.0333c310@pop.xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_===99658====itcampus.de===_" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part MIME message --_===99658====itcampus.de===_ Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit On Fri, 08 Jun 2001 21:51:28 +0200 Seth Mos wrote: > You can get the aic7xxx compiled by selecting the build > firmware option. > Try checking out using the linux-xfs.sgi.com host if it > works. Did not work for me. i followed the discussion, but could not get it to work on our server. tryed on my home machine without scsi controller and experienced problems in the ext_attr.c ext_attr.c:56: parse error before `obj' ext_attr.c:57: warning: function declaration isn't a prototype ext_attr.c: In function `sys_attrctl': ext_attr.c:64: `count' undeclared (first use in this function) ext_attr.c:64: (Each undeclared identifier is reported only once ext_attr.c:64: for each function it appears in.) ext_attr.c:69: `type' undeclared (first use in this function) ext_attr.c:70: `ATTR_TYPE_FD' undeclared (first use in this function) ext_attr.c:71: `obj' undeclared (first use in this function) ext_attr.c:78: `ATTR_TYPE_PATH' undeclared (first use in this function) ext_attr.c:86: `ATTR_TYPE_LPATH' undeclared (first use in this function) ext_attr.c:93: `ATTR_TYPE_PID' undeclared (first use in this function) ext_attr.c:71: warning: unreachable code at beginning of switch statement ext_attr.c:123: `ops' undeclared (first use in this function) i am running a red hat 7.1 box installed with the sgi xfs 1.0 cd. well, don't know whats the problem with the 2.4.5? i didn't have any problems with last releases (2.4.2-4). thats why i decided to wait for 2.4.6. > I'll upload my linux-2.4.6pre1-xfs to > http://iserv.nl/files/xfs/ > It's just the kernel tree make mrpropered, it's the best > I can do. The > weekend is coming so that's why I uploaded the tree for > interested people. > > It's 20+MB so a fairly hefty download. thanks a lot. hopefully i can get my hand on it this weekend. at home i'm sitting behind a 56k, so i wont try. thank you, thomas ------------------------------- itCampus Software- und Systemhaus Gmnh Leipzig - Halle - Wittenberg http://www.itcampus.de --_===99658====itcampus.de===_ Content-Type: text/plain Content-Disposition: attachment; filename="" Content-Transfer-Encoding: base64 DQo= --_===99658====itcampus.de===_ Content-Type: text/plain Content-Disposition: attachment; filename="" Content-Transfer-Encoding: base64 DQo= --_===99658====itcampus.de===_ Content-Type: text/plain Content-Disposition: attachment; filename="" Content-Transfer-Encoding: base64 DQo= --_===99658====itcampus.de===_-- From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 13:24:06 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58KO6bL021032 for linux-xfs-outgoing; Fri, 8 Jun 2001 13:24:06 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from itcampus.de (www.itcampus.de [194.45.97.156]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58KO13D021029 for ; Fri, 8 Jun 2001 13:24:04 -0700 Received: from [195.252.152.186] (account ) by itcampus.de (CommuniGate Pro WebUser 3.3.1) with HTTP id 99663; Fri, 08 Jun 2001 22:26:55 +0200 From: "Thomas Winkler" Subject: Re: acls with samba on xfs To: Cc: jtrostel@connex.com X-Mailer: CommuniGate Pro Web Mailer v.3.3.1 Date: Fri, 08 Jun 2001 22:26:55 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_===99663====itcampus.de===_" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part MIME message --_===99663====itcampus.de===_ Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit On Fri, 08 Jun 2001 16:01:26 -0400 (EDT) John Trostel wrote: > I don't think this is an XFS problem. I wouldn't be > suprised if it was a Samba > problem. think so, too. > Why are you using TNG for PDC and HEAD for the > file server, when > SAMBA_2_2 could run both functions for you? we are using tng as pdc because we need to use ldap as authentication backend. as far as i know samba 2.2.0 can't do that. in the mailing list it was just said that its on the todo list and not to be implemented till september/october. the tng is running very well, but is imho not usable for fileserving. we did quite some testing on this. thats why we decided to run a dual samba system like this. it's running without any problems for quite a while now. > I would try using SAMBA_2_2 (CVS from yesterday or today) > as both the file and > PDC server and see if the problems go away. Then you > would know that it was a > problem strictly of using TNG and/or HEAD versions of > Samba. we'll probably try this next week, but we want to stick with the ldap solution for now. hope tng is not the reason. ------------------------------- itCampus Software- und Systemhaus GmbH Leipzig - Halle - Wittenberg http://www.itcampus.de --_===99663====itcampus.de===_ Content-Type: text/plain Content-Disposition: attachment; filename="" Content-Transfer-Encoding: base64 DQo= --_===99663====itcampus.de===_ Content-Type: text/plain Content-Disposition: attachment; filename="" Content-Transfer-Encoding: base64 DQo= --_===99663====itcampus.de===_ Content-Type: text/plain Content-Disposition: attachment; filename="" Content-Transfer-Encoding: base64 DQo= --_===99663====itcampus.de===_-- From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 13:31:19 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58KVJES021631 for linux-xfs-outgoing; Fri, 8 Jun 2001 13:31:19 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from blipvert.blank.org (blipvert.blank.org [216.112.239.86]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58KVG3D021625 for ; Fri, 8 Jun 2001 13:31:17 -0700 Received: (qmail 15402 invoked by uid 500); 8 Jun 2001 20:31:14 -0000 Date: Fri, 8 Jun 2001 16:31:14 -0400 From: "Nathan J. Mehl" To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: RH7.1 ISO: panic on boot after install. Message-ID: <20010608163114.L8330@blank.org> References: <20010607141357.Z8330@blank.org> <4.3.2.7.2.20010607211301.0349d628@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010607211301.0349d628@pop.xs4all.nl>; from knuffie@xs4all.nl on Thu, Jun 07, 2001 at 09:15:39PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Okay; upgrading to linux 2.4.5 and the linux-2.4.5-xfs-06042001.patch appears to have resolved things for the moment. A pox on VIA. :-b -n ------------------------------------------------------------ "Doing those tests, however, meant giving dead armadillos erections, no mean accomplishment." (--Steve Mirsky, 9/1997 SciAm) ---------------------------------------------------- From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 13:38:26 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58KcQhp022294 for linux-xfs-outgoing; Fri, 8 Jun 2001 13:38:26 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chimta02 (chimta02.algx.net [216.99.233.77]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58KcN3D022283 for ; Fri, 8 Jun 2001 13:38:24 -0700 Received: from jtsdell (66-2-81-26.customer.algx.net [66.2.81.26]) by chimmx02.algx.net (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id <0GEM006C2P76G9@chimmx02.algx.net> for linux-xfs@oss.sgi.com; Fri, 08 Jun 2001 15:35:37 -0500 (CDT) Date: Fri, 08 Jun 2001 16:35:10 -0400 (EDT) From: jtrostel@connex.com Subject: RE: There is a book on XFS In-reply-to: <200106082007.f58K73716567@jen.americas.sgi.com> To: linux-xfs@oss.sgi.com Reply-to: jtrostel@connex.com Message-id: Organization: Connex MIME-version: 1.0 X-Mailer: XFMail 1.5.0 on Linux Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yes... it is externally accessible! Thanks Steve. (And, yes, I am a cheapskate) On 08-Jun-2001 Steve Lord wrote: > > > So it turns out you can actually buy a book on XFS, it is somewhat spendy > ($57), > and contains much info which is Irix specific. It does however go into some > detail on dump/restore and other stuff and has printed versions of the man > pages. > > So for those of you with money to spare: > > http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=1400512638&vm= > > And for those of you who are cheapskates: > > http://techpubs.sgi.com:80/library/tpl/cgi-bin/download.cgi?coll=0530&db=bks&p > th=/SGI_Admin/XFS_AG > > I think this is externally accessible, and you can get the pdf form of the > book from here for the price of a 500K download. > > Steve -- John M. Trostel Linux OS Engineer Connex jtrostel@connex.com From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 13:41:17 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58KfHgO022624 for linux-xfs-outgoing; Fri, 8 Jun 2001 13:41:17 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58KfG3D022619 for ; Fri, 8 Jun 2001 13:41:16 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA00168 for ; Fri, 8 Jun 2001 13:41:32 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2104074; Fri, 8 Jun 2001 15:39:58 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA24470; Fri, 8 Jun 2001 15:39:58 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f58Kgd417277; Fri, 8 Jun 2001 15:42:39 -0500 Message-Id: <200106082042.f58Kgd417277@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Nathan J. Mehl" cc: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: RH7.1 ISO: panic on boot after install. In-Reply-To: Message from "Nathan J. Mehl" of "Fri, 08 Jun 2001 16:31:14 EDT." <20010608163114.L8330@blank.org> Date: Fri, 08 Jun 2001 15:42:39 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Okay; upgrading to linux 2.4.5 and the linux-2.4.5-xfs-06042001.patch > appears to have resolved things for the moment. > Just FYI, I think that patch has the NFS permissions problem, to fix this go to line 193 of linux/fs/xfs/linux/xfs_vnode.c and make sure the code looks like this: if (from_readinode) { if (xfs_vn_iget(vfsp, vp, (xfs_ino_t)inode->i_ino)) { make_bad_inode(inode); } else { linvfs_set_inode_ops(inode); vn_revalidate(vp, ATTR_LAZY|ATTR_COMM); ^^^^^^^^^^^^^ This call was missing } VN_UNLOCK(vp, s); } I am pondering how to respin a 2.4.5 patch, I may have to hand edit it. Steve From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 13:57:35 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58KvZ5a024252 for linux-xfs-outgoing; Fri, 8 Jun 2001 13:57:35 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58KvW3D024238 for ; Fri, 8 Jun 2001 13:57:33 -0700 Received: from geeksrus.net (localhost.localdomain [127.0.0.1]) by wwweasel.geeksrus.net (8.11.2/8.11.2) with SMTP id f58KvNn05056; Fri, 8 Jun 2001 16:57:25 -0400 From: Alan Eldridge Received: from 164.57.254.209 (SquirrelMail authenticated user alane) by wwweasel.geeksrus.net with HTTP; Fri, 8 Jun 2001 16:57:25 -0400 (EDT) Message-ID: <52766.164.57.254.209.992033845.squirrel@wwweasel.geeksrus.net> Date: Fri, 8 Jun 2001 16:57:25 -0400 (EDT) Subject: =?iso-8859-1?Q?Re:_patch_for_patch?= To: In-Reply-To: <3B2112F5.5450D65@thebarn.com> References: <3B2112F5.5450D65@thebarn.com> Cc: X-Mailer: SquirrelMail (version 1.1.2) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Alan Eldridge wrote: > >> The fs/Config.in patch is missing the default. Fixed: > > Hmm what? > its there. >> CONFIG_UFS_FS_WRITE $CONFIG_UFS_FS $CONFIG_EXPERIMENTAL >> + >> +tristate 'Page Buffer support' CONFIG_PAGE_BUF y I had to add this "y" **********^ to the patch file. The kernel rpm would not (auto-)configure without it. The RPM's configure invocation bombed out because there was no default set for CONFIG_PAGE_BUF. [alane@wwweasel alane]$ ls -l RH* -rw-r--r-- 1 alane alane 120238 Jun 8 02:26 RHlinux-2.4.5-core- xfs-06082001.patch -rw-r--r-- 1 alane alane 120239 Jun 8 16:46 RHlinux-2.4.5-core- xfs-06082001.patch.new [alane@wwweasel alane]$ diff -w RH* 2489c2489 < +tristate 'Page Buffer support' CONFIG_PAGE_BUF --- > +tristate 'Page Buffer support' CONFIG_PAGE_BUF y [alane@wwweasel alane]$ From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 13:59:50 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58KxosL024477 for linux-xfs-outgoing; Fri, 8 Jun 2001 13:59:50 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58Kxe3D024446 for ; Fri, 8 Jun 2001 13:59:43 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA1151071 for ; Fri, 8 Jun 2001 22:59:37 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2103885 for ; Fri, 8 Jun 2001 15:58:21 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA06399 for ; Fri, 8 Jun 2001 15:58:21 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f58L12e17668; Fri, 8 Jun 2001 16:01:02 -0500 Message-Id: <200106082101.f58L12e17668@jen.americas.sgi.com> Date: Fri, 8 Jun 2001 16:01:02 -0500 Subject: TAKE - speed up unmount on dirty filesystem Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk If you delete a lot of files and then unmount the filesystem it can take quite a while to complete the unmount. The last part of the removal of an inode happens asynchronously from the user thread, the way these were being processed during unmount meant it could actually get stuck waiting several seconds for a buffer to become free. This changes the logic to avoid this. Date: Fri Jun 8 13:55:16 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:96591a linux/fs/xfs/xfs_vnodeops.c - 1.504 - Make the mode used on flushing of freed inode controllable - on unmount we do not want to be delayed write as we can end up waiting for a buffer for several seconds. linux/fs/xfs/xfs_vfsops.c - 1.318 - change xfs_finish_reclaim call from sync linux/fs/xfs/xfs_inode.c - 1.320 - Make the mode used on flushing of freed inode controllable - on unmount we do not want to be delayed write as we can end up waiting for a buffer for several seconds. From xfs_iflush_all use the new parameter to indicate we should do async writes not delayed ones. linux/fs/xfs/xfs_inode.h - 1.150 - Change prototype for xfs_finish_reclaim From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 14:18:52 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58LIqAq026169 for linux-xfs-outgoing; Fri, 8 Jun 2001 14:18:52 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from amoa.org (amoa.org [207.207.51.226]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58LIb3D026141 for ; Fri, 8 Jun 2001 14:18:43 -0700 Received: by amoa.org(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256A65.0075121C ; Fri, 8 Jun 2001 16:18:43 -0500 X-Lotus-FromDomain: AMOA From: ctooley@amoa.org To: linux-xfs@oss.sgi.com Message-ID: <86256A65.00751066.00@amoa.org> Date: Fri, 8 Jun 2001 16:18:38 -0500 Subject: RE: There is a book on XFS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk And yes, that book has probably now been downloaded more times in just one day, than the whole rest of the time before. :) jtrostel@connex.com on 06/08/2001 03:35:10 PM Please respond to jtrostel@connex.com To: linux-xfs@oss.sgi.com cc: (bcc: Chris Tooley/AMOA) Subject RE: There is a book on XFS : Yes... it is externally accessible! Thanks Steve. (And, yes, I am a cheapskate) On 08-Jun-2001 Steve Lord wrote: > > > So it turns out you can actually buy a book on XFS, it is somewhat spendy > ($57), > and contains much info which is Irix specific. It does however go into some > detail on dump/restore and other stuff and has printed versions of the man > pages. > > So for those of you with money to spare: > > http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=1400512638&vm= > > And for those of you who are cheapskates: > > http://techpubs.sgi.com:80/library/tpl/cgi-bin/download.cgi?coll=0530&db=bks&p > th=/SGI_Admin/XFS_AG > > I think this is externally accessible, and you can get the pdf form of the > book from here for the price of a 500K download. > > Steve -- John M. Trostel Linux OS Engineer Connex jtrostel@connex.com From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 14:19:35 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58LC2Ko025608 for linux-xfs-outgoing; Fri, 8 Jun 2001 14:12:02 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58LBi3D025579 for ; Fri, 8 Jun 2001 14:11:50 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA08070 for ; Fri, 8 Jun 2001 14:11:21 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2106972 for ; Fri, 8 Jun 2001 16:10:05 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA96959 for ; Fri, 8 Jun 2001 16:10:05 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f58LCks17786; Fri, 8 Jun 2001 16:12:46 -0500 Message-Id: <200106082112.f58LCks17786@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com Subject: cvs working again Date: Fri, 08 Jun 2001 16:12:46 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We are still using a backup machine for oss, but cvs is functioning again now. Steve From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 14:32:00 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58LW0Zw027108 for linux-xfs-outgoing; Fri, 8 Jun 2001 14:32:00 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58LVh3D027089 for ; Fri, 8 Jun 2001 14:31:50 -0700 Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA01270 for ; Fri, 8 Jun 2001 14:24:10 -0700 (PDT) mail_from (knuffie@xs4all.nl) Received: from qn-212-58-163-247.quicknet.nl ([212.58.163.247]:63959 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Fri, 8 Jun 2001 23:23:57 +0200 Message-Id: <4.3.2.7.2.20010608232103.033417c8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Jun 2001 23:23:54 +0200 To: Steve Lord , "Nathan J. Mehl" From: Seth Mos Subject: Re: RH7.1 ISO: panic on boot after install. Cc: linux-xfs@oss.sgi.com In-Reply-To: <200106082042.f58Kgd417277@jen.americas.sgi.com> References: <20010608163114.L8330@blank.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:42 8-6-2001 -0500, Steve Lord wrote: > > > > Okay; upgrading to linux 2.4.5 and the linux-2.4.5-xfs-06042001.patch > > appears to have resolved things for the moment. > > > >Just FYI, I think that patch has the NFS permissions problem, to fix this >go to line 193 of linux/fs/xfs/linux/xfs_vnode.c and make sure the code >looks like this: > > if (from_readinode) { > > if (xfs_vn_iget(vfsp, vp, (xfs_ino_t)inode->i_ino)) { > make_bad_inode(inode); > } else { > linvfs_set_inode_ops(inode); > vn_revalidate(vp, ATTR_LAZY|ATTR_COMM); > ^^^^^^^^^^^^^ > This call was missing > > } > VN_UNLOCK(vp, s); > } > >I am pondering how to respin a 2.4.5 patch, I may have to hand edit it. The tarbal of the 2.4.6pre1 tree has arrived and is available. I'll spin a patch of that and upload it to http://iserv.nl/files/xfs/ Greets -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 14:43:30 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58LhUwN028161 for linux-xfs-outgoing; Fri, 8 Jun 2001 14:43:30 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58LhN3D028153 for ; Fri, 8 Jun 2001 14:43:26 -0700 Received: from auto-nb1.xs4all.nl (perle-wan1.coltex.nl [10.0.1.177]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f58LhKq14458 for ; Fri, 8 Jun 2001 23:43:21 +0200 Message-Id: <4.3.2.7.2.20010608233942.0337faf0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Jun 2001 23:43:23 +0200 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: 2.4.6-pre1 patch Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk OK I've got the 2.4.6-pre1 tree and patch up at http://iserv.nl/files/xfs/ For the moment untill oss or linux-xfs is up in some decent form. Bye -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 15:15:06 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58MF6UR030548 for linux-xfs-outgoing; Fri, 8 Jun 2001 15:15:06 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58MF53D030543 for ; Fri, 8 Jun 2001 15:15:05 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA00634 for ; Fri, 8 Jun 2001 15:15:03 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2102568; Fri, 8 Jun 2001 17:13:48 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA80389; Fri, 8 Jun 2001 17:13:48 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f58MGT117995; Fri, 8 Jun 2001 17:16:29 -0500 Message-Id: <200106082216.f58MGT117995@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com cc: tgr@spoiled.org (thomas graichen), knuffie@xs4all.nl (Seth Mos) Subject: New FAQ Maintainer Date: Fri, 08 Jun 2001 17:16:29 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, A few days ago I asked for volunteers to the new FAQ maintainer in light of the limited time Thomas Graichen has nowadays to keep it upto date. Several people volunteered, and the end result is that Seth Mos has agreed to be the new maintainer. I would like to thank Thomas for initiating the FAQ, and for the work he was able to do on XFS whilst at Innominate. Thomas was a pioneer on getting XFS up on the Power PC and Alpha platforms and we had some very interesting remote debugging sessions via printk and email. So, thanks Thomas, and thanks to Seth for taking over. Steve From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 15:40:57 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58MevDF032444 for linux-xfs-outgoing; Fri, 8 Jun 2001 15:40:57 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58Mes3D032437 for ; Fri, 8 Jun 2001 15:40:55 -0700 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA00595 for ; Fri, 8 Jun 2001 15:40:53 -0700 (PDT) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA43535; Fri, 8 Jun 2001 15:44:39 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 0BB2C15A47D; Fri, 8 Jun 2001 15:39:07 -0700 (PDT) Subject: Re: growing a partition From: Florin Andrei To: ctooley@amoa.org Cc: linux-xfs@oss.sgi.com In-Reply-To: <86256A64.00644FF1.00@amoa.org> References: <86256A64.00644FF1.00@amoa.org> Content-Type: text/plain X-Mailer: Evolution/0.10 (Preview Release) Date: 08 Jun 2001 15:39:06 -0700 Message-Id: <992039947.16403.3.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 07 Jun 2001 13:15:39 -0500, ctooley@amoa.org wrote: > > just make your partition larger by using FDISK. Delete the partition with fdisk > and create it, making sure to use the same starting point you had used before. > Since this only changes the partition table you should be fine. Be forwarned > though that editing the partition table can lead to lots of migraines. I had no > trouble with mine. After you have rebooted (if you change the partition that / > lives on it's going to not be reported right until you reboot) you can just type > "xfs_growfs /" at the prompt and it will magically make space for you. It made Rebooted into single mode (because the erased partitions were /var/log and /var/spool), did exactly as you said. The result: everything's fine. Your method works perfectly. Thanks, -- Florin Andrei From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 16:24:45 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58NOj2D001476 for linux-xfs-outgoing; Fri, 8 Jun 2001 16:24:45 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from amoa.org (amoa.org [207.207.51.226]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58NOh3D001472 for ; Fri, 8 Jun 2001 16:24:43 -0700 Received: by amoa.org(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256A65.00809F89 ; Fri, 8 Jun 2001 18:24:54 -0500 X-Lotus-FromDomain: AMOA From: ctooley@amoa.org To: Florin Andrei cc: linux-xfs@oss.sgi.com Message-ID: <86256A65.00809DCF.00@amoa.org> Date: Fri, 8 Jun 2001 18:24:48 -0500 Subject: Re: growing a partition Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I can't take credit, it was pointed out to me. It seems to work but the severity of what it could mean is not something to recommend to an average user. Chris Florin Andrei on 06/08/2001 03:39:06 PM To: Chris Tooley/AMOA@AMOA cc: linux-xfs@oss.sgi.com Subject Re: growing a partition : On 07 Jun 2001 13:15:39 -0500, ctooley@amoa.org wrote: > > just make your partition larger by using FDISK. Delete the partition with fdisk > and create it, making sure to use the same starting point you had used before. > Since this only changes the partition table you should be fine. Be forwarned > though that editing the partition table can lead to lots of migraines. I had no > trouble with mine. After you have rebooted (if you change the partition that / > lives on it's going to not be reported right until you reboot) you can just type > "xfs_growfs /" at the prompt and it will magically make space for you. It made Rebooted into single mode (because the erased partitions were /var/log and /var/spool), did exactly as you said. The result: everything's fine. Your method works perfectly. Thanks, -- Florin Andrei From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 18:06:20 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f5916KmO005837 for linux-xfs-outgoing; Fri, 8 Jun 2001 18:06:20 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from walt400.holman.net (aazpppdsl56.sttl.uswest.net [63.226.208.56]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f5916I3D005830 for ; Fri, 8 Jun 2001 18:06:18 -0700 Received: from uswest.net (walt400.holman.net [10.0.0.2]) by walt400.holman.net (Postfix) with ESMTP id 667F240F0AF; Fri, 8 Jun 2001 18:16:12 -0700 (PDT) Message-ID: <3B2178DC.2090803@uswest.net> Date: Fri, 08 Jun 2001 18:16:12 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-xfs i686; en-US; rv:0.9.1) Gecko/20010607 X-Accept-Language: en-us MIME-Version: 1.0 To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: cvs working again References: <200106082112.f58LCks17786@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I'm getting a strange error when attempting a checkout at CVS now: cvs -z3 co linux-2.4-xfs cvs [server aborted]: can't chdir(/home/cattelan): No such file or directory Maybe I'm spaced out (it's happened before), but I can't seem to co anything at the moment. I wanted to try 2.4.6-pre1 to see if it corrected the high memory usage that showed up with 2.4.5 - don't think it's XFS related though, cause /proc/slab shows no unusual usage with inodes etc... Just improper freeing by the VM it would appear. Too much swap usage for this system. Any help is greatly appreciated. Thanks, -Walt Steve Lord wrote: >We are still using a backup machine for oss, but cvs is functioning again now. > >Steve > > > From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 18:29:36 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f591TaYD007495 for linux-xfs-outgoing; Fri, 8 Jun 2001 18:29:36 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f591TY3D007480 for ; Fri, 8 Jun 2001 18:29:35 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip35.idcomm.com [209.60.72.162]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f591cdU04052 for ; Fri, 8 Jun 2001 19:38:39 -0600 Message-ID: <3B217C2C.A31D6ECC@idcomm.com> Date: Fri, 08 Jun 2001 19:30:20 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: xfstests Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk How important is it to run the cmd/xfstests? The extra partition requirement can be a pain to come up with, but if the xfstests are more or less just there for good feelings now, I might consider ignoring it. What do I gain or lose by running or not running the xfstests? D. Stimits, stimits@idcomm.com From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 18:34:26 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f591YQLI007905 for linux-xfs-outgoing; Fri, 8 Jun 2001 18:34:26 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from server.home.fliegl.de ([195.180.174.246]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f591YO3D007890 for ; Fri, 8 Jun 2001 18:34:25 -0700 Received: from fliegl.de (server.home.fliegl.de [172.16.1.1]) by server.home.fliegl.de (Maggifix) with ESMTP id 1A8EC4AAA9 for ; Sat, 9 Jun 2001 03:34:18 +0200 (CEST) Message-ID: <3B217D19.986150C4@fliegl.de> Date: Sat, 09 Jun 2001 03:34:17 +0200 From: Deti Fliegl X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux XFS Mailing List Subject: XFS lockup with samba-2.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, today something strange happened on a system running 2.4.6-pre1 from the latest CVS tree together with kernel NFS V3 support and samba-2.2 with windows 2000 clients. After I tried to move a directory under windows 2000 from one location to another within the same XFS partition the windows 2000 client locked up. First I thought there might be a windows problem - but it turned out that the corresponding smbd process on the linux box got into the D state and this happened to all other processes accessing the target directory (of the move). After a while I had a couple of processes (like ls, bash, find ...) all in the D state from the moment on when they tried to stat this particular directory. There were no system messages describing a possible reason for the lockup. After a reboot everything was fine again. In the meantime I configured samba not to use kernel OP locks and the problem did not occur again. This could be a clue but I was not able to do further testing since the system is used for production. Kind regards Deti From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 18:34:28 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f591YSCN007914 for linux-xfs-outgoing; Fri, 8 Jun 2001 18:34:28 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f591YQ3D007895 for ; Fri, 8 Jun 2001 18:34:26 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f591YK006288 for linux-xfs@oss.sgi.com; Fri, 8 Jun 2001 21:34:20 -0400 Date: Fri, 8 Jun 2001 21:34:20 -0400 From: Alan Eldridge To: linux-xfs@oss.sgi.com Subject: config patch revisited Message-ID: <20010608213420.A15810@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I didn't get that quite right it seems. Urk. It worked after patching when I did make oldconfig_nonint, but the subsequent run on a fresh rpm -ba failed. It's state dependent. The right patch for fs/Config.in is: ---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<--- --- /build/RH_raw/linux/fs/Config.in Fri Jun 8 20:39:39 2001 +++ linux/fs/Config.in Fri Jun 8 21:09:35 2001 @@ -5,6 +5,8 @@ comment 'File systems' bool 'Quota support' CONFIG_QUOTA +[ $CONFIG_FS_POSIX_ACL ] || CONFIG_FS_POSIX_ACL=n +bool 'POSIX Access Control List support' CONFIG_FS_POSIX_ACL tristate 'Kernel automounter support' CONFIG_AUTOFS_FS tristate 'Kernel automounter version 4 support (also supports v3)' CONFIG_AUTOFS4_FS @@ -84,6 +86,23 @@ 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 + +[ $CONFIG_PAGE_BUF ] || CONFIG_PAGE_BUF=y +tristate 'Page Buffer support' CONFIG_PAGE_BUF + +if [ "$CONFIG_PAGE_BUF" = "n" ]; then + comment ' Page Buffer support needed for XFS filesystem' +else + [ $CONFIG_XFS_FS ] || CONFIG_XFS_FS=y + dep_tristate 'SGI XFS filesystem support' CONFIG_XFS_FS $CONFIG_PAGE_BUF + if [ "$CONFIG_XFS_FS" != "n" ]; then + define_bool CONFIG_HAVE_ATTRCTL y + [ $CONFIG_XFS_DMAPI ] || CONFIG_XFS_DMAPI=y + dep_mbool ' Enable XFS DMAPI' CONFIG_XFS_DMAPI $CONFIG_XFS_FS + [ $CONFIG_XFS_QUOTA ] || CONFIG_XFS_QUOTA=y + dep_mbool ' Enable XFS Quota' CONFIG_XFS_QUOTA $CONFIG_XFS_FS $CONFIG_QUOTA + fi +fi if [ "$CONFIG_NET" = "y" ]; then ---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<--- -- Alan Eldridge "Uh, I think so, Brain, but isn't Regis Philbin already married?" From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 18:45:39 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f591jdc8008837 for linux-xfs-outgoing; Fri, 8 Jun 2001 18:45:39 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from barabas.bitstream.net (barabas.bitstream.net [216.243.128.159]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f591jX3D008823 for ; Fri, 8 Jun 2001 18:45:35 -0700 Received: (qmail 20048 invoked from network); 9 Jun 2001 01:45:31 -0000 Received: from unknown (HELO sgi.com) (216.243.158.69) by barabas with SMTP; 9 Jun 2001 01:45:31 -0000 Message-ID: <3B217F29.92596192@sgi.com> Date: Fri, 08 Jun 2001 20:43:05 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: stimits@idcomm.com CC: "linux-xfs@oss.sgi.com" Subject: Re: xfstests References: <3B217C2C.A31D6ECC@idcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "D. Stimits" wrote: > > How important is it to run the cmd/xfstests? The extra partition > requirement can be a pain to come up with, but if the xfstests are more > or less just there for good feelings now, I might consider ignoring it. > What do I gain or lose by running or not running the xfstests? You gain warm fuzzies that the CVS tree you checked out is functioning more or less correctly. :) If you have an "official" release, I wouldn't even bother with the tests unless you're just curious. If you're using CVS snapshots on a machine of any importance, running through the tests on a new kernel might be good. I generally make sure any change I commit can pass all the tests, but sometimes things sneak through. And as a side note, even if a test fails, it is often the case that the test itself, rather than XFS, has broken as a result of some change... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 18:58:18 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f591wIg1009832 for linux-xfs-outgoing; Fri, 8 Jun 2001 18:58:18 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from barabas.bitstream.net (barabas.bitstream.net [216.243.128.159]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f591wH3D009827 for ; Fri, 8 Jun 2001 18:58:17 -0700 Received: (qmail 25111 invoked from network); 9 Jun 2001 01:58:16 -0000 Received: from unknown (HELO sgi.com) (216.243.158.69) by barabas with SMTP; 9 Jun 2001 01:58:16 -0000 Message-ID: <3B218225.A3E984D0@sgi.com> Date: Fri, 08 Jun 2001 20:55:49 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Walt H CC: linux-xfs@oss.sgi.com Subject: Re: cvs working again References: <200106082112.f58LCks17786@jen.americas.sgi.com> <3B2178DC.2090803@uswest.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Walt H wrote: > > Hello, > > I'm getting a strange error when attempting a checkout at CVS now: > > cvs -z3 co linux-2.4-xfs > cvs [server aborted]: can't chdir(/home/cattelan): No such file or directory Hm, several of the cron jobs that push things around run under Russell's account... that + the machine switch has probably broken things once again. I'll poke around, but I'm sure Russell will patch it up as soon as he sees this. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 19:11:17 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f592BHXa010755 for linux-xfs-outgoing; Fri, 8 Jun 2001 19:11:17 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f592BE3D010748 for ; Fri, 8 Jun 2001 19:11:15 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f592BdO08001; Sat, 9 Jun 2001 12:11:41 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Alan Eldridge cc: cattelan@thebarn.com, linux-xfs@oss.sgi.com Subject: Re: =?iso-8859-1?Q?Re:_patch_for_patch?= In-reply-to: Your message of "Fri, 08 Jun 2001 16:57:25 -0400." <52766.164.57.254.209.992033845.squirrel@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Jun 2001 12:11:39 +1000 Message-ID: <8000.992052699@ocs4.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 8 Jun 2001 16:57:25 -0400 (EDT), Alan Eldridge wrote: >>> +tristate 'Page Buffer support' CONFIG_PAGE_BUF y > I had to add this "y" **********^ > >to the patch file. The kernel rpm would not (auto-)configure without it. >The RPM's configure invocation bombed out because there was no default set >for CONFIG_PAGE_BUF. That means there is something wrong with the auto-configure and we need more details on what is failing. Changing fs/Config.in is not the correct fix, tristate does not take a default value[*], no other tristate field in fs/Config.in needs a default. [*] linux/Documentation/kbuild/config-language.txt From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 19:16:05 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f592G5QL011198 for linux-xfs-outgoing; Fri, 8 Jun 2001 19:16:05 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f592G23D011186 for ; Fri, 8 Jun 2001 19:16:03 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f592GxX08026; Sat, 9 Jun 2001 12:16:59 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Alan Eldridge cc: linux-xfs@oss.sgi.com Subject: Re: config patch revisited In-reply-to: Your message of "Fri, 08 Jun 2001 21:34:20 -0400." <20010608213420.A15810@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Jun 2001 12:16:59 +1000 Message-ID: <8025.992053019@ocs4.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 8 Jun 2001 21:34:20 -0400, Alan Eldridge wrote: >+++ linux/fs/Config.in Fri Jun 8 21:09:35 2001 >+[ $CONFIG_PAGE_BUF ] || CONFIG_PAGE_BUF=y Arrgh, please do not use shell code in config.in files. The config language is *NOT* shell, the above will work for some parsers but not all of them. Documentation/kbuild/config-language.txt Although it looks, and usually acts, like a subset of the 'sh' language, Config Language has a restricted syntax and different semantics. Please provide details on the problem you are seeing instead of fixes, I am almost certain that the problem is not in config.in, it is probably in a default config file. From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 19:49:01 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f592n1Dd013602 for linux-xfs-outgoing; Fri, 8 Jun 2001 19:49:01 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f592mt3D013593 for ; Fri, 8 Jun 2001 19:48:56 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA06725 for ; Fri, 8 Jun 2001 19:48:49 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA2105837; Fri, 8 Jun 2001 21:47:33 -0500 (CDT) Received: from laptop.americas.sgi.com (lord-h2.americas.sgi.com [206.11.101.43]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id VAA12940; Fri, 8 Jun 2001 21:47:32 -0500 (CDT) From: Steve Lord Received: by laptop.americas.sgi.com (8.11.2/SGI-client-1.7) id f592gSn04279; Fri, 8 Jun 2001 21:42:28 -0500 Message-Id: <200106090242.f592gSn04279@laptop.americas.sgi.com> Date: Fri, 8 Jun 2001 21:42:28 -0500 Subject: TAKE - merge up to 2.4.6-pre2 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk merge up to 2.4.6-pre2, testing is fairly minimal, but apart from the mount code being blasted to bits there were no real filesystem changes in here. Date: Fri Jun 8 19:44:24 PDT 2001 Workarea: lord-h2.americas.sgi.com:/src/lord/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:96614a linux/drivers/bluetooth/hci_uart.c - 1.1 linux/include/asm-m68k/raw_io.h - 1.1 linux/include/asm-m68k/mc146818rtc.h - 1.1 linux/include/asm-m68k/rtc.h - 1.1 linux/include/asm-m68k/sun3xflop.h - 1.1 linux/include/asm-m68k/sun3xprom.h - 1.1 linux/include/asm-m68k/zorro.h - 1.1 linux/include/linux/netfilter_bridge.h - 1.1 linux/include/net/bluetooth/bluetooth.h - 1.1 linux/include/net/bluetooth/bluez.h - 1.1 linux/include/net/bluetooth/hci.h - 1.1 linux/include/net/bluetooth/hci_core.h - 1.1 linux/include/net/bluetooth/hci_emu.h - 1.1 linux/include/net/bluetooth/hci_uart.h - 1.1 linux/include/net/bluetooth/hci_usb.h - 1.1 linux/include/net/bluetooth/l2cap.h - 1.1 linux/include/net/bluetooth/l2cap_core.h - 1.1 linux/drivers/bluetooth/hci_usb.c - 1.1 linux/drivers/bluetooth/hci_emu.c - 1.1 linux/drivers/bluetooth/Makefile - 1.1 linux/drivers/bluetooth/Config.in - 1.1 linux/arch/m68k/sun3x/sun3x_ksyms.c - 1.1 linux/arch/m68k/sun3x/prom.c - 1.1 linux/net/bluetooth/Config.in - 1.1 linux/arch/m68k/sun3/sun3dvma.c - 1.1 linux/net/bluetooth/Makefile - 1.1 linux/net/bluetooth/af_bluetooth.c - 1.1 linux/net/bluetooth/hci_core.c - 1.1 linux/net/bluetooth/hci_sock.c - 1.1 linux/net/bluetooth/l2cap_core.c - 1.1 linux/net/bluetooth/l2cap_proc.c - 1.1 linux/net/bluetooth/lib.c - 1.1 linux/net/bluetooth/syms.c - 1.1 linux/net/socket.c - 1.22 linux/net/sched/sch_cbq.c - 1.9 linux/net/ipv4/tcp_input.c - 1.26 linux/net/ipv4/ip_output.c - 1.21 linux/net/ipv4/fib_frontend.c - 1.10 linux/net/core/neighbour.c - 1.11 linux/net/README - 1.9 linux/net/Makefile - 1.15 linux/mm/vmscan.c - 1.56 linux/mm/swapfile.c - 1.32 linux/mm/swap_state.c - 1.25 linux/mm/memory.c - 1.49 linux/kernel/softirq.c - 1.10 linux/kernel/ksyms.c - 1.93 linux/include/linux/swap.h - 1.27 linux/include/linux/socket.h - 1.9 linux/include/linux/parport_pc.h - 1.8 linux/include/linux/mount.h - 1.15 linux/include/linux/mm.h - 1.55 linux/include/linux/linux_logo.h - 1.3 linux/include/linux/interrupt.h - 1.13 linux/include/linux/fs.h - 1.96 linux/include/linux/dcache.h - 1.18 linux/include/asm-sparc64/termios.h - 1.6 linux/include/asm-sparc64/sab82532.h - 1.4 linux/include/asm-sparc64/linux_logo.h - 1.3 linux/include/asm-sparc64/bitops.h - 1.9 linux/include/asm-sparc64/auxio.h - 1.4 linux/include/asm-sparc64/audioio.h - 1.9 linux/include/asm-sparc/termios.h - 1.6 linux/include/asm-sparc/linux_logo.h - 1.3 linux/include/asm-sparc/audioio.h - 1.10 linux/include/asm-ppc/termios.h - 1.8 linux/include/asm-ppc/softirq.h - 1.10 linux/include/asm-ppc/linux_logo.h - 1.8 linux/include/asm-ppc/bitops.h - 1.10 linux/include/asm-mips/termios.h - 1.8 linux/include/asm-mips/linux_logo.h - 1.5 linux/include/asm-m68k/termios.h - 1.6 linux/include/asm-m68k/system.h - 1.7 linux/include/asm-m68k/sun3x.h - 1.3 linux/include/asm-m68k/string.h - 1.4 linux/include/asm-m68k/serial.h - 1.5 linux/include/asm-m68k/q40_master.h - 1.4 linux/include/asm-m68k/q40_keyboard.h - 1.4 linux/include/asm-m68k/mac_psc.h - 1.4 linux/include/asm-m68k/linux_logo.h - 1.3 linux/include/asm-m68k/io.h - 1.6 linux/include/asm-m68k/ide.h - 1.5 linux/include/asm-m68k/floppy.h - 1.4 linux/include/asm-m68k/dvma.h - 1.6 linux/include/asm-m68k/bitops.h - 1.6 linux/include/asm-m68k/amigayle.h - 1.3 linux/include/asm-m68k/amigahw.h - 1.5 linux/include/asm-i386/termios.h - 1.6 linux/include/asm-i386/softirq.h - 1.7 linux/include/asm-i386/linux_logo.h - 1.3 linux/include/asm-i386/hardirq.h - 1.14 linux/include/asm-arm/termios.h - 1.8 linux/include/asm-arm/linux_logo.h - 1.5 linux/include/asm-alpha/termios.h - 1.6 linux/include/asm-alpha/softirq.h - 1.7 linux/include/asm-alpha/linux_logo.h - 1.3 linux/include/asm-alpha/hardirq.h - 1.12 linux/fs/super.c - 1.47 linux/fs/nfs/dir.c - 1.28 linux/fs/namei.c - 1.30 linux/fs/inode.c - 1.42 linux/fs/fat/inode.c - 1.23 linux/fs/dcache.c - 1.25 linux/fs/block_dev.c - 1.22 linux/drivers/video/fbcon.c - 1.18 linux/drivers/video/atyfb.c - 1.30 linux/drivers/sgi/char/linux_logo.h - 1.3 linux/drivers/scsi/qlogicpti.c - 1.13 linux/drivers/sbus/char/sab82532.c - 1.18 linux/drivers/sbus/char/pcikbd.c - 1.18 linux/drivers/sbus/audio/dmy.c - 1.8 linux/drivers/sbus/audio/dbri.c - 1.12 linux/drivers/sbus/audio/cs4231.c - 1.11 linux/drivers/sbus/audio/audio.c - 1.13 linux/drivers/sbus/audio/amd7930.c - 1.8 linux/drivers/sbus/audio/Makefile - 1.5 linux/drivers/net/eepro100.c - 1.28 linux/drivers/char/console.c - 1.21 linux/drivers/block/loop.c - 1.32 linux/drivers/Makefile - 1.22 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.29 linux/arch/sparc64/kernel/setup.c - 1.19 linux/arch/sparc64/kernel/process.c - 1.20 linux/arch/sparc64/kernel/irq.c - 1.19 linux/arch/sparc64/kernel/ioctl32.c - 1.35 linux/arch/sparc64/defconfig - 1.36 linux/arch/sparc64/config.in - 1.39 linux/arch/sparc/config.in - 1.30 linux/arch/ppc/kernel/time.c - 1.14 linux/arch/ppc/kernel/smp.c - 1.25 linux/arch/ppc/kernel/prom.c - 1.21 linux/arch/ppc/kernel/irq.c - 1.28 linux/arch/ppc/kernel/chrp_setup.c - 1.22 linux/arch/ppc/kernel/Makefile - 1.21 linux/arch/ppc/config.in - 1.36 linux/arch/m68k/sun3x/time.h - 1.3 linux/arch/m68k/sun3x/time.c - 1.4 linux/arch/m68k/sun3x/sbus.c - 1.4 linux/arch/m68k/sun3x/dvma.c - 1.3 linux/arch/m68k/sun3x/config.c - 1.4 linux/arch/m68k/sun3x/Makefile - 1.4 linux/arch/m68k/q40/q40ints.c - 1.5 linux/arch/m68k/q40/config.c - 1.10 linux/arch/m68k/q40/README - 1.6 linux/arch/m68k/mvme16x/rtc.c - 1.8 linux/arch/m68k/mvme16x/config.c - 1.7 linux/arch/m68k/mvme147/config.c - 1.8 linux/arch/m68k/mm/memory.c - 1.10 linux/arch/m68k/mm/init.c - 1.12 linux/arch/m68k/mac/macints.c - 1.7 linux/arch/m68k/mac/debug.c - 1.7 linux/arch/m68k/mac/config.c - 1.8 linux/arch/m68k/kernel/traps.c - 1.10 linux/arch/m68k/kernel/sys_m68k.c - 1.8 linux/arch/m68k/kernel/setup.c - 1.13 linux/arch/m68k/kernel/ptrace.c - 1.7 linux/arch/m68k/kernel/head.S - 1.6 linux/arch/m68k/config.in - 1.23 linux/arch/m68k/bvme6000/rtc.c - 1.8 linux/arch/m68k/bvme6000/config.c - 1.7 linux/arch/m68k/atari/time.c - 1.4 linux/arch/m68k/apollo/config.c - 1.5 linux/arch/m68k/amiga/pcmcia.c - 1.3 linux/arch/m68k/amiga/config.c - 1.9 linux/arch/m68k/amiga/cia.c - 1.5 linux/arch/m68k/amiga/amisound.c - 1.8 linux/arch/m68k/Makefile - 1.7 linux/arch/i386/kernel/io_apic.c - 1.27 linux/arch/i386/kernel/entry.S - 1.33 linux/arch/i386/config.in - 1.57 linux/arch/arm/config.in - 1.25 linux/arch/alpha/kernel/smp.c - 1.23 linux/arch/alpha/kernel/irq.c - 1.17 linux/arch/alpha/kernel/entry.S - 1.19 linux/arch/alpha/config.in - 1.31 linux/Makefile - 1.89 linux/MAINTAINERS - 1.59 linux/Documentation/filesystems/hpfs.txt - 1.4 linux/Documentation/Changes - 1.39 linux/CREDITS - 1.53 linux/COPYING - 1.4 linux/fs/hpfs/super.c - 1.9 linux/fs/hpfs/dir.c - 1.8 linux/fs/hpfs/anode.c - 1.5 linux/drivers/parport/parport_pc.c - 1.34 linux/arch/m68k/math-emu/multi_arith.h - 1.2 linux/arch/sparc64/kernel/pci_sabre.c - 1.20 linux/arch/sparc64/kernel/pci_psycho.c - 1.18 linux/drivers/parport/parport_sunbpp.c - 1.7 linux/include/asm-sh/termios.h - 1.6 linux/fs/udf/udftime.c - 1.5 linux/arch/m68k/sun3/sun3ints.c - 1.4 linux/arch/m68k/sun3/sbus.c - 1.3 linux/arch/m68k/sun3/mmu_emu.c - 1.4 linux/arch/m68k/sun3/dvma.c - 1.3 linux/arch/m68k/sun3/config.c - 1.5 linux/arch/m68k/sun3/Makefile - 1.6 linux/arch/m68k/mac/via.c - 1.4 linux/arch/m68k/mac/psc.c - 1.5 linux/arch/m68k/mac/iop.c - 1.5 linux/include/linux/udf_udf.h - 1.3 linux/Documentation/filesystems/udf.txt - 1.4 linux/fs/udf/fsync.c - 1.5 linux/fs/udf/ialloc.c - 1.9 linux/include/linux/udf_fs_sb.h - 1.5 linux/fs/udf/file.c - 1.23 linux/fs/udf/directory.c - 1.6 linux/fs/udf/dir.c - 1.14 linux/fs/udf/crc.c - 1.2 linux/fs/udf/inode.c - 1.20 linux/include/linux/udf_fs_i.h - 1.4 linux/fs/udf/lowlevel.c - 1.8 linux/fs/udf/balloc.c - 1.8 linux/include/linux/udf_fs.h - 1.10 linux/fs/udf/Makefile - 1.3 linux/include/linux/udf_167.h - 1.5 linux/fs/udf/misc.c - 1.8 linux/fs/udf/namei.c - 1.16 linux/include/asm-m68k/sun3ints.h - 1.3 linux/include/asm-m68k/sbus.h - 1.2 linux/include/asm-m68k/openprom.h - 1.3 linux/fs/udf/partition.c - 1.6 linux/fs/udf/super.c - 1.19 linux/fs/udf/truncate.c - 1.8 linux/fs/udf/symlink.c - 1.12 linux/fs/udf/unicode.c - 1.5 linux/include/asm-m68k/intersil.h - 1.3 linux/fs/udf/udf_i.h - 1.4 linux/fs/udf/udfend.h - 1.5 linux/fs/udf/udf_sb.h - 1.6 linux/fs/udf/udfdecl.h - 1.13 linux/arch/m68k/sun3/sun3_ksyms.c - 1.2 linux/arch/m68k/sun3/intersil.c - 1.2 linux/include/asm-m68k/pgalloc.h - 1.5 linux/fs/autofs4/expire.c - 1.9 linux/include/asm-ia64/linux_logo.h - 1.2 linux/include/asm-ia64/termios.h - 1.3 linux/arch/m68k/mac/misc.c - 1.5 linux/net/bridge/br_forward.c - 1.3 linux/net/bridge/br_device.c - 1.4 linux/net/bridge/br_private.h - 1.6 linux/net/bridge/br_input.c - 1.7 linux/include/asm-mips64/termios.h - 1.4 linux/include/asm-mips64/linux_logo.h - 1.3 linux/lib/brlock.c - 1.3 linux/drivers/parport/ChangeLog - 1.15 linux/drivers/ide/ide-tape.c - 1.10 linux/net/ipv4/netfilter/ipt_REJECT.c - 1.10 linux/net/ipv4/netfilter/ipfwadm_core.c - 1.5 linux/include/linux/netfilter_ipv4/ip_tables.h - 1.5 linux/drivers/usb/serial/ftdi_sio.c - 1.16 linux/include/asm-s390/termios.h - 1.3 linux/drivers/char/drm/ffb_drv.c - 1.7 linux/include/asm-sh/linux_logo.h - 1.2 linux/drivers/net/tun.c - 1.7 linux/include/linux/irq_cpustat.h - 1.3 linux/include/linux/if_tun.h - 1.2 linux/net/irda/irnet/irnet_ppp.h - 1.3 linux/net/irda/irnet/irnet_ppp.c - 1.4 linux/net/irda/irnet/irnet_irda.h - 1.3 linux/net/irda/irnet/irnet_irda.c - 1.4 linux/net/irda/irnet/irnet.h - 1.4 linux/include/asm-parisc/linux_logo.h - 1.2 linux/include/asm-m68k/motorola_pgalloc.h - 1.3 linux/include/asm-m68k/sun3_pgalloc.h - 1.3 linux/include/asm-m68k/sun3_pgtable.h - 1.2 linux/include/asm-m68k/parport.h - 1.2 linux/include/asm-parisc/termios.h - 1.3 linux/drivers/scsi/osst_options.h - 1.2 linux/drivers/scsi/osst.h - 1.2 linux/drivers/scsi/osst.c - 1.3 linux/arch/sparc64/kernel/pci_schizo.c - 1.6 linux/include/asm-s390x/termios.h - 1.3 linux/drivers/net/wireless/hermes.c - 1.2 linux/drivers/net/wireless/hermes.h - 1.2 linux/drivers/net/wireless/orinoco.c - 1.2 linux/drivers/net/wireless/orinoco.h - 1.2 linux/drivers/net/wireless/orinoco_cs.c - 1.2 linux/arch/ppc/boot/prep/misc.c - 1.2 linux/arch/ppc/boot/pmac/Makefile - 1.2 linux/arch/ppc/boot/mbx/Makefile - 1.2 linux/arch/ppc/boot/common/misc-common.c - 1.2 From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 20:21:18 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f593LIAJ015967 for linux-xfs-outgoing; Fri, 8 Jun 2001 20:21:18 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f593LG3D015964 for ; Fri, 8 Jun 2001 20:21:16 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA25690 for ; Fri, 8 Jun 2001 20:21:13 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id WAA2105926; Fri, 8 Jun 2001 22:19:58 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA63066; Fri, 8 Jun 2001 22:19:58 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f593Mak27454; Fri, 8 Jun 2001 22:22:37 -0500 Message-Id: <200106090322.f593Mak27454@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Deti Fliegl cc: Linux XFS Mailing List Subject: Re: XFS lockup with samba-2.2 In-Reply-To: Message from Deti Fliegl of "Sat, 09 Jun 2001 03:34:17 +0200." <3B217D19.986150C4@fliegl.de> Date: Fri, 08 Jun 2001 22:22:36 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, If possible can you do the following: o build the kernel with kdb support turned on o use kgcc to build it, I have seen bad stacks with some other compilers. o turn back on oplocks and recreate the hang o work out which processes are hung o on the console use break (or Ctrl-A on a serial console) to get into kdb. o type bt on the processes in D state and send us the output. A serial console makes this so much easier, but you may not have the facilities.. If you do then the output of the bta command would be even better. You can continue the system with go, or reset it with reboot at this point. This problem may just be an oplock bug, but it may be an interaction with xfs. Steve > Hi, > > today something strange happened on a system running 2.4.6-pre1 from the > latest CVS tree together with kernel NFS V3 support and samba-2.2 with > windows 2000 clients. After I tried to move a directory under windows > 2000 from one location to another within the same XFS partition the > windows 2000 client locked up. First I thought there might be a windows > problem - but it turned out that the corresponding smbd process on the > linux box got into the D state and this happened to all other processes > accessing the target directory (of the move). > After a while I had a couple of processes (like ls, bash, find ...) all > in the D state from the moment on when they tried to stat this > particular directory. There were no system messages describing a > possible reason for the lockup. After a reboot everything was fine > again. > In the meantime I configured samba not to use kernel OP locks and the > problem did not occur again. This could be a clue but I was not able to > do further testing since the system is used for production. > > Kind regards > > Deti From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 20:22:31 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f593MVmg016083 for linux-xfs-outgoing; Fri, 8 Jun 2001 20:22:31 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f593MS3D016071 for ; Fri, 8 Jun 2001 20:22:29 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f593MNA11043; Fri, 8 Jun 2001 23:22:23 -0400 Date: Fri, 8 Jun 2001 23:22:23 -0400 From: Alan Eldridge To: linux-xfs@oss.sgi.com Cc: kaos@melbourne.sgi.com Subject: Proper bug report on RH-2.4.5 config failure :) Message-ID: <20010608232223.A6660@wwweasel.geeksrus.net> References: <20010608213420.A15810@wwweasel.geeksrus.net> <8025.992053019@ocs4.ocs-net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <8025.992053019@ocs4.ocs-net>; from kaos@melbourne.sgi.com on Sat, Jun 09, 2001 at 12:16:59PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Jun 09, 2001 at 12:16:59PM +1000, Keith Owens wrote: >On Fri, 8 Jun 2001 21:34:20 -0400, >Alan Eldridge wrote: >>+++ linux/fs/Config.in Fri Jun 8 21:09:35 2001 >>+[ $CONFIG_PAGE_BUF ] || CONFIG_PAGE_BUF=y > >Arrgh, please do not use shell code in config.in files. The config >language is *NOT* shell, the above will work for some parsers but not >all of them. Saw that soon after. I forgot that shell is but one implementation. :) I'll rerun the faulty ocnfig.... The symptom is that the vars aren't set the first time through the configure, so it fails with "no default".... "default" in this case means, the shell var wasn't set, and so the var name went into the "nodefaults" file. Sorry 'bout the inappropriate solution ... I kinda forgot that, unlike some other mailing lists, here I'm dealing with people who know what they're doing, and know more about it than I do.... :) OK ... Here's the patch as Russell supplied it: ---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<--- --- /build/RH_raw/linux/fs/Config.in Wed Jun 6 12:38:09 2001 +++ linux/fs/Config.in Thu Jun 7 23:48:41 2001 @@ -5,6 +5,7 @@ comment 'File systems' bool 'Quota support' CONFIG_QUOTA +bool 'POSIX Access Control List support' CONFIG_FS_POSIX_ACL tristate 'Kernel automounter support' CONFIG_AUTOFS_FS tristate 'Kernel automounter version 4 support (also supports v3)' CONFIG_AUTOFS4_FS @@ -84,6 +85,19 @@ 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 'Page Buffer support' CONFIG_PAGE_BUF + +if [ "$CONFIG_PAGE_BUF" = "n" ]; then + comment ' Page Buffer support needed for XFS filesystem' +else + dep_tristate 'SGI XFS filesystem support' CONFIG_XFS_FS $CONFIG_PAGE_BUF + if [ "$CONFIG_XFS_FS" != "n" ]; then + define_bool CONFIG_HAVE_ATTRCTL y + dep_mbool ' Enable XFS DMAPI' CONFIG_XFS_DMAPI $CONFIG_XFS_FS + dep_mbool ' Enable XFS Quota' CONFIG_XFS_QUOTA $CONFIG_XFS_FS $CONFIG_QUOTA + fi +fi if [ "$CONFIG_NET" = "y" ]; then ---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<--- Here's the relevant bits of the resulting fs/Config.in: ---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<--- # # File system configuration # mainmenu_option next_comment comment 'File systems' bool 'Quota support' CONFIG_QUOTA bool 'POSIX Access Control List support' CONFIG_FS_POSIX_ACL tristate 'Kernel automounter support' CONFIG_AUTOFS_FS [ ... ] 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 'Page Buffer support' CONFIG_PAGE_BUF if [ "$CONFIG_PAGE_BUF" = "n" ]; then comment ' Page Buffer support needed for XFS filesystem' else dep_tristate 'SGI XFS filesystem support' CONFIG_XFS_FS $CONFIG_PAGE_BUF if [ "$CONFIG_XFS_FS" != "n" ]; then define_bool CONFIG_HAVE_ATTRCTL y dep_mbool ' Enable XFS DMAPI' CONFIG_XFS_DMAPI $CONFIG_XFS_FS dep_mbool ' Enable XFS Quota' CONFIG_XFS_QUOTA $CONFIG_XFS_FS $CONFIG_QUOTA fi fi if [ "$CONFIG_NET" = "y" ]; then mainmenu_option next_comment comment 'Network File Systems' [ ... ] ---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<--- And here's the "rpm -bc kernel-2.4-xfs.spec" run, trimmed to the running of the "make oldconfig_nonint" step: Script started on Fri Jun 8 23:08:32 2001 [ ... ] UFS file system support (read only) (CONFIG_UFS_FS) [M/n/y/?] UFS file system write support (DANGEROUS) (CONFIG_UFS_FS_WRITE) [N/y/?] Page Buffer support (CONFIG_PAGE_BUF) [N/y/m/?] (NEW) * * Page Buffer support needed for XFS filesystem * [ note page buffer, XFS are turned off ] * * Network File Systems * [ ... ] * Kernel hacking * Magic SysRq key (CONFIG_MAGIC_SYSRQ) [Y/n/?] Kernel debugging (CONFIG_DEBUG_KERNEL) [N/y/?] *** End of Linux kernel configuration. *** Check the top-level Makefile for additional configuration. *** Next, you must run 'make dep'. The following defaults are missing: POSIX Access Control List support (CONFIG_FS_POSIX_ACL) [N/y/?] Page Buffer support (CONFIG_PAGE_BUF) [N/y/m/?] make: *** [oldconfig_nonint] Error 1 error: Bad exit status from /home/alane/rpm/tmp/rpm-tmp.94446 (%build) RPM build errors: Bad exit status from /home/alane/rpm/tmp/rpm-tmp.94446 (%build) [alane@wwweasel SPECS]$ exit Script done on Fri Jun 8 23:11:07 2001 -- Alan Eldridge From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 20:26:05 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f593Q5GK016482 for linux-xfs-outgoing; Fri, 8 Jun 2001 20:26:05 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f593Q43D016479 for ; Fri, 8 Jun 2001 20:26:04 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA25998 for ; Fri, 8 Jun 2001 20:26:02 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id WAA2109201 for ; Fri, 8 Jun 2001 22:24:48 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA75086 for ; Fri, 8 Jun 2001 22:24:48 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f593RQR28338; Fri, 8 Jun 2001 22:27:26 -0500 Message-Id: <200106090327.f593RQR28338@jen.americas.sgi.com> Date: Fri, 8 Jun 2001 22:27:26 -0500 Subject: TAKE - start of work to access realtime device Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Been running with this for days without problem, no actual realtime testing yet, but this at least gives us the technology to get there. Date: Fri Jun 8 20:23:46 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-base The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:96615a linux/fs/xfs/linux/xfs_lrw.c - 1.101 - Fill in pb_dev to indicate target device for I/O linux/include/linux/page_buf.h - 1.92 - Add pbm_dev to the pbm_bmap structure linux/fs/pagebuf/page_buf_io.c - 1.80 - Use kdev_t from pbbmap structure rather than from inode for device mapping. From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 20:38:45 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f593cjBv017569 for linux-xfs-outgoing; Fri, 8 Jun 2001 20:38:45 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f593cg3D017560 for ; Fri, 8 Jun 2001 20:38:43 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f593cb011207 for linux-xfs@oss.sgi.com; Fri, 8 Jun 2001 23:38:37 -0400 Date: Fri, 8 Jun 2001 23:38:37 -0400 From: Alan Eldridge To: linux-xfs@oss.sgi.com Subject: Running kernel w/o RH patches ... Message-ID: <20010608233837.A11062@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Knowing how heavily patched the RH kernels are (!!), does anyone know if there'd be impairment or malfunction running a stock + xfs kernel on a RH system? I guess there's really 2 separate issues: there's the big "ac-4" patch, which doesn't play nice with XFS, and then there's all the rest of the myriad bits and pieces RH has piled on. Anyone got any good data/opinions/wild-assed-guesss about this? I'm just trying to see all the options, and reducing complexity of the problem space is one I'd like to have. [Back in the days when I regularly had to rebuild the kernel (and libc-3/4, and gcc, and ....), patches only came from Linus, and 100M was enough *disk* for a system. :) So that's how out-of-date with it I am.] -- Alan Eldridge "Ah, yes, his head's been ripped off. I'll get you another." From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 21:02:18 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f5942Iqr019690 for linux-xfs-outgoing; Fri, 8 Jun 2001 21:02:18 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f5942G3D019680 for ; Fri, 8 Jun 2001 21:02:16 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id GAA1896839 for ; Sat, 9 Jun 2001 06:02:14 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id XAA2109125 for ; Fri, 8 Jun 2001 23:00:57 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id XAA94287 for ; Fri, 8 Jun 2001 23:00:50 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f5943Te31573; Fri, 8 Jun 2001 23:03:29 -0500 Message-Id: <200106090403.f5943Te31573@jen.americas.sgi.com> Date: Fri, 8 Jun 2001 23:03:29 -0500 Subject: TAKE - delalloc buffer and page handling cleanup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Removes some code, and actually makes it faster. Problem reports, especially from highmem systems (which I know how to crash in 30 seconds) appreciated - Hint, avoid direct I/O, buffered I/O on the same file, do not run test 013 in the regression tests. I am still chasing this bug. Date: Fri Jun 8 20:58:42 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:96616a linux/mm/vmscan.c - 1.57 - rework the launder code for delalloc pages, we issue a write on them and let the next pass try to clean them up. linux/include/linux/fs.h - 1.97 - remobe writepage_nounlock linux/fs/buffer.c - 1.64 - Add a wait option to write_page, always grab the page when it is set, used from write paths which always want to succeed. Remove code from try_to_free_buffers and block_flushpage, the only places which call these have already dealt with delalloc pages. Finally, use regular writepage, the nounlock version is gone. linux/fs/xfs/linux/xfs_iops.c - 1.107 - we now only have a writepage method, the nounlock case is gone linux/fs/pagebuf/page_buf_io.c - 1.81 - Use code more similar to block_write_page in the write path, leave the page locked for the duration of I/O. From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 21:27:28 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f594RSAS021403 for linux-xfs-outgoing; Fri, 8 Jun 2001 21:27:28 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f594RN3D021397 for ; Fri, 8 Jun 2001 21:27:25 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f594SJH08592; Sat, 9 Jun 2001 14:28:19 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Alan Eldridge cc: linux-xfs@oss.sgi.com Subject: Re: Proper bug report on RH-2.4.5 config failure :) In-reply-to: Your message of "Fri, 08 Jun 2001 23:22:23 -0400." <20010608232223.A6660@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Jun 2001 14:28:19 +1000 Message-ID: <8591.992060899@ocs4.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 8 Jun 2001 23:22:23 -0400, Alan Eldridge wrote: >And here's the "rpm -bc kernel-2.4-xfs.spec" run, trimmed to the running of >the "make oldconfig_nonint" step: > >Script started on Fri Jun 8 23:08:32 2001 >[ ... ] >UFS file system support (read only) (CONFIG_UFS_FS) [M/n/y/?] > UFS file system write support (DANGEROUS) (CONFIG_UFS_FS_WRITE) [N/y/?] >Page Buffer support (CONFIG_PAGE_BUF) [N/y/m/?] (NEW) * >* Page Buffer support needed for XFS filesystem >* >[ note page buffer, XFS are turned off ] >The following defaults are missing: >POSIX Access Control List support (CONFIG_FS_POSIX_ACL) [N/y/?] >Page Buffer support (CONFIG_PAGE_BUF) [N/y/m/?] >make: *** [oldconfig_nonint] Error 1 >error: Bad exit status from /home/alane/rpm/tmp/rpm-tmp.94446 (%build) The problem is the default config has no entries for the new fields. Find out which defconfig is used by make oldconfig_nonint, it is probably arch/i386/defconfig but I don't know for sure, I always build my own kernels. Edit that defconfig to add CONFIG_PAGE_BUF=y CONFIG_XFS_FS=y CONFIG_XFS_DMAPI=y CONFIG_XFS_QUOTA=y Change y to m if you want modules, you can set dmap and quota to n if you do not want those options. Because you are using rpm, you need to do this in steps. * rpm -bp to unpack the code. * Save the current defconfig as .orig and edit defconfig. * rpm -bc --short-circuit to check it gets past make oldconfig_nonint, abort at that point, no need to do a full compile. * cd redhat/BUILD, diff -u the old and new defconfig, save the patch in redhat/SOURCES as kernel-2.4-xfs-defconfig-test.patch. * Edit redhat/SPECS/kernel-2.4-xfs.spec, add a Patch line to the start for kernel-2.4-xfs-defconfig-test.patch, add %patch -p1 to the prep section, where is the next free patch number. * rpm -bc redhat/SPECS/kernel-2.4-xfs.spec to start from scratch. This should apply the correct default config and get past oldconfig_nonint. Send me the patch once it works so I can update our tree for the next rpm. From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 21:34:50 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f594Yo5m021982 for linux-xfs-outgoing; Fri, 8 Jun 2001 21:34:50 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f594Yk3D021976 for ; Fri, 8 Jun 2001 21:34:48 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f594ZiK08649; Sat, 9 Jun 2001 14:35:44 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Alan Eldridge cc: linux-xfs@oss.sgi.com Subject: Re: Running kernel w/o RH patches ... In-reply-to: Your message of "Fri, 08 Jun 2001 23:38:37 -0400." <20010608233837.A11062@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Jun 2001 14:35:44 +1000 Message-ID: <8648.992061344@ocs4.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 8 Jun 2001 23:38:37 -0400, Alan Eldridge wrote: >Knowing how heavily patched the RH kernels are (!!), does anyone know if >there'd be impairment or malfunction running a stock + xfs kernel on a RH >system? I know that Russell Cattelan did an XFS+kdb patch for Redhat 7.1. I also know it took a *looong* time, fitting just the kdb patch into all the RH bits and pieces from the -ac tree took me about 8 hours, and I had all the tools to do the job. Russell, did that XFS for RH 7.1 patch get released? From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 21:44:44 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f594iijb022929 for linux-xfs-outgoing; Fri, 8 Jun 2001 21:44:44 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f594if3D022916 for ; Fri, 8 Jun 2001 21:44:42 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f594iWP12498; Sat, 9 Jun 2001 00:44:32 -0400 Date: Sat, 9 Jun 2001 00:44:32 -0400 From: Alan Eldridge To: Keith Owens Cc: linux-xfs@oss.sgi.com Subject: Russell's patch against RH 7.1 ... Message-ID: <20010609004432.A12217@wwweasel.geeksrus.net> References: <20010608233837.A11062@wwweasel.geeksrus.net> <8648.992061344@ocs4.ocs-net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <8648.992061344@ocs4.ocs-net>; from kaos@melbourne.sgi.com on Sat, Jun 09, 2001 at 02:35:44PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Jun 09, 2001 at 02:35:44PM +1000, Keith Owens wrote: >On Fri, 8 Jun 2001 23:38:37 -0400, >Alan Eldridge wrote: >>Knowing how heavily patched the RH kernels are (!!), does anyone know if >>there'd be impairment or malfunction running a stock + xfs kernel on a RH >>system? > >I know that Russell Cattelan did an XFS+kdb patch for Redhat 7.1. I >also know it took a *looong* time, fitting just the kdb patch into all >the RH bits and pieces from the -ac tree took me about 8 hours, and I >had all the tools to do the job. > >Russell, did that XFS for RH 7.1 patch get released? The patch I'm using is one he did last night. It's for RH Rawhide 2.4.5-0.2.9 kernel. It's on ftp.thebarn.com in /SGI/testing. -- Alan Eldridge "I've told you once." "No you haven't." From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 21:52:44 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f594qipS023534 for linux-xfs-outgoing; Fri, 8 Jun 2001 21:52:44 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gargoyle (IDENT:root@gargoyle.gargoylecc.com [65.100.85.35]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f594qf3D023530 for ; Fri, 8 Jun 2001 21:52:42 -0700 Received: from gargoyle ([127.0.0.1] helo=localhost ident=ringram) by gargoyle with esmtp (Exim 3.13 #1 (Debian)) id 158alv-00068O-00; Fri, 08 Jun 2001 22:54:51 -0600 Date: Fri, 8 Jun 2001 22:54:51 -0600 (MDT) From: Russel Ingram X-X-Sender: To: Ivan Rayner cc: Subject: Re: xfsdump, paride tape, and -m option In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 9 Jun 2001, Ivan Rayner wrote: > On Sat, 9 Jun 2001, Russel Ingram wrote: > > > I'm using xfsdump from cvs (I think it is from 5/30/01 but might be > > 6/5/01) to attempt to backup an xfs filesystem to an HP Colorado 8GBe > > parallel tape drive. Every time I try to use the -m option (the > > parallel tape driver is a very minimal tape device driver and suggests > > specifying 16k as the block size) xfsdump core dumps with the following > > error: > > > > drive_minrmt.c:1820: do_get_write_buf: Assertion 'contextp->dc_nextp < > > contextp->dc_recendp' failed. > > > > Is this a bug or just an incompatiblity with the minimalness of the pt > > driver? > > If you can mail the complete xfsdump command line, I'll see if I can > reproduce the problem here. > okie dokie, here's what I was giving it: xfsdump -m -b 16 -o -l0 -E -F -M"gumby" -L"home" -s home -f /dev/pt/0 / Like I said its a parallel tape drive that I haven't got anything else to work with either (tar works but not to the expected capacity) so it may just be a problem in the device driver but since it core dumps without even trying to dump I thought someone might be interested in if it turned out to be a bug with xfsdump. Thanx, Russ -- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 22:11:06 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f595B6hu024204 for linux-xfs-outgoing; Fri, 8 Jun 2001 22:11:06 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f595B33D024197 for ; Fri, 8 Jun 2001 22:11:04 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id HAA1498124 for ; Sat, 9 Jun 2001 07:11:00 +0200 (CEST) mail_from (ivanr@melbourne.sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA08612; Sat, 9 Jun 2001 15:09:39 +1000 From: ivanr@melbourne.sgi.com (Ivan Rayner) Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id PAA89896; Sat, 9 Jun 2001 15:09:38 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Sat, 9 Jun 2001 15:09:37 +1000 To: Russel Ingram cc: Subject: Re: xfsdump, paride tape, and -m option In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 8 Jun 2001, Russel Ingram wrote: > On Sat, 9 Jun 2001, Ivan Rayner wrote: > > > On Sat, 9 Jun 2001, Russel Ingram wrote: > > > > > I'm using xfsdump from cvs (I think it is from 5/30/01 but might be > > > 6/5/01) to attempt to backup an xfs filesystem to an HP Colorado 8GBe > > > parallel tape drive. Every time I try to use the -m option (the > > > parallel tape driver is a very minimal tape device driver and suggests > > > specifying 16k as the block size) xfsdump core dumps with the following > > > error: > > > > > > drive_minrmt.c:1820: do_get_write_buf: Assertion 'contextp->dc_nextp < > > > contextp->dc_recendp' failed. > > > > > > Is this a bug or just an incompatiblity with the minimalness of the pt > > > driver? > > > > If you can mail the complete xfsdump command line, I'll see if I can > > reproduce the problem here. > > > okie dokie, here's what I was giving it: > > xfsdump -m -b 16 -o -l0 -E -F -M"gumby" -L"home" -s home -f /dev/pt/0 / > > Like I said its a parallel tape drive that I haven't got anything else to > work with either (tar works but not to the expected capacity) so it may > just be a problem in the device driver but since it core dumps without > even trying to dump I thought someone might be interested in if it turned > out to be a bug with xfsdump. The argument to -b should be bytes, so 16k would be 16384 not 16. If this doesn't fix your problem, could you use -v5 to get verbose output. (This might produce alot of output, so you should redirect it to a file.) Ivan -- Ivan Rayner ivanr@melbourne.sgi.com From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 22:17:52 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f595HqV8024579 for linux-xfs-outgoing; Fri, 8 Jun 2001 22:17:52 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from scribe.pobox.com (scribe.pobox.com [208.210.124.35]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f595Ho3D024575 for ; Fri, 8 Jun 2001 22:17:51 -0700 Received: from aluminum (arg09-du137.argolink.net [216.88.88.137]) by scribe.pobox.com (Postfix) with SMTP id 51A7F32592; Sat, 9 Jun 2001 01:17:19 -0400 (EDT) Message-ID: <011701c0f0a3$8482bd30$0300a8c0@aluminum> From: "delay" To: "Alan Eldridge" , References: <20010608233837.A11062@wwweasel.geeksrus.net> Subject: Re: Running kernel w/o RH patches ... Date: Sat, 9 Jun 2001 00:17:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Knowing how heavily patched the RH kernels are (!!), does anyone >know if > there'd be impairment or malfunction running a stock + xfs kernel on >a RH > system? I just compiled a 2.4.3 stock kernel from kernel.org and added the xfs patches in redhat 7.1. I did this after first using the xfs redhat installer. Then I wanted to custom compile the kernel so I got a newer 2.4.3 generic one since it had a newer aic7xxx driver. I am very new to linux I didn't know this would even cause a potential problem. So far I haven't noticed any problems... Will this lead to potential problems? I am going to be using this server as a production webserver. I definitely don't want any problems once it is in place 2000 miles away... From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 22:19:34 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f595JYJL024663 for linux-xfs-outgoing; Fri, 8 Jun 2001 22:19:34 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from roujin.gargoylecc.com (roujin.gargoylecc.com [65.100.85.34]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f595JW3D024653 for ; Fri, 8 Jun 2001 22:19:32 -0700 Received: from roujin.gargoylecc.com ([65.100.85.34] ident=ringram) by roujin.gargoylecc.com with esmtp (Exim 3.13 #1) id 158osH-00025O-00; Sat, 09 Jun 2001 13:58:21 -0600 Date: Sat, 9 Jun 2001 13:58:20 -0600 (MDT) From: Russel Ingram To: Ivan Rayner cc: Subject: Re: xfsdump, paride tape, and -m option In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 9 Jun 2001, Ivan Rayner wrote: > On Fri, 8 Jun 2001, Russel Ingram wrote: > > > On Sat, 9 Jun 2001, Ivan Rayner wrote: > > > > > On Sat, 9 Jun 2001, Russel Ingram wrote: > > > > > > > I'm using xfsdump from cvs (I think it is from 5/30/01 but might be > > > > 6/5/01) to attempt to backup an xfs filesystem to an HP Colorado 8GBe > > > > parallel tape drive. Every time I try to use the -m option (the > > > > parallel tape driver is a very minimal tape device driver and suggests > > > > specifying 16k as the block size) xfsdump core dumps with the following > > > > error: > > > > > > > > drive_minrmt.c:1820: do_get_write_buf: Assertion 'contextp->dc_nextp < > > > > contextp->dc_recendp' failed. > > > > > > > > Is this a bug or just an incompatiblity with the minimalness of the pt > > > > driver? > > > > > > If you can mail the complete xfsdump command line, I'll see if I can > > > reproduce the problem here. > > > > > okie dokie, here's what I was giving it: > > > > xfsdump -m -b 16 -o -l0 -E -F -M"gumby" -L"home" -s home -f /dev/pt/0 / > > > > Like I said its a parallel tape drive that I haven't got anything else to > > work with either (tar works but not to the expected capacity) so it may > > just be a problem in the device driver but since it core dumps without > > even trying to dump I thought someone might be interested in if it turned > > out to be a bug with xfsdump. > > The argument to -b should be bytes, so 16k would be 16384 not 16. > > If this doesn't fix your problem, could you use -v5 to get verbose output. > (This might produce alot of output, so you should redirect it to a file.) > > Ivan It wasn't clear (to me anyway) what the syntax on the -b option was supposed to be to get 16k blocksize, so thanks. I'll give it a try sometime tomorrow and get back to ya. -- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com From owner-linux-xfs@linux-xfs.sgi.com Fri Jun 8 22:25:45 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f595PjK3024924 for linux-xfs-outgoing; Fri, 8 Jun 2001 22:25:45 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f595Pi3D024921 for ; Fri, 8 Jun 2001 22:25:44 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id WAA05527 for ; Fri, 8 Jun 2001 22:25:42 -0700 (PDT) mail_from (ivanr@melbourne.sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA08655; Sat, 9 Jun 2001 15:24:25 +1000 From: ivanr@melbourne.sgi.com (Ivan Rayner) Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id PAA92555; Sat, 9 Jun 2001 15:24:25 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Sat, 9 Jun 2001 15:24:24 +1000 To: Russel Ingram cc: Subject: Re: xfsdump, paride tape, and -m option In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 9 Jun 2001, Russel Ingram wrote: > On Sat, 9 Jun 2001, Ivan Rayner wrote: > > The argument to -b should be bytes, so 16k would be 16384 not 16. > > > > If this doesn't fix your problem, could you use -v5 to get verbose output. > > (This might produce alot of output, so you should redirect it to a file.) > > > > Ivan > It wasn't clear (to me anyway) what the syntax on the -b option was > supposed to be to get 16k blocksize, so thanks. Agreed. I'll update the man page next week. Ivan -- Ivan Rayner ivanr@melbourne.sgi.com From owner-linux-xfs@linux-xfs.sgi.com Sat Jun 9 00:46:03 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f597k3Fb002036 for linux-xfs-outgoing; Sat, 9 Jun 2001 00:46:03 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from due.stud.ntnu.no (due.stud.ntnu.no [129.241.56.71]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f597ju3D002028 for ; Sat, 9 Jun 2001 00:45:59 -0700 Received: from localhost (localhost [127.0.0.1]) by due.stud.ntnu.no (Postfix) with ESMTP id 5744F17AB4 for ; Sat, 9 Jun 2001 09:45:54 +0200 (CEST) Received: from jeeves.stud.ntnu.no (jeeves [129.241.56.14]) by due.stud.ntnu.no (Postfix) with ESMTP id AD5CD17A91 for ; Sat, 9 Jun 2001 09:45:53 +0200 (CEST) Received: from localhost (sebastid@localhost) by jeeves.stud.ntnu.no (8.10.0.Beta12/8.10.0.Beta12) with ESMTP id f597jrt05246 for ; Sat, 9 Jun 2001 09:45:53 +0200 (MET DST) X-Authentication-Warning: jeeves.stud.ntnu.no: sebastid owned process doing -bs Date: Sat, 9 Jun 2001 09:45:53 +0200 (MET DST) From: Sebastian Dransfeld To: Subject: chacl Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-10 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --- chacl.c.old Sat Jun 9 09:45:14 2001 +++ chacl.c Sat Jun 9 09:44:04 2001 @@ -175,7 +175,7 @@ /* directory default acl */ if (bflag || dflag) { dacl = acl_from_text (argv[optind]); - if (dacl == NULL || acl_valid(acl) == -1) + if (dacl == NULL || acl_valid(dacl) == -1) { fprintf (stderr, inv_acl, program, argv[optind]); return (1); From owner-linux-xfs@linux-xfs.sgi.com Sat Jun 9 00:59:28 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f597xSc7003576 for linux-xfs-outgoing; Sat, 9 Jun 2001 00:59:28 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from due.stud.ntnu.no (due.stud.ntnu.no [129.241.56.71]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f597xP3D003567 for ; Sat, 9 Jun 2001 00:59:26 -0700 Received: from localhost (localhost [127.0.0.1]) by due.stud.ntnu.no (Postfix) with ESMTP id 5461D17AB4 for ; Sat, 9 Jun 2001 09:59:24 +0200 (CEST) Received: from jeeves.stud.ntnu.no (jeeves [129.241.56.14]) by due.stud.ntnu.no (Postfix) with ESMTP id A872F17A91 for ; Sat, 9 Jun 2001 09:59:23 +0200 (CEST) Received: from localhost (sebastid@localhost) by jeeves.stud.ntnu.no (8.10.0.Beta12/8.10.0.Beta12) with ESMTP id f597xN506664 for ; Sat, 9 Jun 2001 09:59:23 +0200 (MET DST) X-Authentication-Warning: jeeves.stud.ntnu.no: sebastid owned process doing -bs Date: Sat, 9 Jun 2001 09:59:23 +0200 (MET DST) From: Sebastian Dransfeld To: Subject: acls Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-10 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have this directory acl: u::rwx,g::r-x,o::r-x,u:sebastid:rwx,m::r-x A file created gets this acl: u::rw-,g::r-x,o::r--,u:sebastid:rwx,m::r-- Why does the 'x' only get stripped from default user, other and mask? seb From owner-linux-xfs@linux-xfs.sgi.com Sat Jun 9 01:14:00 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f598E0X7005065 for linux-xfs-outgoing; Sat, 9 Jun 2001 01:14:00 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f598Du3D005062 for ; Sat, 9 Jun 2001 01:13:56 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip23.idcomm.com [209.60.72.150]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f598N1U04780 for ; Sat, 9 Jun 2001 02:23:01 -0600 Message-ID: <3B21DAF0.168A0A13@idcomm.com> Date: Sat, 09 Jun 2001 02:14:40 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: xfstest fail Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm using the 2.4.6-pre1-xfs kernel. Currently it is mounted on a temporary IDE drive that has /boot/ as ext2, "/" as xfs. Tests are run against an aic7xxx controller to scsi hard drive. No tape backup devices are available. First is probably not an error, but I am wondering about the meaning of this output from the 001 test: 001 13s ... Failure occurred on a reiserfs test, but I do not use reiserfs. I think it was testing against overwrites or something related, number 032: pts/3:...src/linux/cmd/xfstests# ./check 026 027 028 029 030 031 032 033 034 make: Nothing to be done for `default'. 026 027 028 029 030 031 032 - output mismatch (see 032.out.bad) 2a3 > Failed - overwrote fs type reiserfs! 033 034 Failures: 032 Failed 1 of 9 tests The 032.out.bad: QA output created by 032 Silence is golden. Failed - overwrote fs type reiserfs! The 032.full: === Creating ext2 filesystem... ( mkfs -t ext2 /dev/sda7 ) mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 117504 inodes, 234942 blocks 11747 blocks (5.00%) reserved for the super user First data block=0 8 block groups 32768 blocks per group, 32768 fragments per group 14688 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Writing inode tables: 0/8^H^H^H1/8^H^H^H2/8^H^H^H3/8^H^H^H4/8^H^H^H5/8^H^H^H6/8^H^H^H7/8^H^H^Hdone Writing superblocks and filesystem accounting information: done === Attempting XFS overwrite of ext2... mkfs.xfs: /dev/sda7 appears to contain an existing filesystem (ext2). mkfs.xfs: Use the -f option to force overwrite === Creating minix filesystem... ( mkfs -t minix /dev/sda7 ) 672 inodes 2000 blocks Firstdatazone=25 (25) Zonesize=1024 Maxsize=268966912 === Attempting XFS overwrite of minix... mkfs.xfs: /dev/sda7 appears to contain an existing filesystem (minix). mkfs.xfs: Use the -f option to force overwrite === Creating msdos filesystem... ( mkfs -t msdos /dev/sda7 ) mkfs.msdos 2.2 (06 Jul 1999) === Attempting XFS overwrite of msdos... mkfs.xfs: /dev/sda7 appears to contain an existing filesystem (vfat). mkfs.xfs: Use the -f option to force overwrite === Creating reiserfs filesystem... ( mkfs -t reiserfs /dev/sda7 ) <-------------mkreiserfs, 2000-------------> reiserfsprogs 3.x.0f Creating reiserfs of 3.6 format Block size 4096 bytes Block count 234942 Used blocks 8219 Free blocks count 226723 First 16 blocks skipped Super block is in 16 Bitmap blocks (8) are : 17, 32768, 65536, 98304, 131072, 163840, 196608, 229376 Journal size 8192 (blocks 18-8210 of file /dev/sda7) Root block 8211 Hash function "r5" ATTENTION: YOU SHOULD REBOOT AFTER FDISK! Next, a question on test 041, will it actually alter partition size or placement on the test partitions' drive? I have the partition sizes that I want now, and don't mind wiping partition contents, but do not want to resize or move partition boundaries. Test 040 says it can't run srcdiff without WORKAREA set, which I don't seem to have a reference to in the README. What should it be set to? Further failure for loop mount, a few others simply did not have tools installed, or else not implemented. Tests 045 through 054: Thanteros pts/3:...src/linux/cmd/xfstests# ./check 045 046 047 048 049 050 051 052 053 054 make: Nothing to be done for `default'. 045 046 047 048 049 [failed, exit status 1] - output mismatch (see 049.out.bad) 7,15c7,8 < --- stress < --- clean < --- create file for ext2 fs < --- Create ext2 fs in file on looped xfs < --- Mount ext2 on xfs via loop < --- stress ext2 on xfs via loop < --- clean < --- umount ext2 on xfs < --- umount xfs --- > !!! failed to loop mount xfs > (see 049.full for details) 050 [not run] Installed quota tools do not support XFS 051 [not run] requires kernel ACL support 052 [not run] Installed quota tools do not support XFS 053 - output mismatch (see 053.out.bad) 5,12c5,12 < $SCRATCH_MNT/test.0 [u::r--,g::rwx,o::rw-] < $SCRATCH_MNT/test.1 [u::r-x,g::---,o::---] < $SCRATCH_MNT/test.2 [u::---,g::r-x,o::---] < $SCRATCH_MNT/test.3 [u::---,g::---,o::r-x] < $SCRATCH_MNT/test.4 [u::---,g::r-x,o::rwx] < $SCRATCH_MNT/test.5 [u::---,g::---,o::---,u:id2:r-x,m::rwx] < $SCRATCH_MNT/test.6 [u::rwx,g::r-x,o::r--] < $SCRATCH_MNT/test.7 [u::---,g::---,o::---,g:id2:r-x,m::-w-] --- > chacl: error getting ACL on "/mnt/sda/7/test.0": Function not implemented > chacl: error getting ACL on "/mnt/sda/7/test.1": Function not implemented > chacl: error getting ACL on "/mnt/sda/7/test.2": Function not implemented > chacl: error getting ACL on "/mnt/sda/7/test.3": Function not implemented > chacl: error getting ACL on "/mnt/sda/7/test.4": Function not implemented > chacl: error getting ACL on "/mnt/sda/7/test.5": Function not implemented > chacl: error getting ACL on "/mnt/sda/7/test.6": Function not implemented > chacl: error getting ACL on "/mnt/sda/7/test.7": Function not implemented 17,24c17,24 < $SCRATCH_MNT/test.0 [u::r--,g::rwx,o::rw-] < $SCRATCH_MNT/test.1 [u::r-x,g::---,o::---] < $SCRATCH_MNT/test.2 [u::---,g::r-x,o::---] < $SCRATCH_MNT/test.3 [u::---,g::---,o::r-x] < $SCRATCH_MNT/test.4 [u::---,g::r-x,o::rwx] < $SCRATCH_MNT/test.5 [u::---,g::---,o::---,u:id2:r-x,m::rwx] < $SCRATCH_MNT/test.6 [u::rwx,g::r-x,o::r--] < $SCRATCH_MNT/test.7 [u::---,g::---,o::---,g:id2:r-x,m::-w-] --- > chacl: error getting ACL on "/mnt/sda/7/test.0": Function not implemented > chacl: error getting ACL on "/mnt/sda/7/test.1": Function not implemented > chacl: error getting ACL on "/mnt/sda/7/test.2": Function not implemented > chacl: error getting ACL on "/mnt/sda/7/test.3": Function not implemented > chacl: error getting ACL on "/mnt/sda/7/test.4": Function not implemented > chacl: error getting ACL on "/mnt/sda/7/test.5": Function not implemented > chacl: error getting ACL on "/mnt/sda/7/test.6": Function not implemented > chacl: error getting ACL on "/mnt/sda/7/test.7": Function not implemented 054 Not run: 050 051 052 Failures: 049 053 Failed 2 of 7 tests More info, 049.out.bad: QA output created by 049 --- Create ext2 fs on scratch --- Mount ext2 fs on scratch --- Create xfs fs in file on scratch --- Make mount points --- Mount xfs via loop !!! failed to loop mount xfs (see 049.full for details) Related 049.full: (dev=/dev/sda7, mount=/mnt/sda/7) --- mounts /dev/hdc2 on / type xfs (rw) none on /proc type proc (rw) /dev/hdc1 on /boot type ext2 (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) /dev/sdc1 on /mnt/sdc/1 type ext2 (rw) /dev/sda6 on /mnt/sda/6 type xfs (rw) --- Create ext2 fs on scratch mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 117504 inodes, 234942 blocks 11747 blocks (5.00%) reserved for the super user First data block=0 8 block groups 32768 blocks per group, 32768 fragments per group 14688 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Writing inode tables: 0/8^H^H^H1/8^H^H^H2/8^H^H^H3/8^H^H^H4/8^H^H^H5/8^H^H^H6/8^H^H^H7/8^H^H^Hdone Writing superblocks and filesystem accounting information: done --- Mount ext2 fs on scratch --- Create xfs fs in file on scratch meta-data=/mnt/sda/7/test.xfs isize=256 agcount=1, agsize=5120 blks data = bsize=4096 blocks=5120, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 --- Make mount points --- Mount xfs via loop mount: could not find any device /dev/loop# !!! failed to loop mount xfs --- mounts at end (after cleanup) /dev/hdc2 on / type xfs (rw) none on /proc type proc (rw) /dev/hdc1 on /boot type ext2 (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) /dev/sdc1 on /mnt/sdc/1 type ext2 (rw) /dev/sda6 on /mnt/sda/6 type xfs (rw) /dev/sda7 on /mnt/sda/7 type ext2 (rw) Is any of this relevant as worth worrying about, since I don't use reiserfs? D. Stimits, stimits@idcomm.com From owner-linux-xfs@linux-xfs.sgi.com Sat Jun 9 07:21:59 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f59ELxKs011828 for linux-xfs-outgoing; Sat, 9 Jun 2001 07:21:59 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f59ELn3D011807 for ; Sat, 9 Jun 2001 07:21:53 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f59ELfaJ050463; Sat, 9 Jun 2001 09:21:42 -0500 (CDT) Message-ID: <3B2230F0.687ECBCC@thebarn.com> Date: Sat, 09 Jun 2001 09:21:36 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: Alan Eldridge , linux-xfs@oss.sgi.com Subject: Re: Running kernel w/o RH patches ... References: <8648.992061344@ocs4.ocs-net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > On Fri, 8 Jun 2001 23:38:37 -0400, > Alan Eldridge wrote: > >Knowing how heavily patched the RH kernels are (!!), does anyone know if > >there'd be impairment or malfunction running a stock + xfs kernel on a RH > >system? > > I know that Russell Cattelan did an XFS+kdb patch for Redhat 7.1. I > also know it took a *looong* time, fitting just the kdb patch into all > the RH bits and pieces from the -ac tree took me about 8 hours, and I > had all the tools to do the job. > > Russell, did that XFS for RH 7.1 patch get released? No not yet, Eric has taken over the task of doing 1.0.1 I had planned on including the 7.1 kdb patch in the SRPM but not applying it by default. We could ask Eric to do the same. I haven't even attempted to put kdb into the rawhide tree I'm working on. My test box didn't come back up and foolish me took the serial cable console cable before I left so I don't know what state it is in. -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@linux-xfs.sgi.com Sat Jun 9 07:45:35 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f59EjZhZ016445 for linux-xfs-outgoing; Sat, 9 Jun 2001 07:45:35 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from walt400.holman.net (aazpppdsl56.sttl.uswest.net [63.226.208.56]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f59EjP3D016379 for ; Sat, 9 Jun 2001 07:45:30 -0700 Received: from uswest.net (walt400.holman.net [10.0.0.2]) by walt400.holman.net (Postfix) with ESMTP id 5BE40426A36; Sat, 9 Jun 2001 07:55:20 -0700 (PDT) Message-ID: <3B2238D8.50201@uswest.net> Date: Sat, 09 Jun 2001 07:55:20 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-xfs i686; en-US; rv:0.9.1) Gecko/20010607 X-Accept-Language: en-us MIME-Version: 1.0 To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: cvs working again References: <200106082112.f58LCks17786@jen.americas.sgi.com> <3B2178DC.2090803@uswest.net> <3B218225.A3E984D0@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Tried this some more this morning. It appears that cvs updates work, just not fresh checkouts. Or maybe my timing was just.....not quite right :) Eric Sandeen wrote: >Walt H wrote: > >>Hello, >> >>I'm getting a strange error when attempting a checkout at CVS now: >> >>cvs -z3 co linux-2.4-xfs >>cvs [server aborted]: can't chdir(/home/cattelan): No such file or directory >> > >Hm, several of the cron jobs that push things around run under Russell's >account... that + the machine switch has probably broken things once >again. > >I'll poke around, but I'm sure Russell will patch it up as soon as he >sees this. :) > >-Eric > From owner-linux-xfs@linux-xfs.sgi.com Sat Jun 9 11:34:35 2001 Received: (from majordomo@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f59IYZMX001488 for linux-xfs-outgoing; Sat, 9 Jun 2001 11:34:35 -0700 X-Authentication-Warning: linux-xfs.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from roujin.gargoylecc.com (roujin.gargoylecc.com [65.100.85.34]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f59IX43D001345 for ; Sat, 9 Jun 2001 11:33:05 -0700 Received: from roujin.gargoylecc.com ([65.100.85.34] ident=ringram) by roujin.gargoylecc.com with esmtp (Exim 3.13 #1) id 1591G4-0002JE-00; Sun, 10 Jun 2001 03:11:44 -0600 Date: Sun, 10 Jun 2001 03:11:43 -0600 (MDT) From: Russel Ingram To: Ivan Rayner cc: Subject: Re: xfsdump, paride tape, and -m option In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1681990229-1839033695-992164303=:8848" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1681990229-1839033695-992164303=:8848 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 9 Jun 2001, Ivan Rayner wrote: > On Fri, 8 Jun 2001, Russel Ingram wrote: > > > On Sat, 9 Jun 2001, Ivan Rayner wrote: > > > > > On Sat, 9 Jun 2001, Russel Ingram wrote: > > > > > > > I'm using xfsdump from cvs (I think it is from 5/30/01 but might be > > > > 6/5/01) to attempt to backup an xfs filesystem to an HP Colorado 8GBe > > > > parallel tape drive. Every time I try to use the -m option (the > > > > parallel tape driver is a very minimal tape device driver and suggests > > > > specifying 16k as the block size) xfsdump core dumps with the following > > > > error: > > > > > > > > drive_minrmt.c:1820: do_get_write_buf: Assertion 'contextp->dc_nextp < > > > > contextp->dc_recendp' failed. > > > > > > > > Is this a bug or just an incompatiblity with the minimalness of the pt > > > > driver? > > > > > > If you can mail the complete xfsdump command line, I'll see if I can > > > reproduce the problem here. > > > > > okie dokie, here's what I was giving it: > > > > xfsdump -m -b 16 -o -l0 -E -F -M"gumby" -L"home" -s home -f /dev/pt/0 / > > > > Like I said its a parallel tape drive that I haven't got anything else to > > work with either (tar works but not to the expected capacity) so it may > > just be a problem in the device driver but since it core dumps without > > even trying to dump I thought someone might be interested in if it turned > > out to be a bug with xfsdump. > > The argument to -b should be bytes, so 16k would be 16384 not 16. > > If this doesn't fix your problem, could you use -v5 to get verbose output. > (This might produce alot of output, so you should redirect it to a file.) > > Ivan > Ok, I ran it again with the right sysntax on the -b option. Here's the command I gave it: xfsdump -v5 -m -b 32k -o -F -E -l0 -M"gumby" -L"tmp" -f /dev/tape -s tmp / It still core dumped with the same message as before. The verbose output it gave me is attached. It's pretty huge and is mostly just messages about pruning inodes out of the dump due to not dumping the entire filesystem. I bziped it. -- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com --1681990229-1839033695-992164303=:8848 Content-Type: APPLICATION/x-bzip2; name="xfsdump.out.bz2" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="xfsdump.out.bz2" QlpoOTFBWSZTWWeAiqkGrsrfgHwcUGf/8y+/3tq////wYWxvvjPvpIhVfAAA AAAACiqUAqg0AMRIUAAAAAAAAAAAAAAAAALYAGSAiVJAAAVSgAAAAAAAAAKA o0DQAAAAAAAAAAAAAACiRQABwD6oD3vCCAGsVBEAaYMfQQx13fOnOm56d09A HPWB69s56weeY55eeQL3Hp55sEdh4AODGAGOuejyR9Ph8awAbGoIQCkVgen2 Dj13gXmbgspAYIBrDLF2wHTENqTsOHZp1gOtmAM4g7vCEAEFQQgFQbgAFMEA AAEEAAAAAAAEBeQABg27ZiDcG0B1RoAcEA6DBsthBKBsFgBbwRABNMBIAVA6 R2CN44MdBgMYqsNjJAgd2cEaDBdwErguuNrbXAw4VniyMAG1tBCAUqPeALBg aUwj3YA4LhXYHOmAAAAAAABmDYgooVgzAFUDBAAAIJiArBbmQvvfCCAF9VqC 0wBUG+fDNThuDqXBxgodwWBOXBa4BuCwRzK70b0ebQOCdHKRwQAVr3HuDeGp FdNXeEUgBNaghAFVHvehVCqVTvRnRV4Hejz0nrbacF3bdut6O6Fbo7r2AUF7 x7wAAFLBNttOxvQAbowAB7cIIAI0wWmAUqOOgAN0d1Czpd0DuVx3S6M9Hk70 YO9W56sevVt70dwFujAOPVu9XgekvfX3wggBM2QtMAUqGXn1vR4eeC56ecXo 56btvOBwdj6eh4IdPB7z6cA6POCzfcwdZSBF7ilb4QQAhKCIApBw89wN3UpO engBGs9EFY68ceJnBNcDK56edV4zj03N7dVuem8Jeqy4LIQXwB4AAAAAAAAA AgAAACJQgE0E0aBAp7SMk2mKPUemRAYTYmnqh1T/M2T9VSqUKeamkA0AAAAA AAAFU/BmlSpJKaNNAAAAAAAAAARNtIFKiJqR6g0AAAAAAAAART36ojJSqUAB GAmAAIGmABGhkYJNJExSVKaU09NNBGQMmQZMhkMgA0aBzdfNy5Vr0crXdd99 9urr/CYgZySlKSSSSSSSSSUSDaqqqqqraQWqqqqr9bM1VVMzMzMzMzMzMgAA EkgFVVASfREn30D76B99A++gffQPvopVffRJ99A++gRAgCSZJWtgXWkJISSS SSlKULAck4w+NE3yq/h4C74xV2b+GhtqSu2u20pc7rX1pwpjwtKf+1u7Kobt 9N9341+n337X+in9kFRX6kJTmYpj9rUUsrY/a84zqMrmb2K9VZj6ojj0LQg7 L3cyyddI8sxek3m1curIpbiluc5aVWOwLSUxN9HT0GMdxwuN2G44XUV1bqU5 smKErjtV5L6rc9H3qtGXsqR1dnF/t9kovbVpNO+9t2n7h9tWsq/J3N9w5tHl sFfh2767lZY3qzoKOi5mGsfJc8V5BVGQ96ajRlY6Yr7hbfWbrhzhVNpLVkSq l6TuWgOlXag655OHVXhqCG76aMe1qT51tbig7cznehhG8FktJXddcwrA5P1y jHtSkOzjjKkpE6b3J9S1eWVnp2+caDIoX3G/lUbm8TvVvHlfc0sVsl3m+PKs xe4s0rqlzx5dnqV48TXKl6tzpr1ejk3rQlVLw8MKg28qzOKilMpbmU76uU3W y3CPL1VH3nt944V/t2dbZKVZM72q6ukq7acwRyt89RNdamilFrlbjF2S3ZMb 17tP24FzvULMvp/g+UJJndhj9k37eTkkkkAAAAHLbe3z9De/mZmec57waAAA HLnuZhTznfO86CXy220AAObs5PPJFpl73pigDzwAAAAAAAAAAAAAAAAAAAAC 2220AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAttttAAAAAAAAAAA AAAAAAAAAzMzMAAAAAAAAAAAAAAAAAAAAAAAAAAm77u7u6eN3d3bugAAAAAA AAAAAAAAAAAAAAAC2220A39u7u7ugAAD9u7u7u6B9+3d3d3fvgAAAAAAAAAA AAAAAAAAKW22SgAAAAAAAAAAAAAAAAAAAAAAAAAAAAABbbbaAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAFtttoAAAAAAAAAAAAAAAAAAAAAA0AaAAAAAAAAAAAA AAAAAAAAAAAAAAAFtttoAAAAAAAAAAAAAAAAAAAFtttoAAADN3ebu7o9bu7s 3dAW222gAAAAAAAAAAAAAAAAZb7bbQDzwAAAAAAAAAAAACe7PN7vfP3gdQrM usbZe7epuEkkkkkkkF4ybkwADy3t7hbAAAZvfZOSKOfuc8vnvTDy222UBv7J 5Jxh7I93zm+dKUC/rbbambvN7u7oBJJJu5kmNKZ4epzsOzNXi7l+gAnJHbvm 55byq8zMzu7QAAA5P0WJKSSSVke3psT575LdfRVIGo909c62t3f27u7u6Cc5 x5+8IADz3z0AyeTOi2tNkkk393beW0AEkkf7vZ4DufZ0ix3jLBv2pSLyiSUy Tb33C/pC+4W5f22223QC2220AAABd88v73ed3d2Z5tuY6tze97rF7beW2vAD mZ7met/ZzPzMbbdl3z148ZnOg3d0AAL+ttTxbnlvAAfvO97zoeMzO5gP1tvM wIc/XvepydzuKRt0AAADvknJJAAAZO96b4vKzMTIDffXAAD0Bd3d3ec5zd2e 3M8AIbJJJJJObSSkbE6fd1d1Xh3KblvttrQAB3wEAIXtnz1r6G7uE+mwDmdZ l35I7ZBtxe8kkmgDnfO97776OS+W9kN9lk7Jsug3d3d3dOc5wAPffejzlttl AAAAAA6CZmZkAAAAzve9b7fd2Vs53e5l3vFZxvnMm3zOvM7k32F8kL7C32Fu W6RmZA7mbg7t2itRXRpBFTnPevHS9VTsT697JzMAAc5zm7u7u7oAAHu7v6Td 5d5zmdG++ufnvvoAGZmZgAAAAAAAAAAAAAAB7v8d97zbc3vOn7udxzz2rvoz b1j9777mbQBvj0Dv7vevwbu754AAAFtttoDczMxAG953vbebzm7n48nNzzeb O982G/oW20D4AfAAAALbbbQAAAAAPP3gHmZ3nf0/Zk947JP3vvXtknUoZeVg Ex3XKtSmZjqtnKknxPVShYbAJJJs6g9iU698dm5RzIGK+7ENOTG29fpG0lIA Y237MzNeyPGKW8N9Nzd7K73vdbQfszMzAFt/cU9J38t9MeNzO5iAA7+zzMzA AAAAAAAAPfee+8PEk+L7uAJJmZnN2225JIeBBZfijd27vwANsv1XrwNyb3RS N7uyJSSSR7zvnvegADnOcAAAAAAAAAAD31bbJaAAAAAAAAtvDMxbbbbMzMwa AABXgAASSSfeAAD76SSSS4ACAkkgAAA0AaAAAAdbu93d3QAABjd5u7u6AAAI 33d3d3QAABXkkkigAAD8AeW22ygAAAAAAAAAAAAC2220AAAAAAAAAttttAAA AAAAAAAAAAAAAAAAAAAAAAAAAAB3fbe22NAAAAAAAAAAAAAAAAAAAAW222gA AAAAAAAAAAAAAAAAABu7u7u6AAAAAAAAAW222gAAAAAAA+AHwAAAAAAAAABb bbaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFtttoAAAAAAAB7u7u7N0AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAttttAAAAAAAAAAAAAB3d3e7u7N33d3d0AAAA AAAAAAAAAAAGboCbugAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAW222g AAAAAAAAAAAD+/d3d349+AAAAAAAAAAAAAAAAW222gAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAGZmZgAAAAAAAAAAAAAAAP5AHwAAAAAAAAADu7o Gbu6FtttoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA7u6Bm7ugAAGZmZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABbbbaAAAAAAAAAAAAAAAAAAAfAD4AAAAAAAAAW 222gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABbbbaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE0Au6AAAAAAAALbbbQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA5znAAB8APgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAC2220AAAAAAAAAAAA93d3dm6AAAAAAAAAAA AAAAAAAAALvm7u7ugAAAAAAAAAAAAAAAttttAAAAAABm3zw97+83lsvZWgAA AAPNWvfL7nHMTTzcnkmRQADMzMwAAAD23zOZhKAB3+OZcw6mgADtt5baF/W3 ZHLbQGZmZgAAAAAAAAAZmZmAz3e+/s9Xu0OOZAAxJYkyoHpWlXMnoo5uEJg+ 7jZbUyk+2K2TFz7kqKyqH3cbfvoxABznOS+dzzMLQN3f3Mnkjy3u283d3QDZ JJFAAAAttttAAAAAAAAAAAAAAAAAAAA88AAAAAAAAAAMzMzAAAAAAAAAA88A AAAAAAAAAPPAAAAAAAAAADMzMwAAAAAAAAAAAACXyySG7o89qbl9zF5Gi221 5EbbkfrL93jtsODNrd6PGbswH5neiSXTG27WZz3w222ySSU27bJJJJRz30e+ +jQEtttuW+e396/Jzrv7vZ/GYTfdbmd/bvsXMAAJJxTpttz277nHa9zuLshC RZmd4q+m076Y9rdWiRwnIYAvO+9i3cZ6uku6tXm3dV+zm32Z6d6Tp0Wpptul vEYKU+mdeesuJnjfXerY5NoAAqkU222SSSeLSS1MbbbjAANStJIi3w7U5HW5 w0QmZUkiXbrG/dU8vZWdIPm7biqNtvG29bchtRYqrDemTX3OnlzandgAB2d7 0R3vOc5O+e9X9uM8zvc2gC/rbNzcd7MhbTc57+3dzf1W22gAAB+nvkj2zhZa A75nerd915nLMSSkkpTKk2cduzZHAG0olIg1K/Zt9LzX0PDbilt96Rv2v9mx P1e5N0LbbbQAAJmZu5uy+zDJ6SSBO6/d4SmdAAo8BJIYtyXJVcWAb3vHRuZm fsPDd3tl43d0c2Y4YtAAADbc39pvu5o9W1V9fcyqhJJJJJMzMkfnqqdUSoQ2 055uJJbG5wGBmZN3du+u6x5iRr7vs7taAAAALzj31+m/t9zN994rx5ehlu7u gue28z9ffLyBtbu7uzQHZPY/EkgDZczETPfxvd3boD/H34BfgAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAG5mZvkXoDOc4FAAAAAAAA88AAAAAAAAAALbbbQB lvtt6XsnmyS7LoAzM3dZgzd0AAAAAAAHe970e7u7uzdAAAAAPPAAAAAAAAAA AAAAAA5u7oO7u7oAAW222gAAAAAAAAAP2ZmZgAA39u7u7ugAGZmZgABnnLV9 /e93no85TVH7e7llbsySjG2RTJN9vefuP25btt0AN3d3TXgG7oW2ttySSXud sknIpts9G23Rfd3XED6km5n7z3VtAAAAG2221oB5u7bZ5JNti27znN3doAEt t+d3b5uSSRX5W6zZO5XxSWpS7tyAAAAAAAAAOc5wAAAAAAAAAAAAAAAAAAAA LbbbQAAAAAAAAAAAAAAAAAAAAAAAP5AHwAAAAAAAAAAAAAAAAAAAAAAAAAC2 220AAAAAAAAAttttAAAAAAAAAAAAAAAAAAHd3d7u7bW21m7ugAAAAAAAAAAA AAAAAAAAAAAAAJu+7u7ugAAtvlkht3QAAAAAAAAAAAAAAAAAAAAAKAN0AAAA ALbbbQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH37d3d3d++AAAAAAAAAAAA AAAABbbbaAAAAAAAAAAAAAAAAAAAAAAAAABoA0AAFtttoAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABbbbaAAAAAAAHN3d3N3ba229bu6AAAAAAAA AAAAAAAAAAAOW29toAAAAAAAAttttAAAAAAAAAAAAAAAAAAAAttttAAAAAAA AABm9710yeSSN8b473nQAAAAAAAAAAAAAAAW222gAAAAAAAAA83d3d26AACN 93d3d0AAAFtttoAA+AHwAAAA92Sdcn73pZ2t0dk9kkABznOBf0kkhoAM7PZy SAAAB+2SSRS+25+5hbQl8tttADySSZAL3venO+d73f222239bbbdAPPAAAAA AB+tskhu6AADd3d3dv623z893dYe22sj9barQAADMzMwAAAAAAAAAAAAAHly eSQ9jOPZoLr7oZ68fG0qtJLuUmKU3rau3kkkke7+5xw5fObzd/ZZW7ugAAAA AHngAAAAAAAAABbZOnmJCXf1vMz3C0Ave96QAO972d5xmT3W83ZsugAAAPOf ue8AZ76EA755Ob7e39dzMzLubv733ZB3rK12282Rz9mHnl/Yskm2nskXPw22 3LxdnPXySfu7ukk57u40Z7Zjva25vf088t3d3QAPJJJkAAAAAAAAAW222gAA Az9PJe7uZ7uy+e+N6BeB3V0z4nu6HsNzxlaE820l2b3d3d05D7z9vd3c/att vne77POTIoAAAXnOZPO96VugBn8bmcnOyW/pjxjFAAAAOLb220AAAAAAAAAA HfefvOA1bn7GeJDdfx54AzMzMTvowoAF/d73h6PPN3V9ku573ujJJ5JJJSdX dnrvPSIbYd3cp3dzTkAAAAAAAAAAAAAAAAAAA7beW2gHb5mLm+PL3y14bomq 65zOcv7ztwnUgP2Z4Hd3mZ7nmZttl5bb21bbbdB+ttkhux5bc3zm+2zu8ue7 WZmAAe885wnPfOeib2874nvPInmZkmQAHL2Tl5zMv73vfe9oAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAttttAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAALbbbQAAAAAAAAC2220AAAAAAAAAAAAAAAAAAAAAAAAAAAf1bu78HfgFtt toAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFtttoAA AAAAAAAAAAAAAAAAAFtttoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAW222gAAA AAAAAAAAAAAAAAAAAAAAAAAAAABbbbaAAAAAAA/kAfAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPLbbZQAAAAAAABbbbaAAAAAA AAAAAAAAAAAD3d3dDm7IttoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAW222gAA AAAAAAAAAAAAAAAAAAAAAAAAAAABmZmYAAAAAB8APgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABbbbaAAAAAAAAAAAAAAAAAAAAAAAAAA7u7v d3dDjd3c3d0ttttAAAAAAAAALbbbQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAALbbbQAAAAAAAAAAAAAAAAAAAHwA+AAAAAAAAC222 0AAAAAAAAAAAAAAAAAAAC2220AAAAAAAAAAAAAAAAAAAAAAAHu7u6HN3d3QA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALbbbQAAAAAAAAAAAAAAAAAAALb fZy+2lzMy3MytuZuB3cASSSL9VeSSXr93cYk7l10XZkk9wboABL5bbbznPZJ zMjzve8HklnkyG6AA3d3d3d7a/OckzMrXN3d0AAAAeeeeBLb7zmb12ssbblV 3aFbOwrK56TA6KSWBtb2RJSd3d2dJdpLdT9SVUvPnlI220gABz9znAAHc8zM wAA7beyelt322+5h2QByb5zlvtudnMuN/b5O9n5zYzdmltttrnOcAA/Vtttz zbbakANjeJKS0o3yC9ANX5ttt9223LTzwAAAAAM3d5u7ugAAAAAAAAAAAABz nOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAW222gAAAAAAAAOe+ g/Xd3d3dIOAAAAAAAAAAW222gAAAAAAAAAAAAAAAAAAAAAAAAAAAAABznODL LLLLLLLLLLLo4cJPhpjs8HUofqeX/WrjHEDyZeb9jE+X/d3otJ/FhMDbf+x8 fl8++Vv70KjcgIqnjgqoOTOjtoqgDVgKAItcKIJWKqKldLItVRRQsEAQUNsR GsFLd1EEQLoiAgp1wBEKH50IL6DEfsinrimOSrxVaoB64q6w77Q/Oj5YAKD0 CXdPg1ld8E4lsen6entpWOBs7u3P5FqFRQDzxFVQJBVWEEQSRNsUCkQFBSBJ FkkJFkhJFAkIKABFFUSQAAACQFRUkABUkVAiwkAiwkkFgEkUCQIChBPqiCqB SAoisgqqEiiCyKgjIqgikgooLIKIJIAiGIcuk3mNqFd/B4ed9Mfupj/neKAg imenV8Nnb7Mbff+mgYP8aVFFRFTntqV0ulKaRVoFYXXYWuutCtONab+ml08t 2UJ9V0AOf3e6UnvqU8VbW9364bofuePf4T22+/1HdP7w9n1mAbPf7re/Zn06 5aT6xQEEU2HC+bt+3Ou7ZjgdkX0gdqFFPKp4Q2AVOborwrV/pC/iSrq/2/jw R/B+6+2KpbNdfQPczoRhkFzpHEK8jwpfrN7Mqw2kDXL3d4jgEkkUkkgAAGZm ZgHvvoAAAAJJJBu7u6JJJIAAkkkgAEkkkAAAASSSQCSSSSSSQMN5u7u7zd3I dRdRF6rU5Vr1uN0dzeRReau3jcFJMiSvEntVyur10J512kQfU2ZmVWOTa1ts 40FEpN3K29NO2ezF7Xyu+yqrubkkGZZ12C8laSR3d2j27d7W5mPNQt3bx9Bv WtSEuewQdzZJJu7sDbbd0H4zM7+6G7skklkkkoAAAGZmZgACSSSASSSQACSS SAAAJJJIAAAAAATMzMP8/599999999mZmYAAA73vegAEkkkAAAAAAOc5wAAA AJJJIAAkkkgAAAACSSSAAAJJJIAAAAAAASSSRu7u7u6AASSSWku3MWhVclRi uZvurIxa4l0Wk3Zbdd73uAOc5wZmZmLbbb3ve9oDM87u75Kudvu7a65dxRSL 0hm3WQd4zu13SWb6d06MzerJVGO33h9cvLvroEt0I1cfe3FotSvJjVkp1vTr /yb+++f0+n0kkkDe970G7smZfzM3+JN73ve6BmZmY9IDfDpw5VfMkzJZ7t8Q SQoNttyCSSSAAAAJJJJJJJAJJJIABJJJAAMzMzAADd3d3d0kkkgAEkkkAAAS SSZmZmQACSSSASSSS/s/ZmW5mZJJJKCSSR2+i8+tuq5jy74nXd907uDd3d3d bcjvsjHV8ad3dwkuVI3d1inqqQV1yS6ORJdlGZTU677zl3nbutlV66mVAH0u R7VuRdDyd5nLz2/u5PL+nd3sxmGgBJJJAAAEkklkkkobu7v8lttkPgAAAkkk gEkkkAAkkkgACSSSAAAAAAEkkkAkkkgAEkkkAA999AAAABJJJAAJJJJJJJAA AAEkkkAAzMzMAzMzMAAAAAJJJI7u7rirIXbLwJtpzWm7LbMuabVvGdW+ed7q Yzcz9Gd7zJskt/UHngAAJJJN3MzNc5zloAD8/q/6/P4/p/k/4Z+/fj+f1/d9 /b3Lf7k1/c/7oANuKurpItyrmSsqneS96QQ22xttK3mABAAAJAAAzIV1EXAq bi9PbV4y5N5ux8cpJJIAABJLt3fcm683fUsu8x/3khts++AAAgAAEkgAMwLy KpMzMv3vLMSzC2zbIIU1VTCmzYXiSgABIAAAAAAAuN2rAvaZmY4fru9UGqao AAAAAkGwSSSSSzZ10BmUzd3aiiYzOzCdoAAD1Vy6qqmqrcidvlUXtMXbu3F+ zLmFOiSYCSSAAAAAAADMy7ptvKZW7pUUTGZcqdbAAQAkkkkkgAACsyqvzbeU yK3dKioJzLlTrfNtgAAAOG2wCQEkkuzurMbb6mVuJw4Ju7mFOCSTC/QNtxHv qqgABcdzvL7d3ecuuZi4X3vZhOUACAABDmZedu7vOXXOzUVU85kwtlymEpBA AAKzLzsXd3nLr7nZqFc5kwnKAAAmISq6u7v/Oml/ZCvsVxfNfSEkkAFXcHZ6 itq+8rDEuUG222NtpW8wAIAABIAAXMd7TFzhWKd0qu3XZOdHN8SAAAe+5eck y3vv6z1vv6eTez+ditsnwAAEAAAkkACkrJ4V2ZmYriQu227pkVNohFV0wpwS SSuI94AiIqqAAHc5edu7vOXUc7NQrnMmE5lt8QDMVVVVX7vc7z7e977vWTfH C5vfErxVUWRVWZvnNc+1rWub1nE7zrsutuvWfvx+r9qDRnd3d2468MrvXrbr 1nskYiixVXOX683z7Wta5vVzj83vdfF39ziXuCiiin0ktFFiqfc1rnPt73vn zRe7twqvMlTokkkkriACPQAR6ACPQAR6ACACPbErNK0A3ZW5mQnV7KnaH0CE EIIQ7X31RRAgQVMdyngBmNa93bjSs3JUxQoSUJP0EAeiCAIIBQkoUJQlKlS6 JzKwAvHjnMcZO+c413jWtqq73mNtbZIFt134+znDLzmk5CSSACru4ke13paq tNuZvdINttsbbSt5gAQAACQAAua72mTI39Cey/vddzfNnbmgAAHvuPMS5ulD 2bt+um9Pmo22T4AACAAASSABSUfXbzMw7d15mYpepX5ak2iW0lYCQSAAJKUp mZisrLttvKZf2H2a++41uBSooo/QKVFVcpvm+UAZjLsix3eSpRCU+iZ96JmK SSSShJRCVgF4nYBmK7uLHd5KmhJP0R7wCACqqgE97iu8uqzGcyFXluziwAAA AAAAAAAALy6eSyC8WVkKR4K5xMAAAAAACAAAA6PNtwVmq9klZaurhSPJvVow AAANbbAAAAAADa2txhjZauLplGTk2gAKbd1VVVVVVVOqqqqqqqdVVVFVVU22 5VZRmMLaysnIoVFTcvBy2xy2xtNpttttw2xy2xtS2m05bY6zJu6FV4srIumU ZORLsctsctsctsbbbltjfk2nDTaceabTltjIvtHY8pD7uwcJJIAKu6SK630y b66Z3TEuUG222NtpW8wAIAABIADqR7nmLnPdc8xO/vbs/R5s3cgAADzzs5zM xSnTr8qdvc+SG2z74AACAAASSG7uzXW0rANVNO+YY1dXc06WTk1ZDabTabTc JtDmE222xy22m2wAAvLanLxXVxdOlk5M0AAAAAHehttw22AAABO5O3Ce47q4 ClmrJnWAAAAAACASQSABcbrU7edl5Dud5bM8wAAABJJJTMzMxEbG66K3K6tn TXz316+hpJWRfrVVVVe90buu85nt7OxRi3l09M173o97t3lXCvdeTkBSzlhs W53dt3mbF5ORVcZrFTMQn5OxECPo7vebM33u9ceGZu87eZ0gpBSCkMbbbUAA AATe7V0zcp5OQFLNWTqeNjcNtgABACSAEkkiYt8Vj7lzarN5wAAbgqnrkv2u cV3Vl5mwcbbbG20reYDcbbcAkAAL2cuyxC4193jzv7z239k8vmS9xu6AAb4y 85JlvkdzL/Oz5cKNyfSSSSSQAACSQAKqjlYLaKE7vtrZ2Hc7y2a6m2222wAA AG22223DbYBG66ZW5Tycgqc1ZNbTbbbbbbbAAAAAG23vo9DbcPWJ7mZWQKlm rJvaAAAAAAAAAAAA6e6hV27lZBU5yya2kAkkkkAAqqqN3lL3MzmRXJzWTtgA ABMz9u7PNzO87FcnN2tm5mYmYmZlXJLbLVO97l33nOb4fa+edvXFXQFqqqqo ve91e/c1r5+Pvt87euKqqqrMzMbut653Kc4si7rNo2S6ABJJBIAAAAAABG7l srdq6WIi7rNo2S1UkgiQUAAIkkAgEpUkgoSqVLbLw1SRwAAbgq/T1XJfnNNu iGdfYugNttjbaVvMBuNtuASAAF7Emu925PePb1653957H7NvmS9zd3QAD87O Z+zMjPb43395vuc364ltPgAboABJIAFeOyWsy4Zy3Ob7advyXOdWz2eYiqQI CUwIJiESQIPtvvOVO5dz12O95m8rZ7PCJAASmEprWshWpKxVve/YXXec3u8v DnN/d3nX7dlW/B7WtazMMZHMyS2tS2ltLaU7PvVfKd27nrsd7zPNnkWQlIgQ IECEpD7d2+U3Lueux13mb2tnOX99FVVRH1VQAAAydcu6bmXOMjveZrZ5vKoA AABW7d5d3u7XE8qec5mKntgAAADNnb5zlc43Mi+TznOZqp5YAAmZmZmZ7urX Xec6+5znOfd7c3pVVVgoKoCwPd0YLbzpu7u6zkU5mZuISURHtmPR6IBJVVVV VVezPGKqe7W8DAABuCr09eyzL9lMBu29QDbbY22lbzAbjbbgEgABezu7EMa4 7Nysq0/c7L5PVAJAAPzMnZO48m+et9/b7vvr6z6W358kkkkkAAAkkACiuuXt 2sy3ewzOGKkl5LnLztqqqqqqqqqsu7u4GS8roHZ73ve8zyp5YAAAA9u16orn t3s973veZ5U8sAEzMzMzg+j07zzHfu9+fvvvvt883HfAtoFtIW0lqqqr7O/e zN+735Ofcfvt79tzT1VVVVVW4JzMUYq8k0uydWbRVVVVVVVV13d3d2j257Kr vr3cRmd7ffcmrneAAAJJC/bke3Lt6/exGZ3t99Cp2wAAABU773qO+zfucu73 0KnLAAAAH30e3fHPbv18m7vfQqcsAAAAerPRy6eTt9VfO+9ntAAbgq9L/dbS PR1I3e9vEjbbY22lbzAbjbbgEgABezua1hzOdX3Zed6k/LS+xaQCSSSSSST0 1d2KV4V+rjn6ue+vrE+tPgAbu7u7uhu7uzG+7Z2qbG1zTm5tzHF3fvQqcsAA AAe3fHPbv18m7vfQqcsCY+Sn5IAAZkzWd79fJ9znM2FT70kgAC6qgZ70zXtz 7nIu797k1c+1JOAEkRABEQAAASGeHLaJDI9727LlLNz1U27yETusJBEggADo httxHvebbAAAAcRHvR3RMvt31U2+3JHPN9EeiPNtuIbdqq96IoqlTTactsbT actsbTabTaa7pmu7fVTbvKxOp12qUQxiaYxNMYm02m02meiGJpkehiaZHoYm iQW5Mvdz1U282sTqddokESCJBEgiQRMgEgiQRLbE9yZNyoqobebWJ1M67Tab UNtttNpgAAAAAASG5NSluZDqW3m1idTBWkAEAQQChIIACQhQCJBQkPLrjNrr QhwAAAkde4z1IjrlPZopevUwbaQkvm3czJA+bbfwEgAFZN2+aa3z9vCOdVLU 8tpVyN4Akkkkkkk9NXd7FK925NKrHZ8KKNk+kkkkkgAAEkgAF04+3Me5dZVX d2t667u3ujbecp7oAAAA72cmYluZGd73ve93k1c3oAfQPoCZmZ++mY2Nmc3O dnve97zu8mrm50AEyJmZndmc3O9nvbu6vakcuPenEq0tPzTbjzAG22AAAACr ZlbuZN3dxdXkImtqmwAJiPAxzEebQAAAADbyqbce2dSo3Mm7u7q8hE02AAAA AAAAAAABmPADMybu7uryETTYAAU22/RDbbj0NtuPQ3tVUeiqqqqKpsA3bSo3 Mm7u7q8qRyNgAAGtptsAAAAAANydo3MnsyMzLzakcjhgABIIAgAgAAIKbcMC B5GUZmTuZGZl5tSORuobbcehNpuIhtt+httttvzbI8AkoSRd1SRHa7CZqg4A AASOv2cjrnrhWZ5azVmLdbg20hJfNu5mSB822/gJAALvJmbNRw8s7r9Wevtu 65eaqzORqbugAH4yyZ2/xk/Oft3y/XNi0+kkkkkgAAEkgAFuPuzHuXt+3F3e 9mRmZmbyauav4CAIAAGd6zl5mbmRmZmbyauau4qqD76B99A++hbIW2T6KCpm WQtshbZOGtc5v57zhl5jN5NXaw+AAAmbEsjGZndzI7He93Zq7ubAIECBAgQI ZGXncZuZF973dmrq4uUhKYJmZmZmZnIwy8WLcyKur3ZGDSmZSXIAPQKZSSSV rXJos1Z2ZDu72EP0e8r2rbbbu7uru7qqAAFXy2KzHW5kc7zuwqdoykREVMCB CUjZ7d1F3dRcxd3LcMZFYmaPdts3Mh5WbCJ2NqpTcDkIY24bZ5zABABABABA BAazKmq1vcwncyMrMzYRNQ2EAEAEAEAEVrWpWtala1qVrWpWsu2c2umlOvg9 iwIkFjtfREfumZz92/r+T9XjmCSKbipLxO1H622tyJg3LyrTqpy4f7sLH3Yr mZItdWzD3UPMpJakzP3b+1a3QSSSQAADMzMwD330AAAAEkkkAAkkkgACSSSA ASSSQAAABJJJAJJJIkkkpJJAAA7vbpJ6KuEkZd9ytLWhbXtjkO5Re524kkkl Lcc2qSzMzSlbV9nYRobqpuZVNx90snZpvPmkkmWrXTcSynaVEzNV3b3dG9hq 4CtorrFXLu7YpO09c4VPTZvNLdq5oDOoxLM2fru7uZWvR3ve9AAA9SSTBu7J JJZJJKAAABmZmYAAkkmDd2SSSboASSSQAABJJJAAAAAACZmZh/f8++++++++ zMzMAAAd73vQACSSSAAAAAAHOc4AAAAEkkkAASSSQAAAABJJJAAAEkkkAAAA AAAJJJIAAAAkkk999h+ft31zmZbznbbMnd29OrKhS7WaDqeObptuuzu7uAO6 d3d3Rttt7u7rkkknd3W/b67eZ3rydcJjyq2+28QJVqk9Nmw7lSO/cK8CtvJa 2Skru+fTMztnGdTndi9fdkXqfGy4Lzuee/3e/ffX7758ADfO97wG7szMv5mr 8kbu7pJJJ3d3cDaXuKePX2+fmy1vvc/ZyzMxu7bbaCSSSAAAAJJJJJJJAJJJ IABJJJAAMzMzAAAACSSSAASSSQAABJJJmZmZAAJJJIBJJJG/pJN3MzEkkkEk iXd2JQ3W3UUd3c6JXdpTuDMe7u62zxyzbxLX3d3RLfdVrM49PSgC9prafNNE SW5137E3I8ycXi3dCVV1PQBGyu7ekkkiq3eNtuvJ8b3TVIQASSSQAABJJJZJ JKG7u7/JbbZD4AAAJJJIBJJJAAJJJIAAkkkgAAAADd3d1JJIBJJJAAJJJIAB 776AAAACSSSADSSTJJJJIAAAAkkkgAGZmZgGZmZgAAAABEkkpJJFS0O2/Ag3 d3bEPR4+3cfD99/Z3fz3sy9/THbmdbttt/UHngAAJJJN3MzNc5zloAD88/4u f2v6TuNzsy/6/pf0/6AAAJHXuMczHUszOvIztjL01sG2kJL+5t3MyQPm238B IABWTd6bYxx+1dMKzHVUd59Uvk96ASQAH52ZnvJ/Hpz9zd3337ubFp8AkkAA AkkAA3Lpxrsxbly6tuvaty8MlZ27FbubqJqGwgAgAgAgAgAgF6IiCYAIAICo wSyjMtzObuw73VuwiahtRHogmACACACACAXveJgJiPR5EoqG4bCAcKcShZRm c97dh7u9sImobqIbhteiCYBQSDYMBuG2wDIiG23Hobbcej+GLCrINo297MjP t3u6EWu9iIqqAGVNUqqAG/d9nKheVu3u7u7u7sKErj0AEegAj0AEfwNtJJJJ JLCQyDupwto7b3d1ZmZkKEtAAMMzLbgEzMuZStS22skCb+Xusvd53O7u7mZm ZNRtoAQJEpSlMASi/tyJ3tbmbu7mZmQjZqUpSkJkQEpSkTMn73tjj3b9vc9O 7mZmQ+2p7NTQAn75ICZsd973LhuV73fbu7u7uw5VB9EAAAA799ERy+XP21Vu 9g2AAAEjr3GOZlO5uG7t5H64nbeqA13Hcf027mZIHzbb+AkAArJu9c3Bij1T xge0qqzvPql8nvQCSQAN87Mz3k9m8/W+PrmxafAAAAAkkAAvzj7sx7l+Rkz1 rsTQB7ve96X2ZbbbbaDQAtVVR5IBznuwhYu6uzLu7uFimb9ERCBJAC9HoScR ACSsAAFOXdLsvdys1XdVFucEkgAAAI8ARAAAAT6AQs22tu913q13ZcNS8Zbb YExEeBABUQNtJgAAADzW1l3u5Wand3cOMAAALiPQ22AAAAAAEAXmlrLvdys1 O7u4ccy2sJK2222221IQrUgfQy5kzMzW5Wdvdzmavve9i4yp+iISE/fQkJ+j 76PkgAORkbXW97u5zNX3vexcZV1QgAAAAAAAAACKzVuit5u1mqXd3cODGgAB JEilKJmZmZq90et7XO83ztdffffGsxVVVVVX/Od/e2vxefr8o3AAAD6Ovdps u+fSjsq5+dvkZT1yDbSEl/G3czJA+aS+bcAAKybvShiyb1T1L1qqrlPTo6y3 pvNuAOAABU7ufn5y/wqPtnRIPvpJIANtwAkkACvEV3a57m5lrxmdqcY61JL2 zC7pFWkKYuEtsCtZPue9nczuvd+585vfbh9IpSSSSS0CACZBQkosAzugSs6+ y5KrrhxnWQAQAQATIKEgUkxKKLnPeMt3nvve7x19998aOIvmo/Utop9Mykpn jV0EJM6+7ckd2XDjdum23ERENtk6NNEgSlQlEIFNRt1Akzbxz3vHfOffGj7j a21VVVf8WnDvvsa6z33j3eJr77740c8AW0gBbSBLbbS2khCSW0JISBbFX7nv Grbr33j3eJr77740cXfoZmZAJMyyWrbbJIFtISW0gFtgBnOmt+zN+3493ia+ +++0cXxA7DMySELVvIMAEzMhAtpCQLVwtsndma9mb9vx7vE19999o4qqsknr VVqqv3+C/5JeBR77P56+T/jAAACR17tNl3jqUevZ+ybxlLVAbaQkv6bdzMkD 5pL5twAAL2cmrHvdnnVV7fXtVUR6cOst6bzbgDgAAVH3X56pnnru/tnRIPvp JIANtwAkkAAv0WXa57mxNb7tfZm+b57vE++3v45/i22yKqiqot5x7Nb9mb9v x7vH77e/jmwtpaqiqqrrPuGa291fu7+73j99vfxw4FpQhaKKKLFUU+5ozT3L vu++97rzn2+HRRYEUUUUWLJBd/cM0+y77vve8fvt7+OKq8VRIR+5c09y77vv e8dffffa5AYKQUhv7mtPcu+74c+HN779riGDSChEFIKQVOxJ9zubd5d93058 Ob337XJjJGRZJ6Jq8KnRVtbGXElVtvI9FXg50VbWRlxJvfftcA2QUgpNIN1s +ym/ufd65z9zvedAAAkdequ02XeOaX130U3TKeqMbaQkv427mZIHzSXzbgAB WTd6UMXZ+PV7u9NVVWZs9EKst6bzbgDgAAVN1e6X5JXf2nCQffSSQAbbgBJI ACnq5K3jMKLmhVdLYy4luut5URE+96PR+Fmup4VdWxlxJVdbz2+mImIkLzac 2KtrGvV3HJe/e+r36q96veGbXbNvpx5r1CUT7BwjaQtpaIipv7n3fZd+3efe 7elN857nvLlVVVVVp9zvPvZd+3ee73pa75z3PVVVRPW22r9z3N+y79vmL7ve jTXORyVVVVer1VVVd3VIoguy+nPwB55TcfJ96ZmZIJiJAJmcvbyfU57mRu7s I5znuefFqqIqqo952837Lv2/unb3tONx+l173q/VX79532DwySZ6TgcAAAJH XmuPdKzlWVH3kqSSkbaQkv427mZIHzSXzbgABWXmZslnDyou/eDMZXOqph6b E7292bzbgDgAAVH3XzqX5sMz7u6JB99JJABtuAEkgAOKXb43O/PVm9l8u49D C/NuOeqqqq9+7YzpdqN4AVftbjnj979+r3va8emXgpg3R7W5ne9HrjcNEbsL tzJ2szs6IgmJ9MevQ0WnXBuj3Nxz3vP9VfveqvzKH3denXBuj3Nxz9+/IprT r064N0e5uOePfvfvV73oYPftXXt3nec7Xnzz3PTYCkF7IFVVXvc1ze9XXd+7 znT7jz3PvKsNkWKjDmc5vurr7fr3nOnN89zxsEGAkn+n/K4fcT78fvv7nOfA AAH8gX7aWZtzb7vOW+ezxOalY24Nwbjb/pt39mfQPmkvm42226zcyynjYv0a vymU6qmL07nlXj2NuAOAABUe+fS1iDc+XcJM++kkgA23AABvLy30XPIvWJOm Cy6Wl3kU77uj0TMzOeAtd87vm8y9+3777h99973l2A2kG0ixr0xF7usFd113 kVc33dnvRMeUxMzmu6Bb3fr99w+1973lUUUV7S5MwzBzBeXv2sy97v1++4fa +97nlVV6ABbYSFqriYa6ugW7Sji7ynfdXbLYKEplJJJJJJJJJXERHqe7uNp3 V8Zjt33bvFxEQFAEzqUkzEzG8u/e7VO95ve5He997d8dtrWtRRRRtKiz/NAB zP372ZvX7ffvuY/ffe508Wl5aSApFAkRAkSb7rfl373Lz77hr7733RRTwQtK EgWlhCWluNgVJIoEIoH/Wf6fxv9z3tvvjN/z+N/0AAASBflfbcvc116V2+ye URKbbg3BuNv+zbv7M+gfNJfNxttt5LzpRgZ2V7uennVVDvTuWVePY24A4AAe iyl6S/JBmfd3RIPvpJIANtwAAby8uXXci9Yk5kurW3eQ7vcmFH6e9MRMe9BU iCQUkiwgPOdq+97u89fuZ275zR4IRQILABSEj2yS0bBDfOb6NTpGk7pJH6V+ 9PVX1MlVVZJPvJO6SU83vmta/Za442tpaqrnO+Vda97333My/ffdOqKooour bbbbwnHl6Lvfe/dyJyk973Y2wBPIh27i4+gqo+ilVHxlzWgNa051zq7t+73h vfD777j00qTag3VK75s93PKSTrD9Ve9+FR5XfNnu55Xkk6P0qqqqqqqqrykq ldgKeSzKSTqT1V+2rr1VVVWUe56p5ZXezyyRuAAAEgX7Vlu+29ZMnezfHny6 U22DcG42/427+zPoHzSXzcbbbdZMz0RgNVuIrV7FXVVQXlFVrJo24A4AAXUW 2vbIn3I3M+7uiUn30kkAG24AANtNb0l4hn5xu5mZ3NpdF2ybq8nog9ExEzG7 uhiWsTxLdpcnR737zRddVttGJbtUuTo9737qKKjy9dt5zn3TPvtat+39x71V VVWZqJ+CRYi08y66GXzFOVmUt2ZnZj8+n0dc1GT3dVdDLxyZWZO+85l+j3kp mtjMTvE0e7Wbhw6Nqqqq9XqqqqqqheorVfN6ewRuPm6Nv13VVVVVer3kjxrx A+PbiNvHzdf4cKqq9X79TJuPZJvjEjbx83R+/eo/nYzKWvPPZG4AAASBft8s uvS3Mei9nei5XKaUg3BtJf2SVzMnwfNJfNxtttq9rZ0bQ4Nqa7r1fnVUzvTo qx5pvNuAOAB4PRZVr2yZuhefd3RIPvpJIANtwAAbaebJec9qjat83xo+28t8 3R795PTbxt6ewRt4+bo9+9yM5tnr3vdZrfLekM0c5rvOdLznM0769kwgoCwe c5n3fuc6Ze9zTvj0x7QtFN2rWQLKSWxu3fc5GRWVlXPNndiUzMzwAQTLd2+7 k5E5mVdubMbwAAAHqiqrcnu897fQ3cq55sxvgIOAFtqDbILIXvfu797q/d7e b076nZBZPhXQW0gsMsKRJWYqqqqrWqqoqqqrWqqqqqqtaqqqsKyCyCyG+a39 z7uun3e3m9Jvqdn+EqqwWQWQWQWQWQe2Qz/N/eNEk9G2o452T0qqyV9ASZE3 FL8Kbnr5xl7dhx3ba9r7R1NTz1zqFaqiNDSvt8R9DQzMzMAAASSSQD330AAA AEzJJAoCSSSAAZmZmAAJJJIBoA0AkkkgEkkkkkkgAkklU3549uTFd3ySuojt rZye7bUm8ZG31du9+XspXO7tzM5dc1I5j5JeqkzdqkTs7m0d7ZmLZzjKWT1F 3tiDVfqWQkkEFrsx9e3uHJpJHVvs7bJnbN3cOn7x3vnrN01a83ePLfAMyNeh mZmYAADMzMwDMzMySSSAAa8ABJJJAAEkkkAkkkgAEkkkAAASSSQcAgAAAATM zMGgEkkkAAAZmZmAAEkkkAAAAAAOc5wAAAAJJJIABmZmYAAAAASSSQAABJJJ AAAAAAACSSSAAAAEklurdtSQJmZ3N5iXk5Iarez3WsroYrvq7rW9mZ3Mkku7 kk7u7uSSSXd3d0kkknd0e6dmTevd68YPS75r3b6K/ZlHWPt8a69RdvD3N6lu znc1zrV8/Jrd3ZvoO8FbytcZd7kpmS7mf1mffffffT6SSAb+73vQbud73am3 9buZmZmgSSJIG0ix+evOTsLW33PaXd0AbbbkhJJJAAAAEkkmZmZkBmZmYAHB JMzAAJJJIAAAAzMzMAASSSQAABJJJZJJKABJJJAJJJI2Sc3czNkkkm6Ekkne xu8BUSV3evuMzE3EteYzu7uAC75Vl2k93d6dmxXnZOl3dxCHmlKbI+2Q7uvd 2sle5TYLdJt4t3QPLLnpJ3D6umqOSekVbXgv2+BA/Ge55nE1qEkkkkikkkAA AzMzMkkkgN3d3+9JJMHwAAASSSQCSSSAASSSQADMzMwAAAAA3d3WZmYBmZmY AAkkkgAHvvoAAAAJJJIABJJJJJJIAAAAkkkgAEkkkAkkkgAAAABJJJAO36+0 Db8+b7Tu6w8urta7tp7u7XS8STk/He971bbbaHngAAEkkmnd3E3d3W5JJJJJ J6b/fu9VUvvXb8t++Q2238BJJM8k9vrVdrnYl6u70uN00pAcG420lczINwG3 AbbbbyXEIGvI9nWrvyqqgvadHem824A4A2/Rj6n7FXLepZAx/00m3D76SSAD bcAAMzLnIvb5LM1iV5WYq3E3FdqJ6P7/p9EKf3JCsgsgsgsgsgsPmC1KKgVA 2DxPe9/fc5vPrmfzv3bj6QWQWFUjCsgsgsgsgsgumTyK5ccU755nOe383R53 7tx9q221JWpBtkG2QtshWpBtJ1VZXEhzXee73f3x7Ls37tx9pIVqQrILIYTt KQUjAxF0PiAoEEmMhzr3fPu79y5s37tzxITnxC1dWsgpDlfvc+5vXuZ8fe7c 98yfgZpx+YYor4hbSFunGGKqqONUVFVURakK1IVbSFGpCtSFakPd7de5rn41 99dm/due+yyFZBZBZCFYAfc1b97nPd73enfu3OSTpFiEnyEWQUmQFIKQZUhp qQrUh73tnOcze9a+u/euPvczMy222gLWQUhWz70Sl70JL3oSUeinXcY853bu brtR12veLbIW0hWsgsgpDzILPwA1VEVpav+r/sufNVV3LVVVUcaqq1VVVVVV X32/16K/qv+av69ewUbbbgEkkzyVvc911V44d7cmZrZnNuRuDcbaSuZkG4Db gNttt0bLRwJLzyp5X5V7Dvd3ranX03m3AHAG36d3sDu7lsNx/3NJtw++kkgA 23AABtp+pdJb42q5c3zR15zW9e7rNPu89mKqqq/0ALVV1vea2EC1VVbJLRFX eri6gW1v03d70ZlG2GSQoMkCIVFVEBVFVVEQsiT5KAgb/OvPOezzzmjev3bj 6H6MFkQgyRgwQIwgwkYJCCkBBgCMgjCQiSF72/X9z377n2jev3bnv0gqSB5I LAolZBZBSUkjDR7xz92/r7nObN6/cuc8H4jFi1J8wuUxVVVVVXMwxVskLVVV Gkg5aQSQbbIoW0SQZMRzMxBRSyJlshbYT3jvf3v2eec0b1+7c5+/QO0kgOXM k7rWrasgsgsgpGMP1pBVkO/uHvveznrzm/l1+9c/ekFkFBAGT9aVVVRhWQWR ggsgsgpDTUqqqqqqvfPs7ePdZ99s1t9zMfeBBkWQWQUMUYqrWQWpCpCraVVV VVVWlKwUVVFVVV+725zeee7znN737uY9CqiqiQUVVgKoAqqqyRVgK85z5675 99rNd5mPQiAowFYCkGAQx5znydaZpzmu9zOkhCgpBSCJBSCkFILIKQUgpBSC kEQYgpBSCkFIKQUgwkhT7l3d8zd+/QjbbYBJJM9iT61dVuPI7/XsGbAAI3Bu NtJXMyDcBtwG2226ybEI72KVj8/H7Xav1qvY+9uxXk2NuAOANv07vZoLlXJd DcP4JDYffSSQAbbgAA20/NtyXDtvMzeRlV7Pd0rToXPb6CkFIKQUgpBSCkFI KQUgpBSCkFIKQUgpBSCjEikFIKQUgpBSCkFIKQUgpBSCjEikFIKQUgpBQEEg pBSCkFIKQUgpBSCkFIKQUgpBSCkFIKQUgpBSCyCkFIKQUgpBSCkFIKQUgggK QUgpBSCkFIKQUgpBSCkFIKQUgpBSH17eb+L71NffZ3Xu32iCkFBiCkFIKQUg pBSCkFIKQUgpBSCgxBSCkFIKQUgpBSCkFIKQUgpBSCkFIKQUgpD5qAgkFIKQ UgpBZBSCkFIKQUgpBSCkFIKQUgpBSCkFIKQUgpBSCktlFIKQUgSsCEUkhLCS HM5v4vk999n3X3bvUIEUJAUJIKECKEAUIEUCQZ7l5v4vnj99c+7y76BNgKQU gpBSCkFIKQUgpBSCkFIKQWcGSpBSCkFIKDEFIKQUgpBSCkFIKQUgpBSCkFIK QUgpBSCkFIKQUgpBSCkFIKQUgpBSCkFIKQUgpBSCkFIKQUgpBSCkFIKQUEiK QUgpDW+a39mre+u9XXe+7cACB5IKQUgpBSCkFIKQUgpBSCkFIKQUgpBSCkFI KMSKQUgpBSCkFIKQUgpBSCkFIKQUgpBSCkFIKQUgpBSCkFIKQUgpBSCkFIKQ UgpBSCkFIKQUBBIKQUgpB73u/szqZvWtPPu8vdEFILIKQUgpBSCkFIKQUgpB SCkFIKQUgpBSCkFIKRiKQUgpBSCkFIKQUgpBSCkFIKQUgpBSCkFIKQSCCkFI KQUgpBSCkFIKbRVVVVtqqqqqqttVVVVVVtqqqqqqttVVSVIKQUgpBSCkFIKQ UgpBSCkFIKQUgpBSCkFIxFIKQUgpBSCkFIKQUgpBSH2Z3uvufOtZ77Wtd57t 9ogpBSCkFIKQUgpBSCkFIKQUgpBSCkFIKQUgpBQEEgpBSCkFILFGQOMkDt7v 7vrvevszO89y/Tvv37ve/ek2Jyt3BbujhahZvFbuRbuxwvf3v3v378syBvXs bG224BJJM8k9vrrL2l2PYkt9volQoAEjcG420lczINwG3Abbbbyb6IZ0KDxv sXZW5K11VX0fs5p7ezYDAHAG36dlb3uFnUdseZvySjcPvpJIANtwAAbafr2S 0nuXe8FbuFLdwcMye/eqwF67PSku7264X0OSKQUgpBSCkP7ns9zjmfvn9ze9 3n7dr9cxUREkJAACSRMgAAAgEpAAABbS1o1bbbbVVFRVVVVFRVVFRVVUYqqq qqh73vufnWu/n7P3fs+1v93uftMgsgsgpBQiPxFILBAoyCMIjIIkPe993n6m 9+237P3ft61v93uZ+WQT/VZCjBFFEFWKAjIIwPyUaqjI/v33X+ute/nX2f3e c1rf7nc/aZBHyiDyW0C1V3dOKqqqqq5mGCCwrILJIfKqqIqvdevT9s1rvn66 /duZr93mfjFVVEVVUVVVUV21VVFVVVVd0okKlVVVVSSsgshu0hWQd7732v3j Wufm37m87r93uP6QWQXTJCF+733D941rnP3O/a1r93mfiCqKpBVVVgoQVGKK iKKqiqqqqqqiqSTvfaP3DWufnmta/d/d7n6AGlRVVRGqqqqqyvbXXxtm769Q httsAkkmeSe3+r2Usx7O7PZ6bxUebjbkjbSijSV3Y0hxtwG222yXa3ip+fUZ PVd17qqrxdnVyqZemwGAOAkvTejUj5yryO8a7Wf02xt/fAHwAAEkkAbaF7pl rnczfI/gqd/cur7XIzv79r9czMzIAgmSqqqqqqqqqqqqqqkCLHomfRHSdzN7 51PO232u9yvsWv5JSkkkCRMzJSqEkzMzMzIBVVQW222trbVVy1VVVVVW2qqq q4WquWrioqqqhA4Aoh7nVfDnXSb37Xhlfb9ER70bvRed86nXSf2q7d79v0RH vQ87l3yJx2n9ior77Po970evo7lvwZdJ/YqK++z6Pe9EbvZM/Bf1J3P1TX32 fAT4WAsZPMJA97O9/a13vxdcdft9/c/SAHkgtSFZBakH3tfcr+1n3799m+u9 d/f7B/d7ZC2yFtkLbPlVVEMyyFtkLbIW0gtThq0g2kLbaqqrmriqqqg3v732 z+3vXf75zfXe+/37iQ41kJPogAD76B99A++gR9FK9nac7iwvUk2224BJJM/J Pb9XspZlx73s9JKSx425I2xuPWkruxpDjbgNtttyot70/LueF7ZXu11Vbrhi be3s2AwBwEl6a+6a7CmDRuY4r5n9NuNv74A+AAAkkgDbQvdMtc9qtF6/5tz4 Wdb7n2tfvvzyyFtkLaEtshbZC2yFtkB99A++gR9Hmu5+u89+7XGuVv7v6cff QUgoRSChFkFJ+AIoAhWQWwYMJGFZ8qqqrkCW5393Vx579v2vsvc+1399+476 FtktWkhaqrYSWiYkswkiwAJczAJISQMxWLILILILIKQy9/dt579zPfZ26+13 9r9xkFA6RlaEigREhBGQBEkGVkPrZC2yFtIVrDIJKyGWkwAATkemYiJn3lEe g37qDT7jbNVm/YfTiuY9AWQUDsgDKyHshLaBbQC2wtskRkT6IiYkCPRVd98+ b+Nor5aXW9f3EQlL4kJbYSSSwqFABQARAAUABlaAAjJAQKyCygIyAIwYkg1k FoDD5bLeWrfve/fvvtGvs9yuezazt/s/ennQPRVUBBMzMzNymZVVRhbUYooo oooottFFDEJjiTIiCAoLczADRAQZJHNUDGTMshbSFakNe9+/fZnvu7zfr3Pt 9/fd/bZC2yFtgYrmXFVVVVVXMuKqqqqquZcVVVVURtxy2221EVURVVVVVVVV VVEVVRikO9/d57Wu53eb/dv2+/ufvcoFStSDb8kKn5gV+SFYFXcLKkPvb+71 zN+99m/3b9vv4/VkKhJqJIFYGJWFVRUUVVRERVb1T8c3n7utTJu48rH3SNtu ASSX7uUvrVpZ1y15Z6E/HOWASRtKKNJXdjSHG3AbbbbJa3vT2P8pd7P3aqqj ebaStmwGAOAkvTay+jQ9HZqivGfwbG398AfAAASSQBtrvbJa576q0Hu5H2d/ C1x99VqqqKiq/rcpVVVVAySM/Iqr1qqqqqqtpVVVVRNLlKqqqqqraVVVVVVW 0qqqqqiVkFCsUVG93rjmfvd+zf7t+339z79jpUPosUiumUB/AMmMgslgRZJG VkFkFkFkFgUSsg9zfczvP283+7ft9/c+/QGKCuqS21fxAiFRFVy0gsgsgtSF ay91rmZ939RX2q637L+9Mv4JmPbKQ8C9+qvtVP7PuiYm4QZnOb/d19vf3P3N /u3ev3PE9CEWKSRQJFAgQn7vc5b939vf7fM+3+3+8BCQigQIKEgyfs73fN5m +/vt/t9z7f79J4Tsjzmv3u61nv29+3ndfZ+/YKEkQQIoQIoSAG9+/czO/ft7 /b7n2/28Ak4ikFILIfv379+9v6vrlO8Xd8NtsAkkv3ddqbFlc+stUvLy3ql6 osbckbaUUaSu7GkONuA223zcq1XC9r86rD9iqqM1rGlls2AwBwEl6bldPNeR Wj455FenfyNjb++APgAAJJIA2137ZLXPbMzldkdV+KwuvqI96I96PZd7iV3d Vt3jy9o9HvRHrgyBfvtP5ut+7v32d0fZ7veQYhFCT8SqkWPza1sFZK4EliBB /e9pHnPur6jHFn1ZvvTHvZhPSq29rlpFHZnvR7oiV2vJVYJdPjF32fFVVVVV Ver6v2Os+u7Ed+5TevenpJCnWBQAawM9SFSCw735Hfed37lN67z1gh6EBGEG fccR3z3d+5d69zyegDFKwowrB0AZEBkGQ5zEd899v3LvXuUsM7JI1IBrWt/v sV5JO/qe1nLgaS+bbAz2+pZm3VJbmSTfN+zsc7E3JG2ko4Nu7ttIcbbaSSjZ 0y96o/LDM32flqqqe9HjSy2bAYA4CSqod3WoBK0fbtzr1P+Nv5t/fAHwAAEk kAbajZnoDmy76pV6I7+F3vf7fA9MZIYkOV9ulve93861ru+kFIKAnZIcrU+v e53fzrWu/ckhDnK/Jdc18q3daSav169fR33cP6fvlV3dVVVVVVUqq21VVVVV W22AFqqqqqrfsxVVVVVXMzFVVVVVfe3qn5zv7fd8brV/fXPKqqqr2Fq5aqBU g5JI7wltIW0hbSW5b3ut2Xndc2/XWtc+bwkNHTEgoHUqGmsFJZFAQBAAWEBA ZJ9rufULruubbTb2T0RNVk3Sgx25tSGXCqYpFPHDyhVafL94qv37973+K+x4 X7+Q6sn3EaSG2wM1ZtF22ri7yXlFO2+xNyRtpJDSV3aiQ4220klGzrrNZtQ9 dzLzP2KvGa1jSy2bAYA4CSqpu9GvIL5l6uy4r1n9Nsbf3wHj4AACSSANtJS7 KyBnOJllZLh9Tc2g2jzdK03k1FXQ8wbe8mByCkFIKCbfrzet6Nfbzn3M1mt0 VVUQ1t++3zVdfbzm+ZrNbOgEX/DArKQjJWFJEEkBSFpDe98531L3mc+rmc2d ngYyIVpEZIyVIWFpB7JFJMUJWQluAKQWYh4Ge8/apfvHte5currf4PEOJA/E YiRBUqUAYDAGSMCJASAw7nn366dd3n7dcz378EPArJCTm+Xz366de3mlv3vb h6QkPr1566de3mm+97xBIDCAb38Xvrjnt57dzPe9CQ6kgegyAFPHTZvmqc6X 5842YvRNF45nWvlV7KnrUWDnXN476nVNCt9NdZ1a12LXzjoxKqzVJrba3Lnq 2bdDMzMwAABJJJAPffQAAAATkkkDd0EkkkAAzMzMAASSSQAAABJJJAJJkkkm SQAAbnemee+GbmTzMyZvmbP24lvLX0Tu03Bdu+7KrPZmY+d1F6uYnEvKW36q Z0VJ1M7dAQl02sezSPcvy7O0M2XEpw9d+pYSSSs7y7rzXtbr5CSWndWdd93u d5U53vpCXZ5OTyZIzttzLQcZ+973oboAMzuZgGZmZkkkk0AAACSSSAAJJJIB JJJAAJJJIAAAkkkgAAAAABMzMw/wfPvvvvvvvpJJIAAAzMzMDd3d3d2SSSAA AAAAHOc4AAAAEkkkAAzMzMAAAAAJJJIAAAkkkgAAAAAABJJJAADd3d3QiSSj 9dPDwGZmxvMS8nJDvHSU9t9tZzzS5vjgWZncOSS7uSTu7u5JJJd1VVd3d3d1 VVhg8qtuwtvWCgNq5p9sxq7PVRPS9L3otmSR12a99ZNJ5jxUXq7cfFjjheUb oXPXhl57P6zPvvvvvp9JJJA393veg3czMzd1u755uszMzAEkkk3bZDmMFc2G M5IzMjkiSyQttttBJJJAAAAEkkmZmZkBmZmYAAkkkgAEkkkAAAAZmZmAAJJJ IAAAkkkskklBu7u6kkkAkkkbmZy3MyySSQCZiSOck0CWkrrHNmZnPdFmJ93d wEbzLA7swHu7qXbtd6r1x3MsD3Y6S2a3MzPczOfuD3xj9ne96qc9fwMz2d89 IoP3W/tme7vfPL+rWeMzDQAkkkgAAGZmZkkkkBu7u/ykkmD4AAAJJJIBJJJA AJJJIABmZmYAAAAAAZmZmAZmZmAAJJJIAB776AAAACSSSAASSSSSSSAAAAJJ JIABJJJAJJJIAAAAASSSQCZnf3Y5yRXFSkfd3d7MK7tzsutyLFyrF5LElJHh md73LbbbQ88AAAkkiEJJE3d3Rkkkkkknp/f/tf8P58FKq7Lqkv538/jSUbbA zq5d1Vy65MF5v3TEuxJSRtpKOH9gLuwbj+bbaSS+bO9mmVtL1Qy8z9irxmxC StzYDAHASXndzurVKG5XBYp1pnw2Nv74A+AAAkkgDbVy1bsyDc2q3Fm1vRPv KsyQ/n3uDbpxz9+/ad1vP379AD36xiM53T1xz9+3rb6/vvj36kspZdVgdvuq wJ73Kore37ZO7qtSft461W5egtVVaAnvkzi6rKz75d1Wv34/KqqqqJn3z7Lz V17297fsfdmoAeVVVVVVVVVVVVVVVVVVVVWAP3vrjnve+++cz3vACTzA1eMR QPu7KlX3ENZK5O452EbJ1V25d2NtgZ3cuVdtdns8ETceAQjbSUcP4Bd2Dcfz bbSSXzZ7pl7zJ6S79Mzvaqqpmt5EstzYDAHASQZkSrWh+hJL3n1rX82/m398 AfAAASSQBtr3R2ZAc2q3rV7mqMSrHOPe5X1y9zZIJUZ1bHXhakR3dt3JnURH vCda0SbuVUq911vWOX3cVUl9zce2Y9Ez610Qko9CSj0JKEkzdRJXZl3JndWz Me/E+w+7RpOvvu585z9vkmKo7+77eOrrfvb2373uYo7auz6VCZAT3fXU2vns 5yXfezlyTJIQAOVVVEKp3fXU2vns3vZrPcyuJAD6B98PvoH30g65Eu7Ca32Z 7OpDbYHdy3zHjGdWcqv1u5KgRZJIEAbbcP4fSfbmffSNjbbSSXzZ0y+J6b65 4vfYqqrxD4VubAYA4CSeZk7arV5ocZfTb5P5t/Nv74A+AAAkkgAA5Tsv0Whj m1WpZW3qiaXXuuSL37/GyiJh8ApBSF9ne46zNe/a53fOO99/c3zYEpYKQUE5 ecy3Tmve+53feO999zxNkifc7rmNdZrfvvfdz7OOb77niaIQYGDGLXl6Y8zN 3SVLHfX1rbIzKve2oiPS16YgxIb4c7ncTV1977n17efc3933fpogxEWKRVgr IAk+59zuXDM1v33Pu/XnPvu+7sk0xYoq85zhmd377mvu284/fd937SKsWT/C FJBP9bx79+/Z67zfP7num+c5993+7s0DAOc73uOrrfvudOfPOffd93ZPAIwR IJ+/xvX1bzL+uhc02ko22Bnduu9Vd9S/b6O4g5YQycoEAbbcP7j6T67++kQN ttJJfNnumbnEqoQvd9qqqvFOEO9mwGAOAknmZO2qT4HGX7cXJ/Nv5t/fAHwA AEkkAAHCzK9FgYpqu+V1l4omj0eA3Gd795sV1l5skR5W2kQ737zYPK296KI8 rbSId794/fv3pkmv15WKTspXd3nbXvRmbcAPu69tPGq3n0er0TMT7M3IAfX1 vXbwvezan3ojJj0xMT+iSj0RKUR70qZXveFvaBf1/Wzi26+u6+iIhJREpSA1 aBC1dmIXKQtpC2kH3b+zN/v3Oazw5l1+3z33PifiRDMpgIGZaOQIwSQGXKQt pkAQUNa1hC2kLb6HERPoQo9EpQRERdv5YBn33TbW/NunT/SJ9SQltkALaEb9 2aiwjrVgGSR5TERETMej0t9XwFfX9bO+dVSdONmJtfQOK0hCRtJGuL3939t+ 3++/fufffd5znO973duu+VJUvaUreE6UVFckgQBttw/h9J9uZ99I2NttJJfN nTL4iqX7jxte3s9CvXgu4ruj1TYo4A4CSeZk7apv3A05uLkfNv5t/fAHwAAE kkAAHMmY6jML10wpJG5k21vVTQ9uZmfx6I95WyQkpaA0VVd8z1t173317v2a d5vZ1VVWhbZFixPs7bc73uX553Na3renxCRYFGSSALJJ5ACcvrbr3vP2u+e7 y5e6fve/e9XpVBJKwuaOklyzp79dyqCSVkar2HJY4rqqqq0wku91dKWy/Vm9 zfwzZFRAUgoCfdXub31+1acuu5uQ31e53vX7SPM13NE5GDIH3Vud71+5u/Ve aZvv374Sy79krpyBpIbbAzuvdfe72bVLwpk4onZJAIA224fw+k+3M++kbG22 kkvmzsy9Z6U/x49m7c93nXrxrtMU2+mwbAHASTzMnb5e0a5QfJZjnw2Nv74A +AAAkkgAA46r07tb1m2nu1SXcl+03Zm/vKqqqqqqkVRugty/Xma7m9/MUVVF gpBRRteXOcd6TX2t8zfx8iiiJD5mKcutcdn2s1zW/jaKqIo7IW0g2kLaQ+uj lze3Z9TOZr7eyFtIW0LQUIsgsgsgsBXDl5rbsz7Ncz7Sqq75mKqrp4a1vXNn 2ta5r7SrsLRpI1VVcM+ObzfN1FmduZwAmYnIj76VEGQXeT2Oxc1eU3mbABHo AI9CAj0GBHoQEehII9BlLV2W9++dzms13XOdJaUhaUhaUhaUh3MMka9kmGYK KZm/tZvVub77nO943AHAzhezuLXri48dMoPV5kWySSQBttw+PpPtzPvpGxtt pDb+CdtE9K93jAvfS6F6VVYRckPM2dBttpHdxN3d7fL3S29gmWt7luw+AG39 8AfDbbbhJAAByndenY3iNZiWD9XfquNv1UKfWjESCrCIopwAtLhmZzg/fFzm ucFFFFFOA1FFFM5ma5wdmXOc39x5IFooooooophaU4BM+9MMTQ8ibuEY3meh eiY9++dGG7E05w13Nb+AEkyNCCwzmZzg7PrnM19Dmyo0TIpObuta58OOxznN bZakFIKQfqBaLS1VzmZzg598O9b5rZ99lq2W22lqqq/a4a1rh9o+PZ999+9v h3iru1V6Wqq9u/XWvHd/cVz777vt/e4qqu7bd1VVVBnqZ7MIq18Dg24A4Hd2 4VsLZ7rU1H5k7QCSANtuH8PpPtzPvpGxttpDb+Cc+9bn73B2Xtgyj11VWp3R N5mzoNttI7uMzM3ariYnBcWt7luw+AG398AfDbbbhJAABy7eVOxvF3XXe9W6 58d+OXe999vneKqru2SKqrv5fl7se9kHOc97mbkzkxCZn1VUyAGAKqTexlxy q7vevad4TAIn0R4EADj0ebbAACY96IBAAAVXVVbF3HVVb2YbmAAAAEAAAAAA AB1S29jLjlVVvVmPd0An0RAIKbbAAJBAAQAQBvoVdRVRtXGl3e9WEdmNw224 bZAEEAEAVDhttw237zhtuPQ4bbj0V1VWxdxyqq3qzcrJAAAAAAEgFVVXHru9 jOx5znN9ze9999VUAJiISAAr77eXPr7ffRyMy79693vo+iqoj0GtuPQxtx6G 23721VV6PRAAAABVVPu85zsZ2M5Uc57173MqqqgAALvPe97Mwzx3sXHVNLBq ODbgDgd3evHnaVqkWeFPBbf5k7YBJAG23D4+k+3M++kbG22kNv4NW2fvVPNs 8t86K3ZvRN5mnQbbaR3cZmZe7xHDU77e43YfADb++APhtttwkgAA142N4jf8 fa733tjkbl379fdzABv31VQACQAG2oEDXs3rxs+5rXva799UIA21Poj6QAAA V9nue56ORl5znvXudR6IkER6JBEeiQI9kREeeTVIkAAAcebbAFW8ZWRVzlVX dmbuWAkkkkt96IASRERHgElKSqedV0XFtvO7amZmZ6SWqvAlKrxW53b7et/H x85nvezu7QJSmEjaVITX0fRSpSmt2fXfOx2Psz3vffb7x7MuOEMuOBlxrWjV yQmYTMR5JTMe8kpUqcu5nnl5FxYdvU9LRJSpqgAANiIiKqubPud5kdjtV73n fc+ttt5DMzIAdITWtNqrbW3oP30+7nOx2O1Xvenm13sfKqQAZH0VVCV07qi9 lHrXJRg24A4Gc1nu6u2uuFxzzxvWfibnQCRANtuH8PpPtzPvpGxttpDb+DVs yfqrXdt8Iq3Dkm8zToNttI7uMzM1dHDC5H6PuStbuw+AG398AfDbbbhJAABr xsbxG+l33QfUvXmBDqqqqlVOps6eXlmSSu/Kq87kyQ+Psz3fO3cgIMgKEgh9 i+9771fp9rPd87TZCKAMxq2Wr8cdnva34+Psz3fO3aryWqqqttzivvfb8fT7 M93zqGgihCJUoAHOcPe198fT7M93zvdYLGzEzG1tx11fRcWHd07XSpVolCkR KlSICVKlSp6I9Ee8JtOPNE9HQOquLi9b7nObfSpUqViJQiQRIIkE48mOXEQQ hoiQUPumXbq4uL1vuc1sXfIiQRE5lwcy4uZmDmVuGY0a0a0a4EP9H+X382oj 3oj2Tz/H35/OZ+YV5GZRs6eVlmIcfnrq6k6qxL3Lsc2x7t8+3O2R32dwvKN6 bndZ13YlSjb9XuKqIBkkiSSSkkkkgASSSQDnOcAAAADMzMwABJJJAAJJJIAA kkkgAAACSSJSSSJJJd3d3KSSAAA1mY69WvSJVVRlVXN8shtddHarRdl7wjXH NzIk+jGV1PeuL1ZkTMY23aV90JvrqsusDHlSO6zMwNm68fP1JOSR8vbLxtHL MzufdzWIM5p6r7X17rwXdeNSMzuF2VlRrm+5uSSzbfdFOkkgAACS73dJAFJJ JJJJAAAAEkkkAAzMzMAzMzMAASSSQAABJJJDgEAAAABMzMw/v+ffffffffSS SQAABmZmYAAzMzMAAAAAAPffQAAAASSSQG7u7qSSQAAAAAkkkgAACSSSAAAA AAAEkkkAAAASST9ID333Mnvsk/QD8Yq33n8c5ZvU73sgHvvo73vepJJO963f d3d3VTObs3cVUmnsYOokU6S7fVs5a3yQaVlFu7zXumBAHmeUCsm5fSXcrEdi 2KpZz0mdIc3WvtvAqOA/UPt37758ADf2ZmYG7qSyHba9993e973ZJJJEkkkD bbu4gq5Wc/T0mbtm7vXkm+Sev2296ttttDMzMwAAAAkkkskklBJJJAAEkkkA AkkkgAAACSSSAAJJJIAABmZmZJJJAN3d1mZmAZmZmGyTm7mYJJJIJJEkkhJm Y37d26yN3fdMnXz193AewZDqoJu7s7e7qvLxMnrytS1Pab03mJJZg1W76qWR SGv9pY93dkl1PSFdzvJVdO6OSSdltrZV0bez1w3RQAGZmZgAACSSSSSSQG7u 7qSSQAAABmZmYBmZmYAAkkkgAEkkkAAAAAAJJJIBJJJAAEkkkAA5znAAAAAz MzMAASSSZmZmQAAABJJJAAJJJIBJJJAAAAACRJJSSSbuFarWaepbOZ3Fdlw2 13atHvJnvn7vt7239N73vcRy222h54AADMzMyd73p3ve9UAA/pfzP4nnuL1f Z998A24A4ES8uK3azjWei3tCjmdBrd3d3d0/kPu8598W7bbZsk+tnQWb6fvL sNrDJqoqs1LRq3vcRttpHdxmZmpKhD59p19i0jbaSkAINttuEkG22vHjY2jC 7/bj73e61JWzzl2REFFR8UV8UV98hRUfIbdVcRCFW9MyYIqm7x+4Pry6+Nm7 3nnXjn2rg40blwcy4OZcHMuCIiJARPg58dfXfTZu/d8+OGgKU4GYYUpTsCTM MERERERE102+uvGzd53z44KKqr2SElttVb3s9mvGzd93z7iqqqvQLVXvZ7ev F2bz3fOvdVeSWqqqq3Dr668bN5nu+d++VVVVVV5h19deNm8z3fO/fKqgqqqr 7Op5dePtm893z9rlVVtbbb4hDMy25mZkgH+j3jPyeZGdjlfvfp7nCZkA/jqm q+j75U1KU36r+W1933fepc/voDbgDgb1d7XW6XuEoc8wXt7qZO2SSEAAAk/q ST7cz76RsbbaEl83OfevD87/VfVTtneKq92zuXEbbaU7uMzM3uorrFy3X19i 0jbaSkAINttuEkG22vHh90AWcsz3bdNGzV57zr204lbxG4mYCSmNErRK1K20 rWpW5o96uvj743nu+dfbTiVvCy2BS0lKiixYsbo96uvj743nu+dfTjH6y0ll sp5zApjlsqOFL2SUrdm/V38bNX3fJ44jhKVFFFFFFGSTOcPZ7HfjnDee5741 yBRRRTtQISn4RMxLdyfF8yMyOV7PdjJjSClttpbS2lv9IGFR1Cfr+/HXuvxs 1f3x7nK+kJaqvtZctttrl944614dms99FZmCSZv4RAj4QIJnORdOMjkXefHP lVfT2YvAtpC2yWr3D7L6+2pq++OfKk/CMgJDm9+/PHw8/a5zne85z93o4Hd2 3lFmT0HPMM3XZOwCQgAAEn8kk+3M++kbG22hJfNxUmjNv3q8Xy2vb5VV87fc c4220p3cZmZvu7jI4Me8fr68UG20lIAQbbbcJINttHsiW+Yp319dmzV59p6a hyiQkR/oQpYD0g/WR6cd64bNXv2nnxEPzZHSo8Nvd9HZrO/af3YcbekIbzWr bbbbqEJJrpbTWxUNbbndMQCFM76PQDaS+96AElJMvRlJ9f1ZXu5eSej6KqgB M+j74WyQt9x8d1X2jO599ziqvYQ+zMzM/GZmAakZrWv1q7nP349uv7Uz2ffd 4voQtVfQhaqrSQCS2wIEJv3l5uvdTPZ993nQCSQ8gqIqrFkVVUUAVVARiqqq qqojJPkhrWYQUIKQUgpBSCkFIKQUGIKQUgpBSCkFIKRQGEQMzQFqqqqvpkAP sz0vMM9nvt94qqqqv6QzuI8yZ3O93w5CRn4EyDP0P8X9XxcrL31/x/c3Bt/w BwK93tu+LMksc8O881N1tkIAABJ/Ukn25n30jY220JL5ue5968CvxVJ3nd7H VXt+7H2nONttKd3GZmb3IyODoeyutKDbaSkAINttuEkG22pdyy+5tmVXpVZn s32ccf0MkOgAPe7ul7kzWd7vk3whGoZzXzfLa87gvaeYtAA+j3m3LESSCJAS SSSSrjVR1KYdu+p5kykpmdX3vAfnG2kAglCM+BNfVH019De1i3RAIASTAQA/ REQDYJJOq1zax+ewXtTmSkkqMzCGZ+1oGLIKQUgpBQHWswhcCPQgI9ABEAVv CpXXmuie2sWJJJfj331VQBdVSQfwze+/dY7yL7X73MyZ5MSvkhWQWQWH8krI LILJQgIVkO/e/au73Zr7P37fOEPAAKBAtKEAUgRArILILILILJ/OBFJExkFk PWyH77XtXdzRr9n79vnIfrV/ECFuEIIVkFkFgcVrVVVVVVWtVVVVVVfsuKqq qqqsJD377OOO6Z9VXjCANuAOG5L4szS4RJZvsU3XAhAAAJP6kk+3M++kbbbb V3d/ZmxWVKFvsaUkS9yawSKhqZyq2szgABxd1rM7dMifnks13tDUAAbcACSA A24DjbalTDuaLqpUWTuSp933XVVVVVVbaqqqqq/wBblqqqqqqttWBUgpB9SF tD6JMSCkPvby+3m9c2Pu75w6KRVYVIKQUh4kltAYFSH1pBtINpC2mz32X283 r23nnngC2wjekbSFtIW0hbSFtIW0C3ISd776++zevbe+eeAAtpCczOkLcwhm UhbYaCEYZlIW08RSCkFIKQUgpBSCkMzMIKQUgpBSCkFIKQUgpDMzAYgpBSCk FIKQUghIE37H29Z7Tzz9wIEtoSQtoAFtAIW0hA8ApBSCkFIKQUgpBSCkFisk zLCQ/EZIZlCBLaECW0IBbQkh8qqqovvX9f32b19t5+ec6QUNqqqrUGIKQUgp BSGtZhBSEhmUIBbQgS2gQ1qkLaQtpC2lq61maJbSFtIW0hbSFtIKQUgpBSGt ZhBSCkFIKQUgpDVpBSCkNazCCkFIKQUgpBRVVVWKQUgpDMzCCkNWkLaQtpC2 kLaQtpC2kLaQ1rWtELb+BgZlIW0hbSCjEikPeuX3M3r7b3zzmukG0hbSFtIW 0hbSFtIW0gpBSGtZhBRiRSCkFIKQUhmZhBSCkFIKQUgpBSCkFIZmYQUgpBSM RSCkFIZmYQUgpBSCkFIKQUgpBSGZmEFIKQUgpBSCGZrJoikFIKQUgpBSCkNa 1rRBSCkFILCKQUgpBSCkNa1rRBSCkFIKQUgpBSCkFIa1rWpBSCkFIKDEFIKQ 725e/ZvX23nXmc6QUgpBSCkFIKQUgpBSGta1ogpBSCkFIKQUBmtazRBSCkFI KQUgoMQ1rWtEFIKQUgpBSCkFIKQUhrWtaIKQUgpBSCkFIKQUgpDWta0QUgpB SCkFIKQUgpBSGta1ogpGIpBSCkFIKQuta0QUgpBSCkFIKQUgpBSGZmEFIKQU gggKQUhnda0QUgpBSCkFIKQUgpBYeYM17Ne+u992990+70MAUgpBSCkFIKQz MwgpBSCkFIKQUgpBSCkMz7WiCkFIKQUgpBSCkFIKQ1rWtEFIKQUgpBSCkFIK QUhmta0QUjEUgpBSCkFIZrWtEFIKQUgpBSCkFImtazQoIyTWmlQSFRA9VvcR d1F7txq2PQko9CSj0JKPQko9Gltx6Gxy49CbcOPQ02nHoYH73vC333TWR8bV 4RSA24A4YosordEpgN+3W9m6ASQAACT+SSfbmffSNgADSS+bnufXmHsd6Ova 8u8516+ppHDgAA4u61me7S5vPJr31G3a6NwBtwAJIADbgONtqdcF3cXVKR33 Lf153DO87tIazWaQDM1mkMbbbahbWY9CSmY9DETHoBjmPQ9s3FVZVrdIva2p j0Nscx6Lptx6G23HoBtx6Ewj0AEegAj0BrZPoiWEegeG6qratbpCWR6FaQv2 YQy0hbQLf6FqrhMICGZcixA7v7O+u9+39fewt4QtsPSAgwcykLaQtpC2kLaQ tpC2yYzMpDfe81313vW/u9wt5A4smZkMYZlIW0he0xk8CgKAsNaw06BYIGtU 0kMxQTAKACDb7adr67+ye4hbsOY8CgmPRmUxIZlMSGZTGQzLiQzLiQrUh3Li QrUh3vM99zH77fnl97D2s9IZbIW2QbzJDLmSFuZIZmZIOZgS24kMzD3o13b3 OMwqMzuIvjvegA96AD3oSXvDbIW2QbYBbZC2yDbIfe39rv3s++zf3Pew97GB 5zKGKqqquOOKqqqqquZTFYGZTFVVVVVXMswVVVh8a1kwjA0ZrJjAzKBtWXKR 59Rt8XZW5PcRy6I8koiIYER5JejwGSGZmT8ATWtazMxMzJoCCkCMzLIdx+J9 VvWMBt/AOG7aqVul80Keg15bHpugEkAAAk/kkn25n30jYAA0kvm57n15h7zv aRVe15e5qzOXXVrTggAA4u61mV2nrvXz8bLua9rFzbgDbgASQAG3AcbbUqe3 FrvruDM7sbneOnH3RHkgiPAER4A9MRPogAiPAER4AiPAER5IPeiQPejVxlUZ d3zneI9zshbZbbbbZLbIW2Qtsg2yCyF7rO79n32/cfew92Aqqqqqqoq+tVVA WQbZC2z+AUg/oKIgLIrmrIW2flVWFykMcy4qoGrr7X7Ps++3+4/v2HfekFkF kFkVViyCyCyHPezNbze/cfew7yQWQWQ1bINshbZC2yFtkLbIW2Q/zd7nP3P2 vvv35/ezz7XZBtkPWyDbIW2QuZkhlvCGa1rRtWTeta0KqqiKjrWsJ/ACkjP3 79v9ul3WPl9xHddx6ACIjphtkRMeBe+j0RCBmdyQy5gGgkGa1rJDMzJDMzJD Mw96Lj5fXRVVr5b8Rx1+9EgR76PR6fQ2vQEkSXLINpDJICFyyYhmWQbZBZDL ZD9+/Y6+zZvf7Xr79lfbkFA2qjUKiqqI2lVVVVVVtKqqqqqraVVVVVVW0qqq jCsoiqqqjWQWfhA96+3+z3333d+v37D2wiwNwUg1KwKyCwVVgshVfv3vt4Cr 27lWfRgDb+AcOzcUeaZ3ORd3u0wm6AQgAAEn9SSfbmffSNgADSS+bn7n15hV Y/ZnsR7nl3nI186t73BAABxd1rMrtPWvRSjVr0UAAbcACSAA24Djbayj27Fz vP125Teffffc32/ew9uQUn8CwEYJWQWGKqqrWqqqqqqtaqqqqqq1qqqqqFZB ZBZDfvZ7f7N73+129/Ye3ILILILILILILAVV/E97Pb/Zub3+139+p7U/CkFE UKyCyCyCyCyCwVVh719r9mbm7+139+p7Ugsgsgsgsgsgsgsgsgsh93uZr2Zu b9rnvU9qQWQWQWQWQ/S0owKyCyCw9ElZD3vZvf7M+K/fd/frx92QWQWQWQWQ WQWQWQWQWQ6d7n2/Znx9ftc96+XUgslnVzKQtoVrBWtVVYoVlQKyCyChL3M7 fZmbm89z3qc7ILILILILIKQ2NZBZB7ZCshe5nb7Nze/ue9T3ZNiaVxqqqqqq rWqqqqqqtaqqqqqq1sPwmYq6VVVVVvriqqqqqrjVVVVVVW817R7f7N81T77X 7vqc7tVf0lqqqquNVVVVVVa1VVVVRVa1VVVVVVrUhWQWVArILILJKeznfabr 9z79+73nHAHD132KpTdFdgn0nA/PobDugDG3AAk/kkn25n30jYAADbfwHufX mHnVWykdtGXeNrFVpPggAA4u61mbfcXOVy67R7VigwBqNtuEABtwAgAHVPey bpb9d+zrONzF7rxBL9xVUrAWQWQWQWQWQWQ33vXTd+1mbN37nvU12QWQWQWQ WBuCkFtLH0Qxe9CS96EqPegA96MxTtc0VFG9e8RND96AD3oAPegA96AD3oAP egA96AD3oAPegAiPVmRt9YVFK67eUWrde9BmZIZlUDEzKsmKmZVIW1SYqpmV YWJiq5jcVVVVVVcyhjJmWQ+73ku/fV2bz7Xveo71IW2RVWLILILILJiFQ4yf Xhj7ftXNzefb571P9P25BZ+VUlZBZBZBZBZDdsir/kfd/fjb/c9q/a+Pta3z +/U3qLBVIKRDHfOG3u/azNm79t771HaqqqugtsJVCnMgjFtc6bLi1vcov3vR GTFRmRvSrt3mbz4+1z3qYQ9ARh1herq3YW1vTWvGXOq0DAG3AHD2vUrrvOY/ OtxynkaFqNc7oAxtwAJP6kk+3M++kbAAAbb+A/c+vMPeVqzJj7pMu8BYqtJ9 CAADi7rWevqqLKWF45qwUAAajbbhAAbcAIAB1STr7pcu8qvVkjvWd1w1726c +VVVe2qrl/u92/hOZ+57Pm8jO+1R+k9iSST6IbbcAHvDbfvMElASndjkx+7+ zO3N3kZzf2omuglKUgATPTud5UbPt7u9usjK32I6mcJmZpbYW2Wqpzhp933N 5vPi533qfVVVVVVX745qnu+1vLx4c1331PqqqqqzMzPE9nJ9vu8rsdXs+9UV c0AAAOxFVQmu5T3fXyudiV77yKuaAAAAE+nMjaR31XXI433kZc0AAABcVVVH vu3jZvPd5XY69vkZpzwZmZJmGNa1tpWttLbbS7/mHv8uNuaby5125bdddbV1 xwMLF92DhXHbfdbCuWFMpla6hQv8LMwvzfnx5+qQd+1UnkJN8+jfbnutbkuf kkknmPPDd26EkkkAAASSSQDnOcAAAADMzMwABJJJAAJJJIAAkkkgAAACSSSB Ikkl3d3cpJIAAHmd3dxVGm8X5bup9w9D2NbpFNu4qnrfdurvPdqVfa/TtfB7 fFaer1WsymcJatl7k0k3F175yn0ru9mLsv19ychstKu2+1BKSSGkkiVSSdPE o9SDtOrvy3ckUdLafjtSnc43fbmczNm6AAJJn7MG7skkkkkkgAAACSSSAAZm ZmAZmZmAAJJJNr0AAEkkkAAAAAAJmZmH93z77777776SSSAAAMzMzAAGZmZg AAAAAB776AAAACSSSAASSSQAAAAAkkkgAACSSSAAN3d3d3QAABJJJAAD8kkk kkSSV0lLAu7vu64vWSLWy9rq61MCJsp5bbu83u7kl3c22+u7u7bbd9JJJ3ad uprjvO+WrPPl2ZtVJt3+C/LxlSyCjXGTGZcHZvO6dNnTlbjrlhWXki3N3V1P syO8Ha8dU27J6gzea7I9qJT9z3+68+++3758ADXkkkg3dRZC1SvU3u7uySSS JJJKSAHljzy007JB728ncZ2e2Q0JN2223RmZmYAAAASSSWSSSgkkkgACSSSA ASSSQAAABJJJAAEkkkAAAzMzMkkkgAGZmZgGZmZm3O7G+7mkklAkk1JJAizA KoG3frw5N13abu711VV2dya9JF2XbbbqqhukszMZFeK0buLkZi182NLtz213 e5Qim5JHu7pJdT0e7adbJVd3dHJJ7Z5pdayuc9r3xeXy7JKADMzMwAABJJJJ JJIDd3d/l9bbZ998AAAGZmZgGZmZgACSSSAASSTBu7ugAAAASSSQCSSSAAJJ JIABznOAAAABmZmYAAkkkzMzMgAAACSSSAASSSQCSSSAAAAAEkkkA73m+dne d33l9kudq9r3qezvGdUvpmnC9p7HuQg222yR54AADMzMyXzMzDve97aASSSf 4JvvZ+/wt9v+QyFdRNq/67+kwG3/QDh7c7rrVfZTrdUUg70RO4cGNuABJ/dJ J9uZ99I2AAA238B7n15mBm3dvHbvAy7wMV6qxc+CAADi7rWeztolv1ueb7L0 6P4+kg/m238fAA24AQADuU9dKq1JJzt67kq4la94gciSoBJJAABPbyke76+X fY63vvVFXNACUiBAgQlKednZ3vu8u+x1zZ96jNOW2222vSFtIW0hbSFLdKqC quZmKqiqqrzlTv3u71r4+vPvewzWd0KqkzKQtpC2haqrltC2gc4d37v2b+23 O/fe9o1vNktoWqqqqrzPc+zC3Nm3fc4dEzMzMzMykkkkksz3V18W5iytm+5w 6kSSSSSSsAAAAAZf3ue76u3Pa3sd964vk0AAAAAiAMjCY6ufFubNu+5w6kSS SSSSAAHcmj3Pc9Xbt29vvvXF8mgAAAB7J7ja5u5ye1727u7mZ7dHD253ar71 O8zhrukJmvtHBjbgASfSSfbmffSNgAANt/Ae59fsx6e3XlJDLvE75VdpPggA A4u61nmtojw9eK1uWHR/H0kH822/j4AG3ACAAdPPldl3qmZa29dlXUoraV71 Q7kSSSStqqqrzq2nte17M+X7N9fve0a2qqqqr6BbSFtIez3tn1+397ld/c37 2tdVVVVVVecpq+373K719z73ta2qqqqqqlbzmPte99Xee9491VVVVVVu+c0+ +8a3Xen73vd+VVVVXttuSTMzN2on3e+m+pXfve9zUnflUAH0RHwAK1V51o+1 v5+Xeub97PbVVVVVZmXcmah7nvd7SZ7zO+9W86fRMgACPvvgAROSn1+91Mzy 8571e50AK3JIXHMhccaNa1rWBKjdX3Ps56iuJFAGo21GVEqd76s9XTJqBdBW jTdjbTSkACT6ST7cz76RsAABtv4D921bKr1qssrrGXeD6le2kwjbbBxtK3nt WyY6PWuLzbenR/H0kH8238/m222wAgAHVNr3dBu79tCErqq7QrefXkpr0Egv RABCSiI8koSCAUJL3veSUJWyerq5TPK6VPejrkPRHgEksASQCQAABMe95THo iI82Tz7a4mZurv3vd+UJIQMQkAKgEIVCAKEJA8hBSCkFIKQUgpBSCkFIKQUg pBSCkMtAJIHcoAQgoEAkWBAhFkgAPAgmLrXt+qu9dzfva8ciqqq21Ttr72u+ qbeFdz6MmZmZmZmYyKCefbymKehW9XZ6KIpBSCyQFCwvOY+17518OuZv3te+ /0EgwPg7p/a/bdfh13N/v2vfuKfE5FVWpuEqBKFZFGd19f2v3zr4dczf79r3 yurbbbf0gTMzAiQEAMzMMzLbbfvfe1P7vE1+ibZv73q6iBEACSQAs423qqL0 q3oiA1G2ozL2+Wev1cXrmxdzzzNjbTSkACT+SSfbmffSNgAANt/Ae7czKZV0 iuT0vLvB+VLcSYRttg42lbz2rXap+6VuZNcjj+kkg/m2/n82222AEAAVTZM8 3rhd3W1FPV2Jq67nvb69SSAACZmci/VPuX7Xw63mue933VV+CS1QgqqyJF8d t9r7743rea973fdWEiwIqyEH6ELaE3DAgZYW0LJC7C33bT2u9+N63mve933V VVVX4IFtCSFr2697Lre/nWfFu8373vc5W1Vbaqqr9nve3dfbc31uXnt+9r6q q0CFtAlqqtlvOazPb9u95WLV7ns9gAAMiKqgA5tT6+ei8m6qfb7PYAAI+ABl VWqXrOu6jcuk+ruvUkkkR4BJEAEegA9Ez6ADwBEAEe0xnXVQs6xPq7r1AAB9 EREQB98PogffR9nKm+F11R6wAajbUZl+vc5Z6/VpnjekXPq15NImny5yABJ9 JJ9uZ99I2AAA238B7t9d0yr215B2XeNeFtpMI22wcbSt57cGqfr6FVeaPRao fSSQfzbfz+bbbbACAAdU9pa8pAu69VXuRTvPZ2l7z2ewcmqqPqqgAAI2PqoJ 9MzMzM6p0Ou6hdSx7XZ2JbHoAIA2IiKqhAAAvT3OcjeXec933sx/D4zMtttq qqhAV9239rezu9ftft/ue4qqquSQlzG363LcAD7ty+39rZ9rvu+5jzn2+7XY AWqq9ktpPxCZlAQrAWAiT73eaz93mtmfvv28d99vu1gpFVVXdq9At7zeZ777 WzPunu+5jz77fdqqqq7AhbQJauASW9AO8+1nt/a2Z09z32P3vt92qs8qYPjg SayyExgfiU/e13Ob5rZnv3N/sv3vt936r6QGqq2rbAMlakl3VhdY6g7N3sJy rravemV9EegQkv3713VVVVVVU94n33JfV21OSZAajbUZl3ndSWKtpGYnHagt sRk5tpc5AAk/kkn25n30jYAACS+bfu9QXbhlHhR9t3g5iq0gI22wcbSt57Vs 5a7XVfap16KH0kkH8kvl8o222AEAA9JXuun3YlAM6+dQXu7HYTl3W1uTMzkR 73kqG4S6pC1VVedd5nud1sz3ee+x+99vu/lVVVVBVd85l97mt546c99j977f d/OrV6ELVXkAMIKQWAimZgWsk/gGVder++7redOH7v7mnm/t938r0JLbAC2g AFq/YABsHWrcxzMzMzvbfb66OjIzbJvrraW4AAAAYRERDltRERBIU22oiIiC QURERBINtv99+Dpn69a6LvlX1PGssURERBIAp970QpSS/eBMzMyPfRPoVl/q 9Ge0jvf3ebzZmaBMiZAGx6uXtZHozYd77vN40BMRCUzIQFUjsMzMAzMwFpIM Ons+33Ozxzxfvvfb7vuXZC5mEMzMkzM/xANJBSDMRM/XdgADM9H7nu9rsfoz Yd7+7zeasBVVwlrUv1haWW2Wn2zXOJ32tjcBqNtRmXed1K1SrfIvE47Q80yz NkcsklAH9Yfd73v3xu7u7u7u236t+3ateoq01eU9Xuy8ERdicGklAcAbszXt KlluaqN0sQucPpJJIfADfzbbbYAQAD0le7cBXcr0cGbj8eIacvN67zqfNStS sqV5lMalSty4kqVKlbHFvrfRsb0ZIsp7mzaUL8QiQ96T8YZSFLSFLSFLrCGX Lbbf3ne+b39rx+O/jm7rOfa791+S3AwxxK1K1ltK1K22VifdPa+3v7XV8d9x MvN67ybYpM/TMTMaQIECBNan13e92ePRvvmZy+xnECB9AiExImRMiZITLY95 EzBd7TXXjy3iXRvRk6zdrI2ZpKZSq21rWta1urjiELbWskn3cfa9r2ONjd6M kWU9zZuVKmJmJmEsBAgEAAARupdeOsfTS3e9pO0827AAgAgAAACACAAADMS6 +dY47Y3vLMp683AAAAgABAIAAAAA3Rc8dY+2N6MkWU9zcwA5ttfeiXLbiI8O WwgEAkgkABRB9nus2qzM7dy/szL7Ny77vVvrXXvF5zctZTynoaKW+5pySSST +SSfbu799IAAADb+bft2rVq8Kt80vPLwbu2utMcSSgOAN6lwk1zvabW3l9Oa FF9JJJD4Ab+bbbbACAAekr924HLM9fLCzeNh4nnWW+0Y3mYKIgkFEEgvAEeg kFHiQAAAA/Hve7hfZrrXH3Rv0ZIsp7m5gAClJJSkkAEzvNe7fOdv07G+jJpn b3N6PVVAAGREDbSSSUJKEiu3FeVlY4zo3oyRZT3IXWiACACACACACACAUAEA OdgpvM6oXRveWZT2cjrCEe8EB6DMM+kApUytLopmNLaXmXu13zXPaPbfd9L3 u9HDVpbS2ltL0zDMAzDMACCVKShcue9VVfa+ju5RhE5V+NiPeXlRZSyQpRE3 ClERERR37nbvv3Pa95PPqcx5vvDSKKKKOqW0tpbS/eb41XV3z3o6eUYTlash pQriAgESEQEBEBAlCShTEzJLh9s26rnvR08oWZVolKgEAQgPe9AAAAAABden O3q3HOTAajbUZVdyV9W8Xif8f2MWWWjYvqfa3IAST6ST7d3fvpAAAAbfzb9m bidWL2aq263Xgt8dt8hxJKA4A2lp3JdLb5G2s1oUf0kkkPgBv5tttsAIAB6Z L/d2BzzH1GUYNbKPSoosxWldABICQSAkABIQOPx6PRDfUCJmD58k6r56vo+n lGE5c5rAAAkESCJBEgr96IhptNptEguCGtadVzNOjp5RROXKzUSCJBEgxy2x y2xy2yACACACiKrOTuu2d6eUXBN2t0CZAAAAAfvNtv3obbcehtNr3obbfo2q qq9blKt5F1r1b08oyCcuzNRIIkEYm1CQQAQATIKElCSSjM3qq63pjenlCuJm 73XGyCJBEgiQRIIS0AAACYDMrsrKzd6eUK4mbrMl5MeOY4YMAAAAkJmZmYic y66rozZjenr9bqmjPVXvzl3V3d9eo6byehKl9WOqa63MzM7oIBIgRKETMqEj tvcWVlY9XfPqXgvPt80Ntp64t6TWta0QczWiGq249CQR6AUeirh5eHbu9u5f ZmX2bMurvmfvO/s3krzctnmec3eWR7ZJKAP5D7d3fvpAAAAbfzb9u1admOi8 8y9a8dlbnIUSSgOANpadyXupR8t01ocf0kkkPgBv5tttsAIAB6Qu69t4Xyqz Krbve77m+nyGR43MrY+gR9Aj6BR6LObj0A249Dbbj0JtuAElcRCzst3ax7vT yhbHJdec+iZmJiZAI9ABHoAI9ABHoAI9ABHoAI9ABHoAI9Eq+23W5Bu9PJZH JbfbddHoG249AxuPRLbcegG3Hobbcehttx6G23HoTbcehAe9KqqqlxjesMco u14u3IbJVVVVVVVVVKuta1pVVVVVXWta0qqqooosVda1mkUUUUUUUUXNazSK KLFUUUUXNazSKLFVVdW22nN70Q1rWtELrWtEMzWtG1RFFG5q5t09yDd6eSzk tvntdHTERVVTj0NtsmYlWRJq61qGRFnN5veyG973vZDe973shuqqq94mZmao qqj0VVVVR6FAXt08yN3p5K84NyY53XR6G2370NsiACACIAJmDLoICZlwImZZ JbYQ0XXu/b1znXvn1v3uZl5w9uwC2kltIeQQRkcyzIyGZQltCW5gTMzAmZZD bmUMjJrPvblPMe709ob3As1dU+9CkFEeSXvRUgoJbQltCW2Q/nMoS2yFW2Q7 v3N5+/b2+7f5zfT49rzd9xEfD76LmqRHwiPjdwI5lwCkFIKQUg3MuFIKQUGI KQUgo1czJDFzMCZmXAntXXblve7eJ5LOwnZzeqkR6QREgiJBEFczAmZlyQd2 61gTMy4Ecy4Ecy570ft99HR++jcghSvrqsdKfTzVX8ybNrLd7n83M9t1i7uy /c3CSm/Y9kDVaOrq6Gdk9vf0WSeeZn4rd0EkkkAAASSSQDnOcAA0AaCSSSAA JJJIABJJJAAMzMzAAAACSSSAiSSTSSSckG223Gd7u7vAbp6X1d3Pq3jE7txS TG8e+WOU2ySDbylmbmWbc49MTsWXcT49XZVGPdqzw+zurnfYN45JZJs3Mxeu e88zN0PbcbW96g9Wku5JLkcq9zerdnezluTzj2s9hE1Gl7enT16kMSIB2NLE hIJkkkgAEkz9mDd2SSSSSSQACnoASSSQACSSSASSSQABJJJAAAMzMzAAAAAA DO970f0+ffffffffSSSQAABmZmYAAkkkgAAAAAB776AAAACSSSAASSSQAAAA AkkkgAAGZmZgAD8AAAAAzMzMAAAAJJJ+kaOe+5i406akCVUreulWdtrO7d3l JJJd3JN3d2JJJbu7qAA7u7L6a1WLFXbtbQr3w6LtDuZzO2lNraFnEXKqaMGX qqczKyQv3d0wne571yW6fTz7OivMdM3tovtFzJ3913+z7n2N++fAAJJJBu6k k/cDbdepm7u6SSSRJJJSNt96jXOEi8095mVlsZmyZWt3d3QkkkgAAADMzMyS SSASSSQADMzMwABJJJAAAAEkkkAAzMzMAAASSSZJJJgAEkkkAkkkm3O7G+7u 7u7nCSd3d3a6uBtAeoXK8cvO7uFMtzV3cAp1enmbV2G7u6EQk7qrmqqeZDBF Oz1rSsNbaSvq12utOTEbY+Hu7pH5ZMozAN51Xd3DJJvtk8eMzcy97vnnLFye RJKACSSSAAAJJJJJJJAbu7v8vrbbPvvgAAAkkkgEkkkAASSSQACSSSAAAAAA EkkkAkkkgAGZmZgADnOc3d3d3dAAAkkkgAaSSZLJJJQAAAMzMzAAEkkkAkkk gAAAADMzMwDnHPHvodsfRdxCVdLpeyZFdIU5JCqY8N6N222h54AACSSSXMzM O973tkkkkkkkl/vfv0o7+T72cAffNttwAA5553M97+85PfFXu98/bfczHqSS gD4T7d3fvpAAD6SQBtv27Xm9q8zPKnbFRl8P24uQ4u6DUcG0tIk/NaytoTvO 161J9JJJD4Ab+aSSQwIAB6pKg3bL7St3l7m8nit07Ezk+TuVKI+lII1oRzLk grbIZlcoS1oRrQipXomY8SiV70Jbe83W9sNm6lblSp6M1tCNaEa0g1o1plxz LmSFth8oiojmYYIqIqIuZZDXea77m9e97Ws72/adNfdzshmZh8iqqIZllBSC s8sS5ZC2yFtA8zDLIfYZkhmGHvQoS97ImIrX25TztbN1W8VST2VD2ImURQpb Ia1o1qQpbIawzJClspbckAgPeCA96MdZd7xT7hHbqblyp7YNkMwzJClshS2Q pbIUtm1ZMMshdOZIZhmSGYZh1VEVEVFN6132b133cve3enTX3nxrp5RFVVVH WjWGlQOG9m9GowNaNZIZhmSFLZClsgEB7yhJQll3VdpTvF26opy0uzuiu8oV kKWyFLZC7cyQuOZIXHMkLjmSCJD3oRIe9E1jztKuu1s3UrTQl3cpfSFxzJC4 5khccyBpVzTrU0rJmnWSFxzJC45gGmYa1khrWtaNKqqIrMxPZ2crKztCM3Ur iWufTxXe9AB6OiJQQSKa1rUhmZgdFgk1rWSGZmSGYHvQAe9AB70AHvRNV14t KvtgkzdSuHV9oe65IW0P8iCkFIKQUgpBSCyYa1qBlttpbbZClshS2QpbJ76/ p9q5ONtv4AAyq7lSrq9OverXHxvn7l9vceJJKAP5D7ve9++N3d3d+EAbb9s6 /B1XV5tPa4nUpe8/WtQou6RqODfYbvP3J1lPledq1on0kkkPgBv5pJJDAgAH pK924HXbu1tmcw3d53tvB1fa69N5IUtkLbIW2QtshbQKojbKxYJaVVVgqW1A bc+vuO2Wnt6SbuqxrnGvEkoiOlR6fRM+mBtkLbIW2QtshbZC2w+MzN+775+u u97jne9vxl1nva9e7DMzCKqrmYYqqqqqrmYYqqqiGZZC2yFtkKl70AHvQAe9 E9vVLT7N1yzdVjXOOO2QtshbZC2yFthbmWBMcyySY5mYAB29U0n2YTrndZbp c1vYASAkkrAAHt9etrnc2prN12rev31e4BJ6IVQAAqpzebtbfd30M9pXI9bb AAAAGx3LzK9fc33pra1zt8q8q4+JmZmZmZwARPbznsr19z3qnd952sVtYAAA HwMvc3J8vfe9b3vO1itroAA+iB99A+/eszP372Zme9+ujmQGNttwAAyq7ura 5vvbpOuefo3nO5viSSgD4Pu97376QAA+kkAbb9m+83tXVq32F0y+H61qFF3S NRwb7Dd5+5frpe3ryYc0dH9JJJD4Ab+aSSQwIABMu5Xu7A67gZnH1133vL3t 0Zu5zPpC2yFtkLaBbe5mZ2FYLAZVXWswzMwcwuGXB1zu9evae3sdvcqLRe5U FeltwNoiYahQlFLS/0g5hcJI5l+kBuNLSvud97t/Z9znfavfevxnLm+aKIiI ooooooqq914+qt7uaK2tTgxFkxMxMxyUJKMAgAgAJBP0RESxXs7U8nfaaddc 4nIdueRf76IVNTH0R8kACBAhcR9CMT3fnPydfZz52+InIVOajKAPRAB70ahr WtEtuJbmfoZmZAFIKJMygW2Bc7v7nH6ud/fq9VeRPF3PbAAAkklQCeVjW3NK q3DTn0EXNOcaSmYmRYqqv6QC2mt87391/XXuc7r9r7XjODvrq7mZmZmVCAj0 AEeAEY+kFLbm063tfO30E5CraztyNbIURCSEoiABJpTVV66/xcnUsobn3zbb AADC7SVbWdeues7TKRa3pUaSckkkk/qST7d3fvpAAD6SQBtv2b5vaurpVt6Z SdnP24uQ4u6DUcG+w3efuSrK3Ox6uaJ9JJJD4Ab+aSSQwIABMu47uksO67fZ iovu3tfM6FNpvZ2pnzmeSSlYJKUHdUO51X33o85WzTjmcbwCSZmZH0D76B8c SZlh/gFIpBSJ3W/rzPd9zncucd63upW0kksBAAACASSSSW6XOPL3M2lZNcnn OS3gAAfVMX3lzW7m5+313vuzdKuu9LrZARfrPbm664zLsARdl4qKqpamYrU0 t297OFy1WVVS1NzMeiZ8VhWBi21VURVRG0n1maz1y33X18lqxUVREXMeMd7o k8zdnNUtNkejrV97aUk6ONtsAAMqt9tLVm7HJuR1edT1bbQB/Ifd73v3xu7u 7vwbutt53N9d3Xtd9dVheWyx1S1tMIu4Go4N9hnPeeXOT1e16KH0kAfzb+b+ aSSENxuATFf4j15MqqqO7Q4Uy6293Ph+BQjJ93ffXM5znvPPXd3m94Qdd6ve 3uc+b5TabPQTMzPrmu6Z7qzTg1TSbgMVVYOu93b3vOXtznccutGHAUgpBSCk FIKQTZ3LrM737t7TOdzHWjDgCkFIKQWRCyb7rLe9+7e0znTMdaMQPigyKCkU fDr733m3nueqX7ntJrqv11MxETNXz7Bdu7kws0xrrtw4mY9CnAhSXnvunMvu 97xLzuY+337cDgJ/5P9X/X/87+f9X/b+fd/Vf27+x/ZDbbcAAMqtfXqrHCGr vTzeyX1bbQB/YH3e9798bu7u78SANt9tc311eare/qus02jbH7F5chxd0Go4 N9hzx9VZUrmGvjeUPpIA/m38380kkIbjcAmJdq3IZ12sN2ddEmXUqDdCeq7q PQTfFKe6+2YxaOerbqPQn729by+9z3E526fb3pQxCgKQzfr7WX3Z2TGa4Orb qYiJ9EX1VSDuzvZtuH3W796fsJmRMzJdeb2nsz3091Fe9ve5kkzM/50PEgsk jvX7vW37vP3yd727Nfvvb3ogsiwFg9oYqqqP2tZpVZMSkrKrFUqFSVlVVQ9P Hvebdd77yPeaxNe97e9HgFBRSCkQqQRIh8QENd73urmd9zpzvM0Pve5sDEQe tgIyNbEQEvgJPe3zlzN/c9Od5o173uG/AQFACPqECVAnFVVEVVVVVVVVVURV VVVUZJcoQIIj6PdwAADlxMzMzMzd3dzMzKqqqqb3ve9qkVXMzBgZlDBBVczM GBmUhbSFtIW0hbSFtIZmYQtpC2kLaQtpC2kLaQtpC2kLaQzetaIW0hbSFtIW 0hbSFtIW0hbSFtIZrWtBaq0LaQtpAR9Aj6BH0CPo2d9XtTfubns9mZmZ7d3d 3efpnJkzx7x+enl5E9W20AfyJ9u7v30gAB9JIA23Wb1NqrurzrzWVvWq311h fmsPLkOLug1HBvsOfsp966vUt3VrRPpIA/m3838+7uOBxuAX1y7d9paUz2NB nb3s3E4fd1Vo+j0JKPQlSFtIW0hbSFtIW0hbSFtIa1rWiFtIW0C1VKQUgpBS GrSCkFIKQUgpBSCkFIKQtpBSCkFIKQUYkUhbSCkFIKQUgpBSCkFIKQtpBSCk FIKQUgpBSJWikFIKQUgpBSCkFIKQtpBSCkFIKQUgpBSCkFIW0gpBSCkFIKQU gpBSCkLozCCkFAQSCkFIKQ97PuXM39z053l0a9729914gpBSCkFIKQUgpBQH MswgpBSCkFIKQUHMpgKQUgpBSCkFIKQUhmZhBSCkFIKDDM9gZirQpaQtpNAK QUgpBSDvfuZrM39z3zzvdmvfe5vuvEFIKQWRGRNK61mKqqqqq5mYqqqqqrmZ iqqqqqtzCFtIW0hbS1fe5v7M5znjneaNe97h36ktsiCkFIKQrSFtA+TMtqqv 9b73e8uZ+5z1f3fdV+quTypmZmZmZmZnzzOth2ZrFz3tocLftanEAnAgKQib 0Zz7o2+731ve82aHu8D5WHec+xe/fdvce92arfe+NKIqszM+u31IO7OUrNxm VB3U49GY8VB3Zym0G4+9knb71V6qqqqqja23wtzkDbbAADMpdqrtdwm7NqVm MUbbUhJJJ/JJPt3d++kAAPpJAG283qb6r28y/WCravr3KZd8jy7hRd0jUcG+ wWqHlXO69y5635dw4/pIA/m38380kkIbjcDVHdeWaUlyStoO3eUrNxmVB3Oq mJmZn+QlMzPJTMzHdmUg+zPmfD3tZlF9UOZmVgBzmuauZ72/V097zM19nvOS AdVFOzxzq7iRdeg5uj9mzPfiveP1Ua6u4kXU3Ob3B8ZHp9ER7ZmVryUuu9U9 uc3uQPgh/iAPe642/v33qn7vP2td4Zr2Twk6BHXLwR6rtxS68Dxq5M9+8233 ruRy6B41fvZPSIHOa427992vu8zN33vaiz8AQUAlIJJbJCyU5mvYedfvu8/c 5znP3e973vc883Ofpb5dfvd51+eWdT1bbQB/UH3d3fvvvvpJJJJJAG283qeP qqs91ZkMqFEsJ5ahRtKQAJA7JnP201XUt05dup9w4/pIA/m3838DbfcJRSAX VS8+fdzdq+82+931e95mc19r3jFWKqqu49E5m9m+ez3aN3bde7FbH0CPoEfQ I+LaQUggb+0+377v2X3e5fr7hgoqimgLSy2L607o5rdfb+7fqe73Pn3xgoB4 kBPvtOve+7X3eZd33sCeEEENbPtu/e5y+7zW33sPQCIHRLIh4P4CloCDBhRI ePc+rrn3q/u8zb+9h0giQRgeIDRAoRKJBGUgKAkqQUgpBSHObd6992vu8zmf Z72eNgjSUESCJBEgiQRIIkLzTz33a+59n2fZ7ueIKQUgpBSCkFIKQUgpDZzT z33a79zmucvuZ4gsBFSCkFIKQUgpBflVVVVS2rA+js918gjbbAADKqc61h3l Nw8Upsi22GgfyH3e9799998ABu7bbm9Tx9KtWsH6idUy+755PCJ3zaU+ACQO yZzK6h1Ty+fLdx6xx/SQB/Nv5v4G2+4SikAupq6GddyZmVkcuubet3vM8Q7a QtpC2kFIKRisUhne3tffer3n2ffX3faZBSCkFILA01GEVVVVSHOb5X33K+59 n319256blsikFIKQ5aQtpC2zIAyVILA016hiqqfX7vF93de/fZ99fdzxpUVV dgAWrlqwKkf4gDhFILNSLBJUgpBSGu92v77df3337XOXP2eIKbgCBUgsJKEB gQ5zPW3fb6/Nv2ffX3vAdVVZFIKCqqp8lgVkhvvder7d59v28+ue9APISDAT 5JA1eafd7fH29Xd56+CSanAh4ikFIKCELgHDu32+V59v2vm+zxBZPAsCRKkF IKQUlkIIVIKQUgpDOc2++7XfnftfN7niCkNWwPEcykL3MlikFjBtk0MzKQtp C2kLaQcPf7FvJDpRvV1TEyVP2m39cY+zJ6aroqKsjEwjsWaHdvqm9ST9Ubrc mbzlWptO5zrBb5S5JP2fiLboSSSQAABJJJAOc5wAAAAJJJIAAkkkgAEkkkAA zMzMAAAAJJJIBJMksS5JyQbbbcg0Nte1GzvXd7k698GVUjBKS6aWUNHOd3X6 3b6+fu6onaJd7KyK7gh226hwlzxw3dXQjze7ue7wsu05vX67qu4kklL0p5u4 2w7W732+eMEl3gS55ZPT2Ppk16uzBI7de75zUm0l0JzZOSI0AASTP2YN3ZJJ JJJJAAbu7u7uhJJJAAJJJIBJJJAAEkkkAAAzMzMAAAAAAM73vR/g+fffffff fSSSQAABmZmYAAkkkgAAAAAB776AAAACSSSAASSSQAAAAAkkkgAAGZmZgAD8 AAAAAzMzMOgwAACSSeeSS+X333jPfUnnkB+ZNztu471+549S3dSckku7km7u 7Ekkt3d1AAd3u7dmvlnXei7vctutVrIVtJp9meLifUyjvSn24bpqlvS3L9MP Zz6oY11VVHCy3WPRD5lTVda7o6dLZfd0JJJJJIbu7OAAiSXA23XqZu7ukkkk SSSUlABw/Yg2W8WKYEzu7u0csmGt3d3QkkkgAAADMzMySSSASSSQADMzMwAB JJJAAAAEkkkAAzMzMAAASSSSSSSAASSSQCSSSd/jveyZmZmZmZEknd3d21G9 bfjlDL3LvbNvY8xZvd3N9zSjscTizG23mg0ttt9l8bNN7ljGs2bExLM63tnG TbvZcNse7ukFmZBdobvFV3dwyB295v25rhV1mTKKu+vZ3QACSSSAAAJJJJJJ JAbu7vz622z774AAAJJJIBJJJAAEkkkAAkkkgAAAAABJJJAJJJIABmZmYAA5 znAAAAAkkkgACSSSySSUAAADMzMwDd3d1JJIBJJJAAAAAknd3d0kkmerYDMe GLmkuJB2vd3CJOe+7e5+zpeXvS2220PPAAASSSTdkki973vaAAMv8c/f4X35 7445jjbb+AAM/TnWwkT7fYeKU2K5bbQB/YH3e9799998ABu7JL391PH0q08w +or70d6j32qL5tKQAJA7JnP201VLLsfL3bj1Dj+kgD+bfzfwNt9wlFIAZZGw Jiu6pvMjl0+7OoKWvELaQtpC2kLaQtpC2kLaQUgpDnPvZnvvV7vftfN7niCm q+ttZHBUZmd0aFVVVUTWta0Q1auRqqyvQoiRtx6Abfogj3oid3GHXqnarncr bniFtIW0gpDLSGZmELaQUhbSFtk8sEznLrM99yvt79r5vTPEFIKQUiYhREg6 aQtKQ19p+8+5v7Pt938364dIWlIWlIWlIWlINaQtKQa0haUhaUh3XOdX7hda 7rbfrh0g1pC3PXQdAUjC7aQa0haUgiQRIIk0CxGRQKUh3vnm+V3r2bb7DpBE giCeVFoNaQtpC2kPELSHe6fb9eX3PrnzfZ4gpBPEkSgdtoKrJUgpBSHe7fb9 eX7fs+b7PEOWkLaQtvoRgZlmBFCJMykLaQtpC2wC2hLnenvvV7vftfN33XiS 2kLaSW0gW0C3YdiGZQ7mbmnWtZqqr3vbW7f796ph01Lo222AAGenOtYdHeb+ 832Ei22gD4Pu97377774CSSQBtvt7108fVWLFtVfwqGT1Xfc5584/m0iABIH ZPZz9tNV10tw3lup7Y4viQB/Nv5v4G2+4SikAuoVzUmclM9PX3CutLlX19ZH oJBe90R6PT4bI9FakK1IVqQrUhWpCtSFakLtT1dorri5V1tTEbERECCIgBJb 6FEE4kK1IVqQrUhWpCtSF7t3vvMv2+/av3dIeWSKRqAq/X0AMJmW22222853 Xz7772fb3vn3d7trzMVVOiyQiPNd+0Ob3zPt7337AsBYCgIcAPvjjzBVRTy8 cejMJx47ZdlvLIjPROTMxOFPWstdna0e95+/fmUBdNdvcJOm6pu63c3W89+/ nd9L+v31W5Gvm2AAGe3ybq+jc3P2+pmxbbQB/Ifd73v3333wBJIA23nt91PG K5fnn31m5T8fCjF4+mANpEACQOyezn7aaqum5N5bso2a5PtN3bJEi/W25myR Qe+GWb6993OZiO+11czvc5BgGxk5xxc5d3eaznMDXoj0x6sJuUxYqGZnOPRe 5LlPFOzYzdJTwCkFIKQUgsBSWw2qqrWiqqo+aq41QrBU6E77T83fqm/s1rns 2EmhtJaoKq37nHrd7v3c5rea78aVVVUVVF9AOd6+b9689nNbzXvtPgD4IFMp akUDndJ5u/X6/ZrPe+JJv7h1c70vb9zW9b7z7wAEQIc742uSetWs3JH6/e33 k488TMEyRDbAADn7st89ket2esu4ttoA+D7ve9+++++AA3dtt5+J+vjGX2+/ vb599vn2b+YKdE/txttpSABIHZFqfurVVdNzN7mu7jKvw3dskSL9bbmbJFB7 5l3dja1q0pnZuZVbCmKY33U49F5kvEinCmnTqsy3Hom8nJyWU4RxY6e7TiM9 6Y8ozdk1Ipwpp06rd26iImZnVkzi0pwhUq1vfe70qqqqHL885bm9Fd63re+c wh9zjrIZmrfWWm+XIz372JKivVfd6+stb3Bm4wPr9b1HNcKnfvtb33uSeRXn OPkbvpXH33zv7fve0K8IW0hbSFuraWqvI9ucR9sajbAADMpal2qKYNW105bb QB8H3e9799998ABu7bbyNedHbHbu3X3wWev46HT4xttpSABIHZFqBVzpem7m 8azdji+JAGkolH8233CSjkklq3ghu1d1SoLvFvrpJVre/ez2W2Fqqqqq/c4+ etz7RfffOb332eVV0ttq227gGZlt9zvzj83PtF93s1znvK8ACZmZmZie5kT6 Zc5D3ezW9+93QaBSCkFIMfucdrd7L73Oa++972siBgpH5VPdp3lbvpX332t7 97uviKsUgpBSCkFIOiCkFIKB83lObmVdQujsvKzN49BMzEPLjJkdQpO7MvM7 j0RfveiJm4vpwCnCO7M6904iYiZiCyMYoqrAT6GP3w+5bn2i573Ob5zvu+2v CcVzMwVZMykLaQtpBSC+/eqvfvVXv3szSi8v2ZloIo2wAAz2od5pN2e3G4tt oA+D7ve9+++++BJJJAG28neVGkdu7dmffZPXp+nZ0yp8380NKQAJA7Iq1PuV V2l7zXa+4cf0kAaSiUfzbfcJKOSSXbXrdrcy7vY85bnNFznOXm+c97NkFIKQ UgpBSCkFIKQUhvlo+5bm9H2a77t7vvfezYMDfMum+5bn2i533eGO+c97NkFg PIyfezW9XjvPtFzvu8Md8573tTpInziqqmc3uuuZc+0Xvu8Mdffe940qqq6t tqzN7OXNW0W4W9uQS7vu6HMtJgJJJJIHKpVZu82XYwrLhntz6+99669wASSS XAJKZmc2byatotwiM7c9WZ3c5mZ4CSSSZmaczKntldt72Z9fe+9doVcktpC1 VVVfvt5fctz7Rfe7ya++97W1VVVVVVVVVV13xMz7Pj7G/uS+bbbbbz057bxH 17j8brezo+bbbkkkk+AJu7ofAAbu228Z+nm91fee+Tn5POT+MdJg8bgNpSAB JJFuqtT91cqqZHyLnvvdzqt+G7tkiRfra2RbbQ/ediZ9frV4mfb9L37vDS/f e+zdltG2LC2gpHRFIKQU9r5PXe5c9z3JvnPfZJtho57XE9fvsTHnvpr7fvsM gK5SVUjWpjVcxqdwpzb86rbIjve96Krs9zuklnX6t798ZMFnqKb9yezX1+pz 3Jv7fvufbG0WSCSSAH0REGRER96vve56GN3Pud377n2+BAmZmBAMzDAIW5bb bbbbaPPvev0Ot3Pud57uR3gAAAEkq4921VmdkF315lOIgLb9DYeiACCqqq9v vTOa99l97hr7fvvd982qpF0ExLa8+aaXRRttttvHXPnmRzEcYC2YuW22gH27 uu970PgAN3bW89O8qNI7y3jq43de6nOT+rafwfSNpfQAJJIt32c/a11TpvIf WbccXxIA0lEo/m3BKNJSBo76tdu7u7/W9arGoVPe3amZm/RoCCZJ8p7vXT7J HlwXXdnNqqqqqp7s13XfOc+LvXvd0Q9yZzXPOe+LvXvd0Q9yZzXPOe+LvXvd 1DYCHYQH3Zveu/Oe+LvXvZ8qqqqrF17kX3d785w+LvXvfOvdgKEzFVdWqqqy F+30X3ub65z4u9esnSCkFIKQx3817z77rmc+MzXfGeCW0hbSFtIW0hbSFtIW 0hbSFtIc3eRfd+35znxd694zxISUehgR6Kbbj0DbcegAj0AEegAj3szM972Z jhxV7DaKehzQ22223j5SXnHlzdzJ27nWLlttoB9u7rve9D6SSSSSQBtvPb7q eMVzcT7748/vvn7Nsj34G0pAAkki3fZz9rXVpm13DwzofEgDSUSj+bcEo225 JF0u+rXbu1a9MmVVybuQXXW5fR4BJaAgF6IhCR6QQAIlEgibrPTPZVZJnZBd dbyiQRIImmxyCJUEoabZABAIabQ1ZyiZ7KrJIzsguutPKcgiQRMACAjhEgiQ RIIkv3mOXeyt9ySy642dyFd9banhEgiSQQBAIkpjlibTabTaGmpvkldUptbc SqrbbZ3VVVVVVVVFVVVEQ22yJ9ETLbI9Ahv0KRKJTp7yS1zZePvhu9++6+Wt qqvwW0hbSFtIW09fctzXdl+ffDd7991UVUfNaqhr3d+XPe+L158Xe/fHvQJb ZvMpbS2lIECfvokTKeXnhvOHXuwvnu1MxM/A1sa0ai2DWkGtAai870vddX13 Liu93NtPpTEkD+NNUqImqQIFREgiPRII96p8y5+XyS5U+7Orb+zMzMzG8ytS Ku25ZPTCTVxObbbkkkk/gBO970PgAN3bbefve/s8vbt9d5e/fTTx9u01W0fB 9I2lIAEkkH3e1HtFXLLyTl5Nifb83dskSL9bWyLbaEzXbrl5ata3mvXzffH2 vt+5j6/xC3HCDWgMiNaQcyltLbWuDcpXf73mt9vd+f3xd7/fYooooooooovt HuC+79vhnucM++9zFFFFFFF9JIlRRc+3y3dx93n2fdd+73O99zFxqKKKKp20 UUbnOaa+7z77Pc5vX19zeqquoWo+JmZQIiAVXV7VM73tbmRy+tyKmVpC2kLa Qtp5VVEVXMzFVVVVVczMVVVRFVzMxVWTMpBeZM+3OX2/ZccvrcikfQI+ghH0 CPoERAj6CZmUfQIjl9bPaVmd7W5nL63Iyy2hC1bLaFqqq598a7cbz777O85t 2tyCZmZnkpmZqIiEvXeJ8Cu7s7MinaywqAc+B1bdnauymsvmkzpSlta0KWvu tS12ylqmGt961E1pTJCCZi1+mGzdQPaUqcbRzIqLfWqYPE99tZnarO5dXeI4 DkkiSSSkAABJJJAOc5wAAAAJJJIABmZmYAAkkkgAEkkkAAAAZmZmAZmZmSSS QDd3d3dzve9bvnhM90d7KHpHlV3O5nGUrNaFw718ecIsVXvc9xdDW85Xak90 r3cr9Z4SSV27M3r2tk3VzkmZncYe552qPkbtSlkqmxqSXycvEt3QBbfX3HNL gbaybkW+l1e7MV7Gnt8JCXc+33TUm4kySRYJckRoOADMzP2Zu7u7JJJmZmZA AAAEkkkBu7u6kkkAkkkgAGZmYG7u6AEkkkAAAAAAJMzMH9p99999999JJJAA AO973oABJJJAAAAAADnOcAAAADMzMwABJJJAAAAAGZmZgAACSSSAAPwAAAAC SSSAAAAM7u6q6SBczubzElVOSSekrN9bb9m8+7d3nJJJd3JO7u7okklu7uoA Du7pr5xLaim4qd5ZOZB3YumiJB7Ubp12W72LvuDH1m1y7AV9zAy8sib6zR0O 1Tzp55POezzzsrnOf2/fJ998fAB7vfe9YEkSSWhaSr1I3d3SSSSJJJKQAPz0 cJjxeTMrMzHxjbQyAASSJJJKQDd3d3d0BJJJJJJIDEkkwACSSSAAJJJIAAAA kkkgAEkkkAAASSSSSSSAASSSQCSJJHe7ub7u4SSSJJIkkkvd25N3krorc5pI 1t8lo27zO5yC7KnFmNtvMturvB93MhUyze7pvSSJd426xt+juwkxZmSLZirc nukocedKp9qjkN1D3W6g7znnPxzPM5mAAJJJIAAAkkkzMzMgN3d3+X1ttn33 wAAASSSQCSSSAAZmZmAAJJJIAAAAAASSSQCSSSAASSSQABznOAAAABJJJAAM zMzJJJIAAAAkkkgACSSSASSSQAAAABJJJAI976Y9y25udtcTKnlncISzMvOn pa3TquXi3ZG22/1B54AACSSSbskkXve97QABu/s53+kd87Z91b19li22223m ttVY+imKImJ84AASSSSf0ATd3Q+AA3dtt5+9Z+8nu5rfee63P33L+lDnx7Kj b+BtKQAJJIt113Lfd5uu0vdqjzdih9JAAbcbb+bcEo225JK39KxWrtdmF82o tjPLXbc/t6/ftoK+kUe/M8tdt/N97cgcLYz2NtyqxvbgLsl5FO12P3n6NmYi YqMy1V3dQbeQXe4eiJ9ETPoguxbl3UG3kbdYjCPTMTMF24W5d060Z5a7bz96 VVV6qqqrfN9cGu0vozz0vOUzyrluTkWRhmUhbSFtAtVdZrj7vN/dS69zpnN8 5rXlVaBbSFtIWo+gR9Aj6BH3My+17uZydQv2eis5mXfvrdlui2kLaQtpDMzC FtIW0hmZnv3pu3x69WnhLm+iG22228x9Tao9ZJ1N9XbW7u7oB/O7uu970PgB JAG289cS9d2cQte2/vrpFd76fP2VG38DaUgASSRbrruW95vq0w3rbsUPpIAD bjbfzbglG23JJvq6+uyZjmI3K9J17Bddj4oj0JBHoAI9ABHoAI9ABHgEkkiA CPRlzjw68ytmE+zoMrMafEegAj0c23Hobbcehttx6G2wAAAAC92TVm5lbMJ9 nQZWZqfACSSQABM3zdl26zc7zZhfs9FZzMmpmZmZmZ4ACr7yXntzmbML9nor OZnFlttt8QLVXVtYVkFN8+bu+79ve0ur7XDX33eOAqqqqqrn32XHb3m9763V z7mvvu8cwFixYCikFBnwV+bl295re+t1c+5r77vHPiHrSFtAd0hUgpBVVe5e 6ucvvb3s43Wfc++3fvaftKqvQAD1V265dX1l3cJ2auo5nrzu77RZmZdVVV+d VVVm81RXszNR0Q22223ntVI1KTu5PJo3cABSSSSfAE3d2SPgAN3bbefvcz+H vu5rff0e/TnFeZ99y9lRt/A2lIAEkkW667lve5tFq8zezm9Ok+++gANuNt/N uCUbbckm5V0qSzgpDVZVV0nJ0Rml1mOHMzMzMzMzMxMp3blE7dO4WoZF4XW4 4czMzqUzMzMzMzvd21YzOc5s5a+bG9rvMy4udACSQAVzMtVud5zmRl1fNje3 fWZe8ABlVVVX0Qqq+++iKqgLdvOdqb6W6qczHS2NqqxZkyR6E3d0m7NdVSlG x9zm98verkPEigzAUNb73d1y9+3vn3NXVdG23azJkUTMxEXaVXZpVZZI9jNb tZmpP3uj3vRM+iYuPa526ra0brCR9GbtVi3YFPoUemZ88wunTd0SPYvNqsRu zNVszNVVVXvT373q/veV+X8j8LO9/PvouF/G222289vku7xlK8i7lSZpGNgE kkknwBN3eh8ABu7bbz96zye7mt5Gee++ZfMmEa7aWtrYxtKQAIB0113LepvO vav1A1Yovj6AA2423824JRttySUqcu1YEyu11tV1kj6M3arFuzJ5zDtRMQUe SRc+utfZzmuffY5rpz7m98ver3Sqv6q/VQXe1gcLqvX595/JFyVl0fpdVVS7 EpmZEolJsESdta7TyMqM671d0i7RAkkTMzP0zM+oua9vN7NMjMjPZmvemnkz z6IgQcSAmZke8dmvZzveYzeHNnPffdvvOXKqqqiiir2vc0Zneb++83WHOHPf fdvvOXKqqoKuoEGtkaine27c79v76OeOcOe+Pu33lzEUVYovSSNRTlo2tzur vd1eb++jnjnD298vur7NLqW2QC0niCk/1msDmv37eZ5177774eHOH7e+cv7S 4H4GaVX8Jfev2b/i4X8YH0AB37Er2e54bOrlk1uEkkAAPB/ACbu7JJ9JJJJJ IA23nriRxD2LZTuZDqfZOX3OnsO3vpAb+AAgHTXXLN9TVO1t5+ofmNRfH0AB twAPgASjbbkkxal131313Oo32oSXV68xx9WZn0M96JzOuCAy6+zy+3Y+rdz6 GRH4iIyEP73ufOGa7zf0f3OH7fOc/Gv7+JDoT++N/tZcc17332+3P7uz+33v P418cIskQ+Yqsn86ZYAWGl19cc/vu/f3C/3en9vfe3+NB/CQgqrIAijIAijI gihowAJKgQkI7/shCAGXH9j+vXM57n3OX+70/t772/xr2mta1rWta1rWta1w xUt12or9uczH7dj9zm6/RceuUpSlKYmRdhGooovvvea39zm+Z3O96fvu/fjv tMgCiiiii4DUUXvfqX937f2+mfu6P33e8/Ged7RRRRetVUUUXrvWbNZx1+3z fH9zh+2c5z8fseNbBqqiii+qvVXqrb2fet94+4OaHAkAB37EtnPGW6ipTHvN kkkAAA+AJu7skn0kkkkkgDbeevYrOIP03vrz64LcgtVLPn298ANwACSSLdC4 zV6oehe1nqXlz4nx9AAbcAD4AEo225JF7Etu/rct5z7Rr7X3uPecP2+c5+X9 iKLZI1pAGooosii53v2tax1+z7fX9zh+3znPxr9pFVFiP9JLV9auBJrXud5d Gv7fd8f7nD+5z7+M7+2P9AjVtqqthAtX3u83dFtLr7sZphgaYYX6FcbOgQdF WglLZZY1vpYtpd9vr/c4f3Offx+9oP6SEyqtAkt0Wrkh73O/XRr+3zf3r/d6 f3Tv38c77f9JC1Vs/BmU9CS95gR4AjwBHoAv3n9vRbh/h5X3at2Px3dn0cp3 6gAAAAAAAAAAAF1GVUVrqvt1bsfbt/QafLfsAAAAcehtt+iE3dVHoWVQARAB HvAKIie2tcPHtfdq3Y+3b+g0+Zq9EJfj3oiPw20kklHgACP2b24vb9z+G63Y /hu9/RW1+utCqqqqqqq27u7X5dudKT+7U2/gkAB37EuG/TjFGdclYtbckkgA AHwBN3dD4ADd223n73qe7mt3pPPuSffG59Pt91tPeABuAASSRbrrlm+przrK umvK30nx9AAbcAD4AEo225JK92PMtLEnoZtOHbzd1ZkfZl/QLpMSX0REAEeA SSSkVCALbbbW39lFRW1n24syPsy/oFyMr5ttyDcg22wAAAAAALWqm4ePO+1Z kfZl/TJvI34A/HvRDbYA/REQgIj0AHoA+AhJTERDmCRPbbh4+/H2rMj8Zl/T Jva7+5ttttttuG23DbbbbbbbUR5NjQEBt64YZ92LMj7K+mVlHzAXAIAAAiIA PREgJJJa6vMqv1b+zGZH7Oel7l/gLR9EVNTEQlJJLB+9Hm25ASC4TpKz4++n JWOPsv5dRfwBIHoiIhII96IAAAQCCvebbAH6E0lR8d9yxx9WX8usz6o9Dbbi AmVVRUTWW7z9+9684ft8+9fXgwHnt5m817vbzh7fPvX11E/JtpI1/pCCeoAw 3+/hlb5zamb2LYx/wJAAd+S7K30y/IniuqGLW2SSQAAD+AE3d2ST6SSSSSQB tvPKKnZ3Rqb769+2PLn3d3vs+fbwANwACSSLdfK99XmvPLvLppW1J9JAAbcA D4AEo225JKXexWruqzszc1vnrzh+3w+/X14Az+AYJIfE+sm8gLHo6++4LHN7 mZH1Xf0Ln76Peg3b+DKeKfruPnX3HfRERHoju75KuZhNxbj5198T2qInCpd8 a7pJem9JlSvfvNy716pl2l6b0mVlvoJTHHPZWtsrsdK0pfeaWu0zrF2ADIAI w8D3ufZn7u+/ftZecP2t/exOgsBCwP60tVc973Lf3vvV598ftb77LQ/Iqomg AdptXfy+d18l75ohd+/eLJ1/ZvsN3Wm/gkAFXu91verypAsp0ni1tySSAAAf ATMySSfAAASAABkrL83OkOpvpX1/Mu/h91V9keHfSBAAAkki3d92a3fnlW5n bWt2KfANuDbgAfAAlMzMzu7pi4qC1aS4EkXWsWW4+y9+2Y9GPbtKO6iXo0Qr 36qqpd1dh25jeu6iXpz7vunrbbaqqqquoc+7eFua+5XXvr7vz7nSroltgW0h bQMzLaq4QlvOL136JO62K4Koz1/vxX7gd3NZ7RX6Dqc7mEwVVbzlLfc5w998 e7x9zrVVVVVVc5ylvuc4a99T3ePudap9bu1VVrwd9d/Mk9y9Xvl3yeZ+9dfv W3VDXObaf1X77n85f79tVVVU8+7PL5a/u+TWobgSACr90pb7Mv1M/KncxcmS SAAAfATMySSfAAASAAF+nkjQlcApSr7EmsefcLy+Wu+0X0kgAAEkkW7tVz1r zrbustpW0fMG38NuAB8ACUbbckic59vl+t5avrc7vfePOvT905+566VVUZ8r db5tf2+b+/cv69P3f33vfaVVVVVYrxXP3Ps5+1f3en7W/1977Sqqqqn853Vt /wfH82/4Hv5vP7IsqqqqqvfseVXzTX238Hvr5n6no77nJm4JnlUAAN7aH7e8 zWvt2PnWfC6ZGAQAe8BxJjSbGAAAAA3sKkvsutJ+zPh1mc1H2sAAAAEkkkkA ACUc5ift2tJ7M+dZnPT5gAAXVVUVVCud96Z/Ve9j2Z+vMznp9LYU4YyACCAH IIltjltkEggA3pmfu3bjsz55GZz0+qopsgEklCUyEAD+Vf8aP38Pt9UftjP0 /xI7Oxm6ul8/g0i75VkmdFQ8uu6unZuculQnSqoDuOt+vuz9uTNbzjO70Gku qu8RwCSSJJJIAABJJJAOc5wADQBoJJJBu7u6MzMzAAEkkkAAkkkgAAADMzMw DMzMySSSAbu7u7u9ySCq5PBU27mpTLmVSRd7F1DiInVM8bFaXNeWJ3W26Wd7 aLb6+0jHVdasOraoDdazVTetrZJnrFV+Fd5aU2kZdUk5HI+dSrEu3eH249Wr hJJd27PNUd3tOH7M2C3H2bOR5Lufb01PyncnCSzuzmDd3RBwSTPfMwbdkkkz MzMgAN3d3d3QkkkgAEkkkAkkkgAGZmZgAACSSSFtttoAAABP7szM++fPfgEk kkAAA73vegAEkkkAAAAAAOc5wAAAAMzMzAAEkkkAAAAAZmZmAAAJJJIAA/AA AAAJJJIAAAAzM6Ulk9Dxczu/cszuqukgep2TfJO/Jb2d27vJySS7uSd3d3RJ JLd3dQAHdpmJ96d3u3f3VFUWnSqbfVnqZa5V5bm7e+GlkN9e903AfR33XFuv dRnRKz27atY7OHL77O8zzZr3+v7m377758AF3MzGQCTu/t73fzxWd73qASSS Q3d3e+PChqmPBsw14/JdvcPu1tMcAAkkkkkgAAACSSSSSSQCSSSADdxJOSAA JJJIAA3d3d3dJJJIAaJJkkAAASSSSSSSAQcJJJIBJJJO88772TMzLJJJQSSS c75GYkqBVTm3d7p3dzza3Ju7zcdUXNw8B27u6+7ernu7ozzd6FJe6a1JErzr ov3JO3HMzHpeZmBJl3A7Vm5VgkMkn7ozc3l5vOOunt/eXMytACSSSAAAJJJM zMzIH87u78fW2yffAAAAkkkgEkkkAAzMzMAASSSQAAAAAg4SSSQCSSSAASSS QABznOAAAABJJJAAMzMzJJJIAAAAkkkgACSSSASSSQAAAABJJJAJzG1IpbGT dFF3XfTfGRTvXd2dqzPQ3d3ultt/UHngAAJJJN3ZJOr3ve9oAB/Z/T9/T+3+ r+f5/xt/q/c+/st7n9f9d3d/sboKvKl+Xd+Ve1PadetYNOQAAAA+AmZkkk+A AAkAADLogZsg71y1nXL9Hhk5JC0vtikkgAAEkkW7tV2Uu8qd3VPVmatx6fMG 38NuAB8ACUbbcki7Ve3au6qqtbD3Dv7W39pmZ67qkEyAA/kVVbPkz+97O5Pt 39u7u7t3YAAAEFbM+3e9yO7r27u7tVQAAAiIAndmfbuZG5nszPbtVQEAmQAD I92vcjk1l37u+85mL/nhC1VVVVc5+f3fv3peZ9+18+5aqqq+ppPuPta1yX2f e18+5SFt389+1qoX5552X2qJj8e9EeiILzV9u1sKy++vM4nzTLgVx7Fii6Ov e9fvVXvVkDbyuXTnzTcD+QAVe6q92fsq+v2oPduY60zdbckkgAAHwEzMkknw AAEgABMdW2bxKb2Vk65ePJy+Xl9vxN+b++kAAAkki3dquxd5VTu6ymlbR8wb fw2223838CUbbckleXu1X12rvC8xZ2Tp61i+XHEKq7a1Kit+3zO59v7hnNc7 zfOWqrMzMzPiZDud2vVnNhmXns77aquABJJJIAAAAJm/tPqy9hfY8+y/tAVT VUAAABk5+fszmw/befs7+2qKSSSQAgAAAEAgIC5jipvZOMzsvtAVAAlKUpLQ AASSSUbPVWRPe+yfZ321W4AAklED6BAydnrvInLzOy+0NtJJJJJJUGR6PQNt +bbSQSFTWrnm3KzHnZfaBtgAAABG1NVFEJSIENmbezs7De5ns77aquAQSSTI mZnqdjuqq5R6/3u7m773vQAVd7s/VSb7MVXr0fOQAAAPB8BMzJJJ8AABIAAT Kr3WjQnleeUvfp3kefe/d3v7736XuwAAA5zl99zqfnTpZe9beWj5NpHw2223 838CUbbckleH1JO3d9d5Xnizuk9Qm/udfGZlVVAov6FtIW0LVXvc535/d341 +97N/P7mZiqqqqqu9nn333u+/XM93nF/cuOKq/xaqqqu/73s/u/fr+M5zfP7 n37uZiqq/QtsIWqq/fvez93nut5z3f2+ve5mKqqqqv4hbSH3vX9znet5z939 vr3uZn4hbSFtIW0hbQtVVX3HXs/c53rfv3P2uPOZmZJbSFtRYjBSKhbQtbaq q7939n7vOj9++/a+f3MzFVVVVVX9+5+1wf37Z+/b/czMv2ZYWqqry1RX9+9+ 1453Z+f337mZiiqooiIiOUp7Xu63obU7H7T4UYSSQAVe715Xt6rTynuLDUSA AAAHwEzMkknwAAEgABDbr1PMHPUT7Ytjv1fX8le++xp78oSSSAAc5y+8lnnn knv7uey89m/S2R9ttAB8ACUbbckleXar67V3vWq6Hufe+35/czDERFVRERER IAIiJnu899sde2e9v3MwwRE/WltLcwzKW0q+jxAEeggD3o7fr2Jf1R99XYEf P6PQQATDMstoNbKxYsWOe7+30c1+p7XvsyeYsWLFjoCy0hZaQsthZb7O89nT Nep7ffsyeYsWNsuswxxltltltiXX1ZB3KH07Ye5ryQeAPAEAEAoSUJLySJgk 7JnOqNk6lG1nZzCnykQkifeBE+gEAG+iG235tum222x1k6ZGbCfWoebfMNfA AAo9HiQALbbcNtwAkklK2p23GnUoL6+Yc+ASSSMzEkrczMwzMtqSBWpDvLe/ fHc9ulHnLmHNJKNAhAKQUIAAEoSUJfnc89xa/d596sv7uSbh9JIAKu9LxKy9 uqmG9JI2wAAD+ATMySSfAAASAAFyqRg4rNr7kukPqzc+Wb5209+UkAABznMv O8s888x73Pd/e3X0tk+DbgAfAAlG23JIrdWurnbu+9z3HfO+js13iHd57Kr1 7H30RUVQmISAn75IAbeS92O693sM9z2cu95MfJR9ECfvvkgAA9Vc9WvdyPTn OR+7dZ+z94PnpAB4AgAiIptAIA+beeoKKba9E1O5kViH1qFnX2hz0ptttttt tttxDbbbbcAAABz0nbOu42cqpzqtL27aWr0tVV9bSFtDPb33ete++PO973z3 3LfehbZC1VsC1VWECy33s5vWve+PN3vec99y32w8CTMsC3JIWqq3YSkp7jbb 7bjZVVRnXiXTMnAAAACA2IiCYj0tsgAgDOu9tvruNmqqs68N8AByuXdAAt73 D3rjZ5znM93DfASkAJiEgF13t3t8403CSSACr3ZNSqrY/1MV3G3IAAAAfATM ySSfAAASAAMy5fqcyCVjNWbd/Ncuf1RZ8vr33Y09FCSSSSSSSSTMx3FzCqVu nXK360T5NpfQbcAD4AEo225JFctNWst3e+8lv7e32l1XORu9w3wAANqqQEp9 fpn1djuu9773OntlKQAAE7Sqqm9Qc3GzVUd1ivuoAAAAAAABJI+TIVvsqa9d Q45y/e7zte9x8SlKUmta2sFrVd99eJntaG/ZvejPe+y/ePbbaAIqqq/FtIaO +vVz2sL9d70b+9zl7miFtk+jMwoFgCNKQtKQa0tFFFN673t0ZrWGtu97537l 7hwtFFFFFNERIPmkGtIe324ue1hve9m/e+5b1wg1o1FFF9aWBK2taqVN9yVz IKO67tw+q1x0qVKlTCScAAIkESCJBEgjd5OYk5kVVVHdWYT3rtzLjmXHMufB dautTUgoIMTLq60ehNpuPQm03HoTabj0JtNx6Ms5R1ZhlvJGIcJJIAKrrpe+ VVXpPb4L3pJsA0Abb+bZmZJJPgAAJAAC5VI5tbr3P32TPLeb9vvf3v2W/RoA AJdtYljdVS9svNra5OtsnzbbZ9AAAPgAbcACSSvLsVrMz379+nZnZ7c2t7fb 3vY7mdxPpqUpAPRVVX0VVEpSr75U173vVHKub249mZkZzO4nZqYAAEklC6PA JLu7iLHL1xd3ZN9jxTokkiBAAmUxJHyU/fd3W1F3d5cd73tzuXinZJ9CS4AA AQCSSQAku7eO3d7cd73vfZ3E7QAEPUmgTPve9m9a13Rz77773PuV6qqvpNEz KFoqqQ973s3rWu6PPec5z7n3K9UVVXxJJaqr73vYb1rXNHX77773Ocr1VoW+ ltJatIjyUzM93cRTb7ahdmZkVl4p0SSS73okJlQkkplHoAhK+7gqG33VC3Mz Ky8U7VVVe9VVWXdXMzPXdZbT+7gnxX27BNDD6SQAVe6Z5daLlVeOrLV8o5AA Abb+bZmZJJPgAAJAAC5XqRg4jaq+48rjd7+83LdgAAB77fbl9nlV3pfurh1t k+bbb+kAAA+ABtwAJJKQ3128zOu5237d1rrjbfead1Jd3aSSlKZmZmZmX7u7 i4bfdUJ5mDyYy8U7hC2kLVVV+LbCW23vddzeta73enOu+c+0c+5Xqqqqqqrr ve9zN61rfNms6t7i5vKKqqqqqqqq27u7qwHi3dDvXrt5eXnWVO2ACZmZn333 0QPoM771eruta37Zfc5zXHn3K9VfS2klqqqr73vZTb7ahOOzCHjWbmk+9Fbu jbe3TkWZhGuavO87jJ94t+AhbYdVJJDMoEg9OoKbdZTkWrMcEX14TtR5KZqP JKPQkoCFtIW2S3wSWry+9ms1rWud3py+5zDVT33cqdmZmwAABkZc3ypjmVGC nNNhJJABV7vQ3zd16pVbi9mPS9UcgADSS+UZmZJJPgAAJAAC5V+ze7Vnd8/e fueepc5qft7bugAAkl3zzsaquM91DrLO+Ubbn0AAA+ABtwAJJKXq+b67eZi9 d79mY121lxvPXNO/u5U7YAAA/R9FVQ3Y8vgHbTkvpjKhyK9vCdfAIAAAAIAI PQBBHo96fQCJj0AifQZ3MhtvtpyLswhwTe3hPdQAAAEx4EAAAAIBJZ3Mim32 05FyzHATe3hOvve9TbIb9y7iyBCUiFR999VRRDY926jl3fvcua74zkVHe7iK nYsgQIe+j6FTFSpSUJKElCAg7uZFNvtpyXyWVATd7lMemrS+zDLS2ltKEhaW yFLZCiXvQoSj0Z3UQ23205L5LKgJu9xQTsNSFLZCloaI4ZhDMMa2wtshbZBJ eSqPOb3bMmW3W05Iu3CKrdROuoiAoAAADtzu8rsXd8zlzUd7cVU85mqnbAAA BVVVV3d5t5znOZTki7cBNVmqCdTAASSSSAQCALu7s/T8k+ps7EcNIZABtxUD nszRWevqrpd9fS0pI2AA2382zMySSfAAASAAFysd4zNcB/Wt7vmdk+PPW4SS SQAACSXfPMS5uqdle71IWZui+UbbPoAAB8ADbgASSUqS27WYUk6fVVVdOS4m bcCFVdygnWkpUpJZMzYAJyd5txnOc5nLmo724qp5zNRUZYAEzExPvo++iqqS u3WN9tVXd5cqi7qAl1nKDHMzMz0ej0xHice92tt5TmnFpwE1WcoCPLV0R4BJ JI9E9tSuvLuqrrpyey3BFVnInX0e9EAJKISXvQkqnwJJJJxHvAJLu59bbfU5 Rk5lwE1d8oJveUAAD4AXfd3t59d3feXNZmci6nve6qdsAAAAdjdve3d3nLlW ZnYup53uoqdsAAAAd3b3t3d5y5rMzkXU973UVO2AAAAN+zb2e0rLuVZ3kUm+ c1FTluo9LbcehttxANyAkkkkkkkv5Nr9f4f1j9t2GE0v09vjPQZfyUNkAQ4w E/Jm+AioippBLzjT2nmrifBA6lDwvyf3/T4q/2Kv7tZwPN9RLj5ub8wKOx+E hCZge8O89hd8j2gbO56PVs89K14WuPmDi4FBL8yfBKaH2UA6WTUodBNyYjdw KFswPoUW5WoU8HSB4jad3kChQ+7u6PQezsNPX6p06fbjdU2eC/17vT3+pVw/ K2VHuUwKh+cDvYq+KlEA9ehnMjM6wohdxm/dTn6DmPd2deP9LuUuPdNDZSv2 J8jyAA7+00yz1NN222SrbX8ZyKm4S522aAX0OQUoc+6h5NtfdwNvP/LLTM2b ykz312nk458BNcwiMiiKKEgsiqRSMGSRYRZBYEWCyCgAAApAIosiwUWCkUhF FkBQWQihFgsBSAsFgoIgskWQUkikUILAFFgIySKAKAoQWKEiwWAIyCrFUIsi igREUUUUFIsiyCgsFIsFIoChJFAUYgKsBSCDARIsUFILBRRggpCKRSLAFkFC LBSKCiyKCyAKQikUFFhFkBYCkirFCChFiILFkFgRSAqkFgLBVFiyLFIpAWCy LIsFFJFIRYoLCQWEBEiigoosBZIoKRYKRSKEUiigCgpIxFiIoLJBZJFUYMFA VSLIEiigiLAUBYLFWRGAKQQSQEQBZIKRYKKoKCkWSSCJBSLAWLBQWCigIrFI oKCrBZEVICxRRYsFgsiyCyLBYChFIpBVCCwkUgsgKsJIqDIiCrAFJFgLFBgg pBVkhIAKEJIACxQUVZCCxQWEWEIsWEFFVYEWEWCyEgqqsiyKApIoLBZFFIKs gsWRYosgqwgsUkUEVCRGEJJFBQiiiixYCwWEUiwFgsBZFgLBZFkiyAsIKQFR goLIsUikIsBQWRgkUkUgsUigRYsBYKQFkikUILFgsiwFICyKLIoCJILCLIsg osBSLAWQUixRSCrFJBQFCKKKpAWCwWLCLIskiigosJEQiiwFIKKKKRRZFVZF IpFIsiLECCrFIpAWKgyKRSCgqxQBGRSCkBRQgKKLAWLJBSIgoCkFikFILBYC wUJBVWRVFUWRSQUIsAUFkiwFkgSLBYRSEAWRQWLAFgsWBIoCySEikgoSCixR QRiyQUUgsIsgLIoKSAsigKLBYRSAxICkBBiwUBQUkFgpIkRQUgoCgAAAsAAF kWRBIjACAoCgChIpILJIsgqxYRYALIpEYCyEixSEWAsikFkUCSKRYKCrIosF gosIKCMgsioIsFIEixYpBYsAUkFRiIoooQFCLAikBZBYLBQFikUFkUIqxQFI KRGLJFhBSSQVYKKAoRZBVgsWAqwUkUVYpFgKCwJFFJFJIRRQBQikBSQWAKCw ikigpBSKEkiwBYKsWIkUBRRQUUUUVYRQRkWCwFIqyRYLIsiKKIpFgpAWRRYC jBAWLICwVZFgAEkUgAEBZFgsFigiQFFkUWCwUiMhFCLAWCxYEUgsVEFkILAF gsAUiiyCwWSLICiixYQWSAoKQUEZIosWREUWLFkUgpCKQWRZFBSRYqyASCIL IqCE6yKSSBAVVRU5R7cq79Pj9/lp4e7jTp38a642PGHdljXq6pjYhu3X8J5O fU159VW2WF6Fxm0DPjYuaQAMTTUzE1Rf1nNbPm4m+3Kvgx7Mrq2Iq5RFuw8W VQoEIgcuxV2m4gNgAAFU6d+tyCcwRQAUVN2FPtKHW9QzStJv6+Xb10uOcSir oKiDmdkoKAgilCXmFK2LYCiCipsI3w4IXXQkJDJEVEVLG3PDdY0aGEpidCam IAHIzmXZTeq1C5VnMABeq4CTnU23OpEL2ThyvtZA3wFVUVL7U2X1oKxFBBFK Uy85XhlRFEUVLTAEVEVLSjGAKCipYRBBFJhiAFKYlMKIYlUMskRBRUkceGSm t6FwoCCKSlxuIEMBNt5qBi3lStlJA2NKKqqipfcZxRVEVLanMVNxCFgN20EV EVJmpgXlTzZ7rYVMKqBgH1ulDboAG9Ti65SGfSKKiKnNZyEmV5jrWRVqmoWA AAVSjTQjdjScCmMIWyxsZQ/IACUhezjjogGUL8dKXZ3Ks86bChYYMAAxu1hQ w07KtbHGpfUJU+mBS9Ddl1koAGdDZ1iXKu6AAc9z0IoAKp34Cioips/r9AOL bcB1ABeaTeeFToOYqhb7czkF1C2jZCx5hYJBSxkp3oZxEFUVKBgJpzXH/zFB WSZTWQLbhz8EfqBZgGAQQAJ/8AWj2kBhbH93kUJA8AAAAAAAAAAAAABQAAAA AAAAAAAAAAAFAKAAAAFAAAAAFUoAAAAUAAAAEgAAoAAAAUAFAACgKAAAAkFA KAAc7hwoRIFUBVFBQdJ9e6IQOHA4RcxTBDQ7FxuA5cOaXdh0kGNrYbEajrjn OADHCacjHPKpElSAoooqgB3UXmNDggoCGaAISO4ODoSwsA6ABWuMwbYwndxw GwzRHLgrGDCsjESo8UkREoUpQUAAeF3tp2Dm4RQ6O2LhuI7WtnHWc7WZw7KM NgABggoMMIwXZkHDYkKDDndoAN7xIiQlCgAAAOHoAMe3JSxnBAOIY6jAFlYA UTMoJzg7dWa1EuFgAOrcLhbmV07ZgucGqOekKJCUSFJKAB13qdZjhaQoFBYY AABBYMIZUrDAAbKwAch3KwGS7c5ZXJnTHIAwR0sekiJCAACgAGeeENw4MKmC GM0rY7gs5AOGw7DFKLhYdAQQ3Kji4hwmoczaG4WFOYyVwmHbG54ERIgKUoUA oG4Hq4MaoMEAWQjNNhGBMKzIsHXAN3C5QKobDrDhynScHA6hnlFCQgKAFAAG 96g2WuHacMrM4ZwusXCxU4UU4IziHCN0YHCABuOHZ0AcOwFGGHOG7yRQlSAo qlUAUa6h7iNw5u2yLh24BjiYUKRdquG4ABhtQAGGt3bahjhmAbQN112ZycHL AW6e4iRKkAClBQAcdeDcVM7cTZ0HbQNhMCrEYEYWOd3WErKLuM24OTBpFAwA AAAAAAAAAAAAAFGhoAAADqn+2Gn6qqVKABkMVPGBVKVAMjJgap7aQSlVMhgA DU36ogkqpkMAASaSBJSo9QAaep/P6+/z/pz9v+cdc/y/q57+l5atq1RjhrMt +vebo+Uq5dtQkLE706PX7Fg6SR2pCO7QydO9vLg9edq8+q7DLlFF2uzjeCSJ 9RBraOrmU90tzxzqpSLmXgpDxSD2OwewiPlTNfuT32ZV7F7AV5G8teHGh0lD F+wOprewu7gmb3pkWm7yhEDzT68D9sU1VWha/C2F9lg7qk28vJaM2ZSnG3Xr lXUd3XnVgvdlsbRjLUzud+IEC+C5eK81sAfjRHD6T1cT9297ujyfXi8GATz3 dC3e9X6hvmBl7AjEaN3240MVuv3ds5dZMyqC0LtvEIODVKe4a/LRmOKuPqo8 6QaNOidu5Onpa9veu+M2X3r69zjk9bQWjDL9y8vPM9ReeYEqq3ZPXTg2eKu4 L2TnRZlnmnXerKr1KmIHiGJZh7de8RnFlWI1lXPMD1A5POC9dUzyV65kVObu 96e2zNi5Hr7g8w+tnGm+d7tS88j3T8u1T27KLF3ert13F2biWj4+mpPNzpB4 udRgedmBbH1ucNbaQLdXhiXtzJvFVnrqQwODrvsnZ1uc0TvA3qp4kp92j2Pu dZPigt6Iyy+yb1V+ZT035c3ufT3dtbPSQIACqqgAAAAAAAAA9X1UAAAAAAAA AAAAAAAAAAAAAAAAAGZmZgAAAfe+8AdP13bGj3z3d3fXJHprpkjunHzu7u6d wA793d3fSfm7mpIAAAAAKqqAAAAAAAAAAAAAAAAAAAACSSSQAAAAAAAAA+7u 7u6cAAJyu7u7NnNn0nXd39irvwkB+kmZhJAAAAAAAAAD74AGz6SSQAAAAAAA AAAAAAAAAASd9W+7q7tc337wz7e+vd9mo5JJJIAD9d3dgAAAAAAKqqAbPpef YSQ+kkk2Bdbtbe6ABmZmYAA79VU9+t93njPru6RVpKlbnLk7h7N+3b3QAD7u 7f01u62MzMzAADZ9JJIHd3d3dwAABJ+u7N0AAFSSXJAAB3d3dI7u7uAVJM37 SZ+zPVIZIAA2Xcqq/dWZ3ScHSf0kn938fwAAAXJLMzNAAB9JJJsAAEkmZX6p 13J7d7oABckqT7t36+71X3djySTI7u7r3VSSAAAAAAABJMzCSE/SSbpJI7u4 AA+kk3NO32d+6zDg/e94A92ZWY0zr9PpUqvVI4VVUAD2tr3tr9RqTqquZs/Z dmacAAAAAAAVVUAAAAAAAAAB98AAAAAAJd3ZoAAAAAAAALk+v9ZeICSSSQMk 9JJAAAAAAAfh3d3O7qXd2AAAkkkkAAAAAAAAAAAAAAAAAAAAkkkkAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACSSSQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJJJ JAAAAAAAAACSSSQAAAAAAAAAAAAAAAAAAAAAFd2ZjMABckqSQAAAAAPv3wAb PpJJAH0kkmwAACSSST9dVdVYJ3AAAAZmZmAAAAAAAAAAAAAAAAAAAAAAAAAA APwAD3vAfSvUYAJJJJAAAAL7u6+7uAAAAAAAAAAAAHf5Je/Y1I6/8mT30+kh Ngv4GgAAAAAAAAAAAG7v7dmZmZOkkknZJ6SSu8zKXgAAAAAAAD77f3XfX27d Uu8wAAAAMu7s6vp3d9Lurnu/dLDgfpJJJJ+kZnm799oAAAAAAAAAB9JJJsAE /SSSQAAAAAAAH6SSSQAAAAAA2XdmaHd3d3eSSZJc327+NSQ632e63j76SAAA AAAAB3Zv27qbD7u7unm7t7s4AAAH6SSSQAAAAAOkkkjh+kkkkAAkkkkAAAAA AAAAAH0kkmx3d7d3WSAAAAPpf7vd3Z04AAAAB9JJJsAAzMzMAAAAA+kkk2AZ 09M1qSLR822vJJJS23Gx7rTPRKN7W2y3Llo7p7d3WSO3d3dQAAAACSSSQBv7 d3d0AAHqXJM3J99AAAAAAAAH5+AAAFVVAAAAAAAAAAH3wAAAAEkkkgAAAAAA AAAAAAAAAAAAAAACADuAAAAAAEkkkgAAAAAAAAAAAAK7u4F93dwAAAAAAAAA AAAAAAAAAAAAAAAAJJJJAAAAAAAAMzMzPvgAAAAA3gCdwAAAAAAAAAAJJJJA AAAAAAAAAAO+3cphI4De3q4FVVW7uAAAAAAP7Kr+/vvv7+/p/fwAAAAAAAAA AAAAAAAAAADMzMwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADMzMwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAADMzMwAAAAAABknpJPzarlZ7193Xcir+u+wAAB+7u 7u4+7u7u7gCSSSQDd2xlfVW1pypJW7p35JJJOfvgAAAB3d3d3cAAABJJM35P 0knd3AAAAAuSVO2ekidH0kzd1z/XfwCfwAe7u7u3uAAAO/d3d3dwAfpJM/YT 26kyR37MzGHAAADu7u7u4VVUAAAAAAAAADPeDQE77eqsxd4gkl7+1+vqr11j su03TiSSSQAAAAAAAAAzMzMBP0k++MsJOd7u7u4AAAAd3d3d3B+fvO3b3dfS Sr+t7u6vWJkgFVVAXJKk4ki/s1JAAAAAkkkkAAAAAAAACdd2vAAAADY9d1v7 bu0gdufrtkdu7uHAAAAAAAAAAAAAAAAAAAb3e7d1PXfruSAAAAAAAAAAAAAA AAAAEkkkgAAAAAAAABVVQAAAAAAAAAFVVAAAAATvu7u7uAAAKqqAAAAAAAAA F93t3dSAAAAAAAAAObu7uaAAAAAAAAAP2ZmZgB/oAfwAAAAU7u7O7uqqoQAd wAAAAAABS7ugAAAAAAAAAKqqAAAAAAAAAAkkkkAAAAAAAAAMzMzAAAAAAAAA A++AAAAAAAAAAAAAAAAAAAAAkkkkAAAAAAAAAMzMzB7u7u7e4AAAAAAAAAAA AAAAAAABXd3dndwAAAAAAAEkkkgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAABJJJIAAAAAAAAAAAAAAAAAAAAAPzu7u7u4AAAAAAAAAAAAABjuu5J cd3AEkkkgAAAAAAAAADOl2tt/fVW/fWnxXJJJJAAABs+n30kkAAAAALklSSA 2fSSSEkkkgA2fSTCSSAAAAASSRv03d3skAAAAAAAGZmZgAAE/Sfrs3dABJJf 43aqq3QAAHd0kkltttttqeNtvY22YwBPSRJJygAAAAAZOlfSSJwAAAAABJJP sdLvrvpV5EgSSSSA3szFtvd83dpJVVUyT0kkAAAAAAAAAAAAAAL3fbu/u6SS Tk/Tn1UAAE/SSSQCfrz7MwgAAAALklSSKzms/bf3VnXkfs5RgOFfl/fi2t3N fGdJkclflY23ZHLcskkjktAd+7u7skVrMzCLST2Tb9LhwAZJ6SSO7u7m7u7o AAAAAAAAAAAAFSSXJAAAf5N8dX6qxu1VUVJMmSoAAyYv5bUAMzMzAAAAAAAA AC5JW6SSO7O70nsbrI3vFgAAAAAEkkkgAAAAAAAAAAAAAAAAAAAGZmZgAABX V/eCOfw6SSSOKqqAAAAAAAAAAAAAAAABf67v6z27m3uv19VKEFbu1u6AAJJJ JAAAAd3d3d3AAT9JJJEkkkgAAAAAAAAAAfSSTPu3d3OxPSST6Ru5rJEkkmk9 7r3VbuwAAAB6SSZIAASSSSAAAAABP0kkl7vZnL3YAPr721u3qAC5JUklSSXJ D9u7uYO7uPvgG9efflMJAAH8AP4AB7MyszZ9WZ7CTpJnzHqNZI9JJMkAAAVJ JckAAAAAAAAAAAAAADu7v0/bqSRxVVXfuSSTJBCSSbsAAbPpJJLnvZlyZ+bt bbttkkkkltkkkm5Hvtj7u1pxvf06vLqqvdAD2ZlZgAAqqoAAADZ9N3db+3pJ IAAMzMzAAAAAHd3Xnzd3QAJJJI+9u7S9Z29eRx98AAAAADqqll3d2z6SmzaS T8uqnt93svN3TuQ8AAAAAB+zMzMAAekkmSAAAABO+7u6qquju7u7gqvAdwAA AAAHd3d3dwAuZmYzu7u6O7MaSVTvakmSAAFSSXJAHz9mZeWwZfdy3vg0AAAA Ht/d1O51ydknAAql/Zd3k36Se96SQ30+6SGTqknAAZdUEbu7u7wAAAHs+qgg AAAAAGZmYHdnvSKXY6STgAAAAAAAAAVLp3vu6b2wPSSTJAAAAAHdknmY3dAA AAAAAAAAAAAAAAAAAA+7d3c1AABrvd3d3cAAP4AfwAAAAAAAAA3u9JPzmZtf fVW4gABu7u7uYu/CQ+67q2fd9D8ESp3d2akkkJJJNO7u5tUs0AAAAB+u+zLu qxoDe6/bs+nr/evd9vrbvABK3drdOAAAACt3a3U/AHAAAAAAZ8GAAAAAAAAA AAAAAAAAAAAAAAAAAAAAsvdq+S7y1kxK8S7ZJZPSSSW22091BEkn+Z2XfdyR 3dwAAAXu7q223Jdkk9PLvd0lXQATxAGiShb43u/etvcd3d3d3AH0kkmwF+z2 ZeAd3d3d3VVUAAAKqqW2219NkZbsgrfNu+skkkAA1I9mH1z7KzNgAAAAAAAK kkuSJ1UqwCYzMz3tuqxo9JJMkAAAE/Ssz2EgAkkkkAAMk9JJD0kkyQAAAkm5 hJHPSSTJAT9JJ+wkkhkntzCJ9N/bu9JHd3SSO7uH6Td35mdu793cAAAAAAH6 SSSd+kkknAAbM/ZmM3u7u7gAAAAJJJJJ33d3d3AAAAAAABmZmYAAAXK9l5n6 /11mEAAAAAAAAEkkkgLklSSAAAAH6SSSR+kb2/tvO3t3TgAAAABkfV199t6k 2AAC2+3d3QACu7q39upIfpJJJAD+/d3d3d3t3fb9Sr3927eTp/AAAAAnfd3d 3cCqqgAAAHd3d7Yk7od3ds2Rknx6rNn0kknADgAAGSZJ6Q7M37327u8ASSSS tV3lkABs+m7und31r/VfpNl7sAAAAAACqqgAAAAAAAAAJJJJAAAAAAAAADu7 N+3UkAAAAD7O9SjQy/3skysk++grE9WZ2Z29Jmb727xJm9JJOnAH5u773t3d 6/u7jeq7tjQAeARGW9MUgvcSgElI223KV3YAsxdmA2gAAACvbdfV99aqyTOn rr6+9LyZv3b2u+kkk2cBWZmYHcAAAB8Hd3307u7gAN3Ms/JHcAP6SSf39/bu 75JO7e7+Jv3bMp772JsCqqgJMzMbvd3dzu7u7uH3yr/fXdj5++94AAAAADJP Xn2HZmZn6bu7u9OAAMk9JJAAAHXd2wAAAAAAAAAAAT9WZ7MTvpJ7s9d3r2yS AB/ru/nvg+/ukk2fwAAAZJ6SSAJ++zMNJIAAAAAAAAASSSSAAAAAAAAAAAAA AAAAAAASSSSAAAAAAJmbf0l/TuzekmSe7d2kkAAA+klHqFpH3wAAAAAAAAAA AAAAAAAAAAH3wAAAAAAA/SSSSAAAAAAAAAAAAqqoHd3d3dwABdfX6ffSZmST 9J+zMVVUkgEyT0kgAAAAAASSSSAASSfrN3dAAAAGPfDAAAAA2fSSSAAAEkkk gAAAAAAAAAAAAAW2lr3Bw6lJlbbacttzxUltcCoB7+InVL+/WQBn92zx9ZNh JJJqlttkkh97u7AAAH6SSSQAAAASSSSAekm3upJ3d3cAAAACSSSQAAVJmSbd Hdck4AAD74AGd3btVndu8AFffX++u7DPSfpJnPpO9I6ZI7px87u7uncFVVAA AAAAAKkkuSA/n9YfX2z+7p38u6pWXdju7u7u4DPy7vreQAAAA/D9y/XJMuSA AAAAAKqqAAAAAAAGVVH7t7u65M37d7dFX4GwAAAAAAAAABee+vO39JeXdbns qqrI4AAAAAAAAAAAAAAJ33d3d3GyUXmAAAAAACqqgFUBIAAAAW22229iSCWy OMtiyS7JJJ0ls+b7d1OuSVJIAAAAAO7u7u7mz6T76SQAAAAM/ZmPwk7MzM7n Dnd3d3TgAAAAAzu6u7u4ABckqSQBP0kkkAAGZmZgAAAAAAAAAvPszMAAAAAA AATu+97u7u4AAAAAFfAQAAAAAAAHXd73e7d3gAAAASSSTOnpJJwAT9JJJJWl rIAAAAnvFgKkkuSAAA++AAAAAd3d3d3AAdJJJvSSScB6SSXpUknAAAfSSSbD 8fXd1YAAAAAfwA/gACqqgAAAAAAAAAAAAAAAAAAAAkkkkAAAAAAAAAMzMzAA APSSTJ+3d+sy87pwAJJJJAAAAAAAAK7dr++kn939/f38AAAAO7uzft/Zmd0m dPSTZ2/t3c3QAAAAAAAFVVAAAAAAAAAGzN+3dJwAAAAAAAAEkkkgAAAAVJJc kyfUITX3JBPmlObbuRJSnXgkGi38y39v9mfrv1lrm938Fx7d3cQAAAAACqqg AAAAAD0kkyQHpJJVVWSAAAAAAAAGz6SVVVP6f38B/AAAAAAAASSSSAAAAE/S SSQBs2SSHZmZmOAAAAB73gEkl/SSw++AAD3vAAAAAAffAAAfgAAAAAAAAALu 7uSSXd3ckA97d3e7DoCDvRthvZZJFJVvFcbbE9rA63AD998AGBYAAAAAH2b9 u13ezM6cAGSffekkgPX9VDt3d3U5ckqSd+kkkxPSTOSvpJAkkkndd3TACq9X 0u7irrvTFbMzO7jfv2ZmWPuAcAAAO7u7u7gAAkkkkAAMk/ZmG7AAB97Myrwq SS5J+kkkkABUklyQAPST9WYTM677mSAAAn6TP2YSQAB9JJJsAdJJJM6ekntv azJpAANn0kkqqqAAAAAAAAAAzPVO+7d7pwAAAAAAAAAAAAAAAAAn6SSSAAAA AAAAAD7W+np+3CSQAAFtttHaNHW+bSSUbm+FL44A8qJDkbgX/l3z4SQKqqn6 Sbuvbu9MkAAAAAAPqr1AAAAAAAAAAkkkkAD7P1ZvsGSOAD6fpJJs7u7umZmZ 293d3d3ABwAAD0kkyQAAAADv3dknpHdwAAAAMk9J7N6TK47h4AVW+bxze6SS Xu7iSSbcy2qz3d37u7gAAAAA++AAPxgWADfeGH3d3d3TgAAA3d3d0Hbu/fbu oAAAAAAAAAJJJJAAAAAAAGz6SSQAAAAADZ9JJIAAAMzMzAAH8AP4AAAL7u6+ 7u/AAAAO7u9u8mSb27u7A7mZlZ7L9JLuSA7u7u7uAAAGZmZgAfu7u7u7gAAB s+kSeSSO4AAAAJJJJAAAAAAAAAFVVAAAqqoDMzMwBVVQkkkkAD9u7qvlyXmf ZvSSfipVMBnd3AGZmZgAAAAPbVDK767tj9I/KozLtd7mboAAAH3wEkkkg97w Lu7vvngPe8Abu7u6AAH7MzMwAAAAEkkkgAAAAAAAABVVQAABncA3u4AAAAkk kkAAAAAAAH1VK7e7J35L3ZHd3d3dwP4J33V9393Z/SSSO4AAHm7t7uYqbbUk kna23KSTeNJMfcWTqSUm7tt93d18STAAlVbJLbbbddSCRr2SSdvcAAH3d3fu 7pwALjMymHfszMzKkkv92ZmZ3t3dvd7gAD0kkyQAABJJJJ9JJJsC5JUmnd3d 97MyrzgADMzMwAAAAAAAAAMy2TEklU8bdRXVzySSkskklttsnc7u++6+7uAA AAAAAAAB7d1nxu64AAAB3d3d3cAA7u7u7uA+kkk2AAAXu+3d0Hft3d3UAAn7 136199+2/v1d2d04AffAAAAAAM9vt3c30kk9p+q5vud3QAAAMk2fN+bskAAS SST27u3uwDZe+zC49ziHthOxKSU5m7ba0klEqy1VRUqtu9jJAAfu7u7u7ld3 d3q7uc+hfd2z99JJJ3AAAAAC8+zMz7GjN+rc9l6WvPZXqvfvXmoAAAAAAAAA AAAAAAADMzMwAAAAAAAAAJJJJAAAAAAAAADMzMwAAAAAAAAAf339/f39/f39 /fwAAAAAAAAFVVAAAA/d3d3cfd3d3dwAAAAAAAAAAAAASSSSAAAAAAAn6SSS Hdd2x+/+fv8/z9CSEkP+CSQkn/pIQkhJBAkkkCQ/3hCEkJIf+ASSSBIcOfvj +v5Nv+WZrn9d6G/xpk2sxcv/cw9uaTchYvO3fb5lNzHlSL6Aw93raPGdvKoZ 553El93dJbbbbb3dbp7rJITUkrbbUkkl6093IJJetskkludtmW2sRpETvXtP dvEAiEoLsmO9d3fN31jmSSSW0e7sS6egC7u6PndPe6umZmZ117VZd2ODd3d3 QAN3d3dAAqqou7uwBmZmZmZ+zMFVVAAO7896qqjM/ZtVW7rveffVein6tv9d /tEAZd3abP0657xJfVLl3TnfWmyNvrSLq7jfG0QQ93dyZmTt3qqq3ed3dzd3 d3QAN3d3dAAAbu7u172g43d3d1fvDt7u7u4HveAACqqgAB73h+uqkmTs9J0a dzMm7v/U7u9732ST93d0ndN79V3EW1tvu73M430pJJIAAvclQEhbJUkklbba kkkSSSrZMySTu7pO7ulvd3W2SSSJJJL0ltsk7u973d34ADu7u67u77uABu7u 7oAADd3d3QEPAGEkm3h9g3dHhCdArLJKtl2E8TUkklbZM2SSMkmqNtG3zbSP MNUnTwHWNFpLu7lvN8Jq7qraklu7W3mW2palIkTJKu582wAAkxbLl7u4kkny 5DkiEliQGpBZltgAA7u73V5cwnnVEk/KZiQ7luTjzcTbJJJFJJdttSR5evdF e9JBzL+z2Zh9JJKqqmwDd3UlbbbuVIPkGe3sechxG4XaAAJbLQCt0quy62Pn 1Nx73oqqv6q9bu7tNSNJaWqJJF2oACTsUJAHdw7uHEARVdtoAoGy+6Dg3JJC ABNeEiVSty0kkmSOTt50d0j6+3NAtxa9xK8JJl6ToV3r3d17u62202/jET+/ Ikk1JJKz9bUklxACvdxFtttoAFbSSzGiSe7S2Skmkkk7YprN4VKju6gt9xNJ MUykkmIJaSZmXd2x2SeyTK201PPlUAB3du7r76SN3f2WJd3cntqrL623u7vW 0DMCQ0eSeJFxRJEkkqQffABmZmZ98d1Uu3d3Sakk7d3U0klEkpfLj4gIAyyR ubslvrbbUkEs1Vrugh7tcm6jJeKQ5tgjw094WReKA5yRRJJOJIAAJ1LkwObl ltrcklVVSe97v3ei7WB+Bu5nWu16zLZbalkzW6eGCPyVkiSSWYpLSSSZJG1W 27JakraScxojwtzFdx5lsauehNXiba222SSfZh21tnz8PE5pJJAXIkxEDT3O AbZLW7bbYkSbmReUb8AAGAJywwbVB1i8s80l3dygAAu7sAHd3d3bu7u6kkmn d3Lmzr2VK9mc18PLQtmTCLW3Mnjjsy1ZIgAJejO54S7o92aY3Io7KSShHNsI x3O7L18HLcHjQT5L3XxtVd9vY4Qz07AVpDYqWG6yjDn0I3tNdHnJmezBCRxn s2Z7fR+6QrEOO3BHynrx4uY19o14D97z++zCCkMzLx9vuc8ezfNc+98/el3f nWz4gpPZnvez6+9Ykd7Cpyc48VZVtnzy5ynvvd3LswN9ioh3vKy5H9cucX77 1AC54kOXx7N5vn3vn7xXj8633yQUU3S1gb3u9dfeznjXtXN8+989jun2u9+Q laqKPSW2agmoJqCagmp9ne9brvPXzvr3e+fe+fvS8pmufcAtWRRVVVW73um/ u5v7xYrz3vY/d89aL31UqVc2223ioBfJsPfe7u733kltxVdza0KU+kAuWfat 9yKs1fKgF8mwXyo2RhEwpsAABgIvr4a7m+vnPCzOW5840Tj3uAAAAAABgNfF A18mMpfJjKXy53pplnr9fu9TyPc8mIWtu5PHFbDjaAAc4CCXd73ZtTcijsA4 +4Jx1HJnb3Z69Q4bcFWPGfE9fOWqvOk3AQz07AQu0NgnBNVWwZ6F72rVB5a3 m77UWiCPZtz2+jRsuuch6tHp7Rz3RbvdW/VGiZ6e5r5FA18igaRQV8vvgABs AAAAOybvGVY3uW54ze9Xb87fVPbsvgC/pGAAAAAESSSkkAGviga+VW8eitt7 eOeMzvLt+dvqme2HNfIoGvkUDXyKB/JFBvwq+jki+UkkXykki+QDbTzLubHd 8Z9fPfTvNM+v1b+y3hRQBuSSS7sAKre+Xsc3xn3Pvvq9zTbtZ9y3wkk0N3d3 LsAKKG9s4nL5y2fc+++r3NNu1n3LZRQBJNCTQ0WQtshbZBprV+dLvZrWP3fe ftlePvuOpBZBZBYKqqqsuXVy/Ol3s1rH7PvH2yvH3zjJ0jbJbSFtINpBZQ19 u6drvZrV1rPvvH2i/U7eh5QFIKQUgoDrHK/Ztd6Nax++54+2VMPuk+T4+iCi VIV1zzmzmuHd++3MPbzm8zz8oWtu5PHFbDjaAAchwezpdvDwzeUstde6h5Rb E5ky73rezS5bnU6uR8D1+ctV9qzE+imHZoRfaOkPHA9VUGege9p5QeXtZ+xk wgz2bczN9dmQHrunlnsmzWsfYe58fcK9fbPtfAETRId3zOX50vNmtY9z7n3n gp7WqQlgkmOXjpfbO73p9nPefuFT7e/sGApBSCkFH4Hb7ebizCfAdl5qTK/b nqTvuzX2YMynwHrVO9iKXXYN9UqvWpF72d3sRS61fLuVKk/vokCaxZmEbfrU i3c7vYil1q91VSqkooowRkEZBGAqoqqqqqquzftucX7ZrS97z3vuGPz9znvC qqqrBEFVVVXtoS2hLaEtoW1tttthmelG0q61Iu7O616vV7LzuG23S3LbbbVV kFIc+3e5mdX3eHNndc99sr59v73mQWQWQWQWCv0tYLIL773KbEwsYvw9NWA9 zwTUbZHcnjmq0RY2wADBBnS7ve7NqjkUdmADj7S3HOyZd702tS3BOqD5vwPu fk7eV9qzE+MyYdziF2hsE4Jqqgz0D3tOqDy9rfvZiLQBHs25m+XoH4G32tc8 9lPiPWqU++fvua95h9AUgpBSCVCAq8rb33q87vR5fc4uj3Ofe2V8aNXnLVWC ixZBZBZBSaBYPRaKqqqKVIKQ5PXuG9284c0b7z3vrz4d7zwARgayvSxZ6txZ av3ujrVS6C+aSPiu4FOrMObm/e+1Xo++SZE8AAkQAPUUU2fa5mt0vOHNG/vf av3sPs7RRRRRRRRRTuj77mG+W9707s5732s9T7fKKKKKKKKO6uWre/c+1Tfb fbO6N7937ePipveKoVQqhVCCCqOWqyCOpw0W3lror93esrlS9c0dGoKoF8gq gXwVQ3VM+CqAENp4kgQL5MoF8nno1tS7Xorvd9ZXKldxpxIENttil3YCCAc3 uc7O759m5N76v3Lv0rp3kbYXcnjm6rYMaQHg5vR5AdzO9c3a05G3ZgA7tCcx 6hnrvnKpbnaZWc5vw4i/S2p+1eT4mbBq7Bz3e8eAxTadtbMcdvuixPTU7eTX sTyKvMfRdy4v2VPPfte0Xftc9xeiZ98qiiiqqqO9fJ887o9o3v7V7v58Jr7S q8AAt+tstUbC2hgS5QhN6T7177ZzRz7Od38+E19pVVVVURz5Pu3ndntHPs7r Pr0T32lXSqqqvxLbDvL2n2r7nD7RzuZ54J37WhVVVVVV17tPfX3eH2jnO69v onvs0PLbC2nAFAkTHEG0at4ZlidmfVPrfc3PZOdv0zkqd+zOABW5qCagmoJq Cagmo+fVPre7ufZOev2uCd+1zQWqqqqqvs8fXvt9fuXnfb2EfPpT77yxVb4a mfQ6VT0Gyj3xq3czMv3vY/WEbkG+Acovrh1c13kBm3eRthdyeJdBnFYyQApv aU+uZvrm6U3I27MAHBPI9z2ZiUKczry2vW/PizTnutr5PFnHXWdHhDW5Z12t DxVmEfnb7osT3aXZu8+1PYvCFixOV2G+Fb9LK62Z7eZ6++398QtparABYAR2 FtIW0+TbXyba+WTxyH2Wtt3nr6Ra+9ky18gBfIA1fKSSL5SSSSClVVVVVVVV VUk1pVVVVVXWta0qqqiKrrWsOeAADe973sUVRQFVVDlk9Sz6DUhOOjyDrCEz MzMr7t3czMzMxc5rXLa2rWiq1Xe960qiqqquZrWhVVQW61rSqbUW2270O7IW 2QbZBtkLbIc2+Pvc3t7u5z2/a5dnde+zcgsVVVVVdfPDt7zZ7d3z7ftOjue+ y5qF8AvkAL5AC+XpJF8gkn3KqXyqiCkFIKQUgpve9E0CkFIKQUhrWtaIKQQN a1hDMzCHuO/sw3ft7yutmzl233i/cvkAL5AC+QAvgMAKAikki+QSRfKSSL5P xyrti9jvZldK++bftcv2eIZlIW0hbSGZmELcw+Vhc0KqXXC83o+5d77s9p+H 4+12/KIiKqo/bM2b3sz28zf2z2rfh+Pt9vyqqqvYS2ktttPt8NXnNnN3e/t9 fbfh0fa79nQaqsUBVVXmFPg77m+679r00fc47rxTeRthdybhzlWcRIAT3mnp l3O+7N0puRt2YAOILjEz2Zlk8i7bhnYvcw14JE1Z7rE9OYWTNWGwibpXAZjR 5W8La833Fp5dK1ma9xPIvHwt3UX25lNa9o7q67o+x+Hx7X1+VVVVVNfapq7t 10Z6J9VeVcunml8lvWvYri9HLi3o9vsXuB33vT32e7yi9EUVhOp023bj8Gfk 6AAw3ETN/G8uub32vnZm/GRYyJ7Xj2XXN77e3zw1zc6KAwgGwPb4O+vt3Xtd 89fHOb0QUgpBSChwBSCkFIKQUgpLSIbN9N+Lnddzt8+NZa+VxdfLhmzjmtTL aSv5L5OotvVBhD7PLz4loVny0hfcMW8NfO7yNsLuTcOcrYsaQHg5vRPTMzfX N0puRt2AAHw4sx6pkzczuKbzlys9BJ6ECfbbFdxVht9zysKhrYXGt555WYY/ Ou0rLrzdvM59E8ItmVa0WIvvcoRYPSss41evOu1OXW8FVTKrFpe7uKxDq6rS trdREhS9O7y3usvdvdXprUqgsUh9aQX6laU6Knyg31V1mlefI++QX1qny0b5 Hm/F6eyMJBEABhzftjfGst8j7favT2ckWIoecAAtwl0o88aX2UvsevfZ4VVR oANoAW/W223Q8+PqPqyn2V7qvu59VIAAAHu3wb8aXPqP2/Xz4+9pVVVVVWgA Z6XRCaVLfgVNB0dl3bsDVELuTxzVN5nEAifEPetc6vMzcw5ulqNJWgcfEs+T zw3cLbbj9yruCdJ5ceM8M8LaZqWRevx2vCoay2LOfFQsnHjO8V2Kqr1m5r9U relr1lruEXVMRi21I3kb8a/den15sFVVAAA3W5z6fYfZbl937PT77OADQACi sy079PYfazM+1993XnMVVVEVXg2kE0c9j6271mZ3Xr732XPnvuLbVVVVVVba qqqqqrbVVVVVVbaqqqqqrbVVVVVVakFExIL1VVVVlSVVVbaqqqqqrbVgW0hb SFtBJWQ2cPfHtW71mZ9r18+Ps+ekFIKQU8qkFIKIVAQZBYwUBAw2PvjmW71m ez6+fH2d5fBFkFILIKaFIKQUhBqiq6+OHMX7Vu7fb+3zXnx9htVVRUVFNmjv x9q3eszPa+u/Xx9n3qiKqqqKoCi7V6N5G+K7MNXbj5tgAAAAAgABtmSSNJXW 01fbda29gByzMNndzSX3xQAAAAAAAAAABspXgCD2r4FXQdMCu95q2l3Ic1Tm cSCJ8Q96yugPMzcw5u2KtJSgcfVR4nM8N3DI27pquBtpHjfDPC2makOwTX4a eekZp1jGtvjq4zr1qxgrsxbwmvBi6LpQ4t36IuqxrGun2W3sAfpz9tnT3vAA AgKSSQMpJJOmAAAgIL5UyGZrWiCkFIKQUGHOXp2n2z27fQDZ5P27x73opJJ9 JBAC+QAvkAIBP5L5Nv5fNtut1Wvd9kafQDJXZu0dwAAAAxubnc1vD2D76fd9 7GffCCAAAD7OzE+9rmzI2dPP22d1+qm203S+tdqmIn2XXo2uXXhqmVVfckq+ W3m3ojap8nu5XbsXp1VVRtqw4A8yQAbAA9kzhF03lZ4x+e90fO9c85mYZmYB DMy221VwCEGnQO/ZrtdFy/dy9zl93uaPtYQUgpBZySDJUgpEL9dvB+v3MveP 3e5o+1NK5mZmZmZh+9vnyLrG6bjdfswzDK2enegP22Ri2wep4jb41mYduAzb Mppud6n7sPXL/b7OfZWd1bm6qqrgAVVVvXSmDt3d3dA3d3d02qqt3d39oC23 nbbUESTIN7dure3gASUvJEmpuffWKqqI6vVVH3waGPtz9NwuSq7rLJHuzoJN SSQ7VeIAtsttSSSVoAbu7u6ABVVRd3dgDLu7vMzMFVVAAO7757y7u7Zkk+A5 t3NzbmSST17uttdy220kklpFgBqJJd2p+ktktFtbbRuvutzLJN3ZJUTITN3T JZJJUkklbbbbbakkkqAABu7u7XvaDjd3d3V59dDO3pJAe94AAKqqAAtu7ttO dz8y3DJKTbbCSR+/Vt7uuT93d0nSeA/AW2ejezz6J6TAaiSSAAJ7d3b3YDMz MwDd3d3MzMzQffB3d1vd3W3u7rbJJJEkkl6S22SSTd3u78AB3d3dVVXdwAN3 d3dAAAbu7u6AAFHszMzq93bu0QgCstJJ222pJJckuSVtk9Gu6CVNsi0kgXuJ FNz2RpJJd2rXh3px7qYWklu7XXmW2peSkJJklKAfBspJJFWybuyEknMpI7Tx RSCwABFZltdSSb7t9ZmbO6tJEs93cd0+mjopXJEiSQiQ7EzUkAOKkvbsdko8 AJYkku93cq7bbUkklbbbuU8ihg5gPLu6y/fZC7u744AK3T3Zt33TMPbr3d7u 61NkWryVSSSiRDtegaA+7Nd4Ek93efkiSu7upuy0pImTM7ndJbsUnd3Tcek7 KbW3aSSTJH6bmq97uec+88d77p+nLvnfK7q+Nme961VVAL+AA/fokklEkkv3 621JJHu5Xu4i2220AAVttvMbsuSSd3dJUuSTbaSdslY92kEWqjdvEtgJUk+i VJqSSIAz7n3vvJO7ujd3dO+AAL7ukn352N1EjRZGAAyt7u6S220kkjDaVhLH gEmQ4IYAAOSkhzJJJJbSSScy+vpO6gWSRtVtuJJJpJKJJDddCSUbuk73u4/A bu7u/tTV2xtV4e9uR6oBMgd7hvVzwK9O2SSJLyTI2cgnW5Kqqk4CSSe96SLu 7/WAH3wEisQOviQbXK8zElCQcLs9JbakklmKSAUkySSSSSS221tO0k7utIk5 luY8u5N3ZI38wIfEyRttskk93cbWl5HweLNSJ7tJAiJJ7u5zvDuslrltts8k klmWPzb54AAwAQ9LYr68WvS527yS7u5UAAPd222222SSSJJJKtttWySKLsbP nhhe1/DCrvHdmG73kbYXchzVO8ziQRPiGOFlNAeZm5hzdsVaSlA4+AWbmbuI 4ZDINddwRtDUZ7c8LaZqWgT2saeZGA7zeLL7FonXrFjmOqt5PPalYRdCotm2 oVVY043bH667nM0d1pVVeFSCz4ipKkO2kLaRY6tPqcofXWZhOu8S5L76l8Gi iSSUmrbgAGZn+8SZlJqSCyD8KQUgpDWsMIKQUgoJMykLaQtsDxWl029tv3z3 ne6u972Fq+C1Cqu8dF8vqE+6uzDfrvsTwF8gBfIAXwCTdVVA1NaEku9vLl37 mXfee97uTnN54ANSD6pqXbWoNQK1Kc12fM/VmfWfc/fd7zl0EWQWQWQX6DAr WQWQWQWQUEWRh3nrszLe3Lzfu3r3nt9ZBYfiESZlkKhBSZJJEKkFII0lW+7k FNdQ7v27sWdq2tXydL5DBfLMpC2kFIKQUhnfd8Zjfbus33vfd2XeyCkH1IW0 hbSDCVpC2kLaQqQ3aQ939fcNY3711n3Pvvd0b3uB4IKEhbJQIKESpBSCkFIK QUmez71YwAZlol2z4YVd46Oubd7yNsLuQ5qdpryQQ1I9wGyU0B5mbmHN2xVp KUAA+IKzt3Ek24arjSL1G+FhenxAftS09SO1ldxyyd3szo71mrXy3MKDspmQ H2oDO8JPHwWZ2rUPDs1XRzVsYN72KQUgsDwSKBaHgFIKQUGIW0gpBSCkFIKQ UgpBSCkLaQUgpBSElQCChAihIFhrfft4+NVv311m/ubz2uASW7jt0ABbYQ6K QUWISGZSSS0M17fXhrciA6eUsaH3vTHpkmzw3IgObikjPx+Ib8uWstKBUgTO a7q9NV7zWs933Pe9zuiQmwAFkkiSTN+9redN17rWs733Pe93miCkOpBSCkFI KPIEEy89m72ar3mtZ077nve73cI6BbBgVIKSwQqQUgpBK6z3nDK85rWc57nv c3whvXdZfGq81l5z3fe5zjDFVVV9faemV5vWs5z3Pe93ndKqqqqql4dzKe5c 7e8msLzRO9nS6h7DbDZDmt2mvJAzVGhUEqTeD3M3MO5Yq0lKABugtPBu4Wiu oeA03Ub8LC99xLHdcRYb5cez3DWMsnd7GwDBemHZx30Qutb5cPaYWj7T9xdU +JtXKhQZiydM9uTbbbbbfffAC+5UlJD75AH3yAF8AAOOXWSoUGKz3ee7zXdl q2223sJJAzM3jXQAGXG0+ZQOBkdSoUBivL573ZHOepJJRyMoGUDKBxJJKORl AygYqGDobKiSSXVcy3UqMeEeZOmdt5aLrqKKKKBlAygZQO0kko5GUdAjRUGi i5V3lZKhQXmTpnbe7k6oMoYOi0kkoSoM1yMjkcUcf1pfVSXy+pXLQ7a+eW1c BBCsu7lWh28cwydM7bjU57GpHI1I5aSSViu3cakcjUjlpJJWK7dxqRy0kkrF du/ySS++sV27eOoERjrN/cfs59zuqa9ffSAEN4b3d8AA5IE5o5y82AAcgBEg pBSCkFIKQUGMVhBl5o5y1nd9AA1qZrpJcNOtbAkJhp1vUkJANamapjmfbN93 yZcsnZnjOzaKyNAeS+kqSfJJH0knyS+ilSNFBF98vkKVI0UE++QpUkFKki+t fv2+TuO8/fPP2c/d68xf0AO5mQkLaAAbQAEEABQAEzLMhCEzMDIRJmUMYyDM ymSIyRJmUC27/ft6PZtV/fr5+zn3ecuigBNQ2AUS95xL0xkbH8M6LjO9nS7y NkNmw5zdvGvLBDVWgeJtN4Pczcw7lirSUvd2cWU88d7tTafUe4UXab4W1TQp 2vxCOBDs56fM5Yu4ZrRCgvTPH2zjvpiF1rewjvaYWj6t/APMsKH2nx5TEKFQ 8CH7733gD4A+UX0knySAdOfffJDG22xJJL4A/fpqdc6s/dWT9M9u5e2JJJWl JBJEYgAYvvvvvnVkkkkAAADJfvdv2FnKz3b7dwsjAz5fKBLSSSkkiSSUkhQM CJL776gkSRattM970+8VZ5X058+73m+GsAAzMtuSEzMKoquS6zD776LK9Kwm 4p0z27lsDHISpJISSB98gD75AH3yAPvkAffKkDPvlrnvS/vFYZ2TpntuWz5A AAAWlJJF8pJIvlJJEltKru7tfKSSL5OSRfLbv3pn2FYd7pV5vV+zsYVkFCKK qqq659v7c9jzPvvd3ea5q/YvpAtVVTUysBvPte5PY8z73bbyZH5fJl+90XFY L3u23kyPy+ElVL72fT3ve+B7mU/XWhyW1fDKhnqJd5G2GzYc5uCLIwjFWgeJ lN9we5m5h3LFWkpe7s4sFPPLdxllSaarhbL1E0213QtxE32nAhy0NcDki7e8 uekGC9bvkn4xrzM3Y8HEb0fslrkJlV5bfTqWSrnfcz3OZv4oKQUgpIbW2qqq qqq21VVVVVW2qIqqqq3uYqqqqqo5mYqqoiqqv333p9jed+5nuczf3c4qqKiq rmZioGZTioKq5mYqqqqqrmZiqroQV1rMVRFVVVzMzwW0tVYLrWYqqq7VVdaz FBVVVzMxVVVVVXtv3ftz2PO/cz2+5v7ucURURXL0Mq7EKoBVIQFWuqlXRSKq q3Lgi5atq1VW5mKqiTMpDuZhC2kLaQtshv77u/p7T3X3M9vub+7gdJmULVoY qjmXFVVVVVczMVfELaQtpC2kFIKQUgpDWswgsmKq21VVVEVW2qqioiK21RFV VZUgpBSCOUzFVVVVtqqqqqqttVVVVVVtqqqqqqttVVVVVVtqqqqqqttURElS CkO5rWiCkFIKQUgpBSCkFIKQ1rWtAkRSCkFIer9nfj2WnfvcMufZ2ECW0JJb ZCS1R+tq2ttvuH3PaPsTv247frr6UAEIqqrpv7O/TPsqc+5PXzWYqqKoKKqm e7zxr2k57h7OazOK+Tr75Uks6by64PeMXTbEl5e9vbVeg199nD7Ndv3o8VVV V3bYW0hc4868p3Qe4a58GgdUcu9EnDZsOe5sjzWNhFKtA8TaduB7mbmHcsVa SlAABZb8d3G2WxT6FUvSdNNvWXfcvATTgeDlvK2Su3gWPXJfTxXNW+LeV093 a1hE9m+y0chGVXtvvWryxrfGrxNc6L5VS+VUQUgk7v77nxres77XD32t+ugw FIKQUgpBSCkN69fGe+7zf2+OvfX68TXL4MAUgpBSCkFyDAqQvt97hr33uZ1v vu59kdazuEFIKQWAsikEM3v4zv3Ofad3PffY2fa5npYAzoKQWRV48ZzBUuq3 rdu/dfa48z33s97wbnuNSIdHvceMpO7OWoW5yJ7Mueo97xTulPPPl08oELDX vbM19zm9b+uvvvsbtHXM5IxZFgLC65zpo599zeuuffa39t1N/XqHCpBVIKQW QWAqrrm53298Pr1577t12Crru7ku8TbTZ5mb0jMeRhFeVaB4m3jdMjztx+tj bStAART5+G+SQ5MuvxdD1HTTbbnniXrUvcsPuU74gE1i7pHn3RDCmLzz7pKM UW+XD27AzV7Oni99XR2/HPt65599hv7Pmch1j6EtWGuczPub1zzn32t6+18z feSCxEFkUg+VVzfe8v7m872r++zefZ9Wu+1qsoAEKqqqsuYeu5nUe9Lnp6vr 3lSqqSxUqXyVXmuDpBTzrQRRTv2wZmZmZmZnvszMuZyG8A7M60deo36XMzMz MzMzMzPYEtAFszrQRRTv0uZmb997277PeWeOrQA7M60EUU794PtBzMwhmUhb SFtIXMwhlzIH6M1263r375z9+1vX2vtln2/0kkIWrQAID6SgEBzKTCSREJIm ZcCIMICgSQQzLMkFAESAIZlmBJFkgkzKQtsh7ue3+zf7n66/ZfZvRZ7fxC2k LbJ+IQZmWTJIKARYDmUyCCQQzLA8LmYTUkBQBmZcIAwMynwqSBr4VJZ+5U99 6oe/P97u7HM+njJVZ7Zd5pWGwSdJNOrGgjFWhEEqeN9pkeduP1sbaVvdyvFy LPeG+LQtmeNXgkFtN5abbc7GlEKsPez3IedYu73lqfIpi8/Z8YoK1N8+Ht1i RV51+tNzYYe+7vXfOfZfZ7RZ7f0OwUQzLP0kgoGZgYEzLJAgW6wACZmYAAGX MgQiGH3yoBL75Js194v9cz9R79Dx6J/Z7PygBbmEJCQtttAIVCAQEQg1V55z 33f2s7+c/Ze57RZrYiqr+IEtskLXlyFvDWdfvta5859l7ntFPzriqqtvQDZJ AG2qhD3rmV45v3p60/g1N06obbYA2AAARKGXp71zuOb7hRepSZaUklBVVVa2 26qoBtXPesXccPvXMnq13aqqqoAAHK5e/bud9fry/Z7caupVbDQ0BRRG7uK3 fvbud44gbE1tS31NuqqqVKqr6h5L6xbxxOfeHnNz2ey4Uzl7ygPX5nc9heu7 ySkNj05OEjpVuWiGKNAky8L4cWxnbj9bG2lb3cvaEw8z4b4pCSZ6mhJYBopT y4Ay4sPZ7sQcfC9o9gbxFMXrs7yt9nJF748PZMDFC1memZyXYHRWe9H16HdF fUl998jMy1xFvHEN6K+qruzpq3unDpB6Lvvl7733kuMBcooPWj18l99976ZN Tve8+zvL9fvnKzl/fZe+1dVVAAQqgub399nu1fb985Wcv77N9oAAAKUH3O13 ufZ3l9v3zlZy/vs32goFNtttttN6gBfLMzfevYePeeVMPehe0akgG2ffAC+Q AvkAIBtptVFe+9MhpvPKmHvS1qqqqqpttNtvKIAZU96ZDDfPKmHvS7pgAAAA AAAAAAAE15zQLszumfbj5pwfeZmd3X7tPThJKh0yMs1RoEnbR18OLYztx+tj bSt7uWhNNZ475NiOZTc0JctbSvlJlwALKpZr8c93oFdgm6PYG0Uxes3wqsim 898+Hs9y6g6HMwSvhmEXsQg6dvPKmHvS7pgAAABVVVVVVVO2e9MgELdePbWT 2ZmZmZmZmZmZmnpeA4K1POz66+7ut8xBBBBBBBBB3r31+y897fKn3ZV19yb3 zEEEEEEXMDwAAPsJJB+9hJIPvvJcZxHDndWWT2jKCS4gffewkkH73sJJHgAB 4AAeAAHkSSffHCSRx0k8MBJAzrzHCB5Hr9ZXWrq7zcl1d3Ltq7uRSSSSRgMA AAPvgD75FPjZ0vb93By6V7Vk3t++QB98gD75AH3yAPkgBgAFkl3Lu7u868BA WbJwkGUHPBQB58SST4kkHPEkk+Jwk8fEkE+0k8T7STx+8DxOn77w3CSD732Z 14CAs3HnLsvDBWOF+96ZmbyWEtHyslxli+SVkuMvdHMxyZWDmY5MrBzMcmYk 6HMxyZioBuZjFmYTMZizBeIoLMe8vTe09pR3piWhLeWJaEmYqzHMxiu2ZmEl ZjmYxXbLtmVmOZm8sS0JbyxLQlvLPYTvsmN6j3eumrbz054LKZ7gfVnWfjuN zTSn0l1H2cBhjmbtxXvGTn2zO8m6xJLwDrU7u6W22h73vOu6WDMzMwBu7u6Z 1e3dzPyfABXoeEy6v651/ldPfXJuTd3d3M9mZX7QqvH3wd99w/AZf793f69N /cf07u79f0ke7Okijbb32Pe7q7bbSScwABu7u7oAF3d2Xd3YAy7u7y7/We94 7gA7nve967u7YSe7uJtZIFzL5Wyb2d1tttkkFJJSRYAZyJLu7kV6S2222kkk 7uy3cts95Q3czuzO97O53T9Obu7u6ABu7u7oAADd3d2qqtAN3d3du/fgzukk gKqqAACqqgW22227u2rMSSE2TrxkkiSSS39LJ+3bmY7V3d0nd0T9y/EVWr1t 87ZnbGSal3dCAC1LbcpJBNttqSSRJJKt2n3wVf13cVVUK95u5u7mZmZoJJJK qqkfgASSSZmZmSAc+Dd3d3QAAMzMzAHd3d3d3ZmZlVo8Bu6BSAAikkrZIAPA DBSZJG7jvQmpJNtEwlnp1aENyJttJd2rulezz21TTt3d9726n3wST9pmY0MT ySgUSqSSTHJPdDtSSzIkj2rke7iCScxywnQLu7xvr26O7qUlxLW3ue72c4pX JEiSeQAktBJJIDF229ux2QYAOcJJPe7uMkttoSSStslmVJSdM9ler2eq799J zczMzgAF59mnszMKjhPqKO7t3bZLAABSSSUkSb6PQNpM727Kmm233ckiSgAB 62WkkA2Sdv7fN0cPq+8VWfu9m5WpDu43d3d0ttGgaGkABLnHpq7wvdLp2Oqm gAG93dZbLlv7u78kST+SSSX79+tqSWm8+7qqWODMzMxJJJ99Dnd3Lqm5m7uz Ukk7bPXkT4G2sCAVpbM4nu8YTSTEmu7zp323lJJPOpJJSSSSSSSBvV5JTMbR JFtdgHdJ3d1tktJJJ9bQcJQA8kyHBDFUkkvO227u22222pJJLMtnp3UBtttW ySJJJKttuJLluDvqVWXhJJfvSCBmZmZ98RVLe8PbqCzZsQCpA73DerngVO2S SJRJK2XulD5BIAKuSSKtvd1t93d9RbPc23mN2VIHzD4a3bJcXr7G3BwwRzzl tJJJzLJ3UCyRtyS2lt0W21JbrbZK7Hl9bmTLrtbebmgQ+JkjbbcSSXLcsyPz 8rTnqkyR4dxAiSS3dUvd3WSSSSW2ttvn5vb63ytrJJJAAFUAFWerwadz2Bnu 7jSSSbu7LZJJG7JCSSVW23bJJg2jd913NtC+OvaOy5tMkNmDJ6CTh0eWRRXG 2iSbevlpfLO3F62NtKbOr0uQ4N8V1l9M9tuaOSV2EIrPdVfatJYt4N93hnnx usXB6aXxK55eedmTYduzDve3TdI9yuZBXozPAzoBBQUXsknqRO55vQ88KzUl ywrNSXLCs1JcsKzUlywrNSXLCs1JcsKzUlywrN5zmcsl3xvObzlJcIpBSCkP s5vmtb17XOO/u97X3O7zPm693OOEFIKCBvjea5nGBhFIO+N5rmccIKQUgsBR Jvjea5nEht5bznM4yHOF5zmcSFd8ac5VgOb4nTgOb4nSNO74nT7q0AApy91L Trs5+E0c9qXTV27qXTV27qXTV27qXTm9t1m6Te28bJvbeNk3tut7ib23jZ4n SLN5AKckLi7y3Ioeo9vg9OA5vidfnLp/Y3Q1dS8WT2gtraUiak0Uumrs8Dm+ OE6Dm+OE6Dm+OE9lMJJAoQqXluRTNy5vuxXQc3xwnQc3xwnQc3xwnQWm3e7r bZrUuabNaQklzTZmkMM9rDMCePHBPGXNzddd3dS2VNS++UUkiXyf1JffRQkU RKlCGV98Kga+EMpIQwTKBALbwO3o7y/d0XOve96kbBjY0AFAwACgGwAAB1k3 JPTpmX73cudd3eexgAAAwbbbptt02LDVmXf3r7zO+977J9fvcc6AAPruwBfM np3u9/fX3me7376fXnvVzoAEFJqNp/CBCZlkg36ze/2/uXm9ft63Nbucwyvc 2iRmR7N90hBcz8YWld1tEkyy+aU5524/OxtpZlO1IZz7xQlrzbc1LTrXOnPc q7r1KBzg33eD32cbrpHppfErnl552ZNh068O3y3xwn1frW0MwGe70Z377O80 c507c5z9AgToDGfIDYWDAtgofrZkIy0ISfj3T8e+3v37vMNdN3vOffBAWAdt tbCDWySSNbAg1sk9m59mZkyuTw9ASq0QWtbZ2bfZ3b33vvpIOZcAAjlzMyAB bluAAFcuYABKZmSSAAYZmZjjmXKGQH33tnDvt7+vN933l7nOXz9phISXHMAA 4JJJEzTrQAAXHMJJDWadZA0OadYQuOLpz5lFOn+/YKLeu/PL/K9WPcyZnqvl 8vv0IySCyGadZAAuOYECXHMCAWxVFBZzPs/bPv3Ofr3ftb6Ze85uii6f0MuK 1yAW41q2i1ts54z6637f299zg43tzgA7d3d3YG9Sa16tavMoVZWTZ112bs28 xWt1t0227+TAXwB83VKubzV2aOb7t305nNm+cVQFVVVeFtIYOtdutHN929N3 ejm+PCFtIKQUgpBRnaKKKKKW0UUUUUaVUqpVSxbSuet7hs/fddYTwOup3O7b 7h0gk4R5bC1cbaJJl70vnynY97z87GmlN2rQmzg31T8KLM23NS8Cd1VZ1r1a SxN5Lu3At9kSouH03SwQueXnnZkneaG32YXxPqk/psjuYW9fgwTJi8ETuznB RRRRRRRRTQZmGELSmoRNQiahE1CJqMuCCCZd3BBBBBBBBBLu7gggg0IBBBLu 7gggghS2ltExIKQUhaKd1s2b5vu+mzN6Od4cRfWqqqqrw0Zzz0zPa7x9zezu zSqq9VVVdLow9rm/HfdN95x9057m2228SAF8gBfIAXyAF8gBfIC5qcHMqtd3 7d+7Xu85N+5Oc8AABtvEkkgG3mm5dslV1x9ld17UUNbbtStSFakK1IVqQrUh WpCtVHeHXVdkd9VdnYnOqzk3VMQDbTdN0VQfuPO7qvt/b5nyvuznJ7at78Jc 1KogpBSCH27694v29/cNePu72ezZ6HAZTd9ecX29+4a7X3Tej2woBFAGeQ9+ CaL58J7y9SxN3c8dIihxXpOk4OZbC1cbaJJl6+5cXwzs3V62NtLMp2pDBgI9 Twocvd7CatfURd7qrpXJPMFviY2jGjayLw4tZhd4erwvPiVXvF9UbWas16l6 qemtq5mg9izexA1CbiHeY+OivVVVXu9Ze8d733mnvDWHTU4qqqqqrvmzeGa5 u5yb3s5oOdwhmZhDMwAQFUgzN87eXq+W7dTObnMk30AQqumTUu7ual3dzUu7 vWpXWclxB3919a2/srRfIAXyAEgG2222227bc462ZLrLud33Z3c49ttVVV0E Lal98m+btzK34lw1WsiyfXlU03oFVVDXBqQvUElZe472syuquZc3mt86CqAA AZvbd8rsuN9rJvNc3ucdWoVqFakKgKKqrq749M1u93lNnM1ObnNKqqq9LaQt oFv2e713fa8FfjlezT3Z7AJIZuVmHhJxKyyFq420Yo2Lw924EHowbimXW20s ykn171SFUrozUgtfc77abp0lYLPgFu+5b6hC4PPdKwELrl5DRl2gWTs3Drea sl1vxucnvu11W7eJxCmUheRn2Wj5ffJPInhhvaYcM5ObMmIGHMLww3tMOGcm iygAMnF5heGGtmHDmImjXOZtdGadbkxZ9lRPDKMUurd1MUn2WqwTxEqrq6qc NZObNyAYSAZylwzS6VM4c1ObKHAUgoSFScw1l05o1p1tw1w1rmyZIQ2QWSTO b25o1p0XOHNHN1+4BDWdqcy95jUuN+s2Td9lzQLaZuRwb0nEzLIWrjbRiSQo vsMiztxPLsbaXTagmsHq21ZbEM1ILd1X22y8tSeCfake8FvqILg8HzAZQfTL 3Z2ZWRiwbVmrLdbR3zq/ZHVbPbRFJUTPLZ9lq0l9y+S+NvbmzWnRc6d1ObJg CyfpAZUg0IQWSBk7re3prHC503qanZISO5IWRgFSGkgoIYJoUhq0gpBSCkFI KIVUikFIPF6Osebdb3dl105qam16BbQAtVVWwhbZAJbyQmBIPc3vl1s3t0Xp zJzQb5JLegAczMhJDMy2/Gg1rVtyBMzMkCTMzAhJMzMCQA5e63ddN7dF8cyb 5sOdAAC1aBC2hoMykLaQtsNikFIKQUgpDmta0QUYbZrVIbzLiqsOZzN7zepv 3Ldme7k7qY87HMySqrmUg2wOZmEhbZPAjIa1rQaJrWravHvNXXdTe3Zfdean dhxV9A7mKq8ttvAAMzPdut7dbN+2133l3ncmtTHi8ltCkxx2jJIyY4kK1IXV xIVrNBAUJIKEgoQQxxla85m9cvdpvo5dHO9yb1NvNvdn3vcUvb7fa4hH79ip tN7XmomsxdsgwThs4mZZC15JGxJdb7mznbhmXW20vUk1j1kipnpt7NJEzEb7 rbq2pTMN+5s94cu9jNoHselNB9Mve7PdmWRHHh2vNWuhv3Q5921duYZ40BEY PFezB5XuTAZJIiQgxISETywIs54de3zN6N+92nC53J3QeD0BKl0ATEAU5VVV sAlu++3zfs5o3vhverrO91U1KnxMAMzMAIxAASZlwikFIKQUJJUIEpUBSCtj wvLfa7m9G/cbhOCPtwD76ZmZmZmZkAtwwrxNj0YoPr86xPEQAPoQOezVd91w 3v3E3Z7rnXTm/EG3CRgZlINpDO+5rus9zXF337tOFPvOY6z4hbSFtxmYqquA EtoQJbYQD3n699hrXfuU6U95z7RTeqECW0IEtzmggGta1oIE1rWtBAmta1oI JSST7776SQAAIb3tN9Fc3s1Fi7ovRPLN8pJAAAAAAAAAAQB72O/dFd5lFXkX M+foi4eEAIAQAgC19UkIvlUkIvlUkIvlUkIvlUkIvlmdz6eOvLBZ7y2PRN32 ASQzcrEPCTiZlsLXySNiS69fBtZ25qmXWy0syk4fV96tmh+exDeSFx33W32k lZ25Z9wT7vB76hi4PsWlnl0y8hvgsnV7kwbVm8j3XuIzsqvbjqn67j1oMlFY ZXihdE7h4tJVJBACAEygdUUgTRQAjyShKUi+UJSEvs94caCZdSvSLSj0Tt6T 1JmVEhbUcBRZBSCyaIpEqQUGa1WtIW1rSFta0hbWtgYQUhmY1uEFILAVJTLb SDalpC+06zeuu97fO+a6U9heXjvUIwNZpwhlxwhlxw0ENZprX2X7V4R061oh IpIvlJI4l9j9tWSeq7uurMqa/CDD2tzUxmMmpjMZNaxmMmpiZjJqYmYyQdOZ KqqqquOOKqqqqquOOKqqsNwLrV1oCDA9nxd5v7e97evPa7XJqDzC18gBfIAX yAF8qAXyYC+GNtNiba+W9ReTqu71rO12uTUE85shbSFSCnVVVVlSCgaAigQa kpIIVIKQUhnnfOa873vt550eKZhcJAKyDzrzN6873v15514pmFyTksg9eb1o 1rXbvrrpTMKvoR757vDMz1310eKa1ozQRIyB0YCRSCAwFgthOLny96bEz9nu 5tF7lZMWAydvAvLSVH5tq1JdtzkjnblmXY20sykn5XB6tn1D9ZiFOanu8knR mUr2klZBPgE+4PTTTR7Xpi5c8vKnvF4c4hc9vDhz205pzy9xHZ7LdK7KpUFt rl471zk4JOT0UQpukKJBEgiQRIKTK6pe5602dz3t69BgAxT4flXu/rvD47r7 7evgEBMsIG/tK3f1p4572s9i2JJJAHySSAAACgH8kkmB8kkgADOK1svm1e90 FXFAGyR/ffffBIBmgALjmAAXWrprdEhlX2n1t1y08d97WDbb9IZmYQzMcVVV VVchLbccVVVVFRy44qqqqqrlxxVVVVVXLjiqqqhjiQrUi71c2zza8t9zUdeQ wXyAF8gD5FfKsLIWlkLShZBkaWWltM98r7X1p8d+fnRbRkrS2jJK0top4a0l pYWlIeV9e+39mOKmdNOjpDMwwhmYYQzMMMzC2y220qKc0vb3e2+yqd870KKK KKOW22220+737m9azXM2HpXuD2+7m2XuVtRAmdxKywmR9jbFqOq50bWDctxb G2lB3VYEc83ieWG8/OIU5rxhYxPW315RYZuC/byPcMZwOZ3sWhBo3pl6Q94p kDN58coHrpDzRrvN95L9N/c2rFVj2cpy1VPvq2wACCQakBVfud+rz6776iqr 6fVWVUqw223iSAF8gBfIAXyAF8s3GxzN55ip3zq50hczCWqqqoj33Ld3W+tV VTnay6s2AA+k1qXd3rWtaku7vQAGZmAAU9y313zzaqc863rwBJmZhCEzMyEm Zi+2GZmQ2QCa1rJIBmZgAGZlt1lX11x9bVeb9edVfQtpJJAtsgFtkhathIWr YBO5rVeXvuNKnDRzsAgW0hJC1ZYAJUgsKSJKyUAtoSS2hC3k/ZvVfXvPNlXh riqq+IW0A5mW3ISTMzAgZmcA25i9ub6tF4ZrmgOySOta1DMy25A0GtayaAkU IDBAAjrWsNAEUABjCBDWtW224EkAuZgBlXt3vq0U7M1y21UFiqvS1frv9j99 bnNW1S/Ypjr9+3N31Bd7W94xleuc2t8ABUn75d12+z0qqvs76qN2VVUAD3vC +JJ1GTjSSbZbakkkrUiO5BHytttttoDt21IgaBB15s9u4fEUEtIkkn1tnds9 JK8xyT0ksHfN4SoDJ3dxlk7uqqqTMzO377aqqAMzMzAAG7u7ugAXd3Zd3dgC 8+zMzN+0nxt3dsktttttkzLugACknwIA4G2xIk5gqtE3s7rbbG2xCSaAGG1q tbPd3OyevW2220kknd2TMmFYlaBHMPe07un6c3d3d0ADd3d3QAAG7u7tVVaA bu7u72ZX5ZndJJAVVUAAFVVAAD3tvsqSREdokkfkkkv5K3+3Zkn5d3dIAyI5 B+Iatuyded68dedsCJqSAAeo5WbvAzMzMA3d3dzMzM0H3wXd3ZVVR8r1USSS ZmZmSBJJJVVUj8ACSSTMzMyQADd3d3QAAMzMzAAAG7u7u9VfffZ1CqSSLSSS tkgAAzqO6SR+XpXDUkm2uJnJNHfU1UubtKRJ7u6Z0wcL1VTS0dfd73u7p98E k/b+MzGgn7MMEiVSSSbbnd2yVBLy80ke7kEO7iCScx211uNsIDw7rMwDucaS Sa7qA8yjukdbkiRJK2S0AAIBDJJ261HRoGhzS0gu+7uUUttqSSSttt9ajJJn s8rfs9uXue/fDLu7AAer6rk7rjbdfnsJOZEO9vSX03b1AApMUbdFowQm9u2o pJLu5pElAAC2W4akCLbF5JRZK293Xdu5OS01K2SWpJJL1tsuYh4cFqzmJc7Y vZi7wrAjvbs8iAGSSX3dzttf79+78kST+SSSX79+tqSXkoep0wK2W2kkk1tt vMds9JJAO6UlJJpJJO1/d7jabTQABEl3cNCQS8SSDN7ngve3bykkn3NVht+c kkklvrbbIl4mrd1UkgWSweHdJ3d1tkt0DQPW0NakwA20knEkqSS/O2SbuyW2 22pJJLMre2gebbLfrZJKkksqSRiSRqQIIQMrjeY3bJJKSScy13u2i7tt3dYT 66Pb3JCk9w3urnipqkkiRJNlkpJA8yEeQAVckkVbaYA4P3d3TfTcfm2nRuyW 1JLcUIJLctp8/YkoOJ0t2O2kkk5ltoAAvpG21W224albUkt1tslc9vrcyXHa U80CHxMkbbbiSSxa7EvGm4t9WyfEkxJJbuqUD2gbzbYbtkhqSz2JSekXd0hA AyIws9H7eyiBfYSe7uMJJJu7stkkkbskJJJVbbdsknvL13BmPbV1K97W5g9v u6SF7lQhyEycQhlqSb821aqusGCyMZjuLY21qnbUV83g9ULyVQhzU90BazPX y9ggf0+yYn3DOCKN0ex6S0L0y82e8U+72HrAsHeGivBjO3WdgtO5hO5bzPc4 0qcOaGCyCyCiqoiIWA1oRKrIsgshla1u9ary73yijwzOLaZPgMzThDKUhaUh aUhzMMIfya1o1qRhmaa7yvMr6636qpwy83XF1mpa6UpSlOMmsZi6ulKUre7V trfKKpwy8a3l1ANXTUvyquYZiqqqqquYZiqqqqquYZiqqqqquZi4qqqqqq5h cVVVVVVzMXFgdu28HfO0Vd8W1iiyTWt7N14Xm3TU3lCgCMkGT8iii7zVeF13 tu7iczL3Sqqqqrq3mab0dd7bu4rzHty21VVVVXmab7xd+PW8uK9x9irQltCE YkUhbQCeSCkLmYQUgpBSCgwuUBVtqgI20hbSHd7b3xeZ63dxXmPs8QtpavbV tqqvddLV+fvt57gdea7l+zLneItZm5GzECZOQQy1JN+batxJCVk3o8G47i2N tKbtSb+x4PVs0OzEL7E91hazfCr2EDyf2aV3A6osbrE7uENu/HV7pXWK80Ks 0TcrjPXTie17NrlXNfeyrrd+brhfc0bzE5j7KEJbQlqqABVczKb52Xy83apy 67dVVAAABzFbupzsvmbbvlys6vK1qVWtSkBVeWiQrUhWsgsFVQcx3mJzpnM2 XfKOdzTILILIKQ41IVrNRywByrcu6zsvl43Spy83vJNTQIAW0C0UFCQbq5rh nMdu+WtM7dFRUVVdtt5rdzXTO7HfLW8ddrm7UKoAAN3d3bm+L1zsvt7VW6nI a6u7AAAAAKSBlJAwAAADLyFXqM3HVZS3aksqFgAAAAxfIAXyAF8gD5IAXwAv ll4FO9Uw20Yr0zVd62FzFttrUK1PKrjiVqYIKEcuOKqqqqJjiQ7zj66OlFIP vQrnu3O90kJnY/a+BESkGhFBba22/NtWpKbfZ1kmDcdzIkHN2m+81neqRocm IUreedyPM7TmWic1H5fbpXcDq2lKAMgXrl5DfA+XdZzMYzO54+Iuj2ybqLXT 2A1rcrx7gC8FOPZnlu7nTN+ebPKqqqqq6zWjSqqiKquta1pFVVVURuta0ioi Iqq5madKqqqqq61hiioqqiOZhgqMmZmEMzMIZccJ0Jv3jK64Zy+Kbtrwzvtc a1rXYbUms04Qy44GlVVV1mnWlVVVVVdZpG1a207vtfbM3elN214Z689swAC0 UUWKooopmcr7xm76m2teGevPbiu+BC5e5JqXd3JNXd0Cijczavel9cTdKVyX 5fsEJSgAAXddnKr3pdc5N0pXJfr9YqlUqgAN3d3e+dyrvtGu8TbWvDPOa825 bmZmYLsCCgRiBJXnbc9ozvHbWvM9agM0qqqveadF6Z28Mze9YfX2rtFSCkFI KD1NhzvOX6501v7xrnM2X1z5wgpBRUxPOz3C6QYR7zWzX0weEkJlGz2zj1Jt 6hE7a22/NtWpKbfHRZDg3HcyJBzdpvms71SNpluMEre56AjzO02ic12rPm7w HLPWO77JjuTx1eCkRWHuOvmMzuePuqHtk3UWunt01jcNWzSC/Jn2PKKVnp4S SS2tfnc9yzztPKdLPHtmPzue8s87QZRSzx6RKq+++UeGPz2e8s12jIUqyvC+ U3TNquzsUeU4Irz8ffNJVSTzyvum/GufaLjvL9b8k/SEiySSKQESHL7f72/2 sTZrmJpqvPs/fn3PvxIDmYEJJczCQyrZIS1bblqn69+/a5rE2a5iatXn7Pvz 7n62wtsJC1bAlqrYWruTAfH28+z9m02a7iK8/XD789zQfpJBJmWGQgMLlAyA RLlhkICMJBmZSFth96OyQTe6TIEQzLAyAOZQySJMyyH2bv7u02a5jFXh+cM+ /Pc8QtpCzP0gSAW0AAlEACC/fU66q/fVpBQdds/Yl7fwvU0d3XelanoKMJk6 ABWtpeSRtxJTI08G5bmNIPPdt3QZ7Lh9UzQ2egO8s7KeY2pWm+7nvtqs+p1l hFxidzi4Hjm/P0al4HuGYxmdzx8RdHtk3UWunsNZ3N8QKhB8TLyK8OfXNe+f E+GMFIe+zvta3oXZnsZwtafXD3z3xBSCkFIKGi2lZFikFk7v2u6+7t1jp2b7 ibd5Vp9mfHaRjVH8QWEEYavt53323WOnZvmJt2ZW/XPhBBSCkFIKQUgpDndc 77brHTs33Gatb64eNX6Wqq2EtWkC1V53mvfbdY6dm+BrVW/ZnPvzzSqqqqiJ 33dd+26x07N8xNu8q37PfOtru3CXMw2qqqqq61rWlVVVVVda1rSoGtawhmZk DS61rWlVVVV1rXYTKcHYMPiuz24cI3MnQAXCRu7uZmZ7BFR331177brHXrw5 3Erx5qrfZnfm7FVVVVDzvz77G5rt4c6Lx5urfszvzsD4FIKEz4vfPed3zb7u vuB7Od8b19cBaiZ5+D7QfQybsPcHa2l5JG1JTw2NjBuW5jSDzKBDiuHwsiok PUHeWdks0h4Xjk8vcovCY3s6cns8XAw6vHo1LwPcbcfbasVG+evu4NztMygz 1x1Rt33OX7W7y7OdwSvHmqX7M787+IKQUgskAu/fXf2uax07N+xWu3eqX7M8 eDiSSRvZ1wY5NxzDBvhGJpWkqpfKqUFIKQUjzt7rWXLrW+XXM5lb24cLJpVV 39329ZvHWc7eXnKt9hnC6VVRVVVXnc7msdZrfu4933Fz2Z3rm1VVXchJaqrz 19mrl1rnfZ3vdLfZneubXYAFthCWrSFqqLrxDMMwhe+y3d1ZN7TMlU+DMos1 fIAXyAF8gBfIASAbeL5IBttvuxu7KcmvtmZKp8GpnAAAAB53y72tmc529qrn t5nI3kKFABual3Yo59zd9rNu25e5T258xywTTvXN8JYS5k8ZxXLJMhHCWtpb iSFqSzYOEbNPZ7s65kSDzJUq8ODcHq37bheDoZvbnZXnMb7pr03mvPuOBbrs 71PPOjfJ9xc3ahoK2ws6s2ez3CSi71VHRmx+wqxHsRWjbo1v3s3V5rHN+dVd BAtkDdtLZCNttAuXd3mc75brM55iq3jvq3uwAbtJIAS+S++EDTbTeiAmvtNN dzOXl1W277zzc5feyamTMQQQQQKdJsQg7Ssq5NLviubbdznFomnGqwaNkLVo Ro0SlataNaNeueN3Wue9m6uW617uZsdchKYY1a0a0apSkpUQUvWpIurvWsX3 zjrM767ZS73me2uPmta1rbb4uOZJmZhDMzCIAXyAF8nOC3zk7nUqquBt84HJ K9a1bbbbUwI4mYTiSZpNYQMyZgTBHOL5RqRxfK9ZNevnJdDqazboa7XfyUak cXyjUji+jUjhBSgaKdIH0akc+UakZSKypbtzi77nGO2Zdfea9TbCsWLF8JWp WpWpX5x+zn2b399dV3rObZynmLRK22KCkMPtZx5rWni8ulkMqc7Z1NTvdd6V qeksnYdyjmHirW0vJI2pLt6CNuns92dcxpB5kAiuD1bvF4IZq3OyvOY0ZTem toNju3OrIBiY9VyuiSc53F3d64jxCnWqLXt8t9xc4+3pFg5syP2KwjsaWCHL xN3xHV2bfn80vpXyW8+d8XePiOrsy+a9QcRDkEnTFslKtpREREREROAAPvrq 95m99+v28ebzvPrOGCJuBKU0ABSlkkpRERMCFKJiN99dXns3vt9pd6znPWcK iiiiiiIoOd9dXfs3v19pd6znPU4UTckGslEJUIsPSKQUGG/ZcvPZvfb7S71n OepySQ15aWqqqqqq0tVVVVVVpaqqqqqrvzrfrrXvZ7a6veM185r5VVVVVXWj WtKqqqqq60a1pVURVVHWjWaWBrRrCGYZhDMMwMVFVUwy4KqIqqi4Zciqqqqp hmYqqopeuufXWvfc19xd3XGe2Z6ZhjW/GYZhC45kOwYa1rCFtIW2agmoJupI 9Wd2zO/X9uqzu+Jj01BIW0hbSFtk8q5lxVVVyYqqeW9szvb9uqzu+JiqqsAG SRd3NQu18hh99SVfAC+VYsmSe2mW5C7pZB45BmzN8JYTIMntnHFwS6TOQ4Kx tLySNqSzZ0bdPZ7s65jSDzIAfX2d6JE3OLq3tzltXB5Vqr4eocg07OL3me4S dT0zm3A4OUW7UNB19d5TF2QjUvEO8Uzb6adpaee3IVd0HOTryasqrvK+GZ8G ZlttoBLbv5da1mhVVVVVc1rWlVVVVVda1rSqqqoiuc3ve1EVVVVc3ve9qqqq qq3fXnPXWvXxpe3u+Wbt3vyqqiKqu9a3vaobVJDu4vkBIvlISfV8vkq++cki +QSba+8SST77xJJPveJJO5gE0Ca/DMftZW/Ztu7uxd2vnJN7wKwVqSaUOTWp K5lZvrM47lV13lazNgAVqakU+l3dfL75AwAALqi+cm5z3HSjl392ezeu5JJJ JJJyXyu7u5JJl3d3LvcwAoDtrM+ZnOfN1Ut2S6vlq8ApElda1qBt1KL5ybnO 6pD347LABvy+AF8gBTMzJGBGZmYTAUiomta0aIgOta0kpJK6pnnJ2ed1SHvx 2WABI5HI5JJKlSSBJUkgBK+SUcjj2rvnJuc7rPdrGeGGIAAAAA6SSfe97Pvv iSRSSSSG977znCQJm975zkA1zXOc4Q2b5znOcINL5VSSr651Yecmb53VIZql X7PK7u7kklSSSSQCTF98vnd3YSSQk27uV8kek73Ax14+UOeYxDgJt3xlaMg9 k9s4rgkxp2BWtpeSRtSWbN6NUTPdnXMiQeZRDit0+1vSVgDFXDc4blW6HjW0 2A4g30c7jZxi7g53wedM5t8n3FzdqGgjnovARdmQYj7nWczehMPgzIvYayCr ug85M3XdUh7KUq57BfKW5GvkRyOamVdpqZV2AAHa3vzM7zzdVLdypv2wBRRQ KBySSTuN+Znueu1G9N+3CQQWHczXrrXfeu1G9PCqq4QIHe83661v3m7UzpqQ JAM1zmb7da3ztN5nT7z2rR2ABLdhC2gGAKQUgpBSCkFIkggAYZQJTWZAh32v e5da34TReHtvUWta1rbVeAhuqemx1CoyU0GXt3ezndVRqqsnutxuXGpW2l7J JJmY1urjmXHHUBJfDI8qTOknGPqK2UsmcygZRTp06rWta9ky4ixzLm/XWveT VbeGGlRRRReANaQb64Qcy4Qa2UikFIKQUBlA5vl1nHmefqYbvLp0bfaWXdye eLlcMgiwnddWIrYt8oN7RyXuRAMO7gBurd2CKAAC222227tmjqKGZmZgDd3d 3TfbmVMybu/oALsk3dkiJAEnPjurZy4oAAMkju7drt326rLLb6231cfe652N +/mj10WAACT+7u7qqql3d9l/dmZd/wDd3d3QAG7u7ugAXd3Zd3dgDd3d3d3d 3f2nveAATvv3e96l3bMzfe26qt0dubu7983IV1Vl/mDgNzMzJMvubLdsnQAc 36ySSSQCknd231rfm2u8kxfvZ3O6TszMzAAG7u7ugAAN3d377dAN3d3du/fg ad3d3BVVQAA97wAAV3de0niEUrSRJCSR+f5K7vq/x7u5vuaDW/iP17Ilr4tZ 6bWTUkAB1uaSVHYLu7sDMzMzMzMwD74Lu7sqqo97wkkkzMzMkDu7u7qqq7n3 wAO7u7uzMzM7gAZmZmAAAN3d3dAAAbu7u71VfvffWxu8kuSSSVstpIAIAFkc bbFqSRbbbLdvh62tqgDAfA0prvdW2T3dxjRI+zxHEknvekn30CSV9pu40H6f sydITUkkm2+7ubiSSqXkkB7QNROADgSTmO2Ekmrd0K3MJ2mRJtrZrfqMzukl bkJAABJMkg7qIieGSSjujsd+u/XO1JJKqqgDMbu7YBJpZvtyq/bVVee+GXd3 3AA9659l3ctz6CvzeYu15nW2H3dRUSTVUkisUoAAt7dtRSSXd2EjgQABb62k kk223UkhbW3u63smrIakK7LUkklbbLjZOYS91IW5gFdyPyUGN5ldgF82B4Un Mz3vAT4pEkkm7u7u64N3d97267uYtttoAAtbbbzHzskMgBAkCTbaSSScbYSr sks7u6VJboHBIlEkk+9+53VSzun6EkkO7u7u+A/J27+3N+SG7tbu0F3d297w Bd3d/fC8+woAKQkslpKqpEZKmbu7Jbbbakkksxu3urbbzbUgySTEklUklUkk QLvmyT76TgG7u7u/fEVXlveHvel6wNF7gsFJgBFlVW+NpR9TXSQApLIAGTY/ InmAFZLbW2233dzvIAOdhnp6RS5ktpAPe7igSSrbB5vUke7BorNctKSSSzL6 2gACySQNXmlWITJEkt2tslPL617vrRaljzUTElHG224kku7uVZJpiwZG62e7 ky29bYR7dToAAtskk87JGq2/PG5mSGAAiIgiNvo3t6Fewnu7jKSSTN3bbJJI 3ZISSSq227ZJIoOsyZOjGrO6I5iW9nTpvhLUX2P2sNcJijHJNO1tLySNvJLN m9G6Oz3Z0zHUH6jB2G5x+iM5XD0BQzN6rd5nZ7cFZryBaDvHd472Zcjw3VtL NJvOeofeJOymjtKrpXWrm+Lqn0JhfCRex2EdhyhBdix80bm5ubm5ua1rUWta 1rWvO79zO+51zvNea1rW0pSlKV6ooKkk0qPn3Mb+99O07N519sgpDWacAhlx 0Blxwy41rWtVKUpXuXl9952nZzO1FAAAAO4y+d67Ts5nRNaArWooANtptrFt mZNK2nlzE21EkgEJfJAQQQSopBBL7zO95zuc7Wc33sEtpbRRTZC0UUU7u85r ndU7e3osVRRRRRRTX3d657Xs755nvb0KZaNtNtNtPECG0wE6dIK25xe8urDe q3FXtqRSEiilSRQgpKcjnoIfxQgBDabSWcx+8/Dp9dYTbqsxl+9Md+fhU0db 9rB3oZO3kuKtbSeNtWpLNu9W3T2e7OuZEg/UDxuEejagLuIUJjM3ot3mdntw Vk+ryF/aFvHd4vg925bnW+uJ8E71XbchzTM0+fZD4B3jmb0Jh0nLlvtkKveP cby6rFu3EcL4QCVr6kgpBQkdGtZqOjWsgYuZkDFzMkxAC6SRBcikrtmndXU7 592WiwQWlJIAAAB0kiAbGwrtmHZzrnh3XrOZmY6VVc03WqqqqqqqZputUUVV VVUU1q61VVVVVFU1q61RRRRRRRRRTWrrVFFFFFFFFFM03WqIiqKKKKKZpcv5 JfEqQe5fHbzqre6dRjKDEvmkiN0kLjcSFxuJIBcbiSXG45BSCkFEmVuJLjc3 mtXWEDmu857Pe7V3fe9rG8uOY3HGtaxVVa1ps3e837PdTXs93WnzUWKooov8 jUXOwA/JBQGa797v7O/vrfuX3sJsE40gskEqKKKqma53NezvfV7z7PsA7E+S xLfvmnwkhAIQduTKzxm8vY0+F1tNtv6BC5mB2EkzEUUUdFLSG/XX2c58X7n2 s++2dpClpCl5m1VVVVVdGta0qqqqqro1rWlVVVf0LVXZvetKBSKQ0auJBSCk FIKAwwtAQUgshS0gqA0pDwrc1h+dgVD9t1V09e1ZPzU797LfanstM9Z3RhHi rW235tq1JezVRJJT2e7OeY0g8yAG4R6LJhuDoDAd3hTu8zs8KwDbNtme0TeO 7x3s8t9HjfnhfBXdtR7savKaoMJ8Arx9vQd7FibE3HYj2JbXzk3Pfdy/fb2d 2QpcwhhaQpmYQwzMk/BJFDRlJJCmspbTrWPfva3+1+9qvv3X77JpjwVVVEbG qqqqKitFtVVVVVVsaqqsLLSFK0glaRloSy0ITSqqqqqqqqqru+5zv2u/ar99 376ms4qqqqqqqqqqqqqqqqqqqqqqoqKqqqqqq/GjVIUtIWWkGxpBKWYKQUgp BSCkFIKZg4QaNGqomvua3nPvfY896/KIqqoqqojERERHmvb39nvLr77x66ER ERFVFF/SANdtcgQa0CG/c39n3y+3949rT8BGotAAa2QiWyS16SSJzMIBoFkW MA0a1RR4+7fs78vd+8e0aR0QpUUfoQLWKKNKXfuZ9n3y93949o1gQ0iMMMvx FJJDDNUqKKKKKOuaJLVWy3l9d/Z9xffuffGjLtVVVVVMMpClpC2kLbDFVzFX kkLaAFua79q/PdPO/d++NYqqvCW0hbQ4CwFIKRmZSFtIW33j9mez7ypQNw8j nuGLlTmHNmzN6b7paj59j9rB9s8dkPdztbbfm2rUlmqiSSns92c8xpB5kAPr 7CPRYZquVCve3Wxi5nZ4Vg15Gs+vF/aFu8pweWY8m+mHz4KbT23Gbyi7IMJ8 Arx9vQd5amxb7PZ7msecv1696vfuffH29dPwKQUgsilJA0m2vk219999T7J8 SQAhJIpJABe23+rcqt/Z+8vF5AAAYA223oAAACBdnVosyq2dytXYAC++SAbf JIAXyAF8gBfIAXykki+Ukk++reXNbtVs7VauwQAgBBcjkn5fK7u7Mt3bQS1J I+94rdSSP333vliSXL2z3b5V7jMnt06S0EtSSCWpJcEtxJAncJIJ0k8TuEnv vvvgd3CSiluJIk4SfZJh7ymYxJ4ILDqRJO4kgcACH33jhII++8cAJiUr766d wXylSQXylSQXylSQXylSQXyp71QXdVbO3kybBfKo5Gvviggl8pUkEvlKkgvk pUkF8pUkF8pUkF8pUgBK7KsXdVbO5UzABp0qpL4pjS+RRlCGOZQD4BEgiQ1d apogiQRIIxCadaoQxzLJMcyk0Iadashu96oL3qrdvmqZjXyKBrypJSpGvkUD UMcz2ENOtawhp1rWSbCKRNu97whp1IL5SpIffKvbCNe9VbO1UzNEpUk8kkld 3d2vvvld3dySRyRtj9VRkcqqpVVJVVXLrV0qqqqqjjmtYKqqtVVVVNJGr9uT 231cO9uup/rZni6cpPtwldl2Qr28dkPdztbbfm2rUvYdTagmdnPJqQeZOFvE jTcyYHktq72635a8nupRoemv3BfEDd47SdxLuveec+UFPbAYE1uG9ea8ilx9 vQd5amxNdiHZuJN+w599dV4eu1VVVVVbaqqqqI/pJBvtXFVVVVVbaMCoakEl ZKMqQUgpBZORnQOnved4b4/azp7NwWRVgLAUiFSCkFk+kIxIFpBSDLCQeBQB QCKBFkE333z3D3zl4feIKfSKQUgoMKhtEVVbaqqqqqrbVVVVVVbaqqI8qquW qqqIqq21VVVVVW2qIFSH3PfHKb+fay8PbIKQcIKQUgsPmFSCmCBUgpBA13x6 nPvr7edMAJYTM53rrDvHus7IeBQFZjzvnWHuvtZ0SBsrzrvDvHujOm4h9CQb 3zzDnfaM6ZIQ5edzgs3YaolU+XyUqq8+791XPXddTynenVBbGiV2XZCvaAek GoaFbG2/NtWpezE0YHnZ0yakHmdQ7xPqTNQO2HXq9Y85M324emcVNW3v1zGz HI78ZQylnO8mTlrRuhNeVGs+44bx9vQkeR4NmbLUMfjvftawv3fXpkHe+vcO c7rHsNQ/BJOoQM7nnmHe+0Z054AGMhJa0gQRCD3PPMOe9ozpxFNVV8QhaojZ IS2g4ZVVVVVEaWqqqIqo0aIqqqqrS1VURVVWlqqoiqqtGiqqtXAkjV8317Tv vaM5OO5BrYQ8CkFIKQUgpBSCCApBSCkFIKQUiXEU86a2NRRRXl9vKXvfZvXJ 1F8AA1oAEa0ABqKKIiIjQALvPNKb972PA6Kr4ABqKKKKKV8g9X2Uud+++l85 J3z6SSSVdoILkkkmMxLu7gqShUkoVkkki7b+c23DX2vvjgd9eFuPwAA14RrT AAd0ALaABbQALVVVzThBrSDWkMC45hFUgpBSCiFMpKXn2e03D7O96a5Dqr6S QQEGACsBnq+VVVJdWrx6uv86s27rwZU/P1An29dvPawTnCLpBqGhWRtvzbVq rb0auEkoWdnPJqQb3RTdA9LhvK5V1aG6z5axvInrvxelZVItBGzzkfndYxtZ rvJucHvlc0O+LmaPAm8fb0JHlvNia7EOwq+bh7Wud+N9nOsgsjyE/CkFIsik FIKQUQJmWS1chCWiml9jcOZz3jXDvVVfiBaozrvN+03NZvnvG+dnPL+tWm7S FtPwSM0AoosWDrVIW0tXfH9jcNZz7Ph4PVRRRRRRRRe69d+5c5r3s88N3qNv 0MuIoooooovfc+3zNc9v7MdjpFHltttutZmoSAAB775LTppMnPlVptxttttt tt998Am6p8gBfLRnEVznyq/qmr5MCHow1rWeVd2qIqq73vWlVVVVVda1rSqq ru2wC1V3vetLDcghu7F8mAvkwYlPk5HxkwlznyqWnVtMUpVEEECSqEVXpNay /Z68nM/fZ8PJtWQUAVVVXLeZuZje7V93JyGHUtGe/bfdHCZ2PWD7emHpDqGh WxtvzbVqSzRvNtwvOzjk1IN7opuge71X4z1eWHq3Im9WW95R16ecwq1VFoI2 ecjleCsY2s28Ny/W2s9Xi+N6PbVw3j7ehMPRjFUR2Grpw9Ap19mL7CPb3YQz MwhmZav4ktUR+fO/sPZ99nh7KKqKqKr8Qm+531zv7f79v9zv6AavO/ZpU0Uq fP7733sz733j3OcEjBCp997RynCD2vd9MeWqqqqZz2e5r2vb77SrshbSQTUE 1BNQTUKrKyc9eezue772CHV2qqAfpKuq3JJr633F53f2fcea1qRqqoLD8DKq qmc+z77X2vt99r6Fq4FKttVVX9CQvO9+1z9V1l7rX76+5dnD3pfbAV4yjbeq ftgSFI1DQrY22cWm0sV4MWdC2FnZymzWxM76vBzUnWQ6V5G5g3uqsra5BR3r WFWqrDtu43svE3pA87czzOMTxkY3hfXlQpTp9vQrN6GDcnM0kdiV68y991e5 n31zx97Ok5+5TPa7myCkOWkLaQUhkC2sAt7q53nKZ3W9gSe5VVVVVVVV5r3s 13lz2u+3xVVVVVW2qqqqqqtVVVXQACqpCgCgUKqqAAAAAAKqqqqqaiqSZaqm Kqqrlqqqqqqvd+5m+8ue1nfXiqqqqqttVVVUKkFIKBSpBSCkG1VURVVW2qMU RFXPe8d5wz2u+5xRFRURW2r2iKiqrlqqqqqqttVVVRURtqislSCkFInd+1ne 9me13x8RSCqCkFIKJfvu+e/YZ9rvoKrAFIRXVfe5ne+pnfBFAYwFIKDPauj3 r73DOAaZAiySAM+njk9Th5+LTYQ9L7bCvGdknQr3EloRnS7a22cWm0uvOw50 bYWdnKbNbEzvdlL1BxbXCId0E5hKuPJ7uxD0qnYvn1A7dTvE63y7c3M8sB5F p1ic75cqvVjR7ep9msMchz4xVIdnkrdOVz7rPvmKn2q/avPeunXCxig9cx7u /b9r2bRRREQ693md33fc9w6EgshAWSKQUBYLIpGL7l9z2ve1zjD2XXu5r2ez XZ98m3S1W5hknklqSSVLSShY5WmyavtO1Ec69N3jvO6Nd2qqu7fguZhC5mEM zMh4UgpBSCkFIa1rWiCm2uWPaw6KHX775hqAGAAAAAAg7d3p/Hv4838T+P6q a/206LWMnB+c3NTEaV36B+qL8YvXtGgPz6+6AWFHNerHvLQZTZuT6XUkrwwA W22223duZBt6TutmZgDd3d3Tdz2ZKybu/oAGdLNum1mIxKrNxQY0kSQAD3LR ztW7pvpaJ6ekEmuyEeW9Z6d69yQAATknd1VVd37MzMy/uzMuwDd3d3QAG7u7 ugAXd3Zd3dgDd3d3LAHlmW7u2W22222T6bu+6gCkrEFpG8jbTMWknMz3SIdy Z9OUttttJJJaiiOmGS2PdnN+skkkkjSrb3ddNk7fA27m9nX72dzuk7MzMwAB u7u7oAADd3d++3QDd3d3bv34M7pJICqqgAB73gALbe7ut8kkmW6BJIAM78/0 au76z8e7uk57NhAA/RJTuLxM3rGmku7njRIRXBd3dgZmZmZmZmAffBd3dlVV HveEkkmZmZkgd3d3dVVXc++AB3d3d2ZmZncADMzMwAABu7u7oAADd3d3afq9 fr97ykkpIkk22wADd0JV/Nt7u2tttt222uQd6zvLknJG2H3d1VAA3dlTt1tt 7utvMttrb83akkrbkTwEgNkxJJK2Td2SJJcleXkkO7lSiSB5EnMjtqRJO7vr 691jZMbR715hDM7nbcbkBAHAgSRjuo7tdj7dgUdOgaIqkku7uVtttqSSSttn pEjIJdXLdS7gty2kACS22222vjuHjTH0kArbzFzA0W2aeotbSCWkk4LKYSTb 2d22pJJLuzieAI7utuZaBCdtuaIeEkSzFlWmbKlW7LUkklbbLndndUgINNu6 Wucu2S9LsjsF9JzFJAS7rao3+6i/gAj+SSSX79+tqSU7uavdAHbbaAALW22/ N2T0kgAAkbbbaSSSckj7Z01tNlvt2RF7oADDepkklLdGyrdqjTfrLrbbguyQ yS2230kSGVv2hu5UkirbKABd3bb622gAeFu8TvEAAFtJImbu9uZn7P053Pe8 AG7u7u/fSFUkloAJJJbbbaSShA8OZ1JKVt+bckkkqSRWWvbnbRd227uyF7OG 8lSD3Dergizeuy20kkpPZbYSSW0SeQAsySSFVtvu7nd3bquTPSRT0ltIC7uI CJNtd837Uke7M6uqW1JJFZbaO7rJH6earaVdNStqSzGiAXfWelsZTykgGSNt txJLMXk7JGyD7PGIkcwEUkisXlu6nPbu2SSSOyRKtvzdtzLZvZ3Tu7pTvZRM AFLBeal3dyqJJJu7ttkkkbskJJJVbbdskk7J7fSk4eq9W9aOQ+u+2wrxnLZA ThXuCXPohoVkbbOLTaXXnYc6PzYWdnKbNbEz3e7OvPeDk2vgGb7qm8zVix5P d2EOlMY/h0A7dTpJb5Z25nlgBCUart6HTTMrOnzPWqfTpg9nZ67hXTOqKOV2 hd9gAgABtgBqS++kkiSkkAAC8x4scq+3e995d3YAAAHd7m3K325czuwAqqqq rJJRJRna7Nvbc9d3uVSqqvOrmZiqrFUzLiqqqhmUDFdVu3ed10c7ydVWDaQU gpBSFtINpBtIW0hbSXKdvedHB71fEG2FFIKQUgpBZC2kFEBJqCaj1gDd1c89 31S+c6AAGpBqTWgDLzJ1nXZbfOylUAooAC5c63yUre+UVRQAAUYq5y73yVF7 5AVQCFUfJNv5L75uqlTLUKu2s96V42b2nc73PTd9tBXjOyToV7eJ6QahoVsb b8kbTfZnYmlAs7OU2a2Jne7K8PRyt7fAlZmk+1P3bhFqWMY9zwg4bqdJK04H w3fJ9wTTjNVnM6ZF6M6fDheWb02Yy7VYPb1jvzT5zOcEua9bbbbUKApBSGtV w45muDft7IKQUgpEmprHDjma4aufZJ0ikFIKQ1rlujrrNdHWdzOkFIKAzr62 2226OedG3M1zxd69nfKqqqqru/c+5dnHWa8N9ec9bbTWZhmYIAQAgBACCJL6 RSRK9q1lBNVPuFuo4EAIAQAgBACCvvkgTAQAgvOq1lBvKnzWYjgQAgBACCL4 lSRfKSVIvlBSRfKRSRJEqSXXbs45mu3uHOdye2EgskBm97qtluED4BJSlPpB fI+AXyPgF8j4BfLttXTx77lz1OTvuBkzLLaVuoBZmZIGTMpbowzMIZMzDcFI AyaNawh9rf15z7f3dGTuYnXt0Gi7shXi/OYcGGA7JhzTbE2ydXK0irOw50bo WZynGIMmIeGUzVgMldPmO4ny03XO0jMfqUsZwfCd2YmrdQfUCnt7t9vnNBpj Zq4+vkSxs8Vx8OqI4XfIFgNUEdhu+s1t6pvj4e+MCBS0CKALAgyUSDEpZJnt 571371567jJAZJSCJBGAJlIeuHvXnk326MwBVo0SFGoVtLaW0tSjegQwzEo1 IZrNd7dPfZz12XE+Tp0vk1ukpfKKQlL5RSEpfKKQlKSEtffXd3dSSCCTqtXb zuec1VrdsQAgAoGgBAHwB8UG+lu7tIu7s83JseGb6FtAACe94kkn33iSSffe JJaXvvJJJL33kkkl77ySSS995JJJfX32Z772Z74UgpBSCx53ve94Q4273ffO +017vd8nvvFJJL33kkkl77ySSS995IIIkkniSSAADvveJPE777xJ4nfvvInD jnsLfeimvcsIb3vN7skm973vYQd73raAcARIZ7PvZ5JILPveAHAkkk74kkgA Aknib3Ysx95a87p4tPfZ5/KRyAABaSkkihrWtaDpBSCkFIKT+BUgpDnOa0ht VVV3vetKqqqqq61rWlVVVVVda1rSqqrC/bN9vOfi8/e3+zZ37nJNS7sACiqK CuU56+83zn1eu9nUtB2TZCvGekK04osiwZrtibZOrlbxqzc8Doj8aFmcpxiD JiH1qVDxG2PeQqK8tN1+GzwAD9Km8iwbnhR2YooLye6oKOGez6XUaUkahfX2 MmG9hXHw3qhvXUFzaoA7M53hZqflJLy+sWZqgEKoAL463v5z6ce9768m99+W 9N6xJLhcSGYXGFBSCkFIKApbIUtCUzMhwFBDRlhYElthjp5PPfKl3b4i9F7L S+EDTbTYl8hA03EID5CAXwi0vkmnIdPPPKl3b4h9o+RRRRRRRVwJBEIc1nt/ Xnwnvd+zR9onyKCiiijnNa9v68+H3u/Zo+0fI4ABS0kJSoooiKKXL7X1d/Ly 9+99ma3sJyAREBEiFy+++rrg8fe99ma0QyEE5JJJOX331e8N3j3H2STAkiEw UgpBSCkFIKQUgpBSCyISazvvV343dcvdPspPkRVVVVVVVQhPe+vZmt6bXWZ9 73NAnpj4HxfZJi3SvQHCIJalGydXK3jVm5x0RuhZnJ8YgyYh8LhnLCZJ1gLC RXYjS8nu5oz1ayDJM8bpOuBi8ufcu2dns85pLKSMQntN8g2or4onsHCZGc1W TJu56SFeb9rrFitzHsrw/vvrcQWtFZd5nvV343dcvdPs26IW2BbTiSKKsirI IiqqqqqqiqqqqqqkRVVVZmUkDZBSCkFIKQUgiDCTMVVVeZnvV307y99Zleub qquSQSSaK2AF6mte1JIJfAVhOdXy3C9clcK7fl8AL5AC+QAvkAL5AC+QAkgH wDfFzj2ujPbe9MrwrLGA222223+X3wDbiQDbzRz9+dH7qizpdfhXbbd/AP1V QMqqqlVVVVzLiqqqqqrmXFVVVVVfrrXs2qqqqqq73vetqqqqqqu973raqqqq ipve972Jrmc+tGFezndeFnYapJAkjkkAAA+QB9DMzJDMzIoIKzMzDhBZIyU+ 17XPq57H3e+zj937nMIY5lkMy222qtuwD4A+++++G0v3ZK7N/Oj8Y/PXdfss ba+T4qqqvDQAsCJiQUKBFCAKECIfa7vn1c+zd9fXb9hxIKfpKfbAA1EBSCkF IKQWDCQwskFAEqVJJJVft/Zf6utqX21YXfVklva3ZaveyTM7QfQsaTC/1SrZ Orlaas3BnReVCzOU4xBkxD7up6cMR9J1fCMpp9j4vXl9p6epfY7nnL3jksjM D6dzU6cM9ntGosoiFzxN9jbl8IAO7Nc6HtQRYee64Ub6T3nRpbreuvGCSSVf NJKqSPlWYEIoRJUlAUCRlSCkH1AwBQJHnfu573vq5e759t+znsDYSZlCBaqq qqvfvb3v6uazl99t+w5MAgzQEgoEOAgKQUheZgL+rW1W20QAAACgUqqqqqqq qlKNtVVtttKKqsBJrVIW2Q5+x5v9+rm+6vftv7N74Qts5ORUlSCkFIKQUgoO tUC1VNLPuY8399XN57rc77j9lIXu98++rmvtPLnx9xo9khFBA3nOc17tc145 vO+4/ZTgKQUgsBUVVVVVVUVVVVVVUVVVVVVOMgshbzl++rmvvZfe7zmuP2by Qa1VVVCqqDd9AGZmYAAAKpDMzMAqkAAB2+8++VczmVxffcr65u930ACigAZm ZgAAAoozLzKAAAAMzMwAAAAZl3Sqqqqq5mYqqqqqrmZiqqqqquZmKqqqqq3M xVVVVVW5mKqqqqq933nz8Ya5p93Ne1x+wu29VVSZhSFpSDWkLaFtAtaSbpX8 kkqHb0Gr6Ogy7CekB2WpvZHmYCxkkD8iTalF2Em0xZvaMFRoWZynGIMmIPDl 2sh41bNi5JQDXzL8h3IuXrKrZWvz7PIXe3ZpxvpN9ZTKWeivFRSRquvyWe1N uXwQHhvbJnumnHmT3dhsgs8z3IUvMrgnTK8K19tVUqqq63Se8iXuVpOM8fbK qq/ffJ6NvEkkh422020215JJLzz25iZPXpJucKtnJamru7u7AAAO3W+932L3 nlXzvK9crvcu7u7u7uywABxnHozPbpzPOV65XbGoJIJAAPSS7r1plHd14mXK s6dldFUradU4FU26dOnhLjmELjmEuOQRRCVe67ni53bfd1u+0JUU1aWyUqKK KKN3v3i5vw33d9vtCcRSKKRV907+9ozXPm/cu/tPX6K4d0UkkUkkUkEBIpJI pJJ9JJJJJ9JJClvvaiZtsV97UP0Vw7YpJIpIL8kpJEAIAQAgBACoBeK/cVy8 fnTydb1lyMLU0r20pe5b7pNlZpNqUUGpKoxZtHHCEaFmcpxiDJiHhl0xh425 13T2hztzUaXs9mkCep7MYy5DdOPoGb07FRzu5uez0N5qKRmrj7Lc8m3DfGk+ G9sxb7oe1IBtUAd876zlc9tsXexa/RXDhYl8pJFEvvlJItX0kiiSqSCAMSkk UXyqSEXyqSE+SwgpDe97N7IKQUgpBQfwpFgKdxfv3K571sXfsWv0VqHEXyqS EXygJ2ltLaZVVVVVxwyqqqqqq44ZVVVVVVccMqqqqqqty3Kqqqqqi+3o79rp mvhPfaN32jZr65VVVVVVccMqqqrjktu4FXYQ7ertAJyp377kvOzz3H2cnX2T czoQQQQQTkmpLu5cmpJd3BJfAI3BUemIv2013rWP0VzWvAIAQgEL5Sl999Yt PahT3U7rvYtfor5L7qVVIE1h3774zXdNPfbOX29aFAPoSGrlTI++5Lz7PL9V /cnb+3kjVGhoaNy6Z990zX32/s0X7h3Pt6su7LSWW6VVVXJmYqqowyZSFPOY QpjmEKY5hDMmZDYpBSCkkya1gT2sM+14zX3fXC/bOZ9vtlStSta1UrLaVrUr GnSdMyzNVwdPjav1tuFqcV7aUtass6Qnn5aTalF2Em0xZt04OC8qXmc5xaDJ iHhl31VDxt3puHIDadHMeRft6e3h0eU4NxjLC9OOchenWYA7p3s9norxUUjN R9cu+LShvjCfDe2LPdN9iKDqd2+vILMT9ORPb5mUexaetUur6qapOotSt8XE zCFOautEKa1daIWWkLLSGswv33jNc7u4e+53PtseELLSy7CEstCWVix5JN5M 0ABTHErVM+94zXvt3D33O59tK0SqxQ0lalalalXSdOk6Ee7ETvXxE/Zp66lI VOk2kkqq2gAySWq2gAVVtAAqrWq1qtarWq1wz73DNe+37NGs+5ndfc2lkEEE EUoQQRVy/vuS8+9v15lVL+52/uYlkEEEEEECbadCPexE96+I6ifs09kaG0+B DaYgQIECBAvSKRBKkggkS68RL1E310dVKezT2Ro70++ikkUUkn3wvqpfCkFI Oi61rCCkFIKQUgpBSCkFIKOi61omApBSCkFIZmRR0vlVL5U0wENptp8CxO81 E310Lp56TfIbT9QI8CG0206VUqpVSrQxXW+ma79tzy6+7ftp8iJPJOgmUhS5 i+Xj2e5meVTInNdPp65I6x2RTxXbVVD5o7IB7n5aTalF2eJNuQ4qOHBKl5nO cWgyYh4Zdqofa29aO+4SAdnUUv6/dvdPXRiGWcct3JeYfTedJeXc9nobzUTS NV9dO+LRhvjCfDe2LPdN9iKDF7Xdw+q15HpyJ3uoTR7H66XvavkIBfIQC+Qg F8j5FVjtemWib7qMolV72jt+VVVVVVvMud+ndfd3TDPffGmToSLICfJhffG9 ffbpmL99e/bfl7LaWqtJaqr4ujM2fa53dMMPvu/bfvQtXuGZhJBBEbozWz7X 2kp0+7977mi/W222gqRQDd5L+5OZ9lR9VT7vfbr2d1LqwAtfKSRpIoGvigAA Bvy+TbXy6+mc+8d3726YZ93v2+e+Jaq0ltC1f0haq72d/eN65+3TDP3f3tnu iqqqikFXO/bO/b5rukp37v3t+6qq/BbSFpSFRNQTUE1BNTdz6vbs9x857vOs fc4G3awni0tG1rhEk5R4rxAQvq016vwwTPbvek9wGxzcPkWVQABLbbbbe7nV +qsYDMzMxwZmZmD27nqz6Vk3N++gAbTn0wqbu7u6en1fpH3du9N3My7mZn47 3vdD4dvvlAE3d389nZf5dzLu7vYAqqo3d3d2/mZl2Abu7u6ABmZmYAAu7u1V VABu/vszK27v/NKqqcADu/V977roApL9ZIl3SO+ZJJzKpM8/Nt2OW0kkmvyI ghiksj3Z0ktttttpJJPd3W9G5sMFRObzLG6nbI3EkklbbbaDd3d3QAAMzMz7 7ADMzMx6/3g6dJJAVVUAAPe8AAFVVH27u7MrYzO6cSSSb/o7v27NOyrO6gzt aX6l8hUkr3GKd3VmpJd3RIkpuW2oHCTbZakkkkkkl62j3vBd3dv3veHveEkk mZmZkgd3d3dVVXd+AA7u7u7MzMzuB3d3Y3d3QAAG7u7ugAA+VJFJZ3u0BgdA iTUsJJFt2zQBAACpNsnpLu3q23JHRJFXe5pE1DToCSAfd3Vd25222RJJbu1v Mttrb3HaCTbaJ5eJkAmEktJSu4H1HREm+zE8jbbHdyQ0DSiScyXIwKN3aMPq SBbEk0V15vsu90kKxunAAihPSVtxJJgoZaLuu2KGhLUqiSe7uNtltJJJtAbN KPbW+36qz3vC7u7gAFcJIS6dPRZrFzDllIBFyztvWpEklEo2uAC77dKtSSS3 QO4Id3XLbSAPQMbuib+++37tzOy9Put+A3d3dHGT7KfHrNUq5Wkgcqd3ZH5S jJuRLWj3MCA7slqX79+/H8AAiSST+/fv1pJI7ezC7vcwBd3dpJJJ7vdb9b8E Xd3dSSSSSSSttt9bdkbYLZLArSm6ABESgySkgPSod1FqbyS620zOl6m2y3bb b6KJeSvZuNu2NtpWyAACbuyXsttoAHhWAd0kAAtklxKNtJJIqct98ADd3d39 oXd3Z3cmezM3MJOJttpJRYAGO7jKm/NuySSVJIrLZezbd227uuHMJ7DUN71l 8Gc2ZPSSxJJeQstvd3FJe4nl3Ctts2tt93c7O7pdw2SR+bkqRPd3EBElW207 kjztbqA8HEpbUkkVltpJJNkkhqSStFWpW1JZjRA0u5lmZK4ynlJ8AZJJJJEk lu6p0skM4Jb3kgOSARQAA7u5S6NskMckttbbbzFPNtsAc+46B49de7pVLy/j 1btVVaZmZmffcAHd3SEkkqtt2tt3tz3bfZbuaWysOvRy8J2N5mYD5obIEQ8J tNq7CTNsOK92bzdPnznFoMmIeGbeq648SOhYd4xgdnUQv6+7SBuyg4xlfYbR k6hl9OVAe3j7Rns9FeKiarWoG+r9nuSgvYdHu3Ec86e1IBhqkjvcb6mIUZ7f SlA527u7opQAZJJLu71rWru/J73b3XMqPe3zRtxrWtwIFxxrbah5Pe5m3mkv vO+aDRCDMMVtqqqqqrFkLbIoCyCyCyCyVIW0h6nvbzb7SX3nfNSkRYUcJD1P ed5x9tL3zvmiGSFQYUSCkE8j72tcfaS6755mgsITISskBNBJBQgCkJGeT3u5 19pTy+6tLXztruqy666Tm8+i75fQEbVi35rnvX3OH2yTYycAkQ5s988w++bn vfZ9uK6qq5LleercVl8SDp5ceuYOy1NK9ZuYV6DLaOeASmRdhJm2HFd9MHT0 o9OV43mBIj44eou5dmEzV4njWh2cxC/X3acA9Hl4+yDM7DPJii9O50l7ezs9 nobxpRqWoT0WeTcF8KO3Gc9JpzUgSz5ukjjfMZO9VN4Srq16eWZmZmez32IK 6wv3Lh91vt/fZn3eG/K5iiNAtpC2kG0g2kNU19zD7rfa++zPu8F2QtpLVyNo DRVS0++5h9xvtfffa1e8FfX8gBJADbSeKkrtX7ReynvX49I9WNFIKQ+tINpC 2kLaT4FY5mYRVS+QVVpJS0XBeyn3X4D2rK9El8m2gAtoQC2gSWqqqubzZmvu Zlv3G+9v7L93jA2EAUIEwuHvuZlv22++39n2PeOyAwuD77mZb9xvvt/Z9j2v IaCLCAmjlPfdzLfvN93f2fY9rwMIKQUgpBSCkly/e368+b726Ps9db7d446z YH2WzczxXoN22nngEpk1EmWHFd9yV72szTEGTEPDNvbsw4TFZjYVq0dBC/uo 4d6PLxevTmE6vHwLNN49ZgDvZ2dm7uQ3jCjQl3CeizzU6+EHbiPb52gcngEE bwkdcC93qZ3btWbYb23GvvPB59Tca1SNpKg1MawKkFIKQtKJfvt6edc1r76/ d+e5ufwfbJKQLo2c/ezGv7zfe3+7rPvHdECeG1pABpa2221boTn3cy76678b +y/d8935kUgsgoRSCkFIKQfU0CgpBZFQzWsIcMM597WX3tc19v7evtedHeQk C2yFtINpWrVFwJBuxLv7ust59ea+39n2ee9JJxwkhasBZ+C2WWgpF7zp2az9 vXv13zf7n2fYd1xVVVVVeXNiXv3tZ77EfQ3r3kCsy7mZmZnv33vn5fH8aO29 +xCn8eFgruVVV8l8knLVLO9zqb5rtt370oWXanspuVJvENGWerHOLU8V73Oq WZS7TtoHPAJTJqJMyyY7vpqaHnynGIMmIeD69dGLF42yeb3kYNHMUv7rrHSZ eWMZiGr088InXpvWYS9y9d7OzajzRR6rKL4evmlBfED3bi3PO9xPEFLmLxA/ TE1NznUzzWTr96VkSSS9SSSXtvKmfdm5Kq/Ptu/eUz8klsQtv9+IN+/PD972 qrvPJJJXaE79ZBvPPOnn7Vdv77UqS3sVM59c72/c+3l4e3vOn6SW0JDLiqqq q4BPb/dPubT8376+/a7ee3vuvwQJbQt35zrm+yfr+I3nqhL8B5P3Kbyc5bzr GVc+jJsikFgKAyaO+O97c+7n32+3frw+3+AA+knyxYoQ0d98Z73669ee/b33 N/XVJepfJY9L1Oyqb0dMyqh6eV+Kne51nufoztI7kA4FhAksV1pXvPjOMQZa jPjt3EtuPGXryylemaxRo5hm/d2ribJl6ZzejFfNQ0zjzoGW5cGb64jrRbqy w+By+1Ji+IHs5bju9h05y4HcDrwEdq8vX7SY9vr1q1xm1Pl95fVa7kb5nPs9 etVfPNp/I6lVUJJfLsvcXKTWd2nbkrjdRzSS+bVfKGi5blPcM666ouN7h38A AhWYAFL4783t937fdYbPZ3vEAGBoenOeudvea542ezvew/EUDBW2rAqQUgpP wCkFIKQUheHx73656/d/b7dns73vf34gpEmJBSCkFiglAAT2/HDPb/Zr693+ 32637XegYAm6N6c57Omu977l9zjeaNCakATAAEVCdqXxymbvY+l4gi+Pvv1u C3KJWWW6dC6inDZ5XpXV7iqdYuy370eBvTKuSSxXWle8+M4xBlqM+Iu55Zce J4rvF+zTYdHMU37fZwFjzVmpvih6qKmceswDLcuDN9cR1qL0hrftcfi3fa3Q fED2ctx3fElcS7p7j4O+hXXwbcWwFe7hS1d8cpm72PrusVAspJJKsix5nHKZ HFs8Svbvwz7776Z7CPBI7Mzi1Fs8F5b7wHSTejnTb49v3PcvjXDlPwAFxoAC VNJvhr6/Gb9z7l9rhyiFVV9JJLVqv1iw1TH5bt97PETeLGq8NuIAAEgKpU4k mNfNv5Jtq4rvFF5+Xb3r9716du3emSK5aq6C1VXea1w0fX47332/ffO+nabz 8EJbQlqqqqq/XvOmeNH687379v72uHKfYr9bbqQzMttt3D0QFX1fKSC+QAvk AL5asj2T7Iqza0CntXAu7mH4rsmWdmeUQ20avdzgWECTLoNvI3vPjOMQZajP jgvLfXHnSR0jG+ws5H1C9uDq3mvca54h6qGmceswDLcuBb3rjWlRSNWYwvMt 32yIHxA9nLcd33YTy4l3T3eLV8PHbXabbsU9N8qLNS7u5q7sAAA77nd/TOPu 17vvuV1+b8bmZmZmZmZmZmYUcD8Dt9HKZTWXs38iv0C2kEms8dNXZ3nvfc+1 v7nTKfBQUsCoz9IRQgfvt++w+O8+79+77Xt8EZ5VWAsgsgsgsgqkFUmufa7h 059vvvu+17fNpR8iixRRZdSUvaUT4+vvvjx9vft8zma3UoiqpBRRzXucNHe8 97h323XDaURSbAUgpBSCkN75nDx7Xe+4d9p1s81U2QUgpBSCkFIKQUg5SFtI POc1hr3u99yd9nm+aqqqXuagmoJqCagkLKr3330SBr5NtfLqkT0N2rNdOgHo bPeL7JlnezPcost7V3RhYQHNoNva3R58pxiDLUZ+ObeW32LOKVp82QMi7KEc 92ARrN9Z2aueL09XTDON9e7Nl24c31xrUqpGrN1heKV9ekpW4R3s57km/Ybu ZLRvnYHlnaK897ZebI+z6qqkWvk2yFtIW0g2kLaQtpCpBtIW0hvd4bPe73fH ud8cirXhC2kLaQtpCsPkVVKqTYL5NgvkAL5AC+QAvlLvDh73u+4d7l2oYtIN aQtKQStGsKRrSCJBEhv14aPeO99w73LtQwpBEgiQRIIkESHL84H4BSCkFhwV UVtqqqqqqttVVVVVVtqqqrDW98ebIKQUBk1m3CGXHCWKApBSCwL3nv3e7Oft Ld9mmwuq+9tqL5NlC+QyhfIZQvkMrCGXHCDjjiQWRAy44Qy44Qy4i+VZfsvl npm+zaNkuq+yeqL5DKF8j0hmZmZmZmaYoCTWta1A/dVVVVFVrVVVVVVec5zn OKqioio1qiqqqqNtFRUVFRrRVVVVVbaIrZQUgpDnOc3sgpBTPvuJI997FATf L8PzPkppzPeUqPvvAAD3ykki+kknykkAAAAAK+XyC4dM5X7Pd14tdu6pLOfs kJJJJJJJJJJAAAAAA6be8pi8/dax5xdUilnelANsAAbbbabqm2z5HTGovWt9 ftNC6qXXPfAIAAJAevOT707ee6Pyj9kuxP1Enlfil7eqkY67KXvHjFFLA8IH S8GpvJTvXjOMQZajPgd6899XrTdhuSIjJ6wdC1nu7Vtix9M7Vvj6ephEx8Z7 dvtyWdc9mZuAKltKvCzvo7566Lueu+wczo6TfUb0QF8CY0UA07o3v7x88+9n uc13dptz7hIRQBQIEUCCRgQ2b3rM+1vh1++9nuc11d7t+J5VV6859wvr0+5m /c18u3bfjzpnoLAfAAAKAAndH3T58e5z3M+Xrtv054tpSCCCCVJJqRSOcn3J zzs+7fecz6uxyuU+7uCCCCCVNa1pSCpJJW2284fb4e7U+7nec183uceNfu7Q laAK1NSKVJNa1FABd95Pudnq9r7uZ3l59XXK5T7uwK1qKVJIoKmpE6sAAAAu 7Mte3F1Z7YStyX6qyrr2X301mWKk1rSla1qKAADd95vuV7qp7uZ3uexO3dT2 8AAAAN6Xm3eXlTW13HaZSqUtm4kgBIASS8pIL5ACQAkDXyba+Tbbtk5365lc nbRqjK7s1AXxvZ6uZnuW5BnrZq73SBYQOk4NTe1KD15TjEGWoz45t7y31WxN 9BPPCdwXLoZpz1A5bEjjGK9q9PAxUvi53XcdXVbuYcJNLaVeFnfSKX27ALuX fYOfjo6TfdmsgTwJDulAM87r3tO/u5T72e9nEdI+0qqqqqr4u+a3p8p7mc5n kdIvdKqqqqq7IZ41zW+afKe5zl8jxHutwLaS1VVZCCrgFuvZzW8eb9ie7vvs UeL7SqqqoEWARSC57N+7zu3m7ae73t8j1faUir7dWpBtVbbfcLvfed077X3e 97fq9XrpvIVVV4AA0J7O57nO7rmW973t8nK3FVVUCCwBVV57nt81V1t7vevV O7tea1JKqq8NSDUAB7U1d3XOb333fZW8Hfd69U7PMoFAGgAHc57rOb5XO153 j1TkruUADsl3egAPSaqvfffen2ve39bvvd38H5+2PCkMu5Mg8uY8DK16I5xN mCAgXBvoedub4+ftbg9e33NGUAAS22222qp3spb8GZmZgGZmZh7K327mb98A Dfrcw1mZmYVWfX0uvpu3Nzft3QO5W27uyx+bbdTuwUntYhuitAABwO7yq7Mz MbfzMy7AN3d3dAAzMzMAAXd3aqqgBmZmZmZmZ+ffFVVAAO7/Pvupd2zNxvsy UGr5kknMqkt6+ttddtpJJKSSLSSikkuqqo4DwN/ZmZlVVH4HvC8u/ftmS/ey HdJ27u7ugAN3d3dAAAzMzPvsAMzMzH678DTu7u4KqqAAHveAAF7u6m7qSTKd AkkqSSVkbu7N3ZD3dBIBN69UABUkp3Uw914WpLu7lA2+kk4N3d3dA3d3d3d3 d3fwHveFVVHveHveNfSST2ZlZkgd3d3dVVXd+AA7u7u7MzMzuABu7u7oAADd 3d3QAAG7u7u1+7i+42lpJJJJJWN2E8SSSSZJbbXMAFJbbbVskVeO+HHqA83G 22ku7iFQh5dow7bMhJB3dquZbbW352kk22xeAkDJJMSUte7baSSsxNJeO6uS 0BcdRJOY7B4AUju6+vqACWrTJEs80l2Xd3e5uJMDuYBHn87W3OSQYStWYpFY acWpKtpJd3crZLaSSLbZJLuLH2+3yfvXf63Kv67uAAPZnv3uzkCcxli05h3a +7hbZO6jRUkiSi1bJ3ZhltSSS3QO4IAAX1tpJJ9baKSZI1j1vaEnxLd6v1tt qSSV9bJOzN9M5tGDu7nc0rrbfWMBOZy2bYyQPAM7uyW3y17/B+/E/vySSRJJ K/fv1pJLA5KMAUy220AAVttt7uuT0kkgApNbbSSSSSdMhnTC2xgM5+AEiSfc aBBI4QFhIQ9bmWVtvMdrbbb7bRbbLettvjIl5IZWxa220rZAISe3dkvrbaAB 4WgHdJ7uLZSWxKNtEklyy58ADd3d39ppmZdt7u7u1JOzMzNrbbSW57A1EoDV ObzG5VbbUklU82y9m27tt3dY8DkSrHdlvuQ3Q+btyElpWVWwnqpFinbrbskk Vbbfd3O93db6JJeSrqTSA7kAyS7baZPa26gMwSLyltSSSWZbaSSTbbbUkklb UkraksxogdxdzLPcq3anLhJ8AbbJJJEkkz3PRS25wxLqC5GwBCSe7u19ysAH WSNuSW2tvzTyeSWJBYCSeXRLl4RHuojaS7u5Wkkk5ktttttkkkJJJVbbtbVz s3pfPOfXQ+u5O2kVduoC+M7PVzxC7J9Zui+FYWEDnesd2a3R58pxiDLUZmIi 9jz54EZy8rsS7F6pC/dQBw6Lgc2HLmr0WExUzjN27kGw7uZMq0JVwtVlnfZJ L57ALuXfDefjvdZvu9msie4Au6UA2mLaMB9XyPTPart4KKBNDVFG7d3NTMzM mpWZWQrrePnuvqWOp17F8pIL5AC+QQXyCmpJBMxVzRJDMXAM3rTz3O7er7ne XqWKbuA23AAKo+SYU3wFNz4swy+beL7veXycqd1JAvswAMtACWrQAC1Vjz3b zm+PF551u+Zy5ri0AAtVVoAFqqvAfPO+13XXTznXfKeTlzXOBgAKAEYZlIW2 GmGYugAC1d22298YqqqAzTpDXd5667nOvNMmW7WTNgPW5JJIVVUkkkKpqT5U 4n2V2TKVorqLJe22mng2yJSSAFAyNfKl9IQA6STlz2xmUomNdUde3njAOSam ru7kmruwBrUGtT3sd627dmavnVc1rJC2gLLbIW0VSQag0NaE1KKrf1fX7l75 fu8t3O/dz5pEAEXxfZ6ueI1R567gvurCwgc71jx1ujz5TjEGWoz4Ei8NWBGQ NY92NdieXUH9fdugbFu4cM8Mur6e4Q0vi923r1OrOzLhwUNI2FnfSSvYBdy7 4bz9bDuYqe3ORLvn2+N65dTz31E9SiY8rGKrJqSRlvl2AA3d33rLvubqbTHm uyUXIkkvvviSRfL7776SQAfyKAAAAAAANlTal1aeOa7FUC7+SWJBSCgrmWW0 JbZC2mmEMykK1gqva517t2Xl12m8HWbdWqqq5LbCS1aATpmuvOOi8brtN43S 7JatACQtLISEtFUVbO1zfXm3ReXXU3dN1VUgggggggnZedrN1kdpnU3dRgQQ Tcmpd3BBN3eGEzMLIWlIdeddb3dmdbvtN47zeFkhGtQiahEIIIJ9d3Lu7idq s6pdW9pznZVlibabababaxAIATbQgE20VsrJUutz42ncdllxNtNtO00GZhhD MwwhmYYQzMMh1VVV1rRrSqqqqqt1q60qqqqqrvvwfZwZk6E5Oq6MkgAi+N5b 67PjijO+tGrvdKFhA6Tsag4mT1K0QhlqMEdQtrfbptfitI3IsmumHKNRqRW7 ivlm616b1Gqzrk2LdzJgzmZGNi6z00yrvZ7vLz9JrrzUeq7DuEPQ5Eyb3jN5 48o042emUiySRe+SPvqr74EffAJtptoQQQQT3PVebe9zbfKl8urtBBBL1Jq7 uCfSS7TUE1BNQSvb7XMvl+9fKmctmZVVWTQmoJqCagmoJqCSEzfd9rN3y+Z3 HE2y83ozUl1pK/kq+X0+XyDZtGDs3cpFkL2bWWO92uJqubSBNb7zbzuczj3N 8s1XXMKAsB+SWXkXwDbbbbbdYbm1MMMmzKRZLvYAAa0BIBvvO1e75fLvtVU3 vmc3u9S7sAAABzvFd3fL5fs9Wuc7Wd3sAJIqjWoNahTWpR/fJt/fJtooWR57 q4zDtu7klzyvxjXnLnljsW+VGrvdKE9RPTS1NF2N3vErRCGWoycHULa3278b XuFbUuy+eXQizlxsxIrcxTyzdnreg1WdcmzMzJnYozzY6u6pV3lbfXboBTGX fPT4bpfu9y18TJ3neayz1TTjDZ6vszZt2238m382wAAcl+56vcvt8vuerXOd rO72AkGtDWgAB7nq7u+Xy/Z6tc52s7vYFKVFKUAHru189Xd3y+X7PV9mbU27 bbb4AAAABttttszq2zDl36q81znazu9gAAD13d3d3dc6tswwOVdX2Zsdbd8A AAAAAAAAAAAtIb1Z7zlabDvJ5nR1t34AMzK5cbVVRFVbcuYIqqqIq25cxVUW DblsNooqiimsurrBRRRRRRRRTWXV1gooooooooprLq6wUUUWKqirze75nsc3 W/X7BqEY6wnnZVKlVVVKlVVVQurrFVVVVVdZdXWKqqqrrK1rWta4Qy44Qy44 Qy44Qftbvnn3bq8vX7fxovMXmtOiGXHCGXHAy41rW78AL5AC+QAvkAL5P5LJ 73q3ee2zTy/JvftV5vfqQUgpBSCTLmELbaqgsPlFSsgsgpD2+5u9zE573nvb StMCOnRwInjeW3Z80+yHPVXV3ulCwgdLY7rxG30K0QhlqM+I695bW+1crZ5P aNyerBK8Be4Vk5mFeObpZyqK4cCedcyZFu5kwYzIhJtk0yrvUu0eukAvrnjo 8T3Sb2PdnBC4CiJ1wN6J3c8/bM5z2670qqqqqrmtd+zzz7t17O58u9fcMzMx VVVVfSQtXu/t+Tf27p7ndfH2znMcxVVVVVbXn33nf3Lp7ndeXrWYUUNtttuJ AC+QAvkAL5AC+QAvkAL5XM95Z6urM3yI3Y222222Bku7vV3Y370v1drvL9dV h6wABsAE7L36+1v1T3d/emTbf161BJFFKKqqoUUX996t/VPd325iZ6wrW222 35JAC+QB8kAJfIAXyxzz6s9SzL8iNR5y+QAvgG226bpum6sABHPanUsy+RGm 5lAACSAPvkAfIACSSEkkkkkmG9V1t0r3YV4vrnbgM0koHxfLfXdnxW5Dnrbq 73WhYQOk67GN0iTzT0Mhlqs+I68trfauVsWevbj9UCb7rpHV7FuYn5Zur09T TS+M6U9er3cz1Gs2oWbXgY3xWPz1gFbzzx3rbzmU8DkTPXLw8/Vu0uy/IjUA ySSAEUkkkGwoBsKAALJsV7SmatjUDAAAAAAAAAAAYE15U2pe+4y91XB6VVSS 7TUE1BNQSFK1676m9Z1da2qp2EZPkVX2vPPJzPZWZ2qquzQmoJqCagmoJqES Qjva32pzOzKzO6qqK0pUkUADUmhqTUO97WdqczsysyugABrWk228BmCXyI3I JfLYUbSybKl23uCXyI3IJfIjcgl8iNyCXyI3IJIjcjkcjkcgkRuQXyI3IL5X typtLYZKux7gvkRuQXyI3IIjcjkcjkcjkcjkcjkcjkchNuVNo0pExvccjkcj khKkcjkcjkcjkcjkcjm2XbuF53aSxh6BBaHuwNFeN5bM2fLMnZbHzHhCiQOk uRrSTJ7itDIkUdjXkQ+etTmAjJFjR7D6sI04Lo2HRmexo4O5+pENbIU6o4LO sndmeOQt9Hsb0075a2uWvbmDDNFXKNzmOnyL8pt51epbtHnWyyPzefLa++cc GklQwf3yoYQXyccH999Qwh98nHCHyccIOOEHHCGoKKm0jTLLe4GjjhDEkWWO 7+SLljiThB0MHQwY2N0MHPvoEbiSwypV7SGXA24PV8rku3VNyQtfO7hUkIqi SckuOpAqgCpIRUgkUVbSJSj2VHkC1UhI5HJl3d3UkjAbAYAABVXSuUpiI5ku wAAAAAAANkkAABVrWSlNRHMl2AMBsBgAAAAAACynVykYiOZLsAAABA02+AQA gBAH21dZKReqW7e3YIINAQQQaHvKr1d3Uv0vLr7JQRR4qqqqtPta0qqqqF0a whTMwg4ZhBpmEHMMJpq9c6mdPa3m+mCiin1sXxPYuW1sJv29c++0EYZk6BBT jQ0V43lszZc88yjBZq73SIkDpLka3zSUHuK0MiRR2VIh+561q7jdsimz0XLc 9eIQwTVrOjMyo5u+nr1FiIe+tHlcrfdmeGMu9HsWCjfFexbr2TBhrVcN9zKb fId+e3j19S3aPPbo3fbmK/NtEV97SnOs37DWva9xQP5DV531X2M17HTrmt1V VV9bbV5mZnWqnOVKrfbrKzm6wAAADLu7riu+Jx3jp+13jveZmZmW2pFVVU67 6muYvec1zvdKqqq7LaQtpC2kNvBznXi3nK/ua5rmt9Z8yW1VVZKyC1AqFFVh WQWCq61mKqqqqq5mYqqqqqrmZioGZSFtIW0LVWhQmbHTzyPt23vM3rNEFIKQ UgpBSG7SFtIW0hbYHc7sdvNJvpw73N63rdqqqqqrvmXvB294m+PDvc3relFV V4BbmEHMwhbSCkB9yxUjawsnIQK8aGivG8tmbBnlmThto1d7pESB0ljr6NOj 3FaIRYo7CcHILUtXIKQRTY1y3PWBFnBRy70WjPIYd8W8p42qKV+rrfdmeDLv RjpHqpa3k32vbmDJGtfN0+5qjEF0/Vt5tzkdfX7aZzj3t3r2ugcSpBSCkNdz CH1sikZ3Z9nLrbnxzW/d33n2qqo7JUg2kLaQqQUhzBz155z3Nd7rm/XWwE0q 0g1pBrSDWkGtINaQ9Rz135z3Nd7rhsx0Qa0g1pBrSDWkEtIW0C1V13Bzt51M 3ned0VVVREXTWtudwdcveJmzOd7pXS2i1rflJoYFA0wqqqq5qpr7KupxO0ld VVVKjDT3Xseeu/O9Od53RgQFFVUFXq65e9cd4853PnStkbYViSVkFKyLCHkd +95Kbzu/aPITpPc++zd297z328fUQK8aGivG8tmbPLMiy3tPe6REgc51jzsa Kg9xWhkSKOwkcuWpauQ8pJqnRLpuesCLODr27DozxGa+8S3ljDrYSlXplxt9 7vBl3o9k89Nq7zU93XwfXLyEKXPzVZzVHJ3PVt4+pU/btJ2Zfp1/L8kl+/Wq 337auhn6/0/eSe+0ez3qushCzn3y+tKvt7dede1dYSMs5vl9XVdOb3VdZCF9 XSvkuzB0XvbWKthC+rlWNtsAA1oake7yovfvV3jGdvb3ZmAAAAqpz1cpme9X eO7zN57uudlqqqqqqe7xut9fbvO61vXM9Ti8LVtqqwVXfuVuvee7vfta37uf U6qr8FthxVVXMzFVVVVVczMVVVVVVzMxVVVVVXMzFVVVVqqoGvlPnlbyLp9u yZWGQzyue7IOS82wiYN2n2eSKbGPzPtqR3x8x0IJ13vd73fNrcvvX3719iqq uABVUuq2rS/pLN3dA3d3d07anpJn6OAFPdttrpJAt0DRnHtZIRJJ8B3eMlvd 3RWSSSX2VvhdvIwQUc33d0dsjezuL3Mzsr3lXd27gbu7u6ABu7u7oAC7u7Xd 3YAvPszMy8+zM/wVVUAA7vz3l3d2zJM3MlXCZjdWZ1dvUgEXMtsrttpPiSUk vIJ6kvYSSVVVO/cADMzJu3dUxnlfdz3tN3Mz707d7Pe2cHc3d3d0ADMzMwAA Bu7u7XvaDjd3d3V+8A7u7u4e94AAKqqAFttt7u63Ekk987zbTqSSV/lbz02S T8AAJ+Apupd1trbm7EtndWTUl3crrm7ckBvSSSIG7u7u7u7u7+A971toAAu7 tt7u62ySSRJJJekttkkk973d34ADu7u6/ru67uABu7u7oAADd3d3QAA7szMq Xe7t3etqRJ4YiSrYwBTtR4k22yGel4AUltttWtmozQU8MMGbjTbSXd3LOQ4T u7rV0i5LMVbzLbUkpCSZJYnhMAkSSSSUts7uotSSTzCSBQBCgyAiSsyS0knw ujg+qz1rACtbaG7eJ7td0aCGom2SSSSSW7ZKSeQsD3T4txzidJNrbbYAAbtt tSSSVop74ZmavfuvV3Mybl237l3d33AW20AAjwAsxybj0UlbqHdT7CB3W2dt 60pEgACQ86TO7uUqSSW7PJIlMAAUZLb5Ek+rtJ9UlJ5N7jbqQOGq393Bu7u7 o7rqv331D373j93a94+HWT0nN862L3dx3dttmt0UC1JJKJJLYDd3d2ve26qg Bd3d0klyT3vTu9JJIB3REkgBEq2emR9Ee4TkAI0k+493eLa4MkI8hMy5lcbf ylSSsfuluw4+B3TdvN+VI3d2xJd3dyqqpb622gAeFoWE6S0EoTpJ4QkyWXMo Abu7u/tC7u7fAPj93d3ZmZhVbbJJJhvPm3bbJN3ZK767bakiDlrVJ0Q7tt3d YJqVY7u7lifY3TetkpEDlb9SSBGknu62/WSSKtt93c33d1du7tvpJPNyRJeS A7mBpJfna743POZJKQBu7YsxOSJJLVuKS0kkuRqVJKu2pJW1JZkXdUugzHZm bu2SyDJmCnwFtkkkkSSW7uOrlm6B3Io93IeRNJAL7naSQG0k1bIlW08xx5Pb JGScAOMb6damAK/Mk93cYAALu7baAAbu7u7JJJp3fnfsr79K71fZW24XPcFT G/BemP0wvss7T3ubRIHOupsZyKg9y8tDIkUdmHxAXIdW+HMO2zJW0ZueMYnp l6vxi3MFnUeY9UarXyzvZfOeZuiJe+fZhrzjPYnt8hi1N7cjHDs9NO5JOGez fcfQ3Intzs3scErAv2vqnfE2hDMoSW9rW1tbVFPvebrEgVQJVR2v33p73vCX Xmo0FMC1TcU8BGHgUlBSCkFIKQtpBSCBWBSCkLaQUgpBSCgxBSCkPvdbzX2t 87rX33Pay874gpBSCkElQwFUUgpBSCkPYqoKYAmpADn3jlZ3jfO3mffc+y25 yqqqqqqqqqpuohlV7Lcr2S88Svez0GrrYBQMoGUDKHQKqdOk202yivPKTK9k v2ye9g/ZjUAQ2UDKJ9CVIvoSoNNtMgivnKi6+3m+Xfvbt7dSyCCM1rWruWQR ShBFy/XKyvb97fe37m8tupZFKEEEEEEQ1690uvZ7Oc97mXd3ToTMwyEluNat opXjWt0b2dm5vX3OZfVva7464wp0XqY34L0xP3i/WXd9shZA5x1NjOSnea8t DIkUdmHx7Cqlz5hzo8cbenX41ifUdV6+WdZzHkBkSjtZCvcemxLuzPA27Euc w31m5wxeTfXPaoT1IctNV3MVci0erryvCorHPOuzudWihU6oZTpABQN0FrjW ta1vka+97T7nfV3McGoqq1LpVAOX7cpXvX33Mv11uWAAtUAvkAL5MBfIbXyb a+Xc1UrtM7Hr8bmsIW0tV9S20VXeaHT7XtPud9vKl1VVU1qSs1JIbAAFak5f uyle5bu++VuXylKKopRVFAO7lZXcy+z3Pcts0q4S220C1VVczqOnveay95p7 ZpVwuswhlpC2kLaQtocFEFuUg2nRjnd7zOcx7ZtVVVVdX2pV87u+8V1Mnq2D gABfc5U9uUyTL0FCnVUxvwXpj+C9Xd32tlkDnAYvcbO875aIRYo7MNxDEylz 5hzo8cbenX41ieGepEq9v17J3eHeZbVrIUPbOhXdmA27EEHMVpiq3vXdhEs8 S7sUctO6fcxVy2avX7NK9PqeXx2LS+wAAAFVv1a2r2+Xfueznqqqqqfq1tbb bbd/I79z7PufZx+78qqqqqrw99Xnebz33cxN+VVlVVfbjnfcuPfdLr21VVVV VdT2nPeunvul17aqqqdBfqv3Y8zf1PfdLw156RtlqroLaQtpBtINpD3I83z1 Oe6Xhr2ELb0ikFIKQUgpBSCkFIKQzKSSYxZmWSGKKyEDMoQC2hAltAIczLJa u4BPdjdc99h994vTX3gEk3VVSpVVVXr5SQQb9Nm+a72rTYeWeQItJAiRfKRS RfKRSRfKOKDTChFpJyOT5ffQRE7vs1Eva42V6Zx1+vt3wXpj+CmWdu+1ssgc 4CfDsr7ynloZEijsw+PFVLnyDnR+xxt6X2eNQkO+IiPtOe6bvn6iQ2MhWode qfdmAu7EEN6s969nefCjfXUxMfNU/Kx9zFXIxHq684+p+29FvcnpXYs8fIQH y+QgPl8s0a1qENaNZOpA1o1kIZhmSGYZhgC4ZQ8DEWJp0apDc13X3e4d+8Xu PuHNkMwzCGYZmyCkFIKQUgpBQYhrRrWiCkFIKQUgpDV0azMMyp4iRSL5SRSL 5QQL74w7uBN89WOr3b473pBSCkFIKQUgoJ52bN60qqqqqro0a1pVVRFVXRqa 1pQNGprCGGTMIYZMwMyZaVrXAz2vc7mFvr05XffTtstsvC4mYQcyYQaUgXy9 FPpF8qEKRfIKqSL5RT6SL6ZM+9mFv17t5jzvX6fUszNySaNTWtE6TNm5vRDD JrWiGjU1rRB0amtEM+dTW9kNbd/XdpKKfSVEphvvAmsVukZ6vfb4lT6SgQ2g BACAAAAAA33vV9rz14CsxY6k7OAAAAAAQAgvPkqqqqqVVVVVVVVYqqqqEmb3 vQbmtTMwe9utbd9v13N3yVyqzPeAAHaSSAEkkA3Vdr1/EO7m1BYrdSakmpon rkmtS7l3Jd2R9NS7lkEEZ9/4vvvpFJXfuf2P9782pkWLHXsxrvAhtCP2pJqS ruCCWSyCK79+7f17/cyafxZIm0xvwXpj88LmW9u+2Qsgc6CfaK+8p5aGRIo7 B3H3cE3pvp0ydArRZlb8tC7PFrwYz16E+057ou7x71MitZClQ69ZaBmFRaTq 27bU/RoeHr4aeC4KOsR5S6fcyvN9lXqy+vesIua91+MKc8vDHXfCiiiixfxC 0WL15+/e3y/vt9zC65+W4678KKKfglopZAlthAtGwkje/d/e1y6/fdzMLrn5 bj9v1XUkk/AEMygElqrZAktVbJCW/QJP3fjd7++7aZ3d7+FzH7n1+kJ+IApB SCiTM3KtaahAZcaqqhgCyQiYhio5JJaqY1Wqq6zxq9/e5aZ+3e/hda0/c+v4 C2wgW7CQtoQwzFVSyEFCB+1+7+O3PcTn273PxXWn9xDAAGFJJHMd9+zNfd5a Zt398V1p+4kKZr3D7fx7dzO15r7xm9/daSCShJGeNn33Xn1zL7Ob+Lbmvvea KKfBGtCAWlCAWlCQtFFFN5419p58Zc57vPit7r775oowVYCoooqim2+634uc 6xgoUIm0xvwCmM57HMt7d9rZZA50EvEFZ3o/PRCJFHYPcfbvIrTRzzmGVaLc rfloXZ4teDGevQlYmfGbvjb7DKohx0OVdetspOYsdWkatdtTmqheQ4ReYbYm eV16utPUXiqvX2aMUz7j3vfa3u57nxW80+79UVShGoqixqqVUu9Ww8nt7nA8 nk6yT2c/qpRNtNqta1v4JMzGtf0JBzLky46CBrXw/vh999mdzut/jHu9fn32 aW0/SQLmDaYSW41rWta5JDLj+AAy4818b/fD9zntab3f4urnd/fetwpaXoZc H8EDLg4ABlwS0uEhI44NaW0WEyAS44fvxrnhPfc7mr3f4rdd3n33mmilWlkL Rsg0aQpaQpaQpbA/EcxpaagRLQmoQnN8/fjPtvec+1pvd/it1r9xp+CFoIjq ilEU8bAlMoQJS0JJ+38X9mvu15n4rd/b7r72io6KW0qKKKKKOjx9v3d91l5r 4rz7ffvvtGbCQpaEApaAUqPaVOChB++Pa++5lu+eK8+33n31+2fpIgZ+N9+7 zLd8/Fbz9vuv3325OBBz3vez2aRk8tTgtE0yq1sjUY34KY/eCmWdu+1ssgc4 NNUwkTvNeWhmQxWTCF7dDeeFnPH3mFfUWZV4sLs8WvBjMw2ux+fezrw72PzB ddLIRiGy2yUnMW+x3bx773s3sBeQ4OLxDbEzyuvVMXZ6G5U99d8nO3Wsvtzf KF20PMzL4L0S63fPit59vuvvvs2rAWQWQdWQtpCtqaila1QPfa5373bN97Q5 9vv33zu6P018A2xfL4ySJffKSSL775SSAABF8vlNpBSCiBve9/juvu95rLnH 8Vt5+3377n2/c/SSSS7uqAQAZJJV2O8nb+3Ng8/Km7M/bPez13fm3+SS+RAS S+YCkkEkkKqVcMySSS7zH3vTjmeyzf5U3p+w9N2XbbPySSUklr5JSSAAAbJH 8l9KAAAD9yHf7uuDz8qb4zDPWyTWA2AwS+AABpFA18UDKAAd/PPRe7sg98qb s7DPewl3wA18VVfkkBatAAtVV+vTf33D9+53u9czfhr7ne/vXNKqqu6223yv T2+8Pve93euZ7g18873732fbFRXvoZlluW/oS3Lbga5jxPv3Z+H5MfpDNC07 +Lb8FcfvBTLO3fa2WQOcBLzibB7l5aGRIo7PDuPu4JYFc54+422zK35aNXi1 2B/W0z2nPZ14dmZ5PGqFayEZWevWyUnMVmLSdW+e21b24LyqO1zDrEzyutqG dWX6ummxbZa925CzfKm31Zu+89mCAF+X33ykkAbdkLmZA2AoZrArthpSCH7h +/Z+N9+5rL34bb53z8+88PxCCH0ieeUz99O+5vWXOfhy71rzn7777c8/gtVZ FkpEYlZBYYApBSCkFIKQU+p+79Pc5vWXnRt3m/1v77773J4FGSofRSKRhWQW QWQWQWGgFILBCsgsgsxOeO87zWXnRt3m/rc++++91VVVgsgsgsgshx6nX72p 73d6y88Nv2+ffe56QX3vhhK9WjSNc9m6KNVbnvsz33sK7D3qnsM8qj9ee8+1 SqXyql8qpKtvpT1e3uhYp7NVe3bV73fe97JFlPzcg49iM0IXdtq994fLOHc8 3dWp1ksmB0I0FyTyuX3uXkru+bIZJ50EzibR7j4ZoZcijs8AAfDilgr55zAL fnjJ90XjT4MZ5Wmt+2Tfdome6dk1xWMhGVnr0kzrmelgQIQywfObOzs3O8tH GIID2Y90x8wYhXNL973dZefF7znzefffXyqqqv6Baq8OK+9Ve93uW5+lO7/Y 7nvfe/agkEkKVVZ7tuPfL73e6y8/F7v9u913XJ5VV6L75NtL5fl8HN8PP1el Vnt2Dz8nv6Zs7q3cOgKQUhmUIGBiiEM7890u++OjtV9rVL5F36+zM+ma+7oK OYzC6x2q+dbnr0ml+8mxtlANsQDbBsKYDPe0L9JVZz9rM5Tc9endfi/gD4SV UvlSQUgpBSCkRy4kMcykMtkLbIW2Qtsg2yFtCd++59ra9993WXni93z7l371 bySVSiD9NF0CqKEb1U+r799+yvyt5xW6+zmcz7KAMXYABqHfd93b77L3hyvH 7ndPdfbkLbIW2AtLbAkttV1VuwYKLAUgpD45fXw8+d6RoI9C9g2MVUw+Vy+7 PYuw175kgtJc7oSWrytfuPhmhlyKOzwAPu0I4FqysA22y437Al4teDGDFarJ 7XjGZcMGTbU6yEZfM9aLKBnpYOHFZYPOTc89Z9h1Qjx4ZM3HjxMmh05km7uY 6zMOwl6/ZKXyql9SSGC+QAvkAL5NgvkAL6JElxIclDbfe73uqva3uZuJLouB dQ3Nz77vexuXZcxvdRe4kuze5UgpEiOO+95ted7md5uvHd3A6CyCkM3ec5te dt7zlecvLm+HSC6VVURVVtqqqqqqtpVVVVVVZCISddd51e9t7zleb5luc7DS oqqqqqqqkFVVVVVVVVVVVEVVVVVEVVVtqqIqqpUgpBSF5e95tec7mc5t5y8z hDfe83zMSfe5I4lq5ffLMzMxPUVmJPs5I4kuJMPl6vlMW9O7Krs0My6yixp1 zb2gAuxNDQmoNag1qfSXf3cPXvf32/pW6Drdo94W+9L1OUPseFZRT5SF0djV ezhe9LPbPPSugC33hdjKlezaa28vwA4AKqiqyrd3duN3dA3d3d0/HdXJJets kklvXZttrpaRNu8KdR7qgGST4DT03ZRu7XfXO8kuQIUgvZN6WHh3d0csnm9n cyAIu1XiALbLbUlu7oAG7u7ugALu7td3dgC8+zMzMzMz9fwqqo0AO7895d3d syST2ZdyPq+8++c+Oyqp98IBSABWmwoklJLJJ3bJ622TG3aAL3d1LrovbltS JOuJQjublrslSSSVoAZmZmAAAN3d3a97Qcbu7u6mZdm9e9Kkjh73gAAqqoAA KqqPt3dyelLnt3W726lf5Yp3d7pJPwAAndJ4fu621t93czdkAtSSSAAC1JIJ W20kkm222pJJLd3d3fwHveC7u7e94VVUO7u7u3dSS9JbbJJJu7JPW22222yS SAACSAA3d3d0AABu7u7oAADd3d3X6/1373rs3czK27vTpdimpJJK2yQSX0wg UGRt2O82apzbfjFIu6DG2ku7uWchTeXcKmDhOYbXmW2pQN9EiY5TGTOMhJJK Utvt3bbUkl6QAcQBAXpI5ALMlsAHu9ma3bmdEONiSb3Ilu300R1NFEkgMklO 23yJPIViW5vN2yUjDpJqSS73dyVtttSSSVttzLbW1e3OnQDc46e8JIAAHbbb bbaAD03QJXcOcIYt2d3e4zNA0m22kDqEUQAB4+mnOos7dUpSSW6B3BAAC+tv DABJt6tkvdTUHJKVy+bstSSSVt9LSOG5Ab2Lt6yvrC9tzK+4ySaJO2+bD3sz uu7tsskl4BG1uTd7d3d2A3d3d27u7Xd3YBd3aRJJ7urySSQHcykkgASVa7dx sxtOmQAAWJToAe56J2RMgkkkAXMu7stkn6R+SSS9qFtOAd3bmP27rd3eNvPu 5vT3O31ttAA8LR4A8S2S3EiST4pJSW3MtttttqSSXlZO6gWSSSOySEkkqttk ki0+3VyTtkkm7slvrbbUkT41GAaGd3ZJu6yri1cqzzwBd46l2MbrZrURIrlk BJaSkkjfd3OO7u7UklVVSe97u75dA2fgbu7t+8+JJbttqWeczekq7hu2LMUk iSSWYpLSSSZIhSTa7SSZIksxrolyhzHdndtkbuehNXibbZJJIkkt3VrrYve4 77YYyATW2W4kyW+6VEkCyNuN2RJIrJH52ScToB1SyNYTYe6R+8yT3dxgAAu7 tttttskkkSSSVbbatkyXc88HN262gyyWdF3qZYfO5Pe5dhr3zJDJPOg8Zh7L X7l4ZoZcijszAAfdoJRo55zHmVbZcS9gL8WvBjPK01v2vPmM3fBjHsitZCMr PXo3Kc9RBw46tsPrLdz02r1WwEeIHsy5uFv3MFKmmq76uVd+57lb7TFld1qD WgAABRVb9m917fMvvuuV3vb2wrBRQAKKKJv2b3Ve7zuZ7vOV3jF9uWoDbbbb bbb8AJMFM9ezK9mw9u5W7pbqqsAUUDJd3c1Lu7mpd3etTfs5h7feue1ve3lu EFIKQUSaPe5s9vnc9vWnlzCcVVR97mz2+dz281y3OVVPWKD7mz2+dy6cd3N/ ef5CQigAKAAiABrWvu+2fcz7NXOcz4PgAEQAE4pCgWlAkYHvu90ffcfs19mu 9zZPgAUElSX3ypJV1fep+wWzc9U39e5L2ZPzPX3uPncn3uXYa98yQyTzoJ9K ltfuPhmhlyKOzwAB8OJQWrtrLSvrb6pewF+LXgxnlaa37bN+E3S4c3bVayEf Ss9eih6qXTYQt+futauyuKGda6tLtXIqrqeHzf289JGUu+ie9vE8PmfY0j5p 72k7yWyCuK2PMwiyQWRWx5mEXyrJIt21jm5txfLCCyK2PMwixJOpt2ttY/Tu 3muwRSCwUFgKQt1rXn2zl9r3vc7sgow8irvetPtnL7We97O+3bbW2lYb3zde 3OvZfvevnZVVVJBNQTUE1BPk218m2vlt697F1mez06r7Pc8mlRnP1u2edyfc vVvzZDJPPwGDzFtfuPhmhlyKOzABx8OKWArt7er1pX1Fztvq/c2/FjwYzytN b9rz2c8883cjFSIUnbW13eul6cx2GetatWOreWtribacnKnQt1GxXZnerrWO /XPRZhF8gBfJgL5Ntal3d6i7AAT2+erjbPb97Jzlgbu7u7ujoVMbWmHfB7zx HAhIPOaYNtGGm0e1Xjcm1capR6O8hkq002jx996G4HwChDrrvzz7l3vvPvtn wQbo7377OfKkePve29V42vlVaPAaXVntlk1NU6g+wb02l2zzuT7kcW+SARJ5 e4E3DbZ7l4ZohdijswAcfM0uTCZ0G8HrSvqLnWsorx19gZzytNb9rz2c8955 u47DWyHLiHevNSU56ib2nlR5vj2eOnyXmIRBOhJW6jYreztrfdDL7hal98sD sW7565zZ72HSEKyCyCyHK57hzvfdzvDk72P32Z971fYK/OSvmlO8/ferGCv0 krHec9h0B5j7hzvfcz33e/aPUVwtpCpBtIdx+4e73681fnXPYZ36eICJCMKk FILPKQUgohUgpBQgZx594732+apm+4Zw4AAskkPFSCwfTa+AJvrmvG7z2+bv zrvsM9yA4vSQKWhChbALbJCbbnDfu75q+dc9hnqqqq9SSScKbibpv1YiVu9X ivS/c8UvZVudvUyw+dyeuBjA35khknnw0PNtr9y8M0MuRR2YAOPhxSwV8xvB 61fdRcCkl1ye6H4MZ5SmtvO3Ps552fPO3IxWiEZGevRuU56ib2nVR5t7njo9 Sxs9tFx0dyFsV+yVuRb7ryP1Tmm+KqqxL775uqGxL5fMKbbdVclE5b3XkfVO a04rfkSdplClyASl1StaiijaOcda4c93fNXzrnsM8OFFCfQRAInoSPLp5h7f 3t83fnXqXphESCJBEgjBGCBvm/ZzNZeutdwzp8AoEjaAQqARhuGve5msb7Lo 9S95BYMSBENkLIQtuuubusb10dpe7kCOKFCFlr3bIU9qLWnqtJJKlKVUoit3 CFayLWXvgUIAoQBQgRSAChEM6+3CFcxRc09XyzVePsL8/PTMrXiy82XmGb1V tPncntzkMVx+ZIZJ58NDzba/cvDNDLkUdgABHFR6dsEO8JpfrbnS16m/Fnwf ytBuT2vPZz3fteRipEIyO9nqkzvSl0xjtr2z7DXrpDcmR6n6dTHXajYrzK7b HHw4taffffTZtMsce1KrWnq+S0mYTNqQtnOrWoffLPlSSuGP3POtZzma9dcM MviTkkkRkkkiGb3rnfernc3ce7OlzPByQBA8CIJNc133O1zmbzXttOmXxNSc IpBEjFkhRCRAQIiECIhvOa77tdezms16uHjL4RAwRGGiCkLzmu+7XXs5rNer h4y+0QUhIpCKQUFAAeQkE+gpFhs73Op49ty46FyH3klSRj5g2wFQm9SX2VvT N9rqcctJRa5D6y0l8gKbrWFPfkl8A26bqqqX3t306XdXu+rni0reBwzeqlpd wT2Yuys4iQiTzYJ7BbWMC8c0suRR2AAEFOQjLOg3hdJfpblVx+0peZ5+uLVF PaszvZntxLJBGiEZGevIJ07voIeHY33km9u3tCXU8fPZzYvcq0V+J2+3m56e WkHV/ch186q1IW2SW0IS1KBI2797m/Zm+697f2+bro8ZWTgEIKQEy7v33Prd 9149mvtY8PjKyVSKet297fud+t37Xx7NZXZ4y9ot1VVVcAmpICrXx7Oe+u+Z 9PfZatzn0y+LFFAqiqqZ7L6+33777M7vc9zLYfKeHLxO+++8/vvve1c9iLcv TiVTpxeVUM1JKvl8slmaeO5u9nLp4usW+ULS1BBhIhBkk5e859v3r9h3maPZ 9le179mofYvvq+VL6lIjpPbu+FrF2+HtVviQX2Z7PZ5MiHIhnYE29XmVoOXN olZdzp45ypOIkIk82C0MNpYC7DnFlyKOwAA+BTkIx+19vW7TPUi5wks80/Mc y/b7ZEfac9neeVHn2GCxEKxDOuxujPQ65UL4FmZVVQP13OTu717ReV1q+ibq Xu9udaiwi2/D2lW+JD5alVL777vszK6OmJ8ggfPrlW5O5Ae3lF1Td5rhELm4 q3xkiS+Wim9p7e3jcJ2T1Oq3wbSpIURj01328+97vs7zNe5r5KvfszuKq9AA qAHYsiSTa328+97vs7c9vvzVe/XkxJJjXWezPLtZ16vdVkqq6eLs++UNXtc9 3nxr7tzXua7q4r377N7u+wFIKQUBSCkFBhJKyARUdYfc37vPj3eZr3O7qv3z eatUCRQgChAGdXsgDVfJ18qyRdO29Xswm5N87qVVHnI1nm2wFFBR67p8nM2v nN+7Xs32ty85nauUStu5PHNVZxEhEnmyNzrbBgXjml1S12Tu70IKchGO53Zv XZVPUXOtb9qb89ONZ63Kj7Tns6+yDeT0w2MhWoYefb4pbMhC+4W7W/Otlbc9 MtUFVrYu7kK1Fu7d6uzCbk31kqqR5OTPRtttsAAkklKlV7N95Pvd5zvubvO3 9btVnrdA2+9czPp97Pd76lHyIBRPMu1XMz28vNfYQUgpBQSOa6fa5v7u7t1z n33MVL9ea+7AZCfNVEec46N3mvjutua5z77mLlM+pzfPlVgSLCAqqiQAj3vO Oz69174+3xzfe+3VS+pvW/CQIsABVenTAABGEDnGnvZ7fTvt9db93u61SfeF l2vujqqp/Nz5ZXwtVwy+XplE3O9WFVSfnlSpVT5KklglXQvOXplE3O9WYrfr zWpwABQAGAIACEBAkYIQG5qa9zN734+31ze+ffcMb9cw2AJ77feLT3Ztq3et WMW4fClm4MoljdyeOIja1jJAAbfZm21jAvHNMLkUdgABBTkIx3O7NuUP0tyJ XMKXnr9aLb7fLrmEdzemWINdajnXVJRnoHvaVO8njue7AzxiPs3sfQDvdOgO isY/Rcy6FRNz3sRT80H3zVrsyZvemjqdneyqBnn5cfce1R8nPULIDGKvZm3b jSz32d7Frs5O+oWcGpcX2XaXiz743d3d3d2fAPZsvDN8vTKJpneo+rz9uZV+ bfLykgA2wBOnTp06dOnXLPPZZncvTKJud3nv1D9e1leynTqDKBlAyghKkhK8 ru5dSDhmgcMZm0Hk56hZwakuvwzRtxlbtUcgSpGUDKBlAygZQMop06dXevpZ u+XplE3O9UxSjz9V3j9lMZQMoGVykJQMoGUDKBlAyu2N5LN3y9Mom53qmKV6 vVJjr2UxlAymMoGUDKBlAygZSAIlc19eG+Xi6M3q2/uro5dVfAFAP75gL5Og f3yYH3yAPkgDMzMzH/2EISQkh/P+RSKQIIyEkEjIKKiQiwkFWEABVkFIIxSR YBBQhIiooRZERQAUJIoLIKSLJARkUFkikWSIrCDEFFJIoRQARgRZILIoAoKR FQUkFEVFikiIQFCRZIKoIjEFFhBZFBEFkUgsFISIkFIsUCLBZFGJIsIsARWQ UARgoKApBZJIDBhJFiqQikCKCwRAhJBEILIQYwigCyAKAQiwIoQAUBYRYLIQ iwFAUVYEiikEZAFAWRYKqyRYCgiBAUgKBIskgsIsiwFWCyKCqCwJFFAUFkRg AshBGEUJILAUFIAiiLAgsCRZIsFUBYCMIoqigoChFgsUgxkkBZISQikBQCSA pBYqwCCIqgrFiQWKAskBSBBSKEWACkkUILBSCyMSSKEgKQFJBYsBZIQUigoS CkIpIjAiyKKCkAiwAWLCCgoEAUACEikBZAFjECCkihIpEZCCxSSAoIyAiCJJ FJBQFAWCMkgosAiMFiqKIxEIjCIogoKCwiySQRkWQWLCCyRRSQFkFIjFgKCw iqqKCQikkEQiiiihBYCyMYQgpCKIqCqSKChBRZJAWCqQUiwFkgEUFCLIEiyC wFFCMYQikgpAgpFUBYCxSCJFigiQBYACgIxGQFFICwFkEQWEFVYpJBZFiwEQ VQUgoSKAEUhFCKKSCwFFAWEUIsigKCxURUQUUgMEgRQWCwkixVIRQFJIAoQW ARSRjCQWARQILAkgoSALCLIQgLJAWAAskBQVZAIoEJEQWKCwUgCkAFICgsBZ JFkIoSRZJFAkWSRYRSSLFAgsgoAIyCkikWQUESCkFiwiigoQigKSCiJFAAEV FgosCAsgCkFBERBjIQUURBQIqkgoKpBZCIgoIiiRIEFIsgpBYoCyQFiyEUgo QWLCKCMAkFiyQFCKQFJBZJBGQBSEUUFkWACxYRSLIqwFIACqRSQiwEVRAgoK EVQIoSKEgKLIpEVUFJIoAKAKKASRViiIoRQWQiggxYEkFgSCyQRUFWAoKEFC AKCMkAWQkiiiigKSKALFAWCoqLFigRAVIRSBFBYLCSLEVgsJBFZARFRIRYSA sAUkgsEQgKCgEiMgrEkAVSRSBIoEIqyLJAUhBSCyQFgsisYRZABQBZIQUhIs CEWEgoQWAosAFRhFISKSCJIKRQkUIshIAoCIIrCQFUhBQUFAWRRUYQkUUIEW AoiojEYLBSCqCIKRQFiyKskUWSEFJFkkigQigCqASRRQFABEWSLCKQgisFCC xYRQFUgoCgLIsUgLIRVIoRFUYDEkigEWIgRVgLAUILICgsBSEUFJBQBEBYCo wgpCAosgSKQARiwWACiMixYLFFBUVgqgCogsAUFgskgpAgiQiiICkSICyQFI EFIoRSCxiSSCwBYQjGSEiwkFISRYSCkkBYBILCLAgKALIEIIxQFgLJBYSCkA UIKACiwJFCMZFIoCIEUICwiyKAqwJBYsBQWREigCyEBEEZAFJBZIshEQiiwg oiRRRRZCRQFIoKKskikWEiMkUUUBYsUgCyCkhFCQWAqMFRWAsiowAgCkFIf4 hCEkJIf3CEJISQ/1kIQkhJDRIQkhJD/wkISQkh/cIQkhJD/sCSSQJD/6QCEk JD/hIEgGQhCSEkEkISQkhsCSSQJDhJAkkhIf3CEJISQsIQkhJDCQhJCSH8hC EkJIf3CEJISQ+hCEkJIf4hCEkJIf3CEJISQ//MUFZJlNZ4WOU3QIoKlmAYBB AAn/wBaPaQGFxW5zQAAUArqAACgAAAUBSIAUAAkAkSAAAAAAAAIlAAAAAAAA BbAA0CgACgUkkCgAAAUKUAVCoAAAAAAKJAAABQAABIAAACgB8xhCumQG2AAp IDffbiZSGCVTd8Z4Q4ePcU8Jvexu13jej2bKXDg6urLbOG1Lu72ow88SeeDe j088GbvFePqgBQBQAFKAd75t90YeCOriPLeDY8ltFw7qAdPd4vPXvd57sGsL l3jja7xeHFo4Ju0pwTth5h2d7bQ96+qAJBWtAClKNDvFHcGADdvvBzXp7vPT 1d7DK8PKXDXu3A4N7B6bp28HtHQ4bcgajq6mF7x3g7tAdM19UASAkAFCFvsT wjnB897xrdPBaPeV5046A7hg3XBiljzzc9bvCpgU8q8HPFxRe7vC9e22mZcD uAWfUgUkAoAKEjI98+HUGAw9OD2cxvTz0w7w9PBaC8sk4O1SkkRgxuxoXBAx DOrA547p4L3PbbLeHxAEgFFClCIPrh9XExNym4A+s56bLsyNN5O8elkc9R2l 3je9M1A88rjgB2bg3Q629zeCyuwreeZ2c4LB3TwaG1bRQ4fVAEgFCgVRVA+6 9kBvgXhneM62C50b3PA9uXncjnh25GLa94K7l4OFzlLezwbXt61ni9dnmp1X h2PKh6tje9fVGgyAUAEqVQO+PmWR97eGHAGDtw88Xsjb3i8PJOHODpwXXh0g 2rdiHnu7w200oJhtTstUxyO9eZp3q+qAIgJAChKgc9vvnte8HseV6zylkb3c OC0bjmNVsqwNvLPFMXhDS97Zd5VpL0bxx5SekHg4PO9vLnh8X0BkAoBVKSrR 3w+B7xc9Qq3G9UR7hDqoMNg6AnOl4AXu6C5VwLa5093jZbVwRhdXUI57MPWI VREFFSAIgBEAIgBCAVEKSBIBx1P9MzPVVSqU0DAAqn5pgqUqpkwAA1M2oFKV PSAMhhqe0hGpKqaYAANP1RAkqpkMAASaSEylKjQBiep2fn7d9+q/VUmYGLKZ SiWv1+2rN4mW01EiUki4mSLgC5JA0CNcXJJHMvfmrzPsuPbvY76VW59VvbpS phb91+DcuAl0fqVxHz6L1fqrD3imufSeTUWC+ksGc/y7fYgDQppyiTcTy4n1 x4r4dtsE3C5mk1C61LGZMOujMVV3JwGqmPlmll0zpjJftNeXfF57Qp+53MPW 27uK3M5x69eqr3L3BCI+d19mZ+4+Qa56Dc8VkEt9yuR7DHjFLPKbDxnbuhdh zUZs3j4w6uGUucHfY4oh7JczNJGwXUGN1pcjkNWDiov1r3t4Urz3O1dpWWL3 ZzUMqgYCOxu2+uK94+AJGVZm2A5vI+080tZDCN6t5K5e09MA0FoFPdjW+gPO Xdh8yB+kQ8LfBd+1n2opbX7lN7uZw7pHfo1gG6mvajUPZmTJHWNuwb59nTrz sZ3wyYrpes9PdNNd2XZz7Iecw56GDJoRzE280seRd4Q52pO9lM9OOU9A8QHK dOPPwUju6sG4rq6XiriW4ENU7TmkujOmLlM9recDr8Pc6Mm/Ay4Wbx+ej7id fviE5FV2INsqzbyrHLYuPu196kQ3FnqOzwRFwZB0KxO+FtfuRonuN6gezs9s 8lp5m+5WTNXPoRt8MuQ7vV6UqYd8lh7R2N06gNe3rZ7D647y6tgyOJfU5fJk ImTtxdOV0VwVOM7lEom8jvUtHczJvsq1b29Ow48wb2R6UCABCZBB3i0les9B fQZ2aFgzS4+JzeG7qtjXT1g66HJce3dCiFvFfSnvXvd98RDurO+XQbnz1I7v d99X7tw5euU3OR3T76VUudDtxqyPiQhnuOn3t62ehr14t4XBurOa7OdkW9hu 9vKPKG5WBvJeJ0TB2bm44+e+T5j9hwzVCU1PBbIdx8N3eLC7zs18Bu6Qs5Tt j8ZQlplamZuUWFbSijVEcCjriHUDhVL271yO62boULp2+HhKUCyFy92+nrM8 fQASWnMsdkttoAAAHGZ51+7d/ds2e/e18VsjjLrfe54mkJ7aBYvJDX2ou8NS W+/Lft/b7Xufm+9ZE2Zudxt7JJQAAAAAB77ls7JsWgAAAAAAAd73oAAAAAAA AAEkkkgAAAZJ9JJAAAAOcAAAAAAAAAAAAAAAAAAAAAH1ttu2gABi3tttoAAA AAAAAAAAAAAd73oAAAAAAAAAAAAAAAAAAAAfwA/gAAAAAAAGMnZ2SO7u93bA DnAAA59z4l5bbb5f05JJz12yT8W22gO230yWSft3bXJFtsqXltkltsRad2Sc 3IRdwglUkomTm3JLbbbQAAAAHZJPSd73sA/SSSSPSTskgAAAABJJJIAfpOZm YbAADf7kkkn9/fwDgBQ7JJ6SA/W3m7upsP0kkkgHMzM9gAAAA+kkmYfSSQAP T4779JJJAAAAA/SSSSAZJ9DMzAAH0kkyQAeknZJAAA5wAAAAAAAAAAAAAAAA AAAACSSSQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABbbb bQZJ9JCSTmklic7mE2DvHvXd39t/XMtkAJJJJB2ST7dTvL9732STn7kyQAAA +kkmSASSSSAAAAAAAAAAAAAAAAAAAAAAHPufPpN7mEigC2222r73vPffYEOc AA7+73pOgVGXn4d2bwAq9I223bb7sVG8s9b3qRu6yLQ7cycz19dktP5+kkk/ p/fwAAMzMzAAAAAAAAAAAAAAN/e97whJJJIAAAAH6SSSabOft125Wbk+6SUC /rbJI5+ZmewH33zA8AMzMzAAAAAABv7d3d0FnnXvMtgm3m3bbSXehJRV5t2+ bbbnkvT9rt7bJL221+t+kkiS/AA37vO9e97ve96afbb9bdtAB+dzPszGyRtu 2Vdw27iuX8CvD2Etewdnih57ywdJoft8Q/YdpnNVeRe+kXq54+QPekL6ZrSX FS22qeHTm+L70ndsSes57W6ZWAAAAAAAAADn37nwJmZmEAW283dT7Xc9nb+x dkk5smybCyRPZ13jCTYHJJJ7TskgH6TP2ZhISSSSBP0kkkAABtv1ttoDkkkm wAAA2ckkk9JOySPpJJkhbbbb3verbbbQC2222gAAAAHffNnPZJIAAA9JOySA cknc5hJ376H02SZIT9JJJAAAF39u7uoAAB7u7k8oy93m2227ZPsj777vj998 5aSSfV679u2RQAAAAAACSSSQJcd29zzyQAAAD9Lu7utgDskntzDl3fu+3ect oAAAAdiS8yYzcv6/vfzP7+n9/H82ckkkAAH7P2ZmY33vSc07cGiZ73sOfb97 v3oQAAAAAAAAHe96AAAAAAAAGjoAAAAAAAB3vegAA37vOjQ+z3vBFe+9vh70 2317962mSfpJJIoAAAAAAOcAAAAAAAAAADL99u7tX5bci9ttoAAAAPw73tsW j1QkGrkjCSZW222K2+bcuyR+ZbsTurzQqQqdlpJJKk2Tm3ekkuTd/buagAAA AO970AAAAAAAAABP33y22yQAfSST779kg5tknM0tspbazmZmAAAAAAACb8eY G2+tt5z1WgAfpJJJAAHve7u+97ue9v7Oe97oc3d9mfL3DnJ6SAA3d3d0AAP9 797zMIALPvvb336ZPMzLUz9nrHuoOXkhixu3fNUpJkxSW23q2G23bbbbbba3 t8d4CJTOUPAEjwM1DhncxPrP0uTd5vtufvd7oUKHJJu/jczs99yZiwAAAkkk kAAAAAABs5JPSQx7eEBdyStsSSSrtr0wSdI8bbbdbbbkskkkkts3aLa/5sOL 7482/vrbS3rckAAAAzMzOW3dzatoAAA7JJ6SAckknOTYFu/t3dSAAHpJ2SQA ACSSSfrJJJLbbft1Jkn0kkyQAD9JJJIGSfSSQAAB9JJMkAAAc4BbbbbQAPpJ JIW20AASySSJQ9JOySH0kkyQA7Z114+73s2cmyd73sgAMk+kkgABl3d3Whk/ 3veMX6dmXO/vdSYAAAAAAAAAEkkkgAAAAP0/ZmZhMk+kkifuHQAe/4/W31tv 9/AAAAAAJJJJAAAAAAA/SSSSASSSSAAAAGW3tttAA73vd/Dsznev2773mgAA B73nuBbQAAABeSSSbXJ+z939f9ufZbNtGW8kkjY9d+3d1Dl5ce6NUHeAQAAA yT6RJN3nNuz8nH76/t1JsiWfTuY7iPz7d3fJAGZm5gy2s3m7u6AAAAAAAANS SSaAByu/ATMzzOO/d6XsW3LaAAAAAAAAAAAAAAAAAAAAAAAAAAABJJJIAAAA ALbbbb9J3dzfFoAAAAAAMzMzAAAAAAAttttoBmZmYAAAAAAAAAAAAAAAAAAA ASSSSAAAAAAAAAAAAAAAAAAAASSSSAAAAAAAAAABLy222gA/LbbbaAAAAAAA AAAAAAAL+ttttAAAAAAAAH62+8zMAAAAAAAAAD+kkkn9/fwAAAAAAAAAAAAA EvLbbaAAAAAAAAPy2222gAAAAAAAAAAAAAAkkkkAAAAAAAAAAAAAAAAAAAAk kkkAAAAADd3d3Qs39mY1HpJ2SVbbacgajSdtd8klQkoc0t+pv8kV9v0+36Sf WNttu3p4jvcKWR2udhnUDt5I+6l0QN3XcnQISvfAm9MbvUm1vPcj2ALFvdJe Xvdznsti/b76e5Y1QAAADve9AAXj4AAA5I3nZ2DDaWVbRZJDJJbPSQdt9222 t393vegGz2HsNgAAAAAH6e3P2YRE/SSSQZJ9JJAAAAAB6Sdkne97AAAAOSSS bAABbbbbe970AAAAAAAAACSST4kmSALbbbaAAAAAAAC/rbbbQAAAAADu969c t9baett9baAAAW2220BmZmYAG2/W22gAP+AOW/1tsv8A5wC/6SSSFtv26kyF ttv0kk7tT0lW85bbQH0kkzpe7uskH7P2ZmYfp3M+yXfrJJQB6Sdkl/SSSSgB +5wet7PSTFoC283d+zLfbtUAAAAAAAP4AfwDN/c/Zb71y2gkkkkD+AH8AAAA AACSSSQAAAAAAAAfTu/ZvM9rb6SW0AAC2222hP2fszMJbznd3e6mWfSSSgAA AAAASSSSAAAAAAAAAPu223lqSbKAAACT16++8ICe3uSbn22Ptk/dbvd3bQAB 72eZwbaAAAAAADve9AAAAAAAAAAAAAAAAAAAACSSSQAA/SSSSAv62220AAAA AAAAAAAA3d/v2Z/f39cc3d3T+AA5wAAAADvfv27uZuhzgAAAAAB439u7mAZJ N3SS0DMz7oZIvZJPSKAAAADR0AAAAZmZmAAAA7+73oAAAzMzMAAAAAABbbbd 3d3dtAAAT3veNBs5Ju7eGZ737Pe97wAAAAAAAAAHOAAAAAAAAAAAAAAAAAAA AAc4AAAAAAAAAA5b68tvZQB2ST0kALvl553CAAAAAAAAAAAAgAtAAAAAA9JO ySAAAAd73oAAAAAAAAADnAAAAAAAAAACSSSQAAAttW2+ttAAAHe96AAAABz7 nwT9I9n3s5lnUnv3f8/fXvt5icWndJ4KDnr9svLs1eze1PfY8MKEyjXkwuk6 Xu7KlnStw4My32RGbE2xWZz9Gbubf1/TnXnsBltl21bVWgAAHJJJN9fLcZb2 W2nLbbbL6SdkkAAAAEkkkgAAAAAADLbs/cnduZ6d7tYjnAz79Mvuc8nPp9kQ AAAAAAAAB3vegAAAAAAfpJJJB3jJ+7nfT/cns6WWfpJJIAAA73v1ttySgAtt ttoAAAAOcAAFttttBs5JJIAAAEkkkgAAttttpb/W22/x/DJPpJIc4AEDBBFV b82342hAi1lySTsUw9hKA5drbsoPZ3eN+3pyRdmTfkiUABn7MzL+tkklNnJJ OEkmwAADsknpMzMzIAAAAAW2220AE/STp9mYcA2SSSPP2dcyzn3c9Pvvb+TJ czCAHrbfW2gANt+tttAAH3pncN8309uDWyfMiPoPSImqy2+bb0YA3IABzgAA AAAPvsX3svG/vbkGqAAAd73oAAAAAAAAAHe96AAAAAAAAAD1tvrbQAAl5bbb QAAAAADq23LbQAAAAAAAAAAAAJeW220AAAAAAAAAAAH5bbbbTnBe46MRySST Yv5JJJvvp934NAAAAAAPbvs5gkrMe98JACXltttAAAAAAAAA7u7mW+zk39L9 Zu5mEW53t6w8aUAADm59fPmq57Lc+kepsskkl9JJJJLbbZ5e7wmPR9H3z5Ud v9+3++969n9H3q0b/X+/qD+AAACZmZhAAAAAAAAACSSSQAAAAL39v6363LQA 73vQT3veNAAAAH8AP5O96zvetnH0vcz5u6HbbWZ+44N0AfrbbjUkrbfNpA31 C7xmayaLCT4uSW222gAGZJ3skj774E++PAAE/TNzCfNi/ZIt20LbbbaA2TZJ LMhJvd3W0kugdvekkSbluyb3dxujPvpI21999V3dvdhz2Z2SFsr1ZS07uy/p JJHq79PSd3T0kAAAAAZPbzMNu7u7p9JJM/fZez7s9ZdGMNj12cc28pD3L03Z 3hkwt7mYG/P17bTpXAA3Wu23DqsKXsR86rmQUq2973oABmZmYBzgW5mY3Td3 d3R3vegAAAAAAL+ttttAAAH0kkyQAbu7u6e973rbbbPvrJJu7HeAR6Sd3dJO Zj0/e9IsAABzgAAAAAAAABPy8reS7uKbbfd3c65bbbaSUB5dkpq5O9kKAAAA ADnAAB2225bQAAAAAAAAAAAAAAAIEk3ZIAAAAAAAAAABlt7bbQAAAAB1bblt vOCXltttAAAD9bbbbQAAd73oAAAAAAAl5bbbQZmZmAAAAAAAAABmZ905wyQA D6SSyT+7j3c/v7+/rbbf4AADJPpJIAP0kkkgAADJPszCSAttttoADZySSQFt tttDk790wAA2ckkkAAAAAZb13rAB+kkkkGzkmfsJJHZJPSQAZmZmLbbbaBbb bbQAAAAHOAAAAAAAAAAAFttttW2220AAAttttoCSTmYSbAD1tvrbySSS/kk5 zOe87e66vYXd2/uZ+zpOckSc97xmgAAAAAACSSSTZxJJM33veXRP9JJJt5JJ JQACfpJJIAtzLaW9b+b++2T3y5KP7W2/d3d2GfN1Td3fZX6SZlSSAAAE73s+ +N377ct2+ttAAAAfp9rd9vk5ZJJsAAAAAB+kkkkAAAHpJ2fsJJIAFJJJxttt 5bJCQhvQ1zEj3dK0knGoAAAn6SST9f2fu/rZ+vpjN2bOSWSUfW9d67byz0kS hZeW23urMQSV0kgnyM7tlsTSqkwmlgAO207mfZmbu7u6e973gAD7d3fbvM3n RmAPvvg/TvemAAAAAAkkkkzPu8ZbJctoMzMzBb9Jzd8kTl3d77PhbTve9AAA AAASfsyYSYtSSSSAAfgAAAZJ9JJO5n2ZgLbbbabu7u689J6ekgAD6223bQAA AAAAAbOSSSAfe4DUAAAdnd3c3gtEh3YlGz4NzGyujD7ee6mqJuzmd7kmCtnJ JO5n3jMybADltsxs699lgjlkttttvDBvs9275WezaL6VpLxBZJ63Uye7LgRB vcuB0w1d4iJS+I0qeME6EYeC0oVFd4qY1Shw81gFBuYiTSpPM+HesBU6aINJ J6K8m+2cz35v2939WySAPvvgAS8tv7dKnoetT1sDFtFS1xtluyXd2ttttgAA AAAAAAAAAAAA/d3308d+Nfpk5+9z6LdBv3xzj9bHegD3uc+/AkMzMzGzkkkg AAAAAZJ9JJC+97zAABkn0kkAAAAHbbe97252Rbn0ifpki2gBbatt9bfy2220 SSSSAAAE/SSSQABySSTYH0kkyQttttoOSSSbAAT9JJzCTZu7u5IAAAAAA/W2 23lW22Vbb18GIAAAAAAAAAX9b2224AAD9bbbbQAA7dvJ6SLTnAZmZmAAAAAA AAABd3d3UO970An6SSSAOySekgAB9JJMkfve97wB93negAttttoT9JJJBkn3 cz49h2QctttgABy222ygAADZySSRJJJIGzkkkgAW237dSZIe973gdt+/ZmN0 A5JJJsAAAAAAD+Ekn93d/v65bQAAAAAAAHe96AAAAFttti22xmZjdGZmZgAA AAGZmZf3e95bJubQzMzMAAAGffD5oIAAAAAAAB++wPEAAAAAAfTN/b7dKsk3 d7d3tklAADvAIAAAADve9A9+zmZmAAAAAAAGZmZgPuAX73vvGsk+n6SSfpJJ IAAAAAAA5wAAAAAAAAAAkkkkAAAAAAAAAAAAAAAAAHraBlt/szMx/f39/AAA AAAAAAAAAAAAAfpu5j9TO+/fY7svLJCT9u9JPRaAW2220Br3f2bzu+z/e973 igL3vXgK4tpb2E0JK2233Wvdt49IsGpVxJIq0AAAAAAAABJJJIAAAAAAACXk 5frba77OfZmAAAtkfsmySSSLyRpK7BaZLbcbek28oPIRsszBoG2l+VKpSgkC xwkq2o05nTnEW22gAFttttAAAAAAAAAaOgAAAAAAABrf9u7uFBP0kt/t3pzc y2bH8AABs5JJIAAATd3d0oAAMk+kk28ns5lSYXttq2973ttt2ckkmn1ttoW2 220AAA798BQAAAP0mfszCQAAEkkkj9JJJIZJ9JJ9ZPu5lZIDkkkmwW2220AA AAAAAAH1ttu2gAAAAAAAAEkkkgAAAABABaAAAAAAAAAAA5bbbZQA7bbcvYtu W0P7Fvbbf6/wfrbbbaHOAAC/rbbbQAAAAAHOAAAAAttttpy222ygA5wAAAAA AAAB+kklzMl5UkgB2ST0kMk++zMMkH0kkyQkkkkAAAAAJJ38Zo7JICSTmYSx 9u7pbQABABabbcQ0efNtt06d3Lb3bLGzyjtoActqTZ6SABs5JJIDMzMzu7vd 3Q/SS8zmPbuBv7d3d0AA7mfbmH4zMzNB3vegBP0kkkLnH6/p+z3769t+i6tq 8tttoA5wAAAAAAAAft3d3dAAAbu7bmZltAAAAAAADMzMwAAM7+d3bPXvPTMi Se97xoOfuV3A81QDO96EAAAE2fc+kk73vYAAAAAAAAAB/Mk+kn9P7+AAAAAA AAZmZmAAS8skkW0AAAAAkkkkAAAAAAAH8AP4B33Pe8B1nvdCUAAAAO223LaD ttty2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/gB/AAAAAADjZ+39m3P0o5I FdceNXZqBL3x9LrMTJ0bIqTNTzhxi9SkeOEw8c7Y/59n13PICxW/W20AAAEk kkgAAAAAAAAAAAAAAAAAAAT99++97vTQfbu77jcz2TNAJ53jwj9JJJIAAADM zMwAAAAtt5N/am/mpJAn6Sc5n7CSQFtt39qSSAAAAAO970AAAAAGzkkkyz6S SUGZmeO7u9km3kkklADkz3H3n7CJp9bfW0wAAAGW3tuzi220AAEkkkgAAAAA AAABzgOySekgAAAAAAAO970AB9bbbtoMtsvLatoAeknZD9mZhIHJJJNgDsne 89w3SgAEkkkgAAAAAAAABzgAAAAAbOSSTbySST/j+AZmZmP4AAOc3d+94ZIA /STu3erbScbu7kfJPyve6hQAAAAAO8AgAAAADzmZmYAAL3M+yZfrEjP9ibuw 1zX3fjAAAAAAAAAB+kkkkH0kkyR/AD+AAALbb6STA23aEkAiSeSsoAFr8222 ve96EB+u/vfh6/7vu/ntTbe+3fkkgAAAADJ77d3SrecoHLbbbKAAAAAAH6SQ zHM+Ge971tgP333wT9Jv4393d14md3e/ub7dAttttoAAAAAAJJJJAAAfffAA BPe94Fv5mTMPLaZmZmAlz636+tpAfr99zd3fYgH733vfefvv3AHy3eW920AA 3d3d0AAAAAdzJO7yfd9ef9v37/AQJJD/oIBAn+IQCBJIMAAAJD/mEAgSSH94 AAASH4nx/L7+f6f23Xn9jTZ0pLUO/xOpxcjv+PtVyavYte73YcHPJNyXhYRq M5N8jwJy7yJyQ+FxrM0R8Egl5LmrcXG+m7Z3aigfzW3N8bzc7O6zi3v7v3fv pfJ9u7oH33wc4AABJJISSSBu7u+zmX3nd9czMzMzEX9bb+tWSTkkUOvg22S/ fW0Bu7u7oAAAFdn3fpn329zFbAAsHZ3CZ7uLkRlqbdk5LUiXh3pvNJ+1zREv YL//2dl1evu36nLgfEZ8kcWkkpJWW2gAW+tvd3c283IgPdISQAS7CTdSSp85 JJO7u6ektA9tjaTb3flS85J9vecx6d72N/UEg7x+DePkmRzG3UvKabimDNNy RNuznEkvvu+++03eBAfVVV3d2YAGbl6pdacVEF923aXJduiopJL1sjyaABJm N2RI7W/EA93ZtQ5JAASS221JJ93c/gBJ9777760Dd3d3QN3d3dAAA+++GZmZ gAADd3d3QN3d5zm/X9j72e5+A19Xd3eraSW+2hpJJEkktJJI93cAA562W7tp s1IrFXmaYlyVSSSXd3dcy+hJJrSSSTtiRKWEklkklWW0n24SepJ7rbYgBBKr zbbiWYiQF3IDggZKokkk7bakklu0Mk9xAAtSVtJNSSSaSSXd3SV5u6jc4pA2 y3sSsotsnicupLu7uW7t9tttqkknAGbG9e7RDdHBe7u7urgu3MyneQ25nsP3 OIAABzgc4t+d6eZkh7pEuElangJJLW7nInoAAlUkuvBs93LTm6rH0PmJ1pNt ixkk/nIBekoAtlUbbO1rIJ0UQ3V1BBBsjbbltqSSStttSSSzFbUkksxSTupL aSTtkiXLOWoR2SSSW293dYtQkEnACOybsAA4AdMz0lzCnmJJRtLGfZ7hzChb Dc3aCe5de6ptu21skRDAO5HM9eq9X3unB3iZwAjkskgkikr62ySb7djYE7ok kkrbdwaBbndw64BotQetsvzbbTxu1Hu91tdSSSXd3KzY3LbzbBLduVJL1tSS l7uKzu5W2SEkkyS2ySSSSy31SRb3IO5+pMjSSSiXWtIoLM4REkkzXuk6SbJJ bl3LaST3uPuH5bQA3d3d0ADd3d3775W1tttxpHFqSa6+7mzQpk8fce4eQL5e 7zhoEjZLfuu51tzK6AArJJPSSPwDP2ZmbmZmaAABs5O847Of2J7vf2B/A/0k njdEk5yQvtvJ2NxJJIkkyTzbbmi27u22JJJxvA+Y2kmRWPUOhtUkkAbd5PK1 j1+4HucyHru2U062t3yCSmcPfsZGdT44XFm31J3sl7M0Q5jzqwljYWG7QYwV hYVs/B4eyQpqYkEUbLJytUV8d12pHoNl9rRy29yfhgtfFWxTxzVsl9nM9MeE QezxnSnGF3abVm57CWPAQOTgpKvZ5w6omF7bL3TGd0hW3dVY4htuBJSAszMm ZmTMzJmZlWADLzJYFUy8a4pCQ5xd9vJDd8pflsMzb73KQuKOQcLycNqUk4bT babbTACNmqqiK1JO0l2LP2knuw97K5nhlfkJcOO88Z7smkk9h0knsOkk9h0k nsOkk9h0knsJ97wwk+JJJ8SST4+t/blU9lzpcRvPGu7JtVVKqqq6qqqZAAAA AMAAAqqqkc9lUqnsQ72KzjMt6A22025mZcNy4kI5JAKk3Z4XVZvll16X3a67 8KSIGwAABAw2Nok9Oi1Wb1VM877tdvThSgBeTG15S215a05a8oacteUNOWuJ xQicUEIOvHSa1XvlKvzv21drwhAhAhAIBXISSSSSQCPXdoXlnuVdk8BmXrbb bbbfJJAAl5AAl5AAl5AAl5AAl5AAl6DW7y01ecyr5xwbt42223aABeQALyAB eQALyADyABeQALMrb3Ni8OxM4gmrewTQqszRDmClck9IWE7taHu9FsZhnO39 TXYW47cHHKdiIe9FXfPHZvd7oNl9rRyT1Gxw48VT52sv8c2bbddjDPpnVD2e N6imbDwKrW7zHkI5ADktW+0bvHuFpKC8PW7c4qjKJCwAAAAAA22235NtojyQ D95Nt+8m215dNF6K8ntlZa3nHPurGkj0eAaF5ehJbM1VAcSdJJ4kk93cSTxJ 0kk9xJKQGwjzcvsbvOccC7r3YqqqoSAdVK8qqnVSvKSTxz3u7gSSSThJJBJO 7vdDq2IeT24csntDo7shtjbBAyG2NsAYSAJgOWxbSsau57Jq8nuUBsdetsPe QpkqtSl1VJUNtt2AFCmnbi09PO83H2taAOSru6kuwNe7ppPvr6re/vXgFFNl osVRSgWj1gIcuV3T5537D5+73WG6RjYq7JbS06qr8BTe9ucpx6m37nfr9ohb SFtJpDMpC2kAFwLAAC/V12msw81bv3jG24AcAQ02m0/LiQjuzzkzw+l+zMqU PO3Zc0w5mhx5wCwnFAjQi8xrQa9BnJ2b+nG5KW47rzfZ0qqi7TDPHDJ3XsG7 L7Ql5Sevk4sYr4+1Wzp45Mu3czpZ3pgVfez1vRVTN0ANLqhsxTvQGSAcdlrH CVdGyU7TW6e2osebovNPwhptNptNtsANzrjW6uzvRe8e2js6pIBnOKSAVznF xyNgCBu+967TW6uzWu9O7p1pvjbAAAA6klJIuLiknc66TW5q7r3rnn33o7m+ ABve972RFyXd1dgGta3vYAAF73vW4AADe960AABrWtaAAA1rWtAAFa1rJUzM yVMzN6lTTnPX2FzWvlCdz3Xc6zl5AAvIAF5AAm2Jtttttttttl5s2slcLXy2 UbT7cUdQ2223aABeQAeWpKIXlELyiF5RCgpDe973sGBvVIW7yTRBSCkFIVRx JBHO+eLBbSyauirxvsfW2226QC4DbbedoeqxbWTq6Vpe+65qQHMG220A2IOc A5xG1vtdtGHo7k9c33bvzIW2QbZBakG0hbbaLalLS67953oosPLCvXN3t6sQ IAYxo6RxjGAP3OcXIKAjtTnjbfp5rXJvYehnrbBa/Z3kD2Kh5caehjw9gOJ9 vFSUfqUclLcd3MzSOljh9NvT3bvRllnsjV6R5X5X28PMR4TTx1Rh+5oQT23j N70zrR7PG9aX4IdpvVeG5G53gOkgByWr25D1XT92Dxx5Xp7XkV7k3vb1Z7iX COMYA0yRAIBAAIBPvjsp676ej7J68977f3i2y2xtBTwNSktigosQyd+u9Jk+ 7je985z772+gAAenPMhMFtoq6uzd2siIiIiMUz5bhDhNrbTrXN873vxQWFgK IVIKQUjPhSHeVxMw+4ZvXd873v3xBSCJBEgiQRHypNwM99XSZnfjN/b9z7vv dDrFWKUFG/n2XMz3LZvPt8++99PUFII8Qm221SQKREczWQUi91S6283fb5tK qyLIKQWQUIoKOzz7VMuHeKqVbebvt82m+PqEANME2UgcYxomVPhURCHmBkVP FE06sqYbzcg6u12JZHGDRXhBSoW06nZv6c1c2ktyXcTPXVJyGTodb3qr+6b+ ke90xvynu1yZFpsB1+23n4nVJujLtVB9c40Z40m0ewvIXtbkMztKT3fP0lp+ 203JoUdyhUiX3V9vX2uPd37nvvQhCEIQIQ+zcpEVHnr9RjvN93et8bb6x8YI LgcHxA31LZulrYqrGthj7ee97feTGANnEgFwG221ntO1acVGv0L6O993e9ba DcO9fd5wcHye59vXG5zve+7ogpBSClQkiqAAAJAAAHL+99ly/vrn3O811nde 9770mgAAbaTboAAAAGDbZwG2222AAWttstVVbbbbbbVaNFVSUSCMRQ+99r25 hfJ7msPt53O/e8TYQRDiTS5e97tqI1rcL6O8972+4uLcvaUPNd1z2h3z2d77 xJ4iJBEgiQ2W/c9ow1nk7l2/b57vfd8QUgpBSCkFIKRNribXE3yPvixXrrL7 m0ZK9Vjk3vcZ5VvguWQhZ52uTyKouq7Y5v6cbkpLcl3BiY66mOnKKPYt6q/u nDxk3T0yT0zA3PPBWO03BZOzzt1rjnqtMgzyJLl7sCZ0rry1ePPfASSAH2bL V7cAJGjmd7Yvid3zNr3931++9tPvABd2AABd2AABd2QQAF3YAAOXl5i7u7u7 u7u7sBl2AAJaVLzM0fb1M1r5PNua597v3vpUKqqAAAlSQJUoJ2+7puFvk+5d 3Xvc9fCiiz5FFUUJaVJ1Lu6CQIQhCl3YFVXlttRcaiJijJCXV94wt8nryZkz vvbqXFykk2lzia3TZEei7pbKvue+96QmMgsgsgsh5+9hW+T7t03W/T3d2Pib bbXNtndKpCo215sq9v2LaXFiVCVCtwAEQAARESAAABKtKhKhK++ex69JvrWp 26yPdxdOJN3bemrakNpeTlFF+78eqq8JbSFtIW0m0MywMXMzFACEITMzKAAj M981991dDg6ryhcKu93Fo6XAFxA2nEkgTbbbZhLvtKphe1tk2FTfOncnfdZt aXPPl7LSl7EXr3psdtH6lHJSW5KMTFwsQvuxLZVR+7PQKQaThxv0/NOemehs 46ngpLOJZps3NGcb3emdaM8YTaA95Nar7ry1HOY8BZIAfZstXtm71Lfbgk+7 Lac17Rc1u96zvu19LuSrsAg3ZtX1+TcN2/KrmNXKrfdW5G24DYucSLAOZy/X La3ntzmazjea9970+5gBHEkuMbbTUz2oLubXZkwLy83fRO02222229SAXEAu LDdysVsvua+q/THfduRyVCqIRK7r3vN93e1+5uZ7J1vm3BIdzv32+bu27+4c NdM285u8GRCQUIZ7fNKFLfYXH5eIBwo4vZ5qadelax7XPYsVyW7y3iOLnp6d Z0mFrvsVq5FjvLi048kkmbhTtdvRsSrnczZHdkU3uKNddnZwe0Z3ueHTNqyQ fpUclJbku4mbF49rA6cziPEdBbuJ1VUTuLV20uglYUum2YLEo8eOatzLeyod 64DBNGKLjQ8CZ1WGvH5xgPfSTR7Olq9s3mWyRxkIo4PIvZQfHz4PE3j8lmZm ZmZnjCofTz7mOXXhYg66zHizOrgC4gEgOcAXEAuIBJA22u3l1RDr9ir1+yIP OlmPFWYAAAAAAAAB2+99fY7RPZ7FF2S3fevqy8bbtSSc5G2pBcQC4gJUu7rE ABmZgAAGZmCqqu5rF8017vveyZmeZ3uXyr2EEKhILIKUFIKQUgpBSCkGVIZh 9vvOZnLz7vDevtauynOHDNsgpBZBQiyCyCyCyChojaB3V7rZzRr7Mcz3e6y7 zmc1OZvdVVVd9sCXdgAAXdgAAXdgAAVKgVIKSYApBSCkFIKQUgpBSCkFIKQU EHN261zVtzfPramSBXezipLyXmXGyWZOTtJpt3FXFppKEkktu71uzMektXNx V3M36CsulU45vAIeUpQzhzL9ujis2GyEGdtbAp8HFAqYDnpWslJjss2d0C66 pV6BdQ3PeAjhr5YETic/EbPF3wlmbG/Xx3cdu5vn19d7M88Bgm+USqvdgTJQ qPl5oCGTEvGWz2ije9NyJTbq/ZL2+W+V0+Xu9Pggfb7nc5Hnd7MnLjo33744 QBAA8kOzpetGetC07JKV5a3fLjbbTnsnsz7yX73Cv17mjvPuH3lyqqNuBHGh CNRRYmd5zXcznkvfHC9t63W+aHavkWaJGooos0EBLQNXV57OeS/d4XPr9l6m 983HyEIQoIQhy99y9dS87unO5czNG+bHr4tKQa2RqKLAy679d+S653lPU1mZ o3zadYpFFFhKxk2NVsLOtX06m63CEvKei8k6EXlqdkbky6UJLkoS2ZvYmqdz puMrOcDx6/GcdwCvhk8cCmrISSO7ewMzPUje9awc861lpMdlna4FdcFXoKW7 cz903RzWJdkn7t4avO+0x5qmWeukTri7jjB/PCoOY8o2aBgKJoiIGrzQEjzv YHZfbCAV27XFYGs8ei9t3n3ELvb+9FuPeMS/bL2/Zmvjmi6gsigIbmW8zM38 nd9+L2/Zmun2tkkxIKAzFteazXUzmy969QG2TkwvKneU62FRlqXrlvKixQlM IBDfPb1vyc13svPZeZrs5qJJ8SoTiHvbfjNa760ZsJXV3tJ7zjT4+c2++dzM 60e6juyV1d7SZziSXGqQkDe37vZM61Xd6pmybmrdtOm26AAAQNgAF4etzOdT O8vvfa1v097Ua1d3AEA9eq5zmGVGy7K1V4PdxGd6evXHmu9LW0Fdq8RviTyz zU9r8FiJJb0K73rj79t7iTy0bDsl7jkmo3PTc0CObymzOnu6t77W1DvPT+WF vl2+4ZIE8ppJJJtlt3do5wAFoJkkhJJIEkkmbq59b0GkiJJJHk2G35+crbbb stttFm7PvpIoN3d3dAAACy7qQAB7ra2ABYPAdMpKvEl81bJJyWpZ3P1Wq6kX 6Y6Il6tjtejsfarkF8PDhD5NJJ92dwaS5JS023gBTmW293T0GIHuk7iAASVK jSTFPMNtvu7ufnLQN9bSUlu6lZJI/KWXh3W31NtrdyT0ki9kbxp4ZS55zUml dbva+GGpV2DkSZ99ZfST0AA++bbbtaQD7m5JO3kura1i2pInUAqkkkvW22ey 6ABbdthh1VcGO9xJJ7uHj3cSAA3bbbUkmAH8AJfvZLZJPrakkkrbbUkkkAAB 998N3d3dAAAJJJK221JJgDFV98CnR8fmdR+4JYh5nifkAAq2+baSJMSSSJ8S T4bs9LY7u22ttLFXmUUoJKtttvu7ud9u76aSQa0kkvO3tAvHiUSSVbbSfxJN JJqW22tMk2tNJJSLMRIC7gApp2UpJJK221JJLd3ANCoAFrbdpJNSSSaRJC7n dyOnIsGm9acyO2ySSHY9y9JO7u5buz0ttskkncA4clvKINIF9zJ1ttuJLd1J 4NwBy3d12222222hzgc4He96Pe9JMzMzvZDbn73sz3t67Ym2QAE4kl14NklI 7Q+CthptpNO9VfIbWXrC0KKL27qABjarckW3o2/VUmJDdXTdOE9ZG23LbUkk lbbaSScw21JJLMUkzup5tVtzrJFW293W7JJJJLbe5EsKvugkIAj9fduqTmSe fdynpHdy25caSydEfZ6F7Ly4TylAA4BXGybE3ZI2Th9loQ48z25md7rfbIXs pwXezKc8qDwDcstmSSSRyRtvcdk7u7okkkrZLCTxud3BbpFutJcvHCSsRFqJ J8ZbKgkgl3d3SSSLLaG2CW7aklbUF5K3g2FysskJJJkltkkkklxDRcu4+7lN 3TI2kkoS5xB3uuZykJJJcNSSRkkkzJJSSTn4AAG7u7ugK4N3d3fvvtsSSVca RxakXi6zj7XMbsucuDDaygN+krA1xtJvpuT0hgAEkltvrbb60Pfve97MzMwA AA/cvrn97p+Ry/W231ySTjTYScyKSVSftjZJMSSSSdbbbsm7skqStuIju3uN tiOydam29SVrdZbhPcfcEJZSTu0WcN1eeP1LTOdyKWGHN46l5ziBw3LvLAKy LsHZJ5cc3koiQw/TcpjZzzrWWkx2WDXF11yr0VLsFGe7BDO8hJN80ca92rxx q+HWzBGZ6ILpVk7pXvK563VSDR7G3OvglvaOqER3F5oCTw9mque3CTs3vt/Z nNpnd37v2ta36e9ve9gACX29G7DebCcxdzuaFas1+X+ElD970C8o9vIM73Nd Uz7d57M0vx99rX74qbkhKkJEwUy0UUU+932dzvlM6cr77O771e7NeFhCE1VS 7hCEJ9c73Pd7p4l513vbdXK3Rcl5cV227rIhWVsad11crdF3lyQGMYx+hEko nfcLrG1tX5z292dzob7ovseZCXF/EgZmNAItu8uOZccwjEkkoyOQjkIxJJL7 q33cM62svX7PtMv3Yj1Ib2OQjuEchHIR1OJJJ1KchVGVUpyEYkklGR3e32e9 2/NrPWTnaGW120iuIbniWkkkRISyQkSSSJkG0veREhISEoJCSABtl3lbs3W7 EJ4XF9tdyxrtXFdQgAiAGm2CABAAgAQAIAEAFe971KbUba1qVHaQx5DrgEbf Zdy8DhKJ8KNlPl1WK2PP0rWSkx2WDXF1c1V+nVWbad/BoJY5wxT0wHZ275YZ l8OVmCsz9EF0q9Ea/UPM8VQOvezbBfUXOTS2RE9q8+AQjw+7cdi0jCd5vbOK 3PLnnpLV0aa3VyK6kEBLbBAAgAQAIAKXoqqopT6aqgmAHXve9mZtXihVt5U9 tlqVOaYBSSc0TC8vQ23LbElaVVVHn5KMmrrWpNgKCyKQ3ve97IKRA3vW0Xkw BeTAF5dlVjrTF26e19WbQoWZhroqqqqq6ISW+576533J05O/euX33sxPveqv Nt1ziQRcAQY40AgMXHIRb3vvTczcz3Pe52tWz1CzMXcBAIB8S4wKcggEBwIk kkpIICcSW7nt29zvE+Op97b7upzmzn3MuwCRzLkgGYqqtJBArCwtAWQ1m+e5 6++8d6p323nfb4js5qyCyL9CQtVVVFH2+d5dc976c8d+vd/d9nN8tk1AAAF+ 7v7nvd7PrO679n3vs53mezJsAKqFVCQ7bINshbSGju+b33vjh1597j7vt7+o 4qfTyXE2lzifCDEADYAAABNJmZHwDPYSsLsDBHjWUMAsR7KB2TeWR94Hr4E5 iEOH1tHul044S3JYNcXXZ1zzMKuy57cwbgxTvSbj1mGaTl8Od9MFZk0id7Yy +uZ6GgcPXbBaLnJo+UXbizGl3SGYfPTL3l7ZvckNVPT3Wye4dfvePu66cbea 92QktVaW0IS1DuvVmPqnd3uLr77V31e48yuLqanhjGMDe3t+Xdz1rrzfLvq3 NUydw0AAAAAYxjGMCuzFffO+5zPeXfV7GGUdA7hHJG223LhuXFpeQAJe8gAS 97wAJSoW3t2X691Zu+ou5HteAD3l4AF5AAuKqiiSkiAQCAAdUvd8Xmc73wu+ vqwzK6AAAAAAAB9znOcSkm51HtzMz2c1eYruLtGd5tttvy97zbaSSXkpmSSS 1aQhC2gAfiSCABmUAAoJJJKp91eRv3r5f3leevDOjWpJJJIAALaBJ9mYBAlq 2BC2wCW2QtpAktshIbPz8d+5+/Zw5+0a+/b3fK0A/BEhDMyQktWwLbCSS2wk ktoQQN99i6e++Jfx1V3PK+751xPnOJxLdL7Td7IB58ACPEdMAbmqu1EyXTaf CRXl7UMdHAH1dHul05KS3JZ2uCvNblfqyW9lz9o4b2Lsh9J+0cCsLyrON6YK z4ydy6VeEde8sz0zkgd9NiFr5zUFyvExMRg317Aoedtqcm6dO4HuNau3IPHd Nc8b2/gFBZD8EJaCUCMOjz7zpVWffK9z5ZWT72xEKHtmbPY6Rs6jORF3AyAy efi7MOfe9dzfen2b9Lt8r2EcVy2223Aje9cO986mud+Hv73P0fhUDYQJHn3c Pvfvrs3296fvc/HG/JPSSSP4fUhUgswIChJBQkBQgChAihAigQUAD32jv7n3 2c6n7vPHuXX4v2s1d+/JIBpIKQUhbQgoSRSCkLaQUgpBSCkFIxCVISFSFtIK RiKQUgpBSCSZVVVVtqsnbjV/dddd71feKr5TOx5iXOJ/HEgVPK2Qhat78bNN 3z9cx/fudp1z8X6vdqsiyDbINsgtSFakK1Abefc96b5+9+zmJz708zX6Zy9X O8LuwAENe80QZcudrgi4m+bGqZcN5m72ds11q7kyKwjigfHyGOmZ4N0XOpLc lmTLQ33lKvQku7Ln7cAxEZBh9JN4ouTcvhXMB5eW8JCJEofP0w1g757UrZPc Y7L6hvX0RtNlZkUoDttS8dgUXBe286eW39t6895ec+Ul5Vm55ALgNt/cSBtt s5ziD7fvtV57WXHuHfLzVfKS+1Z7E3sBtGqq6JIXuNtK3R9u/nzm/u/vZynl 91fNUhbOyG7AM5ySAVzZWFNttvWr1qwKgYzLAAAxmWZrezdE+6TXPoO7PmqP fXT4eAfY7XoA3QG5mZbahWoHxlzANprWshjBzMIZVp1fTNVy5Y/vkzKlTv1/ YvJgC8guqpeRRVUmVVNyNy2222221PfctPvui7z5enyJlB3c+kkkkkkkkkkk kkkkkkgIr9PCTDVj99O+9zGSn4AAAAAAAAANtvvJAAvIAF5AB5L7F25085vM i19p8pMO6/m26SSTTCqS8kqqqqkveqqqgAAAAAgBoA3A75Wvu+iDKvVj+UvC I2s5tsuqqqAqqqqqqVAUQBVVVVVANtzvEWuzsma+vd1z8oxxvH1eQA5JJJJJ JJJIBBebbKlOm2222laceVU6gUJK16IXlMfOfVfPCNrLi7ygdtEdcAjtX7XW sp2JNpsg+NlOIb0f59l25KS3JZhxxu7GbnoqW9l9n7Vvb26ch9J4YcbW3x62 YF7t0x4MkW92Z551o4j2RTY16KzoXlVIx5kYBbzvB2LzxhUjLj6XUXq+7e+c 3e7rzkYRtHQLyiF4UgpBQEEgpDWs06IKQUgpBQYa1dJDMuJDMvxDMzCGZmEM zMXk22vJtteU78fcrztmarcWP5O3GaWk5K5xJSQABjAAAAF7MvdPZmq/eetS +d+CpJAAoko79977k7r2/p7O8ve5fZX78B7f79796fta5O/utavj9+AiAD0r zvvp7Wvpz7rXt539f7f1SXYACqrIpBv3f3z3feePxnXWrz9+ZBQKQUgsakK1 IVqBW22221IVqZED3fe8+/c/c5s93KY7PfkhWpCtSsbOIG222+583uVvs1Sf RGfL6IBcQXKmZmSpmZn6IAANa1moiCDTaqqi4pJFJAm7n2V9er6e9dzp41NN woXrTyIqvvoWJ1HPtxu2sZsN7e32JNiucwhfPTx2dgG9ZB+5Tat2ktyP0cSx Pv1c5LZPbd7sayn1vtfXmTNAYvuLtwO317cnXmIvM9d32jerC3x2KLVck0Nd 5mLsJjIjab6MTTvc1ZCwJuw+e/dT7e+nefa1zdvu22222BWQUgpBSCkFk197 3fczd+zfjvPta5u/YCibIKQUgpDOffa3nb9m/jve6zWuZ9yTJFAUBSCkFEDy DJ7nvb+x+vd+l++1rOb8Hyn8c6kuNpZR7ZR6ezUZ2qyz7N58235ALiAXEAuI BcQC4pT3a+lbPqz5XnarLPvsXFkkQRA2IGDABh5Fbr25flufu71v63P37gQm ZmBAluZCGXFVVT7Z6L+Cfp37PlOa8JpeXe973vPXfPZNO5Pfrc54kj+7bbcL mVuSSZaDaAQtpJJG0AA99mv2s9refv34ee5mvtAACJAihAUJJH5SC0AC2kC2 whJv3fX6ZOXdg+5Z9vwCHkOuAN1yxYbxkwt7PQhlrHFgGmxj3K7Vu0luR5qZ E0onPU9NWx+1e33dkKMxw55dEWIQL7eL9tevy3dsPXnrJOZ6jeVC3xordgjm raTU5HRRrzLwBXh7U3f273vu4r6j6jev347z1XOckX8EltJIQtsCWMIskIRS R17Na/fs9r7P3j9rluc8QWQCE73cHbIdq4uZepd7y8rhe8oqSs3ukNtOnsFf FjeVJ3t6qzK9M9tVldAbb06uIBcKkFILI/Z3nN++c7t5687md+Q/Ir8XJFxb Ui4rJ7Pu575vfp4N+bb+DEkAuIBcQC4gFxAcSYJV8bd++rvy79MDvOigKB20 h25hDMzCGZmQLae3vW/uavVm7XQ9bb+EDYAAAhDTnqrNq9x799fg1feEaLQA Q0wQ02m2jr07meGITOmINa8Hz4Meg64BehGeolfJbfTQuuqrBeasHYnl2Pdp MdmXMTPVd5WM7J7egJwdTc9evh6GmncM8ON9tev8rPDaV3ZnqN6i7y33UV3H h1yUvKxyxZOWZvYBcUzvc4154PA++d+M51ZBce6PdxMYwfOcQxpJDAAMgBZ2 7PVeLvp3ZJmAAIGwBgwAA1cSy1W1mlfavvs2beXMypmImZ56vIAEkAIgCd0A Abr774yT330NGh/MAAAAAAAAAASSSSA5J9Xfs7lPdlMNPZJIpIBJJJJJJJJJ JJJNMy/G9t6LL09hJAkhJCRQjBsGAVpntv1PfROq2eAQNgADBsGAVpm7fqe+ iarTwDbbbYQe+3z3L39ven3saToEQD8fZvvu3j3s0u08ABAZPr56a1+729di wJgMei4jAIoRlHVclt9d18n5x4ORok/PzuxbtJbkxh300G65F6UcltvmN8ic uO+Xon594GOHTfbxbFk87fDNLkjWZ6je80Fvi71motSO9I5I3u88yDfRiad7 mrIwL2I776/iL5kTMLo8vKI8qqDiADfuc07jfcnrm/dABAoo9Oa17Hu5+mr1 rj3QAAN56dp9ueoz3e9mettttNP4YxjGAV32d3ce6z3N5znPve2WlVaQAUIE ZXOn3tO5fr+i9dcrYAPXZ7vscy/XznrzWU99jdgAAAAACBhlP3rI796vJ6M0 /d6bVRERX4G0g2kHX3dvcu+zvWeu+ueVYuIPR0IGwY22222VVSmAAAAAAAAF VVUA22222223VNtttt7Dd7j2F7N6yqx+8q0AAAbbbbafkuPddZPeF+23NXtX ZVfGni5i+vYJwDYBxYU5yP7qKPb+vbcMR5cD7TtWmoy+5Qs5FOkdF9HbE7sR sKecUA+rmUoPHHc7riuds7Fis5geoE90aqJJzM/W0fffPx+AAAkkkhbbZLbW 220SNFPQ9SSibEkvGVJRKO20LZJPvvpFoZmZmAAALbVJm62z1pNrddgAEkHg OnbyGszSknLbbbQTpKeE70IaXrJRD6pPO3dfZJH6LBUZ6Q+LYCPcOey2WgAW 3d20+pJk9d07rvNIDUsV9Z17n3nEk33d3PzloG5bfRyMSAASW+ttrMmibJPS 2Wt9NkhkWOSKbA1Y3n5bi8StydV2aEWeZbedDg74fWz0toA+skbcSJAXcg75 uWQBGQTupJ7tIFqSSS9bbuW7u222RJIndvtJ1kk9wHj3EABW0G7uz3ven330 fltttGZmZgGZmZgAAD774bu7u6AABUkklbbakkwBhqdBvZdc4CWXMi71aSO6 wq222SSTEklvdvcgAJMy225ltkbbbs8+S1JReSSS7u7ru7PZakik0kkvO3h7 a+RSLSSTttqS/JJUlkmdO3W4X3dJJmInu5EgBHTJU0kklCSSSHve7u5mJ3ve xJIZmYkkkiSSQAYd5OrzZw3DYjup2yNvrrrPaWVugBhwDXd3b3d3d3BgcnsV uTXV4koANteRnJbN3X3hnbzkuZZJLbba8DOA5xhfd70nv3vd3c972dkN9d+8 SVs3xPdwANiSGpLiyTSGVAOcmQk8erYk7pT3ed5at3nnFtuttnbZJFLEklw1 Ik6TS0knbbUkklbekSSFWYra0kkkAHaSSTjSSLtkiqSYAbskkkktoAEb1zuE kPd3S1ZZe7vcQe7TfWT13bbg2Scli58T7fElQm0ynnOV7uoEEQsgS5SOknPD O9JyTWPhNB5l6OvuFw4qgSeVttdkGSSSOSY3mN2AbG2k3ilkmd3DoSSSwAJd aSQzt7luoo2ttJeWu21tJJd3CSRtXatt3UOnPZzA3dXz0np6aW1u7uq222SS SSXwAFuY2TG9ShbSSSJPeTKrSVOY1LxwkmUkkmyRvMbdJJOfciSbIoN3d3dA GiSTd+++2EkkkkTmE88a68Gyc7hfaT7u9LL3cG2km/Q3b62gBdbbbb6ST0kk vdmcD3vZgAAC39PYzPcaXQDu7d2bIyqnj9E8bzG5MMtvettqSSSbbbdskk9B JMyQypdbUA93uVskgIElqstpDYnJXm33d3W4e83xtJiQ2scztq4jmXeLotGh GJ3ekVJVU11a3T8BlyCTtzatiuFotG+aAJs2+ygdW/M7m3Yt2ktyWOJYn3nZ xyT2+z2g6+82xMIAxuX3ajtb8rMCOh52Q6IQti7ejbrfRV3HG1PM+GbmQgV+ HtUc17e7Znmw92exi7V77WkuVzi5ys89zBwvCb1vl37sIc363unPs1r3c8Jn Ne+k0REgiQRIIkERDfXvtXXc3rnc980+1v3QNgQZSJo17vPPLlzN993d+prX u4qqrbiXFwG229zNl3LLU3fUYKu3vo/3OAORCiCgpFJ+CpBZD97H1zWX3PaP w4693z4gpDlpClpCyHDm7znufbz73NeHn2kOyQiQ1IAg+d857l1vXvZ8LzHb 8lNVmkZkA615C3Ln3siPve8kvTMRmTSEMe79u5ewaDyAg8Bkz6+yAZTxjqm+ 2+m3jl9kAtr8jued3lu0luR9lxxsUSKbM7JM9sQ49qZ8gxMI0duty/u1teFk ue7I6NutZu93aJtxbFgjNfpDY021fcQxkQFE93nz1zc132NLSednb127++3d qfpJ+uOQCRo2QtVV+DADMdXWgiIBEEABiABdat1DQACCAA4ZrDQACIAChIMN adYQ3+r9nLzeu/s/dd5O872Z7ZDMMuQ/QIwzDCEirICrAICqSQgiSQRVjAAe e393t5rXP2fvu3mprvfECRQUkhdkFskNfcu9vNZ72e67zfKd6eCQEjAihAkW SSQgiQhCMgyEEvdb183M+9njVnd/HgAdnw1ILAxqQUgpBT8BWQWQ+579nOLr M33Px+o/eUgpPyAgAwVCOEiksQqST1/Zn0TPTV2V9bqdjZSSTjEGE6E4nkzk Eue78t4ta4m+J6cSA6dmVXpdajuZUpX7We7z5XRFIKQUgpBSCgK7zNey8zvs 7zutRd79796thEAekr2tcfbj5jaAN7OCAI8A9dmC5ojuI4NvruqFZPZwFrfu 9mO7Fu0luR9dcbuyH02Z2SeB7BSbsPlPF0qhdq2WeOte2t+Oe7E93wImYMXa POBaWIzY+pqSN8j3UZOAr6ePudj32LQ7ZvW4NdDj7vZuloNp42AAMHzp6rp0 jxl+9d2yiuy+t2Nt8afRAcAaXGrph0vIREO+7WWuNIVUKqAAXl+W8evm+azV +1l+9nbAAAAAAAAGDPUAHi79T9ccrb1ryN1kOZnJurDYl8+zoa8zy8o9W1vQ A8j15Ve3JT2b2cribT41xPhXq3AA6i7yq3SOt7pzlJNauNritbUsAOr2d59v Ne5dPt+viCkFIKQUQq5r7Xfa727u7997X3fcc3jfuviIJdVFlQgYzsIOQuTl OoBHg+YAg6UcNGxUlDb6br5Z+nsDFrfmfHNux7tJkkfeutydGNQ7nYzlznio WivMh9FDEW+b5G9ue0L24VOhGYMnaHAiMgjaqDNVaT8NVGQd3VjM9pjm+yvq NUG9e7nAUykh3pvtQ1xNpJtvy8SKSRSSKSRSSKSB1nOAArETIVbK2uzz3h4A AAD8AB5DUhxBIoSKSKKREc3F6plSlc7nrnM+797u7+171dQmruEIQhCPuYXr utW833Wb933efXPvd+Yoooo9kIUqLTae9jZe1Qdvanvb28Jm6utNptNptNpt Np0IFzcpsv1UI7fqm7vbwmbq7XOCBEcYyc4ZRVLiKoqlUp1CNySOWuVKdFb2 2yvVQN3fam+3t4TNp630GycZprVSXrV61NgADett73JNDe8bvQAAGtY1egAI rWraviVNSdjaaSaknEo2bdtlXVAu32pq3mt3m/T33cCIACZmZFSMzJUvugXk 2wSBjbbbbbbbfa+mXWBM7WjM6SpdaRvNt+TbbbbbeLykAXohJtgvIGC8gAXk AC8t7qiLpuZ2tHVZ01cu92p3tSAG222222222225bcyxPOmNe6LWDzAQ9Oh2 ne6qXVBoHdWPRQe2+m6+vs9cDErfqfHINjgFSttfcpzc4idylFRsCjZ4XLLp Yo2AZVPnqcsW4NUx7Fiw893sHaGgtiO9Gqn1arbvhrYwTAKtfe5yNj3eFize 3dhA3Weyi7vpqrY9Izk237ybb95Nt+8m2/eTknOKSTiJIAB3nvKgMqQO77t1 k3t3kqezc82e45JwJFxEk5xkjgCCkuBIuLi90KH3KgXvql93t3krxmd1AA2I GwABA2Q9akzKgXul9zemCmezu+ebnvePPEcPDdzDaAXea0KNv3vPzGEjC6gj PdL6vZ3CZ5zLSQk2uJtcQn24i/ayl5367+7z7fHNdvN0gpBZZFASVXlC9Loe RBg5XO+2b3r2rorpZ70qIXl4fR10dd90vq9nbyDt85yCMH7BlZ55jULMG5j3 dz2jDkryanQCPJmrat7omdz22dW0t2+e6umBbCPUrx8MU12AVK2191D9Od2Q /seDF7Moc9jS89zhMJBpDvtpZ29r7zHA9NRmqYvaNMYWptaZCc2NQV3Y2MEw CyE+HPXIPZwtXu0bvsh3OVel+qZQ3D7MxUbXuFWaX6vi9zfuCqr+hIQtWwJL c12v71dd/OuHea/fVN79+kIFsi2AWiyUAZUKAAW0ACW0AC3rgAGXHAAP2+I7 rnq67+dc9vm/2XX75/AAZcckkI5lySAGXHAAMzK224ABmZkIGZjkJMsiSSS8 scX2jr3zrPvs7lQr7oAADCcB+u7lVUuy6uy5JJM1mgAAugJLdauKqqqqroC2 ySAa1mlVVVVV1JLbAkNazTqSS2yAWqqykTWrDJBGBBDvKfvVzv51w9vm/2Xe /3yhbWtfxJIOOYSSZmNblYEy4ytZgEiMJEQgMYOZZMAAfJtpJJeZZ90w6pYz efzrZa8m2/JNtmZlv0hC38FtgQlq8AAt3qAE/XnN69XP29Pdb/X97f34ACWr YBLVVfyHQAMvGAAAZe9XoOyrBcQC4gFxALiAXEAkmDu7l2AMAA+Xr62ft17N dvv77jPtkQEQjWta0ABP0Te95JjPVVVUmZu71TYQ39TYJt/Ts3rgyshn0/fW /tblt6lxJB9lcS5yqlSQAIAk1wca4vr6qo+75fb2PgEAe2dvcpTuaxEquG3z QBMzAxPbfcfE+7aHYBUrbRY/RukRR7ntOdiftys5+BaHnubM7hCQ+9sru4N1 vsDgB9njvhzIHh2s6dnYJOHa+hcrmxsYJgFD7M8FHIPZw6xjlxUBGdOmDptv MkFkFvrORri21bbVkgs+z2ZvGtrrlabu422lxMOcTWRS9KHVbeuXpvur9RZy EkdQ38+v3Mde3117ffGgAKhIoQKgAPkKBBQJAUABQADhs9vt3r3Nuvb940SS PpIJNAAerFYIrR5XFQdXZEREREREeVNOdzjb7Lg9vwZCRZAToKRKQkUADejt 93N79zbr2/elAAUABNAAIkkFAATeHb7uc3vTndd6GgAEwUgsChCKEtJJtPr3 pnN7053Xe0NQADHL9nnR9qBAIHIiHe6K3Fuza16ahl8+fdI/wur2bthZwvFj u9GBUrbQ7j9G6RCs9KtOT2UAsVjx3pO9yG6LjQGCe2WzcGt+HsY8MrO+4cE9 WiCTjjE6VdX2CiH3SBjiFN7i3GoGu2rGKp3U6VUQ7F72gAOoAAoAEHrul63p AXRlaVXduier3vd8Ag6kkgbbbb8uA328uW3avMusr1ezd91IG28QPgMfkm+J BSS1NBIgVIUCNScM9d72jw3zm9c17Xue9pV5AktoAFtAAawAFFWWSWvt90a8 b5zZrnd+3z3sFFFFVVFFPp7dw0eN95s1zXde572hRREQRkEYnvoEMyLPiNSk NHO62vjf3N9N/b7v333tTZC2UhbKQa7cA5AE1rUaSbaEklLaiFqxLo4qIpVk XXKsvq7M+NgKQUgsDjUgtIMCpBSCry7lfci1WXWqsra7MyvQo8oheWzW0ANt 75e94APLy8AUvKGwhZWrlirbrFWV1dmbpooApebe+8veTbPNuZmk22m3u6H3 cQdQ9dduydOCI0mAMBde7uhs6cgT6lu3sctLO15EtTyZJ3TwiMc52gVK213H 6JUhlZEt8/YoeywhA+zd8xmvbcjc8p7faOHfeuw83ap1vgRJXfRl9RZ11SVV BujB2AXGMwKad8J5HpeXvvB5ZWX5VfdzczLYxoDq4nHItXOKKqYPIRxjkckk knfd7odxuvu58s99f1Rxcy23L5AAvIAF7yAQLyGQC8pkGe820HkpCSl4V5v3 TOqy6ys++v6+MQLygZAvKAGLyAELygJBeUtyHly97yiqpVySSQyC0pkHMyjy Wm9v1zPVlPL+V92/r7ltAAMAGAAAAAr537695yXrm/Tffb+3nuAAF+qS5k53 3uW8Oa5vu/u79vf0hBsFA4RKwMCDUgpBSCkaSSPev3M9x4czmz7f3t+3v6Qj EgE6b+753eHMeb+3fa97nQga327+65nrUQGi3mb5JVi51XdM5iiDKg5cYve/ UvOeR7cx392e6BsBh8+MRPdYaNum+U45fKidJ4ZfCb1Sp3M7dGuwCpS22P0S uzjgCzy9kk7LSM33Zizz3NmGrO7BPabLt3hVKiuFBOGXfaR21RN0resBoatr jDe5OwC4n3uc1b4JCTilbq7+zt33s5rW/fb+lVUCAIgAFVVWE39me1b3F9ze vHvaIEPSAd+uXMhzLiPW3hPY3ScyHMuIzxlHTw/fe96ENdO/vvtW+xf3N/b/ H7NfggT6SJCSICSSEP3j2/31v7a95vm/37Nbz8AA2gAFv6QwJBQgyIADCRCL JGSMuUiwnC0kGxSUhJRCT3OXn2u39dq7P3Dmv37PxCEA/AwCIMFgMQgkkQBQ CIAJAUIkEIRAZJJ72d2/vc1avDZrX78fta+kIflAQSEi+XkvQvUphBzrvvll 5aiLVVEH2/A/l7yxMhIjJAYMkhO39789veC8N7XXfz+1r9IEMZAFkFAn4IDI BYyQi7oOG5un7Dfr2d8vcCefcUZs3AStdOd/ccxqjY57c3MZKft+bx+jX21d RiqLy0Tua6tHOrk8xTB0VChXuXfBM04l6mzPhRfOb2+75Pb6Js8/P6dQ2Skk kvW22798PwAAEkkkLbbaEkkmIkczbCST3d3WNtvypb1TySVdlttttt+++tAZ mZmAAAALu7ZITe61KOQACSDs7upp5sPnXkbbbdttBOkp4lvQglrLSXhr8Mu8 RCCiLDPWtLefcl3czLJaABbu7b609zmXZgr5pAalazXhL84klJ3d3T0toGiQ njQGG7TZKS7O7hsk9JZLZLnW20rHBGZnkrvE0jb3J5lFPbXxbAudDDZIZIL3 cLJC0xG213d3KVu+SoxG+nhO6kk1LuA6pJJL0tu5bu7bcyNkmWx9w2Y2SST7 t0gkABO222pJT3ven330j8ADMzMwDMzMwAAB998N3d3dAAAbu7u7bbaklJ3d iqn2hr33q78pC/noDacAHkPYu47upWtpLuZJi8STyJJAAkzLbaR7beZSStmY kkkgfHSTO7u68AL493dUkklbe7a+5JFpJJ221JdnkgqT3dJO3W4Wj4mwzMXJ VJEkANIeVtcSSSkttbbbcAESJJoADrbt7utbbbaSSQAekvq9TCUfJL0cdkkc dmdtt973vVmZmYAA973X4syZXd3vOouzb7P3GzzMva5xbaAFt5y2yZktoAFt ZJTOae9x1u2xJJcqSUqSQAA3ElOAbZA7dyOTi73PDUgY7dGGDuOYQxe8Pc+m XVu1XHCeWNE87aklw1LvcSaS8STttqSSSttt9yWk5httSSS3bb3Ek1ttG1tq JJgBuSSSY3ZAAv16OEgtn2HCSJbbb3d3d3ZhIGm5lj9axtuYZDpwgLPA8fIl 3cLVvd3TdN6VshalG46SdFJtK6R4k8D88zUDb5nvZnoT3d3FSWN68xtuqySS PdglA29W2y68skzu4dCSSYABKHJIWiSfTd1S1FYivYrbakkku7p2S2LXJJNz VX3vdttklevpPT0RbW6klbbbJJJJLISTbzGULySw2NtJJeTSSVj9LL5nnmcb SSSXO4BvlmE2knuOqNtJyW21JJJW23rZOtWknd02pJJJInML3IYpaJSaSAwl BqXrVfe92ybuyfrjH4d73fYp8PwPwXv3O/Pbu7u6AAAm/Xt9bbQH598Ddkkh bbzlXlsn6SOXd3d3Ukkhbbt/X4c4G7uYJJ713vd7gufdsktVlt3caPG1UAB2 ZuEbltrSF4QV6uCvKKp3QLKjMb5vjQA7Nmbt1tFbEaM7lK37kHJXTsRyQzx3 fSbmd3dcuryb60csjO+fsuTu0tDexb5bmzIcPdnbPCVZRsjJGirL47N1jgIp zdi3req3A1a3Xba8BwAzZ2Yi0F5D3QBIFGrPdxN4r3B3tbVE/JIPJAc5iSfJ BcQH0hbkEkkg6AH2L7Pl1/W3alKvvbV1czWZmT8QmgPzvdILcshmZhoQNZdM gpDRBrSJKvj378bP2+28N7XX78e1pq6kLV2ABauBCWiApBSH33uGr7vNWnOa XXfHtatIKQ0FpDVpEmpLfbxzY8U2vF24TZzY15vwAAMGNiAzyK9HUyu7Mx1N ObdbtNJJIYBiS5JGwAabWpno+zfXp3vXRWzm1WJL6Fmqfm7+x9OWnZ8/fBa8 sjtcUusWzlpvp9xtX5JejJ6nCrrNnLILrn7jPbC9ERmrG9rw76D3izyoDCEB 7obLAIAT6r3B6vLW3+fs1jrNm97sfa7AKlLbm1eY60MrIlvY/YmuyogLjm75 7mvIcAzt7F7pZlG2ZzPAHhPTFbu+Q4Cyc3LWD146jJXXJFg7AKn3g5Hvg2Dv GjBhca+u+843e/sr7Xu9WABBz1/bxOc+19d95xu9byvtZ3sAABy/exzfNE5r fbuzrntc522i0tYDaQWpCtEKwADym0ul5ngXc7ZfpzarM82IEAEzMzM3QAAA AE64rrIt5cRZVzXNcF310BtVVVVVVVQ3ICQCbbbbbfJIAEk0oheUQvKlTaKe Xkzl5U1zXEnZ9v1IKQUgpBJl1rRDWvazMy25mZg2/vMCXNJJJNsYIvL2Zyrq cq/q99ZG+YDADZI5HBg236bFZeYvB3O3swyvta9wAkkoAPOX77Xed5277vm/ uM873DNkQC4gFxAc4uK9313RnZ0OzML1E276NtpJvnFlx7ZePLor3ZMnpfqR MNe2d006afF43naGu/bjwMc8Y9fYxrsAqVtuWP0RviHE5oLYn7NnPLeGvz3N 892ZTiROYcnhKsQ2jrlzy4Tmdpz3Z2dHvtG9kTbsO9aOPgk7Z5Ns4OAtGZqi CfeM1Ay+PrVdfkA6OtT9+x+8uAJLiYm2JXXrqty/GK52u7V7mLvetsAIjMvI AIILy6XA5ywAAz1Za3t6LFc7XZrvcztU2AIGDBMTEDZfq9a3tu6z1d2r3M7V AMBtt6uAJIDnAFxALivb3Ffbd+tzNlbuTPELaS1VYsgsgsBW+97ZzXbvWdOZ 1VoRHohKPL3oVvdmlFmzVPSXp1NeWZuLJzL2TFgZFM2utr1pJRCSXopJe8KQ G773N6vN9999n3PZrPJYKQWAyY7nVAdXTePthm9HlHoULyhKPJdWZPctcvV2 gsAjBeNRJpr26Me91PofXwQa72yeHAdj3zHpuvddgFSttHtvpz8jSC976Y/R 8JnlvZEK8WDNeqZZe4uvVVdd3YJcLcgd950b7RsyutyHeteFa0bb5Ns4Pbtl 7MCsDH7rwO8XO6HrHR0oWGEFIKQUgpBSMPd79rX3ubzvuua77lkOe7ea197m 8+985rPbs8CkFIKQUgpBSCchKBrPd19rV77l96953aYBPR5LcdZVZs5Zu6ze i4XmkklHlq3Tare+5ned7revcs0ST9JJIsGRIiEYwJN819b+5+OXnLn778+A CQ/IAEiwIEUAA701+9+P15y5++/OP79AJIiAiEPFEgpSQQSSCgDKkESFAApY WQIwokEShIfd48/c1vX7ma/b/cv4/EEZCQEYERkIIhCROhKQlEIjJEZIJma+ vdfv29cb+5+fEP0BI1ziafOLia7f1wfTt/Sdjm17Hl3dfYeJm+0Qefdk9zUM B9VB3AzEPXGNdgFSttG2F3NI4N7XOWQZ+0P0sndvsT89wC40Nz8PCeErzCBR atTEhG33hbvtnDcqYbNjoW2LYabPJtnB2AR1HcfcUPd27+9r7nvbuuXPa72+ J+kRgIgSKEIwOn2v3v2r3bc/a/Pp4ABNPloWq0Na5d/e1fPM55939CSWq0AG tkIWJIRkGACkCKRQgc5vX3tXW/ZrXn4hvmZz7663c+1zskjMAUlhBCpBSkQB ribXE2uZUztLsuE92+rjTvuHek7XaDMuisZlWkl65x3cFYzKtJKl5e977caX klILnEvZLyvQt5K9fvNttt2AMYAZm7zcf3DldYoDGC8aiT0Wyc8APnScvjL1 p9uP2CDpkHrjGuwCpW2jb6N5IqhandBbEWftENoGqaH3nuacoOe73eU8JXmE CiHCguzZ+Oc3vt7huVsNyXe2jtJbXjqSuA4BL4amxy7xmpsyXerWZXbUzMzM zM62AAAADbbbbWXrMvZqJratw25ltt0AAA3Mtw2224bV6O1Tx3HNm5jEMG2y QBsAA6juJOaST7u7iveJJJ9+1eemeeoXNarYoAQBlAVVVVUAVVVVVVWkkk7u 7uAKoAKlzN8wvZ6Jy77LOAqqqiqq167tJL35JJIkkkkkkkkkkknd0k+K/ZX0 vxWkleyXtXdXdAAAkkku84pJOJ8T5znFJIkklJAANyCzapxZp5l0/AAc4ABx cAAAum68s97zieC6zLpRggj0qS7DW3ed1PXzOdvM5rAjQLu7uy9707zWp37u d9eM7etAqVIVJILCQFCE+EiyFtIKQUngUBQUFLbIpBAqQWQJjCBFiXE2kklG 8nbo2sllGz3c3Lva7hsyD0+fLJ7legh8PY/YKOmfkDlyQg2gJK20aL6PZxqh biWvs/aHgNe4LoferGBRtXURT/Ha3lez8uodfGpq8V29Stwo1uc+SFdl3tr7 xDbQr/LzLkeFYB13AFdsU3b3fPeev1dftCuy/dMb5ziXAG0lzUKQUgoMJAuN kklRBQFUVggICy5cEQBAAQQQVJIRAQREBERARERBEEEERABQiAiCJdrsEQEA iIAoUgpBYDW21q22221VVVRQAAIAAAQAFVVVkK1IKIFpY1FwkAtNfcvx7m83 x763V0vGIiingLY5Sqxuo/eVure7sfizot4lwFQDQwEMYCAGgIuc5yEZxelt 7Kd3vh76WdIznExnOIMCcQQIECBAUCBAhHIGpJJVJQWPdmHsru3DxYdmQ3iS VFURyEchHIRyEchHIQIFcSqSgri4udyns66x9z3qIWdkwIEBQjkJB5cxtnAJ JrM1boCAKAAa1rVtbXJBKOSBORyQKSSSL97rrHne+p5JhfaqASSBFHJARIOR RwcJBwkHGm3Lbbbqls1czUXeOJkm3Q2223wAJIAEu8lCVVVC8gASUANtxMS6 SSXlbl3486EzHfUkkRyqSSSiqqRJENptqGxJJJgNttt5cEOrucjIqZyhyTEk kpVUiSkkkpIAGriAXEDFxZub797nMPsUIkgvbt3txhGruPVbFvZD58snLqZ0 Xrj/YADM8gcuSb1oBLttGu44zTCnEtLOfhzHWej25q9TezllPcvtCOS+M37y PL4Q5s8JBnn+Tz2QDc+MFcl3tuPvHkvF1+XmXFCsA7Ke9yuog17PZ1+bnt++ 5rjy357A6AA3GkGtDAAigAwzCkGtINaYALABJ0DJrMAAAvJmAAAXjMAAAvGY AAB3bbvO793TV7uX17YAEQuZcnZIyZlIbBzLhBSCkFIKQUgwzDnEBwAAG68P tZfr9bswR1vq5wG1xttsXADoB2JqUZWZnVKsVywAAAAAIkklJJziXJIA868m ZnXlXjI9c0tskLbbX61JIVqAVq8kC2kSxW7cmZl9Lt4LKbbfTUoSLikkSUkn EpJOSRg/Lr9Ru3vfedU2q9QwAAABnYBJCSSESSSdnu2L1+z3XVNr23XaHAFI osBSCgOnWqQxzKA4bbbaXl50BrbbcNuZmceE6ZeZBdSl+5fru7AAF7y+6v2+ 891rROe54/c4Jc4ns3LOmF1nbnXBnry6r3r20bJNwW+iRO1O8wjcnsAFVzz5 Yck3rQCXbaNHrH6caWUwTq7P2iH1e5cT9fQYDiGYD98vS+K+C8Qvh99s8JNs GXJbvt7huJMN2Xe24+PJF1+RxpxorAJRmFMmCm5M29gs8Xe57rqm17PNrjXV xNcs7Xd7+53f1u9qd+MRX6QjSgAJ5oAHqO61devb6Xba3uvnkkn1vwAWkq4l VAvJtte5KEqdbUq3t9kCPbeRbXlLhtQuOYQuZhMzPgLVsgFqrz2s9s5zvNvq LV63ctgBJJ7klV1JJKpXrKktLi821EzE5T2LtbSyszMkO6YoMU6xthZve972 Q3d73shrZve9kNfb3zvAVVVVuqqqiIiIiEo9Ee95RVVQvIAEyjhbV3uRARvO pNq2222222298Aal4A1LyqqqSRyRlzaXb7m9dDr2jnrQMfhlSQQNgycXuc46 lRcVy62ll9zeulW6O+7zEhmXEhmXGB5YOtazUQOhBZvebQMMuZmZmZmQk+JJ M1SARrvfn6n2/ZvXSrdHH1AIE02227SAXEBu5c9zk13wr8cedubVKiTarq9m zz7uyFTkKfP26tvKZ+YOXLd60Al22j1j9G6WU9BOo5+0TvX0eXHPWjAcC7MR Xz92Tx+3729vyv2bPCIl+xfDod9t4eLrcd3tuLjy5Za/y8y4oVgF3MKunfC7 LSaCIfIpV5yw2/h7N3d3dAbr9SlSGDuCXy5prTKKYozMfPvJaZ3HtKqpajtv p73ml4FCTRCFOd931Pt63u5tv3fvX08AkV58+8d1retujXu/Z7PSaRgQRgRF oCVpBK0giQRIfcefevtHd63vMX7fr4SCJBEgjA8RSFLSCkFIKQUgpBSCkFIK QtpBUCpBSHqp972juvb1vNZa/cvs6TSKPWgo0JS2BS846703lze1ftczuumk UUQ7IQZzn2u6N5m9iv3OdyhwFIMO8ASH1Sod9mRTpVqmKioJG99VC7cZvRl8 Drxfo6bpxHAiDSZrT3g65mGbe7tfgOfjmqndKfnwzOgODdSDsaDe32bDFZ9+ zK+mszMzPyUfffD8AAA2227ZJJJba223Nkb9yJri5cNXIySSSYC3f27v6R+t AB3vegDd3d3QAAAHGbz3b68y2SyQACSC53cTVceAJcXzbttoJ0lB6klEkn6X Amh5I5tpzbvTzrWwnqn5tvyA8HzaXkkm7RfW93d1u7tsJ7m/TfQNhq93Nt+d 08qk0jHrcAAc9LaAB6JJJbu1230kFCm5ITqEcttuRuZJHKscEXu50UXNwCkI e+fw4D7fqrXq/j4TiK973vLOySJEnve96Vbd1JFusWpJdulZ1qSSSt20btu7 tvq/NkmC7ieJEkk9ukEgAO222kkrvd3Ld3TnAAbu7u6Bu7u7oAADve9G7u7u gAAN3d3dBUkoNGNWfQT08/pxI6q99JZu+0eOLSTizdV++tskJNSSXiT3Ikrs 7uFmZ9Z6buwVKd0lt1m6QEEklV4kk93d19u7fAnSTUkksUo922vm0i0kk7ba kvJJUnu6ScAHkaJhsPokoSSSAG2yXLIkkkpLakkktzuHdaABaW9t7uqSSSSS SAF4YdPDClkTJG7HXXJIz52CQACTczdj82klGL3h09Wbwnjdrlq1Z9u85u8f jdyamzvX7vrT8AC5lttzLbQALUThPLj3u0hW0k91C7srZ40ACMkigJEkk7u7 7ZLeUT7qT6RzPSRclRgHq0RnjeJ3kjCnqGDm5Woo5EdmpdFEknbbUkklJJDU ksxW1tttvd8LaSiTW242w2427IABJbbbbJNeATSyxQ33cya23AO9p3hxmZJa cC2zMGyGUt6MOe6ysnT41MAWAG9SaklG46Td63y5PJhbfkV3p4CFrE2OO7K+ 7u5yWxhtvnZckyST0cvd3u6Vt82rZJhJPFkkEvNwC0NuQyNtHEpaSkvYrbOp JIAFtkDbSUSVrvuett3dtZn7297vtFtbu7ugBbbbbvd7e2jx10q+WG1Ukkon uTWjfX1ktJJJYGxslYlbnEjjsMtvWS222kkk222222EE6bu6rUkkmkm2N1yS NynwtJpi7oPN5hPrZO7g20mr5/6Te97PW2hzj8H4D373vezMzMAAAX9bLZOL zV+558/ebQD8gGuZCUklJJLu7ZMyRvzrZJiVSSStjb8q3u67Ikk23LbRMS0I 22TfQ97hJa7bbow6Oy2wAWGHNy21pdzEVq/WBXREIhWrbrKi6ouXc3Mdp1WS VW9fPjFA+WhHG9JG1Wm6pc1abqMuTebNtsjvolS2shOhbu/sCIqv6UXwyjED kOHl8F6Y57H8PvfBfczbfCz1uuTdPD1gN27jzUt8S3PIV+3F4Mu73HNnUZie nuqKtK9WuZkV3dGpvt+NhG2kiHORgzMwABWZeKJWZdTAVmXUmGZmQmZHJz3r fa1N7x8fav7N7AiIacnfsveaPu809XurvNDAROyMqQUiFe6+7O75q9Xu79mi cgIZb3vU7rHna93e71s5ATcFCAKEg7AkQ+7u/Pd6fn693fs3LB2EIzRJIzvb ruHdY8fr06B3vzT895c52x6hvRS31wV5Nz1Xbf0RPpA2h7u8345nc5T1T3Lr LCGkgn33rzHLrEnde5Qy1xMNygrzSV2+bSxlDTzPCSeRzWs8x2LI960Au2wT nfQOxpbHNEzP2Byq+z2Wi+EGDsL7O+P45PM0fTMffb3zhfI+fTDL4zet0YcT 3ldyvNb3xLcQr/LzLsZWaMvszFWeHXZevU9325xnec+n3bzDAAAAAAAABAAA CAAAEAAAIAAi7l8zAAAL7vn3Ptzv3u89PuXrWpq4AAC7sKhW8vFSZrWStANa 1rQAEQZrWtGYXdnPcn3fp728+mN/czM0PtiWlWCWlqCSoVVVlSCkH7MIUd37 ufYcu87O7uuapMABYMPtffT69++Tu7z7W9Aboq4QUkihBx7vv0+vJz7W+ZWQ n8IpBSCkFIKQUBBIKQUgpBRk6Pe81F8X2w672U7te95b6Xmurgir2YW2T8P1 FJbVkPvjPe1w19nPT2tZIDoJx53u8frd8+neagGkd2ttJD8SBD91XsP37dXm yOffE/YJifTCYPtxkwomm5QqSRfRI56ljT3MPn5HT2eQ6b6PepAKksEd9G6Y 1k7NWZ+wHNTrvZuU6L7oMBwrsh/l+vp9q870+PwnP3M+HlfLE3ujZhTBU9uW a3oONnYjiJUbW319R7cTmrwTJ32l40V3qMK1terUsXGv3GjnOLmLT3i/azfp 7fckm0gpBSCyAznPnujPneb5O8376EEP2ZId3nde3R5rynu98HZCKPbERERl Rz7MbiuyF2fbvzbY17y8Q222223wEgh+95gmNptNkEb9K+29kF91r7PvdX1S qVVIpG5FCQckkS5xAAgELnOc59W0vusm/Avp37F8CN4klIoCGMBAIBAIBHhf fZ0q/tBfTPsX2rgZhklckJaoKqr4ltMhry/vZvfbnP35O3z9+AD6VdhUkd1v n7799dux++T7vsAAWQBD8AA9kKKQUgpBSCkFIKISzwQHnj233ffvvnPtdPOE a98qZyhpZ293TSb3ieWmp9r7iLPJEEZ7RnmdFoBslgEvmFbGsnZqzPQ6lZ19 0Lqk5HOHUFp/kC1Y/n8s+OPs3nBw8lt9g2Qha7u8h26nA5MsYx660eqM1BKp lZsu4U9PtF2WnxWeazTsYp3M7nv5IAM/QOoCmAAMlWa9z7uXl5+bq/uJ3roO rogW0IeAAzFV33urr32Y29vm3PQAPgtskLVVRqlIAWrXvxr3va9u5Xzq55R0 ABQKwlUARHsnJrudzWX6/ba9CSSQB6xNNtjO1pXt3auDU7PNtycSJBJJIKS5 CWAxkkkh5173vdvINRE8EkhJJJJJHJJIRyOCCr9Fnb6pTnnS+3AIJJJRySSH OJc5HJJJJJJI5CRti1rNK0qGR3dY22225bbmJibSSSklJcUkAAb0vfW9q4Ot fraATEIBDxkG5BBIpIpJaSS9lfrvN3X3y7+mnfPfuEUZV5rL2oadq8Ty1Rbi AeqRnWsI7PRaLADbbFPZfRKltQne5bn7OT4125uFau72wYDnFLkBvI7j8egs fWwmayu6nJi9PTdHD0zocqgz2cJZVMxk1EzBJlGJw+evsIl8lMS4hVxrVnJ1 T9Gz9JAAJxcXOSSLnOckgCPoBOSSUfYdn3xl2yYmAscTzmW22/vLyQFUknVU AABXOJSScXOPN6vd283Pp12MtX36gPkkkpIAAAAAABOcSXJ9a9v33vskxhRE V76gPlziW7dySUkklpd2FS0uVUohISMk1JJd+1GX3tfZiIghd4BFJCSEk+Xy 4uVV3aSptLicKoXkAC8hjXk5bXlddK7Mz4+uyIcEkhznPcIIkFIKQUiG973o ua05mZcy25mZhmYZmZCGZc/BJORAihAFDyXtI4Xbu4VUufpe1SzLhtx70TyS SSh1UUkikkjkI5BEig9Ji9eVK3ViqxkuudsAbQ0+yKSRuQQSKSKRyuEZ3vej Yq1sl1J3Z2qkeHlZsCltEy2OZGQwZEDZEwyRsCJiYE5cVMZQqu3fve9ypgKq 93IOCkkjHIEI2ClJJJOpxg2P5JQjiSMzb869DN9VdxuV0sOrqsQ6Y0oeQzd7 IvNIovhO3MjUPRpj9FqtAKksttHq2S2shOjlufs5e43LM3NhrKPjMGaFgLS3 dS9PcIK5wkiU3+flmTJJujh75aas+er7TzdC6u5kJi55smUZlYh9j5gRULpy xY0cp3o2+Q6MnNKQ+tyltzCDmYpBW0g2qcAYxjGNFOZzC8sruTKtd9VRCu2M aADGACdti22VK22WwJL85htcJHVLi6xvt3nUV7KrOvKCXOWiLiInmEMxcwhm LmELg5hBuK4QauXCGVTMnpFIKQUgoDNaKQtl/hJxviSaSncXZm2it72u3han xlLFFxMYvS4xRYsVQWy0+uz669u69373d/F3ibz4RVgxcaW+IZmLbaW3Ru5r 73azc96sQylVY42IEHySkkSXOORsQJjD0tZVvpPXmVnOlc7aDEEIJptptGHK bzenPuc4V1wftDrbIKQWQfrIVkFkF+6EDMzAkuZ25iBmfPdfd5ddzFLXTorv GljbabUI4mmkoSJSQAA5wBcS4LjYxgEqll97hXcxS+nSO7wCkuc5JdfcSUqq JJJJZxWlx8qXLZC5rNIGApBSGtXNNIKQUgpBm4AshQKkFIabvdwgpBSCkFJI pBSCkO99rbdp6/buc07+uqfXOhEjWQafD4QV+nmqqJz3NjUiOhJk+j3wtAKk s2OzlfFtZCdHBXP3BtJ3s3JRvlBg7OK8Vi/s5rJ5mj7zfDrPm/TX5L2Vbooz It4zcrCpHN1Cu5kJflDsu5kTYXh14RSh6Mb6neSXgfTQx46sXEMa4M/c5JL4 lJAK5xSQD5JJKSAX6m/TcsrMre2PorMAAAxckiBgAAAK87WFZ3vVWKjorMAA SQCtcbIKQUgpBSCkFJJmZgAZmeJ8l5ATM6k235Jtv3rFtl1Je5iLROSqM6uK SRcUki80lVVFySAAAAAdi6ezIVnu9VYqOivYBvOLnOSQBpJcGNJIYAAAwxiy d0c3cxViddav0ALUrUhWpCtSFZBYCrPQlN8+8ObuZr68FZQr2gYMNXOckjCS RgAwy6Vd32FblZyhdOiPYM1JKSTnOccjYBOJEjACEkSylR3fRFbmcl6dEXrA AQwAAAAberiiSxqju+hW5yZ5+vznuBAltkIWqqqqm9ve61+yYukc175aIauo YMvcM1Lq/ckXrj0aBA0/DthePjno9FoBUlmr1YMNOTu0cfe3pmrDXTm5K97P MgRaSzh/s1H2X0Pw+/N9931rezb2vVckW6OGZXvGbdx6qwvEOoV3MhLbi0Zc zInp9oxNwEHvXO79l19zkz5++zx/IAJKWEbFE+Ob+93Lr3OTPuDfqBRSCkF6 RSCkFIKQUgoCGjg879l7vZw6n1KvSCkFIKQUgpBQZUgpBRiRSCkFId4PO/Ze 72cN/WfXEwgpBQEmlkkmbG/cy/b2fGz6z6geIeAqBI8vH1M3sNu9V9OdOUlz nH822wABgwAzGz2Q9d+V9OTsp+dAcBsXAEgOIBcQC4jsCQy+p370KpXS6cwX fYmlTRwhbSOl5983ne5dax3eUOU+dHFJM5qqvfxCW0hJPsxVX74+9zV9vZTX rOXHXe+hblvZJKhI5QLaQrAUgpBQ4CgkkYiqj+O+8x3VauaPyQGnfZRDVxEM q3vHamkXrj3P2wYCvbknkP0OuwAqyyCvTaqt9SdHRj2ew2FNZumojCb58nME sgs6a/JtfK65/K/jL3Pe8cMWDuzPhz27iYt3EbGRXMpLV6eL5ERps3L6aju3 njwXG1LIailMKtb3kkidVV/kIW0C1Nmjvu6utY+Kl37Tr6F5IBbtVGBzey/b +utY7KDN8e0hbSFtIW0hbSFtJaqujhz7WrrWPxfmhzGMYrBmGzfNautY8KIb 4Mngkihyry843Pt6utY7qG/jN4vhtINpC2kLaQtKQtpLVHn23MwfgT5fY5dN t/Jc4wS4l0kkkJIBI5JJO523MHJOpppdy8nSSSSSSetttu6re9gAAb3vWgAA Na1rQAAF61rW5V2AAGtb1oAADWta0AABN37nms1qNlR7ZzN2sXkAC8gYLyAB eQALyNZrRDWs1oLrWra3MwANJBSCkFOUEaDYbCj2asnNxeRIC8gAXkACSAN8 vLwAJADbce83LhuXCDEfOYvfcTw7NOzfPV0UfEMyraOKJ5tF64wNEaf6A4+/ SbLQCpLISR6+Ydprfb7It0cmPZ7C8xqxQ4HsdI8PcDx0rX/Bfr6T4P3wSfe8 zhWDK1g7sz5cXt3Gbx6OoVy8Drbt0HKMys6dF2SVYMncB3PPR7tWc9/EkkgB tttttttuwAYB5yAdfnsuSqxtN5q6dAA5wDiQCQANsgtZKrt4/ZrM1r5Gc+Pv lXwSFtCFqqq9AAtOud1ma0dRnen3yrJQABtx3NZmtM7kT5709wAbbbbb7054 qSq6BzvY+9i4AuIBcQBC2kLaQtoFpCCreHLk+3bvRuffTvQAAJw77NM16T0n vTvfpKqWCXEDbbbsuRSKRQEd6cPXCVbT5nl2LoIBHUuckUiXEpFAAAAGhjrX Lu13YAwnXOXmmuZFd7L73dYIams1hC2kLaQtpC2lqurZFIM37vsO+DHDfpUc MeLgQ3s/TxXs9s9XzLuat01YhXmi4T6xYV4fs1ezF4ixJXZ1gwiY6zXvjgu+ xo+xzzW71CSmmNTdmTPLAR1AHi/XaMrvd3T0ttu7tt9bbQAEkkkLbbaEkklt k3c6l5u7tzMz02bu7sC22fpJJJaHTg93vQBu7u7oAAACv0fZvWjrXJJAAJIP ADrb5834ju5tO22olbq9uMnucSSby3L5K4uNwQl8IyzOj4k2pesb8vTYJCkk k7bb3d3W5ls73dzczKFnWdGu7gvLk7qVJ0ebeQtkACT0toB7oEklu7XbZILO x92vWnZZPJpJKxzYkSqLX5otAog1jozaG05sxiD+++++OZ9Jd+Askkkrbbnd 3SqSKpdiQtSSzElKkkkrbXgG27un1tMaSV8rmEkkk9wB7iAA5bbaSSve97fv vtOcABu7u7oG7u7ugAW20973Ru7u7sW22h0Dd3UlbbaklJ3crPfQffYQpiMx c7H97vPu42RJTRgDdkkkiSSSSSSJJJQAEmZbbQALG2krXaAA23zZ8SSb3d3X 2ZfZa0ikWklidvePe7ryJLaSSdttSXkkqT3dJM4aHkaPGKxeSShJJIAbciU6 yJJJKS2pJJYvdw7rQALW3b3dUkkkkkkAKM33Ndehchxu1tNcVdDYAD9Zu0SR tqsTu6elt7gKd220pZs5+n330k+777Pu98pXve/eEfgLb625lttzLbQALV3c EiOz2kK2+RWEn1fd0BrCW7qSJIoCROd3bu7tlqhshpq8rdGSTG23IyCJYfN7 3bXgM6STfdkLl2yT3vekm7uwG7u7ugbqSWYrEkkrmMW1JAmpIltwRJN1zANl VtktsjoGg6tQ3dVtbc4DhgIA6TMttOKTMJxqrybXLD1AXUaRlezut7l3QlJJ Nt2kmdPUBNei32J09vlJ6b9O737s9IPwAHlt9by2s973rqSRkbZJJLJ7ieDO 8JQm3zaSRxanCST7LbZKSSAAbZMfY2iol5SW1JdG7ozOczMC1u7u6AAD9z8M GCrgHmc2mSSfInrkObPS1eazrWSSSX7u7uj82W9btJPiTu7bZJJFJttJJJtt sbbZiSW7qkSSS80klu6o2lX3pwlViOdzL8msxetk7ubZLfrZmWzve3wBzgPw Hs5mZmZmZgAAC/t7r97+5/f0/b/fz+/gP1d7bfeyJIy2vvvgZ98fn5obu7uz 7d3faWyTzbu7JIko231kgwkVG3G65xwjpa7bbp7d2k7aQBXV45z4W9Yl3d3P T54uRW328UMpHthKiHb3atevjcr48nPVbnCHDybReuPc30ak8j3Hz5ejFhBV lk6tK2bFnoDo62d7PYpkeOQZu71OTQ2QFVk/TNrVW8/lzncz4v2RvROLpmbm i5lHJCDHbzRoiFcuktu3Rd9U9b7ed7ns5vWjb9u3NP1Gd+vNWTxFIKQUhbjh B7SFQEDWrIW2QtsC22221ILIW7p937Lm3ljO/WToKQUgpBSCJBSCSB/AFAke nz31uednHx7qkbbb6AgEAMaYJhovLr9u3NPKM70v2kbRtLb0cy/BHMuBCQjT D3GQQFKn4CBTtiF70fa7V1E2xke9AAR7yiQCFENjEACABAAgAQAGJxkzJMkV EqVeKxmCADwAIAYA0ACbbTbabbmG5MTjJmaCnjELOrDtRSEcJESRSSIJFCRS SKSRSSLuOPoFBVghZ1YidnJJB4uXpBM1rNEE1l1ongUgpBSCkM3reG9kFIKQ UgpBSCkFIKDrN7ujYKAQu97zQQI5rWaAc1rH1dgPR4CFmrp2ooSKSRSSKSRS SRyCCROSSTuPsDAqwFnY8ldkkkkkjbbbbbbbbbbltyul/BhLyR7cK1kWdeyC aVLOUsJF8WBZ5I+mv0e5sb7z329sPn3bkXWEFWWTr5pWyLPQnRy3PQXE9lys 4mTnyaLdQF7Ffk2oxbXz+VcPbJ8eP6wtexN9vQ+Q6bdxF0oyVCOXSW3c2b6F afaJrs00EibmcWB2D21rmAAwbbbbbb73qIFFXQhd7nW/ySSLV2FtIW0hbYHB zLhDMsOkFIKQUgpBSGZmAwL4w9rWY5zC09fuUhbSFtIW0tVVVfvn7etGLi/W lNffVVVVXxC2kLbPxFIKQUgpBSCgOZSHve9vNOl0+aU3fdx6Qa3bAplC1/AA 1oANYqijzvk9msx/bzfracv7udCSW0LVVVEekC251O/bzTrXbSm7ne6XwELa BLVoQltCW9hIQtTh7Xl7rmYPrqmr7slyiVCVCVCpPF3YIAHO5zV7pc1d49e5 g9TvZIKAMykBhcpQQCA4AAYpXWyvS0+2mn73YIBAIBAIBAcAQCAVdrLLn70/ POrXukLTvyU+fHi/R5Q7i7uHoEddW5ri1+yd59mSKzeVlbqsbNk8s9Sde8Xr 3xBIlduVL2umC9orlWQcYF3b1Yis58rw6KS239MY4yexegvEdNu4lKeWGnap 3VKZvZR22N69GBFadmBrcXce9yurc3XXaMakI1IRqQnklxCqimpCOOQUQ3J7 yShNyQm5aopxDpGgRey5jTdHnl7yhuWQl5SEskJCQkJQAAS1EJBwkaSSQiEl pKi6b7Sr1Un30wfs0favM3JhdXWahwUdGbu81uCxSCkULx51Ui8hSEsXlCkk YvNSSPfJJqSR6k1JI59Dc7FhMDRYReu5jWLC5achE5CJyETkInIRNyRcS5E3 JInCQThJ4A5dqvVSzxiH6Uu0ZDzKoihuREhLUQwBQOSEl4gJISXkQEk+hJKP JBIT73gkIrKFXpVa7RMqVevSs2QBtggY222222JJJAAkklshve96JJrWtagf wikM4i7NX7mqCX1eOLvOXlELyiEo8qqqbbhty2+SSSAG222xJJJAFJeXgASm aFkzIigQbIPZ666u1VVySRobTSgRNc8kkkxIjWrybsCQDWr1NWAAhCNavWpa EIQRGtXrMzMzM9bud2S5Xbtypj+e+e+mJckgHUkkpIAAwwZIySSA361KqVt3 KOvX3d9Ka5zkhED4BSCkFIKQUgpGa1dZmZmYAANAugAAAAAW+aVzulzfSmgT XqXJ5Rxk9l3hL6ndYPntuLWln7bMfdm5J1m8rK2DGFbIs/UnXxkEzfHX2Zsd t9EPZfIqAKC6tdURiZnPlvFVynd7u70xjsx+kWC8bxm3cbdOomrbAKS8303I In7R7Rg49dU8vJaeN5Dt9MVjEA0By8SSSAG222225bc42BITtz2N9mc+3tzW HXh7O/a7c1da1l2CApBSCgzMzCGZmQ1GHwE3vetAQYGtawhmZnke97yjyYaJ MB1rmk8ZddclNdGLuztbbEmALyYAvIAPKVELyiF5RCShAw9vl71VVNti8vLw 35L0zJBMRlYVd3KOa83Td8AAAB5JJKSANiABTafsq8uXTutmulu74AABtttt ttbtF97m+b2y9vnzJ93gVUAFFVCSGuLp7XO9l5duF9OC2PczOtptt+S4uBcl LgjWryCIIIjMzCIAgMzMACCDMzAAAMzMAMl3d2BeZgFVmXKl3dWqNodu/cvC 7zfN7Xft5117a84qqvYQAaWpLsqqCuy9u3KnXr6tpvuribXE2oPaqpbBSO45 IsDsJLYY5mrft5v29r8+fvXVdzi9AAtX4wCCgRmY2JIBcQC4u56/anx573dY /ZML3ve+e9Kxdsgb3WN0CyeXWoyrQ+TmLjKOyS5K2Z5pWlrPd1fFMXN8dfZP B6LbmGaL7jnAgNJ+ftDosyb3cW71pv6ZObeP2x4BVo7LcRlKJdQrlJbdzR06 Ddy7lj645WUX66CitqnPReftpiM7nEgbAA1du+v67+5m+b3nrrzs+0c72Sqk toQm8xJFbLVVVud163u83ze8fk9qX37ZroE2QEX31/XevZvm9zqfZfePuGux AG6kSeuOd+czW+b2dT53Pk/b4AQCAQHAFznF9xNSCA4gEAkklvfoOXtVeYWP 7RD+jedWgjUIkAwzKW0tpbApaQpaSkUgRiUXFNo2553eZbVHX169pvVflxCB cQgIUtIUtIUtIUtIUtIUtnwwwhjJIBj72svdZvm9uX5+fPfbXxxFFFFFFFFg CyEn4kIikFIKB157eXus3+3t/Xz1x/fbvr4+YALCAoo7KWkLaQtsLJfiF9mE OdnOZ7mXes39vbl7932L3u9kMzMn4igLFikFkhANeTbfn7yj3obsXkSAkjyX lCgAXkAC8hgLyuiqpeU+rK2vjCM+CIeTQezak8MZRS9Ms18brOgTumyr2Mr3 C+G4sZ6veUlb476ebdqOendq5rGLm+qcI1ZHdyiDYl8nUQPLozKX5GLTefy1 scl9zX3sxjtx+mWvAOy4Ox1GUolnSnVXu6yeU82/V0aOk3La9eTLg7MTJF12 /Rujb1JFVQSSSd5Irbi4AuIBAuQFxALiAXEAuJtcW1hvblVpkjDX7dPaX3iC kLaQbSFtIW0hbQLRO+PXO+cdb9rNd79zH2l9OAxIAkIgSP89JFRFVVQp8Htb P37jmjV3+1fZ15+0+2QWdABkrCkkYVIKQWT4UgsikKkkgzgGZ3er7ms1d+1r Ne319j34gpBSCkFIKTUkCoEgipBl+73O57V1d/azH2vn2NgTiTcAUBlSCkFO VRdT6/avO+LnLvurntdee0/GgUgpBSCkFIKQ5R5z7RrPeM1q7+1fZ19jvn4J bQhLYEiqSR+rM+XkoiIiF6UkvRusCfvpK+YwyM76NvEkgbb+S4qkA4kkgGDB gvXU6ffGVefWC988d3iSSSZIkklJEHUnJVLimaysBuYQczCGZmELcydVWGu+ 0au+U8/JHz8zwO3ak8r4l+l08vbacmz9NsXs88urHmH19ox5Dze8pEgOXPzN qpfurnHYHviJ2Cc9tuZ7lmig5nEap/Y3J8PlkRPJ/B/JD3L9VuibM65Ki6US xlXVyktTJnnnY9zOWjc68Thb2Zo5ojqV7rVZrkhJCSMGDAByQkkvpUNlk7TO 7bT4jIu22/zy8Da9LBtuZsPiSSRrikI1xSEa+v7uULpMv7CvtvX2n573pJMX JUAAYAMGDC/b3TOlX6dlbua89b14wGPJJGMhHIRkI5AhGhkde3T090u9mTte fY17bYyDhGwj9MuOELmGEMzDCFzDJOCig3TgUXs9vXniUvQ2dfu091tt+BAI BAIrzabXk2m15Npv3eiIXubirli168OiD7T3x3QGYZaUtPQIWqqqtAAvO/cv d+XqfZzPvt+5ftvuAAAd96/XvbLXu53fW9jM8uIBcQC4mC4gFxMFxAJA2n33 i9XbyhPfe9vbfpk6kuAJEGMAGj+gDRPwqp+9p+9nXXOa5vn1/NkTe2aTN+ZW G+d3Ry6PV+exL2WpPsV9oyYTze8pEuT8beZs9FbxVEWjy25hksV32d/Zo+Cz vb8BPvKud8OGJnxpUoEtnpwgz8lwFy4tRnYlaW0tCXR9ElqeXHnqo8xLhnJd yO85dX6Ry2LL3CiqqPgAC0aABbobYfwiCAtcXlPt7nSubn3fu3ptdk+ST4lI LiAXEAuIBcQCBttvV766K8979Xp97HsKb5kJ4UgpBSCxRSCiElQE+RUzfGY6 5t572v0pcW+Id3HMel57X7UJqS6lU2AHr7nfuOT7nO999v7G+AKqqq115y+z bl97vnu9c9SW0IkCVgKx0EClR0SlpClpC1pDuZdXXtGZ77vnu9cPYQpaQtaA lRRRRRR9PazXHHuy893XuPe76e9ApUaUJerlS1VkEAoACpKnjWvs11875993 3z3mveJiKKahaUC0pC0pECFxAhcWd9EZrJ0RuSWdPZWa9lXfVs86kA4ixq53 eUZNTb1WExlHZJe7dtovE+43ehHY2bpkq3pEQszu5xKgewOo8O3X4bzU2+eV mqJ7D0j9pzl+fbs9kykwYi401izkuj6AErnlyZ6irM165d1VPvveqvPO+0s3 Vb6ouIELjG222mmk2/ucXBCv5xSP75125Nd599pht2+p69hmOQHBzJDDMyQw zMkMMzCGGZk978AB7w9nsAAAEpLIh1K269sS6CgAax3cAFANAGgAAAADQBvO ho0PK7dknN59fLy94kBLySADySQBaQAeAIbamXESLzc+846bYNXO7zngxxtU dtDQgTa0EAgEAgkUhHM8bKqWHfbKm3fY/Xcp7sg8SScciSXJIxjQwRxttPFy vZrmVS6Hu7RtV2P13VRIBcQC4gFxMFxMFwNAERSRziJs3aN2oGynNqtjz1+u 3UIx8b4002ly9sjZ6sOPTznm6cXtC8lumtu8oXTvTfAx04v37x8s8QtHlX46 teodp2pPK+JfptAG0YQMw7PS5mefHUXfCYc3Gus3lYkByfn1ptWe6sdIHviJ 2CO1325yzRR4DgJ42NgRZYSZLOatan7Vrvs9wkwlwoljEuthuakw5kWu7M23 MZ3ATz5m+dd+17cuvcz2d7nTNeOgRQgRQ3RW2mmXnfa7qqT9Zedvdnrq7ukA uIBLAFIKQUgpBSCkzMIW0hbSFtAtVcO9e899t1ev3O693NGa6HQFIEqEmAAu 71d3Kl3cq7AAy7AAAu7AB9d3a7L99efc3vubz2t619v7Xtdmt+vgAAF3YAAF 3Y+uwARl2REEQRayICIC7uIgiJL+ucQC4gFxALBe9N97M9boes9N77VK9eSX dypd31vuS7AN7zADUuy5dhrWYAABmZgAAGZmAAAZmYAGpV3dS7upd3d3JrWt AARWZcqdvNb5ft+5fNGrne53I+73CFpSDqkLaQtpC2lsItoJIBcWry213tOh +v2zSJEqTnEBzWlVVVXMwxRJJmWEltkxUzLIUFxALiAXEAuI9fvZ3FvZmPob NNSNu5J4MzMAAAzMwAAVczMVVSZlIW0hbZPwzMsiqrawAAFrAAAX375k+/fc 47dy/3Pryr9dgAALcywAAMZlgAAXl4AFVVWuW22sArWQK1IVqQ92z2a+5NZu 7+1k+z6+Xu+JMABjMsAADGZYAAGRmWAABhmYAABkzMAAAzMwAArGJUtaVLWl T1SsxUeLza9ptDhp2nvRP0zPT2L3dMyzajnYPcEEcP9VP2/fLtinWDHH74Pd 9MgwFsBt+Zz3eK2egXQYPAHPVreeXK9cr1at85vBJ7RvL6WU/EkuX63Mtt9b baABJJISSSAkkkv1s7nribG1u6qUkvKWRtuz0kkkjDdkM3dloDd3d3QAAAOY fd5PO9kLVbAAbAzNhtsOAGQxyS22gnQ2RhbjaUk9MqSEwAqd4CjNOvpO6cVU kmNQPEmpKwCTMtsSSWy3AA3zKHZyyrLrJqVeoRtpgAT0lt7u7lG2293a7bbb wUOazjSdlsT5vzDdkyRL1SYC9b7dLwvMAAvdwSqVZkh5pJeVUGY2py6EwxLj UpYABHJbUmdZuyd1SSSAAUqSSXlbbm7bQBbmVuTUrjQe5hJJJPdpAAALtttq SS5Ek8B3unOAA3d3d0Dd3d3bQCOgfffaN3d3dAAAzMzMBSSWALvXEmfXt4yt GKUPuSTxrx9q1WyOSRJJJEklQkl93e7jMyymgb62q22WJ4+NVbaXkkkABbu7 b3d3JJJYre4C1ppcySW7bali8klSSSY4QBHzJMUsfm26SSSAG0idtbjbbbtt qSSS3dHZ3dQALa27e7qkkkSSSAJwHkbBy2JnTuOVpt2RS0WgATbttttkkgAk 87H7r1JG7abJLlGR+bO/fbM73Pvorfv30/dWn4ADnA5wWgAWoDNSQOaQraki TX3dWyTu7Y4ksJo5klkrdVvle9DH1Mq61H3cQ+ZaW77Y+POePsrmh7SmD6wm Rt7e2BdyS1Zh3u5FJJW22pJJK221ttt7usSSSTnIMz3pmZu7hRbbbe97222y ST1klzs1Ah8wz3cjaZutgjuJzjhOY5KzltzG+7qUSed7nz3SvSgAXV2vrSSW lG3e7zun1xB+zFK+A3e7GukvkszPE3pvc3LfJeX4k21uyTPZJL3domIcuqtk pJJNJJJwDRbQ23zaRJ9u6X3cPWyWRJJIABSSdzbbcSUlhJ7bf2ZaZzmZmAbu 7u6AAC/DBeZ6eEhlSSVSRhzJlcHhmCS0kkz1bu39NtkckjMbu7v33wAAbqSS ttttttrbbb3ddqSSQa5Ert3RsbKN6Ayq5Fo1eSYYbzLWu7o2S37utnod3TLb bbcyST0kkpOYSSSSTbQAA/XPd962/pbKA5znLJMwlIklu7bJt9tnpJJEkkqk krdbbZlr74JJJJDT7uZ9mNLfnZzx44Lbvsyst6X5uygb631JSepWmVLg+6cC MzFAT6PerBOdrBGYm+fmk8b433R3l3deOnLAjKvZ55pKE8x+7nXvKRLk/NWm TlvhV7HxjD3xEzPR232Zg88Aguc4+4PG5z2rOsfkVH681bcM/WwBZ7r0qUq5 8YcC4z3TSVyeXPTPcczgr2ifbZruOVcqt+zd2O2ep8LyltryctrybuVMzMlT MzJUzMyToANNa1gBEeRASvJw3K8u65DtWdtxSje0jFG3TPqQzMwhjmUkDMzC GZmEMzMIZe4qAAMmZgSTDLlS1pMgAL5v2u/fY57e/W3d9+9t9PtZz6wAKMyk K1VECtSFZBQFXcjCoRQhzz64dPvu8z1vbnu6fjusCCzGKKKKsUUbmELaQtpC 2kC2hC2hC2k4CJBGRGAiQREMXKENevzzL7mvKer977PH2tVCFagFakK1IVrI cIMSDmWYQYgMQYghLlhBahD2XEIZlxIZzdw17Xu2/cu12m+6V5S5cI95bVFC 8ANtypbcQ4gkikkUl3dUbWtnh7vpNUp+Nckg1IKGgAAAAwOq6craej8932y1 vdi5JIuKSRcRJFxSSLikkXFJIkpIwAswc2mnud7K8t28Xc20uJEkXEkSeSUk nB85CRSRgAyQhL21nclJ5K65q31aj3fMP3CSJJcJtE9JJCSiQAmVs0s1/fCL 3KmgsozY7M2N0rFuc6DkXXywQI1q+zfTM8h3iznmazykSHoW57JVVl5b4Gvj GHvjevrOt9mB5oguczdZ2+7+rN+F1zF8/H5WhH1nur/SQC9qzelRlXcxhPSe 7NJOhZfY89T7lRvEJZuGyFI9N8t9WrO2wYMGDDskikkRJOJEk5xZTWbteEZ5 YtWnVWVi4iSEVVER3LaQ88zDR71R++8evj3MJaIggTTM37ntPl/Z2dn2Zvs+ oVN3HbuIN63971719SXvvM12Z7YAHJVSXYZJNbvnvaR1zdenvZvee7wAAbbr 15Dsq2ZLteUkud92ADBgAAwYAAOKsUye4+qLyvJc77suQkkkkgAA0AAAaAAA AAOl1zmNyD19UCPPrfbhJISOADAAABhvcWrJ5T09a2a7m879rtruwAB7zUW1 WmXprutH1SuN8TfdkFC93AZe9lgZtXseXy6Xxdmfq7TycSHJP2OdIc9vRcbq zfdRDkYMtyDlTy550K7udU7g9qwu+NVokj9RneflkkAuHMPOpSlEsYl0fu7i VlHHlnpV5vc8COTqnjwY0WeK6rr4XMwCqhOVJS6QAIAAIBgLIbzz9mX6+0e3 7nxm+a998X0PhVRSst3l5ar/IQltABv4kjV57r+1zdGs6/lXcPRvPU1TaQ27 vrv1UYzr6/K+/XeNZFkFCAfAgsk1zfd61efrnn58cz6+xPykFIKQUgpBQYEz ml/e+1dt869v7Mzv523RCkZ2AoMqqqFQkoEQH6WlRdypb1ZRNRdr7n3Y/or5 XrnnFJIh9QU+5C7lXbOuI6l2AAHyXJJFVP677b79VffK8fdbw6BFwBJc5JAG /cXOcBttPKq+73M9De9vMvZj/Ubu6N0ADQBoncAB4omERO1+a3rnU8ZjdknE v3QVe0G7m2DmYuzS0SU54WvyYt3k4kFxYe51phzxpo4vVm+6iHJmMxX0wVWa SgOlGfzVb7036Yb9nab5d1pMk9R7n6xi9bqN5S8ebGJcF7oSR5ZRqz0vZhe4 DhpVNDE8V0G0xTl++Na1rR0BSCkFIKQUgpFXV1d84Jc5bq7iXEnVUggSQBgz uS667Mc5vKNyecQrnG222228SABeQALyABeAG29SSSkD88vLUz6g7QB5tVm/ KYnBtPwDTbbbbAQDWeVbda57WtfbndfTMj69XboAckAoAAAAAAADs19Nc197 WtffYePsMp4xfuCojD9BIViuul39e1XwG1cZS+TacnERaSjINvKng2ttGxyb Tp2RaS1JeTpR3Zta8qq2nscm1l7j0CSYkFIKQUZtD4tpBSCgMpzDh73N7v2t a9szpemXxi6nQkUIH19LVW6AMzMIKQUgpBQGGQXFfaUvfXZ6qrbWUtUiejeV qQNttt6klwBJLiBtvyz2Xmo0vqeS/VZne7U9N4lem3T4ZvXVc0MmHdi0LSDk mF2T150jk4kPw7krho5xezwaLK9hy+6iHJmMy5k7RRMB0tzzk7Jt8scnjSre 6R0c/SbRc7nE4Q2MJ6T3TQTrynXhztXLKmHWXwhmOqngMrjnyJyXUZer3vcC cAXOcBtttttuxTb772Ek2qpbPKexw+2kJ1IKQUgoC2kLaBaugkltkkjSe393 t3e613fub37OmfZ66OgcbcxlZnTL2pNkm55UL20sywBttukkAuIyRcUki4iS Li6LOy8vJt3e2qrNrVRt0qr1LikkXAgwAABg7JHIVWCu3ZXAdSOnVfPpEBst vySiW/LyXolvy823i8wBeTAEgBtttuSVQ6qp4kOhm8+WD6RDym2222222222 3JIAB5q57Mtm1PXdaeWXleLRd+XJJCFzMIZmYQzMwhmZhDMzAMmZZbYWdyBq 7sHTrM7hB0tN9EYlCSmPJe9EEC1VWAAqz2ZrWt+NcvtHtHs57DRfAABcku7l VUtndxbR9zPc39vWjt1tnPPR1fptPtxeirnZvTOXbsiBPueda3+odI5OJDjc Vk65fdxrK9NWTxopyw25kZHUdgiCkPn/bacu/eudRfH5WzukfqD2v0m0LO5x WYQ37iJPdNBOzLjzssvkdwHQPSOyFLgjeHtD0e15mYAAYnc05zvOazm8++1P t/Xk+yJJJ7c9dBlSHcqOlKBvt72ed9ScriXBGA6mVsnotRChJavJKY0ovLsd ql28UnXj2bjYCFYqEFCBMw9me59zms57h32jZmvXXzUIAsIAoKEk9VVVYnyS S1opBeW+dVtcKkVotFGRMRySkEgTXQBMyqil9yps9adeexWtza5t2MH0E42I qSSASQl3atSZlzZm+6sm2sWZtLbAGylxw4kAuAMOMOcBu+xWs93tzZl5fXSt ezNtXuAMSb44kkkxOcXGJp94uXeerzTABZU72rMN722no5e85TuIlTNfce3X VgJuS5h5N/qHSOTiQ8ONwWWn19pr4zVj9pvXsvoalvqIh1CwHNjl98HYsG95 /fe74/W90jozLhnrfQLuDhcIbJFnumkmZceesvizCoqFuJ7M2XteT9trFmbS rU0024gFBtINpCpBSF7hzWx7n2+e73Zr72jZ3ntHqQbSFSChBSCkLaQUgq8j LkVKre9l0bwqXXyMjn5cvKIUR70QvKFMLyiI97jdE1l7dM0vMVLeq7vRdHSA 3ZJE5ABQHoCgM+dZd6+99u94RuKt6nVdAuXllq00Vr4cXS3equu4F3vV242z zbmZb8vU4q4pZD6dmxZz01rN+bVpaW0WvwJaQbSDaQbSHt9tX7z2tOx0u+9t 1ezO96uKSRcUG2222yFb7ud9f32M1N+8+5rdXrcIQhCAp0hI1We4dPvX7uPd m732+8LvYp8AS0oBaKq9AAt7AJavjfT2+73hntTXHciTO+e8b6Ys11bnO5uq TIQiwJA+Q9G92xfrpVHKxIDM43BZIfZ7eizi9V8r1OUbsNOesmivrqyyxe+y hHZrX2rfvH4q3uke+C7GwJ3CwpxdIMJ633XQTry48/Wevj2vhQWfG7aMZ9jv OcM5wIgAM1e59r2c+9pm3fd+5nJfOdJbSFtIW0hbQNgKA5lIW0IuDHfmu/Z3 2NT3PazXWdqVWoSQlQXlER73vTTVeu8e7pGWs0ajyW+T22rvGd7p1s537ehN wE+CSKDCd5ebj993XbzSvs7SFwbST5+Y35ZfZ307t4u9v1IS83wUgpBSCkOE hmqa++33f3Mftb53e9Y0sSSSj3vovsajc43HHFK0zBUvKfEmzzn2HeY639cz uGfYCSAdJCfiVJYsVNc4CSSTpJJfI69Ja7V7kVysqzT7vetPJWLrxnszjvG8 tysELZRdWs6m/bmqhUjrCQMhrQ9n7WnjKeqea6HPUxV3fZx0Xrg/kLL9+5nt w4d+vM/NiR6jhSE6NGKHg0MJ514cJwvL7Fhc8cfuqvP1mC2W77m0VVO+5znl xtJpLkjboAGwGpKnGazW+37OM5v01fde13oBclcAS4kDbbo7Mt1k7PTJ33ey ZPS6720HQJbQIWurWQFJEV07Pr374+13nNe5rWb83zplgAal3et8mZ3vs7nm 89vPZzycACCaey8Xly+8Tnfd1z2u87BIaiNjL8wIiZTiZbcS5PeXiQkJCXDc uG5/PJeRITtmW9zrevNI10qTm8luZXLjbTBwb0MzNhIZmYEMzIQls+Xot3d7 uujb3LiSjU9EvLzbmZxLySeZgTMz4DMzCGZmEMzMPAKQUgpBSCkFIKQUhrWt aIKQUgpBXKqouKab721C6meV5O0U0eEAg1JJGY4ltLekkmGZS2ltLcAAxedz 7sNySsfrwuI8IMXFFIIPJJJRSfLkmXJoIChIlNapbS3MLmwHXO1+p4zdCqfX nrnHVW/zI4+eLNqX4eMZGsvemcs3atHncx7VPUdSOsJ33VcM9pSylPVPY107 MsNV32d6IdTMFYcp93kRww4NsJavdPWnzbvXja0FDwaGE868OUjI6pjO5VGA zbOuZy3EDJrbgn08LynMwhczAOgCgEbrWEKWkKWwNAAOGUhS0ha0gloHwKQU h27v3b9nLq5c59zLul1wgpBSCkEmY0kWGalEqVWZmuAAGtZgAAGZmAErMuVF 3VaqQlQlQhz7m82/cuvt7HOarq3U+AIyZlI0RUyXZIa3y+XzO53ed3m87yxE cn6VCUZmYQUgpBSCkFEMyhb8ABb2Elq2S26z75523f2s1vXBVfiELV8AAmEC CYmt3m/tZ37l3rf2+I/lVZWFVC2gqqstpBSCkFAZ1e7srvvFzC325qXEgEuc ikOcDEkAuIKQtvwsBSCkFIKQUgomZSAC4gFzp313h2VnejvILnOA3gAHEFyp d6yAAAzMyIAAMy4KquiAWrhbZbZbrMxYG3fOb+vzms++r9zMIW0DImZQtVck lqqt39r67w5revtV+5irYEiFYQBSSNCc40pxHfZLLh2zvs0fc7F51d1nc6h7 WpnFM8uuHl1j4XpMr1J9qikeWPoeQ9lbGZmuFG9fCqvTQnOu5pWbiuzNnjWw GctPHtD4ArNLtERJJtltzLbfW22gASSSEkkgJJJOck33xPSLgAlFjbfna429 dnpKp6SN2SSbuygG7u7ugAAAc439vx+0mZG3WgAGwOxQW8B0w8uhSdltBOh9 yUMUje1q+DzG4emH2nqe6YOmWqKNltDuQ5Eomk2Tuk3dttSSVtertDKy23dz XdMLQYqeVzu229Wb3cDdASd3bbfSSAAvTqpQ5humyejtuW22N7r8UkpahuvB yWUMCILqq3JNT3une/vrZj2bJSSWlBEu98Ta+7u5xsYOFFVzBe6Hqkklq7e7 rUkl5eVtvraALbEyTdACvuJJJPcAe4AAu222pJb99u973unOAA3d3d0Dd3d3 QAAHe96N3d3dOgC223MzMNttpJLXdnXvl8m3wPyz5Oj5WZkRKjZ16rZHIWkk oiSSiSSu7u6TMtt3dskikrbzG7W2ifEloAC3MvqSSSkklmK3gL2UpJMkkt22 1Ly8klST3SSACOwk1JryJncyd3WfAKVWNttuW2pJJLd3u7uoAFtbdvd1SSSJ JJAHsGodx5rQNbwzzxxEYXXVJJG7JIAAwD0NtVsknpAAJPN7GqbV0Jdc2h+s vJL9bme57Pvqftnz79fWn4FttmXfSDMkkgAEvEL2hQxdOlY0YGPAbvOYCvbu ilpLrrYb4uZofS7IfW7bsPWJC9a89iIEFJ58aqfWd0kbNaUuGk2pfl3d3Ekl yy1JJJW22tttvd12+rbbYW2ygCRJtVWbI7JJAAJJJJJJbb3d3dq6Q50tLSXG q2RTu4Lu6jTcxvZYBuizMm9I6XjJ8eLDzuZXAJ+tAAq7p0F7uESSpPrR3PG+ PE6bvbxHgGOnZtKM3uqtqmPzJqqVs9JJe7u61tEm1vrhJJyEnjVvdo60Nt83 G0lu6pST3uklkSSSAAUknc25JAtkvxG788/ZltZmWZmZIobu7u6AAAe3d7tv fP3vSbd3d25vNz7JZ5CiZO33ZnRVkkmykmJW0RuaRFa3u7u/fc+lttloG7u7 ugC27u6k3ddqSSZPd47r1JLpS3QqG4CO4H0WYlmSW93NslsU5Z6ZnGWSSTMx uz0llfs3m7u+973tAAAJnO8/uz+/s/vcfvr9bbbmPTBJxVcdSS3dqtzJRb6j W7u7s3d3SSSS9H33w2SSSQ4Wg8kOStb3fa3I07szxOyS7qCtSSeJ45VUhsDk 7vR5npyimYNrAHac1csfubfHXtbq2bxfpi3cp8s8liS3l276HR5P2SqfqDSO sJzeqI9ntKWOpzWl7WzOy0xXfZah3XvCoW0+bLQxYtr6GuVZ6nzbvXi0YlsR 8ShhPOvJiXjMo30LndVvKqlMe3exXWemQzEmmmm01rYAIgAAAAIgAAAAIgAA AAAAAJe9532s6a1v2rd5M1AtpCpBtMIMwwFgmEDWb+3v7MOZvn2q/cMVUgAN khJaqrZIReb+namLtdIB2d4lxrkhxVJGSAAAAAAL3a8Z6l3092tgYQAABg22 23qIFzMCSHr3vN3vPbO67fczM3nQkBushUqWBEAAAEAAAAAiAAIgAiVCqyEj m8IKQUgpBQYXLDpBSCkFIKQUhmZgMC40wAC1yjS9wBVVVGTDmaQDDfvrvz3n 3f/eXRT9rbeImYgbTTbabbTbabbTbhpzhuDu+/e/DjhOP4XEvN5wLJqFpKte GXTmUtpb8AB0kmjWqW8JMrl1Akg4oMQ0D6slaZ71r15XXW3JMRQgEAgEHlzk UggEBjE0VvYOy/Tcpeq6m1JLXr9xREnORSRcikEHOCAQCAQcSECXJS14qiyv X4WLJ7Ksw93tvpOX446D65X2NvYc7d9Do8pmCF3PXnUOcJAyGvyHs9rTyROa /H2NdOymKu77Dm1XKtVh2Zdzs7TNzuqPPgfZvoFOnFoxQ8GhhPSWZcX7ri9k kl/Tg/04KoR0uKzUdWN4i/JSpnl5NNypmVtAIAEACAAgBgFVmlGT1nFXiOrG 8yawAO8ve9VVVIAfkm2AAACAGwAbM1TZFz3ZUlXhtTkPJx4AAAABySSSqqBe XtSSVVVNttttttttLIp65p9dYVORxNw7m9a8nDc+8m2/eTYHvIAPeQAe8gDk l5RVVVeXl4KqgbKXvVr13O9ByKvDqnIeTjwAOXveRVVVe8BVEgAAAAASkgkJ SQSFL3rva9Om72yrztbZ1zp2dqqqpIAAAAAMGXfc7MPe7ZV52vWdceAAAGpc 5JAL4lJIuJyRcRouIBcU321KLzbKyu16ynH2lxAIG7QCQaDdcBsS92u99mae 9Xqzvap4/P1LiAXEAuIDiTXM7PeO8dfGt873e3510klZBZBZBQNDaQmZXlMy vLvYUoyqe5F5WYSU7L0hZLFXjjlVTySTaew/rn6eHrcFfqDCOjJAZjK7PB88 lcj8fY107MpirlGeWhTOwy+zHt3Lmdhnu5IacV9FsneSUc2cUuhGE9K8IgXh MuKehl/QiPiEC8UGA7ZrPM79m8AAOyXZNazAAAJmZgAAEzMwlTMuql3cqWx8 QAAde33smvxk3J1xmbAAMUki7x8TSTfGqqouKSRSQAABX32dffTtYddsz0AA YMAAAAGhjXKSbbmt+7572M3fHcvOexuVCUhKxiqhBXpOo5lxQkFMykhbSFtI fc+ud+fuxyzH1njySBtuwAAAa2K3ffPfbRT66ZvNaWtpNrjaV8o3vnu9op9d dJ3CeCHxUy0ZUXupIMPc1ffO++1dPzr65zRNWkLbCxjAUgslpC2kLaQltAtV d83r7Wnf3znd5133H7hIWqoACSVzV+9pv3me39r5z7HgyXdwG+Nt5tp5viZu 7qm+FDrcvcKuaVnrayWK1kKOMqKqpwWT0rhb0RSN5c7qmayQMMzeXs8Fyx12 2eXsj69nnDVN9bqvaO2+nXdy5nY5z4hTXLusej2CpFwwrF3bg6SvDMXjMudI XfPIu7liR7HHj6uFW9qaUJLfYVwRWZD7rFW9uryiF5KaYLKyslSCjSKQUHmt +5p39853eGvu/BYEFAGWOe5rfvaej7MO8+kEABNN++088+9v2h76AgEUAd3e X3tPu9dN+r8RSCkFIKQUgoDHV33uuX3uPt3M9PCakhKhJiAF3YAElpUJUJWm vezl+53Xuame3JoRIIkESCJBGAgt73W737M6Xei/d8kKnUqRkmuZnva3ed7r xzRnfQ+JVI7dgXd3d3dgAVCIAAAAvPt5fovd6y9b+7et569c7tO2Or96WKPU lpRyZN/Ue71zkZfUOkc4SHiubvP2e5H0qbXj7KunZ6mK64KtBr4aeF8bGMuY c4IcYGVtNr7ztHtCiLphWLu/DpDcwyvyuDA9UCd9MI0H2mEqc2zvPoZx5Lj0 O+s53PdZnQJo7e9C95f0Su3dfYU/sw76MpFRv3ksS97zcXNffFX97mr+8/Ya 3sOwgoqoqKzPc5ec9x9zXtb1l7hftBgCkFIKAsigLml7v77b37XTe/b8mu++ 9FkYURWhwBSCkFILA2PNc97j9zXd571M77j3hBSIGZSFtIW0hbSFtJaqrnPv s193xt97X28565kz2wAB67u7mubvvLe9rvOc38ma7nKsFkFkFkFArKyQ3AUD kivNt59vm737ffuc31M100QUBJf2e5NX1HkYcPUjXyw0jYRgK7PLR0v6Zl2e XqH7Etr9bPD9fXD0vqFCOTJA6Lj3s8h50tLx9kXTswUwWXcO+PY8RAU8/R7l zOwvnxUiy4t88ewmKxcUdZambhfKvCfe55M5yKjzwhjvJRdkfVJG9prfieIK QUgp1AqQUhrm/e077rbu657wnbS9JzO24rDru6581NcrSUQoEYVmb9mvc47+ 17nObvfOGb8cAAWEE+W24ABSm1W5jvtbmZe92KzNGAAAAAAAAAZSu893u755 6u5WZm6UZowC+ckAbbbb5R2Xvsd+rcrMzdFSM3zjbbgNnEkgEkDbfrhK3cT9 PX3My1DxAsG5mZ79uZneEBtWQRrEkbQ8QG4m23gOAAAAAFFnqrc3qebd5WZm tTc3yAAAABA2IG2zzNtdvxC5WJsIe9fM+zz0dw2Pym4vBPmQuus/nHeGD1wv FLwUI5MkbUaRnJ+zz70JaXovbq907JnqqzL4gGYiBJN1yZlzDihMwruhgHkO zu1B8j0aKxY9g7pXhmLxmXOlqg9M9hc84o0oh1RK1U8PZ6569zICybVKkFIW 0gsKqKta2m2c1cmZuZl73HXsrMx7NrHJN8auJtKpFIKQz2XCDmXCFpY13r7P t8vt469mZb2bdqSb1jTfmM4xnGMY031mezPZj1ujnFeWEk9u9ZPJAWZuezPU AKW2oc5EgyAGQOY8knLBkAO1Yabt0O/PMt76W7k3qw2iOoRyBJFvEoVdy1xW Xdy1xWXdy+csuhDjYd73PevZdDv1ZmPZ6uuSb7GAIAAPSSSQCSNsSSQOy5i4 w6uLJjXVVHSnu9G3GjbbczLegHAAgAAG26qqqjHHd1TxZMbVEdOQbD55ccdI A2AAAAAAADAGAABlkbtUuHEblVTnGietfeyMzLzLWklrSTAy8YAABl4wBKvL qou5KJU3jfnfu7+1M7273vRfd0bvvmQUh1qQrUhWpD2XFKUSBElxSScS4GcT PLp3c0qkXW9w8PZNWVCyWTHYq3DHV1L5S1vbBAGrYpyAojmyR7YhS89yPokz 6H26fSdhu+xR2OjFoVe4QpXH7MudqfXigIZw9w7OJC580jIynhcO5x6vOh87 bdDFUfnNwTtUG7nNFcMysk5YPd7cywAAADdDiQHOAckkXFJIuKOQ4kHe2rjz cvBxHAdkoldkzOtha8iqqqXkVVVS8qqiT794kkn37xJJPv3iSSfeJJP379vu +yNGifwH2N3FGR86+XlVVVUvKqqqpeVVVVS8qqqqklVVVAAABwNtrIv6HeV0 kaFP7sVHc2pJJJJJJJJCSEJIAAq13XV0kbITGdoqU7zmZ1ty2022e8l6AGm2 02222nENtGRdF9PU4irqqjjRVH7uySSSSSSSRyQJJJJJJJMaszNy+dQAQs6J aHW7PU1kJKamqEACgAbYIAEACABAAgAzyqcmb7HrTb9fRLknMfCABAAQA0wB MATbabbUNvzboiurqdzoQAXKzpKL2GutKQHkANNtpttNtpttNtzDcqZnE++v aW5G/VVYLulzDxsUkigIBALQiY0AiSYnVVKXFWdzOHb9fdzMrplzN5e6+ejq /E7L6TJniTr7ccvhvX1WhuihwDpCajefs9yPokz6H2bh9J2XPGKub6rQq9ur uRuZehnszsO30HMhCGAPH3u1dzQOcpElnJzc49XnQ+sy9mmRLlmzUm1JMbll RE3HAXOPnKot6b054ku5a5ZV3Ixx7BEkjckiTkIuKDax6Xl1ckaBazgiKLbS 87e7WSRgIsexSv1nW2m34AAAAjr2Xl9KfaqsqK/FrF6/QAAAAABgwAHPXat3 kr3N71dYc7c2bO92QUgpBQTpCJOoVRdKoq2ZdUSNXs0qW3q9qSSUKF5e9C9E LklSovlcVrNuqJGr6aVbe8vKIXlEEFIKQUicH94gpC2yKQUgpxNpPi737bWW Psrcu6Kiz4tX7PauJtcTSCkFIctINpBth0iqApBSJtcQCSfEhriydyd2r679 K7l3BizTFvveeINpDlzCFtk2quta1pVBVVda1rSqqkzKQbSFSCkLc377W91+ OLqi3LXRiN3ve8le39u9FdNfbX0bxcUOaHMUctIWSzOxXq7t1XVTd9q6oQ45 dGUXNXrN2qmkbF1ChFmXd7avcTnFekChaexaFHt1d3XU37MuYcs58UOe9PeX e5cIpnNJuRPOUm5x6vO93irMMhr85MWTuWTruG61ZEVg+uqcxKqIuDNSMSiI MgqrtbF6yNuqocNECMxem7oyIqYwLupilmyYq33l7yz3velQ3sRU1YUIW7NW r75cTa4m0kOTzdXDLuzLjte8Vl4l0RTWS9e2Ncy+cvU96/cTbldAAxcA4l5u rslt4Wu1Ubi94rqvPZ5tpIykFIW0hbQLaSQtoFqrSaM3vauvs+xc297d6N9+ 4QLaQtpaqiKmS9e0Nd1rujU172b1N+6Ael2ekk9AAAAAABEEGm2mklIJcWSA YTKbdeqoop33qKVp7t3d3d3aS1pLXd24ZeMAAAy8YABBGXjAgKCCUHvKyTIr MjBqIbzGQpcdnLixTRBV5QhrL2cT7uzMxek1Zvsx0XQszf1jZYxGSbtVjo9l xTIa2OMU7s3nSLJ0FEdr57sznnkFrL3comDaCeFuKz3Zsk7u722j7762/rbb QICTdkJJJArbbeNtkU2Rcl7u7uVbbfm7bZ6Nv9IiSRF5b999bQG7u7ugAFtt ttt3dO7bDI23ZAAJAM4D3PpNJSuaYVijlkk44T7HYfGnm/OXNsW+CskJyduj fbVaM9sXae5HurSSRjtzLbcyydndTJIG9PiSWr3c2y5aIAHSkkABfO23uAUa Tb3drskk9qTOEbfQaxNbstrdnpJI1N1tJKVXPLETvvYcNs3ZTXZqwCT/9999 9cy23gB9ZPOQ1IJJJd1iXdxAvWUC0mpJILu4Kkk9622NgTuAF7LbJW28ZeHi eJPbpBAHcgDd3b3vZO972JzgAN3d3dA3d3d2AC0B3vemZmZgAADd3d3QN3d2 dzmvf1nUn7uT+++0vd5lPM7iSTu0L5tt93dzJJJJJJAAb9I8mo02mrBqa5JL a35st93dz9PWpJJEkk4rR4AVlJJkkl222peXkkiSesjyDRGzpJnVLMRIC7t1 LekqaSSTttqSSWexd3d1AAtrbt7uqSSTSSS7u6+O53r3Vgi5G4bY/JS2ySSZ 5uzgBJAAFD7u7rbZZjbc7u6Tzy5uj3pmYYDifvTfp99szvM+9D/JFoABzgc4 Dve9Jmdy5bJczs9S8BLyJ5Mkvd2tpJdeDZ8zzSxyyavVSUk+JECXdCs9leKi LOJIE9GzVGzWklFEkkiSSUkklZbSSSa7dpJJN3dttbbbW6I4r3FtI2ttTWk9 1mySSSS20AC6V0GThAAI144t3Zuh5jbyQ1G/Z8VqUia+bXklPJdzL4BTH8CA 6BUTbZGyT6kDd32E7iZ05pzQyX2TSczRt6u2q3ZEkqlbJukSSUknlI20pZJC SSe7u6YBotobQXlPJTz1sbrhrbbattpJJIAEkk6ySyQJJyveD9mW1mZvve9g tu7u7u2gAW3z19vWd3E4ZG4kknyWkxRb452XMhlZJJy3hzJkkbiAdPdUlu7s kkklkklSSSttttpkSSqQAFlSSUiRK3ZqJFZDtXn4o8SUbi8nLd7m33FvxVzn HOeADnAAZ+zM5m5nszQAFtse1u7cffX8WgG/fnDzklqV9WXmNuekottvqiSS UkkpG25La++G7u7ultZn2eEn35nvWgtuoaw13YVOugTpa03hWK0xIa3dLWZ5 8Wva9uvRu+dZ0Qh+nlnno7sr8oculvcaWt3LkLI7r6vcncrOTJAa8N5ez3LS 0ovQ+3T5zs7LsVdo1M8XZqTPdUHBc3LmLB0Onnz309vZ4aC8j7SoXxSWuJdy swn0c8wYuAis9JuCdqo723YzV779vWtTnuZ3U277gAFUSi7sAANVd5dgAAXd lyadscy562+3D1SSnfvScvtxsAAAAnZJoHppcHNpe2bvg3794Yt2ZnpqbeFE +l3m+mnpwgmIChpRUK1QKkL87csms27x5drbdFYhSvKIXo8l5xhuRFzV5d1m Zl7royLSURkQvKIXk9bAqavLM5zm/e9rm7c89JFVK+VKjQDWa17u999h9vez 73e65s52++JbSFtIW3hIZiqqbtz7nWXrvs3rU99rjXb3zr4giADlXuSXH3zu qi2rmT2d0b6lxA2220teLyOY88scmtg8/Ps89Her8YxtBb8Elr65cnde71W4 mSpC4SE2IZ7Pcy0mfQ+3NPpDk3aq05R7Ezxdmp8BWOxh3Ny5jzn3HU56re9y HPKM42visOuE90swi0N5FfYsV6Lye5Ok2YHKtnhvKYeGtKc3G30Qo8o96Duz B0a6gPcVCdz18o2020222y73cp1Lr11t2Vbiw3OzW2222228JAMt7WZUuvXV VtW5x7eZRoAAANttiQC4gFxZftvIVe3V5mL3PnB9vvHXiDaQtsMgpBSCiZlI goDLekG0hbSDbOkVcykLaRZm5eNXvay8zF3OuLpuejxcQC4gFxBSWqqxNlnd /c5v3OcPc+cO33D2KHwBKkolLSQgAIZu4ezvub+5zh3nzh2+5fJsZVqMhIm1 eu9fc17ez28cXjcXlxdeYN7de9Zt37Lc543F7W+O0kAuIPJLgCS4gnuXMyrX u6nXao31zqN89Her8ZZwALZzkFoeX2S6M9fXtzy185OaJGxCF+zxKUbR9D7d PpO9lMVc2Jwl68fvVJqbO5rHrduu5bq8K2eVOeCW9rxDOamvqnlYoR7q5lJy q+zRshd8syB9qzTLDu3O6riTCh56KpMzMzGm2m34E3nReCsq/K7u172V216s v3k21VRH4LaQbSHsPtt7bzWud3vezu/Pzodb++4QbSFtIW0g3Fta2trbevuy qtl56syZi3tRPb90YAAAAd5ySTiUkAAa9mQfdud7e3RVbPRYbizvsqSRSRBJ JAJIRSQCSSLJVSd2plbTCuVdHppacxcAAAAAAABvv3794YBmb5TMqIXojyp5 W8NYZ3RW4ZnTtitTtXtZ8AsXCVIKQUgpBSCgP2jX229rJp3uq8zvd89E/VXh FnAAAAIlJAADiU6/dHnqrtbqq973s77KR7FioAAAAAAAYgq370FSt+8qvd97 09uUuzerqdjbbbbfEAAG8SkgbKKfn0YMLrD0ki+N89Her8YxtGuQZyC19Trn eG+nbnlr62c0SCJo2F+zwKUbSXovbq9Dx2qOx0YNBq2TgLqVyZcxZ0ZzihzA lXj4nDzzNwZ1lPmndY6o91cy+Jyq+ejPRcXfOauVOv3eREhl8VI2O7Fh7EYi wABpxJALiYLiAXEAkFBYsikFIsEtpDL3mt5e6z333tReb7tzuxYezFdLiAXE AuIBcQC4gFxAJIG277VePVfb09mq8288TRWdy1e2uKSRcUki4pDgNtt9Bv3q urubedkN9FVHt3x18vHMzMzMzO97ShxfhCqnXLb7cjOhVOVbUJKLS9ZbMjWH Xl8qvr3OhVOVdpeXuKsnY5he9e1fXueOylfeUe8kisnY5hedfKr69yYXVgrp eSQ7zNb9v7fjffc79fU3ftc6aMIKQT+ABB6eu8z9z9vxv9+ecS+wvNb3Yz8Q gxkkkf3nnvn99H2TzQ0zWznlo7z+flBKe0WTF2JaD7OTaQV8axntfK2lxK8N Qpfs8eK2s0+vj7CMkCzdNqlHQhIm7Bu3Em1dcdGzEHVuZFk9BwcoaoaFcwjs 6cMvIOiIhWZ1/RYp7Lno1pd85o0nDVxeLpldmoWzj0teRUWZebD2r1bcbNES 7XlJ2FBuMRTynlM8NXv3rySbgrFU8pA/dnN/gH9IoDiRyQlNplPs519v9+zv OnNi5raFTF5elJJLkkirvIzd7ZZeo1RrxN95e8vJ6beZsXfbt6tIi9G3ySSW pIBFAEDBSCkFIKQUBEQXl15ewXuR16r2iZy9yQNSzyXJJJerrvfdN7r057Z7 pe77zeZ4ADZCIACQ5UDcJew7Z7YcTiwezve9Dn3e6VeQ9nnpig2XSznlo718 vFsbvSN41jugPXkF8tHdKx7Pa+VtLiQ2oUv2e5Gp0+vj7D6Q55WpS94wiol7 PDd9WKhdw9cRxY2wal+33AeON9hDpaerd9CfCWZ18Mnqr7NzxVoU7zUHQM7a zw0x9Z7Z7i/Z2q4fySSSPb7y8tm8ich5yh9uPVlXO3Dd8AB1ICfiH62GiXKQ f3XM/XO+/d7rfTfNTvIyZ32pUu7quAZmYAABmZgAH6pJV2GtZgAakktoELZr VINpBrVVdBasHN232xxtdtrdVPVViy4a0etzM2m2/JckvQA15Ntrybb8Lyj3 gGvJttebc+SRHmkEzu7WzsybR70no7y163H31gakkkpIBOJORsAikgG84uST N959l5dSZNo95SeuLy731bxcUkAAnOLnOSQD7kkmZaEkvANJJti90JXnyPsH jdnxPbinjx6LOgAAAxjGMYxoAY3fe9hd9nrPe7L8p22Y/MY0ABwADnOc9fuu tn2de/HM+45e00KcAUgpBSCwF/EWRWSsExIKAsFIhsh57rrve88/fHM+L4+o kFIfZSFtIW0g2pif3OLj5PLq3vu7b2SjrCtM22sJS9it7j4iE4HRxO3OmuVD PauVlLiQ2oV+XiUqzT6+Pt0+k5bhpcvs7gT0x+3dnsTG9KMOYc6xrDYLh7u9 vqDneC3BnVwtNYISJZmdfbs9VfZuEzS77nAEYbT6d9heLJ175ZPI906upcTf ONKm3YA+9PVOz06/eWTx7qJOpgwBgwAYAAV7Op5Z28nfeyvI90naYfLnOSQC cUkAnFySI1JMFxALi6u+y69mPu+vPNye8fZ0hbSFtIW0nZCZlkhaqqu+37vZ XpzsxVifXffgAAJJJJNS4qqqAGNnfe1XOxZMVZjNTyvAAAdScjYqREne/P3d fZ9h3Oa48+vQPACHwIhiqJLipLLl2AAEXFgJXYztTrRcZUZNZeGrV5QoXlCS Rr3diHGYc1w1x50vYTgiQRIIkHT9iqiCIC5l4AIgDfc77h7TJ3OTXOdy/O27 UEQF4vEJJeLlT6MwsgqgjhKgwKhFgfgGVCLBJtcSXK53R/Xt+orN+Aygr43t tYSlrXi9xk2+RzF7gO9lwee1ZKxntfNWlxIe2rwr8vcjU6fXx9un0nFBVGX2 dwJ7z8B7mSe2k9x13X7H1nr7VbmIKcj1YPsNdJWY53CV5Pbk90/ZcMml3zi6 aGptlouLJarM8oeXWn3nyTaUUiSEHy40EDDKQpaBokUA3o1ohfnM2Sa0qYzu 595sqK5ar5Y/I8joAAAAADBgB2/Y3OxXPU8XfPz623q4BxJA2y1ewCYsUgoh MxaHz94+z2HM5vnPvN1fmD+khaqr4fBKVMrS7Nd19GhXtOX3fHna9vBEQjY4 oCkcikkTmVLTabbTsNqsIdwHK117sXq2ZTbakkUjkUkigIikUkihIoTtWsVB FleWL3r71dlERGKRikcigKRyKQRFIoSKNmT2US55Yvd8vGeXrFxwUEljhlIY 4ZZClzAqqqI1wwpDHJlgQAJmTJgAAEzJkwAACZkyYAAB3OZy7ZvPTnu+nb5m TswAArGTLlTGRz7ylS37ya0AQCBAwQMEEe95gmUTWXahNaRu7kzeI0BAwQME DBAwQAIAEACBtNiXouNd6tiZFyHoUIqyoVutceVeeOjvV+Jj7SnhSV3r2ac4 RdJYM9s5u0uNvdi93n0jd4rlSmaW6XKrp4i1CJrXmzjmdzTscDwo5uNb3o0h 7TO9nnueCcbTmDu2V5Pbuv1NezJuc76B8D4VM8czw2ILGzYNI77wA23MtiQA e8vSALyADyS8AfAAvIAF6/uubJlO0/k7+x9sTO/LwA25JJJJJIBFJAJJJvrL 7knKjmoze5qrXMtw29XgAXk2wXlAAvJsBeUgHuUe8BQkmQEr2lPJl25jlN9l 7tw2ccJJIEjkkkgEkiikiaXEMjOdPewvoR2TDPX33nhSkkTBREgEJIiRSSKE ibUfu0XgKXPTA93PeuRsE2gEIEAAwA8uIki5xc9LyhS3PIz3c955GxAANttt NMo92sukKXPKZ7331stpBtIW3wMmZSFtIW0g2kLaQbSFkHvPr113WO96+OEF IKQUgpBSCkFIKQUDfOWmbczl3d8+FV2W0g24JEFEuXhFIKQUgpBSCgIZlIVr ILIKaCfru7wfLM2CAObpRCmrfPe71fjGNRS7Tt13s2509narLBntZK2wuN3e GVXyiTfjT6+Pt0+k5LFTX68PYCxLtG7ju1dnrOiOLI+8j1yB6PUnZ2eTlZVy eGSvOnp3B126N10a76TdPe0veL3xWAXTtWd6AAHbsvO93fm+tTPXy995vy7s AB27uVO5fm+u7mvbx3L3rwADehJJFXvew11EbkyTre3oSSEkkkjbbbsMSSSC qpy3Dmsww6OcRNTVvFCvAjnKzMyVF5lUAvLwJJmZkozMwhrl116Zxx7x+276 5wElyyDaAkUgpBZBEgpBQGRZBZIOPnpmmd7l6wSoa045M0znMvWKwG7sAACx 5SlOlZiKd1Btttttt6Dwst9tS3T7kolxUk+NpJtquK8XaOr3oJTvMDfaQKad zy65VRdvSZnNnGHM8+4b4B+Jzono2oU7fcykxf0PaMAZCGdde5QGvK8x7cfk 9zBkwvE9AqLmdPPwlvsE9rV3dYi5tXySJJJLltu7sk9JbaABJJISSSAkkk5J J7Pfs4XdZfetyyySfpAv1tt/Xbhe22SLfvvraA3d3d0AAAB9iXW90ibdkAAk A7d4R73I2pLiXXZpUVUZgaF3kQaputXZxeSOo8Nz0rbpik0HZrLeo8+5XrYd 2G+qAF5t5tbHGExAAnTJRSSSXG22AA+xy29wHlZG5Ju7PUPzb7SuzU9gjcct rdtvrbbZuyYm0rKtfqPH3PcMNcJcl1YBDP777431tu9nt+veRFtSRJ7rIheS ZL0ISdakkkN1XiT3pbY8m7uyXc231tbbeve15vE93uBXcigAE7bbakk+7ub7 3vYc4ADd3d3QN3d3dAAAd73pmZmYAAA3d3d0W1JIPOZXlfopdPre8CRUfprA 6fNpNgANJJIkkkkkkkknd1P1tt3Z6N4cKrdXiSSY6pPbJJ3d3OoAeteNJJEk mvJ3AXuJKJJKtttS8kkiSLIn4ANxRtPG6lmIkBdmLUFJW0kknbbUkkt3VCST QAFUlbSTUkkmkkl3dzscZQsrUEJmKySSRZi9W2wAH3Ekz0ikdbc7u6TwlM8Z 2gHr3WS225eXM9ve93md5k76E++3sWgAHOBzlttAAt7m33NJdzNsJ7pLCSOk CS3dbaSmb12ekMPNJxve9D6yVIk3T2i7+JdeeEA4CekZqjZrWOdvSRLMpJJb SSTltJJJtttSSSW7ttrbba3WJO7qQW221bJC844TVHJJJbaAMr4qdAX3d3SR SbQCAOuZbJ2aH9nij5UZuZhPMWl6lN34U9y691aNrepKsoMbtaPKZ+Ja6+ZC +yX9l+uk93T777JO2TZJWLbQ+++L3vXm7upJ0GZmZnvue8OuAaLdra7l5RuN TdcqSBLG5b0hJzM73sr4XbepJ7d2DMwP2YGczd4O7jbZIkkkpLbJJJJLcd4c PMDIJGYkkokiYr3gBmNuEkky93UmSSSb99azM95999XFtADd3d3QD8tJJqQA vWpIpSNtvd1t5hNE7m65i8uAC66152oBJslu5htuZZQEOskknOW0Az9mZm5m ZmgAAb7vb3lnvtvv22wA5/stvfYzCLbzgn62ebbZJJJJJcSQSdl3dVqSSStk lJ+zwk+Z971pFD6223bQ73vTrfvyTat6GjZelAjzxoqdnmQ81em66TswmcvL NLhZLFuLcmWTDuH02+moW0bjJYM9vErbC43i4YX6wl1qL18vbq9by1YptZyj xfNdLq8N2qdWM9V0bWP2Ob3meihqXl5bnopGVMmjZXnTwG+7yW2HfXvfC96o XbOjfZCdDR5TrXaQC4gpC2kFIKQUg7IKQS/fX63W8y/bd4QUgpBSCgzgKQUg 7t4Zxzd1efcvPiCkFIKQfUhbSDaQbSfxmEWQy0gpBSCkOWgJUW5cVJk+u/ut efMvXd3z3pN5gAAZfrubzl9yLxrh9JdgAHb6jnLnf2aZznQAASSSdWxhzlzn c0znOgAHbsl7y9c1mjndTec5zsu7u7oIUFBF71Mvmsu+dzeb7CEKCEIG7525 zujt5be+gACoj3lELynLn5nyO19S7tnbp28uFklLrW5Ojt7e8LvC7M9D0ZSl Az2xF7aXGznHz9SSq1V6+Xt1et73QOqY7T6GsNbBvtewjPS861jyDy7kVjyr fD13PFy0ybeTkHvZBqs1rM2Z6L0q9WuZCbe5JDoXvu63n33khxrIW2QtpC5c VVgZbIZbIN7efYve91s5r6vZC2yFtkOZmCUkQRBAAAF4Wdjfvdq52vHZJCSZ mYgXLiQczJC2yFayCkFkztedpv3vVc75tt9AAAAAAA90mdjfvTtzPPoFySc5 ILiAXEAuIBcQC4gEkEcvKbwrt1ldGxAIGIabT6IaATOA77jsIXadiBCAQ0wQ CAVtFFbdbNbtzNuzSKIxV2SCwk4HKBXVuj0qY8j4lMJY5eOWY8jTbaqpDdpC tSC1Dutlee1ucT28vNXpCi2s3Nxsji62EQVBCh656tyr3u91kS8WqJu6Z6xV ORlevj7dfrSdM3KllHtXYXKMsXZfLt15X3It4x7WzP10jyXmM9zNbTuCmrtT zp5dpb2l52VTd2g3mcv2bO8NfXLroiwCIioiJvl3z5329XvpEEJO8zfO5eu3 u+ytSEqEqBBSC7Nb++u/ru/aIKQ5VXcltCS0DF9nN9c7er50AARu+751vXc3 eHgFIKQUgpBSCkFIKQ5eb599edu9c+7EoyFT5zfL277e8fusUIoCiii6GtIN aQa0hzfte7rnn7283jnfm+hBAVeLqYALxmARABeMwqS8XKi1yotci0astbN/ a9nfnPr1b3yEIQhpaiW0MYwnPerlp7toll9ud7gn6lWdrJKlErPXC5p7w6JS W/nWcF4tU4sMnqiinWV5Xy8NFpzpSco9wJwSX1mzU5fQ5XSGlNx0n1Ma8qMW rj58vTs9iirfm5gtIQTwzx7S3tL3eqm7uzxo1zHiLUzfTfQ9btjGMYxjGMYx jGMTHvezNndDL3auHqabGMYxjGMYxjGMYwy8vTa7r7pQ/a6viI5FwjUYxjGM YxniNA1xCY1xVZT9tZr7pQ/2ntpCjUhRqQo1IVbSFGpRtGNAIPZ3trNnded2 Wur0EAgEAm0oooo75vZ275287d9eGdJS0hS0gIFxCBcQgXEIEkDbeVV2X6zz 7nb7vMW6s9AihAFJCMKkFIehbSCkFBkqQUDQLGpRE6TEgpBSGHXf27zz8/b5 7RerrhBSCh6CFGLIpBSCkFMPn3N37z8/b57RTuuyJ4EYgwHD7Rzz7l3e+0U7 owC0+Hq0hXmZi32gPQflzR9mh58491d4ndLwrbjF1d+HRJy39V2S8Wre3Kr4 xVORlevj7ddolJeDsuhHBHfd2132cazkTIUkxyiFuLl3mLezxqmNr0o2cOeB rtbO+8bcM8ErPIA9Y33FSqyr36kLRQmlVD0EMRym+a9v686+fucwfsw92QzC ySWxVVRjzetOuvXm70+/ahOAIeJJ39779x/HXeqe/H2jXxKWkKWkKWkKWkqD LSFLSVGVH8ABS+31082ed7vv34c0CijhKUpClKQpSyfiCIyfamaiAAiXrS8l S8y2EM+dfr+51/P31/b93ZswhmGGH4AFABggSKOadGaEVFVFNaNGEMwwzSgg a0aMIXGkPBftXWiCkFIKQUgpBBApmZIsYcIqa00h25vvTzznM9zuv3NufoDY tCDWKKiIiIj21/e8/nnN+177975ERFF/AANVKEkQKnAigsgJWRYsPWvtde/X 3v7Ofvt+u4XFoQ8tCgfqkqu9+1t+1v7197+z9z7YP0kkl2AFySSbuweh3kML S+ffb1mqo+zV+ra3SuRXasd1jOOgnSjJb+UpwXi1Z1BHXxi4uZuLVYzu6r2Y xPI9vvlH4KqvLM26a3K823jsDN8d4eVYz3M0b5mz15HtLzn5dwLDEjzd7drv tYA9TuKLhGy9bH3X77G2235JJL4c0jkI5JFJJISRM2vs6LqzD5/fXVz9EN8k kkAOW224cNiSSTIBttNuZlnTSr47caeas+Pt+mKvOXlAAvLySbYLyABeUMgP LyUuGC8oZAJNecQx+PQkgH7yhtryCT77ulTmas+r7fpisxry2BjIXkA0lENz Mttttvl6vR6IqqoXkAC8gAXl9NO+5qaxb8fZ0xV5q8oAPd5ej3gKqkpqqptk tuZbcttttt9Bd9z9WL7r+zpgvG23o+XvJgNttt6kmALyYAvIAF5AAvLpqzn4 1ZXX3z13uL0gC82DbbbbbepIKqkqqq2m2Bm/Vy/Lr+7974982223q4AoVKQI oDJUgsH9zMzX29b8fn9z3369+zMzMxgAAAAAAAAAAUcPpOS998q/tmT82222 22238l7wHUgJmW2022njv56fb28t05xf7Ea9WK9mXuZuupojtOYtB7dk0175 F4rZf0NOSlRX2iyxUqbWV6+Xt1XnAMmjwQwt2+J32z2C+XTfOMvxWvpvcPF0 Z7kTjMdpq7VM6TH2+UHoK7bwRh9uZSRuuBKgvzLCrHegAcNy22+Xl5AAve8g H7zb1ebbXk26Era4Xd0uJ4bebqleWO79lFrikkXFIpElJGMhHIRxjGMYxzK7 3qnpfV1y9wmJialOG229ABAEpOG5STiXKTY0hjRO33qsrFj7WenbHzgxriGZ HI22225luG+XveAH7zbfvKXvdyuS1bznr9vmZIZmZ4ABIa1rJC3MkHMyQzMw 0AKECKEZNa05IZcckMtNAKBIwQAGZlIbzvveOXXxxz3Hm92QtvgAHMtuEAy5 kDLmiZmYQzMwhmZhDMzCF+973jt30+zvHmt4BTHGBWpCtZC2kK1A8mNykMbl MczMzCBJzd1ZJit7fTlXzbbbabb8m215Ny25nOcUknOKSTnFGQXFxLNyu77N YTR4dM9IW2QtsCFti22222oQjbbefFdm+uFdHnppK2OSIIBFJAG+c5zjUz2T UswBXGhvPX2YxScURHouTerMlD3iD7OPJUpxK9+qLVKir9m9esXFbF1rlamb 4CYzaIlQOCsmOxUa8nLi3ftlCy+VrZ9By7PVVrLXY6SVVxDudbk7cxUegrtv BYYfbmUccuxrjvPcW9bhQB8vkqqdCa1kwJJmTMlBWYpFxSKRcVPPeZMp2Z5+ tGLikUi4pFLS2ltLaX0AmYZkgZhmSQMwzAA93nvaufad6z7z7hfAA5hgEtFF FFFPrRTM737vsdfadcz3z7hqWlCEtFgAbu77733cyfb7t2/tvtgG7u7sHYiH EglHZ3yPV23hXfXYABzi5wBc4lwAAAAAI8u++r2ysvce7VZmWm4QhCEUhCZ2 +bc9vk3ud47me2+5yKoooop244ZSlvgcMvgntPcyadpXa7j6b3Dbx2e4kEbY ITQIQBAFLSltFLbFLbFLXed+57PX7Ru17H0r23a8IQIBAIBAIBAIBG7vrzvt 9VrnRnJrWunM0UpMBHSUscCzLu+0M5gPGcrLf1PKUqK5ujnGaprXqb5PXRSa 12b7OGcnO6CPCb58dluzp7ToWyX2ZcJ3yXWHPIo5IrBTV2qZ0mPt8oPQW3IN OWH25lHHMbDvMDvE+9j7ss278IBAIBADGmxsIucTkFJIdz17WkpUu2+m+da/ YxsENMDAgNMEIEIEIEHK5xc4EQ2A0d77Z280aPtv3M9130eWraVbSraVUVRV FUfgLUaQvso4Qt1nPez1+0aPtv1992999R7AySAtyOEHMLhDLg4TLg1oiIjS ANERe653uW79o+2/BvfC3nOPO1vu0E9t3Oh7vjec5nOcfOLnr3X3ft5d7z7T l391UqSWogAABPzaSYLiAXEAuIBKu53tegXOrvcnu+uYAAAKkST2c57L7l3v 2uz0YDmj3vLMy+9+8wbJ28OpiywAObGczKIUQhCEOVN3k5Ne5ot9rd56+eOZ oZS3fHirLTcSFzFo8jnd0HWP8+PZIU1MIHFxGqNW+567UjnG+1E5Y57sc3Hn Ovjsnrs708c1bFL6peHteKdnjOtvJiGHtczr5DfFjzFwyZDqg71zH3OOd+1f PGua9t93MzvfZroQiEIiBDXc701nnNu9zM732a6hCEIQh9VSVFod96/b9rPt d4+99rWur4hCG5AGooovAAa2BGtDl79rW/a37Xx973tZ1zOPCDWkGtINaQa0 g1q8slxWe8hkDlw3Lh0kpzW9vqelb1Jv5zOM+7JKUABvW297AqXvW1ry9ypq 9MqbADWaa0AF61draqAZca17vua9vntb571mZtu0U6iizwBEQiR3ze772vtd 9TM525DqKKKKLa1re89y++vc+O+2Zm/qfOkUUeSQlKiiiij9vt6fPfa+O+4Z nPWYjulaeCAQCGMYwEZxd3N31vsfsCai01aVrW21rWpUqVqVqVL/iECVJVVU /t/FVFSpCQKFKEQpBEKiqSKSKIgqQRCBSJFCoJBUIVChFFAiooKLBYBFFFAk BYSQkRkFkAWBFkJFIRZIoBFkBSCwJFiyQWQFJFICyCyRSALIsgKRYQFkigRS ApACRSRSSFEhJRRCiipJCQJRURkIpAIKKKQFILCQWCqjJCpRAhCQKhCSQhCV RJCRZJBQFgisWLFUIKRVAFCSLCKLBYKAKKCyCyIkVVIRZIsFkiIEUBGSMjRQ EJFIBEKUJEJFQRFJFBEEIUkQKSIoglCQiIAqCESgSCpIEUiqIixSKSAIwFki wUixSLILJFgsIpFkixZILIQWEiwFIKQUBYLAFIQWKEiyRQWAsFkFhIoAKCwW QUEVkgsgAsUWACigCkWoIJJUKhAhCEKqiSUACgiEUFAWKSEihICrCKLCKBFJ CRSSQUIskUhBSEIpAWCkFICySQWEFBVIKKVCQkJRSKkkhSRQpAgwYrEiCiCI IoMQYrEilSEkoAgUIQQiCqFRUCUIKoJIKiVQSEhCjFFJICkUBRRZBQixQFkR ILCKApFkikgLFkkWSLJFFkgpAFgKRYCwgsIoSLIApIKRZICyCwBSCixQIoQF igLFIpIEUWApBZAkWARQAVUSEBZBRRRRVgCkFWQkWQUgsFCLFkFJIshIqIQU UWRQWKoSEiyARZCSSRQIoCgLILIiRViyQqVFJIQiRSJBSqKKCBURQqKFIKUR CCCIBUAKhRURIEIQiISAKAsVghCIgRYKKjEYSMVFkFhFihILBSChFIQWEBZI KAQUAUkIChAiwUBQFIoCkBZFihFWAosFkBQFCCkIsUFFIQFiqQgCyQEYRRYC goCyBIxUiyBFUUVRYsiwIsFgQIsIsgQUIskIqiKyBFiwixZAUgoEFJJFkgCg KEjGEUFgqkURCAAsAUAWQAgsIApISEkQigoikhEEFJSRSKFBSiKioIilQiCQ gEiKghFICIpIKkhRkihFhBYSKAoosCKEkFRIRSLBYSEUIsUVYKKQWSRQgskI skUkIsgoApIKCwFIskWAKEFJFkgpFCLIshFJILCCkkVSQWAIhJFFCIxRGEWC kAGIpIEIiKQUIoCgsAkFhIoosgpBSEUUUVQWKCgLFhFkkAUJFJIKQFkhFihJ BYSKQBVkiyQUILBQIsBQWCgQUWpIVJCSiBEIUqEAlJFFIEUkUKUJARFJERCo IUkKQgRUFFJKlSFVVUQUiiMYihCCyRZCLBQUJCSKCyQWCxRZFCRSAoSKCMIp IKSLCKSCkJFCLBSCwIskWEhFkFCRYQUhFkUBQWSSCkFCCgRZIKSKSCkUBYLC QFCKEgpJFIoAKAKIwYgsAFAUUUVRZBQJFICkUUkIoCwkBZCLJFWQkUhIsBYA LJICwBYSKCyKQiikWDEgLIxBSEUFKqFClRRUSKglBIEKRCoFQKgVIQqoSIiK AJFIkFCFKFKSKKIlJEUFRFUEpEEIkJQVSJIUjBBBQBSRSKKKoKEFgEiiikiq SKBFWKQFkILIKSCgQYwgLJCKSCwikFkihBSKEgKSQFAAFkgoAskFIKSLJFJF CKCkWSSKSCkBSLCCxQBYQgKRQFWSQWCwRCIhIskkUUkgoAoKQigEVSSRQFRg KCkUkkIKQhCFEJSJSKkoqpCIKpVCRZFBSRFSRYAApBSEUiJISFBIpUoqIkgI qQJRCEISFCKqEJJJRUlUEKqioBKKlUVKoqpRJCQgCwikgsJFIAsWQBZBQFBS RQikkgRSEgpBYAsgoKEUgRQWCwiwUixQgLBSCKIpBSEWQFCChFICkgqkQVUo qUEIQIQkJVVKIBBRYAjCKiKoqySCiyEBSBBSSSKASAqxViorFEJFFCokEhSQ QQIioERIEgVCihSRBUQVRQqxUGECCorJESKKjAFIKAAsgsIsikiwWSQFAUgK CgKEFAWSLJABQCRYCwigCxSSSKApCCwUAWQiwRJIKBBUSQVYKQVQRgKKAAoR QhFIqixFYAoCJVBCBRKCVCSVCUVUkhUgSiVRJCoUiFSBEFSioQFkBSKRYSKC kirFgCMIKSCgQRFBFQWf5hAIEkh/UIBAkkP+IQCBJIaYQCBJIIQCBJIf4hAI Ekh/UIBAkkP7wAAAkP+4QCBJIWEAgSSCEAgSSGoAAASG4QCBISH9QgECSQsI BAkkMhAIEkh+hAIEkh/UIBAkkOwgECSQ/zCAQJJD+oQCBJIfyYoKyTKaynBU SkAmiW7MA8CCABP/gC0e0gMLs+8cAAANAAFe29RIApQQgiUUVVKAopKEUCEE kIClSKpQKoAKKAkoEilUAlBSklUVJEqARFUSBQkKUoAFUSFUkoVSQUFAFCig EQCRKgBEJBEQQAqCAoXfMAAegAAAAKDDQgYQz5bcFh4Ae28boSFME3beTSk8 YGgXcE3Ta9e8htIBg9vXeHucF6BRmgfbAAAAA0GnSHuhrgj72D0e0R7ktDQ4 JzypmzqM46bZ3d55tm8e4PDui71VNd0sA6Y9seqt3a8gcd3eOMHkcAAAAB6A ANUePBOj3XepMHhRqevLF1ljWHJnNp5bzTzew8u8I8q7ymeG6UKwbFxrXvcO Yhl5UnvDuEcNocaAAAAAAAoO4cQ8zuPOu973ZhVbzdK7edg9o470Hrre9M6g PD2d6m3hvdnd4cPPNuK53ZBa4JjtZmsXPTOReDgAAH1rQAAAfR3p9mG9vVt6 lpvLvDHhV63BgakBYWPNV24CeurcKB3DB6p27UzricNXXceJ6eABQegAAD6A Nz74bR3hnPau8G2s23HlnSg8AGpsg9PXgng8NvaeNYDC7jjE4Gbpuye3e1vH NmqFXAAAA+gAABpXfRwj7a9TG3kM4ZYmZ6O8I3gevPO4YDwLDs88Hg956XjL 3ph6nu6Xr3qbrygBoA0+gAKBoO99M94PeSGe9t7zD3jFzXTadzS6uDMcvbZe DjdUxOG3tRvGDuDweHnqsneluUg94N0vLe54wd49jb1B6APoBQ0A0BofPUoo Y+7tiW7055J7hu6Vz1Z5V54uuvexF7mDyPOmbmgo7Rea4dwXuAxVTePAAA+g AAArpfYn0fMeuvZ0mFlw3sN56M51uDebuubcN573bbbw1zuhuDd209au3gnj mgnt3eVeeb24F56cwHh51SpIioChVKKKVJCVVCJIFFIJKkpEIJRKIQIgBCKQ AdU/2Mz1VUqUAAGgqn4wKlKKowAANTNqBSlQZAGIGqftIJqlJI0AADT9UQTU lVNMTJiYmEmkgSSlIADJ6m/1/X8/vX+H9sKr+5V2ZHUYEcTTPgG0kkgC75wA AAAAAAAAAAAAAAFVAAVU6047P8d/5Xvnvfe93n1tazRmdttWw7GTm4A81od0 rDmrRmW5D69T3Ebe9J5S9/YSXTnyz777z4Tm6nap4yLIM916bmWSPd4DO2px 4Bi1+vjDvTU0/Qb37tW4digVye1WdwVEfbrHmBDuax4wOchO9mrEXqLFAHA5 wz0m5V1y+tbFO8mJHbNMY8O5lwMCqAbBseSeFZT30+QD8vnnfdf31815XelQ nFCXe3c4Nd0oC3lZce7KMTjdOYpmppjfb2J0b2ZzcmduT8fZghqu1E4tfXO1 eitNVazGk9pgmPgOND7U/LatFBuSpI+wswYEsKzhAzm+NkBQ7s0+7nnQ0+Ku grvHxegdlY6NkW1xtXe7k5urkyLOowucNowHPQ6uGZu7TOlN7Scx5LbaK9PU CdyLoeruMyxzs3C99dfluiLszKXCexbQj2pCPHD5NAAADxbFoBAALzUOt7O6 nXljBuXdEzGpzGPN4h6uhedZ6hg2igs53U8PLaug3tWdxGOGS+urHB0I7UMz s5du5iJAs05PNdstXDhblekjI/ZrVkA5+y4dueHE8Gpkyru7qd3KIOvKU9yh pCTp4mTl3Qbc3YojmZNsUrJyukl+gdjxH9vI+T0H8D6+3PC0eliGn1W7i30W rYcwvDvGsAe09hJ2/e7cJzf8wru/ebPz1dBwwzG2yfrrtxAA+j9GBL6lbN4e w2u5m88F8Znndjt5ABEny7tEjRc5XdEnp15UD2nnc8sRzMyoXMkXt27uP0LY WDE4MxuMye7ymz8bG76DfdNgtdczDwLy9xygLYAgMLzGe7LuNbxXYS6FILtG +tGLjZ5rx0T0GGJ8R7dSYzMy616+ke7MIAxjMwn1ADcQ8tnTRJPPyTxR5hxN PMGF77BARNPr3XakOglcnXX+y93gws1bbu8ifU+kpW4fB5c1Kb0FGwKkIHjN M2rfAidK5l3eHoQBDgyS8Ku9ENzC71BPlsgAOY3lnkidWad3fV+zONfcNdao 6nJbmbReaLptAycV5xLtG9HscpIr1uzuXsMxqyhm+WO5h9nU2loeGYVqNUsz B2PwizO3ZQ480FR3y7BcSwOcfY2yaADe3JnHdfW8iHw3OlaPDoPZ7GzjuIuJ 1G7szMrhvme6r2dFe6em9LtQLJv0eY2kz4/fe2aX9c7m467O91xnpndGssHE 826pANds7tOx9SwlouNcVVPukk2pJKqnfgfk1lF72b3qmzW5d42aSxPFJVhE 9zeZ3doeS30iru6Wzw0/ajZ9+zvO0QW223IvbbaABckhcjl+tpz3fCwok/fN Z9WVXUqmzPpNf495m7J639sc23uXbsloAAAAADnOF7+Y9751y3n3vc689+ne 7gu2gZd1zkkzTeZ3Oj79y/TZc9tKbbdsbcfkmfQ0u1ubuyXLd5bxgwR3TXW1 MJiu01VK2TzzLJJJL+m7upFAANn37czCRQJ+jsknsWnpb3d1sigHp+nMzCd3 L9u7Ul+y7juvZL9u6T247u7VigAAAkkknqvd3WyKLyzd9qRTk/Te5f3cmTDM u5sUAAAAAAD6T377vvd+zP3ry/X7zJZLQAA7OTd3xFt+ttssLyzdrJ39nZd3 1/J9JJLZQAAzoYQAAA7k4nJJv713d2H7f25hsbVU5xbbyTvYL18wBD5pJKN2 W2k/ybmHM2b7md8d3bJaAAAAAB6Pvt+d+3fd/JOZzMy+hvvkbtUdlttLLCW3 QHjQ0gUq1ba287cs2bJLCgUB+zP2fswufd/d4t20AHe96Mz2c4+3ehQeXLe3 23lqFUCgPe8z7v3d79zPtxUloAA/W/pu7qRQ7zh9NjM+43EAAAAAAAAW32xN g1XjliSjKrbavsVACJflpwYB6HCSo3k5rRs+Vrd+j648JP1btto3xI9aK4kj Z+SJxxWlVN2SORt2RyW9nlU8LwC+7hRjawxJRN2W2222gBmZmYAADJ6Tm6SW qWSTZFAH31LsmbvLd326WLbt+3dSRQAAAB+tt9u8SSAAPTk7meJFAfSbmG6i rdv27qSKAH09PZnCaAO++94P0jznBHL1lkjVcklsZjjdiOz3Nyhi30uW3Lbd 3Lc9lQqUSO53GLu7o4O6S1xttK3u5mqcw2rCdht/VsbpfvnOvPKAV8fj8JJJ JAbnu4J3ufNjNEnc9OPeW2gW2TdSTa223bQBj8wErWEJ2kyt2V+xokWtqJ3P sy52xu7+augooAAAB3vegM93st2W7mey2e97wKAAAADMzMw9nePfCK220PXx Itb6Y1wF6ESN2ecj0ZTSZ+Ru7iRQAAAB3vegAAn62butkUAAHJ6c7mSTMwoC 36zd1sjsWR+zMzdtskttttuZbRZIIkMuq5JuaCmHm8OaloADn7d3cmZnNmvS F7ns5jX3Psm+OC7mPfIbI9x6IVbpKEVlczahopgvreRbbtOd3dzPtFt3fsZn DYnt8mYs3EZDGVeTUDBePa0ZySarsloO5u93d+v0skyLABtv1ttqVJJJIAAA AAD1tvpNkrghiF18e5p56vyaVbadltt2SW3bQAAAd73oDnOfhW5n7Gk/SSy2 0AAADMzMwAAAAAAABr92Qe7ydz8x3l33vZ11tigP1ttttAAE3MzCKAFmZjft QBfe9+87e/hdX98SSYjb9u6kjJJWdE33fc+4uIAFns+6nM3FnMU26Zu4iyo4 qaJy7R5XwYttQjVdJCSffKBeWbvy/ud25aC9s3u6kU9F7u/n7TMJFAAAcmye 0W83Ur0nN++0ktBP2ybul5r9vcym3saQVbMsjZHlMd8IZNOyAi1uy0AA8/bu 54Tve9to2fvtzMJFAAD9Nk1+xnv23frzZNoBe9pK7Ks6ndqZctqtqdm3uIcL CUkMHl4b3olHZLbbcG32kkm27u2zmBLXoLFAAt9Z3OusRYoHKxflvraSzq1W HL2m1YsJPRt8asX7FW8oHTic8S8zY1PcB6JuVueYZ8TPULZKZ5iqV5b6qGrq rLHvS94bZDsR9QGWI2qisSKreHjTktIr1JRuy21OTcNkigAbM5Nzr36ts33Z JaACSSSQD6emfvYTQAAAAB+k5eW/b7Ps9lsigelvJJeaPibTuokWNoUqgovX WpDF51c/PN9L3fe3QABmZmYAAAAHM71u7mYClk3M/bvHLM57Ps7mc+zMJAB+ mT7MwkUdnJ36Tsm/TJ9nsJFAAAAA+5M3fc0jLaIcDvQd6neTPvXOzGNpb547 n7r5d91mS9kklUC222m2xh0kv71M1L7iIAvs+5pb2RfSenJa52in0TJdbstq JJPX25bLRUFlXQvo1bbaXZOPhpEkbtMCWqE71PZ7ojbDGuYbd3W2/AKK3aSh a3ZbeYa1JeZ2e7ZJFAB2fSzdZJd3bsA5zgPeBug972773t0AAflttttb8PAD 74c7ed5bbJaDZ7m8zHM/X893uvZUndlGYQSZ0kkkkOgqc973vAH337Ru7mff ZvxbJHJLmSNt3ezpDESczx7KBhCqptlkkjb6b5rQ9tAL9bJKd7uhBM9bLJkW 2xPvpJIH3Pn37skk3YAAAOc4X3k2b9v3vubn26W376UB6LdkkBbtvAcRxDy3 pY0ka3ZefPzr7eRYsbEL5ITFNJlbvN+SSlbstto6Lbrweu+5cxi5+g6ZzG5v onDFp5QcBkEKttttszEkkq7bckkkHkeOqZu7z01mfffe/e2r6y73X32ZFKAg dW3xbfW5nPd5aT8q22gAAZbe222/rbbbQT46AABtvLbbQAAAAD74d46/d5wX nD1pdv0km/pOY6MOx99L3O7zPN1QAAAAAAW8/fR7rwAAAAAdn03Uq8SSRb6y 2ewse6iy1uS2TPDwFBoDs9N9nOSeF239OzeZhIoAAAAAT9fdl+/R+5vmRX5J qRnr5IkyN2W2TzSVqSM4eNiUrclfwA/gLcm7qT1nuZzGYUn76bhFrdlx7pGm RwJSxyWxTElzJFYrbktsMbbd9V6AYLj93Ed4iDe0/E/LdSa/v7763bJzLmZa gAAAABv2tneb7b9F/L9PSOSQIfAFABwBCvtc1NzqJFAUPHhNoXpdzgtuDdmH EWW5HZbbeZW7r9Zvv32w++61lAAAD0+n3um7Nkhc9iOWe24DnMzge9Wo67SS fPr+x7m7vcyWSFTOV7porn77gAD8u7u7qB3skmZIAAD76Nttu21tkWDIYlbt WjQNxEbPTQyrJaAAAA7Nn36fp25+zc8vO95sszMy7sAAC8s3fakUABm/bu7o 9Mndfm4iJJFlpP1s3dbU5JJfq6AdnZu90b59pu63D9zd2bv7d3YkskkkAAAA H6em7uligAZbexe7u2b+u7srclDs5JcvHST4pJUBPODNltttto9P05mPJe73 18TN/Wbuva+l8FH6JtJWySRttN2Wv80SbXyiQUWHhndvbnLqyWgABbyzd832 bZ+kt1abN582t3utAAAADsn5757xAt/Td27zfTxdr3qUB+HvSS973Mv6rbd1 DMzAc5z8Ab+nveM0AttttoABmZmYDMzMwt5bbve992tuZJAAzMzMABI+tttg AAAAAH3wAAAAAL2ze7s317zMJFffBbl5u67kd3fvTdLKAAAHJmz99yZIAW/p u7qRQAP02Td0stD6T9uewkUMaeJK6cc3LtAgh9rzsyQnc7e6W7ZJLtX639JI ttAAAAPk9t9+zePRBH7e7Z1PJE19u6kigAAZmZmALdv27qSLyLPbuJEtttk8 0lhBuXrHK/Pycded+xvofbsX19j7v7f315F/T2Jeb2ZFAAAADvf3ALQH8S/W 2/1v8AAAABzzMzwei0AAAAAAA36ckkkAAAOW227aBGW3tu/ltttn3TwQAPTZ 3d5c36nOe9vru/t/ZmXdsPsuZ7GF23lttpJZ3t7baD6yReiqSNFC7SZGVEVh vLjxdfIValK+4uXB4Z1A0WsJGN27GkFW7LbbSll+tn7u/vXL+3JK7vpdzzM0 AAAAO970AN3e+X7nePSQ8GoGr11SoA2Nt3H616MJ0SHzlSQs1QAAGRbJJ65m QAAOTZ3MJsAAAfpbPry35m/Z897szZFoAAD0nrubzi+5lqSgT1fp2SZsA+3d 3c0cnpvt0sUtLJ9v2ncJFAAAWlkSfuMwkUB+izd3EinJWLvSk6wAQydPJEyL S427Lb5vAjfdm5UV4M9qzN2Pd6d4GrJatMBW1lRkuJtX3PuAAAABkc+kkmS/ pu7qRQFv1nfedYLLQAAAAAAffA7Pp3M4TS1Y2y3cejBBbbHZbF6tHja/IRJL k97fe96SRZaA7OTd3z0zMxaAHp9PszCRQMmSyR6bR2fSzskbZbbbbdetAi14 lGipY4/Y0SJUq81227Lybu4kUAAAABLY4CairBHqSrdlslsb1L2IajGZJaD7 4BblSTsmgAAAJ+tm7rZF++AAAAAAn76bmeJFDszZN3e9vc2ScTvfc3M/czNJ G7OLbaAA++cn6b3jHcu3ZLQAAHps79uX+5j87/b/P6/1y83dTZXJJFloAAAA 73vQH6fpuZhIv05NzL+Q3WyevZ3O4SffKABe2b3dSKJ+XmZlbbVJvOy0a3mM Np25jbrbd9JKGGcQXr4TZFJKWHnJJ25ubtq0wyCKWOwAAP0/TWZxzG89M3vf brMzP3hbJOkzJbX1qRJPW2QQknrSV2Y0S6zUi1ztSsPiaj3GmTwakvonK6iC o89BN38Ul2W22u+ly2t4kkrZ6+cHM9wBmTe2JNLy7hgCKrbSNp1djaF6a7L4 EmpR8ghJHbbbjP3ol999999Psvj4Bb9f0v12ySyb2LezfMt7cx67I3bzZEkI FWa266zSQ3eohVbaUbSjdhfrqSQZMvrpJmHbCRUlI27I7QAAAkk9nuXmZb+f t3Mn7H2POnZhO7161DpzQ1SrPcFEvF8tE6wPu9nJEUq3pmSTbJIk9skktcyS SSAAH62222gAAAAAHFtt22r+tttyL222+t671VbXbbbcxL3RBIcpG5JMz0kg h2zJkPsKeWOed8iTK3ZbbbjkaKrb3ST32KAEkkkgAAAAtttuiLuwU1psJaDs aQrMW06zoNWRI/e2Tdqz8WbuPt+akTzuZzDQts6NRVl3CTH0CWp73RKmN2ef NaTa8SjRVDcfVeR0vU+DAbMbksyNJGt2XXjWk2+oSSWqpBK93ddfJDjI4oAA AByZPv3vnr273vZbbbZmeaNL71D12N2hPHx8q7V7ERbXFAAAbM43d6nK+/zv ltuaHJyb7PEivSTskgAABXwDDvLkipOkmySSWWciKqq7GKH2yjcEOk+Ph6AX vAcmDVZWtRzwGpFWynOcAAAAAettn6R/lZmYAAAAADZnLu69NAPeW3bLJky9 /N3G2SzdSN5G5+vgIfGrmOkUl6Ncoo2+kqUHr8QZW7frbQw+20mquTo1yw+J INbdlvN6f2My2SW/p9GpnN0kUAAAttusPvE2tU+JJNt1psZdoFDS8kkSWgAA AH3wB2fpu05cuvTQAZPSc3STqSekgAAAn703d0sUA/S2dzG+1ZJJJQAJ+yfP ZzLluyKBzN+3fbpebu77UAB6L3d3ER6+sj1snL3HPnjVq31nN1JFB9Nk3NLL QAAAAAdls+z8xkJFAAGzvL5zPAA+npu5qx2Wl62kLWvC6SQDuaQZXfX1j2d2 yW1lt9jLZJoyu2SJNvH5v1VG92V21lFdqU9fQd0OOLvUUQn09livNq2T0zMt SV91b62S0P09N3dLFE/Wzd1sigkkk38m7u2RQJ+9N3dLFAACy9l3v73avM25 PZz0nY0GqXO8hmrewL3bMe2be2voq3bbbbblr9c57zdDh7Js7M9IAA5J7dK9 bJZIZJ1lmc/JBWNtJSmSySRWAO223LaAP3EkmSQCX3XfBQAAAAy2y/W1bQAH 3wPW2+ttAAAOWwP5OHOevqfvmj9ENzMkkfm7pMS6dsPCCeIsSVsrZJiVZtlP gONkMJqV7veqAH3wAAASbP3jdzQW27rnJ2STvOx6+1vjXJfe6AAAASSXvvWN zd7Z+vd3cvzn1W5b6zvD5xdzcXMzMygkkkkAAHOcPc790Fc70LskkkknOPc8 C0MzMzAADO5u93W/fffbORtu160lDdbskE9NwrS8J1QlqN22gAL9Zu7iRQ+k /bns3d/ZnPuzk8znNy9zNlki2WhP1s3dbIoAGTlufN53Ps53wm2gAAAFu2SR bAAAAAC3ZiSaXkkrG7LbbU/Zs7pq4wcek8oklG7ZIhcJNrvO40h6489eUSXK sJb1ece9k/Mm3jd3JIoGfBgAAAANn37czCRdn37czCffRQDZnNzPj7GxLKMD x98D9v0653H7XH5jkiJ7Pl9+fm/d93VdAVbbZJJJW2xgxtwyK63zboG73B2O bskWKAFuWSTcuyTtj9y3M73ttHxcy2+uX9RL9lt7bec4ffWuD8WqSwm9bVVV r1ttySE0DMe83xtz15eABb+u7upPt3fRzmZbd1Jqt3dzQEoAAAAflt+skYPK J+QHAu2y23Rj9vTpDLJsknpJQAAAAAAzOXfv33295bJJaA/SftzMJFABcvN3 dZzbcx+zCW2e9uv057l3c3dtAAAAA731+73GY9u8k66/fc9vrzczjuZ62RQA JmZmEAAAAB+npvv3l9v6e5MvP3d/Sx3bso2HOgAAAAAAcno9u9TWfr3d3utA DJkSdbyLIt+s3rvPWb96cne6toAAAAAAAFuXv1vraoAAAADkWe3bO7u92JO/ r7tCxQAAAAAMmz7d3OXuJuLUkgo3ZbcbJ4XTI2+uOJKhq0kkkk+n6bnsJ7dv d3astA5LZ7dYb6kFOpGi16nWEjXyUbbljlUxLz7E725drudsT/X+vf3zJf5/ r/WAAAAAAPvhs5zZ35k7s2/u51PRJayZL96+tqgxb+vpJFbu77H6vTu6SLbR tztlyy7bcvkiCb58TpNrkkJoDL3Ug2yOkhijltsyRJGt4khbmSebup5jmZYH rbAAAAffB1bctvZ+33N77q+yqdvd9u8aSKAPbds33csktAAAAAd7qO3dtsT8 s3dbH6Tffvr719Y3Ja/a0ehMUd9I0ka3Zbbjxo8bXFD6dh7e974+59xQy29t vIt533vWCCAXsnoo2/N2SSXt0gKVZtDrlt73ehu97/if5Pd2rIoMmySZDvZ+ Pvn4+0YD4++LbKBzk7ut3OotbJDjXqhS5DgyR7Wxw18uy0IHoAkkgJCbG3MJ N1FW2yWvwaSVsdqmJRzV5ybNSrbbbUkkkPvrbbabM53M4TQANm8+zM+xYs3P v2SfM37393q/bX98fvu7TiGt+i9NdWlKEOM1cpLDn2TvvGID8nJJJkHe96If rbbZKAAGW3tttAFkkli9ttoAGz6SSQB9bbbZT6222yjlttu2gAA+cvI66HFt trtvd3W2y5nYvL1KzITLPPEJRvQ3bC/t9d3dskkkixSs3nT9kt3dWOS2CPUq tSSHHDh8yyYp3dybkttAAA+nfvc740AAA++AAGTZ9vyu8ufeksndlkkPujp7 u6G3z80SZXdfAiG2+KlS615V02HC1qPPDyTltttoYfaTa3Zb8nda3+z+k/r+ np3e7vv5aAAAAA+mz9nsJsA+3d3c0AD6T9uewkU+n7nc93t33s7nvNgAAAAA AAA3nuv3M97wZJySLQPpn3u+MKH2+1/m5vSzZeftsXhQfDubVlhUDIGSWxuy 3zLzO2iP0/e3337jblAAHp+nMzCd2/t3dz9n7MzKn292+33NqygBycm+zxIr kWe3cSKAM73oQAF9uY93u+37dk3NLLQemTm7r2W220dd7wFPrbbbPTm5+zta l7OTd3xIoNh1E2tVykZXr3gEhb3dzUBb3m25bQAAH12fTN3iLbznP3e96AAA AAett9bnU7Jt1zkklJJPzd5V/O/bu7odX7Z6Saq22220At/S3mpu5pZQAAAA AAAD9znPS5+zHpe3985636R9nsJFAAAAAAAAHZk+76GXfvetki5Jyd73skgn x0GB4ABmbOSSPyUGrbbbFC73dxr2Tk575kvefe9Hia22F2s8a27La2wZtSng o0pZzdly20ADs+m891+ucTLdJU3P3su5bbaAAbPc2Zxvu2Y2ySB9PTmewzQA AAAADve9Ll39u6mgAAAAP0n7STpS4WoSTEkfaZpNMlTclusPOJtkAZNn3fdd /ets0yW2SNktAAAAEkkkv6ft97bv7n6eep8/buey2RQABJJJIAAC2TI0tFVr fJpeSsvjZ3use0vxF8SbZtAAAOz03e7d/a5xVK2T3ZzCdypJKstA/RZu7iR3 9PddtsloAF+s3dxIp6ZO7ulit/Mk5JNAPp2bz2EigAyfpN3SSMvd3XpoH0tm 5rZFLSyTJIvZ+m7it+nOy0Bk7JvdJLQyf1sk/v6xf4ABJJJIAAHZ+m7qmpPT Xpby8+9eJJMkflOvA+tchQXklvdzk2Wju6XMvsw25aLVd1tg2pK1pVtrHeiI FY5c0ETI22e0br0XH6IDmwEG6Bk7jVXVr2iLeVbYAAD9bXe9AAAAAAAAAAkk kkAAAAAAAAAMzMzAAAAAAAAAAAAAAAAAD+AH8AkkkkAAAAF/Wbu6kemzu9vz k+5JkUAAPpP257CRQADk5N9nZoHrxKjcmuCETROW+ReRVsEL0zVm2+PL0ucL MqW+fBY9DVlxE3xfavbGWJLQF/W222gAAAA5bbe5frTXrvN3eubXb+23woAA Afp+z3vGl5PTfbp3r3dvO6SRLedjcEqUZ4uZ7eTXo2kriSSsj6eaSTQS111J 0+JqlbsrbcQXaTI3YABycm+zxIoXL9u7rPpEv76YTY3ZIpiS06SCK27LZJpi qQvd3VLbvt3GligAAAPT99mZnsn7mZhIo2e5vMwkUAAyfbmYRa73vQAAJ+Wb u4kUAAAAzMzMA2Tk3dLLQ5P0/e76+tuyfrbN3W/fSKAAC0skySKAfTk1nuN1 He96AAAAAAT9k+zMJFHJz9bbZYoAAAAAAAZJu7pJQM/e5zmkcnt+77Y5S27a APfJN3MJKL+5mTa+/dfdvu+bcttttftaPi5Fz4jIs5RSClsc27La2QrUruHz 85I7I+b83fSWx6dUV8mKn3OWlMjVaq6o3Y09WryUu47HNklP1ttttH5attt2 0HQNBOcPAAMzMzADPgwAZN1zkkxBP03fbrqLbZaAH5JJJIJ++m5l/d30+yJ+ E3dbIoW/RrrOYbsbs1+a4m1uyu+KxryNdU9lXuP4rIx1h8gc57OG501+wK+2 B52O3PTue/zjLlqygAv62220P1ttttAJ36vuBAANt5bbmvuSSQAAAAAAAAAA AAB3d3u7v62222gAAB9ySSXmfs59fnJ6X2Zc/Z6m13CrUtqvVVuxtt6234uJ KhoN+0CWxYSZFcaTxsd3dun1SMUbiaTfKLkh4+ziIJjY7VLaaADJX2o8dKS9 u1XpObu2RQE/WzXvdvOT08sin0jNzuZbsnk3MN1aAyT2XlzN7ZtAAJ+tm7rZ FAAPWz13XjtjC7emTD4Mg2NuZGkqm7LbbbII9SrTzzbbbdlttr8GknOfPvWL Rwpe1es7mCW5bbbbaGnyWwrIZtJYmkRBKSN20+4CyKITVxIkZRkb2xyNlvFK 0VU3SSSZdb8uJtbspdkcmN1JJLQAA+++npNzSyAAAPT7Zy4/bw/cz0tk/ffP r9mZ3MAT8ltPGe73taZbaDy2ls9JLRs7zfd++r5hskAAAAGZmZgAAGt3nObu /r6ez7In6kmajd+/FnIstJPvpJJCT76SSQAAAA+/fPwAX7629z2N0WTs5N3f EigA5mZ3Lv1ttp9bbS8q225bQX6S2TNnJtklfW327+bukloAAAAA/MvCSuYs gjbkttD18u6zxMjVuvWhniRQH3wGzeefez159efd/Rcn0z2Mnw8TvY8wHdKt kttttttorfPF3dA90+O8ou3fPTyqcjluSyTm/NySSGSW2225u3xMDuddSl7M enJ0nU5N7khMNRqE8dlJO+231rSTkbbCUTdsnmhd0Tees2N2FYkkrVl3Ekkb ZbbaQ2fSTdgAAAAAAAzP3d3/f97uc7Nn9/fwAAAAAAAAM37d3dAAAAfTs3ns 7mfuZmEjs2SSVZaAAAAAB9J+3PZu83d3vdZqxbFH6T37cZlyyRuySLUACfs7 nxhO767zdqRQPpsm5pqYklW7Lj1okWvlsSyGkNFckuUjcoAAAAAFvrOcftY1 mgAfp+m5mEh++873j8IWgAAAAAB6cnc7e5eXbFoAJ+yfZmEigNnN/bu+JLze hDLL3sSqDkkcttt7u5bvbvnJm293d3u7uWYB3XeKMvn01G5/xJL3l5e97y/8 yEAgH+8khCEkghAgEhD/wASEJJD/6ECASEOSAH+f57/b9vf+c/z/pcTjvx/y 04yNg//znP6uBMi+3C+547zle7RIw/OOjPHY+A6oD0UszDIyPGbo9J4zldp8 dmP9fbfGduJQ41Obnh21vj4XM6l+l7zNGZ0sx+wm3f2DaRe0aK5ZnThWnrmk nm9FhbxUGE7vtMRPHPUtJKJIJaysVFq8lJJPSXp10Npt2DbJK0kkt7hi2ajf BU4DC90lskkq2sN7u7VUsypex7rkKNUJMSxdeFoUJPXL4BeJJLOlYrfXyuWZ 2I+qW2mKNm4klU7ujKMJ2nd63rXUicO2bG8TOy22W7GB0EkfDAu2ELenp23O g4MkXCzgtYsHbLXQLJfSCaTIBvrTozRRgA3d5THZSABG9ndsmR2J73QOZk+f 3vvDn967avoSd3aKp6AXxW23jtNdUeN9BM4nu1aOkR7rZQiTfegGYOQAN8ap 5JSpJO8XfPKztAzuIoTqmznZtS16t9MCpFRGzQB6kgJ9co7VSzq7PJ3KGUj2 7kCPsWvXecDTR0qNsABdyi9S05Ru92d1ttkkkhAAmZLZbYwBa3t5zrCdntA3 p6SNWyTMmSsd6i0BdbDOj6d0fLpp93JbskzEYiZ0Mo1tpNoDmH3dytkcxbsl 7u69l8eJEh8S1d1tIlJpIru3m8Wkk80+Xk/N27jbcXdJIgPaOyzmk+BLRe5x Xat89Xl3hbadHk/TQtsm5OSZJJO1i70J2QAhuVvvFrywXoOt9fa3bk+vodS5 D71+n1oWb2UNgLokGe7ZslNECmKFd3gI4t20DuYm5K41NUmy7FwyiEkjwZJV 4r05uO3dscjloS0pkkRYkklu7Jbu7fJCl4uu0drVdCXIjiVZSsczjs43Mtd7 jb2pBtVnbW3dGd3LkJLwmBjjHV2tS5jD6DlJPOy7t91tHghTm7twWJ7rTJAP t0p5lu7tvj3NII7u2u1Hd0htVionlh1Dtmy2uxIkujGFOsysQudPDnMXW854 ky5tkhiCupKJZiqWx1VvMfm7JJAOdA8jIklY0kpZN3JjCVNVqWLoAOowDppP gq1xLr9cbAEJvJEnkiMGSQlt+AQENvnERKt3USSTQABAsJJKSW7qhvdt9PFt 7jbzLJSO7Mvj0Esjh9G5WfoZ8/okkl5T76222kkeFts1cO33U+t4UeBpOwyc bi3jPNyTMjdkmoVvsw+bu3a3pT3VIr1tqjewb7bu9pNqjtUii06tHb1b0JNI +OrDCmI65LJO7ukhtupPTOC2Nc0SR3KtjsZ908umCk23ug2jhClJIpu15Zsb c7t60Ic7XLZJIr3bPDJHb4XRs3Qkks8YSddUG7qP/LBiv31QAuE937runLs9 z7m1nt7qqm+7u6RlQn3ySQWXkDZcweQSFIfuN697JAvcJllm9ub0VVAHieiL HNUX29d29RsDxF61gsfbrhJXr2dt8+vb7Zf2J6+6swhzWxgmzC4ws877c1+U Xn+7OeFlrO4XrIyRve5Ezm8Q7hiXFW2FTq2KnT3j4ujd/fvAd04Xj09vXcNb DnLzwAFuYBJmYWqq8JbSFtIW0hcXdXXu8vNa9rfHV680QtoeAUCRhmUhbSFt hgKEkQzKQbSHAzMwgpBSCgoCkTSkEg9oaVgsqX4pbm5JtDbbbaYhtIW2B4JF CBmYQtpB529XRd61257prh27zA8AAggEUIAoTDMIMySSIIADde3q5bq69e31 66OJ4AgoBIkQAN2gEzftZl96+5jr2jnJr8laPktsvfRVXqzNpZqV6JXZsJIS SSSSRyS8g8W7NyVMdX9j2tCQkhJJJJJISQkJIElY7d7ZuzblN2tmAAAAAAYv nJF8gkXykkXy2CyZuDN1ZaeVWavlJIvlJIkoRMAYwaQwDvOexGur2CzhtUSl OyHttsXbOnk9L8YOfeoWSpCPwGYhdqvHwoue1YE9Xm0t1Mk6vAQ7H17dTvt8 3O3a4dgEwPV2yrlnjMzV3X84yJ2EzC2s3s7xPK6D2Alakr5b3LEyo0G+F67l d2eUxM3K7uMyaXW0r1bNtsAAbAGxsAAl6zc0yZFVLNi02/L5Mk++++CACSGP 5L74AAGwDfe1eqwrKzZzvV69tMbAAAEADW5az1lTazZ55q9v33JJNoANAgFt CAKEgy6199vNa3rt5rPO+H3nx8ASIgAbaySSILCSKoj7Netzu+X9eX53fzs9 8BEBEe5qc57Tevuy7853rJ974AH12BJEnvtbOd8a3rvd3evuXo++7ILILILB YCzjb++G223vu7fdbeXV7ruueeNzloAgYiTm/r1yuz0zk+xmed58+9WwAA1+ Q6E7HoG9+4Xpp9h3Cw+9JK8Hs62twL2XvJ8JDD19vXSgS8Pn6qN+ijW75Akt +swE+3MeXVuaVtvJlcR71XjabimZN7OnvVec3WAhjfoy2EbGjIxW1bR3DIIk Q3Qathuzb18b6Dk7Z2+Rvzm53fJ9vX3zM899fvrIARHwib7tZylGcqOd4jfD bfJAA2m2m3Y9tW87r951VTqO1HvDdA2SQABs++YffJgvkTYrynWe2iq881HP lwfJgxAmMANUki+RJF8pJF8scUzt0zc7k6kfrjYc84njF5BVVS8qKqqXlNVV UgKpsAGEyA2whsISiafmXcV092RGLoysp1yueo95MA95MA95AAvKIAfvJsBe UQZUNsbAGw55fqCsd44nnEZ7eT5mPmAJgNtgAAAAAAAAAETtK77IraeD6MmO c4+Tx8QANvWTISEhISEr0gyIbBNyEwl7zmXI0vJYZF0pvtis1w+Ii8hc+V5V wEhI5IFMslzLJxEhJ5IkJF5QAxJQ3LXlDcteUlsMy3db0K7ziDOjVBPQLyhu WtSV1q4Qy44Qcy4Qy44RzLhBMy4RzBALxmPM1eF6Sm3ruqXq68xFoq6XTurm Ok9u9456+Rbtq7XHS+la2tJiOqB6kz7U3jG6gSV66hO4d3nP2K69sZkqPktz GfZZD10R+7X2foV6Z5jWMbuaPwZGuq8ZqHivLXzxtpxZzYlhN2SoeX2Hqq7u 36Zm0QvfLqb8uTrwgEAgD4AOZjmY3MzMywCZmYEAxzLCXO7OZ7OM0zyro35e Ze1RJJJJJJJCSSSEkkkkkau7zlMnTpknHn5eXPQAAAAQNgACCKE9Vu76js2v V11T7kb6IGwAABAAAAqMFS7qW487o+NfZ66Hulpb8TMzPEUgpBSCkFILIzWt YQzMwhmZhDMzCGZmAZMykNJ01Xnry56upvy8ucDwffID75AffID75AffKST4 AAAPZN1Xu8ezZ0OfLy5wNAAAAGDADon1e1Xmabm0d0b5cvQfCaabbaaaadXt +ozd7dM6jnx8fOW/KKvKtpbToSDmXAhlxtpdmXfq7Z6urg5PlT9KyuLkiATB DGAmHwH3yYfJgvWRE2ujwoxq31XamcMXsyIhdRczd9RLfXEeMXG9l9nuutMn wu6bSpd78hsfbqoBmd2Ty7c81nibK2/WozJSwcmW+3dn4Y9Xn7dmlLk/A+V7 TVhO70kw83xcDQBwMryPJcL5iekwTx70Wc5WaSzvmBpqPt19mNuZGM8wYfMG CYIBNjbGwWJUpParVZV1Nnq0DfR3HtL5A5PpI/IkUkiYJsW0bTwYgZmOBBSC kFIKIgKm7wgsgy5nHpEat1RtrEvJJtppe8pFMQQQwYmCYfAID0M1ZWU5mHvF fafe06z1toURYrwBo0g0aQbF1J5mRmBEBEG+83fLvub2z3O4TOb9r7XTvogE QGTJmAAhmDSDRpC0aBSxVGkFIauXedPs+5lz7X2L46ex+IKQUgpBQYXtzcl1 1PslydG90yT5FvaV3lbto8W9W+7q9MNmGjfjOT3udO4817q4QtWkGjSFLZ0g pBSCkFIKQUHDKQEC+QgSkUabTzJdbruvN1az3q8vHsXUUUUUXzfiGYZhC3Lh C0zCfAKQUgpBSGNu9+17mt9+vftb536vvt83UW9fQsJ70Zkuj3nqe17U0e5Z tRc6u7zTVa6/GTXSeY+jo8htc3ecs3uN9uromhurHJxw3Xbndt94rXBg7PUp N5w8afWOGF8SlNYhMmcO4Y205i5vpdhNmemk+PeKlSc1hevA8vKTBPSdH6W+ GBmnWEMzHASZqmkhlpIpKqq4mOCKqRrSCWkKWkPe9t3r2982PfvPfD51494g 0pBlEiMFBY6tTTtzhvXOObOe8a8d8ucnRIsWLFBQBYTLQlakKa1mtmeO6N+z fDueunvTTCW0jaVrLdTJmZMmZStStZbllVMV+tm4vCmL3vI+NEMaGNDGNttg KEUhwbrWzm/bc7w77NePex5hBZBZBZPBbSFtIW0hbSFtIW2QusL7hzfK3uz1 58373fsVVVRAWYAAyVCKQ0bzNe+2dum6N373fr9887WQWQWAqpzQAFtAAtW0 z32zl43Rv73dv2ffbu1VcAAtWgAamZTAAUjcQC+Tnetzr3E4u8pfOd526iSS RdhUkkgAPt/Nbmua7vmPXrPbfXz4a2GUR6VZu+y1053b583ezJKfZtHJkeuC ssR/lMM3ezjxmXyMvpma/XwaypOecNa7PRrrdzFs93a/epSDOAElrGPXR6SJ wSYAgtKJVOde6ZA8TxoY3oYwR5N2aUoW+tYWe1w6iVzfu2S50s9qwAEQkkkZ 17Xtb25vV7nO+132veb3hUkkgAIhKqQzE7n25v2mUr6vbzO7nTbbbsAAAAAK H6dS56twv32t/e199x3yS2yFtkLbIW2Qtv3yA+SkkYMPW8Nzs8Q6KxS+fvL3 ZszWDYIBfAfffAAIANik+WrvW+Rfp7kT2a8z07vl85U4gQZmYiIAqq5mGKoi qszLIW2SgCDaEKEuFTmvs332X96c3k1zz3k97ne9QqV73oWvOrTbJ2lcrjOf LaulsKFCiIiBekq7PTnt69fcmvs9zHs+n3OG/gAiPetGLrD4R5mequa/Jv37 1NeT3TllNGMbpTyHlT707L2L3Tpb4LXrz2x7PLk556+jdau889Zmq/bU0CnL tyPEe2YN9lvONu84ngwx2mPcGv2TZ+4Aou6uJs5V2Zw86fa4fOOELvLQrULc 4d0yTgVc5gtj13wFmZ3uXhipuaUDeXK/jvR3NvqVP3t9mZmZmYJxDHEper70 PupDjf0QAAL1ze/uZzU37Puc77d79N87d+APmDYwPm2HwxjGNztwu6PTDzq/ a96b7k6z5a0XcXdrWtaEKNenJm/czup99k3vnnPtd51zUtChd1YoKMqWq9Kh lD6L1+53XX29Pm03XhRyCAUTkFHIKOQUcgo5Bb2XW94hi3fdeeU5ZXZHK0+j kI1IIBROQ+jIRjjjkPgEMf147v1+r2HLKUzO7lXtyVghjSAjkFF8nIKJOQSA QCQCAVdXVunXiNxabWnu51eFWfAJAfAIAAAAAK4le7tvcz2oFlau8p68lcAA AAAAAAB3z2ZYqq4n1bGVX1+BQHnt9nVSbNt7uxlSweE6+Vwa8sfu8mQKd088 GpV4VfXO0rJde9E2/Dwr82O0GWKvMGv3ZHOzyT6DAFrxV7geQePtHtvcXy0t HOkwEgPPMlKbqD5izrM89z3LhvIs/sF00KocYdT8Jzt4du6szMzMgW2QbZC2 yFtIW2QWsLm9QW53a5K57nVyrbJYwAYABPkvWuu5py53suX0WdBiOEl7zc9M tmzzo7Y06ut3rOWoJXuDfO/c+uy9v5DdFfPqv0pDmMXRdjvfvPMzM9nsw7vQ Io9VJr2j09v77O6AsAE81mucntdznNb+7f2/N7muJYAXcsAABawAALuWAEQF 3aIgIgLu0RAAF3LiACEu0g2kG2Qse717313vNcea+ft+PuYQbV8mC+QCBtvg bbk9db7Nvn7K9jm9Xvd7WJ4xtvgeFUSovkyRfKSRbfp71+0DXFieReBMXifc A+l9XNmdumuob5WX2zBjYuSKRfoIr12EB7vsiz3Ld8/B4ghKG/DEisWY0uD0 8r7c0+7PVPoMAi5R6JMIszu4+hqLqE2inzuDgA8aBUzkJBJ7A+nMB+rCoteu Nbvgrz0BjVXPveXtfgPEgAxAAAwA6vbR09G69sg3d7uWqsmJiJuG3Dblt2wG 23JESPPQ943Z21lv1efd3PlveJJJJJJJJJJJJJJAAkV+rdfe9W7KtTXvPy7c AAYMAAAAAJVdt1b9szOq171ru72e0BgwAAAAAAubMVZk7nt3We9i6t7d94AA ADJJF9JGDAAz3U89hu1ZL9T3vZ5begAAAWlJAOX0ja8m215Ntryg3lTMnZeW Ybsd18ir5fKSRfKdVUkqkAqSNwAG0bUp5V7Nk7H73dnKtbbbpgwAYmDHh6ir dZK6q6n73dnIrQBiABgAAMQC+Xy9TpUThnd+qDeeYyadloOdm/t49d8MHr6r Jpe7nVXM8y7w84btNqCxjBJfT117Uq8wyu6OqhvDVamuwib2HgwWCMPb6ocV QhqzZ6GGG4fK8Hm1TfMhdu376cj9aau72IAZyWvucaIx6zxLXxIE/FpUgNmr Mjc9u7W23pJ4i1JZ7FPMypcQWlu7GiSBC/Yru82txnbLOyqZlqy7bcVxtFkn it1PFp9Z2Ccb4kJkPd23zsedlzJKSlCSYVq2Zuz3ZVpGj73kKzMz7198Jlc8 zwQPvj8v75HhPPoHSfa+bumPgH292W28PzuaPjqm3eTHtZxprxXkvotP2JXD XQeIVmve7tZvkCsNID9D1fULJ2Wm+7kQ/LRbmV2+pJKu13EBcdDimjdYPY8A 14j1uvuxzeo82Sd3T1a5JLwnuGBigACqyxtp7xZZ3uVJPDCuGdfSReqdsknl CRMMfQjUSUs8dVqzESLu6623IAAJO3ZZKrL1LYtJN3sTfmW7e7u7u6SSSSRj Z0ey83buiqdlqkhtN5zu4Sgs7yqtjUskzJJe73et7jbjHB73u4rdeK9tqPO0 5ktiSWOm9oLRLY7vcrYMxRLedIG8M3xkSSSlskz0k9us9wtaSSYA93u7g9bS HjVmUk0zJYlFvqc7ZC9S4tPi6N4nu2Y+5c7bT41jwwNuIkkx+zButhdzGBzU Bby7r17n0/RNoz15JUeTjYuvJmedypgbu2zd3wbexJdIW5t9zAkmjYpIw+6M 3LbD3UBABE3OByEp24lsrnn4V/rY5kM5Ekomt69x2HLu242m1dkA7ro2Oc+q 7UVZUsye3ahalM7HmWG93dbk0vzXPW7Yp2TjvkPcJCJMZ9VHJPVtG+NS1Cdg Dk8651A22vh1S7pGXupXCSTunn5yy4AAKliSkKJUn2ffffKdyXU/P7s8YVuF BYOnpbVfNPDT7TwkdyOBbscyage4rwMlOdrvXqbYzJOkq8jptr9aSDjTWiM5 tO1QnX5nqYpZX3XvbFkydjPasdHHw8ANwHkfE8jZDc2Sk6AKQEQgAdsuGR+d kJuJJZknkiau7uV2cMCSASHgAkks7VPZbOuu23Xu2Sb2bMwyYzximpBBO2T4 yfSRJJLyl+tttpJI8csmRfrw4bu29aN2yVzG3nr+83ntzed4rQKH3wc5y2SS fTvO9SW23yk3Z14eG212xK3uiYA5EACtowc4t2SzE3ZO7ulb9KA3rQzcSKJJ YhJfd0dlxKLyrm6B1N22Dura83z3e5XW2h3d0XdBDbZAlqjAAGYo/blCr413 bjHEN55C62KAN3RadUtPd3Tm5fcuJcMbfc296Ijt1Y+Ajd7pjI6aPRSkcdxe Pmhb1PseYPXJ4rUyVKQOInlNsTV5wXcmjExcent9vXRunOwm9kqeR4D2vz7p eYst1dow7t715wveGjV5le5jAJpeNZtWGrHgBdXlsyPnk0bvF4VMbD50zr7c c6aQO4py3T3t2SbRmyjw83vZqqawbEwYAwAYNmHqKt1kqdXU/e9zzlU1gwA/ 1+SkkJGAADDe79l4zzrpUusr371+RuMGGokBNtttMa31Vl7bldXrde93ZyqC +AXyAULaQtpC2kLaBaoinKe32839v7G95VnZPHy8kvKnWKHW4X9XxF/bFa5n u+SJ4KfaHpnfvb/a9m/fvnnsvcZwikFIKT8hUgpBQH19+TPGe9r9rXtPv3su /at0TwCkFIKQUh2+L8P3ve93Pd5332PPst6fBwBSCkFILAUgsLSM+H6dSmze 8ex1veft9QasfJIBfIBfItIW0hbSFtJ+DMpC2kKQgbO/fcaqvu+uSavOr0OR dBsd17CcFWNO7jjswSCyPvJZy3WNBVGA5ymeQ7fTxribT8TZIOz21apOd3Hu L25JxXN4BFyjkyH1u4DbleEazRjM2a83N5e1IZMdhfhLd39uCFd5cz2rJVjy 7NfulbEeSnfn7e38QtpC2kLaQ9mtW22lq3CST7WtZAwhAy/L689+5nuv7PW9 x1x8QtpNySRlykG0tHjVH8EltCBS66877P2v3f2vr3N/aeznQAAP0n79r7ue zgO29+6LV8R1/JeUbKS8qS+XkTtZP1zv3v3zvXtcv1zxBQPwKQUhbSCkFIKQ SVIKQUiHf37m6777O8+3+67Nd1y0/AAoAM6n1o+97X3NZnPfs333vftvjMHw LWBWApBSCkFIPF58+1r6vfezPu/e9s9xzSqqqq8C2gW0h3fc+3u09fY6VZXG zLXyYL5MF8gF8gbVfAW0hbYfiKQUgpBSCkO+w33779nO/ud/bNe09u/vwCCQ UgpBSCkFgZmYDAzKQtpLRFVX4sve4Gvk3YV+Rf2J/jFpzu8tmeGrVnNgjdNW 656Zpzjzb3FUvZy0t2Zndg+UbrvB6upLyPg63IH6+dSmNS97Nv6Pugw3qKwG mMo9YfM+gOOJTpyydAEWx6Y3J15y8od8Z5l90r1clve6RFwns9nqMfUkxNs+ XwC+BtvAb3HylTOebyUR2t+bbbbTWAAAyp7kG+6TdtedLrfi/ySSQRAAAAAA ABnvys9+Df2r5qZ++5d3z9JVVmZkmYAAe379N3793Mv7R+dGc361eWFZBZBY FErUhWQUgqpnfGr33D7PtHzz7Zv3hRfwBFrkkWJCghDh+xfPv18+1PzUz97l pYKK4hCEI+79fub9rnceyd5ua791TYj+kALVRRRRpKWwkkoWKs7yz1d+Z0iu lV9zttttNP8G1SYmqrYAa1mlFdDbCSNoAEtFR1rMERFRFRzLmgABoqtAktoE LaAFtAAbQALd/G9d9z337Wb1s67mvueecxRH8ABatAAtVaAAv7e80RuSSRYB ckkkXGtb1oCoqPDW6cAAEC5QwAB8lAAZrVmAAMiAB3Wj9znAAGIACIACF3vb omwAAUABm96N6mwAEQAGIACb3s3o2Ek7efXz0+o++13szMg370Xg2kO8n35u QjoBdoR3RLfb01Pr1nKTv1pflvZVGMGzxvtGq9kuzaGn5+i0tvHXbXHvrJm9 3mF4BpaypvNY3k3rMA9IBzHOPlJnBADteYx6Yi33VyqZy4aqpDh4VW08tneu dxlHpr9tp+kgOZchmYZmYLUbckDMz5rjlzD7997Hf7DmvOv3e6zf2ujafoSW iiix4DGgLX0kUXyifvx2fn2Ref608yXweXyhHF8oRxfKEcXychElJEMYxmlU A/ve973qL67IDbpXa6on67v6m2/l73vSBLdEDCAYOXDbiW5bcrJezcffYQFl 5v7vbpJISOSSSSSSSSSKSSSTMlDnn3BF0jLfdmDbltttxDcNtttttySSRZc5 xetZvTrutLv1eu4kSAAIGzvvkST5ORMQXpkB3fHur2l/VfXfsqSSZc1JCZcb W0t0W8zMzRNa1rMzP0kkhoAZJJrOfnh39+v7ueM7s6+/a5d+sCHyUR5ejySi F5ANL3kKADyABeAJmQAAANSSS+7vc8vfxnr9mv2rMOzKu5I31QkHIEkkkkgE kku8HXsyn3taerNrvbPaDkVBwd5ScLQje7LRPb03G+fUrlKW7WEd3s6jyOAv pR5rPd197lb+EjYEskvo/TdnvNeHNHT6RZiOb6nPKr1URFHHvLo87d46iPXE Qt8dg6QeybxQY7yHYUrbk9oS2xjrRWfEzqdlczLbczLbbStAAvIAF5AwXllU VXkoiEl6qKKXlG44vwV27JlorX1Hdl55Gb1vckky61pzM0uZrxN7+5znA4Ao EjDfOc5zgG+c5znJ8KQUgpDVpC2kLaQtp3Xe869VVER62wLaQtpDvMvNN1fI BJA22222mneYX3Tu9T6Z7Pua3F1r3eveSAW0JGiIqM5zmc5YdUQ3nOa4ughU JBAdb3rabAAQLVOyohJJKqqqqoqqqgCsSVTd3dryLqrzF8tIV5l3u76XrxV4 66w32eXzSTaS+jOc1znOENZznOc6QUgpKCkFIKQUhbSCwECpBSCgy733veE5 znCj73ve8SSSSSSXqSSAAP73ve8SSWfR1NTyzjuuNRkTddstJtv3kkm20l7w kklVUAABEkkpIABSWZODy293rzp9197X3NevJUzMyVMzMqQZl4AAAzLxqSSS 7AADWrwAFVXoW0hqlAUgpBRJWQWQUOduivu919rj743fs7zSIrgAFoiLAWBc zkd6ureVa+6vYqattptptttxOaznd7nud9z56fb9m5qIgAXJJIuUvxz777Nv 3x7zn2vd3gAFJCsBhQAEQABpAO332uHec3rL031xzl4X7RHKa8LunNTpvpz9 KsHvn5O+XR/D7x6+xpc5t8tGYSXVPbN31WvfJOtvzeNFL22elpr1+c7u81uD WjpkRSyZX4esxFjoB5B5o7jpjkfhkYg4UW0ZchXlJE3O3S0q56x9ePN5bpJ1 blNJJKPQkkhQABLp7nL372fa6/Hjfvte7YSSfABvel1z3u+vdfeC/fTn3b7u fEFIKQUdMOB72cR9rvt++7xPPxv5vtZ7RBSCkFIKQWQRVaBrNOG+/c3zvfs6 J9s39263t1og5SDaQbSDWkEtJaKqzGXznvc57vVPem/Mz7n2ABQBUkkuWe7n 2c+49zh7037t593WAAAd3fNbavenu89zavT09x3etQHy4iA3yc3vhr3d8533 3op2a+5e70BSCt+4YdRtbdjz9fwq2E+/ezgdfpnZ0T6/vLiHs1PK0Jst89O2 VT3O5c5ZTnMULF3eg3HneG5dGvrjkl9Tib/DMF1PljyltteOVrcdKE9dSa4d ne3dYxyasSWbVkPmxroV4c/Oe3d67Pc8aKzVredbJtfZnPahupN5w5zd13Nb Cjurnt0l71e8vLhlkiEUiABw0Z833O/a37M4v2vc+17uJJJcl7c9kZ7Pcr89 aO2n03PKJJJNMABBAAYySTmPL3v3ee+O9Y/fe7fvb3khL5fNDExPB7vr3s0d 4I7u3Ky/HQUVChJFBN3j32+/cebyy/fe39r2+/ETXySGkkrwe3nK+WbFJ3d7 aK3uTaWNVVVtpCoVJXUGBUgpBR4Pvdr9rmnWmPO+92618d+ghIKEEMIB9iIW Tt584PoqJ++3obOvyVxEQr6I3kRWOm/fffZmtbgSfiSyCAAPvJ9e91378b0m eb/cJ6HnDrf0fFah5dL4+D6zHtughfvJoXeQ1zpWRQ48dHx2efpd145Sbhow 5no6W+fj4VlhldSfTQvLd1YMJxSrnhXpPWH0a1zrqkPd3Xb5IxoPQt7270yZ 56dx0Y2nt3D2LNcZ3d5yV33xrZxt+M9v4311u5999bnp+VQkihAGgKFigAKA AiAAoCgSczJgADGSSIgAJUoACIAKADBAJbQBQAEDpp7fx939zfcu3P377rma 8M/AAMQAEKkoAB0DEgUCAoEiEiEihAFABkQANxAAHGgAIgAIgADBAAtoAFYC wkHbz9pgazWEPTL1+/G9fkyX93ZDZdua5eTba8m20l8kklChJJGswwABQAFA AYySRECRQMzDCAIGtawhbSFtIW0hbZpk9Mq795vsKan79+7XUuyuSQfkvioA BPkSMISMAJ73zqsXflfaU5+/exyVw6z75ffSSJEcYwAAAABhjdI5erOJnqJf vc9evrwAACajk9t97m/mL97nPn7XHSqqr0APOZQAuZbbacNVvFHq9fqMndve lvKYAMABgNsNUkny+eJ8qj4s0fe7OJb9Wr5SSL5SC+SAS+QCXwC+QC+QC+QC B3U492N1muZTdXuLTTmd3rzBzwHN3w2cMyOZj9UZIvPb57mSvdOCnd1L41Rx F3Ia1nuCT7H7kAd2tSte7Qlu75YMpyvY1qGSl2vsT31bUOMl6iSTx5Rc7rMJ N3ufcupD7zoPIW7bntzD6Ljh5nJS72Gc/ZQbSFtIW0DFczMVVEVVVzLkAABm ZkREBEGZkqXdr5QvI52w4d60+7c6XU6qXyAWpIgvpJbSQbSDbAbSDaS22826 b9jrv2O/O6J3bxUNbTxgAABkkmpIqqpeTYC8sY3coUPkcRXZM72QyarF5NgL yABeTAF5gNy25cNuZbbbhJJHzfll77t2F0e7YeTqJJKSAAAAAAAAalSz3z6P e7dcz3ZMmp3q+Uki+Uki+UkiUkAEu7PQ+nV6nyrRe4c++Xb9TFyre7HqrDuH 77nZikkkgEUkkkkkckXljLVX3Y9rDuMZ7HnSSSSQkbkcISQkiJIiSLEmKV3Y /KsO4T9b3H6qzMmjMyZmZV5mX4iAy9al6AAiBeavNRABEDWaa1ARAETWtTNR AARGXrUvQKI9AtpBtINpC2kN9zNHP3DXTvOp/fbiKfR4CHDdOiyaieO7ujYK me7oxdAXPy7FmYqq0HGTrPG9fro7Wqmc2rsSVzH4HVyV2VpZmFezJ73HRshc SySzDBIROEs2SXwI7jr9OROX2PsOpz2Cs94IaucukQe3NTbS0cbeW0rdvuK9 BtI1VVV1d7LcwxzKpgS0shaUhWjIWlkLSwN3cdG9/fcemn767vd++LBKWnAA LmGwtMwg5hhDMww+TkIvlJIvlJIvkXMWMu87rx7zMJ4vezvNiAABA2IAAJ6s Ws9g9663S+nmsnXnIAAGAEBgwYK1jNu4Z3bfo7h3GTl2MExMTExgwTEzLzai jMeXvUu9rOO3tepgNpp/NttsqbXzUvft99m/vLX6+9+ngCIIjttTa+bn3fe7 37F8v5vvp4P0qXYAH3MqCj21736939geK3lzaacAYmAAAY/fZV+W93t49F1h vY8P330kAABDGADbb1L6du5P378t67q9zfU/j+P34wf55YNHdJuK5h4Y9LS3 Vzz6c8g9lZ9Rx7nTF6udTmDqjzgzQq+BUZj61KAAjakAs904A5DR27JPQ96C E4IMlvbPOFneKGl5j3RcHgelEkWOTONR8OkSJqJkSU0MeGkgD1XEUMNKeJLD JumpK2Nvh3OLu6W1ySN42GaSDm5MEqy88CfMgd7dPAAlsh4+zNxRjncwt+rc m7slaSSJI2qjH6bLRL4YBnH2DgiLeARPq65gA67p61tt2kA33ZW0My9RwS62 xzJySS6Vsbp5bLJJMy231nuu+69zmW5T15Ide4gR1W3u3fPydKPK0Mqvtnb0 1x8gAA8Po92yTElgGSo3u51+ba3Xz87fX9JL3W0AevrfRK+RJKde4SLXSSlC emrj3ZOY3oQ+r9lzdEZJXd1SSSS9tJuBKGskkzLa203mWQQAVDuwrexWGSpy lvp3Dy9CTVt3JcQFK1OlPSTR3ttmlp0ACLd2STWyzD02utmN1t93qi2uky92 5kkkbk2OcRwm7soslt9SSW0I3YGSohCu002tWydNySXu31ecbe4NTYBIz3up 9uztyvnFIalYMm1JQl8oQ6jVH3e7pKSSM9kgDNVrbzG3vZ3BtJIokmeTJJt6 Jd6RXZ3ZUkEpDHqb7tx8Lm6gUgSjqj9wK8sIWEoyGS1Ge0nWaSdJMo7ohknM gItUeYHdbdSb4N8SOu3o7NK0GECdd3bjvTJJIZMybbbRu29uuXHestIgDcc3 huQAAk2tWFPHjsku3lhswBCmnvZhs6HnSSUt3bLe7utzE8bZ72tjdyNNcL2b R28bAsySC93PbzeZTe59tu9fZ4hLTaZN305LZONk5EzYLbskyH18WUyRk0xR 5jNl5uTuct85l5U1XAF0232E9xy4AO7pIyATFI77csPaagJEnl8gkN1BEkz0 tskbarbeVcZKrNkCQ6dFiHrOU9FPc99Gzrbttsy1tvMXVnHwKmry8t3bZY2p 0VAWbCZpcRZiUvu7Z3pOkTS4Y9w86SfEiLNTXHA0WrD67OtypEJcAAQTxK2Q ySO7IepHraTEl3dyiRGrkEkSSSgsNuiyZktzHbnanjopJO7oUwnjNmkmubUj ZYySScxu222wkkXLbMnafZ6j1zYbu3XY43/mfTx8/vlW/vJ4X9JJbmSTcZNK KAHCSSStjens9dS22v091sTNXcOXb3WTkVEnPFHd2B6dVSqTnd0dkL8dz1xd 7dNEEWnlp80j4xd067s7dg7pXY23Y2273dymQ1KNtW21tuwgATd1+r3F5Yhs hzcDYLtMotXdyXlJJ3d7pJfAd17DRDgO5vnuz06l3vcM72ZeIOVTlfSdt8e5 SAIxVeN9vkfGanh/CiX19o3RuxyIx1qAXk5vC3azMzjZveyg3vmex6995uL3 t2qL1E1uIfsC7dWZl04jl8W7Rj8IcOyyDtPhVGd7u6asO+wVGvesO4nOyUcg +ry5cfj590cctc9MFnKd5/vf5iMIHgT9zHE6X32/ffrzvGvXmzRAK6ERRkRN Hqlz7nPc+17311mfX3DDiKKOgApaAFPZRR+ApbClu+mfHb973ufc7Hb227ya 4oKCiEIvQQRkzMAiA5Ki7peb5aZznu/cvvacv31+5MnNYQERBGTMwgIAjkrU 1mgiACMmXgREREF5LyAiAuYhCfYEQAiNGqIqoiI+zVy8+773c50+b659ee6a PbVfxLaQtpC2kLbC1VwtbcGAADYgYMHFCAAAAAHytshbZBtILUhg5lkLaLVt atrVttLcLmVttttJgkEZKRSCkFIUtIKQUBlDf3d3X3379799nvjrdp9E2ml5 Umh1u1mZqic6joWcI95K4MTma7z3ud19mn2fZj05M2AEEH0njiMi93erd1Eb o3G2mavKZleUzK8pmV5AL5AL5B4AACr63s2/Zj2tuV7yE97c9XciEMPeivcC fbJ7fNHfPKfaifVZoRa/dMvyE42aYannerN095N53rxe9aBhL7dmZ5PeW1Zf ySkD8VRbfZeqNYj2Czfd2d3Vfkh6Y3ZvOHzg62A30H7dOfBmv4z2+3vR6o90 7KkkzgAGMAYxjGMYxjG7QEzs7t8eN9HeqciXUfe973plN+973m3zbblty3Db PNg2223EwsN+3PrvK0qJ2bj5WqM373vJgNttttttttttt4ANgViVVXova+7v tfcR3TzmrWD2rAqtSqiqpeVVVVS8oqqqvJfRVVV15JzVVS8myqpeteu6q6SS S9VVVXA/OjOfv3d33Dr3OuY8/Hdb17ng/RBgR3znObOEkiCAAhvnOc3ySSIg AKAAoADDfOc5vgACMkkRAAQZJI83vewADMzAAMzMAA3rWrboAE22kkklXdNq tr7vvqx7quFUV1zh8kkkGZmQkk9daoW2ABmZgeRQzLJsQQAMzAltkLbIW0hv vS7179+5ffrnHOedfPf0hDiABmUABtkkkltJCUiIEgHyAXySBvc/T07v3r/X 3nKr1+zcVdFtIW0hbSFtIW0hbSFtIfe7rvveC7NyrL5ZspfIBfIBfIBfIBfI BfA223kHiu9Mwk7N7eXuja+SSbAAbkr7mtfavu9d93763p1f0zvM42eXsvgU m96BPVHJeI5LX1K6+Ko8HpXOrCYL+5moDrjtC9lQy+wnhNzUmPNXsfbuO8si 9jnkufL0tG31tp40LOtx34qSd9KnpfaRzNOfe4y5Jy333nz5970PvX7z2r4+ 5ru/R00AtYAAC1gAALWAAIi1gAiCLuwBEBF3aIhttNttsotfKSRfIpXOyu33 bhIdXRmc2QzMwhmZhDMzCGZmBmZbW1gQKCS++GCX0U7u9vVta6rqdGCAXyAX yu7lS7lgAAX3JkQEQBlywAALuXFSWqoVUvv2vfd7097SpW3ywm/IAAAAAAAA Dr1733732XvLrNc305cFFFFFisJEYQBGADN+3rm893277t1rut95c0KKKKLM cwIFxoSWime1t1z3fb1nsus1zpuXCEKCEIQrm9R9ec+79rWdaz7etuCxkFCL J2trINsg2wt0a9rNZ7fXU86Jmq0wBA2YklJIkl9JGDACJSSfL776/XdXnr9P ZVVWXqxODBgAACBsAHJ2vvS8611s8iuxVt24801ZwLuav3Ok4vLFabWNdMd5 inYYTat1Cq+7MEmHG4G9eSI0PmDvVIewLsXbvjq5Y1jvkunL0lzBfekh60Ah WYdRJJxn10vOs7ZO9fNe90fTZ1LxunOJm7Vb7fddepwrLdarTgDCIIUvk2vk 2QUgpBTQCkFIKQUgpBSJrnuG9+77Ws669mrs7w0GwCpBSCkFKhJFN63vfMmZ zL1zTXOvsAKlSipQBL2vf332pmca3N8399oAD9KQC+QC+QC+V25nd1KTIVdO u3py+QBC2haqwILAkFVecd5999hmby65jrp6JrABgwAAAAx7Z6z0keVidZ5+ 2gAAAGxABJIpJPllGe9mO0TJVQ72NjBtuZlzDcS3y8SAvKRgvIAF5AAvKQBe UTkTnZw3bkog7OjK5JOVTCSSA23EkkgbbcWhvVfQm7renX3TiqqrgBLaAWqO t7OP73YdNbBEa2Ve5evPzXns9LmPNBzUfY8mees9Mfq/NL84niENuMW92XXs yUpKPLOso297Z3YYul7QLfsTMMLe8t7BZ6ePnP0lJzpx1Tbmsj3uSIF25nkU pis1ecP5uRbvlCn0yje7OQ3LJugA7jKC+TgQQAM33V67ve+5euc3u+vnQA+l gd++3zf3b129a1fd9znzoiA22221bqG0bd3sKyq3feG2knWSD2q3WOybrZ3V 5VERWTQ5WuqnWW3exub6FERERA+51rfJ9M7t3Xdc+TnYAiI5wAAvMwAADMzA ggCNTl77rmr5vXHOb+399993sEBARmZkREABmXhAEQRzLiqIrmKuDaQtaQts hfu8d6zb9ndvNcpzz92fcIUtIUtIUtKVFCBTXM17Vp9k17l65rU69977aiEb kn3wgSQihAIBAIrC7ywUThV69x96zySoGs5Jkvb6evsA1+svrM9notubbX6F /kJX0mmV9DNMF9vF+x55Xjh64vU7Rzsc53j+hKnb54JtOWeiLYmZP1ok4XVT M30zvYSALPyQeN9ZwDi92br73dsFy0eTntHAT28sGXnbm19vPW9BADGhjKSI 5PlJGhjGMYK6zyr2x3pWKvs3xz3zGhBQSSEkk5JUVVL5DYLygAXk2wXl2PM3 e1QKWRtaK+iYt9q8gAXgBtttttttttttttuS8x7W1H7PZ7zvYt8+eTykgSSE kkSUkfvJtteTba99HkA/eTbfvJzFmcRMz0H7PS9u/t9+NnvkpJJJISSfgbbb bxhfv01P16/evXNO9R8AeuwLlVUl2XRCSHvt73b9op1/fucNl8+4/BJICyST aABUACKAEkUAILIEItJaVCSaC1mVdwCTL97WZn3280+9zvb3DnuupPpIMqQU LBEkUbKEANggALCQA7pz5O+z2HG/a3x5effE+UjV4u22+68zTdms73yj+Cn+ RfMKuPqwndH7sE6UuO1yrerurzKTmvUW4G9zxblXmj+LK7N52U4H1ztmvZ7D CMaRiq5ydg450z1O4Vu68k0DZ5Y5fVgKTyrv6Q28O00zufPOA7rp/Anyzj0v CwFefUcqPVzJ1zLuratfeg8cT1HC/xjsDAgvR5zx7ePe8328vU773tKKqkKC AbfTlvub+1DO63N8r7dgAKq+5fdzuC+7zvOndTvve0qrgW0hbSFpSFpSFpSD WkM7vvrt8893neHprv2dQAACZzfe66t99znefTXfvvtqsWQWQWSQ57nvZnnb 73O79M53up4ikFIKQUgpBQHe+67nU7nu9zx5133tEoCkFIKQUhzOa33N5xPe Ob7M3z2qQUjKKQUgpD6/sUVVRFGZmEEBERe/u/fteY7+5zvP3pv73t7v5VVV EVXMzFgZlIW0hbQtczMzMux+to8mMpPtiDPpF7W/fP1me61nYMu+0YwMk8Bm TJmukqd3nms6nnBOVTTOV4Ytez2J+oWIo07mqa9jI9wvYu3RmnUcVN9LxIdr vsk2YrAe5BobjvtwAkC38UHleXpYjXJXua693VBc5Gvs73fVu+993n09q33v fbggAiQ3vl17Xnye+993p6ffe5qRZBSajCwRIKQUgpBSCkLVVa1VaS2kLaQt pC2kLaQtoFtaqqqqoLWAAEu7lS7uVLu5Uv7Pe3nV58+ra9d6vequ3BAc5BDI knIp981IfMPl5OOQkG0R1eZx0vK5re908Pt3fWZCOffMhEmQQCAQ02382yvP Z2eeP2vfZ32Z9rX3vvRRRRY8CiQYkGmvk018pgZOynoP2Xvus6PO9mLV8mnK iwMqXYHs127dz29fO5zftdtr333PUAAJiAYAgXbKUkq+ot56r9fk3d5vHY5v bw3W2CAG2DSIGPxADg0Be/Eknu7gAAFeNeTjB7MyFXnuCsvffa7VVVZvWtSq qta1rMzMRA4AEQtYAAF3aACIC7vN893b67fb5z773OW576d4sAAiLuWBEAC1 xARAC1xBttsbb0GxffBsu8MqvX033ry/erzReXazsQ8XZIZl70rOXYx1jOW+ T37eMpeTfgMJ3jjno4873XVr9ivFaq1TnJsdIT7he1YB2e2csixy+kxW04b+ 6+y5ANvHKErPxYaF8j4EzONy9ZnHHmOerQ27vvN8e4pjs7x5t+nTr9UM3pOb bbYDbbbacJ6nfdMyRldfFGG9O1NNtttpDh2DedUb2d01Ab6+++xq037Q33R8 GGX3OIfvZvfe++5fNr5VmlwtWtg873ryZl83neyoVSIIAAAQAAAgAASVJg3f t+vLeg72+6ilH72rW27ASBtNxIBUwMykM96b7zWca/a++eyv3u8aQbSDaQbS DchWo2jfgLcMIZmGRkYkXz+TuL18tu49vuhij72je6vkKSL5RTMIYWlEHHEk kWQAltLaWlL93avsfgfsvvVSA97RPWIaAQMQmNtDQCAQeSFudmYte+3ukWv1 e3KRnksAAUABgmZhDDMwhhmYQwzMIYQkzMwBgJAM+oAKVgAVqAJTClTBmZeq 63VhSxc032uqvVN1RBAlOxKZfT13PbwzX5uY/DPRU8lvrC2yXlb272XO9cWz 2LQdhtHUcmr0hHoc3duPM3NOhJ31AZWSPJP3RaGNPncWb+xokQLPBYlMXTbX aE9/W70oYHh45l2Z42Tt7zfgnb3h970vrVAhjKX0ik+QlFCEQTMwhcMyFCRQ gIZTMIZhmEKZmAYAGIAImWT8CGaH78c6X2HN/v3dV93t+bZClpCttggAJLSk EayDSy0tpAAto2zTq++46o/V29Xh+0rsdACAQCATY2CkkQSSSKh1PXzes3e6 Q03OedJJ8kklJJJJJI5IEhJCSSSXRnY9Fld2dcZ7dDnNS25bctvySSlt/Lyg Bi8gAXoSXlEJL0eABeQALyABeT+tZFPqionNz74cx25WQfJNsbfkkke95tvy TbkbbbbbbbbbPJe8oSSS5ziuflWRsqyv37S/aONrfpIJFIKQUgpBSCiTXySk gAHySSAA+SSQAH6SSSMNb06PH7Srzevs+0vZzS1IVqQrWA2yC1A+hFCQccQE CQUIAsIEPgAGba+PuP617rf79r4qaOapCBMH56e5trzW/e12ujmqSSfp5kkk kud7wbNzT7/Jq/ow5rJz7iP72W19PHcE2st7aQg75qwp+PjxOzRXvXsFvsXb D2bSaFek3fHnaw8TUFVTE2uHM3Kte+3iemqFFa4Mut8Yua4d755l2yDzqq3c H6Vn20vcwF17mhb0Xb5pBZumK8e0BoSz1EsJhUlkhF5wxJDunREkKttI5aHv Zrb323ZTeS5sDqACkSSZJSTZrfi1X6gye5mpKmEjcyo+EuHBKTsrYABiieDt dHqbb2Ekg3d21tt2o+J1hWjvayPNagBg8JdZUiqX4+ojfbNk6SWWtW9fAyXR m5Kstp93dsG9ugRNbupK++hN4+trA4Y38phi6Qk7u/ed09be5CnE4tvde7hx ABWW9fdOyye7Oo6vxIGZfXMqU8Sak7QALIiQq53EBLdA7oDbg0XXFw42xt93 u5xJJJXCJhEvd3Fi2cklurrtYwCHdCww+oqrJUvN8GpbOamoPgMI9TjAqxXd fQnxJNpAAckb6ACbknbI3NbEhNtpaaSXdXqTj6Xd27tkkjkkAsJq3RbGeYNU nrJIu6Rvs3CVbW1LJ6N291vdKgk9K72+2k9vTvdYI7YoltLUvdzfiTh73Hp7 M31lcezZKgOwWniI7duvcbrHSasXg0SC4dEfN6Q7esnopNl7bXIlSIMObsl9 48gV3HiV4gEd2GdEHuHhCtSrpP4zogySZc8zrg0bs7PRMclsrvdbT5Uhtqeb RMIvleoN2jOiRL5w3NNkw6q0fH2YT61pVDZenc3YrLKTskEdSUbJ0DZI2525 xksqpNyF1r1l7U0GMAEJJPnuySre7uvupJI3ckjlOTNS7u7MSsnkb1prI5n1 7tW7XIEbjSzz2013uO6B5vuoc9I1fWwS0dJD6+DJnDQJJ6Vvcbnd0m7sOG9q Xd3ZiTmZbaAALJGgMgmGXbrh6nRGbj2nNS4aUgBJbLHiFO052LXpVjAr6PmV oPk4YGq36zwzrvu+P333y++++ttbfm3zlySQq6lFUtx9vQrd9zADVrMVck7c 2HnxtrRGgOSUm+PuLJaKWJVtyXFm22opJHu7iT2BKRSRRZLRcy2ttt7uvmiS e7idODAEx4ZnrQl6W3Mtlyzu6i7u2rKlVd5lRzaWFLWSSTmNy2221JJLyvW2 53ezBfDjudTax3WMsmq+bjmh2e5pOtu5JJu6FZAwp07qZbVW7ey77uJNF9ZH Q1Rw3kaCLECp03w3JLVU3O7o7AKIAFndq7vcE0gSN7usKEoYfm33PyJ891w8 Xx12PzzHJbZI+7u9AgBIXsmyPmrzOkkzd2WXL6JFLJCDuGd3SABX/Mf33dJO p9JI1w/3Qjnj3m3knvV6wk973BUEo/O3j2bOm3B7Rd4Z4nFmQ50KWhekGPvR 92um+6m8Vm9PG+wfng6q+pXjvYZeyPs0Xd1+O5OK1RqG8OE/Xb25fYZx06t9 mELi3b7Yq7wE/apwfcJv6LHvl5EGD8QTMeQ9b3WlayGQaPOuZdzt2W5c2GK0 4uyt4iHd/y95eXl7wjunljipnua399vddc1SQ+GAIABKySSMCICSSu94/Xx8 e217r73DvOdQMho8OEKWkKWkKWkKXWELhSDzenxzovdb37m9dedunxQwmYUh qlIJlIUtIUBfIQJIH800CjflLXtq5693TJ7GqBAIBAD+BiGMYGpJJQUuxTyl vyvb1HrsdZs98MAaGAgEAuSSSKUAAtKABGtAA8IAAkzm0d/HT4e71ft6r3nv HYH0kkcwuAACAkgOYUg1pC0sx3BSRKi5psMAFkzCyS0pAlop3vF+N+PjvM+5 2vN/M599CHW/wAAGs01oAAI1mmaAIiINZprUN3d2WAAAABdW7u2ADABgAwAA l2XdgIGwABA2IGy6t3dgMAGvUVDXlSm+RccozKtOjoLebkC8oblr2XEtta4N y4Qtxwg5lykUgpBSCkFIKAzLSFtIY74vjmvGt53mX3OV1zvKQtpYFSChFkFk HVIV972Zm5gYcowwM7cpGMX3EaViOJ5hd4QY99pGjxWYvK6vVJr3N626FO6+ c7UPxZqd+l5k9fp6ErVmUb7LpZfQ1zXC7y1rIvO0N295O/ttveukHez1Pk/x aF7ar1sSyLvY6zH7Mvs2DCd3IbanZ9ztfb5Pr1vPb+trl94ABUkkA1M++nMf DzXL7fCuuX3NEtpC2kLbatGirZNq1qlTMe45W9nEkJJJJJJJJJIm3Lb8vJOZ cJe88vejUNsvrmWVnXybdtwMzMIY5lIY5lIZlkLaEbSDbObNfdPrfGfL01z3 zbSQlagdCTMzA+SkgwYukbgGZmdtcpl1nY7q99wwBAMTAPzkTEyl+ynyf7k/ 1OY7z3AAAAAMGDeAas7y8qh1vtUVX3WBqSX0kiSUkAAAAAAxX3vLo6nKdOmt /fb6EJmZgTMy28cIW0hbSFtPkAvkAvl0zvLkScvW8+qyeSBtsSCkLaTSGZSF tIW0hbSFO1XV+9m8mKYrLu7vxvV7Y9VnFd3mSLORJm48Vx1S0Vdp7FdbFevs 5ytdTkUJvawcp4t7v+chX2xwPN9ua3x5fY/qG7erM/EfgJszgLppma+9uYi2 KhmfiJkPpYJA3eBvsqqW6v3h8N+beb+uujr8O8NWO4xjGtawCtYBK1rUtta1 re8ed7q7ynre6WrdxjQAxjGAJj8BJJJJNrd097KN0NcVBXmyOSCSSUckkkmZ QxzKQxzKEkxzLIZmYQz3e99muae6GaUrd+oXyjkPko4AAB/ElJIvlBteTlte Tba8pcRud3RI75XGIg7l5NvCOYtW8G5hDLmEMzMA8lx3gqqAC8ZgRAAfcZzs 77Lx6a3fa9N68RARAZi8ipLxcqLXKTGJMabTabTddfvdWlHaGVstb7WmxRYS 479317j7tu+XRvviHQkEQgnREgiBgCkFIUtIKQUgpEnu916+5zee7weZzu+6 77pBSCkFEn8HDh33V76v3bdb5m+/fQKKQtpBSCkFIKQUQqQUgpBSDkkkUA97 PO5EDEsODbGMa3e5R/lr4a9GV3Tcv3DGWp3fX8O0p6/LlV9krPTt6A/FoeEc BEyB0wvX38W2swar8aOGdnt3Toicnwbo0z9y9kiJ7fNP2hpCd+YEzpMsF4zZ mi61dwjjT9Oz7bl8tl74McmvYT3Nd79X7CIItYRAAXdgEQEWuIAALuwAALuw AALuwAC9S9Xfe69mvtPy73zO+PEhCkhFAYEO275nvcdmkVeWYYLySVMMwAxz E1VszISSS5JDfO87y97m+avOG7znd90E0ApBSCkFIKQUjIZzturvfNcNd263 edebAA4QiCkFIKQUgsBSHXe93uZze87vXL3u9WBVrRVUltFAtpao9kJG0LV3 p7vb3Wt5runuu9yiIqr9RjYBfyS3XW669dTNmab6XiSX0kA5fOZkC3MIW5hB zMIZmYQuZgFufQCfAAAAAAAQfeunWfXf2nuc33O+znOKIiKrAC61kknzkAGI YIEwYV3Z711WRjdjzx16E8wM8XoVd3jDd3w8H5HcfnO9CuPClmqtfPuGnHTe p0N9uAFRGTHZ83ltR9Ked9nez26cCTN75SZtY0gq+G5atJA4a+xvPyTSneYE zpMsF4tQYIunqyK/rjo/BsF3pLn6n2qtM/S2DBgwAA6SSSAakvlmvrncqyPd zS89WakvnI/km2QtshbQNAKQUg5lwjArjIMPvgQbd46269ZnsWab6WEkh/JI ebTXQEgU7zufe3rW/q/a6c7n3T4ABngFAoACVIIyUABlSCwKEBQktI0ABiAA oADEABEgSMEABkEAUAjECCgREABhBgERAAYgAEUkkkWSST97OXvjet/tex/b 0dvOE0BFhPosiQlnrd/d0b336vPvHT170+AABQAIoQIM1VXCpSWlQlQrYABb vGsntb697e+aX3vb0AABd2AABd2AABd2AABd2AABd2ACS0qEqEkCanR5EF5M bu4teYvIWXSJultRWRm1a7zkOCkFIKQaUg1obSbuvc17bvu9ndPu6PXs5wg0 paCIopsGtCSAm0fvU/X3rM5m5O7Hzk97ila0zmvZwN429vt0Eyfn2HPBGTbg AZjdl6Z3eW7N8pkR3XOqtfjY5/P3stl+o1z84h3Ml8i793Ow5sXgJr7BMuMy 7ODlgiGZ4iZDMNhgHtkdNfX0TuO598sWy7JveQHNfsft82ezvWKooIxY/gGl IWlIru76tbp1tdH2Uve3WuXyYxfIEL5AiVdwhQQnnO653WnL3nre5vJvO/V2 ISIhQQhObnL3tzf23ed3d/Z3uszlcighCEIQn1tafdb5vfdPuy9G85OIEKCg hRretfc3n21913H3e705nu9RSkJsFIKQUgpBSCwUJJKlZd1a0gdW425rXrj3 ve9yfGZextrNvtHlZHJfL5FSzPa/U9uYPtuXJ7kj+CH4EkkQqQUhrj37Xnf4 19nMf3fb05nPviCkFIW0iED5UVERFVIoABAQAAARv0LNeqicVOqiqrLIsmZK ZjXb0mBkp7FzirapmT9sWJFZ6AneV6q9s7VqvTM7b2vq9Ooen9998mvunc87 PbpwJP5/c3NHdPdw04xx7NomDkPJVKd4O3bcJZffpTOYHr4fP0v33IMynJ4t j4ZZozNll9+9iQUguSx3IFDKdz3e7503z77Hz1bzfukOOEG0hbSDaQ4Pd917 zvud9r7fteW37136cZMykEtC1VoNpBtIW0hbYxSCkFIKQUiZr6658+1vXu+8 q6/etm7di+QC+TSV21enkbux+2/UvHW/Wvl8lfihzseehuvr3nTNcXNNP+Uw DMzIECTMuVLu5UJUJPyppzGd37v3Od3399n373tr93V/oURF/lfpUCCkFILA Uho3+9++7h7rz3nmP73sb9MSa+VZTB37oG1vpJhfES9bvrV/dWnujogmzffs 33qKJrg6hV9dP4rSu0aKHvtsunnP2TPcPJyKYYunrnpbZ6lNcEKI6R1GhZM0 DrF3d45i3F/fMeW3k877OMJTzf37xpvpRNUHrCax/epO69TpZXaLyyaTaTt2 06i9gxHu7zXvn6CIO/bu8yb36fvtXu+b166qqJu7sAAAAAAIAABUrer9y59t 5z29/e3rXN+v24BwUgsIVADMTMoIBfJgvkAvkwXyYJBNx5ddrw9d9DF67fps giBUqqhJUhGs9y3F+2996+Y593X3rRBEAlUOTnr79rvefQ7Mi8X73Xg22msB gAwZCSGVmYsnZ537ql1rfmdckiBsAGMEzzI2CSSVPem7MlHr8bPdMlPYaCSS TY2AAIGxA2AK/ZxtzrcxT3PYFvo5S+kgAAFSRLnxhMo63yHfuwlhOfmANSqu w1Lu5UvNb9zfMXPbel/ezmtX3WwC2kKkdAAIgAaAKgEZckkmwAu7AAASSSa+ UcXU0YDzWNVEw+m6X2zvTneI4b6neJxpuTAenl7UbwPGuYrJ2XOyqbmWdzAf l7X99D5Gc+77O9m5pwL5z503Dbq4Ljl8INeboGbk8PF+5KsXlha6MKY4J1nf nDz93jh+dy7F59Bdfn96RfBxHeuDYAAF3YAAF3YAAF3YAAF3aoSqAKtlhDZv M7eOtPx0zvfd1rvu/bJsFIKQUgpBSCkEANSQRANgpBSCkSTzlvdbb9z1bv7O c3vM+8BnFVbefIOe1L3E+t6jevKom9FqaeL4G2wL9Dep96cnPrbz19v57XQM kkq7uJIGxfAL5AL5AL5VdD3u5+MLc9WnvsOaIW0hbQLVWgAWqgCve97s++On OXt5r2ZfP2dVektpC2yaIpBZUJUzMyVCVCUrgI3veaiACIjMvIgAAzMwAATI L5Gwytbmdy32lkzy4y18gF8gbbbDLsmte1zPfc9PucvfdOTf3tToAB8a367P t/Pb37POd3vMv3Q2BIoHEgpBSCkFIKQtoMCslIpBSCkLaQUgoDP5Fii41FFF FFCEIWtCEIQhRCOfc+5MeCLPEr4OgnxXHvMd28Qx3fGXm5lxD0FbfZMcrTnh AlvC9K+t4Y9ez2Zu2hhVxY/zsFdc9ewfQ1CblqzLzZ37ZzWPo8Azs33c/buW m5z7cxtMXvMC3Q5VSeeZFji6eIWfQZ998/vte++M+u5rcDPGb77v8JAoIQC7 sCIALuwAALuwAAL3VRuqkjOOs7r7mvv1918X3Ttxznv3vEUgpBSCwFIKAx1p vM4fcLv1+6tz2Uv2uh67DUkkl2A5ml3nfcme9G+6zWfXrzoAAHed5e+3d+v3 3Gdzd/fa+92fAAAb7z7s1fJ72/pr77rn28u/OlDYCkFIKQUhy893e9+ft+M0 e92+e0852vk2vmvubfvPDwUszlN1d7ZdUzvVAAAAAAAAGB1kiZt8q7nhjnrc O9sAAG/Npp0kgF8gF8srjCKZinl5adIM2+94XyAXyAXyAXwJ2yJgvkAvkwXy uFLaqqcmbeZ5307cnaFL+a9VrYzKvaWHWr19w8yY9OPVMDGATefkLET0g3MW 97LlzwMwY+7E8a88nMctK6ltXLqWrnpMe5ueBDAiqHe7PdlzhlzTw3S89pfn KW1zvS1AAepax7e30gx5A5OJbSk9WW9aSKxC188xruWMSxkp1cwA4t7Pbl9P GGg62RmGABGVvySXe7k3J3m3LuZbWy0AAz7rwEmZI7fdhnezSgdw22elmdub ttkcklZ8SiB5Wmd4AXgPCUlC1fjzrY2bPTpbZbh223xg29q7nmFuAdr4jt9u JIru7pNU6bt9Y6OwBujTtaPPRq3T4O7t6SryJJXi3N2QAEgADyWSe22N+mbh NJO7etW6uvkTb5SWHiDYgHW5LfElwAW7vtzivRydvJdgS9eL3d1mVlttRCld tG9ncnh23n5tt9u2Ud3XQCKV3QTY6KrbPQ4uMlayKeHt7IAb7CrQfEi9yFtp tk68aUB2iSBZNbqO+kAgAlk0JW293Zm2tpN2ABkzM6RkESRJ1vhSH+M2Qnrb Wy7aPW23u6bsSqW6f1vDtZO12+rqSSsUbGty+M57707G84oXnOHu9feFmTfH N19Ie8Ba0kn5pIrEmvJKwkmSTMttt91b3m+VPhdi12ZbmKrCSR3z2sK7uvMq D494LtSJJJclu4OmQXw6gACoXrI771nJzklC2m5meKO7s7XrvHfvjfqbNbO6 vdX52Tu7puiS2lzbBT1tsgAviSQBImVzMjuOAPdsl8rbb4XzfOB6LoQWZXbt 7tvgie9dKzn256wM6TVm+tHlIw9FIBKz1SSS317ts7ugui5xIKS62pZLvZh5 ZmGSkSI+E5XIOnpawAygF0PQR1vbsm9sh7uj/Ep9zZJBfbyFm7tDwAWjqAnC 5Jk3VvR3TaSO7V18t23FGQeW+5zztbjbatkmZzktodVSejulrxHwhEOdFWOi hV/3731b+n1M99W35+vH21AXrR57uhWyPKAN7eSKoAIs2vkorJj2cLX3huda Cbu+0yEmknHqSIi1Fq2em5JepXJKbqSTTjeKPuSsb4+OORsNPmO7uAApAAhI HLYyd0M5fWTLYNsluYrdF1Crd4rCSbgHXxUgvSI1t1JJLMkttttqSSXlbbu9 njnr45bUBtlkw+JIeY3JN3ZPTzbNJuG2d3S2SR7s52ZJJXN3dus2gRyCzJ2v t2o8Os1ppqKlNaNLen92StKtvu7m5JSNEyQZvPtc0FqExgdacwleV8tfOHtc 9ngdl8/EpKuNvugl1daXZerbbZJJOPX6TM4QDZJqEbC5+2f79MUt+Wpb3cj7 776QAAek7u7d2W93X17j4C3MttBJJvq7b/d3C/q0eKlB9czmX9CLTi4txk7N 2qpic3cn1mybUQKd9wwCk9kknhiWH1u9YkRdjfQkrec8L7URR6SSds/0qjyY 7X2592jt44Un9Pm5vd093nm+edVMWb7kaxrzO5eSlCO8V3E5FmXz/eX6/Zzb 8L3Z5b5WMfsrz3v4hbSFtIW1Wiqqu/ud7hfnWd1ZnJ+kXhZj45yMAAdACBsd qzbtTy8r2p1+u630bGxAAAgbAA6b3e8X9la+7O++fZeZf33O2WAQQbvl+5rR nOGvHq31X2jY5GiKqvi5rFVgZlIYburlvvdNePDvmtdfYtshbZAD75AffID5 AAAAA59VRS/eXl5eLNofrocAAAOkgNiA+SA++QC+VqcQm9OVcvIM9Mu36gS+ A++QC+TY/vmAANiABWWOnM9q1aUTMNbbT+SCFSU1o1vt9nY1zOI7nL0RBEyS 15AAvKQBeTYC8n0zY+myLcPKHqy6k2VhhUOuuK9dCi8HMpbe77fWbJLG8PkF N53t2IPuOHdXl18gBCJ3Kbnfn6W3+Hj9+cjIy3WZve/bvhST30WvZH6rxM8N VY3y7o3ljBeWUTvTu8Ae36z6I+7ftiX1fK1Dm7U4sJB2vIAF5AAlVVQEUkkk kkckAlBTLzTFe48uStq5bTltVRXRINoELcLl1hvnb063WmPcyoxNNtttuwAh dloebNWYzfNa65m1FRUR/2BtINpDu9bt77fTfu3OXutvMOeIW0g2zaqwzKQ5 c1czAkhI0kOQXykI18pjpFb6vahOsmjy0W4XokcTL+GxeWAHkvebbbctuW3J JtQqr3wYt+1t5WXVMAAAG2HyQwALrblbqwvU08G8wqMGB8B98gJC2hFCKEUI szu9cu+5edKO95ebyWKCpVYKBAAETbuXrvHd52XOauc3c0IgACgAAYj31IYO ZSGDmUhg3KYNy4ZlLLXm3LXk9dvbqn800zNNvSvVRz5cZM8UJolRHI9mfsWA kJvbsi25r8vx3gXW0bps5rAO1a1r92zd3m33f3zPlV8M2buDt09wSdnwppg5 d0/d2LIOz1PjPclWN8vdNTdO4vcYQPUfP31uRXJVnP2Dd1bzutftHtSUikFI LIXMwgpBQE0iiRprWEMMzCGGZgGGZS2lttwhmZhC57fbmeLwtbvK+N33tzaK qqt1KlJtJVVRfKSRfIJEmONNjAAAuymTPeV+YVCnc1+fy+QCX3yGMAAK2qpB QQCER7Z495VkJLmWe8MPkkkAAAxMQACCslHnpN9cRZT07nqqqqtCS2hAaPd5 rx2+89MNNo03zbaabe5Mzw/ej3YnQZermvl55jzvPGtrq3V8X3oHRbZQUJIo ADDbYEGRdyXYZdgAAXdqqqon1queuDAxIKQUMu5J6q2XyztvFRUwKbbbbbbb arQvVdZuT2YBq3ffvYwLcR1SFtVTE/2eY1FCAdtYQl7dzvXN9wJTyTjs7LhG P19CnT7qhXB+zkvY8fnHxLrPZv3xX35KrvbubMBfz+5cnx3qYAPHc886Z2ep ebPYkUN849bd3kMt6Z495c/ELt+hybnzr2blICz2nuswNrAAYCwJFYCyEBSG dzq95zneF3bu6u8ZCAsgpCAoCwAFVYACwAGdddveczunWczNb2eVVoBbQCWq qrmYYqqihmUEABJBIKQUiJBSCgyQtpJK1IVqQtsLawALW2b53M33ntzWu8JW DAAECBDfySb+SXzeRXmzM3KVNzjrcCCwIqwAFURXYQltCXpmm7u0nCnMlW22 6aAGNAIBAIBBW5NMzdpZYUBLcYz8kIkXyfySmLmELjmGAKBIyYXMIYWkKZmE MKie55mu9wx4afF1jHYAfIAMmGWTAkgoQEzGgf0In7DWEMwzCGwANaNa0AAw MMpKXZJS6AA/fZ9+5rib/azMt5mjP1LwAClREoAHJALjQkwADMKSSWiiq4+t 77N+/Ye1e76OsHckkpYjQAKVWKqxVXcecB+wi2n6/Yr+iuYqz1wMM1ZT4r1H Ub7V7gcRLkPHek3XdnhpOmUFmSLyoWLR6HNAsJ916ex/3xqP6v577dPdgLr+ WqcNv7dg6YlMHXFm32IxjVk65rd28ZRg8M1eHhufVnftvoLHRJp9FMObnu/M QxMaHXyCMaGwbGmy0t2uo3tz7fDVzjmH2yFuXCDcuEMuOEGuYQzDMgUEDf32 a+5987N6dPrdEFIKQUgpBSKEUIRnvZv3fedntOnlpDuzLzNm0bUZCmEk7nbm 9vdi1ZBcb5Lz25rc3YtOy41eS9SSSWxVbebuzq2ovYWU9+28LW1jtfLG7oy9 LW1j1W/lbbbYiTs6NrapubeKQKN1UqsCdQQoe70cxTDFQqLmb7yuHm+eYuJW dV16vbjfEeGGLLhS9bc9GRm/VZ4iFX0L4ehVZX3zy6k7rme7ue8sLGowV5zM gPZmzObpiHKjtyKbSyh/vU/3syy/YS1l5w6TTbbbbaI9brh3js7m3mlXoAFq qtAAtWgSS2gdbm9d47O5t5pRUV6ABbQALd2mAAWjbvp3ro7m3Oqn4C0pC0pC 0pPAKBIzMKQtKQtLgSCyAgwgZgp73cc1rvLw9ou2AAoopJpvc6O+8O5xySCy HN3O7Omm87w7yA2yFtkKz1zMzMLWNpJbbaz26vU5b9WugAAAEDZ+cGAGyV7V 76j24tvwAAAAAAAAGXV2623Pvub53Pru7hCEIQgY999v23NXNHr4rK9n3Zhw 3uk8sppzfdOoHTiFV3jk8TmbJvdZYWEq/Fi1zM0XRxxxMUvvdnl+L9+WaNTc /DGY7xb367wknfQWm4LNGWHU983zGxt0GMj16vfau/S+K999P29/vr/axzje c5Pv3ZCBQUQhHem9989vM9w2eRRBEBFWKKKOe17nnt8c1w2eRRREFFX+AS0h a0hvXue5b45nD7h98QpaQpbApaS14ES0ITmGIoou9c35fbd6/uR6KKKEIQoJ 3NZl86vmcnZnYQhCKLwg2kG0hbZPhl1vvl35N69rhe8IW0hbQpVVVVe9N91q 863ucLxfF7jWtjWlpRrWtjW4Dcbhnt94vvOezfHuuiNaNaNaNb4h8Zp0YQbj cINxuEGjSDRuggKBEDW/cX776uvtcLwfEGjRooxH4ABojTTTEkkkxNNPv3uk u4rtPf2qqrpkzNIHZ8xc0OpUDdPmN5oeyJmT8SeeT1VRqVQkNMjzPKjzL2ei zYKB3W1Xf4sfvjy+wb7NmFOv7kmN2id3ieHLC5oyzx0tIcsshub1NPL06+G+ 0r0C+nvhe6uOtpzP2uHMRVRH+hJGijQAKWwClRRR93fdr7zvXdZw5piIKPgA KVFFFH2jN9vva13OG+GvAADQUURBoADSgAJVaABovH3u+d+zpvprwAFKirQA BrGySSe1mzeG7AOlqSSSUygilewbmLUkkkKEkgUJAUIRCCAChAFCRJDmGupz VBtWmklqSSXs9e0nW5FvS1ftSSBiAAiAA/1AAv9+ux99++1dftcOch8QeKQU aEdDjr7xe79en3vk8rFW269F+79+5te3f1kVt23k3xbudROWV4IN6m30+Zsu IVIy83FtOpFvRjMWIq3t5mJ+6ivXsqzro7gwx5T++Yq+/bxz333H6v29m1eS Hvge7d9ryLjmZEXvtoxdqH1jA3J4ge4s+yzvqc+F+6dfvThHkOfFxiLbBgwA Bg2IGF4YsWbWqTcvLfp1egDAABgMuSSSSSQr0892t7edazSJmKbbf4vJe8AJ tzMtttttw25lkARwsrr7Pvirw1xkxbbb1tyvJw8pDHMpDHMpDHMpDHMpDHMo Y5mvW1m3uzpWdqrFsaNtttttttttptzM9vWEgEk698aW9nhNpnscXQkkk6eJ I7gQCQSQASSSSSSSSSSSSWTR51zNjpYzXYwSQCSSSdJJIAA4ADgAMYNsCWFH NYX2bBFFdhF517QAAAAAAAAAAAAAAHPHXXjNuXq68WG7mSQAAAAAABeSSSkn Gepz29MM9h3o8vcAA+A+SbA++QH3yb++TaTbfJrwVKyYWvHpl/dOyvXl2dHa 2nFvdw6kqN05KaCrW4tWWTXZzrvJqYntBcbyr1fHFvQ57R4UAdceHwv9+3tz 422v36E/P9vbKtyTyDMtX2sXvNcAcQkHu27TAYu/ZGu8QvEXvoc+1VPJ4b7z pc4/v33w9NqvwSS2haq2W22wM3f3vVIZEjY/aVlMGajP3vbviIjilCx7sdri 4vpM2re9C7dUWsfkvengi83qUi7u8MEla+7edYn7Ov0pdN1lr5Tq13r7ez3Z L7PLN5vy2hgxsTBjYg5JJKSMM5ttvtV1u57xkK93re71MW1fm22wALzWtAAA ZmtaAAAzNa0AAEazWaIiIANazAACIzNXdrtd3Pubc17vud2S+vPD3o/bQAAA AHJIkiXyXwSJfKEA7sV+3e3u2X155bNXD2Uw5SSEMzMJxDWawhlzDAK4yDaQ Wsggvla+nW7d9tKeHXvVwrg9UBdpnF87v1Zw8n0Txw9mw9Ht5jVSp5Rw2dI6 m5bW9095d5ZVyj6IHrcPX91bbfj6sXsuqHQOAer3eQY8uTDauvLWe5GIDjTn ey+bv+/CnekqpPzGn7gkxOoHJbHbt3Jctr553OeZdLilzErmK97e61Kpux62 4Kl4jsmi0ZHfAtnM4kkklp55tt7rEltPprWYkZVirSKS6dBN/SQNU2EDwZnX dHT1XrZnb25ttkUb9UqVmt22QA4TAdBthbhqXj6WyTbtvW2y25ltsz2XH4W8 92cYKSO08ZJzMAHS/6xcKz5/XPk+9wHdQXVEemyRPd2RIb7Tmhizt1yVKvck w7IbPAVp7ZZ4BcF7Vey22vEklZLhBJ67dFbzEXOZC7HfiIs0nurwIY+U97uL r3nGenr7Ekkk4G3xPd3XcTx1puzMk2d1I7rs9NdAl6p2trd1CytCT3e3w7pb m4ud7u6gAS22cu6ddveaRJQ7pTdtlpJPKqXGZU72bm7bjaTW66I96dbbY75J Kt+tkhJJmd0uCJIC2pJOS/ra7cA+TZ2EBdsGZOdExPMbed3ct7uDNjZvZ3ON 9GvK63yncobXe7utHBk0UI8sIJBkLzyjfbvNpBKtJHEeWsDpJElJPXdfW51v rrd8KM8J1o7D4IBclyS7tHAEjiaskKNyzecyQkk0zLuXekkAAFtbate77Unu uNtBsJHik4pCekURJgd7Mjs3Ji1U1iDklZHCkkd1Wecj6ADrJIPbskRAkiQ3 QS/WYrwFl8qlnhhCpt7teIePXAbN3bl9Z6RpTXMC7c9RCyq89mLTlo9NLG3n CwAA8cV7iZ3HewhDJI367DlsBJRLSOXybNpHX0l7OYYWEBl7iVtXXso60Dum hp8ymVqS6vMlfd0tkZWIl+Bwu/bsnXBzZvvsPfJb7d4gBOyIIzwTMbEsYRt2 dRfI8LCYo1D45bVh8ZE3Jba2/OzKtAtGXXJdtfmwJ4cFqVfRJJSPEko8y+c5 rRBDoi10AXxJx6o2wkt9vJJ227u22pJJBgBFFnFI4/DQrpcJbhJMSAAAHgKB xFPhSQmjmFuwd1FteXbb6Lb1p3dn7uMMuJNRu823FXEkksyS2222pJKcnnTM fX8Ezl3qKJg7pKSWHEFmKS+kkSrbzG7e970otrvelDdp73P3vmfHl/Xx3GdP Xu1GgCzTIt1gNjFoZ6pu+qt7u622txECQ745BwhHA4AADu7akSJqvXiOkt4Y AKq15G1yOXb3Hhm231du3G0kAyfHE7bj2LziNeDFZZMde4zFsJh7u4m2yEkk yd3dKAOvcQJ3evetzJGKAI8t7BGNLXr3Z1XiFIB57u+Ra4oDN67i9MEo5AU9 nju+GI417WM5td1y+4mYVtBDjI2d+2g4/QZoF7JfZvkp/nzrX7Wc+zbtbmav innd19usTPGPNs6G7gis1xURPQrdnLL6OdVdIoWi+nF9Ps963fd72e/ZL7Pb pvUxbZ8gAuSIGwYMHyXyTBL759jeSs9nvV1+V3R7hipgAA3vXz3N+9zT3vb3 3W89b681uLpBtIW0hUgpBSCid4ezX199v77efb9zvb36tJ8AAmhSCkFIOvZm 53nvvd7zXuc1zntPd62QbSDaQtpaIqq7J3nHfc73Wc33Xe9um6ch4JC5Qg1V bEkkmNNptN7ntbu99eVe3k3HlAUfBCgIiL+z7c393f3J9rnN6zu+3prIesGD AAY2JkbqZSmZZuXW3eKW7msEAxAgAGDMckl5izbvNsrcy9zSmU9uQkhJJFJC SQJJJJJJJ15fnZ0Vu83Ypxiw3gmoIi23FuJvdjucILzw4+OHW36Re6du0H0c xLaLgirPownwzVs7CKn3qlv30rX5Ney53d1wGM/Fd3bcz26w8BTzYLq3U50z 1xN6CGRHfM9tZ71Jzs+FMvT77VjffKENIJMZujXckkkkkn5JJKSAAAAAWe02 s9WyzbyqvVTRtAAAAAAAAAKtunnc3zu+75ze+Znac0AAHZKku7qVWtNOZ3Xe 63eu85ttzszsRAbRB3Wtb7ne83zN973e7ztSuteCEtsC1RFVVbirTzr0v2jm 3eWZo6puFz75SEa+UkwJmZhDMzJDMzJDMzIMzLmjj13vOc7blbl3Zi1Mq7xJ JKVVOSMkkkCRwk7ezugzu4JubmI82zrRA0vc3DEV7uAcNgAQMAYS2DGwJAAH l7F21V7lu6oG89Ea6u2wEDMS96pqqpLyVVVVMtikBgA2xAFJL3svHC26VvMK ky7qLyY2StxJVVVQAAAAEADbAAEANtmQn2HSDz2Tld1si7zlirmF1GOx+Kzf O6oZ5Zkq3BuVe7S60ebjJvme8ZuKmq4/KeCfummFhWD0ZtdaI+js3OyGvmnc TeL53lXkDerYb2kZmYIbM39ufRdk9twoM0IOdHc9nod308dXvn7M3z6X36v3 pft1b5DHfqvW5AIBFJAIEjkikkJPJZq09c32e9MtZm+prPTfLybYLygAXk2A vIGC8gAXkJVOzFzYY6JdnJ9m4/fvaz4Jh8mQUuXbm4lySSX9kkkp3jOnurit xZtmwCvL5Nr5dzrd7932u6znOd1e5bdeIKQUgsPEUgpBSCkFIW0Bl0qqudN5 rOd17vDfeXmFbpRFVHYADRG7O73vDm9d7zfW5dpeBr1VV5AQQmfbXz7f2+77 u873emzYH6SLuckJUJUJUCCkFIJcpC2kLaQtpC2kdPbszd9V3WMmVNtRjbbb aesAAA033e6xou8X9BnJnnQ0161v6fqvcYPZ65N39iI8/PB2TgV3nb7uyhaZ cqF8sVJNyyWs/p+t9LCfB+2Kv2/v21zjb9NrRq4iW5tre2rzY/JA+3zVz2nb dtnNl36HrcR7reaEdZXQehfb8TR98b2ffd7j3y1gEG05l28rAAAAAAAAAEVm 5hWyO9vKJUy/tlgFtttttttk3Cpj273NtbZKpU7jaabYCabYBDZZm5tbe2bU qtI9sAGDGH9JJJEk++++++kgAESX0kn33yX1XCvLZsqqfpu07a2xgATNS6NS SSdVVHkgA8l711VVVVVVTKqrSSSsDYuWY7vbtRJlVEYy6llVUBRFBVN0DAN9 73vFUVIMcsBsE2XtxNsd1dEa8RGcWd7yVFVQAVVVVAwJYEgAAwCUglk+RuRR V115l1HDzLuCKdaHl7ybA95Lqp1QwBjEOWVQyJlkAUl4AF6vKI9C8lTieyLn WBHN4RcOO2nEt8ve82D95tv3k237yctpI970eGNeTcuPeUy35KG8vk5hFvau kc7ysts197ybBu/qteRVFUvKCqql5AFUvKaqqpeQFVS8qqqqkpqqqYjcmgPh 8bphzPd5FBF832bJug/TEgIOHQDGcMmaKsI6EcrzxHO6u9zeTzs6ZqWmYIns mYXL/KfaplzJMq0d/md7AM7vbxVn90P1mLBwr0DtrKtsIu4a8ncdVnYcXdma Z1Vxb8nH4tz+b7juPy66COdO/SM87jp9e10tsxKpqqpeU1VVS8qoqqXkMqqX kFVVLyiqqqXkyome7bfOd42xWOBlDO5sGIGxsQAAAPfY8z3r3NvbIZVOPd9/ SSkjAAoAYMAAPTtd+6qyrohdV7ZbH4AAAAAAAADJ7Hjzcz1Zd1VtN+AAAAAA AuSAWove883Mr1XmVPsfgAAAAKYhJAj74Pm++261r7vPrzfc0yvkIQhO3cIQ jaPY5uer0q8lOY15ptOxAIBAIBAIBAL3o57dr0q8lOY16xAI+QI++LSyFpZC 0pC0shaWQtLadt9mM9u+JRGU/aIBAIBAIBAIBALd33vTJ8IdrSt29PHJ+Sx2 kJn9mN8HriB8BABiBwHM8eb5S04asOeCHguw4zWlMXtpfc+FoC73FT+++Lzf fXs207vs3d9oq9IfopMHdfLupueTt1D90ua84Zrj6a93rjLCHk2btc5QZ3vt l3zvxPZ9lvvxLIU+0QCAQCDopJFJIpJFJIpJF3vdjuenZeZWUvdkQ45GKKSI BPogBQ20KRobaCABw9NzZCmRd0sud4kAhsHLCAAAGwAYABABaGu3enKuyour 7OBtgAGwqqqPeTbZC8pkD3lLA95MYe8hge8pkD3a5JzebLIy7nrfEMBth7wA e8gA95AGpIiI1rWtQAABrWs1AAAGtazUAAATWtamgAALlfZ7n33r5q83fOb9 7UAAAZl5AARAzMyqjMySrvMlRknwSSSRyEkpZXHe7C6yW+zEX3SSSNtttttt tttNu2OYnugy953VEZdqt1Wlo22tpa29JJLcwjmYQ0a9ne+zMunu7kzzYAAf a2239WJ+97JRWPcu74AW0CENBBAUgpBSCkFIKRJmUALVVdahJMzMAMygEtvf Z5BPX62XYR3hxvEjdPl6RjRH2rWIci9mCGac9yx5Bx8MbkPkezmN13Zivwd8 s++tKNMG+fj9x31Io7CkXvtF0549HefNhed6uyvAtri0IlStx+i6+YiM29Wj OdCFBIWC31Gt9ufc8mNi/b8L9vJPubNcAARCSREAAZt73d5rmt8095s0cAAQ +aABaI+Peznb3N70+5s17oADVoAFqiIrQAG+7b7ne3Ocfc2e30AAtaAAoADE AAYgBPe15znc5nOafc2e6ADEABEABmhTnH3u+17Nc0973hnnwADWgAWilAAt ixVsgWxfe763O+17Odd4Z5FWm1b0kUCIk1VUpwIyEczPe8QnplVu3eUvDI04 SJJJSIiCCCRSEkkepfOqI5Cr2Z6r9K33o/ee3HlfAAfAIBAJgmIQIQIt5t57 1X7PR+WeWLmipbplcWtGtEtKW0bY1tXXvMyWXsGQco6KJe9Xn7ZietzF4Pdc G4Se2HeGDO3Tq6SqZEhvVbJS/HNidXXdeRmY4Cl7g+6+yDrbv332F5PL45PZ vswcfV++FhZl5LO71TZ5S2DsCa7noOyDtN+Ju84hTyx9mD/TXlcp+vu/bV/s PeXk6sQAHwACA+Af33yGIBAIovM96Vfvep5fk7wATNhJJJJIgiCQk/F6QBeW XFbWV3Fdc7qvZq85eTbBeRIC8hge8/KPMYLyGB7z8lEeUIGClQkgYLyPm15N tryL2+va++Lu8mMFcX9+XykkUIAmJiBsGDBKreKbfsOvc/b6X7jkwBjbaabb dWoS87qvr97z0vdEtpC2y1VVFhwGSsoACCAAyoTf281zz93Wvu17c7n3LIW2 aFIKQUgpBSCkFHMpCtSwAG2SBbQJbQALJWBQAErIKSgAoAM3lt373vJ0+9rf TfmQUmgFIKQUgpBrSCkSfQjiqzRCCpeVxrGn2i0zFDrhauhKUluzL7tOeYpb rF1+Uryjy7sjM3r17nfkWC7j6Z6ftio2vL9HK6GnV3Y+qkI5W3QLq2eszMeh 03IM8o6X5FCmKZyi4y7l457eNA5vXV73c6XP17ekFFRUlru9q969ujm0EKK1 bp50q3mE8S5Mp+bOdlxZvmujuvpz6Vf2w/rKvRZ9mqJrT30ehehK1F5W417v Ojm+n2yKfSRL0vfc+9n3edHN9NEIGYZJW5W5mol6vWlSS+TaS+aQ3uzZnhd7 ceondetZk7j1Wme96JfN/L5fRpl3nvWd5t4XO+9cNwCJBSCkFIKQUgoMDg87 z1Oc3wc773oQ4KrJJFUR99n2b3c+5tyXn332/gADa5d67K324LazET21NAAA QNgDBAmIZdrAolSi1NZLLJFCvzRTllw8hw8cdns3nR00d7s3twEoylcMyTGr TFNrFHB3Q7y9ymNFbdVL0VXXdLeull58Ac4F4SO2qvnxX7DnQ9hMerB4K4/u J8vo4yOeRHfDFqrlTgX3ZvTjH911UfU7WM73uCqqqroAltALcAM7rnucpvTs vO+7v1AhbQAGjQIW0CWrRtINpIFtJIfva+93ndfL3pe/e9vnsIXMw+UJF8oS IIgATEwBC6e7vefq881Pe9l6BaSSUkiSSTkTGDGhjQgSiFOJJcGl9rRd7Dzt 3Mz2pJehwnCmJyUxxqW2VK1qXCZhjgBlMbt+z7n3Pe0b4PPufbnWpUrVaq2l ZUrUAQ0JoZ0m+93prvdRve9ax80MY0BRa1LbK1LbLlz1NGguOnRqBJrd9lev Nrl7Ub25ax6nHHFBSDaGRoHjmEq44YQq44YB/QFBYGGnWl1AWRQEDejbs0Qq 5lcgaIpD9vf2/v3faN868zv72+vXxmiCkFIKQUBmtFdDmUwrTGuNVqUStGpc C5gm0MU186uvd71q91b3vV97zBoTGhNVo1KWyjUo1KJWjGvZ3e9/ZmfXmHd0 97VLmPL3rZdrd9qtS1LfBuHfUA2mdGR6cMi7wGAlibN880GyXXbuCuDFgLs7 FkqHb3lbBdjzQMMruvdJ7l18ZTruBu+FMxE69QM3PNroYTZ+Q64JhLlurbes lUSRLJ15yydu6QYdkfjI8SHUkuQl0mbiSI90kihOklwAAbuN5lD9SqBQh3cS kSSYm8xlvQ5cyCZkU3XN2WptrRnBnEbwk3VRJ4mo+PC+LSpHMUy5t93bs4nr aXXZAlW9nO89cJ0jtsWtCU+sSyJbW03q5Qw0/5d996Z33Zcn331xsMEUw83N Xa++dpP3YZMup4A/KQgvJITpPHd0T7ctnA60Zxru7sXigVgWZHL7Pd1tn7cN 7w0SoZlvsy+geE3xtpIJPOdGmu08jwDHsyqEnGLq7Oc5SxIe7GCd3QoiScGv hnUd3dZ5i0mwKJTt2KAdvtHW6u152yRwtxKTp267SvFKbj0DARwtzV7nd7Nv Zs2RNcxy0912WRzN0LI50cNJPSQhWud2+3etuySSPZsyS0WW240km62wKSZj 4eWtjlHXJJLbeu5bb3+78Jn0fBL2odvZ98B0mZ9NyvHZWo5nSpLp3NjxSTAA bi0xG+7VEt3ZAM7qctsLcbrZbslHgKgAjEkvJoa4w2rNrbZqlykR83fMATxP eyCYgYXhEc9MZ3QOYJAFfoyNQk3krDkJJDd9f2RPuHi9u3uPvsbned1nFOyz MZhVz6rlm3sxtvZz2SJPtLs7jQaBuWlTE9Yg6QpXaACC0lzTzO42vXzt6M+S tsJkgNhPizpJ4HDHd3b6+1pG6UMGnNzVNaKrG699b3rYwBDK8zu1vPY6/bt6 3vdm5OA6Rue3RV1vT0jOFQO9d82bcyJJnNI2RV45u7JN2dl7u62eUmyQddYr TAuZHbQAAkkgAMwNXZn933fe7rA/qfQj5vfbvLsbt211twsrAXLW+TnPoJ5E m7SX4LVP107IvItp2WONuZJfQvETtGVu25VmLYNEFLBhJTc6y9JIZcuXtMms XdPSRtpJHESTT7WfFyyXdtBJJPgSBwBPm0T4u2TlnhvS0RRtiEkyNJHxJ8ES Skk0l4YVnO3t22jZHuwz0cZIoOy9nUzUieRlsiVbcSSSzJLbbbakogvIT2Od vlkEgAAl61cVgt9WvQkmISz1txbbb2ttlpgAC3sttrXnOe+7DUabaJraGrZQ YliViqVS0eRGTJO8XVDr7u6y2tyPERCeIGy2kERkHHKSSDj7u12rrDCaWa25 6OyGSduymhEi3oniSq7uoXrfSh+ArLPiLkUb5yNLV3Iu2QASJd09SRRiXb17 dtuZtd7hgFvq7UPbtVV4qPF2uXBI88jFPhe91FX5z0ObF4QUiC8EM7AeqecZ teV0ZDrKo7MRbael2U3/UVm7o9fiyYz9PuOb7HGjLazKxAgI63PZlOeOWuKS ty8716687VzbnCwYbt6rdMbzrt3JdLWrfhc89j/Xfuft9OXhzn7h1FGhIUtC FKirGJGc+7Nzu/u6vv3c7ucQhCEIQjVL7vN757ucecHmue5x6jaVD9BSCwMp jgMhUhoNUxwgpBSCkFIKQQxMQihFIOBJPYa537Nb+57Xd8561jVN8MjGQGo4 xjAQ0zM72X3hbdo3PVjTBDGMBAITQ2xjGMtZ7bzvdNfjFuFvgQxjGMYxjGJj /skyEXygpF8v21e77qRixGZF2cvlByL4uOYQbnrr8RSCkFIKQUgoDKb0Q0GG ZhBSCkFIKQUg4ZRsWPve+/c/b37OPeGX7D5WIgxFFEEoiPR1O9w07JrFk120 u1S4bpJMgD3vL4lNtFL5kc+QRxJxxjGMmV19vXdde9PX3vt/PBqLWta1rahA UJE7yhtdcz2daohrF578KXHKyFGOZ2HOmKQOyA8YPblnDbM6XKXOs2h3b44a 9tWEy/WEbZWbVRc3mv389WPc09lIA7OOJ66uX2E7PTO0nhJizvU9h5ZUvSHE 99Qbxp9Aevkd1Q9nzi9GL9U2HxxLz3v7wGAEUAUADV7zu+ns33g87v1nELJJ EFve71z3ubL3pec96BtdhrOe373Ob1eXvR77OaLfwBbQCZcoWqqqrRvq97tu ss3U971N78gF8gF8mvhsM1OBORRTh797EbsKYp6V7VDpzMzMzMwuSSS7Hb4+ n2X9t7307v3vczmgAANetzfu67Pvdv33r977QBkl3cqSXuZmZm2dsFcijFup jRmZ73ju1ms6PGULAexUfjrgnErOxaQ+MrWrAbnsB3usHAPTLsuULXh0rrnj ml5Grj7sd2cMzNagDvjueEv04w89a+8D3uGj7TNj15v52+5cynD0KfVxlqsT 6V1C94WSuyGXanjy4MyL9sWd37jsqZ3v2ndxe8vrS+TQh5AllBQknfvu957v M+97n2r99rpsBSCkFIKQWH8wqQUgpDnPvfc59vD9znv3m/fe2eBSCkFIKQUg pBKkFhwgpBSCkFIKQtoMDzW7J6wa7etFEWpObnKlWRrRnv3o/RyL1vtlM5ia V+88zPZ7Bq80lK+0JWrjft+xRERVV+CEtoRzvvHt8+8Z9vtve7N823YgbAPy SkkXyckXyCRfJyRfL3b73t/fvyov3Tfds09D8vk5IvgjABMYYl98SRL5IIA9 T73r/Zqn69PdzzH3dra2xakFrIW2QtpD4HMuEFILAUgpBSDmW32znuafPHVK c1mvd+npuby71/uoivy1Yj89vfOcfIrnxwhzRZNtCvHOVIfWQpE9Q7vHw3Mz ecczGpzRuvKOq7XKxELrT2btW7dd8zSm5Xe9tKbzCZ2W+Welc8yXS3jl12SF Ij559Kz6cjjfsT3Vev7ru52jSJlpL3pbaXySJIldUAAAAAvblvvap16X7uMm nqAAAYMABiBhH6pW9Kvr3zvOIn800226SSQCSSCNbPZvFX19fsGqq+khbYSW 6AC9oANFVznOX2c59v7f3PZmdiOLgAzcZl4EREAJd5ue5eb+199v3b7r0QBB BmZkQARBmZgRBEBmZhEAAZl5AREQRmXheQGOXNd5eafb57l5eUdAQbQgDaEL REVfvbzOb113j7W/fXne+HwCkFIKQUgpBSJXnN++u/D7fPuXl5J8qfJvd3vS s697DDPkqS++bS+SUT1ZI8lMDMxjBi/TztHAuiW3Dhdr7VSPZdebM25uhFFP gShL2cW2auzil0FL4ZmbF3Lrm56mT77lixo+z3efe7dHxo+tnhFiww7pyca+ Odaz4G5rwVAbq83U9HPdvDEL4alo6VkLflLvj9klHuFD5lxT6zfe97w/eXg1 4ah14KFxS5f3vGDXXr3lSq3nJL3oqt5mZmyZwsquSSSjydxTqtNOuVVH9+/d vFaRFODhdOe973vL1xm42dzT9rf2/d+lQlQrFVavAAF3YAAF3YAAGevvX3e3 9n33t93t78qrJUgpBSJL7nt873bbm8+N6tv1VVhXN9703x+19l13njNkXxC2 wLMrymZXlzS1rVhdSvqvxU89I99qh398XmEUMO6nV3FnvGpDntuZfbyFSUEf UdrWw8IVszbrfgczNj7nRueZkynfJA+Czu92nKbHJLiwTJpzj29dtuxeB9kz oQN3MvDulO5Y1SPJXulb8M+F8vX7z679v2fs13XP03sfELaQtoW4AFLQAtRR RwpaQy5zWzm/X2d7rntKb8QpaQpaQpaQpaQpaf2iCkFIKQUgpBQdGqQpaQpa QaUhrm/e91993mXfOdN6nxBEiVFFFRm13bea9fZ7uuYa137uYoiv4ltINpBt IW2cIpBSCkFIKQUBzKQ8b9rt577NlbnVQnXJIG209GN/JJoBAIBFh2ryzO0m 3nfVTxANoBAAIBAgAA9tqhZHs8XPeoy6AAAAAGDAAPGVhpUrdvytvMtgwYDG FffJBAEDD1XaxHsF716qm4AA2ANmJyIGxg6bx6XFmVv3vbYAeXyYxfIBQbZB tlGRtIW0OwzDsc9vWuPHOXRnYetx+73RZxec+obF6qOJ8sHsLCFB6vJBBzKY u5rREkZwsPpTVOGezXLfKHrnZ5G7/aze8x97Mm98fg5Pqa8eG49MJw7TviLp YPs/Xi1VuzdoOaZNEN86VVM2tu0R9W/T29L+Q9uV99WoMtREQohVFFHviFtI XZb3NXeHe+3h3viFtIazMIW+whcaDUWKqm755dcp73ufG99+AToC74zfdzed 3n2vvtcmpzQCMuwD7e9p9cZ7Tvs97n3jndqlsAYMAAAExMrvIN6nk2u9Xuds WbgCYmDBgAAAGfXjeHLqe+nd71GZbC4SQjBgAgbAIuePOUrh76qXd7nm0wbT TtL4D4G228Wc37nXtO2+71W8NttvwNgNtulXYnvO16bO6vK5i9+855aq765T t8d/BKvyLH4/o128Dz9swSdvrm+e18xGw6XweU49w6J1Jgq5DqhYhi6bfce8 N9o3dFnYyX33fLbkRfs9k0fLnHIZ9dmLswZPXh60J4Dc329I6tp50c+7m+53 b4DvbWgM+qeTffblJGP4v76muqLS1eafXEBHW8jufRChbvvckWHTSbdd1V4/ b+5993x98mj2iFrSDWkGtINaQa0g1oNRRbtM1rNzbevX5p731+22+tCH9Frl Ra5UWsg2kLaQbSDaQtOceZzMy39y/t/vfu++92n1/FQG0hbSFtIW0hbSfgzL Kl3cqXd1J0zMwAADeddll1lQw/PP370nc129raaSkF8g8MGMGCYmDF7DY29w o0592+U7sFxrBgAAAgbG239MtvXnZzqu6t8q7XHmWlINEV1bbVwluW2B13p5 ivXW/r8n33fZ99yvN4ZlIW0hbSCkFIKQUapKOCoOlN65193b76d2mRNeXySf yb9Vc4jR43jNK8/z9i3hnOaJQcuVKXyDQY+6U+8PKqJ9z2u13WzksdpvToqM 2/C+U3eiYKL14ODveruf3zWVZ9Bi8QPdNXyUcnSfYm+unWSCcU9R4XDM0ea0 mD65XR91DyunfXcHnslB+9+1eh+gfm/1y0Pv15N2ZHi+RV3bje6yktq83MFi +Jpkb1ymty8m7Mn1okVDb10P7N3Ju4bcUy6bapedb72z3tD75YnNd1mPG800 avel95vuoAgI/pd/ab7jcyPmqz7u8zLLbTTbbbTbTovJg9uQHIt3cm7jnVwA AM5u143e9zNd1fe90QIQhQQhNZnZe9advnMazm8ZFSgRAioqii7frcctxy3H P4DT64Qz+h8tfVFefpnLAEIbBdvabzo2uNv2ow92qKvaiWPPR56Z7cVa86My pMfoXZvVVYPXtBJhG8l09n6unv5o/Z8geD9Bu6PjsbbP2BXjeWzkN0TjOp8Z hecPYXcDlb8p06eV3JDvEf737G/Ro8H5Tp67px9luC435eQyAXlISC8pCQXl A6dL5Qji+JEB8wGP2faO432TMgdtvd7hYA7dgXWM5bl3zedvveXvm03r0Jaq zkGojTnNYcdXV675zes93TzQRH9LsA7p2X+7Wc872c3j33zu4hWGAAPeO9Yv t5zmbvtZ73U7DofkKkFAwrAxbaqooqlSH2u8d27zPXE+ndu6b4SSUkfWpXrH 3rvDt6mMSSSU7SJHEdTynGt5Wt0kkkjYyZg29sTW+rb3wU9pp+7Voa8e6Gcp fUdsk9r55M9mrNnF8BMnPTDiizFiLO6lnB937czdY9V6AGV8Gsx8J5eYGxIh 2yLl2tZ20s3VJ5+bV4rv0xeDaVvy5WTyuHnmU5qOavIqiJh5HbdlOCY+6Klr f17mPSQrAgiCSSPGtVukyWpBIryRvezrU0/NOLLOmA9j7ddDASpg8AkiSTHP XYPbrXPS37OBczIDGslsbSFqWpbruurDmGu3u5KElFryON87fA233d3Ytqtt VuyVss3OSQGlduD1bcsXkvUqa4eqSttuZbbJJHMkFv+Xu88+Hvn9lL+B03iA O7a/bZFdneU7jnbTAHk1MdOF2J/kvVJKB47bltGEjr1tm7sTIGnueZaxm9K7 L0s8sS0ZVcwwYBbe9wwHz47MHI8zJcSphjyqvDjNrlacWqJDvd3VzySSWeO3 wHde7utuzbW0xskw5s3O3gnl9zZmw+yJSKSadkAt5RM56+q43z1bRYSaQyBk g8/dzAKzs9st9GpH0ittsZJKAUfEqPdlzuFNkkkk5ACZkLk5sNKJTwa3r3ef pO8WuE8pZJLbbmW20ddPVgncbEx2+PDAQO61ZZcy1VpJRTU+bVJXdmk+j922 YX6sy7vUAPbeoLSpw1ZiU93TzXJEtNtvlzoQTs1JaS1uCqe3miayZ4R72S5l Td1bkZAuFTaunPb7aoizuBcvamwAArfZnm3JgAE9LpL8TNvt9W8KSUulryHR Vy6s2q1qSvsw1VbtkZy9vvZPyj3vbmc5wAPe573Beb90AIBSN5JWXJ0Vduiy eSdnoVXvc5vEIIk5kVu7aiVc808G+zLa602xuvbe9bGJ3QJZku7et9ueO+7r Ipmel8F1vDzaLU53lqRkzIlXU2iZkuOWjd9ts3us093uvhpW8lEkle7mJN3b bSSSW2njAHZ7G5svbCN3aWbetJa9iQwAZ1Vt5Nq+pJV8YHLASFBtngktUZK8 kT2Hl1z6ecb++n0kXzzG56O70kgdyNq+SfgKYXWyiSWY5FOnSSXHe7WkIABj bqIA7BOR2nYZ2KS+n65JdJJJgACRAyRLHG7ykKSP4xyxttgAAJ+AzsCXEo90 YUO8ueZVIccgHcBHMZuAUg3dt7BAOvkF1Fszkq2okklmSgDd3MwXn76Yx776 b+73D25MytuHT4eNFuyRrt6bfSStrsb67Jb23LJFJ3cxJJJE7d7PbbtBbtcg Hu3VwpKsRPLz4TEQJKYnNk7u6ZLaykkQAZ4B+wuMEad6zygbfebb7p2Zy7pB HXX4r2Vg3d113b1rt3STKwABmKecr8ACQvPABP9YGnuitsgAjS6aPru7dtuP u91OqraDn3cA5VQGu8n5q5cx+7ttr2fpZmbaOpweueMqyric9cvVDys9kC3D 5+4J+Rss4LRncOQYZWm9W/d6PQS1KygYkDix+F/2Hmh97n3Z7vl99XJFgV66 d3gO3IFLPK4ZjlkS7rvgGFm5QEOl2gd3a6uH31d7L9u7nw6HvZqr+Qe6+zcC Yi6JUaabkykrULW9ilkQBMZtG5aYh921UR3AJbYTLoxzfzr7WPs59v7t34AA Bp9z3bnb+3keYzu7v7XftKq8AJbQC1VEdbbvbzv3NaL9zm/c9u3p9VWKqMRY agGqN1zfMzTvvU6nsNJx6Ty8nChe8oSUaRN2KV28VZfOZ2LXe8kZhkYpqupx 1Th202q5eS5Z1b5npkifWV09k0zlrSWYPXLzKWLe5ex7o3N457jALLnUqCWI LBx5OweSd8Izi9OM93LRg9RnceYo01bF5Zxe8SEefAOaHivzpwlaDn3jNIK+ efVQy13yi66owfFjRONQ1r8+mq5wraXTt9ViJi5znzGnE/XtH0r8YLvrv2YM qXh77QmfjfqnAA57S+a9vInmt+992XnPdPrtVUYoRSCkM7u4e0+vPuaPcw3/ m/v15ec/EFIKQUfMP9iZWkG0hbSKIPf3P7+vs/Tb+93mR+a+1/fLfc92fwAA CAIgCKAEQJaoLIKEXPguOZJCXHGtz69/Xnj8/39n7vdD+dftfu2/fu9rWta3 0smOMhWshWs6KQUgpBSCkFIKOOJCpU+QMTGBW7gAeujpnb+zO+7p/fXbn5rb hj+zs3NzRWDhJIOEjidJBBI4HTh4kHCSQcJJBuTH59cf2dPoM+wfCvdt7u/X juB1RUUyioqqop+mqplQkklNU7q4kklbl2W7q7q4kkkXcuxJVdy7Evfv2b3U KeufTr8x6zvG/R78rjhrAACJNVCSSQ5YmwJAj3ve8wYAEJJK4Skm963r+kre Zve6lTigQQRERAKiIiQh+dH35P7ufv7uh/f13+3rtv3Pd/b+7wADW973uEop BSCkFIKQUhEKEveRVFUkpqqql5UkkqgMaSScAABIADYQwaSXrszndR0fc/tw j6Dj7JU9eYVQkkEhKSSQSA2BIDAGAABIA2wlfby5y+cdkVHaU0+ud80+J11j 2r9a507vg927WPsMCdsVK+Qol2Q3ab6CaTGcD0dXuGVqDirucus3kVXz3D0z Gv8Q8ghiuduGB19JJ8NL7rvjs9xivFrl7UYNc8rimcAqw3ne1VR10WNZsjHH Y392b32wL5EfZ+R9s9MP34XvzfYbJl2VVVQ6qqEkkiqqqxJK7su7S8kru7u7 S95NJJK7t3dAVVTVVVVVVUL6aMz4/Xfr2j09h+zPr7UnudGgCSeBJOjW7ve8 Ia3d73hDe7ve8mAoSTYVgKQUgpBSCyG9YQzMwhmZhDMzDQl5KYvdR9H3zrmv phrYPoi9mrjJg+Xk22QgGZmEMzMIZmYQgGZmEgDlwtxsk+SSSCBX6nov3T9+ nfvxa/K80K7M09dYYAAuZmb1rkNBCKEQzeb3shrWt72TQEFAkGbu972Qze97 3AVDWt71s8nVVVJOqqhJJK/nMHT98t3sDDYR31Q3+3fdOlySSSSSSSSSEkAy TaklViSSUVucpF9rrms1i+VfRHRhcxVVnkqqigGIAbljGyGAvJwwflJIZVBV fddHuyfNzfS+Hx0YXd2xP2kn6/v3vYUkj5ZyBErN85zeyGt73vZPlVXWta11 ga3vJ8KQUgpBSCkFIKZrWiGZmHlLsF5A2vLrlNTH1PJX3330uvouoieqrOHO fiGGZnxFIKQUgpBSCgMzRrCGYZhMwy0tpbKWh4FisMMtYnaXY/p77fs6B0ti 8jFVX9t22oTcty78SnUI5COSRSEchHIRzcz0r37q/Z37s+5W6Xzj7Lzd3H8k klBAS22nDbbcriaojkI5ISNRyHt993qZlX8Vqxez5vipBcFIzLm3jeGdLqO7 gy0d4lX2h+fYvXiXPOGKR0YOHS9wdaJ6v3Kay/I7oCLKch/jPo/iYPu7PsQx tET7R5dx0tyg+I1qhrymalcwgV8VnZkzels1pP3aXsfZQsynvfKl9GfO/338 /q/pqfj97diaq92MydJCXDeJIAk8lCAF5BAC8yAlw3qSSTICXDcas+IvPor7 u+xE19Fb+H7M2L2Z6VTqqjDXBkYmAAfp3512d7VRa78jPfi+ea/e7ExjbaaY wfySSIwaSSXW3y913+73Z+rbk/O+VVeackkDmZCUUgpBSCkFIKQUQkG5QAFr AAa2jUAC1tYEltEv0zJWL9+7v3b+9q/J4vefr1etsF8kmxguIiIc3+ndb9+f ve/fvvuTTt89t3WdghRwAC3kkkaOBJbQgbd/jN/vu/v2bruq16ZjbabbdL5j aac5XXbneudarofTOcACD13cqLud1c3vPb99v7zevjX3OH6SVS7kiwIiM4/T O/vd/fcz9vy/a73W002mnAEADfLzdHv2R3h7u1ZqP6UYZy/JgXMwC5045cEp ztlaO4pt0d5u+39xfbfXjb5QA6tgznr69whNRt3Mc1lIzO8E6PK5/d4Ev4jf Dd9nhfl8vpJRpndde7C2OqQ4gOojOxROHOeZeF4PdNT8NL2X2nMcQP1WZyey L03+Rn3Pvvd3XvOCqq8JC2khLaB/AKQUhmZhBSCkFIk3lktpDfD8d/fd/fZ7 m/tbN59vWEG0t5atn+EzKQtsmAMyC+QCQKr/J5f7u/Vcfdiu/Fp/vkgTbYj+ kkkWf249n39vn9yc/u/zk5ms2AGm2m6DeOnPsvLU9avu0v1775A2222Aa1Nc 2v3u73vOb38u/s2BEGru7Bgpe099lVu4itfkE0AAC5IAAAAASluEvMzzur88 H51QDbbbf5JKW0AtXIS1+8c99zu9Hfvc5U9re1VV0W0hbSFtIUtgdcMpITN+ /e874fe+zWjNa7973DnCFLSlRRRR/BS0JPhDT9V9zy73PSyXXXqku2mntW1k 85s19R0h5l10KOfX2Xfj3IUrwtT6zjkLtzj7vb3IUkji69Rs3MT1NNrMe3wt u/4HiN5Yc+8ZqPPe+Xl9Jzcuvdq6odBrO6T5iwSkenTzr4rJstmlBQacnr7R mJ0E/R3D2sdid2xfzfiYvS8fWb7c9nQALXl8QzMwhmZhDMzIGZmEMzMIq9q1 Ve7l2uvdxb6ytSkgAFJSSL5EbXlLbXk22vJtteTba8r1uwx7r0uCnXZ7nuX+ BQkigAbzvr7o59y568w49ai9+SR2LuHZ0VK255g7pckven3l5erPezuadFN/ X3B+rv26EP3PxC2yikFIKQUgpBSCy2UikFIKQUgpBSCkK1IKQUgpBSCiCC+Q 18m0n6/y5/ugUNc+v8wrL75fqTCwIgAu7ACAWsIgIgXvMiIIgBmZkAARHj73 7nt+5y2rjL/W59r2fr0RAQVFuXHgDrWEM+1rRBDWXCGZmSUUgpBZDMzCCkFI KMSKQUgpDHMpBSCgMmXMIZmYQ1u8w19+/czjln7Q89vf79vpDMzCGZmIpBSC kFIKQUgomZmEMzLbbYAFtwDMxrybbXkVO5NHzh188ce+zJ0+++teTba8pJF8 pJPvr5gABd3d2wYAAMGDAYBd3LsABgwAYMBgy7u7sAAAAAAAAC6u7sAAAAAA AAC6u7sAAAABgwGILu6uwAAAAAAAAHnOUyt31t8FXXXVynsV9l9vrxx50x9E bTgXUgjjty1IMq3N92Q/pzNviEV5t556OHhRose8hu5X7kpvFIHu1UGS/2lg /aAQcYGeym/Q2nTnR4YbYRpahdGleNzymZyrZWGbL5TfEiQYX0C7cG79H9Nk vr/Tj9G1vrh9zm9b/t3d3Lu6lr/eAAM1rWgIgA1rWtAAAa1rWgAANa1rQAAG ta1oAADWta0AE5zrNPc/dvmk99+rfN7/atdrq2yFtkG2QWQWQWQWZ9+fs/e4 ZrKd/d/Fe85zF/ASFtAhaqqqr9z35/dN8bT9lfTMgqIjfQl6IS8vQk9mN6sL rNYe+K9M1r6T8EihATckBe87w+n379zY5VrW+aS9aXphLy9CSDVGaGUqJzfb eazAgoSDFWKKKL327nLvnvW2neWzedtCiiiiiiQSSSIb7bnf3tan33PZNGsz 6YhCoQohCEd30zffa+4b39c+t9rNGIooLFFEAFWADFF538fZy2+9ec1d57nO Pe+Ph1L0g4+mUnwo67rpaIHt3OybSE3d9iHbqLxa/Wi31O4u9CZ6s8uB2p7f ezJcUrLw9Zbz/luG7y9jwW+RVS34Pju1JoIrUEFMg4pXFMxguzk87PPhfYtB B7KdoflEWez8z8t9pUfvfv5/L8v2UKN6eG2qQWlINaQa0g1s4qqXG2ix+vt8 5PvX6a0v13L5l/AUESQJUCVAlQJU1rXu8c797XvPcSzvwqoivhSCkFIQbF+A AtPxaUg1pBa6q4SoLRAABy7iIiAiM37H3f2ent/rmQey/3ggiIiN3cVAzKQq QbQsK/vaffv2dP2/3xpTWZDNuOvtfPfrw9pKvn1xzwAB0AOJBSCkFEkmZ7Nc 9wuu0z1uftmLBkqQUgom7p+++78z7jL27AApL3vu8feO56mKXcADgAVIc97P cd9PZ6mMKZi0vKNSSSj3tT2yTR5juKvKrqqqnlk97fZeU6YyRd0Bjuca8Nwg 50XqxHZm+s2L2u3yvI0t2TSPVZyA4303cJzH486lX3CeES9DL/Hn8viM+yMZ 7LjiKM+4LRjNlRaeslHn2AG7fTgq+Kzpt8VoAjGVmw+WYs++NmxZvdLjYo+3 xwe7X4ADJJJTeffZ97p7XqadGVn+dkaOiSquyIjX3ufT3vd19czSZnrgIIP0 C2kLaQ/fe+7fvsz6maT9rT+/EG2TQpBSCkLmYQUgpBRJmUloioxzX7978/fr TueniI5Ui7WBHvb97uejXLy5tsTBfJgmP8JjNkh3eWb3U1+ld348BFJAJJJJ JJJJJJISTP379fvftJmfvzn7MzNaVCiBR+5z975z1p+zr5WKKL0tKQa0haUg 15rRDoXVRVUko8kdNZdxhrhPhc61eQQAgQTHJIpCOQUkkchHIRyWk7Png+6X jsl+PetO6NT34fZSPbVOcDqsMm9mFPbyoKVmb7nr65BV2X3adhSfu3Z1B4yH YH2B5m6ZvNonOCtGK3+LwQ8Lx7XuZfmPqV3cu7qw60NYPeCo0x4hdZyBdslQ +5ncs2aedjcytWtMmFp9lxnfTJ2x3TC3T6HDoTICXDfeS9keKiqEvJMgPxkA T5MiQnzIkGgAIbU9f1bG384T+PnNfDQCYSOUA0NgQAgQDIBtNjIA+++Po7NP vfPxfzUuG022m3Ag0azToho1mnRC3Q4HVVVVw1o1pAABqZprQAAGpmmtAAnv a9+v3tfq9nn7tkWLjslSsyZMkpcy7iWCgn2/37X599+r9ep+AfgGHyYAMGdx z7e810/ftbbT1JfIACNUfwADcI2kPa/b/O/fp+u/37vZtkzKQtpC2kLaA1Rn 79+zzzufp+z9xSeCAoSJ9b96/dz6fZ9zkkkysJ3BRQhCe37XPOdz1ezm4QhC EIQjfySS35JJR90OT8d6TlyzvXTpbd+Y3twhaDNBzh3Z3r5mSXTnP2WHIr43 QLq82u22jbgn7uwTO3l2PM943uVRb0c6SpnvDLwZ8D7acXptaiSsKGaupBvp 7rCPXnlwFZTw7KeigYAsKbR5CjCkYt19EkuJ0hStvQNHKvlXuQd0Fkbetpy9 X3d25bb27awGk1D4gPMJJDljnsmN5ZN0dI5mWu3u7ra0koSBivnBpK3e6+ZA gy1T1Y84bw7d6NeAcdG9Uy24ABsWSSKV5uGInuSSfiXTmFRvNStZT3dskt/y 9377sy37fvvuzunLwBqA7hXOj7mJy+Nhw2al99Pr4eEBwiZCvJDIKR274k7u 2QknSY7L3c1CSUABc9ivp7bcshBN1aVfW3d2tkmpWypDkeW2tFctY3fa5rGy dOr3GfTeyW90I3dAMSSXiZ6EwXu7i93XbG2+1v13ZNeccwbbHO6KSTIetuoC O4Nnd3rudxObus5BTuEmoQC2q5W7iXIne7szNyt3ea/c9Vu7ac53s57xgC3s eHnTesooA62+s9baUSbfHuJ52VJJ2XMtu7tuZAJe7cJK7utYwd1qG2+tlkkk l7BhqUJe7rjTvtBT3WwyRdXcZPN9ZJIba8E6S0Bjg2mmGQ9e5VWrCbqSVtrv ZlFkgkJJwZs6MQpb3EtPzJwI8d8S8JA7LIidW+VbRJPibMybJHMAAias2Tms To7g9OuieUghM5JdDuyST2GUY3Vy3RJFtt9W5kfnIlve95zjwF713wL73vMz Od+U+immXIJXbwWLxMk90ax69gCJR0k3dth3dvrjBytp+G+hZBtRAD3t7HaS d4vmlG8OgRIAk3uXWjts4iUl3LvtzNuP2Fu7IhJGI6LsipcbYpAtjslhR3cg b7m28KybVASXLbruiN6+b54mxAiWhNm7v3W33yffOgE/E7FEy3wEBK8La0mz aGzus29L646HOiBLhQtgvuqr7e6uZGm5LbZW3mLNSSLJOVNRvvY2ozAHC63r xyS25h3GSGXxO7qtAvQ6S2dyEjTBidryu1EpJIpckil7uJkhkdb6jvC23pJj knd3TdPUkgd3c2lpzDLvdYvSWZM2S5bbEvJJLd20nTVXrzR5rzthZdbaSSXk 5bQN3dzfv2/g73trfu9d7wtycmc3ieSN3NbVxupVexvzl7u61uSSAASW2SO3 N3fZtgaNt17y3t1cB1gsfOEkv0cHoCLI5J3d0ktrsjbRJyvW11RN8lPB6uUn a22T65Wx3u82wESbMttlxTJGW93dm22116klHSSScx2e2rrbdR5YxgbHZN09 x9FJbQABe7utsJIoAQWr1tzBIPX3cHZtPTASbu7WtGS5dPL3eU76VEDqPT1h D6VIZrsptxFbzsKBjzfV+ywX19dSML5l5vbDQaVoy9i4ILTWzoGEU+Fe/4Lh 8bvYI124s6cvp9wO2vil5MgxjABSPc4TfTiVoOc9uKX07SQrduaz5uH8svt3 HfPV3dEcF7r0+z2zgQLShCFoooooyIyCMgiQr7vtbvNelvvcGQRkEYCKNptY fCBCEIXJJ+nXvF9PqR2ry3lyBo0awhhhmEMwy4QTDMIYYZhMIoIQIQIR59Wd Venb9U9XlsQmhGOJjFJIoKOKVKdKpIoRqKCFJlGOb5rkb72vHukuNMYRuOHi 44apTMyuKSKKEcUIIBXdZd+d+9VpzZiGPpImC8vmQA+AAQCAWeq/XbvPNUd6 sQHwACySIBAIBNobCT02rm+isz3tcPiNy4QzMMAylIZSkG5cIZkUSTkAEwWc D5e3dayvTvAANgCAAAACuMfFdqjrx7W2AMAAbTTbESPsfverzRm+8+o57qx6 eR9Ut7J3vRSZLq64LxiIfV1d3hMVt+9NfLfVwa4e0sZvuyGEdr9e3h5luLsP dQ7ZTmcLtA8a/TtzzvmS4dF0LTUhnKVK6FCsXp8vnOKyC8t77zD4osjEj6cO O58Jr2vse+e0tmfedpfvbI7LuBUKqLuQrWQtpDe87sz2/Dy+93VkLbIWtrRg CbadzKjm1v1z3veT5JgvkAvl6SSQi8uYAu7RAXmYgAARzMMEFVVVzMkLbIdz mY/Ht/Tefe7ILFEVVVHXfaMznvR1nvd2W0g2kG0hbSFtIW2BbbV769cveemZ n33SIAR8t9l9zvchzYACgZvmbZzeq5sOVVXYJHMaznMhnIEM3nN+zXebnTiK ioiJox+zMNOfa5PZnHcpZiFyfbY1XvfsX5aIrvP9Jn7evynoe8vlM31e4Tdp nMXFw5EnN7YYSXal7Rd632EW+JNUTU9s9GltopUubhPUSk1wmjBYhE+xdasQ Yidfl6hFcDnP25hnlq4k3iR6Mcds17b6hsCS5yL3O+EVFEfVe3233j2uJzqq tCAW0CFtLaFqrvWa7nb3VePOqqqqgO43bfe601zoAAGs7ves79z7vE134AAD n3OL+53m/u1rfwBVDQHPZ3rnvd3te3XecIVIKQUgpBSIde8XN873fHV10b0G 0JaqqoXmbZ3ndzfb1mBl2GVLs3dxZrjL3vm+8trfcwAADt/fezL13V91ntXG ZnbPSbNaHYlcpmbVPm5OPTu2eu5ehCVmb6PcKu6Y9DIvuTeQA9l4G9k7eRna 3NFus8J3D9hrfxuX5oDx1+3JvlYi4X0enD8xSvd0Jm0iezx9GDdBwT2mrVxD 3fVIAcRbuZyxSzsq3nJH5dt2RABETnc0zveO84GgAMWQWQWQzXd7O65jo7lH JC2yFtkQHwAAACBsyTMuU3hJTkAAALVt5pQVkqQUgsg6Oa3rTy5mnhBSCgya 1mZze9HN11SHHDmuGtPLdJ8jAWVlLLkpr5GDpZd3TwKaUX2FLLzHW3mrvJMF IKQUhfvGrv5vuZ3ue97Nadnt/Mjx6OxsntIu7Eu4exzG0dlzvUrs6yXMDh9E 3nZDVgvZvbeEyK0c35S6Mi+pd9X0V982pPtW4VD+Vlb9yLjrHA35BN9Mh2E1 +M0JYS+tfA5BmTsKK9D4yNypeZEX3N9u9vQ6sWUMBeUQvKIUFEjjvW9Te81h Jc0/c5vZzl1gB8IgJmjvO92c5vNaJ4giQRIIyiIqguLCIgAuLggAIuXYGrgi DJdkSRvbvd73OcvWRIIkSaQHWnnOaOb5mtT/GTNrzfNG95rJEAGab1vU3vM1 NAAAXo7fuvO61u9O7zkPgFIKQUgpBSCn3vXmPxd7lK35aWkhNt6pfvUWN5Z+ wNmwvaB2TWp3buUqB57Dyy4VuSr73me6tDRcoKl1FewP2bpExpaucGjvCZqX S9xfltYgPLFZ/D7LdftCc72vzDL8ex72d8vidy9kPhNpmVIcNozz9gxXyb84 w9UpvPO9neKrfPh1e1PSLlpiG222ADGHet81rtzvd5yYAH1V/UyC+QC+QC+Q C+VZBtdz9tV27l4p5fItJaq/pbSFtkLaQd0hy5hC3i/fd7Lqzy0yTPL5SSKS DQ/k7bWa9uq8LVlXCwlFRc1mOSVlzXkkleIOvHe7o4SWkmCKdhTB7fW6fe97 feBlXZbmR+HrnDkqfLE19M2o8xy7Pce56T1K222mmmm21hKddbp2vdmDvHhd J4hSa8mbuZ1wrsvPabqKNi9fPFrxs6e2cXSurTcWaRj60dxuVbZycx83DmP+ 255z2794dOfvvl6d9anEfLoZxp7kIxJzRMZWhZO4/joq6nOeZmp3z5vsOwtL MRctA3sqx9l93RZem57q8Ummmm22mm36ppvnvJrad+77Ob77QRAAeb3z2c1z 7XzWXK2KxxERERzdryGAkhgLykAXk2AvIAEvVXSRnLthBFOTOmuSkBtuZckk ckCRyQJJJPuxdz7Gq69lPso6AAAAIIpIL4D75AJfAL5VVrpnX43c68joveEv gF8gPvgAEAhDTEIENgupd57eivs5RqjMT5oQCBCBIQCBiE2wQgQM2vZTrrV9 cOXmta8aPqUtqN2kKW4Mg4ZcIOLmSGYZmJBMzKkEtwQwtyvt31fe+7TdYPql qdcnxJ9FJHFIpFIhskikijckUjQz7rj7zz31de+VW883QIYz5IE2hjPvl8A0 MBAIm5XsdnpJl3lfdu5F5L2TeWFXF1V5ZyQsybfTtCebXfV4/xO6YmpYGD3g Wc8JgKPOy8SsOHLjdXuzL7edG/P6KURSdLn8J6vtrMsvUU977Tq6Fdh6VeV9 sbPYYYbwOCeSEfNdX3RNnMTbXtPk0dlynwpnYNPn4Zub/FIp4jjT2NRSRRSS RkYOREcirttyva1UzddPnk26ZqFJERSJikWJVSBC8mmyBeUiBC8gQI++S971 2rtHpJJuQN7N7l18++f3M289z9vXxfbweXxwhaUn6SSIZhSGZhmDAzCkGtIW gkCiSBHzH3dn45ftcufr9fKeCzF3yQWjEWKL+AAED7PHb6/uO+ffufr3n2bv 197pv8QUgpBSCkFIKCQhRCIBmue7nr+673re/2z7b637h+AATAAEiQlBSCkF ILAUgpBCUQgm5AiMghQALw599rP3XXP3f3d7+Ua8WJffkkkmvrwyftX5ZXc7 /X2dbXHr+/AAMQABBAAdcHe9X8e5+5v9vf6vN0ee/AAMQAEndp+55/cc++3m ++NP7v2vd/AAMEABEABOQANfe/YbO79hdneCZ+9g32Xe8M8g1EreAnVg+HOF n3nFFls9F3uubfrmbkAjlefXZfUSHVPYd20cU5BYgNc/u+w+mbvuPvn8PUPx Yntk3vtq6CXYYCb7X5TBN5ngcXjjijPKlJXiyG4JmE5Neb3Ve2GjjcBhgW8l 21n8SX33wNt+CIGwE2/xvcu9VGfnL/a37fbfc9r9UXcq7iAA5N/e9L/dc37N /d739J77XAiAP0kl2ctfL59897fvuArU9MhuZ+95GNzrM6KhFWZnsrv6TkXv Nzvsv3m9+zfu979Ovc4ABEH2ue1brzrX3ue337v0vvd6qshIoM6zq+5l+273 3fOb+6nn4901IAn6ACSwAOnz+1n35ze83re8/T87p+pogpBSCkFIKQWfiEih WQBQAGH57Ob7+2Z+/PbLq7xa7Pwl9+SSSap/gAAN337FVzwXLivuuqfZs1bM QY3t62dXh8g95XHpthXl+pHmskzfLwmKwDk1eb3FuiZUdNFpB71TW2dycfWG hmfy+z3z9qGIEe6dnlAHhfh8e+062DtAntpx7gycOpxNMy+UJ7su7ohGbuYN jddynSAXncUJlctfmHSYgbABJJIBfJJAFpa24SbleQ20QvfiSSUIKa8tL++y bv6S4t89s132dvm39c+INpC/gAEli48nP327v55vNfubPFfNv7JPwAAiAA9O fm/vXX5ze/v2ubPGO239n34AC1VskktwltIYAGZmSSMDMpC2wPCkLjmEFIKQ UgpBRDneru/fb1+N5v3NfcePvXPrlAaL2/pJ7W9ZSDlzKQxzCkHLmUg5cykH LmWGEUgpBSCkFPkfbX7x3OVkv9deQ/J+nXRsIkn8BIpJFJJGQUJFJJJIoyCh JEkk6a70l95OnjrL7fR+0vKOp75xJJNSACAVtLaW2kRqQbVII31Iavtqfffe vHMyXl3uuPlcOt7qF8m5JF8m5JEk3L+ImZ4ADK5WqrWq20RqZnH93X37k601 q9vMWx+uHW8BNMaYNpsKNtS2qfA3GmE6CkFIKQUhmatNaIKQQMM0mELmKYQz 41Oa9732bBcllbiezQHOLmVy8m3EJrynn6WvJmWmSpczKyVMzLcarCIAMa1a asAA/VVS7K1qswAACzG8moCqtmlkqakr7Pfbv287b97u+bwGACrhjcGo3Hd7 Vgqfe1e3mMHiczC75rXc6Rb58f3dNtWMuUjjxxhYj4NkqHPaFhMWryQFC/Bh LcmrNHjPXAdS2nnl3jR7D0N2ewNZQiw1M4gyzNk1yYfcZpHuiZAFTJNzctdk 4YzOIPIcwAgOiiVXdzh0DrJE5DfPX3dz7dzMdc22gTWzD7iISUn6WhrU+yyZ ktWZWwG3JbtZ4gYrsGYPBIvu45Ykk+R09u130uWdxAo7bZC4h6k+BntmdgYX I95ll4gTfOOPCSYudkyGSyOSTX3T1H+XuzPuuidhfXBR0JOF73cnJ0k+0Dbb cgeES4bYcJJfoy8O8GycyW7sdAAH6V29221vxb7dbzHb7bJt2YSOFO3Xcy7l tSKSV9aT3G8ttaMb7Zu76c+YnhL3MxOj0BfdqZiXkl+py4BOCRJkz2KJKWSj uo3YAOZvb27A+9aRYNrltq9j5W8KtfudOEg4Lbx8dKSE7qlHA97m9PZ3SyBK d0EkkcVSXX1XqJtOc737vQAXvevfrZufZ3m+8tXt9SBfNcWutbsjskzJIIAH 7c0Md13alxgG1DBkG3rbmSVeJixxbulYXUmx7n2G1MoGLIxO5y9oF4660eF7 rVRpsl7uVjSSiSSvISZ0JZWVuySS27u3YzhuT0M0Z3tizxIMWteTeLhq0nHx JHZLlr5Yd54/Atkkk4ZMyZuSRwACtpebt9FJqs820Jd8jRKm77IJbJESbmBK XKkfDUgrbZCDhJ3dlkkk7tktq7bACSS20rE/MBy2rrHH5y0vN3XdjBwCeKJJ OZI7mXj7OEW8r47Y4l3dxq20DMN7lIuPEW1B3m8ebei7rSfdzSZMQMft317x QuunVHNeyO3byfG2Pb2ZI7W/SbntkjJ4ZN3TQXqIFBxoPMttAAF8/NeMEEO7 sntP31vyR7X14nbvxxxNld27qllxo8TJO18GnbJUYx2ueKxCRJrzbWXMzG3Z G423V5JLSJQl6F+jYvc3eo9aWbfIQyuTZdwW2qEkJXnaSSeXiewlJv2Y233a 3bbu7JUkkkkSSESBskDa9F2y022S22277dtOEDuoAiUiXEviVu27K53re6vt 21Xc9b6AClLd3ukKUsiIk9W2ko7EkkvKS2222pJJKS7o71vstqI7qxRjXTtY FsYLa7u21KRe5PK59ki9973j6atjvRC2Ry873nznPELZ62BDXp0dstgO74Qe ycrHZJ3d0kvdlwgnBXm4OqwRTYpJHvbdu7q0TkTel2ThQLLZTkudMkjb3Z0g QAkstkkmWTSDxGH0k8fRE1QjxCvMae7/a3e+++APqhtv7QDaiejpc93R0dul QAu7ufFU6gU8t3N8Lxvt3qaspb2JoFbmWI3E6uzhksVRvZYrcfYZ5DXpG3ds RWM9u9ogBOvZl7eILvFF+F5mt5yef798Uc9u8nvpuH5MZ9KQNOvmd6pmhu7D DpxXEq5VvHe3yft2dJ1YYrtvU1+l53HeeJzL937zrxrV7eYtUdHVoOMS+cap PA5kuEKXG4QblrhC5lTCFzK06XylQai+UYgFLa6pm+7h08arKvy1Rv3ea4Ew QCYJghptNrQT1Xue9O3lXprV7eZrhR7l5tptNpu35fKEcVTLxkqZeMrYH+FS 7A3rbWiIAAzWprQAEA+rv37X32+3+m/s6m/b5zxjq/Z2ndKqyZmnCGXHCFzD CbDWtGQMFIZlcpBSCkFIKQUQzMcIZccIZccIZccIY4Pz9zXefJ03FFV6JvZX VlcvJtvyX0ANeTba9URCo61rNCKisNa1hDMzAzMbW32a9++zd/FePaXubqke i91+wAC6VVUXykkSEBSCkMyyGJBSCkSa1mELcw/ezu737273eZKksrnQhspe 1+Wb6V8osKlU6lADAQxgAABj6r7vMcsq6vF76PwurLAAAQAWkgkXykkXyhGv J4wXls5Bc87pVmcoyGxVuyt7Ku6XkEi+lUqkkHIEgEJI0kkn8kkSRJJSElW+ rc7k54MO3MWqnWrqLuypCNuW4bblv73pbhKSXMz8vMAXkafXHyz69Bzi+mL2 NXKMUoZFtXm3fU7OuZ3iwJdLyVub2Yjm+sJtxYIvaWe3e9MA8RlPjeVOXh2k jj3AGzaBjwv+vC7nt3j6vvRDd8CA/Mfd8DIRx5St3Z4u3yd4N8FkCc8+aY5i DFx9k+Nn17A/qQj8vsGZLqapbjgT6rrqXk2AvKQBeTAF5ElySSSSSEkgS+23 3JqnWXeL30fCh1aAAARKSRfKSRfJyRfKSRfIJF8m215XW3j7bKjG6zEFq41O l5RMryiZUG0hbSgpBSCkFIKQUgjaQtoWqvgAM3ree3nT3N3WuDdj19iqqqm7 ohmZhC3MIZmYQ1h33da7hntcuzbvqPu6wg3MIZcwG4Wtv8EhcwBA2Hu9r9oZ 1aFUrkGs9VgZBttsRBrNzXPs7k+3l87zc1zk1PtiIAXlFmc92533drrW953e zD2uqughbQgS2gWqqqab7nt8zfs3d62byPteVVVRX1ArUhWpCmrnua6e1qud dmdT2/akKhFILJ4LaQtpC2kLaQoL5AfLzaq8n7wNeTyisFCnWzEV0TxcTnmP RO2TlwGYZdJ0jX3mMfmcbDtW9OXlHPQZwB3OLLHSg8bjS50c57p3W8tCvWfm M3ITnF2zHZF1QYsF830VmvYeFgibuwZnLaOhxJOefPW6JbZ1CmZuXPlaLuRw gsb8fcw2gV0zx3Py/e/Z+/NHoOeH0YL4E+1TPLc/fvJmTnGPLgWstX7RF/N/ fZRvvTfXSMm3LtTz+0aEk98bDb0Vl+urtTz+bXyHQ8W+1ZlTM9LzzO2iApDd pC2kLaQtpC2kTqaOnva9Tlzfs279z1oeAAQEAiIAoIjVF1lvWseFVAo2IhLy vbmc3b2bx2t7zvtRyhPARECCTfjp3bvnOezvec37Ps9CJU182l+qXeRc1fuu XhgWs9imihvHC1cgVeLmKV3CwgjUR5menZq90hc9vRUXjXfN5w4H3ZDw1zqh 3X5+cnJ+ymd90Zbc+DzwPs2pLcfuMMBnh+mm4ZsOxaep1G6vCyjeWArNDniy dYoqW76UvM+Qn1zX9t4Oknikw9c7tB973vehdl8a7zd9m7vu9+9G+AAQAD3j Z0zfvb7a965vfPu3eXUkmREAAAAAAAARAJKm1399M+FRakS8neW5vvfj+/fv 36atfg0l0C1JLVDxNW/m000296+F6315no8urOa03t4BFVUVGAG541M9x+rm 9a4e+jn3YCTTTTb4AG25d55b8Z7X1Osq7Xl6ZzQRABuu3d+r7ny/TvM3v32X nugABRVTzfPp9uZt3Xra5rW576M92qhkFkFkFkFiquyW0hvek1b7PsvisMzk 1iE4SmspvO3u0v3ndgZXezFRxXHwsPjfL1r9vtgWO0lhXjXW93gDuQJ7KQeM 7UiMPrKuMaP1C+W+zl4NdkBJQBfgfu+AOrId6xGO5Lt85sODtAwtOefPU8o2 lAZkz3y+efb+u7MzfGTPtc3rXPeHP3dh8kzKQtpC2kLaBaq9l8rz0cTN9qwu 1qt0EzG+nKzZbTYt2G/ZjDVFKNq51TLLjVpfvehJJJiu2qnT6Zx7vtb37evt NZ7VxAABH2/R99XsDpJceV6cO6bbbcAYgGwQevtrhd+7bfs5rW9D98OtIiqr Ag5YEoHuzno7v7tr17Wa13V+nd/b1lgANtu19jnSPPq9hs6qhsfYFU4vkAvs SzKQtpC2kLaQtpC7zCGVdZ6XXo/cu/ZmXvHvS71oAKoqoVUKqFUm18s3g4Kv KpWpRW7VpwWbvOAs8Vj71LJh6k1doqHVp3uwy+31/P2VhyKm8/dXee5wABGe Ji5wghXzRfbDBmqbClc8J9B9617gxxbjLHF+f2/cMj2KMK1J6pz9c50DeGck tfnz0ujpVZxWZN7+379+PsnMw1n76/ZrL1zH35rRUgHNzc9vfg1uzdoTO0nZ pNxncEW7dHAjJfTYBDRnuZs8Vz3bfrrNb199pgILDVJImh77r47n3e7Lres8 faoQ6gw4z5zvV7hrfN1V3dyn215YvqE0220008z2nRemN/etfs1mt6e9ruQQ RBB9m/M9Lfh9uyW5dL3KjW4kgF8gF8gF8gF8gF8mC+Z83Ud9y3lT7X6/W6mK Po8TabTeggG0AMYBm5Fp3DtDrnp6SXOjvgAAIklJJ8l8lJAKTknypfNIKQUg pBSGZrWgGBrWskOY/c6wJZPE7s2C+zPTt4Z7vaVYFx6i0TOmV42LBy7Dfb63 Z03a1UKdSl6dYue5wAB8MBi9zGQVDuNOPeelNdrp0bMqMp81me3NHmdxefhF OcTXhdiM9CSLnBGNXM6+ie8MbKnmg953Bk58Q3LfP8vTvc/F9dnh1cfdl1Sq 606n1XTaabaaYReta0QEQRGZrWgqiqhVRZBZBZBSDTWs0oGZrCGZmEMzMSkg AHvXlUacPF1qpFsXeh0AAAu7u7Ig69yPW9Xue5emprk99nrAimIENt+T2ub5 D6r9VU5c06u8398JJJNW8zlyHxW6Xaq6fe2xJYlZTyR+99lZcgi1uO4SSS2a 2lqcbTy3VIqqndotttttPcNwnlays3CXau9fpl6vgPtbcARmZkAABmZgAJLh T+SIL5AJJibZkTPYppmVuXtGK5x37Wa3EABl2ZJfS58fS/r5zudZpdcnPZve yFtIW2RtIW0g2kO5msJIpJESRFwr3P3N0W+qaqrrvCzVGjmjPCG0JU8/Emu6 3r1kNjzM8/cY+vuu1HnOUUWPgDuULsLcDG2L9jWvamX7g0E8eUr1Z5j1eYc1 +i3J55jMTWQj3IVcoTgtArTzI/LXzzVr0q+SDfChGZ43pefl49JJjzd3vLV0 E59uDwXKQoq5qkkRJFJIiSKSRZKqkSREkRJPpY/N+R43FsHFL28j9crJikkU kibbTbamG55JACF5QwYvIAQvIbIF5RVzb6Ink+nUXXURSYXMNMtcvKWCF5gJ uVMtoQAheQAheQAtqIhVVVVXMKQtKQt7peeM9fa+9rzvbrvVebusPiHcwwti rFU2S0WKXbY+bxGnsj2tdqY3nTFqBC+TGL5AqQd5cIZmGEMzDCGZhhSSmdhI YpBSCkFILEuY4E0dc2vtW7K+7TvDN7X2YPotLS2ltFKWlaoEgrbCAWtCBHhx 0c9XxXWuYZebXHfvYgAMQFIKQWFEVVba220YMATEDBggBjY2MTbTTbAbGxAA 2Jttt5mSekPKTx6sa3LyST7KIIAghIIgCEEAiuwgoSCTiZec15eF7ozjzejd t1ovKUvL0Ql6B3bkyIuTIl1BZW03Ta8vnuFcDKwPBXqrdl7tuAnRdXlre68K 8/dlXt7l0hqsDau8bzeGm4uZ3py9zTY3eAB6keL6AjfU3c9rWvYmXKiMmKr9 xl5pH3mxnl2jxebrWbtse8S7w4SgeLV5+wdTXwzycUk3GJOF71wiXvVbczt6 wc0YjF6W8UsTd76vksXza+TSoSoiVCVCSJMgIEEQQQAIgiCAAAhKFIKQdb65 fVzh7XNaOO96Xffa4SSb7lantddu3y80btvO68SgKBIyl93uswfjxadtZdfW e+d7uOo28u8MZNRkWeKLSSSEkkjdmphOsisW0ZcirMURs0kAYHYGXuXDxvN3 vr1uL3vSvrekFJCVCVCVCUAIAAAQRAAAgiCIAREBEEa3marX32p37O75mp99 9LdzeTAAAGLAAAvufSSSLxdrICaZzL+neM5Ps5vmane9i/rzoRBEBfM19er+ m+N9n3dd53fXe4Gy7sqqqvwSFtCEPBPdw48F4cPfZrtiC9tzNwaR7k2TT1qS 53tYWatJ7FPTzmvr4XCaa9Ignm5Ju8AdzbX7p68Og+WaSRGnT2dRMay97Lxk 7FTNjrtW1gmFZOizm+oJZJlgMskvaD4ecY7hjbTi5vpaTuWcqF5eO8Vl/HTm EjznDt5qZzkHy+8kkk7My6l2AAOfL5Nmt83n2bXO95O3f13gAfLtYak+++ko fm5fjZ6twivdbGYaAAAAAwAGDMLq5o5mGbNvdtZNTbwxgAAAgWh5SQBAhOx+ b2twnpdsirMbe3PBAEDYAA2IAK325eYYTLM9M1xVufNuzBmgoCAGhgIBAIQI bdD1y7M2ZbJTeYm/Bb8xjGAgEAgEMY/vvkNekikwkhcfnLw8ZctZitQSsxtN tpttN6CASSSBA2m225EkkiQkSSShuSrKqYjaaL0moay6iYlQReakkkCAXve8 0whuG5bEkkgASSSAJmWm2m3KXpolXOhcVWe4mucGO+eAAzMtpbwLcwg5mELc whmZhDMzCGZmQP9wCQhJIf+pD/ZgSiEIQqiFEJUISEJRQKKCiwCKAAooCxRR YCwlEKISVCFFEJUIiiiKAopBRSEUUgLFhFFCCiwFFkFFkUWAopCCikihKohU IUQlVKIiQkISEUJFFAUWEUWCiwIKBBRSQhUkIUUSiEhCVIQqFQohJJRAhKRC oQhCgFgCxSKKKKKKAosCALFERYSKALBRSACiyLFgsJIQhRUKKhCVCFQhKhRK oJCIokhCoQkohVUUSigoqEKqpRCSiEqoQpSKKEUUJBSQUWQFFhFFJBYoEUUh AFFAkiiwFFhFFAFFiikkkWLJFFIKLCElEKIVRCSqohUqiipUIsgooKLCEWSC wBYKRZBSoSFUBKoIEqoVJCpISSBRAqBVBRVUQkqpJRUhCoQlQhVQqoUVUhRR CiEqFBCiEkIQhCFUQhCqkIVCFSiEqiFQhVVRCoQkhCqkIVIQqQhKhCoQohVE JVUQlSEJKohBRYsgCIQgooEUWKKQFkKJISQhKIVCEIUBJCFEKIikUQhVQolF QhCoQkKKohIQoolFEISEKJRCFEohJIQklFEIsCCxSEFFIopAUUixSLCVCgoq QoohJJUIVCoQWLBYpAUWSKKQUUhBSASEJCEkISEKIVUkKKqiFEJUKJRRVVRC QhVUQqlFkgsWECKLAFFkUUIQFhCEqSVCFSioQhKhCoQqoQqSEqoVCQoACiiA VJCqqAACACUFVKhFFgCxQhFgoEFFIosiqUQhCVRRJIQooqoQlVUIUQohJCEk ISqISiFQhVVRRVFFSiFSiFQhUoikUUkUUBZCQUUUWBBQIQhJUIVCiqIQhRCp IUVCEIFFVVEKKJIQkKCApFIoosiiwFiwIRRRQkIVKkJEQohUIUSEKqhRQgKK CwUUkUUBYQUUBGCkFIosJBYshFiwUWEISiEohIQqqhCQhCFSEKhRKohJCEqi FSERRBRQUUJFFAUUkUUFhAUUkUUiikIAKLIosgLFIosICwUkUUCKKAKKAKLI ooKLIooSQUWAoshBRSUQqSEJRCqhCpUVAAAAIAAAAqqlVRCCigosixQgKKEF FAUWEKJCFSEKqEKKKhCVCEgKKAooooQgosFFIsWQhRCqKJVUQqVRCpVEJICg opJFgSKKSKLBRZJFFqEKqQhKogIqEJCEohRCqoiKKqQoohRCiEoohCqqUQqp CFEJKqiiqhCSEIQlUEKkISiFEKqRRSEUUgLFhFihBRYCiyCiyKCgKKQgooRR SRRYKCikIsUgCikCKKALBVhKhCoQqVIQkIVVUQoqERKhRKKlSiElEKhCVCEC KLJFFkkgooSKLCQiikkkUUiiySAKLIKLIosiiyqkISQhUJVQFAAFAoJQQAIE IFSpKgQkohUIQhUkISpCEohKkkIVRRUISQhCioQqEJUIVCEqEJVEJCIokhCo QkohUhCoQqEIQqEAiiwiigKKRRQiikgKLCEqVCoSiFVVFEkCoVKIVKKlUVVE kKohRCVCEhCUQohRCQlEIQhVVKKhIQWLAFIooCixQUWRRQISiEqEJRCQhIQq SEJKISiEqiIokohCFSpCiQUgooKKRRQCKKCxQgopBSSKKEFFABRYopAUgooQ UWAsUUgsWEUWAKLJIKLFFkIsUgKKSKLAWLBYoQAUUAUWSKKSCikIUSpRIQhV VAAAKkAESBIVVQCSgAhUqBAFILAkgiKosFFkUUUWRRYCxSEIooCigEkWKoql UQkkISiEKqEohJIQAixRYsCCxSEFFIopAWKUUSiEqFBRUhRRIUQlFEooKKhC VUohJRCVUIsgAKKCikgosIoEhFgBFkBRSQWKQigEUVYLFkUIUSiEqqohRCEJ CFEhJFkkFihFkBYoKQUUFFFFJJFikIKKRRSCigEUWUQlEKqiIolQoqVCFSEJ UhCqISiFSEKkISoQqEKIVRCQqSqIUQkJCFEWKEIRYKSKLCCiiwkFFkFFAUUF FJFFCKKAKKAKLCBFFFFgCiyAAsFCKKQUWCiyEFiwgopFJBFFUAQJICAQEpAA SUBVSSqJRRCEhCpCEohUoolEKlEJRCUQkISqkKKlVCEhCEKkIVCiVRCSEIQq iFQhUKKhRICiyRRQixSEFihAUUkWLAIKLAFFkkWKLFFiMFIUEJVEKISEKKko hUhCRRYCwUIKLCKLCEUWALFIpAFBSCiwBQWQRVYKEhBZCQWKRRRRYKLJJFFo hCElVUKJRCiFFEooqEJUhCoQkkhCiiSEJCLBZIKLFFkBYoQixQIKKUQqiEoh CEqiiSQhRRVQhKqoQohRCSEJVSiFQhKKKokIQqiiVVEKKiMIosBRSAosgosk FFJFFhFFgCiyQUUgsWSKKSKKEUUFFgCigCikCKKCxSCiySEkUWQUUFiyEUUh CFUQkoqqghASECQIEKhIASoAECBKlVRCqhCSEIQqUQkIVRCQkCUQlQhKISEJ CFSQhJKIVVFElEJKISiEqiIokohCFSpCioQqqISpQKQBRSBFFAFBRSCiySKK EFFkhFFkiikJFFAhFFAkixYEAUWQBRYLFAUUkhCQhJRCpKgSggAAQpAQiJQA QKAqSqRUklQlIIUUSiiEKohRCpUKKkIURFEkIVKRFJCEhCUQqEIQohCoUVIQ lEJIQqpCFQhCVREUSoQKkhCQklEKkoJISFFFQhKhCqkISQhKkIVCFQhCFQhV VCFQhIQqiiVRCSEKkKJCFSEKqCiwiigKEixYSKRRYopBSIkiwRUkiyRRZJAW KAosUUhILFIKLJBSEFgKAKLCQUUBQBRYsWQUWQixSpEIgVRAJRVVCSIAoACg AJVSiFSFQqFVAhVEKIiUVIQqoQkIRRZIEWKECKKRRZBRQCKEohKIVVERRKhR UqEKkISpCFUQqUQqQhIQlEIBFFBYoQUUgosCRRYoskFFkBRQihJFFAUWKLFP +ACQhJIf6AJCEkh/2kkhCEkhqSQhCSQ/+ySEISSH+gCQhJIf/AgQCQh/+kkI QkkKASEJJBJCSSEA2kJIQCbCBAJCFCEJAhIf6AJCEkhQCQhJIZJIQhJIfgCQ hJIf6AJCEkh4AkISSH/ABIQkkP9AEhCSQ//mKCskymszr1I8gFHeL/zPBgEA CAzv/kR0c5AX/fv+AAIAAQAAIAAcJG/juqlBAqoOCkqAAVICU2A0iBrKigKJ CmzUAAAEFSU01NmAAANBqmqBoFGtFUJJUCiQABQKG2RAFCRIAkotmQEQrRoo QgDgAHvevNtY0KaVo0kCePvh4Lj0z08c5GerdAjjsHj2Vh4QcR17w8HT1z03 vR7w9rts4557x07ep9NrGi2KZNJAee+Pbw6t429486Hp7x3pR649ul7Meesc geOeve4ypDuPO96YDz117Xeeh6I9PeoY76KKVbFLWCpU762wu45xVD5hwm6V cKeVG573jTvDQC9Penuu3obqa1heOWRw1snlc+mjRIYzDVVK8eKn29673tPW 6e9WdTum6OO7g708s87rvXtge8YHKHEGHueuDkzr7FVIoGzBkJcPh9g8e914 wWb1bSAUe673lM71lFlgBzc73sPeWS7cXHk9DvN468U68eqvoBTRZmKlK+ef JbG708PXneLNcVGdZvGCW5bybemx42e2to3THemjwgMqvctDFw6e70vtrQtm mhZhiqL5JjNCsbbb3zemd7zR67w8Y3XuB5ze8uTrM9Yd5j3gd53XgV3nnnk0 kC49U+2Mimk2BoVfN4zq44KYxjvph3k1PJumO8ou9M4Hnnj3i45dRXr08QM9 butzrelvHvsUGm2orTRVKvj7p0sX3mC9Z5723h095byPOO8w7iG3ZnPI95O4 wczPOy7o7wR7u0aFnXxqFEjRtqJAffPoevCPbyoSOnvY82DPUdd63vWmb3eN 3a6diOR1OF66no6PHZ3qU9AaAkqSpSKChIqSQKBIqpSUFSAAABx1U/9jM9VV SpJp6NI9TEBk0ZGgGmTTTQCJhgqVKgAAaAAAAAAETYQ1SqU09QADQAAAAAAa bSI0lUoAAaaB6gAAAAA0/VECSqkADJk0AAGmgAABJqECVSMQ0EaUPJD0j0jR 6m1PEm9TSH6fp/D8/2fwP4a/T+FZ3+CqivKqj1Wr+ZVfH8x/YQn+B37D9wn5 n4n9D8T8Hxs/a//P/Cv9P7N/1/6wkn5nx+B0/cWfilGFln8DBKNE/aYbLKP4 FHT+JglH+v6v1/lt3X5/+v9v5K/M/HL/JRv8hH45+O/it/OUsPmHcncAjI3d 48eKKVYVe7OzNap7De6OqEKI1lqwsDbm8cV3NXJ6rEBu8TtMI3MUVDULOdrZ 7u5gEd2xlpqKbLCW0GQ1OW1u0aW0AcmjjhjmEUUd3FUmilx6oki7Gg12u6fX qHKZwzqM8uiElgXb29Uag17HMD72ULjQD2AAXz4nI7ZnIwjL8ExymXbbYuWb O6klU6VJYJKwBEA7lpcBpGR4tNFSYxHlbye62LvsJFUpS6VyddaolQbhw9xI iuYwLhxvKWqxyy5djuzceEU7BMYUYFdG85yYMJRjYulo3CUVKNqLXZnaktcs grblmzgqJQtYXlXuWArzgueiszufXhuG0ccYUqgGhYpLsxPhua0kktq94kqN 8Tk5PL7eJ1YdRIbtI7RNHQsZapJdentrs1Q5dQzqygH1xBXSWXJK5YEY7IzQ HW0sHFKiCUq3bM169vGRr68VjbYwiiY1wM0zOB7rpLVY09nIBLczOuN3jb4U hLwG9tcL8A+7Oy4Xm0gLxZpl0E6yekIMMmst5WlY9EV1L7at4evf2Uw3Izxi zdXEZWEg2ftxmhIaQvANPJI0/O5enpiwccwzU67cy3w5LbF25GwHhs5DpzLd 6dOLShNqWppRcFR1dNZZC4JnJmXqVrMLpC2K67yWDN3ke0mwy9e5bq8JcQ2s FaoR3YeTN3rF4OpNvNayMB3sezT61eE527mEpZFI+Liy3fZlrsw8cacQD3bm ar16+VwXNWMLr4HDM4qHLgsj1odCnJAro9TodyzMXQttrV3MANuSSAAAAAAG /r++2bsR2bu/t+t2SJQAAAAA978DdAAAAAzMzMAAABbbbbT3uyTMmwcyzu/b rUod9wGz77nOA7bbctoA7gJCt2TZGrJcSWknSUnJauZDEa6eRPsTJdXtttAA AG28c45zgKttttoJJJJACSSZd3qKMRwwniMsI4gXpjTkknNtiAasJW7uyFQ3 JO1I6SZRzq1pct3dJkkkgAB3J717csvXN322/fs7Ynvfd4qiR5LdJPNRySTE aJ4mW0kuMmpK4Pl32zZq8WIoASTmZhkg7JI5xme9zZJMk+5yAUAB627620Ja B3L9vd3bvPemXfrZKJJ6Sdmz6SSSne96AAAHvvbvu7ugAAW22236222ygAAA AAAAAdttuW0AAAAAAJfrbbaEvckzm3nssr56Sdi2gDttty2gAD1tvrbQD+AD +ABP0kkPpJJCu/AQAB9u7u5oAAAAAAAAAAAAAAAbby220AAy2SSJBM+k7JK3 f3Oe563NtoAbNzMNi5mX3jm7bI3AuTBE4KnjTSiMTcdtEK0S0us2+R13T5+D gv0tr933Y+s2efOrO972JSJJJNJImTd1AEi9CBgGHW6PC1gEu7j2ao5Ekokm w0khEpq5EnmWXm83d3293Ws5ItoAAAAAAZPtzMemZn6E3czeLu4kUWlkk+z4 zt1IoAOSZmJvOuxtKMzMzD76SSSQO97u7mZoAA5r6SZJB33veBR99JJ2e7JC xQenZ3O45hdz3bhZRlHemEHbczCSHQVOe973gEr9edbu5mbbkjbTTbiRIEmx WlAyAO82+jV89EgAHSSJLGsq6VYAW3e4SZrjdckmhmZ3rv2Dve3dzM0AANde 7u88kiUTanbOVyLXw7W2k3I63erkW8CShbVy9rVTZJUaVxEkRKOSSUjV3icN bwLt7W1vKlIr7aYDKvh2xSEC0NKGn7kyyXr9JPT2l9baAAB9bbbZQJfrbbaA AAXO9emfSTknYVUAE3PPzOPz0irj+L1/F771k/l/gTd3Mu2SW0A9730+nvbp eaT262RWTZ9u6SWnJsnt0st5Nk9+RmNxIoMn0v3LbaoOTk32eJFAAAAAMzMy XefAKGgyWkisx3BkrESUlKjk2dJJGZy220mZmYQD3vvvvm97u7oAAAAAAAAA DG9JOqWH3LckhM5Q8Wbp43rySdu7JdypBM3JITOBwkSRNtExJCVMPd3Kdp2H iHzOcLe8hliW3AO0nuPNQizhMnr9pm3kS2wAAD8ttttoAAAAAAAAAAAAAAAA ADA8G0AloAAAAAAAA8DAAAO970AAAAAAEkkkkkk7q7u7iSe5EmQDNNKRXipF IBySSZIAAB+kjf3JyfT7g3lmz2txRt7hfDteCwnfcZ0xAN5U51ml9dzIUVFJ JJAlyOGRJtmWbGxW97l2wAPyfn7dzPNL1bbmftcl7IoOBmpPZj3srmHupVug Pt3dLkIb1Ur39vMbpEAett99JFtlAAAkkkkAALbfMCO89z1tigGSfpu73e89 6pLzkUoHwbkzEklJUbbe7uttySQDagN6eknZrbe3ZQLbbbaAAZmZmB9u7u5r Mv27vrZ99MqSSAAAACR9b1mZgAAAAAAAAAZmZmAPpP257CT9f2fe94w5P03u ZUisn3pyfd3S2UAAAMk/Td0ktHZzmYabIADJyTd8SWgcn6b3MJFDk3e+kJIb QhwAloqu67YAy0kkUzHjbey26zMxFAAAAPk9vtzm8KtPusd39ftk1v09mewh QAAAAD6cmZniQtm7upFBAbJQqYAOEwkmRpnKyGniOQpaWCt887Xt46jmpHNo auMYnY0tzORjckkgPfa+Z3i973F1QAAAAG0PW2eltAffADLb222gR93vXgAA AAAAAXX68ttsoPW2+tv6STu7tY3KYVvCYk4pupJR5CTRKTbeckoy6AAAAEzM zD69m89lSKAAck/b3MNhJJsit3jPu7jOhVojR6LmOPQ+tal24KdkTt3o+7iV vI4WA1JHU+bLmcR8dG6Owh8a40UrRJ4/L6SRO2223JJJIdLfa8jYHMjtre7e 7zbNme32raBwtt73vfbI9bbUkq33bxunx2twbN5oDEu5QqChCSZIAzMzMAAA AAZ+zvBzfu9ZA/P3e97mZmYAAAAAAZmZmAAAAAAAAABJJJIAAAAAAAAAAAAT 9JJJAHv3eAih93M5ngttoB623331v1Treeu3N799vvcvsgBcbfe7JJqgAAH3 7n3DLb6Sc5zqSUAAAAAAfW222UAAAAAAAAD1vp6T0WgAAAAAAAD3wNAB+tvJ JJi0CgABl+vt5zftTFAAUv6vuWfZzzzrbfSSuSTnczv7M9n2EkAAAAAF/d73 vOOgAAAAAzft3d0AAAAAAAAASSSSAAAAAAAAAHe96AAAAAAAAP4AffP4AAAA DLsvLbVlD8ttttrLb236+933qttttA+c+A4t7Pt9st5dvrbQFjJhV/WJPt7J Jrevtc1vxXNtyo7Unfd8fvvs+774/VjuGs7eOAh71REpaIxFqOQjKJSHdXcl SzUtNdeXPODhs1c2V2vn14oTyjbtJXesWSSt3Xwbkkfd3QBThOhkKklcThJM kgSxLiy9khOrK6VzeNxLElI7b7Mb7m5oQAAAAABJBxd6uSUYAEq4wFRqMBxI MC4pM7CS0ABmZmYAAZPSc3SS+n6czMrEm7tzZ+s5eW22KABAirJMiTckVasz uTLZVXdqKPuSXckprYB+1V8lkWkivvqS+wm5GEZjcw11/dz2a+59+tzmHfrl sktAADZeQUIEUu2Z270MkDK3ErMUbUVpUkpLTbbadOXIpRRMN3AcMGKPW0SU xQExksbQyyiB29V8bguRSGoxWJdO7u4ttvmABN0bckk5QpVMW6QEyknU86a2 smyKJIkSXpb5vhsxR26zibCJUDlkA+mffTMAr5+PgFv1/S/XakmkdUb3GQTk s6egjAS1PWWx3IpKGzvLb7fve9biUtkm6kVz7jcz3mj2/ruN9yz9e5hv43d1 IoBmZmYJJJJItGltSOQbmHs7r4LoYAq0WwK20dXVCjluPoFpMbsncrDsSUk1 LT11khMKnNtyJ1qiUfcS9SSuwBdgBG4ttoAAAAABq8tttszft3delt9bbf1t ttoABnd3n7Obc72b81FtOW227aAAAAfrvf3XjQAAAF/W222gAAAAAAAAAAAA AAAAAAAAAkkkkA9bb620AAAAAfrbbe9722gAfwAfz6222ygAAAAAAAAAAgAt ABJJJIDe7u93QAbu7u6AAAAAAAAAAAAyTkknffe96Azft3d0D6SSTYAAPu95 0BP0kkkHbbbltAD1tvrbQBmZzoZIZ7s+8eTlkkyQBmY572ePbdm6c5b62gB3 4Pfve94gAAAM9e/Pl/J9JJM2csme+ys++zMzJIHe96AT9bbbaoAAAc586Hf1 b93d320+cAAB9708dTNnJP3mcSSH3y96YpJJJLJBckitZDAFqVkrdxtpCd7P vpMktqADeTkkmwfrbbbPy222gcAQAAAAAAAAA973vAAAAAAAAA7L9bfu/vuZ ZS0A7zn3ygAHLfts1re797ZjBcL6O9yA1NvHApLQVjhItMiSUKSgJOZPjdxo AAAB9CkQZHREsAeHCwA4lHJJMVI6BIlGAAAAMzMzAvv2sXW9iFcyyzJE2L77 eZjdL+AbM5u7qds6Qa1ZCkxYInZpPurtCo0a3eEJEBhBrDPde+Absk+n6T82 p3mcWgS7eQjABxRjvNL2ktWNpRTUr0a3fTMy1JueZM3t9AloWz97PsbqA/T9 NzMJFADHfeXbdktAtn3s+xuIAAHJsl1mzO/fbyz8332zb3N/c9bz7zM/dnL9 1bqAAAAAAHrb+7JPottOXzPezyirbLbLQAABL9fpJIspJUy5JMrMk2znd0Zb pLdYV9wpgxJc7aAAO223LaAAAA/oF+cAAAAAJ7e++euXtkgA5JJvLmdyyV93 M5nGTfZ6akskkWiSSSQAADPe94Pfz7vT76e7/Pfz+WfygPTdx65u2WgAAP28 4MAAa/HQ91Z4LtdigoSC7wzeSSSaGcXD03GgE5IAAAAAA9JO5P2ltsA+9JOy bAAAAAAAczNmfjvt1QAAAMFcLMEjkonCCouE5bgbzp0kkhAkkM9m8Pp7Mvt0 930/PtjrtVaAPvnQ0au06S9aQDPJ2zvK0KVcLQQNtJLdSSSb9u7u5QAAAAAA GSe3eb7Ptkkn6STmfG93t2z0koAAAADndr9bm/YjurLxi/cXNOpiHSVhzWHw 1zKk1R2k4FADhfd677t9vju/ve3MctkjPoQFI22ncIHc4nvXBhDpgd1v3clu 7NzMzMlAGd/d6EAAfTlskmpaAP0bn7KTjdM20D6fs93xpQAL6zm7qT63M9jN AT99Nzj2Pp33vYo2OTd3Ei25u7qQocnI8TI0N3S3iJMK17xI3i1NbbYdKN1Z bxuKEwkSlGWWkkY5G+nWMu8AgGbmZhu9739PZ3GNLO971XYvnn72uOO/V98/ EdWXaez1zNAB13qpJmYAYSZpE5hJEvSSsE0rpNIGA7bzsbJOa2xciKV091KN tNy+zo0OSU9nOe4t+29mfrORuxbbaAFv1zMAmSlyk7ZDJJJJIqCsAcL8E8rd l5le7ud3c9g6AAAP1tttu28tttsv195mYOW227aAAG28tttADttty2Se3ebV tA573PeB/bf5lt7bv8v8ABlt7bat7ZJ5b9z7loAAAAAAAAA/qZmZ/M/n8/n8 AZO7vMFn0W3BZwklySaSd7MJ6S0kkipJI3fd04QAAAAB3nAKAGSckkgAB+z9 mTl5eevvbtz3ec93fZQAAAAP22ZmMSd/b2YzK2RhxOSRxttuonrbY01LZFK6 LjvMYLAlHCC4k3gAnLJNSTJJLixKSZJyfZnM33qz9EkkgABbbbItttffBznD qr+97vmNAAEv36SSRaAAAA/WnPgKAOfgEAAAAAAAAAfW222UAAAAAAAAD622 2ygAAAAAAAAfW222UAAAAAAAAD6222ygAAAAAAAAfW222UAAAAAAAAD6222y gAAAAAAAAfW222UAAAAAAAADZ+3d3SUAAAC1bbbtoADlttu2ne/WtsFtKzBf MPaZaiLTtvDvbnNluSU7bbbQAC/rbbbQAAPve93wAAAHbbbltAAABn3efe1O ++5s+wqUAAAAAAAADOcX9ctttAAAAAAdzZnJOwktAD7d3dzQADktnt1sUckk C3erMkEpxozuiwYAhKwkaE0lAZP0m7pE9zeZlSffKAX6zd3Eip+tm7rZFAAD 6LmdZgoAH07N57CRRyXm/ZjNKD74B+lvXebzvm3uzszNZH4tttspCdSbiQSj eGSt2V3SdHAQzTS7pppb3Ijq5cU4YlGjmDmcAlRwq00220/rbbRb+v6SSLaA Ad73oi3lttwD8t37bN3PWSWgAAN3dfJLUlHjbSSjMVmF8MRcpKNJGNNyXJKH ZsyMltptsNJKNqOEhK9pUKXZwJk1007amKNRin2kbO6aktSm0AAAP1tttxOS 5l+3d2Rnrb6+u3My++y2SB77OZmYAAAAAAAAAAAAAADu7vf3ft3pvZyTlkW7 Y+tttoyTkkkAOTdPMxAv623kkW7aADbeckkja/W2229n6Sekltttn7kkntsW 29yTk9JAAAAHdz639y+y2gAABPjoz9JyT7dLbO972gH62222ipJJJSY222Sb sk8G5zw1EkEpJI3bbbQAAAAH9Vtt/g7/MzMzAAAv62220ABn21n3HtFX9bft 3UmwAO9D74/SGb9u7ujN+3d3QC82Zyt5niUBJJyugAGdSSlJQk0SFhFOdEuY Be5o1I00E7MdyyOEEjkiSSSUO9iSCN2SZJQAUn7nemAAAAett5JEyKRn05+o Zmolt1K+l/etnVtt3v3l7bm2gCfuEm+9vwlJI5JSbAEBNEkkmJd3SHmlU/C7 7Ad+6p8oV9TKbakkk6se1L1hthVEktye57s/pu7u9ZznPelbstVwBQ/KWluW bZyRJlXbctvbV72STMQkzfvsxlzbJAAAAAAAH30skkirZbb5bbzJIv2yC8zM x9q23Z+5u+z17tWgAAAAAAAAe6U1yW2XbaC2223FvbbaAd3d7mC28W23bQBV SSbNttttsv1tt5N3MuTmfnPTrNA2fftzMJFAB2225fo2iDCkmq4WJsy9611o KKKaTCAZUhOomRO3R6EzekOmcObwCHAy0o43WfZ227lqhSyS73rc3MQAAAAS SSSAAB6e89vvb+3WAOh1lrRJpDETC4hoJu7SSSSku1JJJAAAAD6cZme80Pb9 mZ37tyZ7dhf1m7qSKACOltyyWgvrN3uXLJKvZ6bzdJFAffSSSFXvhiadZAdX Na+Fjla4OtYhOqd2Np2wzdns59JIZjabwts8TkUhVZvO7uqAP4mfbeXvuT+T +W7b/A8n07JJoAAH3xu7u6szp55v7n2zSVJjAwDW2uSTklJJJjQ7K1W9kjck g0q9V85ZIMUWZJ0kugAOM5x1qUWy0AAAAAAD771tvrbG28tu++knkjvJJF20 AHrbfW2+973gez7MzAAAAAcve7u77D+k7ns5lt9NmwAPrbySbG1+W21cud47 77e5Z9tkkAAAAPvszMzAAAAAAAAZmZmAAAAVtttuSU+5CHZ2RIrFT3C9KSag d3QhJYRq4ZLSEyZI51yluomTVY4+x0eNc9rdzTqTOzBoHTO5VZJgdhJttyOp mZjUAK+3d3d0HPZecvu3mZvc5Ppn05m7q22g533vAlttttoAAAAH5bVtt3n3 ZuS+0rm7uskBbbbb6V8YEoZbe3dnz0222OTtixNwgxKSSTloNmtmCs7eXJyy TlrvJcyoAOW/rvt1JABJMIspKSKTZJOVuotClPIk5O7km07a1OJts5zzfY+e zNloAX1nN3UigAAt+s3dbIoAAAA7Ozd7rP32XvvL7NADZ9MoCMtWSZEm5JCl iJMj2E7vJ31BgY362VCqKAAACSSSQCbmMb99bec3MxpQoAAAAACOPSTubsB+ n8s3d/n8q++1qgiWOu20pJHowbNkRL0kyNNyAAAB98AAAH0Wbm4kVQHktHN3 LZHpaHFtt1Pc3mYSPT6fZ2xu922S0He96DuX7c/c1m9/p6e5Z6YzQADskiZm YmcXI21amzVuOw3ksgirko2tuTafdXXO5uRuOkTsMMVwRNvHG2y5HoNkUYpG 9zDBiS5KIlYasOdXGbFt33dyRd2O4VfTW+LZ1vDwCq9Ld5rGuFOSQAAAnx0A AS/W220D9bbbbQAAHwft3JvcvpMk9FtAAAAAAJJJJAAMWxdtuW69JJc/du/r 32+++nve3a7fu9eCgC/ett9bAD7VttligABLmc85gtBmZmY3s5JNnxbbQAAA AADb3d3utUAAAAAADMk72SQ/r/r+/u8/s+7/Z/T+3+/+7z/339n/j+/rP2f8 td/A/of6H+v/oOvxf8v+Z7P8LgSSQhbAgEgbQkJIQn4f6XYSAQDdQJKIfmhI BIUeoIBCKAEh3KhIQkmks/tTQz9IST0JJUkk/3f7/5/9xkJJ+r8P5XZ0hAhD 8gT9P1an7D/Bs/YZ0okhA/sECQEZABGSQARkhJJIjCEjEACRGSBBGEJAARhJ ICIECAiBJISIISSRGQhBEkJCQRkIBESEAiMkCEBEABGSQJIfyEAgBQwIEiIA SCMIECCMkkIIySERgAiBAARCQAh7UPj9wet6eL2SSEAgFfqdJMT9ZQSEJAgV ujfYSSg/3b1ulyxK/j+l/mM/L+r+Z+Bo97n/kJP+Awo/vP1fFHCSQgEA/X8v 357/BOEpn8T+0w/uIv0MJn4wf8E/Isyy3h+OTeZ5dfC/yI87j8ta6AbQKdFO 1KWVnLK6zkt7yEjvt7U8DSzlhwmg5jpihSNliWWiySWAAEdvd1EcmKghJ3ER xwd2KBwJTdiAnZikm/ue3b37n3tds3sAAzvfvuj3eLMmySiQ7zmOtmz93cPO SuNFA5iJMTBug9sswTWwHFJ15GTUbt3mLt7R0R2JUk1iHXhxaN7Mu1i4tJN8 HawZ7cvOu9fuk7v7LbubtoAAOc4kkXWkoHYkxYyNN9BJBlnruR3bOd07MZiU gAFOmW222yySXFLRMjdbmLmsdY0yISHTSSpKN9yTYBkbSUcRVpEghXOenT3P MTQcGWe3uuyXISSTo/B39zvVt/TZItpDgzPe9JvvHSS2G0ko3Tck3d2Tu7uZ 7HqQGCJ3MORDHDM2ayxIpWNx02QgAHSGpWUufNcw4yjDkEk6U7yLdxlvFzFC Chdtrt6+ddxAb5JMkkmEkhSEmJJSSRySSRQDczMwV7ve/ge72Tv0yc/Ha0an mdwPXm2g0y4pIW1G2lUsEVCDIB3ckSkV2p9OO2A04teXbbtSlWLdGaQN6SYk udwXNqSNJVmXsOQacBIUJcbMSx867HY2u5EnZ3c3EkMgGnjBkrWQqndqRJU4 kgUFXdpNuu0lnhjrq3mr0wAauCGkSdNbRkk/hny+3W3uE6fvhQHxkyySQSMx RViREAHbuhTdu90oAAAAAAAJIM46dI7u7iRuyQtpKkpG6zG13dzNbW6XZEml lzQqXVvPs29u6URUV5a25tvupKdxu0o0lG9WPHu7sU7uzMaQ533Rd9xI6id2 vvlcN/J6jJXd0Lbe4TfJ2rXa94Y7x7zAwCGSEkkayd6n3cl27d6OA6M0SQD3 LXEe7jgkyM6Uua1sTZKzr7dnRY9l8sSSWUklr1InhBeSSTiSZDD1ii1a50I6 IruJXbuZlEmr3Xc3XNOIKMgAAztJ010SYEIs4CABTaU6+MRBKuVM21S09iYb DmKTd3djdRJIOKQmgO0925kkcJJJ/FUfOlyS7jl5gvaD99eu9r4rLYWW5hcx Mx7OW2LYDSusbur6Bdsld2bb6Q12R0svm9xp2MuDzzaXR9XSFzIo+bRsWArG yQi8mPH1ko5De7isDrGhpdqRCmYdhzxZRemddQXp0rNQq/e9maWyY62+F8WV Ojr1cmoplc9rdew915Zy8973JsJIoJgCySDOVXs9vmcnfGdzuOtc2aFfNCon K57fPd70fev2Ptd9o4ryqWKSHUgtqigICKgXKl3cqXdypd3ete9nfu+Wt+76 /Lc8dx6qTBJAJOqGqT6KkAqQCQNwAbZ7b9u7V+ebfVze+nvRt6XSSkkqpJjk bAAAIc77d8uvw82+2+d8F8sYMA4kAqQCpekipSSKlJIvVu7terNTQV1MvlxF wxyvVFHolOzlnTUEU9Tv1YxW2LK6se455GnrvKlJZbZe7Hylpl3NncusmE3z TrNV30B7g+6bdvob0apSywMs2Xby51J70l7OrjFJDhInPdo5u2Q2QdeUpgh2 8OFKjidrDjsgarzZmcmTherzDktT3PKsipNqk2oKQqqILAUgpBSCkFIKQUgp CqogpBSCkFIKIUkFIbOc5vd9703zVVd5u4HCLVFRESUBhzQVbtENEp5VUaTv EaWPCcbNt+qt973vU+gpDDnemjpl6tzo8ILA6SNMH1SrYe2e5fjXmt3erqTB SCkH1SFzNpayHc7vFvFSAVIBUgFElIKkAqQCpXJFSCRUpJKqqWd4K7i5uzOZ ml9qlKuwifAO87FzPXrju+gDlrs2M8yd4tFfC9e5zd22SOOhJNqk2qTapNql 69nM2p7bcRPCZk7tZ1emsXPdRbmhTIKkc5cGAnjV1vK76BdvRQ5m329Fqhyl l88tLlluoXm1JYnV0YcxnCZTWUc29rAW2Mw1pWDWNw5zqUW8UtCjXjer9nbM KNtnfa9RBYMOqjv18NmHWzndd4TshBJSKKc1w2WdbNc7vuDCRCOgAAXdgAAX LsAgBcuypLioVEVJa+GHJzVYd7vhsGE2qHb5rR5L0997niDWuHUrr7fIFAaz KNt8fb3yiCkFILAUBPAAMbdVw67cOd6chMOtbnHuVzedd1cZ7lTsCmzXnV+X F0dudr2za3uoOnrusopXMheQNCYuEjjlgzGe5uhNuBh6ipG+VmSdKlZrPJce lur0hZThVbLm1ttqZE33Iu4cPdVnY+sZQfMcSiw+lBgKYybe3bkK448dZZrZ 2erhveUZy766O95wnZCGu86ms495bzVqqjABed93Xp3d67672AAAX7lc4Zlb 1yt8pV9CQqqDl2qs7AkLt9feeOPPaNa2BBNKrsBSCkPVdkKqiG6172X3Zrla z2d0QaogpBSCkFIKQUhpIKQc5zvdbOa7ed7y8IKQdUQpIKQUgpBSCkFIbu9b e3rvezOXVkO1RBSFVRBSCkFIKQUqEqenc21Or73ear5QEu7CgAu7AAAu7Kkt KhKhKhKhWwAF3YAAGuXubd3zG33K8WyhpuptJCZTT7ZN6PUzNPOMjeSWvaXc dnHJDeX2xxulXK8aOLY46Ord7nexihcDmOjjKNjMgLYoYWgLrLgyXlkZk2ku IM2mbsSr6GdiyVmgyzV3gAAGZmAAAZmYAABmZgAAGZmAAAZmYAABmZgAAGZm AAAZmYAABmZgAAHd661OTL5r27zRERANtySNt2AAADYMYXcu2AAAAAAAN3cl ggQANiAABl2Rtt2DAAAAGy7LbtsQAAAAAVVZlSVS0DFILAppIKTCYqa7mvPe 5nuTUX4AADMzIgAgl5eAhCF5eAAAZmYqF3RKpVXhx5fDVlbzjpRDwXzmcO8y 9eazRvnc5ub5rNdazQR8sAM77ObWp821MbbbbsAAAAZ3pmLq4dvHZYAAwAAA YDbfHmYuLh28hfG03jQ7YCGMBADGAjpnHiO8nbMvkYAAAACAQ1SYJU2hqkND u3qKguiRfTsCANTZdZTUdhTZeuaelYGmH1wgQ26Os7rfdm2ubrbUo5ZoTW7Z yYdD0iW8Wq+scrTvGbWxoUczDuKimshPKOA7Z5cQyqYJ7RcFHdyVyOkiV3Df ZyzDo0qGOkhjSGAAUAgLpyEqnIc7M5xcfZLuPLtSRtNtMSQCpAKkAqQCpMnM xW+95M6uS2qbTTJktttNNsuwAIpJKUkbF2AdeZ3q5MnecjnMAAAAEgEkAqQx 1SASuosEPCkHMqyCkFIKQUgoxIpDXc5fDndX3db1m910gpBSCkFIKQUgpI3d VTVVSqtgVVEKqiGtbzb1ZZ3DNvVSYKkwVIBUDbbaae97yuru85b7u5nM7xsQ AANnlJIqUkipSSKlJIq4t33lvsl7Odzmd8AA2AAXd3d3d3e+9v09Oc9M973t d6AAB3M4aurvDu93XneVSbqk1E1U9sfgzhG+9W0xVXS13jwnRsDUp5yC1XMb XTABtNbOKhObfdJtp0cszG7VZCRck1mulqd10OVpXcmMagKeWbU5OPL6BW6u hJml4VtsVly0qh7RWdry1wrhKSWxvuPq972XudeIUG9bT4Kqra9XrY05poMp WHvdZwCYLAUncrV6Nc1fe33rrfNQUYbWJrO932zpzXN79u/e1vWOuywwIsgS mQjOlSSRKZFCpJI0kNujLvxw33lnnvueu85300AAVEADCmFBAUJAQpIKQe0Q qqhYQFIRC7osJI+Pe7g+w3uz03fXnfLWm2223lJKgbEgDRzb3O+rLdd1Xuev 199eG+8VVVV0BVVCAVS0e73Z7LenXN0dfXz182oioAZ6c57Wva+zJ7l67fn2 e+z3AAKqvh7QVjzNcs5To9kTXdrmr5z153190K8zVnGXR5jlbjzM6PX1IwW+ zFLNJ0cvpZzXWqoOWcqbWJh2bQ5MU3ZcjV2r6nk4tHefdsta8ZRechzoRlsI AipWLFljiLyUuR6XNTnCoru7u7rxCWze7lRORY7jmHnXqjUvRQ6sNHJb1zex +LYOXqu+4py/G8857Od9m/BTNqq71srvaOdte3nnMvfTNxttvoMAAAAM97Xb +1k9vXdefZ77Ne5y7sAAPuX3OXexd8py9fpe+vOcb6qApIOyknJElJAAAGqQ xql6bri7XtWqa/Tuz2PnGqQxqkMdJDAGDbbac9M529Zxetbt+YzosdeqBl5l SVuKWDNjp16jiyI6w7FObcGK5WBUul1lGU7Uxl7fG+yjMoHXbnNba7V27qY1 9SSZvr5TCnRzsKW5Sc7muJ2JPq3sIfSz2hq7GZKBcA2KNluutRDRuhcsZrZk rpq23w1ITLdtUN6+932deF53dZWjeiuvud9ndgHkgpBSrDmy9omsily1vE0q v1G/UY1BLmJVpXrz1e1sTQyWVz2t16sw4dzzztahsTSN9TfOBnDNmYrU77fW peNtppqvcWm9MhbpGtHRA+F3deFzZ2B1C3W6pfQSvUy85qvV7Oe66853V6ra sGymRYCyDlu3t94u5pPWplxJNNPgAkgKMpDbbogqTBUm1SmZ7M5nee9mSW9j 2+9bzU0UnRtWgtOyiquYjrQQLm3bjfRlYSc25Bh206smktwIKrdwzKT6HbfY sN2Mhiu4d2toFsZhDtua769WHYbKZyZeZyhGLmT28r6SlM5yxyLEr1Xfqq7q r268kGEMmR7TpTVEybr21V7dKkMV9uqZT2/l+3ipPjk5m+vu/a39NRxn2rsA AiMrX2r4932s5zvPntfZdkQOXKlxSQpaohQ0kKGkhQ0kOXrHXvGa9rz6rv1i kfCkDTY0wZKpJOSKqFJaiklJRSDZfXOHB7neczX7bz2PpSVVJJTkipMUiokE FpJSSVSpSQAADKrEMtZRkWU3L0qKxeOvUSTVeJJr1EmKlJIqUkipSQCKkpIB kswNm+73meZPR5AAAA8qpKSCAQAAAYot7ev2fc729fO/W5y7uXdhCEID9PVV mhV1ox3fCriKXyRObuz5dhaKsLYc1Vw1lIVoGyDuerAbTmWqsFdvaJZd7evh 1MJFVZGlmPaxJyjtLKjhwJRZB4Y2btHuURJMAACSWd2WBvY7mYie7dFhs7Hu 6WcmHVnaWODPbzthQ9VuIvmjgA5zn3we7z7d9vt0GSdPfbvcKGaRJCO1R4S0 25IqV33E6t3KSxXDAdXc4U5eMk1JJLPBupy153a+3d3l7QGl0x1uZIQibAmE XCFu7gnFkpGc5x9uTdyQAAHOcG1mZ32PvfepIyJZeEaBxyGRdqhitas4xX3b O6NgCi0AHzZDZwk8Y3fPcdBTVyD1GBmi433Jbs7mAoQIFyegmmyR3PXmETrw dJS7u67JchJJJkkuSV2ZSShSUdq20ZmZmXttZ73hl4MA/A73dm7siXWTqySK 4gIqaM5oWpC4nwozaSJ7uQ7O7uGntkDICMckLYbUciwAU0rRPKTuu4gpcojT ZLTbJJydndkkrJJJIC2222gBuZmYK95JVJJE0t1IB7goM7MsNq87Du5SkPRt KNtLzZSy0KSk7uroIkklu6etbOm82C4Bsauy+eSnTbCV2nJNyU9HATLMdzBG 2kqQYWEnRl5fc8KVttRLbVbixIJX0K7tndfWWWmySp1dl9kpk6kLohmVm0ie NdQC7jiVLHZj7Fu2G2XE93Yfx9I7PwCB3d0QI/YHu4H8ScL7dGft/cbzZ7ve 7L+7377vSgAQ4ALbbbaAAGc73M7u+7ve572893pInaSKkTy8dDuHN8u5O71N N4psmtqzAB3XabbeR8u16H3FKAO7bkjttuEmSE9seWr3Uskz74n6KS8ybfwP drT+FAUI2ABdqb2E7Qe60M7r59CQAI4kkm3NbbHd3M1u7tNFokm+Q5uuA8k5 No0UApIQdvudFnid2dKTXIMTs3kkltJJYyRvXcySSQkmzM7Dawx9fXIydo7u G3HOSbaQd5q0mdz4KYTZ0tJiADmL2jIdHd0stLqcWPUoVb1sdt92YNGCokkp EtzHWoAAbrLYAAsfmVK/Krn6MTcdb3xxD8OyduspOjdr8HmnrNc3Mj1WQ2Dq 3MxNbORmE7tvodq06slPpCHaVkc6fDa56b7Maaay1kRDyzao0moDfc44Xt3R 59qCiYzOkxG3u8qGDd1ut8/Ht7r6Z5ifrz8UDbTbdgHySqSNciuP4++7zufM tnz/CqVJpKo/rzst/H3c4ez7Wsqq+AAEISA+u0ABVVUAOY5jr1+7hzPNea7A JyBL73XfcteXz2buvfBeO+m++z7Pnva+8ECHwAHAkNa33ZrPvtcz772Z08BF CRAiCh6/VVerRQMjOXOJhPV73vEY5TEjxS4RfegPVdhW/vbw13n3M+fdu+9e kSS5W1gHc3hm5VJMvGEEILPS6ymKV28QWmGrCnYtNsjQ4szOZe6E1eW3KwuV ZN8qSQ67Du8UG1Biq4jftSWLrOSEPLN0qKaGYmVMpGdnVnQF9h2k8NcRrUK9 zu63qud9mX0PQIwUDwa7lOb86dPu7s1V53VXV+omlfcpIudxw6KqvefJHaXs 37fM6+84ceQKqgUgsgoRQV1r32c59973MfZu73wOy7AAzeXx99ne99uD953x NPBgAxNAgAzF709z27g/ewMznkklJAJJGMiqpIAA22Wrft9zfe9wd6ZfG222 4qAVIBUgFSASlVUht0X73u972n3jVZ7QFUqqIoqty8v7f2vu++19q+/c5zn6 7AADkX398bvRjwWMKCrPrHx+ujR9tyLb1mLs6QQq0CKjV2i9nJLJqW9e9cOv HlE3yb7a5giWaiUAmOhfJrbOFiHntqxyZFYtZUzbrROG0HG77n0q6wKDVweg wM3tJ+W+tttv1JIBUqpUDeKgKSAVIBUphzwazX3mX72cVIBUgEkDbfySSV8A 1+c+/bv7fz9tq/gAAHtb++MXls8+zPNtvwAAAwYABnuel+43t+7J7OgJANtt qk2kA2BM0m5p73Lezi6234BsAAAAJkw7457jnu77nflSpSSKlSUkipSSIGxK qYUlVM+Ba3zvzr7j9hysNPglUVAkaVVWiEAKSpgrxd6cPd2dJnk/NhTEkh0l VUwSpJJi2vG+6b5wylnkfFfe+E1e7jx1w6j9w7Gc0n44qNK+OMR6kYemwjU7 C6rYuwls4Jh7uKNPKNC9QcZA9CQKVHZwfT3I+7Y4FlnMhTQssqZWCAaN247T iECFCLDZvJ7s4ynql9k+r1VXrWVRAjVSEI1RCEKpfgWFyEYUkG7kuJNi7sAA Iu+/rn7Nbmv2v35qt7tYFIfQFIKAoDKEgiQREQERCt81O3rZXeu8vUDoADjv xc9nZ999GenhAAKqUbuek97fJffLrmgRicnOZszud66roHwM4Dvrs7R3uO/S RnknuVUrzw16/e7uqhoJFkAHfKqofAVd2ECXd2SHrGex6b5Z72nXeeKqlUki qqqqkkqlVUkSSqqlSDQAAqqKrPHtPTW78+73l752qEVVVGgAKvBd0s+Mq4+o 813LpbFdSGHlfctpJvFOFnc4tq7HPZwUJe9edC7eUaF6nGO65NrupSxqE9oN V2tMLLOZKKaFWWVMl0cOrMZJRj3pkUVAdmkUsbsFTw25XO333a3e98AAGqAA KoVqSA1QAAJplVSoO87tTj1c7N68zE4uIjafELwRgFc7K29ObvvNVm+FMOxY pBSCkFIUgbsWS2BYwESCJBKooIJdx9W9i07k2uuYJttLeZsrY+q+xT3ve1n3 0eWqEAB7vc+utY9NdzX2/vey/bVVEdkCqVUd7rzU7T0z1nc37O3me8qCqKoi DmmvNTlPDPX7PX3uZ7zbsTEwAAAAB85PXVx9V+i9ft2T08AAAwYAAAU2d5PZ Vx9V+imb0Um7ZSphVIYwYMGxAwaGNL5JV76ldasj6oR2OgN+V9y52ThoU7X3 G2F3NyY968EwyK7U6GxwSuUS96+hToUDnTqxLOCVbINC7EbpskI53OsF4BKz XBjUTWexGEmr6J6nfOelGtpA9c3sQFzLflgsnuyQ3vySUkAQNvHQMoaAoCgO dZmlXHiv0U9wCjSmFAUBQdUohTEIaTEUWZvNLrMx9XNk7yd+emeoqUxrwBcu 6lV9ADICwFIKQUgpBQYSsMsJUqypWSSNS7kjVT7sbz4r12+rgfLPjt2yvalV IjUiVIolFBVIoKpFBVJklUgKpEkqlJJUWTeblBb4s9I+8ftx+9HIQkjqqpDB tpjYAg7vbV+I17jw6uA+Z7ueNgAHUkknI2IKpNjSYANmzuGWVd28Xg08p19O wAAABAAw6/kkkg7VKq7y7vPl1q3Zy/Zffu63zoAAGu37LSb1jk5dveZzfAAA O95ntWrm8dnb1l99u+7zoABETF95l9fs78kYaVOlSvdXM4TQpvOYy3yPS8cm McLep1Z7TmYqd5IjdwnGzkOyXSrWa3dt6TjoVxy6O9l+atOmulRnjBpBTNq1 wN9m6stNMklHZRpS5a21p64bh6+qZt1z2q5y+KsAFVumqXIESCkFINqk3STo HOXevcXeW7XSQ7uHDjfQAsCwHCtaabbSSbttu9EuZUvFarQTx53ulTt3MOZl olUkkSSlaSSSRSSJJVIpUzhlx1MVqtBI2MZC9yikgkkru8QjmZl3d4Zmb1kh p1rLiRSChIpAQDHMyyTHMx1Xnvj28cOXV89quczzw2T3ve95JIgFEkqkktr3 m22kkvVVUZmZkAC8zMgAS9V5759zHF7dXzHe9znkNkopJEJL1VVUEUiSl6qq qtJWSUSkkklVVVV69EvpcxWq0g7zG65mdlJa1rQa1mtak+AUgpC973veyCkF IKRhQAa1rea3RBSLAUSUkFIKQUgpBQZve970Q1rWtaIa1rWtHgNGtawDNua1 oBAUIEUIVnrOa35xs5eaes/KQqSvUAABXqAAAq6qqqrqqAAAVOklV3cikkRJ JJ9cu5JLpVTL2e7M88drYT62+vPA2IBJA22VVJIClVAIFt97rxxciIt9g86D bfqBtsqkkRAACUVQBCAi5dwARAARIQCSAElSWIQIiBCIwhNew12/ZeuZYmX6 /X8ldls9xoVujNG4r1HscPSCFZgKnIAJvYFBb28nKlsweQFbu2y+6hdEO0GB t+eW6R7eZ03glJu0aChN7hvWWOvefaL62plyhqwXhzopas09RXS8fXQ96q9d Q+AASIM653vnGzl1Z3zr7vCfRGSNtBAlVFqSQSmL90o16/nBs7de+c93dIuw aaI0/EBpohaQUgpBQEKtq4IFW1YCyQGJAEq2iWAAyrsIFU/OvfNjw6237593 nLVV+rLqySQl1dgAVVAAVQrUkknObz5Oe3842bur+PuapfghJBqgAGsqrkJL kAlUqkgGU5Lqqqrk8+9zzt2vQ+2fbJAEHySSQQAABA2AP595vvnjwvLz3596 7IICINSZv5md++vbeXme+h5O1SAVJgqQCpMFSAVJpTznt31u2gTs0S7u7r1a sl7vS1a0E9U0eJoC2VQCBtsTNXpud51R7s57nVfHzekv1sm1xoU3j7bfaust Yu67E5w5hbERqBoxLJdOleZ1km8vSMurW3eWdIoWndFvk2HlnIesZV8e0Pdu rQ7e3TzWlto5K53d+z3fcdtz77nW29Xmem/dzQGrsCtda13vLrTrVXfNvbmA KQUgslMpIKQUgoGEFIKQet973eqXWV3M1e+3mKk2qaSHTpt0tMiDd5g3lk3H sUQAKAAya5lnL47y83Xs7t1z2pwZsCKBBmnHu9u96zVXfb13g+wPEUgoaBSC kFIKQUgpDV0EAqqJJVLjj7Permr1qvZ7aclqqr8ABVKqnkIpBzLYie7nwd3U r1Xfrqhd3d+gl8iubv169x6WrBZBZBZBZBZBQnSCkNX1vM7XNXrVdzut1zwm E+BQUgsBSFVRBSCQKSCgw+3vf271d5mtNddr5ZoS+T50vdo1RDWTj4dcgB0T uaUiAC4csvloXbS3rrFdZm2TWawctEZpuiXt01dR5j2SXbFDqL1W8RzjqFWN sgVmMpktjZQK7QeGD2tXFc7eOTqhtSr96gklsgwIway2IpWy699VVVUu5WT0 sXFJwv6W+64BcXV3gVd3dXbS2zz6y7v09NaQhCEAC9Tfdd3evX3vtuXibegA AxoExMBjy+9l7wlnTVua4hCghCFB7XDu9+Y7v05vawD5VSqSMGAHEkkiRMEB w7vucnCPs8svNEAgEAg7OJ3dxSSKSRSSVJLbkvNLe81cV53Z5VSpl3FJIgkU kickQSaMsuDkuVJNvjFneO72enNz5cKz4Y1S92cudLIlsKKh03Lpb23h2TOy M4BeR6L7GOy0AmVYLjxhi3hK03jVHDtB7Cm3lihouWiAb3G1qSW423jW6+Ay 6HT17UJAHIAviumbutFkN6x3vqurz3p5buygBvO/d++G+7xbdabckjcvVoZN TTJB2pcgi2E92nNWLX2zYx1dzGTCnxkkbZDg3GiOjmVqOY40mchGtqdxsKLd 3TBh270kvDnPu8Z3vf03Zu6oAAffAMzM937l0GztJc9i17vOQ2Sg8clxtTu7 nTaADAbRAsABqDFrdMyTHW6ElqNGR93HNce8UY0VfC67TTfIAyEnMw5E5DWz MzPvpDMzMwPDlX5x9kmy2UCQAABJbu6iTEkm3Tck3d2Tu7ukbu22+09PWYFl xQu0vGs6ob2RKo1HdpVJN2pO8JnHb7p+2yLa9b++n7WBKCvdXbsKpreqUN67 stiguOgovGe7u6sbu7JXUkkkgLbbb+tADbu7mTJxomzKkkjdHCwFjZuMt67o 4e07cDOIMcJI2ko20lc3S22abe7uoWySdvJgPTenYLZKfObsdXcknbSS5DVk kmFvQITmYXUkj1E7XMsx6r5LdYkndJN3dJO+1tstLJEnujpJcYRQITO8FiS7 UlJ3YF3EmUALGm8o8zxxKrotXC+5gAae6DHutOT8t7v3yRJOYft2Nsklqklj bb7x7ftSSS3cKtLpNkkkkgAAAAABf19xzOZvk0wkksFEmSTN3drZDu4KGlbu 7tbpo5FVwtuTHiJ1MBUBl5HLbEodd0kTugTjlqMO7cjrm2+eW2z3dUndxF2x 2mOL77dmxWBtv4aj9v1w8a3V12CrSVdD07s0SdAAASnkbbZbEb193Dm6WYbe W2dFsIl7BCBUkbNZt3reNvRdgAd0jlFbqd92bytRtSmktZI6aB2xyQARU7pI U8hN23lHAO4du5wADCkOwO2Lrs5JTosri3zUttpTb6YlyUMaG4QM2SPQyg9W iXZ2gSAOeVMzMc7bsVcRXbuc23CSS1tJvseNTNbT3UuCzOrqR2OjeYS5sIoH GuuRjANLqccGkdmbdLbIImgXaa13vYXty+4t5SF5YJDbpi5QzlZwMrqy8L5E 3ljekdR94Ua0ij173tv3e+c9nd4s7oADDySkkpfgm1SbVJSCwFJWZmRgZeWQ qrsKuxrXO6da+54v7mvi7vGxMYADUp+KQs4zObzzLiYfqpkC+1F4yhSqvZ6q pbjAsIvNYZ5QQIpJIoEjC7apq3Xeb7Wd3zZT8Ug+QVSlUDbbbbfwYd+uffZ9 feLVAABtwYMAAAHst83jm3vb3qAAAYMAAGDAeEuO13O52dzkgAAgbEADYAHW +Wr7OznVyQAAAQABVVgXd2QPCQgkDMokCqz1cPfV7TjG4gfs1jF8nwdKtyI8 Oxpcd2AccYiqYzo7sblBantuBS6O2Qb3aKJ3tvtKxLeVcMtWbBITQtmUR1WD 2h6urtze0nXpapqVKGpZ3GkLiUvai5zlp3fqqvZnwQCklQNiVJUgEqSQNlAJ YZ3xXPX6c6E2kqk7ENpOqqk65wNxc3Tnc477IQkSL8Vq/b2c9u/ZxvfkDwtV PCNlUhaQWWkZCNIVKllAlJBaAAN1mvPK9fs5mb94kkCKKu68QqtWRQkpKSRU oFJWnIKkdOcV+2evt3zmboVXiqoJJKroAGBd0pkkgwu6JZE2k6kFSOyKlJIq UkipNG8y83l7zymaqud7PAAwYBHWtawhmZmENa1rWg0EQSSRNa1rUkk1BAAU ABQAJrWtfGw2AAiAAxkkkN73vQaABZCMEAA1rWtTQACwCJNa1rCGXeb3KsBq /vXq9Z+3+8+7u+77PAAAavWr0AABq9fbzYAAmPMyUvnSx3mRUrclxUrdluSR SSSR/eubIvYfLd5yZuSSVVUlI5FVNURkapEI1SkCCpEI1SGQVJwjSUhM7pmP uSat3vc5eKSSDYgAYMAKAPljb7mLUZmZZN8nyvq2omoTMmhLM7cJVCpby1kx s0HypaMxp3WoYTt7tFDNN9pWIca2xYCwiiE1TGZKWVe4N5pVxXb25qJHdwB6 1k8qa5YaWWBkyEY6kfJCYADAGGokipEkVKRyKlkkVIBUtsfeLuSa3uzkmqkA gb0IqkkVKSZKhVBCghISpe/b9u9Tu956e5nM4KRhNQ5vHfHmrvZ3XWwPgAEv nO9m+/uc375f7tzPoQoIQhCEdvOvufc3vv7mfXevpuXcIQhCghO+9nPzfvdP a+e6rViixRVU0QCqKCFUKZ32Z99f77vp9v271lARABvuvfbyd+709qb3lKqq Kopr5+vfvq794+zmqqTaX6qur9Va0c6Pe7DuWiZ126Ftnm8FdQmq0MDmZktB 7ckxZmBs41e22OKuixgXLN6yms4PVfJgLKVqtujybNNnclF7fLtC21yq83OO jAuI5GOpGGqfXcwxcbzx37X3K5R4FIoHfvs3p3v4+z7m7Pq+77L+SpHPq+yt A1ZTGsnb4zZUwWjl6qYFBl0xsxLPe970q6wbANsQyoNtXGfb6vV4O6Ux1J1R KDADUN83THZ1dkQzR1VVVR1xJm8mbHEO0dXlcYTu5hksRDur1dRfK5yAzYLF K3YbgrqTcEtoK71O7Pdc62AJswyatKAoJbl1dPEMhJyrmEvtKwZmdwpLDkDL cVQW6a0FNLbdR0dQOYBoiiJSmqNdwo52CZ1zdJIYub1xSveeBmhc0EmVG2Yn dVt2q9d16tuvVaQUgpBQGX5RHKvnO41vW88drvNX96fQEQAfcm9O733e/p9f fc++36wAIg57e+uL597e+/X37np2ghOW3xWy95neatJvPe44NgDBgAgbbOZo 0qbmSuHdkjOEAACrqrq6urDXXpGTM6U8bMhu7uqqqq796nbL7sfGRF1aQjEq qqvciw9RgV23rakC9XpdXdXdXbyn25k2aQ67W/LMZUNdS3FA7Q4UpVg4EO+8 BOZ3MNJzG1l8OBJj6RzGaLsQOdS47fTgXFTGYqGe0ag9mN7Z2NWjYGqDREXS ndwoi5mQHNvDgcVXz7SltVdJcWKPVLuiBL76280vnO+9z3pevc+97gsB+Uki gCgACgAKQCCFJ99369UfZ3n3N9Old7u/vbPoSQUCREAkYq5rdeyu4c+5zfx0 ruvu59tUFiqiKqc39ryevv2jXOnOd+35+4qqhALH0Z+v69hRoJ42foPvV6ve Q0x4viAfqeX3f3tfSeAUg8oCpIIyAggCRSCyMhEOcdXrf2818fFcO7+9r7fp KhIxqiFVRKIEgsJGKQaohVUBQSRGmoVVRkCIIADFQAFkkiApEABEAkUAg1vm sy9/b1v4+Gu9397X3hAIskYkJEEAD5oEABBkIIsETopDnq351d9zvN3xfjvd /eyEK7RCkgpBqhApIKAq7PazV7PVdRQekwQXE3RouV0tkU7veTed2Dm5wAar t7Gc14WHt3TbDoCxWIGz2adbytsG+zgWxbNyiNB7g9tCOlxFFdJBw3TlKnuw 0hdF2X1zUkKTpahHcutqlWVIqpIoST5NXcvYb7vOZ3yJvPea2JKqcq0LqJKq 1VJsAFrABEQFJNgKkNJSlTQ6pG87x5Dvu8vq8jd57ztJNa1apahRsFy4dXOH fdu875uTu/eetiUqs1q+1y3N+vZ4rXN9x7CRYX6sr1o714H3BW61cixtV72k 6kTY1njXK3vnc4SpGEghD4ABANKqqqoCIiAADJSStxzPO7e59hrsVB7lV6nP VXvI8Jb1TlQxEzuunypp1nFgq1nKnVX71da4jGEMyw9P2e4CKPaZisUzoN3B dDCgqMKyZmIUsNMgFA7nHiqBIY0cbawXqRbIVbdB5i4ssIgbK3Bx7RNtR4aC o9MkcNatdGTjS62hKWFigBc31K6urq6uvVd0Q2xd9eshb1x32twdkq7iIIN5 3OvaPbndzs13M2QhVTAFsLLYMkNGFUZIJjbSAEC7sgp3Ous53nJ3mbd1rKu6 iBda5eGXvmzmzeqA0KAqQUhp3yt6zezm981V8SCkFIKQSKEOwlQqqrU0QORN s3ZFqqqqq7CRw9SrhaGYoSWQiQQBklm+bvV60cNZznKOVAiTZAF95xvl845O zmc6yYAUqVqUkFpSIyLICkFEpIe6dPGG91WXe9rbfn27G6QVCo8shmkYTl2h dWUA5Lu5CVZlYZuZu7bLuiDZm9pq2c69KOvSS1digEj2bsrDBtb0pRjisvbw yPYdrbdBxUdsYDkmBkMq3yrF6ruvVfghg2mQAO3u7dVrW+77zuVzSqiNtDbb b7vLXJmbm87p3eDbcVAKkwVIBUmFJAVVupBJAqV7B8eTM3q5vdfbdUm6pOxU gFSAVJgmJtt7rFmXObzvdev3dgI64rdVCqnN9bu9ez1+3333vntXUm5JEtXR ABFpcdkXcqLtUmCpAKkAqQCQJwSG22222A1VkpIKQeUSjOGbv3mu199r7f3D VZ0FkGZY7KrAnS7shKpVVaCAfa1d7H7knN7vF7klqqVAUlVA39KVKRuA9AAG njDm7t9+m9z3PZdVVKSAAAAAMGDZBtrPe4ue9m9zkAAAAYDV1dWW9rjS4nBK xvzzGDAaHpq6izZL56CatZ3TXJl3OKs2Y11zs28LutvSCe8b60VRhfI9Rd6C W31yuXdDQokxQo3ZhmqKVKI6aDSNrDcW5YE1PiXl3d0iI8aFfpCT72ZS75y9 e377l9d9aqBrNd3hJg2QugqqlnIbby+OhuF133vVXi/ue7gP6y9++6n8lTTS qksnBj3S9+97V8viQigS0AkLEQZIBrL9vt+ppzdZ7ezqAwHfN28rdY5zez7V TSdAfdy3VOdLN9nFzbp0kqbTpa83j4Qelm8zi5F9Xx9TCqpIC0knIhJJJAUg H1Upao0/gj98vh9XGPSqAR2ZiUSpWZk26TvAOvKRUSl9Nd2MFnI+lXx0p7Qo 5ry+noteSG7Vps7uMx84506YJ2p68Wo7vL566LYfNtvt7kC7hdkgxJJrbxG5 fX2wbxmMJQVeCF25u8+jacSXJOQA91cJIhuMtlptxtHKbzND3ia1trdlSRbb MZtJ2+66venuZzbklXr1uzTm3doiA6rm5z3d3jY57prjbbokXZce9t7pPXek lpBnBstbt2mUSknJJJJJJIZLuSSpEl1hbgm13KhNj7agAemdOvd6SGzutqMK Kd3c6Sl5gAgksnSXUKAajs67tySzTvds6sQqxFGQDO6uQAALIFmakEkOIqNA Uc47FLsoAC7UrMzMwGD9bd/c5bbVA/AzMzEjq7uRJiSTbpuSbu7J3d3SN3bb e1FdCAyUzArvWloZEoxXZtDUiTxJxvmAGZJ12RwLjiXcN3THbyPawdwu2z1e zJsl+3M73om5LMy7uoC22yRbbQ3d/bu6Oc4fgZm+7bb6dk759zCIa3OxR1rr YejhUmNtKNknsl5SWSMqQwqyOHLswaMk6DSRkdRbpJwRzjnJAIK+Ud9l8kIY TdlWsmMbfZKeW2JS1HEV3bwbKbZJbgAlEACbDgmxgdJJIjRxkxompNmxKc9c b2Z3bqykle0St8bxo3jwW9KkQ2ycXRgB5s78PqJ+zG2/iZR+P0gAnc23ekcD 0F6qfO0sXveld9973ohwAW2220AIcAFttuc+85vdz3u9393vegkk36FZbnC+ 6SUkkt3EqKnEPnXNsAGEkk5mKSVJKHW29JhJuzGkSczBMW7GO7rs9R3i5Gsx 7d7oBVdSk05LR0q7G4rU1aFe3iMgE293DwakkbbbSgbZA7sotKku6Dq0IyOa 31ZM9cndKbTsC31wcbBgV9Eg2XFuzIdWl9fFPO7uVaO20NiJMgknQATM48/A Htm5XZd6Wkmku3cL3S4Jt0t2JamAA5oGQuN8+NgDibfdkRMzXTe9NfIKE69i CgOklZtaEkkm6zRnct2dAB2xSAAANJgKzt2eQyhW4brSIqidL3GBbcyZo4Ds umNbSrZd927KvaeERAcis66KQE1LALOh7jzuVBWCU12yr2XUPU48w9tjLAOU WKHtrNQdardCMQ2oiN6ZsvR6e96vX+Fmj73pVkKCWFpBSCe3f3GqbXZmvt/f V7kkkgsn0RJITPgAKgQpkCJu/vu1V22c+b1f3eH1ckIMQAHYvuevj6m14X6b xWOKlSZ4RElVIBJUmJptjsDm6h3NvFdNOqMIiPOTJy+K6q4wYAfLl94nMOLO 5xS+dkkVKpIABKqqp1SiSSSru4EISru4BJV3cJAq7arXL2i7MM6cUvjBCbbb bbbd8JJeKRzOYbtVqqiqI+qiyFVbZC+bbOU6c5o5zZZCqtshdW2QuiiFUVCl VREqXcQKAS5dWhUXjJUy5cqxVjEOmmmnXU0Lg3gxzM59a+3bV50Mjp7jIeA0 KJzpwqCA1kF1Z7gAZU7UqObZ3mCgZLotAZiVYIQOjydc7RWThmqR8unQ9TCi 4E3Ziew88x0evRRzszhrsvz69L9uXyXJaS7EQAHLc5rZy9brfNmcVVILILAW Aqjhdus2czFN5YDaabbbYDc7i7I+5ifH0AIgZZdwta2/s7o9vPb3PbvzS10s AMY0MAsjjkI5CM2dtvezcxXuy3IRyC6pIgFJIp8kkld2ruqVVd2rJNEk0aEy Or7bio6K4k0XVJKkq9SSq7VIjkVKRSKkRyKkRyKkKOMaJu+3NX7JOurSxaEh d1cIUUUTXOVZzlFO2LFiwwZJvd2ardloTs21V2AFS63dTEIZV2EQBEXSSWLq 7AACLpYAC7ur4ilZ+F4cDSNsjYzXWa7xQQolw5oHZdXqydfu18b7QeQBllHb opAFx5gIwBLBjVc9zqDcfbu4FOhNWQpS7CDV5N5qDrtdVmBbla7+rdQlfHSb 9VUmwa1m/taVCEBu+czNZzMQDl2XdgN3zmZrOZiCH0u0RH6XZFd53DV8u0RI sgsgpFgLAUFc1qsMveYgAABvW5ms3zWkAb5y9Ze7LazXN3rjzOXbQcAUgpBS CkFIKTbzd648zl21CGcL79fjzmrKb57TzcZdHMNdRFnpfB8cu4LooAgqVOS2 0GpwGUY7aCJLacvLC5ae4x04Y1dYY324sMgtCrFAKYQe3dI3DH21FPSidRpZ 2IztDudmW69W6Eu0q2Vt269R5vQ29cteAebIKGJKIcvvL515vV2oSFb1d621 recu+3CVCpNRawAAADze7vfHW6X4kjJJx3q6vbvVcuqYHAIVUFQoRJJPqqSE Tm3XHvdby2pySQUOa3WuPNcu3JkhGbq901jrdVZtPPqCVvFqSTm4vhlAznek bsrKvKVduqsfXMPAdeCtSyp1125hwWN4BUTc26KCaSLpu2hJ3BjK7ojV05O5 HavI4q1t7OskXCGthHnttI3hNLr4Wcbsqbd9XvqlbmznvX3r3e5jMAD6VVXY Tk573TfeXTROQUgviCJIMiQkoolEJEKEhQBlc11vnL7yr0dAASgihq6EkKvK 417O9xe9JJCA7AAZQEUAAWEgIgAPNcrb2uZ29vA6EikAJPhAAYJJIsgRBkhI gwiVXprEFQqSnteryZvfj28RePSdG5pFmkkku13pZ0znYPqSqlE+cvkv7vpZ yDmbWonjODynWOkFLT4q861Nug0Mb2VxO6tR06XzAJNyXRTLSKLu3xGWe3bd aox1XRfTX1rDrvaPRSEHtwpLskcuVu0c7RR3cDdvOMXZcdVXqHrfXaJXba9X q9uqxfPnxsPKvHjDDFvHiw3RqqqqRxYuXyWt4234LBtts8ZFvveyjett+BsS qgbbySAcfN3dl05u92SAAASSZmZmZl3dpvV8ye77W2dwAADvb3c7zuts7gBu XYCN83STJvV6+sMoZh6KwRTTQfQ8Fu8scscrodxpyXU7d5ccFlQCGIEQdZGF pYnjxgXY7Hq3K1Snoo6482w8yJlC72iXQvaCi91Z7HfbXMeTc1759mY85O1Q CoGzrkbb5QQqqCqQIJVVuzW2znM3DiqqvAEHJ3H2Wumd7KqqTpLCQO4+3xdz o1jbABtvutTvWtzuud3FwEQRF3rnNtF85rdKiBIoDF2FVQcrfDet4dzL5yqY VTBUgElZEHVVVRSVIgkqaYIJJAUnZnHy+3M4NjTBAIDtVSpkEwGwFTGVSBCp Oci7r5e5umAqTYCpdCBSTYCpNgKk2AqThIKk4SCpNgKk4SCrX1qasvd3i7x0 hQjVIiI1SISCpNjGqTYx1SO3JISSSZSaO5vGyQKtP12Z13O6siqLk7V8Ar4W 3fR3TID6U0SuybOxTq68x4r3dPAdOHGZiN7eHtbYygmbXGlrLy7Re1kdTkNN 8xc06ovCmTecKPXlPJlOnr57e87JJJJKqSSqUkipSSJKSSqUkipSSUlJA6KL Zvc5wDaqlGqTapNpNVVVqd2VVVUTkikkUkikkUkkkiknYNPbvTers7FJJJIp JUkkkkkkkkADt9cVzvM6ZwAAAAQCAQCAQHd4rWbt7ucA6pIAgAIpIBxJAUjZ BSF3dkFIKQUgoMQUgsJd297vu9G+QFIKQUgku6IVVEKqkuNulIKkAqQFUDfw TGLZfMnbVITeXWzeXvdAhuSSJ8AAywL1VcOa1o1zLIKQUgpBSCwwBQQpIKQU gpDesbbzM27yobILBZFILIKQqqBgVQKQUgoyly65p0WnrFXnyoAKXm08dcjm opmK73eDnXtjW4+lq4sWoQxBE3BoVkMtKJrLxknAFul6RS0b1bSytPTheiGN UeYiCLtLg57cz2utt5ejemve47HXdaPXCpJBBAgskNcyreaXecbJqElCkFIK QUgpBSCiElUSSKABQFJCUENoSF1JrWtJs3rDd2lgADtWgAKqgAKpakJKrRIb xzLvC9ZvnNYBJKqgQPpKqqUIMAYMAOHs2N8zmS4Az04lV3JVVJG227ABznGd h1cnewBtttsADKSVBqpXJFS3j5sNXTtw7VBoAAAaDdBzjWmrnJvbbbTaejdX vrv05vPb9qSfbs1L9d+j2/e1gAAu7sOJK2Byqy9A2n0F4q4mHSmjWYO63OsN DI8kqLul7HrWhGjcBG2Qy0ohxuyNys1lLMu65VHWijrjy1k2DqYhtBFrCHwD mza7bVYHkYC7h1GuPald3bab6JUkAIBAIAJh07HzsF0EAMYggKAgEAgEGded 7nW10EAjtVVVIoCAQCAQCARO8eXw50FYIqqQAAAHlJAIpIBsO65vB4AAAAAA AABucecvnLQANttpppBvjXN7zmYAAfX6SSS7753zXfdwAADk7zrXe9wOyVVL XJUiwjGMaECbGMcU53Zm7JrGNgmxjGMYxjGMbBXxNbeL0ncN317457e0IJcI +Ob2buYc1mlt2yIFgJ1w6qt1ZFOadQuHtne00hrPU+C86lXUoXwzuRyrkxCD MbTtZ0h4yOiSTGSSW5t51wokwknNdmXVw31PZvZptLI4YT2d2dlADvO/dD3e LbtltC/fnHe9N0dJIJAjRB4pVISbjix7MEfV0cG4dUnOXlhg9KUraR6DOi2o ca3dLJhMRLOWYSQcKk3DpO3YJMQwQ7kO6SVN23wAAffBb73md779O7PZJf15 3W9xXjaGSB3u85DY2FqY41O7uN23MzOYGSXPzdwlnB980872TJN/bAAEu7mC STwizVXEnOWa2ALszXuqXfZu7v7dG7u7ugt59JJ99NWgAO5nMzJPuE+9gEki 20d73p73veElybIha2rmEO4zU5nQyhMUku5IgBxBepLFSMfDkEpJE26EkeAb g1OUaG9NrVz3FjEFsukzZJ03Lwk9yfRrYpJKJJJJH4AZmfszA5w/DxpHaoxx 2nk7g6geIt0xajXQktxtpRuiTmWcBui6aMm7uwk72HNqKcAMJDcwEnMdNZES gqKcmXKZ4dBMzJSpRpEiRQq+LwVy7NtlmNyTUiszuVYN6Su6QAJkmLABoNDe 1FqB7qende3waukpaodovoOBAGCI8cSWESM8uZzlymADt3pPwwn7MbbA774H 6QDTEjoDlLQM3l71+97tJ7773vAAAAAAABbZPfued5jMzMzN5zgSSSkZGy+3 GTunR3OikpGunN9xRJJOZkjlySHZId3RqJXK7SkRJzMJ4zsyPu7qXIQpXrk+ zPvvrxAfOPqTd8nxZofQQAXRdkTe7q6zfPOQ6MAABOSSSSS223ujWmEBd8Qc wAc2yYA6JN3Tcg7kgNkAwEN5edHlrr5yLZvM2mb7O5JJVNbb287ZdsiSSACd XE0TmRzL6FNliAAbuJ3mzqtTLIahnd3bC0ttWISGISQAAA+b7p3dG0klmSPR zxoSbw68gBzMBp02kkXGu6tZ48NvAW3wsACX6uxtAq2zivbJYzJUdXw6iNmr eHAqzMzW97Zt1DWbfVcWI4GDwxEhknik7vdwxoWlXbwp2tNBUznaLkOqGi24 Gs4gchb7Xs2Pxl2nd3gpbazsw8UZreN8hHIKSSNgt6lSktxKqUIxjiSSRImx wwuYbzXtnH1KqUEJUgUBNptRJJSRRJJSRAIBPLvS5q3q28iAQCbG0AxjYJsY xjXZ2zveD7zm8rR2qtpFFFMAJVFBAlUUECVRQQJVFBAmrzTzuc497lmBAlUU ElyQLsUUsqiiFUUQqigKoakaGpC+drL73vdKj0g0NHACVY0ANDgRcRERERER nl+97OaWiIiIjT1iaknlVKnLVxEhE4Ekjcm7k03vuFtb2KDkRHJHFCOKEcUI 4oRxQjighElmm97gbOxaRxQRHIiOSRSSKSSOdVxXciktKqu1d2qVa8W71vWt 1iGgEAgEDqlyIn4UlVFUldosmiYlSQz4z47ZxcPr3a5Da3tDx1Mi5QvClvWu pEnr2VprM25SIY4FmiySGSeKTu+3BG3yGLH10+DioOmd3Re8dUNAMSx2bTWA dwgzk5DT2Q0uu0cQZwbpO+YXZVuwJeN5hCkgpBSGYXlW5BAxDGaKQQXzHs3r e6ceuQjUdLFixRcIQxFCVLoCpV27697xSd7VSS5a5KpVqKKRKCG+ne92ddfS VUVdxdEhCQoohO9envbPOoEupVUtRPlpa07i8TOyS8SRUpFru0q3e5yGw1vd pW3xA2AAsxrMzBgxgwAQNgACzKzMwAAYMGwAAbHeNZeYAAAABSt4LJVIjUlU iNSUkRqQkFHGpdtbzeZDc2b1OSJIJE5GwADElVQbb3X1bt+x7nvAZLsIg5zc 897et573gi13VXfAzMzIGZmZcxzKKBSCkFIKQUgpBLauoHevXl5na52q7RBu rZIIAGwE26b4YvOZe4jvcnJjPLNPL20zT5LIisKW6uoovnJB7lOl3m09KWjN OHXAGcycyHI+3z2QcyPNrNLQtvuYLnE7DTpuWiDW4G0XzGqjvbd2C6iUtze8 3u8Tm6KgKxEwSqnxBksuikIFSuIpIEUvk2n72g+Tl+OTJTD0ouqpppoGmoqk MCqWiCkFIKQUgpBClupCqohXDmVl5nN1a6gIDTGMDs+UtyKQbkkoByEWrcMm XuTb72xjExxxQkHAb1JJKSNylSqSNgNgNt2ycS2Ybl7h1OwYSKSSpJFJJJIp COSRBIuofW8zudu1DqGQmXdou7tSXdq7u7VggEAlZE+d6zt85MRL6pCOQjjk JJFqq7u1JIpJFJIsV3FKrE661zTrvdsaNWUkJJtECKkz4iqVTdVToRIqUkJS XqVIu7sCCgAZmVVUFVItMKISZ7fbHusfQ7r8kkkSVSAqkfSVSAjpOSNUqohA kIO6qqRIt31ub9L+vnbesYA0MYxjGMAYxjGJJNWps537lrOxQxM5Kgo4O92O LeHUOL6K9165ZW31JOrNC2COvCSAIYseECdu9mM8GlovcvLVxjplmN5bmmZn cKhzTeEUsOkgzpe84zVPs0evez21rdZlcvN795+IRtugAKW7uWhESEhHutX3 ufZ3qgoCNSSSBNv7N9p4nt1v6kAqQC40lIKkAqQCQNt519OG73uA38lSASqk BVVUu9gPc9rO+1d64AABm9ryPFjeDbfyD4Z9JJJADr1bHd4AAAADcBtty8lq YiNtt1xMbYlQPKytZbgtJ5Vpqdzbqt066QnkwkECkgpBQGcTXMvjz6uZW737 Vcs3stw71Qb1ocXN5awHvW0MveOdHat8HrQKDsQNEjSdhSncbh7m7KsmZfQb eTQ6wtvHMMx8WcEzLelY72cXrl8I+qVyu60dx3l07M17d+DAAJFAAKkkKQng AuQWQGcO9Na5TvkFWMCZJC2VXqtK1WIDPqrPUaB9YMO23UDEl7TgxBYEdbdl bre+ZfgwABghAUJGGATRrnG+c3u7hOAdKAA3zry+auuBAK3v5eF75vt9kwAB krXd9Ol8zfIBproeWraSvR7t2jaIo4TgvBZj3jvcV1zqs2Cs59sqKSzMp5tN 2ODRI0mcUpouTebQCNhU5LrLfdWtVlQyQThuw0VjtTO3M0Wb1q1LttRYfSg6 xKkL5aezFXcd8LTwIFMWAo72d6t53pXBREA4c4cvWb43xVBRRRRR8QKKR+kD 3uePb1Vazx0xFF20IKInAkaVObdHLNb5S8BRRRsADpCy6JRQgiJo7vtPczZt FHoAFFI0AB8EhZdBCiqsADDDMuGBJFBiEUkJhmYTAAMzNHevK7t1zWV3sICw BAUgpBSCkFIKRJ2qau6uqqqpqiSSlZAiKO9pfV6c7t0cRAkisUUSR+odX4bv MAczMIeM8vj2/U3k33krl25IEkkgEUkkk7VKSXJN77z6r1TvOc3ckIOA2223 aBvp71kc6rF8FSsMVfXtzRMJiAx9bQrePMyW3kYspOdm4cYF8MRIZOgnsAG5 GkqBs512LOukR1YtnDoNfUSs61AiOIx1w4vO989vvDJ0viVnjeOGF6XeOc2d 6qqoAanvHZjvfE94PpV3dVdgasAL6veb9U9zie6ANDABfJV0S6vTw0e54XhK kIhzeO+JX2+9vlPdnDrzna7feXwhzuFO75vk7V9CHRkgeCb5qq8b2173uPfS EDERkWQgxhIKPuHeN33nR5DpIRghJs5x813dc74azQwQALr2m8RCTyj8qdyC jhvrEjZ08s3J1nNW+7F024xbScmbWLGweBROnEoylO42MJJq6Fdt0bLrEXWn ZwOw7sola7UsdY6osGpS30RmH06+N3iVAALFWZJGrqz6EWMQgngFIKQ531do u/b77jV9IKQUgpEl5nOF94crO87yt+jAu/crXKvYlFebXpuxG7cq9kTWT1VX rmqralZ0UV4Kodr3eVXqadLD6ijz5Kkr5o7rgQ2hFAmoDVEOGta5ey+5zfa5 V85qqbVIBUgFSN9VJMFyKOKqoN3Xa9bEmrOc971+N3d3d3d31j6UIzY6M0kC 9z45XI8w8yasJ7SJjAGpjshEO3EL5JyZpasQNEjSZxSmi5N5mraNhWFOvGuM rBs4LIdXHL14stywrao6BqyWd6OhUNvNveRpIcyudZAS65NE1t1d3d3a/SAV Qit1rT7z6s9zmrzmtHRkPiCJBEgiQ0a1ncz3H2te7ne3XiCh9ICyEikAFkkg oSJSDNApBSCrKqqpUwZdgBEB7nu83k19+d5v973u5z7YAAF3YGpLu5Uu7kKq iFVRCqohVUQuyCkFIKMLzk3v3qHPb73pdlqqq4ElVQQKrZVb5vLvr053mbt7 2SN+oG4DdNt9Rly+1erzrPc7zt3SqJK3e9Lzq8N673uu3wkLSG3M5vRneDrO 85uuVT2ApBSCjEikFhYwpIdzXJvN7e1rve7rtcq74QUgoDOyNiaEDh3Z3lOc KzXK573reXs57nBxwpRcdx8s64Alu6DFy02xS7WBfbzgIGIlkQjsruWWKuC3 QHdBTYFYISnWDZw68nGsSylLBtKlgcU7ptPrt3Bd1mjprWjneYZ3a6z3Odu6 FJ1QWG6pVzOca943r3e+zPZf6XhKn6wADU96fuT9zL3v7v6dz16+sAAPpd61 7uenfjvNfe9vPXqfWAAB1nOznz63dfdbx7ky7u7u69u1yXuimWCY07yV6ry0 ipb743m+fd9Zn3IIggD0nL3v3tTbz3W+c73x0R72qkAqTBUgFSAqkAqQWAwY KJLG8W93UPw+5ec3Wi/RdVIkUVKSKKlJFFSkiipMhFSkiipZmTJUzMmSTw1r UzQAA5a7znvveQG91vl53u7bLw89zwDBttttt9AMxS7QDGxhkkAYADMxRUgR TTSCkFgKQUgpBSkohVFGgLtCpAhUgQqQIVL7cWLPj7eO7+6/TbWt/F2Ouyp0 1TJdCAPrE3bvnu6jiuzqC1bsVTDTrdlcQ4sMo9cO3XDbsWRgPHs0w6X05pG0 niSVdWNtzu1BrYrsgTd3dd47u7TAxJBzbaDZjO63zbjckkkvEjdqSaCJ3d2b 3dJJ3UJxCjaCdnBJJN2tT1tNia2lZMOPXgbrueZNg1YdkU4PnnZoky12aXmL iXxJMbUSWUVCSSd2QTdzO0pd12klEMEB6tqWkjJsgAAPvgt++zMx92730Yma XeXxM19Kbk7BJG8bjfd3c7uJ4ySJYhBsoqExRydO0VCsx9cgzTiIXGipIAKS 7uTJJWQk9kgmadm9Ck1d3ZpObm3M5JJGkpISSSZJKS2wKhuIyNyNttgUAK0z tbmEwptpJRtuSbu7J3cenSCdmPXMVXa6zkO47RxJ8TzUd2tau0uPd3LBEy3j SlgMKORwQtpOPbe2YA9I1d1cDe7rRrTOZLYABru4l1upJIE/SSSFtttZmfsz Ad7x99DJN4gAruzTxkHJzBjDXWbxMjecbjbbck67jp0OOQ1ZJfdO7NGAd2Qx QEhu1JIR232co3rWzM2nOc3lYRSS67kFzG22lBOF900WRIVJLABQ7OUZ1OyH OlkQAO4SaxoaBtkxjdBszduaWwSnAOOdxC7IRvYSsMjdqu7HW7p4Q3eZN/Cf UW0l8O++BY+kAEdJJ68aSrZid45bz3O53ueR7333vMttttoAQ4ALbbbaH4DO 9/e/c32+9mZmZm8l7uyRtttqJRvcxmIknu7pUxtNrWKztkdgCZWSNTdacybH 3Q8gLtKQ6SQAcyHElUmJKtWOZmnpPgPvqxKbx+uu458yqtLHmZlnDvXs7rfA QLokklqSSm7IIpJI5u7vJJdlJJXq6E5mRIrHMoprI9lWSAcyY85kuaCuj6I5 OzO1BJJa3LbSDLWxZyWnnnADug6cZulGRBU7knEnSbQF0bvOphQnmo0inzUA gkJJNFpcxCSAB1W21O7ugodw5zu19oxLL293OOA0liBAC2pmZm5JwoUCSdst 42AABKdGLbliyhXRGTRLXdTw7jGGJo9pe3CO3dQGUJjw2xquTiRnaiCBkJG2 I0Zqq9xmkON5bb7kzW8N3mRT1R4ixwxCdQl5t6rSwy+LhHmbutw85PLvc16/ vT33j3d8e129XmPmVNgEZkzKAzP4JJJLuEIQhCbnf3fNvfl92+bu6gnslAch GSREEBQDY2CARm8OWu+XO+zm7mxnJz1oBAIBNpRRTZVCm3W9c4b9nqe83y+8 ruYewUUWKsXpVFEGmiFUUQ3l9vfTvu7zXN5s1ZjDL1UgFSAVIBA22KgFSAVI BUnFznV3rvdczmm7vOJ8zDVXE221u6IVVANCIqo8zeb7md2Vx73mt33ntZ5v cAAQdznd9uc7Pb9vmd+++z7mh3xttttPrNqgKSkiZszLnOuans92+d3u7MQZ nGakSRUgkVJkipOSKlJIqQSKlI3PYvX3eI6/TPcO7vVvHd8TTaMihFIKEWQU h3N8e53Med5nTfOdIplPTTwnGcOJRAbpe3CLtC+mY9FtcjysnrMDRIdgkZmF jV0w0xaNiskuhZEqzRKjxTFMO8XYl52Xg72muMXdAqG3DcrN2+IsqnikrJdM 8G02BQuhXqQhPggOzt7ns97k9n2a573fenG9/WABERzvNy+Z627+1v3efZ2P kRAARfr+7O+nPt6zNc5v7k18CIAD3Od57d6ZrnN+zm1+Fy7AAJzV9Nmsd3z3 e+7znm2vDYgYIG221e7yfXOZ9etd5v7s10AAJy9a5zed7evZrfeb4ZmyGrze Vt5ru673nb6tcFkkWALAAFgALIBBVVd85pvnM1zLO3vfC1vHqv1VNK9vBC5x Rhukz2WrYw7I8zu1GZgA1u09YoZemtRrFAkehYGIkZYxI7gt7cFFI2VckusW 2eoM3MnNSaLsnMu28VcMQapsO3vZwST27y+ZqA2UmpeE8AtJ0Q9ar3jjOvrG dfPgjZtjxOdIKQUskgLCMlMChL3m+XlnazXd9rmu7zKsgoFCxpoFkSpoUkJf lQO7mnUuKfZlags96lgTDSyzqwvsXa100AAyxSCkFA3YCkFIKSEqJLSErO5x oVRd3AQAFqqFVCqhVQqAzWYRAADM7l5ffZvO+Xz2/Xr2e1yAACL1l4sDMyyF 3dkLu7BpRVbbzW81nHU7rmb9z27779LsAgDcnt3q+X9nzndb3l79zeuURSCm iQrozqqu5JO1zM1qubvude7by86yRDzsABqDKL3w33d93vlHKvMz3KUgoCGx Fay9X3Pt5vh3vPZc1XWRIQZWh6ZiG8hqExjSQ3Y7tl1e3DyNTHjT54VwUJG2 CRMyoOqCsaN514JLohW9wC5zYfWTNVLnzo2u69HN8xiQNabwBTqdodm2pDE7 7LKCQ67urithVUQpIKQWGiKAoiLCqt7zTvtd3p5e6zL7l4wKuiFUSTiQWSbl +qsVBYNSy0c4Dnm1dB8649pQpNVnASyq+aT2795cjyd2X33TLHxpR51AMTbb 7zcW8ybNfd6XmW1jfAbbAPORg2DDhy9vOwz3PZw6Wo931KqTJEkiSVVQurGh pqksCCgRl3QG1gpBSF1bZBSCwFIKQUgpBSCkFJV2XBSCkFIPaIVVEKDvK7hw rVe53ut1zejj2QqqniQnEhTJJGS8qAtDVgSFVdyQLq6auSSN2VVkIYkjVKr3 pIzt+33t2Lnec6Uag8qSVBEBVAVQSklQRMTKAqlw2eshJu99nRd3rade0w9I Aku6ILIKEUgsVW/eu/ers05I61CtO0fjRwdWfabpkrYuw8gTGwBjduJEu9NJ GtTRW2Oh1ojGUR1YO7fQO2SUC5LrHt8QU45zm7oys4WDW3rpX2htvFTvM44t plRUbfqKm5t6vuu+7ztGt62nXtJBQikFkFIaWrlgAAXcsAAC7lgAAAFST129 l913vvd9k53nd2c0EA7V9MzV1zm+63RzbvNncPgEmpMIsFUgpBSCwZJ2/HLr ua37nKPb5nCqO1XqpJlPi0Dg0ci9qqqq51U96u67uSsqpF3UqS7BJP0WAlgP 377f3b99edWTL7vfDbbdgAAAAA2222AEQAAAAAAAAREQAAA3cKJ6rut4YY0e ldnFF96jdXd3d2LGF8FwdZM7zXMbsAAAAAAAOdLO7fO32+TO81k4AAAAB2SA BJJJq3k5NneS+rvL529JzkkjkgSSSOSSSBI5IA2wTck28Rx2HcfV1A0MMGXr zej5lHTE0ziIzL45ABl8dQNcCD64EBGKIzMrRI2lxJDyS6x7fFpiKc1mAOmq VnmaljvAvGZoNQ28GcMscJkgehUc0pOyd65IEkkkkjkgSSSSSQkjfey+bedX Jy+Ld7nZJFABttttuAoc9t5vr5ve91rh7ZQEHlASqXAg1QSDXQrgiO6WIVoZ etbNry9Su2OTPSaGTqMtJtvEqoBKkg6ESAVIBUgFSAVLWbfJC9XHSWkK9WZl epbVUK9SQA5nQpzmd5Xq6IMsIoQjI2QqqIVeta3rPb3nu8m8PcPRUmCpAKkA qQCTSqqHSXpIVVFVRCS6FIWySFiyLFIqxm+Nd13Xq5m/c5e32t2q3KqiVQxA IoA69fMz3fZ7e+94PuAekUVzhzy33rQeXR1V2TDbSdvdj7Hr2Qi7QF4ra3Rm XzSSrmgc4m+GIkYCOavu6eComnYY4nAJ57ztZom5h6OELhadjoqd5S56CYss oKs3reZxiNro62zBIwmJeYHT9fRpmiKQUgpD3V9mvcrut97zzdeogsgeYE+S S0CMmzj28z73fua3r5qummTopDPHHWszXPe1zej2PekFIPaIVVEUkipAIG22 98tee5sftzs8GTvG222A5JJd3JS/dazmu+d+7vnufZ230BYAAADqqQ8jkjVJ c5g+87nPe5s4t76Pt+9ckjkgSNJKNvEkAqpUDbeGv3N573Xea5ni94KqqqtB Ibu7kqqq9ht9zenHneavbb0AADElJIqUkipOSKkAqQCpAKu53NsPXzO7yZ3n l2OJUBVVS6qVSfVQFA2vWAAByqDdz3J2PK0p3uq6yiOpUfhl5ubDqOGrESGE 45YfbFe3FyShsZCbg5EjACebvtlONLLFl2VkopWyCpH3TLe2plCuoTOlxDB4 xPeNhHKimXAG9d7kt8BFHkoZbcXu7tqlJIpIAAAAqqgAGHvaHg5fs71HHmav dXdQNgwDiVUlJJVKlJAAGzfY/Oc9fOox9zyOLvQAAAAKpKqQCqqAAbJu6dnc 3ndOPN5vtWttttioBUgFSAVIBUgFWbmzb8ez3kced5vtWiSBtvzYqQCpAKkA qTBUmCpT26eDl+zuo487zy73RIG5VcSklkWIF3RKpVYSRXucrtV287wvTm99 Pd9BJDxSqqvPdfV2/ZrvK1nN81znVbEJUqAbbbpJJNuINV916TvTl85qzvOs AC6shYKQWARJIN3S1TVNUBJJKkkVIt83TS+aczuZmxUpJFSkCFVQRqgAaqgk iwpWASLAIOwFm0c00m7bQulvXUBukSti7Dt5M7twNyAgdpV5fLUlXMhLORvh qJGAE8W77Z6xEU7FnWFtBYAhExH0mW9t0633bYSsdV33INPbeinWVzDwROwr 57HoT5r2nWrVAIsgLJJI93yu9vXOVx101qV6ve6mQtb0t6+DJqr9fNLG+CT1 2doe9uMLGirN6q66r1VZZehpu1ejLr1eizRraDszOdO9D5kOzerPerqqq9hC xJK2s50KqqBq0U9DCGJYHXV6tzpexC7K6ncW5lm72knQ47wywMvjNYwGgejY ASvJ2g3nBaiq5oHOJvhiIJu8XN32z0RLugcDP4YvqQvIyUEmPnPvsD3cpujT ToEY6zs7jabzbNbipqXWQcciiCVjsuNttt+AAAAALfOntzz9zsy173gAAAAB gwAAT533d9fuaZw9abbbbbbbbYezl99uezjl761SAqg8gbbbipAKkAqQCpE5 73d9e8d4b4VIBUgFsBQFJJd0QqlsKqiFVRLUFiynIKkAqXE56Z7u+3m3lzwq QCpMFSApIBUgFSAVIBUgEmP3PZ7u+zFy9++iCAJPt9+5377bjW79Oaiwg/gq swDYnDHzN9zva973X6q8Ofa22y84Z6nB47X31KS+z6l9xpci063nrIyO86xg sVvlcvsNMBEV1MY9u80Wgsq8XRTTQuVDd8r0ClhUyZmZdTbtKs29BQVkksDl mjrvnspBjEISMIxgQDurO3FO1uxM23DXfX1tWgN97333l18ttstryR9ky+2d ADzLHIgGzTZ5pyNEHOCki5tRCXkPMrD3Rbge5mTYOULh0ALLtdp3d2CYlRLR DJRQNk8/dXPKwAOW5zuN7zc/pwW3dq20AD74bM8z6BQMzMS3oDpM4dyBU2cM OSbsMkbxpyTgABLtFQknhZbbZhKzUlG5c59sFQnq58kAoqTb7kl0YABUJJvs 2+ztOZgiJNGexR9m5m3Y3dpiSEkkmNpS973JH7lttbaAMz3pPd/ZpJktt3d2 dXd0kSSUiSCUikkARk20jOnCkY1L63ButROJS7aqO7pJV3MAHSGfHVnNhppO S1IkiQnkq+zN04VOk4GnWft0v1skkjd3fPszJDd1JIC21t022222yWlSShkm 7uy5JJ3dy3UNmbvFGiNazVr3WGEm225JKVJRm7O9N3YlSbehlm2KJihdJ1mO TITjy73ZdWAITRkkqSwAOEu5Lq44EiRBWFnL29gyhfIxqN6iZ1vHb4kBUgHA AGnJJWbh0DiD3QESMSQk905oALdrITdg0BfJCwtSvVkzZqWbekMuPd3W03v4 +S+eNtjpbLM7gBgess8aD+udh6X28sznvcz2cX3fvu9YAAAAAAAPW2+ud7n2 Zuc3c9rMzM/ffaI2221NRuliDHdgy3V4SuZVOc2EAABRkhbzbzUkOoTYldqQ kjswdyke7t3G0SnG/sySWkTjOy2+7k2a+SyOEmj2ZYUwJTT3utOpvcwGyQAn HqSSUU7uSUtS7Rk04GwFz3sx+e505oNsw3DCemWO9FxNnd6SQrEami29zWkt vEjJgE7u7iT3dIBuxEta9vdxtlkoBK9czUTrBkqJcg+ADiSSrjFvMdDhAGt6 RD3GE5lpZfdOBPOaNfJuy3bxDAM4KrRJJac7s7d7tkkiRJJPqr3u7d9uUrub dIVL1p9orqxdRJ6zzwbEHnOhXGawO52JM5AdY0mVNwHd5KwHCRd4cbvt6txL LxMHrDdgEcmI5J2jOs9tbQRRrjt7i0209s1q3HsO8SyA3IDe8q67VYr0FCFn is97nr9pz27rhDSQE4i6pmc7vd6933tXtzW79QHliYAF2PSo4y3IDavgVQV5 VXJkSbcN2sCWnx3ukZDmqhkvQZDde9VXcYoxy5hucVnKtxQFIKQUhvM97V65 3udd1mq1gIWRSCkkWQBKvb3vb53uY9zWe9w2BB6Crq79V1SBm9NKrgrkyvUW oQbe88lS95VbzYaG23e0SrR62N2I6aurEWHrGuEDbGE9XMgvGleg8SLsE3sy 61at1G2a08FeG1oyJSG0VBixVo6Kk2hWDOnO8c28oGs13z2EEFRi6t3gOQqv VIzzu+a0+a1uvb4eUCRVYChFkFCL71dS2YqLXGZxdRv1ep3417SVpztBJLvQ se+8aqqp9EuMPIy+IwR5VVVRtC3JTKsEKZi9VV1XGGC5oFtbpFRr3q2rjfUE 0TvG7yKW69XUMknUZGLOZxu8sx8TxCMAw5V9vOO++zTtza78+gbIpKSnZrM3 qBrbLYsx5TruNac13zu24tJq6gj3HYOuIBbh0jqeUSbe7jd8CiRbG7jszrrc arGCpiXw6AKVfUB8ME37vsvcoHVeZQ45iVDAjt9vG8qBS4jbZbrvu5pe5tZv 2q9sgpBYCyWqUgaq2/XdXH3i4qZzjd0Za/FaKC++ydDOpfZxuxkI966yTE9i qWXdhy/eoUZDG72Oo/a8nlIKyeB3rMv2Gve1PaPbXpBTgTPbdVlmhDs6uBhM GqpvvVl24FYEiEWcj71cywAPrXqb3rfGuffa3Pr5X3c9YGDBMbAIpJKk7FSc FSeL2TbXfbvOP3e4+ZFSYIG3oAABkkA4pnvGXdmPaXUdcC3k8rq1UMd9Uu0o 9L1I0KjIoLToPKEDWMI6t4PtSu+OEXYxLZt1zOdRmb1rZWmrFEbUBwBSHe1G jQq0Ga7eYrOGigrpussVbtSd58Tw5mQGLzW7ntAAEgKpAVSbqk3VJum28XX3 LW99svdXPO+NppvQAbafkz7sd5Pbv76bnv13L3mgAAPvs+b31k5ncvzzzTrg iuVVSDToKVhVFFFvPa9z2+LrTCKyIY/Xfqq6qlWRVMmy3WmEVkROVvvV7Z1T Z28ryhAPM3x96oHEH3K1Q4Cb+1eVKkmAAQCEryVYABVVdwZHkht0JdMmwa94 belbpt+G3ThCqqqpAyXQwbSrLzXtuaKFdtBnrMt7AHeFUq2G12uxHxA1g4j1 QOLtJu+q7u+h5m6GVivGevfwRbvL4OrVbh6Z8PnDYe2XV60uyluKrwtB6K7i bFuxd51oR23rXuU5XKrO5ltsgsihYkpio9ggqQCpMEm9N7zpreFl6w2kDbbe JVQFUkrImAAXt7zHrC5poY4AAAdUkjkbIqqSSqSqSNi2ze5o7NBF61Y2mm23 1JAKkwqmCBrYbm67vytey9ZERAAM97Pd762r7dzXmWBEGVBBdywASWlQk97P b56z27jXtZjAOz0SQlQlQqQhJdVXeb7TldqjO5VgAPFVVVdgGzV83vdLrdDz W9hOShUAFkk2EBqiSXe8dZWuVRy9c4qqqroKqiBLSJSCVJUAlSycfrkbvnfP N8IXb3VZbJaWwjFHRrgc7XcfMDWDiPVJRs9nK0Mabsftvnva0dstWy357Ffn ep6ocvCCSpZvEa4C7RHNIWeqzo4Uub0dWbe5Tvt17TRtzW+Z7ei+VRWc4KqA ChAFCRmgAHRd3myzW6o5etwM5u7zhl7oo5rdMMIKQUgpBSGTlW64VrlVfNb0 QU0ABU2RSCycIpBSCkKqiCkFAZKqiFVRC5WZrhe3dtc1vnAKpVkhJt3euF63 VWnL1yTAgoSHSlSLans32X5ftc6AgSQqA9U9OzNMvN9nst7W++kq7AOVVS7A 1fe3NmcRwG+e9sbb4AFKkm6pUA2A2znLvZuJnNLfd5zbA6LrGUkupKlIhEAa akCDTqqi6khKooGNt69tlb13dlvLlauHUkErUs7MGJUK2FDO2ojecdXa6grZ XHMu6V9kZRLd1JtbZV4TLXCSskpG2XjCgtBXnUBS4cIqwWeqzoLrV3E3xFix mwhl5xDrNwiOjmkx47trgUABTBggEPIAK3y9mzMQu87d7iuamCJJATgmFANp oZQCyO+Xx5jL0jnuYJXsCQJJogmjaKRJSCSCJRqqVpD3qJRr1IA7hmQp0MAy M7IfVFIKQUgpBRjd3IX28whjmZZOqm21VeTbaSSSSSJKpJJVVVVscQWNq9ne 95VUlJIqUkiVSSVSckqkEipQkVQgEjkV9vtksbV97O9lJJIkkL2QJlZmBMu8 u7u3AxGRQZd0QaohVUcRFRER1KzjWUpfL3laFREQBeZhAggjMzCBUzLlS6oh VURKREUuhvWyrxS83ewVfNMYxjLpJURxoAY0Gc7yTEXI2r71ToMYxptAJsYx jVDMkne2uzkRcjd9k70ADEkkpIwAYIHSTClSVAJUhRdTebfW05OcyL09qMvu ve9XluPqVIwrnXRDUqFcDnY7JQzCQDixbT0jau5mHBz1mS6b2tsK4TLo0C6x UdmAzpUCvgKR2WrO2Mq64INPbvMp5lqnuX7zzqzkNMjasO6AAAekkkkkkkkk kk2+dHDqasV7e7skg5IDDyqoQYMlKqqEbPP2ofrcbXcmX1t0kkngF2AF8zm5 zL1mE1es4BESKklOtZjrdavFNVmwqSEZuRm9aNbKzd4mqNbZFIKQUgsDQsCq ogpIUG9Zt3W29Za6rNzjC8Ac5XMxeWmLeBMhbAUgsxCwUgpBSF1RBYCgkplZ jrK0YpqrckTkCRk3CQzNUbvVImVmqRkyEn4SSjX2O7zPHM+2VzXPfexU6CrK xmzBtLsj1TsqbpwxG2CHW7zwogveU0EW5m6qFwgmZzzrq1dC0b2VFLclB0zo fSOCre2m60THSNWRutdxNT2tdz3ftcv77WX7r7ONb8Ln1gAFVug1rmzfMtvi 6rOUyCyCyCyCyoVUATNtTOaxnDt67YRRKgO0GdyduPt9b4Z0T4wAAAAADElJ EZnYN3xvOy87GAFqqVEgACYwQAGZO3HOvpyZnYAAAAAAAAAK7UXbk4+nJedj oCqQFJZVUm0qZBJRKkmiCpAKkAqQCBtPMU7cnH05LwTTbLpVTqQQNttt4Zd8 ubfW+Gt2AGpdgTL1ec1mbdvvdb5ZySqYm23qSwecUzkyYjZdjXe+Qe1zntne deRA1q6pCxZeC+WjDrBoguU1UpSboFbcvtPQMq6OVl6+V10b9lkWD0xdIHkv C7wEV2E0Deu7sgYNax9e2s51pkdd3h7KvldeVzXgIbSDuiNbGjgpBpre77l3 15W8zRBSCkFILIh0ihQEqEqCl7Xved1ntT3e716VCqsC7sAiALuwIICLWAaa bfgAkkQNjbbbbbYghIwAyoQYAAAAwsIwbAAAAAALu8zAACvZmYF3d3ALu7yO b+y59vz6+5PvvXa7sABl2Xj9KoIw9e6v7Pr8/NcriQW95nL5s5zlnHCKfgUQ u7AlF3ZU2u7Lu8uSwAgF3YAAF3YACoUwBQiyBru/qfFvuHe9vfMkkDYyF67W t6y+mnmzvO3ywkhxVVERHO5re9Z6be5Pd9zXdZERAEQARBERERBEQEBAAEER EQRARAKgAAAiAAAAAAAACIAM17N7y/TT3Z7vs53VgRAAAEBB66qEqFfSlT10 VSqoTA6cMOnOVre8rm8xwY+z3azHjy+TcmmuXPBzwWADEeq6YdmJ9T1De5OI QZnY2jupgq6ZOocC12tdyaHTLLdOzxC2DYzdae2xwZGFAgABAd2dJrDm7Wt2 SISGeBA4q1JmUZvSJ8heNlLchPGSNttqbsu+ki3clttpNOLsGDuKJvgyj0a2 pFrFudorMZu45O3cV1qfayopibmtriWchPC29IW7ukwjhfceaAF3iKeM7VjD taCDRvqgmVcu9nduTdigAD74ek3d13vc/ejkUrSjazCSSCL1yHlKHTucEm6J 29O3u7pLSkWIrZUJCd6+kafPYLEhjx0r5UguEtRtKoxJCXT3WmiTkGcNKF49 Sh3UMmy8raQhpPRdrd2gHGSSSZbIrcz223tki2gDPfszO/ScneyLJJJZ+ko9 73vHve94IcdenJt72/aGJtoGUEkpfLCnl2EO7mb7u3RWpa82Q8jDJMmkiG05 TvodGMKIhwgUk5eTefU0d7mBKJL3d0lxJRJJySNttv9aDltu639u6GszM8vF 6b73rfeybeZpWDNzmRp7lQfE4xFzjbbkkrm6dv8Rv5puG2aJIBSSNv6ZvSsD Ibg7uWe7papa1Tk6h1mJSXcqa2ZI+7LAcaARjUbAhv1m7CNHZABja1zZLu8z u3uNZhkoN7G6bHd2g8cylHbN3wx9vI8tIzo3yQ06lr3pyRO7NkSJibbYHSY9 MhAD7qzMxvkegfdpJ5pcphuyZskCHABbbbbQAhwW233zA0juIlAAC7UkSSVJ SNpbr1NAI7u6aGJKNToTBbLA3btJ0TaapTL6gcgN2ZCSLNYS8zA5K7dzMbbJ Ujf2ZJdnuKmy2wk76m/pABdi7LpMadON1h6p3VvcSSCS5Mk2KTJC2293VdPL dBwdsDcjJ6u5Q9K3eUmEXQnE62+wWoX3ac3iklvWkjLDMAhndvEnO4Vt7FvW dNSrus0bpGhvuhdqdajELWpZbPOpFEAAGABLa3EwBCSCRXC9kifd3cEkTd7J rTBpGI527yoDczAEbUbbMVvJ3d2ySRIki6vpUrq3SXU1xKxy7LoMyieRyaUp wG10ODJuWXuDWCQV1HKPdNSSlizeTttHcqbWWdtqdLo1JQrRrxdI4Kt7abq9 gvNxqrCW6ZIpwyzaIi3JnubvbnVj3FvdnO91viQCpAJICkAqASQCpA3nDnOQ 4re9W92c73W+0qzk5xbirrapp6VnqHrxBnguItimXpeVK9dkFIKQUgoCHNe3 t5d+Md8PcrW6hxVVO1mOrvpj3h2uXrdSxSChBQgpBdEFIa7vvK3d9Md9O8rW 6BdkI0Uxttvb27nLvit7xadmcQ23gACBHkkkEBvnue4bJ5W/d8vbyddgAAWp CaJIAAAt+AHq3ekG9ElpvsqDWspsABttttIXgHbffTxtkLsa3nUe19y+zOQ8 pBNQqDI8Fg5gyxTJC49R3sxXYuWt1sQrrqZWW9E0sebujWOc81Bh5QwKwo3o 3ikeq87OOtNvLzB1vbqYInxkybp6zJc5sBNV6k4Gcm6emWpUb1MBcgRSCkFI KQUgsheO+evNce3ftXR3vD3d33AoBTIhqAsZaQUgsBSCkrvPV3XV7fjVVzvD 3N33CZJNbfc93rXMzxl13Z7hq+WQA3xVVRkFlQZJTEVUFWSFBFkGRFDT7vsL drlzo21UYfJe9XqbuJJXqYG9b41EXfNQhkgpIKSMgHe73t3d9NXXPcPdvnNd 5kFIKQUgpBSCkaGfhASry9+zu0tfUQOyvsZ2eqjfVcBbvCYIHUGUm8Eu7OXl 5Y27Shg1tQihKsduRzBvbCZqFQYnQbDu7SzaW3qpqbrp3Ys3KOPH0M5XiceS +wiumTrPGr6VcqKw5B02nmyFKodaaNdecbiaOZmDrQg2LXfQqZO11lgVDQXI 16vUfKRNu5O55eg9s1zOVITzDNZZCqohVVPiKQUgpBSCkFAaujX1b5vd18U/ aPtbN81hiqqqhfoBq+e1nNPLvxS4e0a3lHiA+dg3iDECacVAKl7N5mQ91x4v ct87l9aulEq0lEqFVCpAIs96753vOw6O1uLOWRuk3rBtgAHKpVQFVVUgElUS kF6qVP3fb3duQfcXuLnbI8Qgp3JatApBSFVRBYIFMit3UqqBpIAtNVGcO85m 9Vyc0d2a3zV5tQieCKSRIAVUISq3AqipDzznNvprmvb3zer3YaCAkoSCJD0C iqIKQlZ71PZbbdldNAIw+9UqqyjOvhV66Qu4j3Ch3UDOvVsG5riHOkIooVfa t07gFhRWslMTcboWbmCxyjub11yNWdNF7aEcukKvsvlZcg6bUvNlginz4mg7 3Gm3gk3rfbkiB4I2RCm7VBBkhDTKr1tFM7u/Vzm+vOZ7Wt5WvAsIofAAffc5 x39Qg+JXYXfdwt0+YCQ1jsGAC3lhhjbdUSTaAAggAC953e2tXvT3fd73lbhg ACaZ9nuct93Wc2+5vK1oEBSCmpJJEtVeRF3YAAF3YAAF3ZEB3nNav3ea717v u7znJU3vm97e61nNveW5k4RSCkFIKAsE3rWuVutZvbznXWTkkkRAAa5hnu11 czXthPqyVmPI6uzDj47JjuxMpG4ReUOJGUSCtMq9s+R7MVuAqzgsco7m9fI0 dFrtw9FLpSr6uVlyMzamIXwOU8XK+21jdpq+vTdqV2GXj5lvrxC4dvuqq2ks A73V8295vK1VgAKAAskkRhJEQJGx+hYADSRrlZrutazp3hedAI8AAQHla13C umu85jrQcBSCkFIKSFVLzurzXJvfO9zes7etVUqrsAAP7p3vderi5vC4TCbS YUAqTBUmCpAKkDbbdrgZ3qxTOPe8u5kjfaASDKqVdgBrfb5yZM3zl7y5l2Xc RBCdgGXOcVq873t8cxpt+SqkAlSCJIBJAUlckknBUo5CuNU6Td95NtWpfe9H YR1SAqkBVICqQFIAGDpsZEQAAS7tAcqqqrsIg5V/ckOwBH6btxZ1Y6t7JSCm PijBjF0ZilZSNcFut3h0lw7KQmYULNxAdEw7il0crFjxqY+dCVZSsuQTKeEg ml2wKw6vO3WkwVsWEXeuE7qXXyrbtUG6x1eWKAAS7lwQBEEu5YAAB3MwAiCC ZepUZIqTkipSSKkSRUiSKlnGTqtS+97yXM7ybdNtqi7ipEkVIkipEkVIkipS SJKSMGGdyxape996Wrx75gBhISQJFCMJJPJJJXd20t72+ryl86ZJLnL2Khx0 MAEAgbEDADMOLql84ZNu8udAAAAAbbTwQ1SzDi6pfedveVmnkgoLBRSCidVz M2dLzjvu8zNPUiF3rqdLznO3bedmBCKAmX3p1FZvE3idmheqtpZms6n1VVVV 5LvkyDOHBcHQ6gLyUX0Pa5B06xR0nGYwwOvDi5m5Qd7XbEQMvaWWazGhBuR1 Jfi6xqrXNVLSdWA7RkEynkVYCaOWehyAbh5OdpultmV2CWXyNJjliuqq7u/X deKQQDuuzvc7zoTllruy7u7u7052Wt3ea80AAqgFS1yCpDHVIBUhjqk3SQa5 cta93m2awGwAAAAAAbN213uX0zoESkkVKSSSAAAZVZZeXnd6m+95vV9AAInr 6z3NTi7g0Nq6uALQeSrI5ApVVVU1kzjWnsBmZ71ayaZ3QwnXjd3d3e1VP3q3 iuhTbXYTgWdrvHJCq6DKJM67WQbyhG7LRrqJ5q6iLNq2Olc73rvYSBl7VmNw nE+GUDWGTjQBl4r12jIJlLItIq+2zFkbvL6GLQLGLVLEzFkJpTrZb6vUAKAt t8SBttvoNnJFzvHm3znQEF+kkkkskgEkkkk/JJLxe4a3ecRwXmQknUleXd3J JJABkuqSLu7SSRL3kivH3Yc5HmsTTGNgAAAPugstd17b5m8UkipEkVIhSQfR UpJdqld3dqlJLtO0verxPC4ByydalbmAQAEkEkkkkkkySSQhN9Z3mb5+z2YV TTTdJtOkAqTqpZFIKQUgpBSCgN3RCqohQKkXIlJAAHVLvvHfc95362202mmq qTzt+vft98+21JPA5l5AAASEbbbcgAwYAWpIF7vMXO69zDAeAAAAADBALkwb Vrek75Xd3zGUaSrduK71h852LplWcPENlA1HkIfO9rs2Ek5e1bZ2ArXeUy60 C52S1C6vRWZ1lyCZSyI3ZJaFKagavBWklzoXlg9L8ePdec5d5vtDJkWSWkkl JLYRB4JKqlJARd3cf0CC98/u+577fskPrnAIWkrLcqkkoRxUoRxUoRxUoRxU oRxVCMY/B9Pufe79vuZCGMYxjGMPAAAAcpVSkkSoue933O+3wcmeAAAAAAAA Afch72d97fXITzbbfKou5KuwDWn2ffZ3n289985nwG5dqkKgC93z77r77vvu a1efAAAa1clzbmSOJFS7u7tAAC7u7u7JHSO5Nl/c0v4AAWblVTevvvtvu/ev 7mlhttvFQCpAKkAqQCSA2by4c5wN6LVgDZod7Rq9ZscSryZhd1YASIp1Zzlu UpoVNTdbFmrikVzXohza2yEblzgpeGrFBOOXVqxLkSw6uwdCatlObpQuOzu8 9J093u7x893fctjxA3dUgEgdVCUSQqoSUfkEEAcn79+/dffu/v3NLPwFUu5U u7lS7uVdgB39t/D4t/TPpigu7uqN3d3d88DEiwSZGeOUAAB3t8zd+zW/vvu/ Xr7OgWgx1Qx0MaoYxjoZvEzxfu+9s9y/EKCSNVDoG3K9ee772uZ7mvb7IpEi qcTnrnN9uz2X7d2lVMTEkBVA2223iSSQCSVO99C877cPcz267SSyKOqdgFSk gsgsgsVwAB4ZT6rzXfe1ft5vgAAGsr2tp9E5E7r72n3Nczm8mAWdclRbRhVN LNtYNic6wMprtGbvGKzO4mhUOPTlg5hO0t2sF8YXunKmm4atOQMIcEoLWU91 8iSSSgO5N7XYA+NTKu4SSiybqLCW52LeUwq3qzdiFiGTJAAd7+798O84Sbbb aF7bzy73MHChHnYcdK1RUaMbTsBJ5mdJS4sXiMcUux3dG3OVgQk1JoZzEeRF MkpFww2JHNwjjtaCYrrpcy9zOlt00lsUAAc5weTMz163OROz32e597KQUk7j eapMZ3HNtqKdsvu6S2442m2pSRVggAIFSAboF3HJDWrDpJiTbtu7cb7il3R6 SdMD6rB3LSYA5QADMw2Oc4Q1u7t2BIySSTHLgtubpvpIKKSTbcjxJKGElnLt bqUbbbbSpJyRJJSNt0nJJtyHdOjVl3xrNctnKGy3nBJRJSmZuvR25whg0hCO VI8IJEdWI7nHTkQaPMwk3ZVJEAW4lHIzR3VzMySN3UkgLbbb+tADd3f2Zkkk pEmWBJIiTuJDN0PibOcwGsYBzD0aTbbcklN028bbnpFN3dkUJ0USshZvS+2S yczrsaTxKoMtvMFyRyMAAQvt2c0iBKCampZcPHBoZpNOSEkrMpEpEFEKQDGn Gyrpd2ohAN1AsUbbJBFctbedyF2AAr3lxOYChmTd2LhwQFQpzlO1/h838+bb JkJ+XcAHbwkgjdzS61J/dr5gExHdu92SSSSSSQAAAAAAZnMzcz3tIAAF3JIS T4mSNu2ySCd3GFlEWyVaT5Sn1dO513HMVNt4W5MeC0d0XZMDbZJLlkg9JaSt 2Fuh5mc+hk+JP31Hn8asDkuofNgAWKO27Q+5uo5mrdCAJMcUbbkibb3d1sQk k3blTAO0dG9QZJJuyo+gsDMypJilYm6k3umRxbdhahDA80pHdtrGrt9LFid3 dxJPBanBcfYcoNU7qG+XbIYAla0PjwbSEdSugkiSS1E7vYXC2FjpKdN2NpPM CsYDHN7VQtKmcW7mSd0fYiTmYjCSSFluQd3d2Y24jgECOMOuBQzaVSr7IrL0 jkOqzAN7oaN4tUZpe0TUnNj21Ram6MB7BV65sKuPWXWubao2ONE0VYLkt3gt yw6QDhkyh07o0liGLmkr5QV21zr281cl8jzt3u30YAqbbbbb/ByNgGHKffZC /d71+vc0QNnVJIqUkipSSKlAVIBUgFSAVpJVtkWbpLvszZzTtVTAvY81y991 vXa71DZBEgjIjBRpyr2taWNdqReu6z3veq/eqvddgg63gSJ7mdqVAWGRZFIK QUgpCqoBmiWkFILATnN61m+75vfbvnbkDgk3nNVlIdubnAdYr16Kv4e9QN7p iEbxQbEa9WAQzed5Rd13OXvXMrtXJB29FILDpBSCkFIKQUhVUDAq6IVVEKqj 1ACpV21Vq3zRyA1KPUHzU63nTFgUGLplXY2tT0PJb1JgKT0JVg2M5tkZe1Zp zSadLeJvcFO6aNKiaAsJzZjvMvZZkTbe4bMNWcaE3YBm1enNWWWrbtEJIsPM MMt+v3vV6/ee4QSO6wm8Q486aIiAG7XzuZ7Nb7vns9vcKl3cqWtqkAqQFJMF SYLGkpG+X2YiG5nb05qvOpVJIlSqSAAAAAAAO0GwM89fDqKAAAAGExEkkkkk kkkkow2ORMT5OGUpjrySSr1JJKvUkkq9XqpJJV6kklXqSQSqqCSJJJJw2BsV GHHkyQsLCSSSSSSSSSSSXXq8kkqr1UkkSS5dm9HEQ9t45FZZJJJO+9XqJSck kkkMSkkSqqkgESXt57xsPZzed5vvareELu7IXd2Ru1VVWwhVVCQ5remnYez3 Od5vnYAAwYNiBuqTdUm/eqwwI5oazjYyYCrytq9PKZbObQmDlCOl1eh6lfMq sE1J9e1HtuiGoN3bJqY3TyV1t0HoDvcFBzaUT2maDsGTZlPNq0K6GEw0bjmD YFm1tZNZ68Uea4XZzXt+9z72vqqFUQdWGrs5e/dv3s5qvb1vPe8qMgQBvun1 67l+v3Oa91CEUr1VV3VVZrzsmIWc7YpsnV6lBnTDxtZNPZyAAA9vXd8Xx3vr 1z3fNANtvh2SSqJMSqSRKlbSSU1zuTM5Zve83db20lVSSJIkAAAYDBnp3vuc ztx+73PdXdAAxVSkkVORsQJsbEHvXvOctby37vc93u8UkASSSAA3ipNqlmZm EFILAUhmZkC7uyDbRBpoific3k7kc9znPe4+qkzSJxxjGMYzFQpIqUjkVEcY zDY8hZPX3Mns7wlvalXBHh54rjeDoN6aBQAe9STUvTmpZRqcblDuiSS2+q1w WuoS1afMt3w0qxMplBtE2C5Ld5gl4zWdkIhq8JjvCJyoLRFDfbz0BvZsxI3N 17t7YAoWLFjGcRHGMYxjC0qUHIlSVSjmw7vddzr3Nfd67qSXjFrWvVgTGMCC IAmMywAAJjMsCI023BsQ4yNiBsQANgAACHCQAAAAAAAABDhIAAAAAAAAAetb 63vJuL3J7nN0tttttuldZmELzMwhmZmB8k6a3veiwUgpBYKAoCxMrMwheZmB eZl3d3d3z6z2n4YKi2pkq+4kkkkkkkkkl1VVSSS97ySRJNEnEsjqbt1xqI1z yEkkkkkkkkkkEkEkkkknuO5eUK11zNKQbxJIBEATM17vCdye1k5ueAAPPuRN 3RHUgSGq9TDSsZS6mDwtqhVVdfNcrm7RZqLRclV98WGN+LJvcQwrqlfVcE0L LHILgMe08CqyZSfK71J428iy5RMdrDe1edoGo93bZGLDOSKwUzl9Ofa3ach4 VdDrGuupiNzKtnFFwGR6FqJNNWs7RudpsiLmldyfV71e7M4Boa+zMXvvEkG8 97hfsy9Dnt3nrtVUREUABAQQREEEAAEAQABBEIglTEBEAQGS5fe95pr29b9z O+XACjlVTQqIiJIGpE5zWu3vvHK05lW9wnoCROIT2u5ruXVdz2ZvXr8QKAm9 773mGV72uZL7Ah8HAFIKQ4dr3u6yuueOWZXvcIKQUgpEmav3eY+1e9e5zRqK Xd3d3aoDqAu7ur2iO7OExJ7uvzimCwAArzdvTW8rV+9xeLmfS+X9OEzL09x1 3qDo7WdxCFrUaezMnKd2rzHY7VEyDRfdYy4EDMl3RYtm30uunbsmZYxTrems obg4CY9VW90SIFZuIA3RU7i+e0+793zvM433vdTftfEQAKkgzm/b97T7edb7 3ut/a+EIE9d1drtQO+c12s9zWe3zXNa9WHkWChFgRQIoHe80+y+uvG7M57lH Btigooo8y8517k3DvBXuptPghpgAAAAAHYc49ydebyK918AAQL5Oh1Sbqk3j TaaLCkgsgshrV70+9Zvft90arqQUgpBSCkFIKDEK3etPe2b33fdGu2pBSCkE qRZIfMgV3vOPss3qvb9eqv1UqtJpDCerizjFDLr1GpPN70OGi3rpvunFWKlX pMfA5yMNYdgfKVh9gPXYWVDdwvUsqa5moOkpR3L6rzoRN2oMBztIAgR3ac5W mBfbJrwLeZwutojIgzY0zS4AMaOX3PbLprlYG1CixQy6fk2lTbbbui+9l3uC 5zebeEVLnNmaZ20995vXXdWfIeE2NjJDjCe6+3ftdsvXN79vd3qg0EUYENd5 mZzpVa5vfdm6tIKQUgpBSCyYCkFgLKoGX3ms3310QyWaOb7L95o6XV0QyWaO bXqW9TaPG+YDDzau2iX69t8WxRA1XXIDqSQqvVVSvd9wTZy4IGPkyGgMu5dO t58sLrRruOGz1K1sYiGWuo7mY9D7jWm5Cryt2dyVuuxBOoOdDL2xvcKFS1cT Voi9HQ8HYo1t7lRQnG+p5BwBmbEkLDNdWy9nassUub51oVe9Xvqqqr6o49V0 YosEOqqqq6gSVXYHgq7LZKT2t9wR7r295ydUhITkDvecvEzutX2+8hKhDUk9 l0NXV2EIgArqxUdPXyAQ1T0v1GQp9WV0AIyOqr66vC0lBdbQnHinLu7u7uwB rPd7r7Eua+1v7v3wBEAezPd639Sfb1v73vgAAPpOYZnM9ncK6hNQrb0uPs0E MdZzqYlnFp14OrIBA53OjyJT7eiGPblWjK0Xb6rcFnT3FcZxsQdMd3wu9kOv KWUOcjXIVYgs6VykhxZo1xo5CqGZEWzqq6ZRm9Vz73pVUQqqIKcVUYXdFgKE Bku6IXdyZISgAzMwAAJmXKl1RD7nt/fVliZefb98P3wElUqqrYqud79fr+wT V5f3OxVRUVX4JKpec771+xHV5nudirZBSCkFIKQUgpVkpvT10N7W36qVX5LV iravnw5t+9XVd95u8mWmsl5u7S1NDsG2wRO87vTInky93VrG9SpQnkkwpVly 02AAAGUcW/eJ94UuXvPLYAAMCmAHyhIlSZEy/Xz68z3x9wTlu++89gSKmSVC SqkkVKElQgAxs52y53uwvnN199bFr29Sy7Bx3gx3pTrJeWU+mAzjdzi+5Ueh Lrdhge3KtcqldFUwwWdviAlctvtqDlMfC71w68GKrIbdYbOzAzdDTz6Tpg1n IWhSCioCz2Tt1dUyikthqcaAF0VVNU1UHt2FtMgpBSHHvnnu0Je9zy93xpVI apNyBBkck6kpLipSSKqJKJJ7BCuVA8rzXUuEcSSSSSRYFgAAsnyLvJ7v2ezH 37Y7y9+3uvQbbPpHZahYQABnp9zN+5Pujl8zn3fPeSQkkD6klVXOXyqu7uSS SSSQkmJJJS5977Hn2zM1zW9eftdvXwElVmYBWXlI7NAAkRttttPmffX6xP13 33McAAAEAgEAAHklSSkkSVVOd3Jxbg+TNxewsAADypVUkAiSSSg223i76e75 1k7eZnTPPG7YgPJJJJjacbiSSQQzfXV+8VKzl57Omn5fgAKpVqBCqVeGBMIv ZZGYTcpO73Ajfw+fLFV04bysT69a1BV0MGZquBxCrh3vwE+3LxBT7cwFXiK+ 6vg5HfVwVuR5aHboWV3ZwQHFNaxkOreFQwkkrX2grMR6lmS4uahjHZVjn15l 97u5oAQuZ685mpz33NkybJAW8d3mse5v6dV69xl3Vu1JP2WHOc8T772m9tzG tcc9zpMgfrnvXEEjt3QrHXzA4BQQ5FakVDlhvSTFWy3PvzP6dy39Lu2UBwBD nOBNz3hh7ErfcOq75h0ZMu7keDZhzKUg0aW51sxRzAAJdtyEkkRpJmEkyN6d 2Sruae7JMO1sSRiVuNjlSXcgAAWSTSBHTrXIPszc5yRQCb23nbdklQkkkwDn y2/psk1eUAzMzMzfuMN1+8G2kolSTknd3dIAABGzbes7NkuVNicbyx0KkLkM nmpTttVvaHV9vE2cbgjURkjdaQY3iEndpx5zK2dwuwnNuv6W3ctUG7uz3ve3 Td1JIC222/rQA3OZmdFe73v5ZzveVPTdzec3dvk8w8w9W9bQvYEmoVcbfJVD NeriC9ySMDitxcpvACI8E5egZjMe7OQS0qzHJs7u2ZcikxEAIRk5d0NG5xaM 4STd3SNoOhYZTSNuRrN7d1G3QNpM1yUkcRoMhgdCUlCSbJJPbwfIWldl7qN9 HlZXJiJbu6lG9m7U4AAbqSUiUTttbupEjDhvbztKrdJkGc808Q91e73nhAtt ttoAQ4ALbb3d0kZCxYXiSCWACSR9o3Rurpphi4XIRwB7s7jNCJWIqA4q1yuh sC7bouAZmdiWcTl3mdGt06tJiXcSTHDzDu+DRPCNT7d2Stbmk78AqACJRQKu 7f1rG23jnUuA4QhLEljiXEuNKLMet92sYHl5YD2rDA7XXMsnNq04UQBmYZMn d1TRMPbsN3rUfE8W4j0TSXDEF1sSp0kkhJPdtG7DENShhORUkyXuut1wtTLy JrmBgoRjmwOi4nBwAFRxuACApNsl1biPZWyBGbjTekpZcDiKSM6U4B3dxXST hzOErAgSOF2AOxwSXzoVb3VaeRO+7uJ6X2uVisHUyeMLysgc7nW6hj3Zhlu9 Jdc17sZ2G107hsSvq1cmtZ29MOvBeJ4jrdE9fOaNILyZFEj2LegDA3FEW3Fl C8zQSacuXd3dnbsXdh6e73n1zerzW/tT73wAGWJgZt90800yZns9p4AABttt P8KVM2gEl37xnc+5bY7L59nz9iQNppttttXtbz191W6vWzfc571c9og3dwPi QUAuXapSSUpIAAAABx798znOismL7t8+fLAGwYAZ2Jptw7m5qwXLvOR877m3 4Q9b4NjcchBknl3Dx7s55YFmLe5funUAcY2AgQABw7N5fva7rDnVmKdjAq7u 6u7q6gsCEnhJLphF01ym93mIGAhoTR9SSqyW9qlVOQOkdQ7ya6OH7S2doc2u Jf1bHdPVyZUOWDLyunsN5YLq9CfXVviu5VOsB1uycst1Z4uu0mw+yGwhiAVL lNqTmsYLzlFt9xVXgbdE3datvBoS2cJyyXvPTVw+PBTuMRrO871zc56++fpI hjTBgwYNgw7JfFl7ns8mglx5ueJvSSOSBIwiJAJISSSEki5N6nV+i7nPPm77 vW22222A1vmcx67+zW/nebffToAJM1v7vAOy83nfRKpKl++r1VfiPIrH8JXP OH1grdWAl1m89s1bXdd511zh4FIKQUgpBYHhpJSso9nL5v2umqazM155vOEO c9LKrsvM3nYQNqvb2hYa7LO8FYKst+APgAEwX5ft1Vbys1579wb3mXvvC+z6 rzDa4Xfcbbu5wedxZmZA33NpjTeqXRTqxyoO9V68jtduihJaZFCBvDTOxHXh ObSV5haplIWGL6iwzwe285dgva63pd9mqV1HI+e8jXq+qqqqBgNbRxBha57p SErNcNbGzd8vfcdEqCJBEgiQRIIkEQGdzXe7LHmd3m+hGIHVob1VqvOZ0e96 sAsistcjxb9Vevmga2i9sNcj6qqtR5muo46LfM173tRYNdRvHRK5KtrMqvKr 9V7ZISoLNJXI+r1C6VNdzqH3VZMvOqPVqc59b0zjhNZw1rvlZWg7goFm7fJd yaEM3WSLTqzxVGlriXa7fbpFGJ9XTmmHYiOsbiqyG6ZNHuQeHjxheq6OSk03 YNX2U5j6lglZj7vu+1CgKIQKO1vmu87NdvvOd13m7u6uq2qq7r3uWkjjiolc uo5QCHHTioIIKvUq6/ZfqoDiMJtUEuVGvX6q7keM6lrosMOvVdbtjuED50mU HQeZd3d3d3VCwAVVDd3etb12+nN67zfTbILIKHhkpkFC2SqqQpVXW6vN56/G /a7zfdOB9KqXZdVKuwDN87rfd6+z6c9vvvd03fqroG6u46MR5KsOIq066ULz DMu1YN47047Uq3mcFmiizMyBvuZRDXZ0OWnVhh0dvc7IThwdwUszq58psDs7 wVi5Q4t7egoUM63q5871jX2cbwW6O2GDCFspENFm7u6u68SDnAjnrosNFn3r VVvNZmrrVdzpvuu83muisBGAjEQESCMBma3mtbveu505nb3rt6gE6Qqkkkuq +d5O8x829XcRy+K227BA2DEJX3ueznOjfs8czRe9c1ios2qvpCqnqzm6+evy 7iOX3vG3gzxI2DBxA3AXjObNOezVLRl9zrwG222/UIat0NJtJPxObr5535dm KczucbbbeeSSSkjEwCMqu9n2u88+7n05vUZrm9B9LsAOJUAlSoT6pyd9vO+X Xt9xHFHk3mlzOvw3cdqVZG6E0rwbWoW+KHJaot5ECLCH1W3tPmEdEeKybUgc FIzYZ2E42tJuVqDxPSrQe3gPJ6+ulr6Mh5lLKGEd7yNz27ebvsfeejvd4222 3vFSAVIBUVVEKqiFVUOEUgpBSCkFIcr2ud93PZ2c3Xu9433vZIrMhCAQIa53 t3zje+9vC95pRRRV8ADQrRIUJue5577Dm+9eEmR5VUmMBtsBtCSJBCmLZr3t +86573sq9GgtoIRpoIAlUBVIoq6g00QaaINNENY+37Pfe39987l7tcqLXIty JYKIQhqfb++9v3ue+vjWNUQhQFEMS75ovT3t9ft9M9JgxjGMYxjGMYxgAADJ NUzpDmFJm7u7q7961UUuc4ukOZmoG5IAwNadXXjNDqt5r2e9b6ontvu2yr7d KeOVFr5okbZ2lOsocu5Gc8IzVFth0cvjiLOaSMyEG83m7E7r7lamMLYjrwXl KrIbaV3GJRVwy9lObpt69y8V2PVXvc9t65yTjxJGVUuvXBRIsC7oabTN4+z2 TO7677L8u2IGIaAAATVET3d5zO37t6z3MzM9SIwVRS9Pc3x4vt2NGVXu22oJ b59A2Up6quvXdeqN3fq86933NavM8kFgKQUgoMme3nqliSIDmBKqVXvEcumC M8obAfq91DT266ZvucztWQsFIKQUgpBSCkEhkBkAoUgpBSBOOd7mu3uuZzM7 dpKq1JJJe9YAAHMnrnL8zz3b7fN8u2tvKhtsLnmanuR3MdzsQqki7Lod1mDn 3IsEvuzOhluUctctey4NuM1eQDHa3U7ayM7pGrBeSjgbplHJgmXigadPZGZB snvTh4nezmvPevstnugADBgAB1VJJVSSUlJJVGTZ3vOGz2bzh7QAAAAAACmD Bqz3d3Th6+3Z7wAaonUq9WttuvUkkq9SSSr1JJKvUkkSSST1GtMTnDBFqWGT jPUkkSSSSSTJI5J1UqqSAAJqZnN1TPXszk94AAAYMAEHZJKoJpXZ7vvdfPX2 Xyb4xKqokiVJKSAAAAAAAWK572bqla3zV9ogpBSCkFIKQUGXXK1rvc3sM53J vW6aobpJMl5m7vALzik2uKmkFIKQUgpBQHMda5vveW1rfDL6Fooo7AqmiCVR CqaIJVENHXYlhqnWZplE1O9dBtg32vtUx7MMfIUe2waU6+ljixZddbMJ6rjp ZYD2/HrbvTkaq82S3tbEpjkXajrwWq0hvRjyKbfFXgZXZKGJ8KebuXr06jce cW4cvCDWczuPCCVRKpiqKLGvWWt1u+b93mvu4vnd6fa+x1a0u/sxRGS7S1in Z2q3ved3bV6bzud0xRRR2QqmiCVRAGKkxipMYqXJubm4cj5L5C83NWdpLHRh lyaFIKQUhZd2RDQBGGY0qTGKkx5FSI5EkRxjGM5O93qt5xky7j29V+5FJFI5 5KqSFJEqVdV27wRJJskGyRRJ2krSNO82Tzy0bZy4ormojjQSRyEchHIUo5CO QjkI5Mvj73Vz3B3a4cuOej91EcY5ERwFIRyEcg3IBIo5OF8c3u13jeTmeyOe j9pi1sWhCFrXFrWbe57HW7b+1zXH6bb8mNNjGakkkRxoEDTYgbAb4N3m6vPg 8nOS569ngbb1JAoRUiROKlIooqTFCKkSNxUhCkVSNxou8yU+sAYl6c11YKWW 8d5Qitkoc91nFItfdpyM0FTBGYNhxjgk1uK82U9KdLLcm7LUvRtlGrzUwurp A5ki0o68JB2rzO1McDEIreVwx7B17i2+JItpYLHxmc758GLmRabb8IbBYoJw ipQcIqUQhUgbFSBsVIGxA2m20J77nvk5bNa5jV/Z4UIgiQKRAgYiCJU5vePO d0e1x9nS/d9W9L9VLcagBHG+fvT5y3c7h6d9zYUVUKqKQWTJFABlhdFEFIKQ UgpBSCFMgs03rvDrunOc1lPTXd6yVVBV3aAIkXEBd2a3e89vfZ5dszsvpzu9 LAc1ea7w67pzucxTOXIhIsInQAC8Nuayu8Ouynl6vpzuBcEmbazTVOzlrVt2 6T6tuqp0FegrzF2dO2ytrxz/X9v5kgBiT/j/8Uf2iiEhCQIH5/uKAP7z9p/v /z/2P4n+Rr/l/nVp/l/if5/9jP3n7wSJ/4n9v91n96pouIUiIn7igP+kmOj/ ob2H95vD0JJr+8w0Rhsqg8ISSfy8FDCZ8f1nrqJ+s/9xn4n9KgSQwGH6+h0u Ek1+P9DA6JNSx1eOxJQmUe6X/zCaA/9oS2CiigsBRQgDCMgREWQAUgsIRZII kWQqgkoACoSQqqlQqQqCyKsWLAikiCRRZFkFkIoRZBZAWAKQUikikIoLAERS LARAkUUFCKQkIowjIBAWEFFgKCiwiikIAopCKCiyCixRSKLCSKLIKLBRZIos iiyQUWECKLAFFkUUIQFFFFIBFFhFixYSoQhISUQqSEkhUJCgAAUIApKACEIF SAEUWAosIopIooRRQUWALFAFFgEUUFikFFklElUigRUqSFIqIKIAFVkkgCKw AgqrIsEQWRZKKqUSEKhKkJAKokCqkQEKKkhCqhCoUVUiKAIEFFFILCCkFgEF FkBRSKKQgAopBYpBRYRYoQFCqohVVCEqQhJIQqiEgLIooSQWLAUWQgosgopJ CEohVQhJIhQAqQAQIAlQACEqoQJUqpSEQkiikIosiihFICooqAAIoAACggSq CSqqRBVIJKKAqEilVUoiqSCySSCgCKiwiqRZCKqqKoKEiwIKASREJFiwUWCy CgoKCwIKRQIQFhIFSSUSiFQgRFSUVSJSgiCwgsgKSCyKChFCLAFgAjIEWSKL BRSCiiiwkFFkFFAUWAosCKLJFFkkgooSKLCQiikkkUUiigEBRQiiyKLIopIC igKLBYEQKAQJICAoJQEFVVCKQBSCrAkiESQjFGQkkFWALAIKAsgqkigRQikh FkFVVAUILEQixSQUCCrFRAWQUABSKLGMRWQqVCEqFRSVUqSEkoAAAgEkhRVQ hUhCpUKJQCiwFFkUWAKKARRYopCLFkBRSRRYCxYKKQgCigCxZIoskFFICxSE UWKKqoAAACFIkCpUkgqkWRZFIoIyEBYQEIxGLKkKgVUCoQgiUFVUiKkCUERU kAAqVQSVCqhJAWRQJIkjAgoiEUkiwFBYrEUgsjEkBSIiwUWAQWioVIVCSFSV CQKhVBIQJAgioSIAAAACEFhBYQUWCgoQFUkFFhBYoLFgCikgopBYpIooLBQi ihFFkiikiiwgRRRRYAosgAKKSKKQUWCiwkFFkBRSKQEVUkIAosUkUgMQFhFi yQGIQWSCqCkhKgSqkAqoEgIJVFURQFUWERkYyQWREiwFgoLIskFIpBRYqMBZ ABEIQAUUgCyEBYEAUkAYRhCKKEgosAWLAUUiigKLICiwFFhBRYRRQkUUCKLJ FiwIooBIsWQkFFIAsAWQkJCqJUhRRCSiEkoJQQACkIAhAAAKiqshIiRSLCKo ARYIhAWAKpCApIsJBVVVWSRjAIsgKEiyQIpAiyCIAgwUqVCEoqiQkIUSqIVU KoAikARCAsAVQigCyCkkRJRAqgqQKokiJJICEYoCkVUSKQIArIMIRYSLRJCV KCEqiFVVEJUKJRRVVIQkIVRCiElERRVUQySAooCixRSEgsWAoskFCSQhRRKh CqlEKlIRAqiFFFVQFAElCCgJSqSEiwkUFJFCSApBQCKhEgRRUYKCyAIqEIKE WRRBQUBAIQhURRVEqosgLERQFFkFWAKKKBAWAsCRSLFhFCKoQUBYCKKwBQik BYBFhBYsigLJBQgosJFFkgKLIsFICxSKKAKKSKLFFJJIsWSKKQUKISUQohVE JKqiFSqKCQUWQUUFFkIoKEBYAsFKKqFVCFUBKoIEqoSpCpISSBCSIKgSBRVE KkIRQBVIKqJIQn5w/MQsn4EQ/of8QgECECrP2h/2f9v0a/SzhZ+P6H7y3kVo /L3fFYT8eFSZDgfiYXP3a2f4l2fgT/Z3/KYdKP1Qkmj8NH5c/DDDoOxD+XLP 2lHvQkn8P1hoP5Qkn9oQCBCBz9IABJD+jAhIEkn9RJ/Wfxn8jwUfn/kfoCAk RE/Q3A/cIYBo0f/h/mJsEMJ+X4bns/SEk/GBAhD9LMskkIBAPxCBJIED9Ygp +w0oss/q/IkCEgQN9DhRUJ+Z2WX+Rf4BJJR+7Z+J+s/KAfoH7ISS+wknAkk3 CSfsP1XL/M/EP3j8JoNH+1w3/E2HD9Dh2EgQIQL/aGvzLGQkaYqxSSQgEA2f vwvCEJJAgbAgQhaSSEAgFT+ZlEISSBA/AkkIBAOwkl/uOFTx+MkCSQIH5jxN zpCiSQgEAv8sCpD9k/A/H8j8RKiH6kjGSSRYKSQhIEBYshR+Z+B+JcP0Dfj4 ehU8dohCEgQPyPcP3yUaJAhIECgws+9OZ+v9RcvKhJNf9odCVYfhCSeGw5wk CEgQMA/OEkf3hAIEIGjgfl+6NB+oTZ+USiz+ISSJZhRnk0PYST8/wPbP2BqS SfGGfgONnYJAAsNdoYkDRR++HqNnD8C+H7WbNGxPip/N/CEkS7hJPyQkks/X /EP3QkCBCBskCEgQOn6z9sJJ+v8Qln9xo2OH+JR/YEAgQgfs/uC4T8gv+f4n 55S9X/q/+Wr/pf/i7kinChIdRqhtoA== --1681990229-1839033695-992164303=:8848-- From owner-linux-xfs@linux-xfs.sgi.com Sat Jun 9 12:34:26 2001 Received: (from majordomo@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f59JYQZf006502 for linux-xfs-outgoing; Sat, 9 Jun 2001 12:34:26 -0700 X-Authentication-Warning: linux-xfs.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f59JYO3D006499 for ; Sat, 9 Jun 2001 12:34:25 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f59JYIaJ051950; Sat, 9 Jun 2001 14:34:18 -0500 (CDT) Message-ID: <3B227A34.495F6A5D@thebarn.com> Date: Sat, 09 Jun 2001 14:34:13 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Walt H CC: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: cvs working again References: <200106082112.f58LCks17786@jen.americas.sgi.com> <3B2178DC.2090803@uswest.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Walt H wrote: > Hello, > > I'm getting a strange error when attempting a checkout at CVS now: > > cvs -z3 co linux-2.4-xfs > cvs [server aborted]: can't chdir(/home/cattelan): No such file or directory I have no idea why cvs wants too look in my home directory but I just created home/cattelan in the chrooted space; seem to work now. > > > Maybe I'm spaced out (it's happened before), but I can't seem to co > anything at the moment. I wanted to try 2.4.6-pre1 to see if it > corrected the high memory usage that showed up with 2.4.5 - don't think > it's XFS related though, cause /proc/slab shows no unusual usage with > inodes etc... Just improper freeing by the VM it would appear. Too much > swap usage for this system. Any help is greatly appreciated. Thanks, > > -Walt > > Steve Lord wrote: > > >We are still using a backup machine for oss, but cvs is functioning again now. > > > >Steve > > > > > > -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Sat Jun 9 14:04:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f59L4Zb01978 for linux-xfs-outgoing; Sat, 9 Jun 2001 14:04:35 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f59L4YV01973 for ; Sat, 9 Jun 2001 14:04:34 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip9.idcomm.com [209.60.72.136]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f59L3ZF14395 for ; Sat, 9 Jun 2001 15:03:35 -0600 Message-ID: <3B228F91.3E63027C@idcomm.com> Date: Sat, 09 Jun 2001 15:05:21 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: how to tell? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This seems strangely simple, and possibly absurd to ask, but now that I have a system running with xfs, I have to wonder if there is some fast/simple way to sit down at any linux machine and find out what filesystem type it runs on a particular mount point? df, does not say, and fdisk only mentions linux native. For ext2 there is the lost+found directory as a clue, but I don't know if maybe some other future system might also have this directory; add to this that migrating an old filesystem can leave a lost+found on the new one as an artifact, so it really is not a good clue. What is the simple means to know that a machine I'm sitting at as an administrator (but not installed by me) is running xfs or any other filesystem type? D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Sat Jun 9 14:12:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f59LCLb02145 for linux-xfs-outgoing; Sat, 9 Jun 2001 14:12:21 -0700 Received: from woody.fsl.noaa.gov (IDENT:root@woody.fsl.noaa.gov [137.75.132.225]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f59LCKV02141 for ; Sat, 9 Jun 2001 14:12:20 -0700 Received: (from tierney@localhost) by woody.fsl.noaa.gov (8.9.3/8.9.3) id PAA31678; Sat, 9 Jun 2001 15:10:19 -0600 Date: Sat, 9 Jun 2001 15:10:19 -0600 From: Craig Tierney To: "D. Stimits" Cc: "linux-xfs@oss.sgi.com" Subject: Re: how to tell? Message-ID: <20010609151018.F31347@hpti.com> References: <3B228F91.3E63027C@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.6i In-Reply-To: <3B228F91.3E63027C@idcomm.com>; from stimits@idcomm.com on Sat, Jun 09, 2001 at 03:05:21PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk cat /proc/partitions Look at the 3rd item on each line. Craig > This seems strangely simple, and possibly absurd to ask, but now that I > have a system running with xfs, I have to wonder if there is some > fast/simple way to sit down at any linux machine and find out what > filesystem type it runs on a particular mount point? df, does not say, > and fdisk only mentions linux native. For ext2 there is the lost+found > directory as a clue, but I don't know if maybe some other future system > might also have this directory; add to this that migrating an old > filesystem can leave a lost+found on the new one as an artifact, so it > really is not a good clue. What is the simple means to know that a > machine I'm sitting at as an administrator (but not installed by me) is > running xfs or any other filesystem type? > > D. Stimits, stimits@idcomm.com -- Craig Tierney (ctierney@hpti.com) phone: 303-497-3112 From owner-linux-xfs@oss.sgi.com Sat Jun 9 14:13:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f59LD1P02180 for linux-xfs-outgoing; Sat, 9 Jun 2001 14:13:01 -0700 Received: from vitelus.com (vitelus.com [64.81.36.147]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f59LD1V02177 for ; Sat, 9 Jun 2001 14:13:01 -0700 Received: from aaronl by vitelus.com with local (Exim 3.22 #1 (Debian)) id 158q2U-0005YZ-00; Sat, 09 Jun 2001 14:12:58 -0700 Date: Sat, 9 Jun 2001 14:12:58 -0700 From: Aaron Lehmann To: "D. Stimits" Cc: "linux-xfs@oss.sgi.com" Subject: Re: how to tell? Message-ID: <20010609141258.A21324@vitelus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B228F91.3E63027C@idcomm.com> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Jun 09, 2001 at 03:05:21PM -0600, D. Stimits wrote: > This seems strangely simple, and possibly absurd to ask, but now that I > have a system running with xfs, I have to wonder if there is some > fast/simple way to sit down at any linux machine and find out what > filesystem type it runs on a particular mount point? df, does not say, > and fdisk only mentions linux native. Try the 'mount' command. From owner-linux-xfs@oss.sgi.com Sat Jun 9 14:16:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f59LGDD02389 for linux-xfs-outgoing; Sat, 9 Jun 2001 14:16:13 -0700 Received: from mail.unixcircle.com (adsl-63-193-121-28.dsl.snfc21.pacbell.net [63.193.121.28]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f59LGCV02386 for ; Sat, 9 Jun 2001 14:16:12 -0700 Received: from unixcircle.com (pissboy.unixcircle.com [10.0.0.13]) by mail.unixcircle.com (8.12.0.Beta10/unixcircle) with ESMTP id f59LFXgD004728; Sat, 9 Jun 2001 14:15:33 -0700 (PDT) Message-ID: <3B2291FB.B5A59FD8@unixcircle.com> Date: Sat, 09 Jun 2001 14:15:39 -0700 From: rollingblackout Organization: a fool with a tool is still a fool -- fool@unixcircle.org X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: stimits@idcomm.com, linux-xfs@oss.sgi.com Subject: Re: how to tell? References: <3B228F91.3E63027C@idcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "D. Stimits" wrote: > > This seems strangely simple, and possibly absurd to ask, but now that I > have a system running with xfs, I have to wonder if there is some > fast/simple way to sit down at any linux machine and find out what > filesystem type it runs on a particular mount point? df, does not say, > and fdisk only mentions linux native. For ext2 there is the lost+found > directory as a clue, but I don't know if maybe some other future system > might also have this directory; add to this that migrating an old > filesystem can leave a lost+found on the new one as an artifact, so it > really is not a good clue. What is the simple means to know that a > machine I'm sitting at as an administrator (but not installed by me) is > running xfs or any other filesystem type? > > D. Stimits, stimits@idcomm.com how about "mount" command? [thang@pissboy thang]$ mount /dev/hda5 on / type xfs (rw) none on /proc type proc (rw) /dev/hda6 on /xfs type xfs (rw) /dev/hda3 on /reiser type reiserfs (rw) /dev/hda1 on /win type vfat (rw) /dev/hda2 on /ext2 type ext2 (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) cheers! From owner-linux-xfs@oss.sgi.com Sat Jun 9 14:17:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f59LH3602417 for linux-xfs-outgoing; Sat, 9 Jun 2001 14:17:03 -0700 Received: from web12704.mail.yahoo.com (web12704.mail.yahoo.com [216.136.173.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f59LH2V02414 for ; Sat, 9 Jun 2001 14:17:02 -0700 Message-ID: <20010609211702.43593.qmail@web12704.mail.yahoo.com> Received: from [216.88.88.108] by web12704.mail.yahoo.com; Sat, 09 Jun 2001 14:17:02 PDT Date: Sat, 9 Jun 2001 14:17:02 -0700 (PDT) From: john simms Subject: Re: how to tell? To: stimits@idcomm.com, "linux-xfs@oss.sgi.com" In-Reply-To: <3B228F91.3E63027C@idcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk cat /etc/fstab --- "D. Stimits" wrote: > This seems strangely simple, and possibly absurd to > ask, but now that I > have a system running with xfs, I have to wonder if > there is some > fast/simple way to sit down at any linux machine and > find out what > filesystem type it runs on a particular mount point? > df, does not say, > and fdisk only mentions linux native. For ext2 there > is the lost+found > directory as a clue, but I don't know if maybe some > other future system > might also have this directory; add to this that > migrating an old > filesystem can leave a lost+found on the new one as > an artifact, so it > really is not a good clue. What is the simple means > to know that a > machine I'm sitting at as an administrator (but not > installed by me) is > running xfs or any other filesystem type? > > D. Stimits, stimits@idcomm.com > __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-linux-xfs@oss.sgi.com Sat Jun 9 14:22:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f59LMof02649 for linux-xfs-outgoing; Sat, 9 Jun 2001 14:22:50 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f59LMnV02644 for ; Sat, 9 Jun 2001 14:22:50 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f59LMmaJ052532 for ; Sat, 9 Jun 2001 16:22:48 -0500 (CDT) Message-ID: <3B2293A3.8CBA3CF0@thebarn.com> Date: Sat, 09 Jun 2001 16:22:43 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Ok this is really a test message Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk But I thought I would update every body on the status of oss Thursday night the machine locked up hard ... no idea what happened here but since things were down and all the data had been transferred to linux-xfs it took over services for oss. (web, ftp, mail, cvs ) Since oss was out of the loop any ways we decided to go ahead and upgrade the machine to RH 7..1 + XFS 1.0 , which is where things are at currently. While some outages were experienced generally due to configuration differences between RH 6.1 and RH 7.1 I hope it wasn't to much inconvenience, and while we have tired to test most services on oss it is possible something may not be exactly right just yet. Thank for your patience -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Sat Jun 9 14:39:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f59LdSC03594 for linux-xfs-outgoing; Sat, 9 Jun 2001 14:39:28 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f59LdQV03591 for ; Sat, 9 Jun 2001 14:39:27 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip12.idcomm.com [209.60.72.139]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f59LcSF17388 for ; Sat, 9 Jun 2001 15:38:28 -0600 Message-ID: <3B2297BE.7A0D5480@idcomm.com> Date: Sat, 09 Jun 2001 15:40:14 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: Re: how to tell? References: <3B228F91.3E63027C@idcomm.com> <3B2291FB.B5A59FD8@unixcircle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk rollingblackout wrote: > > "D. Stimits" wrote: > > > > This seems strangely simple, and possibly absurd to ask, but now that I > > have a system running with xfs, I have to wonder if there is some > > fast/simple way to sit down at any linux machine and find out what > > filesystem type it runs on a particular mount point? df, does not say, > > and fdisk only mentions linux native. For ext2 there is the lost+found > > directory as a clue, but I don't know if maybe some other future system > > might also have this directory; add to this that migrating an old > > filesystem can leave a lost+found on the new one as an artifact, so it > > really is not a good clue. What is the simple means to know that a > > machine I'm sitting at as an administrator (but not installed by me) is > > running xfs or any other filesystem type? > > > > D. Stimits, stimits@idcomm.com > > how about "mount" command? > > [thang@pissboy thang]$ mount > /dev/hda5 on / type xfs (rw) > none on /proc type proc (rw) > /dev/hda6 on /xfs type xfs (rw) > /dev/hda3 on /reiser type reiserfs (rw) > /dev/hda1 on /win type vfat (rw) > /dev/hda2 on /ext2 type ext2 (rw) > none on /dev/pts type devpts (rw,gid=5,mode=620) > > cheers! Ahh, so simple, thanks. Related to some other answers, it looks like the /proc/partitions does not actually list filesystem type; and mtab is good, but the mount command without arguments seems to be the easiest. Thanks! D. Stimits, stimits@idcomm.com PS: I always get two copies of anything sent to the sgi-devel list. I am also subscribed to the announce list, perhaps everything is going to both lists? Seems a bit like a minor quirk. From owner-linux-xfs@oss.sgi.com Sat Jun 9 15:05:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f59M50B04200 for linux-xfs-outgoing; Sat, 9 Jun 2001 15:05:00 -0700 Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f59M4wV04196 for ; Sat, 9 Jun 2001 15:04:58 -0700 Received: from qn-212-58-163-247.quicknet.nl ([212.58.163.247]:61244 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Sun, 10 Jun 2001 00:04:34 +0200 Message-Id: <4.3.2.7.2.20010609235556.031a2c68@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 10 Jun 2001 00:04:33 +0200 To: stimits@idcomm.com, "linux-xfs@oss.sgi.com" From: Seth Mos Subject: Re: how to tell? In-Reply-To: <3B2297BE.7A0D5480@idcomm.com> References: <3B228F91.3E63027C@idcomm.com> <3B2291FB.B5A59FD8@unixcircle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:40 9-6-2001 -0600, D. Stimits wrote: >rollingblackout wrote: > > > > "D. Stimits" wrote: > > Ahh, so simple, thanks. Related to some other answers, it looks like the >/proc/partitions does not actually list filesystem type; and mtab is >good, but the mount command without arguments seems to be the easiest. >Thanks! awk '{print $3}' '/proc/mounts' >D. Stimits, stimits@idcomm.com > >PS: I always get two copies of anything sent to the sgi-devel list. I am >also subscribed to the announce list, perhaps everything is going to >both lists? Seems a bit like a minor quirk. That's probably the result of the reply to all function in the mail clients. Bye -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sat Jun 9 15:24:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f59MOxT04823 for linux-xfs-outgoing; Sat, 9 Jun 2001 15:24:59 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f59MOwV04820 for ; Sat, 9 Jun 2001 15:24:59 -0700 Received: from [192.168.1.10] (helo=den2) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 158r9w-0004D1-00; Sun, 10 Jun 2001 10:24:44 +1200 From: "Juha Saarinen" To: "'Russell Cattelan'" , "'Walt H'" Cc: "'Steve Lord'" , Subject: RE: cvs working again Date: Sun, 10 Jun 2001 10:24:26 +1200 Message-ID: <006101c0f132$f1706e30$0a01a8c0@den2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3B227A34.495F6A5D@thebarn.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk :: I have no idea why cvs wants too look in my home directory :: but I just created home/cattelan in the chrooted space; :: seem to work now. Because.... ALL YOUR FILES ARE BELONG TO US! (Sorry, couldn't resist... I know it's old by now...) -- Juha From owner-linux-xfs@oss.sgi.com Sat Jun 9 16:11:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f59NBnZ05493 for linux-xfs-outgoing; Sat, 9 Jun 2001 16:11:49 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f59NBmV05490 for ; Sat, 9 Jun 2001 16:11:48 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip88.idcomm.com [209.60.72.215] (may be forged)) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f59NAoF25314 for ; Sat, 9 Jun 2001 17:10:50 -0600 Message-ID: <3B22AD66.ABE507FD@idcomm.com> Date: Sat, 09 Jun 2001 17:12:38 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: Re: how to tell? References: <3B228F91.3E63027C@idcomm.com> <3B2291FB.B5A59FD8@unixcircle.com> <4.3.2.7.2.20010609235556.031a2c68@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > > At 15:40 9-6-2001 -0600, D. Stimits wrote: > >rollingblackout wrote: > > > > > > "D. Stimits" wrote: > > > Ahh, so simple, thanks. Related to some other answers, it looks like the > >/proc/partitions does not actually list filesystem type; and mtab is > >good, but the mount command without arguments seems to be the easiest. > >Thanks! > > awk '{print $3}' '/proc/mounts' Aha, that one works. The one I had viewed though was from "cat /proc/partitions Look at the 3rd item on each line" /proc/mounts is yet another easy way to find out, but /proc/partitions was the way that did not give the info. > > >D. Stimits, stimits@idcomm.com > > > >PS: I always get two copies of anything sent to the sgi-devel list. I am > >also subscribed to the announce list, perhaps everything is going to > >both lists? Seems a bit like a minor quirk. > > That's probably the result of the reply to all function in the mail clients. That is probably it...it isn't the list sending both, but a reply to the list that I receive, and the copy sent directly to me. D. Stimits, stimits@idcomm.com > > Bye > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. From owner-linux-xfs@oss.sgi.com Sat Jun 9 16:21:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f59NLuu05700 for linux-xfs-outgoing; Sat, 9 Jun 2001 16:21:56 -0700 Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f59NLtV05697 for ; Sat, 9 Jun 2001 16:21:55 -0700 Received: from gateway (dhcp181-19-151-24.nm01-c3.cpe.charter-ne.com [24.151.19.181]) by falcon.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id QAA24782 for ; Sat, 9 Jun 2001 16:21:53 -0700 (PDT) Message-ID: <002401c0f13a$a4798b40$0600a8c0@gateway> Reply-To: "Sean P. Elble" From: "Sean P. Elble" To: Subject: XFS/Linux 1.1? Date: Sat, 9 Jun 2001 19:19:30 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C0F119.1BB50B20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C0F119.1BB50B20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Does anyone have any idea as to when the next "official" release of = XFS/Linux will occur? I'm currently running a CVS version, but I'd feel = a lot more comfortable with an official release, and god knows a ton of = problems/bugs have been fixed since the initial release. Any thoughts? Sean Elble S_elble at yahoo.com ------=_NextPart_000_0021_01C0F119.1BB50B20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
Does anyone have any idea as to when = the next=20 "official" release of XFS/Linux will occur? I'm currently running a CVS = version,=20 but I'd feel a lot more comfortable with an official release, and god = knows a=20 ton of problems/bugs have been fixed since the initial release. Any=20 thoughts?
Sean Elble
S_elble at yahoo.com

 
------=_NextPart_000_0021_01C0F119.1BB50B20-- From owner-linux-xfs@oss.sgi.com Sat Jun 9 16:27:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f59NRDJ05910 for linux-xfs-outgoing; Sat, 9 Jun 2001 16:27:13 -0700 Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f59NRDV05907 for ; Sat, 9 Jun 2001 16:27:13 -0700 Received: from gateway (dhcp181-19-151-24.nm01-c3.cpe.charter-ne.com [24.151.19.181]) by falcon.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id QAA10707 for ; Sat, 9 Jun 2001 16:27:11 -0700 (PDT) Message-ID: <003201c0f13b$61c46800$0600a8c0@gateway> Reply-To: "Sean P. Elble" From: "Sean P. Elble" To: Subject: XFS/Linux 1.1?? Date: Sat, 9 Jun 2001 19:24:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, Does anyone have any idea as to when the next "official" release of = XFS/Linux will occur? I'm currently running a CVS version, but I'd feel = a lot more comfortable with an official release, and god knows a ton of = problems/bugs have been fixed since the initial release. Any thoughts? Sean Elble S_elble at yahoo.com From owner-linux-xfs@oss.sgi.com Sat Jun 9 16:56:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f59Nu2h06328 for linux-xfs-outgoing; Sat, 9 Jun 2001 16:56:02 -0700 Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f59Nu1V06325 for ; Sat, 9 Jun 2001 16:56:01 -0700 Received: from qn-212-58-163-247.quicknet.nl ([212.58.163.247]:61476 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Sun, 10 Jun 2001 01:56:00 +0200 Message-Id: <4.3.2.7.2.20010610015041.0342cb18@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 10 Jun 2001 01:55:59 +0200 To: "Sean P. Elble" , From: Seth Mos Subject: Re: XFS/Linux 1.1?? In-Reply-To: <003201c0f13b$61c46800$0600a8c0@gateway> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 19:24 9-6-2001 -0400, Sean P. Elble wrote: >Hello, > >Does anyone have any idea as to when the next "official" release of = >XFS/Linux will occur? I'm currently running a CVS version, but I'd feel = >a lot more comfortable with an official release, and god knows a ton of = >problems/bugs have been fixed since the initial release. Any thoughts? > >Sean Elble >S_elble at yahoo.com I can't predict. The CVS version is much better then the 1.0 release tree. Btw the 1.0 installer was pretty packaging. The only packages that have to be respun are the acl kernel xfsprogs and devel packages. The installer can be reused for 1.0.1 which will be the next release. The version will at least contain a newer kernel and tools. It will take time to release it. It will have to be run through the mill of Q&A tests and tortures. And that takes a _lot_ of time. Bye ps: don't post html mail to the list please. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sat Jun 9 17:53:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A0r1k07184 for linux-xfs-outgoing; Sat, 9 Jun 2001 17:53:01 -0700 Received: from web11701.mail.yahoo.com (web11701.mail.yahoo.com [216.136.172.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A0r0V07177 for ; Sat, 9 Jun 2001 17:53:00 -0700 Message-ID: <20010610005300.21016.qmail@web11701.mail.yahoo.com> Received: from [24.151.19.181] by web11701.mail.yahoo.com; Sat, 09 Jun 2001 17:53:00 PDT Date: Sat, 9 Jun 2001 17:53:00 -0700 (PDT) From: Sean Elble Subject: Re: XFS/Linux 1.1?? To: Seth Mos , linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20010610015041.0342cb18@pop.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks for the reply . . . I'm using the CVS version because it was supposed to be better than the 1.0 release, and I havn't suffered any crashes, or failures of any kind for that matter, but, I would feel "safer" with a official release. I understand that you can't make a prediction, but I just don't understand why they havn't started the tests for a release yet (have they?). Thanks again for the reply. P.S: I apologize for the HTML . . . can't ever remember what machines have it, and what don't. :-) --- Seth Mos wrote: > At 19:24 9-6-2001 -0400, Sean P. Elble wrote: > >Hello, > > > >Does anyone have any idea as to when the next > "official" release of = > >XFS/Linux will occur? I'm currently running a CVS > version, but I'd feel = > >a lot more comfortable with an official release, > and god knows a ton of = > >problems/bugs have been fixed since the initial > release. Any thoughts? > > > >Sean Elble > >S_elble at yahoo.com > > I can't predict. The CVS version is much better then > the 1.0 release tree. > > Btw the 1.0 installer was pretty packaging. The only > packages that have to > be respun are the acl kernel xfsprogs and devel > packages. The installer can > be reused for 1.0.1 which will be the next release. > > The version will at least contain a newer kernel and > tools. > It will take time to release it. It will have to be > run through the mill of > Q&A tests and tortures. And that takes a _lot_ of > time. > > Bye > > ps: don't post html mail to the list please. > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. > ===== ------------------------------ Sean Elble MaximumLinux.org Voice Mail: 1-800-699-2466; Voice Mail Box 8603550213 E-Mail: S_Elble@yahoo.com ------------------------------ __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-linux-xfs@oss.sgi.com Sat Jun 9 18:21:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A1LvQ07739 for linux-xfs-outgoing; Sat, 9 Jun 2001 18:21:57 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A1LuV07736 for ; Sat, 9 Jun 2001 18:21:56 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA00811 for ; Sat, 9 Jun 2001 18:22:14 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA2112171; Sat, 9 Jun 2001 20:20:39 -0500 (CDT) Received: from lord.americas.sgi.com (IDENT:root@lord.americas.sgi.com [128.162.184.125]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id UAA01792; Sat, 9 Jun 2001 20:20:39 -0500 (CDT) Received: from lord.americas.sgi.com by lord.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f59Nb4E15754; Sat, 9 Jun 2001 18:37:04 -0500 Message-Id: <200106092337.f59Nb4E15754@lord.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Sean Elble cc: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: XFS/Linux 1.1?? In-Reply-To: Message from Sean Elble of "Sat, 09 Jun 2001 17:53:00 PDT." <20010610005300.21016.qmail@web11701.mail.yahoo.com> Date: Sat, 09 Jun 2001 18:37:04 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Thanks for the reply . . . I'm using the CVS version > because it was supposed to be better than the 1.0 > release, and I havn't suffered any crashes, or > failures of any kind for that matter, but, I would > feel "safer" with a official release. I understand > that you can't make a prediction, but I just don't > understand why they havn't started the tests for a > release yet (have they?). Thanks again for the reply. Because we currently have a staff of 2 working on XFS kernel related stuff, myself and Eric (Ananth is on vacation). Eric just relocated across half the country and his wife is expecting (I have an 18 month old to complete the picture). Packaging kernel RPMs takes a fair amount of effort and time (cpu and otherwise). As does keeping up with the mailing list, fixing bugs, merging up to new kernel releases, and in my case doing a lot of other work on different projects too. There will be some new kernel RPMs, but it may take a little bit yet, especially if you want them tested (fortunately there are some other resources there). Steve From owner-linux-xfs@oss.sgi.com Sat Jun 9 18:37:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A1bhF08190 for linux-xfs-outgoing; Sat, 9 Jun 2001 18:37:43 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A1bgV08187 for ; Sat, 9 Jun 2001 18:37:42 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id VAA15756; Sat, 9 Jun 2001 21:30:39 -0400 Message-ID: <3B22D1F6.434FFE0A@ieee.org> Date: Sat, 09 Jun 2001 21:48:38 -0400 From: "Bryan J. Smith" Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Sean Elble , Seth Mos , linux-xfs@oss.sgi.com Subject: Re: XFS/Linux 1.1?? References: <200106092337.f59Nb4E15754@lord.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > Packaging kernel RPMs takes a fair amount of effort and time (cpu and > otherwise). As does keeping up with the mailing list, fixing bugs, merging > up to new kernel releases, and in my case doing a lot of other work on > different projects too. > There will be some new kernel RPMs, but it may take a little bit yet, > especially if you want them tested (fortunately there are some other > resources there). Are any of the distro vendors taking _any_ interest? I'm still perplexed that the distro vendors haven't seriously looked at XFS, or at least it appears they have not. IMHO, it's time for them to "step up to the plate" and start supporting a JFS that does all they want. BTW, I see RedHat has added the Ext3 patch to their 2.4.5-0.2.9 release, but I've see nothing but "problems" on the Ext3 list (although a lot are Ext2 issues under 2.4.x as well). IMHO, I think Tweedie/RedHat should just focus on getting full data journaling complete (I'm still wondering why I tried to do meta-data journaling) and leave any "advanced" features to other JFS' like XFS. But I'm not going to start a whole flamewar on that (let alone knock all that Tweedie has done and continues to do). -- TheBS -- Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 SmithConcepts, Inc. http://www.SmithConcepts.com ========================================================== Linux 'Worms' exploit known security holes that were fixed 3-12 months earlier. NT/2000 'Worms' exploit unknown se- curity holes that won't be fixed for another 3-12 months. From owner-linux-xfs@oss.sgi.com Sat Jun 9 18:45:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A1jD408368 for linux-xfs-outgoing; Sat, 9 Jun 2001 18:45:13 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A1jAV08365 for ; Sat, 9 Jun 2001 18:45:10 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5A1jfA18912; Sun, 10 Jun 2001 11:45:46 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Russell Cattelan cc: linux-xfs@oss.sgi.com Subject: Re: Ok this is really a test message In-reply-to: Your message of "Sat, 09 Jun 2001 16:22:43 EST." <3B2293A3.8CBA3CF0@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Jun 2001 11:45:41 +1000 Message-ID: <18911.992137541@ocs4.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 09 Jun 2001 16:22:43 -0500, Russell Cattelan wrote: >Since oss was out of the loop any ways we decided to go ahead and >upgrade the >machine to RH 7..1 + XFS 1.0 , which is where things are at currently. The only problem so far is that ssh asked for my password. Turned out that sshd on oss now talks DSA as well as RSA. Anybody using ssh 2 to access oss needs to (a) Generate a DSA key on your machine if not already done, ssh-keygen -t dsa. (b) Append ~/.ssh/id_dsa.pub from your machine to ~/.ssh/authorized_keys2 (not authorized_keys) on oss. Of course everybody should be using ssh 2, there are security problems with ssh 1 protocol. From owner-linux-xfs@oss.sgi.com Sat Jun 9 18:48:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A1m4b08482 for linux-xfs-outgoing; Sat, 9 Jun 2001 18:48:04 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A1m3V08479 for ; Sat, 9 Jun 2001 18:48:03 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id VAA15888; Sat, 9 Jun 2001 21:41:49 -0400 Message-ID: <3B22D493.84DBFF25@ieee.org> Date: Sat, 09 Jun 2001 21:59:47 -0400 From: "Bryan J. Smith" Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Alan Eldridge CC: Keith Owens , linux-xfs@oss.sgi.com Subject: Re: Russell's patch against RH 7.1 ... References: <20010608233837.A11062@wwweasel.geeksrus.net> <8648.992061344@ocs4.ocs-net> <20010609004432.A12217@wwweasel.geeksrus.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alan Eldridge wrote: > The patch I'm using is one he did last night. It's for RH Rawhide > 2.4.5-0.2.9 kernel. It's on ftp.thebarn.com in /SGI/testing. *DUMB* question: What is the "RHlinux-*" file for? I looked through the files and it seems to be a subset of the other. -- TheBS -- Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 SmithConcepts, Inc. http://www.SmithConcepts.com ========================================================== Linux 'Worms' exploit known security holes that were fixed 3-12 months earlier. NT/2000 'Worms' exploit unknown se- curity holes that won't be fixed for another 3-12 months. From owner-linux-xfs@oss.sgi.com Sat Jun 9 19:25:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A2PUg09180 for linux-xfs-outgoing; Sat, 9 Jun 2001 19:25:30 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A2PSV09177 for ; Sat, 9 Jun 2001 19:25:28 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5A2QP419181; Sun, 10 Jun 2001 12:26:26 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Bryan J. Smith" cc: linux-xfs@oss.sgi.com, Russell Cattelan Subject: Re: Russell's patch against RH 7.1 ... In-reply-to: Your message of "Sat, 09 Jun 2001 21:59:47 -0400." <3B22D493.84DBFF25@ieee.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Jun 2001 12:26:25 +1000 Message-ID: <19180.992139985@ocs4.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 09 Jun 2001 21:59:47 -0400, "Bryan J. Smith" wrote: >*DUMB* question: What is the "RHlinux-*" file for? I looked >through the files and it seems to be a subset of the other. linux-2.4.5-xfs-06082001.patch contains the new XFS files, RHlinux-2.4.5-core-xfs-06082001.patch contains XFS changes to the core kernel. BTW Russell, linux-2.4.5-xfs-06082001.patch contains lots of generated files. You need to exclude .depend, .hdepend and .*flags files. From owner-linux-xfs@oss.sgi.com Sat Jun 9 19:41:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A2fC509467 for linux-xfs-outgoing; Sat, 9 Jun 2001 19:41:12 -0700 Received: from sphinx.druber.com (druber-gw.lightband.com [216.129.135.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A2fBV09464 for ; Sat, 9 Jun 2001 19:41:11 -0700 Received: from sphinx.druber.com (sphinx.druber.com [10.0.0.2]) by sphinx.druber.com (Postfix) with ESMTP id 9189B8650; Sat, 9 Jun 2001 22:39:03 -0400 (EDT) Date: Sat, 9 Jun 2001 22:39:03 -0400 (EDT) From: Dan Swartzendruber To: "Bryan J. Smith" Cc: Steve Lord , Sean Elble , Seth Mos , Subject: Re: XFS/Linux 1.1?? In-Reply-To: <3B22D1F6.434FFE0A@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 9 Jun 2001, Bryan J. Smith wrote: > > Are any of the distro vendors taking _any_ interest? I'm still > perplexed that the distro vendors haven't seriously looked at XFS, > or at least it appears they have not. IMHO, it's time for them to > "step up to the plate" and start supporting a JFS that does all they > want. I agree. It's frustrating. I have RH7.1 on my K7. Out of the box, I can pick ext2 (ick) or reiser (ickier). Along with some stability problems I've heard about (in re reiserfs), it annoys me that there is no dump/restore functionality for that fs (an no immediate plans). XFS is a PITA for me, since I run win98 under win4lin (unlike vmware, who can run as a pure module architecture, win4lin requires several thousand lines of patches). Getting the XFS patches to co-exist with the win4lin patches has not been pleasant. > BTW, I see RedHat has added the Ext3 patch to their 2.4.5-0.2.9 > release, but I've see nothing but "problems" on the Ext3 list > (although a lot are Ext2 issues under 2.4.x as well). IMHO, I think > Tweedie/RedHat should just focus on getting full data journaling > complete (I'm still wondering why I tried to do meta-data Amen! From owner-linux-xfs@oss.sgi.com Sat Jun 9 19:57:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A2v9Z09711 for linux-xfs-outgoing; Sat, 9 Jun 2001 19:57:09 -0700 Received: from ceasefire.bitstream.net (ceasefire.bitstream.net [216.243.128.220]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A2v9V09708 for ; Sat, 9 Jun 2001 19:57:09 -0700 Received: (qmail 30925 invoked from network); 10 Jun 2001 02:57:07 -0000 Received: from unknown (HELO sgi.com) (216.243.158.125) by ceasefire with SMTP; 10 Jun 2001 02:57:07 -0000 Message-ID: <3B22E172.6E78CB6C@sgi.com> Date: Sat, 09 Jun 2001 21:54:42 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: stimits@idcomm.com CC: "linux-xfs@oss.sgi.com" Subject: Re: how to tell? References: <3B228F91.3E63027C@idcomm.com> <3B2291FB.B5A59FD8@unixcircle.com> <3B2297BE.7A0D5480@idcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "D. Stimits" wrote: > PS: I always get two copies of anything sent to the sgi-devel list. I am > also subscribed to the announce list, perhaps everything is going to > both lists? Seems a bit like a minor quirk. It's because "reply to all" goes to the person, and to the list, which is usually a good thing in case a poster is not a subscriber. There are procmail filters that deal with this. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sat Jun 9 20:20:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A3KHV10096 for linux-xfs-outgoing; Sat, 9 Jun 2001 20:20:17 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A3KGV10093 for ; Sat, 9 Jun 2001 20:20:16 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id XAA16987; Sat, 9 Jun 2001 23:13:32 -0400 Message-ID: <3B22EA13.71596D98@ieee.org> Date: Sat, 09 Jun 2001 23:31:31 -0400 From: "Bryan J. Smith" Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: linux-xfs@oss.sgi.com, Russell Cattelan Subject: Re: Russell's patch against RH 7.1 ... References: <19180.992139985@ocs4.ocs-net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > linux-2.4.5-xfs-06082001.patch contains the new XFS files, > RHlinux-2.4.5-core-xfs-06082001.patch contains XFS changes to the core > kernel. ??? I cannot get the latter to patch against RH 2.4.5-0.2.9. Maybe I should just stick with the CVS tree? I see it is now upto 2.4.6pre2. -- TheBS P.S. Damn it, I ordered my Athlon 1.3GHz chip Monday from a near-local reseller and they still haven't delivered. Build is going slow on my Duron 650MHz. -- Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 SmithConcepts, Inc. http://www.SmithConcepts.com ========================================================== Linux 'Worms' exploit known security holes that were fixed 3-12 months earlier. NT/2000 'Worms' exploit unknown se- curity holes that won't be fixed for another 3-12 months. From owner-linux-xfs@oss.sgi.com Sat Jun 9 20:30:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A3U6L10288 for linux-xfs-outgoing; Sat, 9 Jun 2001 20:30:06 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A3U4V10284 for ; Sat, 9 Jun 2001 20:30:05 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id XAA17110; Sat, 9 Jun 2001 23:23:47 -0400 Message-ID: <3B22EC79.C12518C9@ieee.org> Date: Sat, 09 Jun 2001 23:41:45 -0400 From: "Bryan J. Smith" Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dan Swartzendruber CC: Steve Lord , Sean Elble , Seth Mos , linux-xfs@oss.sgi.com Subject: Re: XFS/Linux 1.1?? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dan Swartzendruber wrote: > I agree. It's frustrating. I have RH7.1 on my K7. Out of > the box, I can pick ext2 (ick) or reiser (ickier). Along > with some stability problems I've heard about (in re > reiserfs), Well, I'm not going to touch the ReiserFS argument on "stablity," because that differs from user to user. But what I _can_ tell you is that many of us rely on production NFS networks -- and test after test, year after year, ReiserFS just takes issue with non-Linux clients (as well as some Linux clients). Chalk it up to the non-traditional UFS design. *SO*, regardless of any "design superiority" that the "ReiserFS absolutists" like to talk about, some of us *NEED* a traditional UNIX filesystem (UFS) design like XFS. At the same time, the features of XFS aren't too shabby either! > it annoys me that there is no dump/restore functionality for > that fs (an no immediate plans). Again, it's the traditional UFS focus again. I wish Reiser and his team on building the _future_ in filesystem design, and look forward to the day ReiserFS does all we want. And I will admit it's great for standalone systems or non-file server appliances *TODAY*. *BUT* it's not going on my fileservers. I need dump, I need 100% kNFSd compatibility, etc... > XFS is a PITA for me, since I run win98 under win4lin (unlike > vmware, who can run as a pure module architecture, win4lin > requires several thousand lines of patches). Getting the XFS > patches to co-exist with the win4lin patches has not been > pleasant. If my Windows app won't run under WINE, I don't need it. Plus I've really moved to open document formats (e.g., LaTeX, SGML, XML, etc...). > Amen! Seriously. I had 0 issues with pre-0.0.3 releases of Ext3 -- which were all full-data journaling. Then when running 0.0.6, I found out "meta-data" journaling was the default. Worse yet, using the "data=journal" option to supposedly "force" it into full-data journaling still did (and, in many cases, does) NOT. Pisses me off. I'm not going Ext3 for "performance," I'm going for "reliability." So I don't care if my performance is only cut to 75% instead of 50% -- give me only 50% if it works flawlessly! Now they've released 0.0.7a. I thought 0.0.6b fixed everything for meta and only the 2.4 port was being worked on. Ack, I'll just stick with my tried and true 0.0.2f installs! -- TheBS -- Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 SmithConcepts, Inc. http://www.SmithConcepts.com ========================================================== Linux 'Worms' exploit known security holes that were fixed 3-12 months earlier. NT/2000 'Worms' exploit unknown se- curity holes that won't be fixed for another 3-12 months. From owner-linux-xfs@oss.sgi.com Sat Jun 9 20:38:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A3cC010557 for linux-xfs-outgoing; Sat, 9 Jun 2001 20:38:12 -0700 Received: from sphinx.druber.com (druber-gw.lightband.com [216.129.135.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A3cBV10554 for ; Sat, 9 Jun 2001 20:38:11 -0700 Received: from sphinx.druber.com (sphinx.druber.com [10.0.0.2]) by sphinx.druber.com (Postfix) with ESMTP id 3FABE8650; Sat, 9 Jun 2001 23:36:03 -0400 (EDT) Date: Sat, 9 Jun 2001 23:36:03 -0400 (EDT) From: Dan Swartzendruber To: "Bryan J. Smith" Cc: Steve Lord , Sean Elble , Seth Mos , Subject: Re: XFS/Linux 1.1?? In-Reply-To: <3B22EC79.C12518C9@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 9 Jun 2001, Bryan J. Smith wrote: > > > XFS is a PITA for me, since I run win98 under win4lin (unlike > > vmware, who can run as a pure module architecture, win4lin > > requires several thousand lines of patches). Getting the XFS > > patches to co-exist with the win4lin patches has not been > > pleasant. > > If my Windows app won't run under WINE, I don't need it. Plus I've > really moved to open document formats (e.g., LaTeX, SGML, XML, > etc...). well, what can i say. i really like quicken/2000. and wine is just lame - it's been 75% (or whatever) done for years now, it seems. if i can get a nice threaded mail client with IMAP support, i'd move my mail from win98 to KDE in a flash. > > Amen! > > Seriously. I had 0 issues with pre-0.0.3 releases of Ext3 -- which > were all full-data journaling. Then when running 0.0.6, I found out > "meta-data" journaling was the default. Worse yet, using the > "data=journal" option to supposedly "force" it into full-data > journaling still did (and, in many cases, does) NOT. Pisses me > off. I'm not going Ext3 for "performance," I'm going for > "reliability." So I don't care if my performance is only cut to 75% > instead of 50% -- give me only 50% if it works flawlessly! i'm new here - what is the metadata journaling argument re ext3? From owner-linux-xfs@oss.sgi.com Sat Jun 9 21:07:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A47SU11273 for linux-xfs-outgoing; Sat, 9 Jun 2001 21:07:28 -0700 Received: from yowie.cc.uq.edu.au (root@yowie.cc.uq.edu.au [130.102.2.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A47NV11270 for ; Sat, 9 Jun 2001 21:07:24 -0700 Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1]) by yowie.cc.uq.edu.au (8.9.3/8.9.3) with ESMTP id OAA08514; Sun, 10 Jun 2001 14:07:02 +1000 (GMT+1000) Received: from nut.csee.uq.edu.au (nut.csee.uq.edu.au [130.102.66.13]) by gum.csee.uq.edu.au (8.11.3/8.11.3) with ESMTP id f5A471506818; Sun, 10 Jun 2001 14:07:01 +1000 (EST) Received: from mango.csee.uq.edu.au (mango.csee.uq.edu.au [130.102.66.4]) by nut.csee.uq.edu.au (8.11.3/8.11.3) with ESMTP id f5A471o26448; Sun, 10 Jun 2001 14:07:01 +1000 (EST) Date: Sun, 10 Jun 2001 14:07:00 +1000 (EST) From: Chris Pascoe To: Steve Lord cc: Subject: Re: TAKE - delalloc buffer and page handling cleanup In-Reply-To: <200106090403.f5943Te31573@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-33463914-992145249=:7090" Content-ID: X-Scanned-By: MIMEDefang 1.1 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-33463914-992145249=:7090 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi Steve, > Removes some code, and actually makes it faster. Problem reports, > especially from highmem systems (which I know how to crash in 30 > seconds) appreciated - Hint, avoid direct I/O, buffered I/O on the > same file, do not run test 013 in the regression tests. I am > still chasing this bug. I get a repeatable crash immediately on 017 with these changes. Same machine as before (1GB/Dual P3-Xeon), just a slightly different partiton layout. Was I supposed to avoid test 017 too? Traces / disasm attached. Going to recompile w/o highmem now, will let you know if it fails. Hmm, same thing happens, and same w/o highmem on non-SMP. Chris ---559023410-33463914-992145249=:7090 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="20010609.crash" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="20010609.crash" LS0NClRyYWNlIG9uIGEgZmFpbCB3aGlsZSB3cml0aW5nOg0KMDE3U3RhcnQg bW91bnRpbmcgZmlsZXN5c3RlbTogc2QoOCwxOSkNCkVuZGluZyBjbGVhbiBY RlMgbW91bnQgZm9yIGZpbGVzeXN0ZW06IHNkKDgsMTkpDQpVbmFibGUgdG8g aGFuZGxlIGtlcm5lbCBOVUxMIHBvaW50ZXIgZGVyZWZlcmVuY2UgYXQgdmly dHVhbCBhZGRyZXNzIDAwMDAwMDAwDQogcHJpbnRpbmcgZWlwOg0KYzAxNjFl YTQNCipwZGUgPSAwMDAwMDAwMA0KDQpFbnRlcmluZyBrZGIgKGN1cnJlbnQ9 MHhlMTJiYzAwMCwgcGlkIDIxMzY0KSBvbiBwcm9jZXNzb3IgMCBPb3BzOiBP b3BzDQpkdWUgdG8gb29wcyBAIDB4YzAxNjFlYTQNCmVheCA9IDB4MDAwMDAw MDAgZWJ4ID0gMHhmMTFiZTRhMCBlY3ggPSAweDAwMDAwMDA5IGVkeCA9IDB4 MDAwMDAwMDANCmVzaSA9IDB4MDgwNTIyMDAgZWRpID0gMHgwMDAwMDAwMCBl c3AgPSAweGUxMmJkZDdjIGVpcCA9IDB4YzAxNjFlYTQNCmVicCA9IDB4ZTEy YmRkYjggeHNzID0gMHgwMDAwMDAxOCB4Y3MgPSAweDAwMDAwMDEwIGVmbGFn cyA9IDB4MDAwMTAyNDYNCnhkcyA9IDB4MDAwMDAwMTggeGVzID0gMHgwMDAw MDAxOCBvcmlnZWF4ID0gMHhmZmZmZmZmZiAmcmVncyA9IDB4ZTEyYmRkNDgN ClswXWtkYj4NClswXWtkYj4NClswXWtkYj4NClswXWtkYj4gYnQNCiAgICBF QlAgICAgICAgRUlQICAgICAgICAgRnVuY3Rpb24oYXJncykNCjB4ZTEyYmRk YjggMHhjMDE2MWVhNCBfcGJfZGlyZWN0X2lvKzB4OTAgKDB4ZjRmYjE5YzAs IDB4MmYwMDAsIDB4MCwgMHg3MDAwLCAweGUxMmJkZTFjKQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGtlcm5lbCAudGV4dCAweGMwMTAwMDAw IDB4YzAxNjFlMTQgMHhjMDE2MWZkNA0KMHhlMTJiZGUzYyAweGMwMTYzMjg1 IF9wYWdlYnVmX2ZpbGVfd3JpdGUrMHgxNzUgKDB4ZjZlNTA1NjAsIDB4ODA1 MjIwMCwgMHg3MDAwLCAweGUxMmJkZWE4LCAweGMwMWNlYTkwKQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGtlcm5lbCAudGV4dCAweGMwMTAw MDAwIDB4YzAxNjMxMTAgMHhjMDE2MzMwYw0KMHhlMTJiZGViMCAweGMwMTYz NDBkIHBhZ2VidWZfZ2VuZXJpY19maWxlX3dyaXRlKzB4MTAxICgweGY2ZTUw NTYwLCAweDgwNTIyMDAsIDB4NzAwMCwgMHhlMTJiZGY4NCwgMHhjMDFjZWE5 MCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBrZXJuZWwgLnRl eHQgMHhjMDEwMDAwMCAweGMwMTYzMzBjIDB4YzAxNjM3NGMNCjB4ZTEyYmRm MzQgMHhjMDFjZmQ5OCB4ZnNfd3JpdGUrMHgzNDggKDB4ZjU5MGM2YjQsIDB4 ZTEyYmRmNzgsIDB4MCwgMHgwLCAweDApDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAga2VybmVsIC50ZXh0IDB4YzAxMDAwMDAgMHhjMDFjZmE1 MCAweGMwMWQwMDU0DQoweGUxMmJkZjk4IDB4YzAxY2I3NjUgbGludmZzX3dy aXRlKzB4MTBkICgweGY2ZTUwNTYwLCAweDgwNTIyMDAsIDB4NzAwMCwgMHhm NmU1MDU4MCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBrZXJu ZWwgLnRleHQgMHhjMDEwMDAwMCAweGMwMWNiNjU4IDB4YzAxY2I3YTANCjB4 ZTEyYmRmYmMgMHhjMDEzNjE3NSBzeXNfd3JpdGUrMHg5NSAoMHgzLCAweDgw NTIyMDAsIDB4NzAwMCwgMHgwLCAweDFmMzY3YThmKQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGtlcm5lbCAudGV4dCAweGMwMTAwMDAwIDB4 YzAxMzYwZTAgMHhjMDEzNjFiMA0KICAgICAgICAgICAweGMwMTA2ZmNiIHN5 c3RlbV9jYWxsKzB4MzMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBrZXJuZWwgLnRleHQgMHhjMDEwMDAwMCAweGMwMTA2Zjk4IDB4YzAxMDZm ZDANCg0KLS0NClRyYWNlL2Rpc2FzbSwgZmFpbGVkIHdoaWxlIHJlYWRpbmc6 DQoNCltyb290QHRveSB4ZnN0ZXN0c10jIGZyZWUNCiAgICAgICAgICAgICB0 b3RhbCAgICAgICB1c2VkICAgICAgIGZyZWUgICAgIHNoYXJlZCAgICBidWZm ZXJzICAgICBjYWNoZWQNCk1lbTogICAgICAgMTAyODEyNCAgICAgIDM5Mjg0 ICAgICA5ODg4NDAgICAgICAgICAgMCAgICAgICA1MzAwICAgICAgMTc2MjQN Ci0vKyBidWZmZXJzL2NhY2hlOiAgICAgIDE2MzYwICAgIDEwMTE3NjQNClN3 YXA6ICAgICAgMjA5NjQ0MCAgICAgICAgICAwICAgIDIwOTY0NDANCltyb290 QHRveSB4ZnN0ZXN0c10jIC4vMDE3DQpRQSBvdXRwdXQgY3JlYXRlZCBieSAw MTcNCioqKiBpbml0IEZTDQpTdGFydCBtb3VudGluZyBmaWxlc3lzdGVtOiBz ZCg4LDE5KQ0KRW5kaW5nIGNsZWFuIFhGUyBtb3VudCBmb3IgZmlsZXN5c3Rl bTogc2QoOCwxOSkNCioqKiB0ZXN0DQogICAgKioqIHRlc3QgMA0KVW5hYmxl IHRvIGhhbmRsZSBrZXJuZWwgTlVMTCBwb2ludGVyIGRlcmVmZXJlbmNlIGF0 IHZpcnR1YWwgYWRkcmVzcyAwMDAwMDAwMA0KIHByaW50aW5nIGVpcDoNCmMw MTYxZWE0DQoqcGRlID0gMDAwMDAwMDANCg0KRW50ZXJpbmcga2RiIChjdXJy ZW50PTB4ZjY3MzIwMDAsIHBpZCA3OTMpIG9uIHByb2Nlc3NvciAwIE9vcHM6 IE9vcHMNCmR1ZSB0byBvb3BzIEAgMHhjMDE2MWVhNA0KZWF4ID0gMHgwMDAw MDAwMCBlYnggPSAweGY2NmZmZDgwIGVjeCA9IDB4MDAwMDAwMDkgZWR4ID0g MHgwMDAwMDAwMCANCmVzaSA9IDB4MDAwMDAwMDAgZWRpID0gMHgwMDAwMDAw MCBlc3AgPSAweGY2NzMzZGUwIGVpcCA9IDB4YzAxNjFlYTQgDQplYnAgPSAw eGY2NzMzZTFjIHhzcyA9IDB4MDAwMDAwMTggeGNzID0gMHgwMDAwMDAxMCBl ZmxhZ3MgPSAweDAwMDEwMjQ2IA0KeGRzID0gMHgwMDAwMDAxOCB4ZXMgPSAw eDAwMDAwMDE4IG9yaWdlYXggPSAweGZmZmZmZmZmICZyZWdzID0gMHhmNjcz M2RhYw0KWzBda2RiPiBidA0KICAgIEVCUCAgICAgICBFSVAgICAgICAgICBG dW5jdGlvbihhcmdzKQ0KMHhmNjczM2UxYyAweGMwMTYxZWE0IF9wYl9kaXJl Y3RfaW8rMHg5MCAoMHhmNjZmYmMyMCwgMHg3ODAwMCwgMHgwLCAweDExMDAw LCAweGY2NzMzZTk4KQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGtlcm5lbCAudGV4dCAweGMwMTAwMDAwIDB4YzAxNjFlMTQgMHhjMDE2MWZk NA0KMHhmNjczM2VlYyAweGMwMTYyMjVlIHBhZ2VidWZfZGlyZWN0X2ZpbGVf cmVhZCsweDI3YSAoMHhmNzE0ZWJhMCwgMHg4MDUyMjAwLCAweDFhMDAwLCAw eGY2NzMzZjg0LCAweGMwMWNlYTkwKQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGtlcm5lbCAudGV4dCAweGMwMTAwMDAwIDB4YzAxNjFmZTQg MHhjMDE2MjMzMA0KMHhmNjczM2Y0NCAweGMwMWNlZWFiIHhmc19yZWFkKzB4 MWZiICgweGY3NGY5NWQ0LCAweGY2NzMzZjc4LCAweDAsIDB4MCwgMHgwKQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGtlcm5lbCAudGV4dCAw eGMwMTAwMDAwIDB4YzAxY2VjYjAgMHhjMDFjZWYzNA0KMHhmNjczM2Y5OCAw eGMwMWNiNjMwIGxpbnZmc19yZWFkKzB4OTAgKDB4ZjcxNGViYTAsIDB4ODA1 MjIwMCwgMHgxYTAwMCwgMHhmNzE0ZWJjMCkNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBrZXJuZWwgLnRleHQgMHhjMDEwMDAwMCAweGMwMWNi NWEwIDB4YzAxY2I2NTgNCjB4ZjY3MzNmYmMgMHhjMDEzNjBhNSBzeXNfcmVh ZCsweDkxICgweDMsIDB4ODA1MjIwMCwgMHgxYTAwMCwgMHgwLCAweDMpDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAga2VybmVsIC50ZXh0IDB4 YzAxMDAwMDAgMHhjMDEzNjAxNCAweGMwMTM2MGUwDQogICAgICAgICAgIDB4 YzAxMDZmY2Igc3lzdGVtX2NhbGwrMHgzMw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGtlcm5lbCAudGV4dCAweGMwMTAwMDAwIDB4YzAxMDZm OTggMHhjMDEwNmZkMA0KDQoNCltyb290QHRveSAvXSMgZ2RiIC9ib290L3Zt bGludXgtMi40LjYtcHJlMi14ZnMtMjAwMTA2MDkgDQpHTlUgZ2RiIDUuMHJo LTUgUmVkIEhhdCBMaW51eCA3LjENCkNvcHlyaWdodCAyMDAxIEZyZWUgU29m dHdhcmUgRm91bmRhdGlvbiwgSW5jLg0KR0RCIGlzIGZyZWUgc29mdHdhcmUs IGNvdmVyZWQgYnkgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCBh bmQgeW91IGFyZQ0Kd2VsY29tZSB0byBjaGFuZ2UgaXQgYW5kL29yIGRpc3Ry aWJ1dGUgY29waWVzIG9mIGl0IHVuZGVyIGNlcnRhaW4gY29uZGl0aW9ucy4N ClR5cGUgInNob3cgY29weWluZyIgdG8gc2VlIHRoZSBjb25kaXRpb25zLg0K VGhlcmUgaXMgYWJzb2x1dGVseSBubyB3YXJyYW50eSBmb3IgR0RCLiAgVHlw ZSAic2hvdyB3YXJyYW50eSIgZm9yIGRldGFpbHMuDQpUaGlzIEdEQiB3YXMg Y29uZmlndXJlZCBhcyAiaTM4Ni1yZWRoYXQtbGludXgiLi4uDQooZ2RiKSBk aXNhc3MgX3BiX2RpcmVjdF9pbw0KRHVtcCBvZiBhc3NlbWJsZXIgY29kZSBm b3IgZnVuY3Rpb24gX3BiX2RpcmVjdF9pbzoNCjB4YzAxNjFlMTQgPF9wYl9k aXJlY3RfaW8+OglwdXNoICAgJWVicA0KMHhjMDE2MWUxNSA8X3BiX2RpcmVj dF9pbysxPjoJbW92ICAgICVlc3AsJWVicA0KMHhjMDE2MWUxNyA8X3BiX2Rp cmVjdF9pbyszPjoJc3ViICAgICQweDMwLCVlc3ANCjB4YzAxNjFlMWEgPF9w Yl9kaXJlY3RfaW8rNj46CXB1c2ggICAlZWRpDQoweGMwMTYxZTFiIDxfcGJf ZGlyZWN0X2lvKzc+OglwdXNoICAgJWVzaQ0KMHhjMDE2MWUxYyA8X3BiX2Rp cmVjdF9pbys4PjoJcHVzaCAgICVlYngNCjB4YzAxNjFlMWQgPF9wYl9kaXJl Y3RfaW8rOT46CW1vdiAgICAweDFjKCVlYnApLCVlc2kNCjB4YzAxNjFlMjAg PF9wYl9kaXJlY3RfaW8rMTI+Ogltb3YgICAgMHhjMDMyYmRhOCwlZWF4DQow eGMwMTYxZTI1IDxfcGJfZGlyZWN0X2lvKzE3PjoJc2hsICAgICQweGMsJWVh eA0KMHhjMDE2MWUyOCA8X3BiX2RpcmVjdF9pbysyMD46CW1vdiAgICAlZWF4 LDB4ZmZmZmZmZjgoJWVicCkNCjB4YzAxNjFlMmIgPF9wYl9kaXJlY3RfaW8r MjM+Ogltb3YgICAgMHgxNCglZWJwKSwlZWR4DQoweGMwMTYxZTJlIDxfcGJf ZGlyZWN0X2lvKzI2PjoJY21wICAgICVlZHgsJWVheA0KMHhjMDE2MWUzMCA8 X3BiX2RpcmVjdF9pbysyOD46CWNtb3ZiZSAlZWF4LCVlZHgNCjB4YzAxNjFl MzMgPF9wYl9kaXJlY3RfaW8rMzE+Ogltb3YgICAgJWVkeCwweDE0KCVlYnAp DQoweGMwMTYxZTM2IDxfcGJfZGlyZWN0X2lvKzM0PjoJY21wbCAgICQweDAs MHgyNCglZWJwKQ0KMHhjMDE2MWUzYSA8X3BiX2RpcmVjdF9pbyszOD46CWpl ICAgICAweGMwMTYxZTQ1IDxfcGJfZGlyZWN0X2lvKzQ5Pg0KMHhjMDE2MWUz YyA8X3BiX2RpcmVjdF9pbys0MD46CW1vdmwgICAkMHg4MDAwMDAyLDB4ZmZm ZmZmZmMoJWVicCkNCjB4YzAxNjFlNDMgPF9wYl9kaXJlY3RfaW8rNDc+Oglq bXAgICAgMHhjMDE2MWU0YyA8X3BiX2RpcmVjdF9pbys1Nj4NCjB4YzAxNjFl NDUgPF9wYl9kaXJlY3RfaW8rNDk+Ogltb3ZsICAgJDB4ODAwMDAwMSwweGZm ZmZmZmZjKCVlYnApDQoweGMwMTYxZTRjIDxfcGJfZGlyZWN0X2lvKzU2PjoJ bW92ICAgIDB4ZmZmZmZmZmMoJWVicCksJWVkaQ0KMHhjMDE2MWU0ZiA8X3Bi X2RpcmVjdF9pbys1OT46CXB1c2ggICAlZWRpDQoweGMwMTYxZTUwIDxfcGJf ZGlyZWN0X2lvKzYwPjoJbW92ICAgIDB4MTQoJWVicCksJWVheA0KMHhjMDE2 MWU1MyA8X3BiX2RpcmVjdF9pbys2Mz46CXB1c2ggICAlZWF4DQoweGMwMTYx ZTU0IDxfcGJfZGlyZWN0X2lvKzY0PjoJbW92ICAgIDB4YyglZWJwKSwlZWF4 DQoweGMwMTYxZTU3IDxfcGJfZGlyZWN0X2lvKzY3PjoJbW92ICAgIDB4MTAo JWVicCksJWVkeA0KMHhjMDE2MWU1YSA8X3BiX2RpcmVjdF9pbys3MD46CXB1 c2ggICAlZWR4DQoweGMwMTYxZTViIDxfcGJfZGlyZWN0X2lvKzcxPjoJcHVz aCAgICVlYXgNCjB4YzAxNjFlNWMgPF9wYl9kaXJlY3RfaW8rNzI+Ogltb3Yg ICAgMHg4KCVlYnApLCVlZHgNCjB4YzAxNjFlNWYgPF9wYl9kaXJlY3RfaW8r NzU+OglwdXNoICAgJWVkeA0KMHhjMDE2MWU2MCA8X3BiX2RpcmVjdF9pbys3 Nj46CWNhbGwgICAweGMwMTYwMTc0IDxwYWdlYnVmX2xvb2t1cD4NCjB4YzAx NjFlNjUgPF9wYl9kaXJlY3RfaW8rODE+Ogltb3YgICAgJWVheCwlZWJ4DQow eGMwMTYxZTY3IDxfcGJfZGlyZWN0X2lvKzgzPjoJYWRkICAgICQweDE0LCVl c3ANCjB4YzAxNjFlNmEgPF9wYl9kaXJlY3RfaW8rODY+Ogl0ZXN0ICAgJWVi eCwlZWJ4DQoweGMwMTYxZTZjIDxfcGJfZGlyZWN0X2lvKzg4PjoJam5lICAg IDB4YzAxNjFlODAgPF9wYl9kaXJlY3RfaW8rMTA4Pg0KMHhjMDE2MWU2ZSA8 X3BiX2RpcmVjdF9pbys5MD46CW1vdiAgICAweDIwKCVlYnApLCVlZGkNCjB4 YzAxNjFlNzEgPF9wYl9kaXJlY3RfaW8rOTM+Ogltb3ZsICAgJDB4ZmZmZmZm ZjQsMHhjKCVlZGkpDQoweGMwMTYxZTc4IDxfcGJfZGlyZWN0X2lvKzEwMD46 CXhvciAgICAlZWF4LCVlYXgNCjB4YzAxNjFlN2EgPF9wYl9kaXJlY3RfaW8r MTAyPjoJam1wICAgIDB4YzAxNjFmY2EgPF9wYl9kaXJlY3RfaW8rNDM4Pg0K MHhjMDE2MWU3ZiA8X3BiX2RpcmVjdF9pbysxMDc+Oglub3AgICAgDQoweGMw MTYxZTgwIDxfcGJfZGlyZWN0X2lvKzEwOD46CW1vdiAgICAweDE4KCVlYnAp LCVlYXgNCjB4YzAxNjFlODMgPF9wYl9kaXJlY3RfaW8rMTExPjoJbW92ends IDB4OCglZWF4KSwlZWF4DQoweGMwMTYxZTg3IDxfcGJfZGlyZWN0X2lvKzEx NT46CW1vdiAgICAlYXgsMHgxYyglZWJ4KQ0KMHhjMDE2MWU4YiA8X3BiX2Rp cmVjdF9pbysxMTk+Ogltb3YgICAgMHg4KCVlYnApLCVlZHgNCjB4YzAxNjFl OGUgPF9wYl9kaXJlY3RfaW8rMTIyPjoJbW92ICAgIDB4MTgoJWVicCksJWVk aQ0KMHhjMDE2MWU5MSA8X3BiX2RpcmVjdF9pbysxMjU+Ogltb3YgICAgMHg4 YyglZWR4KSwlZWR4DQoweGMwMTYxZTk3IDxfcGJfZGlyZWN0X2lvKzEzMT46 CW1vdiAgICAweDE0KCVlZGkpLCVlYXgNCjB4YzAxNjFlOWEgPF9wYl9kaXJl Y3RfaW8rMTM0PjoJbW92emJsIDB4MTAoJWVkeCksJWVjeA0KMHhjMDE2MWU5 ZSA8X3BiX2RpcmVjdF9pbysxMzg+OglzaHIgICAgJWNsLCVlYXgNCjB4YzAx NjFlYTAgPF9wYl9kaXJlY3RfaW8rMTQwPjoJbW92ICAgICVlYXgsJWVkaQ0K MHhjMDE2MWVhMiA8X3BiX2RpcmVjdF9pbysxNDI+Ogltb3YgICAgJWVkaSwl ZWR4DQoweGMwMTYxZWE0IDxfcGJfZGlyZWN0X2lvKzE0ND46CW1vdiAgICAo JWVkeCksJWVheA0KMHhjMDE2MWVhNiA8X3BiX2RpcmVjdF9pbysxNDY+Oglt b3YgICAgMHg0KCVlZHgpLCVlZHgNCjB4YzAxNjFlYTkgPF9wYl9kaXJlY3Rf aW8rMTQ5PjoJbW92ICAgICVlYXgsMHgxNCglZWJ4KQ0KMHhjMDE2MWVhYyA8 X3BiX2RpcmVjdF9pbysxNTI+Ogltb3YgICAgJWVkeCwweDE4KCVlYngpDQow eGMwMTYxZWFmIDxfcGJfZGlyZWN0X2lvKzE1NT46CWFkZCAgICAlZWRpLDB4 MTQoJWVieCkNCjB4YzAxNjFlYjIgPF9wYl9kaXJlY3RfaW8rMTU4PjoJYWRj bCAgICQweDAsMHgxOCglZWJ4KQ0KMHhjMDE2MWViNiA8X3BiX2RpcmVjdF9p bysxNjI+OglwdXNoICAgJDB4NzANCjB4YzAxNjFlYjggPF9wYl9kaXJlY3Rf aW8rMTY0PjoJcHVzaCAgICQweDIyMzQNCjB4YzAxNjFlYmQgPF9wYl9kaXJl Y3RfaW8rMTY5PjoJY2FsbCAgIDB4YzAxMmMzM2MgPGttYWxsb2M+DQoweGMw MTYxZWMyIDxfcGJfZGlyZWN0X2lvKzE3ND46CW1vdiAgICAlZWF4LDB4ZmZm ZmZmZWMoJWVicCkNCjB4YzAxNjFlYzUgPF9wYl9kaXJlY3RfaW8rMTc3PjoJ YWRkICAgICQweDgsJWVzcA0KMHhjMDE2MWVjOCA8X3BiX2RpcmVjdF9pbysx ODA+Ogl0ZXN0ICAgJWVheCwlZWF4DQoweGMwMTYxZWNhIDxfcGJfZGlyZWN0 X2lvKzE4Mj46CWpuZSAgICAweGMwMTYxZWUzIDxfcGJfZGlyZWN0X2lvKzIw Nz4NCjB4YzAxNjFlY2MgPF9wYl9kaXJlY3RfaW8rMTg0PjoJcHVzaCAgICVl YngNCjB4YzAxNjFlY2QgPF9wYl9kaXJlY3RfaW8rMTg1PjoJY2FsbCAgIDB4 YzAxNjA0NzQgPHBhZ2VidWZfcmVsZT4NCjB4YzAxNjFlZDIgPF9wYl9kaXJl Y3RfaW8rMTkwPjoJbW92ICAgIDB4MjAoJWVicCksJWVheA0KMHhjMDE2MWVk NSA8X3BiX2RpcmVjdF9pbysxOTM+Ogltb3ZsICAgJDB4ZmZmZmZmZjQsMHhj KCVlYXgpDQoweGMwMTYxZWRjIDxfcGJfZGlyZWN0X2lvKzIwMD46CXhvciAg ICAlZWF4LCVlYXgNCjB4YzAxNjFlZGUgPF9wYl9kaXJlY3RfaW8rMjAyPjoJ am1wICAgIDB4YzAxNjFmY2EgPF9wYl9kaXJlY3RfaW8rNDM4Pg0KMHhjMDE2 MWVlMyA8X3BiX2RpcmVjdF9pbysyMDc+Ogltb3YgICAgJDB4ODhkLCVlY3gN CjB4YzAxNjFlZTggPF9wYl9kaXJlY3RfaW8rMjEyPjoJbW92ICAgIDB4ZmZm ZmZmZWMoJWVicCksJWVkaQ0KMHhjMDE2MWVlYiA8X3BiX2RpcmVjdF9pbysy MTU+Ogl4b3IgICAgJWVheCwlZWF4DQoweGMwMTYxZWVkIDxfcGJfZGlyZWN0 X2lvKzIxNz46CXJlcHogc3RvcyAlZWF4LCVlczooJWVkaSkNCjB4YzAxNjFl ZWYgPF9wYl9kaXJlY3RfaW8rMjE5PjoJbW92ICAgIDB4ZmZmZmZmZWMoJWVi cCksJWVheA0KMHhjMDE2MWVmMiA8X3BiX2RpcmVjdF9pbysyMjI+Ogltb3Zs ICAgJDB4ODEsMHg0KCVlYXgpDQoweGMwMTYxZWY5IDxfcGJfZGlyZWN0X2lv KzIyOT46CW1vdiAgICAlZWF4LCVlZHgNCjB4YzAxNjFlZmIgPF9wYl9kaXJl Y3RfaW8rMjMxPjoJYWRkICAgICQweDE4LCVlZHgNCjB4YzAxNjFlZmUgPF9w Yl9kaXJlY3RfaW8rMjM0PjoJbW92ICAgICVlZHgsMHgxMCglZWF4KQ0KMHhj MDE2MWYwMSA8X3BiX2RpcmVjdF9pbysyMzc+OgljbXBsICAgJDB4MCwweDIw KCVlYnApDQoweGMwMTYxZjA1IDxfcGJfZGlyZWN0X2lvKzI0MT46CWplICAg ICAweGMwMTYxZjFlIDxfcGJfZGlyZWN0X2lvKzI2Nj4NCjB4YzAxNjFmMDcg PF9wYl9kaXJlY3RfaW8rMjQzPjoJbW92ICAgIDB4MjAoJWVicCksJWVkaQ0K MHhjMDE2MWYwYSA8X3BiX2RpcmVjdF9pbysyNDY+Ogltb3YgICAgMHgyMCgl ZWJwKSwlZWF4DQoweGMwMTYxZjBkIDxfcGJfZGlyZWN0X2lvKzI0OT46CW1v diAgICAweDI4KCVlZGkpLCVlZGkNCjB4YzAxNjFmMTAgPF9wYl9kaXJlY3Rf aW8rMjUyPjoJbW92ICAgIDB4MWMoJWVheCksJWVheA0KMHhjMDE2MWYxMyA8 X3BiX2RpcmVjdF9pbysyNTU+Ogltb3YgICAgKCVlYXgsJWVkaSw0KSwlZWR4 DQoweGMwMTYxZjE2IDxfcGJfZGlyZWN0X2lvKzI1OD46CW1vdiAgICAweDIw KCVlYnApLCVlZGkNCjB4YzAxNjFmMTkgPF9wYl9kaXJlY3RfaW8rMjYxPjoJ bW92ICAgIDB4MjAoJWVkaSksJWVzaQ0KMHhjMDE2MWYxYyA8X3BiX2RpcmVj dF9pbysyNjQ+OglhZGQgICAgKCVlZHgpLCVlc2kNCjB4YzAxNjFmMWUgPF9w Yl9kaXJlY3RfaW8rMjY2PjoJbW92ICAgIDB4MTQoJWVicCksJWVheA0KMHhj MDE2MWYyMSA8X3BiX2RpcmVjdF9pbysyNjk+OglwdXNoICAgJWVheA0KMHhj MDE2MWYyMiA8X3BiX2RpcmVjdF9pbysyNzA+OglwdXNoICAgJWVzaQ0KMHhj MDE2MWYyMyA8X3BiX2RpcmVjdF9pbysyNzE+Ogltb3YgICAgMHhmZmZmZmZl YyglZWJwKSwlZWR4DQoweGMwMTYxZjI2IDxfcGJfZGlyZWN0X2lvKzI3ND46 CXB1c2ggICAlZWR4DQoweGMwMTYxZjI3IDxfcGJfZGlyZWN0X2lvKzI3NT46 CWNtcGwgICAkMHgwLDB4MjQoJWVicCkNCjB4YzAxNjFmMmIgPF9wYl9kaXJl Y3RfaW8rMjc5PjoJc2V0bmUgICVhbA0KMHhjMDE2MWYyZSA8X3BiX2RpcmVj dF9pbysyODI+Ogltb3Z6YmwgJWFsLCVlZHgNCjB4YzAxNjFmMzEgPF9wYl9k aXJlY3RfaW8rMjg1PjoJcHVzaCAgICVlZHgNCjB4YzAxNjFmMzIgPF9wYl9k aXJlY3RfaW8rMjg2PjoJY2FsbCAgIDB4YzAxMjMyZTggPG1hcF91c2VyX2tp b2J1Zj4NCjB4YzAxNjFmMzcgPF9wYl9kaXJlY3RfaW8rMjkxPjoJbW92ICAg ICVlYXgsJWVzaQ0KMHhjMDE2MWYzOSA8X3BiX2RpcmVjdF9pbysyOTM+Oglh ZGQgICAgJDB4MTAsJWVzcA0KMHhjMDE2MWYzYyA8X3BiX2RpcmVjdF9pbysy OTY+Ogl0ZXN0ICAgJWVzaSwlZXNpDQoweGMwMTYxZjNlIDxfcGJfZGlyZWN0 X2lvKzI5OD46CWpuZSAgICAweGMwMTYxZjcyIDxfcGJfZGlyZWN0X2lvKzM1 MD4NCjB4YzAxNjFmNDAgPF9wYl9kaXJlY3RfaW8rMzAwPjoJbW92ICAgIDB4 ZmZmZmZmZWMoJWVicCksJWVkaQ0KMHhjMDE2MWY0MyA8X3BiX2RpcmVjdF9p byszMDM+Ogltb3YgICAgMHgxMCglZWRpKSwlZWRpDQoweGMwMTYxZjQ2IDxf cGJfZGlyZWN0X2lvKzMwNj46CW1vdiAgICAlZWRpLDB4NWMoJWVieCkNCjB4 YzAxNjFmNDkgPF9wYl9kaXJlY3RfaW8rMzA5PjoJbW92ICAgIDB4ZmZmZmZm ZWMoJWVicCksJWVheA0KMHhjMDE2MWY0YyA8X3BiX2RpcmVjdF9pbyszMTI+ Ogltb3YgICAgKCVlYXgpLCVlYXgNCjB4YzAxNjFmNGUgPF9wYl9kaXJlY3Rf aW8rMzE0PjoJbW92ICAgICVlYXgsMHg1MCglZWJ4KQ0KMHhjMDE2MWY1MSA8 X3BiX2RpcmVjdF9pbyszMTc+Ogltb3YgICAgMHhmZmZmZmZlYyglZWJwKSwl ZWR4DQoweGMwMTYxZjU0IDxfcGJfZGlyZWN0X2lvKzMyMD46CW1vdiAgICAw eDgoJWVkeCksJWVkeA0KMHhjMDE2MWY1NyA8X3BiX2RpcmVjdF9pbyszMjM+ Ogltb3YgICAgJWVkeCwweDU4KCVlYngpDQoweGMwMTYxZjVhIDxfcGJfZGly ZWN0X2lvKzMyNj46CW1vdiAgICAweGZmZmZmZmZjKCVlYnApLCVlZGkNCjB4 YzAxNjFmNWQgPF9wYl9kaXJlY3RfaW8rMzI5PjoJcHVzaCAgICVlZGkNCjB4 YzAxNjFmNWUgPF9wYl9kaXJlY3RfaW8rMzMwPjoJcHVzaCAgICVlYngNCjB4 YzAxNjFmNWYgPF9wYl9kaXJlY3RfaW8rMzMxPjoJY2FsbCAgIDB4YzAxNjA2 YWMgPHBhZ2VidWZfaW9zdGFydD4NCjB4YzAxNjFmNjQgPF9wYl9kaXJlY3Rf aW8rMzM2PjoJbW92ICAgICVlYXgsJWVzaQ0KMHhjMDE2MWY2NiA8X3BiX2Rp cmVjdF9pbyszMzg+Ogltb3YgICAgMHhmZmZmZmZlYyglZWJwKSwlZWF4DQow eGMwMTYxZjY5IDxfcGJfZGlyZWN0X2lvKzM0MT46CXB1c2ggICAlZWF4DQow eGMwMTYxZjZhIDxfcGJfZGlyZWN0X2lvKzM0Mj46CWNhbGwgICAweGMwMTIz NWM4IDx1bm1hcF9raW9idWY+DQoweGMwMTYxZjZmIDxfcGJfZGlyZWN0X2lv KzM0Nz46CWFkZCAgICAkMHhjLCVlc3ANCjB4YzAxNjFmNzIgPF9wYl9kaXJl Y3RfaW8rMzUwPjoJbW92ICAgIDB4ZmZmZmZmZWMoJWVicCksJWVkeA0KMHhj MDE2MWY3NSA8X3BiX2RpcmVjdF9pbyszNTM+OglwdXNoICAgJWVkeA0KMHhj MDE2MWY3NiA8X3BiX2RpcmVjdF9pbyszNTQ+OgljYWxsICAgMHhjMDEyYzVh YyA8a2ZyZWU+DQoweGMwMTYxZjdiIDxfcGJfZGlyZWN0X2lvKzM1OT46CWFk ZCAgICAkMHg0LCVlc3ANCjB4YzAxNjFmN2UgPF9wYl9kaXJlY3RfaW8rMzYy PjoJY21wbCAgICQweDAsMHgyMCglZWJwKQ0KMHhjMDE2MWY4MiA8X3BiX2Rp cmVjdF9pbyszNjY+OglqZSAgICAgMHhjMDE2MWZiNyA8X3BiX2RpcmVjdF9p bys0MTk+DQoweGMwMTYxZjg0IDxfcGJfZGlyZWN0X2lvKzM2OD46CXRlc3Qg ICAlZXNpLCVlc2kNCjB4YzAxNjFmODYgPF9wYl9kaXJlY3RfaW8rMzcwPjoJ am5lICAgIDB4YzAxNjFmYjEgPF9wYl9kaXJlY3RfaW8rNDEzPg0KMHhjMDE2 MWY4OCA8X3BiX2RpcmVjdF9pbyszNzI+Ogltb3YgICAgMHgxNCglZWJwKSwl ZWF4DQoweGMwMTYxZjhiIDxfcGJfZGlyZWN0X2lvKzM3NT46CW1vdiAgICAw eDIwKCVlYnApLCVlZGkNCjB4YzAxNjFmOGUgPF9wYl9kaXJlY3RfaW8rMzc4 PjoJbW92ICAgICVlYXgsMHhmZmZmZmZmMCglZWJwKQ0KMHhjMDE2MWY5MSA8 X3BiX2RpcmVjdF9pbyszODE+Ogltb3ZsICAgJDB4MCwweGZmZmZmZmY0KCVl YnApDQoweGMwMTYxZjk4IDxfcGJfZGlyZWN0X2lvKzM4OD46CWFkZCAgICAl ZWF4LCglZWRpKQ0KMHhjMDE2MWY5YSA8X3BiX2RpcmVjdF9pbyszOTA+Oglz dWIgICAgJWVheCwweDQoJWVkaSkNCjB4YzAxNjFmOWQgPF9wYl9kaXJlY3Rf aW8rMzkzPjoJbW92ICAgIDB4ZmZmZmZmZjAoJWVicCksJWVheA0KMHhjMDE2 MWZhMCA8X3BiX2RpcmVjdF9pbyszOTY+Ogltb3YgICAgMHhmZmZmZmZmNCgl ZWJwKSwlZWR4DQoweGMwMTYxZmEzIDxfcGJfZGlyZWN0X2lvKzM5OT46CWFk ZCAgICAlZWF4LDB4MTAoJWVkaSkNCjB4YzAxNjFmYTYgPF9wYl9kaXJlY3Rf aW8rNDAyPjoJYWRjICAgICVlZHgsMHgxNCglZWRpKQ0KMHhjMDE2MWZhOSA8 X3BiX2RpcmVjdF9pbys0MDU+OglhZGQgICAgJWVheCwweDIwKCVlZGkpDQow eGMwMTYxZmFjIDxfcGJfZGlyZWN0X2lvKzQwOD46CWFkYyAgICAlZWR4LDB4 MjQoJWVkaSkNCjB4YzAxNjFmYWYgPF9wYl9kaXJlY3RfaW8rNDExPjoJam1w ICAgIDB4YzAxNjFmYjcgPF9wYl9kaXJlY3RfaW8rNDE5Pg0KMHhjMDE2MWZi MSA8X3BiX2RpcmVjdF9pbys0MTM+Ogltb3YgICAgMHgyMCglZWJwKSwlZWF4 DQoweGMwMTYxZmI0IDxfcGJfZGlyZWN0X2lvKzQxNj46CW1vdiAgICAlZXNp LDB4YyglZWF4KQ0KMHhjMDE2MWZiNyA8X3BiX2RpcmVjdF9pbys0MTk+Oglw dXNoICAgJWVieA0KMHhjMDE2MWZiOCA8X3BiX2RpcmVjdF9pbys0MjA+Oglj YWxsICAgMHhjMDE2MDQ3NCA8cGFnZWJ1Zl9yZWxlPg0KMHhjMDE2MWZiZCA8 X3BiX2RpcmVjdF9pbys0MjU+Ogl0ZXN0ICAgJWVzaSwlZXNpDQoweGMwMTYx ZmJmIDxfcGJfZGlyZWN0X2lvKzQyNz46CWpuZSAgICAweGMwMTYxZmM2IDxf cGJfZGlyZWN0X2lvKzQzND4NCjB4YzAxNjFmYzEgPF9wYl9kaXJlY3RfaW8r NDI5PjoJbW92ICAgIDB4MTQoJWVicCksJWVjeA0KMHhjMDE2MWZjNCA8X3Bi X2RpcmVjdF9pbys0MzI+OglqbXAgICAgMHhjMDE2MWZjOCA8X3BiX2RpcmVj dF9pbys0MzY+DQoweGMwMTYxZmM2IDxfcGJfZGlyZWN0X2lvKzQzND46CXhv ciAgICAlZWN4LCVlY3gNCjB4YzAxNjFmYzggPF9wYl9kaXJlY3RfaW8rNDM2 PjoJbW92ICAgICVlY3gsJWVheA0KMHhjMDE2MWZjYSA8X3BiX2RpcmVjdF9p bys0Mzg+OglsZWEgICAgMHhmZmZmZmZjNCglZWJwKSwlZXNwDQoweGMwMTYx ZmNkIDxfcGJfZGlyZWN0X2lvKzQ0MT46CXBvcCAgICAlZWJ4DQoweGMwMTYx ZmNlIDxfcGJfZGlyZWN0X2lvKzQ0Mj46CXBvcCAgICAlZXNpDQoweGMwMTYx ZmNmIDxfcGJfZGlyZWN0X2lvKzQ0Mz46CXBvcCAgICAlZWRpDQoweGMwMTYx ZmQwIDxfcGJfZGlyZWN0X2lvKzQ0ND46CW1vdiAgICAlZWJwLCVlc3ANCjB4 YzAxNjFmZDIgPF9wYl9kaXJlY3RfaW8rNDQ2PjoJcG9wICAgICVlYnANCjB4 YzAxNjFmZDMgPF9wYl9kaXJlY3RfaW8rNDQ3PjoJcmV0ICAgIA0KRW5kIG9m IGFzc2VtYmxlciBkdW1wLg0KKGdkYikgcQ0KDQo= ---559023410-33463914-992145249=:7090-- From owner-linux-xfs@oss.sgi.com Sat Jun 9 22:34:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A5Yox12088 for linux-xfs-outgoing; Sat, 9 Jun 2001 22:34:50 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A5YnV12085 for ; Sat, 9 Jun 2001 22:34:49 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id BAA27866; Sun, 10 Jun 2001 01:28:07 -0400 Message-ID: <3B23099E.1C1DC95A@ieee.org> Date: Sun, 10 Jun 2001 01:46:06 -0400 From: "Bryan J. Smith" Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dan Swartzendruber CC: Steve Lord , Sean Elble , Seth Mos , linux-xfs@oss.sgi.com Subject: Re: XFS/Linux 1.1?? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [ Probably starting to get off topic here. ] Dan Swartzendruber wrote: > well, what can i say. i really like quicken/2000. We need more people to lobby Intuit. GNUCash is nice, but an OSS project just cannot build the industry relationships so users can do on-line banking. TheKompany's trying to do this, and it will be interesting to see what happens. > and wine is just lame ??? It's a great porting toolkit first and formost. And from the standpoint of reverse engineering for "run-time," it's amazing what they have done. I've always sided with Linus that the "goal" is to get commercial developers to produce native apps for Linux. But what the WINE project has done is nothing less than unbelievable. > - it's been 75% (or whatever) done for years now, it seems Yes, and it will _always_ be like that. You cannot "hit" a moving target. Samba is in the same boat. But it's 100% Windows free, unlike Win4Lin or VMWare. Heck, some older apps that will not run under 98, ME or 2000 run fine under WINE! This is a testament to its capabilities. > if i can get a nice threaded mail client with IMAP support, > i'd move my mail from win98 to KDE in a flash. Well, there is GTK+-based Sylpheed (although it should run fine in KDE as well): http://sylpheed.good-day.net/ BTW, I recently posted a list of apps that I use regularly: http://www.zepa.net/hypermail/elug/2001/05/0105.html I chucked MS Office in 1998 after upgrading to Word 97 from Word 95. I lost half my templates and, after spending 15 hours recreating the most complicated one, I simply said "fuck it." Now I will only write in LaTeX or SGML. LyX (http://www.lyx.org) does both quite nicely -- and I even use it to create presentations in small-size PDF formats (e.g., 25 slides in 50KB!). I consider MS Office to be a bastardization. The testament to that is the fact that _no_publisher_ I know of uses MS Word as its publication system (and even when they take author submissions in MS Word format, they save it as text and force the user to use "mark up" for their script that converts it to SGML anyway ;-). > i'm new here - what is the metadata journaling argument re ext3? Ext3 started out as a full-data journaling-only "add-on" to Ext2. Worked great and, after 3 months of testing in early 2000, I adopted it on all my systems (version 0.0.2f). Then Tweedie started to get fancy and went after meta-data journaling (aka "v2 mode"). All I've had with meta-data is nothing but problems -- and data loss! Worse yet, I cannot seem to figure out how to "downgrade" my journals to "v1 mode" (full-data) other than converting back to Ext2, booting a pre-0.0.3 Ext3 kernel, recreating them, and then re-booting the new kernel. The entire issue is a pure performance one. Full-data journaling is basically a "double buffer" and cuts performance in half. Meta-data just journals the structural and attribute changes to the filesystem, but not the data. The "ordered writes" mode has cost me a filesystem once, although newer versions are supposed to fix it. I really don't care because full-data is fine for me. I sure wish he would just focus on that, but Tweedie has done a fine job regardless and I don't want to knock his longstanding dedication to the kernel in general. -- TheBS -- Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 SmithConcepts, Inc. http://www.SmithConcepts.com ========================================================== Linux 'Worms' exploit known security holes that were fixed 3-12 months earlier. NT/2000 'Worms' exploit unknown se- curity holes that won't be fixed for another 3-12 months. From owner-linux-xfs@oss.sgi.com Sat Jun 9 22:45:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A5jK412292 for linux-xfs-outgoing; Sat, 9 Jun 2001 22:45:20 -0700 Received: from yowie.cc.uq.edu.au (root@yowie.cc.uq.edu.au [130.102.2.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A5jIV12289 for ; Sat, 9 Jun 2001 22:45:18 -0700 Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1]) by yowie.cc.uq.edu.au (8.9.3/8.9.3) with ESMTP id PAA24143; Sun, 10 Jun 2001 15:45:12 +1000 (GMT+1000) Received: from nut.csee.uq.edu.au (nut.csee.uq.edu.au [130.102.66.13]) by gum.csee.uq.edu.au (8.11.3/8.11.3) with ESMTP id f5A5jA508180; Sun, 10 Jun 2001 15:45:10 +1000 (EST) Received: from mango.csee.uq.edu.au (mango.csee.uq.edu.au [130.102.66.4]) by nut.csee.uq.edu.au (8.11.3/8.11.3) with ESMTP id f5A5jAo27665; Sun, 10 Jun 2001 15:45:10 +1000 (EST) Date: Sun, 10 Jun 2001 15:45:10 +1000 (EST) From: Chris Pascoe To: Steve Lord cc: Subject: Re: TAKE - delalloc buffer and page handling cleanup In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 1.1 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I get a repeatable crash immediately on 017 with these changes. Same > machine as before (1GB/Dual P3-Xeon), just a slightly different partiton > layout. Was I supposed to avoid test 017 too? Avoiding tests 013, 017, 049 (and all the tape ones!), the stress tests have completed 3 passes now.. Hmm, must have seen me typing - 042 just failed (running SMP/highmem again). Active process was: 0xef9e6000 00005670 00005669 1 001 run 0xef9e6350*xfs_fsr 042 90s ...Start mounting filesystem: sd(8,19) Ending clean XFS mount for filesystem: sd(8,19) Start mounting filesystem: sd(8,19) Ending clean XFS mount for filesystem: sd(8,19) Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: c0161ea4 *pde = 00000000 Entering kdb (current=0xef9e6000, pid 5670) on processor 1 Oops: Oops due to oops @ 0xc0161ea4 eax = 0x00000000 ebx = 0xc4b09d60 ecx = 0x00000009 edx = 0x00000000 esi = 0x4014e200 edi = 0x00000000 esp = 0xef9e7d7c eip = 0xc0161ea4 ebp = 0xef9e7db8 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010246 xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xef9e7d48 [1]kdb> bt EBP EIP Function(args) 0xef9e7db8 0xc0161ea4 _pb_direct_io+0x90 (0xf3594240, 0x0, 0x0, 0x100000, 0xef9e7e1c) kernel .text 0xc0100000 0xc0161e14 0xc0161fd4 0xef9e7e3c 0xc0163285 _pagebuf_file_write+0x175 (0xd8a99320, 0x4014e200, 0x100000, 0xef9e7ea8, 0xc01cea90) kernel .text 0xc0100000 0xc0163110 0xc016330c 0xef9e7eb0 0xc016340d pagebuf_generic_file_write+0x101 (0xd8a99320, 0x4014e200, 0x100000, 0xef9e7f84, 0xc01cea90) kernel .text 0xc0100000 0xc016330c 0xc016374c 0xef9e7f34 0xc01cfd98 xfs_write+0x348 (0xece267a8, 0xef9e7f78, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc01cfa50 0xc01d0054 0xef9e7f98 0xc01cb765 linvfs_write+0x10d (0xd8a99320, 0x4014e200, 0x100000, 0xd8a99340) kernel .text 0xc0100000 0xc01cb658 0xc01cb7a0 0xef9e7fbc 0xc0136175 sys_write+0x95 (0x7, 0x4014e200, 0x100000, 0x100000, 0x100000) kernel .text 0xc0100000 0xc01360e0 0xc01361b0 0xc0106fcb system_call+0x33 kernel .text 0xc0100000 0xc0106f98 0xc0106fd0 Chris From owner-linux-xfs@oss.sgi.com Sun Jun 10 00:06:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A766713153 for linux-xfs-outgoing; Sun, 10 Jun 2001 00:06:06 -0700 Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A764V13150 for ; Sun, 10 Jun 2001 00:06:05 -0700 Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk) by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1) id 158zJa-000GSP-0X for linux-xfs@oss.sgi.com; Sun, 10 Jun 2001 08:07:15 +0100 Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3]) by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id DC9BD27F0 for ; Sun, 10 Jun 2001 08:06:00 +0100 (BST) Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001) id 679E3125E6; Sun, 10 Jun 2001 08:05:59 +0100 (BST) Date: Sun, 10 Jun 2001 08:05:59 +0100 (BST) From: Keith Matthews Subject: Re[2]: XFS/Linux 1.1?? To: linux-xfs@oss.sgi.com In-Reply-To: <3B22D1F6.434FFE0A@ieee.org> References: <200106092337.f59Nb4E15754@lord.americas.sgi.com>, <3B22D1F6.434FFE0A@ieee.org> X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Disposition: INLINE Message-Id: <20010610070559.679E3125E6@rebutia.sweeney.demon.co.uk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f5A765V13151 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 09 Jun 2001 21:48:38 -0400 Bryan J. Smith > wrote: > > BTW, I see RedHat has added the Ext3 patch to their 2.4.5-0.2.9 > release, but I've see nothing but "problems" on the Ext3 list > (although a lot are Ext2 issues under 2.4.x as well). IMHO, I think > Tweedie/RedHat should just focus on getting full data journaling > complete (I'm still wondering why I tried to do meta-data > journaling) and leave any "advanced" features to other JFS' like > XFS. Because if you are running a DBMS the last thing you want is the OS _also_ journalling main data writes, metadata is all that you want. For the record I spoke to Stephen at the Linux Conference in Birmingham 2 years ago and he stated then that metadata only was actually more difficult than journalling everything. Steve may want to comment further. ([OT] PS, is it pure chance that 3 of the filesystem leading names are 'Stephen' ? (g)) -- Keith Matthews Spam trap - my real account at this node is keith_m Frequentous Consultants - Linux Services, Oracle development & database administration From owner-linux-xfs@oss.sgi.com Sun Jun 10 00:07:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A77ep13243 for linux-xfs-outgoing; Sun, 10 Jun 2001 00:07:40 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A77dV13240 for ; Sun, 10 Jun 2001 00:07:39 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f5A77PaJ056302; Sun, 10 Jun 2001 02:07:26 -0500 (CDT) Message-ID: <3B231CA6.E1AB993B@thebarn.com> Date: Sun, 10 Jun 2001 02:07:18 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: "Bryan J. Smith" , linux-xfs@oss.sgi.com, Russell Cattelan Subject: Re: Russell's patch against RH 7.1 ... References: <19180.992139985@ocs4.ocs-net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > On Sat, 09 Jun 2001 21:59:47 -0400, > "Bryan J. Smith" wrote: > >*DUMB* question: What is the "RHlinux-*" file for? I looked > >through the files and it seems to be a subset of the other. > > linux-2.4.5-xfs-06082001.patch contains the new XFS files, > RHlinux-2.4.5-core-xfs-06082001.patch contains XFS changes to the core > kernel. > > BTW Russell, linux-2.4.5-xfs-06082001.patch contains lots of generated > files. You need to exclude .depend, .hdepend and .*flags files. Oops sorry about that forgot to do a mrproper first I'll have a better set of patches once I'm sure the merge actually runs. -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Sun Jun 10 00:43:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A7hC713601 for linux-xfs-outgoing; Sun, 10 Jun 2001 00:43:12 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A7hAV13595 for ; Sun, 10 Jun 2001 00:43:10 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip35.idcomm.com [209.60.72.162]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5A7gEF26032 for ; Sun, 10 Jun 2001 01:42:14 -0600 Message-ID: <3B23253F.6EE690FC@idcomm.com> Date: Sun, 10 Jun 2001 01:43:59 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: TAKE - delalloc buffer and page handling cleanup References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Chris Pascoe wrote: > > > I get a repeatable crash immediately on 017 with these changes. Same > > machine as before (1GB/Dual P3-Xeon), just a slightly different partiton > > layout. Was I supposed to avoid test 017 too? > > Avoiding tests 013, 017, 049 (and all the tape ones!), the stress tests > have completed 3 passes now.. Hmm, must have seen me typing - 042 just > failed (running SMP/highmem again). My SMP worked on 042 without fail; this was from the 2.4.6-pre1, are you using this version too? I did have 049 fail, "!!! failed to loop mount xfs", as well as 053 giving a lot of fails due to unimplemented functions. I am still wondering about the post I gave for my failed tests, but I can add something of an experiment I did. For the use of encrypted filesystem partitions, it requires use of loop device. Should something happen to the encrypted system, such as power fail or power off, one has to do any sort of filesystem recovery through the loop device. That in turn requires mounting the partition and then running the test against /dev/loop0 (or maybe loop1 if it was the second encrypted system to mount). But xfs_repair refuses to run on a mounted system. So I might suggest that xfs_repair be allowed on a mounted system, provided some circumstances are met. One, which I am not sure if is possible, is that it could be allowed to run if it is detected to be a loopback device; if this detection isn't possible, there might be a need for a flag to allow forced repair (maybe the encrypted partition could be mounted read only?). Anyway, the other limitation is that during the creation of a loopback encrypted partition, the mkfs.xfs causes an error note about block size parameter not being valid. This didn't seem to make any big impact, because I was able to create an XOR loopback layer over a partition, and still run mkfs.xfs. I then copied a large amount of data over, and intentionally shut the power off without unmounting it (it wasn't writing at the time though). When I brought it back up, mounting it with the encryption password worked fine, and under superficial inspection it appeared to be ok. I did not check it close enough to know if it really was ok, so it might not be as good as it seems. If anyone is interested in seeing what happens, you can create an encrypted partition via something like this (I'll assume /dev/hda4; normally you would also pad the partition with random bytes first, I won't for this): losetup -e XOR /dev/loop0 /dev/hda4 [enter some easy to remember pass] mkfs.xfs /dev/loop0 losetup -d /dev/loop0 Now to mount it: mount /dev/hda4 /mnt/somewhere -t xfs -oloop,encryption=xor [enter pass] You should be able to use the partition normally at /mnt/somewhere. Now if you wanted to run repair on it and it was ext2, you'd mount it this way and run: fsck.ext2 /dev/loop0 Running instead fsck.xfs /dev/loop0 will run and not say anything...does this mean it didn't do anything? Or just that it was clean? If instead I wanted to run xfs_repair, it will refuse...I suppose it may not be appropriate even, should xfs_repair be useful against loopback devices? D. Stimits, stimits@idcomm.com > > Active process was: > 0xef9e6000 00005670 00005669 1 001 run 0xef9e6350*xfs_fsr > > 042 90s ...Start mounting filesystem: sd(8,19) > Ending clean XFS mount for filesystem: sd(8,19) > Start mounting filesystem: sd(8,19) > Ending clean XFS mount for filesystem: sd(8,19) > Unable to handle kernel NULL pointer dereference at virtual address > 00000000 > printing eip: > c0161ea4 > *pde = 00000000 > > Entering kdb (current=0xef9e6000, pid 5670) on processor 1 Oops: Oops > due to oops @ 0xc0161ea4 > eax = 0x00000000 ebx = 0xc4b09d60 ecx = 0x00000009 edx = 0x00000000 > esi = 0x4014e200 edi = 0x00000000 esp = 0xef9e7d7c eip = 0xc0161ea4 > ebp = 0xef9e7db8 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010246 > xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xef9e7d48 > [1]kdb> bt > EBP EIP Function(args) > 0xef9e7db8 0xc0161ea4 _pb_direct_io+0x90 (0xf3594240, 0x0, 0x0, 0x100000, 0xef9e7e1c) > kernel .text 0xc0100000 0xc0161e14 0xc0161fd4 > 0xef9e7e3c 0xc0163285 _pagebuf_file_write+0x175 (0xd8a99320, 0x4014e200, 0x100000, 0xef9e7ea8, 0xc01cea90) > kernel .text 0xc0100000 0xc0163110 0xc016330c > 0xef9e7eb0 0xc016340d pagebuf_generic_file_write+0x101 (0xd8a99320, 0x4014e200, 0x100000, 0xef9e7f84, 0xc01cea90) > kernel .text 0xc0100000 0xc016330c 0xc016374c > 0xef9e7f34 0xc01cfd98 xfs_write+0x348 (0xece267a8, 0xef9e7f78, 0x0, 0x0, 0x0) > kernel .text 0xc0100000 0xc01cfa50 0xc01d0054 > 0xef9e7f98 0xc01cb765 linvfs_write+0x10d (0xd8a99320, 0x4014e200, 0x100000, 0xd8a99340) > kernel .text 0xc0100000 0xc01cb658 0xc01cb7a0 > 0xef9e7fbc 0xc0136175 sys_write+0x95 (0x7, 0x4014e200, 0x100000, 0x100000, 0x100000) > kernel .text 0xc0100000 0xc01360e0 0xc01361b0 > 0xc0106fcb system_call+0x33 > kernel .text 0xc0100000 0xc0106f98 0xc0106fd0 > > Chris From owner-linux-xfs@oss.sgi.com Sun Jun 10 01:30:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5A8Ug514456 for linux-xfs-outgoing; Sun, 10 Jun 2001 01:30:42 -0700 Received: from yowie.cc.uq.edu.au (root@yowie.cc.uq.edu.au [130.102.2.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5A8UcV14452 for ; Sun, 10 Jun 2001 01:30:39 -0700 Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1]) by yowie.cc.uq.edu.au (8.9.3/8.9.3) with ESMTP id SAA25918 for ; Sun, 10 Jun 2001 18:30:35 +1000 (GMT+1000) Received: from nut.csee.uq.edu.au (nut.csee.uq.edu.au [130.102.66.13]) by gum.csee.uq.edu.au (8.11.3/8.11.3) with ESMTP id f5A8UX510360 for ; Sun, 10 Jun 2001 18:30:33 +1000 (EST) Received: from mango.csee.uq.edu.au (mango.csee.uq.edu.au [130.102.66.4]) by nut.csee.uq.edu.au (8.11.3/8.11.3) with ESMTP id f5A8UXo29642 for ; Sun, 10 Jun 2001 18:30:33 +1000 (EST) Date: Sun, 10 Jun 2001 18:30:00 +1000 (EST) From: Chris Pascoe To: "D. Stimits" Subject: Re: TAKE - delalloc buffer and page handling cleanup In-Reply-To: <3B232396.5344500B@idcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 1.1 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Did you mean to CC this to the list as well? I'm not an XFS developer, just testing! The kernel I used for my tests was the 2.4.6-pre2 one, with the delalloc changes. Check your CVS/Entries files to make sure you got the versions affected by this TAKE (it took several days before I got them!) 042 was always working for me before these changes... just this time, it failed after several complete runs through all of the tests. The 017 one was quite dramatic for me, just start it and it would crash within a second... Chris On Sun, 10 Jun 2001, D. Stimits wrote: > Chris Pascoe wrote: > > > > > I get a repeatable crash immediately on 017 with these changes. Same > > > machine as before (1GB/Dual P3-Xeon), just a slightly different partiton > > > layout. Was I supposed to avoid test 017 too? > > > > Avoiding tests 013, 017, 049 (and all the tape ones!), the stress tests > > have completed 3 passes now.. Hmm, must have seen me typing - 042 just > > failed (running SMP/highmem again). > > My SMP worked on 042 without fail; this was from the 2.4.6-pre1, are you > using this version too? > > I did have 049 fail, "!!! failed to loop mount xfs", as well as 053 > giving a lot of fails due to unimplemented functions. I am still > wondering about the post I gave for my failed tests, but I can add > something of an experiment I did. For the use of encrypted filesystem > partitions, it requires use of loop device. Should something happen to > the encrypted system, such as power fail or power off, one has to do any > sort of filesystem recovery through the loop device. That in turn > requires mounting the partition and then running the test against > /dev/loop0 (or maybe loop1 if it was the second encrypted system to > mount). But xfs_repair refuses to run on a mounted system. So I might > suggest that xfs_repair be allowed on a mounted system, provided some > circumstances are met. One, which I am not sure if is possible, is that > it could be allowed to run if it is detected to be a loopback device; if > this detection isn't possible, there might be a need for a flag to allow > forced repair (maybe the encrypted partition could be mounted read > only?). > > Anyway, the other limitation is that during the creation of a loopback > encrypted partition, the mkfs.xfs causes an error note about block size > parameter not being valid. This didn't seem to make any big impact, > because I was able to create an XOR loopback layer over a partition, and > still run mkfs.xfs. I then copied a large amount of data over, and > intentionally shut the power off without unmounting it (it wasn't > writing at the time though). When I brought it back up, mounting it with > the encryption password worked fine, and under superficial inspection it > appeared to be ok. I did not check it close enough to know if it really > was ok, so it might not be as good as it seems. > > If anyone is interested in seeing what happens, you can create an > encrypted partition via something like this (I'll assume /dev/hda4; > normally you would also pad the partition with random bytes first, I > won't for this): > losetup -e XOR /dev/loop0 /dev/hda4 > [enter some easy to remember pass] > mkfs.xfs /dev/loop0 > losetup -d /dev/loop0 > > Now to mount it: > mount /dev/hda4 /mnt/somewhere -t xfs -oloop,encryption=xor > [enter pass] > > You should be able to use the partition normally at /mnt/somewhere. Now > if you wanted to run repair on it and it was ext2, you'd mount it this > way and run: > fsck.ext2 /dev/loop0 > > Running instead > fsck.xfs /dev/loop0 > will run and not say anything...does this mean it didn't do anything? Or > just that it was clean? > > If instead I wanted to run xfs_repair, it will refuse...I suppose it may > not be appropriate even, should xfs_repair be useful against loopback > devices? > > D. Stimits, stimits@idcomm.com > > > > > Active process was: > > 0xef9e6000 00005670 00005669 1 001 run 0xef9e6350*xfs_fsr > > > > 042 90s ...Start mounting filesystem: sd(8,19) > > Ending clean XFS mount for filesystem: sd(8,19) > > Start mounting filesystem: sd(8,19) > > Ending clean XFS mount for filesystem: sd(8,19) > > Unable to handle kernel NULL pointer dereference at virtual address > > 00000000 > > printing eip: > > c0161ea4 > > *pde = 00000000 > > > > Entering kdb (current=0xef9e6000, pid 5670) on processor 1 Oops: Oops > > due to oops @ 0xc0161ea4 > > eax = 0x00000000 ebx = 0xc4b09d60 ecx = 0x00000009 edx = 0x00000000 > > esi = 0x4014e200 edi = 0x00000000 esp = 0xef9e7d7c eip = 0xc0161ea4 > > ebp = 0xef9e7db8 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010246 > > xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xef9e7d48 > > [1]kdb> bt > > EBP EIP Function(args) > > 0xef9e7db8 0xc0161ea4 _pb_direct_io+0x90 (0xf3594240, 0x0, 0x0, 0x100000, 0xef9e7e1c) > > kernel .text 0xc0100000 0xc0161e14 0xc0161fd4 > > 0xef9e7e3c 0xc0163285 _pagebuf_file_write+0x175 (0xd8a99320, 0x4014e200, 0x100000, 0xef9e7ea8, 0xc01cea90) > > kernel .text 0xc0100000 0xc0163110 0xc016330c > > 0xef9e7eb0 0xc016340d pagebuf_generic_file_write+0x101 (0xd8a99320, 0x4014e200, 0x100000, 0xef9e7f84, 0xc01cea90) > > kernel .text 0xc0100000 0xc016330c 0xc016374c > > 0xef9e7f34 0xc01cfd98 xfs_write+0x348 (0xece267a8, 0xef9e7f78, 0x0, 0x0, 0x0) > > kernel .text 0xc0100000 0xc01cfa50 0xc01d0054 > > 0xef9e7f98 0xc01cb765 linvfs_write+0x10d (0xd8a99320, 0x4014e200, 0x100000, 0xd8a99340) > > kernel .text 0xc0100000 0xc01cb658 0xc01cb7a0 > > 0xef9e7fbc 0xc0136175 sys_write+0x95 (0x7, 0x4014e200, 0x100000, 0x100000, 0x100000) > > kernel .text 0xc0100000 0xc01360e0 0xc01361b0 > > 0xc0106fcb system_call+0x33 > > kernel .text 0xc0100000 0xc0106f98 0xc0106fd0 > > > > Chris > From owner-linux-xfs@oss.sgi.com Sun Jun 10 03:43:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5AAh3o16206 for linux-xfs-outgoing; Sun, 10 Jun 2001 03:43:03 -0700 Received: from linpro.no (qmailr@mail.linpro.no [213.203.57.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5AAh1V16200 for ; Sun, 10 Jun 2001 03:43:01 -0700 Received: (qmail 21282 invoked from network); 10 Jun 2001 10:42:59 -0000 Received: from false.linpro.no (213.203.57.201) by mail.linpro.no with SMTP; 10 Jun 2001 10:42:59 -0000 Received: from ay by false.linpro.no with local (Exim 3.22 #1 (Debian)) id 1592gN-0004aa-00 for ; Sun, 10 Jun 2001 12:42:59 +0200 Date: Sun, 10 Jun 2001 12:42:59 +0200 From: Audun Ytterdal To: linux-xfs@oss.sgi.com Subject: Re: how to tell? Message-ID: <20010610124259.A16794@false.linpro.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B2297BE.7A0D5480@idcomm.com> User-Agent: Mutt/1.3.18i Organization: Linpro A/S X-message-flag: Outlook is bad for you X-editor: Jed with muttmail Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [D. Stimits] > rollingblackout wrote: > > how about "mount" command? > > > > [thang@pissboy thang]$ mount > > /dev/hda5 on / type xfs (rw) > > none on /proc type proc (rw) > > /dev/hda6 on /xfs type xfs (rw) > > /dev/hda3 on /reiser type reiserfs (rw) > > /dev/hda1 on /win type vfat (rw) > > /dev/hda2 on /ext2 type ext2 (rw) > > none on /dev/pts type devpts (rw,gid=5,mode=620) > > > > cheers! > > Ahh, so simple, thanks. Related to some other answers, it looks like the > /proc/partitions does not actually list filesystem type; and mtab is > good, but the mount command without arguments seems to be the easiest. > Thanks! df -T -- Audun From owner-linux-xfs@oss.sgi.com Sun Jun 10 05:52:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5ACqVd23137 for linux-xfs-outgoing; Sun, 10 Jun 2001 05:52:31 -0700 Received: from sphinx.druber.com (druber-gw.lightband.com [216.129.135.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5ACqTV23134 for ; Sun, 10 Jun 2001 05:52:29 -0700 Received: from sphinx.druber.com (sphinx.druber.com [10.0.0.2]) by sphinx.druber.com (Postfix) with ESMTP id 16A768650; Sun, 10 Jun 2001 08:50:22 -0400 (EDT) Date: Sun, 10 Jun 2001 08:50:22 -0400 (EDT) From: Dan Swartzendruber To: "Bryan J. Smith" Cc: Steve Lord , Sean Elble , Seth Mos , Subject: Re: XFS/Linux 1.1?? In-Reply-To: <3B23099E.1C1DC95A@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 10 Jun 2001, Bryan J. Smith wrote: > [ Probably starting to get off topic here. ] > > Dan Swartzendruber wrote: > > well, what can i say. i really like quicken/2000. > > We need more people to lobby Intuit. GNUCash is nice, but an OSS > project just cannot build the industry relationships so users can do > on-line banking. TheKompany's trying to do this, and it will be > interesting to see what happens. interesting idea. > > and wine is just lame > > ??? It's a great porting toolkit first and formost. And from the > standpoint of reverse engineering for "run-time," it's amazing what > they have done. I've always sided with Linus that the "goal" is to > get commercial developers to produce native apps for Linux. But > what the WINE project has done is nothing less than unbelievable. i didn't mean to (potentially) offend anyone. i'm sure the wine guys have worked their butts off. i mean from the enduser standpoint, as far as using an advanced app like quicken2000. > > - it's been 75% (or whatever) done for years now, it seems > > Yes, and it will _always_ be like that. You cannot "hit" a moving > target. Samba is in the same boat. i don't agree. samba may not be "complete", but it does everything i need to do (the only things missing are not visible to win98 it seems). the last i heard, quicken2000 under wine can display the account registers and do much of the mechanical stuff, but the online operations don't work (which is 99% of my reason for using it). > But it's 100% Windows free, unlike Win4Lin or VMWare. Heck, some > older apps that will not run under 98, ME or 2000 run fine under > WINE! This is a testament to its capabilities. > > > if i can get a nice threaded mail client with IMAP support, > > i'd move my mail from win98 to KDE in a flash. > > Well, there is GTK+-based Sylpheed (although it should run fine in > KDE as well): > http://sylpheed.good-day.net/ worth taking a look at. i've also heard from someone that kde alpha kmail supports it. > BTW, I recently posted a list of apps that I use regularly: > http://www.zepa.net/hypermail/elug/2001/05/0105.html > > I chucked MS Office in 1998 after upgrading to Word 97 from Word > 95. I lost half my templates and, after spending 15 hours > recreating the most complicated one, I simply said "fuck it." Now I > will only write in LaTeX or SGML. LyX (http://www.lyx.org) does > both quite nicely -- and I even use it to create presentations in > small-size PDF formats (e.g., 25 slides in 50KB!). I consider MS > Office to be a bastardization. The testament to that is the fact > that _no_publisher_ I know of uses MS Word as its publication system > (and even when they take author submissions in MS Word format, they > save it as text and force the user to use "mark up" for their script > that converts it to SGML anyway ;-). hee hee. i can't argue. then again, i almost never use any of the office crap any (from winblows). > > i'm new here - what is the metadata journaling argument re ext3? > > Ext3 started out as a full-data journaling-only "add-on" to Ext2. > Worked great and, after 3 months of testing in early 2000, I adopted > it on all my systems (version 0.0.2f). Then Tweedie started to get > fancy and went after meta-data journaling (aka "v2 mode"). All I've > had with meta-data is nothing but problems -- and data loss! Worse > yet, I cannot seem to figure out how to "downgrade" my journals to > "v1 mode" (full-data) other than converting back to Ext2, booting a > pre-0.0.3 Ext3 kernel, recreating them, and then re-booting the new > kernel. ugh. > The entire issue is a pure performance one. Full-data journaling is > basically a "double buffer" and cuts performance in half. Meta-data > just journals the structural and attribute changes to the > filesystem, but not the data. The "ordered writes" mode has cost me > a filesystem once, although newer versions are supposed to fix it. > I really don't care because full-data is fine for me. I sure wish > he would just focus on that, but Tweedie has done a fine job > regardless and I don't want to knock his longstanding dedication to > the kernel in general. point. one of the things that pissed me off about reiserfs was the (as far as i know) un-announced incompatible change. i had been running mandrake 7.2 with all reiserfs. went to reinstall to get up to 2.4.3 (via mandrake 8) and couldn't access things. finally gave up (after 10+ hours and 3AM) and went to ext2. *later* i find out what happened :( From owner-linux-xfs@oss.sgi.com Sun Jun 10 09:22:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5AGMKf26876 for linux-xfs-outgoing; Sun, 10 Jun 2001 09:22:20 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5AGMIV26873 for ; Sun, 10 Jun 2001 09:22:18 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id MAA03229; Sun, 10 Jun 2001 12:15:29 -0400 Message-ID: <3B23A15D.8C23C74C@ieee.org> Date: Sun, 10 Jun 2001 12:33:33 -0400 From: "Bryan J. Smith" Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dan Swartzendruber CC: Steve Lord , Sean Elble , Seth Mos , linux-xfs@oss.sgi.com Subject: Re: XFS/Linux 1.1?? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dan Swartzendruber wrote: > i didn't mean to (potentially) offend anyone. i'm sure the wine guys > have worked their butts off. i mean from the enduser standpoint, as > far as using an advanced app like quicken2000. First off, don't use the "latest and greatest." I run into Windows bigots daily who say "when Linux apps can support my Office 2000 documents, then I'll switch." Of course, they are the same ones who goto XP the day it comes out. CASE IN POINT: Microsoft canNOT even get MS Office for Mac formats to work with most of the MS Office for Windows ones (I mean, ever try Excel? CSV baby! ;-). Stick with older versions and you'll be better off. Better yet, lobby Intuit! > i don't agree. samba may not be "complete", but it does everything > i need to do (the only things missing are not visible to win98 it > seems). First off, you're talking to a contributor on "Samba Unleashed." And I was not saying anything "bad" about Samba -- actually, Samba is _exponentially_more_stable_ than native NT because Samba is a pure, 100% userspace daemon. But Samba _is_ in the same boat as WINE -- wasteful reverse engineering that takes years and can never keep up. Personally, I think it's time (and it has been suggested) that the Samba team create their own client-side interfaces to Samba. Although that could be another lesson in frustration (Microsoft doesn't exactly put "everything" in the DDK). So, this brings me back to my original point: Don't used the "latest and greatest" features. I constantly bang my head on the wall when some smuckie on the Samba list says "please get ActiveDirectory working, I need it." > worth taking a look at. i've also heard from someone that kde alpha > kmail supports it. Well, age old Netscape Communicator does fine for me. > hee hee. i can't argue. then again, i almost never use any of the > office crap any (from winblows). I _hate_ word processors. Give me a DTP or give me nothing. I'm still lobbying IBM to release the Ami Pro 3.1 source code as OSS. ;-PPP Hopefully KWord will be the replacement I am looking for. > point. one of the things that pissed me off about reiserfs was the > (as far as i know) un-announced incompatible change. i had been > running mandrake 7.2 with all reiserfs. went to reinstall to get > up to 2.4.3 (via mandrake 8) and couldn't access things. finally > gave up (after 10+ hours and 3AM) and went to ext2. *later* i find > out what happened :( Again, I'm not going to touch ReiserFS. I don't want to be further labelled by Hans Reiser as someone with "ReiserFS jealousy" because it is in the stock kernel (and Ext3/XFS is not). -- TheBS -- Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 SmithConcepts, Inc. http://www.SmithConcepts.com ========================================================== Linux 'Worms' exploit known security holes that were fixed 3-12 months earlier. NT/2000 'Worms' exploit unknown se- curity holes that won't be fixed for another 3-12 months. From owner-linux-xfs@oss.sgi.com Sun Jun 10 10:25:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5AHPSl27951 for linux-xfs-outgoing; Sun, 10 Jun 2001 10:25:28 -0700 Received: from sphinx.druber.com (druber-gw.lightband.com [216.129.135.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5AHPPV27948 for ; Sun, 10 Jun 2001 10:25:26 -0700 Received: from manticore.druber.com (manticore.druber.com [10.0.0.19]) by sphinx.druber.com (Postfix) with ESMTP id 75C77864F; Sun, 10 Jun 2001 13:23:16 -0400 (EDT) Message-Id: <5.1.0.14.0.20010610131639.009ece60@sphinx.druber.com> X-Sender: dswartz@sphinx.druber.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 10 Jun 2001 13:23:16 -0400 To: "Bryan J. Smith" From: Dan Swartzendruber Subject: Re: XFS/Linux 1.1?? Cc: Steve Lord , Sean Elble , Seth Mos , linux-xfs@oss.sgi.com In-Reply-To: <3B23A15D.8C23C74C@ieee.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:33 PM 6/10/01 -0400, Bryan J. Smith wrote: >Dan Swartzendruber wrote: > > i didn't mean to (potentially) offend anyone. i'm sure the wine guys > > have worked their butts off. i mean from the enduser standpoint, as > > far as using an advanced app like quicken2000. > >First off, don't use the "latest and greatest." I run into Windows >bigots daily who say "when Linux apps can support my Office 2000 >documents, then I'll switch." Of course, they are the same ones who >goto XP the day it comes out. > >CASE IN POINT: Microsoft canNOT even get MS Office for Mac formats >to work with most of the MS Office for Windows ones (I mean, ever >try Excel? CSV baby! ;-). > >Stick with older versions and you'll be better off. Better yet, >lobby Intuit! it's not a matter of latest and greatest. it's a matter of things i can do with q2000 that i can't do with older ones. yes, i'm perfectly aware i could do without those features, but i don't want to. as far as "lobbying intuit" is concerned, this is basic Business 101. companies like intuit will start porting apps like quicken to linux when it captures a reasonable market share of the desktop (i know there's a certain degree of chicken and egg there, but that's life). > > i don't agree. samba may not be "complete", but it does everything > > i need to do (the only things missing are not visible to win98 it > > seems). > >First off, you're talking to a contributor on "Samba Unleashed." >And I was not saying anything "bad" about Samba -- actually, Samba >is _exponentially_more_stable_ than native NT because Samba is a >pure, 100% userspace daemon. But Samba _is_ in the same boat as >WINE -- wasteful reverse engineering that takes years and can never >keep up. we're talking apples and oranges here. my point was simply that for most applications relating to win9x networking, samba is pretty much as good as having an NT server. looking at the compatibility list for wine, only someone with very generous definitions could say the same thing. just looking at the issue as an end-user here, not a developer. >Personally, I think it's time (and it has been suggested) that the >Samba team create their own client-side interfaces to Samba. >Although that could be another lesson in frustration (Microsoft >doesn't exactly put "everything" in the DDK). > >So, this brings me back to my original point: Don't used the >"latest and greatest" features. I constantly bang my head on the >wall when some smuckie on the Samba list says "please get >ActiveDirectory working, I need it." addressed this already. > > worth taking a look at. i've also heard from someone that kde alpha > > kmail supports it. > >Well, age old Netscape Communicator does fine for me. fine for you. i note you never asked why i need IMAP. if i was able (or willing) to settle for POP3, there are a myriad of apps i could use (including the current kmail). From owner-linux-xfs@oss.sgi.com Sun Jun 10 11:40:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5AIe2H08535 for linux-xfs-outgoing; Sun, 10 Jun 2001 11:40:02 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5AIdxV08521 for ; Sun, 10 Jun 2001 11:39:59 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip26.idcomm.com [209.60.72.153]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5AId7F31045 for ; Sun, 10 Jun 2001 12:39:07 -0600 Message-ID: <3B23BF31.26DF5174@idcomm.com> Date: Sun, 10 Jun 2001 12:40:49 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: how to tell? References: <20010610124259.A16794@false.linpro.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Audun Ytterdal wrote: > > [D. Stimits] > > rollingblackout wrote: > > > how about "mount" command? > > > > > > [thang@pissboy thang]$ mount > > > /dev/hda5 on / type xfs (rw) > > > none on /proc type proc (rw) > > > /dev/hda6 on /xfs type xfs (rw) > > > /dev/hda3 on /reiser type reiserfs (rw) > > > /dev/hda1 on /win type vfat (rw) > > > /dev/hda2 on /ext2 type ext2 (rw) > > > none on /dev/pts type devpts (rw,gid=5,mode=620) > > > > > > cheers! > > > > Ahh, so simple, thanks. Related to some other answers, it looks like the > > /proc/partitions does not actually list filesystem type; and mtab is > > good, but the mount command without arguments seems to be the easiest. > > Thanks! > > df -T > > -- > Audun Just to let me know where things stand, I've added this to my login scripts for root and my main regular user: df -text2 -txfs -T Very nice. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Sun Jun 10 13:10:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5AKAsa22007 for linux-xfs-outgoing; Sun, 10 Jun 2001 13:10:54 -0700 Received: from femail1.rdc1.on.home.com (femail1.rdc1.on.home.com [24.2.9.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5AKAqV22004 for ; Sun, 10 Jun 2001 13:10:52 -0700 Received: from digitaltux.com ([24.101.49.82]) by femail1.rdc1.on.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010610201045.ZWDU2001.femail1.rdc1.on.home.com@digitaltux.com> for ; Sun, 10 Jun 2001 13:10:45 -0700 Received: from localhost ([127.0.0.1] helo=digitaltux.com) by digitaltux.com with smtp (Exim 3.22 #1 (Debian)) id 159BXn-0000Lb-00 for ; Sun, 10 Jun 2001 16:10:43 -0400 Date: Sun, 10 Jun 2001 16:10:41 -0400 From: Zoltan Kraus To: linux-xfs@oss.sgi.com Subject: Latest CVS wont build Message-Id: <20010610161041.63313c28.zoltan@digitaltux.com> X-Mailer: Sylpheed version 0.4.66 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="W6,QO:_7VG=.nujd" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --W6,QO:_7VG=.nujd Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit The latest CVS (as of 10min ago) wont get past the make dep stage. Here is the error msg: make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux' make -C kernel fastdep make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/kernel' make[2]: *** No rule to make target `/usr/src/linux-2.4-xfs/linux/include/linux/autoconf.h', needed by `/usr/src/linux-2.4-xfs/linux/include/linux/modules/signal.ver'. Stop. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/kernel' make[1]: *** [_sfdep_kernel] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux' make: *** [dep-files] Error 2 I did delete my old tree and this is a new checkout. -- Thanks, - Zoltan Kraus ________ Windows: A 32 bit hack for a 16 bit operating system, originally written for an 8 bit processor on a 4 bit bus by a 2 bit company that can't stand bit of competition! -------- --W6,QO:_7VG=.nujd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7I9RDp0iq+lfR+9YRAsz4AJ9odO9b7R9JWtAy2bPb8N4KiXIK2QCfdp7l +dOKDkDjFm0HyDx7yygddMs= =heKW -----END PGP SIGNATURE----- --W6,QO:_7VG=.nujd-- From owner-linux-xfs@oss.sgi.com Sun Jun 10 13:26:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5AKQwi23513 for linux-xfs-outgoing; Sun, 10 Jun 2001 13:26:58 -0700 Received: from mail.unixcircle.com (adsl-63-193-121-28.dsl.snfc21.pacbell.net [63.193.121.28]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5AKQvV23507 for ; Sun, 10 Jun 2001 13:26:57 -0700 Received: from unixcircle.com (pissboy.unixcircle.com [10.0.0.13]) by mail.unixcircle.com (8.12.0.Beta10/unixcircle) with ESMTP id f5AKQogD005524 for ; Sun, 10 Jun 2001 13:26:51 -0700 (PDT) Message-ID: <3B23D80C.20AB5F02@unixcircle.com> Date: Sun, 10 Jun 2001 13:26:52 -0700 From: rollingblackout Organization: a fool with a tool is still a fool -- fool@unixcircle.org X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: Latest CVS wont build References: <20010610161041.63313c28.zoltan@digitaltux.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk My checkout won't build either, but diff errs... mkivmem.c:286: warning: passing arg 1 of `down' from incompatible pointer type mkivmem.c:297: warning: passing arg 1 of `pmd_alloc' from incompatible pointer type mkivmem.c:297: warning: passing arg 2 of `pmd_alloc' makes pointer from integer without a cast mkivmem.c:297: too few arguments to function `pmd_alloc' mkivmem.c:298: warning: passing arg 1 of `pte_alloc' from incompatible pointer type mkivmem.c:298: warning: passing arg 2 of `pte_alloc' makes pointer from integer without a cast mkivmem.c:298: too few arguments to function `pte_alloc' mkivmem.c:321: warning: passing arg 1 of `up' from incompatible pointer type make[2]: *** [mkivmem.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/arch/i386/mm' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/arch/i386/mm' make: *** [_dir_arch/i386/mm] Error 2 Zoltan Kraus wrote: > > The latest CVS (as of 10min ago) wont get past the make dep stage. Here is the error msg: > make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux' > make -C kernel fastdep > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/kernel' > make[2]: *** No rule to make target `/usr/src/linux-2.4-xfs/linux/include/linux/autoconf.h', needed by `/usr/src/linux-2.4-xfs/linux/include/linux/modules/signal.ver'. Stop. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/kernel' > make[1]: *** [_sfdep_kernel] Error 2 > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux' > make: *** [dep-files] Error 2 > > I did delete my old tree and this is a new checkout. > > -- > Thanks, > - Zoltan Kraus From owner-linux-xfs@oss.sgi.com Sun Jun 10 13:31:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5AKVhj24122 for linux-xfs-outgoing; Sun, 10 Jun 2001 13:31:43 -0700 Received: from main.braxis.co.uk (main.braxis.co.uk [213.77.40.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5AKVaV24098 for ; Sun, 10 Jun 2001 13:31:37 -0700 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.9.3/8.9.3) id WAA09214; Sun, 10 Jun 2001 22:30:06 +0200 Date: Sun, 10 Jun 2001 22:30:02 +0200 From: Krzysztof Rusocki To: Zoltan Kraus Cc: linux-xfs@oss.sgi.com Subject: Re: Latest CVS wont build Message-ID: <20010610223001.A7211@main.braxis.co.uk> References: <20010610161041.63313c28.zoltan@digitaltux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010610161041.63313c28.zoltan@digitaltux.com>; from zoltan@digitaltux.com on Sun, Jun 10, 2001 at 04:10:41PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Zoltan, You ->probably<- forgot to 'make oldconfig' after copying old .config. Cheers, Krzysztof On Sun, Jun 10, 2001 at 04:10:41PM -0400, Zoltan Kraus wrote: > The latest CVS (as of 10min ago) wont get past the make dep stage. Here is the error msg: > make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux' > make -C kernel fastdep > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/kernel' > make[2]: *** No rule to make target `/usr/src/linux-2.4-xfs/linux/include/linux/autoconf.h', needed by `/usr/src/linux-2.4-xfs/linux/include/linux/modules/signal.ver'. Stop. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/kernel' > make[1]: *** [_sfdep_kernel] Error 2 > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux' > make: *** [dep-files] Error 2 > > I did delete my old tree and this is a new checkout. > > -- > Thanks, > - Zoltan Kraus > > ________ > Windows: A 32 bit hack for a 16 bit operating system, originally > written for an 8 bit processor on a 4 bit bus by a 2 bit company that > can't stand bit of competition! > -------- From owner-linux-xfs@oss.sgi.com Sun Jun 10 13:48:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5AKmFB26071 for linux-xfs-outgoing; Sun, 10 Jun 2001 13:48:15 -0700 Received: from smtp.eunet.yu (smtp.EUnet.yu [194.247.192.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5AKmCV26065 for ; Sun, 10 Jun 2001 13:48:12 -0700 Received: from flash (P-5.25.EUnet.yu [213.240.5.25]) by smtp.eunet.yu (8.11.3/8.11.3) with SMTP id f5AKm3w05931 for ; Sun, 10 Jun 2001 22:48:03 +0200 (MEST) Message-Id: <200106102048.f5AKm3w05931@smtp.eunet.yu> From: Milutin Kitic To: X-Mailer: Poco 2.1 (733) - Registered Version Date: Sun, 10 Jun 2001 22:45:42 +0200 X-URL: http://solair.eunet.yu/~miletb/ X-Mark: 0 Subject: bad blocks Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5AKmEV26068 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I have recently found some bad blocks on one of my hdd-s... On Irix i use 'fx' utility to mark them. On Linux, is there something similar? I have xfs on this disk. ------------- Pozdrav, Milutin Kitic From owner-linux-xfs@oss.sgi.com Sun Jun 10 13:56:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5AKuDe26962 for linux-xfs-outgoing; Sun, 10 Jun 2001 13:56:13 -0700 Received: from main.braxis.co.uk (root@main.braxis.co.uk [213.77.40.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5AKtUV26922 for ; Sun, 10 Jun 2001 13:55:44 -0700 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.9.3/8.9.3) id WAA13475 for linux-xfs@oss.sgi.com; Sun, 10 Jun 2001 22:55:24 +0200 Date: Sun, 10 Jun 2001 22:55:24 +0200 From: Krzysztof Rusocki To: linux-xfs@oss.sgi.com Subject: 2.4.6-pre2 still crashes. Message-ID: <20010610225524.B7211@main.braxis.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve, Could you please take a look at http://braxis.co.uk/~kszysiu/xfs/2.4.6-pre2/ Kernel was 2.4.6-pre2 dated about 20010609 19:00 CEST (GMT+0200) compiled with egcs-1.1.2. Unfortunately i still had no time to get some serial cable so i provide only backtrace of process that crashed (dammit, i didn't think to let machine continue after the second crash, lame me...) , hope that it will be sufficient (rewritten manually :/ )... Facing 2.4 generic problems here ? Cheers, Krzysztof From owner-linux-xfs@oss.sgi.com Sun Jun 10 17:08:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5B08u626077 for linux-xfs-outgoing; Sun, 10 Jun 2001 17:08:56 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5B08tV26070 for ; Sun, 10 Jun 2001 17:08:55 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 159FGI-0005Al-00 for ; Mon, 11 Jun 2001 12:08:54 +1200 Date: Mon, 11 Jun 2001 12:08:54 +1200 (NZST) From: Juha Saarinen To: Subject: Interest from the FreeBSD camp Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've noticed that there's some interest from the FreeBSD crowd in XFS. But, they don't like the GPL... would SGI consider using a BSD-style license instead? -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Sun Jun 10 18:14:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5B1EXE04183 for linux-xfs-outgoing; Sun, 10 Jun 2001 18:14:33 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5B1EWV04178 for ; Sun, 10 Jun 2001 18:14:32 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA09825 for ; Sun, 10 Jun 2001 18:14:32 -0700 (PDT) mail_from (tduffy@engr.sgi.com) Received: from engr.sgi.com (dsl-lust.corp.sgi.com [192.102.139.50]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id SAA14711; Sun, 10 Jun 2001 18:13:14 -0700 (PDT) Message-ID: <3B241B89.9247E5BC@engr.sgi.com> Date: Sun, 10 Jun 2001 18:14:49 -0700 From: Tom Duffy X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Juha Saarinen CC: linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juha Saarinen wrote: > > I've noticed that there's some interest from the FreeBSD crowd in XFS. > But, they don't like the GPL... would SGI consider using a BSD-style > license instead? IANAL, nor do I represent SGI in any official capacity, but I don't think SGI would be very interested in doing this. We (SGI) released XFS to help make Linux a high class OS because we want to sell Linux on our boxen and want a commodity OS. But, if we could convince the powers that be, it may be possible to release the code under a dual license, but then changes coming back would be tricky to reincorporate. I highly doubt we will not stop the GPL release of XFS because this would hinder the code from going into the mainline kernel. We already have a sticky situation when external people submit core xfs patches back to us if we want to put that code into IRIX. What I think the plana of action is to ask each patch maintainer if they would be willing to sign away their copyright to SGI so the code can be stuck into IRIX...I don't think this has come up yet since most of the major development has taken place in house or from SGI contractors. -tduffy From owner-linux-xfs@oss.sgi.com Sun Jun 10 18:32:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5B1Wtd07268 for linux-xfs-outgoing; Sun, 10 Jun 2001 18:32:55 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5B1WrV07263 for ; Sun, 10 Jun 2001 18:32:54 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id VAA03391; Sun, 10 Jun 2001 21:26:07 -0400 Message-ID: <3B242273.27FBCD37@ieee.org> Date: Sun, 10 Jun 2001 21:44:19 -0400 From: "Bryan J. Smith" Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Juha Saarinen CC: linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juha Saarinen wrote: > I've noticed that there's some interest from the FreeBSD > crowd in XFS. But, they don't like the GPL... would SGI > consider using a BSD-style license instead? Juha -- First off, I speak as an individual not associated with SGI in any way. I also speak as a closet BSD advocate. I hope everyone here takes note of the level of proliferation BSD has in the current Internet, and even at Microsoft. Without BSD, our modern Internet would be no where near where it is today -- where BSD runs a number of major archives, sites and key services. And far be it from me or anyone else to being a political discussion on licensing. But at this point of development, I would be interested to note whether or not SGI is the copyright holder of 100% of the current XFS codebase (at least the parts that would be needed to port to BSD). Or if some 3rd party GPL submissions have been made, and their copyrights would need to be consulted before re-releasing as BSD (or any other license). It gets touchy, as with any other GPL project, although it can be accomodated -- by dual licensing "out of the box" as GPL and another (usually commercial, but BSD is an option). [ SIDE NOTE: For an article on what I'm talking about, see my pre-pre-preliminary article on "Dual Licensing GPL" here: http://www.smithconcepts.com/opinion/#tth_sEc1.2 ] So, again, before SGI could even consider releasing under a different license, 100% of the GPL XFS source code used would need to be either under SGI's copyright, or others have signed over their copyrights to SGI. This is the _key_ to dual-licensing (or switching the original license to another after-the-fact). I'm not familiar with SGI's XFS codebase, but I'm sure there was a lot of work to get it to compile for the GNU toolchain and other intricies of Linux and other GNU toolchain OSes (like Linux, BSD, Solaris and a few other, RTOS). Did SGI do all this work? Or was some "early porting" done via GPL by outsiders? And if "dual-licensure" ended up being a copyright option after careful checking, I'm not sure SGI, nor most others, would go for BSD. As I discussed in my article, companies are choosing GPL, LGPL or dual-licensed GPL/commercial for a reason -- they don't want to give "free R&D" to long-time, industry "leeches" like Microsoft and WindRiver. SGI has already choosen GPL, so the only "possible" option I see is a binary-only release for BSD (maybe LGPL?). So, maybe, that is the avenue the BSD team should be taking. Maybe working with SGI under a NDA or some other agreement. Again, it gets mighty complicated -- barring even the political decisions that need to be made. -- TheBS -- Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 SmithConcepts, Inc. http://www.SmithConcepts.com ========================================================== Linux 'Worms' exploit known security holes that were fixed 3-12 months earlier. NT/2000 'Worms' exploit unknown se- curity holes that won't be fixed for another 3-12 months. From owner-linux-xfs@oss.sgi.com Sun Jun 10 19:39:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5B2dCx10312 for linux-xfs-outgoing; Sun, 10 Jun 2001 19:39:12 -0700 Received: from femail2.rdc1.on.home.com (femail2.rdc1.on.home.com [24.2.9.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5B2dBV10309 for ; Sun, 10 Jun 2001 19:39:11 -0700 Received: from digitaltux.com ([24.101.49.82]) by femail2.rdc1.on.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010611023905.FMGF963.femail2.rdc1.on.home.com@digitaltux.com> for ; Sun, 10 Jun 2001 19:39:05 -0700 Received: from localhost ([127.0.0.1] helo=digitaltux.com) by digitaltux.com with smtp (Exim 3.22 #1 (Debian)) id 159Hbb-0000CB-00 for ; Sun, 10 Jun 2001 22:39:03 -0400 Date: Sun, 10 Jun 2001 22:39:00 -0400 From: Zoltan Kraus To: linux-xfs@oss.sgi.com Subject: New Debian XFS Floppies - BETA Message-Id: <20010610223900.47bfa0bf.zoltan@digitaltux.com> X-Mailer: Sylpheed version 0.4.66 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=.1wi5s(cPrG1_Cd" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=.1wi5s(cPrG1_Cd Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I have uploaded new xfs floppies under the BETA directory on my site, I have not tested them, but they include the preliminary code for a menu driven XFS install written by damasta. Someone give them a spin, I'd like to see if they work properly.... http://markybobdeb.sourceforge.net/zoltan/disks/xfs/BETA -- Thanks, - Zoltan Kraus ________ Windows: A 32 bit hack for a 16 bit operating system, originally written for an 8 bit processor on a 4 bit bus by a 2 bit company that can't stand bit of competition! -------- --=.1wi5s(cPrG1_Cd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7JC9Hp0iq+lfR+9YRAln2AJ9VGk0+OkcZUVXpzwm0UdCCp1p63ACfRv05 p1CAof1ckaK11883lYUNDcI= =+CZ7 -----END PGP SIGNATURE----- --=.1wi5s(cPrG1_Cd-- From owner-linux-xfs@oss.sgi.com Sun Jun 10 23:45:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5B6jlq04322 for linux-xfs-outgoing; Sun, 10 Jun 2001 23:45:47 -0700 Received: from ente.berdmann.de (pD9011831.dip.t-dialin.net [217.1.24.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5B6jiV04311 for ; Sun, 10 Jun 2001 23:45:44 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.16 #2) id 159LSD-0003rj-00 for linux-xfs@oss.sgi.com; Mon, 11 Jun 2001 08:45:37 +0200 Message-ID: <3B246910.95E5FE7A@berdmann.de> Date: Mon, 11 Jun 2001 08:45:36 +0200 From: "Bernhard R. Erdmann" Organization: Bernhard Erdmann Communication & Network Solutions X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Linux XFS Mailing List Subject: map_add: Assertion `ino > last_ino_added' failed Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I got this snippet from my nightly backup run: FAILED AND STRANGE DUMP DETAILS: /-- ente /var lev 1 FAILED [/usr/sbin/xfsdump got signal 6] sendbackup: start [ente:/var level 1] sendbackup: info BACKUP=/usr/sbin/xfsdump sendbackup: info RECOVER_CMD=/usr/sbin/xfsrestore -f... - sendbackup: info end | xfsdump: version 3.0 - Running single-threaded | xfsdump: level 1 incremental dump of ente:/var based on level 0 dump begun Sun Jun 10 02:24:35 2001 | xfsdump: dump date: Mon Jun 11 02:12:27 2001 | xfsdump: session id: ccc7ce3b-6c3e-49cb-8d3d-7632f8f51040 | xfsdump: session label: "" | xfsdump: ino map phase 1: skipping (no subtrees specified) | xfsdump: ino map phase 2: constructing initial dump list ? xfsdump: inomap.c:1345: map_add: Assertion `ino > last_ino_added' failed. sendbackup: error [/usr/sbin/xfsdump got signal 6] \-------- What's the meaning of "Assertion `ino > last_ino_added' failed"? From owner-linux-xfs@oss.sgi.com Mon Jun 11 04:49:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BBnEN13248 for linux-xfs-outgoing; Mon, 11 Jun 2001 04:49:14 -0700 Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BBnCV13245 for ; Mon, 11 Jun 2001 04:49:12 -0700 Received: from heppcl.ph.qmw.ac.uk ([138.37.50.187]) by zeta.qmw.ac.uk with esmtp (Exim 3.16 #1) id 159QBy-00056f-00 for linux-xfs@oss.sgi.com; Mon, 11 Jun 2001 12:49:10 +0100 Received: from heppct.ph.qmw.ac.uk (heppct.ph.qmw.ac.uk [138.37.50.246]) by heppcl.ph.qmw.ac.uk (8.9.3/8.9.3) with ESMTP id MAA02587 for ; Mon, 11 Jun 2001 12:49:10 +0100 Received: from localhost (pd@localhost) by heppct.ph.qmw.ac.uk (8.11.2/8.9.3) with ESMTP id f5BBnAP02953 for ; Mon, 11 Jun 2001 12:49:10 +0100 X-Authentication-Warning: heppct.ph.qmw.ac.uk: pd owned process doing -bs Date: Mon, 11 Jun 2001 12:49:10 +0100 (BST) From: "P.Dixon" To: Subject: NFS crash ... xfsdump? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Whilst running xfsdump on our serve, NFS crashed and couldn't be restarted. The output from /var/log/messages is shown below. I've read that ext2dump shouldn't be used with 2.4 kernels - does this apply to xfsdump? Any time I see a NULL pointer being de-referenced, I get worried... I am running kernel-smp-2.4.2-SGI_XFS_1.0 from the Red Hat 7.1 SGI XFS install CD. Cheerio, Paul ------------------------------------------------------------------------------- Paul Dixon Email: P.Dixon@qmw.ac.uk Department of Physics Phone: (020) 7882 5054 Queen Mary, University of London Fax : (020) 7882 5054 Mile End Road, London E1 4NS URL : http://hepwww.ph.qmw.ac.uk/~pd ------------------------------------------------------------------------------- Jun 11 12:12:31 hepserv kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Jun 11 12:12:31 hepserv kernel: printing eip: Jun 11 12:12:31 hepserv kernel: 00000000 Jun 11 12:12:31 hepserv kernel: pgd entry cb13a000: 0000000000000000 Jun 11 12:12:31 hepserv kernel: pmd entry cb13a000: 0000000000000000 Jun 11 12:12:31 hepserv kernel: ... pmd not present! Jun 11 12:12:31 hepserv kernel: Oops: 0000 Jun 11 12:12:31 hepserv kernel: CPU: 1 Jun 11 12:12:31 hepserv kernel: EIP: 0010:[<00000000>] Jun 11 12:12:31 hepserv kernel: EFLAGS: 00010282 Jun 11 12:12:31 hepserv kernel: eax: 00000000 ebx: cc458dc0 ecx: 00000000 edx: c0374620 Jun 11 12:12:31 hepserv kernel: esi: cc458e40 edi: cc458dc0 ebp: cc458dc0 esp: cd941ec4 Jun 11 12:12:31 hepserv kernel: ds: 0018 es: 0018 ss: 0018 Jun 11 12:12:31 hepserv kernel: Process nfsd (pid: 1950, stackpage=cd941000) Jun 11 12:12:31 hepserv kernel: Stack: d0901f74 c9dac060 cc458e40 00000000 05c0f573 d09023f6 cc458dc0 00000000 Jun 11 12:12:31 hepserv kernel: cf9f1214 11270000 cf9f1204 00000001 cf475fe0 cd941f24 ffffff8c 00000000 Jun 11 12:12:31 hepserv kernel: d09027a4 cf475e00 05c0f573 00000004 00000000 00000001 cf9f1204 cf9f1090 Jun 11 12:12:31 hepserv kernel: Call Trace: [scsi_mod:proc_scsi_Rsmp_3c0a4691+958468/127681248] [scsi_mod:proc_scsi_Rsmp_3c0a4691+959622/127680094] [scsi_mod:proc_scsi_Rsmp_3c0a4691+960564/127679152] [scsi_mod:proc_scsi_Rsmp_3c0a4691+986009/127653707] [scsi_mod:proc_scsi_Rsmp_3c0a4691+1021008/127618708] [scsi_mod:proc_scsi_Rsmp_3c0a4691+951891/127687825] [scsi_mod:proc_scsi_Rsmp_3c0a4691+1021008/127618708] Jun 11 12:12:31 hepserv kernel: Call Trace: [] [] [] [] [] [] [] Jun 11 12:12:31 hepserv kernel: [scsi_mod:proc_scsi_Rsmp_3c0a4691+698248/127941468] [scsi_mod:proc_scsi_Rsmp_3c0a4691+1020880/127618836] [scsi_mod:proc_scsi_Rsmp_3c0a4691+1019560/127620156] [scsi_mod:proc_scsi_Rsmp_3c0a4691+951289/127688427] [kernel_thread+35/48] Jun 11 12:12:31 hepserv kernel: [] [] [] [] [] Jun 11 12:12:31 hepserv kernel: Jun 11 12:12:31 hepserv kernel: Code: Bad EIP value. Jun 11 12:13:56 hepserv kernel: xfs_iget_core: ambiguous vns: vp/0xc6734970, invp/0xc58acab0 Jun 11 12:13:56 hepserv kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000008 Jun 11 12:13:56 hepserv kernel: printing eip: Jun 11 12:13:56 hepserv kernel: c01e7892 Jun 11 12:13:56 hepserv kernel: pgd entry c4a51000: 0000000000000000 Jun 11 12:13:56 hepserv kernel: pmd entry c4a51000: 0000000000000000 Jun 11 12:13:56 hepserv kernel: ... pmd not present! Jun 11 12:13:56 hepserv kernel: Oops: 0000 Jun 11 12:13:56 hepserv kernel: CPU: 1 Jun 11 12:13:56 hepserv kernel: EIP: 0010:[vn_revalidate+34/232] Jun 11 12:13:56 hepserv kernel: EIP: 0010:[] Jun 11 12:13:56 hepserv kernel: EFLAGS: 00010282 Jun 11 12:13:56 hepserv kernel: eax: 00000084 ebx: c58acab0 ecx: cf4f3000 edx: 00000000 Jun 11 12:13:56 hepserv kernel: esi: c58acab0 edi: 00000084 ebp: c58acab0 esp: c4a53a24 Jun 11 12:13:56 hepserv kernel: ds: 0018 es: 0018 ss: 0018 Jun 11 12:13:56 hepserv kernel: Process xfsdump (pid: 2319, stackpage=c4a53000) Jun 11 12:13:57 hepserv kernel: Stack: c58acab0 c58acab0 c174eee0 00000001 14003fff 00000000 00000001 cf4f3000 Jun 11 12:13:57 hepserv kernel: 00000000 c6333dbc 00000514 c6333dd4 00000008 00000000 0079bc68 00000000 Jun 11 12:13:57 hepserv kernel: c17ca1cc 00000002 00000000 107afea0 00000000 00000000 00000000 ffffffff Jun 11 12:13:57 hepserv kernel: Call Trace: [xfs_bmbt_get_state+51/60] [xfs_iget_core+1916/1956] [xfs_getattr+64/636] [xfs_vn_iget+52/60] [vn_initialize+213/344] [linvfs_read_inode+30/80] [get_new_inode+227/376] Jun 11 12:13:57 hepserv kernel: Call Trace: [] [] [] [] [] [] [] Jun 11 12:13:57 hepserv kernel: [iget4+221/232] [xfs_open_by_handle+275/796] [xlog_state_clean_log+163/212] [xfs_ioctl+3001/3836] [xlog_state_clean_log+163/212] [xlog_state_clean_log+163/212] [xfs_size_fn+0/20] [_xfs_imap_to_bmap+43/768] Jun 11 12:13:57 hepserv kernel: [] [] [] [] [] [] [] [] Jun 11 12:13:57 hepserv kernel: [xfs_size_fn+0/20] [xfs_bmbt_get_state+51/60] [xfs_bmap_do_search_extents+736/960] [xfs_bmap_search_extents+77/84] [xfs_bmapi+835/4840] [] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-375818/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-535039/96] Jun 11 12:13:57 hepserv kernel: [] [] [] [] [] [] [] [] Jun 11 12:13:57 hepserv kernel: [do_generic_file_read+1606/1620] [generic_file_read+101/128] [xfs_inactive_free_eofblocks+240/720] [xfs_iunlock+67/104] [xfs_inactive_free_eofblocks+257/720] [xfs_release+198/228] [xfs_iunlock+67/104] [xfs_release+218/228] Jun 11 12:13:57 hepserv kernel: [] [] [] [] [] [] [] [] Jun 11 12:13:57 hepserv kernel: [linvfs_ioctl+47/60] [xlog_state_clean_log+163/212] [linvfs_ioctl+0/60] [xlog_state_clean_log+163/212] [sys_ioctl+619/708] [xlog_state_clean_log+163/212] [system_call+51/56] [xlog_state_clean_log+163/212] Jun 11 12:13:57 hepserv kernel: [] [] [] [] [] [] [] [] Jun 11 12:13:57 hepserv kernel: [stext+43/203] Jun 11 12:13:57 hepserv kernel: [] Jun 11 12:13:57 hepserv kernel: Jun 11 12:13:57 hepserv kernel: Code: 8b 4a 08 6a 00 25 80 00 00 00 50 8d 44 24 18 50 52 8b 41 14 Jun 11 12:14:52 hepserv named[1810]: lame server on 'elo-relay.elotecnico.pt' (in 'elotecnico.pt'?): 194.65.3.21#53 Jun 11 12:15:00 hepserv login(pam_unix)[2183]: session opened for user root by LOGIN(uid=0) From owner-linux-xfs@oss.sgi.com Mon Jun 11 04:52:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BBqMx13851 for linux-xfs-outgoing; Mon, 11 Jun 2001 04:52:22 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BBqKV13844 for ; Mon, 11 Jun 2001 04:52:20 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5BBqJq24325 for ; Mon, 11 Jun 2001 13:52:19 +0200 Message-Id: <4.3.2.7.2.20010611134816.03502208@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 13:52:18 +0200 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: CVS tree Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Is anyone experiencing a missing Config.in in the Bluetooth section? Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Jun 11 05:15:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BCFfa16367 for linux-xfs-outgoing; Mon, 11 Jun 2001 05:15:41 -0700 Received: from wlug.westbo.se (IDENT:root@[193.14.164.225]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BCFdV16364 for ; Mon, 11 Jun 2001 05:15:39 -0700 Received: from localhost (gandalf@localhost) by wlug.westbo.se (8.10.0/8.10.0) with ESMTP id f5BCLNE24850; Mon, 11 Jun 2001 14:21:23 +0200 Date: Mon, 11 Jun 2001 14:21:23 +0200 (CEST) From: Martin Josefsson To: "P.Dixon" cc: Subject: Re: NFS crash ... xfsdump? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 11 Jun 2001, P.Dixon wrote: > Hi, > > Whilst running xfsdump on our serve, NFS crashed and couldn't be > restarted. The output from /var/log/messages is shown below. I've read > that ext2dump shouldn't be used with 2.4 kernels - does this apply to > xfsdump? > > Any time I see a NULL pointer being de-referenced, I get worried... > > I am running kernel-smp-2.4.2-SGI_XFS_1.0 from the Red Hat 7.1 SGI XFS > install CD. To mee this looks like a SCSI related Oops. First there's the SCSI one and after one Oops has occured the kernel is left in a very unstable state so anything can crash after that even though there's no bugs in that code. See below. You should really consider a kernelupgrade, a lot has happend with both the main kernel and the XFS code since that release. So I suggest that you checkout the latest version from the CVS and compile that. I think the kernel in CVS is 2.4.6-pre1 or -pre2 with the XFS code. > Jun 11 12:12:31 hepserv kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 > Jun 11 12:12:31 hepserv kernel: printing eip: > Jun 11 12:12:31 hepserv kernel: 00000000 > Jun 11 12:12:31 hepserv kernel: pgd entry cb13a000: 0000000000000000 > Jun 11 12:12:31 hepserv kernel: pmd entry cb13a000: 0000000000000000 > Jun 11 12:12:31 hepserv kernel: ... pmd not present! > Jun 11 12:12:31 hepserv kernel: Oops: 0000 > Jun 11 12:12:31 hepserv kernel: CPU: 1 > Jun 11 12:12:31 hepserv kernel: EIP: 0010:[<00000000>] > Jun 11 12:12:31 hepserv kernel: EFLAGS: 00010282 > Jun 11 12:12:31 hepserv kernel: eax: 00000000 ebx: cc458dc0 ecx: 00000000 edx: c0374620 > Jun 11 12:12:31 hepserv kernel: esi: cc458e40 edi: cc458dc0 ebp: cc458dc0 esp: cd941ec4 > Jun 11 12:12:31 hepserv kernel: ds: 0018 es: 0018 ss: 0018 > Jun 11 12:12:31 hepserv kernel: Process nfsd (pid: 1950, stackpage=cd941000) > Jun 11 12:12:31 hepserv kernel: Stack: d0901f74 c9dac060 cc458e40 00000000 05c0f573 d09023f6 cc458dc0 00000000 > Jun 11 12:12:31 hepserv kernel: cf9f1214 11270000 cf9f1204 00000001 cf475fe0 cd941f24 ffffff8c 00000000 > Jun 11 12:12:31 hepserv kernel: d09027a4 cf475e00 05c0f573 00000004 00000000 00000001 cf9f1204 cf9f1090 > Jun 11 12:12:31 hepserv kernel: Call Trace: [scsi_mod:proc_scsi_Rsmp_3c0a4691+958468/127681248] [scsi_mod:proc_scsi_Rsmp_3c0a4691+959622/127680094] [scsi_mod:proc_scsi_Rsmp_3c0a4691+960564/127679152] > [scsi_mod:proc_scsi_Rsmp_3c0a4691+986009/127653707] [scsi_mod:proc_scsi_Rsmp_3c0a4691+1021008/127618708] [scsi_mod:proc_scsi_Rsmp_3c0a4691+951891/127687825] [scsi_mod:proc_scsi_Rsmp_3c0a4691+1021008/127618708] > Jun 11 12:12:31 hepserv kernel: Call Trace: [] [] [] [] [] [] [] > Jun 11 12:12:31 hepserv kernel: [scsi_mod:proc_scsi_Rsmp_3c0a4691+698248/127941468] [scsi_mod:proc_scsi_Rsmp_3c0a4691+1020880/127618836] [scsi_mod:proc_scsi_Rsmp_3c0a4691+1019560/127620156] [scsi_mod:proc_scsi_Rsmp_3c0a4691+951289/127688427] > [kernel_thread+35/48] > Jun 11 12:12:31 hepserv kernel: [] [] [] [] [] > Jun 11 12:12:31 hepserv kernel: > Jun 11 12:12:31 hepserv kernel: Code: Bad EIP value. Here's the SCSI one. Now the kernel is in a very unstable state, this may corrupt other things in the kernel and the SCSI subsystem is probably not working anymore. > Jun 11 12:13:56 hepserv kernel: xfs_iget_core: ambiguous vns: vp/0xc6734970, invp/0xc58acab0 > Jun 11 12:13:56 hepserv kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000008 > Jun 11 12:13:56 hepserv kernel: printing eip: > Jun 11 12:13:56 hepserv kernel: c01e7892 > Jun 11 12:13:56 hepserv kernel: pgd entry c4a51000: 0000000000000000 > Jun 11 12:13:56 hepserv kernel: pmd entry c4a51000: 0000000000000000 > Jun 11 12:13:56 hepserv kernel: ... pmd not present! > Jun 11 12:13:56 hepserv kernel: Oops: 0000 > Jun 11 12:13:56 hepserv kernel: CPU: 1 > Jun 11 12:13:56 hepserv kernel: EIP: 0010:[vn_revalidate+34/232] > Jun 11 12:13:56 hepserv kernel: EIP: 0010:[] > Jun 11 12:13:56 hepserv kernel: EFLAGS: 00010282 > Jun 11 12:13:56 hepserv kernel: eax: 00000084 ebx: c58acab0 ecx: cf4f3000 edx: 00000000 > Jun 11 12:13:56 hepserv kernel: esi: c58acab0 edi: 00000084 ebp: c58acab0 esp: c4a53a24 > Jun 11 12:13:56 hepserv kernel: ds: 0018 es: 0018 ss: 0018 > Jun 11 12:13:56 hepserv kernel: Process xfsdump (pid: 2319, stackpage=c4a53000) > Jun 11 12:13:57 hepserv kernel: Stack: c58acab0 c58acab0 c174eee0 00000001 14003fff 00000000 00000001 cf4f3000 > Jun 11 12:13:57 hepserv kernel: 00000000 c6333dbc 00000514 c6333dd4 00000008 00000000 0079bc68 00000000 > Jun 11 12:13:57 hepserv kernel: c17ca1cc 00000002 00000000 107afea0 00000000 00000000 00000000 ffffffff > Jun 11 12:13:57 hepserv kernel: Call Trace: [xfs_bmbt_get_state+51/60] [xfs_iget_core+1916/1956] [xfs_getattr+64/636] [xfs_vn_iget+52/60] [vn_initialize+213/344] [linvfs_read_inode+30/80] [get_new_inode+227/376] > Jun 11 12:13:57 hepserv kernel: Call Trace: [] [] [] [] [] [] [] > Jun 11 12:13:57 hepserv kernel: [iget4+221/232] [xfs_open_by_handle+275/796] [xlog_state_clean_log+163/212] [xfs_ioctl+3001/3836] [xlog_state_clean_log+163/212] [xlog_state_clean_log+163/212] [xfs_size_fn+0/20] [_xfs_imap_to_bmap+43/768] > Jun 11 12:13:57 hepserv kernel: [] [] [] [] [] [] [] [] > Jun 11 12:13:57 hepserv kernel: [xfs_size_fn+0/20] [xfs_bmbt_get_state+51/60] [xfs_bmap_do_search_extents+736/960] [xfs_bmap_search_extents+77/84] [xfs_bmapi+835/4840] [] > [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-375818/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-535039/96] > Jun 11 12:13:57 hepserv kernel: [] [] [] [] [] [] [] [] > Jun 11 12:13:57 hepserv kernel: [do_generic_file_read+1606/1620] [generic_file_read+101/128] [xfs_inactive_free_eofblocks+240/720] [xfs_iunlock+67/104] [xfs_inactive_free_eofblocks+257/720] [xfs_release+198/228] [xfs_iunlock+67/104] > [xfs_release+218/228] Jun 11 12:13:57 hepserv kernel: [] [] [] [] [] [] [] [] > Jun 11 12:13:57 hepserv kernel: [linvfs_ioctl+47/60] [xlog_state_clean_log+163/212] [linvfs_ioctl+0/60] [xlog_state_clean_log+163/212] [sys_ioctl+619/708] [xlog_state_clean_log+163/212] [system_call+51/56] [xlog_state_clean_log+163/212] > Jun 11 12:13:57 hepserv kernel: [] [] [] [] [] [] [] [] > Jun 11 12:13:57 hepserv kernel: [stext+43/203] > Jun 11 12:13:57 hepserv kernel: [] > Jun 11 12:13:57 hepserv kernel: > Jun 11 12:13:57 hepserv kernel: Code: 8b 4a 08 6a 00 25 80 00 00 00 50 8d 44 24 18 50 52 8b 41 14 And here XFS blows up, probably because of the first Oops that left the kernel in a unstable state. > Jun 11 12:14:52 hepserv named[1810]: lame server on 'elo-relay.elotecnico.pt' (in 'elotecnico.pt'?): 194.65.3.21#53 > Jun 11 12:15:00 hepserv login(pam_unix)[2183]: session opened for user root by LOGIN(uid=0) > > /Martin -- Linux hackers are funny people: They count the time in patchlevels. From owner-linux-xfs@oss.sgi.com Mon Jun 11 05:17:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BCHs016635 for linux-xfs-outgoing; Mon, 11 Jun 2001 05:17:54 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BCHrV16632 for ; Mon, 11 Jun 2001 05:17:53 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5BCHmq24435; Mon, 11 Jun 2001 14:17:50 +0200 Message-Id: <4.3.2.7.2.20010611141456.0335b9f0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 14:17:47 +0200 To: "P.Dixon" , From: Seth Mos Subject: Re: NFS crash ... xfsdump? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:49 11-6-2001 +0100, P.Dixon wrote: >Hi, > >Whilst running xfsdump on our serve, NFS crashed and couldn't be >restarted. The output from /var/log/messages is shown below. I've read >that ext2dump shouldn't be used with 2.4 kernels - does this apply to >xfsdump? > >Any time I see a NULL pointer being de-referenced, I get worried... > >I am running kernel-smp-2.4.2-SGI_XFS_1.0 from the Red Hat 7.1 SGI XFS >install CD. I recommend getting the 2.4.5 or 2.4.6pre1 patch from the oss.sgi.com FTP server and rebuilding your linux kernel. I don't know if CVS is a 100 Percent a the moment. There have been fixes in the development tree for dumping on a active system and NFS. If you can reproduce it using a more up to date tree we would be most grateful. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Jun 11 07:14:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BEExB26123 for linux-xfs-outgoing; Mon, 11 Jun 2001 07:14:59 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BEEvV26116 for ; Mon, 11 Jun 2001 07:14:57 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA00744 for ; Mon, 11 Jun 2001 07:14:56 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2119054; Mon, 11 Jun 2001 09:13:39 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA22237; Mon, 11 Jun 2001 09:13:39 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5BEHCm07761; Mon, 11 Jun 2001 09:17:13 -0500 Message-Id: <200106111417.f5BEHCm07761@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "P.Dixon" , linux-xfs@oss.sgi.com Subject: Re: NFS crash ... xfsdump? In-Reply-To: Message from Seth Mos of "Mon, 11 Jun 2001 14:17:47 +0200." <4.3.2.7.2.20010611141456.0335b9f0@pop.xs4all.nl> Date: Mon, 11 Jun 2001 09:17:12 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth is correct, this problem is fixed in later kernels, you can use the cvs tree - which I admit does have other problems right now on highmem systems, or you can wait a little bit and I will update the patches on the ftp site in /projects/xfs/download/patches - the code which is there now does not contain the final version of the fix (and I need to go through a few hoops to create a new patch at this os level). Steve > At 12:49 11-6-2001 +0100, P.Dixon wrote: > >Hi, > > > >Whilst running xfsdump on our serve, NFS crashed and couldn't be > >restarted. The output from /var/log/messages is shown below. I've read > >that ext2dump shouldn't be used with 2.4 kernels - does this apply to > >xfsdump? > > > >Any time I see a NULL pointer being de-referenced, I get worried... > > > >I am running kernel-smp-2.4.2-SGI_XFS_1.0 from the Red Hat 7.1 SGI XFS > >install CD. > > I recommend getting the 2.4.5 or 2.4.6pre1 patch from the oss.sgi.com FTP > server and rebuilding your linux kernel. I don't know if CVS is a 100 > Percent a the moment. > > There have been fixes in the development tree for dumping on a active > system and NFS. > > If you can reproduce it using a more up to date tree we would be most gratefu > l. > > Cheers > > -- > Seth From owner-linux-xfs@oss.sgi.com Mon Jun 11 07:16:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BEGde26385 for linux-xfs-outgoing; Mon, 11 Jun 2001 07:16:39 -0700 Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BEGdV26382 for ; Mon, 11 Jun 2001 07:16:39 -0700 Received: from heppcl.ph.qmw.ac.uk ([138.37.50.187]) by zeta.qmw.ac.uk with esmtp (Exim 3.16 #1) id 159SUU-0006eL-00; Mon, 11 Jun 2001 15:16:26 +0100 Received: from heppct.ph.qmw.ac.uk (heppct.ph.qmw.ac.uk [138.37.50.246]) by heppcl.ph.qmw.ac.uk (8.9.3/8.9.3) with ESMTP id PAA04283; Mon, 11 Jun 2001 15:16:26 +0100 Received: from localhost (pd@localhost) by heppct.ph.qmw.ac.uk (8.11.2/8.9.3) with ESMTP id f5BEGNc06246; Mon, 11 Jun 2001 15:16:23 +0100 X-Authentication-Warning: heppct.ph.qmw.ac.uk: pd owned process doing -bs Date: Mon, 11 Jun 2001 15:16:23 +0100 (BST) From: "P.Dixon" To: Steve Lord cc: Subject: Re: NFS crash ... xfsdump? In-Reply-To: <200106111417.f5BEHCm07761@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I think waiting a little bit is the sensible and least worrysome fo me. Cheers, Paul > > Seth is correct, this problem is fixed in later kernels, you can use the cvs > tree - which I admit does have other problems right now on highmem systems, > or you can wait a little bit and I will update the patches on the ftp > site in /projects/xfs/download/patches - the code which is there now does > not contain the final version of the fix (and I need to go through a few > hoops to create a new patch at this os level). > > Steve > From owner-linux-xfs@oss.sgi.com Mon Jun 11 07:22:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BEMV027414 for linux-xfs-outgoing; Mon, 11 Jun 2001 07:22:31 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BEMVV27410 for ; Mon, 11 Jun 2001 07:22:31 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA24483 for ; Mon, 11 Jun 2001 07:22:28 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2122315; Mon, 11 Jun 2001 09:21:13 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA96404; Mon, 11 Jun 2001 09:21:13 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5BEOku07811; Mon, 11 Jun 2001 09:24:46 -0500 Message-Id: <200106111424.f5BEOku07811@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Seth Mos cc: linux-xfs@oss.sgi.com Subject: Re: CVS tree In-Reply-To: Message from Seth Mos of "Mon, 11 Jun 2001 13:52:18 +0200." <4.3.2.7.2.20010611134816.03502208@pop.xs4all.nl> Date: Mon, 11 Jun 2001 09:24:46 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi, > > Is anyone experiencing a missing Config.in in the Bluetooth section? Is this still the case - there is a Config.in in the internal source tree and it shows up in the cvsweb tree on oss, so I think the problem is somewhere between oss and you. Steve > > Cheers > -- > Seth From owner-linux-xfs@oss.sgi.com Mon Jun 11 08:01:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BF1vb01709 for linux-xfs-outgoing; Mon, 11 Jun 2001 08:01:57 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BF1uV01702 for ; Mon, 11 Jun 2001 08:01:56 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA05652 for ; Mon, 11 Jun 2001 08:02:11 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2115507; Mon, 11 Jun 2001 10:00:17 -0500 (CDT) Received: from sgi.com (eagdhcp-195-16.americas.sgi.com [128.162.195.186]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA50246; Mon, 11 Jun 2001 10:00:16 -0500 (CDT) Message-ID: <3B24DC69.15CBB564@sgi.com> Date: Mon, 11 Jun 2001 09:57:45 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Milutin Kitic CC: linux-xfs@oss.sgi.com Subject: Re: bad blocks References: <200106102048.f5AKm3w05931@smtp.eunet.yu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Milutin Kitic wrote: > I have recently found some bad blocks on one of my hdd-s... > On Irix i use 'fx' utility to mark them. On Linux, is there > something similar? I have xfs on this disk. There is nothing built into XFS for marking or avoiding bad blocks. There was a thread about this earlier, you might check out the archives. I think the summary is: Modern hard drives have internal "housekeeping" to transparently move data away from bad blocks as they appear. By the time the _user_ actually starts seeing bad blocks, this means that the drive can no longer cope with the failures, and it's probably a short trip to the trash. Look for the "ucsc-smartsuite" utility to monitor drive health (via the S.M.A.R.T. protocol), so you can replace your drives before they fall apart. :) HTH, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Jun 11 08:20:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BFKZ704152 for linux-xfs-outgoing; Mon, 11 Jun 2001 08:20:35 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BFKYV04148 for ; Mon, 11 Jun 2001 08:20:34 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA05188 for ; Mon, 11 Jun 2001 08:20:27 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2123213 for ; Mon, 11 Jun 2001 10:19:11 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA48635 for ; Mon, 11 Jun 2001 10:19:10 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5BFMih08207; Mon, 11 Jun 2001 10:22:44 -0500 Message-Id: <200106111522.f5BFMih08207@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com Subject: Revised patches on xfs ftp site Date: Mon, 11 Jun 2001 10:22:44 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I just updated the 2.4.5 patches on the oss ftp site, projects/xfs/download/patches The new kernel patches are upto date with the development tree as far as xfs fixes goes, In particular the nfs permissions problem fix is now in the patches. They do not have the most recent changes which are in the cvs tree, but those appear to have some issues. Steve From owner-linux-xfs@oss.sgi.com Mon Jun 11 08:37:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BFbFe06443 for linux-xfs-outgoing; Mon, 11 Jun 2001 08:37:15 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BFbCV06427 for ; Mon, 11 Jun 2001 08:37:12 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f5BFbAaJ067648; Mon, 11 Jun 2001 10:37:11 -0500 (CDT) Message-ID: <3B24E5A1.7404BFBA@thebarn.com> Date: Mon, 11 Jun 2001 10:37:05 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Juha Saarinen CC: linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juha Saarinen wrote: > I've noticed that there's some interest from the FreeBSD crowd in XFS. > But, they don't like the GPL... would SGI consider using a BSD-style > license instead? I explored this as one point and got nowhere with it. There are two problems One finding a license that the BSD folks can live with and at the same time prevent SGI's competitors from shipping XFS with their systems (ie SUN). Two finding anybody in SGI management that actually wants XFS on BSD to happen and thus willing to commit resources to writing a "dual" licensee. I have also talked with the BSD folks a bit and from a non commercial stand point there is no reason why XFS cannot live on the free BSDs as an independent GPL'ed entity, ie loadable kernel module. -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Mon Jun 11 08:42:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BFg0S07314 for linux-xfs-outgoing; Mon, 11 Jun 2001 08:42:00 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BFfxV07305 for ; Mon, 11 Jun 2001 08:41:59 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f5BFfvaJ067685; Mon, 11 Jun 2001 10:41:57 -0500 (CDT) Message-ID: <3B24E6C0.E3855EAE@thebarn.com> Date: Mon, 11 Jun 2001 10:41:52 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Tom Duffy CC: Juha Saarinen , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp References: <3B241B89.9247E5BC@engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Tom Duffy wrote: > Juha Saarinen wrote: > > > > I've noticed that there's some interest from the FreeBSD crowd in XFS. > > But, they don't like the GPL... would SGI consider using a BSD-style > > license instead? > > IANAL, nor do I represent SGI in any official capacity, but I don't > think SGI would be very interested in doing this. We (SGI) released XFS > to help make Linux a high class OS because we want to sell Linux on our > boxen and want a commodity OS. > > But, if we could convince the powers that be, it may be possible to > release the code under a dual license, but then changes coming back > would be tricky to reincorporate. I highly doubt we will not stop the > GPL release of XFS because this would hinder the code from going into > the mainline kernel. note there is several examples of non GPL'ed / dual licensed code in the kernel ... the new adaptec drivers for example. > > > We already have a sticky situation when external people submit core xfs > patches back to us if we want to put that code into IRIX. What I think > the plana of action is to ask each patch maintainer if they would be > willing to sign away their copyright to SGI so the code can be stuck > into IRIX...I don't think this has come up yet since most of the major > development has taken place in house or from SGI contractors. Yup no major code contributions have been made outside of the linux side of XFS. > > > -tduffy -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Mon Jun 11 08:47:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BFlaT08156 for linux-xfs-outgoing; Mon, 11 Jun 2001 08:47:36 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BFlZV08153 for ; Mon, 11 Jun 2001 08:47:35 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA02130 for ; Mon, 11 Jun 2001 08:47:55 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2122982; Mon, 11 Jun 2001 10:46:19 -0500 (CDT) Received: from sgi.com (eagdhcp-195-16.americas.sgi.com [128.162.195.186]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA53584; Mon, 11 Jun 2001 10:46:18 -0500 (CDT) Message-ID: <3B24E732.D3A3C8A6@sgi.com> Date: Mon, 11 Jun 2001 10:43:47 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Russell Cattelan CC: Juha Saarinen , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp References: <3B24E5A1.7404BFBA@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Russell Cattelan wrote: > Two finding anybody in SGI management that actually wants > XFS on BSD to happen and thus willing to commit resources to > writing a "dual" licensee. Remember that one of the most time-consuming, difficult parts of this project early on was handling the "lawyer issues" - I saw one slide that said a couple lawyers quit in the process.... :) Tackling that all over again would probably not be a high priority. Also, you have to think about "what would SGI gain from a BSD port?" - what would justify the extra expense for the company? XFS for Linux is a strategic move for SGI, it's not a purely altruistic project. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Jun 11 09:13:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BGD3910686 for linux-xfs-outgoing; Mon, 11 Jun 2001 09:13:03 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BGD1V10683 for ; Mon, 11 Jun 2001 09:13:01 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f5BGCwaJ067811; Mon, 11 Jun 2001 11:12:58 -0500 (CDT) Message-ID: <3B24EE05.F7E46B6C@thebarn.com> Date: Mon, 11 Jun 2001 11:12:53 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Juha Saarinen , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp References: <3B24E5A1.7404BFBA@thebarn.com> <3B24E732.D3A3C8A6@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > Russell Cattelan wrote: > > > Two finding anybody in SGI management that actually wants > > XFS on BSD to happen and thus willing to commit resources to > > writing a "dual" licensee. > > Remember that one of the most time-consuming, difficult parts of this > project early on was handling the "lawyer issues" - I saw one slide that > said a couple lawyers quit in the process.... :) Tackling that all over > again would probably not be a high priority. Actually that had to do with the de-encumbering process, i.e. trying to figure out which pieces of code might be bound up with license agreements SGI signed at one point. Since that part is already done the issue is mostly the wording of a new license. > > > Also, you have to think about "what would SGI gain from a BSD port?" - > what would justify the extra expense for the company? XFS for Linux is > a strategic move for SGI, it's not a purely altruistic project. :) It wasn't an issue of gain or not gain for SGI but a sense of what could be lost: XFS on solaris seems to be the biggest fear. SGI is not against XFS on BSD and they would be willing to find that happy license medium if somebody from the BSD community would actually do the most of the work to write a license that would fit with BSD but not allow an open free for all in the commercial area. > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Mon Jun 11 09:21:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BGLEV11188 for linux-xfs-outgoing; Mon, 11 Jun 2001 09:21:14 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BGLCV11185 for ; Mon, 11 Jun 2001 09:21:12 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id SAA1985009 for ; Mon, 11 Jun 2001 18:21:10 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA2122537; Mon, 11 Jun 2001 11:19:53 -0500 (CDT) Received: from sgi.com (eagdhcp-195-16.americas.sgi.com [128.162.195.186]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA53884; Mon, 11 Jun 2001 11:19:52 -0500 (CDT) Message-ID: <3B24EF10.8A221BA4@sgi.com> Date: Mon, 11 Jun 2001 11:17:20 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Russell Cattelan CC: Juha Saarinen , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp References: <3B24E5A1.7404BFBA@thebarn.com> <3B24E732.D3A3C8A6@sgi.com> <3B24EE05.F7E46B6C@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Russell Cattelan wrote: > Actually that had to do with the de-encumbering process, i.e. trying > to figure out which pieces of code might be bound up with license > agreements > SGI signed at one point. > Since that part is already done the issue is mostly the wording of a new > license. Sure, but there would almost certainly be more money spent on many lawyer-hours to determine whether that new license was acceptable... I did not mean that SGI would be against XFS on BSD, it's just that it would likely cost a fair amount of money and time to do it, and there would be risks involved, and you have to find a motivation to do it. Perhaps goodwill would be enough, but it might be hard to justify. Ok, I'm done with the licensing discussion on-list, these things can go on forever. I have trees to merge. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Jun 11 10:08:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BH8KS12287 for linux-xfs-outgoing; Mon, 11 Jun 2001 10:08:20 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BH8JV12284 for ; Mon, 11 Jun 2001 10:08:19 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA05435 for ; Mon, 11 Jun 2001 10:08:17 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2124947 for ; Mon, 11 Jun 2001 12:06:58 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA43513 for ; Mon, 11 Jun 2001 12:06:58 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f5BHAUY14461; Mon, 11 Jun 2001 12:10:30 -0500 Message-Id: <200106111710.f5BHAUY14461@jen.americas.sgi.com> Date: Mon, 11 Jun 2001 12:10:30 -0500 Subject: TAKE - fix direct I/O with egcs-2.91.66 compiler Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk A new statement was inserted into a function next to some block address calculation code. The end result when using the egcs-2.91.66 compiler was killer code which took the system out very quickly. I had been testing with the redhat 7.1 compiler recently which does not exhibit this problem. Rather scary how sensitive some of this stuff is. Date: Mon Jun 11 10:03:36 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-base The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:96663a linux/fs/pagebuf/page_buf_io.c - 1.82 - reorder code to work around compiler bug! From owner-linux-xfs@oss.sgi.com Mon Jun 11 10:11:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BHBCq12405 for linux-xfs-outgoing; Mon, 11 Jun 2001 10:11:12 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BHBBV12402 for ; Mon, 11 Jun 2001 10:11:11 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA06684 for ; Mon, 11 Jun 2001 10:11:03 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2123705; Mon, 11 Jun 2001 12:09:24 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA04018; Mon, 11 Jun 2001 12:09:24 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5BHCuq14477; Mon, 11 Jun 2001 12:12:56 -0500 Message-Id: <200106111712.f5BHCuq14477@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Chris Pascoe cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - delalloc buffer and page handling cleanup In-Reply-To: Message from Chris Pascoe of "Sun, 10 Jun 2001 14:07:00 +1000." Date: Mon, 11 Jun 2001 12:12:56 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi Steve, > > I get a repeatable crash immediately on 017 with these changes. Same > machine as before (1GB/Dual P3-Xeon), just a slightly different partiton > layout. Was I supposed to avoid test 017 too? > > Traces / disasm attached. Going to recompile w/o highmem now, will let > you know if it fails. Hmm, same thing happens, and same w/o highmem on > non-SMP. > > Chris This is a compiler bug! Not exactly sure what, but I can build a working kernel with one compiler and a failing one with another compiler. gcc 2.96 works and egcs-2.91.66 does - for this case. I have reordered the code and it all appears to work now. Steve From owner-linux-xfs@oss.sgi.com Mon Jun 11 10:23:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BHNnX12770 for linux-xfs-outgoing; Mon, 11 Jun 2001 10:23:49 -0700 Received: from vulcain.knox.com (knox-gw.knox-software.easynet.fr [212.180.90.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BHNmV12767 for ; Mon, 11 Jun 2001 10:23:48 -0700 Received: by arkeia.com via sendmail from stdin id (Debian Smail3.2.0.111) for linux-xfs@oss.sgi.com; Mon, 11 Jun 2001 19:25:59 +0200 (CEST) Date: Mon, 11 Jun 2001 19:25:59 +0200 From: Andre Majorel To: linux-xfs@oss.sgi.com Subject: ACL documentation Message-ID: <20010611192559.A882@aym4> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello all. Is there any documentation that explains in details how XFS ACL work ? I've read acl(4) (or acl(5) as it's named in the Linux port) but it leaves too many things unsaid. For instance, - what is the mask field for ? - exactly how do chmod and chacl interfere with each other ? - after chacl, the perms look like ---abc--- where abc is the value of the mask. What is that supposed to mean ? - exactly who has what rights w.r.t. ACLs ? Thanks in advance. -- André Majorel Work: Home: http://www.teaser.fr/~amajorel/ From owner-linux-xfs@oss.sgi.com Mon Jun 11 10:33:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BHXsw13062 for linux-xfs-outgoing; Mon, 11 Jun 2001 10:33:54 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BHXrV13059 for ; Mon, 11 Jun 2001 10:33:53 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA24650 for ; Mon, 11 Jun 2001 10:33:49 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2125590; Mon, 11 Jun 2001 12:32:34 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA87461; Mon, 11 Jun 2001 12:32:34 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5BHa6U16367; Mon, 11 Jun 2001 12:36:06 -0500 Message-Id: <200106111736.f5BHa6U16367@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andre Majorel cc: linux-xfs@oss.sgi.com Subject: Re: ACL documentation In-Reply-To: Message from Andre Majorel of "Mon, 11 Jun 2001 19:25:59 +0200." <20010611192559.A882@aym4> Content-Transfer-Encoding: 8bit Date: Mon, 11 Jun 2001 12:36:06 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just an FYI, the folks who work on the ACL code are in Australia, I tend to ignore these questions and leave them to the folks in Melbourne. This of course means it can take a while to get an answer to acl questions. Steve > Hello all. > > Is there any documentation that explains in details how XFS ACL > work ? I've read acl(4) (or acl(5) as it's named in the Linux > port) but it leaves too many things unsaid. > > For instance, > - what is the mask field for ? > - exactly how do chmod and chacl interfere with each other ? > - after chacl, the perms look like ---abc--- where abc is the > value of the mask. What is that supposed to mean ? > - exactly who has what rights w.r.t. ACLs ? > > Thanks in advance. > > -- > Andri Majorel > Work: > Home: http://www.teaser.fr/~amajorel/ From owner-linux-xfs@oss.sgi.com Mon Jun 11 10:39:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BHdFl13343 for linux-xfs-outgoing; Mon, 11 Jun 2001 10:39:15 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BHdCV13338 for ; Mon, 11 Jun 2001 10:39:12 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA03787 for ; Mon, 11 Jun 2001 10:39:29 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2120957; Mon, 11 Jun 2001 12:37:47 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA39436; Mon, 11 Jun 2001 12:37:47 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5BHfJa16405; Mon, 11 Jun 2001 12:41:19 -0500 Message-Id: <200106111741.f5BHfJa16405@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Sebastian Dransfeld cc: linux-xfs@oss.sgi.com Subject: Re: chacl In-Reply-To: Message from Sebastian Dransfeld of "Sat, 09 Jun 2001 09:45:53 +0200." Date: Mon, 11 Jun 2001 12:41:19 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > --- chacl.c.old Sat Jun 9 09:45:14 2001 > +++ chacl.c Sat Jun 9 09:44:04 2001 > @@ -175,7 +175,7 @@ > /* directory default acl */ > if (bflag || dflag) { > dacl = acl_from_text (argv[optind]); > - if (dacl == NULL || acl_valid(acl) == -1) > + if (dacl == NULL || acl_valid(dacl) == -1) > { > fprintf (stderr, inv_acl, program, argv[optind]); > return (1); > > This does seem to be a correct fix. Thanks Steve From owner-linux-xfs@oss.sgi.com Mon Jun 11 10:46:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BHkNW13546 for linux-xfs-outgoing; Mon, 11 Jun 2001 10:46:23 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BHkLV13543 for ; Mon, 11 Jun 2001 10:46:21 -0700 Received: from auto-nb1.xs4all.nl (perle-wan2.coltex.nl [10.0.1.178]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5BHk8V01593; Mon, 11 Jun 2001 19:46:08 +0200 Message-Id: <4.3.2.7.2.20010611194235.039f8320@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 19:46:06 +0200 To: Steve Lord , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: TAKE - fix direct I/O with egcs-2.91.66 compiler In-Reply-To: <200106111710.f5BHAUY14461@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:10 11-6-2001 -0500, Steve Lord wrote: >A new statement was inserted into a function next to some block address >calculation code. The end result when using the egcs-2.91.66 compiler >was killer code which took the system out very quickly. I had been >testing with the redhat 7.1 compiler recently which does not exhibit >this problem. How about running the code through the Stanford Vailidity Checker (SVC). It is build to seek out improper construct. It won't help you avoid compiler bugs but it will help you finding bad code in the tree. It won't fix them automatically. I can't get it to compile on the moment, not sure what I am doing wrong. Might be interesting. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Jun 11 10:53:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BHriH13889 for linux-xfs-outgoing; Mon, 11 Jun 2001 10:53:44 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BHrfV13884 for ; Mon, 11 Jun 2001 10:53:42 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA1997453 for ; Mon, 11 Jun 2001 19:53:39 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2122637; Mon, 11 Jun 2001 12:52:23 -0500 (CDT) Received: from sgi.com (eagdhcp-195-16.americas.sgi.com [128.162.195.186]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA60280; Mon, 11 Jun 2001 12:52:23 -0500 (CDT) Message-ID: <3B2504BE.3813E544@sgi.com> Date: Mon, 11 Jun 2001 12:49:50 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: TAKE - fix direct I/O with egcs-2.91.66 compiler References: <4.3.2.7.2.20010611194235.039f8320@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > How about running the code through the Stanford Vailidity Checker (SVC). > It is build to seek out improper construct. It won't help you avoid > compiler bugs but it will help you finding bad code in the tree. It won't > fix them automatically. I actually was talking with Dawson about this a while ago, and he seemed interested. We still owe him comprehensive xfs-specific "rules" to check, though, something that only a few people can probably put together (steve, ananth... not me yet.). I was hoping he'd run it through the standard kernel checks, but haven't heard from him. I'll ping him again... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Jun 11 11:11:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BIBnN15602 for linux-xfs-outgoing; Mon, 11 Jun 2001 11:11:49 -0700 Received: from mailout03.sul.t-online.de (mailout03.sul.t-online.com [194.25.134.81]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BIBkV15587 for ; Mon, 11 Jun 2001 11:11:46 -0700 Received: from fwd00.sul.t-online.de by mailout03.sul.t-online.de with smtp id 159WA9-0001Ul-01; Mon, 11 Jun 2001 20:11:41 +0200 Received: from t-online.de (340024412816-0001@[217.81.140.216]) by fwd00.sul.t-online.com with esmtp id 159W9w-0yOQyGC; Mon, 11 Jun 2001 20:11:28 +0200 Message-ID: <3B2509D9.EF1A48AF@t-online.de> Date: Mon, 11 Jun 2001 20:11:37 +0200 From: Hasch@t-online.de (Juergen Hasch) X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 To: Andre Majorel CC: linux-xfs@oss.sgi.com Subject: Re: ACL documentation References: <20010611192559.A882@aym4> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: 340024412816-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Is there any documentation that explains in details how XFS ACL > work ? I've read acl(4) (or acl(5) as it's named in the Linux > port) but it leaves too many things unsaid. > > For instance, > - what is the mask field for ? > - exactly how do chmod and chacl interfere with each other ? > - after chacl, the perms look like ---abc--- where abc is the > value of the mask. What is that supposed to mean ? > - exactly who has what rights w.r.t. ACLs ? take a look at http://acl.bestbits.at/pre and get the posix 1003.1e draft. It should have all the details you are looking for. ...Juergen From owner-linux-xfs@oss.sgi.com Mon Jun 11 11:35:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BIZBN19588 for linux-xfs-outgoing; Mon, 11 Jun 2001 11:35:11 -0700 Received: from babel.spoiled.org (babel.spoiled.org [212.84.234.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BIZ8V19570 for ; Mon, 11 Jun 2001 11:35:08 -0700 Received: (qmail 27428 invoked by uid 8); 11 Jun 2001 18:35:06 -0000 From: Juri Haberland Reply-To: Juri Haberland X-Newsgroups: spoiled.linux.sgi.xfs Subject: [OT] Re: XFS/Linux 1.1?? Date: Mon, 11 Jun 2001 18:35:06 +0000 (UTC) Organization: spoiled dot org Lines: 18 Distribution: local Message-ID: References: <5.1.0.14.0.20010610131639.009ece60@sphinx.druber.com> X-Complaints-To: newsmaster@spoiled.org User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (OpenBSD/2.9 (i386)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dan Swartzendruber wrote: > At 12:33 PM 6/10/01 -0400, Bryan J. Smith wrote: >>Dan Swartzendruber wrote: >> >>Well, age old Netscape Communicator does fine for me. > > fine for you. i note you never asked why i need IMAP. if i was able > (or willing) to settle for POP3, there are a myriad of apps i could > use (including the current kmail). Netscape can do IMAP and I use it now for over 2 years on my linux boxes at home and at work. Juri -- Juri Haberland From owner-linux-xfs@oss.sgi.com Mon Jun 11 11:52:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BIqBf22335 for linux-xfs-outgoing; Mon, 11 Jun 2001 11:52:11 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BIq9V22328 for ; Mon, 11 Jun 2001 11:52:09 -0700 Received: from auto-nb1.xs4all.nl (perle-wan2.coltex.nl [10.0.1.178]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5BIq6V01719 for ; Mon, 11 Jun 2001 20:52:06 +0200 Message-Id: <4.3.2.7.2.20010611205143.03b196a8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jun 2001 20:52:05 +0200 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: ACL documentation In-Reply-To: <3B2509D9.EF1A48AF@t-online.de> References: <20010611192559.A882@aym4> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 20:11 11-6-2001 +0200, you wrote: > > Is there any documentation that explains in details how XFS ACL > > work ? I've read acl(4) (or acl(5) as it's named in the Linux > > port) but it leaves too many things unsaid. > > > > For instance, > > - what is the mask field for ? > > - exactly how do chmod and chacl interfere with each other ? > > - after chacl, the perms look like ---abc--- where abc is the > > value of the mask. What is that supposed to mean ? > > - exactly who has what rights w.r.t. ACLs ? > >take a look at http://acl.bestbits.at/pre and get the posix 1003.1e >draft. >It should have all the details you are looking for. > >...Juergen Link added to FAQ. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Jun 11 12:43:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BJh1330620 for linux-xfs-outgoing; Mon, 11 Jun 2001 12:43:01 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BJgwV30617 for ; Mon, 11 Jun 2001 12:42:59 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA04762 for ; Mon, 11 Jun 2001 12:43:18 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2073712; Mon, 11 Jun 2001 14:41:15 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA80670; Mon, 11 Jun 2001 14:41:15 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5BJikk17269; Mon, 11 Jun 2001 14:44:46 -0500 Message-Id: <200106111944.f5BJikk17269@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Krzysztof Rusocki cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.6-pre2 still crashes. In-Reply-To: Message from Krzysztof Rusocki of "Sun, 10 Jun 2001 22:55:24 +0200." <20010610225524.B7211@main.braxis.co.uk> Date: Mon, 11 Jun 2001 14:44:45 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk These backtraces do not tell me very much unfortunately, this might be an issue related to your hardware, it might be worth posting on Linux kernel itself. There are changes in the interrupt handling code which went into 2.4.6-pre2 which may be what has bitten you here. Steve > > Steve, > > Could you please take a look at > http://braxis.co.uk/~kszysiu/xfs/2.4.6-pre2/ > > Kernel was 2.4.6-pre2 dated about 20010609 19:00 CEST (GMT+0200) compiled > with egcs-1.1.2. > Unfortunately i still had no time to get some serial cable so i provide only > backtrace of process that crashed (dammit, i didn't think to let machine > continue after the second crash, lame me...) , hope that it will be > sufficient (rewritten manually :/ )... > > Facing 2.4 generic problems here ? > > Cheers, > Krzysztof From owner-linux-xfs@oss.sgi.com Mon Jun 11 13:51:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BKpK709436 for linux-xfs-outgoing; Mon, 11 Jun 2001 13:51:20 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BKpJV09426 for ; Mon, 11 Jun 2001 13:51:19 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA08015 for ; Mon, 11 Jun 2001 13:50:58 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2126144 for ; Mon, 11 Jun 2001 15:49:36 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA15562 for ; Mon, 11 Jun 2001 15:49:36 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f5BKr7i18057; Mon, 11 Jun 2001 15:53:07 -0500 Message-Id: <200106112053.f5BKr7i18057@jen.americas.sgi.com> Date: Mon, 11 Jun 2001 15:53:07 -0500 Subject: TAKE - fix chacl error checking code Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The wrong acl pointer is used at one point. Date: Mon Jun 11 13:48:59 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:96686a cmd/acl/chacl/chacl.c - 1.5 - When verifying default acl, use the correct pointer. From owner-linux-xfs@oss.sgi.com Mon Jun 11 14:16:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BLGKh13820 for linux-xfs-outgoing; Mon, 11 Jun 2001 14:16:20 -0700 Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BLGJV13817 for ; Mon, 11 Jun 2001 14:16:19 -0700 Received: from eclipse ([65.4.56.167]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010611211607.FQBZ14901.femail12.sdc1.sfba.home.com@eclipse> for ; Mon, 11 Jun 2001 14:16:07 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Micah Yoder To: linux-xfs@oss.sgi.com Subject: Stability of the Red Hat 7.1 + XFS system Date: Mon, 11 Jun 2001 14:17:04 -0400 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01061114170409.01070@eclipse> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I just installed RH 7.1 w/SGI's CD and the kernel on it. The server is co-located, about 400 miles away... I am running a process (slashd of Slashcode) that hung in the "R" state using 99% of a CPU (there are two). That was after it was running well over a day. I can't kill it, even with -9. And every time I try to access the directory of its log file or any file in that directory, the process hangs in the "D" state and I can't kill it. I couldn't reboot using normal methods -- when typing 'reboot', the 'shutdown' process was unkillable in "R" and kept hogging CPU cycles. When I typed '/sbin/init 0' the same happened with a 'umount' process. I had the hosting center reset it. Now they're saying there are filesystem errors on the restart and I can't get to it. They're saying they can't use locate and aren't finding ifconfig in the normal spot. They're looking at it now. Is this XFS's fault? Any ideas on what to do? I noticed that the FAQ said that processes hanging while accessing an FS could be fixed by recompiling with egcs. Was the kernel on SGI's CD compiled with egcs or 2.96? Need help! Thanks, Micah From owner-linux-xfs@oss.sgi.com Mon Jun 11 14:25:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BLPeg15477 for linux-xfs-outgoing; Mon, 11 Jun 2001 14:25:40 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BLPdV15474 for ; Mon, 11 Jun 2001 14:25:39 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA02490 for ; Mon, 11 Jun 2001 14:25:04 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2127565 for ; Mon, 11 Jun 2001 16:23:44 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA31384 for ; Mon, 11 Jun 2001 16:23:44 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f5BLREX19094; Mon, 11 Jun 2001 16:27:14 -0500 Message-Id: <200106112127.f5BLREX19094@jen.americas.sgi.com> Date: Mon, 11 Jun 2001 16:27:14 -0500 Subject: TAKE - yet more delayed buffer intergration with main kernel code Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This smooths the integration of the delayed buffer concept in the main kernel and removes the need for the toss_page address space method. XFS now uses no extra address_space methods. There is a still a hole which is going to affect highmem systems, but I am pretty convinced I could make ext2 hit it as well, write a large file, truncate it on one cpu and run sync on the other. Date: Mon Jun 11 14:21:15 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:96695a linux/mm/filemap.c - 1.76 - remove the call to toss_page - we now use the unmap_buffer call in try_to_free_buffers to clear the delalloc state. linux/kernel/ksyms.c - 1.94 - export block_flushpage as pagebuf calls it now linux/include/linux/fs.h - 1.98 - remove the toss_page method linux/fs/buffer.c - 1.65 - Add the delay flag to the fields unmap_buffer resets, with this we can get rid of the toss_pages address space method. linux/drivers/block/ll_rw_blk.c - 1.68 - Cleanup, use buffer_delay rather than reference BH_Delay directly linux/fs/xfs/linux/xfs_iops.c - 1.108 - remove the toss_page call linux/include/linux/page_buf.h - 1.94 - remove pagebuf_toss_pages prototype linux/fs/pagebuf/page_buf_io.c - 1.83 - Use buffer_delay rather than BH_Delay directly, simplify _unmark_delalloc as there are less cases now, remove pagebuf_toss_page, mark delalloc buffers as mapped so that unmap_buffer clears the state, use the buffer_delay flag instead of the !buffer_mapped test to look for buffers which need conversion. From owner-linux-xfs@oss.sgi.com Mon Jun 11 15:02:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BM2md21801 for linux-xfs-outgoing; Mon, 11 Jun 2001 15:02:48 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BM2lV21796 for ; Mon, 11 Jun 2001 15:02:47 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA00879 for ; Mon, 11 Jun 2001 13:56:15 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2128809 for ; Mon, 11 Jun 2001 15:54:56 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA23786 for ; Mon, 11 Jun 2001 15:54:56 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f5BKwR718218; Mon, 11 Jun 2001 15:58:27 -0500 Message-Id: <200106112058.f5BKwR718218@jen.americas.sgi.com> Date: Mon, 11 Jun 2001 15:58:27 -0500 Subject: TAKE - cleanup pagebuf startup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The pagebuf daemon was started by xfs, now pagebuf starts it directly, less interaction between the two subsystems. Date: Mon Jun 11 13:54:07 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:96689a linux/fs/xfs/linux/xfs_super.c - 1.127 - remove call to start pagebuf daemon, this is done by pagebuf itself now. linux/include/linux/page_buf.h - 1.93 - no need for prototypes for daemon start and stop calls, handled internally now. linux/fs/pagebuf/page_buf.c - 1.85 - Let pagebuf start its own daemon - xfs used to do this. From owner-linux-xfs@oss.sgi.com Mon Jun 11 15:04:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BM4BJ21938 for linux-xfs-outgoing; Mon, 11 Jun 2001 15:04:11 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BM45V21928 for ; Mon, 11 Jun 2001 15:04:05 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 159Zmz-0005wd-00; Tue, 12 Jun 2001 10:04:01 +1200 Date: Tue, 12 Jun 2001 10:04:01 +1200 (NZST) From: Juha Saarinen To: Micah Yoder cc: "linux-xfs@oss.sgi.com" Subject: Re: Stability of the Red Hat 7.1 + XFS system In-Reply-To: <01061114170409.01070@eclipse> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 11 Jun 2001, Micah Yoder wrote: > I just installed RH 7.1 w/SGI's CD and the kernel on it. The server is > co-located, about 400 miles away... Is this the VIA chip set box? Evil stuff... ;-) > Is this XFS's fault? Any ideas on what to do? I noticed that the FAQ said > that processes hanging while accessing an FS could be fixed by recompiling > with egcs. Was the kernel on SGI's CD compiled with egcs or 2.96? Well, I certainly experienced f/s corruption when I compiled with RH's gcc 2.96-81, which went away when I recompiled with 2.91-66. You might be better off using a later XFS kernel from the CVS, but at this stage, I'd still be very leery of putting the f/s on a co-lo box 400 miles away... especially with VIA hardware, which is known to be broken in various ways (refer to Alan Cox, Andre Hedrick and Ingo Molnar's comments on this issue on linux-kernel etc.) -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Mon Jun 11 15:09:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BM9ZJ22171 for linux-xfs-outgoing; Mon, 11 Jun 2001 15:09:35 -0700 Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BM9YV22168 for ; Mon, 11 Jun 2001 15:09:34 -0700 Received: from eclipse ([65.4.56.167]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010611220928.ILBR14901.femail12.sdc1.sfba.home.com@eclipse>; Mon, 11 Jun 2001 15:09:28 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Micah Yoder To: Juha Saarinen Subject: Re: Stability of the Red Hat 7.1 + XFS system Date: Mon, 11 Jun 2001 15:10:25 -0400 X-Mailer: KMail [version 1.2] Cc: "linux-xfs@oss.sgi.com" References: In-Reply-To: MIME-Version: 1.0 Message-Id: <0106111510250C.01070@eclipse> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > I just installed RH 7.1 w/SGI's CD and the kernel on it. The server is > > co-located, about 400 miles away... > > Is this the VIA chip set box? Evil stuff... ;-) It's an Abit VP6 motherboard. I've heard good reports from it, so that *better* not be the problem!!! > Well, I certainly experienced f/s corruption when I compiled with RH's gcc > 2.96-81, which went away when I recompiled with 2.91-66. But what is the kernel shipped on the CD compiled with? That's what I'm using. I know Red Hat uses 2.96 to compile their kernel, so I dunno if SGI did the same. > You might be better off using a later XFS kernel from the CVS, but at this > stage, I'd still be very leery of putting the f/s on a co-lo box 400 miles > away... especially with VIA hardware, which is known to be broken in > various ways (refer to Alan Cox, Andre Hedrick and Ingo Molnar's comments > on this issue on linux-kernel etc.) I think I'm starting to lean toward telling them to install the latest stable Debian with ext2...... :-) From owner-linux-xfs@oss.sgi.com Mon Jun 11 15:21:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BMLtb22818 for linux-xfs-outgoing; Mon, 11 Jun 2001 15:21:55 -0700 Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BMLsV22815 for ; Mon, 11 Jun 2001 15:21:54 -0700 Received: (qmail 24310 invoked by uid 0); 11 Jun 2001 22:21:48 -0000 Received: from adsl-3-30.adsl.easynet.fr (HELO mail.gmx.de) (212.11.27.30) by mail.gmx.net (mail01) with SMTP; 11 Jun 2001 22:21:48 -0000 Message-ID: <200106120020550634.06FDB540@mail.gmx.de> X-Mailer: Calypso Version 3.20.02.00 (4) Date: Tue, 12 Jun 2001 00:20:55 +0200 From: "linux" To: linux-xfs@oss.sgi.com Subject: xfs + samba Content-Type: text/plain; charset="WINDOWS-1250" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I'm a french sys adm. I've installed xfs on my server on / and /home and i'm pretty happy with that (see previous posts) but i'm not sure it the right place but maybe somebody was confronted with this problem. I'm about to make my server a PDC. I can't access file with accentuated characters via samba i can see the files but "file not found" in the samba log however i have in my smb.conf client code page = 850 character set = ISO8859-1 any ideas? thanks for answers or links @++ nico From owner-linux-xfs@oss.sgi.com Mon Jun 11 15:24:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BMOwt22964 for linux-xfs-outgoing; Mon, 11 Jun 2001 15:24:58 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BMOuV22961 for ; Mon, 11 Jun 2001 15:24:56 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 159a78-0005xl-00; Tue, 12 Jun 2001 10:24:50 +1200 Date: Tue, 12 Jun 2001 10:24:50 +1200 (NZST) From: Juha Saarinen To: Micah Yoder cc: "linux-xfs@oss.sgi.com" Subject: Re: Stability of the Red Hat 7.1 + XFS system In-Reply-To: <0106111510250C.01070@eclipse> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 11 Jun 2001, Micah Yoder wrote: > It's an Abit VP6 motherboard. I've heard good reports from it, so that > *better* not be the problem!!! Well, check the Linux mailing lists -- reading those, and having battled with a Tyan Tiger 133 for ages now, I would be extremely hesistant depend on anything with a VIA chip set onboard. I'm sure that they'll get it right at some point, but at the moment, stability and reliability still seems to equal Intel, and then preferably a 440BX chip set. (I know about Intel's past chip set gaffes, so no flames, please.) > But what is the kernel shipped on the CD compiled with? That's what I'm > using. I know Red Hat uses 2.96 to compile their kernel, so I dunno if SGI > did the same. I believe it's 2.91-66 for XFS 1.0. > I think I'm starting to lean toward telling them to install the latest stable > Debian with ext2...... :-) FreeBSD with UFS and Softupdates might not be such a bad idea. IMO it's more work to manage a FreeBSD system, however, so don't jump into it until you understand it. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Mon Jun 11 16:59:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BNxeJ03997 for linux-xfs-outgoing; Mon, 11 Jun 2001 16:59:40 -0700 Received: from mailgw.cc.uga.edu (mailgw.cc.uga.edu [128.192.1.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BNxcV03979 for ; Mon, 11 Jun 2001 16:59:38 -0700 Received: from archa7.cc.uga.edu (arch7.cc.uga.edu) by mailgw.cc.uga.edu (LSMTP for Windows NT v1.1b) with SMTP id <0.034A8C85@mailgw.cc.uga.edu>; Mon, 11 Jun 2001 19:58:03 -0400 Received: from arches.uga.edu (ci191169-a.athen1.ga.home.com [24.18.21.187]) by archa7.cc.uga.edu (8.9.1/8.9.1) with ESMTP id TAA90488 for ; Mon, 11 Jun 2001 19:59:36 -0400 Message-ID: <3B255A44.570F9EB8@arches.uga.edu> Date: Mon, 11 Jun 2001 19:54:44 -0400 From: Daniel Spratlen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: boot problems Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello xfsers, First off, thank you for your hard and wonderful work. Now for my question. I have an IBM x220 server, and I can't get RH7.1-xfs to boot unless I use the boot disk that I created during the install. System configuration is as follows: # df Filesystem 1k-blocks Used Available Use% Mounted on /dev/scsi/host0/bus0/target5/lun0/part6 16606376 463144 16143232 3% / /dev/scsi/host0/bus0/target5/lun0/part1 99588 5376 94212 6% /boot /dev/scsi/host0/bus0/target6/lun0/part5 7521620 144 7521476 1% /opt /dev/scsi/host0/bus0/target6/lun0/part1 10236604 29812 10206792 1% /var There are two scsi disks in this system which both come off of a Adaptec AIC-7892 scsi adapter. Here is /proc/scsi/scsi: # more scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: Seagate Model: STT20000N Rev: 7A61 Type: Sequential-Access ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 05 Lun: 00 Vendor: IBM-PSG Model: ST318436LW !# Rev: 3281 Type: Direct-Access ANSI SCSI revision: 03 Host: scsi0 Channel: 00 Id: 06 Lun: 00 Vendor: IBM-PSG Model: DPSS-318350N M Rev: S9AA Type: Direct-Access ANSI SCSI revision: 03 I n the scsi bios, I set the disk with the Id of 6 to be the boot disk. Here is /proc/scsi/aicxxxx/0: # more 0 Adaptec AIC7xxx driver version: 5.2.4/5.2.0 Compile Options: TCQ Enabled By Default : Enabled AIC7XXX_PROC_STATS : Enabled Adapter Configuration: SCSI Adapter: Adaptec AIC-7892 Ultra 160/m SCSI host adapter Ultra-160/m LVD/SE Wide Controller at PCI 1/3/0 PCI MMAPed I/O Base: 0xeffff000 Adapter SEEPROM Config: SEEPROM found and used. Adaptec SCSI BIOS: Enabled IRQ: 9 SCBs: Active 0, Max Active 64, Allocated 93, HW 32, Page 255 Interrupts: 26199 BIOS Control Word: 0x58d4 Adapter Control Word: 0x5c5e Extended Translation: Enabled Disconnect Enable Flags: 0xffff Ultra Enable Flags: 0x0000 Tag Queue Enable Flags: 0x0060 Ordered Queue Tag Flags: 0x0060 Default Tag Queue Depth: 32 Tagged Queue By Device array for aic7xxx host instance 0: {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0} Actual queue depth per device for aic7xxx host instance 0: {1,1,1,1,1,32,32,1,1,1,1,1,1,1,1,1} Statistics: (scsi0:0:0:0) Device using Narrow/Async transfers. Transinfo settings: current(0/0/0/3), goal(10/127/0/0), user(9/127/1/2) Total transfers 0 (0 reads and 0 writes) < 2K 2K+ 4K+ 8K+ 16K+ 32K+ 64K+ 128K+ Reads: 0 0 0 0 0 0 0 0 Writes: 0 0 0 0 0 0 0 0 (scsi0:0:5:0) Device using Wide/Sync transfers at 40.0 MByte/sec, offset 31 Transinfo settings: current(12/31/1/0), goal(12/31/1/0), user(9/127/1/2) Total transfers 17814 (7090 reads and 10724 writes) < 2K 2K+ 4K+ 8K+ 16K+ 32K+ 64K+ 128K+ Reads: 129 0 4633 1280 264 784 0 0 Writes: 1042 215 361 6227 1185 1694 0 0 (scsi0:0:6:0) Device using Wide/Sync transfers at 40.0 MByte/sec, offset 63 Transinfo settings: current(12/63/1/0), goal(9/127/1/2), user(9/127/1/2) Total transfers 8276 (627 reads and 7649 writes) < 2K 2K+ 4K+ 8K+ 16K+ 32K+ 64K+ 128K+ Reads: 43 0 102 146 146 190 0 0 Writes: 2856 262 1506 1775 605 645 0 0 And also included, here is my lilo.conf file: # more lilo.conf boot=/dev/sda map=/boot/map install=/boot/boot.b prompt timeout=50 message=/boot/message linear default=linux image=/boot/vmlinuz-2.4.2-SGI_XFS_1.0 label=linux initrd=/boot/initrd-2.4.2-SGI_XFS_1.0.img read-only root=/dev/sda6 append="ramdisk_size=2500" I know that this email is long, and has a lot of files attached, and I apologize for the length, but I thought that I'd provide as much info as possible. As I said, I can only boot if I use the boot disk that I created during the install process. I made sure that I installed lilo on the MBA as per the FAQ. I have the most updated bios available from IBM. If I boot with the boot disk, everything works wonderfully, but I'd like to be able to boot from sda. The only thing that I can think of at this moment, is that hda on this box is a cdrom, but I don't think that this would be a problem. Upon bootup, the machine looks on the media as per the boot order in the bios, It checks the scsi drives first, and then looks on the cdrom, and then the floppy. This is the order that the drive lights come on, and also the order that they are supposed to boot from according to the bios. TIA, Daniel Spratlen spratlen@arches.uga.edu From owner-linux-xfs@oss.sgi.com Mon Jun 11 16:58:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BNwm203839 for linux-xfs-outgoing; Mon, 11 Jun 2001 16:58:48 -0700 Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BNwlV03834 for ; Mon, 11 Jun 2001 16:58:47 -0700 Received: from eclipse ([65.4.56.167]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010611235842.OGVA14901.femail12.sdc1.sfba.home.com@eclipse>; Mon, 11 Jun 2001 16:58:42 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Micah Yoder To: Juha Saarinen Subject: Re: Stability of the Red Hat 7.1 + XFS system Date: Mon, 11 Jun 2001 16:59:38 -0400 X-Mailer: KMail [version 1.2] Cc: "linux-xfs@oss.sgi.com" References: In-Reply-To: MIME-Version: 1.0 Message-Id: <0106111659380F.01070@eclipse> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well, they got the server back up. Said /etc/rc.d/rc.local was "complete gobledegook". I'm back in and everything else seems to be in OK shape. Is there a fairly straightforward way to upgrade the kernel and XFS? I'm a little wary of using 2.4.5 because of the swapping issues. But it might be worth a shot. > Well, check the Linux mailing lists -- reading those, and having battled > with a Tyan Tiger 133 for ages now, I would be extremely hesistant depend > on anything with a VIA chip set onboard. I'm sure that they'll get it > right at some point, but at the moment, stability and reliability still > seems to equal Intel, and then preferably a 440BX chip set. well I certainly can't replace the motherboard. Unless things *really* get bad and that's the only possible solution. If this happens again I'll probably just have them install Debian + ext2. From owner-linux-xfs@oss.sgi.com Mon Jun 11 17:28:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C0SiS08462 for linux-xfs-outgoing; Mon, 11 Jun 2001 17:28:44 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C0SfV08447 for ; Mon, 11 Jun 2001 17:28:42 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5C0TXk18131; Tue, 12 Jun 2001 10:29:34 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Daniel Spratlen cc: linux-xfs@oss.sgi.com Subject: Re: boot problems In-reply-to: Your message of "Mon, 11 Jun 2001 19:54:44 -0400." <3B255A44.570F9EB8@arches.uga.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Jun 2001 10:29:33 +1000 Message-ID: <18130.992305773@ocs4.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 11 Jun 2001 19:54:44 -0400, Daniel Spratlen wrote: > First off, thank you for your hard and wonderful work. Now for my >question. I have an IBM x220 server, and I can't get RH7.1-xfs to boot >unless I use the boot disk that I created during the install. System >configuration is as follows: [Useful information snipped]. The one thing you are missing is a detailed description of the symptoms. "can't get RH7.1-xfs to boot" does not tell us much, we need to know how far it gets and what the last messages are. Does LILO boot, does lilo load a kernel, does the kernel issue any messages, does the kernel see the SCSI controller etc.? Boot problems have many different causes, without details everybody would just be guessing. From owner-linux-xfs@oss.sgi.com Mon Jun 11 17:38:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C0cWH10037 for linux-xfs-outgoing; Mon, 11 Jun 2001 17:38:32 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C0cUV10026 for ; Mon, 11 Jun 2001 17:38:30 -0700 Received: from [192.168.1.10] (helo=den2) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 159cCR-00063z-05; Tue, 12 Jun 2001 12:38:27 +1200 From: "Juha Saarinen" To: "'Micah Yoder'" Cc: Subject: RE: Stability of the Red Hat 7.1 + XFS system Date: Tue, 12 Jun 2001 12:38:06 +1200 Message-ID: <004f01c0f2d7$f306e660$0a01a8c0@den2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <0106111659380F.01070@eclipse> Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk :: Well, they got the server back up. Said /etc/rc.d/rc.local :: was "complete :: gobledegook". :: :: I'm back in and everything else seems to be in OK shape. In my case, parts of /var were corrupted (after I compiled with gcc 2.96 that is). :: Is there a fairly straightforward way to upgrade the kernel :: and XFS? I'm a :: little wary of using 2.4.5 because of the swapping issues. :: But it might be :: worth a shot. FWIW, I'm running it here on an Ext2fs box -- no issues at all, and swapping seems OK. However, I understand that 2.4.6 will have the VM reworked, so it might be worth waiting for that. I don't think there are RPMs for 2.4.5, only CVS. It's not a major hassle to upgrade with that, but it's not as trivial as with RPM. Also, running CVS code on a production server is a bit of a no-no. :: well I certainly can't replace the motherboard. Unless :: things *really* get :: bad and that's the only possible solution. No, I understand that. Same situation here. :: If this happens again I'll probably just have them install :: Debian + ext2. Well, it's a combo that's been known to work, and very well too ;-). XFS feels like it's close to production, but perhaps not quite yet. A UPS (check the NUT page at www.exploits.org/nut before deciding on which one) would probably make sense, unless the co-lo offers that already. -- Juha From owner-linux-xfs@oss.sgi.com Mon Jun 11 18:03:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C13TC13970 for linux-xfs-outgoing; Mon, 11 Jun 2001 18:03:29 -0700 Received: from pilot11.cl.msu.edu (pilot11.cl.msu.edu [35.9.5.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C13SV13967 for ; Mon, 11 Jun 2001 18:03:28 -0700 Received: from pilot.msu.edu (pm558-39.dialip.mich.net [35.9.49.91]) by pilot11.cl.msu.edu (8.10.2/8.10.2) with ESMTP id f5C13Qe31190 for ; Mon, 11 Jun 2001 21:03:27 -0400 Message-ID: <3B2569D2.2760D6AA@pilot.msu.edu> Date: Mon, 11 Jun 2001 21:01:06 -0400 From: Chris Szilagyi X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: quota support Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I'm trying to get quotas to work on an XFS partition but no luck. I have a partition that was formatted and set up with the SGI_XFS Redhat 7.1 installer. I read the docs and followed the steps to set up quotas as specified in README.quota. I have mounted the XFS partition with quota support, by adding 'usrquota' in /etc/fstab, and ran 'quotaon -a'. When I do a 'setquota', I get a "Not all specified mountpoints are using quota.". When I do a 'edquota', I get a "No filesystems with quota detected.". Any issues with xfs quotas on Red Hat 7.1 or something that I may not be doing right? Thanks for the help, -- Chris From owner-linux-xfs@oss.sgi.com Mon Jun 11 18:09:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C19Fk14967 for linux-xfs-outgoing; Mon, 11 Jun 2001 18:09:15 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C19EV14964 for ; Mon, 11 Jun 2001 18:09:14 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA08889 for ; Mon, 11 Jun 2001 18:09:06 -0700 (PDT) mail_from (ivanr@melbourne.sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA23513; Tue, 12 Jun 2001 11:07:40 +1000 From: ivanr@melbourne.sgi.com (Ivan Rayner) Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA05318; Tue, 12 Jun 2001 11:07:39 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Tue, 12 Jun 2001 11:07:39 +1000 To: Russel Ingram cc: Subject: Re: xfsdump, paride tape, and -m option In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 10 Jun 2001, Russel Ingram wrote: > > The argument to -b should be bytes, so 16k would be 16384 not 16. > > > > If this doesn't fix your problem, could you use -v5 to get verbose output. > > (This might produce alot of output, so you should redirect it to a file.) > > > > Ivan > > > Ok, I ran it again with the right sysntax on the -b option. Here's the > command I gave it: > > xfsdump -v5 -m -b 32k -o -F -E -l0 -M"gumby" -L"tmp" -f /dev/tape -s tmp / The argument to -b should be bytes, so 32k would be '32768' not '32k'. Let me know if this helps. Ivan -- Ivan Rayner ivanr@melbourne.sgi.com From owner-linux-xfs@oss.sgi.com Mon Jun 11 18:16:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C1Grr16168 for linux-xfs-outgoing; Mon, 11 Jun 2001 18:16:53 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C1GpV16165 for ; Mon, 11 Jun 2001 18:16:52 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id VAA09311; Mon, 11 Jun 2001 21:10:04 -0400 Message-ID: <3B25702B.E9763DAC@ieee.org> Date: Mon, 11 Jun 2001 21:28:11 -0400 From: "Bryan J. Smith" Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Juha Saarinen CC: Micah Yoder , "linux-xfs@oss.sgi.com" Subject: Re: Stability of the Red Hat 7.1 + XFS system References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juha Saarinen wrote: > Well, check the Linux mailing lists -- reading those, and having battled > with a Tyan Tiger 133 for ages now, I would be extremely hesistant depend > on anything with a VIA chip set onboard. I'm sure that they'll get it > right at some point, but at the moment, stability and reliability still > seems to equal Intel, and then preferably a 440BX chip set. Depends on the revision of the Tiger 133. Tyan is like the Microsoft of the mainboard world. You gotta wait for revision C or D before it's good. Late revisions of the Tiger 133 are quite stable. But early revisions? Watch out! One chipset that is a blessing and a curse is the ServerSet III from ServerWorks (fka RCC). Even Intel has OEM'd it for their high-end boards -- damn they know how to make memory and CPU controllers (let alone the 1GBps north-to-southbridge interconnect)! The catch is the on-board Ultra33 controller is just getting support now in the kernel, and the AGP is a slouch. Of course, if you're paying $300+ for a mainboard, you should be going SCSI (or at least 3Ware ATA-RAID) -- hence, "ServerWorks." ;-PPP > (I know about Intel's past chip set gaffes, so no flames, please.) I personally cannot stand people who say "this company sucks, or that company sucks." It all comes down to specific parts and models. E.g., the ViA 686A (Ultra66) southbridge has compatibility and performance problems galore, but the newer ViA 686B (Ultra100) bests the ICH2 (Ultra100) southbridge in most people's eyes (and has a higher handwidth channel to the northbridge too). -- TheBS -- Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 SmithConcepts, Inc. http://www.SmithConcepts.com ========================================================== Linux 'Worms' exploit known security holes that were fixed 3-12 months earlier. NT/2000 'Worms' exploit unknown se- curity holes that won't be fixed for another 3-12 months. From owner-linux-xfs@oss.sgi.com Mon Jun 11 18:31:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C1VtD18589 for linux-xfs-outgoing; Mon, 11 Jun 2001 18:31:55 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C1VrV18582 for ; Mon, 11 Jun 2001 18:31:53 -0700 Received: from [192.168.1.10] (helo=den2) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 159d24-00066F-01; Tue, 12 Jun 2001 13:31:48 +1200 From: "Juha Saarinen" To: "'Bryan J. Smith'" Cc: "'Micah Yoder'" , Subject: RE: Stability of the Red Hat 7.1 + XFS system Date: Tue, 12 Jun 2001 13:31:27 +1200 Message-ID: <005401c0f2df$66daad90$0a01a8c0@den2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3B25702B.E9763DAC@ieee.org> Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk :: Depends on the revision of the Tiger 133. Tyan is like the :: Microsoft of the mainboard world. You gotta wait for revision C or :: D before it's good. Late revisions of the Tiger 133 are quite :: stable. But early revisions? Watch out! Yeah, I managed to avoid that trap... got a revision F motherboard here. :: I personally cannot stand people who say "this company sucks, or :: that company sucks." It all comes down to specific parts and :: models. E.g., the ViA 686A (Ultra66) southbridge has compatibility :: and performance problems galore, but the newer ViA 686B (Ultra100) :: bests the ICH2 (Ultra100) southbridge in most people's eyes (and has :: a higher handwidth channel to the northbridge too). I've got the Apollo Pro 133A set with the VT82c596B South Bridge. I can honestly say that it doesn't work as well as an Intel 440BX solution. -- Juha From owner-linux-xfs@oss.sgi.com Mon Jun 11 18:33:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C1XUo18916 for linux-xfs-outgoing; Mon, 11 Jun 2001 18:33:30 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C1XSV18907 for ; Mon, 11 Jun 2001 18:33:28 -0700 Received: from [192.168.1.10] (helo=den2) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 159d3e-00066X-00 for ; Tue, 12 Jun 2001 13:33:26 +1200 From: "Juha Saarinen" To: Subject: Today's CVS doesn't compile Date: Tue, 12 Jun 2001 13:33:06 +1200 Message-ID: <005501c0f2df$a16da480$0a01a8c0@den2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yes, I used kgcc. CVS about an hour ago. {standard input}: Assembler messages: {standard input}:826: Warning: indirect lcall without `*' {standard input}:908: Warning: indirect lcall without `*' {standard input}:1003: Warning: indirect lcall without `*' {standard input}:1044: Warning: indirect lcall without `*' {standard input}:1074: Warning: indirect lcall without `*' {standard input}:1104: Warning: indirect lcall without `*' {standard input}:1135: Warning: indirect lcall without `*' {standard input}:1164: Warning: indirect lcall without `*' {standard input}:1193: Warning: indirect lcall without `*' {standard input}:1494: Warning: indirect lcall without `*' {standard input}:1589: Warning: indirect lcall without `*' gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o pci-irq.o pci-irq.c gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -DEXPORT_SYMTAB -c mtrr.c gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o smp.o smp.c gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o smpboot.o smpboot.c gcc -V egcs-2.91.66 -D__ASSEMBLY__ -D__KERNEL__ -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -traditional -c trampoline.S -o trampoline.o /tmp/ccaQiW2d.s: Assembler messages: /tmp/ccaQiW2d.s:868: Error: suffix or operands invalid for `ljmp' make[1]: *** [trampoline.o] Error 1 make[1]: Leaving directory `/usr/src/xfs-cvs/linux-2.4-xfs/linux/arch/i386/kernel' make: *** [_dir_arch/i386/kernel] Error 2 -- Juha From owner-linux-xfs@oss.sgi.com Mon Jun 11 19:09:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C29ma22206 for linux-xfs-outgoing; Mon, 11 Jun 2001 19:09:48 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C29lV22202 for ; Mon, 11 Jun 2001 19:09:47 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id WAA09533; Mon, 11 Jun 2001 22:03:00 -0400 Message-ID: <3B257C93.6019EA85@ieee.org> Date: Mon, 11 Jun 2001 22:21:07 -0400 From: "Bryan J. Smith" Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Juha Saarinen CC: "'Micah Yoder'" , linux-xfs@oss.sgi.com Subject: Re: Stability of the Red Hat 7.1 + XFS system References: <005401c0f2df$66daad90$0a01a8c0@den2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juha Saarinen wrote: > Yeah, I managed to avoid that trap... got a revision > F motherboard here. Yep. Saw the same thing with the Tyan S1854 too. I have revs A, C and D. > I've got the Apollo Pro 133A set with the VT82c596B South Bridge. I can > honestly say that it doesn't work as well as an Intel 440BX solution. The VT82c596B and VT82c686A are the same southbridge from the IDE standpoint, Ultra66. They are really no better than the VT82c586B/596A, Ultra66, having all kinds of UDMA resets and bottlenecks. Most "enthusiast" sites showed it was not capable of >35MBps "theoretical" and most HD would perform 10% _worse_ than the older 586B/596A (let alone probably 25% worse than the aged iPIIX4 in the i440LX/BX/GX). Now the VT82c686B, Ultra100, really shines. The resets are minimized and 83MBps is the max theoretical performance most enthusiasts benchmarks are showing, with less CPU utilization than the similarly performing iBCH2 (in the newer i815E, 820E, 850 and 860). But it's hard to find outside of the KT133A/Pro266 chipsets (most older KT133 and Pro/133A's still have the older 596B/686A -- although I saw Abit's "lowcost/$85" KT7E has a 686B with an older KT133). The new AMD 760MP/MPX will sport a modified one with a 266MBps north-to-southbridge interconnect like the i850/860. Well, that's enough of my "technobable" for a filesystem list. ;-PPP -- TheBS -- Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 SmithConcepts, Inc. http://www.SmithConcepts.com ========================================================== Linux 'Worms' exploit known security holes that were fixed 3-12 months earlier. NT/2000 'Worms' exploit unknown se- curity holes that won't be fixed for another 3-12 months. From owner-linux-xfs@oss.sgi.com Mon Jun 11 19:11:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C2Bag22332 for linux-xfs-outgoing; Mon, 11 Jun 2001 19:11:36 -0700 Received: from imf10bis.bellsouth.net (mail110.mail.bellsouth.net [205.152.58.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C2BYV22327 for ; Mon, 11 Jun 2001 19:11:35 -0700 Received: from spruce ([208.61.4.190]) by imf10bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20010612021217.HJTC1485.imf10bis.bellsouth.net@spruce>; Mon, 11 Jun 2001 22:12:17 -0400 From: "Juan Casero" To: "Juha Saarinen" , "'Bryan J. Smith'" Cc: "'Micah Yoder'" , Subject: RE: Stability of the Red Hat 7.1 + XFS system Date: Mon, 11 Jun 2001 22:00:25 -0400 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <005401c0f2df$66daad90$0a01a8c0@den2> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Normally I don't bother with these kinds of pointless debates but this one touches a cord in me. I have two deskop workstations here (both using MS Windows 2k cuz I need the advanced 3D graphics) using the 440BX chipset. In my experience this is one of the most stable chipsets I have ever come across. My primary workstation is a Tyan Tiger 100 with the i440BX chipset and two Pentium III 500Mhz processors and 1 Gigabyte of ECC PC100 SDRAM from Crucial. What these boards lack in performance they make up for with rock solid stability. What good is the fastest computer on the market if it can't stay up long enough to get any useful work done? I also have a Tyan trinity (1590S) board with an AMD K6 that uses the VIA MVP3 chip set. This board has been plagued by problems and instability under microsoft's OS's. I think the problem is with the AGP port. I was finally able to get some use out if by installing linux on it with no graphics-strictly a server-and using it as a firewall/gateway. For this reason I flat out refuse to buy any system that uses a motherboard with any VIA chipset. My machines have to stay up for weeks and months at a time. Anticipating a long wait before the Itanium systems could become affordable I decided to deck out my current system and so bought the extra RAM and a nice 3D graphics card from 3D Labs with full OpenGL hardware acceleration. Hopefull I won't have to wait too long before I can afford the kind of technology presently used with Itaniuum workstations. juan. casero@bellsouth.net -----Original Message----- From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com]On Behalf Of Juha Saarinen Sent: Monday, June 11, 2001 9:31 PM To: 'Bryan J. Smith' Cc: 'Micah Yoder'; linux-xfs@oss.sgi.com Subject: RE: Stability of the Red Hat 7.1 + XFS system :: Depends on the revision of the Tiger 133. Tyan is like the :: Microsoft of the mainboard world. You gotta wait for revision C or :: D before it's good. Late revisions of the Tiger 133 are quite :: stable. But early revisions? Watch out! Yeah, I managed to avoid that trap... got a revision F motherboard here. :: I personally cannot stand people who say "this company sucks, or :: that company sucks." It all comes down to specific parts and :: models. E.g., the ViA 686A (Ultra66) southbridge has compatibility :: and performance problems galore, but the newer ViA 686B (Ultra100) :: bests the ICH2 (Ultra100) southbridge in most people's eyes (and has :: a higher handwidth channel to the northbridge too). I've got the Apollo Pro 133A set with the VT82c596B South Bridge. I can honestly say that it doesn't work as well as an Intel 440BX solution. -- Juha From owner-linux-xfs@oss.sgi.com Mon Jun 11 19:16:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C2GoR22542 for linux-xfs-outgoing; Mon, 11 Jun 2001 19:16:50 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C2GnV22539 for ; Mon, 11 Jun 2001 19:16:49 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id WAA09560; Mon, 11 Jun 2001 22:09:41 -0400 Message-ID: <3B257E24.2A3BC69@ieee.org> Date: Mon, 11 Jun 2001 22:27:48 -0400 From: "Bryan J. Smith" Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Russell Cattelan CC: Tom Duffy , Juha Saarinen , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp References: <3B241B89.9247E5BC@engr.sgi.com> <3B24E6C0.E3855EAE@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Russell Cattelan wrote: > note there is several examples of non GPL'ed / dual > licensed code in the kernel ... the new adaptec drivers > for example. Someone is going to have to sit down and explain to me the whole Adaptec non-support/support of Linux from 1993 on. All I know is that I have _never_ had good Adaptec support, period. In fact, I distinctly remember when Adaptec released (or at least modified the existing drivers) in their first "officially supported" drivers for Linux and my compatibility went to crap (was that 1998?). At least two dozen different Adaptec-brand host adapters later, I find I usually have to rip 'em out and replace them in Advansys and/or Symbios/TekRam cards. Plus Adaptec's non-support of Linux with new products still makes me wonder how "committed" they are to Linux. -- TheBS -- Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 SmithConcepts, Inc. http://www.SmithConcepts.com ========================================================== Linux 'Worms' exploit known security holes that were fixed 3-12 months earlier. NT/2000 'Worms' exploit unknown se- curity holes that won't be fixed for another 3-12 months. From owner-linux-xfs@oss.sgi.com Mon Jun 11 19:18:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C2I5O22644 for linux-xfs-outgoing; Mon, 11 Jun 2001 19:18:05 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C2I4V22641 for ; Mon, 11 Jun 2001 19:18:04 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id WAA09573; Mon, 11 Jun 2001 22:11:13 -0400 Message-ID: <3B257E80.EBA8F8CE@ieee.org> Date: Mon, 11 Jun 2001 22:29:20 -0400 From: "Bryan J. Smith" Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Russell Cattelan , Juha Saarinen , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp References: <3B24E5A1.7404BFBA@thebarn.com> <3B24E732.D3A3C8A6@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > Remember that one of the most time-consuming, difficult parts of this > project early on was handling the "lawyer issues" - I saw one slide that > said a couple lawyers quit in the process.... :) Tackling that all over > again would probably not be a high priority. Right now I wouldn't want to be Bruce Perens over at HP trying to figure out how to release HP OpenMail as OSS. ;-PPP God knows it took Sun forever to finally release the StarOffice code as GPL -- and they were really trying to get it out as GPL too. -- TheBS -- Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 SmithConcepts, Inc. http://www.SmithConcepts.com ========================================================== Linux 'Worms' exploit known security holes that were fixed 3-12 months earlier. NT/2000 'Worms' exploit unknown se- curity holes that won't be fixed for another 3-12 months. From owner-linux-xfs@oss.sgi.com Mon Jun 11 19:19:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C2Ju322783 for linux-xfs-outgoing; Mon, 11 Jun 2001 19:19:56 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C2JtV22780 for ; Mon, 11 Jun 2001 19:19:55 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA07835 for ; Mon, 11 Jun 2001 19:20:14 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA30953; Tue, 12 Jun 2001 12:18:30 +1000 (EST) Date: Tue, 12 Jun 2001 12:18:30 +1000 From: Timothy Shimmin To: "Bernhard R. Erdmann" Cc: Linux XFS Mailing List Subject: Re: map_add: Assertion `ino > last_ino_added' failed Message-ID: <20010612121830.E237728@boing.melbourne.sgi.com> References: <3B246910.95E5FE7A@berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3B246910.95E5FE7A@berdmann.de>; from be@berdmann.de on Mon, Jun 11, 2001 at 08:45:36AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Bernhard, On Mon, Jun 11, 2001 at 08:45:36AM +0200, Bernhard R. Erdmann wrote: > I got this snippet from my nightly backup run: > > FAILED AND STRANGE DUMP DETAILS: > > /-- ente /var lev 1 FAILED [/usr/sbin/xfsdump got signal 6] > sendbackup: start [ente:/var level 1] > sendbackup: info BACKUP=/usr/sbin/xfsdump > sendbackup: info RECOVER_CMD=/usr/sbin/xfsrestore -f... - > sendbackup: info end > | xfsdump: version 3.0 - Running single-threaded > | xfsdump: level 1 incremental dump of ente:/var based on level 0 dump > begun Sun Jun 10 02:24:35 2001 > | xfsdump: dump date: Mon Jun 11 02:12:27 2001 > | xfsdump: session id: ccc7ce3b-6c3e-49cb-8d3d-7632f8f51040 > | xfsdump: session label: "" > | xfsdump: ino map phase 1: skipping (no subtrees specified) > | xfsdump: ino map phase 2: constructing initial dump list > ? xfsdump: inomap.c:1345: map_add: Assertion `ino > last_ino_added' > failed. > sendbackup: error [/usr/sbin/xfsdump got signal 6] > \-------- > > > What's the meaning of "Assertion `ino > last_ino_added' failed"? In xfsdump it creates an inodemap of the filesystem which basically is a datastructure which says whether a directory or non-directory inode has changed or not for the dump. It creates the inodemap by processing all the inodes of the given xfs filesystem by making bulkstat calls i.e. ioctl(fsfd, XFS_IOC_FSBULKSTAT, &bulkreq). The bulkreq has a buffer and a request for a buffer's worth of inode stat records. It is supposed to return the inode stat records in ascending inode number order. This assert seems to be indicating that the latest inode it is processing from bulkstat does not have a greater inode# than the previous one ! Something wrong here :( Have you seen this before ? I can add some more diagnostics so that we can at least know what the 'ino' and 'last_ino_added' values are. --Tim From owner-linux-xfs@oss.sgi.com Mon Jun 11 19:59:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C2xQK25808 for linux-xfs-outgoing; Mon, 11 Jun 2001 19:59:26 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C2xMV25802 for ; Mon, 11 Jun 2001 19:59:23 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id WAA09739; Mon, 11 Jun 2001 22:52:37 -0400 Message-ID: <3B258833.9FE3146E@ieee.org> Date: Mon, 11 Jun 2001 23:10:43 -0400 From: "Bryan J. Smith" Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Juan Casero CC: Juha Saarinen , "'Micah Yoder'" , linux-xfs@oss.sgi.com Subject: Re: Stability of the Red Hat 7.1 + XFS system References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [ Okay, I'm _really_ getting off-topic. @-P ] Juan Casero wrote: > Normally I don't bother with these kinds of pointless debates > but this one touches a cord in me. I have two deskop workstations > here (both using MS Windows 2k cuz I need the advanced 3D graphics) > using the 440BX chipset. In my experience this is one of the most > stable chipsets I have ever come across. And, until just recently, was still being made (possibly still being made, "unofficially" ;-)! The i810 and 815 chipsets are limited to 2 DIMMs with only 128MB and 256MB SDRAM modules, respectively -- which canNOT be "registered" or use x4b IC sizes (nor ECC if I remember correctly?). Numerous mainboard manufacturer's have released i440BX chipsets with newer FC-PGA/VRM 8.4 support, usually with an Ultra100 ATA controller on-board. So other than the lack of AGPx4 support and unofficial 133MHz FSB support, they are still quite a good solution. E.g.: http://www.epox.com/html/english/products/motherboard/ep-bx7+100.htm > My primary workstation is a Tyan Tiger 100 with the i440BX > chipset and two Pentium III 500Mhz processors and 1 Gigabyte > of ECC PC100 SDRAM from Crucial. What these boards lack in > performance they make up for with rock solid stability. Actually, it's not surprising to find the i440BX matching even i815E chipset mainboards, even with PC133 on the latter. > What good is the fastest computer on the market if it can't stay up > long enough to get any useful work done? Exactomundo! Although if I _really_ need "stability" combined with massive amounts of RAM (which means no RDRAM-option), I go RCC/ServerWorks -- even Intel agrees! Of course, ServerWorks has AGP and ATA/IDE issues just like ViA did prior to its Intel cross-license. But the memory/CPU interconnect and north-to-south interconnects are just unbelievable! Hence why "the big boys" (large PC OEMs) used them for years for servers. > I also have a Tyan trinity (1590S) board with an AMD K6 that > uses the VIA MVP3 chip set. This board has been plagued by > problems and instability under microsoft's OS's. VIA had "several revisions" of the mVP3. ;-PPP > I think the problem is with the AGP port. Many of the "revisions" of the mVP3 were completely for AGP fixes. Most of the "workarounds" are now available for older versions in the software drivers -- albeit at a performance hit on those older chipsets. ViA's Socket-370 chipsets _after_ the Intel cross-license of 1998 (?) are exponentially better. I wouldn't use the mVP3 as the "measuring stick" for ViA. > I was finally able to get some use out if by installing linux > on it with no graphics-strictly a server-and using it as a > firewall/gateway. For this reason I flat out refuse to buy > any system that uses a motherboard with any VIA chipset. Because of the i810/815 stability issues, not to mention the MTH issues of the i820 as well as various i440GX issues that did not plague the i440BX before it, I _refuse_ to use _any_ Intel SDRAM chipset after the i440BX. As such, it's either a "souped up" i440BX, select ViA chipsets or ServerWorks -- or an actual AMD chipset if you can get one. ;-PPP I usually stick with ViA because of the "flexibility" of the chipset. Intel's chipsets are far to limited. This is especially true in the case of the new ViA Pro266 DDR chipsets. Get one that has both SDR and DDR slots -- you can use all kinds of memory types in them -- including 512Mb SDRAM ICs for upto 1GB DIMM support, just like ServerWorks'). [ See my post here for more detail on SDRAM IC support: http://www.zepa.net/hypermail/elug/hardware/2001/02/0008.html ] I've had few issues with the ViA Apollo Pro/133A (694X), although the early Pro (693) is a different story (it pre-dates the Intel cross-license). The KT133 is fine except for the crappy 686A southbridge -- but the new KT133A w/686B is fine (and select Pro/133A and KT133s with the 686B are as well). The Pro266 is just as nice for SDR SDRAM (although DDR SDRAM is still "maturing" on non-AMD760 chipsets). > My machines have to stay up for weeks and months at a time. My KT133 stays up as a primary workstation, including 3-D gaming, for months at a time (Linux, of course ;-). > Anticipating a long wait before the Itanium systems could > become affordable I decided to deck out my current system > and so bought the extra RAM and a nice 3D graphics card > from 3D Labs with full OpenGL hardware acceleration. I'm really looking for a good review of the nVidia GeForce and Quadra series of products versus the 3DLabs/Oxygen ones at professional GL applications. I never was a fan of nVidia until recently (as they released Linux drivers), and have always preferred the latter. But the 16-bit color 3-D performance (under both NT and Linux) of a low-cost (~$130) nVidia GeForce2 MX dual-headed board changed that. > Hopefull I won't have to wait too long before I can afford > the kind of technology presently used with Itaniuum > workstations. The new "bang for the buck" seems to lie in the AMD Athlon MP (although you can use older chips in dual processor mode on the mainboards too -- but the MP chip version is better). The EV6 bus combined with the full-peer cache concurrency of the Alpha/Athlon design shreds Intel's Pentium/Xeon SMP to pieces. But, alas, the new Tyan AMD 760MP mainboard product is just a "preview" and an "one-time" product. The "production" chipset is the AMD 760MPX which will sport a separate 64-bit x 66MHz PCI bus directly on the northbridge (as a node on the EV6 CPU-memory-I/O crossbar), in addition to the "legacy" southbridge for PCI/ISA. AMD 760MPX mainboard will sport sub-$200 prices because they still use only a single, 2.1GBps PC2100 memory channel (unlike the more expensive i840/860 chipsets with dual 1.6GBps PC800 DRDRAM channels). The point-to-point EV6 CPU-memory-I/O crossbar interconnect lets one Athlon (or Athlon MP) do I/O while the other talks to memory -- which seems to best even dual 1.7GHz P4-Xeons on the, yet unreleased, i860 chipset, in all but the most memory-intensive tasks. [ Enthusiast review (read the whole thing, very interesting -- and it's not even the 760MPX yet): http://www.anandtech.com/showdoc.html?i=1483 ] We'll have to see if ServerWorks' DDR SDRAM P4-Xeon chipset can "save" Intel in Q4. Right now, AMD is really starting to pound Intel at even the high-end for far, far less money. Since Intel has denied ViA any licensure of the P4 architecture, it's up to ServerWorks to save them (not that ViA is in ServerWorks' league anyway ;-). Frankly, I probably won't purchase a P4 _until_ there is a DDR SDRAM chipset anyway (and I hope the Intel-ServerWorks cross-patent licensing agreement gives ServerWorks better AGP and ATA/IDE interfaces). -- TheBS -- Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 SmithConcepts, Inc. http://www.SmithConcepts.com ========================================================== Linux 'Worms' exploit known security holes that were fixed 3-12 months earlier. NT/2000 'Worms' exploit unknown se- curity holes that won't be fixed for another 3-12 months. From owner-linux-xfs@oss.sgi.com Mon Jun 11 21:24:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C4OwL01160 for linux-xfs-outgoing; Mon, 11 Jun 2001 21:24:58 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C4OuV01151 for ; Mon, 11 Jun 2001 21:24:56 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA02849 for ; Mon, 11 Jun 2001 21:25:14 -0700 (PDT) mail_from (ivanr@snort.melbourne.sgi.com) Received: (from ivanr@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA25730 for linux-xfs@oss.sgi.com; Tue, 12 Jun 2001 14:23:37 +1000 (EST) Date: Tue, 12 Jun 2001 14:23:37 +1000 (EST) From: Ivan Rayner Message-Id: <200106120423.OAA25730@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - linux-xfs xfsdump/xfsrestore man pages Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk clarify blocksize units, add quota info, and -d option Date: Mon Jun 11 21:22:25 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build6/ivanr/isms/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:96707a cmd/xfsdump/man/man8/xfsdump.8 - 1.4 cmd/xfsdump/man/man8/xfsrestore.8 - 1.2 From owner-linux-xfs@oss.sgi.com Mon Jun 11 21:55:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C4tF504581 for linux-xfs-outgoing; Mon, 11 Jun 2001 21:55:15 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C4tDV04576 for ; Mon, 11 Jun 2001 21:55:13 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA04024 for ; Mon, 11 Jun 2001 21:55:31 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id OAA14863 for linux-xfs@oss.sgi.com; Tue, 12 Jun 2001 14:55:02 +1000 Date: Tue, 12 Jun 2001 14:55:02 +1000 From: Keith Owens Message-Id: <200106120455.OAA14863@sherman.melbourne.sgi.com> Subject: TAKE - Add XFS and KDB to defconfigs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk None of the default config files had entries for XFS or KDB so they defaulted to off or caused problems for unattended installs. This patch updates all defconfigs to append: # # XFS addons # CONFIG_FS_POSIX_ACL=y CONFIG_PAGE_BUF=y CONFIG_XFS_FS=y CONFIG_XFS_DMAPI=y arch/{i386,ia64}/defconfig also have these options appended: CONFIG_KDB=y CONFIG_KDB_OFF=n CONFIG_FRAME_POINTER=n Date: Mon Jun 11 21:51:00 PDT 2001 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:96708a linux/arch/sparc64/defconfig - 1.37 linux/arch/sparc/defconfig - 1.23 linux/arch/ppc/defconfig - 1.30 linux/arch/mips/defconfig - 1.18 linux/arch/m68k/defconfig - 1.10 linux/arch/i386/defconfig - 1.56 linux/arch/arm/defconfig - 1.17 linux/arch/alpha/defconfig - 1.17 linux/arch/sh/defconfig - 1.15 linux/arch/ppc/configs/walnut_defconfig - 1.10 linux/arch/ppc/configs/oak_defconfig - 1.10 linux/arch/ppc/configs/mbx_defconfig - 1.5 linux/arch/ppc/configs/gemini_defconfig - 1.12 linux/arch/ppc/configs/common_defconfig - 1.18 linux/arch/ppc/configs/apus_defconfig - 1.6 linux/arch/ia64/defconfig - 1.8 linux/arch/mips64/defconfig - 1.13 linux/arch/s390/defconfig - 1.5 linux/arch/ppc/configs/rpxlite_defconfig - 1.5 linux/arch/ppc/configs/rpxcllf_defconfig - 1.6 linux/arch/ppc/configs/est8260_defconfig - 1.6 linux/arch/ppc/configs/bseip_defconfig - 1.5 linux/arch/parisc/defconfig - 1.2 linux/arch/ppc/configs/power3_defconfig - 1.3 linux/arch/ppc/configs/ibmchrp_defconfig - 1.3 linux/arch/cris/defconfig - 1.4 linux/arch/s390x/defconfig - 1.3 linux/arch/ppc/configs/TQM860L_defconfig - 1.3 linux/arch/ppc/configs/TQM850L_defconfig - 1.3 linux/arch/ppc/configs/TQM823L_defconfig - 1.3 linux/arch/ppc/configs/SPD823TS_defconfig - 1.3 linux/arch/ppc/configs/SM850_defconfig - 1.3 linux/arch/ppc/configs/IVMS8_defconfig - 1.3 From owner-linux-xfs@oss.sgi.com Mon Jun 11 22:24:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C5OIH05983 for linux-xfs-outgoing; Mon, 11 Jun 2001 22:24:18 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C5OGV05977 for ; Mon, 11 Jun 2001 22:24:16 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip12.idcomm.com [209.60.72.139]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5C5NXB00495; Mon, 11 Jun 2001 23:23:33 -0600 Message-ID: <3B25A7B4.6F3DE3CB@idcomm.com> Date: Mon, 11 Jun 2001 23:25:08 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Spratlen CC: linux-xfs@oss.sgi.com Subject: Re: boot problems References: <3B255A44.570F9EB8@arches.uga.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Daniel Spratlen wrote: > > Hello xfsers, > First off, thank you for your hard and wonderful work. Now for my > question. I have an IBM x220 server, and I can't get RH7.1-xfs to boot > unless I use the boot disk that I created during the install. System > configuration is as follows: One thing that has kept a couple of 2.4.x kernels from booting my system is a bug in fs/block_dev.c, function ioctl_by_bdev, near line 596. This is fixed in the 2.4.5-ac kernels starting around ac3, and I have hand edited it in each version I've used that does not have the fix. You can add the line starting with "+" (don't actually use a "+" sign): int ioctl_by_bdev(struct block_device *bdev, unsigned cmd, unsigned long arg) { kdev_t rdev = to_kdev_t(bdev->bd_dev); struct inode inode_fake; int res; mm_segment_t old_fs = get_fs(); if (!bdev->bd_op->ioctl) return -EINVAL; inode_fake.i_rdev=rdev; + inode_fake.i_bdev=bdev; init_waitqueue_head(&inode_fake.i_wait); set_fs(KERNEL_DS); res = bdev->bd_op->ioctl(&inode_fake, NULL, cmd, arg); set_fs(old_fs); return res; } I realize it is a long-shot that this might actually be your particular problem, but I have the same integrated adapter which is what brought out this particular bug. The bug fix was provided through the kernel devel list. I'm hoping CVS here might add it in as well. D. Stimits, stimits@idcomm.com > > # df > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/scsi/host0/bus0/target5/lun0/part6 > 16606376 463144 16143232 3% / > /dev/scsi/host0/bus0/target5/lun0/part1 > 99588 5376 94212 6% /boot > /dev/scsi/host0/bus0/target6/lun0/part5 > 7521620 144 7521476 1% /opt > /dev/scsi/host0/bus0/target6/lun0/part1 > 10236604 29812 10206792 1% /var > > There are two scsi disks in this system which both come off of a Adaptec > AIC-7892 scsi adapter. Here is /proc/scsi/scsi: > > # more scsi > Attached devices: > Host: scsi0 Channel: 00 Id: 00 Lun: 00 > Vendor: Seagate Model: STT20000N Rev: 7A61 > Type: Sequential-Access ANSI SCSI revision: 02 > Host: scsi0 Channel: 00 Id: 05 Lun: 00 > Vendor: IBM-PSG Model: ST318436LW !# Rev: 3281 > Type: Direct-Access ANSI SCSI revision: 03 > Host: scsi0 Channel: 00 Id: 06 Lun: 00 > Vendor: IBM-PSG Model: DPSS-318350N M Rev: S9AA > Type: Direct-Access ANSI SCSI revision: 03 > > I > > n the scsi bios, I set the disk with the Id of 6 to be the boot disk. > Here is /proc/scsi/aicxxxx/0: > > # more 0 > Adaptec AIC7xxx driver version: 5.2.4/5.2.0 > Compile Options: > TCQ Enabled By Default : Enabled > AIC7XXX_PROC_STATS : Enabled > > Adapter Configuration: > SCSI Adapter: Adaptec AIC-7892 Ultra 160/m SCSI host adapter > Ultra-160/m LVD/SE Wide Controller at PCI > 1/3/0 > PCI MMAPed I/O Base: 0xeffff000 > Adapter SEEPROM Config: SEEPROM found and used. > Adaptec SCSI BIOS: Enabled > IRQ: 9 > SCBs: Active 0, Max Active 64, > Allocated 93, HW 32, Page 255 > Interrupts: 26199 > BIOS Control Word: 0x58d4 > Adapter Control Word: 0x5c5e > Extended Translation: Enabled > Disconnect Enable Flags: 0xffff > Ultra Enable Flags: 0x0000 > Tag Queue Enable Flags: 0x0060 > Ordered Queue Tag Flags: 0x0060 > Default Tag Queue Depth: 32 > Tagged Queue By Device array for aic7xxx host instance 0: > {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0} > Actual queue depth per device for aic7xxx host instance 0: > {1,1,1,1,1,32,32,1,1,1,1,1,1,1,1,1} > > Statistics: > > (scsi0:0:0:0) > Device using Narrow/Async transfers. > Transinfo settings: current(0/0/0/3), goal(10/127/0/0), > user(9/127/1/2) > Total transfers 0 (0 reads and 0 writes) > < 2K 2K+ 4K+ 8K+ 16K+ 32K+ 64K+ > 128K+ > Reads: 0 0 0 0 0 0 0 > 0 > Writes: 0 0 0 0 0 0 0 > 0 > > (scsi0:0:5:0) > Device using Wide/Sync transfers at 40.0 MByte/sec, offset 31 > Transinfo settings: current(12/31/1/0), goal(12/31/1/0), > user(9/127/1/2) > Total transfers 17814 (7090 reads and 10724 writes) > < 2K 2K+ 4K+ 8K+ 16K+ 32K+ 64K+ > 128K+ > Reads: 129 0 4633 1280 264 784 0 > 0 > Writes: 1042 215 361 6227 1185 1694 0 > 0 > > (scsi0:0:6:0) > Device using Wide/Sync transfers at 40.0 MByte/sec, offset 63 > Transinfo settings: current(12/63/1/0), goal(9/127/1/2), > user(9/127/1/2) > Total transfers 8276 (627 reads and 7649 writes) > < 2K 2K+ 4K+ 8K+ 16K+ 32K+ 64K+ > 128K+ > Reads: 43 0 102 146 146 190 0 > 0 > Writes: 2856 262 1506 1775 605 645 0 > 0 > > And also included, here is my lilo.conf file: > > # more lilo.conf > boot=/dev/sda > map=/boot/map > install=/boot/boot.b > prompt > timeout=50 > message=/boot/message > linear > default=linux > > image=/boot/vmlinuz-2.4.2-SGI_XFS_1.0 > label=linux > initrd=/boot/initrd-2.4.2-SGI_XFS_1.0.img > read-only > root=/dev/sda6 > append="ramdisk_size=2500" > > I know that this email is long, and has a lot of files attached, and I > apologize for the length, but I thought that I'd provide as much info as > possible. As I said, I can only boot if I use the boot disk that I > created during the install process. I made sure that I installed lilo > on the MBA as per the FAQ. I have the most updated bios available from > IBM. If I boot with the boot disk, everything works wonderfully, but > I'd like to be able to boot from sda. The only thing that I can think > of at this moment, is that hda on this box is a cdrom, but I don't think > that this would be a problem. Upon bootup, the machine looks on the > media as per the boot order in the bios, It checks the scsi drives > first, and then looks on the cdrom, and then the floppy. This is the > order that the drive lights come on, and also the order that they are > supposed to boot from according to the bios. > > TIA, > Daniel Spratlen > spratlen@arches.uga.edu From owner-linux-xfs@oss.sgi.com Mon Jun 11 22:53:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C5rCt07377 for linux-xfs-outgoing; Mon, 11 Jun 2001 22:53:12 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C5rBV07370 for ; Mon, 11 Jun 2001 22:53:11 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA02517 for ; Mon, 11 Jun 2001 22:53:07 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA69854; Tue, 12 Jun 2001 15:51:52 +1000 (EST) Date: Tue, 12 Jun 2001 15:51:52 +1000 From: Timothy Shimmin To: Sebastian Dransfeld Cc: linux-xfs@oss.sgi.com Subject: Re: acls Message-ID: <20010612155152.I237728@boing.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from sebastid@stud.ntnu.no on Sat, Jun 09, 2001 at 09:59:23AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Sebastian, On Sat, Jun 09, 2001 at 09:59:23AM +0200, Sebastian Dransfeld wrote: > > I have this directory acl: > u::rwx,g::r-x,o::r-x,u:sebastid:rwx,m::r-x > I presume you mean directory _default_ acl. > A file created gets this acl: > u::rw-,g::r-x,o::r--,u:sebastid:rwx,m::r-- > > Why does the 'x' only get stripped from default user, other and mask? > Ok, after looking at the Posix ACL standard, code, discussing with ajag@sgi.com, ... When the access ACL for a file of a directory with a default ACL is created, it's ACE permissions are set by _intersection_ of the respective default ACEs permission bits and the mode bits of the parameter to open/creat. So if the creat mode bits don't have the execute (x) bit set for user and other (which will depend on the application you use which makes the create/open call), then nor will the USER_OBJ ACEs and OTHER ACEs. Which is what you saw. The GROUP_OBJ ACE is treated differently if a MASK ACE exists, as is the case in your example above. If we have a MASK ACE (see 5.3.1.2), then the GROUP_OBJ ACE is left alone, and the MASK ACE is intersected with the group permission bits of the creat parameter. The std group permissions bits on the file, however, are updated accordingly. If you did an "ls -l" on the file, then you would see that the group permission bits match the MASK ACE permission bits (see 23.1.2) that you see with "chacl -l". (If there was no MASK ACE then the GROUP_OBJ ACE would be intersected with the group permissions as expected). I hope I haven't confused you. The standard can be equally confusing ;-) The withdrawn Posix ACL standard can be downloaded at: http://wt.xpilot.org/posix.1e/download.html Andreas Gruenbacher's site has some useful info: http://acl.bestbits.at Cheers, --Tim From owner-linux-xfs@oss.sgi.com Mon Jun 11 22:55:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C5t0p07574 for linux-xfs-outgoing; Mon, 11 Jun 2001 22:55:00 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C5swV07564 for ; Mon, 11 Jun 2001 22:54:58 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5C5u3p01830; Tue, 12 Jun 2001 15:56:04 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs From: Keith Owens To: Daniel Spratlen cc: linux-xfs@oss.sgi.com Subject: Re: boot problems In-reply-to: Your message of "Mon, 11 Jun 2001 22:56:23 -0400." <3B2584D6.D8E38B16@arches.uga.edu> Date: Tue, 12 Jun 2001 15:56:03 +1000 Message-ID: <1829.992325363@ocs4.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk If you are not seeing LILO then you have probably have a mismatch between LILO and the BIOS. You mentioned that your BIOS is set to boot from id 6 so try these commands in lilo.conf. boot=/dev/scsi/host0/bus0/target6/lun0/disc disk=/dev/scsi/host0/bus0/target6/lun0/disc bios=0x80 You have boot=/dev/sda so you are writing lilo to the wrong disk. The disk/bios pair tells lilo where you are booting from, lilo needs to be told about non-standard bios settings. You could use /dev/sdc instead of the long names but it is better to be safe and use the devfs names instead of assuming that id 6 is always sdc. From owner-linux-xfs@oss.sgi.com Mon Jun 11 23:02:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C62va08114 for linux-xfs-outgoing; Mon, 11 Jun 2001 23:02:57 -0700 Received: from ente.berdmann.de (p3E9E7330.dip.t-dialin.net [62.158.115.48]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C62uV08110 for ; Mon, 11 Jun 2001 23:02:56 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.16 #2) id 159hGL-0001dR-00; Tue, 12 Jun 2001 08:02:49 +0200 Message-ID: <3B25B089.FC5131E6@berdmann.de> Date: Tue, 12 Jun 2001 08:02:49 +0200 From: "Bernhard R. Erdmann" Organization: Bernhard Erdmann Communication & Network Solutions X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Timothy Shimmin CC: Linux XFS Mailing List Subject: Re: map_add: Assertion `ino > last_ino_added' failed References: <3B246910.95E5FE7A@berdmann.de> <20010612121830.E237728@boing.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > ? xfsdump: inomap.c:1345: map_add: Assertion `ino > last_ino_added' > > failed. > This assert seems to be indicating that the latest inode it is > processing from bulkstat does not have a greater inode# than > the previous one ! Something wrong here :( > Have you seen this before ? No, I haven't seen this before. From owner-linux-xfs@oss.sgi.com Mon Jun 11 23:31:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C6VjO09698 for linux-xfs-outgoing; Mon, 11 Jun 2001 23:31:45 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C6VhV09695 for ; Mon, 11 Jun 2001 23:31:43 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA09510 for ; Mon, 11 Jun 2001 23:31:18 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id QAA00589 for linux-xfs@oss.sgi.com; Tue, 12 Jun 2001 16:30:54 +1000 Date: Tue, 12 Jun 2001 16:30:54 +1000 From: Keith Owens Message-Id: <200106120630.QAA00589@sherman.melbourne.sgi.com> Subject: TAKE - Remove warnings about unused variables Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Remove warnings about unused variables Date: Mon Jun 11 23:30:20 PDT 2001 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:96709a linux/fs/xfs/linux/xfs_iops.c - 1.109 linux/fs/pagebuf/page_buf_io.c - 1.84 From owner-linux-xfs@oss.sgi.com Mon Jun 11 23:40:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C6e3a10224 for linux-xfs-outgoing; Mon, 11 Jun 2001 23:40:03 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C6e1V10218 for ; Mon, 11 Jun 2001 23:40:01 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5C6duV02390; Tue, 12 Jun 2001 08:39:57 +0200 Message-Id: <4.3.2.7.2.20010612083703.02f859d0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Jun 2001 08:39:55 +0200 To: Daniel Spratlen , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: boot problems In-Reply-To: <3B255A44.570F9EB8@arches.uga.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 19:54 11-6-2001 -0400, Daniel Spratlen wrote: >Hello xfsers, > First off, thank you for your hard and wonderful work. Now for my >question. I have an IBM x220 server, and I can't get RH7.1-xfs to boot >unless I use the boot disk that I created during the install. System >configuration is as follows: > ># more lilo.conf >boot=/dev/sda >map=/boot/map >install=/boot/boot.b >prompt >timeout=50 >message=/boot/message >linear >default=linux You say that you have altered the bios to make it boot from disk 6? You are NOT writing a boot sector to disk 6 with this config. If I think I am right sda == id0 and sdg == id6 Edit your lilo.conf to make3 boot=/dev/sda6 It should then write the MBR to the seventh disk in the array. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Jun 12 00:31:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C7VmY13227 for linux-xfs-outgoing; Tue, 12 Jun 2001 00:31:48 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C7VlV13224 for ; Tue, 12 Jun 2001 00:31:47 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id AAA08963 for ; Tue, 12 Jun 2001 00:31:24 -0700 (PDT) mail_from (ivanr@snort.melbourne.sgi.com) Received: (from ivanr@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA65255 for linux-xfs@oss.sgi.com; Tue, 12 Jun 2001 17:29:24 +1000 (EST) Date: Tue, 12 Jun 2001 17:29:24 +1000 (EST) From: Ivan Rayner Message-Id: <200106120729.RAA65255@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - linux-xfs minor change to configure.in files Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk use . ./VERSION rather than . VERSION to source the version info Date: Tue Jun 12 00:20:31 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build6/ivanr/isms/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:96710a cmd/attr/configure.in - 1.4 cmd/xfsdump/configure.in - 1.6 cmd/xfsprogs/configure.in - 1.6 cmd/acl/configure.in - 1.4 cmd/xfstests/configure.in - 1.7 cmd/dmapi/configure.in - 1.6 From owner-linux-xfs@oss.sgi.com Tue Jun 12 00:42:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C7gRu13977 for linux-xfs-outgoing; Tue, 12 Jun 2001 00:42:27 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C7gOV13973 for ; Tue, 12 Jun 2001 00:42:24 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5C7hIZ02254; Tue, 12 Jun 2001 17:43:18 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs From: Keith Owens To: Seth Mos cc: Daniel Spratlen , linux-xfs@oss.sgi.com Subject: Re: boot problems In-reply-to: Your message of "Tue, 12 Jun 2001 08:39:55 +0200." <4.3.2.7.2.20010612083703.02f859d0@pop.xs4all.nl> Date: Tue, 12 Jun 2001 17:43:18 +1000 Message-ID: <2253.992331798@ocs4.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote > At 19:54 11-6-2001 -0400, Daniel Spratlen wrote: > >boot=/dev/sda > > You say that you have altered the bios to make it boot from disk 6? > You are NOT writing a boot sector to disk 6 with this config. > If I think I am right sda == id0 and sdg == id6 > Edit your lilo.conf to make3 boot=/dev/sda6 > It should then write the MBR to the seventh disk in the array. Not quite. sda6 is partition 6 on sda, i.e. the first scsi disk. Also id6 is not necessarily sdg, the old style disk numbering only labels disks that actually exist, with id 0, 5 and 6 you get sda, sdb and sdc. Add another disk as id 4 and sd[bc] change to sd[cd]. This is one of the problems that devfs was designed to fix, which is why I recommend using /dev/scsi/host0/bus0/target6/lun0/disc which always points to id 6, even when other disks are added or removed. Even with the correct disc name for MBR, you have to tell LILO which is the boot disc, otherwise it assumes the first disc is boot. From owner-linux-xfs@oss.sgi.com Tue Jun 12 04:44:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CBiPm30475 for linux-xfs-outgoing; Tue, 12 Jun 2001 04:44:25 -0700 Received: from gwa2.fe.bosch.de (gwa2.fe.bosch.de [194.39.218.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CBiNV30470 for ; Tue, 12 Jun 2001 04:44:24 -0700 Received: (from uucp@localhost) by gwa2.fe.bosch.de (8.10.2/8.10.2) id f5CBj3A03320 for ; Tue, 12 Jun 2001 11:45:03 GMT X-Authentication-Warning: gwa2.fe.bosch.de: uucp set sender to using -f Received: from fez8020.fe.internet.bosch.com(virus-out2.fe.internet.bosch.de 10.4.4.20) by gwa2.fe.bosch.de via smap (V2.1) id xma002437; Tue, 12 Jun 01 11:43:51 GMT Received: from 135.1.8.1 by fez8020.fe.internet.bosch.com (InterScan E-Mail VirusWall NT); Tue, 12 Jun 2001 13:29:33 +0200 (W. Europe Daylight Time) Received: from flo.sh.bosch.de ([135.1.69.188]) by topas.flo.sh.bosch.de (8.8.8/8.8.8) with ESMTP id NAA23291; Tue, 12 Jun 2001 13:41:03 +0200 (MET DST) Message-ID: <3B260040.B3AB8F2@flo.sh.bosch.de> Date: Tue, 12 Jun 2001 13:42:56 +0200 From: Juergen Hasch Organization: Robert Bosch GmbH X-Mailer: Mozilla 4.75 [de] (WinNT; U) X-Accept-Language: de MIME-Version: 1.0 To: dahouet@gmx.net CC: linux-xfs@oss.sgi.com Subject: Re: xfs + samba Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >I'm a french sys adm. I've installed xfs on my server on / and /home >and i'm pretty happy with that (see previous posts) > >but i'm not sure it the right place but maybe somebody was >confronted with this problem. > >I'm about to make my server a PDC. > >I can't access file with accentuated characters via samba >i can see the files but "file not found" in the samba log >however i have in my smb.conf > client code page = 850 > character set = ISO8859-1 No problems with XFS and Samba here. We have lots of files containing Umlaute and it works very well. You might try one of the samba mailing lists at http://de.samba.org/samba/archives.html There seems to be a french one, too. ...Juergen From owner-linux-xfs@oss.sgi.com Tue Jun 12 06:32:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CDWZm04202 for linux-xfs-outgoing; Tue, 12 Jun 2001 06:32:35 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CDWXV04199 for ; Tue, 12 Jun 2001 06:32:33 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA16944 for ; Tue, 12 Jun 2001 06:32:30 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA2131350; Tue, 12 Jun 2001 08:31:15 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA29242; Tue, 12 Jun 2001 08:31:08 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5CDYOt20352; Tue, 12 Jun 2001 08:34:24 -0500 Message-Id: <200106121334.f5CDYOt20352@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Micah Yoder cc: Juha Saarinen , "linux-xfs@oss.sgi.com" Subject: Re: Stability of the Red Hat 7.1 + XFS system In-Reply-To: Message from Micah Yoder of "Mon, 11 Jun 2001 16:59:38 EDT." <0106111659380F.01070@eclipse> Date: Tue, 12 Jun 2001 08:34:24 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Well, they got the server back up. Said /etc/rc.d/rc.local was "complete > gobledegook". Define gobbledegook i.e. what was in there, was it all zeros? Also, is root on xfs or not. The unfortunate thing is that so far the only way to upgrade from the rpms is to build your own kernel. The cvs tree is currently at 2.4.6-pre2, there is a patch against 2.4.5 on the ftp site in the patches directory. There are a lot of xfs fixes in this since the 1.0 release. I cannot remember exactly what compiler was used to build the kernel rpms, it should have been the egcs-2.91.66 version, but I was not directly involved so I cannot be sure. > > I'm back in and everything else seems to be in OK shape. > > Is there a fairly straightforward way to upgrade the kernel and XFS? I'm a > little wary of using 2.4.5 because of the swapping issues. But it might be > worth a shot. What swapping issues - swapping in 2.4.5 is no different than previous 2.4 versions, it is just people started commenting on it. The 2.4.6-pre2 kernel does have changes in it to make swapoff go faster if that is your concern. > > > Well, check the Linux mailing lists -- reading those, and having battled > > with a Tyan Tiger 133 for ages now, I would be extremely hesistant depend > > on anything with a VIA chip set onboard. I'm sure that they'll get it > > right at some point, but at the moment, stability and reliability still > > seems to equal Intel, and then preferably a 440BX chip set. > > well I certainly can't replace the motherboard. Unless things *really* get > bad and that's the only possible solution. There is nothing about XFS which should be directly affected by the particular type of motherboard you have. XFS may stress the system in different manners, and expose kernel/bios/hardware bugs that ext2 would not. However, if a board works without problems on Linux normally, but is crashing with XFS then I would say the most likely explaination is that you have an I/O load which is triggering a bug in XFS. Without some form of oops message (decoded) or a stack backtrace from kdb, there is not much we can do to diagnose the problem. There is a good chance that running the latest kernel will make the problem 'go away' since we have fixed a lot of problems. However, your situation with being so far from the machine does not make it easy to do experiments with different kernels. > > If this happens again I'll probably just have them install Debian + ext2. Steve From owner-linux-xfs@oss.sgi.com Tue Jun 12 06:38:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CDcH204387 for linux-xfs-outgoing; Tue, 12 Jun 2001 06:38:17 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CDcGV04384 for ; Tue, 12 Jun 2001 06:38:16 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA00031 for ; Tue, 12 Jun 2001 06:18:22 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA2115373; Tue, 12 Jun 2001 08:17:05 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA97565; Tue, 12 Jun 2001 08:17:05 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5CDKKD20224; Tue, 12 Jun 2001 08:20:21 -0500 Message-Id: <200106121320.f5CDKKD20224@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Juha Saarinen" cc: linux-xfs@oss.sgi.com Subject: Re: Today's CVS doesn't compile In-Reply-To: Message from "Juha Saarinen" of "Tue, 12 Jun 2001 13:33:06 +1200." <005501c0f2df$a16da480$0a01a8c0@den2> Date: Tue, 12 Jun 2001 08:20:20 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Yes, I used kgcc. CVS about an hour ago. > > gcc -V egcs-2.91.66 -D__ASSEMBLY__ -D__KERNEL__ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -traditional -c > trampoline.S -o trampoline.o > /tmp/ccaQiW2d.s: Assembler messages: > /tmp/ccaQiW2d.s:868: Error: suffix or operands invalid for `ljmp' > make[1]: *** [trampoline.o] Error 1 > make[1]: Leaving directory > `/usr/src/xfs-cvs/linux-2.4-xfs/linux/arch/i386/kernel' > make: *** [_dir_arch/i386/kernel] Error 2 > > > -- Juha Hmm, builds here, looks like a tools problem on your end - this is also a file we have never touched, you are looking at vanilla 2.4.6-pre2 code there. Steve From owner-linux-xfs@oss.sgi.com Tue Jun 12 06:59:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CDxrv04892 for linux-xfs-outgoing; Tue, 12 Jun 2001 06:59:53 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CDxpV04889 for ; Tue, 12 Jun 2001 06:59:51 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5CDxPV04764; Tue, 12 Jun 2001 15:59:26 +0200 Message-Id: <4.3.2.7.2.20010612155601.039283b0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Jun 2001 15:59:10 +0200 To: Steve Lord , Micah Yoder From: Seth Mos Subject: Re: Stability of the Red Hat 7.1 + XFS system Cc: Juha Saarinen , "linux-xfs@oss.sgi.com" In-Reply-To: <200106121334.f5CDYOt20352@jen.americas.sgi.com> References: <0106111659380F.01070@eclipse> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 08:34 12-6-2001 -0500, Steve Lord wrote: > > > Well, check the Linux mailing lists -- reading those, and having battled > > > with a Tyan Tiger 133 for ages now, I would be extremely hesistant depend > > > on anything with a VIA chip set onboard. I'm sure that they'll get it > > > right at some point, but at the moment, stability and reliability still > > > seems to equal Intel, and then preferably a 440BX chip set. > > > > well I certainly can't replace the motherboard. Unless things *really* > get > > bad and that's the only possible solution. > >There is nothing about XFS which should be directly affected by the particular >type of motherboard you have. XFS may stress the system in different manners, >and expose kernel/bios/hardware bugs that ext2 would not. However, if a >board works >without problems on Linux normally, but is crashing with XFS then I would say >the most likely explaination is that you have an I/O load which is >triggering a >bug in XFS. Without some form of oops message (decoded) or a stack backtrace >from kdb, there is not much we can do to diagnose the problem. There is a good >chance that running the latest kernel will make the problem 'go away' since >we have fixed a lot of problems. However, your situation with being so far >from >the machine does not make it easy to do experiments with different kernels. See http://kt.zork.net/kernel-traffic/kt20010611_121.html#5 This explains the problems people are seeing on VIA boards. These are general not XFS related issues. It's just that the 2.4.2 1.0 misses a lot of updates to handle the VIA chipsets. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Jun 12 07:00:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CE0AD04926 for linux-xfs-outgoing; Tue, 12 Jun 2001 07:00:10 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CE09V04923 for ; Tue, 12 Jun 2001 07:00:09 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5CE01V04771; Tue, 12 Jun 2001 16:00:01 +0200 Message-Id: <4.3.2.7.2.20010612155918.03931b00@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Jun 2001 15:59:46 +0200 To: Steve Lord , "Juha Saarinen" From: Seth Mos Subject: Re: Today's CVS doesn't compile Cc: linux-xfs@oss.sgi.com In-Reply-To: <200106121320.f5CDKKD20224@jen.americas.sgi.com> References: <005501c0f2df$a16da480$0a01a8c0@den2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 08:20 12-6-2001 -0500, Steve Lord wrote: > > Yes, I used kgcc. CVS about an hour ago. > > > > > gcc -V egcs-2.91.66 -D__ASSEMBLY__ -D__KERNEL__ > > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -traditional -c > > trampoline.S -o trampoline.o > > /tmp/ccaQiW2d.s: Assembler messages: > > /tmp/ccaQiW2d.s:868: Error: suffix or operands invalid for `ljmp' > > make[1]: *** [trampoline.o] Error 1 > > make[1]: Leaving directory > > `/usr/src/xfs-cvs/linux-2.4-xfs/linux/arch/i386/kernel' > > make: *** [_dir_arch/i386/kernel] Error 2 > > > > > > -- Juha > > >Hmm, builds here, looks like a tools problem on your end - this is also a file >we have never touched, you are looking at vanilla 2.4.6-pre2 code there. See "My kernel does not compile in the FAQ" Good luck -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Jun 12 07:18:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CEI6p05430 for linux-xfs-outgoing; Tue, 12 Jun 2001 07:18:06 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CEI5V05427 for ; Tue, 12 Jun 2001 07:18:06 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA09365 for ; Tue, 12 Jun 2001 07:18:04 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id AAA24905; Wed, 13 Jun 2001 00:18:02 +1000 Date: Wed, 13 Jun 2001 00:18:02 +1000 From: Keith Owens Message-Id: <200106121418.AAA24905@sherman.melbourne.sgi.com> Subject: TAKE - Check return code from md.c:blk_ioctl Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk As suggested on one of the XFS lists, I asked the affected maintainers to check the BLKBSZGET and BLKBSZSET changes. Andries Brouwer pointed out ----- Index: 6-pre1.1/drivers/md/md.c + case BLKBSZGET: + case BLKBSZSET: + blk_ioctl (dev, cmd, arg); + goto done; ---- where clearly the return status from blk_ioctl must be returned, that is, the code should be err=blk_ioctl(); goto done_unlock; Code changed accordingly. Date: Tue Jun 12 07:14:49 PDT 2001 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:96720a linux/drivers/md/md.c - 1.14 From owner-linux-xfs@oss.sgi.com Tue Jun 12 07:50:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CEob206637 for linux-xfs-outgoing; Tue, 12 Jun 2001 07:50:37 -0700 Received: from solo.e-qual.net ([209.234.71.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CEoaV06634 for ; Tue, 12 Jun 2001 07:50:37 -0700 Received: from [24.182.250.249] (c1115231-c.hedend1.ia.home.com [24.182.250.249]) by solo.e-qual.net (8.9.3/8.8.5) with ESMTP id JAA17848 for ; Tue, 12 Jun 2001 09:49:08 -0500 Mime-Version: 1.0 X-Sender: johnr@209.234.71.137 Message-Id: Date: Tue, 12 Jun 2001 09:50:33 -0500 To: linux-xfs@oss.sgi.com From: John Roach Subject: Xfs issues on a sgi 1200 and 1450 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I have been trying to install the cvs full tree for xfs from sgi. I have found that the aix7xxx scsi driver will not compile as a module or as part of the kernel. This is a huge problem since this is the fondation scsi device on the 12 and 1450's. Any suggestions? If not, thats okay , I wanted to let you know. John roach Iowa SGI Sales Beacon Microcenter 515-224-1992 From owner-linux-xfs@oss.sgi.com Tue Jun 12 07:55:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CEtGt06932 for linux-xfs-outgoing; Tue, 12 Jun 2001 07:55:16 -0700 Received: from gargoyle (IDENT:root@gargoyle.gargoylecc.com [65.100.85.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CEtFV06929 for ; Tue, 12 Jun 2001 07:55:15 -0700 Received: from gargoyle ([127.0.0.1] helo=localhost ident=ringram) by gargoyle with esmtp (Exim 3.13 #1 (Debian)) id 159pcf-00013E-00; Tue, 12 Jun 2001 08:58:25 -0600 Date: Tue, 12 Jun 2001 08:58:24 -0600 (MDT) From: Russel Ingram X-X-Sender: To: Ivan Rayner cc: Subject: Re: xfsdump, paride tape, and -m option In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 12 Jun 2001, Ivan Rayner wrote: > On Sun, 10 Jun 2001, Russel Ingram wrote: > > > > The argument to -b should be bytes, so 16k would be 16384 not 16. > > > > > > If this doesn't fix your problem, could you use -v5 to get verbose output. > > > (This might produce alot of output, so you should redirect it to a file.) > > > > > > Ivan > > > > > Ok, I ran it again with the right sysntax on the -b option. Here's the > > command I gave it: > > > > xfsdump -v5 -m -b 32k -o -F -E -l0 -M"gumby" -L"tmp" -f /dev/tape -s tmp / > > The argument to -b should be bytes, so 32k would be '32768' not '32k'. > > Let me know if this helps. > > Ivan I am still having trouble getting the drive itself to work right so it's becoming more and more likely that this is a hardware problem rather than an xfsdump problem, but even with the correct syntax on the -b otion it still core dumps. Thanx for all your help so far. Here's the command I gave it this time: xfsdump -m -b 32768 -o -F -E -l0 -M"gumby" -L"tmp" -f /dev/tape -s tmp / Russ -- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Tue Jun 12 08:02:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CF2K007242 for linux-xfs-outgoing; Tue, 12 Jun 2001 08:02:20 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CF2IV07236 for ; Tue, 12 Jun 2001 08:02:18 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5CF23708938; Wed, 13 Jun 2001 01:02:04 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: John Roach cc: linux-xfs@oss.sgi.com Subject: Re: Xfs issues on a sgi 1200 and 1450 In-reply-to: Your message of "Tue, 12 Jun 2001 09:50:33 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Jun 2001 01:02:03 +1000 Message-ID: <8937.992358123@ocs4.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 12 Jun 2001 09:50:33 -0500, John Roach wrote: >I have been trying to install the cvs full tree for xfs from sgi. I >have found that the aix7xxx scsi driver will not compile as a module >or as part of the kernel. This is a huge problem since this is the >fondation scsi device on the 12 and 1450's. Any suggestions? If not, >thats okay , I wanted to let you know. This is a generic problem with the aic7xxx code, it is independent of XFS. Please take it up with the aic7xxx maintainer or linux-kernel. From owner-linux-xfs@oss.sgi.com Tue Jun 12 08:06:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CF6Ul07399 for linux-xfs-outgoing; Tue, 12 Jun 2001 08:06:30 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CF6TV07396 for ; Tue, 12 Jun 2001 08:06:29 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA01070 for ; Tue, 12 Jun 2001 08:06:49 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2131083; Tue, 12 Jun 2001 10:05:12 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA25486; Tue, 12 Jun 2001 10:05:11 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5CF8Q420589; Tue, 12 Jun 2001 10:08:26 -0500 Message-Id: <200106121508.f5CF8Q420589@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: John Roach cc: linux-xfs@oss.sgi.com Subject: Re: Xfs issues on a sgi 1200 and 1450 In-Reply-To: Message from John Roach of "Tue, 12 Jun 2001 09:50:33 CDT." Date: Tue, 12 Jun 2001 10:08:26 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hello, > > I have been trying to install the cvs full tree for xfs from sgi. I > have found that the aix7xxx scsi driver will not compile as a module > or as part of the kernel. This is a huge problem since this is the > fondation scsi device on the 12 and 1450's. Any suggestions? If not, > thats okay , I wanted to let you know. > > John roach > Iowa SGI Sales > Beacon Microcenter > 515-224-1992 Hmm, I am running on an aix7xxx based motherboard now, the driver does compile if you know the correct magic incantation. Generally you need to set the configuration option to build the driver firmware with the kernel, and in order to build the firmwaretools you need a db-devel package installed (db3-devel-3.1.14-6 in my case). Steve From owner-linux-xfs@oss.sgi.com Tue Jun 12 09:38:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CGcdg30267 for linux-xfs-outgoing; Tue, 12 Jun 2001 09:38:39 -0700 Received: from sphinx.druber.com (druber-gw.lightband.com [216.129.135.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CGccV30264 for ; Tue, 12 Jun 2001 09:38:38 -0700 Received: from SWARTZ-D.druber.com (SWARTZ-D.cac.stratus.com [134.111.43.114]) by sphinx.druber.com (Postfix) with ESMTP id 622D986E3 for ; Tue, 12 Jun 2001 12:36:25 -0400 (EDT) Message-Id: <5.1.0.14.2.20010612123605.040c6cb8@druber-gw.lightband.com> X-Sender: dswartz@druber-gw.lightband.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Jun 2001 12:38:31 -0400 To: linux-xfs@oss.sgi.com From: Dan Swartzendruber Subject: xfsdump vs tar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The common wisdom is that dump is dangerous to run on mounted filesystems. I do so for weekly backups on my home system, because it is scheduled for 2AM on Sunday morning, when things are relatively idle. I note from the man pages that xfsdump can only be run (apparently) on mounted filesystems. Is there anything fundamentally different about the implementation of xfsdump (for linux specifically) as opposed to the other dump programs (such as for ext2 filesystems) that makes this "safer"? From owner-linux-xfs@oss.sgi.com Tue Jun 12 09:48:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CGma830706 for linux-xfs-outgoing; Tue, 12 Jun 2001 09:48:36 -0700 Received: from c000.snv.cp.net (c000-h001.c000.snv.cp.net [209.228.32.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CGmZV30703 for ; Tue, 12 Jun 2001 09:48:35 -0700 Received: (cpmta 27656 invoked from network); 12 Jun 2001 09:48:30 -0700 Received: from amoa.org (HELO ?192.168.1.50?) (207.207.51.226) by smtp.tooley.com (209.228.32.65) with SMTP; 12 Jun 2001 09:48:30 -0700 X-Sent: 12 Jun 2001 16:48:30 GMT Subject: Re: Xfs issues on a sgi 1200 and 1450 From: Chris Tooley To: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.10.99 (Preview Release) Date: 12 Jun 2001 11:48:30 -0500 Message-Id: <992364510.3107.2.camel@itspec.amoa.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 12 Jun 2001 10:08:20 -0500, Steve Lord wrote: > > > > Hello, > > > > I have been trying to install the cvs full tree for xfs from sgi. I > > have found that the aix7xxx scsi driver will not compile as a module > > or as part of the kernel. This is a huge problem since this is the > > fondation scsi device on the 12 and 1450's. Any suggestions? If not, > > thats okay , I wanted to let you know. > > > > John roach > > Iowa SGI Sales > > Beacon Microcenter > > 515-224-1992 > > > Hmm, I am running on an aix7xxx based motherboard now, the driver does > compile > if you know the correct magic incantation. > > Generally you need to set the configuration option to build the driver > firmware > with the kernel, and in order to build the firmwaretools you need a > db-devel > package installed (db3-devel-3.1.14-6 in my case). > > Steve > > I have to say, I have and do run quite a few aic7xxx SCSI adapters and have never had a single problem with them. I keep hearing about how there are all kinds of issues, but I'm probably done 20-30 installations onto drives on these cards and never had a single issue. Would someone please enlighten me as to what is wrong with them? Chris Tooley From owner-linux-xfs@oss.sgi.com Tue Jun 12 10:07:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CH77h31116 for linux-xfs-outgoing; Tue, 12 Jun 2001 10:07:07 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CH75V31112 for ; Tue, 12 Jun 2001 10:07:05 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5CH6vI11116; Wed, 13 Jun 2001 03:06:57 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Chris Tooley cc: linux-xfs@oss.sgi.com Subject: Re: Xfs issues on a sgi 1200 and 1450 In-reply-to: Your message of "12 Jun 2001 11:48:30 EST." <992364510.3107.2.camel@itspec.amoa.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Jun 2001 03:06:57 +1000 Message-ID: <11115.992365617@ocs4.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 12 Jun 2001 11:48:30 -0500, Chris Tooley wrote: >I have to say, I have and do run quite a few aic7xxx SCSI adapters and >have never had a single problem with them. I keep hearing about how >there are all kinds of issues, but I'm probably done 20-30 installations >onto drives on these cards and never had a single issue. Would someone >please enlighten me as to what is wrong with them? The driver code works one compiled but the way it was "integrated" into the linux kernel build system leaves a lot to be desired. There are too many ways that aic7xx can fail to compile, or worse, be miscompiled and fail when the driver is used. I tried to show the aic7xxx maintainer how to do it correctly but he insisted on doing it his own way. What do I know, I'm just the kernel build maintainer. From owner-linux-xfs@oss.sgi.com Tue Jun 12 10:32:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CHWcq32002 for linux-xfs-outgoing; Tue, 12 Jun 2001 10:32:38 -0700 Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CHWaV31999 for ; Tue, 12 Jun 2001 10:32:37 -0700 Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:61332 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Tue, 12 Jun 2001 19:32:28 +0200 Message-Id: <4.3.2.7.2.20010612193034.02fc2210@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Jun 2001 19:32:19 +0200 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: severe fs corruption Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I just got feedback about the report with subject "Re: severe fs corruption" which was led back to a faulty memory Dimm. The report can be scuffed. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Jun 12 11:12:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CIC3U00559 for linux-xfs-outgoing; Tue, 12 Jun 2001 11:12:03 -0700 Received: from mail.cmdl.noaa.gov (IDENT:mailsrv@mail.cmdl.noaa.gov [140.172.192.208]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CIC1V00554 for ; Tue, 12 Jun 2001 11:12:01 -0700 Received: from cmdl.noaa.gov (blizzard.cmdl.noaa.gov [140.172.195.31]) by mail.cmdl.noaa.gov (Netscape Messaging Server 4.15) with ESMTP id GETX8000.KYM for ; Tue, 12 Jun 2001 12:12:00 -0600 Message-ID: <3B265B70.A5BCF044@cmdl.noaa.gov> Date: Tue, 12 Jun 2001 12:12:00 -0600 From: Kirk Thoning Organization: Climate Monitoring and Diagnostics Laboratory X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS and knfsd Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Has this issue been resolved? I am getting the same problem on a Redhat 7.1 system using the SGI kernel-2.4.2-SGI_XFS_1.0.i686.rpm. Almost all clients are Redhat 6.2 (~15 clients) with a couple 7.0 and 3 HP-UX 10.20. My impression is that the load wasn't that high, since it takes 1-2 weeks for this to occur. Here's my output: Jun 6 09:05:40 ccgg kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000010 Jun 6 09:05:40 ccgg kernel: printing eip: Jun 6 09:05:40 ccgg kernel: c88e7e83 Jun 6 09:05:40 ccgg kernel: pgd entry c793b000: 0000000000000000 Jun 6 09:05:40 ccgg kernel: pmd entry c793b000: 0000000000000000 Jun 6 09:05:40 ccgg kernel: ... pmd not present! Jun 6 09:05:40 ccgg kernel: Oops: 0000 Jun 6 09:05:40 ccgg kernel: CPU: 0 Jun 6 09:05:41 ccgg kernel: EIP: 0010:[ipchains:__insmod_ipchains_S.bss_L1076+564547/16321505] Jun 6 09:05:41 ccgg kernel: EIP: 0010:[] Jun 6 09:05:41 ccgg kernel: EFLAGS: 00010246 Jun 6 09:05:41 ccgg kernel: eax: 00000000 ebx: 00000000 ecx: c7fdadb0 edx: 00000010 Jun 6 09:05:41 ccgg kernel: esi: c31db5a0 edi: c31dbaa0 ebp: c31dbaa0 esp: c23f7edc Jun 6 09:05:41 ccgg kernel: ds: 0018 es: 0018 ss: 0018 Jun 6 09:05:41 ccgg kernel: Process nfsd (pid: 1005, stackpage=c23f7000) Jun 6 09:05:41 ccgg kernel: Stack: 00000003 0b01e79b c88e8286 c31dbaa0 00000003 c2338410 46000000 c2338400 Jun 6 09:05:41 ccgg kernel: c23f7f4c c7f56be0 c02fa000 ffffff8c 00000000 c88e8614 c7f56a00 0b01e79b Jun 6 09:05:41 ccgg kernel: 00000000 00000000 00000001 c2338400 c2338290 c2338490 c2338000 c24eb800 Jun 6 09:05:41 ccgg kernel: Call Trace: [ipchains:__insmod_ipchains_S.bss_L1076+565574/16320478] [ipchains:__insmod_i pchains_S.bss_L1076+566484/16319568] [ipchains:__insmod_ipchains_S.bss_L1076+559621/16326431] [ipchains:__insmod_ipcha ins_S.bss_L1076+624832/16261220] [ipchains:__insmod_ipchains_S.bss_L1076+558131/16327921] [ipchains:__insmod_ipchains_ S.bss_L1076+624832/16261220] [ipchains:__insmod_ipchains_S.bss_L1076+372168/16513884] Jun 6 09:05:41 ccgg kernel: Call Trace: [] [] [] [] [] [] [] Jun 6 09:05:41 ccgg kernel: [ipchains:__insmod_ipchains_S.bss_L1076+625984/16260068] [ipchains:__insmod_ipchai ns_S.bss_L1076+624648/16261404] [ipchains:__insmod_ipchains_S.bss_L1076+557553/16328499] [kernel_thread+35/48] Jun 6 09:05:41 ccgg kernel: [] [] [] [] Jun 6 09:05:41 ccgg kernel: Jun 6 09:05:41 ccgg kernel: Code: 8b 40 10 39 d0 74 21 8d 58 c8 39 f3 75 06 8b 5a 04 83 c3 c8 > > Are there any tricks to getting knfsd working with XFS? Our server which > serves an XFS partition gets an "oops" after about 15 hours of extremely > heavy use. I'm using the latest distro from CVS (2.4.3-XFS). Here's the > kdb output of the oops, just in case someone has any ideas on how to > debug this: > > Unable to handle kernel NULL pointer dereference at virtual address 00000000 > printing eip: > c0145933 > *pde = 00000000 > > Entering kdb (current=0xceffc000, pid 625) on processor 0 Oops: Oops > due to oops @ 0xc0145933 > eax = 0xcff9ae70 ebx = 0xffffffe8 ecx = 0x0000000f edx = 0xcff80000 > esi = 0x00000000 edi = 0xceffdeb4 esp = 0xceffde48 eip = 0xc0145933 > ebp = 0xceffde68 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010207 > xds = 0xcff80018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xceffde14 > [0]kdb> bt > EBP EIP Function(args) > 0xceffde68 0xc0145933 d_lookup+0x67 (0xc83e70c0, 0xceffdeb4) > kernel .text 0xc0100000 0xc01458cc 0xc01459e8 > 0xceffde7c 0xc013c911 cached_lookup+0x11 (0xc83e70c0, 0xceffdeb4, 0x0) > kernel .text 0xc0100000 0xc013c900 0xc013c954 > 0xceffdea0 0xc013d862 lookup_hash+0x52 (0xceffdeb4, 0xc83e70c0) > kernel .text 0xc0100000 0xc013d810 0xc013d914 > 0xceffdec0 0xc013d969 lookup_one+0x55 (0xc4b860e0, 0xc83e70c0) > kernel .text 0xc0100000 0xc013d914 0xc013d97c > 0xceffdf04 0xc016d882 nfsd_lookup+0x3b2 (0xcf05ac00, 0xcf05aa00, 0xc4b860e0, > 0x6, 0xcf05a800) > kernel .text 0xc0100000 0xc016d4d0 0xc016d9cc > 0xceffdf2c 0xc016b50b nfsd_proc_lookup+0x87 (0xcf05ac00, 0xcf05aa00, 0xcf05a8 > 00) > kernel .text 0xc0100000 0xc016b484 0xc016b520 > 0xceffdf4c 0xc016adf9 nfsd_dispatch+0xc5 (0xcf05ac00, 0xceff8014) > kernel .text 0xc0100000 0xc016ad34 0xc016ae90 > 0xceffdfa8 0xc0293bca svc_process+0x2ca (0xcfef5b20, 0xcf05ac00) > kernel .text 0xc0100000 0xc0293900 0xc0293e30 > 0xceffdfec 0xc016abba nfsd+0x1a2 > kernel .text 0xc0100000 0xc016aa18 0xc016ad34 > 0xc0105547 kernel_thread+0x23 > kernel .text 0xc0100000 0xc0105524 0xc010555c > > > Any help is appreciated. > > Ajay -- ************************************************************ * Kirk Thoning Phone: 303 497-6078 * * NOAA/CMDL Fax: 303 497-6290 * * R/CMDL1 e-mail: Kirk.W.Thoning@noaa.gov * * 325 Broadway * * Boulder, Colorado 80303 * ************************************************************ From owner-linux-xfs@oss.sgi.com Tue Jun 12 11:20:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CIK6T00898 for linux-xfs-outgoing; Tue, 12 Jun 2001 11:20:06 -0700 Received: from dmz.tecosim.de ([194.24.222.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CIK4V00895 for ; Tue, 12 Jun 2001 11:20:05 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f5CIC3U08929; Tue, 12 Jun 2001 20:12:03 +0200 Received: from ns.tecosim.de(194.24.222.9) via SMTP by dmz.tecosim.de, id smtpdzgkqKa; Tue Jun 12 20:11:54 2001 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with ESMTP id f5CIIii32717; Tue, 12 Jun 2001 20:18:44 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f5CIIiw18085; Tue, 12 Jun 2001 20:18:44 +0200 Date: Tue, 12 Jun 2001 20:18:44 +0200 From: Utz Lehmann To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: severe fs corruption Message-ID: <20010612201844.E1258@de.tecosim.com> References: <4.3.2.7.2.20010612193034.02fc2210@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010612193034.02fc2210@pop.xs4all.nl>; from knuffie@xs4all.nl on Tue, Jun 12, 2001 at 07:32:19PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi We also have a lot of trouble with bad DIMMs here. If something got strange, we do a RAM check first. We are using memtest86 (http://reality.sgi.com/cbrady_denver/memtest86/) which is really nice. Run it for a few passes. If there no errors, the trouble is caused by something else. If you got RAM errors, dont even think about another cause (until the RAM is fixed). utz Seth Mos [knuffie@xs4all.nl] wrote: > Hi, > > I just got feedback about the report with subject "Re: severe fs > corruption" which was led back to a faulty memory Dimm. > > The report can be scuffed. > > Cheers > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Jun 12 11:22:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CIM8r01026 for linux-xfs-outgoing; Tue, 12 Jun 2001 11:22:08 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CIM7V01020 for ; Tue, 12 Jun 2001 11:22:07 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id UAA00228; Tue, 12 Jun 2001 20:22:05 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id UAA26899; Tue, 12 Jun 2001 20:22:04 +0200 (CEST) Date: Tue, 12 Jun 2001 20:22:04 +0200 (CEST) From: Seth Mos To: Utz Lehmann cc: linux-xfs@oss.sgi.com Subject: Re: severe fs corruption In-Reply-To: <20010612201844.E1258@de.tecosim.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 12 Jun 2001, Utz Lehmann wrote: > Hi > > We also have a lot of trouble with bad DIMMs here. > > If something got strange, we do a RAM check first. We are using memtest86 > (http://reality.sgi.com/cbrady_denver/memtest86/) which is really nice. > Run it for a few passes. If there no errors, the trouble is caused by > something else. If you got RAM errors, dont even think about another cause > (until the RAM is fixed). The report was from a month ago or so. This is just a notification to the list that the cause was found. Sincerly Seth From owner-linux-xfs@oss.sgi.com Tue Jun 12 11:23:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CINWM01155 for linux-xfs-outgoing; Tue, 12 Jun 2001 11:23:32 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CINUV01152 for ; Tue, 12 Jun 2001 11:23:30 -0700 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA52344 for ; Tue, 12 Jun 2001 20:23:28 +0200 (CEST) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA56912; Tue, 12 Jun 2001 11:27:30 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 45E7B15A49F; Tue, 12 Jun 2001 11:21:53 -0700 (PDT) Subject: Re: XFS/Linux 1.1?? From: Florin Andrei To: Dan Swartzendruber Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain X-Mailer: Evolution/0.10 (Preview Release) Date: 12 Jun 2001 11:21:53 -0700 Message-Id: <992370113.26356.2.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 09 Jun 2001 23:36:03 -0400, Dan Swartzendruber wrote: > > well, what can i say. i really like quicken/2000 GNUCash? > if i can get a nice threaded mail client with IMAP support, > i'd move my mail from win98 to KDE in a flash. Evolution? http://www.ximian.com/apps/evolution.php3 (but that's offtopic...) -- Florin Andrei From owner-linux-xfs@oss.sgi.com Tue Jun 12 11:28:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CISon01304 for linux-xfs-outgoing; Tue, 12 Jun 2001 11:28:50 -0700 Received: from mr1.ash.ops.us.uu.net (mr1.ash.ops.us.uu.net [198.5.241.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CISnV01301 for ; Tue, 12 Jun 2001 11:28:49 -0700 Received: from mail.knightsbridge.com by mr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: www.knightsbridge.com [208.199.89.253]) id QQktcz23704; Tue, 12 Jun 2001 18:28:41 GMT Received: from duke.wrkhors.com ([128.5.32.250]) by mail.knightsbridge.com (Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) with SMTP id 86256A69.0064EEEE; Tue, 12 Jun 2001 13:22:27 -0500 Date: Tue, 12 Jun 2001 13:20:08 -0500 From: Steven Lembark To: Florin Andrei , Dan Swartzendruber cc: linux-xfs@oss.sgi.com Subject: Re: XFS/Linux 1.1?? Message-ID: <36940000.992370008@duke.wrkhors.com> In-Reply-To: <992370113.26356.2.camel@stantz.corp.sgi.com> X-Mailer: Mulberry/2.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> if i can get a nice threaded mail client with IMAP support, >> i'd move my mail from win98 to KDE in a flash. > > Evolution? Mulberry (see www.cyrusoft.com). -- Steven Lembark 2930 W. Palmer chicago, IL 60647 lembark@wrkhors.com +1 800 762 1582 From owner-linux-xfs@oss.sgi.com Tue Jun 12 11:29:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CITxv01424 for linux-xfs-outgoing; Tue, 12 Jun 2001 11:29:59 -0700 Received: from sphinx.druber.com (druber-gw.lightband.com [216.129.135.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CITwV01413 for ; Tue, 12 Jun 2001 11:29:58 -0700 Received: from SWARTZ-D.druber.com (SWARTZ-D.cac.stratus.com [134.111.43.114]) by sphinx.druber.com (Postfix) with ESMTP id 5785086E7; Tue, 12 Jun 2001 14:27:44 -0400 (EDT) Message-Id: <5.1.0.14.2.20010612142923.00b1eaf0@druber-gw.lightband.com> X-Sender: dswartz@druber-gw.lightband.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Jun 2001 14:29:47 -0400 To: Florin Andrei From: Dan Swartzendruber Subject: Re: XFS/Linux 1.1?? Cc: linux-xfs@oss.sgi.com In-Reply-To: <992370113.26356.2.camel@stantz.corp.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:21 AM 6/12/2001 -0700, Florin Andrei wrote: >On 09 Jun 2001 23:36:03 -0400, Dan Swartzendruber wrote: > > > > well, what can i say. i really like quicken/2000 > >GNUCash? not remotely close. > > if i can get a nice threaded mail client with IMAP support, > > i'd move my mail from win98 to KDE in a flash. > >Evolution? > >http://www.ximian.com/apps/evolution.php3 hmmm, i'll check that, thanks. From owner-linux-xfs@oss.sgi.com Tue Jun 12 11:37:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CIbIa01710 for linux-xfs-outgoing; Tue, 12 Jun 2001 11:37:18 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CIbHV01707 for ; Tue, 12 Jun 2001 11:37:17 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id UAA02998; Tue, 12 Jun 2001 20:37:16 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id UAA28353; Tue, 12 Jun 2001 20:37:15 +0200 (CEST) Date: Tue, 12 Jun 2001 20:37:15 +0200 (CEST) From: Seth Mos To: Kirk Thoning cc: linux-xfs@oss.sgi.com Subject: Re: XFS and knfsd In-Reply-To: <3B265B70.A5BCF044@cmdl.noaa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 12 Jun 2001, Kirk Thoning wrote: > Has this issue been resolved? I am getting the same problem on a Redhat > 7.1 system > using the SGI kernel-2.4.2-SGI_XFS_1.0.i686.rpm. Almost all clients are > Redhat 6.2 (~15 clients) with a couple 7.0 and 3 HP-UX 10.20. My > impression is that the load wasn't that high, since it takes 1-2 weeks > for this to occur. Try using 2.4.5 with the XFS patch on top that is available on the FTP site oss.sgi.com. 2.4.5 is better then 2.4.2 from the 1.0 release. It will take some time before a 1.0.1 release comes out. Maybe we can convince Steve to make a stable tree based on a full kernel releases. ;-) 2.4.4 or 2.4.5 and 2.4.6 when that comes out and a devel tree based on the latest -pre kernel. It will certainly be a bit more work but it would probably be easier when trying to make releases. Just my 2 euro cents. Cheers Seth k From owner-linux-xfs@oss.sgi.com Tue Jun 12 11:41:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CIflQ01911 for linux-xfs-outgoing; Tue, 12 Jun 2001 11:41:47 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CIfkV01908 for ; Tue, 12 Jun 2001 11:41:46 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA04729 for ; Tue, 12 Jun 2001 11:42:06 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2136852; Tue, 12 Jun 2001 13:40:29 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA31829; Tue, 12 Jun 2001 13:40:29 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f5CIhgL23312; Tue, 12 Jun 2001 13:43:42 -0500 Message-Id: <200106121843.f5CIhgL23312@jen.americas.sgi.com> Date: Tue, 12 Jun 2001 13:43:42 -0500 Subject: TAKE - fix highmem problem where ext2 oopses Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Finally fixed, this was a core Linux bug. Chris this should make your box happy I think. Date: Tue Jun 12 11:38:23 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:96754a linux/fs/buffer.c - 1.66 - Fix from Al and Linus, change condition when we put a buffer back onto free lists, skip buffers which have been freed from pages, let page_launder clean them up later. From owner-linux-xfs@oss.sgi.com Tue Jun 12 11:48:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CImSE02153 for linux-xfs-outgoing; Tue, 12 Jun 2001 11:48:28 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CImQV02150 for ; Tue, 12 Jun 2001 11:48:27 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA52830 for ; Tue, 12 Jun 2001 20:48:24 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2125712; Tue, 12 Jun 2001 13:47:06 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA93811; Tue, 12 Jun 2001 13:47:06 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5CIoIK23342; Tue, 12 Jun 2001 13:50:18 -0500 Message-Id: <200106121850.f5CIoIK23342@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Dan Swartzendruber cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump vs tar In-Reply-To: Message from Dan Swartzendruber of "Tue, 12 Jun 2001 12:38:31 EDT." <5.1.0.14.2.20010612123605.040c6cb8@druber-gw.lightband.com> Date: Tue, 12 Jun 2001 13:50:18 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > The common wisdom is that dump is dangerous to run on mounted > filesystems. I do so for weekly backups > on my home system, because it is scheduled for 2AM on Sunday morning, when > things are relatively idle. > I note from the man pages that xfsdump can only be run (apparently) on > mounted filesystems. Is there > anything fundamentally different about the implementation of xfsdump (for > linux specifically) as opposed to the > other dump programs (such as for ext2 filesystems) that makes this "safer"? > xfsdump does not use the block device interface to get to inodes, it uses a couple of special calls - one to scan all the inodes in the filesystem and one to open those inodes without using path names, should an inode change in between the two accesses then it is not placed in the dump. File data is read using the read system call, directory contents via getdents. So there is no issue with xfsdump looking under the covers the way the regular dump program does. There is an issue with xfsdump missing files created during the dump process - but the next dump should catch those. Steve From owner-linux-xfs@oss.sgi.com Tue Jun 12 11:52:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CIqUb02306 for linux-xfs-outgoing; Tue, 12 Jun 2001 11:52:30 -0700 Received: from sphinx.druber.com (druber-gw.lightband.com [216.129.135.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CIqTV02303 for ; Tue, 12 Jun 2001 11:52:29 -0700 Received: from SWARTZ-D.druber.com (SWARTZ-D.cac.stratus.com [134.111.43.114]) by sphinx.druber.com (Postfix) with ESMTP id 71AFB86E7; Tue, 12 Jun 2001 14:50:14 -0400 (EDT) Message-Id: <5.1.0.14.2.20010612145210.040d0ea0@druber-gw.lightband.com> X-Sender: dswartz@druber-gw.lightband.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Jun 2001 14:52:20 -0400 To: Steve Lord From: Dan Swartzendruber Subject: Re: xfsdump vs tar Cc: linux-xfs@oss.sgi.com In-Reply-To: <200106121850.f5CIoIK23342@jen.americas.sgi.com> References: <5.1.0.14.2.20010612123605.040c6cb8@druber-gw.lightband.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 01:50 PM 6/12/2001 -0500, Steve Lord wrote: > > > > The common wisdom is that dump is dangerous to run on mounted > > filesystems. I do so for weekly backups > > on my home system, because it is scheduled for 2AM on Sunday morning, when > > things are relatively idle. > > I note from the man pages that xfsdump can only be run (apparently) on > > mounted filesystems. Is there > > anything fundamentally different about the implementation of xfsdump (for > > linux specifically) as opposed to the > > other dump programs (such as for ext2 filesystems) that makes this "safer"? > > > >xfsdump does not use the block device interface to get to inodes, it >uses a couple of special calls - one to scan all the inodes in the >filesystem and one to open those inodes without using path names, >should an inode change in between the two accesses then it is not >placed in the dump. File data is read using the read system call, >directory contents via getdents. > >So there is no issue with xfsdump looking under the covers the way the >regular dump program does. There is an issue with xfsdump missing files >created during the dump process - but the next dump should catch those. great, thanks! From owner-linux-xfs@oss.sgi.com Tue Jun 12 12:01:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CJ19x02532 for linux-xfs-outgoing; Tue, 12 Jun 2001 12:01:09 -0700 Received: from ceasefire.bitstream.net (ceasefire.bitstream.net [216.243.128.220]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CJ18V02529 for ; Tue, 12 Jun 2001 12:01:08 -0700 Received: (qmail 7142 invoked from network); 12 Jun 2001 19:01:06 -0000 Received: from unknown (HELO sgi.com) (216.243.158.19) by ceasefire with SMTP; 12 Jun 2001 19:01:06 -0000 Message-ID: <3B266660.A4F03A03@sgi.com> Date: Tue, 12 Jun 2001 13:58:40 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Juha Saarinen CC: Micah Yoder , "linux-xfs@oss.sgi.com" Subject: Re: Stability of the Red Hat 7.1 + XFS system References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juha Saarinen wrote: > > But what is the kernel shipped on the CD compiled with? That's what I'm > > using. I know Red Hat uses 2.96 to compile their kernel, so I dunno if SGI > > did the same. > > I believe it's 2.91-66 for XFS 1.0. That's correct, kgcc a.k.a. egcs-2.91.66 was used to compile the RPMs on the 1.0 CD. They got filesystem errors on reboot? It'd be nice to have some idea of what it said, but I know that's tough in a co-located situation... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Jun 12 12:04:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CJ4JV02652 for linux-xfs-outgoing; Tue, 12 Jun 2001 12:04:19 -0700 Received: from barabas.bitstream.net (barabas.bitstream.net [216.243.128.159]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CJ4IV02649 for ; Tue, 12 Jun 2001 12:04:18 -0700 Received: (qmail 28600 invoked from network); 12 Jun 2001 19:04:16 -0000 Received: from unknown (HELO sgi.com) (216.243.158.19) by barabas with SMTP; 12 Jun 2001 19:04:16 -0000 Message-ID: <3B26671E.A35F2F3E@sgi.com> Date: Tue, 12 Jun 2001 14:01:50 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Micah Yoder CC: Juha Saarinen , "linux-xfs@oss.sgi.com" Subject: Re: Stability of the Red Hat 7.1 + XFS system References: <0106111659380F.01070@eclipse> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Micah Yoder wrote: > > Well, they got the server back up. Said /etc/rc.d/rc.local was "complete > gobledegook". Is that the technical term? :) Was it full of null characters? i.e. ^0^0^0^0^0^0.... in vi? That could be a pre-allocated / null-character filled file if the data on rc.local had been changed, but had not flushed to disk, when the box hung. > I'm back in and everything else seems to be in OK shape. > > Is there a fairly straightforward way to upgrade the kernel and XFS? I'm a > little wary of using 2.4.5 because of the swapping issues. But it might be > worth a shot. We'll have RPM upgrades in the hopefully not-too-distant future. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Jun 12 12:09:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CJ9Yj02822 for linux-xfs-outgoing; Tue, 12 Jun 2001 12:09:34 -0700 Received: from barabas.bitstream.net (barabas.bitstream.net [216.243.128.159]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CJ9YV02817 for ; Tue, 12 Jun 2001 12:09:34 -0700 Received: (qmail 30836 invoked from network); 12 Jun 2001 19:09:33 -0000 Received: from unknown (HELO sgi.com) (216.243.158.19) by barabas with SMTP; 12 Jun 2001 19:09:33 -0000 Message-ID: <3B26685A.893C057A@sgi.com> Date: Tue, 12 Jun 2001 14:07:06 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Chris Szilagyi CC: linux-xfs@oss.sgi.com Subject: Re: quota support References: <3B2569D2.2760D6AA@pilot.msu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Chris - there were issues with quota support on the Red Hat / XFS RPMs in 1.0, peruse the list archives for details and patches... it's been fixed in CVS for some time, need to get those updated RPMs out... -Eric Chris Szilagyi wrote: > I'm trying to get quotas to work on an XFS partition but no luck. > Any issues with xfs quotas on Red Hat 7.1 or something that I may not be > doing right? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Jun 12 12:12:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CJCWe03025 for linux-xfs-outgoing; Tue, 12 Jun 2001 12:12:32 -0700 Received: from femail11.sdc1.sfba.home.com (femail11.sdc1.sfba.home.com [24.0.95.107]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CJCWV03022 for ; Tue, 12 Jun 2001 12:12:32 -0700 Received: from eclipse ([65.4.56.167]) by femail11.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010612191229.KAAP26560.femail11.sdc1.sfba.home.com@eclipse> for ; Tue, 12 Jun 2001 12:12:29 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Micah Yoder To: "linux-xfs@oss.sgi.com" Subject: Re: Stability of the Red Hat 7.1 + XFS system Date: Tue, 12 Jun 2001 12:13:26 -0400 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01061212132601.01097@eclipse> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks for the info everyone. I'm going to re-compile the kernel and hope things work better. I grabbed the CVS development version ... is that insane? :-) If it's working for all of you then I trust it! I'd like to compile it on my home box, to eliminate the possibility of something in the kernel compile triggering the bug on my server. I'm wondering how muc of a mess it will be to move ... will I just need to scp over the bzImage and the /lib/modules directory? And there's probably no way to do that without installing the kernel and modules on my home box (but not booting with it). What about all the additional programs? Do they need to be updated? There doesn't appear to be a way to build them all at once. Any tips on getting them all compiled and moved over? Thanks! Micah From owner-linux-xfs@oss.sgi.com Tue Jun 12 12:17:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CJHLE03250 for linux-xfs-outgoing; Tue, 12 Jun 2001 12:17:21 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CJHJV03243 for ; Tue, 12 Jun 2001 12:17:20 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id VAA10918; Tue, 12 Jun 2001 21:17:18 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id VAA02049; Tue, 12 Jun 2001 21:17:17 +0200 (CEST) Date: Tue, 12 Jun 2001 21:17:17 +0200 (CEST) From: Seth Mos To: Eric Sandeen cc: Juha Saarinen , Micah Yoder , "linux-xfs@oss.sgi.com" Subject: Re: Stability of the Red Hat 7.1 + XFS system In-Reply-To: <3B266660.A4F03A03@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 12 Jun 2001, Eric Sandeen wrote: > Juha Saarinen wrote: > > > > > But what is the kernel shipped on the CD compiled with? That's what I'm > > > using. I know Red Hat uses 2.96 to compile their kernel, so I dunno if SGI > > > did the same. > > > > I believe it's 2.91-66 for XFS 1.0. > > That's correct, kgcc a.k.a. egcs-2.91.66 was used to compile the RPMs on > the 1.0 CD. > > They got filesystem errors on reboot? It'd be nice to have some idea of > what it said, but I know that's tough in a co-located situation... See if you can recover /var/log/boot.log. Dis lists als the output generated during bootup of the system. Seth From owner-linux-xfs@oss.sgi.com Tue Jun 12 14:02:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CJfa604017 for linux-xfs-outgoing; Tue, 12 Jun 2001 12:41:36 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CJfXV04012 for ; Tue, 12 Jun 2001 12:41:34 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip19.idcomm.com [209.60.72.146]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5CJeuB01824 for ; Tue, 12 Jun 2001 13:40:57 -0600 Message-ID: <3B2670A5.35327B6F@idcomm.com> Date: Tue, 12 Jun 2001 13:42:29 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: XFS and knfsd References: <3B265B70.A5BCF044@cmdl.noaa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At one point I had the NULL pointer dereference at the same address during boot of a new kernel, which did not have SGI patches. It appeared to be aic7xxx failure, but was not. I keep mentioning this one patch which is part of Alan Cox's ac 2.4.5 series, but which is not yet in the main kernel source. Even if you cannot use this patch at all times, can you test the following? In linux source, fs/block_dev.c, near line 596 (depending on kernel version), there is a function "ioctl_by_bdev". In that function, add the line I have below that starts with "+" (don't use the "+"): int ioctl_by_bdev(struct block_device *bdev, unsigned cmd, unsigned long arg) { kdev_t rdev = to_kdev_t(bdev->bd_dev); struct inode inode_fake; int res; mm_segment_t old_fs = get_fs(); if (!bdev->bd_op->ioctl) return -EINVAL; inode_fake.i_rdev=rdev; + inode_fake.i_bdev=bdev; init_waitqueue_head(&inode_fake.i_wait); set_fs(KERNEL_DS); res = bdev->bd_op->ioctl(&inode_fake, NULL, cmd, arg); set_fs(old_fs); return res; } Please note that on my SMP system, several kernel versions or combinations die at bootup while trying to work with filesystems. Without this, loopback encrypted partitions are also very likely to do a hard lockup on this machine (about 90% of loopback encrypted partition commands caused lockup). I have added this to every kernel since then that I have used, and never seen the Oops again. Here is my first Oops (no ksymoops because it was fatal and unbootable) without XFS: Trying to unmount old root ... <1>Unable to handle kernel NULL pointer dereference at virtual address 00000010 printing eip: c01c5bda *pde = 00000000 Oops: 0000 CPU: 1 EIP: 0010:[] EFLAGS: 00010202 eax: 00000000 ebx: 00000000 ecx: 00001261 edx: c1479d98 esi: 00000000 edi: c1479e2c ebp: ffffffff esp: c1479d68 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 1, stackpage=c1479000) Stack: c1478000 cfe97f60 c1479e2c c013b0fb c1479d98 00000000 00001261 00000000 cfeac560 00000000 fffffffe cfe97f60 cff06ea4 cff06e10 c0346340 0001def6 cfef0001 c01ea7b2 cff06e00 00000082 00000202 c14e1cb8 cfef8200 cff07e60 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 40 10 83 f8 02 7e 0e b8 f0 ff ff ff eb 7e 8d b4 26 00 00 Kernel panic: Attempted to kill init! While it is quite possible these are not the same thing, it is still fatal in some filesystem cases if this fix is not added (with or without XFS, it is a general bug). D. Stimits, stimits@idcomm.com PS: I'm in the Boulder area too. Kirk Thoning wrote: > > Has this issue been resolved? I am getting the same problem on a Redhat > 7.1 system > using the SGI kernel-2.4.2-SGI_XFS_1.0.i686.rpm. Almost all clients are > Redhat 6.2 (~15 clients) with a couple 7.0 and 3 HP-UX 10.20. My > impression is that the load wasn't that high, since it takes 1-2 weeks > for this to occur. > > Here's my output: > > Jun 6 09:05:40 ccgg kernel: Unable to handle kernel NULL pointer > dereference at virtual address 00000010 > Jun 6 09:05:40 ccgg kernel: printing eip: > Jun 6 09:05:40 ccgg kernel: c88e7e83 > Jun 6 09:05:40 ccgg kernel: pgd entry c793b000: 0000000000000000 > Jun 6 09:05:40 ccgg kernel: pmd entry c793b000: 0000000000000000 > Jun 6 09:05:40 ccgg kernel: ... pmd not present! > Jun 6 09:05:40 ccgg kernel: Oops: 0000 > Jun 6 09:05:40 ccgg kernel: CPU: 0 > Jun 6 09:05:41 ccgg kernel: EIP: > 0010:[ipchains:__insmod_ipchains_S.bss_L1076+564547/16321505] > Jun 6 09:05:41 ccgg kernel: EIP: 0010:[] > Jun 6 09:05:41 ccgg kernel: EFLAGS: 00010246 > Jun 6 09:05:41 ccgg kernel: eax: 00000000 ebx: 00000000 ecx: > c7fdadb0 edx: 00000010 > Jun 6 09:05:41 ccgg kernel: esi: c31db5a0 edi: c31dbaa0 ebp: > c31dbaa0 esp: c23f7edc > Jun 6 09:05:41 ccgg kernel: ds: 0018 es: 0018 ss: 0018 > Jun 6 09:05:41 ccgg kernel: Process nfsd (pid: 1005, > stackpage=c23f7000) > Jun 6 09:05:41 ccgg kernel: Stack: 00000003 0b01e79b c88e8286 c31dbaa0 > 00000003 c2338410 46000000 c2338400 > Jun 6 09:05:41 ccgg kernel: c23f7f4c c7f56be0 c02fa000 ffffff8c > 00000000 c88e8614 c7f56a00 0b01e79b > Jun 6 09:05:41 ccgg kernel: 00000000 00000000 00000001 c2338400 > c2338290 c2338490 c2338000 c24eb800 > Jun 6 09:05:41 ccgg kernel: Call Trace: > [ipchains:__insmod_ipchains_S.bss_L1076+565574/16320478] > [ipchains:__insmod_i > pchains_S.bss_L1076+566484/16319568] > [ipchains:__insmod_ipchains_S.bss_L1076+559621/16326431] > [ipchains:__insmod_ipcha > ins_S.bss_L1076+624832/16261220] > [ipchains:__insmod_ipchains_S.bss_L1076+558131/16327921] > [ipchains:__insmod_ipchains_ > S.bss_L1076+624832/16261220] > [ipchains:__insmod_ipchains_S.bss_L1076+372168/16513884] > Jun 6 09:05:41 ccgg kernel: Call Trace: [] [] > [] [] [] [] > [] > Jun 6 09:05:41 ccgg kernel: > [ipchains:__insmod_ipchains_S.bss_L1076+625984/16260068] > [ipchains:__insmod_ipchai > ns_S.bss_L1076+624648/16261404] > [ipchains:__insmod_ipchains_S.bss_L1076+557553/16328499] > [kernel_thread+35/48] > Jun 6 09:05:41 ccgg kernel: [] [] > [] [] > Jun 6 09:05:41 ccgg kernel: > Jun 6 09:05:41 ccgg kernel: Code: 8b 40 10 39 d0 74 21 8d 58 c8 39 f3 > 75 06 8b 5a 04 83 c3 c8 > > > > > Are there any tricks to getting knfsd working with XFS? Our server which > > serves an XFS partition gets an "oops" after about 15 hours of extremely > > heavy use. I'm using the latest distro from CVS (2.4.3-XFS). Here's the > > kdb output of the oops, just in case someone has any ideas on how to > > debug this: > > > > Unable to handle kernel NULL pointer dereference at virtual address 00000000 > > printing eip: > > c0145933 > > *pde = 00000000 > > > > Entering kdb (current=0xceffc000, pid 625) on processor 0 Oops: Oops > > due to oops @ 0xc0145933 > > eax = 0xcff9ae70 ebx = 0xffffffe8 ecx = 0x0000000f edx = 0xcff80000 > > esi = 0x00000000 edi = 0xceffdeb4 esp = 0xceffde48 eip = 0xc0145933 > > ebp = 0xceffde68 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010207 > > xds = 0xcff80018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xceffde14 > > [0]kdb> bt > > EBP EIP Function(args) > > 0xceffde68 0xc0145933 d_lookup+0x67 (0xc83e70c0, 0xceffdeb4) > > kernel .text 0xc0100000 0xc01458cc 0xc01459e8 > > 0xceffde7c 0xc013c911 cached_lookup+0x11 (0xc83e70c0, 0xceffdeb4, 0x0) > > kernel .text 0xc0100000 0xc013c900 0xc013c954 > > 0xceffdea0 0xc013d862 lookup_hash+0x52 (0xceffdeb4, 0xc83e70c0) > > kernel .text 0xc0100000 0xc013d810 0xc013d914 > > 0xceffdec0 0xc013d969 lookup_one+0x55 (0xc4b860e0, 0xc83e70c0) > > kernel .text 0xc0100000 0xc013d914 0xc013d97c > > 0xceffdf04 0xc016d882 nfsd_lookup+0x3b2 (0xcf05ac00, 0xcf05aa00, 0xc4b860e0, > > 0x6, 0xcf05a800) > > kernel .text 0xc0100000 0xc016d4d0 0xc016d9cc > > 0xceffdf2c 0xc016b50b nfsd_proc_lookup+0x87 (0xcf05ac00, 0xcf05aa00, 0xcf05a8 > > 00) > > kernel .text 0xc0100000 0xc016b484 0xc016b520 > > 0xceffdf4c 0xc016adf9 nfsd_dispatch+0xc5 (0xcf05ac00, 0xceff8014) > > kernel .text 0xc0100000 0xc016ad34 0xc016ae90 > > 0xceffdfa8 0xc0293bca svc_process+0x2ca (0xcfef5b20, 0xcf05ac00) > > kernel .text 0xc0100000 0xc0293900 0xc0293e30 > > 0xceffdfec 0xc016abba nfsd+0x1a2 > > kernel .text 0xc0100000 0xc016aa18 0xc016ad34 > > 0xc0105547 kernel_thread+0x23 > > kernel .text 0xc0100000 0xc0105524 0xc010555c > > > > > > Any help is appreciated. > > > > Ajay > > -- > ************************************************************ > * Kirk Thoning Phone: 303 497-6078 * > * NOAA/CMDL Fax: 303 497-6290 * > * R/CMDL1 e-mail: Kirk.W.Thoning@noaa.gov * > * 325 Broadway * > * Boulder, Colorado 80303 * > ************************************************************ From owner-linux-xfs@oss.sgi.com Tue Jun 12 14:12:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CLCY702511 for linux-xfs-outgoing; Tue, 12 Jun 2001 14:12:34 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CLCXP02506 for ; Tue, 12 Jun 2001 14:12:33 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA01838 for ; Tue, 12 Jun 2001 13:52:52 -0700 (PDT) mail_from (juha@saarinen.org) Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 159v4k-0006n9-00; Wed, 13 Jun 2001 08:47:46 +1200 Date: Wed, 13 Jun 2001 08:47:46 +1200 (NZST) From: Juha Saarinen To: Steve Lord cc: "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-Reply-To: <200106121320.f5CDKKD20224@jen.americas.sgi.com> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 12 Jun 2001, Steve Lord wrote: > Hmm, builds here, looks like a tools problem on your end - this is also a file > we have never touched, you are looking at vanilla 2.4.6-pre2 code there. Which tool(s) would that be? Do I need to upgrade something...? Binutils? -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Tue Jun 12 14:22:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CLM3B04258 for linux-xfs-outgoing; Tue, 12 Jun 2001 14:22:03 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CLM2P04253 for ; Tue, 12 Jun 2001 14:22:02 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA06189 for ; Tue, 12 Jun 2001 13:53:10 -0700 (PDT) mail_from (knuffie@xs4all.nl) Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id VAA17762; Tue, 12 Jun 2001 21:49:37 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id VAA04645; Tue, 12 Jun 2001 21:49:37 +0200 (CEST) Date: Tue, 12 Jun 2001 21:49:36 +0200 (CEST) From: Seth Mos To: Micah Yoder cc: "linux-xfs@oss.sgi.com" Subject: Re: Stability of the Red Hat 7.1 + XFS system In-Reply-To: <01061212132601.01097@eclipse> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 12 Jun 2001, Micah Yoder wrote: > Thanks for the info everyone. I'm going to re-compile the kernel and hope > things work better. I grabbed the CVS development version ... is that > insane? :-) If it's working for all of you then I trust it! > > I'd like to compile it on my home box, to eliminate the possibility of > something in the kernel compile triggering the bug on my server. I'm If the hardware is sane, that should not be too much of a problem. It takes about 15 minutes on my Athlon 500 with 256MB ram. You should be able to survive at least that. > wondering how muc of a mess it will be to move ... will I just need to scp > over the bzImage and the /lib/modules directory? And there's probably no way > to do that without installing the kernel and modules on my home box (but not > booting with it). Just tar them and copy them over. tar -cjf linux-2.4.x-xfs.tar.bz2 /boot/*2.4.x-xfs* /lib/modules/2.4.x-xfs copy it over, unpack, edit lilo.conf, run lilo, make sure everything is there, cross fingers and reboot. You could also compile the bzImage and modules, tar the tree and copy it over, untar your tree and then run make modules_install && make install. Everything will then be put into place. You only have to edit lilo.conf, run lilo and reboot. > What about all the additional programs? Do they need to be updated? There > doesn't appear to be a way to build them all at once. Any tips on getting > them all compiled and moved over? They don't need to be but you can run ./Makepkgs in the cmd tree which will generate either rpms or debs of the util programs. > Thanks! > Micah Good Luck From owner-linux-xfs@oss.sgi.com Tue Jun 12 14:31:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CLV5U05863 for linux-xfs-outgoing; Tue, 12 Jun 2001 14:31:05 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CLV3P05852 for ; Tue, 12 Jun 2001 14:31:04 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA06402; Tue, 12 Jun 2001 23:31:02 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA03737; Tue, 12 Jun 2001 23:31:01 +0200 (CEST) Date: Tue, 12 Jun 2001 23:31:01 +0200 (CEST) From: Seth Mos To: "D. Stimits" cc: linux-xfs@oss.sgi.com Subject: Re: XFS and knfsd In-Reply-To: <3B2670A5.35327B6F@idcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 12 Jun 2001, D. Stimits wrote: > At one point I had the NULL pointer dereference at the same address > during boot of a new kernel, which did not have SGI patches. It appeared > to be aic7xxx failure, but was not. I keep mentioning this one patch > which is part of Alan Cox's ac 2.4.5 series, but which is not yet in the > main kernel source. Even if you cannot use this patch at all times, can > you test the following? In linux source, fs/block_dev.c, near line 596 > (depending on kernel version), there is a function "ioctl_by_bdev". In > that function, add the line I have below that starts with "+" (don't use > the "+"): I have only just setup NFS here at work but I will see if I can provoke some odd behaviour by putting the presure on the NFS server. The server is currently 2.4.6-pre1 based on my testing machine. I have run Bonnie with different sizes on this NFS mount and with 2 clients concurrently. I can't make it go boom yet. The 3Com 100Mbit switch at works is having a harder time then the actual NFS server which is a desktop machine. The clients are SMP and the server desktop machine is UP. The current CVS 2.4.6-pre2 tree at least contains the patch/fix mentioned above. The 2.4.6-pre1 tree does not contain this fix? The machines at work currently use this tree. And they did not crash yet. You seem to be using a ramdisk. Can you compile the kernel to get rid of that? (it's just that I don't like ramdisks). I personally compile all the important hardware drivers like network scsi and fs into the kernel. Seth From owner-linux-xfs@oss.sgi.com Tue Jun 12 14:32:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CLWuQ06237 for linux-xfs-outgoing; Tue, 12 Jun 2001 14:32:56 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CLWtP06230 for ; Tue, 12 Jun 2001 14:32:55 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA06775; Tue, 12 Jun 2001 23:32:53 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA03924; Tue, 12 Jun 2001 23:32:53 +0200 (CEST) Date: Tue, 12 Jun 2001 23:32:53 +0200 (CEST) From: Seth Mos To: Juha Saarinen cc: Steve Lord , "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001, Juha Saarinen wrote: > On Tue, 12 Jun 2001, Steve Lord wrote: > > > Hmm, builds here, looks like a tools problem on your end - this is also a file > > we have never touched, you are looking at vanilla 2.4.6-pre2 code there. > > Which tool(s) would that be? Do I need to upgrade something...? Binutils? ? Local Brain failure, aborting. Can you give some more details about what does not compile? It works for me. And I don't rememember anymore. Seth From owner-linux-xfs@oss.sgi.com Tue Jun 12 14:40:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CLeAZ07495 for linux-xfs-outgoing; Tue, 12 Jun 2001 14:40:10 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CLe7P07490 for ; Tue, 12 Jun 2001 14:40:09 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA60230 for ; Tue, 12 Jun 2001 23:40:04 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2139476 for ; Tue, 12 Jun 2001 16:38:46 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA69177 for ; Tue, 12 Jun 2001 16:38:45 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5CLgKi01300; Tue, 12 Jun 2001 16:42:20 -0500 Message-Id: <200106122142.f5CLgKi01300@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com Subject: Out for a few days Date: Tue, 12 Jun 2001 16:42:20 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I will be out of email contact for the remainder of the week, so coverage from this end will be thinner than ever until Monday. Please talk amongst yourselves for a while, and Eric will attempt to keep up when he can. Steve From owner-linux-xfs@oss.sgi.com Tue Jun 12 14:42:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CLgYr07990 for linux-xfs-outgoing; Tue, 12 Jun 2001 14:42:34 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CLgXP07987 for ; Tue, 12 Jun 2001 14:42:34 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA22605 for ; Tue, 12 Jun 2001 13:09:26 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2135703; Tue, 12 Jun 2001 15:08:11 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA65820; Tue, 12 Jun 2001 15:08:11 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5CKBNd04155; Tue, 12 Jun 2001 15:11:23 -0500 Message-Id: <200106122011.f5CKBNd04155@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Micah Yoder cc: "linux-xfs@oss.sgi.com" Subject: Re: Stability of the Red Hat 7.1 + XFS system In-Reply-To: Message from Micah Yoder of "Tue, 12 Jun 2001 12:13:26 EDT." <01061212132601.01097@eclipse> Date: Tue, 12 Jun 2001 15:11:23 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > What about all the additional programs? Do they need to be updated? There > doesn't appear to be a way to build them all at once. Any tips on getting > them all compiled and moved over? Each command subtree has a Makepkg command in it, this will build rpms for you. I am in the process of updating the ftp site with the latest command rpms, they should be showing up in a new directory in the xfs tree, cmd_rpms. I said in the process of, the stupid ftp server is down again! Steve > > Thanks! > Micah From owner-linux-xfs@oss.sgi.com Tue Jun 12 14:47:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CLlpj08988 for linux-xfs-outgoing; Tue, 12 Jun 2001 14:47:51 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CLloP08984 for ; Tue, 12 Jun 2001 14:47:50 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA05807 for ; Tue, 12 Jun 2001 14:47:49 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2117326; Tue, 12 Jun 2001 16:46:32 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA69552; Tue, 12 Jun 2001 16:46:32 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5CLo7t01402; Tue, 12 Jun 2001 16:50:07 -0500 Message-Id: <200106122150.f5CLo7t01402@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Micah Yoder , "linux-xfs@oss.sgi.com" Subject: Re: Stability of the Red Hat 7.1 + XFS system In-Reply-To: Message from Steve Lord of "Tue, 12 Jun 2001 15:11:23 CDT." <200106122011.f5CKBNd04155@jen.americas.sgi.com> Date: Tue, 12 Jun 2001 16:50:07 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > > > > What about all the additional programs? Do they need to be updated? There > > > doesn't appear to be a way to build them all at once. Any tips on getting > > them all compiled and moved over? > > Each command subtree has a Makepkg command in it, this will build rpms for > you. I am in the process of updating the ftp site with the latest command > rpms, they should be showing up in a new directory in the xfs tree, > cmd_rpms. > OK, they are out there: ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/ acl-1.0.5-0.i386.rpm dmapi-devel-0.1.1-0.i386.rpm acl-1.0.5-0.src.rpm MD5SUM acl-devel-1.0.5-0.i386.rpm xfsdump-1.0.9-0.i386.rpm attr-1.0.3-0.i386.rpm xfsdump-1.0.9-0.src.rpm attr-1.0.3-0.src.rpm xfsprogs-1.2.7-0.i386.rpm attr-devel-1.0.3-0.i386.rpm xfsprogs-1.2.7-0.src.rpm dmapi-0.1.1-0.i386.rpm xfsprogs-devel-1.2.7-0.i386.rpm dmapi-0.1.1-0.src.rpm You do not need all of these, xfsprogs is the basics, xfsdump and the acl/attr stuff make up the rest of the package (dump needs acl/attr). Steve From owner-linux-xfs@oss.sgi.com Tue Jun 12 15:06:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CM6rS12106 for linux-xfs-outgoing; Tue, 12 Jun 2001 15:06:53 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CM6qP12102 for ; Tue, 12 Jun 2001 15:06:52 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 159wJA-0006rf-00; Wed, 13 Jun 2001 10:06:44 +1200 Date: Wed, 13 Jun 2001 10:06:44 +1200 (NZST) From: Juha Saarinen To: Seth Mos cc: Steve Lord , "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-Reply-To: Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 12 Jun 2001, Seth Mos wrote: > ? Local Brain failure, aborting. > Can you give some more details about what does not compile? It works for > me. And I don't rememember anymore. CVS'ed and tried building from a clean tree again, just now. Still bombs out at the same place: gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o bluesmoke.o bluesmoke.c gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o dmi_scan.o dmi_scan.c gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o pci-i386.o pci-i386.c gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o pci-pc.o pci-pc.c {standard input}: Assembler messages: {standard input}:826: Warning: indirect lcall without `*' {standard input}:908: Warning: indirect lcall without `*' {standard input}:1003: Warning: indirect lcall without `*' {standard input}:1044: Warning: indirect lcall without `*' {standard input}:1074: Warning: indirect lcall without `*' {standard input}:1104: Warning: indirect lcall without `*' {standard input}:1135: Warning: indirect lcall without `*' {standard input}:1164: Warning: indirect lcall without `*' {standard input}:1193: Warning: indirect lcall without `*' {standard input}:1494: Warning: indirect lcall without `*' {standard input}:1589: Warning: indirect lcall without `*' gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o pci-irq.o pci-irq.c gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -DEXPORT_SYMTAB -c mtrr.c gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o smp.o smp.c gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o smpboot.o smpboot.c gcc -V egcs-2.91.66 -D__ASSEMBLY__ -D__KERNEL__ -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -traditional -c trampoline.S -o trampoline.o /tmp/ccmY3EiG.s: Assembler messages: /tmp/ccmY3EiG.s:900: Error: suffix or operands invalid for `ljmp' make[1]: *** [trampoline.o] Error 1 make[1]: Leaving directory `/usr/src/xfs-cvs/linux-2.4-xfs/linux/arch/i386/kernel' make: *** [_dir_arch/i386/kernel] Error 2 -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Tue Jun 12 15:12:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CMCZO13183 for linux-xfs-outgoing; Tue, 12 Jun 2001 15:12:35 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CMCYP13173 for ; Tue, 12 Jun 2001 15:12:34 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA17502; Wed, 13 Jun 2001 00:12:32 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA07965; Wed, 13 Jun 2001 00:12:32 +0200 (CEST) Date: Wed, 13 Jun 2001 00:12:32 +0200 (CEST) From: Seth Mos To: Juha Saarinen cc: Steve Lord , "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001, Juha Saarinen wrote: > On Tue, 12 Jun 2001, Seth Mos wrote: > > > ? Local Brain failure, aborting. > > Can you give some more details about what does not compile? It works for > > me. And I don't rememember anymore. > > CVS'ed and tried building from a clean tree again, just now. Still bombs > out at the same place: > > gcc -V egcs-2.91.66 -D__KERNEL__ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes > -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o > bluesmoke.o bluesmoke.c > gcc -V egcs-2.91.66 -D__KERNEL__ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes > -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o > dmi_scan.o dmi_scan.c > gcc -V egcs-2.91.66 -D__KERNEL__ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes > -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o > pci-i386.o pci-i386.c > gcc -V egcs-2.91.66 -D__KERNEL__ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes > -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o > pci-pc.o pci-pc.c > {standard input}: Assembler messages: > {standard input}:826: Warning: indirect lcall without `*' > {standard input}:908: Warning: indirect lcall without `*' > {standard input}:1003: Warning: indirect lcall without `*' > {standard input}:1044: Warning: indirect lcall without `*' > {standard input}:1074: Warning: indirect lcall without `*' > {standard input}:1104: Warning: indirect lcall without `*' > {standard input}:1135: Warning: indirect lcall without `*' > {standard input}:1164: Warning: indirect lcall without `*' > {standard input}:1193: Warning: indirect lcall without `*' > {standard input}:1494: Warning: indirect lcall without `*' > {standard input}:1589: Warning: indirect lcall without `*' > gcc -V egcs-2.91.66 -D__KERNEL__ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes > -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o > pci-irq.o pci-irq.c > gcc -V egcs-2.91.66 -D__KERNEL__ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes > -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 > -DEXPORT_SYMTAB -c > mtrr.c > gcc -V egcs-2.91.66 -D__KERNEL__ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes > -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o > smp.o smp.c > gcc -V egcs-2.91.66 -D__KERNEL__ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes > -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o > smpboot.o smpboot.c > gcc -V egcs-2.91.66 -D__ASSEMBLY__ -D__KERNEL__ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -traditional -c > trampoline.S -o trampoline.o > /tmp/ccmY3EiG.s: Assembler messages: > /tmp/ccmY3EiG.s:900: Error: suffix or operands invalid for `ljmp' > make[1]: *** [trampoline.o] Error 1 > make[1]: Leaving directory > `/usr/src/xfs-cvs/linux-2.4-xfs/linux/arch/i386/kernel' > make: *** [_dir_arch/i386/kernel] Error 2 Under what distribution are you? From owner-linux-xfs@oss.sgi.com Tue Jun 12 15:14:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CMEdK13623 for linux-xfs-outgoing; Tue, 12 Jun 2001 15:14:39 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CMEcP13620 for ; Tue, 12 Jun 2001 15:14:39 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 159wQj-0006rx-00; Wed, 13 Jun 2001 10:14:33 +1200 Date: Wed, 13 Jun 2001 10:14:32 +1200 (NZST) From: Juha Saarinen To: Seth Mos cc: Steve Lord , "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-Reply-To: Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001, Seth Mos wrote: > Under what distribution are you? This is a system with XFS 1.0 installed from the ISO, so it's basically RH 7.1. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Tue Jun 12 15:17:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CMHdx14214 for linux-xfs-outgoing; Tue, 12 Jun 2001 15:17:39 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CMHcP14203 for ; Tue, 12 Jun 2001 15:17:38 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA18561; Wed, 13 Jun 2001 00:17:36 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA08437; Wed, 13 Jun 2001 00:17:36 +0200 (CEST) Date: Wed, 13 Jun 2001 00:17:36 +0200 (CEST) From: Seth Mos To: Juha Saarinen cc: Steve Lord , "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001, Juha Saarinen wrote: > On Wed, 13 Jun 2001, Seth Mos wrote: > > > Under what distribution are you? > > This is a system with XFS 1.0 installed from the ISO, so it's basically RH > 7.1. Weird, all the systems I test on are 7.1 based. Are you _sure_ you are using kgcc? what's the output of gcc -v? Did a make mrproper help? I have 4 machines that compile the latest checked out CVS without problems so I ame puzzled. From owner-linux-xfs@oss.sgi.com Tue Jun 12 15:22:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CMMmQ15171 for linux-xfs-outgoing; Tue, 12 Jun 2001 15:22:48 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CMMlP15168 for ; Tue, 12 Jun 2001 15:22:47 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 159wYb-0006tR-00; Wed, 13 Jun 2001 10:22:41 +1200 Date: Wed, 13 Jun 2001 10:22:41 +1200 (NZST) From: Juha Saarinen To: Seth Mos cc: Steve Lord , "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-Reply-To: Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001, Seth Mos wrote: > Weird, all the systems I test on are 7.1 based. > Are you _sure_ you are using kgcc? what's the output of gcc -v? Yes, if you look at the output, you'll see that it's using kgcc. I enabled it in the top-level Makefile like this: CC = $(CROSS_COMPILE)gcc -V egcs-2.91.66 # kgcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) > Did a make mrproper help? Nope. Might try building it with gcc to see what happens. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Tue Jun 12 15:29:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CMTcu16378 for linux-xfs-outgoing; Tue, 12 Jun 2001 15:29:38 -0700 Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CMTbP16373 for ; Tue, 12 Jun 2001 15:29:38 -0700 Received: from eclipse ([65.4.56.167]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010612222931.ULHF14901.femail12.sdc1.sfba.home.com@eclipse> for ; Tue, 12 Jun 2001 15:29:31 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Micah Yoder To: "linux-xfs@oss.sgi.com" Subject: Yeah, got it up!!! Date: Tue, 12 Jun 2001 15:30:28 -0400 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01061215302803.01097@eclipse> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [micah@nova micah]$ uname -a Linux nova 2.4.6-pre2-xfs #2 SMP Tue Jun 12 13:58:47 EDT 2001 i686 unknown No help from co-lo people required. All RPMs also updated (thanks Steve). Hopefully now I'll be able to sleep at night. :-) Eric, > Is that the technical term? :) Was it full of null characters? i.e. > ^0^0^0^0^0^0.... Yeah. I think less showed it as ^@ characters. I did edit the file before attempting to reboot. From owner-linux-xfs@oss.sgi.com Tue Jun 12 15:33:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CMXE617056 for linux-xfs-outgoing; Tue, 12 Jun 2001 15:33:14 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CMXDP17050 for ; Tue, 12 Jun 2001 15:33:13 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA22037; Wed, 13 Jun 2001 00:33:08 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA09895; Wed, 13 Jun 2001 00:33:08 +0200 (CEST) Date: Wed, 13 Jun 2001 00:33:08 +0200 (CEST) From: Seth Mos To: Juha Saarinen cc: Steve Lord , "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001, Juha Saarinen wrote: > On Wed, 13 Jun 2001, Seth Mos wrote: > > > Weird, all the systems I test on are 7.1 based. > > Are you _sure_ you are using kgcc? what's the output of gcc -v? > > Yes, if you look at the output, you'll see that it's using kgcc. I enabled > it in the top-level Makefile like this: > > CC = $(CROSS_COMPILE)gcc -V egcs-2.91.66 There is a entry below that reads CC = $(CROSS_COMPILE)kgcc Use that one please. I think it is still trying to build it with a 2.96 version. when your output produces compile strings reading kgcc .... well I'll believe you. Can't think of anything more subtle at the moment. I'm going to sleep now. Next posts tomorrow morning (in 8 hours or so) ugh Seth From owner-linux-xfs@oss.sgi.com Tue Jun 12 15:37:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CMbet17957 for linux-xfs-outgoing; Tue, 12 Jun 2001 15:37:40 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CMbdP17954 for ; Tue, 12 Jun 2001 15:37:39 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA18748 for ; Tue, 12 Jun 2001 15:37:35 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2139987; Tue, 12 Jun 2001 17:36:22 -0500 (CDT) Received: from sgi.com (sandeen@linux-xfs2.americas.sgi.com [128.162.184.56]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA22982; Tue, 12 Jun 2001 17:36:22 -0500 (CDT) Message-ID: <3B269962.5B77739B@sgi.com> Date: Tue, 12 Jun 2001 17:36:18 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: Juha Saarinen , "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > There is a entry below that reads > CC = $(CROSS_COMPILE)kgcc > > Use that one please. I think it is still trying to build it with a 2.96 > version. when your output produces compile strings reading kgcc .... well > I'll believe you. Please do give this a shot, I seem to remember Russell said that the literal "kgcc" line was required to actually make things work. Voodoo, you know. :) -Eric From owner-linux-xfs@oss.sgi.com Tue Jun 12 15:39:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CMdxP18387 for linux-xfs-outgoing; Tue, 12 Jun 2001 15:39:59 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CMdvP18384 for ; Tue, 12 Jun 2001 15:39:57 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f5CMdhaJ083546; Tue, 12 Jun 2001 17:39:43 -0500 (CDT) Message-ID: <3B269A29.5F0F560B@thebarn.com> Date: Tue, 12 Jun 2001 17:39:38 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Juha Saarinen CC: Seth Mos , Steve Lord , "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juha Saarinen wrote: Right sorry I didn't spot this sooner gcc -V egcs-2.91.66 does not work on RH or Mandrake system you must use kgcc to invoke the compiler... I'm not sure what difference it makes but it does. > On Tue, 12 Jun 2001, Seth Mos wrote: > > > ? Local Brain failure, aborting. > > Can you give some more details about what does not compile? It works for > > me. And I don't rememember anymore. > > CVS'ed and tried building from a clean tree again, just now. Still bombs > out at the same place: > > gcc -V egcs-2.91.66 -D__KERNEL__ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes > -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o > bluesmoke.o bluesmoke.c > gcc -V egcs-2.91.66 -D__KERNEL__ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes > -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o > dmi_scan.o dmi_scan.c > gcc -V egcs-2.91.66 -D__KERNEL__ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes > -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o > pci-i386.o pci-i386.c > gcc -V egcs-2.91.66 -D__KERNEL__ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes > -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o > pci-pc.o pci-pc.c > {standard input}: Assembler messages: > {standard input}:826: Warning: indirect lcall without `*' > {standard input}:908: Warning: indirect lcall without `*' > {standard input}:1003: Warning: indirect lcall without `*' > {standard input}:1044: Warning: indirect lcall without `*' > {standard input}:1074: Warning: indirect lcall without `*' > {standard input}:1104: Warning: indirect lcall without `*' > {standard input}:1135: Warning: indirect lcall without `*' > {standard input}:1164: Warning: indirect lcall without `*' > {standard input}:1193: Warning: indirect lcall without `*' > {standard input}:1494: Warning: indirect lcall without `*' > {standard input}:1589: Warning: indirect lcall without `*' > gcc -V egcs-2.91.66 -D__KERNEL__ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes > -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o > pci-irq.o pci-irq.c > gcc -V egcs-2.91.66 -D__KERNEL__ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes > -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 > -DEXPORT_SYMTAB -c > mtrr.c > gcc -V egcs-2.91.66 -D__KERNEL__ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes > -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o > smp.o smp.c > gcc -V egcs-2.91.66 -D__KERNEL__ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes > -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o > smpboot.o smpboot.c > gcc -V egcs-2.91.66 -D__ASSEMBLY__ -D__KERNEL__ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -traditional -c > trampoline.S -o trampoline.o > /tmp/ccmY3EiG.s: Assembler messages: > /tmp/ccmY3EiG.s:900: Error: suffix or operands invalid for `ljmp' > make[1]: *** [trampoline.o] Error 1 > make[1]: Leaving directory > `/usr/src/xfs-cvs/linux-2.4-xfs/linux/arch/i386/kernel' > make: *** [_dir_arch/i386/kernel] Error 2 > > -- > Regards, > > Juha > > PGP fingerprint: > B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Tue Jun 12 15:40:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CMePY18477 for linux-xfs-outgoing; Tue, 12 Jun 2001 15:40:25 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CMeNP18473 for ; Tue, 12 Jun 2001 15:40:23 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5CMeFL13335; Wed, 13 Jun 2001 08:40:16 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Juha Saarinen cc: "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-reply-to: Your message of "Wed, 13 Jun 2001 10:06:44 +1200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Jun 2001 08:40:15 +1000 Message-ID: <13334.992385615@ocs4.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001 10:06:44 +1200 (NZST), Juha Saarinen wrote: >CVS'ed and tried building from a clean tree again, just now. Still bombs >out at the same place: >gcc -V egcs-2.91.66 -D__ASSEMBLY__ -D__KERNEL__ >-I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -traditional -c >trampoline.S -o trampoline.o >/tmp/ccmY3EiG.s: Assembler messages: >/tmp/ccmY3EiG.s:900: Error: suffix or operands invalid for `ljmp' >make[1]: *** [trampoline.o] Error 1 cd /usr/src/xfs-cvs/linux-2.4-xfs/linux/arch/i386/kernel gcc -V egcs-2.91.66 -D__ASSEMBLY__ -D__KERNEL__ \ -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -traditional -c \ trampoline.S -o - -E | grep -B 5 -A 5 ljmp That will show exactly what it is complaining about. Also need output from as -v < /dev/null From owner-linux-xfs@oss.sgi.com Tue Jun 12 15:44:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CMiWw19197 for linux-xfs-outgoing; Tue, 12 Jun 2001 15:44:32 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CMiVP19194 for ; Tue, 12 Jun 2001 15:44:31 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 159wtd-0006un-00; Wed, 13 Jun 2001 10:44:25 +1200 Date: Wed, 13 Jun 2001 10:44:25 +1200 (NZST) From: Juha Saarinen To: Eric Sandeen cc: Seth Mos , "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-Reply-To: <3B269962.5B77739B@sgi.com> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 12 Jun 2001, Eric Sandeen wrote: > Please do give this a shot, I seem to remember Russell said that the > literal "kgcc" line was required to actually make things work. Voodoo, > you know. :) Aaaaaaiieee!!!! Oh all right then, hang on... -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Tue Jun 12 15:46:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CMk3f19366 for linux-xfs-outgoing; Tue, 12 Jun 2001 15:46:03 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CMk2P19359 for ; Tue, 12 Jun 2001 15:46:02 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA04608 for ; Tue, 12 Jun 2001 12:50:42 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2136274; Tue, 12 Jun 2001 14:49:26 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA40471; Tue, 12 Jun 2001 14:49:25 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5CJqcZ28253; Tue, 12 Jun 2001 14:52:38 -0500 Message-Id: <200106121952.f5CJqcZ28253@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: stimits@idcomm.com cc: linux-xfs@oss.sgi.com Subject: Re: XFS and knfsd In-Reply-To: Message from "D. Stimits" of "Tue, 12 Jun 2001 13:42:29 MDT." <3B2670A5.35327B6F@idcomm.com> Date: Tue, 12 Jun 2001 14:52:38 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > At one point I had the NULL pointer dereference at the same address > during boot of a new kernel, which did not have SGI patches. It appeared > to be aic7xxx failure, but was not. I keep mentioning this one patch > which is part of Alan Cox's ac 2.4.5 series, but which is not yet in the > main kernel source. Even if you cannot use this patch at all times, can > you test the following? In linux source, fs/block_dev.c, near line 596 > (depending on kernel version), there is a function "ioctl_by_bdev". In > that function, add the line I have below that starts with "+" (don't use > the "+"): > This code is in the 2.4.6-pre2 code in the cvs tree now, but you are correct it is not in the patches. Steve From owner-linux-xfs@oss.sgi.com Tue Jun 12 16:11:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CNBvY21592 for linux-xfs-outgoing; Tue, 12 Jun 2001 16:11:57 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CNBuP21588 for ; Tue, 12 Jun 2001 16:11:56 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 159xJv-0006wt-00; Wed, 13 Jun 2001 11:11:35 +1200 Date: Wed, 13 Jun 2001 11:11:35 +1200 (NZST) From: Juha Saarinen To: Russell Cattelan cc: Seth Mos , Steve Lord , "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-Reply-To: <3B269A29.5F0F560B@thebarn.com> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 12 Jun 2001, Russell Cattelan wrote: > Juha Saarinen wrote: > > Right sorry I didn't spot this sooner > gcc -V egcs-2.91.66 does not work on RH or Mandrake system > you must use kgcc to invoke the compiler... I'm not sure what > difference it makes but it does. Hmmm... well, that worked. Maybe worth updating the Makefile? Thanks Seth, Eric and Russell for the help! -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Tue Jun 12 16:28:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CNSbM24165 for linux-xfs-outgoing; Tue, 12 Jun 2001 16:28:37 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CNSaP24156 for ; Tue, 12 Jun 2001 16:28:36 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip23.idcomm.com [209.60.72.150]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5CNS1B19311 for ; Tue, 12 Jun 2001 17:28:01 -0600 Message-ID: <3B26A5DD.1BAAA1A5@idcomm.com> Date: Tue, 12 Jun 2001 17:29:33 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: mkinitrd, ramdisk failure? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am trying to take what is very close to my working kernel configuration, and change it around slightly so that ramdisk and modules are used for the XFS related items. The reason being that with these in the kernel and not as module, the image is too large for floppy...I'm going to attempt a 2 floppy boot setup. However, either mkinitrd.xfs is failing, or something with lilo config is failing. The system is scsi, but scsi is being compiled in and not as a module. System is RH 7.1 based. Here is what happens.... It boots normally for a while, looks like it is working, detects the scsi controller, it even goes through some network and USB stuff. Then, when it *should* be saying: Start mounting filesystem: sd(8,6) It will instead say: Kernel panic: VFS: Unable to mount root fs on 08:06 Two lines immediately before this occur regardless of whether it is the working version or the one that breaks when xfs is part of a module, and *might* have something to do with this, though I doubt it (line repeats twice): fatfs: bogus logical sector size 0 fatfs: bogus logical sector size 0 I think that is related to a drive that is for windows only, and unrelated. The version that works I have as "2.4.6-pre1-xfs-2", the failed but nearly identical version is labelled as "2.4.6-pre1-xfs-3". Here is the lilo.conf (note that the i840 chipset must run with apic disabled to be reliable...Intel seems to have broken the chipset): boot=/dev/sda map=/boot/map install=/boot/boot.b prompt timeout=50 message=/boot/message linear vga=0x030c default=2.4.6-p1-xfs-3 backup=boot.backup.when-2.4.6-pre1-xfs-3 image=/boot/vmlinuz-2.4.6-pre1-xfs-3 label=2.4.6-p1-xfs-3 initrd=/boot/initrd-2.4.6-pre1-xfs-3.img read-only root=/dev/sda6 append="ramdisk_size=25000 noapic" image=/boot/vmlinuz-2.4.6-pre1-xfs-2 label=2.4.6-p1-xfs-2 initrd=/boot/initrd-2.4.6-pre1-xfs-2.img read-only root=/dev/sda6 append="noapic" One thing that I wonder about, although lilo install did not generate any error, is the append line of the -3 label. Before this, I have only used: append="noapic" Now it appends two items at once, both "noapic" and "ramdisk_size=25000". Is the space separation the correct delimiter between multiple append items (man page does not say)? Or maybe what is happening is that it thinks the whole "25000 noapic" is what to set "ramdisk_size" to (in which case it probably ignores the parameter entirely)? There is also a kernel config item to allow initial ramdisk size to default to something else, but is set to 4096 by default; thus the lilo parameter should get around this for the larger ramdisk requirement. Maybe I *must* also set this option during kernel compile also, and not just for lilo? D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Tue Jun 12 16:31:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CNVWv24709 for linux-xfs-outgoing; Tue, 12 Jun 2001 16:31:32 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CNVVP24706 for ; Tue, 12 Jun 2001 16:31:31 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 159xcM-0006yA-00; Wed, 13 Jun 2001 11:30:38 +1200 Date: Wed, 13 Jun 2001 11:30:38 +1200 (NZST) From: Juha Saarinen To: Keith Owens cc: "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-Reply-To: <13334.992385615@ocs4.ocs-net> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001, Keith Owens wrote: > cd /usr/src/xfs-cvs/linux-2.4-xfs/linux/arch/i386/kernel > gcc -V egcs-2.91.66 -D__ASSEMBLY__ -D__KERNEL__ \ > -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -traditional -c \ > trampoline.S -o - -E | grep -B 5 -A 5 ljmp > That will show exactly what it is complaining about. Also need output from > as -v < /dev/null Woarrgghh... kewl voodoo there, Keith! ;-) xor %ax, %ax inc %ax # protected mode (PE) bit lmsw %ax # into protected mode jmp flush_instr flush_instr: ljmpl $__KERNEL_CS, $0x00100000 # jump to startup_32 in arch/1/kernel/head.S idt_48: .word 0 # idt limit = 0 .word 0, 0 # idt base = 0L # as -v < /dev/null GNU assembler version 2.10.91 (i386-redhat-linux) using BFD version 2.10.91.0.2 -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Tue Jun 12 16:35:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CNZV825415 for linux-xfs-outgoing; Tue, 12 Jun 2001 16:35:31 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CNZUP25404 for ; Tue, 12 Jun 2001 16:35:30 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 159xgx-0006yX-00; Wed, 13 Jun 2001 11:35:23 +1200 Date: Wed, 13 Jun 2001 11:35:23 +1200 (NZST) From: Juha Saarinen To: Keith Owens cc: "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-Reply-To: Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001, Juha Saarinen wrote: > ljmpl $__KERNEL_CS, $0x00100000 > # jump to startup_32 in arch/1/kernel/head.S # grep startup_32 * head.S:startup_32: trampoline.S: # jump to startup_32 in arch/i386/kernel/head.S Why is "i386" translated into "1"? -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Tue Jun 12 16:42:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CNgPw26664 for linux-xfs-outgoing; Tue, 12 Jun 2001 16:42:25 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CNgOP26661 for ; Tue, 12 Jun 2001 16:42:24 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA29374 for ; Tue, 12 Jun 2001 16:42:20 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA27367; Wed, 13 Jun 2001 09:41:06 +1000 (EST) Date: Wed, 13 Jun 2001 09:41:05 +1000 From: Timothy Shimmin To: Steve Lord Cc: Micah Yoder , "linux-xfs@oss.sgi.com" Subject: Re: Stability of the Red Hat 7.1 + XFS system Message-ID: <20010613094105.L237728@boing.melbourne.sgi.com> References: <200106122150.f5CLo7t01402@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200106122150.f5CLo7t01402@jen.americas.sgi.com>; from lord@sgi.com on Tue, Jun 12, 2001 at 04:50:07PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jun 12, 2001 at 04:50:07PM -0500, Steve Lord wrote: > > > > > > > > What about all the additional programs? Do they need to be updated? There > > > > > doesn't appear to be a way to build them all at once. Any tips on getting > > > them all compiled and moved over? > > > > Each command subtree has a Makepkg command in it, this will build rpms for > > you. I am in the process of updating the ftp site with the latest command > > rpms, they should be showing up in a new directory in the xfs tree, > > cmd_rpms. > > > > OK, they are out there: > > ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/ > > acl-1.0.5-0.i386.rpm dmapi-devel-0.1.1-0.i386.rpm > acl-1.0.5-0.src.rpm MD5SUM > acl-devel-1.0.5-0.i386.rpm xfsdump-1.0.9-0.i386.rpm > attr-1.0.3-0.i386.rpm xfsdump-1.0.9-0.src.rpm > attr-1.0.3-0.src.rpm xfsprogs-1.2.7-0.i386.rpm > attr-devel-1.0.3-0.i386.rpm xfsprogs-1.2.7-0.src.rpm > dmapi-0.1.1-0.i386.rpm xfsprogs-devel-1.2.7-0.i386.rpm > dmapi-0.1.1-0.src.rpm > > You do not need all of these, xfsprogs is the basics, xfsdump and the acl/attr > stuff make up the rest of the package (dump needs acl/attr). > dump needs attr but I don't think it should need acl. Dump knows nothing about ACLs - it saves them because it saves the EAs. (I'd be curious to know how dump fails if ACLs aren't installed) --Tim From owner-linux-xfs@oss.sgi.com Tue Jun 12 17:26:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D0Q9J01120 for linux-xfs-outgoing; Tue, 12 Jun 2001 17:26:09 -0700 Received: from walden.phpwebhosting.com (walden.phpwebhosting.com [64.65.61.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D0Q8P01117 for ; Tue, 12 Jun 2001 17:26:08 -0700 Message-Id: <200106130026.f5D0Q8P01117@oss.sgi.com> Received: (qmail 13696 invoked by uid 508); 13 Jun 2001 00:25:59 -0000 Received: from unknown (HELO localhost) (24.183.20.69) by walden.phpwebhosting.com with SMTP; 13 Jun 2001 00:25:59 -0000 Date: Tue, 12 Jun 2001 19:25:56 -0500 Content-Type: text/plain; format=flowed; charset=us-ascii X-Mailer: Apple Mail (2.388) From: Ben Gollmer To: XFS Mailing List Mime-Version: 1.0 (Apple Message framework v388) In-Reply-To: <005401c0f2df$66daad90$0a01a8c0@den2> Subject: Re: Stability of the Red Hat 7.1 + XFS system Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I know this thread is getting way OT, but I had to chime in. I've had nothing but good luck with my Abit KT7A-RAID + Linux, but I know friends have had trouble, so I've been lucky. Anyway, I'm in the process of putting together a new workstation, and I'm going with the Abit KT7E. It has the VIA 686B southbridge with ATA/100 support, 1 AGP/6 PCI/0 CNR slots (thank you Abit!), and can be had for pretty cheap (check Pricewatch). It looks like a great board, and you really can't get better price/performance than with an Athlon system. If anyone's interested, email me and I'll let you know its performance with XFS + Linux. Ben On Monday, June 11, 2001, at 08:31 PM, Juha Saarinen wrote: > :: Depends on the revision of the Tiger 133. Tyan is like the > :: Microsoft of the mainboard world. You gotta wait for revision C or > :: D before it's good. Late revisions of the Tiger 133 are quite > :: stable. But early revisions? Watch out! > > Yeah, I managed to avoid that trap... got a revision F motherboard here. > > :: I personally cannot stand people who say "this company sucks, or > :: that company sucks." It all comes down to specific parts and > :: models. E.g., the ViA 686A (Ultra66) southbridge has compatibility > :: and performance problems galore, but the newer ViA 686B (Ultra100) > :: bests the ICH2 (Ultra100) southbridge in most people's eyes (and has > :: a higher handwidth channel to the northbridge too). > > I've got the Apollo Pro 133A set with the VT82c596B South Bridge. I can > honestly say that it doesn't work as well as an Intel 440BX solution. > > -- Juha > > From owner-linux-xfs@oss.sgi.com Tue Jun 12 17:31:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D0VhD02005 for linux-xfs-outgoing; Tue, 12 Jun 2001 17:31:43 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D0VfP02002 for ; Tue, 12 Jun 2001 17:31:41 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 159yZM-00072I-00; Wed, 13 Jun 2001 12:31:36 +1200 Date: Wed, 13 Jun 2001 12:31:36 +1200 (NZST) From: Juha Saarinen To: "D. Stimits" cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? In-Reply-To: <3B26A5DD.1BAAA1A5@idcomm.com> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 12 Jun 2001, D. Stimits wrote: > going to attempt a 2 floppy boot setup. However, either mkinitrd.xfs is > failing, or something with lilo config is failing. The system is scsi, > but scsi is being compiled in and not as a module. Try compiling SCSI as modules instead -- that's what I've got here, and it works (Tekram controller plus two drives). Mkinitrd looks for the SCSI modules to put into the initial RAM disk image, so you'll need them. > It will instead say: > Kernel panic: VFS: Unable to mount root fs on 08:06 Sounds like the SCSI stuff isn't being loaded. > The version that works I have as "2.4.6-pre1-xfs-2", the failed but > nearly identical version is labelled as "2.4.6-pre1-xfs-3". Here is the > lilo.conf (note that the i840 chipset must run with apic disabled to be > reliable...Intel seems to have broken the chipset): Hmmm... the i850 works for me. > Now it appends two items at once, both "noapic" and > "ramdisk_size=25000". Is the space separation the correct delimiter > between multiple append items (man page does not say)? Or maybe what is > happening is that it thinks the whole "25000 noapic" is what to set > "ramdisk_size" to (in which case it probably ignores the parameter > entirely)? No, that's the correct one -- I used it here. > There is also a kernel config item to allow initial ramdisk size to > default to something else, but is set to 4096 by default; thus the lilo > parameter should get around this for the larger ramdisk requirement. > Maybe I *must* also set this option during kernel compile also, and not > just for lilo? This I'm not so sure about. If you read the README file for the kernel sources, it says: If you ever need to change the default root device, video mode, ramdisk size, etc. in the kernel image, use the 'rdev' program (or alternatively the LILO boot options when appropriate). No need to recompile the kernel to change these parameters. Also, the Documentation/ramdisk.txt appears to say that you can change the size, without recompiling. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Tue Jun 12 17:33:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D0XN502348 for linux-xfs-outgoing; Tue, 12 Jun 2001 17:33:23 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D0XKP02333 for ; Tue, 12 Jun 2001 17:33:21 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5D0XFI15144; Wed, 13 Jun 2001 10:33:15 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Juha Saarinen cc: "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-reply-to: Your message of "Wed, 13 Jun 2001 11:30:38 +1200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Jun 2001 10:33:15 +1000 Message-ID: <15143.992392395@ocs4.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001 11:30:38 +1200 (NZST), Juha Saarinen wrote: >On Wed, 13 Jun 2001, Keith Owens wrote: > >> cd /usr/src/xfs-cvs/linux-2.4-xfs/linux/arch/i386/kernel >> gcc -V egcs-2.91.66 -D__ASSEMBLY__ -D__KERNEL__ \ >> -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -traditional -c \ >> trampoline.S -o - -E | grep -B 5 -A 5 ljmp >> That will show exactly what it is complaining about. Also need output from >> as -v < /dev/null > >Woarrgghh... kewl voodoo there, Keith! ;-) Not really, just cut and paste the commands in your bug report, changing the -o file to '-' and adding -E. It is the standard way to see what the pre-processor is doing. Damn, there goes another trade secret :). >flush_instr: > ljmpl $__KERNEL_CS, $0x00100000 > # jump to startup_32 in arch/1/kernel/head.S >Why is "i386" translated into "1"? gcc on i386 has a built in -Di386=1. It is only a comment, ignore it. ># as -v < /dev/null >GNU assembler version 2.10.91 (i386-redhat-linux) using BFD version >2.10.91.0.2 That version of as is OK. The problem is gcc -V egcs-2.91.66 does not translate $__KERNEL_CS to $0x10, kgcc does. kgcc uses the egcs-2.91.66 back end but a different gcc wrapper. The kgcc wrapper sets pre-processor flag '-$' which forbids the use of '$' in identifiers. With -$, gcc -V egcs-2.91.66 works as well. So the obvious fix is to change the top level Makefile to say CC = $(CROSS_COMPILE)gcc -V egcs-2.91.66 -$ The pre-processor from gcc 2.96 automatically sets -$. Consistency, what consistency? From owner-linux-xfs@oss.sgi.com Tue Jun 12 17:44:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D0iIU04103 for linux-xfs-outgoing; Tue, 12 Jun 2001 17:44:18 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D0iGP04096 for ; Tue, 12 Jun 2001 17:44:17 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5D0i8e15197; Wed, 13 Jun 2001 10:44:09 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: stimits@idcomm.com cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? In-reply-to: Your message of "Tue, 12 Jun 2001 17:29:33 CST." <3B26A5DD.1BAAA1A5@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Jun 2001 10:44:08 +1000 Message-ID: <15196.992393048@ocs4.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 12 Jun 2001 17:29:33 -0600, "D. Stimits" wrote: >It boots normally for a while, looks like it is working, detects the >scsi controller, it even goes through some network and USB stuff. Then, >when it *should* be saying: >Start mounting filesystem: sd(8,6) > >It will instead say: >Kernel panic: VFS: Unable to mount root fs on 08:06 Probably because the XFS module has not been loaded. Did it ask for the second floppy? I am not familiar with two floppy boots but I think you need prompt_ramdisk=1 with the kernel on the first disk and initrd on the second. From owner-linux-xfs@oss.sgi.com Tue Jun 12 17:50:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D0oST05122 for linux-xfs-outgoing; Tue, 12 Jun 2001 17:50:28 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D0oQP05113 for ; Tue, 12 Jun 2001 17:50:26 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 159yrM-00073R-00; Wed, 13 Jun 2001 12:50:13 +1200 Date: Wed, 13 Jun 2001 12:50:12 +1200 (NZST) From: Juha Saarinen To: Keith Owens cc: "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-Reply-To: <15143.992392395@ocs4.ocs-net> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001, Keith Owens wrote: > Not really, just cut and paste the commands in your bug report, > changing the -o file to '-' and adding -E. It is the standard way to > see what the pre-processor is doing. Damn, there goes another trade > secret :). Wonder if it'd work as a party trick too? ;-) > CC = $(CROSS_COMPILE)gcc -V egcs-2.91.66 -$ > > The pre-processor from gcc 2.96 automatically sets -$. Consistency, > what consistency? Indeed, but, it doesn't seem to work. Make dep hangs at this line: # make dep gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep scripts/mkdep.c make[1]: Entering directory `/usr/src/xfs-cvs/linux-2.4-xfs/linux/arch/i386/boot' make[1]: Nothing to be done for `dep'. make[1]: Leaving directory `/usr/src/xfs-cvs/linux-2.4-xfs/linux/arch/i386/boot' scripts/mkdep -- init/*.c > .depend scripts/mkdep -- `find /usr/src/xfs-cvs/linux-2.4-xfs/linux/include/asm /usr/src/xfs-cvs/linux-2.4-xfs/linux/include/linux /usr/src/xfs-cvs/linux-2.4-xfs/linux/include/scsi /usr/src/xfs-cvs/linux-2.4-xfs/linux/include/net -name SCCS -prune -o -follow -name \*.h ! -name modversions.h -print` > .hdepend make _sfdep_kernel _sfdep_drivers _sfdep_mm _sfdep_fs _sfdep_net _sfdep_ipc _sfdep_lib _sfdep_arch/i386/kernel _sfdep_arch/i386/mm _sfdep_arch/i386/lib _FASTDEP_ALL_SUB_DIRS="kernel drivers mm fs net ipc lib arch/i386/kernel arch/i386/mm arch/i386/lib" make[1]: Entering directory `/usr/src/xfs-cvs/linux-2.4-xfs/linux' make -C kernel fastdep make[2]: Entering directory `/usr/src/xfs-cvs/linux-2.4-xfs/linux/kernel' gcc -V egcs-2.91.66 - -D__KERNEL__ -I/usr/src/xfs-cvs/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -E -D__GENKSYMS__ signal.c | /sbin/genksyms -p smp_ -k 2.4.6 > /usr/src/xfs-cvs/linux-2.4-xfs/linux/include/linux/modules/signal.ver.tmp with "-$" added as you suggested. Without it, it continues. Maybe it needs to be escaped somehow? -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Tue Jun 12 17:56:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D0uuI06234 for linux-xfs-outgoing; Tue, 12 Jun 2001 17:56:56 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D0usP06228 for ; Tue, 12 Jun 2001 17:56:55 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5D0unv15534; Wed, 13 Jun 2001 10:56:49 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Juha Saarinen cc: "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-reply-to: Your message of "Wed, 13 Jun 2001 12:50:12 +1200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Jun 2001 10:56:49 +1000 Message-ID: <15533.992393809@ocs4.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001 12:50:12 +1200 (NZST), Juha Saarinen wrote: >On Wed, 13 Jun 2001, Keith Owens wrote: >> CC = $(CROSS_COMPILE)gcc -V egcs-2.91.66 -$ >Indeed, but, it doesn't seem to work. Make dep hangs at this line: > >gcc -V egcs-2.91.66 - -D__KERNEL__ '-$' has been converted to '-' so gcc tries to read from stdin. for (i = 0; i < 1000; ++i) fprintf(stderr, "I must remember to use $$ when I want $ in makefiles\n"); Try CC = $(CROSS_COMPILE)gcc -V egcs-2.91.66 -$$ From owner-linux-xfs@oss.sgi.com Tue Jun 12 17:59:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D0xlw06827 for linux-xfs-outgoing; Tue, 12 Jun 2001 17:59:47 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D0xkP06813 for ; Tue, 12 Jun 2001 17:59:47 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 159z0a-00073w-00; Wed, 13 Jun 2001 12:59:44 +1200 Date: Wed, 13 Jun 2001 12:59:44 +1200 (NZST) From: Juha Saarinen To: Keith Owens cc: "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-Reply-To: <15533.992393809@ocs4.ocs-net> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001, Keith Owens wrote: > Try CC = $(CROSS_COMPILE)gcc -V egcs-2.91.66 -$$ Nope, it still stops at the same place. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Tue Jun 12 18:13:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D1DRh08941 for linux-xfs-outgoing; Tue, 12 Jun 2001 18:13:27 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D1DPP08935 for ; Tue, 12 Jun 2001 18:13:25 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5D1DJv18922; Wed, 13 Jun 2001 11:13:19 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Juha Saarinen cc: "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-reply-to: Your message of "Wed, 13 Jun 2001 12:59:44 +1200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Jun 2001 11:13:18 +1000 Message-ID: <18921.992394798@ocs4.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001 12:59:44 +1200 (NZST), Juha Saarinen wrote: >On Wed, 13 Jun 2001, Keith Owens wrote: > >> Try CC = $(CROSS_COMPILE)gcc -V egcs-2.91.66 -$$ > >Nope, it still stops at the same place. It needs CC = ... -$$$$ to get a single -$ for CPP. But that breaks CC which sees -$$. I will do some digging on this to work out the best fix. From owner-linux-xfs@oss.sgi.com Tue Jun 12 18:46:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D1kMh12293 for linux-xfs-outgoing; Tue, 12 Jun 2001 18:46:22 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D1kKP12289 for ; Tue, 12 Jun 2001 18:46:20 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip17.idcomm.com [209.60.72.144]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5D1jkl14058 for ; Tue, 12 Jun 2001 19:45:46 -0600 Message-ID: <3B26C626.24EC0F20@idcomm.com> Date: Tue, 12 Jun 2001 19:47:18 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juha Saarinen wrote: > > On Tue, 12 Jun 2001, D. Stimits wrote: > > > going to attempt a 2 floppy boot setup. However, either mkinitrd.xfs is > > failing, or something with lilo config is failing. The system is scsi, > > but scsi is being compiled in and not as a module. > > Try compiling SCSI as modules instead -- that's what I've got here, and it > works (Tekram controller plus two drives). > > Mkinitrd looks for the SCSI modules to put into the initial RAM disk > image, so you'll need them. > > > It will instead say: > > Kernel panic: VFS: Unable to mount root fs on 08:06 > > Sounds like the SCSI stuff isn't being loaded. That's the interesting part. The bootup shows that it booted /boot/, and all scsi was detected and loaded. It was mounting of the root partition (/boot is ext2, root is xfs) where it failed, due to lack of the initial ramdisk providing XFS...but I think I did get XFS module into the ramdisk. I wonder if there is a way to read an initial ramdisk image and see if XFS did indeed make its way in. Guess I'll try again explicitly forcing XFS into the ramdisk. > > > The version that works I have as "2.4.6-pre1-xfs-2", the failed but > > nearly identical version is labelled as "2.4.6-pre1-xfs-3". Here is the > > lilo.conf (note that the i840 chipset must run with apic disabled to be > > reliable...Intel seems to have broken the chipset): > > Hmmm... the i850 works for me. The i840 IO-APIC can send spurious interrupt vectors for irq 217, which does not exist. i850 is a completely different chipset. i840's without the 64 bit pci slots have only one of the defective APIC items, while those with 64 bit bus have more...mine has 3. 2 of those are tied to the 64 bit pci, which means pci activity is one of those locations it fails under heavy load. > > > Now it appends two items at once, both "noapic" and > > "ramdisk_size=25000". Is the space separation the correct delimiter > > between multiple append items (man page does not say)? Or maybe what is > > happening is that it thinks the whole "25000 noapic" is what to set > > "ramdisk_size" to (in which case it probably ignores the parameter > > entirely)? > > No, that's the correct one -- I used it here. So specifying both on one line as I did should work? I wasn't sure about the space separator. > > > There is also a kernel config item to allow initial ramdisk size to > > default to something else, but is set to 4096 by default; thus the lilo > > parameter should get around this for the larger ramdisk requirement. > > Maybe I *must* also set this option during kernel compile also, and not > > just for lilo? > > This I'm not so sure about. If you read the README file for the kernel > sources, it says: > > If you ever need to change the default root device, video mode, > ramdisk size, etc. in the kernel image, use the 'rdev' program (or > alternatively the LILO boot options when appropriate). No need to > recompile the kernel to change these parameters. rdev would be for changing parameters of boot, but this is the first time this kernel with this configuration has been installed. The old entry still exists until I can get the new one to work right. The kernel itself was reconfigured. > > Also, the Documentation/ramdisk.txt appears to say that you can change the > size, without recompiling. Right, there are two possible ways to change it, I didn't know if both were required (this is one of my questions). Sounds like either/or will work. But since I'm not using the same exact kernel configuration, and this is an extra kernel rather than just a partial reconfig of old, this will be the first time I have booted with XFS supported only by module. D. Stimits, stimits@idcomm.com > > -- > Regards, > > Juha > > PGP fingerprint: > B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Tue Jun 12 18:46:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D1kO912317 for linux-xfs-outgoing; Tue, 12 Jun 2001 18:46:24 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D1kNP12312 for ; Tue, 12 Jun 2001 18:46:23 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip17.idcomm.com [209.60.72.144]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5D1jol14074 for ; Tue, 12 Jun 2001 19:45:50 -0600 Message-ID: <3B26C62A.526AFD8F@idcomm.com> Date: Tue, 12 Jun 2001 19:47:22 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <15196.992393048@ocs4.ocs-net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > > On Tue, 12 Jun 2001 17:29:33 -0600, > "D. Stimits" wrote: > >It boots normally for a while, looks like it is working, detects the > >scsi controller, it even goes through some network and USB stuff. Then, > >when it *should* be saying: > >Start mounting filesystem: sd(8,6) > > > >It will instead say: > >Kernel panic: VFS: Unable to mount root fs on 08:06 > > Probably because the XFS module has not been loaded. Did it ask for > the second floppy? I am not familiar with two floppy boots but I think > you need prompt_ramdisk=1 with the kernel on the first disk and initrd > on the second. To clarify, this is a lilo install to the hard drive. But I want it to work correctly prior to trying to make a floppy. In the bad old days, such as when I played with slackware and 1.0.9 kernel, floppies for install came two at a time, one the boot disk, the other the root disk. Since the use of a single floppy is now impossible with XFS since it exceeds the floppy's capacity, I'm trying to make it as a module. This allows the boot kernel on one floppy, and the ramdisk contents on a second floppy. But it is correct that XFS module is not being loaded. Since I created my initial ramdisk with mkinitrd.xfs, I'm wondering why it is failing, how it is missing from the image. I'm thinking I used this incorrectly. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Tue Jun 12 19:02:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D220s14839 for linux-xfs-outgoing; Tue, 12 Jun 2001 19:02:00 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D21xP14834 for ; Tue, 12 Jun 2001 19:01:59 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA00129 for ; Tue, 12 Jun 2001 19:01:57 -0700 (PDT) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA85774 for linux-xfs@oss.sgi.com; Wed, 13 Jun 2001 12:00:40 +1000 (EST) Date: Wed, 13 Jun 2001 12:00:40 +1000 (EST) From: Timothy Shimmin Message-Id: <200106130200.MAA85774@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - acl/acl.h --> sys/acl.h Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk To comply with the withdrawn Posix ACL standards (and at Juergen Hasch's request), I've moved acl/acl.h to sys/acl.h . A "make install-dev" in the cmd/acl directory should install the acl.h file in its new location (a new builddefs will have to be built using the new configure which has the new path for PKG_INC_DIR). --Tim Date: Tue Jun 12 18:49:41 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:96792a cmd/acl/configure.in - 1.5 - Move from acl/acl.h to sys/acl.h. cmd/acl/man/man5/acl.5 - 1.3 cmd/acl/man/man3/acl_get_file.3 - 1.4 cmd/acl/man/man3/acl_size.3 - 1.3 cmd/acl/man/man3/acl_get_fd.3 - 1.4 cmd/acl/man/man3/acl_from_text.3 - 1.3 cmd/acl/man/man3/acl_free.3 - 1.3 cmd/acl/man/man3/acl_dup.3 - 1.3 cmd/acl/man/man3/acl_delete_def_file.3 - 1.3 cmd/acl/man/man3/acl_valid.3 - 1.3 cmd/acl/man/man3/acl_copy_ext.3 - 1.3 cmd/acl/man/man2/acl_set.2 - 1.3 cmd/acl/man/man2/acl_get.2 - 1.3 - acl/acl.h --to--> sys/acl.h cmd/acl/VERSION - 1.7 - Bump revision to 6. For acl.h path change - also note chacl fix. cmd/acl/doc/CHANGES - 1.7 - Note the move fo acl/acl.h to sys/acl.h and the fix to chacl. cmd/xfstests/include/builddefs.in - 1.5 - Get rid of -I include path of /usr/include/acl. cmd/xfstests/src/acl_get.c - 1.2 - acl.h --to--> sys/acl.h cmd/acl/man/man3/acl_set_compat.3 - 1.2 - acl/acl.h --to--> sys/acl.h cmd/xfstests/src/acl_test.c - 1.3 - acl.h --to--> sys/acl.h From owner-linux-xfs@oss.sgi.com Tue Jun 12 19:03:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D23cC15189 for linux-xfs-outgoing; Tue, 12 Jun 2001 19:03:38 -0700 Received: from walt400.holman.net (aazpppdsl56.sttl.uswest.net [63.226.208.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D23bP15185 for ; Tue, 12 Jun 2001 19:03:37 -0700 Received: from uswest.net (walt400.holman.net [10.0.0.2]) by walt400.holman.net (Postfix) with ESMTP id 18133401D4D; Tue, 12 Jun 2001 19:13:51 -0700 (PDT) Message-ID: <3B26CC5E.6050804@uswest.net> Date: Tue, 12 Jun 2001 19:13:50 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-xfs i686; en-US; rv:0.9.1) Gecko/20010607 X-Accept-Language: en-us MIME-Version: 1.0 To: stimits@idcomm.com Cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <3B26C626.24EC0F20@idcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I'm not all that familiar with mkinitrd.xfs as I use the standard "unpatched" mkinitrd under Mandrake 8.0 Does it need the --preload switches to preload the appropriate modules in order for XFS to work? Using stock mkinitrd I need to use: mkinitrd --preload pagebuf --preload xfs_support blah,blah,etc.... That forces the ramdisk image to preload the proper support modules. Dunno, maybe mkinitrd.xfs already does this. -Walt D. Stimits wrote: >Juha Saarinen wrote: > >>On Tue, 12 Jun 2001, D. Stimits wrote: >> >>>going to attempt a 2 floppy boot setup. However, either mkinitrd.xfs is >>>failing, or something with lilo config is failing. The system is scsi, >>>but scsi is being compiled in and not as a module. >>> >>Try compiling SCSI as modules instead -- that's what I've got here, and it >>works (Tekram controller plus two drives). >> >>Mkinitrd looks for the SCSI modules to put into the initial RAM disk >>image, so you'll need them. >> >>>It will instead say: >>>Kernel panic: VFS: Unable to mount root fs on 08:06 >>> >>Sounds like the SCSI stuff isn't being loaded. >> > >That's the interesting part. The bootup shows that it booted /boot/, and >all scsi was detected and loaded. It was mounting of the root partition >(/boot is ext2, root is xfs) where it failed, due to lack of the initial >ramdisk providing XFS...but I think I did get XFS module into the >ramdisk. I wonder if there is a way to read an initial ramdisk image and >see if XFS did indeed make its way in. Guess I'll try again explicitly >forcing XFS into the ramdisk. > >>>The version that works I have as "2.4.6-pre1-xfs-2", the failed but >>>nearly identical version is labelled as "2.4.6-pre1-xfs-3". Here is the >>>lilo.conf (note that the i840 chipset must run with apic disabled to be >>>reliable...Intel seems to have broken the chipset): >>> >>Hmmm... the i850 works for me. >> > >The i840 IO-APIC can send spurious interrupt vectors for irq 217, which >does not exist. i850 is a completely different chipset. i840's without >the 64 bit pci slots have only one of the defective APIC items, while >those with 64 bit bus have more...mine has 3. 2 of those are tied to the >64 bit pci, which means pci activity is one of those locations it fails >under heavy load. > >>>Now it appends two items at once, both "noapic" and >>>"ramdisk_size=25000". Is the space separation the correct delimiter >>>between multiple append items (man page does not say)? Or maybe what is >>>happening is that it thinks the whole "25000 noapic" is what to set >>>"ramdisk_size" to (in which case it probably ignores the parameter >>>entirely)? >>> >>No, that's the correct one -- I used it here. >> > >So specifying both on one line as I did should work? I wasn't sure about >the space separator. > >>>There is also a kernel config item to allow initial ramdisk size to >>>default to something else, but is set to 4096 by default; thus the lilo >>>parameter should get around this for the larger ramdisk requirement. >>>Maybe I *must* also set this option during kernel compile also, and not >>>just for lilo? >>> >>This I'm not so sure about. If you read the README file for the kernel >>sources, it says: >> >> If you ever need to change the default root device, video mode, >> ramdisk size, etc. in the kernel image, use the 'rdev' program (or >> alternatively the LILO boot options when appropriate). No need to >> recompile the kernel to change these parameters. >> > >rdev would be for changing parameters of boot, but this is the first >time this kernel with this configuration has been installed. The old >entry still exists until I can get the new one to work right. The kernel >itself was reconfigured. > >>Also, the Documentation/ramdisk.txt appears to say that you can change the >>size, without recompiling. >> > >Right, there are two possible ways to change it, I didn't know if both >were required (this is one of my questions). Sounds like either/or will >work. But since I'm not using the same exact kernel configuration, and >this is an extra kernel rather than just a partial reconfig of old, this >will be the first time I have booted with XFS supported only by module. > >D. Stimits, stimits@idcomm.com > >>-- >>Regards, >> >>Juha >> >>PGP fingerprint: >>B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 >> > From owner-linux-xfs@oss.sgi.com Tue Jun 12 19:07:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D27xt15935 for linux-xfs-outgoing; Tue, 12 Jun 2001 19:07:59 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D27wP15930 for ; Tue, 12 Jun 2001 19:07:58 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id EAA76004 for ; Wed, 13 Jun 2001 04:07:53 +0200 (CEST) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA81628 for linux-xfs@oss.sgi.com; Wed, 13 Jun 2001 12:06:35 +1000 (EST) Date: Wed, 13 Jun 2001 12:06:35 +1000 From: Timothy Shimmin To: linux-xfs@oss.sgi.com Subject: acl.h has moved Message-ID: <20010613120635.O237728@boing.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi there, Just a heads up for anyone with a user space program which includes . To comply with the Posix standards I have moved it to . Cheers, Tim. From owner-linux-xfs@oss.sgi.com Tue Jun 12 19:34:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D2Y6219816 for linux-xfs-outgoing; Tue, 12 Jun 2001 19:34:06 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D2Y4P19813 for ; Tue, 12 Jun 2001 19:34:05 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id TAA06366 for ; Tue, 12 Jun 2001 19:34:00 -0700 (PDT) mail_from (ivanr@melbourne.sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA02857; Wed, 13 Jun 2001 12:32:44 +1000 From: ivanr@melbourne.sgi.com (Ivan Rayner) Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id MAA14818; Wed, 13 Jun 2001 12:32:43 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Wed, 13 Jun 2001 12:32:43 +1000 To: Russel Ingram cc: Subject: Re: xfsdump, paride tape, and -m option In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 12 Jun 2001, Russel Ingram wrote: > On Wed, 13 Jun 2001, Ivan Rayner wrote: > > > Well, even if it is a hardware problem, it'd be nice if xfsdump didn't > > core dump. Would you be able to send me the output of 'xfsdump -v5 ...' > > and the core file? > > I can't seem to get the error messages to redirect to the file so here are > the error messages I got this time: > > sh: xfsdq: command not found > sh: xfsdq: command not found These errors indicate that xfsdq/xfsrq weren't installed. If you want your quota information included in the dump, you should install them. I think they're part of the xfsdump package. If you don't care, then you can ignore these errors. > xfsdump: drive_minrmt.c:2201: do_end_write: Assertion `first_rec_w_err >= > 0' failed. > Aborted (core dumped) It looks as though the following code failed with errno == 22 (Invalid argument): cmd/xfsdump/common/drive_minrmt.c: rval = ioctl( fd, MTIOCTOP, &mop ); if ( rval < 0 ) { /* failure */ mlog( MLOG_DEBUG | MLOG_DRIVE, "tape op %s %d returns %d: errno == %d (%s)\n", printstr, param, rval, errno, strerror( errno )); return -1; } where mop.mt_op == MTWEOF and mop.mt_count == 1, which later triggered the assertion failure and core dump. In other words, your hardware/driver didn't want to write an end-of-file record. You could try running 'mt weof 1' from the command line to verify my assertion. What driver does your tape drive use? You could possibly take a look at the source and see how it handles the MTIOCTOP (MTWEOF) ioctl. For example, you can see the scsi tape driver code for this at linux/drivers/scsi/st.c line 2223. Ivan -- Ivan Rayner ivanr@melbourne.sgi.com From owner-linux-xfs@oss.sgi.com Tue Jun 12 19:58:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D2wAh23232 for linux-xfs-outgoing; Tue, 12 Jun 2001 19:58:10 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D2w9P23225 for ; Tue, 12 Jun 2001 19:58:09 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA21512 for ; Tue, 12 Jun 2001 19:58:05 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA2127877; Tue, 12 Jun 2001 21:56:47 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id VAA33302; Tue, 12 Jun 2001 21:56:46 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5D30J903344; Tue, 12 Jun 2001 22:00:19 -0500 Message-Id: <200106130300.f5D30J903344@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Timothy Shimmin cc: Steve Lord , Micah Yoder , "linux-xfs@oss.sgi.com" Subject: Re: Stability of the Red Hat 7.1 + XFS system In-Reply-To: Message from Timothy Shimmin of "Wed, 13 Jun 2001 09:41:05 +1000." <20010613094105.L237728@boing.melbourne.sgi.com> Date: Tue, 12 Jun 2001 22:00:19 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Tue, Jun 12, 2001 at 04:50:07PM -0500, Steve Lord wrote: > > > > You do not need all of these, xfsprogs is the basics, xfsdump and the acl/a > ttr > > stuff make up the rest of the package (dump needs acl/attr). > > > dump needs attr but I don't think it should need acl. > Dump knows nothing about ACLs - it saves them because it saves the EAs. > (I'd be curious to know how dump fails if ACLs aren't installed) > > --Tim OK Tim, I stand corrected, I was typing fast at the time. Steve From owner-linux-xfs@oss.sgi.com Tue Jun 12 20:03:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D33Tk24162 for linux-xfs-outgoing; Tue, 12 Jun 2001 20:03:29 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D33QP24147 for ; Tue, 12 Jun 2001 20:03:26 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip36.idcomm.com [209.60.72.163]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5D32ql31272 for ; Tue, 12 Jun 2001 21:02:52 -0600 Message-ID: <3B26D839.E6C58E3E@idcomm.com> Date: Tue, 12 Jun 2001 21:04:25 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <3B26C626.24EC0F20@idcomm.com> <3B26CC5E.6050804@uswest.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Walt H wrote: > > Hello, > > I'm not all that familiar with mkinitrd.xfs as I use the standard > "unpatched" mkinitrd under Mandrake 8.0 Does it need the --preload > switches to preload the appropriate modules in order for XFS to work? > Using stock mkinitrd I need to use: > > mkinitrd --preload pagebuf --preload xfs_support blah,blah,etc.... > > That forces the ramdisk image to preload the proper support modules. > Dunno, maybe mkinitrd.xfs already does this. While I'm convinced that this is the basic problem, I can't figure out what is missing. Matt Ryan gave me one very useful command to mount my initial ramdisk on loopback and see what it actually contains. I can absolutely guarantee it contains: pagebuf.o xfs.o xfs_support.o I have tried this both using the "--with" and the "--preload" arguments. I have tried both with the stock (but current) mkinitrd, as well as mkinitrd.xfs that was from the same 2.4.6-pre1-xfs cvs. In all cases, the kernel and other module items successfully unpack, e.g., module based USB and ethernet modules successfully load. I even see the scsi system load...without that, it could never even mount /boot/. I see it succeeding at all things until it mounts the root filesystem. There must be some other module I am missing...not just pagebuf, xfs, and xfs_support. What is the fourth module? Can anyone here that has a module-based XFS support give me a list of lsmod output? D. Stimits, stimits@idcomm.com > > -Walt > > D. Stimits wrote: > > >Juha Saarinen wrote: > > > >>On Tue, 12 Jun 2001, D. Stimits wrote: > >> > >>>going to attempt a 2 floppy boot setup. However, either mkinitrd.xfs is > >>>failing, or something with lilo config is failing. The system is scsi, > >>>but scsi is being compiled in and not as a module. > >>> > >>Try compiling SCSI as modules instead -- that's what I've got here, and it > >>works (Tekram controller plus two drives). > >> > >>Mkinitrd looks for the SCSI modules to put into the initial RAM disk > >>image, so you'll need them. > >> > >>>It will instead say: > >>>Kernel panic: VFS: Unable to mount root fs on 08:06 > >>> > >>Sounds like the SCSI stuff isn't being loaded. > >> > > > >That's the interesting part. The bootup shows that it booted /boot/, and > >all scsi was detected and loaded. It was mounting of the root partition > >(/boot is ext2, root is xfs) where it failed, due to lack of the initial > >ramdisk providing XFS...but I think I did get XFS module into the > >ramdisk. I wonder if there is a way to read an initial ramdisk image and > >see if XFS did indeed make its way in. Guess I'll try again explicitly > >forcing XFS into the ramdisk. > > > >>>The version that works I have as "2.4.6-pre1-xfs-2", the failed but > >>>nearly identical version is labelled as "2.4.6-pre1-xfs-3". Here is the > >>>lilo.conf (note that the i840 chipset must run with apic disabled to be > >>>reliable...Intel seems to have broken the chipset): > >>> > >>Hmmm... the i850 works for me. > >> > > > >The i840 IO-APIC can send spurious interrupt vectors for irq 217, which > >does not exist. i850 is a completely different chipset. i840's without > >the 64 bit pci slots have only one of the defective APIC items, while > >those with 64 bit bus have more...mine has 3. 2 of those are tied to the > >64 bit pci, which means pci activity is one of those locations it fails > >under heavy load. > > > >>>Now it appends two items at once, both "noapic" and > >>>"ramdisk_size=25000". Is the space separation the correct delimiter > >>>between multiple append items (man page does not say)? Or maybe what is > >>>happening is that it thinks the whole "25000 noapic" is what to set > >>>"ramdisk_size" to (in which case it probably ignores the parameter > >>>entirely)? > >>> > >>No, that's the correct one -- I used it here. > >> > > > >So specifying both on one line as I did should work? I wasn't sure about > >the space separator. > > > >>>There is also a kernel config item to allow initial ramdisk size to > >>>default to something else, but is set to 4096 by default; thus the lilo > >>>parameter should get around this for the larger ramdisk requirement. > >>>Maybe I *must* also set this option during kernel compile also, and not > >>>just for lilo? > >>> > >>This I'm not so sure about. If you read the README file for the kernel > >>sources, it says: > >> > >> If you ever need to change the default root device, video mode, > >> ramdisk size, etc. in the kernel image, use the 'rdev' program (or > >> alternatively the LILO boot options when appropriate). No need to > >> recompile the kernel to change these parameters. > >> > > > >rdev would be for changing parameters of boot, but this is the first > >time this kernel with this configuration has been installed. The old > >entry still exists until I can get the new one to work right. The kernel > >itself was reconfigured. > > > >>Also, the Documentation/ramdisk.txt appears to say that you can change the > >>size, without recompiling. > >> > > > >Right, there are two possible ways to change it, I didn't know if both > >were required (this is one of my questions). Sounds like either/or will > >work. But since I'm not using the same exact kernel configuration, and > >this is an extra kernel rather than just a partial reconfig of old, this > >will be the first time I have booted with XFS supported only by module. > > > >D. Stimits, stimits@idcomm.com > > > >>-- > >>Regards, > >> > >>Juha > >> > >>PGP fingerprint: > >>B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 > >> > > From owner-linux-xfs@oss.sgi.com Tue Jun 12 20:28:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D3SDD26818 for linux-xfs-outgoing; Tue, 12 Jun 2001 20:28:13 -0700 Received: from mail15b.boca15-verio.com ([208.55.91.59]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D3SBP26811 for ; Tue, 12 Jun 2001 20:28:11 -0700 Received: from www.sigmastorage.com (128.241.173.170) by mail15b.boca15-verio.com (RS ver 1.0.60s) with SMTP id 030821423; Tue, 12 Jun 2001 23:27:54 -0400 (EDT) Message-ID: <3B26DCBB.2289C8FC@sigmastorage.com> Date: Tue, 12 Jun 2001 20:23:39 -0700 From: Matt Ryan X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: stimits@idcomm.com CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <3B26C626.24EC0F20@idcomm.com> <3B26CC5E.6050804@uswest.net> <3B26D839.E6C58E3E@idcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk sorry, I meant to write that to the list as well. I just wrote: gzip -dc your.img > somefile mount -o loop somefile somedir also, just running mkinitrd with the verbose (-v) option is pretty helpful too (not sure if you were doing that already). Matt > > While I'm convinced that this is the basic problem, I can't figure out > what is missing. Matt Ryan gave me one very useful command to mount my > initial ramdisk on loopback and see what it actually contains. I can From owner-linux-xfs@oss.sgi.com Tue Jun 12 20:28:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D3SM626865 for linux-xfs-outgoing; Tue, 12 Jun 2001 20:28:22 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D3SKP26862 for ; Tue, 12 Jun 2001 20:28:20 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA03270 for ; Tue, 12 Jun 2001 20:28:40 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id WAA2116443 for ; Tue, 12 Jun 2001 22:27:04 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA16203 for ; Tue, 12 Jun 2001 22:27:04 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f5D3Uaj03584; Tue, 12 Jun 2001 22:30:36 -0500 Message-Id: <200106130330.f5D3Uaj03584@jen.americas.sgi.com> Date: Tue, 12 Jun 2001 22:30:36 -0500 Subject: TAKE - merge up to 2.4.6-pre3 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk One small mod before I go on vacation! This should be fairly painless. Steve Date: Tue Jun 12 20:24:09 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-base The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:96799a linux/drivers/mtd/nand/nand.c - 1.1 linux/drivers/mtd/nftlcore.c - 1.1 linux/drivers/mtd/bootldr.c - 1.1 linux/drivers/mtd/nand/spia.c - 1.1 linux/drivers/mtd/nand/nand_ecc.c - 1.1 linux/drivers/mtd/redboot.c - 1.1 linux/drivers/mtd/nand/Makefile - 1.1 linux/drivers/mtd/nand/Config.in - 1.1 linux/drivers/mtd/mtdblock_ro.c - 1.1 linux/drivers/mtd/maps/vmax301.c - 1.1 linux/drivers/mtd/maps/sun_uflash.c - 1.1 linux/drivers/mtd/maps/sc520cdp.c - 1.1 linux/drivers/mtd/maps/sbc_gxx.c - 1.1 linux/drivers/mtd/maps/sa1100-flash.c - 1.1 linux/drivers/mtd/maps/rpxlite.c - 1.1 linux/drivers/mtd/maps/pnc2000.c - 1.1 linux/drivers/mtd/maps/physmap.c - 1.1 linux/drivers/mtd/maps/octagon-5066.c - 1.1 linux/drivers/mtd/maps/ocelot.c - 1.1 linux/include/linux/mtd/nand_ecc.h - 1.1 linux/include/linux/mtd/cfi_endian.h - 1.1 linux/drivers/mtd/maps/nora.c - 1.1 linux/drivers/mtd/maps/netsc520.c - 1.1 linux/drivers/mtd/maps/iq80310.c - 1.1 linux/drivers/mtd/maps/elan-104nc.c - 1.1 linux/drivers/mtd/maps/dc21285.c - 1.1 linux/drivers/mtd/maps/dbox2-flash.c - 1.1 linux/drivers/mtd/maps/cstm_mips_ixx.c - 1.1 linux/drivers/mtd/maps/cfi_flagadm.c - 1.1 linux/drivers/mtd/maps/Makefile - 1.1 linux/drivers/mtd/maps/Config.in - 1.1 linux/drivers/mtd/devices/slram.c - 1.1 linux/drivers/mtd/devices/pmc551.c - 1.1 linux/drivers/mtd/devices/mtdram.c - 1.1 linux/drivers/mtd/devices/docprobe.c - 1.1 linux/drivers/mtd/devices/docecc.c - 1.1 linux/drivers/mtd/devices/doc2001.c - 1.1 linux/drivers/mtd/devices/doc2000.c - 1.1 linux/drivers/mtd/devices/doc1000.c - 1.1 linux/drivers/mtd/devices/Makefile - 1.1 linux/drivers/mtd/devices/Config.in - 1.1 linux/drivers/mtd/chips/sharp.c - 1.1 linux/drivers/mtd/chips/map_rom.c - 1.1 linux/drivers/mtd/chips/map_ram.c - 1.1 linux/drivers/mtd/chips/jedec.c - 1.1 linux/drivers/mtd/chips/chipreg.c - 1.1 linux/drivers/mtd/chips/cfi_probe.c - 1.1 linux/drivers/mtd/chips/cfi_jedec.c - 1.1 linux/drivers/mtd/chips/cfi_cmdset_0002.c - 1.1 linux/drivers/mtd/chips/cfi_cmdset_0001.c - 1.1 linux/drivers/mtd/chips/amd_flash.c - 1.1 linux/drivers/mtd/chips/Makefile - 1.1 linux/drivers/mtd/chips/Config.in - 1.1 linux/drivers/media/radio/miropcm20-rds.c - 1.1 linux/drivers/media/radio/miropcm20-rds-core.h - 1.1 linux/drivers/media/radio/miropcm20-rds-core.c - 1.1 linux/drivers/media/radio/miropcm20-radio.c - 1.1 linux/mm/vmscan.c - 1.58 linux/mm/filemap.c - 1.77 linux/include/linux/swap.h - 1.28 linux/include/linux/quotaops.h - 1.8 linux/include/linux/pci.h - 1.43 linux/include/linux/kernel.h - 1.18 linux/include/linux/fs.h - 1.99 linux/include/linux/coda_cache.h - 1.5 linux/include/asm-sparc64/string.h - 1.7 linux/include/asm-sparc64/softirq.h - 1.7 linux/include/asm-sparc64/linux_logo.h - 1.4 linux/include/asm-sparc64/hardirq.h - 1.11 linux/include/asm-sparc/softirq.h - 1.8 linux/include/asm-sparc/linux_logo.h - 1.4 linux/include/asm-sparc/hardirq.h - 1.10 linux/include/asm-ppc/softirq.h - 1.11 linux/include/asm-ppc/hardirq.h - 1.13 linux/include/asm-m68k/linux_logo.h - 1.4 linux/include/asm-i386/mca_dma.h - 1.5 linux/include/asm-alpha/delay.h - 1.8 linux/fs/sysv/inode.c - 1.20 linux/fs/super.c - 1.48 linux/fs/proc/base.c - 1.24 linux/fs/proc/array.c - 1.29 linux/fs/nfsd/nfsfh.c - 1.26 linux/fs/nfsd/export.c - 1.18 linux/fs/nfs/inode.c - 1.26 linux/fs/nfs/dir.c - 1.29 linux/fs/namei.c - 1.31 linux/fs/inode.c - 1.43 linux/fs/dquot.c - 1.27 linux/fs/buffer.c - 1.67 linux/drivers/video/creatorfb.c - 1.9 linux/drivers/usb/usb.c - 1.50 linux/drivers/usb/uhci.c - 1.44 linux/drivers/usb/audio.c - 1.31 linux/drivers/sound/wf_midi.c - 1.8 linux/drivers/sound/pss.c - 1.9 linux/drivers/sound/gus_wave.c - 1.7 linux/drivers/scsi/sym53c8xx.c - 1.24 linux/drivers/scsi/sd.c - 1.36 linux/drivers/scsi/scsi.c - 1.36 linux/drivers/scsi/constants.c - 1.7 linux/drivers/scsi/NCR53c406a.c - 1.9 linux/drivers/pci/pci.c - 1.37 linux/drivers/pci/Makefile - 1.16 linux/drivers/net/eepro100.c - 1.29 linux/drivers/isdn/isdn_ppp.c - 1.15 linux/drivers/isdn/hisax/tei.c - 1.8 linux/drivers/isdn/hisax/isdnl3.c - 1.11 linux/drivers/isdn/hisax/isdnl2.c - 1.10 linux/drivers/isdn/hisax/isdnl1.c - 1.11 linux/drivers/isdn/hisax/hisax.h - 1.17 linux/drivers/isdn/hisax/fsm.c - 1.8 linux/drivers/isdn/hisax/config.c - 1.18 linux/drivers/isdn/hisax/callc.c - 1.12 linux/drivers/isdn/avmb1/capiutil.h - 1.5 linux/drivers/isdn/avmb1/capicmd.h - 1.4 linux/drivers/isdn/avmb1/b1pci.c - 1.14 linux/drivers/char/rtc.c - 1.20 linux/drivers/char/random.c - 1.15 linux/drivers/char/console.c - 1.22 linux/drivers/block/ll_rw_blk.c - 1.69 linux/arch/sparc64/kernel/time.c - 1.14 linux/arch/sparc64/kernel/rtrap.S - 1.8 linux/arch/sparc64/kernel/ebus.c - 1.13 linux/arch/sparc64/kernel/devices.c - 1.10 linux/arch/sparc/kernel/rtrap.S - 1.7 linux/arch/ppc/kernel/ppc_ksyms.c - 1.31 linux/arch/i386/math-emu/fpu_trig.c - 1.5 linux/arch/i386/kernel/entry.S - 1.34 linux/arch/i386/defconfig - 1.57 linux/arch/alpha/kernel/sys_sable.c - 1.8 linux/arch/alpha/kernel/osf_sys.c - 1.24 linux/Makefile - 1.90 linux/MAINTAINERS - 1.60 linux/Documentation/sound/README.OSS - 1.6 linux/Documentation/Configure.help - 1.82 linux/CREDITS - 1.54 linux/drivers/usb/printer.c - 1.36 linux/drivers/usb/acm.c - 1.38 linux/drivers/isdn/hisax/md5sums.asc - 1.12 linux/arch/ppc/xmon/xmon.c - 1.15 linux/drivers/usb/uss720.c - 1.19 linux/net/khttpd/security.h - 1.2 linux/fs/partitions/check.c - 1.24 linux/drivers/isdn/hisax/gazel.c - 1.9 linux/drivers/isdn/avmb1/t1isa.c - 1.12 linux/drivers/isdn/avmb1/kcapi.c - 1.13 linux/drivers/isdn/avmb1/b1pcmcia.c - 1.12 linux/drivers/isdn/avmb1/b1isa.c - 1.10 linux/drivers/isdn/avmb1/b1.c - 1.13 linux/arch/ppc/kernel/entry.S - 1.19 linux/arch/sparc64/kernel/power.c - 1.6 linux/arch/sparc64/kernel/pci_sabre.c - 1.21 linux/arch/sparc64/kernel/pci_common.c - 1.11 linux/arch/sparc64/kernel/pci.c - 1.20 linux/drivers/net/tokenring/ibmtr.c - 1.13 linux/include/linux/pci_ids.h - 1.36 linux/drivers/net/wan/sdla_x25.c - 1.7 linux/drivers/net/wan/sdla_fr.c - 1.11 linux/drivers/usb/dc2xx.c - 1.19 linux/drivers/isdn/avmb1/t1pci.c - 1.13 linux/kernel/timer.c - 1.13 linux/drivers/usb/dabusb.c - 1.11 linux/drivers/pcmcia/pci_socket.c - 1.8 linux/drivers/usb/usbmouse.c - 1.12 linux/drivers/usb/usbkbd.c - 1.15 linux/drivers/usb/ov511.c - 1.23 linux/drivers/usb/hid.c - 1.25 linux/drivers/scsi/scsi_scan.c - 1.15 linux/drivers/usb/usb-uhci.c - 1.21 linux/drivers/usb/usb-ohci.h - 1.11 linux/drivers/usb/usb-ohci.c - 1.21 linux/drivers/usb/ibmcam.c - 1.13 linux/drivers/isdn/avmb1/c4.c - 1.13 linux/drivers/isdn/avmb1/b1dma.c - 1.14 linux/Documentation/filesystems/devfs/README - 1.7 linux/Documentation/filesystems/devfs/ChangeLog - 1.8 linux/drivers/usb/plusb.c - 1.12 linux/include/linux/devfs_fs_kernel.h - 1.5 linux/drivers/isdn/hysdn/hysdn_net.c - 1.8 linux/fs/devfs/util.c - 1.5 linux/fs/devfs/base.c - 1.16 linux/drivers/isdn/hysdn/hysdn_proclog.c - 1.9 linux/drivers/atm/fore200e.c - 1.10 linux/drivers/usb/wacom.c - 1.13 linux/drivers/usb/rio500.c - 1.11 linux/drivers/usb/pegasus.c - 1.18 linux/drivers/sound/aci.c - 1.6 linux/drivers/ide/ide-tape.c - 1.11 linux/drivers/usb/dsbr100.c - 1.10 linux/drivers/isdn/avmb1/capifs.c - 1.11 linux/drivers/isdn/avmb1/capifs.h - 1.2 linux/drivers/usb/mdc800.c - 1.10 linux/drivers/usb/serial/keyspan_pda.c - 1.14 linux/drivers/usb/serial/ftdi_sio.c - 1.17 linux/drivers/usb/serial/usbserial.c - 1.16 linux/drivers/usb/serial/whiteheat.c - 1.14 linux/drivers/usb/serial/visor.c - 1.17 linux/drivers/usb/serial/omninet.c - 1.13 linux/drivers/usb/serial/digi_acceleport.c - 1.13 linux/drivers/usb/storage/debug.c - 1.4 linux/drivers/usb/serial/keyspan.c - 1.10 linux/drivers/usb/microtek.c - 1.9 linux/drivers/usb/bluetooth.c - 1.11 linux/drivers/mtd/Config.in - 1.4 linux/drivers/mtd/Makefile - 1.6 linux/drivers/mtd/cfi_cmdset_0001.c - 1.4 linux/drivers/mtd/cfi_cmdset_0002.c - 1.6 linux/drivers/mtd/cfi_probe.c - 1.5 linux/drivers/mtd/doc1000.c - 1.4 linux/drivers/mtd/doc2000.c - 1.5 linux/drivers/mtd/doc2001.c - 1.5 linux/drivers/mtd/docprobe.c - 1.6 linux/drivers/mtd/ftl.c - 1.5 linux/drivers/mtd/jedec.c - 1.2 linux/drivers/mtd/map_ram.c - 1.5 linux/drivers/mtd/map_rom.c - 1.4 linux/drivers/mtd/mixmem.c - 1.3 linux/drivers/mtd/mtdchar.c - 1.6 linux/drivers/mtd/mtdcore.c - 1.4 linux/drivers/mtd/mtdram.c - 1.3 linux/drivers/mtd/nftl.c - 1.5 linux/drivers/mtd/nora.c - 1.3 linux/drivers/mtd/octagon-5066.c - 1.4 linux/drivers/mtd/physmap.c - 1.3 linux/drivers/mtd/pmc551.c - 1.5 linux/drivers/mtd/pnc2000.c - 1.3 linux/drivers/mtd/rpxlite.c - 1.4 linux/drivers/mtd/slram.c - 1.3 linux/drivers/mtd/vmax301.c - 1.4 linux/include/linux/mtd/cfi.h - 1.4 linux/include/linux/mtd/doc2000.h - 1.3 linux/include/linux/mtd/flashchip.h - 1.2 linux/include/linux/mtd/map.h - 1.6 linux/include/linux/mtd/mapped.h - 1.2 linux/include/linux/mtd/mtd.h - 1.4 linux/include/linux/mtd/nftl.h - 1.3 linux/drivers/media/video/tuner.c - 1.4 linux/drivers/media/radio/radio-miropcm20.c - 1.6 linux/drivers/media/radio/Makefile - 1.6 linux/drivers/media/radio/Config.in - 1.5 linux/drivers/isdn/hysdn/hycapi.c - 1.7 linux/drivers/usb/net1080.c - 1.6 linux/drivers/usb/serial/belkin_sa.c - 1.7 linux/drivers/mtd/docecc.c - 1.3 linux/drivers/usb/serial/mct_u232.c - 1.6 linux/drivers/usb/serial/empeg.c - 1.6 linux/drivers/sound/ymfpci.c - 1.7 linux/include/linux/mtd/partitions.h - 1.2 linux/drivers/mtd/nftlmount.c - 1.4 linux/drivers/mtd/mtdpart.c - 1.3 linux/drivers/scsi/osst.c - 1.4 linux/fs/reiserfs/stree.c - 1.4 linux/fs/reiserfs/super.c - 1.4 linux/fs/reiserfs/journal.c - 1.3 linux/fs/reiserfs/inode.c - 1.4 linux/fs/reiserfs/fix_node.c - 1.4 linux/include/linux/reiserfs_fs.h - 1.4 linux/drivers/usb/serial/io_edgeport.c - 1.5 linux/drivers/scsi/aic7xxx_old.c - 1.3 linux/drivers/net/wan/hdlc.c - 1.3 linux/drivers/sound/aci.h - 1.2 linux/drivers/media/radio/rds-miropcm20.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Jun 12 20:53:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D3r9A30838 for linux-xfs-outgoing; Tue, 12 Jun 2001 20:53:09 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D3r7P30835 for ; Tue, 12 Jun 2001 20:53:07 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip36.idcomm.com [209.60.72.163]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5D3qYl06840 for ; Tue, 12 Jun 2001 21:52:35 -0600 Message-ID: <3B26E3DF.1B22B76A@idcomm.com> Date: Tue, 12 Jun 2001 21:54:07 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <3B26C626.24EC0F20@idcomm.com> <3B26CC5E.6050804@uswest.net> <3B26D839.E6C58E3E@idcomm.com> <3B26DCBB.2289C8FC@sigmastorage.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Matt Ryan wrote: > > sorry, I meant to write that to the list as well. I just wrote: > > gzip -dc your.img > somefile > mount -o loop somefile somedir > > also, just running mkinitrd with the verbose (-v) option is pretty > helpful too > (not sure if you were doing that already). I've done -v, and also mounted each of the initrd images since then. I definitely have the three modules I know of which are required: pagebuf.o xfs.o xfs_support.o Perhaps there is some kind of argument or order required that I don't have? Or, since I compiled the kernel on RH 7.1 and used kgcc, would there be some sort of change required to the compile of mkinitrd.xfs to make it use kgcc as well? I noticed this URL does not have mkinitrd.xfs man page: http://oss.sgi.com/projects/xfs/manpages.html ...and the cvs cmd/xfsmisc/ does not seem to produce one either. My assumption is that this and the original mkinitrd are identical (incidentally, I turned in a report to RH bugzilla that their man page does not match the command line option syntax of mkinitrd --help...the latter is accurate, the former not for --preload=). So can *anyone* verify that it really is possible to run XFS as modules? If so, can I get a list of modules you have under lsmod? Or if you remember, a sample of the mkinitrd.xfs line used? D. Stimits, stimits@idcomm.com > > Matt > > > > > While I'm convinced that this is the basic problem, I can't figure out > > what is missing. Matt Ryan gave me one very useful command to mount my > > initial ramdisk on loopback and see what it actually contains. I can From owner-linux-xfs@oss.sgi.com Tue Jun 12 21:45:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D4jEs04760 for linux-xfs-outgoing; Tue, 12 Jun 2001 21:45:14 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D4jDP04757 for ; Tue, 12 Jun 2001 21:45:13 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f5D4jAaJ086395; Tue, 12 Jun 2001 23:45:10 -0500 (CDT) Message-ID: <3B26EFD1.723327FA@thebarn.com> Date: Tue, 12 Jun 2001 23:45:05 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: stimits@idcomm.com CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <3B26C626.24EC0F20@idcomm.com> <3B26CC5E.6050804@uswest.net> <3B26D839.E6C58E3E@idcomm.com> <3B26DCBB.2289C8FC@sigmastorage.com> <3B26E3DF.1B22B76A@idcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "D. Stimits" wrote: > Matt Ryan wrote: > > > > sorry, I meant to write that to the list as well. I just wrote: > > > > gzip -dc your.img > somefile > > mount -o loop somefile somedir > > > > also, just running mkinitrd with the verbose (-v) option is pretty > > helpful too > > (not sure if you were doing that already). > > I've done -v, and also mounted each of the initrd images since then. I > definitely have the three modules I know of which are required: > pagebuf.o > xfs.o > xfs_support.o note the modules must load in this order pagebuf xfs_support xfs When specifying them on the command the order they are given is the order they are loaded. The mkinird.xfs in the source tree just added the modules to the basicmodules list rather than having to list them by hand on the command line. Note the 0.9 release of XFS installed xfs as modules using mkinitrd.xfs to build the initrd, the 0.10 and 1.0 release did not do this since boots seem to take slightly less time with xfs in the kernel. > > > Perhaps there is some kind of argument or order required that I don't > have? Or, since I compiled the kernel on RH 7.1 and used kgcc, would > there be some sort of change required to the compile of mkinitrd.xfs to > make it use kgcc as well? I noticed this URL does not have mkinitrd.xfs > man page: > http://oss.sgi.com/projects/xfs/manpages.html > > ...and the cvs cmd/xfsmisc/ does not seem to produce one either. My > assumption is that this and the original mkinitrd are identical > (incidentally, I turned in a report to RH bugzilla that their man page > does not match the command line option syntax of mkinitrd --help...the > latter is accurate, the former not for --preload=). > > So can *anyone* verify that it really is possible to run XFS as modules? > If so, can I get a list of modules you have under lsmod? Or if you > remember, a sample of the mkinitrd.xfs line used? > > D. Stimits, stimits@idcomm.com > > > > > Matt > > > > > > > > While I'm convinced that this is the basic problem, I can't figure out > > > what is missing. Matt Ryan gave me one very useful command to mount my > > > initial ramdisk on loopback and see what it actually contains. I can -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Tue Jun 12 22:16:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D5Gba08450 for linux-xfs-outgoing; Tue, 12 Jun 2001 22:16:37 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D5GZP08443 for ; Tue, 12 Jun 2001 22:16:36 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id HAA00764; Wed, 13 Jun 2001 07:16:34 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id HAA00737; Wed, 13 Jun 2001 07:16:33 +0200 (CEST) Date: Wed, 13 Jun 2001 07:16:33 +0200 (CEST) From: Seth Mos To: "D. Stimits" cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? In-Reply-To: <3B26A5DD.1BAAA1A5@idcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 12 Jun 2001, D. Stimits wrote: > I am trying to take what is very close to my working kernel > configuration, and change it around slightly so that ramdisk and modules > are used for the XFS related items. The reason being that with these in > the kernel and not as module, the image is too large for floppy...I'm > going to attempt a 2 floppy boot setup. However, either mkinitrd.xfs is > failing, or something with lilo config is failing. The system is scsi, > but scsi is being compiled in and not as a module. System is RH 7.1 > based. Here is what happens.... There is a entry and link in the faq to make mkbootdisk format larger floppy's. If you do that you can compile both xfs and your scsi driver in. I use 1.68MB boot floppy's for my servers at work. The kernel contains XFS, megaraid and eepro100 compiled in. It should work for you to. You are running into space contraints. Seth From owner-linux-xfs@oss.sgi.com Tue Jun 12 23:41:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D6fp318206 for linux-xfs-outgoing; Tue, 12 Jun 2001 23:41:51 -0700 Received: from blipvert.blank.org (blipvert.blank.org [216.112.239.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D6foP18201 for ; Tue, 12 Jun 2001 23:41:50 -0700 Received: (qmail 7604 invoked by uid 500); 13 Jun 2001 06:41:49 -0000 Date: Wed, 13 Jun 2001 02:41:49 -0400 From: "Nathan J. Mehl" To: Russell Cattelan Cc: Eric Sandeen , Juha Saarinen , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp Message-ID: <20010613024149.Z8330@blank.org> References: <3B24E5A1.7404BFBA@thebarn.com> <3B24E732.D3A3C8A6@sgi.com> <3B24EE05.F7E46B6C@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B24EE05.F7E46B6C@thebarn.com>; from cattelan@thebarn.com on Mon, Jun 11, 2001 at 11:12:53AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [a late response, my apologies] In the immortal words of Russell Cattelan (cattelan@thebarn.com): > > It wasn't an issue of gain or not gain for SGI but a sense of what could > be lost: > XFS on solaris seems to be the biggest fear. Is it? Sun is already shipping a number of GPLed utlities with Solaris 8. (Most notably and blessedly, /bin/bash.) There's even source code included, buried deeply back on installation CD #8934... I rather expect that if Sun thought they could gain some sort of competetive advantage from shipping Solaris 9 with XFS, they'd simply go ahead and do so with the existing GPL code. However, I can't see it happening. Sun has a strong financial disincentive against such a move: they currently make money off of selling "server" editions of Solaris (which bundle Solstice Disksuite) and rebadged copies of VXFS/VXVM for Solaris. Why ship for free what they currently make in the neighborhood of $5k/seat for? :) -n ------------------------------------------------------------ no plans / I'll go where the machine goes / the past is a placebo / dissolving in a drain / I'll sleep beside the railroad tracks / with no more rent or income tax / I got no fixed address now / I'm waiting for a train. (--Firewater, "So Long Superman") ---------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Jun 12 23:44:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D6iR318431 for linux-xfs-outgoing; Tue, 12 Jun 2001 23:44:27 -0700 Received: from blipvert.blank.org (blipvert.blank.org [216.112.239.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D6iQP18426 for ; Tue, 12 Jun 2001 23:44:26 -0700 Received: (qmail 7624 invoked by uid 500); 13 Jun 2001 06:44:25 -0000 Date: Wed, 13 Jun 2001 02:44:25 -0400 From: "Nathan J. Mehl" To: Juha Saarinen Cc: Micah Yoder , "linux-xfs@oss.sgi.com" Subject: Re: Stability of the Red Hat 7.1 + XFS system Message-ID: <20010613024425.A8330@blank.org> References: <01061114170409.01070@eclipse> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from juha@saarinen.org on Tue, Jun 12, 2001 at 10:04:01AM +1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In the immortal words of Juha Saarinen (juha@saarinen.org): > On Mon, 11 Jun 2001, Micah Yoder wrote: > > > I just installed RH 7.1 w/SGI's CD and the kernel on it. The server is > > co-located, about 400 miles away... > > Is this the VIA chip set box? Evil stuff... ;-) I think you're mistaking this gentleman's problem for mine. As much as I'm enjoying my little test run with xfs, I'm nowhere near confident enough to use it on a remotely colocated production machine yet. :) -n ------------------------------------------------------------ "There are certain phrases that inspire an instinctive dread in moviegoers: `Tarantino-esque'; `big in France'; `starring Andy Garcia.'" (--M.E. Williams) ---------------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Jun 13 03:01:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DA1WY30696 for linux-xfs-outgoing; Wed, 13 Jun 2001 03:01:32 -0700 Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DA1VP30693 for ; Wed, 13 Jun 2001 03:01:31 -0700 Received: by giants.mandrakesoft.com (Postfix, from userid 500) id 43C2FC9B8; Wed, 13 Jun 2001 12:01:10 +0200 (CEST) To: Juha Saarinen Cc: Russell Cattelan , Seth Mos , Steve Lord , "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile References: From: Chmouel Boudjnah Date: 13 Jun 2001 12:01:10 +0200 In-Reply-To: (Juha Saarinen's message of "Wed, 13 Jun 2001 11:11:35 +1200 (NZST)") Message-ID: Lines: 15 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.103 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juha Saarinen writes: > On Tue, 12 Jun 2001, Russell Cattelan wrote: > > > Juha Saarinen wrote: > > > > Right sorry I didn't spot this sooner > > gcc -V egcs-2.91.66 does not work on RH or Mandrake system > > you must use kgcc to invoke the compiler... I'm not sure what > > difference it makes but it does. > > Hmmm... well, that worked. Maybe worth updating the Makefile? no, it is the gcc driver interface who was broken. i believe that has been fixed in our latest gcc for us.. From owner-linux-xfs@oss.sgi.com Wed Jun 13 03:27:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DARde02053 for linux-xfs-outgoing; Wed, 13 Jun 2001 03:27:39 -0700 Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DARbP02048 for ; Wed, 13 Jun 2001 03:27:38 -0700 Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id GAA08544; Wed, 13 Jun 2001 06:27:35 -0400 (EDT) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <0GEV002016CDOH@lmco.com>; Wed, 13 Jun 2001 06:26:37 -0400 (EDT) Received: from lmco.com ([134.5.85.243]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <0GEV007DX6C9X4@lmco.com>; Wed, 13 Jun 2001 06:26:33 -0400 (EDT) Date: Wed, 13 Jun 2001 05:18:32 -0400 From: "Jeffrey B. Layton" Subject: Re: Interest from the FreeBSD camp To: "Nathan J. Mehl" Cc: linux-xfs@oss.sgi.com Message-id: <3B272FE8.97A8F575@lmco.com> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.19-plogic-lmco4smp i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <3B24E5A1.7404BFBA@thebarn.com> <3B24E732.D3A3C8A6@sgi.com> <3B24EE05.F7E46B6C@thebarn.com> <20010613024149.Z8330@blank.org> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Correct me if I'm wrong, but doesn't Solaris use a Veritas filesystem as the default filesystem (I know HP does). If that is the case, then getting rid of royalities to Veritas but still charging the same per license would increase their profits. Sure sounds like motivation to me :) Jeff "Nathan J. Mehl" wrote: > [a late response, my apologies] > > In the immortal words of Russell Cattelan (cattelan@thebarn.com): > > > > It wasn't an issue of gain or not gain for SGI but a sense of what could > > be lost: > > XFS on solaris seems to be the biggest fear. > > Is it? > > Sun is already shipping a number of GPLed utlities with Solaris 8. > (Most notably and blessedly, /bin/bash.) There's even source code > included, buried deeply back on installation CD #8934... I rather > expect that if Sun thought they could gain some sort of competetive > advantage from shipping Solaris 9 with XFS, they'd simply go ahead and > do so with the existing GPL code. > > However, I can't see it happening. Sun has a strong financial > disincentive against such a move: they currently make money off of > selling "server" editions of Solaris (which bundle Solstice Disksuite) > and rebadged copies of VXFS/VXVM for Solaris. Why ship for free what > they currently make in the neighborhood of $5k/seat for? :) > > -n > > ------------------------------------------------------------ > no plans / I'll go where the machine goes / the past is a placebo / dissolving > in a drain / I'll sleep beside the railroad tracks / with no more rent > or income tax / I got no fixed address now / I'm waiting for a train. > (--Firewater, "So Long Superman") > ---------------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Jun 13 03:50:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DAoNl05670 for linux-xfs-outgoing; Wed, 13 Jun 2001 03:50:23 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DAoKP05665 for ; Wed, 13 Jun 2001 03:50:20 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5DAoCV26151; Wed, 13 Jun 2001 12:50:13 +0200 Message-Id: <4.3.2.7.2.20010613124643.04cb8fa8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Jun 2001 12:50:11 +0200 To: "Jeffrey B. Layton" , "Nathan J. Mehl" From: Seth Mos Subject: Re: Interest from the FreeBSD camp Cc: linux-xfs@oss.sgi.com In-Reply-To: <3B272FE8.97A8F575@lmco.com> References: <3B24E5A1.7404BFBA@thebarn.com> <3B24E732.D3A3C8A6@sgi.com> <3B24EE05.F7E46B6C@thebarn.com> <20010613024149.Z8330@blank.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 05:18 13-6-2001 -0400, Jeffrey B. Layton wrote: >Correct me if I'm wrong, but doesn't Solaris use a Veritas >filesystem as the default filesystem (I know HP does). >If that is the case, then getting rid of royalities to Veritas >but still charging the same per license would increase >their profits. Sure sounds like motivation to me :) > >Jeff True, they will sell you an a Veritas Journaling FS if you pay deerly for it. You must pay seperately for their volume manager and it is also tied to the size of your storage. BUt i'm not sure about that. The Filesystem is called VxFS, there is now also a freevxfs.o for the linux kernel but this is read only and does not support all on-disk formats of the fs. It seems like the on-disk format is different between variants of their FS. >"Nathan J. Mehl" wrote: > > > [a late response, my apologies] > > > > In the immortal words of Russell Cattelan (cattelan@thebarn.com): > > > > > > It wasn't an issue of gain or not gain for SGI but a sense of what could > > > be lost: > > > XFS on solaris seems to be the biggest fear. > > > > Is it? > > > > Sun is already shipping a number of GPLed utlities with Solaris 8. > > (Most notably and blessedly, /bin/bash.) There's even source code > > included, buried deeply back on installation CD #8934... I rather > > expect that if Sun thought they could gain some sort of competetive > > advantage from shipping Solaris 9 with XFS, they'd simply go ahead and > > do so with the existing GPL code. > > > > However, I can't see it happening. Sun has a strong financial > > disincentive against such a move: they currently make money off of > > selling "server" editions of Solaris (which bundle Solstice Disksuite) > > and rebadged copies of VXFS/VXVM for Solaris. Why ship for free what > > they currently make in the neighborhood of $5k/seat for? :) > > > > -n > > > > > ------------------------------------------------------------ > > no plans / I'll go where the machine goes / the past is a placebo / > dissolving > > in a drain / I'll sleep beside the railroad tracks / with no more rent > > or income tax / I got no fixed address now / I'm waiting for a train. > > (--Firewater, "So Long > Superman") > > > ---------------------------------------------------- -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Jun 13 03:57:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DAvFX06835 for linux-xfs-outgoing; Wed, 13 Jun 2001 03:57:15 -0700 Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DAvEP06831 for ; Wed, 13 Jun 2001 03:57:14 -0700 Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id GAA10767; Wed, 13 Jun 2001 06:57:13 -0400 (EDT) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <0GEV00N017PYHY@lmco.com>; Wed, 13 Jun 2001 06:56:22 -0400 (EDT) Received: from lmco.com ([134.5.85.243]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <0GEV0006O7PVKQ@lmco.com>; Wed, 13 Jun 2001 06:56:19 -0400 (EDT) Date: Wed, 13 Jun 2001 05:48:18 -0400 From: "Jeffrey B. Layton" Subject: Re: Interest from the FreeBSD camp To: linux-xfs@oss.sgi.com Cc: knuffie@xs4all.nl Message-id: <3B2736E2.E10A2265@lmco.com> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.19-plogic-lmco4smp i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <3B24E5A1.7404BFBA@thebarn.com> <3B24E732.D3A3C8A6@sgi.com> <3B24EE05.F7E46B6C@thebarn.com> <20010613024149.Z8330@blank.org> <4.3.2.7.2.20010613124643.04cb8fa8@pop.xs4all.nl> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > At 05:18 13-6-2001 -0400, Jeffrey B. Layton wrote: > > >Correct me if I'm wrong, but doesn't Solaris use a Veritas > >filesystem as the default filesystem (I know HP does). > >If that is the case, then getting rid of royalities to Veritas > >but still charging the same per license would increase > >their profits. Sure sounds like motivation to me :) > > > >Jeff > > True, they will sell you an a Veritas Journaling FS if you pay deerly for it. > You must pay seperately for their volume manager and it is also tied to the > size of your storage. BUt i'm not sure about that. Ah... That's also true with HP. We had to pay a large amount to get on-line FS resizing (since it's a Veritas product). With HPUX 11.0, LVM was a HP product (I think) that came with the OS. I've just read that with 11i, LVM is now the Veritas LVM. I don't have any experience with the Veritas LVM, but I rather like the HP LVM (and the Linux LVM!). I've seen freevxfs.o but haven't tried it yet. I would think that for companies like HP and Sun that have very large pools of talented programmers, writing their own FS over a period of a couple of years would yield better $ than licensing software from Veritas. In my experience, Veritas has to be one of the most expensive companies to deal with and their tech support is not good at all. Anyway, just my opinion. Sorry for wasting space. Jeff > > > The Filesystem is called VxFS, there is now also a freevxfs.o for the linux > kernel but this is read only and does not support all on-disk formats of > the fs. It seems like the on-disk format is different between variants of > their FS. > > >"Nathan J. Mehl" wrote: > > > > > [a late response, my apologies] > > > > > > In the immortal words of Russell Cattelan (cattelan@thebarn.com): > > > > > > > > It wasn't an issue of gain or not gain for SGI but a sense of what could > > > > be lost: > > > > XFS on solaris seems to be the biggest fear. > > > > > > Is it? > > > > > > Sun is already shipping a number of GPLed utlities with Solaris 8. > > > (Most notably and blessedly, /bin/bash.) There's even source code > > > included, buried deeply back on installation CD #8934... I rather > > > expect that if Sun thought they could gain some sort of competetive > > > advantage from shipping Solaris 9 with XFS, they'd simply go ahead and > > > do so with the existing GPL code. > > > > > > However, I can't see it happening. Sun has a strong financial > > > disincentive against such a move: they currently make money off of > > > selling "server" editions of Solaris (which bundle Solstice Disksuite) > > > and rebadged copies of VXFS/VXVM for Solaris. Why ship for free what > > > they currently make in the neighborhood of $5k/seat for? :) > > > > > > -n > > > > > > > > ------------------------------------------------------------ > > > no plans / I'll go where the machine goes / the past is a placebo / > > dissolving > > > in a drain / I'll sleep beside the railroad tracks / with no more rent > > > or income tax / I got no fixed address now / I'm waiting for a train. > > > (--Firewater, "So Long > > Superman") > > > > > ---------------------------------------------------- > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Jun 13 03:57:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DAvOH06874 for linux-xfs-outgoing; Wed, 13 Jun 2001 03:57:24 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DAvMP06870 for ; Wed, 13 Jun 2001 03:57:22 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5DAvFm05813; Wed, 13 Jun 2001 20:57:16 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Chmouel Boudjnah cc: "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-reply-to: Your message of "13 Jun 2001 12:01:10 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Jun 2001 20:57:15 +1000 Message-ID: <5812.992429835@ocs4.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 13 Jun 2001 12:01:10 +0200, Chmouel Boudjnah wrote: >Juha Saarinen writes: >> > Juha Saarinen wrote: >> > >> > Right sorry I didn't spot this sooner >> > gcc -V egcs-2.91.66 does not work on RH or Mandrake system >> > you must use kgcc to invoke the compiler... I'm not sure what >> > difference it makes but it does. >> >> Hmmm... well, that worked. Maybe worth updating the Makefile? > >no, it is the gcc driver interface who was broken. i believe that has >been fixed in our latest gcc for us.. Is the bug the lack of flag -$ in gcc -V egcs-2.91.66? Adding -$ to the cpp flags compiles trampoline.S. Or are there other bugs in the gcc driver? From owner-linux-xfs@oss.sgi.com Wed Jun 13 04:08:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DB8sA09015 for linux-xfs-outgoing; Wed, 13 Jun 2001 04:08:54 -0700 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DB8qP09008 for ; Wed, 13 Jun 2001 04:08:52 -0700 Received: (from hch@localhost) by ns.caldera.de (8.11.1/8.11.1) id f5DB8Rj25870; Wed, 13 Jun 2001 13:08:27 +0200 Date: Wed, 13 Jun 2001 13:08:26 +0200 From: Christoph Hellwig To: "Jeffrey B. Layton" Cc: "Nathan J. Mehl" , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp Message-ID: <20010613130826.A25781@caldera.de> References: <3B24E5A1.7404BFBA@thebarn.com> <3B24E732.D3A3C8A6@sgi.com> <3B24EE05.F7E46B6C@thebarn.com> <20010613024149.Z8330@blank.org> <3B272FE8.97A8F575@lmco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B272FE8.97A8F575@lmco.com>; from jeffrey.b.layton@lmco.com on Wed, Jun 13, 2001 at 05:18:32AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Jun 13, 2001 at 05:18:32AM -0400, Jeffrey B. Layton wrote: > > Correct me if I'm wrong, but doesn't Solaris use a Veritas > filesystem as the default filesystem (I know HP does). No. The default is UFS. Christoph -- Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Wed Jun 13 04:10:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DBAgV09364 for linux-xfs-outgoing; Wed, 13 Jun 2001 04:10:42 -0700 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DBAfP09353 for ; Wed, 13 Jun 2001 04:10:41 -0700 Received: (from hch@localhost) by ns.caldera.de (8.11.1/8.11.1) id f5DB9oh25953; Wed, 13 Jun 2001 13:09:50 +0200 Date: Wed, 13 Jun 2001 13:09:50 +0200 From: Christoph Hellwig To: Seth Mos Cc: "Jeffrey B. Layton" , "Nathan J. Mehl" , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp Message-ID: <20010613130950.B25781@caldera.de> References: <3B24E5A1.7404BFBA@thebarn.com> <3B24E732.D3A3C8A6@sgi.com> <3B24EE05.F7E46B6C@thebarn.com> <20010613024149.Z8330@blank.org> <3B272FE8.97A8F575@lmco.com> <4.3.2.7.2.20010613124643.04cb8fa8@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010613124643.04cb8fa8@pop.xs4all.nl>; from knuffie@xs4all.nl on Wed, Jun 13, 2001 at 12:50:11PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Jun 13, 2001 at 12:50:11PM +0200, Seth Mos wrote: > The Filesystem is called VxFS, there is now also a freevxfs.o for the linux > kernel but this is read only and does not support all on-disk formats of > the fs. It seems like the on-disk format is different between variants of > their FS. Only HP-UX has a major difference in the ondisk format. If you are able to test it I can send you code that should be able to read it. Christoph -- Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Wed Jun 13 06:55:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DDtgY00669 for linux-xfs-outgoing; Wed, 13 Jun 2001 06:55:42 -0700 Received: from getz.wrkhors.com (jeeves.wrkhors.com [207.227.243.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DDtfP00665 for ; Wed, 13 Jun 2001 06:55:41 -0700 Received: from dizzy (dizzy.wrkhors.com [192.168.200.4]) by getz.wrkhors.com (Switch-2.0.0/8.9.3) with ESMTP id f5DDtIw27929 for ; Wed, 13 Jun 2001 08:55:19 -0500 Date: Wed, 13 Jun 2001 08:55:20 -0500 From: Steven Lembark To: linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp Message-ID: <374140000.992440520@dizzy> In-Reply-To: <3B2736E2.E10A2265@lmco.com> References: <3B24E5A1.7404BFBA@thebarn.com> <3B24E732.D3A3C8A6@sgi.com> <3B24EE05.F7E46B6C@thebarn.com> <20010613024149.Z8330@blank.org> <4.3.2.7.2.20010613124643.04cb8fa8@pop.xs4all.nl> <3B2736E2.E10A2265@lmco.com> X-Mailer: Mulberry/2.1.0a6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >With HPUX 11.0, > LVM was a HP product (I think) that came with the OS. It's been built in for years, comes with the O/S and actually works rather well. From owner-linux-xfs@oss.sgi.com Wed Jun 13 08:31:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DFVD410597 for linux-xfs-outgoing; Wed, 13 Jun 2001 08:31:13 -0700 Received: from blipvert.blank.org (blipvert.blank.org [216.112.239.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DFVCP10588 for ; Wed, 13 Jun 2001 08:31:12 -0700 Received: (qmail 10384 invoked by uid 500); 13 Jun 2001 15:31:11 -0000 Date: Wed, 13 Jun 2001 11:31:11 -0400 From: "Nathan J. Mehl" To: "Jeffrey B. Layton" Cc: linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp Message-ID: <20010613113111.B8330@blank.org> References: <3B24E5A1.7404BFBA@thebarn.com> <3B24E732.D3A3C8A6@sgi.com> <3B24EE05.F7E46B6C@thebarn.com> <20010613024149.Z8330@blank.org> <3B272FE8.97A8F575@lmco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B272FE8.97A8F575@lmco.com>; from jeffrey.b.layton@lmco.com on Wed, Jun 13, 2001 at 05:18:32AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In the immortal words of Jeffrey B. Layton (jeffrey.b.layton@lmco.com): > > Correct me if I'm wrong, but doesn't Solaris use a Veritas > filesystem as the default filesystem (I know HP does). > If that is the case, then getting rid of royalities to Veritas > but still charging the same per license would increase > their profits. Sure sounds like motivation to me :) Nope. By default, Sun uses plain-ol-UFS. (As of 2.8, they added metadata logging.) VXFS is an extra, and rather pricey, option. -n ------------------------------------------------------------ "What a depressing, predictable arc. YAY LOOK AT US FLYING UP INTO THE SKY!!! HONK!!! THE TOILET. HELP!!!! HURKGLGHLGPTHGLHGLBHLGPTH **FLUSH** NEXT." (--www.leisuretown.com) http://blank.org/memory/>---------------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Jun 13 08:39:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DFd5X11464 for linux-xfs-outgoing; Wed, 13 Jun 2001 08:39:05 -0700 Received: from washington.intcafe.net (eu1.st74-net74.ip.superonlinecorporate.com [213.74.74.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DFclP11425 for ; Wed, 13 Jun 2001 08:39:03 -0700 Received: from [172.16.0.4] by washington.solmaz.com.tr (NTMail 3.03.0018/42.aaaj) with ESMTP id ta968103 for ; Wed, 13 Jun 2001 18:36:33 +0100 Message-ID: <005a01c0f41e$a2cc7b40$040010ac@tarkane> From: "Tarkan Erimer" To: Subject: ACL Support Date: Wed, 13 Jun 2001 18:36:38 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have a question about ACL support. Only installing XFS into the Linux kernel enough to get support ACLs? Or Is there any need to install ACL kernel patches found at http://acl.bestbits.at/ ? Thanks for your very help.. Best Regards From owner-linux-xfs@oss.sgi.com Wed Jun 13 08:44:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DFiAS12257 for linux-xfs-outgoing; Wed, 13 Jun 2001 08:44:10 -0700 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DFi9P12251 for ; Wed, 13 Jun 2001 08:44:09 -0700 Received: (from hch@localhost) by ns.caldera.de (8.11.1/8.11.1) id f5DFhv724223; Wed, 13 Jun 2001 17:43:57 +0200 Date: Wed, 13 Jun 2001 17:43:57 +0200 From: Christoph Hellwig To: "Nathan J. Mehl" Cc: "Jeffrey B. Layton" , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp Message-ID: <20010613174357.A24061@caldera.de> References: <3B24E5A1.7404BFBA@thebarn.com> <3B24E732.D3A3C8A6@sgi.com> <3B24EE05.F7E46B6C@thebarn.com> <20010613024149.Z8330@blank.org> <3B272FE8.97A8F575@lmco.com> <20010613113111.B8330@blank.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010613113111.B8330@blank.org>; from memory@blank.org on Wed, Jun 13, 2001 at 11:31:11AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Jun 13, 2001 at 11:31:11AM -0400, Nathan J. Mehl wrote: > In the immortal words of Jeffrey B. Layton (jeffrey.b.layton@lmco.com): > > > > Correct me if I'm wrong, but doesn't Solaris use a Veritas > > filesystem as the default filesystem (I know HP does). > > If that is the case, then getting rid of royalities to Veritas > > but still charging the same per license would increase > > their profits. Sure sounds like motivation to me :) > > Nope. By default, Sun uses plain-ol-UFS. (As of 2.8, they added > metadata logging.) Metadate-logging exists in SDS for about 5 years... Christoph -- Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Wed Jun 13 08:54:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DFsCr13789 for linux-xfs-outgoing; Wed, 13 Jun 2001 08:54:12 -0700 Received: from due.stud.ntnu.no (due.stud.ntnu.no [129.241.56.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DFsBP13785 for ; Wed, 13 Jun 2001 08:54:11 -0700 Received: from localhost (localhost [127.0.0.1]) by due.stud.ntnu.no (Postfix) with ESMTP id 5D19817B09; Wed, 13 Jun 2001 17:54:09 +0200 (CEST) Received: from jeeves.stud.ntnu.no (jeeves [129.241.56.14]) by due.stud.ntnu.no (Postfix) with ESMTP id 8292D17B54; Wed, 13 Jun 2001 17:54:08 +0200 (CEST) Received: from localhost (sebastid@localhost) by jeeves.stud.ntnu.no (8.10.0.Beta12/8.10.0.Beta12) with ESMTP id f5DFs8u14931; Wed, 13 Jun 2001 17:54:08 +0200 (MET DST) X-Authentication-Warning: jeeves.stud.ntnu.no: sebastid owned process doing -bs Date: Wed, 13 Jun 2001 17:54:08 +0200 (MET DST) From: Sebastian Dransfeld To: Tarkan Erimer Cc: Subject: Re: ACL Support In-Reply-To: <005a01c0f41e$a2cc7b40$040010ac@tarkane> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-10 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001, Tarkan Erimer wrote: > Hi, > > I have a question about ACL support. Only installing XFS into the Linux > kernel enough to get support ACLs? Or Is there any > need to install ACL kernel patches found at http://acl.bestbits.at/ ? > Thanks for your very help.. No need, ACL is in the XFS kernel. seb From owner-linux-xfs@oss.sgi.com Wed Jun 13 09:19:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DGJ0F14751 for linux-xfs-outgoing; Wed, 13 Jun 2001 09:19:00 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DGIxP14748 for ; Wed, 13 Jun 2001 09:18:59 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id SAA08068; Wed, 13 Jun 2001 18:18:57 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id SAA07960; Wed, 13 Jun 2001 18:18:57 +0200 (CEST) Date: Wed, 13 Jun 2001 18:18:57 +0200 (CEST) From: Seth Mos To: "Nathan J. Mehl" cc: "Jeffrey B. Layton" , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp In-Reply-To: <20010613113111.B8330@blank.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001, Nathan J. Mehl wrote: > In the immortal words of Jeffrey B. Layton (jeffrey.b.layton@lmco.com): > > > > Correct me if I'm wrong, but doesn't Solaris use a Veritas > > filesystem as the default filesystem (I know HP does). > > If that is the case, then getting rid of royalities to Veritas > > but still charging the same per license would increase > > their profits. Sure sounds like motivation to me :) > > Nope. By default, Sun uses plain-ol-UFS. (As of 2.8, they added > metadata logging.) VXFS is an extra, and rather pricey, option. Solaris 8 comes with UFS. But I still don't feel comfortable wandering and configurating the system. Seth From owner-linux-xfs@oss.sgi.com Wed Jun 13 09:26:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DGQ4e15041 for linux-xfs-outgoing; Wed, 13 Jun 2001 09:26:04 -0700 Received: from ocs4.ocs-net (firewall.ocs.com.au [203.34.97.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DGQ2P15038 for ; Wed, 13 Jun 2001 09:26:02 -0700 Received: from ocs4.ocs-net (kaos@localhost) by ocs4.ocs-net (8.11.2/8.11.2) with ESMTP id f5DGPkl14494; Thu, 14 Jun 2001 02:25:49 +1000 X-Authentication-Warning: ocs4.ocs-net: kaos owned process doing -bs X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Tarkan Erimer" cc: linux-xfs@oss.sgi.com Subject: Re: ACL Support In-reply-to: Your message of "Wed, 13 Jun 2001 18:36:38 +0300." <005a01c0f41e$a2cc7b40$040010ac@tarkane> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Thu, 14 Jun 2001 02:25:45 +1000 Message-ID: <14493.992449545@ocs4.ocs-net> X-MIME-Autoconverted: from 8bit to quoted-printable by ocs4.ocs-net id f5DGPkl14494 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5DGQ3P15039 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001 18:36:38 +0300, "Tarkan Erimer" wrote: >I have a question about ACL support. Only installing XFS into the Linux >kernel enough to get support ACLs? Or Is there any >need to install ACL kernel patches found at http://acl.bestbits.at/ ? There are at least two groups working on ACLs for Linux and they disagree about how they should be implemented. SGI has one implementation of ACL, included in the XFS patch. Andreas Grünbacher's ACLs are different and will not work with XFS. From owner-linux-xfs@oss.sgi.com Wed Jun 13 09:42:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DGgkO15562 for linux-xfs-outgoing; Wed, 13 Jun 2001 09:42:46 -0700 Received: from blipvert.blank.org (blipvert.blank.org [216.112.239.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DGgjP15559 for ; Wed, 13 Jun 2001 09:42:46 -0700 Received: (qmail 11495 invoked by uid 500); 13 Jun 2001 16:42:45 -0000 Date: Wed, 13 Jun 2001 12:42:44 -0400 From: "Nathan J. Mehl" To: Christoph Hellwig Cc: "Jeffrey B. Layton" , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp Message-ID: <20010613124244.F8330@blank.org> References: <3B24E5A1.7404BFBA@thebarn.com> <3B24E732.D3A3C8A6@sgi.com> <3B24EE05.F7E46B6C@thebarn.com> <20010613024149.Z8330@blank.org> <3B272FE8.97A8F575@lmco.com> <20010613113111.B8330@blank.org> <20010613174357.A24061@caldera.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010613174357.A24061@caldera.de>; from hch@ns.caldera.de on Wed, Jun 13, 2001 at 05:43:57PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In the immortal words of Christoph Hellwig (hch@ns.caldera.de): > On Wed, Jun 13, 2001 at 11:31:11AM -0400, Nathan J. Mehl wrote: > > Nope. By default, Sun uses plain-ol-UFS. (As of 2.8, they added > > metadata logging.) > > Metadate-logging exists in SDS for about 5 years... Correct: see my initial post's mention of SDS. :) (Indeed, one thing I've always wondered is if Sol 8's "logging" fstab option is just the "metatrans" code diked out of SDS and dropped into the core OS, or if it's something completely different, and what would happen if you gave a logging UFS partition a trans log...) -n ------------------------------------------------------ "`You understand the concepts of breaking down a human psyche.' Well sure, I work for Warner Bros." (--JMS) ---------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Jun 13 09:44:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DGigW15680 for linux-xfs-outgoing; Wed, 13 Jun 2001 09:44:42 -0700 Received: from chimta02 (chimta02.algx.net [216.99.233.77]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DGiaP15675 for ; Wed, 13 Jun 2001 09:44:36 -0700 Received: from jtsdell (66-2-81-26.customer.algx.net [66.2.81.26]) by chimmx02.algx.net (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id <0GEV00KMENA9KH@chimmx02.algx.net> for linux-xfs@oss.sgi.com; Wed, 13 Jun 2001 11:32:34 -0500 (CDT) Date: Wed, 13 Jun 2001 12:32:19 -0400 (EDT) From: jtrostel@connex.com Subject: Re: ACL Support In-reply-to: To: Sebastian Dransfeld Cc: linux-xfs@oss.sgi.com, Tarkan Erimer Reply-to: jtrostel@connex.com Message-id: Organization: Connex MIME-version: 1.0 X-Mailer: XFMail 1.5.0 on Linux Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You need to install the components in the ../cmd/acl directory also for acl support. This will create the libacl.a library and the userspace tools needed to control and view the ACLs On 13-Jun-2001 Sebastian Dransfeld wrote: > On Wed, 13 Jun 2001, Tarkan Erimer wrote: > >> Hi, >> >> I have a question about ACL support. Only installing XFS into the Linux >> kernel enough to get support ACLs? Or Is there any >> need to install ACL kernel patches found at http://acl.bestbits.at/ ? >> Thanks for your very help.. > > No need, ACL is in the XFS kernel. > > seb -- John M. Trostel Linux OS Engineer Connex jtrostel@connex.com From owner-linux-xfs@oss.sgi.com Wed Jun 13 10:20:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DHKwS16486 for linux-xfs-outgoing; Wed, 13 Jun 2001 10:20:58 -0700 Received: from pipt.oz.cc.utah.edu (jdr1529@pipt.oz.cc.utah.edu [155.99.2.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DHKwP16483 for ; Wed, 13 Jun 2001 10:20:58 -0700 Received: from localhost (jdr1529@localhost) by pipt.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id LAA26677; Wed, 13 Jun 2001 11:19:53 -0600 (MDT) Date: Wed, 13 Jun 2001 11:19:53 -0600 (MDT) From: james rich To: "Nathan J. Mehl" cc: Russell Cattelan , Eric Sandeen , Juha Saarinen , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp In-Reply-To: <20010613024149.Z8330@blank.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001, Nathan J. Mehl wrote: > expect that if Sun thought they could gain some sort of competetive > advantage from shipping Solaris 9 with XFS, they'd simply go ahead and > do so with the existing GPL code. Since XFS integrates with the OS they would have to GPL Solaris (I think) - not likely. With a BSD compatible license (such as would be required to make it into the *BSDs) Sun (or anyone else) could take the XFS code, modify it to work for them (and potentially not work for you - see MicroSoft and kerberos) and then sell the result *without helping SGI in any way*. So SGI loses contributors to it's code and gains a competitor using its own filesystem! James Rich james.rich@m.cc.utah.edu From owner-linux-xfs@oss.sgi.com Wed Jun 13 10:37:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DHbs617755 for linux-xfs-outgoing; Wed, 13 Jun 2001 10:37:54 -0700 Received: from amoa.org (amoa.org [207.207.51.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DHbrP17752 for ; Wed, 13 Jun 2001 10:37:53 -0700 Received: by amoa.org(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256A6A.0060E163 ; Wed, 13 Jun 2001 12:38:11 -0500 X-Lotus-FromDomain: AMOA From: ctooley@amoa.org To: james rich cc: linux-xfs@oss.sgi.com Message-ID: <86256A6A.0060E10C.00@amoa.org> Date: Wed, 13 Jun 2001 12:38:09 -0500 Subject: Re: Interest from the FreeBSD camp Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Loadable modules (as in the case of a filesystem) are not "part" of the kernel directly. Therefore Solaris wouldn't have to be GPL'd. At least that's my understanding ot it. Chris Tooley james rich on 06/13/2001 12:19:53 PM To: "Nathan J. Mehl" cc: Russell Cattelan , Eric Sandeen , Juha Saarinen , linux-xfs@oss.sgi.com(bcc: Chris Tooley/AMOA) Subject Re: Interest from the FreeBSD camp : On Wed, 13 Jun 2001, Nathan J. Mehl wrote: > expect that if Sun thought they could gain some sort of competetive > advantage from shipping Solaris 9 with XFS, they'd simply go ahead and > do so with the existing GPL code. Since XFS integrates with the OS they would have to GPL Solaris (I think) - not likely. With a BSD compatible license (such as would be required to make it into the *BSDs) Sun (or anyone else) could take the XFS code, modify it to work for them (and potentially not work for you - see MicroSoft and kerberos) and then sell the result *without helping SGI in any way*. So SGI loses contributors to it's code and gains a competitor using its own filesystem! James Rich james.rich@m.cc.utah.edu From owner-linux-xfs@oss.sgi.com Wed Jun 13 10:50:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DHoFM18043 for linux-xfs-outgoing; Wed, 13 Jun 2001 10:50:15 -0700 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DHoDP18039 for ; Wed, 13 Jun 2001 10:50:14 -0700 Received: (from hch@localhost) by ns.caldera.de (8.11.1/8.11.1) id f5DHmMm05666; Wed, 13 Jun 2001 19:48:22 +0200 Date: Wed, 13 Jun 2001 19:48:22 +0200 From: Christoph Hellwig To: james rich Cc: "Nathan J. Mehl" , Russell Cattelan , Eric Sandeen , Juha Saarinen , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp Message-ID: <20010613194822.A5469@caldera.de> References: <20010613024149.Z8330@blank.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from james.rich@m.cc.utah.edu on Wed, Jun 13, 2001 at 11:19:53AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Jun 13, 2001 at 11:19:53AM -0600, james rich wrote: > On Wed, 13 Jun 2001, Nathan J. Mehl wrote: > > > expect that if Sun thought they could gain some sort of competetive > > advantage from shipping Solaris 9 with XFS, they'd simply go ahead and > > do so with the existing GPL code. > > Since XFS integrates with the OS they would have to GPL Solaris (I think) > - not likely. They already have a GPLed ext2fs-implementation, if you want to sue them do it now. Christoph -- Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Wed Jun 13 11:15:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DIFvp18564 for linux-xfs-outgoing; Wed, 13 Jun 2001 11:15:57 -0700 Received: from server1.metrolink.com (server1.metrolink.com [216.242.72.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DIFtP18560 for ; Wed, 13 Jun 2001 11:15:56 -0700 Message-ID: <3B27ADD1.5D1EF959@metrolink.com> Date: Wed, 13 Jun 2001 14:15:45 -0400 From: Rob Lembree Organization: Metro Link, Inc. MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs and lilo on a second disk Content-Type: multipart/mixed; boundary="------------1AD242B5975C5652CDBECA3D" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------1AD242B5975C5652CDBECA3D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi there, I put xfs onto my RH7.1 system by first upgrading the RPMs, adding a disk, making xfs partitions, and the cp -a each of the partitions to the new xfs partitions. I modified lilo.conf to do the right thing, and ran lilo chrooted and pointing to the right disk, then ran lilo. I swapped drives (pri and sec), and get "LI" instead of LILO. I then switched pir and sec drives so that the original pri is pri again, and added an 'xfs' stanza to the lilo.conf. This boots the sec drive nicely. I tried to run LILO from this again, but with the same LI result. So how should I get LILO booting off this new drive so that I can put the old drive to use someplace else? I've been using Linux since '92, so I've tried all the obvious stuff. Below is my lilo.conf. Note that right now, /dev/hdb is the xfs disk that I want to make /dev/hda, hence the /dev/hda and /dev/hdb inconsistency. WHen I run lilo, it should (and does) modify /dev/hdb, when I boot, it is configed as /dev/hda. thanks, rob boot=/dev/hdb map=/boot/map install=/boot/boot.b prompt timeout=50 message=/boot/message linear default=linux image=/boot/vmlinuz-2.4.2-SGI_XFS_1.0 label=linux read-only append="root=/dev/hda6" # root=/dev/hda6 -- Rob Lembree Metro Link Incorporated 29 Milk St. lembree@metrolink.com Nashua, NH 03064-1651 http://www.metrolink.com Phone: 954.660.2460 Alternate: 603.577.9714 PGP: 1F EE F8 58 30 F1 B1 20 C5 4F 12 21 AD 0D 6B 29 --------------1AD242B5975C5652CDBECA3D Content-Type: text/x-vcard; charset=us-ascii; name="lembree.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Rob Lembree Content-Disposition: attachment; filename="lembree.vcf" begin:vcard n:Lembree;Robert tel;cell:603-494-0559 tel;fax:603-577-9714 tel;home:603-880-6768 tel;work:954-660-2460 x-mozilla-html:TRUE url:http://www.lembree.com/rob/ org:Metro Link, Inc.;Automation Technology Division adr:;;29 Milk St.;Nashua;NH;03064-1651;US version:2.1 email;internet:lembree@metrolink.com title:Technical Director note:PGP: 1F EE F8 58 30 F1 B1 20 C5 4F 12 21 AD 0D 6B 29 x-mozilla-cpt:;-31136 fn:Robert Lembree end:vcard --------------1AD242B5975C5652CDBECA3D-- From owner-linux-xfs@oss.sgi.com Wed Jun 13 11:39:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DIdO419130 for linux-xfs-outgoing; Wed, 13 Jun 2001 11:39:24 -0700 Received: from msg.ecetra.com (dollar.ecetra.com [193.164.224.209]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DIdMP19127 for ; Wed, 13 Jun 2001 11:39:22 -0700 Received: from vie-ac.office.ecetra.com (vie-ac.office.ecetra.com [10.251.148.147] (may be forged)) by msg.ecetra.com (8.9.3/8.9.3) with ESMTP id UAA05960; Wed, 13 Jun 2001 20:39:15 +0200 Received: from localhost (localhost [127.0.0.1]) by vie-ac.office.ecetra.com (8.11.4/8.11.3) with ESMTP id f5DIdFN12210; Wed, 13 Jun 2001 20:39:15 +0200 Date: Wed, 13 Jun 2001 20:39:15 +0200 (CEST) From: Adam Cioccarelli To: Rob Lembree cc: Subject: Re: xfs and lilo on a second disk In-Reply-To: <3B27ADD1.5D1EF959@metrolink.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk try adding disk=/dev/hdb bios=0x80 as the first line and using root=/dev/hdb? whatever the partition is that you have as the new root partition.. ------------------------------------------------------------------------------- Adam Cioccarelli (B.E Mechanical) Adam.Cioccarelli@ecetra.com Database Administrator Phone: +43 1 536 89 7725 Fax: +43 1 536 89 7719 ecetra Central European e-Finance AG Mobile:+43 664 181 4195 ------------------------------------------------------------------------------- On Wed, 13 Jun 2001, Rob Lembree wrote: > Hi there, > > I put xfs onto my RH7.1 system by first upgrading the > RPMs, adding a disk, making xfs partitions, and the cp -a > each of the partitions to the new xfs partitions. > > I modified lilo.conf to do the right thing, and ran > lilo chrooted and pointing to the right disk, then ran lilo. > I swapped drives (pri and sec), and get "LI" instead of > LILO. > > I then switched pir and sec drives so that the original > pri is pri again, and added an 'xfs' stanza to the lilo.conf. > This boots the sec drive nicely. > > I tried to run LILO from this again, but with the same LI > result. > > So how should I get LILO booting off this new drive so > that I can put the old drive to use someplace else? > > I've been using Linux since '92, so I've tried all the > obvious stuff. > > Below is my lilo.conf. Note that right now, /dev/hdb is > the xfs disk that I want to make /dev/hda, hence the /dev/hda and > /dev/hdb inconsistency. WHen I run lilo, it should (and does) > modify /dev/hdb, when I boot, it is configed as /dev/hda. > > thanks, > rob > > > > boot=/dev/hdb > map=/boot/map > install=/boot/boot.b > prompt > timeout=50 > message=/boot/message > linear > default=linux > > image=/boot/vmlinuz-2.4.2-SGI_XFS_1.0 > label=linux > read-only > append="root=/dev/hda6" > # root=/dev/hda6 > > > > -- > > Rob Lembree Metro Link Incorporated > 29 Milk St. lembree@metrolink.com > Nashua, NH 03064-1651 http://www.metrolink.com > Phone: 954.660.2460 Alternate: 603.577.9714 > PGP: 1F EE F8 58 30 F1 B1 20 C5 4F 12 21 AD 0D 6B 29 > > From owner-linux-xfs@oss.sgi.com Wed Jun 13 11:39:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DIdnS19157 for linux-xfs-outgoing; Wed, 13 Jun 2001 11:39:49 -0700 Received: from hotmail.com (f71.law4.hotmail.com [216.33.149.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DIdmP19154 for ; Wed, 13 Jun 2001 11:39:48 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Jun 2001 11:39:43 -0700 Received: from 204.94.209.1 by lw4fd.law4.hotmail.msn.com with HTTP; Wed, 13 Jun 2001 18:39:43 GMT X-Originating-IP: [204.94.209.1] From: "Thomas Duffy" To: lembree@metrolink.com, linux-xfs@oss.sgi.com Subject: Re: xfs and lilo on a second disk Date: Wed, 13 Jun 2001 11:39:43 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jun 2001 18:39:43.0863 (UTC) FILETIME=[36A6F070:01C0F438] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hey Rob! long time no hear! the problem is most likely a result of a mismatch between what linux thinks is int 80 and what the bios thinks is int 80. I would suggest that you but hdb into the hda slot, then boot off of a recovery CD and mount the drive. change the lilo.conf to point to hda and rerun lilo. the other option, if you do not like the idea of using a recovery CD is to specifically tell lilo that hdb is int 80 by doing something like this... disk=/dev/hda bios=0x80 -tduffy >Hi there, > > I put xfs onto my RH7.1 system by first upgrading the >RPMs, adding a disk, making xfs partitions, and the cp -a >each of the partitions to the new xfs partitions. > > I modified lilo.conf to do the right thing, and ran >lilo chrooted and pointing to the right disk, then ran lilo. >I swapped drives (pri and sec), and get "LI" instead of >LILO. > > I then switched pir and sec drives so that the original >pri is pri again, and added an 'xfs' stanza to the lilo.conf. >This boots the sec drive nicely. > > I tried to run LILO from this again, but with the same LI >result. > > So how should I get LILO booting off this new drive so >that I can put the old drive to use someplace else? > > I've been using Linux since '92, so I've tried all the >obvious stuff. > > Below is my lilo.conf. Note that right now, /dev/hdb is >the xfs disk that I want to make /dev/hda, hence the /dev/hda and >/dev/hdb inconsistency. WHen I run lilo, it should (and does) >modify /dev/hdb, when I boot, it is configed as /dev/hda. > >thanks, >rob > > > >boot=/dev/hdb >map=/boot/map >install=/boot/boot.b >prompt >timeout=50 >message=/boot/message >linear >default=linux > >image=/boot/vmlinuz-2.4.2-SGI_XFS_1.0 > label=linux > read-only > append="root=/dev/hda6" ># root=/dev/hda6 _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-linux-xfs@oss.sgi.com Wed Jun 13 11:49:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DInoO19379 for linux-xfs-outgoing; Wed, 13 Jun 2001 11:49:50 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DInoP19376 for ; Wed, 13 Jun 2001 11:49:50 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA07441 for ; Wed, 13 Jun 2001 11:50:11 -0700 (PDT) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2151854 for ; Wed, 13 Jun 2001 13:48:33 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.184.30]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA45115 for ; Wed, 13 Jun 2001 13:48:33 -0500 (CDT) From: Dean Roehrich Received: by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id NAA69426; Wed, 13 Jun 2001 13:48:33 -0500 (CDT) Message-Id: <200106131848.NAA69426@slobber.americas.sgi.com> Date: Wed, 13 Jun 2001 13:48:33 -0500 (CDT) To: linux-xfs@oss.sgi.com Subject: libtool, for dmapi user lib, and xfsprogs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I just checked in a mod to libtoolize the dmapi user library. When this makes its way to the outside tree I'd appreciate feedback on my changes. Anyone who is building the library will notice libtool in the mix, and people who build rpm and dpkg packages will notice it. We needed to libtoolize this so we can reliably get shared libs for use by HSMs. Given that libdm relies on some functionality provided by libhandle, I also intend to libtoolize some or all of the xfsprogs directory (where libhandle lives). So while you could care less about the dmapi library, I'd appreciate it if you looked at it before I screw up the xfsprogs package :) It seems that I cannot tell libtool about the difference between an install goal and an install-dev goal. The common way to build packages, say rpm (in the cases I was studying), is to have a static list of files in the rpm spec file. We don't use static file lists in the XFS user libraries and tools--instead, our install-sh builds a manifest for us and we suck that into our spec file. Ideally we'd like the dmapi-devel- package to contain the following from libtool: libdm.a libdm.so libdm.la And we'd like the dmapi- package to contain the following from libtool: libdm.so.0.0.0 libdm.so.0 We'd really like to not have a static file list in the rpm spec file--getting the file list from the install manifest is really nice. So I've added a filter as part of the install and install-dev make goals to trim the manifest depending on which type of goal we're running. The RPM dmapi and dmapi-devel packages now build and install to my satisfaction. I have not updated the debian packaging. For dpkg we do not use the installation manifest--instead, it slurps up the contents of the installation directory. Maybe the LT_INSTALL_FILTER and LT_DEV_INSTALL_FILTER that I've added to include/builddefs.in should unlink the files they are removing from the manifest. Is there anyone out there who can try this out? Dean From owner-linux-xfs@oss.sgi.com Wed Jun 13 13:59:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DKx7K01430 for linux-xfs-outgoing; Wed, 13 Jun 2001 13:59:07 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DKx5P01427 for ; Wed, 13 Jun 2001 13:59:05 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15AHit-0007s7-00; Thu, 14 Jun 2001 08:58:43 +1200 Date: Thu, 14 Jun 2001 08:58:42 +1200 (NZST) From: Juha Saarinen To: Chmouel Boudjnah cc: Russell Cattelan , Seth Mos , Steve Lord , "linux-xfs@oss.sgi.com" Subject: Re: Today's CVS doesn't compile In-Reply-To: Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 13 Jun 2001, Chmouel Boudjnah wrote: > no, it is the gcc driver interface who was broken. i believe that has > been fixed in our latest gcc for us.. Hi Chmouel, Do you know if RH's sorted it out in gcc 2.96-85? -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Wed Jun 13 14:12:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DLCHZ02768 for linux-xfs-outgoing; Wed, 13 Jun 2001 14:12:17 -0700 Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DLCGP02765 for ; Wed, 13 Jun 2001 14:12:16 -0700 Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA18492 for ; Wed, 13 Jun 2001 14:11:45 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id OAA13012 for ; Wed, 13 Jun 2001 14:12:10 -0700 (PDT) Received: from pipcws.ca.boeing.com by blv-hub-01.boeing.com with ESMTP; Wed, 13 Jun 2001 14:12:05 -0700 Received: from pipcws.ca.boeing.com (e218766.evt.boeing.com [136.203.14.68]) by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id OAA54442; Wed, 13 Jun 2001 14:12:05 -0700 Message-Id: <3B27D722.30006@pipcws.ca.boeing.com> Date: Wed, 13 Jun 2001 14:12:02 -0700 From: Ric Tibbetts User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9) Gecko/20010505 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Steven Lembark CC: Florin Andrei , Dan Swartzendruber , linux-xfs@oss.sgi.com Subject: Re: XFS/Linux 1.1?? References: <36940000.992370008@duke.wrkhors.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steven Lembark wrote: > >>> if i can get a nice threaded mail client with IMAP support, >>> i'd move my mail from win98 to KDE in a flash. >> >> >> Evolution? > > > Mulberry (see www.cyrusoft.com). Mulberry = $.$$ :( From owner-linux-xfs@oss.sgi.com Wed Jun 13 14:24:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DLOcq04100 for linux-xfs-outgoing; Wed, 13 Jun 2001 14:24:38 -0700 Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DLObP04096 for ; Wed, 13 Jun 2001 14:24:37 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id 04E811399F; Wed, 13 Jun 2001 17:24:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id 01FC11399B for ; Wed, 13 Jun 2001 17:24:43 -0400 (EDT) Date: Wed, 13 Jun 2001 17:24:42 -0400 (EDT) From: Mike Burger To: Subject: Re: XFS/Linux 1.1?? In-Reply-To: <3B27D722.30006@pipcws.ca.boeing.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well, you didn't say it had to be free. On Wed, 13 Jun 2001, Ric Tibbetts wrote: > Steven Lembark wrote: > > > > >>> if i can get a nice threaded mail client with IMAP support, > >>> i'd move my mail from win98 to KDE in a flash. > >> > >> > >> Evolution? > > > > > > Mulberry (see www.cyrusoft.com). > > > Mulberry = $.$$ :( > > From owner-linux-xfs@oss.sgi.com Wed Jun 13 14:32:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DLWP504902 for linux-xfs-outgoing; Wed, 13 Jun 2001 14:32:25 -0700 Received: from yowie.cc.uq.edu.au (root@yowie.cc.uq.edu.au [130.102.2.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DLWNP04898 for ; Wed, 13 Jun 2001 14:32:24 -0700 Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1]) by yowie.cc.uq.edu.au (8.9.3/8.9.3) with ESMTP id HAA02397; Thu, 14 Jun 2001 07:32:10 +1000 (GMT+1000) Received: from nut.csee.uq.edu.au (nut.csee.uq.edu.au [130.102.66.13]) by gum.csee.uq.edu.au (8.11.3/8.11.3) with ESMTP id f5DLW8519531; Thu, 14 Jun 2001 07:32:08 +1000 (EST) Received: from mango.csee.uq.edu.au (mango.csee.uq.edu.au [130.102.66.4]) by nut.csee.uq.edu.au (8.11.3/8.11.3) with ESMTP id f5DLW8m17924; Thu, 14 Jun 2001 07:32:08 +1000 (EST) Date: Thu, 14 Jun 2001 07:32:08 +1000 (EST) From: Chris Pascoe To: Steve Lord cc: Subject: Re: TAKE - fix highmem problem where ext2 oopses (yay!) In-Reply-To: <200106121843.f5CIhgL23312@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 1.1 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 12 Jun 2001, Steve Lord wrote: > Finally fixed, this was a core Linux bug. Chris this should make your > box happy I think. Yes! Yay! (How does one express great excitement in email?) I accidentally left the tests running in a loop since the buffer.c patch came through (so at least 16 hours now) and the machine hasn't crashed! Compiled with egcs-2.91.66 too, so the previous reordering you made was a success here too. Thanks for your persistence on this one, Steve! Now I can move onto my NFS and tape tests, and see if I can find any more bugs lurking away there :). Chris P.S. Yay! Did I already say that? From owner-linux-xfs@oss.sgi.com Wed Jun 13 14:37:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DLbIk05470 for linux-xfs-outgoing; Wed, 13 Jun 2001 14:37:18 -0700 Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DLbHP05467 for ; Wed, 13 Jun 2001 14:37:17 -0700 Received: (from isani@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id LAA14254; Wed, 13 Jun 2001 11:37:09 -1000 From: Sidik Isani Message-Id: <200106132137.LAA14254@otto.cfht.hawaii.edu> Subject: Re: mkinitrd, ramdisk failure? To: stimits@idcomm.com Date: Wed, 13 Jun 2001 11:37:09 -1000 (HST) Cc: linux-xfs@oss.sgi.com (XFS: linux-xfs@oss.sgi.com) In-Reply-To: <3B26E3DF.1B22B76A@idcomm.com> from "D. Stimits" at Jun 12, 2001 09:54:07 PM X-Mailer: ELM [version 2.5 PL0] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk D. Stimits typed: |[...] |So can *anyone* verify that it really is possible to run XFS as modules? |If so, can I get a list of modules you have under lsmod? Or if you |remember, a sample of the mkinitrd.xfs line used? I've never looked at mkinitrd, but XFS as modules is working for me. I generated the initrd manually, but there's nothing fancy in it. As someone else just posted, the modules must be loaded in this order: pagebuf.o xfs_support.o xfs.o (And, obviously the filesystem on the initrd _itself_ must be something compiled into the kernel. Can't be XFS if it's modular.) - Sidik P.S.: I'm running 2.4.6-pre2-xfs CVS from two or three days ago. From owner-linux-xfs@oss.sgi.com Wed Jun 13 14:56:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DLuBj07564 for linux-xfs-outgoing; Wed, 13 Jun 2001 14:56:11 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DLuAP07561 for ; Wed, 13 Jun 2001 14:56:10 -0700 Received: from idcomm.com (IDENT:stimits@x2-pip56.idcomm.com [209.60.72.67]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5DLthl09298 for ; Wed, 13 Jun 2001 15:55:43 -0600 Message-ID: <3B27E1B7.FF8018E9@idcomm.com> Date: Wed, 13 Jun 2001 15:57:11 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <200106132137.LAA14254@otto.cfht.hawaii.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sidik Isani wrote: > > D. Stimits typed: > |[...] > |So can *anyone* verify that it really is possible to run XFS as modules? > |If so, can I get a list of modules you have under lsmod? Or if you > |remember, a sample of the mkinitrd.xfs line used? > > I've never looked at mkinitrd, but XFS as modules is working for me. > I generated the initrd manually, but there's nothing fancy in it. As > someone else just posted, the modules must be loaded in this order: > pagebuf.o xfs_support.o xfs.o > > (And, obviously the filesystem on the initrd _itself_ must be > something compiled into the kernel. Can't be XFS if it's modular.) > > - Sidik > > P.S.: I'm running 2.4.6-pre2-xfs CVS from two or three days ago. I just tested a very carefully made initial ramdisk, and it fails: mkinitrd.xfs \ --with=pagebuf \ --with=xfs_support \ --with=xfs \ /boot/initrd-2.4.6-pre1-xfs-3.img \ 2.4.6-pre1-xfs-3 My lilo.conf has for this image: append="ramdisk_size=25000 noapic" This fails, though it succeeds all the way up until root filesystem mount is attempted. I'm a bit frustrated by the lack of good debug information when a root filesystem mount fails :( For example, I wish it would say which modules were loaded at the time of failure. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Wed Jun 13 15:00:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DM0P608029 for linux-xfs-outgoing; Wed, 13 Jun 2001 15:00:25 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DM0OP08022 for ; Wed, 13 Jun 2001 15:00:24 -0700 Received: from idcomm.com (IDENT:stimits@x2-pip56.idcomm.com [209.60.72.67]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5DLxul10230 for ; Wed, 13 Jun 2001 15:59:57 -0600 Message-ID: <3B27E2B5.CB5E4CF6@idcomm.com> Date: Wed, 13 Jun 2001 16:01:25 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <3B26C626.24EC0F20@idcomm.com> <3B26CC5E.6050804@uswest.net> <3B26D839.E6C58E3E@idcomm.com> <3B26DCBB.2289C8FC@sigmastorage.com> <3B26E3DF.1B22B76A@idcomm.com> <3B26EFD1.723327FA@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Russell Cattelan wrote: > > "D. Stimits" wrote: > > > Matt Ryan wrote: > > > > > > sorry, I meant to write that to the list as well. I just wrote: > > > > > > gzip -dc your.img > somefile > > > mount -o loop somefile somedir > > > > > > also, just running mkinitrd with the verbose (-v) option is pretty > > > helpful too > > > (not sure if you were doing that already). > > > > I've done -v, and also mounted each of the initrd images since then. I > > definitely have the three modules I know of which are required: > > pagebuf.o > > xfs.o > > xfs_support.o > > note the modules must load in this order > pagebuf > xfs_support > xfs I carefully made certain this was the order in the mkinitrd.xfs. It still fails at the point of mounting root partition (note: this is a hard drive, not floppy). There must be something else? My command line for mkinitrd.xfs: mkinitrd.xfs \ --with=pagebuf \ --with=xfs_support \ --with=xfs =\ /boot/initrd-2.4.6-pre1-xfs-3.img \ 2.4.6-pre1-xfs-3 NOTE: The /boot partition seems to be read fine, and the scsi controller is detected and works fine, including apparently the read of /boot. SCSI is directly compiled in. D. Stimits, stimits@idcomm.com > > When specifying them on the command the order they are > given is the order they are loaded. > > The mkinird.xfs in the source tree just added the modules to the > basicmodules list rather than having to list them by hand on the command > line. > > Note the 0.9 release of XFS installed xfs as modules using mkinitrd.xfs to > build > the initrd, the 0.10 and 1.0 release did not do this since boots seem to > take slightly > less time with xfs in the kernel. > > > > > > > Perhaps there is some kind of argument or order required that I don't > > have? Or, since I compiled the kernel on RH 7.1 and used kgcc, would > > there be some sort of change required to the compile of mkinitrd.xfs to > > make it use kgcc as well? I noticed this URL does not have mkinitrd.xfs > > man page: > > http://oss.sgi.com/projects/xfs/manpages.html > > > > ...and the cvs cmd/xfsmisc/ does not seem to produce one either. My > > assumption is that this and the original mkinitrd are identical > > (incidentally, I turned in a report to RH bugzilla that their man page > > does not match the command line option syntax of mkinitrd --help...the > > latter is accurate, the former not for --preload=). > > > > So can *anyone* verify that it really is possible to run XFS as modules? > > If so, can I get a list of modules you have under lsmod? Or if you > > remember, a sample of the mkinitrd.xfs line used? > > > > D. Stimits, stimits@idcomm.com > > > > > > > > Matt > > > > > > > > > > > While I'm convinced that this is the basic problem, I can't figure out > > > > what is missing. Matt Ryan gave me one very useful command to mount my > > > > initial ramdisk on loopback and see what it actually contains. I can > > -- > Russell Cattelan > cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Wed Jun 13 15:15:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DMFe109480 for linux-xfs-outgoing; Wed, 13 Jun 2001 15:15:40 -0700 Received: from blipvert.blank.org (blipvert.blank.org [216.112.239.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DMFbP09470 for ; Wed, 13 Jun 2001 15:15:37 -0700 Received: (qmail 14483 invoked by uid 500); 13 Jun 2001 22:15:36 -0000 Date: Wed, 13 Jun 2001 18:15:36 -0400 From: "Nathan J. Mehl" To: james rich Cc: Russell Cattelan , Eric Sandeen , Juha Saarinen , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp Message-ID: <20010613181536.G8330@blank.org> References: <20010613024149.Z8330@blank.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from james.rich@m.cc.utah.edu on Wed, Jun 13, 2001 at 11:19:53AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In the immortal words of james rich (james.rich@m.cc.utah.edu): > > > expect that if Sun thought they could gain some sort of competetive > > advantage from shipping Solaris 9 with XFS, they'd simply go ahead and > > do so with the existing GPL code. > > Since XFS integrates with the OS they would have to GPL Solaris (I think) > - not likely. Why on earth do you make this assertion? Solaris supports loadable independent kernel modules just as linux does -- implementing xfs on solaris in a way that didn't "contaminate" the kernel with the GPL would be a pretty straightforward exercise. (Well, at least, it would probably not add significantly to the effort involved in a Solaris port to begin with, which might be high.) > With a BSD compatible license (such as would be required to > make it into the *BSDs) Sun (or anyone else) could take the XFS code, > modify it to work for them (and potentially not work for you - see > MicroSoft and kerberos) and then sell the result *without helping SGI in > any way*. So SGI loses contributors to it's code and gains a competitor > using its own filesystem! I think we're all in agreement that a BSD-style license doesn't get SGI anything but goodwill from the xBSD camp. I just think the paranoia about Sun is probably unjustified: as I've pointed out elsewhere, they gain little and potentially lose a lot by adopting XFS into Solaris's base distribution. -n ------------------------------------------------------------ As someone who used to work for both the Soviet Union and an (unnamed here, but well-known otherwise) American phone company I can only confirm the rather conspicious similarity. (--Vadim Antonov) ---------------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Jun 13 15:37:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DMbpo10495 for linux-xfs-outgoing; Wed, 13 Jun 2001 15:37:51 -0700 Received: from yowie.cc.uq.edu.au (root@yowie.cc.uq.edu.au [130.102.2.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DMbmP10488 for ; Wed, 13 Jun 2001 15:37:49 -0700 Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1]) by yowie.cc.uq.edu.au (8.9.3/8.9.3) with ESMTP id IAA01996; Thu, 14 Jun 2001 08:37:40 +1000 (GMT+1000) Received: from nut.csee.uq.edu.au (nut.csee.uq.edu.au [130.102.66.13]) by gum.csee.uq.edu.au (8.11.3/8.11.3) with ESMTP id f5DMbb522884; Thu, 14 Jun 2001 08:37:37 +1000 (EST) Received: from mango.csee.uq.edu.au (mango.csee.uq.edu.au [130.102.66.4]) by nut.csee.uq.edu.au (8.11.3/8.11.3) with ESMTP id f5DMbam19190; Thu, 14 Jun 2001 08:37:36 +1000 (EST) Date: Thu, 14 Jun 2001 08:37:36 +1000 (EST) From: Chris Pascoe To: "D. Stimits" cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? In-Reply-To: <3B27E2B5.CB5E4CF6@idcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 1.1 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > NOTE: The /boot partition seems to be read fine, and the scsi controller > is detected and works fine, including apparently the read of /boot. SCSI > is directly compiled in. I don't believe the read of /boot isn't done using the system SCSI modules; it's done using BIOS calls. So that it loads the kernel and initrd is not an indication that the SCSI drivers, etc, actually loaded properly. Bear with me and check that you are seeing everything below: The point where the initrd is loaded starts with: RAMDISK: Compressed image found at block 0 Then it is followed by (as the root filesystem on the ramdisk is mounted): VFS: Mounted root (ext2 filesystem). [I assume if you're loading XFS as a module, the filesystem on the initrd is ext2, which is compiled into the booting kernel? Otherwise, you're never going to get anywhere, because it needs to mount/run the initrd to get xfs support, and it can't mount the initrd because it doesn't have the xfs modules loaded yet..] You should now see a few messages as the pagebuf/xfs_support/xfs modules load (I assume, never used them as modules): (NB This might come after the SCSI support has loaded): Loading pagebuf module Pagebuf cache Copyright (c) 2001 Silicon Graphics, Inc. Loading xfs_support module Loading xfs module XFS filesystem Copyright (c) 2001 Silicon Graphics, Inc. After this, you should see a few SCSI driver messages at this time, as the SCSI adaptor drivers load, then a bunch of lines like: (if you have scsi modules compiled in) Loading scsi_mod module Loading sd_mod module (always:) Loading aacraid module (my SCSI driver) Vendor: DELL Model: PERCRAID Mirror Rev: 0001 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi removable disk sda at scsi0, channel 0, id 0, lun 0 Vendor: DELL Model: PERCRAID RAID5 Rev: 0001 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi removable disk sdb at scsi0, channel 0, id 1, lun 0 Indicating that the disks were detected. After that, it enumerates the partitions on the disk: Partition check: sda: sda1 sda2 sda3 < sda5 sda6 sda7 > sdb: sdb1 sdb2 sdb3 And then it goes to mount the new root file system: VFS: Mounted root (xfs filesystem) readonly. If you're not seeing the "Detected scsi disk..." lines above, I'm guessing that you haven't got the scsi disk support compiled in, or the disks loaded. Can you check the compare the output you get of the boot process with what I've pasted above, and let us know the differences? Also, knowing the contents of the /linuxrc on the initrd would be handy. Chris From owner-linux-xfs@oss.sgi.com Wed Jun 13 15:39:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DMdB410654 for linux-xfs-outgoing; Wed, 13 Jun 2001 15:39:11 -0700 Received: from chimta01.algx.net (chimta01.algx.net [216.99.233.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DMdAP10647 for ; Wed, 13 Jun 2001 15:39:10 -0700 Received: from jtsdell (66-2-81-26.customer.algx.net [66.2.81.26]) by chimmx01.algx.net (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id <0GEW0071J4930L@chimmx01.algx.net> for linux-xfs@oss.sgi.com; Wed, 13 Jun 2001 17:39:04 -0500 (CDT) Date: Wed, 13 Jun 2001 18:38:50 -0400 (EDT) From: jtrostel@connex.com Subject: Re: XFS/Linux 1.1?? In-reply-to: To: Dan Swartzendruber Cc: linux-xfs@oss.sgi.com Reply-to: jtrostel@connex.com Message-id: Organization: Connex MIME-version: 1.0 X-Mailer: XFMail 1.5.0 on Linux Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk XFmail is threaded, does IMAP and is free! (and is what I use) On 10-Jun-2001 Dan Swartzendruber wrote: > seems. if i can get a nice threaded mail client with IMAP support, > i'd move my mail from win98 to KDE in a flash. -- John M. Trostel Linux OS Engineer Connex jtrostel@connex.com From owner-linux-xfs@oss.sgi.com Wed Jun 13 15:39:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DMdT110687 for linux-xfs-outgoing; Wed, 13 Jun 2001 15:39:29 -0700 Received: from yowie.cc.uq.edu.au (root@yowie.cc.uq.edu.au [130.102.2.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DMdRP10684 for ; Wed, 13 Jun 2001 15:39:28 -0700 Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1]) by yowie.cc.uq.edu.au (8.9.3/8.9.3) with ESMTP id IAA25455; Thu, 14 Jun 2001 08:39:20 +1000 (GMT+1000) Received: from nut.csee.uq.edu.au (nut.csee.uq.edu.au [130.102.66.13]) by gum.csee.uq.edu.au (8.11.3/8.11.3) with ESMTP id f5DMdJ522992; Thu, 14 Jun 2001 08:39:19 +1000 (EST) Received: from mango.csee.uq.edu.au (mango.csee.uq.edu.au [130.102.66.4]) by nut.csee.uq.edu.au (8.11.3/8.11.3) with ESMTP id f5DMdIm19226; Thu, 14 Jun 2001 08:39:18 +1000 (EST) Date: Thu, 14 Jun 2001 08:39:18 +1000 (EST) From: Chris Pascoe To: "D. Stimits" cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? In-Reply-To: <3B27E1B7.FF8018E9@idcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 1.1 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > This fails, though it succeeds all the way up until root filesystem > mount is attempted. I'm a bit frustrated by the lack of good debug > information when a root filesystem mount fails :( For example, I wish it > would say which modules were loaded at the time of failure. If you've got KDB support built in, can you hit the break key to enter it, and do an "lsmod" at this point? It should tell you what modules are loaded? Keith, correct me if I am wrong.. Chris From owner-linux-xfs@oss.sgi.com Wed Jun 13 16:20:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5DNKaX17858 for linux-xfs-outgoing; Wed, 13 Jun 2001 16:20:36 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5DNKWP17841 for ; Wed, 13 Jun 2001 16:20:32 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA14615 for ; Wed, 13 Jun 2001 16:20:28 -0700 (PDT) mail_from (ajag@fudge.melbourne.sgi.com) Received: from fudge.melbourne.sgi.com (fudge.melbourne.sgi.com [134.14.55.184]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA09518; Thu, 14 Jun 2001 09:19:11 +1000 Received: (from ajag@localhost) by fudge.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA21139; Thu, 14 Jun 2001 09:18:58 +1000 (EST) Date: Thu, 14 Jun 2001 09:18:57 +1000 From: Andrew Gildfind To: Keith Owens Cc: Tarkan Erimer , linux-xfs@oss.sgi.com Subject: Re: ACL Support Message-ID: <20010614091857.P8175@fudge.melbourne.sgi.com> References: <005a01c0f41e$a2cc7b40$040010ac@tarkane> <14493.992449545@ocs4.ocs-net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 1.0us In-Reply-To: <14493.992449545@ocs4.ocs-net>; from kaos@melbourne.sgi.com on Thu, Jun 14, 2001 at 02:25:45AM +1000 X-MIME-Autoconverted: from 8bit to quoted-printable by fudge.melbourne.sgi.com id JAA21139 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5DNKWP17842 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Jun 14, 2001 at 02:25:45AM +1000, Keith Owens wrote: > On Wed, 13 Jun 2001 18:36:38 +0300, > "Tarkan Erimer" wrote: > >I have a question about ACL support. Only installing XFS into the Linux > >kernel enough to get support ACLs? Or Is there any > >need to install ACL kernel patches found at http://acl.bestbits.at/ ? > > There are at least two groups working on ACLs for Linux and they > disagree about how they should be implemented. SGI has one > implementation of ACL, included in the XFS patch. Andreas Grünbacher's > ACLs are different and will not work with XFS. > To clarify that, we don't disagree at all, we're gradually working towards a common implementation. Things have moved slowly, but we have a friendly relationship with the ext2 people, and in due course we want to merge our efforts. Hopefully there will be more visible progress in the next couple of months. Andrew -- Andrew Gildfind - R&D Software Engineer - SGI Melbourne Australia email: ajag@sgi.com - work: +61.3.9834.8200 mobile: 0412.834.183 From owner-linux-xfs@oss.sgi.com Wed Jun 13 17:37:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E0bDL29390 for linux-xfs-outgoing; Wed, 13 Jun 2001 17:37:13 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E0bCP29387 for ; Wed, 13 Jun 2001 17:37:12 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip10.idcomm.com [209.60.72.137]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5E0akl03879 for ; Wed, 13 Jun 2001 18:36:46 -0600 Message-ID: <3B280776.2A753E89@idcomm.com> Date: Wed, 13 Jun 2001 18:38:14 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Chris Pascoe wrote: > > > This fails, though it succeeds all the way up until root filesystem > > mount is attempted. I'm a bit frustrated by the lack of good debug > > information when a root filesystem mount fails :( For example, I wish it > > would say which modules were loaded at the time of failure. > > If you've got KDB support built in, can you hit the break key to enter it, > and do an "lsmod" at this point? It should tell you what modules are > loaded? Keith, correct me if I am wrong.. > > Chris I have not used KDB yet, it looks like I'll need to. But, say for the moment I do have KDB. "lsmod" is on the root partition, and uses libc which is also on the root partition. Would enabling KDB help to run lsmod, or would it be another catch-22? D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Wed Jun 13 17:56:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E0upV32536 for linux-xfs-outgoing; Wed, 13 Jun 2001 17:56:51 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E0unP32527 for ; Wed, 13 Jun 2001 17:56:49 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip10.idcomm.com [209.60.72.137]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5E0uMl06413 for ; Wed, 13 Jun 2001 18:56:22 -0600 Message-ID: <3B280C0F.AE1B995E@idcomm.com> Date: Wed, 13 Jun 2001 18:57:51 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Chris Pascoe wrote: > > > NOTE: The /boot partition seems to be read fine, and the scsi controller > > is detected and works fine, including apparently the read of /boot. SCSI > > is directly compiled in. > > I don't believe the read of /boot isn't done using the system SCSI > modules; it's done using BIOS calls. So that it loads the kernel > and initrd is not an indication that the SCSI drivers, etc, actually > loaded properly. Ok, I did some experimenting. Background first: my /boot/ is the first partition; it is ext2; ext2 is compiled in. The test: I went ahead and made all scsi become a module. Voila, you were correct, running aic7xxx as module caused failure to load the scsi driver, and the boot failed earlier, though it got past networking. I'm about to try again, this time explicitly naming the scsi modules. I suspect it won't matter...the ramdisk is being completely ignored by lilo (I double-checked, no spelling errors in naming the file or path). > > Bear with me and check that you are seeing everything below: > > The point where the initrd is loaded starts with: > RAMDISK: Compressed image found at block 0 I have never seen this message; if it occurs early on, it is doing so when screen mode changes, and the screen is blank. By the time it is unblanked, no such RAMDISK message occurs. I am set for something like 60 lines vertical by 142 characters horizontal, so I see a *lot* of the bootup on just one screen page, but I still miss the few lines right after the uncompressing of the boot kernel. > > Then it is followed by (as the root filesystem on the ramdisk is mounted): > VFS: Mounted root (ext2 filesystem). In several paragraphs just before this (or rather, the VFS failure note), no "RAMDISK" occurs. > [I assume if you're loading XFS as a module, the filesystem on the initrd > is ext2, which is compiled into the booting kernel? Otherwise, you're > never going to get anywhere, because it needs to mount/run the initrd to > get xfs support, and it can't mount the initrd because it doesn't have > the xfs modules loaded yet..] Yes, XFS as module, initrd on ext2 of separate /boot, which is compiled in. If I don't have XFS or scsi as module, but all other things remain constant, it boots correctly and runs great. > > You should now see a few messages as the pagebuf/xfs_support/xfs modules > load (I assume, never used them as modules): (NB This might come after > the SCSI support has loaded): > Loading pagebuf module > Pagebuf cache Copyright (c) 2001 Silicon Graphics, Inc. > Loading xfs_support module > Loading xfs module > XFS filesystem Copyright (c) 2001 Silicon Graphics, Inc. This never occurs. It is obvious the ramdisk is not loading, but I cannot figure out why. The initial ramdisk is correctly made, and I can use the gzip scheme followed by mounting on loopback, and view the actual ramdisk contents to verify it has what it should need. > > After this, you should see a few SCSI driver messages at this > time, as the SCSI adaptor drivers load, then a bunch of lines like: > > (if you have scsi modules compiled in) > Loading scsi_mod module > Loading sd_mod module Never occurs. > > (always:) > Loading aacraid module (my SCSI driver) > Vendor: DELL Model: PERCRAID Mirror Rev: 0001 > Type: Direct-Access ANSI SCSI revision: 02 > Detected scsi removable disk sda at scsi0, channel 0, id 0, lun 0 > Vendor: DELL Model: PERCRAID RAID5 Rev: 0001 > Type: Direct-Access ANSI SCSI revision: 02 > Detected scsi removable disk sdb at scsi0, channel 0, id 1, lun 0 Occurs if I have scsi compiled in, regardless of whether xfs root filesystem mount fails; fails regardless of all other things if scsi is a module. It is painfully obvious that my initial ramdisk is 100% ignored. > > Indicating that the disks were detected. > > After that, it enumerates the partitions on the disk: > Partition check: > sda: sda1 sda2 sda3 < sda5 sda6 sda7 > > sdb: sdb1 sdb2 sdb3 > > And then it goes to mount the new root file system: > VFS: Mounted root (xfs filesystem) readonly. > > If you're not seeing the "Detected scsi disk..." lines above, I'm guessing > that you haven't got the scsi disk support compiled in, or the disks > loaded. The "Detected" part works with compiled-in scsi. I'll have to view it closer for the partition check, I can't recall if that is visible (when boot fails, I have to hand copy everything in order to report on it). > > Can you check the compare the output you get of the boot process with what > I've pasted above, and let us know the differences? Also, knowing the > contents of the /linuxrc on the initrd would be handy. > > Chris The linuxrc from ramdisk when scsi and xfs are both modules: #!/bin/sash aliasall echo "Loading scsi_mod module" insmod /lib/scsi_mod.o echo "Loading sd_mod module" insmod /lib/sd_mod.o echo "Loading aic7xxx module" insmod /lib/aic7xxx.o echo "Loading pagebuf module" insmod /lib/pagebuf.o echo "Loading xfs_support module" insmod /lib/xfs_support.o echo "Loading xfs module" insmod /lib/xfs.o I cannot see how this should fail, except that in the process of running lilo (I use lilo -v -v), initial ramdisk is being totally ignored. At one point I found there was a label limit for the name of the label. When I tried to create this label (much earlier, successful kernel), it failed, telling me the name was too long: label=2.4.6-pre1-xfs-2 So I shortened it and it accepted it: label=2.4.6-p1-xfs-2 I don't know where the size limit is, but it accepts labels of 14 characters, and rejects labels of 16 characters; my guess is it needs 15 characters plus NULL in a 16 char buffer. My initrd though is this on the failing kernel (via lilo.conf): initrd=/boot/initrd-2.4.6-pre1-xfs-3.img I wonder if it can't accept that long of a name or path? If it fails due to truncation, but is not telling me, this could be it (I'll try a shorter name for testing, haven't done so yet though). But in general, lilo -v -v tells me all things are successful...I have been watching it for errors...there are no errors or warnings. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Wed Jun 13 17:57:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E0vB932601 for linux-xfs-outgoing; Wed, 13 Jun 2001 17:57:11 -0700 Received: from brev.stud.ntnu.no (IDENT:postfix@brev.stud.ntnu.no [129.241.56.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E0vAP32598 for ; Wed, 13 Jun 2001 17:57:10 -0700 Received: from localhost (localhost [127.0.0.1]) by brev.stud.ntnu.no (Postfix) with ESMTP id 7F8708113; Thu, 14 Jun 2001 02:57:08 +0200 (CEST) Received: from jeeves.stud.ntnu.no (jeeves [129.241.56.14]) by brev.stud.ntnu.no (Postfix) with ESMTP id DFC1480E1; Thu, 14 Jun 2001 02:57:07 +0200 (CEST) Received: from localhost (sebastid@localhost) by jeeves.stud.ntnu.no (8.10.0.Beta12/8.10.0.Beta12) with ESMTP id f5E0v8603084; Thu, 14 Jun 2001 02:57:08 +0200 (MET DST) X-Authentication-Warning: jeeves.stud.ntnu.no: sebastid owned process doing -bs Date: Thu, 14 Jun 2001 02:57:08 +0200 (MET DST) From: Sebastian Dransfeld To: "D. Stimits" Cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? In-Reply-To: <3B280776.2A753E89@idcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-10 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001, D. Stimits wrote: > Chris Pascoe wrote: > > > > > This fails, though it succeeds all the way up until root filesystem > > > mount is attempted. I'm a bit frustrated by the lack of good debug > > > information when a root filesystem mount fails :( For example, I wish it > > > would say which modules were loaded at the time of failure. > > > > If you've got KDB support built in, can you hit the break key to enter it, > > and do an "lsmod" at this point? It should tell you what modules are > > loaded? Keith, correct me if I am wrong.. > > > > Chris > > I have not used KDB yet, it looks like I'll need to. But, say for the > moment I do have KDB. "lsmod" is on the root partition, and uses libc > which is also on the root partition. Would enabling KDB help to run > lsmod, or would it be another catch-22? > Compile a static version of lsmod. Sebastian From owner-linux-xfs@oss.sgi.com Wed Jun 13 18:20:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E1KxW03739 for linux-xfs-outgoing; Wed, 13 Jun 2001 18:20:59 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E1KwP03728 for ; Wed, 13 Jun 2001 18:20:58 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id SAA06384 for ; Wed, 13 Jun 2001 18:21:18 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) 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 LAA10440; Thu, 14 Jun 2001 11:19:37 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: stimits@idcomm.com cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? In-reply-to: Your message of "Wed, 13 Jun 2001 18:38:14 CST." <3B280776.2A753E89@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Jun 2001 11:19:37 +1000 Message-ID: <9980.992481577@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001 18:38:14 -0600, "D. Stimits" wrote: >I have not used KDB yet, it looks like I'll need to. But, say for the >moment I do have KDB. "lsmod" is on the root partition, and uses libc >which is also on the root partition. Would enabling KDB help to run >lsmod, or would it be another catch-22? kdb has a built in lsmod command, no need for the root filesystem. From owner-linux-xfs@oss.sgi.com Wed Jun 13 18:22:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E1MvI04084 for linux-xfs-outgoing; Wed, 13 Jun 2001 18:22:57 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E1MuP04079 for ; Wed, 13 Jun 2001 18:22:56 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id VAA18846; Wed, 13 Jun 2001 21:14:52 -0400 Message-ID: <3B28144A.5F0C2815@ieee.org> Date: Wed, 13 Jun 2001 21:32:58 -0400 From: "Bryan J. Smith" Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: james rich CC: "Nathan J. Mehl" , Russell Cattelan , Eric Sandeen , Juha Saarinen , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk james rich wrote: > Since XFS integrates with the OS they would have to GPL Solaris (I think) > - not likely. With a BSD compatible license (such as would be required to > make it into the *BSDs) Sun (or anyone else) could take the XFS code, > modify it to work for them (and potentially not work for you - see > MicroSoft and kerberos) and then sell the result *without helping SGI in > any way*. So SGI loses contributors to it's code and gains a competitor > using its own filesystem! GPL is an IP _protector_, whereas BSD is not. Again, check out my preliminary "dual-licensing GPL" article here: http://www.smithconcepts.com/opinion/#tth_sEc1.2 Please comment. I plan on finishing it off over the next few days (just haven't had time to even spell check it!). -- TheBS -- Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 SmithConcepts, Inc. http://www.SmithConcepts.com ========================================================== Linux 'Worms' exploit known security holes that were fixed 3-12 months earlier. NT/2000 'Worms' exploit unknown se- curity holes that won't be fixed for another 3-12 months. From owner-linux-xfs@oss.sgi.com Wed Jun 13 18:25:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E1PcV04530 for linux-xfs-outgoing; Wed, 13 Jun 2001 18:25:38 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E1PbP04523 for ; Wed, 13 Jun 2001 18:25:37 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id VAA18850; Wed, 13 Jun 2001 21:17:48 -0400 Message-ID: <3B2814FA.92B290A8@ieee.org> Date: Wed, 13 Jun 2001 21:35:54 -0400 From: "Bryan J. Smith" Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Nathan J. Mehl" CC: james rich , Russell Cattelan , Eric Sandeen , Juha Saarinen , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp References: <20010613024149.Z8330@blank.org> <20010613181536.G8330@blank.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Nathan J. Mehl" wrote: > Why on earth do you make this assertion? Solaris supports loadable > independent kernel modules just as linux does -- implementing xfs on > solaris in a way that didn't "contaminate" the kernel with the GPL > would be a pretty straightforward exercise. (Well, at least, it would > probably not add significantly to the effort involved in a Solaris > port to begin with, which might be high.) Actually, I think everyone here is failing to realize this canNOT be done via the GPL, unless you add the provision. Dynamically linking/loading is normally allowed via the Lesser GPL (LGPL). But as the holder of the copyrights, it is upto SGI to determine what is allowable and what is not. > I think we're all in agreement that a BSD-style license doesn't get > SGI anything but goodwill from the xBSD camp. I just think the > paranoia about Sun is probably unjustified: as I've pointed out > elsewhere, they gain little and potentially lose a lot by adopting > XFS into Solaris's base distribution. Sun Solaris was just an example. The number of "threats" to SGI's IP would be a lot greater than you think if they released XFS as BSD licensed. -- TheBS -- Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 SmithConcepts, Inc. http://www.SmithConcepts.com ========================================================== Linux 'Worms' exploit known security holes that were fixed 3-12 months earlier. NT/2000 'Worms' exploit unknown se- curity holes that won't be fixed for another 3-12 months. From owner-linux-xfs@oss.sgi.com Wed Jun 13 18:26:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E1QNw04643 for linux-xfs-outgoing; Wed, 13 Jun 2001 18:26:23 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E1QLP04632 for ; Wed, 13 Jun 2001 18:26:22 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f5E1QAaJ093140; Wed, 13 Jun 2001 20:26:10 -0500 (CDT) Message-ID: <3B2812AC.8EB3B95E@thebarn.com> Date: Wed, 13 Jun 2001 20:26:05 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Bryan J. Smith" CC: james rich , "Nathan J. Mehl" , Eric Sandeen , Juha Saarinen , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp References: <3B28144A.5F0C2815@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Bryan J. Smith" wrote: > james rich wrote: > > Since XFS integrates with the OS they would have to GPL Solaris (I think) > > - not likely. With a BSD compatible license (such as would be required to > > make it into the *BSDs) Sun (or anyone else) could take the XFS code, > > modify it to work for them (and potentially not work for you - see > > MicroSoft and kerberos) and then sell the result *without helping SGI in > > any way*. So SGI loses contributors to it's code and gains a competitor > > using its own filesystem! > > GPL is an IP _protector_, Hardly! nothing in the GPL says I can't read the code and re implement. Intellectual Property is protected by patents not copyrights. > whereas BSD is not. > > Again, check out my preliminary "dual-licensing GPL" article here: > http://www.smithconcepts.com/opinion/#tth_sEc1.2 > > Please comment. I plan on finishing it off over the next few days > (just haven't had time to even spell check it!). > > -- TheBS > > -- > Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 > SmithConcepts, Inc. http://www.SmithConcepts.com > ========================================================== > Linux 'Worms' exploit known security holes that were fixed > 3-12 months earlier. NT/2000 'Worms' exploit unknown se- > curity holes that won't be fixed for another 3-12 months. -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Wed Jun 13 18:36:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E1awn05913 for linux-xfs-outgoing; Wed, 13 Jun 2001 18:36:58 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E1avP05908 for ; Wed, 13 Jun 2001 18:36:57 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f5E1alaJ093245; Wed, 13 Jun 2001 20:36:48 -0500 (CDT) Message-ID: <3B28152A.9FC9E865@thebarn.com> Date: Wed, 13 Jun 2001 20:36:42 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Bryan J. Smith" CC: "Nathan J. Mehl" , james rich , Eric Sandeen , Juha Saarinen , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp References: <20010613024149.Z8330@blank.org> <20010613181536.G8330@blank.org> <3B2814FA.92B290A8@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Bryan J. Smith" wrote: > "Nathan J. Mehl" wrote: > > Why on earth do you make this assertion? Solaris supports loadable > > independent kernel modules just as linux does -- implementing xfs on > > solaris in a way that didn't "contaminate" the kernel with the GPL > > would be a pretty straightforward exercise. (Well, at least, it would > > probably not add significantly to the effort involved in a Solaris > > port to begin with, which might be high.) > > Actually, I think everyone here is failing to realize this canNOT be > done via the GPL, unless you add the provision. Dynamically > linking/loading is normally allowed via the Lesser GPL (LGPL). But > as the holder of the copyrights, it is upto SGI to determine what is > allowable and what is not. What are you talking about? What you are saying all of the non GPL'ed linux kernel modules are in violation of the GPL?! Guess somebody better stick some lawyers on Nvidia. Ohh and explain this problem to Linus also. > > > > I think we're all in agreement that a BSD-style license doesn't get > > SGI anything but goodwill from the xBSD camp. I just think the > > paranoia about Sun is probably unjustified: as I've pointed out > > elsewhere, they gain little and potentially lose a lot by adopting > > XFS into Solaris's base distribution. > > Sun Solaris was just an example. The number of "threats" to SGI's > IP would be a lot greater than you think if they released XFS as BSD > licensed. Ohh?! like how... > > > -- TheBS > > -- > Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 > SmithConcepts, Inc. http://www.SmithConcepts.com > ========================================================== > Linux 'Worms' exploit known security holes that were fixed > 3-12 months earlier. NT/2000 'Worms' exploit unknown se- > curity holes that won't be fixed for another 3-12 months. -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Wed Jun 13 18:48:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E1m9W07226 for linux-xfs-outgoing; Wed, 13 Jun 2001 18:48:09 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E1m8P07223 for ; Wed, 13 Jun 2001 18:48:08 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id VAA18881; Wed, 13 Jun 2001 21:41:05 -0400 Message-ID: <3B281A70.18AC1760@ieee.org> Date: Wed, 13 Jun 2001 21:59:12 -0400 From: "Bryan J. Smith" Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Russell Cattelan CC: "Nathan J. Mehl" , james rich , Eric Sandeen , Juha Saarinen , linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp References: <20010613024149.Z8330@blank.org> <20010613181536.G8330@blank.org> <3B2814FA.92B290A8@ieee.org> <3B28152A.9FC9E865@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Russell Cattelan wrote: > What are you talking about? > What you are saying all of the non GPL'ed linux kernel modules are in > violation of the GPL?! > Guess somebody better stick some lawyers on Nvidia. > Ohh and explain this problem to Linus also. Okay, I retract that. The GPL _does_ have a provision for linking against core system files (like the kernel). -- TheBS -- Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 SmithConcepts, Inc. http://www.SmithConcepts.com ========================================================== Linux 'Worms' exploit known security holes that were fixed 3-12 months earlier. NT/2000 'Worms' exploit unknown se- curity holes that won't be fixed for another 3-12 months. From owner-linux-xfs@oss.sgi.com Wed Jun 13 18:49:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E1n2b07407 for linux-xfs-outgoing; Wed, 13 Jun 2001 18:49:02 -0700 Received: from walt400.holman.net (aazpppdsl56.sttl.uswest.net [63.226.208.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E1n1P07403 for ; Wed, 13 Jun 2001 18:49:01 -0700 Received: from uswest.net (walt400.holman.net [10.0.0.2]) by walt400.holman.net (Postfix) with ESMTP id D78FE43A3EC; Wed, 13 Jun 2001 18:59:20 -0700 (PDT) Message-ID: <3B281A78.5000809@uswest.net> Date: Wed, 13 Jun 2001 18:59:20 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.6-pre3-xfs i686; en-US; rv:0.9.1) Gecko/20010607 X-Accept-Language: en-us MIME-Version: 1.0 To: stimits@idcomm.com Cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <3B26C626.24EC0F20@idcomm.com> <3B26CC5E.6050804@uswest.net> <3B26D839.E6C58E3E@idcomm.com> <3B26DCBB.2289C8FC@sigmastorage.com> <3B26E3DF.1B22B76A@idcomm.com> <3B26EFD1.723327FA@thebarn.com> <3B27E2B5.CB5E4CF6@idcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I've been running XFS compiled as modules for months now, so I know it can be done. I'm not sure if this should matter, but I always use --preload for the pagebuf & xfs_support modules. Also, I use just the stock-block mkinitrd command. Below is my exact syntax, which - works for me (tm) :) mkinitrd -v --preload pagebuf --preload xfs_support --with=reiserfs /boot/initrd-2.4.6-pre3.xfs.img 2.4.6-pre3-xfs This works without a hitch on my end. Hope this helps, -Walt D. Stimits wrote: >Russell Cattelan wrote: > >>"D. Stimits" wrote: >> >>>Matt Ryan wrote: >>> >>>>sorry, I meant to write that to the list as well. I just wrote: >>>> >>>>gzip -dc your.img > somefile >>>>mount -o loop somefile somedir >>>> >>>>also, just running mkinitrd with the verbose (-v) option is pretty >>>>helpful too >>>>(not sure if you were doing that already). >>>> >>>I've done -v, and also mounted each of the initrd images since then. I >>>definitely have the three modules I know of which are required: >>>pagebuf.o >>>xfs.o >>>xfs_support.o >>> >>note the modules must load in this order >>pagebuf >>xfs_support >>xfs >> > >I carefully made certain this was the order in the mkinitrd.xfs. It >still fails at the point of mounting root partition (note: this is a >hard drive, not floppy). There must be something else? My command line >for mkinitrd.xfs: >mkinitrd.xfs \ > --with=pagebuf \ > --with=xfs_support \ > --with=xfs =\ > /boot/initrd-2.4.6-pre1-xfs-3.img \ > 2.4.6-pre1-xfs-3 > >NOTE: The /boot partition seems to be read fine, and the scsi controller >is detected and works fine, including apparently the read of /boot. SCSI >is directly compiled in. > >D. Stimits, stimits@idcomm.com > >>When specifying them on the command the order they are >>given is the order they are loaded. >> >>The mkinird.xfs in the source tree just added the modules to the >>basicmodules list rather than having to list them by hand on the command >>line. >> >>Note the 0.9 release of XFS installed xfs as modules using mkinitrd.xfs to >>build >>the initrd, the 0.10 and 1.0 release did not do this since boots seem to >>take slightly >>less time with xfs in the kernel. >> >>> >>>Perhaps there is some kind of argument or order required that I don't >>>have? Or, since I compiled the kernel on RH 7.1 and used kgcc, would >>>there be some sort of change required to the compile of mkinitrd.xfs to >>>make it use kgcc as well? I noticed this URL does not have mkinitrd.xfs >>>man page: >>>http://oss.sgi.com/projects/xfs/manpages.html >>> >>>...and the cvs cmd/xfsmisc/ does not seem to produce one either. My >>>assumption is that this and the original mkinitrd are identical >>>(incidentally, I turned in a report to RH bugzilla that their man page >>>does not match the command line option syntax of mkinitrd --help...the >>>latter is accurate, the former not for --preload=). >>> >>>So can *anyone* verify that it really is possible to run XFS as modules? >>>If so, can I get a list of modules you have under lsmod? Or if you >>>remember, a sample of the mkinitrd.xfs line used? >>> >>>D. Stimits, stimits@idcomm.com >>> >>>>Matt >>>> >>>>>While I'm convinced that this is the basic problem, I can't figure out >>>>>what is missing. Matt Ryan gave me one very useful command to mount my >>>>>initial ramdisk on loopback and see what it actually contains. I can >>>>> >>-- >>Russell Cattelan >>cattelan@thebarn.com >> > From owner-linux-xfs@oss.sgi.com Wed Jun 13 19:12:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E2Cqc08839 for linux-xfs-outgoing; Wed, 13 Jun 2001 19:12:52 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E2CpP08836 for ; Wed, 13 Jun 2001 19:12:51 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip19.idcomm.com [209.60.72.146]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5E2CPl15691 for ; Wed, 13 Jun 2001 20:12:25 -0600 Message-ID: <3B281DE1.EE4AFC33@idcomm.com> Date: Wed, 13 Jun 2001 20:13:53 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <3B26C626.24EC0F20@idcomm.com> <3B26CC5E.6050804@uswest.net> <3B26D839.E6C58E3E@idcomm.com> <3B26DCBB.2289C8FC@sigmastorage.com> <3B26E3DF.1B22B76A@idcomm.com> <3B26EFD1.723327FA@thebarn.com> <3B27E2B5.CB5E4CF6@idcomm.com> <3B281A78.5000809@uswest.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Walt H wrote: > > Hello, > > I've been running XFS compiled as modules for months now, so I know it > can be done. I'm not sure if this should matter, but I always use > --preload for the pagebuf & xfs_support modules. Also, I use just the > stock-block mkinitrd command. Below is my exact syntax, which - works > for me (tm) :) > > mkinitrd -v --preload pagebuf --preload xfs_support --with=reiserfs > /boot/initrd-2.4.6-pre3.xfs.img 2.4.6-pre3-xfs Short related question...have you tried this with mkinitrd.xfs? And does your lilo.conf contain anything to increase initial ramdisk size, e.g.: append="ramdisk_size=25000" D. Stimits, stimits@idcomm.com > > This works without a hitch on my end. Hope this helps, > > -Walt > > D. Stimits wrote: > > >Russell Cattelan wrote: > > > >>"D. Stimits" wrote: > >> > >>>Matt Ryan wrote: > >>> > >>>>sorry, I meant to write that to the list as well. I just wrote: > >>>> > >>>>gzip -dc your.img > somefile > >>>>mount -o loop somefile somedir > >>>> > >>>>also, just running mkinitrd with the verbose (-v) option is pretty > >>>>helpful too > >>>>(not sure if you were doing that already). > >>>> > >>>I've done -v, and also mounted each of the initrd images since then. I > >>>definitely have the three modules I know of which are required: > >>>pagebuf.o > >>>xfs.o > >>>xfs_support.o > >>> > >>note the modules must load in this order > >>pagebuf > >>xfs_support > >>xfs > >> > > > >I carefully made certain this was the order in the mkinitrd.xfs. It > >still fails at the point of mounting root partition (note: this is a > >hard drive, not floppy). There must be something else? My command line > >for mkinitrd.xfs: > >mkinitrd.xfs \ > > --with=pagebuf \ > > --with=xfs_support \ > > --with=xfs =\ > > /boot/initrd-2.4.6-pre1-xfs-3.img \ > > 2.4.6-pre1-xfs-3 > > > >NOTE: The /boot partition seems to be read fine, and the scsi controller > >is detected and works fine, including apparently the read of /boot. SCSI > >is directly compiled in. > > > >D. Stimits, stimits@idcomm.com > > > >>When specifying them on the command the order they are > >>given is the order they are loaded. > >> > >>The mkinird.xfs in the source tree just added the modules to the > >>basicmodules list rather than having to list them by hand on the command > >>line. > >> > >>Note the 0.9 release of XFS installed xfs as modules using mkinitrd.xfs to > >>build > >>the initrd, the 0.10 and 1.0 release did not do this since boots seem to > >>take slightly > >>less time with xfs in the kernel. > >> > >>> > >>>Perhaps there is some kind of argument or order required that I don't > >>>have? Or, since I compiled the kernel on RH 7.1 and used kgcc, would > >>>there be some sort of change required to the compile of mkinitrd.xfs to > >>>make it use kgcc as well? I noticed this URL does not have mkinitrd.xfs > >>>man page: > >>>http://oss.sgi.com/projects/xfs/manpages.html > >>> > >>>...and the cvs cmd/xfsmisc/ does not seem to produce one either. My > >>>assumption is that this and the original mkinitrd are identical > >>>(incidentally, I turned in a report to RH bugzilla that their man page > >>>does not match the command line option syntax of mkinitrd --help...the > >>>latter is accurate, the former not for --preload=). > >>> > >>>So can *anyone* verify that it really is possible to run XFS as modules? > >>>If so, can I get a list of modules you have under lsmod? Or if you > >>>remember, a sample of the mkinitrd.xfs line used? > >>> > >>>D. Stimits, stimits@idcomm.com > >>> > >>>>Matt > >>>> > >>>>>While I'm convinced that this is the basic problem, I can't figure out > >>>>>what is missing. Matt Ryan gave me one very useful command to mount my > >>>>>initial ramdisk on loopback and see what it actually contains. I can > >>>>> > >>-- > >>Russell Cattelan > >>cattelan@thebarn.com > >> > > From owner-linux-xfs@oss.sgi.com Wed Jun 13 19:12:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E2Cu608866 for linux-xfs-outgoing; Wed, 13 Jun 2001 19:12:56 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E2CsP08863 for ; Wed, 13 Jun 2001 19:12:55 -0700 Received: from [192.168.1.10] (helo=den2) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15AMcr-0008D4-00; Thu, 14 Jun 2001 14:12:49 +1200 From: "Juha Saarinen" To: "'Russell Cattelan'" , "'Bryan J. Smith'" Cc: "'Eric Sandeen'" , Subject: RE: Interest from the FreeBSD camp Date: Thu, 14 Jun 2001 14:12:26 +1200 Message-ID: <00c101c0f477$75188280$0a01a8c0@den2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-reply-to: <3B28152A.9FC9E865@thebarn.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [cc list trimmed] I'm terribly sorry, I only meant to ask what I thought was a perfectly simple question about XFS and FreeBSD... I didn't meant for this thread to turn into a licensing flame-fest. :: What are you talking about? :: What you are saying all of the non GPL'ed linux kernel :: modules are in :: violation of the GPL?! :: Guess somebody better stick some lawyers on Nvidia. :: Ohh and explain this problem to Linus also. Well, nVidia's kernel drivers/modules are only partly GPL, right? There's a binary component with code from SGI (correct me if I'm wrong) and others, that isn't GPL. -- Juha From owner-linux-xfs@oss.sgi.com Wed Jun 13 19:25:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E2PIp09866 for linux-xfs-outgoing; Wed, 13 Jun 2001 19:25:18 -0700 Received: from walt400.holman.net (aazpppdsl56.sttl.uswest.net [63.226.208.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E2PGP09862 for ; Wed, 13 Jun 2001 19:25:16 -0700 Received: from uswest.net (walt400.holman.net [10.0.0.2]) by walt400.holman.net (Postfix) with ESMTP id 24990401D29; Wed, 13 Jun 2001 19:35:36 -0700 (PDT) Message-ID: <3B2822F8.4010608@uswest.net> Date: Wed, 13 Jun 2001 19:35:36 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.6-pre3-xfs i686; en-US; rv:0.9.1) Gecko/20010607 X-Accept-Language: en-us MIME-Version: 1.0 To: stimits@idcomm.com Cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <3B26C626.24EC0F20@idcomm.com> <3B26CC5E.6050804@uswest.net> <3B26D839.E6C58E3E@idcomm.com> <3B26DCBB.2289C8FC@sigmastorage.com> <3B26E3DF.1B22B76A@idcomm.com> <3B26EFD1.723327FA@thebarn.com> <3B27E2B5.CB5E4CF6@idcomm.com> <3B281A78.5000809@uswest.net> <3B281DE1.EE4AFC33@idcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've not tried this with mkinitrd.xfs - I always use the mkinitrd command. Also, when I build my kernels, I configure the initial ramdisk size at 6144 so that it'll all fit. That's about it. The only other thing, is that I use a reiserfs partition for my /boot mount - gotta have jfs no matter what :) (Except, due to a nfs issue, I don't use it for anything else - once bitten, twice shy) The size of my initrd.img is around 1.5MB, but I imaging without reiserfs it'd fit on a floppy. -Walt D. Stimits wrote: >Walt H wrote: > >>Hello, >> >>I've been running XFS compiled as modules for months now, so I know it >>can be done. I'm not sure if this should matter, but I always use >>--preload for the pagebuf & xfs_support modules. Also, I use just the >>stock-block mkinitrd command. Below is my exact syntax, which - works >>for me (tm) :) >> >>mkinitrd -v --preload pagebuf --preload xfs_support --with=reiserfs >>/boot/initrd-2.4.6-pre3.xfs.img 2.4.6-pre3-xfs >> > >Short related question...have you tried this with mkinitrd.xfs? And does >your lilo.conf contain anything to increase initial ramdisk size, e.g.: > append="ramdisk_size=25000" > >D. Stimits, stimits@idcomm.com > >>This works without a hitch on my end. Hope this helps, >> >>-Walt >> >>D. Stimits wrote: >> >>>Russell Cattelan wrote: >>> >>>>"D. Stimits" wrote: >>>> >>>>>Matt Ryan wrote: >>>>> >>>>>>sorry, I meant to write that to the list as well. I just wrote: >>>>>> >>>>>>gzip -dc your.img > somefile >>>>>>mount -o loop somefile somedir >>>>>> >>>>>>also, just running mkinitrd with the verbose (-v) option is pretty >>>>>>helpful too >>>>>>(not sure if you were doing that already). >>>>>> >>>>>I've done -v, and also mounted each of the initrd images since then. I >>>>>definitely have the three modules I know of which are required: >>>>>pagebuf.o >>>>>xfs.o >>>>>xfs_support.o >>>>> >>>>note the modules must load in this order >>>>pagebuf >>>>xfs_support >>>>xfs >>>> >>>I carefully made certain this was the order in the mkinitrd.xfs. It >>>still fails at the point of mounting root partition (note: this is a >>>hard drive, not floppy). There must be something else? My command line >>>for mkinitrd.xfs: >>>mkinitrd.xfs \ >>> --with=pagebuf \ >>> --with=xfs_support \ >>> --with=xfs =\ >>> /boot/initrd-2.4.6-pre1-xfs-3.img \ >>> 2.4.6-pre1-xfs-3 >>> >>>NOTE: The /boot partition seems to be read fine, and the scsi controller >>>is detected and works fine, including apparently the read of /boot. SCSI >>>is directly compiled in. >>> >>>D. Stimits, stimits@idcomm.com >>> >>>>When specifying them on the command the order they are >>>>given is the order they are loaded. >>>> >>>>The mkinird.xfs in the source tree just added the modules to the >>>>basicmodules list rather than having to list them by hand on the command >>>>line. >>>> >>>>Note the 0.9 release of XFS installed xfs as modules using mkinitrd.xfs to >>>>build >>>>the initrd, the 0.10 and 1.0 release did not do this since boots seem to >>>>take slightly >>>>less time with xfs in the kernel. >>>> >>>>>Perhaps there is some kind of argument or order required that I don't >>>>>have? Or, since I compiled the kernel on RH 7.1 and used kgcc, would >>>>>there be some sort of change required to the compile of mkinitrd.xfs to >>>>>make it use kgcc as well? I noticed this URL does not have mkinitrd.xfs >>>>>man page: >>>>>http://oss.sgi.com/projects/xfs/manpages.html >>>>> >>>>>...and the cvs cmd/xfsmisc/ does not seem to produce one either. My >>>>>assumption is that this and the original mkinitrd are identical >>>>>(incidentally, I turned in a report to RH bugzilla that their man page >>>>>does not match the command line option syntax of mkinitrd --help...the >>>>>latter is accurate, the former not for --preload=). >>>>> >>>>>So can *anyone* verify that it really is possible to run XFS as modules? >>>>>If so, can I get a list of modules you have under lsmod? Or if you >>>>>remember, a sample of the mkinitrd.xfs line used? >>>>> >>>>>D. Stimits, stimits@idcomm.com >>>>> >>>>>>Matt >>>>>> >>>>>>>While I'm convinced that this is the basic problem, I can't figure out >>>>>>>what is missing. Matt Ryan gave me one very useful command to mount my >>>>>>>initial ramdisk on loopback and see what it actually contains. I can >>>>>>> >>>>-- >>>>Russell Cattelan >>>>cattelan@thebarn.com >>>> > From owner-linux-xfs@oss.sgi.com Wed Jun 13 19:31:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E2VSc10272 for linux-xfs-outgoing; Wed, 13 Jun 2001 19:31:28 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E2V6P10249 for ; Wed, 13 Jun 2001 19:31:06 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id EAA170317 for ; Thu, 14 Jun 2001 04:31:03 +0200 (CEST) mail_from (kaos@melbourne.sgi.com) 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 MAA10882; Thu, 14 Jun 2001 12:29:11 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Russell Cattelan cc: linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp In-reply-to: Your message of "Wed, 13 Jun 2001 20:36:42 EST." <3B28152A.9FC9E865@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Jun 2001 12:29:11 +1000 Message-ID: <10546.992485751@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001 20:36:42 -0500, Russell Cattelan wrote: >"Bryan J. Smith" wrote: >> Actually, I think everyone here is failing to realize this canNOT be >> done via the GPL, unless you add the provision. Dynamically >> linking/loading is normally allowed via the Lesser GPL (LGPL). But >> as the holder of the copyrights, it is upto SGI to determine what is >> allowable and what is not. >What are you talking about? >What you are saying all of the non GPL'ed linux kernel modules are in >violation of the GPL?! >Guess somebody better stick some lawyers on Nvidia. >Ohh and explain this problem to Linus also. Linus made an exception to the GPL for loadable kernel modules. Loadable modules can be non-GPL as long as they use the existing and exported kernel interfaces, changes to the core kernel must be GPL. Nvidia cheat on this. Their loadable module is supplied in source form and is GPL. But the module creates a special device which gives user space applications direct access to kernel internals. The real code is in a 2Mb binary only user app which uses the interfaces from their module to read and write kernel data. Nobody will look at bugs with Nvidia code loaded because we do not know what they update in the kernel via their "let's break all kernel integrity" interface. The Nvidia code is actually within the letter of the GPL, the system call interface is the boundary between the GPL kernel and the non-GPL user space applications. However it is definitely against the spirit of the GPL. Other binary only modules fall within Linus's exception to the GPL. There are arguments that Linus does not have the authority to make this exception. A module can use any exported kernel interface, on a strict reading of copyright law only the people who wrote each interface can relax the GPL for that interface, Linus did not write everything. However nobody has felt strongly enough about this point to put their foot down (yet). From owner-linux-xfs@oss.sgi.com Wed Jun 13 20:48:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E3mtj14615 for linux-xfs-outgoing; Wed, 13 Jun 2001 20:48:55 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E3mrP14612 for ; Wed, 13 Jun 2001 20:48:53 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip7.idcomm.com [209.60.72.134]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5E3mSl26523 for ; Wed, 13 Jun 2001 21:48:28 -0600 Message-ID: <3B283464.A3667572@idcomm.com> Date: Wed, 13 Jun 2001 21:49:56 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <3B26C626.24EC0F20@idcomm.com> <3B26CC5E.6050804@uswest.net> <3B26D839.E6C58E3E@idcomm.com> <3B26DCBB.2289C8FC@sigmastorage.com> <3B26E3DF.1B22B76A@idcomm.com> <3B26EFD1.723327FA@thebarn.com> <3B27E2B5.CB5E4CF6@idcomm.com> <3B281A78.5000809@uswest.net> <3B281DE1.EE4AFC33@idcomm.com> <3B2822F8.4010608@uswest.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk To summarize, things are still failing. When I use modules for scsi, it is apparent that no ramdisk is being used at all. I have tried variations of using original mkinitrd, as well as mkinitrd.xfs. I definitely have a ramdisk that contains the required modules, it just ignores it. Here is the most recent mkinitrd command: mkinitrd \ -v \ -f \ --preload pagebuf \ --preload xfs_support \ --preload xfs \ --with=scsi_mod \ --with=sd_mod \ --with=aic7xxx \ /boot/ir-2.4.6-p1-xfs-3.img \ 2.4.6-pre1-xfs-3 Here is the output: Using modules: ./kernel/fs/pagebuf/pagebuf.o ./kernel/fs/xfs_support/xfs_support.o ./kernel/fs/xfs/xfs.o ./kernel/drivers/scsi/scsi_mod.o ./kernel/drivers/scsi/sd_mod.o ./kernel/drivers/scsi/aic7xxx/aic7xxx.o Using loopback device /dev/loop0 /sbin/nash -> /tmp/initrd.sXOMy4/bin/nash /sbin/insmod.static -> /tmp/initrd.sXOMy4/bin/insmod `/lib/modules/2.4.6-pre1-xfs-3/./kernel/fs/pagebuf/pagebuf.o' -> `/tmp/initrd.sXOMy4/lib/pagebuf.o' `/lib/modules/2.4.6-pre1-xfs-3/./kernel/fs/xfs_support/xfs_support.o' -> `/tmp/initrd.sXOMy4/lib/xfs_support.o' `/lib/modules/2.4.6-pre1-xfs-3/./kernel/fs/xfs/xfs.o' -> `/tmp/initrd.sXOMy4/lib/xfs.o' `/lib/modules/2.4.6-pre1-xfs-3/./kernel/drivers/scsi/scsi_mod.o' -> `/tmp/initrd.sXOMy4/lib/scsi_mod.o' `/lib/modules/2.4.6-pre1-xfs-3/./kernel/drivers/scsi/sd_mod.o' -> `/tmp/initrd.sXOMy4/lib/sd_mod.o' `/lib/modules/2.4.6-pre1-xfs-3/./kernel/drivers/scsi/aic7xxx/aic7xxx.o' -> `/tmp/initrd.sXOMy4/lib/aic7xxx.o' Loading module pagebuf with options Loading module xfs_support with options Loading module xfs with options Loading module scsi_mod with options Loading module sd_mod with options Loading module aic7xxx with options Here is my lilo.conf for that (note that the -2 works and has scsi and xfs compiled in, while the -3 version is all modules for scsi and xfs; I shortened the name of the ramdisk file hoping it was just too long before, but it did not help): boot=/dev/sda map=/boot/map install=/boot/boot.b prompt timeout=50 message=/boot/message linear vga=0x030c default=2.4.6-p1-xfs-2 backup=boot.backup.when-2.4.6-pre1-xfs-3 # FAILS, uses modules. image=/boot/vmlinuz-2.4.6-pre1-xfs-3 label=2.4.6-p1-xfs-3 initrd=/boot/ir-2.4.6-p1-xfs-3.img read-only root=/dev/sda6 append="noapic ramdisk_size=16000" # works, no modules. image=/boot/vmlinuz-2.4.6-pre1-xfs-2 label=2.4.6-p1-xfs-2 initrd=/boot/initrd-2.4.6-pre1-xfs-2.img read-only root=/dev/sda6 append="noapic" Here lilo explicitly names the ramdisk as 1304 sectors for the -3 version that is in question. Unfortunately, it lies, it is ignoring the ramdisk, and loads nothing from it. The output of lilo -v -v: # lilo -v -v LILO version 21.4-4, Copyright (C) 1992-1998 Werner Almesberger 'lba32' extensions Copyright (C) 1999,2000 John Coffman Reading boot sector from /dev/sda Merging with /boot/boot.b Secondary loader: 11 sectors. Mapping message file /boot/message Message: 46 sectors. Boot image: /boot/vmlinuz-2.4.6-pre1-xfs-3 Setup length is 9 sectors. Mapped 1607 sectors. Mapping RAM disk /boot/ir-2.4.6-p1-xfs-3.img RAM disk: 1304 sectors. Added 2.4.6-p1-xfs-3 Boot image: /boot/vmlinuz-2.4.6-pre1-xfs-2 Setup length is 9 sectors. Mapped 2274 sectors. Mapping RAM disk /boot/initrd-2.4.6-pre1-xfs-2.img RAM disk: 500 sectors. Added 2.4.6-p1-xfs-2 * boot.backup.when-2.4.6-pre1-xfs-3 exists - no backup copy made. Map file size: 34304 bytes. Writing boot sector. Apparently it requires setting up a serial console to a second machine in order to use kdb, so I am not able to do that at this time. Since it is possible to mount a ramdisk image via loopback, is it also possible to do something similar with a file created from dd of MBR, and debug what it is doing one line at a time? I assume this is too far from human readable to do any good. I'm down to the point where I think I might need to give up on modules, or else ship off dd images of my MBR and initrd for someone to analyze. Very depressing. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Wed Jun 13 20:58:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E3w5A15518 for linux-xfs-outgoing; Wed, 13 Jun 2001 20:58:05 -0700 Received: from sphinx.druber.com (druber-gw.lightband.com [216.129.135.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E3w4P15515 for ; Wed, 13 Jun 2001 20:58:04 -0700 Received: from sphinx.druber.com (sphinx.druber.com [10.0.0.2]) by sphinx.druber.com (Postfix) with ESMTP id 5838686E6; Wed, 13 Jun 2001 23:51:35 -0400 (EDT) Date: Wed, 13 Jun 2001 23:51:35 -0400 (EDT) From: Dan Swartzendruber To: Cc: Subject: Re: XFS/Linux 1.1?? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Jun 2001 jtrostel@connex.com wrote: > XFmail is threaded, does IMAP and is free! i'll check it out, thanks! From owner-linux-xfs@oss.sgi.com Wed Jun 13 21:04:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E44Oh15874 for linux-xfs-outgoing; Wed, 13 Jun 2001 21:04:24 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E44MP15871 for ; Wed, 13 Jun 2001 21:04:23 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f5E44IaJ094113; Wed, 13 Jun 2001 23:04:22 -0500 (CDT) Message-ID: <3B2837BD.AE16A48C@thebarn.com> Date: Wed, 13 Jun 2001 23:04:13 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: stimits@idcomm.com CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <3B26C626.24EC0F20@idcomm.com> <3B26CC5E.6050804@uswest.net> <3B26D839.E6C58E3E@idcomm.com> <3B26DCBB.2289C8FC@sigmastorage.com> <3B26E3DF.1B22B76A@idcomm.com> <3B26EFD1.723327FA@thebarn.com> <3B27E2B5.CB5E4CF6@idcomm.com> <3B281A78.5000809@uswest.net> <3B281DE1.EE4AFC33@idcomm.com> <3B2822F8.4010608@uswest.net> <3B283464.A3667572@idcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "D. Stimits" wrote: > To summarize, things are still failing. When I use modules for scsi, it > is apparent that no ramdisk is being used at all. I have tried > variations of using original mkinitrd, as well as mkinitrd.xfs. I > definitely have a ramdisk that contains the required modules, it just > ignores it. Here is the most recent mkinitrd command: > mkinitrd \ > -v \ > -f \ > --preload pagebuf \ > --preload xfs_support \ > --preload xfs \ > --with=scsi_mod \ > --with=sd_mod \ > --with=aic7xxx \ > /boot/ir-2.4.6-p1-xfs-3.img \ > 2.4.6-pre1-xfs-3 I shouldn't make a difference but I would load the scsi drivers first. > > boot=/dev/sda > map=/boot/map > install=/boot/boot.b > prompt > timeout=50 > message=/boot/message > linear > vga=0x030c > default=2.4.6-p1-xfs-2 > backup=boot.backup.when-2.4.6-pre1-xfs-3 > > # FAILS, uses modules. > image=/boot/vmlinuz-2.4.6-pre1-xfs-3 > label=2.4.6-p1-xfs-3 > initrd=/boot/ir-2.4.6-p1-xfs-3.img > read-only > root=/dev/sda6 > append="noapic ramdisk_size=16000" Why are you booting noapic? When the system boots do you see messages about the ram disk loading? about XFS or Pagebuf messages? scsi controller messages? -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Wed Jun 13 21:12:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E4ClB16516 for linux-xfs-outgoing; Wed, 13 Jun 2001 21:12:47 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E4CkP16511 for ; Wed, 13 Jun 2001 21:12:46 -0700 Received: from [192.168.1.10] (helo=den2) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15AOUp-0008Kh-00; Thu, 14 Jun 2001 16:12:39 +1200 From: "Juha Saarinen" To: "'Russell Cattelan'" , Cc: Subject: RE: mkinitrd, ramdisk failure? Date: Thu, 14 Jun 2001 16:12:16 +1200 Message-ID: <011b01c0f488$328524d0$0a01a8c0@den2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-reply-to: <3B2837BD.AE16A48C@thebarn.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk :: Why are you booting noapic? He's got a problem with the Intel i840 chip set... -- Juha From owner-linux-xfs@oss.sgi.com Wed Jun 13 21:15:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E4FXf17020 for linux-xfs-outgoing; Wed, 13 Jun 2001 21:15:33 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E4FWP17013 for ; Wed, 13 Jun 2001 21:15:32 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip7.idcomm.com [209.60.72.134]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5E4F7l29298 for ; Wed, 13 Jun 2001 22:15:07 -0600 Message-ID: <3B283AA4.28E70443@idcomm.com> Date: Wed, 13 Jun 2001 22:16:36 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <3B26C626.24EC0F20@idcomm.com> <3B26CC5E.6050804@uswest.net> <3B26D839.E6C58E3E@idcomm.com> <3B26DCBB.2289C8FC@sigmastorage.com> <3B26E3DF.1B22B76A@idcomm.com> <3B26EFD1.723327FA@thebarn.com> <3B27E2B5.CB5E4CF6@idcomm.com> <3B281A78.5000809@uswest.net> <3B281DE1.EE4AFC33@idcomm.com> <3B2822F8.4010608@uswest.net> <3B283464.A3667572@idcomm.com> <3B2837BD.AE16A48C@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Russell Cattelan wrote: > > "D. Stimits" wrote: > > > To summarize, things are still failing. When I use modules for scsi, it > > is apparent that no ramdisk is being used at all. I have tried > > variations of using original mkinitrd, as well as mkinitrd.xfs. I > > definitely have a ramdisk that contains the required modules, it just > > ignores it. Here is the most recent mkinitrd command: > > mkinitrd \ > > -v \ > > -f \ > > --preload pagebuf \ > > --preload xfs_support \ > > --preload xfs \ > > --with=scsi_mod \ > > --with=sd_mod \ > > --with=aic7xxx \ > > /boot/ir-2.4.6-p1-xfs-3.img \ > > 2.4.6-pre1-xfs-3 > > I shouldn't make a difference but I would load the scsi drivers first. I tried that variation, didn't work. I know from Walt's post though that the preload above works for at least one person, so I posted this one. > > > > > boot=/dev/sda > > map=/boot/map > > install=/boot/boot.b > > prompt > > timeout=50 > > message=/boot/message > > linear > > vga=0x030c > > default=2.4.6-p1-xfs-2 > > backup=boot.backup.when-2.4.6-pre1-xfs-3 > > > > # FAILS, uses modules. > > image=/boot/vmlinuz-2.4.6-pre1-xfs-3 > > label=2.4.6-p1-xfs-3 > > initrd=/boot/ir-2.4.6-p1-xfs-3.img > > read-only > > root=/dev/sda6 > > append="noapic ramdisk_size=16000" > > Why are you booting noapic? The Intel i840 chipset has broken IO-APIC. It causes a fatal false irq vector 217 into oblivion. I have talked to Alan Cox about this, there is nothing that can be done without Intel, and email to Intel is rejected since I am not a manufacturer or developer of their boards. Note that on i840 boards that do not have 64 bit pci slots, there is only one of these broken IO-APIC's, but on those with 64 bit, two more are added that are connected to the pci. This causes random fatal error on heavy pci use. It is 100% reproducable by simple things such as rapidly mounting and umounting a CD ROM. You'll also notice that Intel does not sell any high end servers with their own i840 chipset, they use ServerWorks. i840 is defective, there is no choice about running without apic. > > When the system boots do you see messages about the ram disk loading? > about XFS or Pagebuf messages? scsi controller messages? No ram disk loading messages. I do not know why. No messages about any of the scsi or XFS or pagebuf stuff at all. If they occur at the very start, right after lilo decompresses the kernel, at the moment when the video mode changes, there is a period of blanking, and I can't see that. But this is only a short part at the start, and I see a lot more. D. Stimits, stimits@idcomm.com > > -- > Russell Cattelan > cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Wed Jun 13 22:12:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E5CQg25218 for linux-xfs-outgoing; Wed, 13 Jun 2001 22:12:26 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E5COP25207 for ; Wed, 13 Jun 2001 22:12:24 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip7.idcomm.com [209.60.72.134]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5E5C0l02180 for ; Wed, 13 Jun 2001 23:12:00 -0600 Message-ID: <3B2847F9.C3022C9F@idcomm.com> Date: Wed, 13 Jun 2001 23:13:29 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: mkinitrd, ramdisk failure? References: <011b01c0f488$328524d0$0a01a8c0@den2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I forgot to send this to all, sorry if you get this twice. Juha Saarinen wrote: > > :: Why are you booting noapic? > > He's got a problem with the Intel i840 chip set... > > -- Juha Yes. And if some people here recall, SuperMicro used to advertise they ran great on Linux, supported it, so on. When I called them and presented them with the information, they replied that it ran fine on NT 4, then removed their Linux support from their web page advertisements. This was also about the time they lost their marketing manager and placed his work load on everyone else...SuperMicro has not since that time supported anything to do with Linux. I even offered to purchase one of their i840 boards as a donation to someone who could work on support outside of their organization if they could give specs to whoever worked on it...they still refused. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Wed Jun 13 22:37:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E5bhC28714 for linux-xfs-outgoing; Wed, 13 Jun 2001 22:37:43 -0700 Received: from sgisrv1.teleworld.at (mail.teleworld.at [212.152.248.30]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E5bgP28705 for ; Wed, 13 Jun 2001 22:37:42 -0700 Received: from teleworld.at (twagw [10.53.77.20]) by sgisrv1.teleworld.at (8.9.3/8.9.3) with ESMTP id HAA29158 for ; Thu, 14 Jun 2001 07:37:17 +0200 (CEST) Message-ID: <3B284D99.908121D2@teleworld.at> Date: Thu, 14 Jun 2001 07:37:29 +0200 From: Gerald Weber X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,de MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: linux 2.4.5 + xfs lockup Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi there, following kernel-oops occoured yesterday night: (ksymoops output) Jun 14 00:14:17 twasrv1 kernel: Unable to handle kernel paging request at virtual address 41a9b2a6 Jun 14 00:14:17 twasrv1 kernel: 41a9b2a6 Jun 14 00:14:17 twasrv1 kernel: *pde = 00000000 Jun 14 00:14:17 twasrv1 kernel: Oops: 0000 Jun 14 00:14:17 twasrv1 kernel: CPU: 1 Jun 14 00:14:17 twasrv1 kernel: EIP: 0010:[pagebuf_locking_terminate+1101639818/-1072693788] Jun 14 00:14:17 twasrv1 kernel: EFLAGS: 00010206 Jun 14 00:14:17 twasrv1 kernel: eax: 00000016 ebx: 08090fc0 ecx: 488d0000 edx: 00000000 Jun 14 00:14:17 twasrv1 kernel: esi: 5cbf8000 edi: 00000000 ebp: cbcd0d2c esp: ca6e9f04 Jun 14 00:14:17 twasrv1 kernel: ds: 0018 es: 0018 ss: 0018 Jun 14 00:14:17 twasrv1 kernel: Process gzip (pid: 21791, stackpage=ca6e9000) Jun 14 00:14:17 twasrv1 kernel: Stack: cbcd0e44 5cbf8000 00000000 d67015e0 00000000 00004000 08090fc0 da268520 Jun 14 00:14:17 twasrv1 kernel: 00000000 d67016ec d06ef820 00000000 c0280f0a ca6e9f88 d67015e0 c27d3260 Jun 14 00:14:17 twasrv1 kernel: c01e378e cbcd0d44 ca6e9f7c 00000000 00000000 00000000 d67015e0 c27d3260 Jun 14 00:14:17 twasrv1 kernel: Call Trace: [ip_rcv+786/920] [linvfs_write+266/324] [sys_write+143/196] [system_call+51/56] [startup_32+43/203] Jun 14 00:14:17 twasrv1 kernel: Code: Bad EIP value. system is a dell poweredge 2450,2 mylex AcceleRAID 352 one of them is serving a raid5 with 300gb. the machine locks up (no net,no sysreq,no console input accepted) kernel is from cvs (2.4.5) regards, gw ps: ...not bad.. xfs check takes only 4 secs for 300gb.i'm impressed... From owner-linux-xfs@oss.sgi.com Wed Jun 13 23:28:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E6SHb03540 for linux-xfs-outgoing; Wed, 13 Jun 2001 23:28:17 -0700 Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E6SFP03534 for ; Wed, 13 Jun 2001 23:28:15 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f5E6RW894586; Thu, 14 Jun 2001 01:27:32 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <3B285950.68ACE779@thebarn.com> Date: Thu, 14 Jun 2001 01:27:28 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: stimits@idcomm.com CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <3B26C626.24EC0F20@idcomm.com> <3B26CC5E.6050804@uswest.net> <3B26D839.E6C58E3E@idcomm.com> <3B26DCBB.2289C8FC@sigmastorage.com> <3B26E3DF.1B22B76A@idcomm.com> <3B26EFD1.723327FA@thebarn.com> <3B27E2B5.CB5E4CF6@idcomm.com> <3B281A78.5000809@uswest.net> <3B281DE1.EE4AFC33@idcomm.com> <3B2822F8.4010608@uswest.net> <3B283464.A3667572@idcomm.com> <3B2837BD.AE16A48C@thebarn.com> <3B283AA4.28E70443@idcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "D. Stimits" wrote > No ram disk loading messages. I do not know why. No messages about any > of the scsi or XFS or pagebuf stuff at all. If they occur at the very > start, right after lilo decompresses the kernel, at the moment when the > video mode changes, there is a period of blanking, and I can't see that. > But this is only a short part at the start, and I see a lot more. > I'm sure this seem like an obvious question but you do have ramdisk and initial ramdisk in compiled into the kernel? -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Thu Jun 14 00:27:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E7RA710140 for linux-xfs-outgoing; Thu, 14 Jun 2001 00:27:10 -0700 Received: from studsv07.studserv.uni-stuttgart.de (studsv07.studserv.uni-stuttgart.de [129.69.21.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E7R7P10134 for ; Thu, 14 Jun 2001 00:27:08 -0700 Received: from ysabell.wh.vaih [129.69.166.244] by studsv07.studserv.uni-stuttgart.de with ESMTP (SMTPD32-6.06) id A74721700A2; Thu, 14 Jun 2001 09:27:03 +0200 Received: from marcelo by ysabell.wh.vaih with local (Exim 3.22 #1 (Debian)) id 15ARWn-0000EC-00; Thu, 14 Jun 2001 09:26:53 +0200 Date: Thu, 14 Jun 2001 09:26:53 +0200 From: "Marcelo E. Magallon" To: "Bryan J. Smith" Cc: linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp Message-ID: <20010614092653.A849@ysabell.wh.vaih> Mail-Followup-To: "Bryan J. Smith" , linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B28144A.5F0C2815@ieee.org> User-Agent: Mutt/1.3.18i X-Operating-System: Linux ysabell 2.4.4-xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> "Bryan J. Smith" writes: > GPL is an IP _protector_, whereas BSD is not. Business interest's protector, among other things, you mean. -- M. From owner-linux-xfs@oss.sgi.com Thu Jun 14 00:27:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E7Rl210311 for linux-xfs-outgoing; Thu, 14 Jun 2001 00:27:47 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E7RlP10308 for ; Thu, 14 Jun 2001 00:27:47 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip11.idcomm.com [209.60.72.138]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5E7RNl11878 for ; Thu, 14 Jun 2001 01:27:23 -0600 Message-ID: <3B2867B2.6F0404B@idcomm.com> Date: Thu, 14 Jun 2001 01:28:50 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <3B26C626.24EC0F20@idcomm.com> <3B26CC5E.6050804@uswest.net> <3B26D839.E6C58E3E@idcomm.com> <3B26DCBB.2289C8FC@sigmastorage.com> <3B26E3DF.1B22B76A@idcomm.com> <3B26EFD1.723327FA@thebarn.com> <3B27E2B5.CB5E4CF6@idcomm.com> <3B281A78.5000809@uswest.net> <3B281DE1.EE4AFC33@idcomm.com> <3B2822F8.4010608@uswest.net> <3B283464.A3667572@idcomm.com> <3B2837BD.AE16A48C@thebarn.com> <3B283AA4.28E70443@idcomm.com> <3B285950.68ACE779@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Russell Cattelan wrote: > > "D. Stimits" wrote > > > No ram disk loading messages. I do not know why. No messages about any > > of the scsi or XFS or pagebuf stuff at all. If they occur at the very > > start, right after lilo decompresses the kernel, at the moment when the > > video mode changes, there is a period of blanking, and I can't see that. > > But this is only a short part at the start, and I see a lot more. > > > > I'm sure this seem like an obvious question but you do have ramdisk and > initial ramdisk in > compiled into the kernel? > > -- > Russell Cattelan > cattelan@thebarn.com Interesting question. Ok, I see the following: Block Devices, Loopback device support, yes RAM disk support, no-brainer-idiot-move-I'm-pounding-my-head-on-wall, No. Sheesh. I still have to test it, but damn...I feel like I locked my keys in the car while giving Bill Gates a compliment. *sounds of loud screaming and blunt force trauma* D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Thu Jun 14 00:39:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E7dCW11590 for linux-xfs-outgoing; Thu, 14 Jun 2001 00:39:12 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E7dAP11581 for ; Thu, 14 Jun 2001 00:39:10 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5E7ceV32059; Thu, 14 Jun 2001 09:38:56 +0200 Message-Id: <4.3.2.7.2.20010614091958.030b5aa0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Jun 2001 09:38:39 +0200 To: Gerald Weber , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: linux 2.4.5 + xfs lockup In-Reply-To: <3B284D99.908121D2@teleworld.at> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 07:37 14-6-2001 +0200, Gerald Weber wrote: >hi there, > >following kernel-oops occoured yesterday night: >(ksymoops output) > >Jun 14 00:14:17 twasrv1 kernel: Unable to handle kernel paging request at >virtual address 41a9b2a6 >Jun 14 00:14:17 twasrv1 kernel: 41a9b2a6 >Jun 14 00:14:17 twasrv1 kernel: *pde = 00000000 >Jun 14 00:14:17 twasrv1 kernel: Oops: 0000 >Jun 14 00:14:17 twasrv1 kernel: CPU: 1 >Jun 14 00:14:17 twasrv1 kernel: EIP: >0010:[pagebuf_locking_terminate+1101639818/-1072693788] >Jun 14 00:14:17 twasrv1 kernel: EFLAGS: 00010206 >Jun 14 00:14:17 twasrv1 kernel: eax: 00000016 ebx: 08090fc0 ecx: >488d0000 >edx: 00000000 >Jun 14 00:14:17 twasrv1 kernel: esi: 5cbf8000 edi: 00000000 ebp: >cbcd0d2c >esp: ca6e9f04 >Jun 14 00:14:17 twasrv1 kernel: ds: 0018 es: 0018 ss: 0018 >Jun 14 00:14:17 twasrv1 kernel: Process gzip (pid: 21791, stackpage=ca6e9000) >Jun 14 00:14:17 twasrv1 kernel: Stack: cbcd0e44 5cbf8000 00000000 d67015e0 >00000000 00004000 08090fc0 da268520 >Jun 14 00:14:17 twasrv1 kernel: 00000000 d67016ec d06ef820 00000000 >c0280f0a ca6e9f88 d67015e0 c27d3260 >Jun 14 00:14:17 twasrv1 kernel: c01e378e cbcd0d44 ca6e9f7c 00000000 >00000000 00000000 d67015e0 c27d3260 >Jun 14 00:14:17 twasrv1 kernel: Call Trace: [ip_rcv+786/920] >[linvfs_write+266/324] [sys_write+143/196] [system_call+51/56] >[startup_32+43/203] >Jun 14 00:14:17 twasrv1 kernel: Code: Bad EIP value. > >system is a dell poweredge 2450,2 mylex AcceleRAID 352 >one of them is serving a raid5 with 300gb. >the machine locks up (no net,no sysreq,no console input accepted) >kernel is from cvs (2.4.5) You mean serving NFS? There is a patch missing in 2.4.5 that makes it barf after longer use. I suggest checking out the newer CVS which is 2.4.6-pre2 based. If you don't want to run the pre kernel pickup the patches for 2.4.5 from the oss.sgi.com ftp server. They have the NFS fix included. Good luck. I've made a torture shell scripts that.. well tortures the the NFS server I use for testing. It starts up a Bonnie for a 100MB file waits 30 seconds and starts another, this will slowly make the number of concurrent Bonnies rise. The server and clients are 2.4.6-pre1 based. The server is a Dell Optiplex PIII 450 with 256MB ram and a 40GB IDE disk. The clients were 2 Dell Poweredge 2450 Servers with dual 733 and also 256MB ram. All was connected to a 100Mbit switch. Both clients ran this test simultaneously. It did not crash the server machine but it was having difficulty keeping (load avg 2) when the number of Bonnies on both servers reached 15. I stopped the test after 30 simultaneous Bonnies on each client. I let the remaining Bonnies complete. The IDE led of the "server" machine was still on more then 2 hours after I stopped the scripts. It seems I was running into IDE limitations on the server side. The stats on the 3Com switch were dropping of when the number of Bonnies on each client went above 15. So this means that the server ran into an IO bottleneck on the server side. The load average during those hours when the Bonnies were completing remained at 6-7. I'm affraid I'll need some heavier equipment to push harder over NFS. >ps: ...not bad.. xfs check takes only 4 secs for 300gb.i'm impressed... That's the cool part. By accident I pulled a 2450 out of the rack for a few centimers but it made the powercords fall out. XFS to the rescue ;-) It's weird, every plug on modern PC's has clips to hold it except the euro power plugs. Damn. I think I'll take some tie-wraps and connect it permanently. Superglue makes a good second. Bye -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Jun 14 00:58:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E7wLQ13641 for linux-xfs-outgoing; Thu, 14 Jun 2001 00:58:21 -0700 Received: from studsv07.studserv.uni-stuttgart.de (studsv07.studserv.uni-stuttgart.de [129.69.21.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E7wJP13634 for ; Thu, 14 Jun 2001 00:58:19 -0700 Received: from ysabell.wh.vaih [129.69.166.244] by studsv07.studserv.uni-stuttgart.de with ESMTP (SMTPD32-6.06) id AE9A29ED0096; Thu, 14 Jun 2001 09:58:18 +0200 Received: from marcelo by ysabell.wh.vaih with local (Exim 3.22 #1 (Debian)) id 15AS12-0000F0-00 for ; Thu, 14 Jun 2001 09:58:08 +0200 Date: Thu, 14 Jun 2001 09:58:08 +0200 From: "Marcelo E. Magallon" To: linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp Message-ID: <20010614095808.B849@ysabell.wh.vaih> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B28152A.9FC9E865@thebarn.com> User-Agent: Mutt/1.3.18i X-Operating-System: Linux ysabell 2.4.4-xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> Russell Cattelan writes: > What you are saying all of the non GPL'ed linux kernel modules are in > violation of the GPL?! One of the main copyright holders has said that it is ok to "link" the GPLed code with code under a license that conflicts with the GPL. Other copyright holders have not said they are against this, but any of them can say so. With the Linux kernel everyone is acting in good faith. > Guess somebody better stick some lawyers on Nvidia. As an individual, you can't distribute NVIDIA's drivers in any form (unless they have changed the license drastically lately, but I'm sure they haven't). Once you get NVIDIA's permission to do so, you can distribute the drivers. NVIDIA provides source to some parts of the kernel module because it's easier for them that way, not because they have to. As an individual, you can you do whatever you want on the privacy of your own computer. If people bothered to read the GPL (or any other license for that matter) they would notice it's a *distribution* license, not a use license. You can modify a GPLed program as much as you want, you can use pieces of it in your own code, you can link it with whatever you want, and it's all ok as long as it doesn't leave your computer (and *please* let's not enter a discussion regarding what "leaving the computer" means, this is off topic enough already) > Ohh and explain this problem to Linus also. Linus has given his own interpretation of what the user can and can't do (distribution wise). He is free to do so as copyright holder (in the same way SGI is free to "clarify" what the GPL means according to their lawyers -- everyone here knows that SGI has provided an interpretation regarding a couple of points of the GPL, right?). This doesn't mean he is right wrt what the GPL allows you to do or not. > > Sun Solaris was just an example. The number of "threats" to SGI's > > IP would be a lot greater than you think if they released XFS as BSD > > licensed. > > Ohh?! like how... Is that a serious question? By providing the XFS code under a license not as loose as the BSD one, SGI is ensuring they keep some degree of control regarding what the competition can and can't do. HP can take the Linux kernel, include the XFS patches and distribute it with the shiny Itanium servers, and it's all ok (funny, this sounds a lot like what SGI wants to do, too). Along the same line of thought, Sun can take the XFS code, patch it to get it to run with Solaris (probably modifying Solaris a bit at the same time) and distribute that (not as part of the Solaris kernel, but as a loadable module). This is probably not ok according to the GPL (this is not the same as a GPLed program linked with the vendor's libc, this is linking GPLed code inside kernel space) and it probably requires permission from SGI to distribute. At any rate, iff SGI is ok with this, and say, Sun finds a way to make XFS run ten times as fast, they *have* to give the source to the people that get the binary module, and SGI can get the modifications back. Honestly, it can't get simpler than that. In the context of large projects with a large interested audience, the BSD license is business wonderland for the people *getting* the code, not for the people writing it. I would have thought that people doing consulting work would understand this without further explanation. But yes, "threats" is a bit off the scale. -- Marcelo From owner-linux-xfs@oss.sgi.com Thu Jun 14 01:07:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E87cq14858 for linux-xfs-outgoing; Thu, 14 Jun 2001 01:07:38 -0700 Received: from studsv07.studserv.uni-stuttgart.de (studsv07.studserv.uni-stuttgart.de [129.69.21.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E87aP14847 for ; Thu, 14 Jun 2001 01:07:37 -0700 Received: from ysabell.wh.vaih [129.69.166.244] by studsv07.studserv.uni-stuttgart.de with ESMTP (SMTPD32-6.06) id A0C72A090096; Thu, 14 Jun 2001 10:07:35 +0200 Received: from marcelo by ysabell.wh.vaih with local (Exim 3.22 #1 (Debian)) id 15ASAB-0000Fe-00 for ; Thu, 14 Jun 2001 10:07:35 +0200 Date: Thu, 14 Jun 2001 10:07:35 +0200 From: "Marcelo E. Magallon" To: linux-xfs@oss.sgi.com Subject: Re: Interest from the FreeBSD camp Message-ID: <20010614100735.C849@ysabell.wh.vaih> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10546.992485751@kao2.melbourne.sgi.com> User-Agent: Mutt/1.3.18i X-Operating-System: Linux ysabell 2.4.4-xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> Keith Owens writes: > Nvidia cheat on this. Their loadable module is supplied in source form > and is GPL. I don't know where people is getting this from, but this doesn't look like the GPL to me: /***************************************************************************\ |* *| |* Copyright 1993-2000 NVIDIA, Corporation. All rights reserved. *| |* *| |* NOTICE TO USER: The source code is copyrighted under U.S. and *| |* international laws. Users and possessors of this source code are *| |* hereby granted a nonexclusive, royalty-free copyright license to *| |* use this code in individual and commercial software. *| |* *| |* Any use of this source code must include, in the user documenta- *| |* tion and internal comments to the code, notices to the end user *| |* as follows: *| |* *| |* Copyright 1993-2000 NVIDIA, Corporation. All rights reserved. *| |* *| |* NVIDIA, CORPORATION MAKES NO REPRESENTATION ABOUT THE SUITABILITY *| |* OF THIS SOURCE CODE FOR ANY PURPOSE. IT IS PROVIDED "AS IS" *| |* WITHOUT EXPRESS OR IMPLIED WARRANTY OF ANY KIND. NVIDIA, CORPOR- *| |* ATION DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOURCE CODE, *| |* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGE- *| |* MENT, AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL *| |* NVIDIA, CORPORATION BE LIABLE FOR ANY SPECIAL, INDIRECT, INCI- *| |* DENTAL, OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RE- *| |* SULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION *| |* OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF *| |* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOURCE CODE. *| |* *| |* U.S. Government End Users. This source code is a "commercial *| |* item," as that term is defined at 48 C.F.R. 2.101 (OCT 1995), *| |* consisting of "commercial computer software" and "commercial *| |* computer software documentation," as such terms are used in *| |* 48 C.F.R. 12.212 (SEPT 1995) and is provided to the U.S. Govern- *| |* ment only as a commercial end item. Consistent with 48 C.F.R. *| |* 12.212 and 48 C.F.R. 227.7202-1 through 227.7202-4 (JUNE 1995), *| |* all U.S. Government End Users acquire the source code with only *| |* those rights set forth herein. *| |* *| \***************************************************************************/ In particular, note this doesn't say distribute. (And I'm not in the mood to download their click-thru license, but it basically says you can "use" the drivers. Period) -- M. From owner-linux-xfs@oss.sgi.com Thu Jun 14 02:01:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E91kR19612 for linux-xfs-outgoing; Thu, 14 Jun 2001 02:01:46 -0700 Received: from studsv07.studserv.uni-stuttgart.de (studsv07.studserv.uni-stuttgart.de [129.69.21.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E91jP19597 for ; Thu, 14 Jun 2001 02:01:45 -0700 Received: from ysabell.wh.vaih [129.69.166.244] by studsv07.studserv.uni-stuttgart.de with ESMTP (SMTPD32-6.06) id AD744B79005C; Thu, 14 Jun 2001 11:01:40 +0200 Received: from marcelo by ysabell.wh.vaih with local (Exim 3.22 #1 (Debian)) id 15AT0S-0000H3-00; Thu, 14 Jun 2001 11:01:36 +0200 Date: Thu, 14 Jun 2001 11:01:36 +0200 From: "Marcelo E. Magallon" To: Seth Mos Cc: Gerald Weber , linux-xfs@oss.sgi.com Subject: Re: linux 2.4.5 + xfs lockup Message-ID: <20010614110136.A1036@ysabell.wh.vaih> Mail-Followup-To: Seth Mos , Gerald Weber , linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20010614091958.030b5aa0@pop.xs4all.nl> User-Agent: Mutt/1.3.18i X-Operating-System: Linux ysabell 2.4.4-xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> Seth Mos writes: > I've made a torture shell scripts that.. well tortures the the NFS > server I use for testing. It starts up a Bonnie for a 100MB file > waits 30 seconds and starts another, this will slowly make the number > of concurrent Bonnies rise. Hmm... interesting. I might give that a try. Ever since moving the RAID to the SGI server I haven't been able to reproduce the oopses I had, and now that this one test machine doesn't have anymore SCSI discs on it, I might figure out if that was an XFS-NFS problem or not... > That's the cool part. By accident I pulled a 2450 out of the rack for > a few centimers but it made the powercords fall out. XFS to the > rescue ;-) It's weird, every plug on modern PC's has clips to hold it > except the euro power plugs. On the machine side, you mean? On the "wall" side, european (well, German) are the weirdest things I've ever seen. You practically have to say aloud "yes, I want to pull this plug out" to actually do it. On the machine side they seem quite unusual to me (at least they are the same ones I've seen on the other side of the Atlantic, north hemispehre) -- Marcelo, cursing weird hollydays... From owner-linux-xfs@oss.sgi.com Thu Jun 14 02:07:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E97MI20392 for linux-xfs-outgoing; Thu, 14 Jun 2001 02:07:22 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E97LP20389 for ; Thu, 14 Jun 2001 02:07:21 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip28.idcomm.com [209.60.72.155]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5E96wl18048 for ; Thu, 14 Jun 2001 03:06:58 -0600 Message-ID: <3B287F0C.D6B1D4E@idcomm.com> Date: Thu, 14 Jun 2001 03:08:28 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <3B26A5DD.1BAAA1A5@idcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Things are finally very close to working. The obvious failure, to include initial ramdisk support, had not been checked (this is something I *always* include, so I didn't double-check...wouldn't you know, famous last words). Now I am however getting what is probably a scsi error, and less likely XFS...I'm not sure though. What I see is that it starts to load fine, then gets to: SCSI subsystem driver Revision: 1.00 kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2 spurious 8259A interrupt: IRQ7. At this point it goes on and runs the single aic7xxx ultra160 driver just fine. When I run without modules, scsi (single channel controller) is set to IRQ 10. Does anyone here with aic7xxx, especially if ultra 160, provide module parameters, or do you just use the modules however they default? D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Thu Jun 14 02:30:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E9U9Z22569 for linux-xfs-outgoing; Thu, 14 Jun 2001 02:30:09 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E9U7P22558 for ; Thu, 14 Jun 2001 02:30:08 -0700 Received: (qmail 29132 invoked from network); 14 Jun 2001 09:30:03 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 14 Jun 2001 09:30:02 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: stimits@idcomm.com cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? In-reply-to: Your message of "Thu, 14 Jun 2001 03:08:28 CST." <3B287F0C.D6B1D4E@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Jun 2001 18:53:45 +1000 Message-ID: <15040.992508825@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 14 Jun 2001 03:08:28 -0600, "D. Stimits" wrote: >Now I am however getting what is probably a scsi error, and less likely >XFS...I'm not sure though. What I see is that it starts to load fine, >then gets to: >SCSI subsystem driver Revision: 1.00 >kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2 >spurious 8259A interrupt: IRQ7. kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2 is no such file or directory. Your initrd does not contain /sbin/modprobe, initrd normally only contains insmod to save space. You compiled the kernel for automatic loading (kmod) which expects modprobe. As long as you load a SCSI host adaptor yourself during initrd startup, you can ignore this message. spurious 8259A interrupt: IRQ7. is a little more puzzling. The system got an interrupt on irq 7 but nothing was assigned to that irq. 7 is usually line printer, although it could have been assigned to another device. In any cause it is definitely nothing to do with XFS, it might not even be SCSI related. Ask on linux-kernel and include the chipset data and PCI routing information from the start of the boot log. From owner-linux-xfs@oss.sgi.com Thu Jun 14 02:36:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5E9aFP23376 for linux-xfs-outgoing; Thu, 14 Jun 2001 02:36:15 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5E9aDP23373 for ; Thu, 14 Jun 2001 02:36:13 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5E9a9V32694; Thu, 14 Jun 2001 11:36:10 +0200 Message-Id: <4.3.2.7.2.20010614112144.032e0538@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Jun 2001 11:36:07 +0200 To: "Marcelo E. Magallon" From: Seth Mos Subject: Re: linux 2.4.5 + xfs lockup Cc: Gerald Weber , linux-xfs@oss.sgi.com In-Reply-To: <20010614110136.A1036@ysabell.wh.vaih> References: <4.3.2.7.2.20010614091958.030b5aa0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:01 14-6-2001 +0200, Marcelo E. Magallon wrote: > >> Seth Mos writes: > > > I've made a torture shell scripts that.. well tortures the the NFS > > server I use for testing. It starts up a Bonnie for a 100MB file > > waits 30 seconds and starts another, this will slowly make the number > > of concurrent Bonnies rise. > > Hmm... interesting. I might give that a try. Ever since moving the > RAID to the SGI server I haven't been able to reproduce the oopses I > had, and now that this one test machine doesn't have anymore SCSI discs > on it, I might figure out if that was an XFS-NFS problem or not... #!/bin/sh stress() { Bonnie -s 100 2>/dev/null >/dev/null & sleep 1 ps ax|grep Bonnie|grep -v grep|wc -l sleep 30 } while true;do stress done > > That's the cool part. By accident I pulled a 2450 out of the rack for > > a few centimers but it made the powercords fall out. XFS to the > > rescue ;-) It's weird, every plug on modern PC's has clips to hold it > > except the euro power plugs. > > On the machine side, you mean? On the "wall" side, european (well, > German) are the weirdest things I've ever seen. You practically have > to say aloud "yes, I want to pull this plug out" to actually do it. On > the machine side they seem quite unusual to me (at least they are the > same ones I've seen on the other side of the Atlantic, north > hemispehre) Yes on the machine side. I know that the power plugs for the wall side differ between various countrys in the EU but in this case it is a power cord going from the UPS to the server. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Jun 14 09:04:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EG4gR03219 for linux-xfs-outgoing; Thu, 14 Jun 2001 09:04:42 -0700 Received: from sender.ngi.de (sender.ngi.de [212.79.47.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EG4eP03216 for ; Thu, 14 Jun 2001 09:04:41 -0700 Received: from hnvr-3e36d65a.pool.mediaWays.net (hnvr-3e36d65a.pool.mediaWays.net [62.54.214.90]) by sender.ngi.de (Postfix) with ESMTP id 5407996D11 for ; Thu, 14 Jun 2001 17:47:25 +0200 (CEST) Date: Thu, 14 Jun 2001 18:04:03 +0200 From: Sebastian Ude To: linux-xfs@oss.sgi.com Subject: Blocksizes Reply-To: ude@handshake.de X-Mailer: Spruce 0.7.6 for X11 w/smtpio 0.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20010614154725.5407996D11@sender.ngi.de> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Does XFS for Linux still only support blocksizes equal to a pagesize (4096 bytes / 4k on ix86) ? If yes, are there plans to work on this problem ? Regards, Sebastian Ude From owner-linux-xfs@oss.sgi.com Thu Jun 14 09:10:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EGABC03410 for linux-xfs-outgoing; Thu, 14 Jun 2001 09:10:11 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EGABP03407 for ; Thu, 14 Jun 2001 09:10:11 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA02284 for ; Thu, 14 Jun 2001 09:10:10 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA2155641; Thu, 14 Jun 2001 11:08:54 -0500 (CDT) Received: from sgi.com (eagdhcp-195-22.americas.sgi.com [128.162.195.178]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA35890; Thu, 14 Jun 2001 11:08:54 -0500 (CDT) Message-ID: <3B28D384.9A10753C@sgi.com> Date: Thu, 14 Jun 2001 10:08:52 -0500 From: sandeen@sgi.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ude@handshake.de CC: linux-xfs@oss.sgi.com Subject: Re: Blocksizes References: <20010614154725.5407996D11@sender.ngi.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sebastian Ude wrote: > > Does XFS for Linux still only support blocksizes equal to a pagesize (4096 > bytes / 4k on ix86) ? Yes > If yes, are there plans to work on this problem ? Yes, it is on the TODO list, but I'm afraid I can't really give you a good idea of when it might be done... -Eric From owner-linux-xfs@oss.sgi.com Thu Jun 14 09:13:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EGDwN03587 for linux-xfs-outgoing; Thu, 14 Jun 2001 09:13:58 -0700 Received: from washington.intcafe.net (eu1.st74-net74.ip.superonlinecorporate.com [213.74.74.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EGDlP03574 for ; Thu, 14 Jun 2001 09:13:56 -0700 Received: from [172.16.0.4] by washington.solmaz.com.tr (NTMail 3.03.0018/42.aaaj) with ESMTP id ya968758 for ; Thu, 14 Jun 2001 19:11:37 +0100 Message-ID: <013b01c0f4ec$b39fd6f0$040010ac@tarkane> From: "Tarkan Erimer" To: "Andrew Gildfind" Cc: References: <005a01c0f41e$a2cc7b40$040010ac@tarkane> <14493.992449545@ocs4.ocs-net> <20010614091857.P8175@fudge.melbourne.sgi.com> Subject: Re: ACL Support Date: Thu, 14 Jun 2001 19:11:42 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In my opinion, Journaling File system and ACL support is one of the primary key to the road of highend server arena for Linux. I think, we will see XFS and ACL merged kernels around 2.5 cycle very soon. ----- Original Message ----- From: Andrew Gildfind To: Keith Owens Cc: Tarkan Erimer ; Sent: Thursday, June 14, 2001 2:18 AM Subject: Re: ACL Support On Thu, Jun 14, 2001 at 02:25:45AM +1000, Keith Owens wrote: > On Wed, 13 Jun 2001 18:36:38 +0300, > "Tarkan Erimer" wrote: > >I have a question about ACL support. Only installing XFS into the Linux > >kernel enough to get support ACLs? Or Is there any > >need to install ACL kernel patches found at http://acl.bestbits.at/ ? > > There are at least two groups working on ACLs for Linux and they > disagree about how they should be implemented. SGI has one > implementation of ACL, included in the XFS patch. Andreas Grünbacher's > ACLs are different and will not work with XFS. > To clarify that, we don't disagree at all, we're gradually working towards a common implementation. Things have moved slowly, but we have a friendly relationship with the ext2 people, and in due course we want to merge our efforts. Hopefully there will be more visible progress in the next couple of months. Andrew -- Andrew Gildfind - R&D Software Engineer - SGI Melbourne Australia email: ajag@sgi.com - work: +61.3.9834.8200 mobile: 0412.834.183 From owner-linux-xfs@oss.sgi.com Thu Jun 14 09:17:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EGHGw03795 for linux-xfs-outgoing; Thu, 14 Jun 2001 09:17:16 -0700 Received: from washington.intcafe.net (eu1.st74-net74.ip.superonlinecorporate.com [213.74.74.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EGHEP03792 for ; Thu, 14 Jun 2001 09:17:14 -0700 Received: from [172.16.0.4] by washington.solmaz.com.tr (NTMail 3.03.0018/42.aaaj) with ESMTP id aa968760 for ; Thu, 14 Jun 2001 19:15:08 +0100 Message-ID: <014101c0f4ed$30ebcc40$040010ac@tarkane> From: "Tarkan Erimer" To: Cc: References: Subject: Re: ACL Support Date: Thu, 14 Jun 2001 19:15:13 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks for your very help. I will install XFS to my Linux box as soon as possible. By the way, when will we see the next release of XFS ? ----- Original Message ----- From: To: Sebastian Dransfeld Cc: ; Tarkan Erimer Sent: Wednesday, June 13, 2001 7:32 PM Subject: Re: ACL Support > You need to install the components in the ../cmd/acl directory also for acl > support. This will create the libacl.a library and the userspace tools needed > to control and view the ACLs > > On 13-Jun-2001 Sebastian Dransfeld wrote: > > On Wed, 13 Jun 2001, Tarkan Erimer wrote: > > > >> Hi, > >> > >> I have a question about ACL support. Only installing XFS into the Linux > >> kernel enough to get support ACLs? Or Is there any > >> need to install ACL kernel patches found at http://acl.bestbits.at/ ? > >> Thanks for your very help.. > > > > No need, ACL is in the XFS kernel. > > > > seb > > -- > John M. Trostel > Linux OS Engineer > Connex > jtrostel@connex.com From owner-linux-xfs@oss.sgi.com Thu Jun 14 10:18:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EHI2R06123 for linux-xfs-outgoing; Thu, 14 Jun 2001 10:18:02 -0700 Received: from sender.ngi.de (sender.ngi.de [212.79.47.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EHI1P06120 for ; Thu, 14 Jun 2001 10:18:01 -0700 Received: from hnvr-3e36d635.pool.mediaWays.net (hnvr-3e36d635.pool.mediaWays.net [62.54.214.53]) by sender.ngi.de (Postfix) with ESMTP id 08CB896D14 for ; Thu, 14 Jun 2001 19:00:47 +0200 (CEST) Date: Thu, 14 Jun 2001 19:17:26 +0200 From: Sebastian Ude To: linux-xfs@oss.sgi.com Subject: Re: Blocksizes Reply-To: ude@handshake.de In-Reply-To: <3B28D384.9A10753C@sgi.com> References: <3B28D384.9A10753C@sgi.com> X-Mailer: Spruce 0.7.6 for X11 w/smtpio 0.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20010614170047.08CB896D14@sender.ngi.de> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 14 Jun 2001, sandeen@sgi.com wrote: > Date: Thu, 14 Jun 2001 10:08:52 -0500 > To: ude@handshake.de > From: sandeen@sgi.com > CC: linux-xfs@oss.sgi.com > Subject: Re: Blocksizes > > Sebastian Ude wrote: > > > > Does XFS for Linux still only support blocksizes equal > > to a pagesize (4096 bytes / 4k on ix86) ? > > Yes > > > If yes, are there plans to work on this problem ? > > Yes, it is on the TODO list, but I'm afraid I can't > really give you a good idea of when it might be done... > > -Eric Okay, thanks for the answer. Keep up the great work ! From owner-linux-xfs@oss.sgi.com Thu Jun 14 12:04:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EJ4lR08975 for linux-xfs-outgoing; Thu, 14 Jun 2001 12:04:47 -0700 Received: from hood.tvd.be (hood.tvd.be [195.162.196.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EJ4iP08969 for ; Thu, 14 Jun 2001 12:04:44 -0700 Received: from chello.be (IDENT:airborne@cable-195-162-217-222.upc.chello.be [195.162.217.222]) by hood.tvd.be (8.9.3/8.9.3/RELAY-1.1) with ESMTP id VAA27968 for ; Thu, 14 Jun 2001 21:04:41 +0200 (MET DST) Message-ID: <3B290BA1.78A041C@chello.be> Date: Thu, 14 Jun 2001 21:08:17 +0200 From: Kris Verbeeck X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.5-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: kernel.h Content-Type: multipart/mixed; boundary="------------3D5D291D85DBEA30B1785105" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------3D5D291D85DBEA30B1785105 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, 1) After booting a linux 2.4.5 kernel with XFS support the kernel.h file contains the following lines: /* Kernel type package kernel2.4.5-xfs-2.4.5-xfs is not installed2.4.5-xfs */ #ifndef __MODULE_KERNEL_package kernel2.4.5-xfs-2.4.5-xfs is not installed #define __MODULE_KERNEL_package kernel2.4.5-xfs-2.4.5-xfs is not installed 1 #endif Why are they in there? They are not valid C code. 2) Another problem I have is when I want to recompile the NVidia kernel module for my GeForce 2 graphics adapter with this new patched kernel. I get a lot of errors, where before with the unpatched kernel everything went alright. A log of the make output is attached to this mail. Any ideas on this? Haven't found anything in the FAQ's of either XFS or NVidia about this. BTW: I had a similar problem with a 2.4.2 kernel, so it is not the actual kernel version that is the problem. thx in advance --------------3D5D291D85DBEA30B1785105 Content-Type: text/plain; charset=us-ascii; name="nvidia_make.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="nvidia_make.log" rm -f nv.o os-interface.o os-registry.o Module-linux NVdriver cc -c -Wall -Wno-unknown-pragmas -Wno-multichar -O -D__KERNEL__ -DMODULE -D_LOOSE_KERNEL_NAMES -D_X86_=1 -Di386=1 -DUNIX -DLINUX -DNV4_HW -DNTRM -DRM20 -D_GNU_SOURCE -DRM_HEAPMGR -D_LOOSE_KERNEL_NAMES -DNV_MAJOR_VERSION=1 -DNV_MINOR_VERSION=0 -DNV_PATCHLEVEL=1251 -I. -I/lib/modules/2.4.5-xfs/build/include nv.c In file included from /lib/modules/2.4.5-xfs/build/include/linux/fs.h:19, from nv-linux.h:54, from nv.c:55: /lib/modules/2.4.5-xfs/build/include/linux/dcache.h: In function `dget': /lib/modules/2.4.5-xfs/build/include/linux/dcache.h:244: warning: implicit declaration of function `printk_R1b7d4074' In file included from /lib/modules/2.4.5-xfs/build/include/asm/semaphore.h:39, from /lib/modules/2.4.5-xfs/build/include/linux/fs.h:208, from nv-linux.h:54, from nv.c:55: /lib/modules/2.4.5-xfs/build/include/asm/system.h: At top level: /lib/modules/2.4.5-xfs/build/include/asm/system.h:12: parse error before `(' In file included from /lib/modules/2.4.5-xfs/build/include/linux/rwsem.h:27, from /lib/modules/2.4.5-xfs/build/include/asm/semaphore.h:42, from /lib/modules/2.4.5-xfs/build/include/linux/fs.h:208, from nv-linux.h:54, from nv.c:55: /lib/modules/2.4.5-xfs/build/include/asm/rwsem.h:46: parse error before `(' /lib/modules/2.4.5-xfs/build/include/asm/rwsem.h:47: parse error before `(' /lib/modules/2.4.5-xfs/build/include/asm/rwsem.h:48: parse error before `(' In file included from nv-linux.h:54, from nv.c:55: /lib/modules/2.4.5-xfs/build/include/linux/fs.h:1105: parse error before `(' /lib/modules/2.4.5-xfs/build/include/linux/fs.h:1106: parse error before `(' /lib/modules/2.4.5-xfs/build/include/linux/fs.h: In function `mark_buffer_dirty_inode': /lib/modules/2.4.5-xfs/build/include/linux/fs.h:1128: warning: implicit declaration of function `mark_buffer_dirty_Rfa70e3d1' In file included from /lib/modules/2.4.5-xfs/build/include/linux/mm.h:4, from /lib/modules/2.4.5-xfs/build/include/linux/poll.h:10, from nv-linux.h:55, from nv.c:55: /lib/modules/2.4.5-xfs/build/include/linux/sched.h: At top level: /lib/modules/2.4.5-xfs/build/include/linux/sched.h:151: parse error before `(' In file included from /lib/modules/2.4.5-xfs/build/include/linux/mm.h:4, from /lib/modules/2.4.5-xfs/build/include/linux/poll.h:10, from nv-linux.h:55, from nv.c:55: /lib/modules/2.4.5-xfs/build/include/linux/sched.h:549: parse error before `(' /lib/modules/2.4.5-xfs/build/include/linux/sched.h:550: parse error before `(' /lib/modules/2.4.5-xfs/build/include/linux/sched.h:551: parse error before `(' /lib/modules/2.4.5-xfs/build/include/linux/sched.h:552: parse error before `(' /lib/modules/2.4.5-xfs/build/include/linux/sched.h:554: parse error before `(' /lib/modules/2.4.5-xfs/build/include/linux/sched.h:555: parse error before `(' /lib/modules/2.4.5-xfs/build/include/linux/sched.h:557: parse error before `(' /lib/modules/2.4.5-xfs/build/include/linux/sched.h:719: parse error before `(' /lib/modules/2.4.5-xfs/build/include/linux/sched.h: In function `mmdrop': /lib/modules/2.4.5-xfs/build/include/linux/sched.h:723: warning: implicit declaration of function `__mmdrop' /lib/modules/2.4.5-xfs/build/include/linux/sched.h: At top level: /lib/modules/2.4.5-xfs/build/include/linux/sched.h:755: parse error before `(' /lib/modules/2.4.5-xfs/build/include/linux/sched.h:756: parse error before `(' /lib/modules/2.4.5-xfs/build/include/linux/sched.h:757: parse error before `(' In file included from /lib/modules/2.4.5-xfs/build/include/linux/poll.h:10, from nv-linux.h:55, from nv.c:55: /lib/modules/2.4.5-xfs/build/include/linux/mm.h:341: parse error before `(' /lib/modules/2.4.5-xfs/build/include/linux/mm.h: In function `alloc_pages': /lib/modules/2.4.5-xfs/build/include/linux/mm.h:352: warning: implicit declaration of function `__alloc_pages_Rd96c2cef' /lib/modules/2.4.5-xfs/build/include/linux/mm.h:352: warning: return makes pointer from integer without a cast /lib/modules/2.4.5-xfs/build/include/linux/mm.h: At top level: /lib/modules/2.4.5-xfs/build/include/linux/mm.h:360: parse error before `(' /lib/modules/2.4.5-xfs/build/include/linux/mm.h:361: parse error before `(' /lib/modules/2.4.5-xfs/build/include/linux/mm.h:377: parse error before `(' /lib/modules/2.4.5-xfs/build/include/linux/mm.h:378: parse error before `(' /lib/modules/2.4.5-xfs/build/include/linux/mm.h:399: parse error before `(' /lib/modules/2.4.5-xfs/build/include/linux/mm.h:400: parse error before `(' /lib/modules/2.4.5-xfs/build/include/linux/mm.h: In function `pmd_alloc': /lib/modules/2.4.5-xfs/build/include/linux/mm.h:415: warning: implicit declaration of function `__pmd_alloc' /lib/modules/2.4.5-xfs/build/include/linux/mm.h:415: warning: return makes pointer from integer without a cast /lib/modules/2.4.5-xfs/build/include/linux/mm.h: At top level: /lib/modules/2.4.5-xfs/build/include/linux/mm.h:428: warning: `struct sysinfo' declared inside parameter list /lib/modules/2.4.5-xfs/build/include/linux/mm.h:428: warning: its scope is only this definition or declaration, which is probably not what you want. In file included from /lib/modules/2.4.5-xfs/build/include/linux/irq.h:57, from /lib/modules/2.4.5-xfs/build/include/asm/hardirq.h:6, from /lib/modules/2.4.5-xfs/build/include/linux/interrupt.h:45, from nv.c:69: /lib/modules/2.4.5-xfs/build/include/asm/hw_irq.h:79: parse error before `(' nv.c:290: parse error before `va_list' nv.c: In function `NV_iMSG': nv.c:298: `kernel_message_level' undeclared (first use in this function) nv.c:298: (Each undeclared identifier is reported only once nv.c:298: for each function it appears in.) nv.c:299: warning: implicit declaration of function `sprintf_R3c2c5af5' nv.c:301: `nv' undeclared (first use in this function) nv.c:309: warning: implicit declaration of function `vsprintf_R954cbb26' nv.c:309: `printf_format' undeclared (first use in this function) nv.c:309: `arglist' undeclared (first use in this function) nv.c: In function `NV_iDMSG': nv.c:320: `va_list' undeclared (first use in this function) nv.c:320: parse error before `arglist' nv.c:322: warning: implicit declaration of function `va_start' nv.c:322: `arglist' undeclared (first use in this function) nv.c:323: `KERN_INFO' undeclared (first use in this function) nv.c:324: warning: implicit declaration of function `va_end' nv.c: In function `NV_EMSG': nv.c:333: `va_list' undeclared (first use in this function) nv.c:333: parse error before `arglist' nv.c:335: `arglist' undeclared (first use in this function) nv.c:336: `KERN_ERR' undeclared (first use in this function) nv.c: In function `nvos_malloc': nv.c:699: warning: implicit declaration of function `__get_free_pages_R5b3b8f78' nv.c:724: warning: implicit declaration of function `free_pages_R234535e0' nv.c: In function `nv_kern_close': nv.c:1295: warning: implicit declaration of function `schedule_timeout_R17d59d01' nv.c: In function `nv_post_event': nv.c:2371: warning: implicit declaration of function `__wake_up_R2c77a2af' make: *** [nv.o] Error 1 --------------3D5D291D85DBEA30B1785105-- From owner-linux-xfs@oss.sgi.com Thu Jun 14 12:12:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EJC7s09397 for linux-xfs-outgoing; Thu, 14 Jun 2001 12:12:07 -0700 Received: from sphinx.druber.com (druber-gw.lightband.com [216.129.135.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EJC5P09394 for ; Thu, 14 Jun 2001 12:12:05 -0700 Received: from sphinx.druber.com (sphinx.druber.com [10.0.0.2]) by sphinx.druber.com (Postfix) with ESMTP id CD87786E3; Thu, 14 Jun 2001 15:05:35 -0400 (EDT) Date: Thu, 14 Jun 2001 15:05:35 -0400 (EDT) From: Dan Swartzendruber To: Kris Verbeeck Cc: Subject: Re: kernel.h In-Reply-To: <3B290BA1.78A041C@chello.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 14 Jun 2001, Kris Verbeeck wrote: > Hi, > > 1) After booting a linux 2.4.5 kernel with XFS support the > kernel.h file contains the following lines: > > /* Kernel type package kernel2.4.5-xfs-2.4.5-xfs is not > installed2.4.5-xfs */ > > #ifndef __MODULE_KERNEL_package kernel2.4.5-xfs-2.4.5-xfs is not > installed > #define __MODULE_KERNEL_package kernel2.4.5-xfs-2.4.5-xfs is not > installed 1 > #endif > > Why are they in there? They are not valid C code. it's bad practice, but harmless - self-documenting. > 2) Another problem I have is when I want to recompile the > NVidia kernel module for my GeForce 2 graphics adapter with > this new patched kernel. I get a lot of errors, where before > with the unpatched kernel everything went alright. A log > of the make output is attached to this mail. > > Any ideas on this? Haven't found anything in the FAQ's of > either XFS or NVidia about this. bad module versioning. this is one of the reasons the first thing i do in a kernel config is to disable module version checking. From owner-linux-xfs@oss.sgi.com Thu Jun 14 13:05:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EK5Ea14905 for linux-xfs-outgoing; Thu, 14 Jun 2001 13:05:14 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EK5DP14901 for ; Thu, 14 Jun 2001 13:05:13 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip85.idcomm.com [209.60.72.212] (may be forged)) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5EK4rl22243 for ; Thu, 14 Jun 2001 14:04:53 -0600 Message-ID: <3B29193B.4E1125D9@idcomm.com> Date: Thu, 14 Jun 2001 14:06:19 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <15040.992508825@ocs3.ocs-net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > > On Thu, 14 Jun 2001 03:08:28 -0600, > "D. Stimits" wrote: > >Now I am however getting what is probably a scsi error, and less likely > >XFS...I'm not sure though. What I see is that it starts to load fine, > >then gets to: > >SCSI subsystem driver Revision: 1.00 > >kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2 > >spurious 8259A interrupt: IRQ7. > > kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2 > is no such file or directory. Your initrd does not contain > /sbin/modprobe, initrd normally only contains insmod to save space. > You compiled the kernel for automatic loading (kmod) which expects > modprobe. As long as you load a SCSI host adaptor yourself during > initrd startup, you can ignore this message. Interesting that it is not there. Wouldn't modprobe be normal on mkinitrd? Since I can do this to view an initial ramdisk on loopback: gzip -dc your.img > somefile mount -o loop somefile somedir I wonder if there is a way I can do a reverse of this...mount it, copy modprobe (statically linked) to it, and rewrite it with dd? > > spurious 8259A interrupt: IRQ7. is a little more puzzling. The system > got an interrupt on irq 7 but nothing was assigned to that irq. 7 is > usually line printer, although it could have been assigned to another > device. In any cause it is definitely nothing to do with XFS, it might > not even be SCSI related. Ask on linux-kernel and include the chipset > data and PCI routing information from the start of the boot log. I do have a printer that isn't normally on. I wonder if this is possibly related to having had it on and used it, then turning it off? But then again, it occurred during bootup, and it wasn't on at all that whole time. Also, I have seen it quite sparsely in the logs, it has shown up before, but is rare. It looks like maybe it is related to the ethernet adapter, at as far as what it shows up next to. I'll probably investigate it a bit then ask the kernel list if there is no answer. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Thu Jun 14 13:38:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EKcf401321 for linux-xfs-outgoing; Thu, 14 Jun 2001 13:38:41 -0700 Received: from s1.uklinux.net (ns1.uklinux.net [212.1.130.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EKcdk01318 for ; Thu, 14 Jun 2001 13:38:39 -0700 Received: from pyewacket.nic.uklinux.net (ppp-3b-27.3com.telinco.net [212.159.133.27]) by s1.uklinux.net (8.11.2/8.11.1) with ESMTP id f5EKcRN31342; Thu, 14 Jun 2001 21:38:27 +0100 Envelope-To: linux-xfs@oss.sgi.com Received: from ndoye by pyewacket.nic.uklinux.net with local (Exim 3.22 #1) id 15AdnG-0002T8-00; Thu, 14 Jun 2001 21:32:42 +0100 From: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15145.8042.774342.718726@localhost.localdomain> Date: Thu, 14 Jun 2001 21:32:42 +0100 To: Alan Eldridge Cc: linux-xfs@oss.sgi.com Subject: Running kernel w/o RH patches ... In-Reply-To: <20010608233837.A11062@wwweasel.geeksrus.net> References: <20010608233837.A11062@wwweasel.geeksrus.net> X-Mailer: VM 6.90 under 21.5 (beta1) "anise" XEmacs Lucid Organisation: Quixotic Hackers X-URL: http://www.nic.uklinux.net X-Cabaret-Voltaire-URL: http://brainwashed.com/cv X-Face: &-8(x5K]<0/|dXSmxL9\p/,6*,C16]W8k1Elf.\e~pa~ASI57X9+eDm^Rkv'?}-bT=o]Hz{ eMQXn Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alan Eldridge wrote on 8-June-2001: ->Knowing how heavily patched the RH kernels are (!!), does anyone know if ->there'd be impairment or malfunction running a stock + xfs kernel on a RH ->system? -> ->I guess there's really 2 separate issues: there's the big "ac-4" patch, ->which doesn't play nice with XFS, and then there's all the rest of the ->myriad bits and pieces RH has piled on. -> ->Anyone got any good data/opinions/wild-assed-guesss about this? I'm just ->trying to see all the options, and reducing complexity of the problem space ->is one I'd like to have. If your question is "Does replacing RedHat's highly patched kernel with a (later) non-patched kernel (with XFS added for fun) mean that stuff will break?" then the answer is no: you can just slot in a (suitably configured) later kernel. I've done so successfully for a few years now, and for a couple of months now with the XFS stuff from SGI. Only caveats are the Documentation/Changes file (as you know) and the full horror (sorry, fully scalable future) that is devfs :-) Sorry if this is all stating-the-bleeding-obvious stuff to you, nic -- www.nic.uklinux.net From owner-linux-xfs@oss.sgi.com Thu Jun 14 14:59:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5ELxUW05643 for linux-xfs-outgoing; Thu, 14 Jun 2001 14:59:30 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5ELxSk05639 for ; Thu, 14 Jun 2001 14:59:29 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA01380; Thu, 14 Jun 2001 23:59:26 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA11588; Thu, 14 Jun 2001 23:59:26 +0200 (CEST) Date: Thu, 14 Jun 2001 23:59:26 +0200 (CEST) From: Seth Mos To: sandeen@sgi.com cc: ude@handshake.de, linux-xfs@oss.sgi.com Subject: Re: Blocksizes In-Reply-To: <3B28D384.9A10753C@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 14 Jun 2001 sandeen@sgi.com wrote: > Sebastian Ude wrote: > > > > Does XFS for Linux still only support blocksizes equal to a pagesize (4096 > > bytes / 4k on ix86) ? > > Yes > > > If yes, are there plans to work on this problem ? Smaller then page size will be failry soon (think months). This is also neccesary to mount Irix disks with 512 byte clusters. Larger then page size is pushed ahed for somewhere in 2.5 whenever that is. Much code involved and the kernel needs to be enlightend in this case. > Yes, it is on the TODO list, but I'm afraid I can't really give you a > good idea of when it might be done... Seth From owner-linux-xfs@oss.sgi.com Thu Jun 14 15:16:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EMGZk06435 for linux-xfs-outgoing; Thu, 14 Jun 2001 15:16:35 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EMGXk06432 for ; Thu, 14 Jun 2001 15:16:33 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA03854; Fri, 15 Jun 2001 00:16:32 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA13374; Fri, 15 Jun 2001 00:16:32 +0200 (CEST) Date: Fri, 15 Jun 2001 00:16:32 +0200 (CEST) From: Seth Mos To: Kris Verbeeck cc: linux-xfs@oss.sgi.com Subject: Re: kernel.h In-Reply-To: <3B290BA1.78A041C@chello.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 14 Jun 2001, Kris Verbeeck wrote: > Hi, > > 1) After booting a linux 2.4.5 kernel with XFS support the > kernel.h file contains the following lines: > > /* Kernel type package kernel2.4.5-xfs-2.4.5-xfs is not > installed2.4.5-xfs */ > > #ifndef __MODULE_KERNEL_package kernel2.4.5-xfs-2.4.5-xfs is not > installed > #define __MODULE_KERNEL_package kernel2.4.5-xfs-2.4.5-xfs is not > installed 1 > #endif > > Why are they in there? They are not valid C code. ?? Don't know. > 2) Another problem I have is when I want to recompile the > NVidia kernel module for my GeForce 2 graphics adapter with > this new patched kernel. I get a lot of errors, where before > with the unpatched kernel everything went alright. A log > of the make output is attached to this mail. Weird, I run 2.4.6-pre2-xfs with the nVidia 1.0-1251 drivers and they compile just fine. Oh and they even work. (just checked by switching to X and back to terminal). > Any ideas on this? Haven't found anything in the FAQ's of > either XFS or NVidia about this. Will add a entry that the 1.0-1251 nVIDIA drivers work with current CVS. There are multiple people on this list using the nVIDIA drivers and XFS on their system and I have not seen reports that everything broke. XFS is a filesystem, it doesn't touch much else in the kernel. It would be hard to imagine that it breaks their drivers. > BTW: I had a similar problem with a 2.4.2 kernel, so it is not > the actual kernel version that is the problem. At that time the 0.9-6 drivers did compile. I only switched to the 1.0 drivers when the CVS eached 2.4.5 or so. > thx in advance Cheers Seth From owner-linux-xfs@oss.sgi.com Thu Jun 14 15:24:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EMOs606754 for linux-xfs-outgoing; Thu, 14 Jun 2001 15:24:54 -0700 Received: from vortex.xnote.com ([65.105.237.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EMOsk06751 for ; Thu, 14 Jun 2001 15:24:54 -0700 Received: from xnote.com (slccheck01.firsthealth.com [209.180.88.28]) by vortex.xnote.com (8.11.0/8.8.7) with ESMTP id f5ELWGA10828 for ; Thu, 14 Jun 2001 15:32:16 -0600 Message-ID: <3B293994.7040409@xnote.com> Date: Thu, 14 Jun 2001 16:24:20 -0600 From: Vernon McPherron Reply-To: vernon@xnote.com User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.1) Gecko/20010607 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: ssh cvs access? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At work I'm unable to update my cvs tree via cvs. I'm guessing it is because of the firewall. XFree86 has cvs via ssh and that works great, is there any way to use the XFS cvs server via ssh? -- -=/Vernon McPherron/=- From owner-linux-xfs@oss.sgi.com Thu Jun 14 15:40:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EMe9W07528 for linux-xfs-outgoing; Thu, 14 Jun 2001 15:40:09 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EMe8k07525 for ; Thu, 14 Jun 2001 15:40:08 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA07710; Fri, 15 Jun 2001 00:40:07 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA15380; Fri, 15 Jun 2001 00:40:06 +0200 (CEST) Date: Fri, 15 Jun 2001 00:40:06 +0200 (CEST) From: Seth Mos To: Vernon McPherron cc: linux-xfs@oss.sgi.com Subject: Re: ssh cvs access? In-Reply-To: <3B293994.7040409@xnote.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 14 Jun 2001, Vernon McPherron wrote: > At work I'm unable to update my cvs tree via cvs. I'm guessing it is > because of the firewall. XFree86 has cvs via ssh and that works great, > is there any way to use the XFS cvs server via ssh? Not that I know of. Maybe we could set up a second cvs server in europe for anonmous CVS checkouts and updates. I'll look into it. I will have to wathc the traffic though. Bye Seth From owner-linux-xfs@oss.sgi.com Thu Jun 14 15:48:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EMmu407964 for linux-xfs-outgoing; Thu, 14 Jun 2001 15:48:56 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EMmtk07961 for ; Thu, 14 Jun 2001 15:48:55 -0700 Received: from [192.168.1.10] (helo=den2) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15Afup-0000Xw-00; Fri, 15 Jun 2001 10:48:39 +1200 From: "Juha Saarinen" To: "'Seth Mos'" , "'Kris Verbeeck'" Cc: Subject: RE: kernel.h Date: Fri, 15 Jun 2001 10:48:15 +1200 Message-ID: <005a01c0f524$19645f10$0a01a8c0@den2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk :: On Thu, 14 Jun 2001, Kris Verbeeck wrote: :: :: > Hi, :: > :: > 1) After booting a linux 2.4.5 kernel with XFS support the :: > kernel.h file contains the following lines: :: > :: > /* Kernel type package kernel2.4.5-xfs-2.4.5-xfs is not :: > installed2.4.5-xfs */ :: > :: > #ifndef __MODULE_KERNEL_package kernel2.4.5-xfs-2.4.5-xfs is not :: > installed :: > #define __MODULE_KERNEL_package kernel2.4.5-xfs-2.4.5-xfs is not :: > installed 1 :: > #endif :: > :: > Why are they in there? They are not valid C code. It's a Red Hat-ism, I believe, supposedly created by the initscripts (although I can't find a reference to kernel.h in my /etc directory). I've got this on my system: # cat /boot/kernel.h /* This file is automatically generated at boot time. */ #ifndef __BOOT_KERNEL_H_ #define __BOOT_KERNEL_H_ /* Kernel type i6862.4.6-pre2-xfs */ #ifndef __MODULE_KERNEL_i686 #define __MODULE_KERNEL_i686 1 #endif #ifndef __BOOT_KERNEL_ENTERPRISE #define __BOOT_KERNEL_ENTERPRISE 0 #endif #ifndef __BOOT_KERNEL_SMP #define __BOOT_KERNEL_SMP 0 #endif #ifndef __BOOT_KERNEL_UP #define __BOOT_KERNEL_UP 1 #endif #endif See: $KERNEL_SOURCE_DIR/linux-2.4/include/linux/rhconfig.h It looks like you have made a typo in some config file, because the system looks for "kernel2.4.5-xfs-2.4.5-xfs" or something similar, but can't find it. -- Juha From owner-linux-xfs@oss.sgi.com Thu Jun 14 15:51:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EMpkf08152 for linux-xfs-outgoing; Thu, 14 Jun 2001 15:51:46 -0700 Received: from gwyn.tux.org (ident-user@gwyn.tux.org [207.96.122.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EMpjk08149 for ; Thu, 14 Jun 2001 15:51:45 -0700 Received: (from timball@localhost) by gwyn.tux.org (8.9.3/8.9.1) id SAA07211 for linux-xfs@oss.sgi.com; Thu, 14 Jun 2001 18:51:44 -0400 Date: Thu, 14 Jun 2001 18:51:43 -0400 From: Timothy Ball To: XFS Mailing List Subject: cvs [server aborted]: EOF in key in RCS file /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_buf_item.h,v Message-ID: <20010614185143.I28585@gwyn.tux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I got that when I did a cvs -z3 update -d -P just now. --timball -- Send mail with subject "send pgp key" for public key. pub 1024R/CFF85605 1999-06-10 Timothy L. Ball Key fingerprint = 8A 8E 64 D6 21 C0 90 29 9F D6 1E DC F8 18 CB CD From owner-linux-xfs@oss.sgi.com Thu Jun 14 16:02:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EN2OH08657 for linux-xfs-outgoing; Thu, 14 Jun 2001 16:02:24 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EN2Mk08654 for ; Thu, 14 Jun 2001 16:02:22 -0700 Received: from idcomm.com (IDENT:stimits@[209.60.72.222]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5EN23l31514 for ; Thu, 14 Jun 2001 17:02:03 -0600 Message-ID: <3B2942C1.85E36E84@idcomm.com> Date: Thu, 14 Jun 2001 17:03:29 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: kernel.h References: <005a01c0f524$19645f10$0a01a8c0@den2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juha Saarinen wrote: > > :: On Thu, 14 Jun 2001, Kris Verbeeck wrote: > :: > :: > Hi, > :: > > :: > 1) After booting a linux 2.4.5 kernel with XFS support the > :: > kernel.h file contains the following lines: > :: > > :: > /* Kernel type package kernel2.4.5-xfs-2.4.5-xfs is not > :: > installed2.4.5-xfs */ > :: > > :: > #ifndef __MODULE_KERNEL_package kernel2.4.5-xfs-2.4.5-xfs is not > :: > installed > :: > #define __MODULE_KERNEL_package kernel2.4.5-xfs-2.4.5-xfs is not > :: > installed 1 > :: > #endif > :: > > :: > Why are they in there? They are not valid C code. > > It's a Red Hat-ism, I believe, supposedly created by the initscripts > (although I can't find a reference to kernel.h in my /etc directory). Redhat places kernel.h in /boot/. Don't know why, but the fact that it is in /boot/ offers some hints. D. Stimits, stimits@idcomm.com > > I've got this on my system: > > # cat /boot/kernel.h > /* This file is automatically generated at boot time. */ > #ifndef __BOOT_KERNEL_H_ > #define __BOOT_KERNEL_H_ > > /* Kernel type i6862.4.6-pre2-xfs */ > > #ifndef __MODULE_KERNEL_i686 > #define __MODULE_KERNEL_i686 1 > #endif > > #ifndef __BOOT_KERNEL_ENTERPRISE > #define __BOOT_KERNEL_ENTERPRISE 0 > #endif > > #ifndef __BOOT_KERNEL_SMP > #define __BOOT_KERNEL_SMP 0 > #endif > > #ifndef __BOOT_KERNEL_UP > #define __BOOT_KERNEL_UP 1 > #endif > > #endif > > See: $KERNEL_SOURCE_DIR/linux-2.4/include/linux/rhconfig.h > > It looks like you have made a typo in some config file, because the > system looks for "kernel2.4.5-xfs-2.4.5-xfs" or something similar, but > can't find it. > > -- Juha From owner-linux-xfs@oss.sgi.com Thu Jun 14 16:10:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5ENAfS08924 for linux-xfs-outgoing; Thu, 14 Jun 2001 16:10:41 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5ENAek08921 for ; Thu, 14 Jun 2001 16:10:40 -0700 Received: from [192.168.1.10] (helo=den2) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15AgG7-0000ZS-00; Fri, 15 Jun 2001 11:10:39 +1200 From: "Juha Saarinen" To: Cc: Subject: RE: kernel.h Date: Fri, 15 Jun 2001 11:10:15 +1200 Message-ID: <005e01c0f527$2c322f70$0a01a8c0@den2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3B2942C1.85E36E84@idcomm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk :: Redhat places kernel.h in /boot/. Don't know why, but the :: fact that it :: is in /boot/ offers some hints. Well, it's not totally obvious, but it seems the RH kernel has it patched in, whereas other distros create it via the init scripts... I think. Used to ID which kernel is running. -- Juha From owner-linux-xfs@oss.sgi.com Thu Jun 14 16:24:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5ENOFP09334 for linux-xfs-outgoing; Thu, 14 Jun 2001 16:24:15 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5ENOEk09329 for ; Thu, 14 Jun 2001 16:24:14 -0700 Received: from [192.168.1.10] (helo=den2) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15AgTF-0000a9-00 for ; Fri, 15 Jun 2001 11:24:13 +1200 From: "Juha Saarinen" To: "'XFS Mailing List'" Subject: RE: cvs [server aborted]: EOF in key in RCS file /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_buf_item.h,v Date: Fri, 15 Jun 2001 11:23:49 +1200 Message-ID: <005f01c0f529$115dd440$0a01a8c0@den2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20010614185143.I28585@gwyn.tux.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk cvs server: Updating linux-2.4-xfs/linux/fs/xfs cvs [server aborted]: EOF in key in RCS file /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_buf_item.h,v -- Juha From owner-linux-xfs@oss.sgi.com Thu Jun 14 16:41:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5ENfCV09815 for linux-xfs-outgoing; Thu, 14 Jun 2001 16:41:12 -0700 Received: from ente.berdmann.de (p3E9E7294.dip.t-dialin.net [62.158.114.148]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5ENfBk09812 for ; Thu, 14 Jun 2001 16:41:11 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.16 #2) id 15AgjY-0000Io-00 for linux-xfs@oss.sgi.com; Fri, 15 Jun 2001 01:41:05 +0200 Message-ID: <3B294B90.93B46C54@berdmann.de> Date: Fri, 15 Jun 2001 01:41:04 +0200 From: "Bernhard R. Erdmann" Organization: Bernhard Erdmann Communication & Network Solutions X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre3-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: "'XFS Mailing List'" Subject: Re: cvs [server aborted]: EOF in key in RCS file /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_buf_item.h,v References: <005f01c0f529$115dd440$0a01a8c0@den2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk me too: cvs server: Updating linux/fs/xfs cvs [server aborted]: EOF in key in RCS file /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_buf_item.h,v From owner-linux-xfs@oss.sgi.com Thu Jun 14 16:45:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5ENjgH09938 for linux-xfs-outgoing; Thu, 14 Jun 2001 16:45:42 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5ENjdk09935 for ; Thu, 14 Jun 2001 16:45:40 -0700 Received: (qmail 3737 invoked from network); 14 Jun 2001 23:45:35 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 14 Jun 2001 23:45:35 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: stimits@idcomm.com cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? In-reply-to: Your message of "Thu, 14 Jun 2001 14:06:19 CST." <3B29193B.4E1125D9@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Jun 2001 09:45:34 +1000 Message-ID: <22709.992562334@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 14 Jun 2001 14:06:19 -0600, "D. Stimits" wrote: >Keith Owens wrote: >> is no such file or directory. Your initrd does not contain >> /sbin/modprobe, initrd normally only contains insmod to save space. > >Interesting that it is not there. Wouldn't modprobe be normal on >mkinitrd? Only on a full blown install ramdisk. End users with initrd are assumed to be using a tuned list of modules. mkinitrd inserts explicit insmod commands in linuxrc, based on the modules you specify during mkinitrd. modprobe is only useful when you do not know ahead of time which modules you will be using. From owner-linux-xfs@oss.sgi.com Thu Jun 14 16:47:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5ENlCs10037 for linux-xfs-outgoing; Thu, 14 Jun 2001 16:47:12 -0700 Received: from ente.berdmann.de (p3E9E7294.dip.t-dialin.net [62.158.114.148]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5ENlBk10034 for ; Thu, 14 Jun 2001 16:47:11 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.16 #2) id 15AgpN-0000KO-00 for linux-xfs@oss.sgi.com; Fri, 15 Jun 2001 01:47:05 +0200 Message-ID: <3B294CF9.941AF7E6@berdmann.de> Date: Fri, 15 Jun 2001 01:47:05 +0200 From: "Bernhard R. Erdmann" Organization: Bernhard Erdmann Communication & Network Solutions X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre3-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Linux XFS Mailing List Subject: do_softirq Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Having compiled 2.4.6-pre3-xfs, I get an unresolved symbol in ppp_generic.o: # /sbin/depmod -a -e depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre3-xfs/kernel/drivers/net/ppp_generic.o depmod: do_softirq # uname -a Linux ente 2.4.6-pre3-xfs #1 Thu Jun 14 12:25:56 CEST 2001 i586 unknown # gcc --version egcs-2.91.66 Any clue? From owner-linux-xfs@oss.sgi.com Thu Jun 14 16:58:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5ENwxs10299 for linux-xfs-outgoing; Thu, 14 Jun 2001 16:58:59 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5ENwvk10296 for ; Thu, 14 Jun 2001 16:58:57 -0700 Received: (qmail 3977 invoked from network); 14 Jun 2001 23:58:55 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 14 Jun 2001 23:58:55 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Bernhard R. Erdmann" cc: Linux XFS Mailing List Subject: Re: do_softirq In-reply-to: Your message of "Fri, 15 Jun 2001 01:47:05 +0200." <3B294CF9.941AF7E6@berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Jun 2001 09:58:54 +1000 Message-ID: <23039.992563134@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 15 Jun 2001 01:47:05 +0200, "Bernhard R. Erdmann" wrote: >Having compiled 2.4.6-pre3-xfs, I get an unresolved symbol in >ppp_generic.o: > ># /sbin/depmod -a -e >depmod: *** Unresolved symbols in >/lib/modules/2.4.6-pre3-xfs/kernel/drivers/net/ppp_generic.o >depmod: do_softirq Kernel bug, not XFS. Patch has been sent to Linus. Index: 6-pre3.1/include/asm-i386/softirq.h --- 6-pre3.1/include/asm-i386/softirq.h Sat, 09 Jun 2001 11:25:53 +1000 kaos (linux-2.4/T/51_softirq.h 1.3 644) +++ 6-pre3.1(w)/include/asm-i386/softirq.h Thu, 14 Jun 2001 02:26:16 +1000 kaos (linux-2.4/T/51_softirq.h 1.3 644) @@ -36,13 +36,13 @@ do { \ \ ".section .text.lock,\"ax\";" \ "2: pushl %%eax; pushl %%ecx; pushl %%edx;" \ - "call do_softirq;" \ + "call %c1;" \ "popl %%edx; popl %%ecx; popl %%eax;" \ "jmp 1b;" \ ".previous;" \ \ : /* no output */ \ - : "r" (ptr) \ + : "r" (ptr), "i" (do_softirq) \ /* no registers clobbered */ ); \ } while (0) From owner-linux-xfs@oss.sgi.com Thu Jun 14 17:12:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F0C1a10860 for linux-xfs-outgoing; Thu, 14 Jun 2001 17:12:01 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F0C0k10857 for ; Thu, 14 Jun 2001 17:12:00 -0700 Received: from idcomm.com (IDENT:stimits@x2-pip10.idcomm.com [209.60.72.21]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5F0Bgl12009 for ; Thu, 14 Jun 2001 18:11:42 -0600 Message-ID: <3B295315.E65F8920@idcomm.com> Date: Thu, 14 Jun 2001 18:13:09 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-3 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <22709.992562334@ocs3.ocs-net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > > On Thu, 14 Jun 2001 14:06:19 -0600, > "D. Stimits" wrote: > >Keith Owens wrote: > >> is no such file or directory. Your initrd does not contain > >> /sbin/modprobe, initrd normally only contains insmod to save space. > > > >Interesting that it is not there. Wouldn't modprobe be normal on > >mkinitrd? > > Only on a full blown install ramdisk. End users with initrd are > assumed to be using a tuned list of modules. mkinitrd inserts explicit > insmod commands in linuxrc, based on the modules you specify during > mkinitrd. modprobe is only useful when you do not know ahead of time > which modules you will be using. So I have to wonder then why this install based mkinitrd.xfs is asking for modprobe? Is that a bug in the mkinitrd.xfs that it attempts to use modprobe? D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Thu Jun 14 17:23:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F0NG311411 for linux-xfs-outgoing; Thu, 14 Jun 2001 17:23:16 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F0NEk11408 for ; Thu, 14 Jun 2001 17:23:14 -0700 Received: (qmail 4122 invoked from network); 15 Jun 2001 00:23:11 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 15 Jun 2001 00:23:11 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: stimits@idcomm.com cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? In-reply-to: Your message of "Thu, 14 Jun 2001 18:13:09 CST." <3B295315.E65F8920@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Jun 2001 10:23:10 +1000 Message-ID: <23334.992564590@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 14 Jun 2001 18:13:09 -0600, "D. Stimits" wrote: >Keith Owens wrote: >> On Thu, 14 Jun 2001 14:06:19 -0600, >> "D. Stimits" wrote: >> >Interesting that it is not there. Wouldn't modprobe be normal on >> >mkinitrd? >> >> Only on a full blown install ramdisk. End users with initrd are >> assumed to be using a tuned list of modules. mkinitrd inserts explicit >> insmod commands in linuxrc, based on the modules you specify during >> mkinitrd. modprobe is only useful when you do not know ahead of time >> which modules you will be using. > >So I have to wonder then why this install based mkinitrd.xfs is asking >for modprobe? Is that a bug in the mkinitrd.xfs that it attempts to use >modprobe? As I said in a previous mail, you compiled the kernel for automatic module loading (kmod). It is kmod inside the kernel that is invoking modprobe, looking for the module to do scsi_hostadaptor. That has nothing to do with mkinitrd. From owner-linux-xfs@oss.sgi.com Thu Jun 14 17:38:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F0c2Y11895 for linux-xfs-outgoing; Thu, 14 Jun 2001 17:38:02 -0700 Received: from ente.berdmann.de (p3E9E7294.dip.t-dialin.net [62.158.114.148]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F0c0k11892 for ; Thu, 14 Jun 2001 17:38:01 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.16 #2) id 15AhcT-0000bZ-00; Fri, 15 Jun 2001 02:37:50 +0200 Message-ID: <3B2958DD.8B47DE77@berdmann.de> Date: Fri, 15 Jun 2001 02:37:49 +0200 From: "Bernhard R. Erdmann" Organization: Bernhard Erdmann Communication & Network Solutions X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre3-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Keith Owens CC: Linux XFS Mailing List Subject: Re: do_softirq References: <23039.992563134@ocs3.ocs-net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Kernel bug, not XFS. Patch has been sent to Linus. Thanks - that helped. From owner-linux-xfs@oss.sgi.com Thu Jun 14 18:32:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F1W5614039 for linux-xfs-outgoing; Thu, 14 Jun 2001 18:32:05 -0700 Received: from walt400.holman.net (aazpppdsl56.sttl.uswest.net [63.226.208.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F1W4k14036 for ; Thu, 14 Jun 2001 18:32:04 -0700 Received: from uswest.net (walt400.holman.net [10.0.0.2]) by walt400.holman.net (Postfix) with ESMTP id 2F16C43C7FB; Thu, 14 Jun 2001 18:42:26 -0700 (PDT) Message-ID: <3B296802.6070205@uswest.net> Date: Thu, 14 Jun 2001 18:42:26 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-xfs i686; en-US; rv:0.9.1+) Gecko/20010614 X-Accept-Language: en-us MIME-Version: 1.0 To: Keith Owens Cc: "Bernhard R. Erdmann" , Linux XFS Mailing List Subject: Re: do_softirq References: <23039.992563134@ocs3.ocs-net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a different patch than the one I was aware of from the kml. Is this preferred over the non-version symbol export? (Hope I didn't misunderstand that..) That one seemed to work well. -Walt Keith Owens wrote: >On Fri, 15 Jun 2001 01:47:05 +0200, >"Bernhard R. Erdmann" wrote: > >>Having compiled 2.4.6-pre3-xfs, I get an unresolved symbol in >>ppp_generic.o: >> >># /sbin/depmod -a -e >>depmod: *** Unresolved symbols in >>/lib/modules/2.4.6-pre3-xfs/kernel/drivers/net/ppp_generic.o >>depmod: do_softirq >> > >Kernel bug, not XFS. Patch has been sent to Linus. > >Index: 6-pre3.1/include/asm-i386/softirq.h >--- 6-pre3.1/include/asm-i386/softirq.h Sat, 09 Jun 2001 11:25:53 +1000 kaos (linux-2.4/T/51_softirq.h 1.3 644) >+++ 6-pre3.1(w)/include/asm-i386/softirq.h Thu, 14 Jun 2001 02:26:16 +1000 kaos (linux-2.4/T/51_softirq.h 1.3 644) >@@ -36,13 +36,13 @@ do { \ > \ > ".section .text.lock,\"ax\";" \ > "2: pushl %%eax; pushl %%ecx; pushl %%edx;" \ >- "call do_softirq;" \ >+ "call %c1;" \ > "popl %%edx; popl %%ecx; popl %%eax;" \ > "jmp 1b;" \ > ".previous;" \ > \ > : /* no output */ \ >- : "r" (ptr) \ >+ : "r" (ptr), "i" (do_softirq) \ > /* no registers clobbered */ ); \ > } while (0) > > > From owner-linux-xfs@oss.sgi.com Thu Jun 14 18:56:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F1u0C16286 for linux-xfs-outgoing; Thu, 14 Jun 2001 18:56:00 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F1txk16283 for ; Thu, 14 Jun 2001 18:55:59 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA00563 for ; Thu, 14 Jun 2001 18:55:56 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) 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 LAA18113; Fri, 15 Jun 2001 11:54:36 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Walt H cc: "Bernhard R. Erdmann" , Linux XFS Mailing List Subject: Re: do_softirq In-reply-to: Your message of "Thu, 14 Jun 2001 18:42:26 MST." <3B296802.6070205@uswest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Jun 2001 11:54:36 +1000 Message-ID: <2343.992570076@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 14 Jun 2001 18:42:26 -0700, Walt H wrote: >This is a different patch than the one I was aware of from the kml. Is >this preferred over the non-version symbol export? (Hope I didn't >misunderstand that..) That one seemed to work well. Both patches are mine. It required about 10 emails between various kernel hackers and digging into the more obscure bits of gcc to agree on a method of exposing calls to exported symbols from __asm__ code. The change to softirq.h is the correct mechanism, especially as you do not have to run make mrproper after applying the patch, changing from EXPORT_SYMBOL() to EXPORT_SYMBOL_NOVERS() requires make mrproper. From owner-linux-xfs@oss.sgi.com Thu Jun 14 19:08:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F28Ew18024 for linux-xfs-outgoing; Thu, 14 Jun 2001 19:08:14 -0700 Received: from walt400.holman.net (aazpppdsl56.sttl.uswest.net [63.226.208.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F28Dk18017 for ; Thu, 14 Jun 2001 19:08:13 -0700 Received: from uswest.net (walt400.holman.net [10.0.0.2]) by walt400.holman.net (Postfix) with ESMTP id 13EC643C7FB; Thu, 14 Jun 2001 19:18:38 -0700 (PDT) Message-ID: <3B29707D.1060009@uswest.net> Date: Thu, 14 Jun 2001 19:18:37 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-xfs i686; en-US; rv:0.9.1+) Gecko/20010614 X-Accept-Language: en-us MIME-Version: 1.0 To: Keith Owens Cc: "Bernhard R. Erdmann" , Linux XFS Mailing List Subject: Re: do_softirq References: <2343.992570076@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks Keith. I'm an experienced linux user, but a crappy kernel programmer :) Always good to have clarity. OT - Just ready about "The Search for The Holy Grail" on Slashdot. Keep wanting to say: "Behind the rabbit?" Sorry... I'll go away now. -Walt Keith Owens wrote: >On Thu, 14 Jun 2001 18:42:26 -0700, >Walt H wrote: > >>This is a different patch than the one I was aware of from the kml. Is >>this preferred over the non-version symbol export? (Hope I didn't >>misunderstand that..) That one seemed to work well. >> > >Both patches are mine. It required about 10 emails between various >kernel hackers and digging into the more obscure bits of gcc to agree >on a method of exposing calls to exported symbols from __asm__ code. >The change to softirq.h is the correct mechanism, especially as you do >not have to run make mrproper after applying the patch, changing from >EXPORT_SYMBOL() to EXPORT_SYMBOL_NOVERS() requires make mrproper. > > From owner-linux-xfs@oss.sgi.com Thu Jun 14 19:24:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F2Oq320328 for linux-xfs-outgoing; Thu, 14 Jun 2001 19:24:52 -0700 Received: from mx.linux.net.cn ([210.82.190.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F2Okk20308 for ; Thu, 14 Jun 2001 19:24:50 -0700 Received: from dfbbb.cn.mvd (unknown [211.99.247.66]) by mx.linux.net.cn (Postfix) with ESMTP id D83FEA7D for ; Fri, 15 Jun 2001 10:24:32 +0800 (CST) Received: (from dfbb@localhost) by dfbbb.cn.mvd (8.11.2/8.11.2) id f5F2Oro10704 for linux-xfs@oss.sgi.com; Fri, 15 Jun 2001 10:24:53 +0800 Date: Fri, 15 Jun 2001 10:24:53 +0800 From: Fang Han To: linux-xfs@oss.sgi.com Subject: Is there any meanning to maintain ac-series XFS patch? Message-ID: <20010615102453.A10643@dfbbb.cn.mvd> 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.2.5i Organization: None X-Attribution: dfbb Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi guys: As we know, Now official xfs cvs tree is sync with linux-2.4.x-pre series kernel tree, And there is another kernel tree : linux-2.4.x-AC, And RedHat's kernel is base on that tree ( Though they split the ac's patch ), It is a little diffcult to apply xfs patch to AC's kernel ( Same as RedHat's rawhide kernel), Is it useful to maintain such XFS patch toward AC's kernel? dfbb From owner-linux-xfs@oss.sgi.com Thu Jun 14 19:43:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F2hEb21989 for linux-xfs-outgoing; Thu, 14 Jun 2001 19:43:14 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F2hDk21986 for ; Thu, 14 Jun 2001 19:43:13 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5F2h7R01983 for linux-xfs@oss.sgi.com; Thu, 14 Jun 2001 22:43:07 -0400 Date: Thu, 14 Jun 2001 22:43:07 -0400 From: Alan Eldridge To: linux-xfs@oss.sgi.com Subject: RHrawhide rpms by Russell Message-ID: <20010614224307.A1978@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk OK so far.... Due to Win2K issues @work, I didn't have time to set up a VMWare to test in. So I'm living dangerously (not really...) and running the i686 RPM on the real hardware. So far so good. I don't use NFS, so I won't get bitten by *that*. :) I'm about to do a full KDE CVS build, so that'll give the filesystem a nice workout. -- Alan Eldridge From owner-linux-xfs@oss.sgi.com Thu Jun 14 20:24:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F3OnF26364 for linux-xfs-outgoing; Thu, 14 Jun 2001 20:24:49 -0700 Received: from zion.rivenstone.net (dhcp065-024-121-117.columbus.rr.com [65.24.121.117]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F3Omk26359 for ; Thu, 14 Jun 2001 20:24:48 -0700 Received: by zion.rivenstone.net (Postfix, from userid 500) id AC9AF630A5; Thu, 14 Jun 2001 18:31:14 -0400 (EDT) Date: Thu, 14 Jun 2001 18:31:14 -0400 From: Joseph Fannin To: linux-xfs@oss.sgi.com Subject: Does XFS require DevFs? Message-ID: <20010614183114.A24007@zion.rivenstone.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've searched the archives but found no answer to this question: Does XFS require DevFS? Or can I build a kernel for my system (installed from the XFS RH7.1 .iso) that does not include devfs without having problems? I've been completely unable to build a working kernel using either the RH-2.96 or egcs -- the build either fails or gives me a kernel that produces random segfaults, oopsen, and fs corruption. I've tried the .src.rpm on the .iso, the 2.4.3 patches and the CVS devel tree. Often I get oopses in rc.sysinit at about the time it tries to activate quota support -- do I need quota support built in? I'm not exactly new at building kernels, but I'm no coder, and my inability to build a working kernel with XFS support is frustrating me to say the least. Should I post ksymoops output, am I doing something obviously wrong, or should I provide more [detailed | organized] information? Any help would be greatly appreciated. -- Joseph Fannin jhf@rivenstone.net "Bull in pure form is rare; there is usually some contamination by data." -- William Graves Perry Jr. From owner-linux-xfs@oss.sgi.com Thu Jun 14 20:33:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F3XoM27542 for linux-xfs-outgoing; Thu, 14 Jun 2001 20:33:50 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F3Xnk27539 for ; Thu, 14 Jun 2001 20:33:49 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip16.idcomm.com [209.60.72.143]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5F3XVl04371 for ; Thu, 14 Jun 2001 21:33:32 -0600 Message-ID: <3B298261.796E7781@idcomm.com> Date: Thu, 14 Jun 2001 21:34:57 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-3 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <23334.992564590@ocs3.ocs-net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > > On Thu, 14 Jun 2001 18:13:09 -0600, > "D. Stimits" wrote: > >Keith Owens wrote: > >> On Thu, 14 Jun 2001 14:06:19 -0600, > >> "D. Stimits" wrote: > >> >Interesting that it is not there. Wouldn't modprobe be normal on > >> >mkinitrd? > >> > >> Only on a full blown install ramdisk. End users with initrd are > >> assumed to be using a tuned list of modules. mkinitrd inserts explicit > >> insmod commands in linuxrc, based on the modules you specify during > >> mkinitrd. modprobe is only useful when you do not know ahead of time > >> which modules you will be using. > > > >So I have to wonder then why this install based mkinitrd.xfs is asking > >for modprobe? Is that a bug in the mkinitrd.xfs that it attempts to use > >modprobe? > > As I said in a previous mail, you compiled the kernel for automatic > module loading (kmod). It is kmod inside the kernel that is invoking > modprobe, looking for the module to do scsi_hostadaptor. That has > nothing to do with mkinitrd. That makes sense. Now I have to wonder why I never noticed the modprobe error on other kernels since I always enable kmod. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Thu Jun 14 20:36:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F3a1V27919 for linux-xfs-outgoing; Thu, 14 Jun 2001 20:36:01 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F3a0k27916 for ; Thu, 14 Jun 2001 20:36:01 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA21956 for ; Thu, 14 Jun 2001 20:35:55 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) 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 NAA18629; Fri, 15 Jun 2001 13:34:34 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Joseph Fannin cc: linux-xfs@oss.sgi.com Subject: Re: Does XFS require DevFs? In-reply-to: Your message of "Thu, 14 Jun 2001 18:31:14 -0400." <20010614183114.A24007@zion.rivenstone.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Jun 2001 13:34:34 +1000 Message-ID: <3943.992576074@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 14 Jun 2001 18:31:14 -0400, Joseph Fannin wrote: > I've searched the archives but found no answer to this question: >Does XFS require DevFS? No. devfs is useful on large systems, the sort of systems that benefit from a decent filesystem like XFS but you can build and run XFS without devfs. > I've been completely unable to build a working kernel using either >the RH-2.96 or egcs -- the build either fails Fails how? Details are required. >or gives me a kernel >that produces random segfaults, oopsen, and fs corruption. Sounds like the build is doing something wrong. > Often I get oopses in rc.sysinit at about the time it tries to >activate quota support -- do I need quota support built in? Not sure. I have run XFS without any quota code at all and it works but you might have a problem with /sbin/quotan. OTOH it could be a build problem. > I'm not exactly new at building kernels, but I'm no coder, and my >inability to build a working kernel with XFS support is frustrating me >to say the least. Should I post ksymoops output, am I doing something >obviously wrong, or should I provide more [detailed | organized] >information? Any help would be greatly appreciated. Start with information about the failing build. I would not even look at run time failures until you are sure that the build is correct. From owner-linux-xfs@oss.sgi.com Thu Jun 14 20:41:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F3f7c28616 for linux-xfs-outgoing; Thu, 14 Jun 2001 20:41:07 -0700 Received: from zion.rivenstone.net (dhcp065-024-121-117.columbus.rr.com [65.24.121.117]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F3f6k28613 for ; Thu, 14 Jun 2001 20:41:06 -0700 Received: by zion.rivenstone.net (Postfix, from userid 500) id 946EE630A5; Thu, 14 Jun 2001 18:47:33 -0400 (EDT) Date: Thu, 14 Jun 2001 18:47:33 -0400 From: Joseph Fannin To: linux-xfs@oss.sgi.com Subject: Re: Does XFS require DevFs? Message-ID: <20010614184733.B24007@zion.rivenstone.net> References: <20010614183114.A24007@zion.rivenstone.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010614183114.A24007@zion.rivenstone.net>; from jhf@rivenstone.net on Thu, Jun 14, 2001 at 06:31:14PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Grrr. My apologies -- looking over my previous message, I've been a bit ambiguous. It's the devel tree that is giving me oopsen and random seqfaults. The 1.0 release patches and the .src.rpm from the XFS RH7.1 .iso won't build. From owner-linux-xfs@oss.sgi.com Thu Jun 14 20:41:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F3fxb28841 for linux-xfs-outgoing; Thu, 14 Jun 2001 20:41:59 -0700 Received: from bug.martins.home (c1164316-a.parker1.co.home.com [24.22.190.144]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F3fwk28838 for ; Thu, 14 Jun 2001 20:41:58 -0700 Received: from vpmonline.com (localhost.localdomain [127.0.0.1]) by bug.martins.home (8.11.2/8.11.2) with ESMTP id f5F3fqt30690; Thu, 14 Jun 2001 21:41:53 -0600 Message-ID: <3B2983FF.4050503@vpmonline.com> Date: Thu, 14 Jun 2001 21:41:51 -0600 From: michael User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686; en-US; rv:0.9.1) Gecko/20010607 X-Accept-Language: en-us MIME-Version: 1.0 To: Joseph Fannin CC: linux-xfs@oss.sgi.com Subject: Re: Does XFS require DevFs? References: <20010614183114.A24007@zion.rivenstone.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk devfs is definitely not reuired--in fact, it's the 1st thing i disable through lilo since I have not spent the time to try to get it to work with any software or hardware RAID devices (by default, it does not recognize software or compaq raid devices). The best success I've had so far is to use the release 1 xfs iso for the redhat 7.1 install ( 2.4.2-SGI_XFS_1.0 ). I've had all kinds of trouble trying to get the latest 2.4.5,2.4.6-pre versions to work--xfs installs ok, just other problems cause random freezes and the system hangs. Once the system hangs, I have seen a lot of files on the XFS partitions get zeroed out, or contain binary all throughout them--however, I don't think XFS is to blame for that--just open, half written files when the kernels hard freeze on me. Now I face the task that the 2.4.2 cciss (compaq raid) has a serious memory leak, so I'm back to trying a recent xfs and 2.4.6 kernel. Good luck--I need it too. --Michael Joseph Fannin wrote: > I've searched the archives but found no answer to this question: >Does XFS require DevFS? Or can I build a kernel for my system >(installed from the XFS RH7.1 .iso) that does not include devfs >without having problems? > > I've been completely unable to build a working kernel using either >the RH-2.96 or egcs -- the build either fails or gives me a kernel >that produces random segfaults, oopsen, and fs corruption. I've tried >the .src.rpm on the .iso, the 2.4.3 patches and the CVS devel tree. > > Often I get oopses in rc.sysinit at about the time it tries to >activate quota support -- do I need quota support built in? > > I'm not exactly new at building kernels, but I'm no coder, and my >inability to build a working kernel with XFS support is frustrating me >to say the least. Should I post ksymoops output, am I doing something >obviously wrong, or should I provide more [detailed | organized] >information? Any help would be greatly appreciated. > >-- >Joseph Fannin >jhf@rivenstone.net > >"Bull in pure form is rare; there is usually some contamination by data." > -- William Graves Perry Jr. > -- -- Michael G. Martin mailto:michael@vpmonline.com From owner-linux-xfs@oss.sgi.com Thu Jun 14 20:42:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F3gJF28965 for linux-xfs-outgoing; Thu, 14 Jun 2001 20:42:19 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F3gIk28960 for ; Thu, 14 Jun 2001 20:42:18 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id UAA09493 for ; Thu, 14 Jun 2001 20:42:39 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) 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 NAA18667; Fri, 15 Jun 2001 13:40:54 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: stimits@idcomm.com cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? In-reply-to: Your message of "Thu, 14 Jun 2001 21:34:57 CST." <3B298261.796E7781@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Jun 2001 13:40:54 +1000 Message-ID: <4198.992576454@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 14 Jun 2001 21:34:57 -0600, "D. Stimits" wrote: >That makes sense. Now I have to wonder why I never noticed the modprobe >error on other kernels since I always enable kmod. Other kernels had SCSI built in? scsi_register_module only calls kmod for scsi_hostadapter if there is no host at all. From owner-linux-xfs@oss.sgi.com Thu Jun 14 20:51:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F3pbU30199 for linux-xfs-outgoing; Thu, 14 Jun 2001 20:51:37 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F3pak30184 for ; Thu, 14 Jun 2001 20:51:36 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15Akdv-0000jQ-00; Fri, 15 Jun 2001 15:51:31 +1200 Date: Fri, 15 Jun 2001 15:51:31 +1200 (NZST) From: Juha Saarinen To: Joseph Fannin cc: "linux-xfs@oss.sgi.com" Subject: Re: Does XFS require DevFs? In-Reply-To: <20010614183114.A24007@zion.rivenstone.net> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk No, AFAICT it doesn't require devfs. What sort of hardware do you have? -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 On Thu, 14 Jun 2001, Joseph Fannin wrote: > I've searched the archives but found no answer to this question: > Does XFS require DevFS? Or can I build a kernel for my system > (installed from the XFS RH7.1 .iso) that does not include devfs > without having problems? > > I've been completely unable to build a working kernel using either > the RH-2.96 or egcs -- the build either fails or gives me a kernel > that produces random segfaults, oopsen, and fs corruption. I've tried > the .src.rpm on the .iso, the 2.4.3 patches and the CVS devel tree. > > Often I get oopses in rc.sysinit at about the time it tries to > activate quota support -- do I need quota support built in? > > I'm not exactly new at building kernels, but I'm no coder, and my > inability to build a working kernel with XFS support is frustrating me > to say the least. Should I post ksymoops output, am I doing something > obviously wrong, or should I provide more [detailed | organized] > information? Any help would be greatly appreciated. > > -- > Joseph Fannin > jhf@rivenstone.net > > "Bull in pure form is rare; there is usually some contamination by data." > -- William Graves Perry Jr. > > > From owner-linux-xfs@oss.sgi.com Thu Jun 14 20:51:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F3pQg30120 for linux-xfs-outgoing; Thu, 14 Jun 2001 20:51:26 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F3pPk30115 for ; Thu, 14 Jun 2001 20:51:25 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip16.idcomm.com [209.60.72.143]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5F3p7l06599 for ; Thu, 14 Jun 2001 21:51:07 -0600 Message-ID: <3B298681.87DE9A27@idcomm.com> Date: Thu, 14 Jun 2001 21:52:33 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-3 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: mkinitrd, ramdisk failure? References: <4198.992576454@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > > On Thu, 14 Jun 2001 21:34:57 -0600, > "D. Stimits" wrote: > >That makes sense. Now I have to wonder why I never noticed the modprobe > >error on other kernels since I always enable kmod. > > Other kernels had SCSI built in? scsi_register_module only calls kmod > for scsi_hostadapter if there is no host at all. That explains that. I have used modules before, but I always make scsi built in (till now at least). As trivia, while working on this ramdisk problem where I failed to enable it, but eventually got it, I tried various sizes of initial ramdisk reserve. Whenever I specified something such as 8192, it would always say it needed about 6 bytes more. I got to 8192*2 reserved, and it still always wanted a couple bytes more. I ended up setting it to 25000 to satisfy it (25000 kbyte). The modules included in the ramdisk were scsi and xfs modules. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Thu Jun 14 22:30:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F5U1v07929 for linux-xfs-outgoing; Thu, 14 Jun 2001 22:30:01 -0700 Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F5U0k07920 for ; Thu, 14 Jun 2001 22:30:00 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f5F5Ts896662 for ; Fri, 15 Jun 2001 00:29:54 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <3B299D51.85A6B204@thebarn.com> Date: Fri, 15 Jun 2001 00:29:53 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: RedHat Rawhide + XFS rpm available for testing. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok after a few false starts I finally have a running RedHat rawhide kernel + XFS. The XFS patches are in sync with the devel tree. All the rpms can be gotten at: ftp://oss.sgi.com/projects/xfs/download/testing/RHrawhide/ These have not been tested extensively so use at your own risk. Note if somebody with a quota setup would test the quota support (since it was broken in the 1.0 release ) and report back any problems. -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Fri Jun 15 00:16:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F7Gju10841 for linux-xfs-outgoing; Fri, 15 Jun 2001 00:16:45 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F7Ggk10838 for ; Fri, 15 Jun 2001 00:16:42 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5F7GKV03199; Fri, 15 Jun 2001 09:16:34 +0200 Message-Id: <4.3.2.7.2.20010615091453.02f4d6f0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Jun 2001 09:16:17 +0200 To: Fang Han , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Is there any meanning to maintain ac-series XFS patch? In-Reply-To: <20010615102453.A10643@dfbbb.cn.mvd> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10:24 15-6-2001 +0800, Fang Han wrote: >Hi guys: > >As we know, Now official xfs cvs tree is sync with linux-2.4.x-pre series >kernel tree, And there is another kernel tree : linux-2.4.x-AC, And RedHat's >kernel is base on that tree ( Though they split the ac's patch ), It is a >little diffcult to apply xfs patch to AC's kernel ( Same as RedHat's rawhide >kernel), Is it useful to maintain such XFS patch toward AC's kernel? > >dfbb There are is not enough time or people that can do it available. Alan can produce -ac patches at an alarming rate. They can't cope with that at the moment. Volunteers may apply. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Jun 15 00:23:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F7NvE10986 for linux-xfs-outgoing; Fri, 15 Jun 2001 00:23:57 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F7Nuk10983 for ; Fri, 15 Jun 2001 00:23:56 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5F7NmV03249; Fri, 15 Jun 2001 09:23:48 +0200 Message-Id: <4.3.2.7.2.20010615091758.03932170@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Jun 2001 09:23:45 +0200 To: Keith Owens , Joseph Fannin From: Seth Mos Subject: Re: Does XFS require DevFs? Cc: linux-xfs@oss.sgi.com In-Reply-To: <3943.992576074@kao2.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:34 15-6-2001 +1000, Keith Owens wrote: > >or gives me a kernel > >that produces random segfaults, oopsen, and fs corruption. > >Sounds like the build is doing something wrong. Or some of the hardware is failing. If you ran 2.2 kernels before you may be in for a suprise. 2.4 pushes harder against the hardware which will show on flaky or not 100 percent hardware. > > Often I get oopses in rc.sysinit at about the time it tries to > >activate quota support -- do I need quota support built in? > >Not sure. I have run XFS without any quota code at all and it works >but you might have a problem with /sbin/quotan. OTOH it could be a >build problem. I do suspect that. > > I'm not exactly new at building kernels, but I'm no coder, and my > >inability to build a working kernel with XFS support is frustrating me > >to say the least. Should I post ksymoops output, am I doing something > >obviously wrong, or should I provide more [detailed | organized] > >information? Any help would be greatly appreciated. > >Start with information about the failing build. I would not even look >at run time failures until you are sure that the build is correct. Make sure you uncomment the CC = $(CROSS_COMPILE)kgcc line in Makefile to make sure you are using the right compiler. People have reported that a kernel built with the standard gcc on rh7.x can fail in unexpected yet subtle ways. Thinks like fs corruption and crashes after trying to use that corrupt data. Run a xfs_repair on your fs to see if it's still in one piece. xfs_repair -n can be run on a mounted filesystem to see if it wants to fix something. Good luck. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Jun 15 00:25:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F7P5X11079 for linux-xfs-outgoing; Fri, 15 Jun 2001 00:25:05 -0700 Received: from sun.cn.mvd ([211.99.247.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F7P1k11076 for ; Fri, 15 Jun 2001 00:25:02 -0700 Received: from harris.cn.mvd (IDENT:harrison@harris.cn.mvd [10.1.9.1]) by sun.cn.mvd (8.11.0/8.11.0) with ESMTP id f5F7KMj00512 for ; Fri, 15 Jun 2001 15:20:22 +0800 Date: Fri, 15 Jun 2001 15:26:40 +0800 (CST) From: Harrison Xing X-Sender: To: Subject: XFS module problems -- usage count incorrect Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I use the XFS kernel tree of June 14. When I compile XFS and pagebuf as a module. After I just run "modprobe xfs", the usage count of XFS is 1 and I can't rmmod it. The following is the results of lsmod: lsmod: Module Size Used by xfs 597542 1 pagebuf 33636 0 [xfs] xfs_support 15272 0 [xfs] Anyone know what's the problem? Thanks. -- Best Regards, Harrison From owner-linux-xfs@oss.sgi.com Fri Jun 15 00:48:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F7msL11414 for linux-xfs-outgoing; Fri, 15 Jun 2001 00:48:54 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F7mqk11411 for ; Fri, 15 Jun 2001 00:48:52 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5F7miV03456; Fri, 15 Jun 2001 09:48:44 +0200 Message-Id: <4.3.2.7.2.20010615092458.03931140@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Jun 2001 09:48:41 +0200 To: michael , Joseph Fannin From: Seth Mos Subject: Re: Does XFS require DevFs? Cc: linux-xfs@oss.sgi.com In-Reply-To: <3B2983FF.4050503@vpmonline.com> References: <20010614183114.A24007@zion.rivenstone.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 21:41 14-6-2001 -0600, michael wrote: >devfs is definitely not reuired--in fact, it's the 1st thing i disable >through lilo since I have not spent the time to try to get it to work with >any software or hardware RAID devices (by default, it does not recognize >software or compaq raid devices). For desktops you are better of at the moment :-) >The best success I've had so far is to use the release 1 xfs iso for the >redhat 7.1 install ( 2.4.2-SGI_XFS_1.0 ). I've had all kinds of trouble >trying to get the latest 2.4.5,2.4.6-pre versions to work--xfs installs >ok, just other problems cause random freezes and the system hangs. Once >the system hangs, I have seen a lot of files on the XFS partitions get >zeroed out, or contain binary all throughout them--however, I don't think >XFS is to blame for that--just open, half written files when the kernels >hard freeze on me. This sounds like a kernel compiled with gcc 2.96. The symptoms match. I think I'll add this to the FAQ. >Now I face the task that the 2.4.2 cciss (compaq raid) has a serious >memory leak, so I'm back to trying a recent xfs and 2.4.6 kernel. Something is broken in the CVS at the moment. Don't know what yet. >Good luck--I need it too. Here is some extra, good luck 2 -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Jun 15 00:54:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5F7sfG11551 for linux-xfs-outgoing; Fri, 15 Jun 2001 00:54:41 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5F7sek11548 for ; Fri, 15 Jun 2001 00:54:40 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5F7saV03479; Fri, 15 Jun 2001 09:54:37 +0200 Message-Id: <4.3.2.7.2.20010615095029.02f54ba8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Jun 2001 09:54:33 +0200 To: Harrison Xing , From: Seth Mos Subject: Re: XFS module problems -- usage count incorrect In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:26 15-6-2001 +0800, Harrison Xing wrote: >Hi, > I use the XFS kernel tree of June 14. When I compile XFS and pagebuf >as a module. After I just run "modprobe xfs", the usage count of XFS is 1 >and I >can't rmmod it. The following is the results of lsmod: > >lsmod: >Module Size Used by >xfs 597542 1 >pagebuf 33636 0 [xfs] >xfs_support 15272 0 [xfs] > > Anyone know what's the problem? Thanks. If there is not any XFS filesystem mounted it would mean that the refcount is not being reset after use. The interesting bit is what you did after loading the module. It could be that some other process is not giving it back after it was used. I am unable to fix this, I'll need someone that knows kernels to do so. Seth -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Jun 15 03:00:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FA0pL13453 for linux-xfs-outgoing; Fri, 15 Jun 2001 03:00:51 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FA0mk13450 for ; Fri, 15 Jun 2001 03:00:49 -0700 Received: (qmail 8755 invoked from network); 15 Jun 2001 10:00:45 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 15 Jun 2001 10:00:45 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Harrison Xing cc: linux-xfs@oss.sgi.com Subject: Re: XFS module problems -- usage count incorrect In-reply-to: Your message of "Fri, 15 Jun 2001 15:26:40 +0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Jun 2001 20:00:44 +1000 Message-ID: <7074.992599244@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 15 Jun 2001 15:26:40 +0800 (CST), Harrison Xing wrote: > I use the XFS kernel tree of June 14. When I compile XFS and pagebuf >as a module. After I just run "modprobe xfs", the usage count of XFS is 1 and I >can't rmmod it. The following is the results of lsmod: > >lsmod: >Module Size Used by >xfs 597542 1 >pagebuf 33636 0 [xfs] >xfs_support 15272 0 [xfs] > > Anyone know what's the problem? Thanks. init_xfs_fs() calls dmapi_init() which does MOD_INC_USE_COUNT. Compile XFS without DMAPI support and your problem will disappear. The module related code in dmapi is a hangover from a time when dmapi was a module in its own right instead of being linked into xfs.o. I will remove module related code from dmapi, I will also review grio, to make sure it does not have the same problem. From owner-linux-xfs@oss.sgi.com Fri Jun 15 03:13:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FADnS13701 for linux-xfs-outgoing; Fri, 15 Jun 2001 03:13:49 -0700 Received: from zion.rivenstone.net (dhcp065-024-121-117.columbus.rr.com [65.24.121.117]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FADmk13698 for ; Fri, 15 Jun 2001 03:13:48 -0700 Received: by zion.rivenstone.net (Postfix, from userid 500) id BDCE9630A5; Fri, 15 Jun 2001 01:20:12 -0400 (EDT) Date: Fri, 15 Jun 2001 01:20:12 -0400 From: Joseph Fannin To: linux-xfs@oss.sgi.com Subject: Re: Does XFS require DevFs? Message-ID: <20010615012012.A24835@zion.rivenstone.net> References: <20010614183114.A24007@zion.rivenstone.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010614183114.A24007@zion.rivenstone.net>; from jhf@rivenstone.net on Thu, Jun 14, 2001 at 06:31:14PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Jun 14, 2001 at 06:31:14PM -0400, Joseph Fannin wrote: > I've searched the archives but found no answer to this question: > Does XFS require DevFS? Or can I build a kernel for my system > (installed from the XFS RH7.1 .iso) that does not include devfs > without having problems? > > I've been completely unable to build a working kernel using either > the RH-2.96 or egcs -- the build either fails or gives me a kernel > that produces random segfaults, oopsen, and fs corruption. I've tried > the .src.rpm on the .iso, the 2.4.3 patches and the CVS devel tree. > Thanks you everyone for your replies, and for putting up with my frustration. Now that I know that my problem wasn't a misconfiguration I have built two kernels now with xfs support -- v2.4.3 with the 1.0 release patches, built with egcs. Both machines appear to be working fine. The problem was definitely compiler related -- even the latest release of 2.96 didn't work for me, though I read somewhere that it did. The redhat-patched kernel in the src.rpm didn't build with egcs (kgcc) but a vanilla 2.4.3 with xfs patches applied built fine. RedHat builds and tests their kernels with 2.96, so I suspect one of their patches doesn't like egcs. (The failure was an "internal compiler error" that happened twice, the second again in the same place, after a `make clean`) The other build failures I got were likely due to a combination of fs corruption (there were some complaints about missing files) and the wrong compiler. The hardware on this machine is solid, though I have another with flaky memory; the problem was 100% gcc-2.96. So don't use it for XFS kernels. :-) -- Joseph Fannin jhf@rivenstone.net "Bull in pure form is rare; there is usually some contamination by data." -- William Graves Perry Jr. From owner-linux-xfs@oss.sgi.com Fri Jun 15 03:24:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FAOmX13966 for linux-xfs-outgoing; Fri, 15 Jun 2001 03:24:48 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FAOkk13963 for ; Fri, 15 Jun 2001 03:24:46 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5FAOhV04357; Fri, 15 Jun 2001 12:24:43 +0200 Message-Id: <4.3.2.7.2.20010615122328.0376def0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Jun 2001 12:24:40 +0200 To: Joseph Fannin , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Does XFS require DevFs? In-Reply-To: <20010615012012.A24835@zion.rivenstone.net> References: <20010614183114.A24007@zion.rivenstone.net> <20010614183114.A24007@zion.rivenstone.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 01:20 15-6-2001 -0400, Joseph Fannin wrote: >On Thu, Jun 14, 2001 at 06:31:14PM -0400, Joseph Fannin wrote: > > I've searched the archives but found no answer to this question: > > Does XFS require DevFS? Or can I build a kernel for my system > > (installed from the XFS RH7.1 .iso) that does not include devfs > > without having problems? > > > > I've been completely unable to build a working kernel using either > > the RH-2.96 or egcs -- the build either fails or gives me a kernel > > that produces random segfaults, oopsen, and fs corruption. I've tried > > the .src.rpm on the .iso, the 2.4.3 patches and the CVS devel tree. > > > > Thanks you everyone for your replies, and for putting up with my >frustration. Now that I know that my problem wasn't a misconfiguration >I have built two kernels now with xfs support -- v2.4.3 with the 1.0 >release patches, built with egcs. Both machines appear to be working fine. > > The problem was definitely compiler related -- even the latest release >of 2.96 didn't work for me, though I read somewhere that it did. The >redhat-patched kernel in the src.rpm didn't build with egcs (kgcc) but >a vanilla 2.4.3 with xfs patches applied built fine. RedHat builds and >tests their kernels with 2.96, so I suspect one of their patches doesn't >like egcs. (The failure was an "internal compiler error" that happened >twice, the second again in the same place, after a `make clean`) Internal compiler errors are mostly related to some sort of hardware failure. It just does not say what. > The other build failures I got were likely due to a combination of fs >corruption (there were some complaints about missing files) and the wrong >compiler. The hardware on this machine is solid, though I have another with >flaky memory; the problem was 100% gcc-2.96. So don't use it for XFS >kernels. :-) That is known and is in the FAQ afaik. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Jun 15 05:11:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FCBg915296 for linux-xfs-outgoing; Fri, 15 Jun 2001 05:11:42 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FCBek15293 for ; Fri, 15 Jun 2001 05:11:41 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id FAA00350 for ; Fri, 15 Jun 2001 05:11:39 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id WAA24648; Fri, 15 Jun 2001 22:11:25 +1000 Date: Fri, 15 Jun 2001 22:11:25 +1000 From: Keith Owens Message-Id: <200106151211.WAA24648@sherman.melbourne.sgi.com> Subject: TAKE - Remove old module code from XFS Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Both dmapi and grio contained spurious MOD_INC_USE_COUNT calls, from when the code used to be free standing modules. As part of xfs.o, these calls disturb the use count on xfs.o. Date: Fri Jun 15 05:09:10 PDT 2001 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:96950a linux/fs/xfs/xfs_grio.c - 1.87 linux/fs/xfs/dmapi/dmapi_sysent.c - 1.9 From owner-linux-xfs@oss.sgi.com Fri Jun 15 05:13:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FCDcP15396 for linux-xfs-outgoing; Fri, 15 Jun 2001 05:13:38 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FCDbk15393 for ; Fri, 15 Jun 2001 05:13:37 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id FAA28749 for ; Fri, 15 Jun 2001 05:13:33 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id WAA24724; Fri, 15 Jun 2001 22:13:33 +1000 Date: Fri, 15 Jun 2001 22:13:33 +1000 From: Keith Owens Message-Id: <200106151213.WAA24724@sherman.melbourne.sgi.com> Subject: TAKE - Remove warning from DAC960.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk DAC960.c needed #include for the definition of blk_ioctl. Date: Fri Jun 15 05:12:13 PDT 2001 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:96951a linux/drivers/block/DAC960.c - 1.27 From owner-linux-xfs@oss.sgi.com Fri Jun 15 05:38:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FCcSb15830 for linux-xfs-outgoing; Fri, 15 Jun 2001 05:38:28 -0700 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FCcRk15827 for ; Fri, 15 Jun 2001 05:38:27 -0700 Received: by seraph2.lerc.nasa.gov; id IAA00914; Fri, 15 Jun 2001 08:38:26 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma000884; Fri, 15 Jun 01 08:38:08 -0400 Received: from cecil.lerc.nasa.gov (cecil.lerc.nasa.gov [139.88.214.20]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA13271; Fri, 15 Jun 2001 08:38:03 -0400 (EDT) Received: from localhost (daamato@localhost) by cecil.lerc.nasa.gov with ESMTP (SGI-8.9.3/2.01-local) id IAA35095; Fri, 15 Jun 2001 08:38:03 -0400 (EDT) Date: Fri, 15 Jun 2001 08:38:03 -0400 From: Dino A Amato To: , Subject: info and feedback XFS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello - We have been using the Linux XFS on some machines here and it works great! A project is going to be started and I wanted to get some feedback before we start. The project will entail 2 - Quad Proc boxes with RAIDS attached and doing number-crunching only and light I/O. Are there any issues with Quad Procs? I saw your Docs and you say you have gone to 512 cpu with no problems. IS SGI going to keep making ISO images to create XFS on root during install and are they going make new ones when RedHat releases new kernels and releases? You wweb site mentioned June that you may get XFS included in the source tree. How close are you to getting that done or do you have a guess when it will be included as dist from RedHat? Anyway great job and keep up the great work. I hope to hear from you. Thank You ----------------------------------------------------------------- Dino Amato | Phone: 216.433.5548 Glenn Research Center | ----------------------------------------------------------------- Linux Now! .....Because friends don't let friends use Microsoft ----------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Fri Jun 15 06:12:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FDCLG16461 for linux-xfs-outgoing; Fri, 15 Jun 2001 06:12:21 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FDCJk16458 for ; Fri, 15 Jun 2001 06:12:19 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5FDCCV05344; Fri, 15 Jun 2001 15:12:12 +0200 Message-Id: <4.3.2.7.2.20010615150443.039e1840@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Jun 2001 15:12:08 +0200 To: Dino A Amato , , From: Seth Mos Subject: Re: info and feedback XFS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 08:38 15-6-2001 -0400, Dino A Amato wrote: >Hello - >We have been using the Linux XFS on some machines here and it works great! > >A project is going to be started and I wanted to get some feedback before >we start. The project will entail 2 - Quad Proc boxes with RAIDS attached >and doing number-crunching only and light I/O. > >Are there any issues with Quad Procs? I saw your Docs and you say you have >gone to 512 cpu with no problems. That is under Irix on SGI MIPS machines. On intel machines the kernel itself is probably the limiting factor. >IS SGI going to keep making ISO images to create XFS on root during >install and are they going make new ones when RedHat releases new kernels >and releases? The 1.0.1 release is worked at but might take some time to complete since the recent cuts in workforce at SGI. >You wweb site mentioned June that you may get XFS included in the source >tree. How close are you to getting that done or do you have a guess when >it will be included as dist from RedHat? Where does the website mention june as a date that the kernel is included? There is little piece about linus tree inclusion in the faq. In short, there are still to much places where the XFS patch is intrusive on the Linus kernel. And from what I understand there are some things that need to be changed before it can be sent to linus without instant rejection :-) Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Jun 15 06:23:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FDNEn16843 for linux-xfs-outgoing; Fri, 15 Jun 2001 06:23:14 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FDNBk16840 for ; Fri, 15 Jun 2001 06:23:11 -0700 Received: (qmail 10026 invoked from network); 15 Jun 2001 13:23:09 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 15 Jun 2001 13:23:09 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Dino A Amato cc: linux-xfs@oss.sgi.com Subject: Re: info and feedback XFS In-reply-to: Your message of "Fri, 15 Jun 2001 08:38:03 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Jun 2001 23:23:08 +1000 Message-ID: <8511.992611388@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 15 Jun 2001 08:38:03 -0400, Dino A Amato wrote: >Are there any issues with Quad Procs? I saw your Docs and you say you have >gone to 512 cpu with no problems. 4 is fine. >IS SGI going to keep making ISO images to create XFS on root during >install and are they going make new ones when RedHat releases new kernels >and releases? People are working on a new release of XFS, against current Redhat. Or you can use the XFS CVS tree which is up to 2.4.6-pre3. >You wweb site mentioned June that you may get XFS included in the source >tree. How close are you to getting that done or do you have a guess when >it will be included as dist from RedHat? Getting it into the source tree depends on Linus's response. We keep sending him patches but so far there has been no response. From owner-linux-xfs@oss.sgi.com Fri Jun 15 06:27:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FDRjm17045 for linux-xfs-outgoing; Fri, 15 Jun 2001 06:27:45 -0700 Received: from seraph2.lerc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FDRhk17037 for ; Fri, 15 Jun 2001 06:27:43 -0700 Received: by seraph2.lerc.nasa.gov; id JAA06360; Fri, 15 Jun 2001 09:27:42 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma006332; Fri, 15 Jun 01 09:27:07 -0400 Received: from cecil.lerc.nasa.gov (cecil.lerc.nasa.gov [139.88.214.20]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA21608; Fri, 15 Jun 2001 09:27:06 -0400 (EDT) Received: from localhost (daamato@localhost) by cecil.lerc.nasa.gov with ESMTP (SGI-8.9.3/2.01-local) id JAA37629; Fri, 15 Jun 2001 09:27:06 -0400 (EDT) Date: Fri, 15 Jun 2001 09:27:06 -0400 From: Dino A Amato To: Seth Mos cc: , Subject: Re: info and feedback XFS In-Reply-To: <4.3.2.7.2.20010615150443.039e1840@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth- Thanks responding so quick! In the FAQ's it mentioned maybe June: "are still some points (mid june) that need to be resolved before it can be sent to Linus. Maybe if we are lucky it might even be included a" Since we are a BIG SGI user her, we are aware of the cuts at SGI and I hope it works for all of you. THanks for all the replies I have gotten. ----------------------------------------------------------------- Dino Amato | Phone: 216.433.5548 ----------------------------------------------------------------- Linux Now! .....Because friends don't let friends use Microsoft ----------------------------------------------------------------- On Fri, 15 Jun 2001, Seth Mos wrote: > At 08:38 15-6-2001 -0400, Dino A Amato wrote: > >Hello - > >We have been using the Linux XFS on some machines here and it works great! > > > >A project is going to be started and I wanted to get some feedback before > >we start. The project will entail 2 - Quad Proc boxes with RAIDS attached > >and doing number-crunching only and light I/O. > > > >Are there any issues with Quad Procs? I saw your Docs and you say you have > >gone to 512 cpu with no problems. > > That is under Irix on SGI MIPS machines. On intel machines the kernel > itself is probably the limiting factor. > > >IS SGI going to keep making ISO images to create XFS on root during > >install and are they going make new ones when RedHat releases new kernels > >and releases? > > The 1.0.1 release is worked at but might take some time to complete since > the recent cuts in workforce at SGI. > > >You wweb site mentioned June that you may get XFS included in the source > >tree. How close are you to getting that done or do you have a guess when > >it will be included as dist from RedHat? > > Where does the website mention june as a date that the kernel is included? > There is little piece about linus tree inclusion in the faq. > > In short, there are still to much places where the XFS patch is intrusive > on the Linus kernel. And from what I understand there are some things that > need to be changed before it can be sent to linus without instant rejection :-) > > Cheers > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. > From owner-linux-xfs@oss.sgi.com Fri Jun 15 06:48:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FDmdH17502 for linux-xfs-outgoing; Fri, 15 Jun 2001 06:48:39 -0700 Received: from studsv07.studserv.uni-stuttgart.de (studsv07.studserv.uni-stuttgart.de [129.69.21.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FDmak17499 for ; Fri, 15 Jun 2001 06:48:37 -0700 Received: from ysabell.wh.vaih [129.69.166.244] by studsv07.studserv.uni-stuttgart.de with ESMTP (SMTPD32-6.06) id A2332F11004A; Fri, 15 Jun 2001 15:48:35 +0200 Received: from marcelo by ysabell.wh.vaih with local (Exim 3.22 #1 (Debian)) id 15Atxl-0000lx-00 for ; Fri, 15 Jun 2001 15:48:37 +0200 Date: Fri, 15 Jun 2001 15:48:37 +0200 From: "Marcelo E. Magallon" To: linux-xfs@oss.sgi.com Subject: stress tests looking for acl.h in acl/ Message-ID: <20010615154837.A2929@ysabell.wh.vaih> 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.3.18i X-Operating-System: Linux ysabell 2.4.4-xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, root@bolero test/xfstests # ./configure [...] checking for acl/acl.h... no root@bolero test/xfstests # cat config.log [...] configure:1628: checking for acl/acl.h configure:1638: gcc -E -I/usr/include/xfs conftest.c >/dev/null 2>conftest.out configure:1634: acl/acl.h: No such file or directory configure: failed program was: #line 1633 "configure" #include "confdefs.h" #include Which comes from configure.in: AC_CHECK_HEADER(acl/acl.h,, [ but: root@bolero test/xfstests # rpm -ql acl-devel [...] /usr/include/sys/acl.h -- Marcelo From owner-linux-xfs@oss.sgi.com Fri Jun 15 06:49:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FDn9117597 for linux-xfs-outgoing; Fri, 15 Jun 2001 06:49:09 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FDn8k17593 for ; Fri, 15 Jun 2001 06:49:08 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5FDmvV05496; Fri, 15 Jun 2001 15:48:58 +0200 Message-Id: <4.3.2.7.2.20010615154647.038fc298@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Jun 2001 15:48:54 +0200 To: Dino A Amato From: Seth Mos Subject: Re: info and feedback XFS Cc: , In-Reply-To: References: <4.3.2.7.2.20010615150443.039e1840@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 09:27 15-6-2001 -0400, Dino A Amato wrote: >Seth- >Thanks responding so quick! > >In the FAQ's it mentioned maybe June: > >"are still some points (mid june) that need to be resolved before it can >be sent to Linus. Maybe if we are lucky it might even be included a" The (mid-june) refers to the point in time that the FAQ was written. So if you read the FAQ in august you would see that the faq was that old. To avoid miss interpretations I'll take it out then. >Since we are a BIG SGI user her, we are aware of the cuts at SGI and I >hope it works for all of you. It does for me :) Seth -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Jun 15 07:05:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FE5oh18047 for linux-xfs-outgoing; Fri, 15 Jun 2001 07:05:50 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FE5mk18044 for ; Fri, 15 Jun 2001 07:05:48 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5FE5cV05542; Fri, 15 Jun 2001 16:05:41 +0200 Message-Id: <4.3.2.7.2.20010615160447.038f9d78@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Jun 2001 16:05:35 +0200 To: "Marcelo E. Magallon" , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: stress tests looking for acl.h in acl/ In-Reply-To: <20010615154837.A2929@ysabell.wh.vaih> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:48 15-6-2001 +0200, Marcelo E. Magallon wrote: >Hi, > > root@bolero test/xfstests # ./configure > [...] > checking for acl/acl.h... no > > root@bolero test/xfstests # cat config.log > [...] > configure:1628: checking for acl/acl.h > configure:1638: gcc -E -I/usr/include/xfs conftest.c >/dev/null > 2>conftest.out > configure:1634: acl/acl.h: No such file or directory > configure: failed program was: > #line 1633 "configure" > #include "confdefs.h" > #include > > Which comes from configure.in: > > AC_CHECK_HEADER(acl/acl.h,, [ > > but: > > root@bolero test/xfstests # rpm -ql acl-devel > [...] > /usr/include/sys/acl.h Ok, there was a recent move of the acl include files and I think they forgot to update the tests. Bye -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Jun 15 07:08:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FE81B18172 for linux-xfs-outgoing; Fri, 15 Jun 2001 07:08:01 -0700 Received: from portal.east.saic.com (portal.east.saic.com [198.151.13.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FE80k18169 for ; Fri, 15 Jun 2001 07:08:00 -0700 Received: from mclmx.saic.com by portal.east.saic.com via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 15 Jun 2001 14:08:00 UT Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com; Fri, 15 Jun 2001 10:07:47 -0400 Received: from mclhub.mail.saic.com ([149.8.64.10]) by mcl-its-ieg01.mail.saic.com (NAVIEG 2.1 bld 73) with SMTP id M2001061510025211650 ; Fri, 15 Jun 2001 10:02:52 -0400 Received: from mcl-atg-exs01.apo.saic.com by mclmx.mail.saic.com with ESMTP; Fri, 15 Jun 2001 10:07:46 -0400 Received: from apo.saic.com (trident.apo.saic.com [149.8.95.155]) by mcl-atg-exs01.apo.saic.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MT17WYAH; Fri, 15 Jun 2001 10:06:56 -0400 Message-Id: <3B2A15A3.2B7176C0@apo.saic.com> Date: Fri, 15 Jun 2001 10:03:15 -0400 From: Tim Wait Organization: SAIC X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: cvs error Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk FYI: U linux-2.4-xfs/linux/fs/xfs/xfs_btree.c U linux-2.4-xfs/linux/fs/xfs/xfs_btree.h U linux-2.4-xfs/linux/fs/xfs/xfs_buf.h U linux-2.4-xfs/linux/fs/xfs/xfs_buf_item.c cvs [server aborted]: EOF in key in RCS file /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_buf_item.h,v [wait@vortex wait]$ date Fri Jun 15 10:13:40 EDT 2001 BTW, great job with the XFS port, runs great on my 300 GB raid system. ------------ wait@apo.saic.com -------------- Tim Wait SAIC - Advanced Technology Group 1710 SAIC Drive MS 2-3-1, McLean VA 22102 Phone: (703) 676-7108, fax (703) 676-5509 From owner-linux-xfs@oss.sgi.com Fri Jun 15 07:24:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FEOMx18677 for linux-xfs-outgoing; Fri, 15 Jun 2001 07:24:22 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FEOKk18674 for ; Fri, 15 Jun 2001 07:24:20 -0700 Received: (qmail 10513 invoked from network); 15 Jun 2001 14:24:17 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 15 Jun 2001 14:24:17 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Marcelo E. Magallon" cc: linux-xfs@oss.sgi.com Subject: Re: stress tests looking for acl.h in acl/ In-reply-to: Your message of "Fri, 15 Jun 2001 15:48:37 +0200." <20010615154837.A2929@ysabell.wh.vaih> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 16 Jun 2001 00:24:16 +1000 Message-ID: <9056.992615056@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 15 Jun 2001 15:48:37 +0200, "Marcelo E. Magallon" wrote: > root@bolero test/xfstests # ./configure > [...] > checking for acl/acl.h... no It moved to sys/acl.h. cd perl -i -ple 's:acl/acl.h:sys/acl.h:;' acl/man/man5/acl.5 xfstests/configure.in From owner-linux-xfs@oss.sgi.com Fri Jun 15 07:26:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FEQj318779 for linux-xfs-outgoing; Fri, 15 Jun 2001 07:26:45 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FEQik18775 for ; Fri, 15 Jun 2001 07:26:44 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA02899 for ; Fri, 15 Jun 2001 07:27:06 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id AAA27024; Sat, 16 Jun 2001 00:26:41 +1000 Date: Sat, 16 Jun 2001 00:26:41 +1000 From: Keith Owens Message-Id: <200106151426.AAA27024@sherman.melbourne.sgi.com> Subject: TAKE - Fix old references to acl/acl.h Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Fix old references to acl/acl.h Date: Fri Jun 15 07:25:43 PDT 2001 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:96955a cmd/acl/man/man5/acl.5 - 1.4 cmd/xfstests/configure.in - 1.8 From owner-linux-xfs@oss.sgi.com Fri Jun 15 08:32:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FFW4L19662 for linux-xfs-outgoing; Fri, 15 Jun 2001 08:32:04 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FFW3k19658 for ; Fri, 15 Jun 2001 08:32:03 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f5FFVtaJ008831; Fri, 15 Jun 2001 10:31:55 -0500 (CDT) Message-ID: <3B5020A1.5FB0A0B7@thebarn.com> Date: Sat, 14 Jul 2001 05:36:17 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Tim Wait CC: linux-xfs@oss.sgi.com Subject: Re: cvs error References: <3B2A15A3.2B7176C0@apo.saic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Tim Wait wrote: > FYI: > > U linux-2.4-xfs/linux/fs/xfs/xfs_btree.c > U linux-2.4-xfs/linux/fs/xfs/xfs_btree.h > U linux-2.4-xfs/linux/fs/xfs/xfs_buf.h > U linux-2.4-xfs/linux/fs/xfs/xfs_buf_item.c > cvs [server aborted]: EOF in key in RCS file > /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_buf_item.h,v > [wait@vortex wait]$ date > Fri Jun 15 10:13:40 EDT 2001 > I nuked the tree and started the gen process from scratch. It should be fixed in an hour or so. From owner-linux-xfs@oss.sgi.com Fri Jun 15 09:39:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FGdQr20439 for linux-xfs-outgoing; Fri, 15 Jun 2001 09:39:26 -0700 Received: from sphinx.druber.com ([216.129.135.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FGdOk20436 for ; Fri, 15 Jun 2001 09:39:25 -0700 Received: from SWARTZ-D.druber.com (SWARTZ-D.cac.stratus.com [134.111.43.114]) by sphinx.druber.com (Postfix) with ESMTP id 98BD0855A for ; Fri, 15 Jun 2001 12:32:50 -0400 (EDT) Message-Id: <5.1.0.14.2.20010615123541.03fc5450@druber-gw.lightband.com> X-Sender: dswartz@druber-gw.lightband.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Jun 2001 12:39:17 -0400 To: linux-xfs@oss.sgi.com From: Dan Swartzendruber Subject: cvs and cvsup problems? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk maybe i'm stupid, but i'm seeing really odd things with both tools (getting development trees): cvs: it gets a complete linux tree, but there is no top-level makefile. it isn't clear to me what to do, at that point. cvsup: it gets a complete tree, but there are all kinds of revision files (the ',v' suffixes), and attempts to build get weird errors from make. i don't remember seeing either of these behaviors before. From owner-linux-xfs@oss.sgi.com Fri Jun 15 09:54:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FGsf420820 for linux-xfs-outgoing; Fri, 15 Jun 2001 09:54:41 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FGsdk20817 for ; Fri, 15 Jun 2001 09:54:39 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA07829 for ; Fri, 15 Jun 2001 09:54:35 -0700 (PDT) mail_from (seberino@sgi.com) Received: from mtv-btc-003e--n.corp.sgi.com (mtv-btc-003e--n.corp.sgi.com [192.26.60.74]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA85745; Fri, 15 Jun 2001 09:54:07 -0700 (PDT) Received: by mtv-btc-003e--n.corp.sgi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 09:55:20 -0700 Message-ID: <5D8FC5BAF25CD41188DD0090276D201C1DB224@mtv-btc-003e--n.corp.sgi.com> From: Charles Seberino To: "'Seth Mos'" , Vernon McPherron Cc: linux-xfs@oss.sgi.com Subject: RE: ssh cvs access? Date: Fri, 15 Jun 2001 09:55:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Vernon and Seth, Works great. This is what I use to run cvs through (sgi's) firewall using ssh. setenv CVSROOT ':pserver:cvs@oss.sgi.com:/cvs' setenv CVS_RSH ssh setenv SOCKS_SERVER sgigate.sgi.com (only works for sgi people - and socks aware ssh) Then I just preface all my cvs commands with 'runsocks' (from socks5 package) such as: runsocks cvs update Don't know if you use socks or not, but oss does work with ssh. Hope this helps. Chuck > -----Original Message----- > From: Seth Mos [mailto:knuffie@xs4all.nl] > Sent: Thursday, June 14, 2001 3:40 PM > To: Vernon McPherron > Cc: linux-xfs@oss.sgi.com > Subject: Re: ssh cvs access? > > > On Thu, 14 Jun 2001, Vernon McPherron wrote: > > > At work I'm unable to update my cvs tree via cvs. I'm > guessing it is > > because of the firewall. XFree86 has cvs via ssh and that > works great, > > is there any way to use the XFS cvs server via ssh? > > Not that I know of. Maybe we could set up a second cvs server > in europe > for anonmous CVS checkouts and updates. > > I'll look into it. I will have to wathc the traffic though. > > Bye > Seth > > From owner-linux-xfs@oss.sgi.com Fri Jun 15 10:19:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FHJwC21269 for linux-xfs-outgoing; Fri, 15 Jun 2001 10:19:58 -0700 Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FHJuk21266 for ; Fri, 15 Jun 2001 10:19:56 -0700 Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA13202 for ; Fri, 15 Jun 2001 10:19:24 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id KAA16782 for ; Fri, 15 Jun 2001 10:19:54 -0700 (PDT) Received: from pipcws.ca.boeing.com by blv-hub-01.boeing.com with ESMTP; Fri, 15 Jun 2001 10:19:39 -0700 Received: from pipcws.ca.boeing.com (e218766.evt.boeing.com [136.203.14.68]) by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id KAA159698; Fri, 15 Jun 2001 10:19:39 -0700 Message-Id: <3B2A43AA.4000704@pipcws.ca.boeing.com> Date: Fri, 15 Jun 2001 10:19:38 -0700 From: Ric Tibbetts User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9) Gecko/20010505 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Dan Swartzendruber CC: jtrostel@connex.com, linux-xfs@oss.sgi.com Subject: Re: XFS/Linux 1.1?? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dan Swartzendruber wrote: > On Wed, 13 Jun 2001 jtrostel@connex.com wrote: > > >>XFmail is threaded, does IMAP and is free! >> > > i'll check it out, thanks! > > > Netscape & Mozilla mail are both threaded, support IMAP, and Netscape is already on your system. :) Ric From owner-linux-xfs@oss.sgi.com Fri Jun 15 10:40:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FHeHq21877 for linux-xfs-outgoing; Fri, 15 Jun 2001 10:40:17 -0700 Received: from sws5.ctd.ornl.gov (sws5.ctd.ornl.gov [160.91.20.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FHeFk21874 for ; Fri, 15 Jun 2001 10:40:15 -0700 Received: (qmail 18958 invoked by uid 3995); 15 Jun 2001 17:39:51 -0000 From: "Dave Sill" Mail-Followup-To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Message-ID: <15146.18535.785412.549090@sws5.ctd.ornl.gov> Date: Fri, 15 Jun 2001 13:39:51 -0400 To: linux-xfs@oss.sgi.com Subject: NFS/pwd probs w/today's CVS dist X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Organization: Oak Ridge National Lab, Oak Ridge, Tenn., USA X-Face: "p~Q]mg{;e*}YR|)&Q/&Q\*~5UWfZX34;5M Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I installed the development version from cvs (checked out at 12:30 EDT) and exported an XFS filesystem to an SGI for testing. Attempting to build perl, I discovered that /bin/pwd was returning the wrong thing, although the bash built-in pwd worked right: $ pwd /malachite/test/perl-5.6.1 $ /bin/pwd /perl-5.6.1 $ uname -aR IRIX64 daacl 6.5 6.5.11m 01101245 IP27 What gives? -Dave From owner-linux-xfs@oss.sgi.com Fri Jun 15 11:16:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FIGM123137 for linux-xfs-outgoing; Fri, 15 Jun 2001 11:16:22 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FIGKk23134 for ; Fri, 15 Jun 2001 11:16:21 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f5FIGJaJ010564; Fri, 15 Jun 2001 13:16:19 -0500 (CDT) Message-ID: <3B504729.61B68C57@thebarn.com> Date: Sat, 14 Jul 2001 08:20:41 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Dave Sill CC: linux-xfs@oss.sgi.com Subject: Re: NFS/pwd probs w/today's CVS dist References: <15146.18535.785412.549090@sws5.ctd.ornl.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dave Sill wrote: > I installed the development version from cvs (checked out at 12:30 > EDT) and exported an XFS filesystem to an SGI for testing. Attempting > to build perl, I discovered that /bin/pwd was returning the wrong > thing, although the bash built-in pwd worked right: what version of irix are you at? I've seen this problem with an older version of an irix 6.5.5 I believe. Note this was a problem at one point, some of the NFS fields were not correctly filled out, but it should have been fixed some time back. > > > $ pwd > /malachite/test/perl-5.6.1 > $ /bin/pwd > /perl-5.6.1 > $ uname -aR > IRIX64 daacl 6.5 6.5.11m 01101245 IP27 > > What gives? > > -Dave From owner-linux-xfs@oss.sgi.com Fri Jun 15 11:19:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FIJCA23601 for linux-xfs-outgoing; Fri, 15 Jun 2001 11:19:12 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FIJBk23590 for ; Fri, 15 Jun 2001 11:19:11 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f5FIJ9aJ010641; Fri, 15 Jun 2001 13:19:09 -0500 (CDT) Message-ID: <3B5047D3.59F689A2@thebarn.com> Date: Sat, 14 Jul 2001 08:23:31 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Dan Swartzendruber CC: linux-xfs@oss.sgi.com Subject: Re: cvs and cvsup problems? References: <5.1.0.14.2.20010615123541.03fc5450@druber-gw.lightband.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dan Swartzendruber wrote: > maybe i'm stupid, but i'm seeing really odd things with both tools (getting > development trees): > > cvs: it gets a complete linux tree, but there is no top-level makefile. it > isn't clear to me what to do, at that point. > > cvsup: it gets a complete tree, but there are all kinds of revision files (the > ',v' suffixes), and attempts to build get weird errors from make. The ,v files are RCS files. Make sure you have the "tag=." field in your sup file if you want the the actuall files. > > > i don't remember seeing either of these behaviors before. From owner-linux-xfs@oss.sgi.com Fri Jun 15 11:19:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FIJhZ23753 for linux-xfs-outgoing; Fri, 15 Jun 2001 11:19:43 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FIJhk23749 for ; Fri, 15 Jun 2001 11:19:43 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA20594 for ; Fri, 15 Jun 2001 11:19:39 -0700 (PDT) mail_from (tbd@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2140874; Fri, 15 Jun 2001 13:18:24 -0500 (CDT) Received: from fsgi158.americas.sgi.com (fsgi158.americas.sgi.com [128.162.184.29]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA75443; Fri, 15 Jun 2001 13:18:24 -0500 (CDT) From: Tad Dolphay Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id NAA13344; Fri, 15 Jun 2001 13:18:24 -0500 (CDT) Message-Id: <200106151818.NAA13344@fsgi158.americas.sgi.com> Subject: Re: NFS/pwd probs w/today's CVS dist To: ds-linux-xfs@sws5.ctd.ornl.gov (Dave Sill) Date: Fri, 15 Jun 2001 13:18:23 -0500 (CDT) Cc: linux-xfs@oss.sgi.com In-Reply-To: <15146.18535.785412.549090@sws5.ctd.ornl.gov> from "Dave Sill" at Jun 15, 2001 01:39:51 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > I installed the development version from cvs (checked out at 12:30 > EDT) and exported an XFS filesystem to an SGI for testing. Attempting > to build perl, I discovered that /bin/pwd was returning the wrong > thing, although the bash built-in pwd worked right: > > $ pwd > /malachite/test/perl-5.6.1 > $ /bin/pwd > /perl-5.6.1 > $ uname -aR > IRIX64 daacl 6.5 6.5.11m 01101245 IP27 > > What gives? > This is actually a known IRIX problem with handling variable size file handles that will be fixed in 6.5.13. Tad From owner-linux-xfs@oss.sgi.com Fri Jun 15 11:23:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FINBL24285 for linux-xfs-outgoing; Fri, 15 Jun 2001 11:23:11 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FINAk24274 for ; Fri, 15 Jun 2001 11:23:10 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f5FIN5aJ010837; Fri, 15 Jun 2001 13:23:05 -0500 (CDT) Message-ID: <3B5048BF.D2A26E54@thebarn.com> Date: Sat, 14 Jul 2001 08:27:27 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Charles Seberino CC: "'Seth Mos'" , Vernon McPherron , linux-xfs@oss.sgi.com Subject: Re: ssh cvs access? References: <5D8FC5BAF25CD41188DD0090276D201C1DB224@mtv-btc-003e--n.corp.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Charles Seberino wrote: > Vernon and Seth, > > Works great. > > This is what I use to run cvs through (sgi's) firewall using ssh. > > setenv CVSROOT ':pserver:cvs@oss.sgi.com:/cvs' > setenv CVS_RSH ssh Note the CVS_RSH variable is only used with the "ext" directive the "pserver" directive indicates the use of port 2401. In other words it isn't necessary to set CVS_RSH. Otherwise yes this is the correct way to get through a socks firewall. > > setenv SOCKS_SERVER sgigate.sgi.com (only works for sgi people - and socks > aware ssh) > > Then I just preface all my cvs commands with 'runsocks' (from socks5 > package) such as: > > runsocks cvs update > > Don't know if you use socks or not, but oss does work with ssh. > > Hope this helps. > > Chuck > > > -----Original Message----- > > From: Seth Mos [mailto:knuffie@xs4all.nl] > > Sent: Thursday, June 14, 2001 3:40 PM > > To: Vernon McPherron > > Cc: linux-xfs@oss.sgi.com > > Subject: Re: ssh cvs access? > > > > > > On Thu, 14 Jun 2001, Vernon McPherron wrote: > > > > > At work I'm unable to update my cvs tree via cvs. I'm > > guessing it is > > > because of the firewall. XFree86 has cvs via ssh and that > > works great, > > > is there any way to use the XFS cvs server via ssh? > > > > Not that I know of. Maybe we could set up a second cvs server > > in europe > > for anonmous CVS checkouts and updates. > > > > I'll look into it. I will have to wathc the traffic though. > > > > Bye > > Seth > > > > From owner-linux-xfs@oss.sgi.com Fri Jun 15 11:37:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FIbLE25358 for linux-xfs-outgoing; Fri, 15 Jun 2001 11:37:21 -0700 Received: from sphinx.druber.com ([216.129.135.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FIbKk25355 for ; Fri, 15 Jun 2001 11:37:20 -0700 Received: from SWARTZ-D.druber.com (SWARTZ-D.cac.stratus.com [134.111.43.114]) by sphinx.druber.com (Postfix) with ESMTP id 8719E855A; Fri, 15 Jun 2001 14:30:42 -0400 (EDT) Message-Id: <5.1.0.14.2.20010615143528.03fc1980@druber-gw.lightband.com> X-Sender: dswartz@druber-gw.lightband.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Jun 2001 14:37:08 -0400 To: Russell Cattelan From: Dan Swartzendruber Subject: Re: cvs and cvsup problems? Cc: linux-xfs@oss.sgi.com In-Reply-To: <3B5047D3.59F689A2@thebarn.com> References: <5.1.0.14.2.20010615123541.03fc5450@druber-gw.lightband.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 08:23 AM 7/14/2001 -0500, Russell Cattelan wrote: >Dan Swartzendruber wrote: > > > maybe i'm stupid, but i'm seeing really odd things with both tools (getting > > development trees): > > > > cvs: it gets a complete linux tree, but there is no top-level makefile. it > > isn't clear to me what to do, at that point. > > > > cvsup: it gets a complete tree, but there are all kinds of revision > files (the > > ',v' suffixes), and attempts to build get weird errors from make. > >The ,v files are RCS files. >Make sure you have the "tag=." field in your sup file if you want >the the actuall files. i guess i was confused by the webpage directions. it (cvsup howto) said that if you want to track the development tree, remove the 'tag=.' from the cvsup file. From owner-linux-xfs@oss.sgi.com Fri Jun 15 11:42:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FIgYB25491 for linux-xfs-outgoing; Fri, 15 Jun 2001 11:42:34 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FIgWk25486 for ; Fri, 15 Jun 2001 11:42:33 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f5FIgUaJ011252; Fri, 15 Jun 2001 13:42:30 -0500 (CDT) Message-ID: <3B504D4C.833883F@thebarn.com> Date: Sat, 14 Jul 2001 08:46:52 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Tad Dolphay CC: Dave Sill , linux-xfs@oss.sgi.com Subject: Re: NFS/pwd probs w/today's CVS dist References: <200106151818.NAA13344@fsgi158.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Tad Dolphay wrote: > > > > I installed the development version from cvs (checked out at 12:30 > > EDT) and exported an XFS filesystem to an SGI for testing. Attempting > > to build perl, I discovered that /bin/pwd was returning the wrong > > thing, although the bash built-in pwd worked right: > > > > $ pwd > > /malachite/test/perl-5.6.1 > > $ /bin/pwd > > /perl-5.6.1 > > $ uname -aR > > IRIX64 daacl 6.5 6.5.11m 01101245 IP27 > > > > What gives? > > > This is actually a known IRIX problem with handling variable size file handles > that will be fixed in 6.5.13. Refresh my memory I know this was causing directories to be lost but I thought the pwd problem is something else ... like the problem we saw in Slowaris? > > > Tad From owner-linux-xfs@oss.sgi.com Fri Jun 15 11:47:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FIlSD25653 for linux-xfs-outgoing; Fri, 15 Jun 2001 11:47:28 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FIlRk25650 for ; Fri, 15 Jun 2001 11:47:27 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f5FIlPaJ011374; Fri, 15 Jun 2001 13:47:25 -0500 (CDT) Message-ID: <3B504E72.71D1539@thebarn.com> Date: Sat, 14 Jul 2001 08:51:47 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Dan Swartzendruber CC: linux-xfs@oss.sgi.com Subject: Re: cvs and cvsup problems? References: <5.1.0.14.2.20010615123541.03fc5450@druber-gw.lightband.com> <5.1.0.14.2.20010615143528.03fc1980@druber-gw.lightband.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dan Swartzendruber wrote: > At 08:23 AM 7/14/2001 -0500, Russell Cattelan wrote: > >Dan Swartzendruber wrote: > > > > > maybe i'm stupid, but i'm seeing really odd things with both tools (getting > > > development trees): > > > > > > cvs: it gets a complete linux tree, but there is no top-level makefile. it > > > isn't clear to me what to do, at that point. > > > > > > cvsup: it gets a complete tree, but there are all kinds of revision > > files (the > > > ',v' suffixes), and attempts to build get weird errors from make. > > > >The ,v files are RCS files. > >Make sure you have the "tag=." field in your sup file if you want > >the the actuall files. > > i guess i was confused by the webpage directions. it (cvsup howto) said that > if you want to track the development tree, remove the 'tag=.' from the cvsup > file.? Are you looking at this page? http://oss.sgi.com/projects/xfs/cvsup.html it says: to keep your cvs tree current drop the tag=. From owner-linux-xfs@oss.sgi.com Fri Jun 15 11:52:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FIqPe25806 for linux-xfs-outgoing; Fri, 15 Jun 2001 11:52:25 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FIqOk25803 for ; Fri, 15 Jun 2001 11:52:24 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA334218 for ; Fri, 15 Jun 2001 20:52:22 +0200 (CEST) mail_from (tbd@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2118400; Fri, 15 Jun 2001 13:51:04 -0500 (CDT) Received: from fsgi158.americas.sgi.com (fsgi158.americas.sgi.com [128.162.184.29]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA17680; Fri, 15 Jun 2001 13:51:04 -0500 (CDT) From: Tad Dolphay Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id NAA13538; Fri, 15 Jun 2001 13:51:04 -0500 (CDT) Message-Id: <200106151851.NAA13538@fsgi158.americas.sgi.com> Subject: Re: NFS/pwd probs w/today's CVS dist To: cattelan@thebarn.com (Russell Cattelan) Date: Fri, 15 Jun 2001 13:51:03 -0500 (CDT) Cc: tbd@sgi.com (Tad Dolphay), ds-linux-xfs@sws5.ctd.ornl.gov (Dave Sill), linux-xfs@oss.sgi.com In-Reply-To: <3B504D4C.833883F@thebarn.com> from "Russell Cattelan" at Jul 14, 2001 08:46:52 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Tad Dolphay wrote: > > > > > > > I installed the development version from cvs (checked out at 12:30 > > > EDT) and exported an XFS filesystem to an SGI for testing. Attempting > > > to build perl, I discovered that /bin/pwd was returning the wrong > > > thing, although the bash built-in pwd worked right: > > > > > > $ pwd > > > /malachite/test/perl-5.6.1 > > > $ /bin/pwd > > > /perl-5.6.1 > > > $ uname -aR > > > IRIX64 daacl 6.5 6.5.11m 01101245 IP27 > > > > > > What gives? > > > > > This is actually a known IRIX problem with handling variable size file handles > > that will be fixed in 6.5.13. > > Refresh my memory I know this was causing directories to be lost but > I thought the pwd problem is something else ... like the problem we saw in > Slowaris? > The pwd problem is seen with a Linux server and an Irix client and is a problem with Irix because it doesn't handle version 3 variable size file handles correctly. The "missing files/directories problem" is seen with a Linux client and an Irix server. This is a glibc problem on Linux. More info at: http://sources.redhat.com/ml/libc-alpha/2001-02/msg00118.html Tad From owner-linux-xfs@oss.sgi.com Fri Jun 15 12:02:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FJ2xf26269 for linux-xfs-outgoing; Fri, 15 Jun 2001 12:02:59 -0700 Received: from s1.uklinux.net (ns1.uklinux.net [212.1.130.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FJ2vk26262 for ; Fri, 15 Jun 2001 12:02:57 -0700 Received: from pyewacket.nic.uklinux.net (ppp-6a-17.3com.telinco.net [212.159.138.17]) by s1.uklinux.net (8.11.2/8.11.1) with ESMTP id f5FJ2nA03945 for ; Fri, 15 Jun 2001 20:02:49 +0100 Envelope-To: Received: from ndoye by pyewacket.nic.uklinux.net with local (Exim 3.22 #1) id 15AymB-0005vY-00 for linux-xfs@oss.sgi.com; Fri, 15 Jun 2001 19:56:59 +0100 From: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15146.23163.684729.718606@localhost.localdomain> Date: Fri, 15 Jun 2001 19:56:59 +0100 To: linux-xfs@oss.sgi.com Subject: Re: CVS tree In-Reply-To: <200106111424.f5BEOku07811@jen.americas.sgi.com> References: <4.3.2.7.2.20010611134816.03502208@pop.xs4all.nl> <200106111424.f5BEOku07811@jen.americas.sgi.com> X-Mailer: VM 6.90 under 21.5 (beta1) "anise" XEmacs Lucid Organisation: Quixotic Hackers X-URL: http://www.nic.uklinux.net X-Cabaret-Voltaire-URL: http://brainwashed.com/cv X-Face: &-8(x5K]<0/|dXSmxL9\p/,6*,C16]W8k1Elf.\e~pa~ASI57X9+eDm^Rkv'?}-bT=o]Hz{ eMQXn Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote on 11-June-2001: ->> Hi, ->> ->> Is anyone experiencing a missing Config.in in the Bluetooth section? -> ->Is this still the case - there is a Config.in in the internal source tree ->and it shows up in the cvsweb tree on oss, so I think the problem is somewhere ->between oss and you. -> ->Steve I'm also seeing this: [root@pyewacket linux]# make xconfig rm -f include/asm ( cd include ; ln -sf asm-i386 asm) make -C scripts kconfig.tk make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux/scripts' cat header.tk >> ./kconfig.tk ./tkparse < ../arch/i386/config.in >> kconfig.tk -: 380: unable to open net/bluetooth/Config.in make[1]: *** [kconfig.tk] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/scripts' make: *** [xconfig] Error 2 net/bluetooth/ doesn't exist but drivers/bluetooth does... I think this is a bug in arch/i386/config.in and net/Makefile Here's a couple of patchettes that get everything to at least compile even if they aren't exactly correct. ------------------------------------------------------------------------ [root@pyewacket src]# diff -u ~ndoye/src/kernel/linux-xfs/linux-2.4-xfs/linux/arch/i386/config.in linux/arch/i386/config.in --- /home/ndoye/src/kernel/linux-xfs/linux-2.4-xfs/linux/arch/i386/config.in Thu Jun 14 21:10:51 2001 +++ linux/arch/i386/config.in Thu Jun 14 23:02:21 2001 @@ -377,7 +377,7 @@ source drivers/usb/Config.in if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then - source net/bluetooth/Config.in + source drivers/bluetooth/Config.in fi mainmenu_option next_comment ------------------------------------------------------------------------ [root@pyewacket linux]# cd .. ; diff -u ~ndoye/src/kernel/linux-xfs/linux-2.4-xfs/linux/net/Makefile linux/net/Makefile --- /home/ndoye/src/kernel/linux-xfs/linux-2.4-xfs/linux/net/Makefile Thu Jun 14 21:13:11 2001 +++ linux/net/Makefile Fri Jun 15 09:38:49 2001 @@ -40,7 +40,6 @@ subdir-$(CONFIG_ROSE) += rose subdir-$(CONFIG_AX25) += ax25 subdir-$(CONFIG_IRDA) += irda -subdir-$(CONFIG_BLUEZ) += bluetooth subdir-$(CONFIG_SUNRPC) += sunrpc subdir-$(CONFIG_ATM) += atm subdir-$(CONFIG_DECNET) += decnet ------------------------------------------------------------------------ -- www.nic.uklinux.net From owner-linux-xfs@oss.sgi.com Fri Jun 15 12:04:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FJ4EY26385 for linux-xfs-outgoing; Fri, 15 Jun 2001 12:04:14 -0700 Received: from femail22.sdc1.sfba.home.com (femail22.sdc1.sfba.home.com [24.0.95.147]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FJ4Ek26382 for ; Fri, 15 Jun 2001 12:04:14 -0700 Received: from neuromancer ([65.13.136.37]) by femail22.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010615190409.OETT25303.femail22.sdc1.sfba.home.com@neuromancer> for ; Fri, 15 Jun 2001 12:04:09 -0700 Message-ID: <000e01c0f5ce$13eb7500$4000a8c0@neuromancer> From: "Grant Rodgers" To: Subject: Current md status Date: Fri, 15 Jun 2001 14:05:00 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C0F5A4.2ADB7140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C0F5A4.2ADB7140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What is the current status of xfs over md, specifically raid5? I read = in a previous message that xfs is slower than ext2 using raid1 and = raid5, is this still the case? The basic question: do xfs and raid5 mix reliably at this point? ------=_NextPart_000_000B_01C0F5A4.2ADB7140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
What is the current status of xfs over = md,=20 specifically raid5?  I read in a previous message that xfs is = slower than=20 ext2 using raid1 and raid5, is this still the case?
 
The basic question: do xfs and = raid5 mix=20 reliably at this point?
------=_NextPart_000_000B_01C0F5A4.2ADB7140-- From owner-linux-xfs@oss.sgi.com Fri Jun 15 12:05:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FJ5Ld26508 for linux-xfs-outgoing; Fri, 15 Jun 2001 12:05:21 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FJ5Kk26505 for ; Fri, 15 Jun 2001 12:05:20 -0700 Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f5FJ5BaJ011831; Fri, 15 Jun 2001 14:05:18 -0500 (CDT) Message-ID: <3B50529D.7197359B@thebarn.com> Date: Sat, 14 Jul 2001 09:09:33 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Dan Swartzendruber , linux-xfs@oss.sgi.com Subject: Re: cvs and cvsup problems? References: <5.1.0.14.2.20010615123541.03fc5450@druber-gw.lightband.com> <5.1.0.14.2.20010615143528.03fc1980@druber-gw.lightband.com> <5.1.0.14.2.20010615145025.03fb4c40@druber-gw.lightband.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dan Swartzendruber wrote: > At 08:51 AM 7/14/2001 -0500, Russell Cattelan wrote: > >Dan Swartzendruber wrote: > > > i guess i was confused by the webpage directions. it (cvsup howto) > > said that > > > if you want to track the development tree, remove the 'tag=.' from the > > cvsup > > > file.? > > > >Are you looking at this page? > >http://oss.sgi.com/projects/xfs/cvsup.html > > > >it says: > >to keep your cvs tree current drop the tag=. > > maybe i'm getting burned by terminology then. i want to be able to track > changes > to files as they're made. it's sounding as though that isn't possible - > e.g. i either > get a snapshot, or the ,v files, and then checkout any files that have been > committed > since the last time. am i missing something? You have several options of keeping current cvs update (oss as root) (slow updates) cvsup (change updated directly from cvs tree on oss) (fast updates ) cvsup the cvs directory ito local drive space (i.e. dropping the tag=.) then cvs update (local repository as root) (half way in-between for speed twice the disk space but can do all cvs commands) From owner-linux-xfs@oss.sgi.com Fri Jun 15 12:13:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FJDOl26752 for linux-xfs-outgoing; Fri, 15 Jun 2001 12:13:24 -0700 Received: from femail22.sdc1.sfba.home.com (femail22.sdc1.sfba.home.com [24.0.95.147]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FJDNk26749 for ; Fri, 15 Jun 2001 12:13:23 -0700 Received: from neuromancer ([65.13.136.37]) by femail22.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010615191318.OMAS25303.femail22.sdc1.sfba.home.com@neuromancer> for ; Fri, 15 Jun 2001 12:13:18 -0700 Message-ID: <003201c0f5cf$5b7d2f20$4000a8c0@neuromancer> From: "Grant Rodgers" To: Subject: Current md status Date: Fri, 15 Jun 2001 14:14:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk What is the current status of xfs over md, specifically raid5? I read in a previous message that xfs is slower than ext2 using raid1 and raid5, is this still the case? The basic question: do xfs and raid5 mix reliably at this point? first version was html, oops! Sorry postmaster. From owner-linux-xfs@oss.sgi.com Fri Jun 15 12:13:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FJDuk26851 for linux-xfs-outgoing; Fri, 15 Jun 2001 12:13:56 -0700 Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FJDtk26848 for ; Fri, 15 Jun 2001 12:13:55 -0700 Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:63274 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Fri, 15 Jun 2001 21:13:51 +0200 Message-Id: <4.3.2.7.2.20010615211242.039dea18@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Jun 2001 21:13:37 +0200 To: Russell Cattelan , Tad Dolphay From: Seth Mos Subject: Re: NFS/pwd probs w/today's CVS dist Cc: Dave Sill , linux-xfs@oss.sgi.com In-Reply-To: <3B504D4C.833883F@thebarn.com> References: <200106151818.NAA13344@fsgi158.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 08:46 14-7-2001 -0500, Russell Cattelan wrote: >Refresh my memory I know this was causing directories to be lost but >I thought the pwd problem is something else ... like the problem we saw in >Slowaris? Was it cd ../dir and getting trapped or lost? Just guessing. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Jun 15 12:24:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FJOmT27119 for linux-xfs-outgoing; Fri, 15 Jun 2001 12:24:48 -0700 Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FJOlk27116 for ; Fri, 15 Jun 2001 12:24:47 -0700 Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:63288 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Fri, 15 Jun 2001 21:24:49 +0200 Message-Id: <4.3.2.7.2.20010615212208.02f53b70@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Jun 2001 21:24:36 +0200 To: "Grant Rodgers" , From: Seth Mos Subject: Re: Current md status In-Reply-To: <003201c0f5cf$5b7d2f20$4000a8c0@neuromancer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 14:14 15-6-2001 -0500, Grant Rodgers wrote: >What is the current status of xfs over md, specifically raid5? I read in a >previous message that xfs is slower than ext2 using raid1 and raid5, is this >still the case? > >The basic question: do xfs and raid5 mix reliably at this point? > >first version was html, oops! Sorry postmaster. XFS over MD devices should work. The only thing that is open to tuning is the syncing throttle when the raid is degenerated state. It should work. Performance numbers are not known. If anyone has some data about relative speeds I would like to see it. Bye -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Jun 15 14:04:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FL4Rp28490 for linux-xfs-outgoing; Fri, 15 Jun 2001 14:04:27 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FL4Qk28487 for ; Fri, 15 Jun 2001 14:04:26 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15B0l1-0001JU-00; Sat, 16 Jun 2001 09:03:55 +1200 Date: Sat, 16 Jun 2001 09:03:55 +1200 (NZST) From: Juha Saarinen To: Seth Mos cc: Dino A Amato , "lord@sgi.com" , "linux-xfs@oss.sgi.com" Subject: Re: info and feedback XFS In-Reply-To: <4.3.2.7.2.20010615150443.039e1840@pop.xs4all.nl> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 15 Jun 2001, Seth Mos wrote: > That is under Irix on SGI MIPS machines. On intel machines the kernel > itself is probably the limiting factor. ... not to mention the limitations of the Intel architecture itself. -- Juha From owner-linux-xfs@oss.sgi.com Fri Jun 15 14:45:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FLj4c28929 for linux-xfs-outgoing; Fri, 15 Jun 2001 14:45:04 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FLj2k28926 for ; Fri, 15 Jun 2001 14:45:03 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15B1Od-0001KG-00; Sat, 16 Jun 2001 09:44:51 +1200 Date: Sat, 16 Jun 2001 09:44:51 +1200 (NZST) From: Juha Saarinen To: Russell Cattelan cc: Dan Swartzendruber , "linux-xfs@oss.sgi.com" Subject: Re: cvs and cvsup problems? In-Reply-To: <3B50529D.7197359B@thebarn.com> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just out of curiosity, if you wanted to swap from cvs to cvsup for updates, do you need to do anything in particular apart from creating a cvsup file with the tag etc? I've been using cvs until now, because I thought cvsup to oss.sgi.com was broken, but would like to "re-use" the existing local source tree instead of downloading it all again. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 On Sat, 14 Jul 2001, Russell Cattelan wrote: > > You have several options of keeping current > > cvs update (oss as root) (slow updates) > > cvsup (change updated directly from cvs tree on oss) (fast updates ) > > cvsup the cvs directory ito local drive space (i.e. dropping the tag=.) > then cvs update (local repository as root) > (half way in-between for speed twice the disk space but > can do all cvs commands) > > > > From owner-linux-xfs@oss.sgi.com Fri Jun 15 14:45:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FLjPn28973 for linux-xfs-outgoing; Fri, 15 Jun 2001 14:45:25 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FLjNk28970 for ; Fri, 15 Jun 2001 14:45:24 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA27623; Fri, 15 Jun 2001 23:45:22 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA19778; Fri, 15 Jun 2001 23:45:22 +0200 (CEST) Date: Fri, 15 Jun 2001 23:45:22 +0200 (CEST) From: Seth Mos To: Juha Saarinen cc: Dino A Amato , "lord@sgi.com" , "linux-xfs@oss.sgi.com" Subject: Re: info and feedback XFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 16 Jun 2001, Juha Saarinen wrote: > On Fri, 15 Jun 2001, Seth Mos wrote: > > > That is under Irix on SGI MIPS machines. On intel machines the kernel > > itself is probably the limiting factor. > > ... not to mention the limitations of the Intel architecture itself. > The scales better then intel x86 systems. where number of arch > 5 A cobalt Qube2 is based on mips, not fast but it usses low power and can move a good amount of data. I believe Eric had some fibre channel arrays left to connect to the qube. Madness. Qube2 with 250Mhz mips proc and 2TB xfs disk storage connected to it. I want it. However my powersupply is still broken and I need to get it replaced before I can try and get the thing booting and crashing again. Bye From owner-linux-xfs@oss.sgi.com Fri Jun 15 15:20:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FMKIB29385 for linux-xfs-outgoing; Fri, 15 Jun 2001 15:20:18 -0700 Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FMKGk29382 for ; Fri, 15 Jun 2001 15:20:17 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f5FMIl898024; Fri, 15 Jun 2001 17:19:13 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <3B2A89C1.BFCEE261@thebarn.com> Date: Fri, 15 Jun 2001 17:18:42 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Juha Saarinen CC: Dan Swartzendruber , "linux-xfs@oss.sgi.com" Subject: Re: cvs and cvsup problems? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juha Saarinen wrote: > Just out of curiosity, if you wanted to swap from cvs to cvsup for > updates, do you need to do anything in particular apart from creating a > cvsup file with the tag etc? > > I've been using cvs until now, because I thought cvsup to oss.sgi.com was > broken, but would like to "re-use" the existing local source tree instead > of downloading it all again. Well technically cvs to oss is still down the port is still blocked, which is why thebarn is currently serving up the xfs tree. I don't know if you can reuse the tree. I would make a backup copy of your cvs tree and give it try. I may simply "rsync" the date stamps, but I'm not sure exactly what it will do. > > > -- > Regards, > > Juha > > PGP fingerprint: > B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 > > On Sat, 14 Jul 2001, Russell Cattelan wrote: > > > > > You have several options of keeping current > > > > cvs update (oss as root) (slow updates) > > > > cvsup (change updated directly from cvs tree on oss) (fast updates ) > > > > cvsup the cvs directory ito local drive space (i.e. dropping the tag=.) > > then cvs update (local repository as root) > > (half way in-between for speed twice the disk space but > > can do all cvs commands) > > > > > > > > -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Fri Jun 15 16:11:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5FNBIP29991 for linux-xfs-outgoing; Fri, 15 Jun 2001 16:11:18 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5FNBFk29988 for ; Fri, 15 Jun 2001 16:11:15 -0700 Received: (qmail 14569 invoked from network); 15 Jun 2001 23:11:12 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 15 Jun 2001 23:11:12 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: nic@uklinux.net cc: linux-xfs@oss.sgi.com Subject: Re: CVS tree In-reply-to: Your message of "Fri, 15 Jun 2001 19:56:59 +0100." <15146.23163.684729.718606@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 16 Jun 2001 09:11:11 +1000 Message-ID: <12901.992646671@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 15 Jun 2001 19:56:59 +0100, wrote: >[root@pyewacket linux]# make xconfig >rm -f include/asm >( cd include ; ln -sf asm-i386 asm) >make -C scripts kconfig.tk >make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux/scripts' >cat header.tk >> ./kconfig.tk >./tkparse < ../arch/i386/config.in >> kconfig.tk >-: 380: unable to open net/bluetooth/Config.in > >net/bluetooth/ doesn't exist but drivers/bluetooth does... I think >this is a bug in arch/i386/config.in and net/Makefile In the internal XFS code and the base kernel, there is definitely a file called net/bluetooth/Config.in. I just fetched the CVS XFS tree from scratch and the file is there. Removing linux/net/bluetooth and doing cvs checkout fetched the file as well, both inside and outside SGI. Try cvs -d on checkout. From owner-linux-xfs@oss.sgi.com Fri Jun 15 22:25:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5G5Pa801096 for linux-xfs-outgoing; Fri, 15 Jun 2001 22:25:36 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5G5PZk01093 for ; Fri, 15 Jun 2001 22:25:35 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip30.idcomm.com [209.60.72.157]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5G5PQl11643 for ; Fri, 15 Jun 2001 23:25:27 -0600 Message-ID: <3B2AEE18.72589F6E@idcomm.com> Date: Fri, 15 Jun 2001 23:26:48 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: rescue disk contents Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm setting up "yard" to work on a 2 floppy solution for rescue disk, and later just as a direct boot mechanism. For the XFS based rescue though, what files would be considered good to have for a rescue disk that would not be on a regular rescue (e.g., fsck.xfs)? D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Fri Jun 15 23:59:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5G6xTA01971 for linux-xfs-outgoing; Fri, 15 Jun 2001 23:59:29 -0700 Received: from ente.berdmann.de (pD9011439.dip.t-dialin.net [217.1.20.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5G6xSk01968 for ; Fri, 15 Jun 2001 23:59:28 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.16 #2) id 15BA3E-0000RM-00; Sat, 16 Jun 2001 08:59:20 +0200 Message-ID: <3B2B03C8.2E0D2EC7@berdmann.de> Date: Sat, 16 Jun 2001 08:59:20 +0200 From: "Bernhard R. Erdmann" Organization: Bernhard Erdmann Communication & Network Solutions X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre3-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: stimits@idcomm.com CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: rescue disk contents References: <3B2AEE18.72589F6E@idcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I'm setting up "yard" to work on a 2 floppy solution for rescue disk, > and later just as a direct boot mechanism. For the XFS based rescue > though, what files would be considered good to have for a rescue disk > that would not be on a regular rescue (e.g., fsck.xfs)? I'd take xfs_check, xfs_repair, xfsrestore, xfsdump. Rescue disks should carry netcat to dump and restore via network. From owner-linux-xfs@oss.sgi.com Sat Jun 16 07:24:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5GEOOP04048 for linux-xfs-outgoing; Sat, 16 Jun 2001 07:24:24 -0700 Received: from mail.gmx.net (mail.gmx.net [194.221.183.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5GEOMZ04045 for ; Sat, 16 Jun 2001 07:24:23 -0700 Received: (qmail 4910 invoked by uid 0); 16 Jun 2001 14:24:16 -0000 Received: from f-45-213.cvx-leipzig.ipdial.viaginterkom.de (HELO temple) (62.180.213.45) by mail.gmx.net (mail05) with SMTP; 16 Jun 2001 14:24:16 -0000 Message-ID: <001901c0f670$9ef80bc0$01000001@temple> Reply-To: "Andreas Piesk" From: "Andreas Piesk" To: "xfs ML" Subject: kernel panic using xfs as modules and gcc-2.96 Date: Sat, 16 Jun 2001 16:28:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hiho, i built a kernel with ide and xfs as modules. but the kernel crashes at startup (see below). some info about the environment: redhat 7.1 gcc-2.96 kernel-2.4.5 linux-2.4.5-xfs-06112001 command used for building the ramdisk image: mkinitrd --preload pagebuf --preload xfs_supprt --preload xfs i also tried to preload all ide/xfs modules, no success. then i used kgcc (egcs-2.91.66), and surprise!, everythings works. the top Makefile says, rh7.1's gcc appears to generate good code, but in this case, it isn't true. maybe the statement in the makefile should be revised. -ap -- log Loading ide-mod module Loading ide-mod-probe module Loading ide-disk module Loading pagebuf module Loading xfs_support module Loading xfs module Start mounting filesystem: ide0(3,1) Ending clean XFS mount for filesystem: ide0(3,1) VFS: Mounted root (xfs filesystem) readonly. change_root: old_root has d_count=2 Trying to unmount old root ... <1>Unable to handle kernel NULL pointer dereference at virtual address 00000292 printing eip: c016df16 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] EFLAGS: 00010202 eax: 00000282 ebx: 00001261 ecx: 00000000 edx: c12fbd74 esi: 00000000 edi: c12c87e0 ebp: c12c5160 esp: c12fbd54 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 1, stackpage=c12fb000) Stack: c12fa000 ffffffff c12c87e0 c0138317 c12fbd74 00000000 00001261 00000000 c12fbd88 c7cd5040 00000000 c9046819 c12fbd8c 00000282 c0200ecc 000000001 00000282 00000001 00000000 c0179e60 c02666e0 c01761e4 c0260100 0000001f Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 40 10 83 f8 02 7e 62 b8 f0 ff ff ff eb 74 85 c9 b8 ea ff Kernel panic: Attempted to kill init! -- Andreas Piesk a.piesk@gmx.net PGP-Fingerprint: 23CB A7E2 2E53 373C DBCD 8EFC 7777 61C1 From owner-linux-xfs@oss.sgi.com Sat Jun 16 07:30:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5GEUj704201 for linux-xfs-outgoing; Sat, 16 Jun 2001 07:30:45 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5GEUgZ04197 for ; Sat, 16 Jun 2001 07:30:42 -0700 Received: (qmail 20665 invoked from network); 16 Jun 2001 14:30:37 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 16 Jun 2001 14:30:37 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Andreas Piesk" cc: "xfs ML" Subject: Re: kernel panic using xfs as modules and gcc-2.96 In-reply-to: Your message of "Sat, 16 Jun 2001 16:28:14 +0200." <001901c0f670$9ef80bc0$01000001@temple> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Jun 2001 00:30:36 +1000 Message-ID: <2712.992701836@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 16 Jun 2001 16:28:14 +0200, "Andreas Piesk" wrote: >i built a kernel with ide and xfs as modules. >but the kernel crashes at startup (see below). >redhat 7.1 >gcc-2.96 >then i used kgcc (egcs-2.91.66), and surprise!, everythings works. Do you still have the System.map for the failing system and can you run the oops through ksymoops against the map for gcc 2.96? That might help us track down which bit of XFS code 2.96 is failing to compile correctly. From owner-linux-xfs@oss.sgi.com Sat Jun 16 07:36:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5GEaZq04381 for linux-xfs-outgoing; Sat, 16 Jun 2001 07:36:35 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5GEaXZ04377 for ; Sat, 16 Jun 2001 07:36:33 -0700 Received: (qmail 20691 invoked from network); 16 Jun 2001 14:36:31 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 16 Jun 2001 14:36:31 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Andreas Piesk" cc: "xfs ML" Subject: Re: kernel panic using xfs as modules and gcc-2.96 In-reply-to: Your message of "Sat, 16 Jun 2001 16:28:14 +0200." <001901c0f670$9ef80bc0$01000001@temple> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Jun 2001 00:36:29 +1000 Message-ID: <2750.992702189@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 16 Jun 2001 16:28:14 +0200, "Andreas Piesk" wrote: >Trying to unmount old root ... <1>Unable to handle kernel NULL pointer >dereference at virtual address 00000292 Kicks self repeatedly. Forget my previous mail, you hit a known bug in 2.4.5 kernels which is not compiler dependent. The fix in Linus's tree is Index: 5.1/fs/block_dev.c --- 5.1/fs/block_dev.c Wed, 23 May 2001 11:55:33 +1000 kaos (linux-2.4/p/b/16_block_dev. 1.2.2.3 644) +++ 6-pre3.1/fs/block_dev.c Sat, 09 Jun 2001 11:25:53 +1000 kaos (linux-2.4/p/b/16_block_dev. 1.2.2.4 644) @@ -595,14 +595,15 @@ int check_disk_change(kdev_t dev) int ioctl_by_bdev(struct block_device *bdev, unsigned cmd, unsigned long arg) { - kdev_t rdev = to_kdev_t(bdev->bd_dev); struct inode inode_fake; int res; mm_segment_t old_fs = get_fs(); if (!bdev->bd_op->ioctl) return -EINVAL; - inode_fake.i_rdev=rdev; + memset(&inode_fake, 0, sizeof(inode_fake)); + inode_fake.i_rdev = to_kdev_t(bdev->bd_dev); + inode_fake.i_bdev = bdev; init_waitqueue_head(&inode_fake.i_wait); set_fs(KERNEL_DS); res = bdev->bd_op->ioctl(&inode_fake, NULL, cmd, arg); From owner-linux-xfs@oss.sgi.com Sat Jun 16 10:15:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5GHFZF05698 for linux-xfs-outgoing; Sat, 16 Jun 2001 10:15:35 -0700 Received: from mailer.21st-century.net (mail.21st-century.net [195.50.224.14] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5GHFXZ05695 for ; Sat, 16 Jun 2001 10:15:33 -0700 Received: from rubistar (bw2-135pub182.bluewin.ch [213.3.135.182]) by mailer.21st-century.net (Rockliffe SMTPRA 4.5.4) with SMTP id for ; Sat, 16 Jun 2001 19:15:31 +0200 Message-ID: <001801c0f688$afe37b00$6402a8c0@rubistar> From: "Thomas von Steiger" To: Subject: lost+found Date: Sat, 16 Jun 2001 19:20:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello List, If i create a XFS Filesystem on Disk, has this Filesystem a lost+found inside ? I have a XFS Filesystem on a old Redhat 6.1, becose there is no lost+found. regards, Thomas From owner-linux-xfs@oss.sgi.com Sat Jun 16 10:22:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5GHMeZ05865 for linux-xfs-outgoing; Sat, 16 Jun 2001 10:22:40 -0700 Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5GHMdZ05862 for ; Sat, 16 Jun 2001 10:22:39 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.2/8.11.2) with ESMTP id f5GHMFb16775; Sat, 16 Jun 2001 13:22:15 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Sat, 16 Jun 2001 13:22:15 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: To: Thomas von Steiger cc: Subject: Re: lost+found In-Reply-To: <001801c0f688$afe37b00$6402a8c0@rubistar> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 16 Jun 2001 at 7:20pm, Thomas von Steiger wrote > If i create a XFS Filesystem on Disk, has this Filesystem a lost+found > inside ? > I have a XFS Filesystem on a old Redhat 6.1, becose there is no lost+found. There's no lost+found. I'm assuming that's because of the journal and the fact that "lost" items are "found" in place. They may be corrupt if they were being written, but they won't be lost. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Sat Jun 16 10:36:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5GHa9W06017 for linux-xfs-outgoing; Sat, 16 Jun 2001 10:36:09 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5GHa8Z06014 for ; Sat, 16 Jun 2001 10:36:08 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id DA9751E102; Sat, 16 Jun 2001 19:36:02 +0200 (MEST) Date: Sat, 16 Jun 2001 19:35:36 +0200 From: Andi Kleen To: Joshua Baker-LePain Cc: Thomas von Steiger , linux-xfs@oss.sgi.com Subject: Re: lost+found Message-ID: <20010616193536.A12476@gruyere.muc.suse.de> References: <001801c0f688$afe37b00$6402a8c0@rubistar> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jlb17@duke.edu on Sat, Jun 16, 2001 at 01:22:15PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Jun 16, 2001 at 01:22:15PM -0400, Joshua Baker-LePain wrote: > On Sat, 16 Jun 2001 at 7:20pm, Thomas von Steiger wrote > > > If i create a XFS Filesystem on Disk, has this Filesystem a lost+found > > inside ? > > I have a XFS Filesystem on a old Redhat 6.1, becose there is no lost+found. > > There's no lost+found. I'm assuming that's because of the journal and the > fact that "lost" items are "found" in place. They may be corrupt if they > were being written, but they won't be lost. xfsrepair seems to create lost+found on the fly when it needs it, i.e. when orphaned inodes are found. On a 100% full file system with no place to create it you're probably out of luck. -Andi From owner-linux-xfs@oss.sgi.com Sat Jun 16 10:40:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5GHeTq06121 for linux-xfs-outgoing; Sat, 16 Jun 2001 10:40:29 -0700 Received: from server.home.fliegl.de ([195.180.174.246]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5GHeRZ06118 for ; Sat, 16 Jun 2001 10:40:27 -0700 Received: from fliegl.de (server.home.fliegl.de [172.16.1.1]) by server.home.fliegl.de (Maggifix) with ESMTP id 85BD017C4A; Sat, 16 Jun 2001 19:40:20 +0200 (CEST) Message-ID: <3B2B9A04.12BDDC7A@fliegl.de> Date: Sat, 16 Jun 2001 19:40:20 +0200 From: Deti Fliegl X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Joshua Baker-LePain Cc: Thomas von Steiger , linux-xfs@oss.sgi.com Subject: Re: lost+found References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Joshua Baker-LePain wrote: > > On Sat, 16 Jun 2001 at 7:20pm, Thomas von Steiger wrote > > > If i create a XFS Filesystem on Disk, has this Filesystem a lost+found > > inside ? > > I have a XFS Filesystem on a old Redhat 6.1, becose there is no lost+found. > > There's no lost+found. I'm assuming that's because of the journal and the > fact that "lost" items are "found" in place. They may be corrupt if they > were being written, but they won't be lost. A lost+found directory will be created automatically when using xfs_repair. This utility corresponds to the well known fsck which checks and repairs a filesystem. Under normal circumstances you never need to run xfs_repair (unless something goes badly wrong). Have a lot of fun with XFS... Deti From owner-linux-xfs@oss.sgi.com Sat Jun 16 14:09:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5GL9F227364 for linux-xfs-outgoing; Sat, 16 Jun 2001 14:09:15 -0700 Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5GL9EZ27361 for ; Sat, 16 Jun 2001 14:09:14 -0700 Received: (qmail 27358 invoked by uid 0); 16 Jun 2001 21:09:07 -0000 Received: from f-216-212.cvx-leipzig.ipdial.viaginterkom.de (HELO temple) (62.180.212.216) by mail.gmx.net (mp020-rz3) with SMTP; 16 Jun 2001 21:09:07 -0000 Message-ID: <000401c0f6a9$2dcd0250$01000001@temple> Reply-To: "Andreas Piesk" From: "Andreas Piesk" To: "xfs ML" References: <2750.992702189@ocs3.ocs-net> Subject: Re: kernel panic using xfs as modules and gcc-2.96 Date: Sat, 16 Jun 2001 20:20:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Kicks self repeatedly. Forget my previous mail, you hit a known bug in > 2.4.5 kernels which is not compiler dependent. The fix in Linus's tree is > hmm, i should give the pre3 a try. but if i compile the kernel with exactly the same settings (it's a rpm) with gcc-2.96. it will crash. with egcs-2.91.66 it runs very well. i will try pre3 with both compilers. thanks for answering, -ap From owner-linux-xfs@oss.sgi.com Sat Jun 16 14:14:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5GLE5p28155 for linux-xfs-outgoing; Sat, 16 Jun 2001 14:14:05 -0700 Received: from sphinx.druber.com ([216.129.135.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5GLE4Z28150 for ; Sat, 16 Jun 2001 14:14:04 -0700 Received: from sphinx.druber.com (sphinx.druber.com [10.0.0.2]) by sphinx.druber.com (Postfix) with ESMTP id DB268116; Sat, 16 Jun 2001 17:07:25 -0400 (EDT) Date: Sat, 16 Jun 2001 17:07:25 -0400 (EDT) From: Dan Swartzendruber To: Andreas Piesk Cc: xfs ML Subject: Re: kernel panic using xfs as modules and gcc-2.96 In-Reply-To: <000401c0f6a9$2dcd0250$01000001@temple> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 16 Jun 2001, Andreas Piesk wrote: > > > > Kicks self repeatedly. Forget my previous mail, you hit a known bug in > > 2.4.5 kernels which is not compiler dependent. The fix in Linus's tree is > > > > hmm, i should give the pre3 a try. > > but if i compile the kernel with exactly the same settings (it's a rpm) > with gcc-2.96. it will crash. with egcs-2.91.66 it runs very well. > > i will try pre3 with both compilers. pre3 with kgcc is working fine for me. xfs on 5 filesystems... From owner-linux-xfs@oss.sgi.com Sat Jun 16 16:11:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5GNBrI16335 for linux-xfs-outgoing; Sat, 16 Jun 2001 16:11:53 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5GNBqZ16328 for ; Sat, 16 Jun 2001 16:11:52 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15BPEK-0003fs-00 for ; Sun, 17 Jun 2001 11:11:48 +1200 Date: Sun, 17 Jun 2001 11:11:48 +1200 (NZST) From: Juha Saarinen cc: xfs ML Subject: Re: kernel panic using xfs as modules and gcc-2.96 In-Reply-To: <000401c0f6a9$2dcd0250$01000001@temple> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I don't mind giving the latest CVS a go and compiling it with 2.96. Could someone give me short instructions on how to use ksymoops etc? -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 On Sat, 16 Jun 2001, Andreas Piesk wrote: > > > > Kicks self repeatedly. Forget my previous mail, you hit a known bug in > > 2.4.5 kernels which is not compiler dependent. The fix in Linus's tree is > > > > hmm, i should give the pre3 a try. > > but if i compile the kernel with exactly the same settings (it's a rpm) > with gcc-2.96. it will crash. with egcs-2.91.66 it runs very well. > > i will try pre3 with both compilers. > > thanks for answering, > > -ap > > > > From owner-linux-xfs@oss.sgi.com Sat Jun 16 18:11:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5H1BHe03840 for linux-xfs-outgoing; Sat, 16 Jun 2001 18:11:17 -0700 Received: from studsv07.studserv.uni-stuttgart.de (studsv07.studserv.uni-stuttgart.de [129.69.21.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5H1BFZ03834 for ; Sat, 16 Jun 2001 18:11:16 -0700 Received: from ysabell.wh.vaih [129.69.166.244] by studsv07.studserv.uni-stuttgart.de with ESMTP (SMTPD32-6.06) id A3AF86D0046; Sun, 17 Jun 2001 03:11:11 +0200 Received: from marcelo by ysabell.wh.vaih with local (Exim 3.22 #1 (Debian)) id 15BR5x-0006mP-00; Sun, 17 Jun 2001 03:11:17 +0200 Date: Sun, 17 Jun 2001 03:11:17 +0200 From: "Marcelo E. Magallon" To: Juha Saarinen Cc: xfs ML Subject: Re: kernel panic using xfs as modules and gcc-2.96 Message-ID: <20010617031117.A25965@ysabell.wh.vaih> Mail-Followup-To: Juha Saarinen , xfs ML Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i X-Operating-System: Linux ysabell 2.4.4-xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> Juha Saarinen writes: > I don't mind giving the latest CVS a go and compiling it with 2.96. > Could someone give me short instructions on how to use ksymoops etc? Create a directory /var/log/ksymoops/, owned by root, mode 0644 or 0600, then reproduce the oops. On that directory you'll find several files named like: 20010602.log 20010602135630.ksyms 20010602135630.modules you are interested in the last two. As you might have guessed, the name of the file is a timestamp (YYYYMMDDHHMMSS). Once you have your oops, save it to a file, say xfs.oops and do something like this: $ ksymoops -v /boot/the-kernel-that-oopsed \ -k /var/log/closesttimebeforetheoops.ksyms \ -l /var/log/closesttimebeforetheoops.modules \ -m /boot/System.map-correspondingtothekernel \ xfs.oops I have kernels called vmlinuz-2.4.6-pre3 with a System.map called System.map-2.4.6-pre3, so this would be: $ ksymoops -v /boot/vmlinuz-2.4.6-pre3 \ -k /var/log/20010602135630.ksyms \ -l /var/log/20010602135630.modules \ -m /boot/System.map-2.4.6-pre3 \ xfs.oops You probably want to run insmod_ksymoops_clean on a dayly cronjob, otherwise you'll collect a lot of logs in /var/log/ksymoops. HTH, -- Marcelo From owner-linux-xfs@oss.sgi.com Sat Jun 16 18:17:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5H1HnH05142 for linux-xfs-outgoing; Sat, 16 Jun 2001 18:17:49 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5H1HlZ05138 for ; Sat, 16 Jun 2001 18:17:47 -0700 Received: (qmail 23815 invoked from network); 17 Jun 2001 01:17:44 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 17 Jun 2001 01:17:44 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Andreas Piesk" cc: "xfs ML" Subject: Re: kernel panic using xfs as modules and gcc-2.96 In-reply-to: Your message of "Sat, 16 Jun 2001 20:20:52 +0200." <000401c0f6a9$2dcd0250$01000001@temple> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Jun 2001 11:17:43 +1000 Message-ID: <4961.992740663@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 16 Jun 2001 20:20:52 +0200, "Andreas Piesk" wrote: >but if i compile the kernel with exactly the same settings (it's a rpm) >with gcc-2.96. it will crash. with egcs-2.91.66 it runs very well. The oops at root remount in 2.4.5 is caused by an uninitialised dynamic variable with undefined contents. Different compilers leave different garbage in dynamic variables, it is just concidence that the value from gcc 2.96 breaks but the value from kgcc works. The real bug is the lack of initialisation. From owner-linux-xfs@oss.sgi.com Sat Jun 16 18:19:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5H1Jqh05602 for linux-xfs-outgoing; Sat, 16 Jun 2001 18:19:52 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5H1JoZ05587 for ; Sat, 16 Jun 2001 18:19:51 -0700 Received: (qmail 23824 invoked from network); 17 Jun 2001 01:19:48 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 17 Jun 2001 01:19:48 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Juha Saarinen cc: xfs ML Subject: Re: kernel panic using xfs as modules and gcc-2.96 In-reply-to: Your message of "Sun, 17 Jun 2001 11:11:48 +1200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Jun 2001 11:19:48 +1000 Message-ID: <5001.992740788@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 17 Jun 2001 11:11:48 +1200 (NZST), Juha Saarinen wrote: >I don't mind giving the latest CVS a go and compiling it with 2.96. Could >someone give me short instructions on how to use ksymoops etc? man ksymoops and man insmod for ksymoops support for modules. From owner-linux-xfs@oss.sgi.com Sat Jun 16 18:24:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5H1OwZ06594 for linux-xfs-outgoing; Sat, 16 Jun 2001 18:24:58 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5H1OuZ06576 for ; Sat, 16 Jun 2001 18:24:56 -0700 Received: (qmail 23984 invoked from network); 17 Jun 2001 01:24:54 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 17 Jun 2001 01:24:54 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Marcelo E. Magallon" cc: Juha Saarinen , xfs ML Subject: Re: kernel panic using xfs as modules and gcc-2.96 In-reply-to: Your message of "Sun, 17 Jun 2001 03:11:17 +0200." <20010617031117.A25965@ysabell.wh.vaih> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Jun 2001 11:24:53 +1000 Message-ID: <5096.992741093@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 17 Jun 2001 03:11:17 +0200, "Marcelo E. Magallon" wrote: > $ ksymoops -v /boot/vmlinuz-2.4.6-pre3 \ > -k /var/log/20010602135630.ksyms \ > -l /var/log/20010602135630.modules \ > -m /boot/System.map-2.4.6-pre3 \ > xfs.oops ksymoops -v needs the uncompressed vmlinux that can be found in the top level of your linux compilation tree. vmlinuz is vmlinux after stripping, compressing and adding a boot loader, it has no useful symbols. So do ksymoops -v /usr/src/2.4.6-pre3/vmlinux. In any case, vmlinux is only used as a cross check on the integrity of the System.map, ksymoops can run without vmlinux and the default is not to read vmlinux. From owner-linux-xfs@oss.sgi.com Sun Jun 17 02:06:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5H96QZ20294 for linux-xfs-outgoing; Sun, 17 Jun 2001 02:06:26 -0700 Received: from ci.pocnet.net (root@ci.pocnet.net [217.28.101.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5H96OZ20288 for ; Sun, 17 Jun 2001 02:06:25 -0700 Received: from leela.pocnet.net (root@leela.pocnet.net [217.28.101.131]) by ci.pocnet.net (8.11.4/8.11.4) with ESMTP id f5H96Hs10732 for ; Sun, 17 Jun 2001 11:06:18 +0200 (MEST) Received: from [192.168.59.2] (powermac.pocnet.net [192.168.59.2]) by leela.pocnet.net (8.11.4/8.11.4) with ESMTP id f5H96F301761 for ; Sun, 17 Jun 2001 11:06:16 +0200 X-Sender: poc@leela.pocnet.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 17 Jun 2001 11:06:13 +0200 To: linux-xfs@oss.sgi.com From: Patrik Schindler Subject: Newer patches? Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I wanted to give xfs a try but found that there are only patches against Kernel Versions 2.4.2 and 2.4.3 which both suffer from a serious problem (filesystem corruption) in minix and ext2. As I don't want to migrate all my disks (but one to test) to xfs and don't want to step back from 2.4.5 (which is current), I'd want to ask you if it will be possible to create patches against newer kernels as they will be released. Or just ask Linus or Alan to integrate xfs in the regular kernel base ;-) Thanks for your support and bringing nifty things to the community! :wq! PoC From owner-linux-xfs@oss.sgi.com Sun Jun 17 02:06:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5H96sw20396 for linux-xfs-outgoing; Sun, 17 Jun 2001 02:06:54 -0700 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5H96qZ20391 for ; Sun, 17 Jun 2001 02:06:53 -0700 Received: from [195.20.224.204] (helo=mrvdom00.schlund.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 15BYWC-0000z2-00 for linux-xfs@oss.sgi.com; Sun, 17 Jun 2001 11:06:52 +0200 Received: from p3ee2afce.dip.t-dialin.net ([62.226.175.206] helo=engel) by mrvdom00.schlund.de with smtp (Exim 2.12 #2) id 15BYV7-0003mU-00 for linux-xfs@oss.sgi.com; Sun, 17 Jun 2001 11:05:48 +0200 From: "Engelmann F." To: Subject: xfs and kernel 2.4.5 Date: Sun, 17 Jun 2001 11:04:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, is there still no patch to use with kernel 2.4.5? Is it easy to build my own patch? thx _________________________________ F.Engelmann From owner-linux-xfs@oss.sgi.com Sun Jun 17 03:40:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5HAeR704541 for linux-xfs-outgoing; Sun, 17 Jun 2001 03:40:27 -0700 Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5HAePZ04536 for ; Sun, 17 Jun 2001 03:40:25 -0700 Received: (qmail 21646 invoked by uid 0); 17 Jun 2001 10:40:19 -0000 Received: from f-150-214.cvx-leipzig.ipdial.viaginterkom.de (HELO temple) (62.180.214.150) by mail.gmx.net (mp007-rz3) with SMTP; 17 Jun 2001 10:40:19 -0000 Message-ID: <008101c0f71a$80f20950$01000001@temple> Reply-To: "Andreas Piesk" From: "Andreas Piesk" To: Cc: "Patrik Schindler" References: Subject: Re: Newer patches? Date: Sun, 17 Jun 2001 12:43:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ----- Original Message ----- From: "Patrik Schindler" To: Sent: Sunday, June 17, 2001 11:06 AM Subject: Newer patches? > Hello, > > I wanted to give xfs a try but found that there are only patches against Kernel Versions 2.4.2 and 2.4.3 which both suffer from a serious problem (filesystem corruption) in minix and ext2. > As I don't want to migrate all my disks (but one to test) to xfs and don't want to step back from 2.4.5 (which is current), I'd want to ask you if it will be possible to create patches against newer kernels as they will be released. > Or just ask Linus or Alan to integrate xfs in the regular kernel base ;-) > > Thanks for your support and bringing nifty things to the community! > > :wq! PoC > > > ftp://oss.sgi.com/projects/xfs/download/patches/ is the answer to your problem. -ap -- Andreas Piesk a.piesk@gmx.net PGP-Fingerprint: 23CB A7E2 2E53 373C DBCD 8EFC 7777 61C1 From owner-linux-xfs@oss.sgi.com Sun Jun 17 03:40:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5HAeTu04553 for linux-xfs-outgoing; Sun, 17 Jun 2001 03:40:29 -0700 Received: from mail.gmx.net (sproxy.gmx.net [194.221.183.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5HAePZ04535 for ; Sun, 17 Jun 2001 03:40:25 -0700 Received: (qmail 21628 invoked by uid 0); 17 Jun 2001 10:40:18 -0000 Received: from f-150-214.cvx-leipzig.ipdial.viaginterkom.de (HELO temple) (62.180.214.150) by mail.gmx.net (mp007-rz3) with SMTP; 17 Jun 2001 10:40:18 -0000 Message-ID: <008001c0f71a$8074c300$01000001@temple> Reply-To: "Andreas Piesk" From: "Andreas Piesk" To: "Engelmann F." Cc: References: Subject: Re: xfs and kernel 2.4.5 Date: Sun, 17 Jun 2001 12:42:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ----- Original Message ----- From: "Engelmann F." To: Sent: Sunday, June 17, 2001 11:04 AM Subject: xfs and kernel 2.4.5 > Hi, > is there still no patch to use with kernel 2.4.5? Is it easy to build my own > patch? > > thx > > _________________________________ > F.Engelmann > > you can easily build your own patch, but forst you should take a look at ftp://oss.sgi.com/projects/xfs/download/patches/. -ap -- Andreas Piesk a.piesk@gmx.net PGP-Fingerprint: 23CB A7E2 2E53 373C DBCD 8EFC 7777 61C1 From owner-linux-xfs@oss.sgi.com Sun Jun 17 04:37:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5HBbHG19734 for linux-xfs-outgoing; Sun, 17 Jun 2001 04:37:17 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5HBbFZ19727 for ; Sun, 17 Jun 2001 04:37:16 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15Bara-0004Dd-00; Sun, 17 Jun 2001 23:37:06 +1200 Date: Sun, 17 Jun 2001 23:37:06 +1200 (NZST) From: Juha Saarinen To: Patrik Schindler cc: "linux-xfs@oss.sgi.com" Subject: Re: Newer patches? In-Reply-To: Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk There are patches on the oss.sgi.com ftp server for newer kernels. Alternatively, you could get the CVS tree and roll your own -- see instructions on http://oss.sgi.com/linux-xfs. Recently, Russell Cattelan (I think) announced that he had built some kernel RPMs for the Red Hat Rawhide kernels as well. Search the mailing archives for details -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 On Sun, 17 Jun 2001, Patrik Schindler wrote: > Hello, > > I wanted to give xfs a try but found that there are only patches against Kernel Versions 2.4.2 and 2.4.3 which both suffer from a serious problem (filesystem corruption) in minix and ext2. > As I don't want to migrate all my disks (but one to test) to xfs and don't want to step back from 2.4.5 (which is current), I'd want to ask you if it will be possible to create patches against newer kernels as they will be released. > Or just ask Linus or Alan to integrate xfs in the regular kernel base ;-) > > Thanks for your support and bringing nifty things to the community! > > :wq! PoC > > > > From owner-linux-xfs@oss.sgi.com Sun Jun 17 05:27:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5HCRIc28357 for linux-xfs-outgoing; Sun, 17 Jun 2001 05:27:18 -0700 Received: from downtown.oche.de (root@downtown.oche.de [194.94.253.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5HCRFZ28342 for ; Sun, 17 Jun 2001 05:27:16 -0700 Received: (from uucp@localhost) by downtown.oche.de (8.9.3/8.9.3/Debian 8.9.3-21) with UUCP id OAA10616 for linux-xfs@oss.sgi.com; Sun, 17 Jun 2001 14:32:19 +0200 Received: (from martin@localhost) by foehn.quickstep.oche.de (8.9.3/8.6.12) id OAA22116; Sun, 17 Jun 2001 14:26:25 +0200 (MET DST) Date: Sun, 17 Jun 2001 14:26:25 +0200 (MET DST) Message-Id: <200106171226.OAA22116@foehn.quickstep.oche.de> From: Martin Spott To: linux-xfs@oss.sgi.com Subject: Re: Current md status X-Newsgroups: list.linux-xfs In-Reply-To: <9gestu$7h6$1@foehn.quickstep.oche.de> Organization: home User-Agent: tin/1.4.5-20010409 ("One More Nightmare") (UNIX) (SunOS/5.5.1 (sun4m)) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > What is the current status of xfs over md, specifically raid5? I read in a > previous message that xfs is slower than ext2 using raid1 and raid5, is this > still the case? I'm currently running bonnie++ in a 'while true'-loop over this weekend on XFS over md/RAID1. This is obviously pretty stable, although it might not be very fast (I'll see on monday). Unfortunately I can't provide info on RAID5, because I don't have an adequate test environment, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Sun Jun 17 06:22:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5HDMTs05187 for linux-xfs-outgoing; Sun, 17 Jun 2001 06:22:29 -0700 Received: from sphinx.druber.com ([216.129.135.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5HDMRZ05184 for ; Sun, 17 Jun 2001 06:22:28 -0700 Received: from sphinx.druber.com (sphinx.druber.com [10.0.0.2]) by sphinx.druber.com (Postfix) with ESMTP id 8678D118; Sun, 17 Jun 2001 09:15:50 -0400 (EDT) Date: Sun, 17 Jun 2001 09:15:50 -0400 (EDT) From: Dan Swartzendruber To: "Engelmann F." Cc: Subject: Re: xfs and kernel 2.4.5 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 17 Jun 2001, Engelmann F. wrote: > Hi, > is there still no patch to use with kernel 2.4.5? Is it easy to build my own > patch? use the 2.4.4 patch. From owner-linux-xfs@oss.sgi.com Sun Jun 17 22:15:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5I5F8402416 for linux-xfs-outgoing; Sun, 17 Jun 2001 22:15:08 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5I5F6V02413 for ; Sun, 17 Jun 2001 22:15:07 -0700 Received: from auto-nb1.xs4all.nl (perle-wan1.coltex.nl [10.0.1.177]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5I5F2V14364; Mon, 18 Jun 2001 07:15:02 +0200 Message-Id: <4.3.2.7.2.20010618070434.02d268e0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Jun 2001 07:14:56 +0200 To: Knuth Posern From: Seth Mos Subject: Re: XFS at all? AND XFS and gcc ?! Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 23:31 17-6-2001 +0200, Knuth Posern wrote: >Hi. > >Thanks for your fast and long answer! > > > not suffered data as of yet. (knock on wood). I have no expierence about > > XFS over Raid5. I have the number of disks for it but unfortunately not > >Did you hear something about XFS over Software-RAID5? I ment XFS over software Raid5. Hardware raid practically always works unless the hardware raid driver is broken. > > YMMV when using it. > >YMMV? Sorry for the slang, Your mileage may vary > > The only problems with md is running in degraded mode. But it does work. > >md is one of the XFS-utils? - I didn't look at them yet... It's not, md is the kernel driver. When your raid misses one disk it will run in degraded mode. This when XFS will perform worse. When you replace the disk the resyncing was not always op to speed. > > It is on the FTP site. ftp://oss.sgi.com/projects/xfs/download/patches/ > > The cvs tree is currently at 2.4.6-pre3. > >Is it o.k. to use the 2.4.3-version at the moment (because in the Readme >on the server it said: ... 2.4.3 is not so heavily tested) - or should I >use always the newest XFS-patch for the actual kernel (which would be >2.4.5 with something as linux-2.4.5-xfs-06112001.patch.bz2 at the moment). This readme was made when 1.0 was released. You should pick up the latest XFS patch. There are numerous fixes on the linux kernel front which also make XFS behave better. >Are the newest patches in CVS or on the ftp-server? The patches on the FTP site have the same fixes as the ones that are commited to CVS. The CVS tree however also tracks Linus -pre versions. But the patches are provided for people that don't want to run -pre kernels. > > Most people reported succes with 2.95.3+ and there have been some fixes > > for the tree for compiling with newer kernels. > >Hmmm. 2.95.3+ does it mean 2.95.3 or higher or is it the name of this >gcc-version? or higher. Make sure you use 2.4.5 or later since that contains the patches. > > Try compiling the tree first with your native compiler and see what > > happens. > >But the problems reported on the mailing-list with the gcc 2.95 occured >afterwards (while using XFS), or? The problems with 2.95 were hanging processes. I believe this also occured on normal kernels. That is the only problem with 2.95 I know of. Bye -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sun Jun 17 22:55:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5I5teO02775 for linux-xfs-outgoing; Sun, 17 Jun 2001 22:55:40 -0700 Received: from groucho.maths.monash.edu.au (groucho.maths.monash.edu.au [130.194.160.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5I5tdV02772 for ; Sun, 17 Jun 2001 22:55:39 -0700 Received: (from rjh@localhost) by groucho.maths.monash.edu.au (8.8.8/8.8.8) id FAA00389 for linux-xfs@oss.sgi.com; Mon, 18 Jun 2001 05:55:36 GMT From: Robin Humble Message-Id: <200106180555.FAA00389@groucho.maths.monash.edu.au> Subject: Re: XFS and RAID5 To: linux-xfs@oss.sgi.com Date: Mon, 18 Jun 2001 15:55:36 +1000 (EST) In-Reply-To: <4.3.2.7.2.20010618070434.02d268e0@pop.xs4all.nl> from "Seth Mos" at Jun 18, 2001 07:14:56 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth writes: >At 23:31 17-6-2001 +0200, Knuth Posern wrote: >>Thanks for your fast and long answer! >> > not suffered data as of yet. (knock on wood). I have no expierence about >> > XFS over Raid5. I have the number of disks for it but unfortunately not >>Did you hear something about XFS over Software-RAID5? >I ment XFS over software Raid5. Hardware raid practically always works >unless the hardware raid driver is broken. I've avoided entering this thread since we're currently not running software RAID5 but thought I'd stick up my paw anyway 'cos we ran it for a fair while and will happily run it again. Around the time of the 2.4.3 kernel we used XFS over software RAID5 for a month or so before a disk died and we didn't bother replacing it - we've been using 420G (7 disks) of RAID0 since with zero problems. RAID5 seemed ok and we sorted out any initial performance problems as we found them with the super-responsive XFS people on this list. Hopefuly we'll be firing up a NFS + software RAID5 + gigabit ethernet box within the next couple of weeks, and expect that XFS will be the only valid choice for such a filesystem. Especially as we're at the large end of file sizes - I expect all writes to be >= 4G. >> > The only problems with md is running in degraded mode. But it does work. >>md is one of the XFS-utils? - I didn't look at them yet... >It's not, md is the kernel driver. When your raid misses one disk it will >run in degraded mode. This when XFS will perform worse. When you replace >the disk the resyncing was not always op to speed. yeah, RAID5 rebuilding on 480G/8disks took maybe 8 hours (this is back in march - might be better now?), but only 1hr if you could leave the filesystem unmounted and XFS could thus avoid changing the block sizes in the kernel and md layer all the time... cheers, robin From owner-linux-xfs@oss.sgi.com Sun Jun 17 23:51:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5I6pgL03570 for linux-xfs-outgoing; Sun, 17 Jun 2001 23:51:42 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5I6pfV03567 for ; Sun, 17 Jun 2001 23:51:41 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5I6pYV14565; Mon, 18 Jun 2001 08:51:35 +0200 Message-Id: <4.3.2.7.2.20010618084228.037980f0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Jun 2001 08:51:30 +0200 To: Robin Humble , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: XFS and RAID5 In-Reply-To: <200106180555.FAA00389@groucho.maths.monash.edu.au> References: <4.3.2.7.2.20010618070434.02d268e0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:55 18-6-2001 +1000, Robin Humble wrote: >Seth writes: > >At 23:31 17-6-2001 +0200, Knuth Posern wrote: > >>Thanks for your fast and long answer! > >> > not suffered data as of yet. (knock on wood). I have no expierence about > >> > XFS over Raid5. I have the number of disks for it but unfortunately not > >>Did you hear something about XFS over Software-RAID5? > >I ment XFS over software Raid5. Hardware raid practically always works > >unless the hardware raid driver is broken. > >I've avoided entering this thread since we're currently not running >software RAID5 but thought I'd stick up my paw anyway 'cos we ran it for >a fair while and will happily run it again. > >Around the time of the 2.4.3 kernel we used XFS over software RAID5 for >a month or so before a disk died and we didn't bother replacing it - >we've been using 420G (7 disks) of RAID0 since with zero problems. >RAID5 seemed ok and we sorted out any initial performance problems >as we found them with the super-responsive XFS people on this list. > >Hopefuly we'll be firing up a NFS + software RAID5 + gigabit ethernet >box within the next couple of weeks, and expect that XFS will be the >only valid choice for such a filesystem. Especially as we're at the >large end of file sizes - I expect all writes to be >= 4G. > > >> > The only problems with md is running in degraded mode. But it does work. > >>md is one of the XFS-utils? - I didn't look at them yet... > >It's not, md is the kernel driver. When your raid misses one disk it will > >run in degraded mode. This when XFS will perform worse. When you replace > >the disk the resyncing was not always op to speed. > >yeah, RAID5 rebuilding on 480G/8disks took maybe 8 hours (this is >back in march - might be better now?), but only 1hr if you could >leave the filesystem unmounted and XFS could thus avoid changing the >block sizes in the kernel and md layer all the time... Thank You! Let us know what happens. Bye -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Jun 18 00:27:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5I7RSX04065 for linux-xfs-outgoing; Mon, 18 Jun 2001 00:27:28 -0700 Received: from babel.spoiled.org (babel.spoiled.org [212.84.234.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5I7RQV04062 for ; Mon, 18 Jun 2001 00:27:26 -0700 Received: (qmail 27919 invoked by uid 8); 18 Jun 2001 07:27:25 -0000 From: thomas graichen Reply-To: thomas graichen X-Newsgroups: spoiled.linux.sgi.xfs Subject: content Date: Mon, 18 Jun 2001 09:12:06 +0200 Organization: spoiled dot org Lines: 23 Distribution: local Message-ID: Reply-To: thomas graichen X-Complaints-To: newsmaster@spoiled.org User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.3-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk just a small wish: can we please stay on the topic of XFS on this list here? ... the XFS list now has reached close to half of the traffic of the kernel list and thus i would really like to see it reaching a better signal/noise ratio ... i think discussions about the best mailer do not belong here as discussions about how good the GPL or another licence is do ... there are other mailinglists or newsgroups for those topics and there is always the option to reply directly to the author instead of to the list for offtopic things - this list here is about the XFS filesystem - please keep that in mind ... a lot of thanks in advance t p.s.: i also still think it would be a good idea to create a xfs-users list to separate the technical stuff from things like "the XFS kernel does not like USB" or similar -- thomas graichen ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery From owner-linux-xfs@oss.sgi.com Mon Jun 18 00:30:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5I7UEo04117 for linux-xfs-outgoing; Mon, 18 Jun 2001 00:30:14 -0700 Received: from mail.crc.dk (mail.crc.dk [130.226.184.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5I7UDV04114 for ; Mon, 18 Jun 2001 00:30:13 -0700 Received: from crc.dk (k020-03.crc.dk [130.226.182.195]) by mail.crc.dk (8.9.3/8.9.3) with ESMTP id JAA28472; Mon, 18 Jun 2001 09:30:07 +0200 Message-ID: <3B2DADFE.9CB35F81@crc.dk> Date: Mon, 18 Jun 2001 09:30:06 +0200 From: Mogens Kjaer Organization: Carlsberg Laboratory X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2win4lin i686) X-Accept-Language: da, en, de MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: NFS/pwd probs w/today's CVS dist References: <200106151851.NAA13538@fsgi158.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Tad Dolphay wrote: > The "missing files/directories problem" is seen with a Linux client and an Irix > server. This is a glibc problem on Linux. More info at: > http://sources.redhat.com/ml/libc-alpha/2001-02/msg00118.html This glibc problem is solved with a kernel patch. This patch is also included in RH's rawhide kernels. Mogens -- Mogens Kjaer, Carlsberg Laboratory, Dept. of Chemistry Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark Phone: +45 33 27 53 25, Fax: +45 33 27 47 08 Email: mk@crc.dk Homepage: http://www.crc.dk From owner-linux-xfs@oss.sgi.com Mon Jun 18 00:57:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5I7vBx04514 for linux-xfs-outgoing; Mon, 18 Jun 2001 00:57:11 -0700 Received: from studsv07.studserv.uni-stuttgart.de (studsv07.studserv.uni-stuttgart.de [129.69.21.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5I7v9V04511 for ; Mon, 18 Jun 2001 00:57:09 -0700 Received: from ysabell.wh.vaih [129.69.166.244] by studsv07.studserv.uni-stuttgart.de with ESMTP (SMTPD32-6.06) id A4512997008E; Mon, 18 Jun 2001 09:57:05 +0200 Received: from marcelo by ysabell.wh.vaih with local (Exim 3.22 #1 (Debian)) id 15Btu9-0000Gr-00 for ; Mon, 18 Jun 2001 09:57:01 +0200 Date: Mon, 18 Jun 2001 09:57:01 +0200 From: "Marcelo E. Magallon" To: linux-xfs@oss.sgi.com Subject: Stress test 015 need to check partition size Message-ID: <20010618095701.A984@ysabell.wh.vaih> 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.3.18i X-Operating-System: Linux ysabell 2.4.4-xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, 015 is trying to create a 50MB data section on the device, but don't check if the operation is sucessful: mkfs -t xfs -f -d size=50m $SCRATCH_DEV >/dev/null 016 does check, but exits with an error instead of using _notrun. -- Marcelo From owner-linux-xfs@oss.sgi.com Mon Jun 18 05:54:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5ICst508384 for linux-xfs-outgoing; Mon, 18 Jun 2001 05:54:55 -0700 Received: from syr-66-24-57-44.twcny.rr.com (syr-66-24-57-44.twcny.rr.com [66.24.57.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5ICssV08381 for ; Mon, 18 Jun 2001 05:54:54 -0700 Received: (from eem12@localhost) by syr-66-24-57-44.twcny.rr.com (8.11.2/8.9.3) id f5ICuPB03749; Mon, 18 Jun 2001 08:56:25 -0400 Date: Mon, 18 Jun 2001 08:56:24 -0400 From: Ed McKenzie To: Robin Humble Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and RAID5 Message-ID: <20010618085624.A3739@cornell.edu> References: <4.3.2.7.2.20010618070434.02d268e0@pop.xs4all.nl> <200106180555.FAA00389@groucho.maths.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106180555.FAA00389@groucho.maths.monash.edu.au>; from rjh@groucho.maths.monash.edu.au on Mon, Jun 18, 2001 at 03:55:36PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Jun 18, 2001 at 03:55:36PM +1000, Robin Humble wrote: > Hopefuly we'll be firing up a NFS + software RAID5 + gigabit ethernet > box within the next couple of weeks, and expect that XFS will be the > only valid choice for such a filesystem. Especially as we're at the > large end of file sizes - I expect all writes to be >= 4G. Note that ext2 and reiserfs also support >2G files on x86 running 2.4 and proper glibc -- see http://www.suse.de/~aj/linux_lfs.html. (Not that those would be _better_ choices, but XFS is hardly "the only valid choice" :) -ed From owner-linux-xfs@oss.sgi.com Mon Jun 18 06:13:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IDDG108712 for linux-xfs-outgoing; Mon, 18 Jun 2001 06:13:16 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IDDFV08709 for ; Mon, 18 Jun 2001 06:13:15 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5IDD9P22480 for linux-xfs@oss.sgi.com; Mon, 18 Jun 2001 09:13:09 -0400 Date: Mon, 18 Jun 2001 09:13:09 -0400 From: Alan Eldridge To: linux-xfs@oss.sgi.com Subject: CVSup question Message-ID: <20010618091309.A21103@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk What's the meaning of the "tag=." parameter in cvsup? I'm not clear on how this works. E.g., on KDE, "tag=." always gets the latest "HEAD" branch of the tree. On the XFS CVSup page, the text implies that *omitting* the "tag=." is how to keep up to date. -- Alan Eldridge From owner-linux-xfs@oss.sgi.com Mon Jun 18 06:13:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IDDa108744 for linux-xfs-outgoing; Mon, 18 Jun 2001 06:13:36 -0700 Received: from dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IDDZV08741 for ; Mon, 18 Jun 2001 06:13:36 -0700 Received: (from ak@localhost) by dkp.com (8.9.3/8.9.3) id JAA02335 for linux-xfs@oss.sgi.com; Mon, 18 Jun 2001 09:13:34 -0400 Date: Mon, 18 Jun 2001 09:13:34 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: XFS and RAID5 Message-ID: <20010618091334.A2209@key.dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <4.3.2.7.2.20010618070434.02d268e0@pop.xs4all.nl> <200106180555.FAA00389@groucho.maths.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200106180555.FAA00389@groucho.maths.monash.edu.au>; from rjh@groucho.maths.monash.edu.au on Mon, Jun 18, 2001 at 03:55:36PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Jun 18, 2001 at 03:55:36PM +1000, Robin Humble wrote: > Around the time of the 2.4.3 kernel we used XFS over software > RAID5 for a month or so before a disk died and we didn't > bother replacing it - we've been using 420G (7 disks) of RAID0 > since with zero problems. RAID5 seemed ok and we sorted out > any initial performance problems as we found them with the > super-responsive XFS people on this list. 7 disks? I'm curious: SCSI or IDE? (We're looking into a Promise or 3ware card to allow us to put lots of IDE drives in a box and run software RAID over top, and were wondering if anyone else has had experience with these cards+software RAID+XFS.) Andrew Klaassen From owner-linux-xfs@oss.sgi.com Mon Jun 18 06:21:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IDLYF09065 for linux-xfs-outgoing; Mon, 18 Jun 2001 06:21:34 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IDLWV09062 for ; Mon, 18 Jun 2001 06:21:33 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5IDLGV17101; Mon, 18 Jun 2001 15:21:17 +0200 Message-Id: <4.3.2.7.2.20010618152002.037ca3d8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Jun 2001 15:21:12 +0200 To: Ed McKenzie , Robin Humble From: Seth Mos Subject: Re: XFS and RAID5 Cc: linux-xfs@oss.sgi.com In-Reply-To: <20010618085624.A3739@cornell.edu> References: <200106180555.FAA00389@groucho.maths.monash.edu.au> <4.3.2.7.2.20010618070434.02d268e0@pop.xs4all.nl> <200106180555.FAA00389@groucho.maths.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 08:56 18-6-2001 -0400, Ed McKenzie wrote: >On Mon, Jun 18, 2001 at 03:55:36PM +1000, Robin Humble wrote: > > Hopefuly we'll be firing up a NFS + software RAID5 + gigabit ethernet > > box within the next couple of weeks, and expect that XFS will be the > > only valid choice for such a filesystem. Especially as we're at the > > large end of file sizes - I expect all writes to be >= 4G. > >Note that ext2 and reiserfs also support >2G files on x86 running 2.4 >and proper glibc -- see http://www.suse.de/~aj/linux_lfs.html. This is over NFS. ReiserFS is somewhat unproven with respect to NFS and ext2 has long fsck times. >(Not that those would be _better_ choices, but XFS is hardly "the only >valid choice" :) Better is arguable and a personal preference. Bye -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Jun 18 06:33:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IDXN609273 for linux-xfs-outgoing; Mon, 18 Jun 2001 06:33:23 -0700 Received: from amoa.org (amoa.org [207.207.51.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IDXMV09270 for ; Mon, 18 Jun 2001 06:33:22 -0700 Received: by amoa.org(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256A6F.004A8461 ; Mon, 18 Jun 2001 08:33:55 -0500 X-Lotus-FromDomain: AMOA From: ctooley@amoa.org To: linux-xfs@oss.sgi.com Message-ID: <86256A6F.004A832A.00@amoa.org> Date: Mon, 18 Jun 2001 08:33:51 -0500 Subject: Re: XFS and RAID5 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Put my first XFS partition into production use this weekend on top of Software RAID 0 sets. The thing that I've found that affects write performance most is the drive itself. We have dedicated a controller to each disk (a two controller Promise card for each of the two disk sets) and performance seems pretty good. As dangerous as it sounds (to the hardware and the data alike) I've even pulled the power on the IDE drive while it was running (DON"T DO THIS!!) and had no adverous affects. Your mileage may vary, but we're very happy. I have noticed that XFS has pretty much the same speeds as ext2+ea+acl when running on identical hardware, but of course you have journalling so XFS gets the call. If only I'd have known that before there was a ton of data on the disks. Chris Tooley Andrew Klaassen on 06/18/2001 08:13:34 AM To: linux-xfs@oss.sgi.com cc: (bcc: Chris Tooley/AMOA) Subject Re: XFS and RAID5 : On Mon, Jun 18, 2001 at 03:55:36PM +1000, Robin Humble wrote: > Around the time of the 2.4.3 kernel we used XFS over software > RAID5 for a month or so before a disk died and we didn't > bother replacing it - we've been using 420G (7 disks) of RAID0 > since with zero problems. RAID5 seemed ok and we sorted out > any initial performance problems as we found them with the > super-responsive XFS people on this list. 7 disks? I'm curious: SCSI or IDE? (We're looking into a Promise or 3ware card to allow us to put lots of IDE drives in a box and run software RAID over top, and were wondering if anyone else has had experience with these cards+software RAID+XFS.) Andrew Klaassen From owner-linux-xfs@oss.sgi.com Mon Jun 18 06:43:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IDhO009510 for linux-xfs-outgoing; Mon, 18 Jun 2001 06:43:24 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IDhMV09507 for ; Mon, 18 Jun 2001 06:43:22 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5IDgKV17274; Mon, 18 Jun 2001 15:42:20 +0200 Message-Id: <4.3.2.7.2.20010618153515.02d29138@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Jun 2001 15:42:16 +0200 To: Andrew Klaassen , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: XFS and RAID5 In-Reply-To: <20010618091334.A2209@key.dkp.com> References: <200106180555.FAA00389@groucho.maths.monash.edu.au> <4.3.2.7.2.20010618070434.02d268e0@pop.xs4all.nl> <200106180555.FAA00389@groucho.maths.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 09:13 18-6-2001 -0400, Andrew Klaassen wrote: >On Mon, Jun 18, 2001 at 03:55:36PM +1000, >Robin Humble wrote: > > > Around the time of the 2.4.3 kernel we used XFS over software > > RAID5 for a month or so before a disk died and we didn't > > bother replacing it - we've been using 420G (7 disks) of RAID0 > > since with zero problems. RAID5 seemed ok and we sorted out > > any initial performance problems as we found them with the > > super-responsive XFS people on this list. > >7 disks? I'm curious: SCSI or IDE? (We're looking into a >Promise or 3ware card to allow us to put lots of IDE drives in a >box and run software RAID over top, and were wondering if anyone >else has had experience with these cards+software RAID+XFS.) IIRC the 3ware driver is a bit shakey. The 3ware card is a hardware raid solution and not a software one. If you use promise cards you will probably use software raid. The issue with the 3ware raid was firmware related. If the controller was missing a disk and running in degraded mode file system corruption could and would occur. Other then that it is a fine IDE raid controller. >Andrew Klaassen Good luck -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Jun 18 06:47:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IDlr409659 for linux-xfs-outgoing; Mon, 18 Jun 2001 06:47:53 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IDloV09655 for ; Mon, 18 Jun 2001 06:47:51 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id PAA20766; Mon, 18 Jun 2001 15:47:48 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id PAA03579; Mon, 18 Jun 2001 15:47:48 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 2A7A757306; Mon, 18 Jun 2001 15:56:41 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id EA1A725835; Mon, 18 Jun 2001 16:04:57 +0200 (CEST) Message-ID: <3B2E0747.6E682C86@ch.sauter-bc.com> Date: Mon, 18 Jun 2001 15:51:03 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Andrew Klaassen Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and RAID5 References: <4.3.2.7.2.20010618070434.02d268e0@pop.xs4all.nl> <200106180555.FAA00389@groucho.maths.monash.edu.au> <20010618091334.A2209@key.dkp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm currently setting up two 240GB Servers with 4360G IDE ATA100 drives. The machine is DELL Precision 220 with PIII/933 and 256M RDRAM. Chipset is i820 (Camino). I made several RAID1 partitions for the system and one 180G RAID5, LVM on top of it and XFS file- systems inside of the lvols. It performs very well but the big problem is that I get corrupt files on the RAID1 and RAID5 volumes. I'm shure it's a problem of the mainboard / chipset since I have the same config on my old P200MMX at home with absolutely no problem. The next step was to buy a Promise IDE controller and I bought the new Ultra100 TX2 cos it was cheap and available around the corner. But oh my, it was listed compatible with RH 6.2 and 7.0 on the package but it is NOT. So I went to linux-ide.org and got the IDE patch and created patched RH-7.1-XFS kernel filesets. I will try them today on the DELL. Now I downloaded rawhide kernel 2.4.5 RPMS and if the Promise TX2 test is successful, I will try to create patched RPMS of 2.4.5 as well. If you are interested in my Promise TX2 patched RPMS, let me know. Simon Andrew Klaassen schrieb: > > On Mon, Jun 18, 2001 at 03:55:36PM +1000, > Robin Humble wrote: > > > Around the time of the 2.4.3 kernel we used XFS over software > > RAID5 for a month or so before a disk died and we didn't > > bother replacing it - we've been using 420G (7 disks) of RAID0 > > since with zero problems. RAID5 seemed ok and we sorted out > > any initial performance problems as we found them with the > > super-responsive XFS people on this list. > > 7 disks? I'm curious: SCSI or IDE? (We're looking into a > Promise or 3ware card to allow us to put lots of IDE drives in a > box and run software RAID over top, and were wondering if anyone > else has had experience with these cards+software RAID+XFS.) > > Andrew Klaassen -- 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 Mon Jun 18 07:21:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IELcN10323 for linux-xfs-outgoing; Mon, 18 Jun 2001 07:21:38 -0700 Received: from rogue.tripp.org (fdsl9.slkc.uswest.net [209.181.83.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IELaV10318 for ; Mon, 18 Jun 2001 07:21:36 -0700 Received: from localhost (justin@localhost) by rogue.tripp.org (8.9.3/8.9.3) with ESMTP id IAA44631; Mon, 18 Jun 2001 08:21:19 -0600 (MDT) (envelope-from justin@tripp.org) Date: Mon, 18 Jun 2001 08:21:19 -0600 (MDT) From: Justin Tripp X-X-Sender: To: Seth Mos cc: Andrew Klaassen , Subject: Re: XFS and RAID5 In-Reply-To: <4.3.2.7.2.20010618153515.02d29138@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have used both the 3ware and Promise Raid solutions. Their are two Promise RAID cards. Only one will work with linux and it is a software raid solution. Promise only supports RedHat 6.1,6.2 and Suse 6.2, and only the basic kernels in those releases. So, if you are not interested in XFS, then you could try them out. It is likely, though, that you could get the same performance (and cheaper), but just buying a additional promise IDE controller and running the kernel's software raid on top of that. And then you could run any kernel you desired to -- plus XFS. IDE software RAID is not likely to have too great of performance. (FYI Promise's kernel driver is not open source, only part of it is and I never did get them to return any emails I sent them about using the card under linux). 3ware, on the other hand, is a hardware raid. As far as your computer is concerned you have a SCSI controller hooked to a pci slot. The overhead of IDE disks is not seen by the processor since it only interacts with the Raid controller and cannot see the individual disks. I have a 3ware controller with 4 40G disks running RAID 5 with XFS as the underlying filesystem. It works quite well. 3ware did have problems with the firmware and RAID5, but these have been fixed and can easily be obtained from their website. The problems only occured if the RAID ran in degraded mode, and if one did not have a disk failure, then the problem never occurred. (Phew). The kernel driver works well in the 2.2 kernels, but 3ware is not too keen on helping you run in 2.4. Now that some distributions ship with 2.4, they may be changing their minds, but... Nonetheless, their driver is open source and is part of the kernel tree. The driver I am running is cut out of the 2.4.5-ac5 patch and applied to a 2.4.5 cvs version of XFS. I have not had any problems despite the fact that XFS seems to exercise the underlying hardware more than ext2 does. I believe the 3ware card is a reasonably cheap way to get a 100+G raid. But I did have to do some light kernel hacking to get everything working reasonably well. .justin. On Mon, 18 Jun 2001, Seth Mos wrote: > At 09:13 18-6-2001 -0400, Andrew Klaassen wrote: > >On Mon, Jun 18, 2001 at 03:55:36PM +1000, > >Robin Humble wrote: > > > > > Around the time of the 2.4.3 kernel we used XFS over software > > > RAID5 for a month or so before a disk died and we didn't > > > bother replacing it - we've been using 420G (7 disks) of RAID0 > > > since with zero problems. RAID5 seemed ok and we sorted out > > > any initial performance problems as we found them with the > > > super-responsive XFS people on this list. > > > >7 disks? I'm curious: SCSI or IDE? (We're looking into a > >Promise or 3ware card to allow us to put lots of IDE drives in a > >box and run software RAID over top, and were wondering if anyone > >else has had experience with these cards+software RAID+XFS.) > > IIRC the 3ware driver is a bit shakey. The 3ware card is a hardware raid > solution and not a software one. If you use promise cards you will probably > use software raid. > > The issue with the 3ware raid was firmware related. If the controller was > missing a disk and running in degraded mode file system corruption could > and would occur. > Other then that it is a fine IDE raid controller. > > > >Andrew Klaassen > > Good luck > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. > > From owner-linux-xfs@oss.sgi.com Mon Jun 18 07:23:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IENtQ10472 for linux-xfs-outgoing; Mon, 18 Jun 2001 07:23:55 -0700 Received: from troll.dimensional.de (dimensional.komed.de [195.185.110.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IENsV10469 for ; Mon, 18 Jun 2001 07:23:54 -0700 Received: from skera.dimensional.de ([192.168.1.100] helo=skera ident=lukas) by troll.dimensional.de with smtp (Exim 3.12 #1 (Debian)) id 15BztH-0003i4-00 for ; Mon, 18 Jun 2001 16:20:31 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Christoph Lukas To: linux-xfs@oss.sgi.com Subject: using xfsdump with 'file device' Date: Mon, 18 Jun 2001 16:30:32 +0200 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <0106181630320C.01455@skera> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, we would like to use xfsdump to backup one of our xfs filesystems onto another hard disk. Therefore I tried: xfsdump -l0 -F -f /mnt/backupfile /dev/sda3 Although we are running kernel 2.4.3 and glibc _with_ >2GB support (tried with 'dd if=/dev/null of=/mnt/testfile' ) xfsdump exits after dumping 2GB with: xfsdump: creating dump session media file 0 (media 0, file 0) xfsdump: dumping ino map xfsdump: dumping directories xfsdump: dumping non-directory files File size limit exceeded is there any possibility to exceed this limit (compile time option?) or any easy alternative to work with multiple 2GB files (like the ordinary dump does)? Thanks, Christoph From owner-linux-xfs@oss.sgi.com Mon Jun 18 07:46:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IEknA11004 for linux-xfs-outgoing; Mon, 18 Jun 2001 07:46:49 -0700 Received: from electre.pasteur.fr (electre.pasteur.fr [157.99.64.120]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IEkkV11000 for ; Mon, 18 Jun 2001 07:46:46 -0700 Received: from pasteur.fr (xiii.bis.pasteur.fr [157.99.90.14]) by electre.pasteur.fr (8.11.4/8.11.4) with ESMTP id f5IEjO088319; Mon, 18 Jun 2001 16:45:24 +0200 (CEST) Message-ID: <3B2DE89C.DEF5D5B7@pasteur.fr> Date: Mon, 18 Jun 2001 16:40:12 +0500 From: Tru Huynh Organization: Institut Pasteur X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Justin Tripp CC: Seth Mos , Andrew Klaassen , linux-xfs@oss.sgi.com Subject: 3ware (was Re: XFS and RAID5) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Justin Tripp wrote: > <...> > > 3ware, on the other hand, is a hardware raid. As far as your computer is > concerned you have a SCSI controller hooked to a pci slot. The overhead > of IDE disks is not seen by the processor since it only interacts with the > Raid controller and cannot see the individual disks. I have a 3ware > controller with 4 40G disks running RAID 5 with XFS as the underlying > filesystem. It works quite well. We are testing the 7+1 raid5 solution on a Rocky 3782-EV motherboard (i815E) and a p3-800eb with 2x256MB ram. And the performace with the raid5 hardware was "bad": * ~6GB nfsv3 transfert write to an ext2 partition takes ~20 min against 1h40 on the raid5 hardware array * mkfs.ext2 of 250MB takes 1h30... * mkfs.xfs was in the order of 10 sec. but the write was even longer (I stopped after 2h!) 3ware support believe that is is cause by the memory subsystem which is too slow... 'hdparm -T /dev/sda' : This is the buffer cache read speed. This is the upper-bound for the system. If this number is not over 100MB/s, the system you are on has a memory load-copy bottleneck with Linux. It could be since hdparm on the raid5 server gives: Timing buffer-cache reads: 128 MB in 1.28 seconds =100.00 MB/sec against on a 440BX motherboard is: Timing buffer-cache reads: 128 MB in 0.72 seconds =177.78 MB/sec Bonnie++ Version 1.00g a) ext2 partition on the boot disk - linux 2.4.5ac13 alineas,1G,10779,98,37033,34, 8364, 8,8237,77,25792,12,172.4,0,16,458,99,+++++,+++,25308,97,463,99,+++++,+++,2692,99 b)ext2 whole array==sda1 3ware RAID5 - linux 2.4.5ac13 alineas,1G, 2138,19, 1885, 1, 1479, 1,5473,51,57514,23,461.9,1,16,529,99,+++++,+++,25462,96,516,95,+++++,+++,3188,97 c) ext2 md0 software raid5 - linux 2.4.5ac13 alineas,1G, 8919,82,19996,19,13627,16,8809,94,47391,81,338.7,3,16,462,99,+++++,+++,24882,97,464,99,+++++,+++,2858,99 Anyone care to comment? Regards, Tru -- Dr Tru Huynh | Bioinformatique Structurale mailto:tru@pasteur.fr | tel/fax +33 1 45 68 87 37/19 Institut Pasteur, 25-28 rue du Docteur Roux, 75724 Paris CEDEX 15 France From owner-linux-xfs@oss.sgi.com Mon Jun 18 08:21:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IFLV711805 for linux-xfs-outgoing; Mon, 18 Jun 2001 08:21:31 -0700 Received: from deliverator.sgi.com ([204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IFLUV11802 for ; Mon, 18 Jun 2001 08:21:30 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA11137 for ; Mon, 18 Jun 2001 08:20:33 -0700 (PDT) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2104416 for ; Mon, 18 Jun 2001 10:19:20 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.184.30]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA18166 for ; Mon, 18 Jun 2001 10:19:20 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id KAA76096; Mon, 18 Jun 2001 10:19:20 -0500 (CDT) Message-Id: <200106181519.KAA76096@slobber.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: Re: XFS module problems -- usage count incorrect Date: Mon, 18 Jun 2001 10:19:19 -0500 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: Keith Owens >init_xfs_fs() calls dmapi_init() which does MOD_INC_USE_COUNT. Compile >XFS without DMAPI support and your problem will disappear. > >The module related code in dmapi is a hangover from a time when dmapi >was a module in its own right instead of being linked into xfs.o. I >will remove module related code from dmapi, I will also review grio, to >make sure it does not have the same problem. No, it's not a hangover. It was put there last week to keep the reference count up. If you've been using DMAPI then you cannot allow the module to be unloaded unless DMAPI says it's okay. DMAPI won't say it's okay unless it's clear that no HSMs are using it (whether or not any XFS filesystems are mounted, an HSM could still be there, watching the DMAPI queues, waiting for one to be mounted.) DMAPI needs a way to say that the XFS module is busy--I thought MOD_INC_USE_COUNT was the proper method. If dm_uninit() is giving false positives then that's another issue entirely. Dean From owner-linux-xfs@oss.sgi.com Mon Jun 18 08:24:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IFOZL11938 for linux-xfs-outgoing; Mon, 18 Jun 2001 08:24:35 -0700 Received: from deliverator.sgi.com ([204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IFOYV11935 for ; Mon, 18 Jun 2001 08:24:34 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA11633 for ; Mon, 18 Jun 2001 08:23:36 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2186705; Mon, 18 Jun 2001 10:22:23 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA38150; Mon, 18 Jun 2001 10:22:23 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5IFP1918677; Mon, 18 Jun 2001 10:25:01 -0500 Message-Id: <200106181525.f5IFP1918677@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Christoph Lukas cc: linux-xfs@oss.sgi.com Subject: Re: using xfsdump with 'file device' In-Reply-To: Message from Christoph Lukas of "Mon, 18 Jun 2001 16:30:32 +0200." <0106181630320C.01455@skera> Date: Mon, 18 Jun 2001 10:25:01 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi, > > we would like to use xfsdump to backup one of our xfs filesystems onto > another hard disk. Therefore I tried: > > xfsdump -l0 -F -f /mnt/backupfile /dev/sda3 > > Although we are running kernel 2.4.3 and glibc _with_ >2GB support (tried > with 'dd if=/dev/null of=/mnt/testfile' ) xfsdump exits after dumping 2GB > with: > > xfsdump: creating dump session media file 0 (media 0, file 0) > xfsdump: dumping ino map > xfsdump: dumping directories > xfsdump: dumping non-directory files > File size limit exceeded This is odd, I just created a 2621561952 byte dump file here. Where did you get the xfsdump program from - an RPM we built, or did you compile it yourself? There are current command rpms here: ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/ which should be identical to the version I just tested with. Steve > > is there any possibility to exceed this limit (compile time option?) or any > easy alternative to work with multiple 2GB files (like the ordinary dump > does)? > > Thanks, > Christoph From owner-linux-xfs@oss.sgi.com Mon Jun 18 08:36:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IFaEo12193 for linux-xfs-outgoing; Mon, 18 Jun 2001 08:36:14 -0700 Received: from groucho.maths.monash.edu.au (groucho.maths.monash.edu.au [130.194.160.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IFaCV12190 for ; Mon, 18 Jun 2001 08:36:13 -0700 Received: (from rjh@localhost) by groucho.maths.monash.edu.au (8.8.8/8.8.8) id PAA09163; Mon, 18 Jun 2001 15:36:10 GMT From: Robin Humble Message-Id: <200106181536.PAA09163@groucho.maths.monash.edu.au> Subject: Re: XFS and RAID5 To: linux-xfs@oss.sgi.com Date: Tue, 19 Jun 2001 01:36:10 +1000 (EST) Cc: eem12@cornell.edu In-Reply-To: <20010618085624.A3739@cornell.edu> from "Ed McKenzie" at Jun 18, 2001 08:56:24 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ed McKenzie writes: >On Mon, Jun 18, 2001 at 03:55:36PM +1000, Robin Humble wrote: >> Hopefuly we'll be firing up a NFS + software RAID5 + gigabit ethernet >> box within the next couple of weeks, and expect that XFS will be the >> only valid choice for such a filesystem. Especially as we're at the >> large end of file sizes - I expect all writes to be >= 4G. >Note that ext2 and reiserfs also support >2G files on x86 running 2.4 >and proper glibc -- see http://www.suse.de/~aj/linux_lfs.html. Sorry, I didn't phrase it well - I wasn't talking about any 32bit issues, but that for performance reasons XFS is the best choice for us - it performs well at most file sizes, but tends to win by an increasing margin as transfer sizes get larger. This is what my tests and most benchmarks I've seen show - of course you should do some tests yourself with your specific i/o patterns to see how it performs for you. If you were doing zillions of operations on 12byte files then ReiserFS would probably be quicker. >(Not that those would be _better_ choices, but XFS is hardly "the only >valid choice" :) I didn't have any luck getting ReiserFS working reliably with NFS and hetrogeneous clients (Tru64,IRIX,...) so it wasn't a valid choice for me at all. They may have fixed that by now. cheers, robin From owner-linux-xfs@oss.sgi.com Mon Jun 18 08:40:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IFeCG12345 for linux-xfs-outgoing; Mon, 18 Jun 2001 08:40:12 -0700 Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IFeBV12342 for ; Mon, 18 Jun 2001 08:40:11 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f5IFdh805572; Mon, 18 Jun 2001 10:39:44 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <3B2E20BF.1FDB7278@thebarn.com> Date: Mon, 18 Jun 2001 10:39:43 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Alan Eldridge CC: linux-xfs@oss.sgi.com Subject: Re: CVSup question References: <20010618091309.A21103@wwweasel.geeksrus.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alan Eldridge wrote: > What's the meaning of the "tag=." parameter in cvsup? I'm not clear on how > this works. E.g., on KDE, "tag=." always gets the latest "HEAD" branch of > the tree. On the XFS CVSup page, the text implies that *omitting* the > "tag=." is how to keep up to date. the tag directive can be used to pull a specific cvs/rcs from the tree eg tag=RELEASE-1_0 tag=. indicated top of main branch, (top of devel tree) Dropping the tag directive altogether pulls the cvs tree itself. > > > -- > Alan Eldridge -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Mon Jun 18 09:11:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IGB2P12797 for linux-xfs-outgoing; Mon, 18 Jun 2001 09:11:02 -0700 Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IGB0V12794 for ; Mon, 18 Jun 2001 09:11:00 -0700 Received: from heppcl.ph.qmw.ac.uk ([138.37.50.187]) by zeta.qmw.ac.uk with esmtp (Exim 3.16 #1) id 15C1c9-0007Bw-00 for linux-xfs@oss.sgi.com; Mon, 18 Jun 2001 17:10:57 +0100 Received: from heppct.ph.qmw.ac.uk (heppct.ph.qmw.ac.uk [138.37.50.246]) by heppcl.ph.qmw.ac.uk (8.9.3/8.9.3) with ESMTP id RAA12448 for ; Mon, 18 Jun 2001 17:10:58 +0100 Received: from localhost (pd@localhost) by heppct.ph.qmw.ac.uk (8.11.2/8.9.3) with ESMTP id f5IGAw826846 for ; Mon, 18 Jun 2001 17:10:58 +0100 X-Authentication-Warning: heppct.ph.qmw.ac.uk: pd owned process doing -bs Date: Mon, 18 Jun 2001 17:10:58 +0100 (BST) From: "P.Dixon" To: Subject: kernel panic with Rawhide RPM In-Reply-To: <3B2DE89C.DEF5D5B7@pasteur.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I just had a kernel panic on our backup server while rsyncing a file system from our main server: Kernel Panic: Kmem_zone_Zalloc: NULL memory on KM_SLEEP request! Nothing else appears im the log files. I was using kernel-smp-2.4.5-0.2.9_SGI_XFS_20010613 Dunno of this is xfs related, but I've posted FYI, just in case. Cheerio, Paul ------------------------------------------------------------------------------- Paul Dixon Email: P.Dixon@qmw.ac.uk Department of Physics Phone: (020) 7882 5054 Queen Mary, University of London Fax : (020) 7882 5054 Mile End Road, London E1 4NS URL : http://hepwww.ph.qmw.ac.uk/~pd ------------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Jun 18 09:19:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IGJAk13022 for linux-xfs-outgoing; Mon, 18 Jun 2001 09:19:10 -0700 Received: from merlin.giref.ulaval.ca (postfix@merlin.giref.ulaval.ca [132.203.7.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IGJ9V13019 for ; Mon, 18 Jun 2001 09:19:09 -0700 Received: from giref.ulaval.ca (roederer.giref.ulaval.ca [132.203.7.24]) by merlin.giref.ulaval.ca (Postfix) with ESMTP id 6806BCA31 for ; Mon, 18 Jun 2001 12:19:08 -0400 (EDT) Message-ID: <3B2E29D9.E8B0BBD7@giref.ulaval.ca> Date: Mon, 18 Jun 2001 12:18:33 -0400 From: Luc Lalonde X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: gcc-2.95.3 lockups Content-Type: multipart/mixed; boundary="------------C11E88737525AB6AA07A3B02" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------C11E88737525AB6AA07A3B02 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hey folks, I'm wondering if anyone has had this problem. I've tried several versions of the XFS CVS code up until 2.4.6-pre3-xfs compiled with 2.95.3. I use Amanda to do my network backups and my system locks up when it dumps from the holding disk (XFS partition) to tape. I've recompiled the compat-egcs and compat-glibc on a SuSE-7.1 system to see if this changes anything when I compile the XFS kernel with EGCS. BTW, if anyone out there is using SuSE 7.1 and would like the recompiled RPM's let me know and I'll make them available. Cheers. -- Luc Lalonde, Responsable du reseau GIREF Telephone: (418) 656-2131 poste 6623 Courriel: llalonde@giref.ulaval.ca --------------C11E88737525AB6AA07A3B02 Content-Type: text/x-vcard; charset=us-ascii; name="llalonde.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Luc Lalonde Content-Disposition: attachment; filename="llalonde.vcf" begin:vcard n:Lalonde;Luc x-mozilla-html:FALSE org:Universite Laval;GIREF adr:;;;;;; version:2.1 email;internet:llalonde@giref.ulaval.ca title:Administateur de reseau x-mozilla-cpt:;0 fn:Luc Lalonde end:vcard --------------C11E88737525AB6AA07A3B02-- From owner-linux-xfs@oss.sgi.com Mon Jun 18 09:23:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IGNV413168 for linux-xfs-outgoing; Mon, 18 Jun 2001 09:23:31 -0700 Received: from msg.ecetra.com (dollar.ecetra.com [193.164.224.209]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IGNTV13165 for ; Mon, 18 Jun 2001 09:23:30 -0700 Received: from vie-ac.office.ecetra.com (vie-ac.office.ecetra.com [10.251.148.147] (may be forged)) by msg.ecetra.com (8.9.3/8.9.3) with ESMTP id SAA18415; Mon, 18 Jun 2001 18:23:23 +0200 Received: from localhost (localhost [127.0.0.1]) by vie-ac.office.ecetra.com (8.11.4/8.11.3) with ESMTP id f5IGNNN16713; Mon, 18 Jun 2001 18:23:23 +0200 Date: Mon, 18 Jun 2001 18:23:23 +0200 (CEST) From: Adam Cioccarelli To: Luc Lalonde cc: "linux-xfs@oss.sgi.com" Subject: Re: gcc-2.95.3 lockups In-Reply-To: <3B2E29D9.E8B0BBD7@giref.ulaval.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Luc, I don't know about Amanda but I have been running kernels built with 2.95.3 since it came out and I have never had any problems even when using devfs or lvm, but the only backups I have done have been with Legato or xfsdump... ------------------------------------------------------------------------------- Adam Cioccarelli (B.E Mechanical) Adam.Cioccarelli@ecetra.com Database Administrator Phone: +43 1 536 89 7725 Fax: +43 1 536 89 7719 ecetra Central European e-Finance AG Mobile:+43 664 181 4195 ------------------------------------------------------------------------------- On Mon, 18 Jun 2001, Luc Lalonde wrote: > Hey folks, > > I'm wondering if anyone has had this problem. I've tried several > versions of the XFS CVS code up until 2.4.6-pre3-xfs compiled with > 2.95.3. I use Amanda to do my network backups and my system locks up > when it dumps from the holding disk (XFS partition) to tape. > > I've recompiled the compat-egcs and compat-glibc on a SuSE-7.1 system to > see if this changes anything when I compile the XFS kernel with EGCS. > > BTW, if anyone out there is using SuSE 7.1 and would like the recompiled > RPM's let me know and I'll make them available. > > Cheers. > > -- > Luc Lalonde, Responsable du reseau GIREF > > Telephone: (418) 656-2131 poste 6623 > Courriel: llalonde@giref.ulaval.ca > > > > From owner-linux-xfs@oss.sgi.com Mon Jun 18 09:24:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IGOjh13257 for linux-xfs-outgoing; Mon, 18 Jun 2001 09:24:45 -0700 Received: from deliverator.sgi.com ([204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IGOiV13254 for ; Mon, 18 Jun 2001 09:24:44 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA19722 for ; Mon, 18 Jun 2001 09:23:47 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA2191712; Mon, 18 Jun 2001 11:22:33 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA14018; Mon, 18 Jun 2001 11:22:33 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5IGPAO32163; Mon, 18 Jun 2001 11:25:10 -0500 Message-Id: <200106181625.f5IGPAO32163@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "P.Dixon" cc: linux-xfs@oss.sgi.com Subject: Re: kernel panic with Rawhide RPM In-Reply-To: Message from "P.Dixon" of "Mon, 18 Jun 2001 17:10:58 BST." Date: Mon, 18 Jun 2001 11:25:10 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is an XFS panic, it basically means you ran out of memory in a place where XFS really cannot afford to do so. How much memory are you running with, and what sort of filesystem configuration are you writing data into? If you are running a highmem system on top of lvm or md then there are possibilities for this sort of thing happening. Also, is this something you have successfully done before with other xfs kernels? Steve > Hi, > > I just had a kernel panic on our backup server while rsyncing a file > system from our main server: > > Kernel Panic: Kmem_zone_Zalloc: NULL memory on KM_SLEEP request! > > Nothing else appears im the log files. > > I was using kernel-smp-2.4.5-0.2.9_SGI_XFS_20010613 > > Dunno of this is xfs related, but I've posted FYI, just in case. > > Cheerio, > Paul > > ----------------------------------------------------------------------------- > -- > Paul Dixon Email: P.Dixon@qmw.ac.uk > Department of Physics Phone: (020) 7882 5054 > Queen Mary, University of London Fax : (020) 7882 5054 > Mile End Road, London E1 4NS URL : http://hepwww.ph.qmw.ac.uk/~pd > ----------------------------------------------------------------------------- > -- > From owner-linux-xfs@oss.sgi.com Mon Jun 18 09:26:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IGQon13356 for linux-xfs-outgoing; Mon, 18 Jun 2001 09:26:50 -0700 Received: from syr-66-24-57-44.twcny.rr.com (syr-66-24-57-44.twcny.rr.com [66.24.57.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IGQnV13352 for ; Mon, 18 Jun 2001 09:26:49 -0700 Received: (from eem12@localhost) by syr-66-24-57-44.twcny.rr.com (8.11.2/8.9.3) id f5IGS9P04054; Mon, 18 Jun 2001 12:28:09 -0400 Date: Mon, 18 Jun 2001 12:28:09 -0400 From: Ed McKenzie To: Seth Mos Cc: Robin Humble , linux-xfs@oss.sgi.com Subject: Re: XFS and RAID5 Message-ID: <20010618122809.A4048@cornell.edu> References: <200106180555.FAA00389@groucho.maths.monash.edu.au> <4.3.2.7.2.20010618070434.02d268e0@pop.xs4all.nl> <200106180555.FAA00389@groucho.maths.monash.edu.au> <20010618085624.A3739@cornell.edu> <4.3.2.7.2.20010618152002.037ca3d8@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010618152002.037ca3d8@pop.xs4all.nl>; from knuffie@xs4all.nl on Mon, Jun 18, 2001 at 03:21:12PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Jun 18, 2001 at 03:21:12PM +0200, Seth Mos wrote: > >(Not that those would be _better_ choices, but XFS is hardly "the only > >valid choice" :) > > Better is arguable and a personal preference. I agree completely, and in the same situation I'd go with XFS, too. However, it seems that ext2 still has a reputation for not being able to handle large files, which is no longer the case. -ed From owner-linux-xfs@oss.sgi.com Mon Jun 18 09:29:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IGTcr13465 for linux-xfs-outgoing; Mon, 18 Jun 2001 09:29:38 -0700 Received: from merlin.giref.ulaval.ca (postfix@merlin.giref.ulaval.ca [132.203.7.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IGTbV13462 for ; Mon, 18 Jun 2001 09:29:37 -0700 Received: from giref.ulaval.ca (roederer.giref.ulaval.ca [132.203.7.24]) by merlin.giref.ulaval.ca (Postfix) with ESMTP id 9E020CA35; Mon, 18 Jun 2001 12:29:36 -0400 (EDT) Message-ID: <3B2E2C4F.2254186@giref.ulaval.ca> Date: Mon, 18 Jun 2001 12:29:03 -0400 From: Luc Lalonde X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Adam Cioccarelli Cc: "linux-xfs@oss.sgi.com" Subject: Re: gcc-2.95.3 lockups References: Content-Type: multipart/mixed; boundary="------------F2520548FDBF142EDFD281FF" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------F2520548FDBF142EDFD281FF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hey Adam, I didn't have any problems for the longest time either. Recently, the server that does the backups would lockup without fail during backups. I'm trying to identify the source of the problem but I can't seem to find the cause in the system logs. Perhaps I'm looking in the wrong place? Ciao. Adam Cioccarelli wrote: > Hi Luc, > > I don't know about Amanda but I have been running kernels built with > 2.95.3 since it came out and I have never had any problems even when using > devfs or lvm, but the only backups I have done have been with Legato or > xfsdump... > > ------------------------------------------------------------------------------- > Adam Cioccarelli (B.E Mechanical) Adam.Cioccarelli@ecetra.com > Database Administrator Phone: +43 1 536 89 7725 > Fax: +43 1 536 89 7719 > ecetra Central European e-Finance AG Mobile:+43 664 181 4195 > ------------------------------------------------------------------------------- > > On Mon, 18 Jun 2001, Luc Lalonde wrote: > > > Hey folks, > > > > I'm wondering if anyone has had this problem. I've tried several > > versions of the XFS CVS code up until 2.4.6-pre3-xfs compiled with > > 2.95.3. I use Amanda to do my network backups and my system locks up > > when it dumps from the holding disk (XFS partition) to tape. > > > > I've recompiled the compat-egcs and compat-glibc on a SuSE-7.1 system to > > see if this changes anything when I compile the XFS kernel with EGCS. > > > > BTW, if anyone out there is using SuSE 7.1 and would like the recompiled > > RPM's let me know and I'll make them available. > > > > Cheers. > > > > -- > > Luc Lalonde, Responsable du reseau GIREF > > > > Telephone: (418) 656-2131 poste 6623 > > Courriel: llalonde@giref.ulaval.ca > > > > > > > > -- Luc Lalonde, Responsable du reseau GIREF Telephone: (418) 656-2131 poste 6623 Courriel: llalonde@giref.ulaval.ca --------------F2520548FDBF142EDFD281FF Content-Type: text/x-vcard; charset=us-ascii; name="llalonde.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Luc Lalonde Content-Disposition: attachment; filename="llalonde.vcf" begin:vcard n:Lalonde;Luc x-mozilla-html:FALSE org:Universite Laval;GIREF adr:;;;;;; version:2.1 email;internet:llalonde@giref.ulaval.ca title:Administateur de reseau x-mozilla-cpt:;0 fn:Luc Lalonde end:vcard --------------F2520548FDBF142EDFD281FF-- From owner-linux-xfs@oss.sgi.com Mon Jun 18 09:31:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IGV8U13561 for linux-xfs-outgoing; Mon, 18 Jun 2001 09:31:08 -0700 Received: from mail.satshot.com (ns2.avsupport.com [207.70.233.201]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IGV6V13558 for ; Mon, 18 Jun 2001 09:31:06 -0700 Received: (qmail 6934 invoked from network); 18 Jun 2001 11:29:44 -0000 Received: from unzen.satshot.com (207.70.233.220) by unzen.satshot.com with SMTP; 18 Jun 2001 11:29:44 -0000 Date: Mon, 18 Jun 2001 11:29:44 +0000 (GMT) From: Shawn L Johnston To: Subject: Re: XFS and RAID5 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sorry for going a little off topic... Have you tried an ICP Vortex GDT6513RS card? I have a server with 9 180 GB scsi drives (baracudas from seagate) that I'd like to have in a single RAID 5 volume. I've had some problems getting just a ext2 filesystem on it, seems like I can only get it to work with a maximum of 3 drives in a single volume. Would love to make it run with an XFS filesystem... Can I ask what type of kernel changes you had to do with the 3ware to make it work? Shawn On Mon, 18 Jun 2001, Justin Tripp wrote: > > I have used both the 3ware and Promise Raid solutions. Their are two > Promise RAID cards. Only one will work with linux and it is a software > raid solution. Promise only supports RedHat 6.1,6.2 and Suse 6.2, and > only the basic kernels in those releases. So, if you are not interested > in XFS, then you could try them out. It is likely, though, that you could > get the same performance (and cheaper), but just buying a additional > promise IDE controller and running the kernel's software raid on top of > that. And then you could run any kernel you desired to -- plus XFS. IDE > software RAID is not likely to have too great of performance. (FYI > Promise's kernel driver is not open source, only part of it is and I never > did get them to return any emails I sent them about using the card under > linux). > > 3ware, on the other hand, is a hardware raid. As far as your computer is > concerned you have a SCSI controller hooked to a pci slot. The overhead > of IDE disks is not seen by the processor since it only interacts with the > Raid controller and cannot see the individual disks. I have a 3ware > controller with 4 40G disks running RAID 5 with XFS as the underlying > filesystem. It works quite well. > > 3ware did have problems with the firmware and RAID5, but these have been > fixed and can easily be obtained from their website. The problems only > occured if the RAID ran in degraded mode, and if one did not have a disk > failure, then the problem never occurred. (Phew). The kernel driver > works well in the 2.2 kernels, but 3ware is not too keen on helping you > run in 2.4. Now that some distributions ship with 2.4, they may be > changing their minds, but... Nonetheless, their driver is open source and > is part of the kernel tree. The driver I am running is cut out of the > 2.4.5-ac5 patch and applied to a 2.4.5 cvs version of XFS. I have not had > any problems despite the fact that XFS seems to exercise the underlying > hardware more than ext2 does. > > I believe the 3ware card is a reasonably cheap way to get a 100+G raid. > But I did have to do some light kernel hacking to get everything working > reasonably well. > > .justin. > > On Mon, 18 Jun 2001, Seth Mos wrote: > > > At 09:13 18-6-2001 -0400, Andrew Klaassen wrote: > > >On Mon, Jun 18, 2001 at 03:55:36PM +1000, > > >Robin Humble wrote: > > > > > > > Around the time of the 2.4.3 kernel we used XFS over software > > > > RAID5 for a month or so before a disk died and we didn't > > > > bother replacing it - we've been using 420G (7 disks) of RAID0 > > > > since with zero problems. RAID5 seemed ok and we sorted out > > > > any initial performance problems as we found them with the > > > > super-responsive XFS people on this list. > > > > > >7 disks? I'm curious: SCSI or IDE? (We're looking into a > > >Promise or 3ware card to allow us to put lots of IDE drives in a > > >box and run software RAID over top, and were wondering if anyone > > >else has had experience with these cards+software RAID+XFS.) > > > > IIRC the 3ware driver is a bit shakey. The 3ware card is a hardware raid > > solution and not a software one. If you use promise cards you will probably > > use software raid. > > > > The issue with the 3ware raid was firmware related. If the controller was > > missing a disk and running in degraded mode file system corruption could > > and would occur. > > Other then that it is a fine IDE raid controller. > > > > > > >Andrew Klaassen > > > > Good luck > > -- > > Seth > > Every program has two purposes one for which > > it was written and another for which it wasn't > > I use the last kind. > > > > > > From owner-linux-xfs@oss.sgi.com Mon Jun 18 09:32:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IGWnN13682 for linux-xfs-outgoing; Mon, 18 Jun 2001 09:32:49 -0700 Received: from caroubier.wanadoo.fr (smtp-rt-6.wanadoo.fr [193.252.19.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IGWmV13679 for ; Mon, 18 Jun 2001 09:32:48 -0700 Received: from amyris.wanadoo.fr (193.252.19.150) by caroubier.wanadoo.fr; 18 Jun 2001 18:32:41 +0200 Received: from ARennes-301-1-1-193.abo.wanadoo.fr (193.251.66.193) by amyris.wanadoo.fr; 18 Jun 2001 18:32:19 +0200 Subject: RedHat Rawhide + XFS rpm : request From: reiser angus To: linux-xfs@oss.sgi.com Cc: cattelan@thebarn.com X-Mailer: Evolution/0.10.99 (Preview Release) Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.10.99 (Preview Release) Date: 18 Jun 2001 18:34:45 +0200 Message-Id: <992882087.952.1.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, After having installed the package kernel-2.4.5-0.2.9_SGI_XFS_20010613.src.rpm I noted that the option REISERFS_CHECK as for the package RedHat rawhide is activate, inducing a degradation of performances for the reiserfs filesystem. Blow, one is obliged of compile the kernel with REISERFS_CHECK disabled. Would it be possible to disable this option for your next kernel package ? That would not have any particular impact and would facilitate the life of those which want for example to carry out benchmark. Thank you in advance -David From owner-linux-xfs@oss.sgi.com Mon Jun 18 09:37:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IGbwn13848 for linux-xfs-outgoing; Mon, 18 Jun 2001 09:37:58 -0700 Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IGbtV13845 for ; Mon, 18 Jun 2001 09:37:56 -0700 Received: from heppcl.ph.qmw.ac.uk ([138.37.50.187]) by zeta.qmw.ac.uk with esmtp (Exim 3.16 #1) id 15C222-0007Qv-00; Mon, 18 Jun 2001 17:37:42 +0100 Received: from heppct.ph.qmw.ac.uk (heppct.ph.qmw.ac.uk [138.37.50.246]) by heppcl.ph.qmw.ac.uk (8.9.3/8.9.3) with ESMTP id RAA12904; Mon, 18 Jun 2001 17:37:43 +0100 Received: from localhost (pd@localhost) by heppct.ph.qmw.ac.uk (8.11.2/8.9.3) with ESMTP id f5IGbhG27307; Mon, 18 Jun 2001 17:37:43 +0100 X-Authentication-Warning: heppct.ph.qmw.ac.uk: pd owned process doing -bs Date: Mon, 18 Jun 2001 17:37:43 +0100 (BST) From: "P.Dixon" To: Steve Lord cc: Subject: Re: kernel panic with Rawhide RPM In-Reply-To: <200106181625.f5IGPAO32163@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > This is an XFS panic, it basically means you ran out of memory in a place > where XFS really cannot afford to do so. How much memory are you running with, > and what sort of filesystem configuration are you writing data into? If you > are running a highmem system on top of lvm or md then there are possibilities > for this sort of thing happening. Also, is this something you have successfully > done before with other xfs kernels? > The computer in question is a dual 450 MHz PII with 256 MB RAM and 512 MB of swap. There is a single IDE hard disk and two SCSI hard disks installed. We're not using lvm or md. The file system is partitioned as follows (all xfs) Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda1 3071616 1394348 1677268 46% / /dev/hda8 3585696 144 3585552 1% /exp/atlas /dev/hda10 2043456 144 2043312 1% /exp/cluster /dev/hda5 6148060 144 6147916 1% /exp/department /dev/hda7 2043456 144 2043312 1% /exp/h1 /dev/sda1 5116208 144 5116064 1% /exp/llocal /dev/sda4 5625152 144 5625008 1% /exp/mail /dev/sda2 4092224 144 4092080 1% /exp/nlocal /dev/hda6 2043456 144 2043312 1% /exp/olocal /dev/hda9 2043456 144 2043312 1% /exp/opal /dev/hda11 549408 144 549264 1% /exp/scratch /dev/sda3 3068224 144 3068080 1% /exp/slocal /dev/sdb1 36079920 17968 36061952 1% /exp/users And I was running this script (on our hepserv1 machine) when the kernel panic occured (on our hepserv2 machine): #!/bin/bash RSYNC_RSH=/usr/bin/ssh export RSYNC_RSH cd / echo "===> rsyncing hepserv1:/exp/users -> hepserv2:/exp/users" rsync -rulHpogtS --delete --force /export/users/ root@hepserv2:/export/users/ Cheerio, Paul ------------------------------------------------------------------------------- Paul Dixon Email: P.Dixon@qmw.ac.uk Department of Physics Phone: (020) 7882 5054 Queen Mary, University of London Fax : (020) 7882 5054 Mile End Road, London E1 4NS URL : http://hepwww.ph.qmw.ac.uk/~pd ------------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Jun 18 09:39:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IGdAG13948 for linux-xfs-outgoing; Mon, 18 Jun 2001 09:39:10 -0700 Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IGd9V13945 for ; Mon, 18 Jun 2001 09:39:09 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f5IGd1805675; Mon, 18 Jun 2001 11:39:01 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <3B2E2EA5.26C1DA3B@thebarn.com> Date: Mon, 18 Jun 2001 11:39:01 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: reiser angus CC: linux-xfs@oss.sgi.com Subject: Re: RedHat Rawhide + XFS rpm : request References: <992882087.952.1.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk reiser angus wrote: > Hello, > > After having installed the package > kernel-2.4.5-0.2.9_SGI_XFS_20010613.src.rpm I noted that > the option REISERFS_CHECK as for the package RedHat rawhide is activate, All kernel options are left as is except for the addition XFS obviously. I'm not generally inclined to start "tuning" redhat kernels. Each individual should decide what to changes should be make and rebuild the kernel to their liking. > > inducing a degradation of performances for the reiserfs filesystem. > Blow, one is obliged of compile the kernel with REISERFS_CHECK disabled. > Would it be possible to disable this option for your next kernel package > ? > That would not have any particular impact and would facilitate the life > of those which want for example to carry out benchmark. > > Thank you in advance > > -David -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Mon Jun 18 09:43:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IGhwk14091 for linux-xfs-outgoing; Mon, 18 Jun 2001 09:43:58 -0700 Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IGhvV14088 for ; Mon, 18 Jun 2001 09:43:57 -0700 Received: from heppcl.ph.qmw.ac.uk ([138.37.50.187]) by zeta.qmw.ac.uk with esmtp (Exim 3.16 #1) id 15C27w-0007TT-00; Mon, 18 Jun 2001 17:43:48 +0100 Received: from heppct.ph.qmw.ac.uk (heppct.ph.qmw.ac.uk [138.37.50.246]) by heppcl.ph.qmw.ac.uk (8.9.3/8.9.3) with ESMTP id RAA13005; Mon, 18 Jun 2001 17:43:48 +0100 Received: from localhost (pd@localhost) by heppct.ph.qmw.ac.uk (8.11.2/8.9.3) with ESMTP id f5IGhm727416; Mon, 18 Jun 2001 17:43:48 +0100 X-Authentication-Warning: heppct.ph.qmw.ac.uk: pd owned process doing -bs Date: Mon, 18 Jun 2001 17:43:48 +0100 (BST) From: "P.Dixon" To: Steve Lord cc: Subject: Re: kernel panic with Rawhide RPM In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Also, is this something you have successfully done before with other > xfs kernels? > No, but I'm about to try some others. Paul From owner-linux-xfs@oss.sgi.com Mon Jun 18 09:49:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IGn9t14264 for linux-xfs-outgoing; Mon, 18 Jun 2001 09:49:09 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IGn8V14261 for ; Mon, 18 Jun 2001 09:49:08 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 76EC61E46C; Mon, 18 Jun 2001 18:49:02 +0200 (MEST) Date: Mon, 18 Jun 2001 18:48:55 +0200 From: Andi Kleen To: "P.Dixon" Cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: kernel panic with Rawhide RPM Message-ID: <20010618184855.A12375@gruyere.muc.suse.de> References: <200106181625.f5IGPAO32163@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from P.Dixon@qmw.ac.uk on Mon, Jun 18, 2001 at 05:37:43PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Jun 18, 2001 at 05:37:43PM +0100, P.Dixon wrote: > And I was running this script (on our hepserv1 machine) when the kernel > panic occured (on our hepserv2 machine): > > #!/bin/bash > RSYNC_RSH=/usr/bin/ssh > export RSYNC_RSH > cd / > echo "===> rsyncing hepserv1:/exp/users -> hepserv2:/exp/users" > rsync -rulHpogtS --delete --force /export/users/ root@hepserv2:/export/users/ ^ You probably ran out of memory and swap. -H makes rsync use a *lot* of memory. Try it without -H or add a few GB of swap. XFS unfortunately handles OOM very badly. -Andi From owner-linux-xfs@oss.sgi.com Mon Jun 18 09:55:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IGtWY14454 for linux-xfs-outgoing; Mon, 18 Jun 2001 09:55:32 -0700 Received: from groucho.maths.monash.edu.au (groucho.maths.monash.edu.au [130.194.160.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IGtUV14451 for ; Mon, 18 Jun 2001 09:55:30 -0700 Received: (from rjh@localhost) by groucho.maths.monash.edu.au (8.8.8/8.8.8) id QAA11308 for linux-xfs@oss.sgi.com; Mon, 18 Jun 2001 16:55:26 GMT From: Robin Humble Message-Id: <200106181655.QAA11308@groucho.maths.monash.edu.au> Subject: Re: XFS and RAID5 To: linux-xfs@oss.sgi.com Date: Tue, 19 Jun 2001 02:55:26 +1000 (EST) In-Reply-To: <20010618091334.A2209@key.dkp.com> from "Andrew Klaassen" at Jun 18, 2001 09:13:34 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andrew Klaassen writes: >On Mon, Jun 18, 2001 at 03:55:36PM +1000, >Robin Humble wrote: >> Around the time of the 2.4.3 kernel we used XFS over software >> RAID5 for a month or so before a disk died and we didn't >> bother replacing it - we've been using 420G (7 disks) of RAID0 >>... >7 disks? I'm curious: SCSI or IDE? (We're looking into a IDE. Seven 60G maxtor 7200rpm + two Promise ATA 100 cards and using both master and slave on each of the 4 IDE controllers. Contrary to popular belief, using both master and slave only gets you a ~5% performance hit. >Promise or 3ware card to allow us to put lots of IDE drives in a >box and run software RAID over top, and were wondering if anyone >else has had experience with these cards+software RAID+XFS.) We're also considering 3ware this time around 'cos they have up to 8 IDE ports per card which saves on PCI slots... we could also try their hardware RAID5, but I think performance'll be way worse than software RAID5 - their website site only claims 6MB/s(?) writes(*) and we've seen more than 3x that with software RAID5 on a slowish celeron. cheers, robin (*) this is for the older 6000 series, and their writing and graphs conflict about RAID5 write speeds, but I'm going with the graph... http://www.3ware.com/storage/raid5_slide.asp#a7 From owner-linux-xfs@oss.sgi.com Mon Jun 18 10:13:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IHDH014734 for linux-xfs-outgoing; Mon, 18 Jun 2001 10:13:17 -0700 Received: from d13.com ([216.33.170.30]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IHDFV14731 for ; Mon, 18 Jun 2001 10:13:15 -0700 Received: (qmail 14634 invoked by uid 526); 18 Jun 2001 16:13:08 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Jun 2001 16:13:08 -0000 Date: Mon, 18 Jun 2001 09:13:08 -0700 (PDT) From: Mike Sklar X-X-Sender: To: Subject: efs support in SGI built kernels Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The 2.4.2-2 kernel provided with SGI 1.0 enhanded seawolf does not have efs built in. I was hoping the provided kernels in future release would have 'efs' filesystem support built in as well. I have plenty of IRIX CDs that it is sometimes convenient to mount from our linux machines. From owner-linux-xfs@oss.sgi.com Mon Jun 18 10:17:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IHHVt14918 for linux-xfs-outgoing; Mon, 18 Jun 2001 10:17:31 -0700 Received: from dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IHHUV14915 for ; Mon, 18 Jun 2001 10:17:30 -0700 Received: (from ak@localhost) by dkp.com (8.9.3/8.9.3) id NAA06808 for linux-xfs@oss.sgi.com; Mon, 18 Jun 2001 13:17:29 -0400 Date: Mon, 18 Jun 2001 13:17:29 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: XFS and RAID5 Message-ID: <20010618131729.C2209@key.dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20010618091334.A2209@key.dkp.com> <200106181655.QAA11308@groucho.maths.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200106181655.QAA11308@groucho.maths.monash.edu.au>; from rjh@groucho.maths.monash.edu.au on Tue, Jun 19, 2001 at 02:55:26AM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jun 19, 2001 at 02:55:26AM +1000, Robin Humble wrote: > Contrary to popular belief, using both master and slave only > gets you a ~5% performance hit. (?)! That would be very, very good news. Has anybody else tried this? Have you load tested the machines and seen smooth performance degradation, no nasty bottlenecks (or whatever it is that is supposed to happen when master and slave are both used in an array)? (Am I asking these question on the wrong forum? Apologies...) Andrew Klaassen From owner-linux-xfs@oss.sgi.com Mon Jun 18 10:45:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IHjcd16213 for linux-xfs-outgoing; Mon, 18 Jun 2001 10:45:38 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IHjZV16204 for ; Mon, 18 Jun 2001 10:45:35 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA488658 for ; Mon, 18 Jun 2001 19:45:30 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2188064 for ; Mon, 18 Jun 2001 12:44:14 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA12486 for ; Mon, 18 Jun 2001 12:44:14 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f5IHkoN28192; Mon, 18 Jun 2001 12:46:50 -0500 Message-Id: <200106181746.f5IHkoN28192@jen.americas.sgi.com> Date: Mon, 18 Jun 2001 12:46:50 -0500 Subject: TAKE - fix for compiling xfs with gcc 3.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have a system up which was built with gcc 3.0, this one change was needed to get the build to complete. No guarantees about the results of running it yet though. Date: Mon Jun 18 10:43:14 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-base The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:97045a linux/include/linux/kdbprivate.h - 1.11 - Fix gcc 3.0 compile error in kdb From owner-linux-xfs@oss.sgi.com Mon Jun 18 11:14:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IIELh17521 for linux-xfs-outgoing; Mon, 18 Jun 2001 11:14:21 -0700 Received: from dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IIELV17516 for ; Mon, 18 Jun 2001 11:14:21 -0700 Received: (from ak@localhost) by dkp.com (8.9.3/8.9.3) id OAA07720 for linux-xfs@oss.sgi.com; Mon, 18 Jun 2001 14:14:20 -0400 Date: Mon, 18 Jun 2001 14:14:20 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Testing XFS+RAID5 Message-ID: <20010618141420.D2209@key.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.2i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well, I'm about to try building a box with XFS over 6 IDE drives (using master+slave on two of the channels) doing software RAID-5. I want to test this setup as thoroughly as I possibly can, in as short a time period as I possibly can. (The IDE drives arrived today, and people want them in production by tomorrow morning, "if possible".) Anyone have any suggestions for tools to stress the system? To look for XFS+NFS and XFS+Samba bottlenecks and bugs? To make the drives fail as soon as possible, if they're so inclined? I've been using bonnie and iozone; any other suggestions? Thanks. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Mon Jun 18 11:21:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IILtD18082 for linux-xfs-outgoing; Mon, 18 Jun 2001 11:21:55 -0700 Received: from groucho.maths.monash.edu.au (groucho.maths.monash.edu.au [130.194.160.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IILrV18076 for ; Mon, 18 Jun 2001 11:21:53 -0700 Received: (from rjh@localhost) by groucho.maths.monash.edu.au (8.8.8/8.8.8) id SAA12520 for linux-xfs@oss.sgi.com; Mon, 18 Jun 2001 18:21:51 GMT From: Robin Humble Message-Id: <200106181821.SAA12520@groucho.maths.monash.edu.au> Subject: Re: XFS and RAID5 To: linux-xfs@oss.sgi.com Date: Tue, 19 Jun 2001 04:21:51 +1000 (EST) In-Reply-To: <20010618131729.C2209@key.dkp.com> from "Andrew Klaassen" at Jun 18, 2001 01:17:29 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andrew Klaassen writes: >On Tue, Jun 19, 2001 at 02:55:26AM +1000, >Robin Humble wrote: >> Contrary to popular belief, using both master and slave only >> gets you a ~5% performance hit. >(?)! yeah - it surprised me too... >That would be very, very good news. Has anybody else tried >this? dunno - I'd like to hear about it if they have... > Have you load tested the machines and seen smooth >performance degradation, no nasty bottlenecks (or whatever it is >that is supposed to happen when master and slave are both used >in an array)? All bonnie++ numbers with RAID0 over 4 disks were pretty much the same whether it was all 4 disks on one (2-port) card, or whether each disk had its own separate controller. It's easy to try it out for yourself. The one thing that may be better with each drive having a separate controller is if a disk dies - when doing master+slave, the controller may get confused and lose track of the 2nd disk... So in a RAID5 situation there's maybe something to be said for separate controllers. However IDE and Linux deal pretty inelegantly with any sort of IDE disk failure so perhaps it's not much worse than normal... We did the pull-the-power-out-of-the-drive thing and had some real disk failures also and RAID5 things seemed to work as expected. A separate consideration is that NFS over a 100Mbit link limits you to 10MB/s anyway, so filesystem performance shouldn't really be an issue; you may as well save yourself PCI slots and IRQs by using master+slave. Gigabit eth will probably push hard enough to make filesystem performance the bottleneck and then any (even small) loss from master+slave may be unacceptable. >(Am I asking these question on the wrong forum? Apologies...) well, maybe :-) lots of people seem interested though - I guess 'cos these are the sort of machine configurations that journalling filesystems are required for. cheers, robin From owner-linux-xfs@oss.sgi.com Mon Jun 18 11:26:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IIQwc18717 for linux-xfs-outgoing; Mon, 18 Jun 2001 11:26:58 -0700 Received: from syr-66-24-57-44.twcny.rr.com (syr-66-24-57-44.twcny.rr.com [66.24.57.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IIQvV18710 for ; Mon, 18 Jun 2001 11:26:57 -0700 Received: (from eem12@localhost) by syr-66-24-57-44.twcny.rr.com (8.11.2/8.9.3) id f5IIScF04241 for linux-xfs@oss.sgi.com; Mon, 18 Jun 2001 14:28:38 -0400 Date: Mon, 18 Jun 2001 14:28:38 -0400 From: Ed McKenzie To: linux-xfs@oss.sgi.com Subject: Re: XFS and RAID5 Message-ID: <20010618142838.B4227@cornell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Jun 18, 2001 at 01:17:29PM -0400, Andrew Klaassen wrote: > > Contrary to popular belief, using both master and slave only > > gets you a ~5% performance hit. > > (?)! > > That would be very, very good news. Has anybody else tried > this? Have you load tested the machines and seen smooth > performance degradation, no nasty bottlenecks (or whatever it is > that is supposed to happen when master and slave are both used > in an array)? I was curious about this myself and tested it; I found much less performance degradation than expected with UDMA drives in a RAID-0. I don't seem to have the results anymore, but off the top of my head, these two drives typically get 17MB/s and 13MB/s when benchmarked in isolation; together in a striped volume on different channels, they max out at 24MB/s, and on the same channel they get 21-23MB/s. Tests were done on a pair of IBM DeskStar drives (DJNA371350, DTTA371010), both with on-board VIA MVP3 and a Promise Ultra66 board. I didn't experience any issues with IDE errors or data corruption. This was all tested on RedHat 2.2 kernels + patches some time back. 2.4 didn't do so hot at the time, but hopefully it's better now. So, in summary, it works, and it's not that much slower. YMMV with different load (my tests were mostly with hdparm and bonnie, and it wasn't on a RAID-5.) -ed From owner-linux-xfs@oss.sgi.com Mon Jun 18 11:29:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IITHJ18928 for linux-xfs-outgoing; Mon, 18 Jun 2001 11:29:17 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IITGV18923 for ; Mon, 18 Jun 2001 11:29:16 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA03174 for ; Mon, 18 Jun 2001 11:29:16 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2186415; Mon, 18 Jun 2001 13:27:59 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA89686; Mon, 18 Jun 2001 13:27:59 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5IIUZq28997; Mon, 18 Jun 2001 13:30:35 -0500 Message-Id: <200106181830.f5IIUZq28997@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andrew Klaassen cc: linux-xfs@oss.sgi.com Subject: Re: Testing XFS+RAID5 In-Reply-To: Message from Andrew Klaassen of "Mon, 18 Jun 2001 14:14:20 EDT." <20010618141420.D2209@key.dkp.com> Date: Mon, 18 Jun 2001 13:30:35 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Well, I'm about to try building a box with XFS over 6 IDE drives > (using master+slave on two of the channels) doing software > RAID-5. I want to test this setup as thoroughly as I possibly > can, in as short a time period as I possibly can. (The IDE > drives arrived today, and people want them in production by > tomorrow morning, "if possible".) > > Anyone have any suggestions for tools to stress the system? To > look for XFS+NFS and XFS+Samba bottlenecks and bugs? To make > the drives fail as soon as possible, if they're so inclined? > > I've been using bonnie and iozone; any other suggestions? > > Thanks. > > Andrew Klaassen For local access stress, run make in the cmd/xfstests directory (you will need the various devel rpms installed, including rev 1.06 of the acl rpms if you have a current cvs tree). This will give you an fsstress binary in the xfstests/src directory, doing something like: fsstress -d /xfs-filesystem -p 8 -n 10000 will run 8 parallel threads doing 10000 random operations each in the specified directory. You can bump the numbers, but you will chew up large amounts of disk space. Running xfsdump in parallel with nfs activity is a good combo. xfsdump will access every file in the filesystem. The reiserfs mongo benchmark will hammer a filesystem pretty well too. As Robin Humble just pointed out, the NFS bandwidth is limited by the network, so doing lots of local access in parallel is going to stress the filesystem more, but there are paths which will only be exercised if you use NFS. Steve From owner-linux-xfs@oss.sgi.com Mon Jun 18 11:32:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IIWdE19261 for linux-xfs-outgoing; Mon, 18 Jun 2001 11:32:39 -0700 Received: from dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IIWbV19254 for ; Mon, 18 Jun 2001 11:32:37 -0700 Received: (from ak@localhost) by dkp.com (8.9.3/8.9.3) id OAA07942 for linux-xfs@oss.sgi.com; Mon, 18 Jun 2001 14:32:36 -0400 Date: Mon, 18 Jun 2001 14:32:36 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: Testing XFS+RAID5 Message-ID: <20010618143236.E2209@key.dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20010618141420.D2209@key.dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010618141420.D2209@key.dkp.com>; from ak@dkp.com on Mon, Jun 18, 2001 at 02:14:20PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Jun 18, 2001 at 02:14:20PM -0400, Andrew Klaassen wrote: > Anyone have any suggestions for tools to stress the system? > To look for XFS+NFS and XFS+Samba bottlenecks and bugs? To > make the drives fail as soon as possible, if they're so > inclined? Oh - and there's one more thing I want to test for: data corruption. Anybody know of any test suites out there that will do comprehensive tests looking for corruption? Andrew Klaassen From owner-linux-xfs@oss.sgi.com Mon Jun 18 11:44:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IIiRn19890 for linux-xfs-outgoing; Mon, 18 Jun 2001 11:44:27 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IIiPV19887 for ; Mon, 18 Jun 2001 11:44:26 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 322021E4C9; Mon, 18 Jun 2001 20:44:20 +0200 (MEST) Date: Mon, 18 Jun 2001 20:44:14 +0200 From: Andi Kleen To: Andrew Klaassen Cc: linux-xfs@oss.sgi.com Subject: Re: Testing XFS+RAID5 Message-ID: <20010618204414.A14503@gruyere.muc.suse.de> References: <20010618141420.D2209@key.dkp.com> <20010618143236.E2209@key.dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010618143236.E2209@key.dkp.com>; from ak@dkp.com on Mon, Jun 18, 2001 at 02:32:36PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Jun 18, 2001 at 02:32:36PM -0400, Andrew Klaassen wrote: > On Mon, Jun 18, 2001 at 02:14:20PM -0400, > Andrew Klaassen wrote: > > > Anyone have any suggestions for tools to stress the system? > > To look for XFS+NFS and XFS+Samba bottlenecks and bugs? To > > make the drives fail as soon as possible, if they're so > > inclined? > > Oh - and there's one more thing I want to test for: data > corruption. Anybody know of any test suites out there that will > do comprehensive tests looking for corruption? One interesting test is that the file system is recoverable from a crash at all times. You can simulate the crash case by running it on LVM and taking LVM snapshots periodically while doing heavy load testing. Then try to mount the snapshot and check if it contains any damages. One problem with that is that XFS refuses to mount a copy of an already mounted file system currently; to work around that you need to set a different file system UUID using xfs_db before mounting to force the mount. Then check if it is readable and if there is any damage. This only checks for software problems of course. For example when your disk does use write caching or not honour flush requests or does other things that violate write ordering assumptions you would need to actually take the power away to test for such problems. -Andi From owner-linux-xfs@oss.sgi.com Mon Jun 18 11:58:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IIw6b20582 for linux-xfs-outgoing; Mon, 18 Jun 2001 11:58:06 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IIw5V20576 for ; Mon, 18 Jun 2001 11:58:05 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id UAA04767; Mon, 18 Jun 2001 20:58:03 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id UAA24634; Mon, 18 Jun 2001 20:58:03 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 9DD6F57306; Mon, 18 Jun 2001 21:07:07 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 4CE6425835; Mon, 18 Jun 2001 21:15:28 +0200 (CEST) Message-ID: <3B2E500D.F96F355A@ch.sauter-bc.com> Date: Mon, 18 Jun 2001 21:01:33 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Andrew Klaassen Cc: linux-xfs@oss.sgi.com Subject: Re: Testing XFS+RAID5 References: <20010618141420.D2209@key.dkp.com> <20010618143236.E2209@key.dkp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk If you want to test the partition where you have your system installed, just make a rpm -Va . This should give you a list of (config)files which have changed somehow. A goot thing is to check the 5, it is the MD5 sum of installed files. Andrew Klaassen schrieb: > > On Mon, Jun 18, 2001 at 02:14:20PM -0400, > Andrew Klaassen wrote: > > > Anyone have any suggestions for tools to stress the system? > > To look for XFS+NFS and XFS+Samba bottlenecks and bugs? To > > make the drives fail as soon as possible, if they're so > > inclined? > > Oh - and there's one more thing I want to test for: data > corruption. Anybody know of any test suites out there that will > do comprehensive tests looking for corruption? > > Andrew Klaassen -- 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 Mon Jun 18 12:02:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IJ2UK20835 for linux-xfs-outgoing; Mon, 18 Jun 2001 12:02:30 -0700 Received: from amoa.org (amoa.org [207.207.51.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IJ2TV20832 for ; Mon, 18 Jun 2001 12:02:29 -0700 Received: by amoa.org(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256A6F.0068A6AB ; Mon, 18 Jun 2001 14:03:04 -0500 X-Lotus-FromDomain: AMOA From: ctooley@amoa.org To: Andrew Klaassen cc: linux-xfs@oss.sgi.com Message-ID: <86256A6F.0068A646.00@amoa.org> Date: Mon, 18 Jun 2001 14:03:02 -0500 Subject: Re: XFS and RAID5 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk One of the things I noticed with the Promise Ultra66 (may be fixed in Ultra100) was that if a disk failed, both disks on that controller (master and slave) start having a load of problems. Plus there is no way to reset just part of the controller, it's both or nothing. By just using the Master connectors I noticed that when I did my testing setting the bus that it was on after replacing the disk (again DON'T DO THIS!!!) was all I had to do to make the disk available. Chris Andrew Klaassen on 06/18/2001 12:17:29 PM To: linux-xfs@oss.sgi.com cc: (bcc: Chris Tooley/AMOA) Subject Re: XFS and RAID5 : On Tue, Jun 19, 2001 at 02:55:26AM +1000, Robin Humble wrote: > Contrary to popular belief, using both master and slave only > gets you a ~5% performance hit. (?)! That would be very, very good news. Has anybody else tried this? Have you load tested the machines and seen smooth performance degradation, no nasty bottlenecks (or whatever it is that is supposed to happen when master and slave are both used in an array)? (Am I asking these question on the wrong forum? Apologies...) Andrew Klaassen From owner-linux-xfs@oss.sgi.com Mon Jun 18 12:13:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IJD7Q21490 for linux-xfs-outgoing; Mon, 18 Jun 2001 12:13:07 -0700 Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IJD6V21486 for ; Mon, 18 Jun 2001 12:13:06 -0700 Received: (qmail 7238 invoked by uid 0); 18 Jun 2001 19:13:00 -0000 Received: from pd901b81c.dip.t-dialin.net (HELO nexus.shadowrun.not) (217.1.184.28) by mail.gmx.net (mail02) with SMTP; 18 Jun 2001 19:13:00 -0000 Received: from nexus.shadowrun.not (localhost [127.0.0.1]) by nexus.shadowrun.not (8.12.0.Beta10/8.12.0.Beta10) with ESMTP id f5IJBpRB032736 for ; Mon, 18 Jun 2001 21:11:51 +0200 Received: (from fastjack@localhost) by nexus.shadowrun.not (8.12.0.Beta10/8.12.0.Beta10/Debian 8.12.0.Beta10) id f5IJBjN7032570 for linux-xfs@oss.sgi.com; Mon, 18 Jun 2001 21:11:45 +0200 From: Martin Maciaszek Date: Mon, 18 Jun 2001 21:11:25 +0200 To: linux-xfs@oss.sgi.com Subject: Re: ACL Support Message-ID: <20010618211125.A32530@nexus.shadowrun.not> Mail-Followup-To: mmaciaszek@gmx.net, linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: <20010614091857.P8175@fudge.melbourne.sgi.com> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 14, 2001 at 09:18:57AM +1000, Andrew Gildfind wrote: > On Thu, Jun 14, 2001 at 02:25:45AM +1000, Keith Owens wrote: > > On Wed, 13 Jun 2001 18:36:38 +0300,=20 > > "Tarkan Erimer" wrote: > > > [question about the implementation of ACLs on XFS and ext2] > >=20 > > There are at least two groups working on ACLs for Linux and they > > disagree about how they should be implemented. SGI has one > > implementation of ACL, included in the XFS patch. Andreas Gr|nbacher's > > ACLs are different and will not work with XFS. > >=20 >=20 > To clarify that, we don't disagree at all, we're gradually working towards > a common implementation. Things have moved slowly, but we have a friendly > relationship with the ext2 people, and in due course we want to merge > our efforts. Hopefully there will be more visible progress in the next > couple of months. What exactly are the differences in the implementations of ACLs? What are the points that you could (so far) not agree on?A Where do you already have already agreed on? (Except being POSIX compliant :)) Cheers Martin --=20 Some of my readers ask me what a "Serial Port" is. The answer is: I don't know. Is it some kind of wine you have with breakfast? --IJpNTDwzlM2Ie8A6 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 iD8DBQE7LlJctOa6aqYVgUYRAsNtAKDVchN/qkXoRafDowpQihttV7CVLgCfcv9x wB15HQbekvgwwP95QYhB92g= =rsgL -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From owner-linux-xfs@oss.sgi.com Mon Jun 18 12:31:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IJVtZ22310 for linux-xfs-outgoing; Mon, 18 Jun 2001 12:31:55 -0700 Received: from mail.gmx.net (mail.gmx.de [194.221.183.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IJVsV22306 for ; Mon, 18 Jun 2001 12:31:54 -0700 Received: (qmail 12807 invoked by uid 0); 18 Jun 2001 19:31:47 -0000 Received: from pd901bb90.dip.t-dialin.net (HELO nexus.shadowrun.not) (217.1.187.144) by mail.gmx.net (mail09) with SMTP; 18 Jun 2001 19:31:47 -0000 Received: from nexus.shadowrun.not (localhost [127.0.0.1]) by nexus.shadowrun.not (8.12.0.Beta10/8.12.0.Beta10) with ESMTP id f5IJT6RB002572 for ; Mon, 18 Jun 2001 21:29:06 +0200 Received: (from fastjack@localhost) by nexus.shadowrun.not (8.12.0.Beta10/8.12.0.Beta10/Debian 8.12.0.Beta10) id f5IJT6Fl002566 for linux-xfs@oss.sgi.com; Mon, 18 Jun 2001 21:29:06 +0200 From: Martin Maciaszek Date: Mon, 18 Jun 2001 21:28:46 +0200 To: linux-xfs@oss.sgi.com Subject: Re: Setting Permissions with ACLs Message-ID: <20010618212846.B32530@nexus.shadowrun.not> Mail-Followup-To: mmaciaszek@gmx.net, linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+pHx0qQiF2pBVqBT" Content-Disposition: inline In-Reply-To: <3B1BA119.827B38CB@t-online.de> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --+pHx0qQiF2pBVqBT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 04, 2001 at 04:54:17PM +0200, Juergen Hasch wrote: [...] > It works for me, here is a simple example: >=20 > bash-2.04$ ls -al > total 16 > drwxr-xr-x 2 hasch users 29 Jun 4 16:52 . > drwxr-xr-x 72 hasch users 8192 Jun 4 16:50 .. > -rwxrwx---+ 1 hasch users 0 Jun 4 16:50 test ^ Where did you get an XFS ACL-aware fileutils?=20 Cheers Martin --=20 If the code and the comments disagree, then both are probably wrong. -- Norm Schryer --+pHx0qQiF2pBVqBT 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 iD8DBQE7LlZutOa6aqYVgUYRAqhpAKDlO0k/PZU+RhI0S8f3qT+wfm+qIwCdFw1h FCO5NBjp3Iad/ugP9Wr23/o= =n+1I -----END PGP SIGNATURE----- --+pHx0qQiF2pBVqBT-- From owner-linux-xfs@oss.sgi.com Mon Jun 18 12:51:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IJpDE23166 for linux-xfs-outgoing; Mon, 18 Jun 2001 12:51:13 -0700 Received: from muaddib.localnet (mail@wh6012.stw.uni-rostock.de [139.30.106.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IJpCV23162 for ; Mon, 18 Jun 2001 12:51:12 -0700 Received: from ij by muaddib.localnet with local (Exim 3.22 #1 (Debian)) id 15C53C-0001Tx-00; Mon, 18 Jun 2001 21:51:06 +0200 Date: Mon, 18 Jun 2001 21:51:06 +0200 To: Andrew Klaassen Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and RAID5 Message-ID: <20010618215106.F1109@muaddib.localnet> References: <4.3.2.7.2.20010618070434.02d268e0@pop.xs4all.nl> <200106180555.FAA00389@groucho.maths.monash.edu.au> <20010618091334.A2209@key.dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010618091334.A2209@key.dkp.com>; from ak@dkp.com on Mon, Jun 18, 2001 at 09:13:34AM -0400 From: Ingo Juergensmann X-Scanner: exiscan *15C53C-0001Tx-00*kY3hjAM672Y* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Jun 18, 2001 at 09:13:34AM -0400, Andrew Klaassen wrote: > 7 disks? I'm curious: SCSI or IDE? (We're looking into a > Promise or 3ware card to allow us to put lots of IDE drives in a > box and run software RAID over top, and were wondering if anyone > else has had experience with these cards+software RAID+XFS.) Well, SCSI offers some advantages over IDE whereas IDEs main advantage is its llow price, but beside this Software RAID5 with XFS and SCSI is working fine here since some weeks with 4x old 2 GB disks on an old HP Netserver 5/133 LS. Being a gift it's a nice machine doing nice things with its RAID5... special fun is to pull out its hotswappable disks although it is not so much fun that the Linux md driver isn't really hotswappable. But I'm running 2.4.3 with stable 1.0 XFS. A 2.4.6pre2 with CVS XFS wasn't really stable, but hey, it's CVS code... And compared to fsck'ing the 9 GB ext2 drive XFS is a real advancement for every user, IMHO, even though syncing the RAID while it is mounted slows down everything a bit (remember: Software RAID5) you can work on the machine where ext2 would still fsckin around... And for those who are interested: XFS is on / with a 50 MB ext2 /boot partition, working pretty good... Well, and personally I'm curios to know and to find out if Linux XFS really works with that 1 GB original SGI drive I pulled out of my Indy... -- Ciao... // PowerAnimator & Maya Operator Ingo \X/ To boldly design where noone designed before! From owner-linux-xfs@oss.sgi.com Mon Jun 18 13:10:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IKABv24036 for linux-xfs-outgoing; Mon, 18 Jun 2001 13:10:11 -0700 Received: from foo.penguincomputing.com (gateway.penguincomputing.com [63.143.102.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IKAAV24032 for ; Mon, 18 Jun 2001 13:10:10 -0700 Received: from localhost (jwright@localhost) by foo.penguincomputing.com (8.11.0/8.11.0) with ESMTP id f5IKA9H32038; Mon, 18 Jun 2001 13:10:09 -0700 X-Authentication-Warning: foo.penguincomputing.com: jwright owned process doing -bs Date: Mon, 18 Jun 2001 13:10:09 -0700 (PDT) From: Jim Wright Reply-To: Jim Wright To: cc: Jim Wright Subject: oops with 2.4.5 + xfs + md raid0 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk System: Tyan Tiger LE S2515ING dual 1ghz PIII 1gb memory two IBM DTLA 307075 drives each drive master on a channel of the onboard raid onboard raid detected as Promise PDC20267 onboard raid set so each drive is a single span set net effect is to use the onboard raid as a pair of simple ide controllers operating system on separate hard drive 2.4.5 + linux-2.4.5-xfs-06042001.patch.bz2 + ide.2.4.5.06062001.patch (Andre Hedrick IDE patches) + linux-2.4.0-sard.patch (extended /proc/partitions info) Drives have numerous partitions. Each pair of partitions are configured to use software raid 0 with varying stripe size. Each raid 0 set has an xfs filesystem on it, built with the default parameters. I left Bonnie running over night, and this morning came in to find an oops. The decoding follows. Let me know if I can be of further help. I'm not on the list, so please CC me on any replies. I found the new patch bundle from 11June2001 and will use those. Are the patches on an every Monday schedule? If so, I'll use today's instead when they come out. Jim Script started on Mon Jun 18 12:01:35 2001 [root@test220 /root]# ksymoops oops ksymoops 2.4.0 on i686 2.4.5-xfs. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5-xfs/ (default) -m /boot/System.map-2.4.5-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. Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says c026b350, System.map says c0153dc0. Ignoring ksyms_base entry Unable to handle kernel NULL pointer dereference at virtual address 00000048 c0125eb8 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: f7e01678 ebx: 00000040 ecx: 00000012 edx: 00049039 esi: f7e01678 edi: 00049039 ebp: f7771864 esp: f5d2dd6c ds: 0018 es: 0018 ss: 0018 Process Bonnie (pid: 1599, stackpage=f5d2d000) Stack: 00003000 f7e01678 f5d2dd8c f7771864 c0128169 f7771864 00049039 f7e01678 00000000 c012ea0e 165a9000 49038000 c013641c 00003000 49039000 00000000 00000000 c0186358 f7771864 00049039 00000001 00001000 00000000 00001000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 39 6b 08 75 f4 39 7b 0c 75 ef b8 02 00 00 00 f0 0f ab 43 18 >>EIP; c0125eb8 <__find_lock_page+28/d0> <===== Trace; c0128169 Trace; c012ea0e Trace; c013641c Trace; c0186358 <__pagebuf_do_delwri+1f8/240> Trace; c01864e8 <_pagebuf_file_write+148/200> Trace; c01867c9 Trace; c01e87d0 Trace; c01e9b1f Trace; c01e87d0 Trace; c01e576c Trace; c0134216 Trace; c0106ffb Trace; c010002b Code; c0125eb8 <__find_lock_page+28/d0> 00000000 <_EIP>: Code; c0125eb8 <__find_lock_page+28/d0> <===== 0: 39 6b 08 cmp %ebp,0x8(%ebx) <===== Code; c0125ebb <__find_lock_page+2b/d0> 3: 75 f4 jne fffffff9 <_EIP+0xfffffff9> c0125eb1 <__find_lock_page+21/d0> Code; c0125ebd <__find_lock_page+2d/d0> 5: 39 7b 0c cmp %edi,0xc(%ebx) Code; c0125ec0 <__find_lock_page+30/d0> 8: 75 ef jne fffffff9 <_EIP+0xfffffff9> c0125eb1 <__find_lock_page+21/d0> Code; c0125ec2 <__find_lock_page+32/d0> a: b8 02 00 00 00 mov $0x2,%eax Code; c0125ec7 <__find_lock_page+37/d0> f: f0 0f ab 43 18 lock bts %eax,0x18(%ebx) 3 warnings issued. Results may not be reliable. [root@test220 /root]# exit exit Script done on Mon Jun 18 12:01:44 2001 From owner-linux-xfs@oss.sgi.com Mon Jun 18 13:19:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IKJ5G24486 for linux-xfs-outgoing; Mon, 18 Jun 2001 13:19:05 -0700 Received: from mailout01.sul.t-online.de (mailout01.sul.t-online.com [194.25.134.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IKJ4V24483 for ; Mon, 18 Jun 2001 13:19:04 -0700 Received: from fwd04.sul.t-online.de by mailout01.sul.t-online.de with smtp id 15C5UB-000550-0B; Mon, 18 Jun 2001 22:18:59 +0200 Received: from t-online.de (340024412816-0001@[217.81.135.71]) by fwd04.sul.t-online.com with esmtp id 15C5U2-29O5tAC; Mon, 18 Jun 2001 22:18:50 +0200 Message-ID: <3B2E623B.EC3CD7A1@t-online.de> Date: Mon, 18 Jun 2001 22:19:07 +0200 From: Hasch@t-online.de (Juergen Hasch) X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 To: Martin Maciaszek CC: linux-xfs@oss.sgi.com Subject: Re: Setting Permissions with ACLs References: <20010618212846.B32530@nexus.shadowrun.not> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: 340024412816-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Martin Maciaszek schrieb: > > On Mon, Jun 04, 2001 at 04:54:17PM +0200, Juergen Hasch wrote: > [...] > > It works for me, here is a simple example: > > > > bash-2.04$ ls -al > > total 16 > > drwxr-xr-x 2 hasch users 29 Jun 4 16:52 . > > drwxr-xr-x 72 hasch users 8192 Jun 4 16:50 .. > > -rwxrwx---+ 1 hasch users 0 Jun 4 16:50 test > ^ > Where did you get an XFS ACL-aware fileutils? Get fileutils-4.1.tar from your favourite GNU ftp mirror and the fileutils-patch from http://acl.bestbits.at For now, you will also need the following patch in the src directory: --- permissions.orig Thu Jun 7 22:49:44 2001 +++ permissions.c Thu Jun 7 22:48:22 2001 @@ -262,18 +262,20 @@ if ((acl_text = acl_to_text(acl, NULL)) != NULL) { char *c = acl_text, entries = 0; if (*c != '\0') { - entries++; while (*c != '\0') { - if (*c++ == ',') + if (*c++ == '\n') entries++; } } acl_free(acl_text); return entries; } else { ...Juergen From owner-linux-xfs@oss.sgi.com Mon Jun 18 13:46:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IKkd525788 for linux-xfs-outgoing; Mon, 18 Jun 2001 13:46:39 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IKkcV25779 for ; Mon, 18 Jun 2001 13:46:38 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA01083 for ; Mon, 18 Jun 2001 13:46:11 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2192864; Mon, 18 Jun 2001 15:44:27 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA15485; Mon, 18 Jun 2001 15:44:27 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5IKl2t31271; Mon, 18 Jun 2001 15:47:02 -0500 Message-Id: <200106182047.f5IKl2t31271@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jim Wright cc: linux-xfs@oss.sgi.com Subject: Re: oops with 2.4.5 + xfs + md raid0 In-Reply-To: Message from Jim Wright of "Mon, 18 Jun 2001 13:10:09 PDT." Date: Mon, 18 Jun 2001 15:47:02 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > System: > > Tyan Tiger LE S2515ING > dual 1ghz PIII > 1gb memory > two IBM DTLA 307075 drives > each drive master on a channel of the onboard raid > onboard raid detected as Promise PDC20267 > onboard raid set so each drive is a single span set > net effect is to use the onboard raid as a pair of simple ide controllers > > operating system on separate hard drive > 2.4.5 > + linux-2.4.5-xfs-06042001.patch.bz2 > + ide.2.4.5.06062001.patch (Andre Hedrick IDE patches) > + linux-2.4.0-sard.patch (extended /proc/partitions info) > > Drives have numerous partitions. Each pair of partitions are configured > to use software raid 0 with varying stripe size. Each raid 0 set has > an xfs filesystem on it, built with the default parameters. > > I left Bonnie running over night, and this morning came in to find an > oops. The decoding follows. Let me know if I can be of further help. > I'm not on the list, so please CC me on any replies. > > I found the new patch bundle from 11June2001 and will use those. Are > the patches on an every Monday schedule? If so, I'll use today's instead > when they come out. Patches are not really regular, the cvs tree is the most frequently updated source of xfs code. This is currently at 2.4.6-pre3. There are some changes in the later patch, but nothing I would expect to affect this. This oops is nasty in that it appears to represent a bad pointer in a page hash so far as I can tell. Can you report the compiler version you used and send a disassembly of the whole of the __find_lock_page (run gdb on vmlinux and use the disassemble command). Can you also send me a pointer to Andre's ide patch please. Thanks Steve > > Jim > From owner-linux-xfs@oss.sgi.com Mon Jun 18 14:08:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IL8RR26873 for linux-xfs-outgoing; Mon, 18 Jun 2001 14:08:27 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IL8PV26869 for ; Mon, 18 Jun 2001 14:08:26 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15C6Ev-0005PL-00; Tue, 19 Jun 2001 09:07:17 +1200 Date: Tue, 19 Jun 2001 09:07:17 +1200 (NZST) From: Juha Saarinen To: Steve Lord cc: Andrew Klaassen , "linux-xfs@oss.sgi.com" Subject: Re: Testing XFS+RAID5 In-Reply-To: <200106181830.f5IIUZq28997@jen.americas.sgi.com> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk checking for sys/acl.h... no FATAL ERROR: could not find a valid Access Control List header. Install either the acl-devel (rpm) or the acl-dev (deb) package. make: *** [include/builddefs] Error 1 [root@dendennis xfstests]# rpm -qa | grep acl acl-devel-1.0.5-0 acl-1.0.5-0 Hmmm... I'm sure it's a simple fix, but which "sys" directory is configure looking in? -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 On Mon, 18 Jun 2001, Steve Lord wrote: > For local access stress, run make in the cmd/xfstests directory (you will need > the various devel rpms installed, including rev 1.06 of the acl rpms if you > have a current cvs tree). > > This will give you an fsstress binary in the xfstests/src directory, > doing something like: > > fsstress -d /xfs-filesystem -p 8 -n 10000 > > will run 8 parallel threads doing 10000 random operations each in the > specified directory. You can bump the numbers, but you will chew up large > amounts of disk space. > > From owner-linux-xfs@oss.sgi.com Mon Jun 18 14:09:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IL9dG27049 for linux-xfs-outgoing; Mon, 18 Jun 2001 14:09:39 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IL9bV27046 for ; Mon, 18 Jun 2001 14:09:37 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA493607 for ; Mon, 18 Jun 2001 23:09:35 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2161606; Mon, 18 Jun 2001 16:08:17 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA27971; Mon, 18 Jun 2001 16:08:17 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5ILAqN31641; Mon, 18 Jun 2001 16:10:52 -0500 Message-Id: <200106182110.f5ILAqN31641@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Juha Saarinen cc: Steve Lord , Andrew Klaassen , "linux-xfs@oss.sgi.com" Subject: Re: Testing XFS+RAID5 In-Reply-To: Message from Juha Saarinen of "Tue, 19 Jun 2001 09:07:17 +1200." Date: Mon, 18 Jun 2001 16:10:52 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The file moved, you need to rebuild the acl rpms and install the 1.0.6 version. Steve > checking for sys/acl.h... no > > FATAL ERROR: could not find a valid Access Control List header. > Install either the acl-devel (rpm) or the acl-dev (deb) package. > make: *** [include/builddefs] Error 1 > > [root@dendennis xfstests]# rpm -qa | grep acl > acl-devel-1.0.5-0 > acl-1.0.5-0 > > Hmmm... I'm sure it's a simple fix, but which "sys" directory is configure > looking in? > > -- > Regards, > > > Juha > > PGP fingerprint: > B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 > > On Mon, 18 Jun 2001, Steve Lord wrote: > > > For local access stress, run make in the cmd/xfstests directory (you will n > eed > > the various devel rpms installed, including rev 1.06 of the acl rpms if you > > have a current cvs tree). > > > > This will give you an fsstress binary in the xfstests/src directory, > > doing something like: > > > > fsstress -d /xfs-filesystem -p 8 -n 10000 > > > > will run 8 parallel threads doing 10000 random operations each in the > > specified directory. You can bump the numbers, but you will chew up large > > amounts of disk space. > > > > From owner-linux-xfs@oss.sgi.com Mon Jun 18 14:17:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5ILHHC27693 for linux-xfs-outgoing; Mon, 18 Jun 2001 14:17:17 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5ILHCV27690 for ; Mon, 18 Jun 2001 14:17:12 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15C6Nz-0005Pd-00; Tue, 19 Jun 2001 09:16:39 +1200 Date: Tue, 19 Jun 2001 09:16:39 +1200 (NZST) From: Juha Saarinen To: Steve Lord cc: Andrew Klaassen , "linux-xfs@oss.sgi.com" Subject: Re: Testing XFS+RAID5 In-Reply-To: <200106182110.f5ILAqN31641@jen.americas.sgi.com> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Oh yeah, I remember now. Sorry about the noise. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 On Mon, 18 Jun 2001, Steve Lord wrote: > > The file moved, you need to rebuild the acl rpms and install the 1.0.6 > version. > > Steve From owner-linux-xfs@oss.sgi.com Mon Jun 18 15:06:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IM6cc30014 for linux-xfs-outgoing; Mon, 18 Jun 2001 15:06:38 -0700 Received: from isis.telemach.net (isis.telemach.net [213.143.65.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IM6ZV30008 for ; Mon, 18 Jun 2001 15:06:36 -0700 Received: from telemach.net (TM-68-212.cable.telemach.net [213.143.68.212]) by isis.telemach.net (Postfix) with ESMTP id 7BE727A112 for ; Tue, 19 Jun 2001 00:06:33 +0200 (CEST) Message-ID: <3B2E7B68.57133A7@telemach.net> Date: Tue, 19 Jun 2001 00:06:32 +0200 From: Jure Pecar Organization: Select Technology X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS and RAID5 References: <4.3.2.7.2.20010618070434.02d268e0@pop.xs4all.nl> <200106180555.FAA00389@groucho.maths.monash.edu.au> <20010618091334.A2209@key.dkp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > 7 disks? I'm curious: SCSI or IDE? (We're looking into a > Promise or 3ware card to allow us to put lots of IDE drives in a > box and run software RAID over top, and were wondering if anyone > else has had experience with these cards+software RAID+XFS.) > I have at home a 8x 80gb ide setup with 3ware 8port card (jbod config), running sw raid5 and xfs. I can get 45mbps out of it straight, without any tunning. Which is more than enough for this music & movie box :) Cpu is athlon 750, 256mb ram. All this (+2 small ide drives for system) is squeezed into standard midi tower case. With some additional fans it runs cool enough to not cause problems. The only thing to look for in such setup is a bit more muscular powersupply; 3ware card spins all drives at once, altough i don't see the reason why they didnt implement it in the way scsi controllers start disks one by one ... So far it worked without problems, with xfs enhanced rh 2.4.2 kernel. PS. Really usefull util for setups we tend to discuss here is this: http://csl.cse.ucsc.edu/smart.shtml -- Jure Pecar From owner-linux-xfs@oss.sgi.com Mon Jun 18 15:18:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IMIr430585 for linux-xfs-outgoing; Mon, 18 Jun 2001 15:18:53 -0700 Received: from foo.penguincomputing.com (gateway.penguincomputing.com [63.143.102.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IMIlV30580 for ; Mon, 18 Jun 2001 15:18:48 -0700 Received: from localhost (jwright@localhost) by foo.penguincomputing.com (8.11.0/8.11.0) with ESMTP id f5IMIk832490; Mon, 18 Jun 2001 15:18:46 -0700 X-Authentication-Warning: foo.penguincomputing.com: jwright owned process doing -bs Date: Mon, 18 Jun 2001 15:18:46 -0700 (PDT) From: Jim Wright Reply-To: Jim Wright To: Steve Lord cc: , Jim Wright Subject: Re: oops with 2.4.5 + xfs + md raid0 In-Reply-To: <200106182047.f5IKl2t31271@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 18 Jun 2001, Steve Lord wrote: > > This oops is nasty in that it appears to represent a bad pointer in a > page hash so far as I can tell. Can you report the compiler version you > used and send a disassembly of the whole of the __find_lock_page (run gdb > on vmlinux and use the disassemble command). # gcc --version 2.96 # rpm -q gcc gcc-2.96-81 gdb output below. I changed the configuration of the box and just got a second oops. When this happens, I'm unable to CTRL-C the Bonnie process that I was running, and I am unable to log in on a different virtual console or over the network. Hard reset is the only way out. New config: dual 1ghz PIII, 1gb memory, two IBM 75gb drives on a 3ware 6410 IDE RAID controller, raid0, drives accessed as /dev/sda. second oops is below as well. > Can you also send me a pointer to Andre's ide patch please. http://www.kernel.org/pub/linux/kernel/people/hedrick/ide-2.4.5/ide.2.4.5.06062001.patch.bz2 Thanks for looking at this. Jim # gdb vmlinux GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) disassemble __find_lock_page Dump of assembler code for function __find_lock_page: 0xc0125e90 <__find_lock_page>: push %ebp 0xc0125e91 <__find_lock_page+1>: push %edi 0xc0125e92 <__find_lock_page+2>: push %esi 0xc0125e93 <__find_lock_page+3>: push %ebx 0xc0125e94 <__find_lock_page+4>: mov 0x14(%esp,1),%ebp 0xc0125e98 <__find_lock_page+8>: mov 0x18(%esp,1),%edi 0xc0125e9c <__find_lock_page+12>: lock decb 0xc032a0a4 0xc0125ea3 <__find_lock_page+19>: js 0xc02b7995 0xc0125ea9 <__find_lock_page+25>: mov 0x1c(%esp,1),%eax 0xc0125ead <__find_lock_page+29>: mov (%eax),%ebx 0xc0125eaf <__find_lock_page+31>: jmp 0xc0125eb4 <__find_lock_page+36> 0xc0125eb1 <__find_lock_page+33>: mov 0x10(%ebx),%ebx 0xc0125eb4 <__find_lock_page+36>: test %ebx,%ebx 0xc0125eb6 <__find_lock_page+38>: je 0xc0125ecc <__find_lock_page+60> 0xc0125eb8 <__find_lock_page+40>: cmp %ebp,0x8(%ebx) 0xc0125ebb <__find_lock_page+43>: jne 0xc0125eb1 <__find_lock_page+33> 0xc0125ebd <__find_lock_page+45>: cmp %edi,0xc(%ebx) 0xc0125ec0 <__find_lock_page+48>: jne 0xc0125eb1 <__find_lock_page+33> 0xc0125ec2 <__find_lock_page+50>: mov $0x2,%eax 0xc0125ec7 <__find_lock_page+55>: lock bts %eax,0x18(%ebx) 0xc0125ecc <__find_lock_page+60>: test %ebx,%ebx 0xc0125ece <__find_lock_page+62>: je 0xc0125f50 <__find_lock_page+192> 0xc0125ed4 <__find_lock_page+68>: lock incl 0x14(%ebx) 0xc0125ed8 <__find_lock_page+72>: movb $0x1,0xc032a0a4 0xc0125edf <__find_lock_page+79>: push %ebx 0xc0125ee0 <__find_lock_page+80>: call 0xc0125d60 0xc0125ee5 <__find_lock_page+85>: mov 0x8(%ebx),%eax 0xc0125ee8 <__find_lock_page+88>: pop %edx 0xc0125ee9 <__find_lock_page+89>: test %eax,%eax 0xc0125eeb <__find_lock_page+91>: je 0xc0125ef1 <__find_lock_page+97> 0xc0125eed <__find_lock_page+93>: mov %ebx,%eax 0xc0125eef <__find_lock_page+95>: jmp 0xc0125f59 <__find_lock_page+201> 0xc0125ef1 <__find_lock_page+97>: lock btr %eax,0x18(%ebx) 0xc0125ef6 <__find_lock_page+102>: sbb %eax,%eax 0xc0125ef8 <__find_lock_page+104>: test %eax,%eax 0xc0125efa <__find_lock_page+106>: jne 0xc0125f20 <__find_lock_page+144> 0xc0125efc <__find_lock_page+108>: push $0x310 0xc0125f01 <__find_lock_page+113>: push $0xc02c87e1 0xc0125f06 <__find_lock_page+118>: push $0xc02c86e3 0xc0125f0b <__find_lock_page+123>: call 0xc0115d10 0xc0125f10 <__find_lock_page+128>: ud2a 0xc0125f12 <__find_lock_page+130>: add $0xc,%esp 0xc0125f15 <__find_lock_page+133>: lea 0x0(%esi,1),%esi 0xc0125f19 <__find_lock_page+137>: lea 0x0(%edi,1),%edi 0xc0125f20 <__find_lock_page+144>: lea 0x2c(%ebx),%eax 0xc0125f23 <__find_lock_page+147>: lea 0x28(%ebx),%esi 0xc0125f26 <__find_lock_page+150>: cmp %eax,0x2c(%ebx) 0xc0125f29 <__find_lock_page+153>: je 0xc0125f3c <__find_lock_page+172> 0xc0125f2b <__find_lock_page+155>: mov $0x1,%ecx 0xc0125f30 <__find_lock_page+160>: mov $0x3,%edx 0xc0125f35 <__find_lock_page+165>: mov %esi,%eax 0xc0125f37 <__find_lock_page+167>: call 0xc01135e0 <__wake_up> 0xc0125f3c <__find_lock_page+172>: xor %edx,%edx 0xc0125f3e <__find_lock_page+174>: mov %ebx,%eax 0xc0125f40 <__find_lock_page+176>: call 0xc012e920 <__free_pages> 0xc0125f45 <__find_lock_page+181>: jmp 0xc0125e9c <__find_lock_page+12> 0xc0125f4a <__find_lock_page+186>: lea 0x0(%esi),%esi 0xc0125f50 <__find_lock_page+192>: movb $0x1,0xc032a0a4 0xc0125f57 <__find_lock_page+199>: xor %eax,%eax 0xc0125f59 <__find_lock_page+201>: pop %ebx 0xc0125f5a <__find_lock_page+202>: pop %esi 0xc0125f5b <__find_lock_page+203>: pop %edi 0xc0125f5c <__find_lock_page+204>: pop %ebp 0xc0125f5d <__find_lock_page+205>: ret 0xc0125f5e <__find_lock_page+206>: mov %esi,%esi End of assembler dump. (gdb) # ksymoops oops2 ksymoops 2.4.0 on i686 2.4.5-xfs. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5-xfs/ (default) -m /boot/System.map-2.4.5-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. Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says c026b350, System.map says c0153dc0. Ignoring ksyms_base entry Unable to handle kernel NULL pointer dereference at virtual address 00000048 c012616c *pde = 00000000 Oops: 0000 CPU: 1 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: f7e00000 ebx: e5bd2a84 ecx: f7e1acd0 edx: 00000040 esi: c17794d0 edi: e5b6be40 ebp: 000094f5 esp: e5b69e38 ds: 0018 es: 0018 ss: 0018 Process Bonnie (pid: 1011, stackpage=e5b69000) Stack: f7e1acd0 0000001f 000094e5 00000010 00000020 000094c7 0007ff00 00000001 c159f13c e5bd2a84 000094c7 c012641d 00000001 e5b6be40 e5bd29e0 c159f13c 00001000 00000001 00000000 00000000 e5bd29e0 c011a18d c1eecce0 c0396a6c Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 39 5a 08 75 f4 39 6a 0c 75 ef b8 02 00 00 00 f0 0f ab 42 18 >>EIP; c012616c <===== Trace; c012641d Trace; c011a18d <__run_task_queue+5d/70> Trace; c01267f2 Trace; c0126730 Trace; c01e8c80 Trace; c0108c25 Trace; c01e5645 Trace; c0134146 Trace; c0106ffb Trace; c010002b Code; c012616c 00000000 <_EIP>: Code; c012616c <===== 0: 39 5a 08 cmp %ebx,0x8(%edx) <===== Code; c012616f 3: 75 f4 jne fffffff9 <_EIP+0xfffffff9> c0126165 Code; c0126171 5: 39 6a 0c cmp %ebp,0xc(%edx) Code; c0126174 8: 75 ef jne fffffff9 <_EIP+0xfffffff9> c0126165 Code; c0126176 a: b8 02 00 00 00 mov $0x2,%eax Code; c012617b f: f0 0f ab 42 18 lock bts %eax,0x18(%edx) 3 warnings issued. Results may not be reliable. From owner-linux-xfs@oss.sgi.com Mon Jun 18 15:36:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IMaEl31442 for linux-xfs-outgoing; Mon, 18 Jun 2001 15:36:14 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IMaDV31426 for ; Mon, 18 Jun 2001 15:36:13 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15C7cw-0005Uu-00; Tue, 19 Jun 2001 10:36:10 +1200 Date: Tue, 19 Jun 2001 10:36:09 +1200 (NZST) From: Juha Saarinen To: Steve Lord cc: "linux-xfs@oss.sgi.com" Subject: fsstress In-Reply-To: <200106181830.f5IIUZq28997@jen.americas.sgi.com> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well, I just ran ./fsstress -d /usr -p 16 -n 100000 a few times here, to see if XFS 2.4.6-pre3 compiled with gcc 2.96-85 (from RH Rawhide) would go to the great debugger in the sky. It didn't. Just doing it again... the system is quite responsive, with top showing both CPUs (500MHz P3s) being used 30-60%. No swap usage! :-) This system is booted from a single IDE drive at the moment. Will try with the dual SCSI drive set up in a bit. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Mon Jun 18 15:44:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IMifV31966 for linux-xfs-outgoing; Mon, 18 Jun 2001 15:44:41 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IMifV31963 for ; Mon, 18 Jun 2001 15:44:41 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA09706 for ; Mon, 18 Jun 2001 15:44:40 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id IAA03759; Tue, 19 Jun 2001 08:43:13 +1000 (EST) Message-Id: <200106182243.IAA03759@snort.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Marcelo E. Magallon" cc: linux-xfs@oss.sgi.com Subject: Re: Stress test 015 need to check partition size In-reply-to: Your message of "Mon, 18 Jun 2001 09:57:01 +0200." <20010618095701.A984@ysabell.wh.vaih> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Jun 2001 08:43:13 +1000 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Marcelo E. Magallon" writes: => Hi, => => 015 is trying to create a 50MB data section on the device, but don't => check if the operation is sucessful: => => mkfs -t xfs -f -d size=50m $SCRATCH_DEV >/dev/null => => 016 does check, but exits with an error instead of using _notrun. That's because there's a non-specified arbitary minimum size for the stress test partitions. I'd suggest using something more like 100Mb... PS. We're still running the QA against the daily CVS trees, but our QA suite is in maintenance mode rather than under active developemnt (for now at least). ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Jun 18 16:25:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5INPD401469 for linux-xfs-outgoing; Mon, 18 Jun 2001 16:25:13 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5INPCV01466 for ; Mon, 18 Jun 2001 16:25:12 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id QAA00405 for ; Mon, 18 Jun 2001 16:25:05 -0700 (PDT) mail_from (ajag@fudge.melbourne.sgi.com) Received: from fudge.melbourne.sgi.com (fudge.melbourne.sgi.com [134.14.55.184]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA10946; Tue, 19 Jun 2001 09:23:44 +1000 Received: (from ajag@localhost) by fudge.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA32209; Tue, 19 Jun 2001 09:23:42 +1000 (EST) Date: Tue, 19 Jun 2001 09:23:41 +1000 From: Andrew Gildfind To: "Marcelo E. Magallon" Cc: linux-xfs@oss.sgi.com Subject: Re: Stress test 015 need to check partition size Message-ID: <20010619092341.B29957@fudge.melbourne.sgi.com> References: <20010618095701.A984@ysabell.wh.vaih> <200106182243.IAA03759@snort.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200106182243.IAA03759@snort.melbourne.sgi.com>; from dxm@snort on Tue, Jun 19, 2001 at 08:43:13AM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jun 19, 2001 at 08:43:13AM +1000, Daniel Moore wrote: > > "Marcelo E. Magallon" writes: > => Hi, > => > => 015 is trying to create a 50MB data section on the device, but don't > => check if the operation is sucessful: > => > => mkfs -t xfs -f -d size=50m $SCRATCH_DEV >/dev/null > => > => 016 does check, but exits with an error instead of using _notrun. > > That's because there's a non-specified arbitary minimum size for the > stress test partitions. I'd suggest using something more like 100Mb... I've run into this before. According to mkfs.xfs(8) min allocation group size is 16 MB. xfs_repair needs three allocation groups to verify the superblock, which means the smallest filesystem that I've been able to use for the tests (see 041/042) is 3x16Mb. > > PS. We're still running the QA against the daily CVS trees, but our > QA suite is in maintenance mode rather than under active developemnt > (for now at least). > > ----------------------------------------------------- > Daniel Moore dxm@sgi.com > R&D Software Engineer Phone: +61-3-98348209 > SGI Performance Tools Group Fax: +61-3-98132378 > ----------------------------------------------------- > -- Andrew Gildfind - R&D Software Engineer - SGI Melbourne Australia email: ajag@sgi.com - work: +61.3.9834.8200 mobile: 0412.834.183 From owner-linux-xfs@oss.sgi.com Mon Jun 18 16:48:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5INmoe02685 for linux-xfs-outgoing; Mon, 18 Jun 2001 16:48:50 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5INmnV02682 for ; Mon, 18 Jun 2001 16:48:49 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip11.idcomm.com [209.60.72.138]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5INn1l18695 for ; Mon, 18 Jun 2001 17:49:01 -0600 Message-ID: <3B2E93B2.2353BC4E@idcomm.com> Date: Mon, 18 Jun 2001 17:50:10 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: db servers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am curious about something. A lot of people are locally talking about different db's and their performance, along with reasons why they can migrate to Linux db's when most of their co-workers are MS-centric. Have any of the people here done any kind of benchmarks or other tests for db performance of IBM's db2, Oracle, PostgreSQL, so on? I'm curious how these various db's work with XFS, especially the ones that want raw access. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Mon Jun 18 17:29:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J0TuB04340 for linux-xfs-outgoing; Mon, 18 Jun 2001 17:29:56 -0700 Received: from deliverator.sgi.com ([204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J0TtV04336 for ; Mon, 18 Jun 2001 17:29:55 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA25160 for ; Mon, 18 Jun 2001 17:28:59 -0700 (PDT) mail_from (ivanr@melbourne.sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA11260; Tue, 19 Jun 2001 10:27:46 +1000 From: ivanr@melbourne.sgi.com (Ivan Rayner) Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA06259; Tue, 19 Jun 2001 10:27:46 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Tue, 19 Jun 2001 10:27:46 +1000 To: Christoph Lukas cc: Subject: Re: using xfsdump with 'file device' In-Reply-To: <0106181630320C.01455@skera> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 18 Jun 2001, Christoph Lukas wrote: > we would like to use xfsdump to backup one of our xfs filesystems onto > another hard disk. Therefore I tried: > > xfsdump -l0 -F -f /mnt/backupfile /dev/sda3 > > Although we are running kernel 2.4.3 and glibc _with_ >2GB support (tried > with 'dd if=/dev/null of=/mnt/testfile' ) xfsdump exits after dumping 2GB > with: I would think that 'dd if=/dev/null' will give you a 0 byte file .. what happens with 'dd if=/dev/zero of=/mnt/testfile bs=1024 count=3145728' ? > xfsdump: creating dump session media file 0 (media 0, file 0) > xfsdump: dumping ino map > xfsdump: dumping directories > xfsdump: dumping non-directory files > File size limit exceeded This message is not produced by xfsdump, but is the result of a failed write (errno == 25). > is there any possibility to exceed this limit (compile time option?) or any > easy alternative to work with multiple 2GB files (like the ordinary dump > does)? By default xfsdump is compiled with -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE which should be enough to make it work properly. If you still have problems, could you run xfsdump with '-v5' to get lots of verbose output so we can get an idea of where exactly xfsdump fails. Ivan -- Ivan Rayner ivanr@melbourne.sgi.com From owner-linux-xfs@oss.sgi.com Mon Jun 18 17:31:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J0VCw04414 for linux-xfs-outgoing; Mon, 18 Jun 2001 17:31:12 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J0VCV04411 for ; Mon, 18 Jun 2001 17:31:12 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id RAA02549 for ; Mon, 18 Jun 2001 17:30:47 -0700 (PDT) mail_from (ajag@fudge.melbourne.sgi.com) Received: from fudge.melbourne.sgi.com (fudge.melbourne.sgi.com [134.14.55.184]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA11263; Tue, 19 Jun 2001 10:29:04 +1000 Received: (from ajag@localhost) by fudge.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA32656; Tue, 19 Jun 2001 10:29:02 +1000 (EST) Date: Tue, 19 Jun 2001 10:29:01 +1000 From: Andrew Gildfind To: Martin Maciaszek Cc: linux-xfs@oss.sgi.com Subject: Re: ACL Support Message-ID: <20010619102901.C29957@fudge.melbourne.sgi.com> References: <20010614091857.P8175@fudge.melbourne.sgi.com> <20010618211125.A32530@nexus.shadowrun.not> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20010618211125.A32530@nexus.shadowrun.not>; from mmaciaszek@gmx.net on Mon, Jun 18, 2001 at 09:11:25PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Jun 18, 2001 at 09:11:25PM +0200, Martin Maciaszek wrote: > On Thu, Jun 14, 2001 at 09:18:57AM +1000, Andrew Gildfind wrote: > > On Thu, Jun 14, 2001 at 02:25:45AM +1000, Keith Owens wrote: > > > On Wed, 13 Jun 2001 18:36:38 +0300, > > > "Tarkan Erimer" wrote: > > > > [question about the implementation of ACLs on XFS and ext2] > > > > > > There are at least two groups working on ACLs for Linux and they > > > disagree about how they should be implemented. SGI has one > > > implementation of ACL, included in the XFS patch. Andreas Gr|nbacher's > > > ACLs are different and will not work with XFS. > > > > > > > To clarify that, we don't disagree at all, we're gradually working towards > > a common implementation. Things have moved slowly, but we have a friendly > > relationship with the ext2 people, and in due course we want to merge > > our efforts. Hopefully there will be more visible progress in the next > > couple of months. > > What exactly are the differences in the implementations of ACLs? > What are the points that you could (so far) not agree on?A > Where do you already have already agreed on? (Except being POSIX > compliant :)) > Primarily the system call interface. There has been a great deal of discussion on fsdevel/acldevel about this. The current ext2 syscall interface raised issues for others, particularly its support for NFSv4/NT/other types of acls. Last time I checked Andreas was in the process of evolving his system call interface to address some of those issues. Andrew -- Andrew Gildfind - R&D Software Engineer - SGI Melbourne Australia email: ajag@sgi.com - work: +61.3.9834.8200 mobile: 0412.834.183 From owner-linux-xfs@oss.sgi.com Mon Jun 18 17:56:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J0uxq05915 for linux-xfs-outgoing; Mon, 18 Jun 2001 17:56:59 -0700 Received: from trinity.arcadio.net (adsl-141-157-92-248.baltmd.adsl.bellatlantic.net [141.157.92.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J0uwV05910 for ; Mon, 18 Jun 2001 17:56:58 -0700 Received: (qmail 8316 invoked from network); 19 Jun 2001 01:55:21 -0000 Received: from neo.arcadio.net (HELO neo) (10.10.10.6) by trinity.arcadio.net with SMTP; 19 Jun 2001 01:55:21 -0000 Message-ID: <025b01c0f85a$9b8c9280$060a0a0a@neo> From: "Arcadio A. Sincero Jr." To: Subject: *** Shrinking an XFS filesystem. *** Date: Mon, 18 Jun 2001 20:56:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello list, Is it possible to shrink an XFS filesystem? Thanks, Arcadio From owner-linux-xfs@oss.sgi.com Mon Jun 18 18:02:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J12EX06283 for linux-xfs-outgoing; Mon, 18 Jun 2001 18:02:14 -0700 Received: from dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J12DV06280 for ; Mon, 18 Jun 2001 18:02:13 -0700 Received: (from ak@localhost) by dkp.com (8.9.3/8.9.3) id VAA15218 for linux-xfs@oss.sgi.com; Mon, 18 Jun 2001 21:02:12 -0400 Date: Mon, 18 Jun 2001 21:02:11 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: RedHat Rawhide + XFS rpm available for testing. Message-ID: <20010618210211.H2209@key.dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3B299D51.85A6B204@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3B299D51.85A6B204@thebarn.com>; from cattelan@thebarn.com on Fri, Jun 15, 2001 at 12:29:53AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Jun 15, 2001 at 12:29:53AM -0500, Russell Cattelan wrote: > Ok after a few false starts I finally have a running > > RedHat rawhide kernel + XFS. > > The XFS patches are in sync with the devel tree. > > All the rpms can be gotten at: > > ftp://oss.sgi.com/projects/xfs/download/testing/RHrawhide/ > > These have not been tested extensively so use at your own > risk. Using these rpms, I saw this on bootup: md: syncing RAID array md1 md: minimum _guaranteed_ reconstruction speed: 100 KB/sec/disc. md: using maximum available idle IO bandwith (but not more than 100000 KB/sec) for reconstruction. md: using 508k window, over a total of 74280960 blocks. ide/host0/bus1/target0/lun0/part3 [events: 00000014](write) ide/host0/bus1/target0/lun0/part3's sb offset: 74280960 ide/host2/bus0/target0/lun0/part3 [events: 00000014](write) ide/host2/bus0/target0/lun0/part3's sb offset: 74280960 hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } hda: dma_intr: error=0x84 { DriveStatusError BadCRC } hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } hda: dma_intr: error=0x84 { DriveStatusError BadCRC } hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } hda: dma_intr: error=0x84 { DriveStatusError BadCRC } hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } hda: dma_intr: error=0x84 { DriveStatusError BadCRC } ide/host2/bus0/target1/lun0/part3 [events: 00000014](write) ide/host2/bus0/target1/lun0/part3's sb offset: 74280960 ide/host2/bus1/target0/lun0/part3 [events: 00000014](write) ide/host2/bus1/target0/lun0/part3's sb offset: 74280960 ide/host2/bus1/target1/lun0/part3 [events: 00000014](write) ide/host2/bus1/target1/lun0/part3's sb offset: 74280960 . ... autorun DONE. VFS: Mounted root (ext2 filesystem) readonly. (etc.) This is with a CMD648 (rev. 1) controller on an ASUS CUBX (rev D) board. Anybody know if these errors ("DriveReady SeekComplete Error", "DriveStatusError BadCRC") are serious? They only occur on bootup, and they occur consistently at this point during bootup. They have occured identically and consistently on two separate machines, with two different drive sets and two different BIOS revisions in them. They do not occur with the kernel-2.4.2-2 provided with RH7.1. And if they are serious, who should I inform about them? Andrew Klaassen From owner-linux-xfs@oss.sgi.com Mon Jun 18 18:04:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J14Do06390 for linux-xfs-outgoing; Mon, 18 Jun 2001 18:04:13 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J14DV06387 for ; Mon, 18 Jun 2001 18:04:13 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA01818 for ; Mon, 18 Jun 2001 18:03:48 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA09047 for ; Tue, 19 Jun 2001 11:02:05 +1000 (EST) Message-Id: <200106190102.LAA09047@snort.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: linux-xfs@oss.sgi.com X-URL: http://zoic.org/dxm Subject: Re: *** Shrinking an XFS filesystem. *** Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Jun 2001 11:02:05 +1000 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Arcadio A. Sincero Jr." writes: => Hello list, => => Is it possible to shrink an XFS filesystem? Other than by backup/recreate/restore, no. See the list archives for discussions re this topic. ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Jun 18 18:14:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J1EY506528 for linux-xfs-outgoing; Mon, 18 Jun 2001 18:14:34 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J1EWV06525 for ; Mon, 18 Jun 2001 18:14:33 -0700 Received: from [192.168.1.10] (helo=den2) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15CA6B-0005av-00 for ; Tue, 19 Jun 2001 13:14:31 +1200 From: "Juha Saarinen" To: "'XFS Mailing List'" Subject: Oops removing files on a full f/s Date: Tue, 19 Jun 2001 13:14:23 +1200 Message-ID: <015801c0f85d$2cdde340$0a01a8c0@den2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk fsstress filled up /usr 100% so I was going remove the p* directories and files. This provoked an oops: Kernel BUG at ll_rw_blk.c:700! Entering kdb (current=0xcbc1a000, pid 944) on processor 0 Oops: invalid operand due to oops @ 0xc020fca4 eax=0x0000001f ebx=0x00000000 ecx=0x00000002 edx=0x20000000 esi=0xca02da80 esp=0xcbc1bd3c eip=0xc020fca4 ebp=0xc040a240 xss=0x00000018 xcs=0x00000010 eflags=0x00010286 xds=0x00000018 xes=0x00000018 origeax=0xffffffff ®s=0xcbc1bd00 [0]kdb> Anything useful likely to come out of this, or should I just reboot? -- Juha From owner-linux-xfs@oss.sgi.com Mon Jun 18 18:23:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J1Nph06657 for linux-xfs-outgoing; Mon, 18 Jun 2001 18:23:51 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J1NpV06654 for ; Mon, 18 Jun 2001 18:23:51 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA02027 for ; Mon, 18 Jun 2001 18:23:26 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA85316; Tue, 19 Jun 2001 11:21:41 +1000 (EST) Message-Id: <200106190121.LAA85316@snort.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Juha Saarinen" Subject: Re: Oops removing files on a full f/s In-reply-to: Your message of "Tue, 19 Jun 2001 13:14:23 +1200." <015801c0f85d$2cdde340$0a01a8c0@den2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: linux-xfs@oss.sgi.com Date: Tue, 19 Jun 2001 11:21:41 +1000 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Juha Saarinen" writes: => fsstress filled up /usr 100% so I was going remove the p* directories => and files. This provoked an oops: => => Kernel BUG at ll_rw_blk.c:700! => => Entering kdb (current=0xcbc1a000, pid 944) on processor 0 Oops: invalid => operand due to oops @ 0xc020fca4 => => eax=0x0000001f ebx=0x00000000 ecx=0x00000002 => edx=0x20000000 esi=0xca02da80 esp=0xcbc1bd3c => eip=0xc020fca4 ebp=0xc040a240 xss=0x00000018 => xcs=0x00000010 eflags=0x00010286 => xds=0x00000018 xes=0x00000018 => origeax=0xffffffff ®s=0xcbc1bd00 => => [0]kdb> => => Anything useful likely to come out of this, or should I just reboot? A backtrace ('bt') and details of your system and what version of XFS you are running would help. ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Jun 18 18:48:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J1mAP06977 for linux-xfs-outgoing; Mon, 18 Jun 2001 18:48:10 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J1m8V06973 for ; Mon, 18 Jun 2001 18:48:08 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id DAA507111 for ; Tue, 19 Jun 2001 03:48:06 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA2191802; Mon, 18 Jun 2001 20:46:49 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id UAA33642; Mon, 18 Jun 2001 20:46:49 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5J1nLo32245; Mon, 18 Jun 2001 20:49:21 -0500 Message-Id: <200106190149.f5J1nLo32245@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Juha Saarinen" cc: "'XFS Mailing List'" Subject: Re: Oops removing files on a full f/s In-Reply-To: Message from "Juha Saarinen" of "Tue, 19 Jun 2001 13:14:23 +1200." <015801c0f85d$2cdde340$0a01a8c0@den2> Date: Mon, 18 Jun 2001 20:49:21 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yes, a backtrace from this would be really useful, also, in the backtrace you will see the arguments of the functions, if you could take the third argument of __make_request and pass it to the md command in kdb: kdb> md
and send the output of that too - it will dump the buffer contents which may help. Thanks Steve > fsstress filled up /usr 100% so I was going remove the p* directories > and files. This provoked an oops: > > Kernel BUG at ll_rw_blk.c:700! > > Entering kdb (current=0xcbc1a000, pid 944) on processor 0 Oops: invalid > operand due to oops @ 0xc020fca4 > > eax=0x0000001f ebx=0x00000000 ecx=0x00000002 > edx=0x20000000 esi=0xca02da80 esp=0xcbc1bd3c > eip=0xc020fca4 ebp=0xc040a240 xss=0x00000018 > xcs=0x00000010 eflags=0x00010286 > xds=0x00000018 xes=0x00000018 > origeax=0xffffffff ®s=0xcbc1bd00 > > [0]kdb> > > Anything useful likely to come out of this, or should I just reboot? > > -- Juha From owner-linux-xfs@oss.sgi.com Mon Jun 18 18:56:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J1uNb07163 for linux-xfs-outgoing; Mon, 18 Jun 2001 18:56:23 -0700 Received: from europa.cox-internet.com (europa-cox.cox-internet.com [208.180.118.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J1uMV07160 for ; Mon, 18 Jun 2001 18:56:22 -0700 Received: from cdm-143-30-bcs.cox-internet.com ([208.180.143.30]) by europa.cox-internet.com (InterMail vK.4.02.00.10 201-232-116-110 license dd72657b95c070b1853187e4f5a0d6a7) with ESMTP id <20010619015357.NCBZ1750.europa@cdm-143-30-bcs.cox-internet.com> for ; Mon, 18 Jun 2001 20:53:57 -0500 Subject: turning devfs off From: Michael Vanderford To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.10.99 (Preview Release) Date: 18 Jun 2001 20:59:30 -0500 Message-Id: <992915971.971.0.camel@cdm-143-30-bcs.cox-internet.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is there an easy way to turn devfs off. Thanks in advance. From owner-linux-xfs@oss.sgi.com Mon Jun 18 18:57:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J1vHX07198 for linux-xfs-outgoing; Mon, 18 Jun 2001 18:57:17 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J1vHV07195 for ; Mon, 18 Jun 2001 18:57:17 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA08066 for ; Mon, 18 Jun 2001 18:57:16 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA2194936 for ; Mon, 18 Jun 2001 20:56:00 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id UAA47575 for ; Mon, 18 Jun 2001 20:56:00 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f5J1wVL32405; Mon, 18 Jun 2001 20:58:31 -0500 Message-Id: <200106190158.f5J1wVL32405@jen.americas.sgi.com> Date: Mon, 18 Jun 2001 20:58:31 -0500 Subject: TAKE - code cleanup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Modify our changes to fs/inode.c to be more in line with accepted Linux style. Date: Mon Jun 18 18:55:19 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-base The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:97080a linux/fs/inode.c - 1.44 - Restructure code changes slightly based on suggestions (from Andi Kleen I think). From owner-linux-xfs@oss.sgi.com Mon Jun 18 18:59:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J1xWO07358 for linux-xfs-outgoing; Mon, 18 Jun 2001 18:59:32 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J1xWV07355 for ; Mon, 18 Jun 2001 18:59:32 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA02019 for ; Mon, 18 Jun 2001 18:59:31 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA2182205 for ; Mon, 18 Jun 2001 20:58:16 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id UAA15794 for ; Mon, 18 Jun 2001 20:58:15 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f5J20ku32488; Mon, 18 Jun 2001 21:00:46 -0500 Message-Id: <200106190200.f5J20ku32488@jen.americas.sgi.com> Date: Mon, 18 Jun 2001 21:00:46 -0500 Subject: TAKE - fix an out of memory case we can cope with Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The handling of return values from icreate was wrong, we would have oopsed if it returned null which is possible. Date: Mon Jun 18 18:57:21 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-base The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:97081a linux/fs/xfs/xfs_iget.c - 1.145 - Deal correctly with icreate failure From owner-linux-xfs@oss.sgi.com Mon Jun 18 19:02:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J22kg07496 for linux-xfs-outgoing; Mon, 18 Jun 2001 19:02:46 -0700 Received: from bug.martins.home (c1164316-a.parker1.co.home.com [24.22.190.144]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J22jV07493 for ; Mon, 18 Jun 2001 19:02:45 -0700 Received: from vpmonline.com (localhost.localdomain [127.0.0.1]) by bug.martins.home (8.11.2/8.11.2) with ESMTP id f5J22d602156; Mon, 18 Jun 2001 20:02:39 -0600 Message-ID: <3B2EB2BD.8030408@vpmonline.com> Date: Mon, 18 Jun 2001 20:02:37 -0600 From: michael User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686; en-US; rv:0.9.1) Gecko/20010607 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Vanderford CC: linux-xfs@oss.sgi.com Subject: Re: turning devfs off References: <992915971.971.0.camel@cdm-143-30-bcs.cox-internet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk when booting at a lilo promp do " linux devfs=nomount " The same can be added in the lilo.conf: append="devfs=nomount". Michael Vanderford wrote: >Is there an easy way to turn devfs off. >Thanks in advance. > -- -- Michael G. Martin mailto:michael@vpmonline.com From owner-linux-xfs@oss.sgi.com Mon Jun 18 19:24:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J2Okd07764 for linux-xfs-outgoing; Mon, 18 Jun 2001 19:24:46 -0700 Received: from sphinx.druber.com ([216.129.135.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J2OjV07761 for ; Mon, 18 Jun 2001 19:24:45 -0700 Received: from sphinx.druber.com (sphinx.druber.com [10.0.0.2]) by sphinx.druber.com (Postfix) with ESMTP id A287B117; Mon, 18 Jun 2001 22:18:04 -0400 (EDT) Date: Mon, 18 Jun 2001 22:18:04 -0400 (EDT) From: Dan Swartzendruber To: Michael Vanderford Cc: Subject: Re: turning devfs off In-Reply-To: <992915971.971.0.camel@cdm-143-30-bcs.cox-internet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 18 Jun 2001, Michael Vanderford wrote: > Is there an easy way to turn devfs off. > Thanks in advance. either build with it disabled, or in /etc/lilo.conf, append 'devfs=nomount' to the boot line. From owner-linux-xfs@oss.sgi.com Mon Jun 18 19:29:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J2T0K07869 for linux-xfs-outgoing; Mon, 18 Jun 2001 19:29:00 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J2SxV07866 for ; Mon, 18 Jun 2001 19:28:59 -0700 Received: from [192.168.1.10] (helo=den2) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15CBGC-0005cx-00; Tue, 19 Jun 2001 14:28:56 +1200 From: "Juha Saarinen" To: "'Daniel Moore'" Cc: Subject: RE: Oops removing files on a full f/s Date: Tue, 19 Jun 2001 14:28:48 +1200 Message-ID: <016c01c0f867$921e67c0$0a01a8c0@den2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <200106190121.LAA85316@snort.melbourne.sgi.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk :: A backtrace ('bt') and details of your system and what version of :: XFS you are running would help. OK. System: Dual P3 (500MHz) 192MB PC100 SDRAM Tyan Tiger 133 (VIA Apollo Pro 133A) Single 20GB Seagate IDE drive (UDMA-66), master channel 0 Single ASUS 40X IDE CD drive (UDMA-33), master channel 1 ATI Rage Pro 3D AGP adapter DEC Tulip PCI NIC Symbios 390 UW PCI adapter (plugged in, but no drives connected) XFS is the 2.4.6-pre3 version from CVS, two days ago. Backtrace copied from screen (aarrgh!! ;-)) : bt EBP EIP Function(args) 0xc040a240 0xc020ca4 __make_request+0xa4 (0xc040a240, 0x0, 0xca02d00, 0x0, 0x100000) kernel .text 0xc0100000 oxc020fc00 0xc02103ca generic_make_request+0x10a (0x0, 0xca02da80) kernel .text 0xc0100000 oxc02102c0 0xc02103e0 0xc0210435 submit_bh+0x55 (0x0, 0xca02da80, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc02103e0 0xc0210450 0xc017e225 __pb_block_prepare_write_async+0x205 (0xcb553c00, 0xc130efbc, 0x100, 0x200, 0x1) kernel .text 0xc0100000 0xc017e20 0xc017e260 0xc017ea82 page_buf_generic_file_write+0x262 (0xcbeb1c60, 0xbfffdb30, 0x180, 0xcbc1bf58, 0xc01e8cc0) kernel .text 0xc0100000 0xc017e7d0 0xc017ec10 0xc01e9faf xfs_write+0x39f (0xcb552b50, 0xcbc1bf4c, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc01e9c10 0xc01ea2a0 0xc01e565c linvfs_write+0xfc (0xcbeb1c60, 0xbfffdb30, 0x180, 0xcbeb1c80, 0x0) kernel .text 0xc0100000 0xc01e5a60 0xc01e5ba0 0xc0135826 sys_write+0x96 (0x3, 0xbfffdb30, 0x180, 0x2c100, 0x0) kernel .text 0xc0100000 0xc0135790 0xc0135860 0xc010be3b system_call+0x33 kernel .text 0xc0100000 0xc0106e08 0xc0106e40 (Double checked it... should get that serial console done.) From owner-linux-xfs@oss.sgi.com Mon Jun 18 19:30:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J2Udn07971 for linux-xfs-outgoing; Mon, 18 Jun 2001 19:30:39 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J2UcV07968 for ; Mon, 18 Jun 2001 19:30:38 -0700 Received: from [192.168.1.10] (helo=den2) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15CBHp-0005d8-00; Tue, 19 Jun 2001 14:30:37 +1200 From: "Juha Saarinen" To: "'Steve Lord'" Cc: "'XFS Mailing List'" Subject: RE: Oops removing files on a full f/s Date: Tue, 19 Jun 2001 14:30:29 +1200 Message-ID: <017a01c0f867$ce2958b0$0a01a8c0@den2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <200106190149.f5J1nLo32245@jen.americas.sgi.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk :: Yes, a backtrace from this would be really useful, also, in :: the backtrace :: you will see the arguments of the functions, if you could :: take the third :: argument of __make_request and pass it to the md command in kdb: :: :: kdb> md
:: :: and send the output of that too - it will dump the buffer contents :: which may help. So, if we have: 0xc040a240 0xc020ca4 __make_request+0xa4 (0xc040a240, 0x0, 0xca02d00, 0x0, 0x100000) I would do: kdb> md 0xca02d00 ? -- Juha From owner-linux-xfs@oss.sgi.com Mon Jun 18 19:54:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J2sSd08206 for linux-xfs-outgoing; Mon, 18 Jun 2001 19:54:28 -0700 Received: from mercury.pricegrabber.com ([64.70.41.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J2sRV08203 for ; Mon, 18 Jun 2001 19:54:27 -0700 Received: from pricegrabber.com (noc.pricegrabber.com [24.8.138.101] (may be forged)) (authenticated) by mercury.pricegrabber.com (8.11.2/8.11.2) with ESMTP id f5J2sSn08113 for ; Mon, 18 Jun 2001 19:54:28 -0700 Message-ID: <3B2EBEE2.5080003@pricegrabber.com> Date: Mon, 18 Jun 2001 19:54:26 -0700 From: Christopher McCrory Organization: PriceGrabber.com User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-0.2.9smp i686; en-US; rv:0.9.1+) Gecko/20010606 X-Accept-Language: en-us MIME-Version: 1.0 To: "'XFS Mailing List'" Subject: Re: Oops removing files on a full f/s References: <200106190149.f5J1nLo32245@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello... I just kind of picked a message from this thread at random to reply to. I just filled up a xfs filesystem to 100%, then deleted the large files I was copying in. No oops using updated sgi rpm kernel [chrismcc@dev chrismcc]$ cat /proc/version Linux version 2.4.5-0.2.9_SGI_XFS_20010613 (root@exclaim) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Thu Jun 14 00:51:24 CDT 2001 Steve Lord wrote: > Yes, a backtrace from this would be really useful, also, in the backtrace >>fsstress filled up /usr 100% so I was going remove the p* directories >>and files. This provoked an oops: >> >>-- Juha >> > -- Christopher McCrory "The guy that keeps the servers running" chrismcc@pricegrabber.com http://www.pricegrabber.com I don't make jokes in base 13. Anyone who does should get help. --Douglas Adams From owner-linux-xfs@oss.sgi.com Mon Jun 18 20:01:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J31t408371 for linux-xfs-outgoing; Mon, 18 Jun 2001 20:01:55 -0700 Received: from web14801.mail.yahoo.com (web14801.mail.yahoo.com [216.136.224.217]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J31sV08368 for ; Mon, 18 Jun 2001 20:01:54 -0700 Message-ID: <20010619030152.96804.qmail@web14801.mail.yahoo.com> Received: from [209.191.60.251] by web14801.mail.yahoo.com; Mon, 18 Jun 2001 20:01:52 PDT Date: Mon, 18 Jun 2001 20:01:52 -0700 (PDT) From: ron mckelvey Subject: 3ware and AMI raids To: linux-xfs@oss.sgi.com In-Reply-To: <3B2DE89C.DEF5D5B7@pasteur.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've been playing with XFS for a little while, been running it at home on my dually box (833hz p3's), with the 8 channel 3ware 6800 card. The performance is amazing. I'm booting off an adaptec 2940uw and IBM scsi drive (couldn't make my tape drive work with booting off the 3ware card) and using the 3ware as 8 x 60gig, = 220gig raid 10. I put XFS on the 220gig partition and it's been sweet. Haven't had any problems yet.... At the office I took my ftp server, dually P3's, 1ghz,514m, and AMI 1600 enterprise controller. The first channel is 7x36gig drives on a RAID 5, booting off ext2 with a 200gig (/u) XFS partition. Channels 2+3 are external cabinets with 7x36 drives also. Both are just one big XFS partition. On this box I move alot of data around, and I hope to give XFS a good testing. (before attempting to use it with Oracle) It's only been up and running a short time, I just recently rebuilt the box with RH 7.1, using XFS patch 2.4.2. (The 3ware box is same build) I'm about to switch the main mp3 server over to XFS also, 3ware 8x80gig's=300gig raid 10.. I've crashed the boxes on numerous occasions and have yet to do anything other then boot them up.... thanks ronzo __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-linux-xfs@oss.sgi.com Mon Jun 18 20:06:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J36Me08484 for linux-xfs-outgoing; Mon, 18 Jun 2001 20:06:22 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J36KV08481 for ; Mon, 18 Jun 2001 20:06:21 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id UAA03626 for ; Mon, 18 Jun 2001 20:06:19 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) 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 NAA12293; Tue, 19 Jun 2001 13:05:01 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Dean Roehrich cc: linux-xfs@oss.sgi.com Subject: Re: XFS module problems -- usage count incorrect In-reply-to: Your message of "Mon, 18 Jun 2001 10:19:19 EST." <200106181519.KAA76096@slobber.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Jun 2001 13:05:01 +1000 Message-ID: <13982.992919901@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 18 Jun 2001 10:19:19 -0500, Dean Roehrich wrote: > >>From: Keith Owens > >>init_xfs_fs() calls dmapi_init() which does MOD_INC_USE_COUNT. Compile >>XFS without DMAPI support and your problem will disappear. >> >>The module related code in dmapi is a hangover from a time when dmapi >>was a module in its own right instead of being linked into xfs.o. I >>will remove module related code from dmapi, I will also review grio, to >>make sure it does not have the same problem. > >No, it's not a hangover. It was put there last week to keep the reference >count up. If you've been using DMAPI then you cannot allow the module to be >unloaded unless DMAPI says it's okay. DMAPI won't say it's okay unless it's >clear that no HSMs are using it (whether or not any XFS filesystems are >mounted, an HSM could still be there, watching the DMAPI queues, waiting for >one to be mounted.) > >DMAPI needs a way to say that the XFS module is busy--I thought >MOD_INC_USE_COUNT was the proper method. If dm_uninit() is giving false >positives then that's another issue entirely. dmapi needs to bump the module use count when it provides services to another piece of code, not at init time. MOD_INC_USE_COUNT is the correct method but dmapi_init is the wrong place. Find a point where dmapi starts providing services and put MOD_INC_USE_COUNT there, probably dmapi_open. Same for MOD_DEC_USE_COUNT. From owner-linux-xfs@oss.sgi.com Mon Jun 18 20:07:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J37pw08586 for linux-xfs-outgoing; Mon, 18 Jun 2001 20:07:51 -0700 Received: from web14803.mail.yahoo.com (web14803.mail.yahoo.com [216.136.224.219]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J37oV08583 for ; Mon, 18 Jun 2001 20:07:50 -0700 Message-ID: <20010619030750.88245.qmail@web14803.mail.yahoo.com> Received: from [209.191.60.251] by web14803.mail.yahoo.com; Mon, 18 Jun 2001 20:07:50 PDT Date: Mon, 18 Jun 2001 20:07:50 -0700 (PDT) From: ron mckelvey Subject: Re: db servers To: linux-xfs@oss.sgi.com In-Reply-To: <3B2E93B2.2353BC4E@idcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello.. We use Oracle and run Oracle Applications, we're planning on moving to Linux, and I'm hoping that XFS will perform OK under Oracle on top of Raid... I'm getting ready to install XFS on one of our test systems, then I'll be able to compare it to our other boxes just running ext2.. so I'll be posting some future comments on this... (I also use mysql alot, and if things continue going well, I'm swithing the web server, with mysql to XFS) As far as raw i/o, the filesystem layer is not even used. The DB reads/writes directly to the drives, no filesystem required. ronzo --- "D. Stimits" wrote: > I am curious about something. A lot of people are > locally talking about > different db's and their performance, along with > reasons why they can > migrate to Linux db's when most of their co-workers > are MS-centric. Have > any of the people here done any kind of benchmarks > or other tests for db > performance of IBM's db2, Oracle, PostgreSQL, so on? > I'm curious how > these various db's work with XFS, especially the > ones that want raw > access. > > D. Stimits, stimits@idcomm.com __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-linux-xfs@oss.sgi.com Mon Jun 18 20:15:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J3F2S08717 for linux-xfs-outgoing; Mon, 18 Jun 2001 20:15:02 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J3F1V08714 for ; Mon, 18 Jun 2001 20:15:01 -0700 Received: from [192.168.1.10] (helo=den2) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15CBym-0005g0-00; Tue, 19 Jun 2001 15:15:00 +1200 From: "Juha Saarinen" To: "'Steve Lord'" Cc: "'XFS Mailing List'" Subject: RE: Oops removing files on a full f/s Date: Tue, 19 Jun 2001 15:14:52 +1200 Message-ID: <020a01c0f86e$018be410$0a01a8c0@den2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <200106190315.f5J3FuS32642@jen.americas.sgi.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk :: Yes, that would do it, There isn't anyway to save the output from kdb to disk, is there? From owner-linux-xfs@oss.sgi.com Mon Jun 18 20:15:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J3Fe608746 for linux-xfs-outgoing; Mon, 18 Jun 2001 20:15:40 -0700 Received: from deliverator.sgi.com ([204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J3FdV08743 for ; Mon, 18 Jun 2001 20:15:39 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA09042 for ; Mon, 18 Jun 2001 20:14:42 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id WAA2197261; Mon, 18 Jun 2001 22:13:29 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA48801; Mon, 18 Jun 2001 22:13:29 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5J3FuS32642; Mon, 18 Jun 2001 22:15:56 -0500 Message-Id: <200106190315.f5J3FuS32642@jen.americas.sgi.com> To: "Juha Saarinen" cc: "'Steve Lord'" , "'XFS Mailing List'" Subject: Re: Oops removing files on a full f/s References: <017a01c0f867$ce2958b0$0a01a8c0@den2> Comments: In-reply-to "Juha Saarinen" message dated "Tue, 19 Jun 2001 14:30:29 +1200." Date: Mon, 18 Jun 2001 22:15:56 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > :: Yes, a backtrace from this would be really useful, also, in > :: the backtrace > :: you will see the arguments of the functions, if you could > :: take the third > :: argument of __make_request and pass it to the md command in kdb: > :: > :: kdb> md
> :: > :: and send the output of that too - it will dump the buffer contents > :: which may help. > > So, if we have: > > 0xc040a240 0xc020ca4 __make_request+0xa4 (0xc040a240, 0x0, 0xca02d00, > 0x0, 0x100000) > > I would do: > > kdb> md 0xca02d00 > > ? Yes, that would do it, Steve > > -- Juha From owner-linux-xfs@oss.sgi.com Mon Jun 18 20:17:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J3Ha008910 for linux-xfs-outgoing; Mon, 18 Jun 2001 20:17:36 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J3HZV08907 for ; Mon, 18 Jun 2001 20:17:35 -0700 Received: from [192.168.1.10] (helo=den2) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15CC1F-0005gC-00; Tue, 19 Jun 2001 15:17:33 +1200 From: "Juha Saarinen" To: "'Steve Lord'" Cc: "'XFS Mailing List'" Subject: RE: Oops removing files on a full f/s Date: Tue, 19 Jun 2001 15:17:25 +1200 Message-ID: <020b01c0f86e$5d0d2f10$0a01a8c0@den2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <200106190315.f5J3FuS32642@jen.americas.sgi.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk :: > kdb> md 0xca02d00 :: > :: > ? :: :: Yes, that would do it, I get a: Bad User Address: 0xca02d00 message when I try that. From owner-linux-xfs@oss.sgi.com Mon Jun 18 20:20:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J3KxC09012 for linux-xfs-outgoing; Mon, 18 Jun 2001 20:20:59 -0700 Received: from mercury.pricegrabber.com ([64.70.41.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J3KwV09009 for ; Mon, 18 Jun 2001 20:20:58 -0700 Received: from pricegrabber.com (noc.pricegrabber.com [24.8.138.101] (may be forged)) (authenticated) by mercury.pricegrabber.com (8.11.2/8.11.2) with ESMTP id f5J3Kun08602; Mon, 18 Jun 2001 20:20:56 -0700 Message-ID: <3B2EC517.1080508@pricegrabber.com> Date: Mon, 18 Jun 2001 20:20:55 -0700 From: Christopher McCrory Organization: PriceGrabber.com User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-0.2.9smp i686; en-US; rv:0.9.1+) Gecko/20010606 X-Accept-Language: en-us MIME-Version: 1.0 To: Alan Eldridge CC: "'XFS Mailing List'" Subject: Re: Oops removing files on a full f/s References: <200106190149.f5J1nLo32245@jen.americas.sgi.com> <3B2EBEE2.5080003@pricegrabber.com> <200106190259.f5J2xIN19258@wwweasel.geeksrus.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello... Alan Eldridge wrote: > On Monday 18 June 2001 10:54 pm, you wrote: > >>Hello... >> >> I just kind of picked a message from this thread at random to reply to. >> >> I just filled up a xfs filesystem to 100%, then deleted the large files I >>was copying in. No oops using updated sgi rpm kernel >> >>[chrismcc@dev chrismcc]$ cat /proc/version >>Linux version 2.4.5-0.2.9_SGI_XFS_20010613 (root@exclaim) (gcc version >>egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Thu Jun 14 00:51:24 >>CDT 2001 >> > > Chris, what CPU build are you using? 3,5, or 686? I had my only lockup (of > unknown cause [opengl screensaver running: can't see an oops and it *could* > have been glide] running i686. > Single P3 550 1 gig ram No X or gdm running. This is strictly a development server so it is lightly loaded. [chrismcc@dev chrismcc]$ cat /proc/cpuinfo | head processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping : 3 cpu MHz : 547.579 cache size : 512 KB [chrismcc@dev chrismcc]$ free total used free shared buffers cached Mem: 1028384 406612 621772 64 100364 165800 -/+ buffers/cache: 140448 887936 Swap: 528024 0 528024 -- Christopher McCrory "The guy that keeps the servers running" chrismcc@pricegrabber.com http://www.pricegrabber.com I don't make jokes in base 13. Anyone who does should get help. --Douglas Adams From owner-linux-xfs@oss.sgi.com Mon Jun 18 20:34:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J3YO609288 for linux-xfs-outgoing; Mon, 18 Jun 2001 20:34:24 -0700 Received: from fep21-svc.tin.it (mta21-acc.tin.it [212.216.176.74]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J3YNV09285 for ; Mon, 18 Jun 2001 20:34:23 -0700 Received: from localhost.localdomain ([212.171.41.36]) by fep21-svc.tin.it (InterMail vM.4.01.03.13 201-229-121-113) with SMTP id <20010619033417.PHCT7382.fep21-svc.tin.it@localhost.localdomain> for ; Tue, 19 Jun 2001 05:34:17 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Giuseppe Zompatori To: linux-xfs@oss.sgi.com Subject: GCC 3.0 Date: Tue, 19 Jun 2001 05:43:27 -0400 X-Mailer: KMail [version 1.2] References: <20010619030750.88245.qmail@web14803.mail.yahoo.com> In-Reply-To: <20010619030750.88245.qmail@web14803.mail.yahoo.com> MIME-Version: 1.0 Message-Id: <01061905432702.09592@localhost.localdomain> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Good News :) http://gcc.gnu.org/gcc-3.0/gcc-3.0.html Giuseppe From owner-linux-xfs@oss.sgi.com Mon Jun 18 20:37:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J3b3Z09461 for linux-xfs-outgoing; Mon, 18 Jun 2001 20:37:03 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J3b2V09458 for ; Mon, 18 Jun 2001 20:37:03 -0700 Received: from [192.168.1.10] (helo=den2) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15CCK4-0005ha-00; Tue, 19 Jun 2001 15:37:00 +1200 From: "Juha Saarinen" To: "'Giuseppe Zompatori'" , Subject: RE: GCC 3.0 Date: Tue, 19 Jun 2001 15:36:51 +1200 Message-ID: <020d01c0f871$141afdc0$0a01a8c0@den2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <01061905432702.09592@localhost.localdomain> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk :: Good News :) :: :: http://gcc.gnu.org/gcc-3.0/gcc-3.0.html Oh no... yet another gcc version to worry about. From owner-linux-xfs@oss.sgi.com Mon Jun 18 20:41:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J3fHT09567 for linux-xfs-outgoing; Mon, 18 Jun 2001 20:41:17 -0700 Received: from deliverator.sgi.com ([204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J3fGV09564 for ; Mon, 18 Jun 2001 20:41:16 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA10941 for ; Mon, 18 Jun 2001 20:40:18 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) 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 NAA12451; Tue, 19 Jun 2001 13:39:03 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Juha Saarinen" cc: "'Steve Lord'" , "'XFS Mailing List'" Subject: Re: Oops removing files on a full f/s In-reply-to: Your message of "Tue, 19 Jun 2001 15:17:25 +1200." <020b01c0f86e$5d0d2f10$0a01a8c0@den2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Jun 2001 13:39:03 +1000 Message-ID: <14728.992921943@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 19 Jun 2001 15:17:25 +1200, "Juha Saarinen" wrote: >:: > kdb> md 0xca02d00 >I get a: > >Bad User Address: 0xca02d00 >message when I try that. The address is not in kernel space. Either you mis{copied,typed} it or it really was wrong. In the latter case it would cause the oops. >There isn't anyway to save the output from kdb to disk, is there? At the kdb prompt, set LOGGING=1. The kdb output is stored in the syslog buffer as well as written to screen, when you type go the syslog data is written to disk. Two problems, the syslog buffer is limited in size and this only works if the kernel can continue and do disk I/O after the oops. From owner-linux-xfs@oss.sgi.com Mon Jun 18 20:54:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J3sHv09726 for linux-xfs-outgoing; Mon, 18 Jun 2001 20:54:17 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J3sGV09723 for ; Mon, 18 Jun 2001 20:54:16 -0700 Received: from relay1.corp.sgi.com (corp.sgi.com [198.29.75.13]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA08955 for ; Mon, 18 Jun 2001 20:54:15 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (gibble.americas.sgi.com [128.162.195.80]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id UAA17410 for ; Mon, 18 Jun 2001 20:53:43 -0700 (PDT) Message-ID: <3B2ECC33.9514CDB5@sgi.com> Date: Mon, 18 Jun 2001 22:51:15 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS 1.0.1 testing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all - I've made available pre-release testing code for XFS 1.0.1. This code reflects the state of the devel tree just before Steve's 2.4.6-pre1 merge; there may be a few more XFS-related mods merged in prior to the actual release. Available at: ftp://oss.sgi.com/projects/xfs/download/testing/Release-1.0.1/ The kernel code is available various ways: o Red Hat 7.1 / 2.4.2 RPMS for those who want to stay close to what Red Hat ships o Vanilla 2.4.5 kernel RPMs with the same XFS code as above o patches against vanilla 2.4.5 The RPMs pass the "does it boot" test, and also pass the XFS test scripts, but they have not been extensively tested yet. Note that the patches are currently broken up into about 6 files, these will be collapsed into fewer patches before the actual 1.0.1 release. The userspace commands are available as both tarballs and RPMs. Please read the READMEs for more information, especially for patch instructions. A modified RH 7.1 installer will follow, hopefully soon. This will solve some of the RAID installation issues people saw with v1.0. If any of the Mandrake/SuSE/Debian people on the list want to package kernels for those distros, let me know, and I'll keep you up to date on the status of the patches so we can put out unsupported/unofficial kernel packages for them as well. Have fun, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Jun 18 21:01:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J41Qw09869 for linux-xfs-outgoing; Mon, 18 Jun 2001 21:01:26 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J41OV09866 for ; Mon, 18 Jun 2001 21:01:25 -0700 Received: from [192.168.1.10] (helo=den2) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15CCgi-0005i9-00; Tue, 19 Jun 2001 16:00:24 +1200 From: "Juha Saarinen" To: "'Keith Owens'" Cc: "'Steve Lord'" , "'XFS Mailing List'" Subject: RE: Oops removing files on a full f/s Date: Tue, 19 Jun 2001 16:00:15 +1200 Message-ID: <022601c0f874$58e807b0$0a01a8c0@den2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <14728.992921943@kao2.melbourne.sgi.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk :: The address is not in kernel space. Either you :: mis{copied,typed} it or :: it really was wrong. In the latter case it would cause the oops. Bugger. 0s look very like 8s with ATI VGA... ;-). OK, here we are: md 0xca02da80 0xca02da80 00000000 00000000 00001000 00000307 0xca02da90 00000000 00000307 0000000c 00001ee8 0xca02daa0 ca0dec20 ca521980 ca02da80 00000000 0xca02dab0 00000000 cb836000 c130efbc c017d9d0 0xca02dac0 cbd86be0 00000000 00000001 ca02dacc 0xca02dad0 ca02dacc 00000000 cb269838 cb553c18 0xca02dae0 00000000 00008e53 00001000 00000308 0xca02daf0 00000000 00000308 00000019 00000000 Make sense? :: At the kdb prompt, set LOGGING=1. The kdb output is stored in the :: syslog buffer as well as written to screen, when you type go :: the syslog :: data is written to disk. Two problems, the syslog buffer is :: limited in :: size and this only works if the kernel can continue and do disk I/O :: after the oops. OK, worth a try. From owner-linux-xfs@oss.sgi.com Mon Jun 18 22:07:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J57T310494 for linux-xfs-outgoing; Mon, 18 Jun 2001 22:07:29 -0700 Received: from dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J57SV10491 for ; Mon, 18 Jun 2001 22:07:28 -0700 Received: (from ak@localhost) by dkp.com (8.9.3/8.9.3) id BAA18487 for linux-xfs@oss.sgi.com; Tue, 19 Jun 2001 01:07:25 -0400 Date: Tue, 19 Jun 2001 01:07:25 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: RedHat Rawhide + XFS rpm available for testing. Message-ID: <20010619010725.B16601@key.dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3B299D51.85A6B204@thebarn.com> <20010618210211.H2209@key.dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010618210211.H2209@key.dkp.com>; from ak@dkp.com on Mon, Jun 18, 2001 at 09:02:11PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Jun 18, 2001 at 09:02:11PM -0400, Andrew Klaassen wrote: > Anybody know if these errors ("DriveReady SeekComplete Error", > "DriveStatusError BadCRC") are serious? Apologies for the noise. I should have spent five minutes looking on Google for this *before* I posted it to this mailing list. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Mon Jun 18 22:58:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J5w7u10844 for linux-xfs-outgoing; Mon, 18 Jun 2001 22:58:07 -0700 Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J5w5V10841 for ; Mon, 18 Jun 2001 22:58:06 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f5J5ux807429; Tue, 19 Jun 2001 00:57:00 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <3B2EE9A9.B1C4DBCC@thebarn.com> Date: Tue, 19 Jun 2001 00:56:58 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Juha Saarinen CC: "'Keith Owens'" , "'Steve Lord'" , "'XFS Mailing List'" Subject: Re: Oops removing files on a full f/s References: <022601c0f874$58e807b0$0a01a8c0@den2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juha Saarinen wrote: > :: The address is not in kernel space. Either you > :: mis{copied,typed} it or > :: it really was wrong. In the latter case it would cause the oops. > > Bugger. 0s look very like 8s with ATI VGA... ;-). OK, here we are: > > md 0xca02da80 > > 0xca02da80 00000000 00000000 00001000 00000307 > 0xca02da90 00000000 00000307 0000000c 00001ee8 > 0xca02daa0 ca0dec20 ca521980 ca02da80 00000000 > 0xca02dab0 00000000 cb836000 c130efbc c017d9d0 > 0xca02dac0 cbd86be0 00000000 00000001 ca02dacc > 0xca02dad0 ca02dacc 00000000 cb269838 cb553c18 > 0xca02dae0 00000000 00008e53 00001000 00000308 > 0xca02daf0 00000000 00000308 00000019 00000000 > > Make sense? Well yup that's a buffer head size 4k device (3,7) but it may be helpful to find out what make_request was doing with that buffer head when it crashed. take this script (odump) run it with the line odump kernel .text 0xc0100000 oxc020fc00 0xc02103ca (the like right after __make_request in the kdb backtrace) This should give you the disassembly of __make_request if you have the kernel built with -g3 the source lines will be intermixed with the assembly. #!/bin/sh set -x if [ $1 = "kernel" ]; then objdump -S -j $2 \ --start-address=$4 \ --stop-address=$5 \ linux/vmlinux else objdump -S -j $2 \ --adjust-vma=$3 \ --start-address=$4 \ --stop-address=$5 \ linux/modules/$1.o fi -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Mon Jun 18 23:33:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J6XVh11294 for linux-xfs-outgoing; Mon, 18 Jun 2001 23:33:31 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J6XQV11291 for ; Mon, 18 Jun 2001 23:33:27 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA27889; Tue, 19 Jun 2001 08:33:24 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA00842; Tue, 19 Jun 2001 08:33:23 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 890CE57306; Tue, 19 Jun 2001 08:42:36 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id C367E25835; Tue, 19 Jun 2001 08:50:56 +0200 (CEST) Message-ID: <3B2EF30D.2765AA76@ch.sauter-bc.com> Date: Tue, 19 Jun 2001 08:37:01 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Andrew Klaassen Cc: linux-xfs@oss.sgi.com Subject: Re: RedHat Rawhide + XFS rpm available for testing. References: <3B299D51.85A6B204@thebarn.com> <20010618210211.H2209@key.dkp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I guess that the reason for the messages is that the kernel tries to drive the disks too hard and they (or the controller) complain and the kernel then reduces the transfer mode or whatever to a lower level. Saw the similar with Promise Ultra100TX2 and SoftRAID5 on 4*60G IBM drive, when I put heavy load on the not yet synced RAID. Simon Andrew Klaassen schrieb: > > On Fri, Jun 15, 2001 at 12:29:53AM -0500, > Russell Cattelan wrote: > > > Ok after a few false starts I finally have a running > > > > RedHat rawhide kernel + XFS. > > > > The XFS patches are in sync with the devel tree. > > > > All the rpms can be gotten at: > > > > ftp://oss.sgi.com/projects/xfs/download/testing/RHrawhide/ > > > > These have not been tested extensively so use at your own > > risk. > > Using these rpms, I saw this on bootup: > > md: syncing RAID array md1 > md: minimum _guaranteed_ reconstruction speed: 100 KB/sec/disc. > md: using maximum available idle IO bandwith (but not more than 100000 KB/sec) for reconstruction. > md: using 508k window, over a total of 74280960 blocks. > ide/host0/bus1/target0/lun0/part3 [events: 00000014](write) ide/host0/bus1/target0/lun0/part3's sb offset: 74280960 > ide/host2/bus0/target0/lun0/part3 [events: 00000014](write) ide/host2/bus0/target0/lun0/part3's sb offset: 74280960 > hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } > hda: dma_intr: error=0x84 { DriveStatusError BadCRC } > hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } > hda: dma_intr: error=0x84 { DriveStatusError BadCRC } > hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } > hda: dma_intr: error=0x84 { DriveStatusError BadCRC } > hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } > hda: dma_intr: error=0x84 { DriveStatusError BadCRC } > ide/host2/bus0/target1/lun0/part3 [events: 00000014](write) ide/host2/bus0/target1/lun0/part3's sb offset: 74280960 > ide/host2/bus1/target0/lun0/part3 [events: 00000014](write) ide/host2/bus1/target0/lun0/part3's sb offset: 74280960 > ide/host2/bus1/target1/lun0/part3 [events: 00000014](write) ide/host2/bus1/target1/lun0/part3's sb offset: 74280960 > . > ... autorun DONE. > VFS: Mounted root (ext2 filesystem) readonly. > (etc.) > > This is with a CMD648 (rev. 1) controller on an ASUS CUBX (rev > D) board. > > Anybody know if these errors ("DriveReady SeekComplete Error", > "DriveStatusError BadCRC") are serious? They only occur on > bootup, and they occur consistently at this point during bootup. > They have occured identically and consistently on two separate > machines, with two different drive sets and two different BIOS > revisions in them. They do not occur with the kernel-2.4.2-2 > provided with RH7.1. > > And if they are serious, who should I inform about them? > > Andrew Klaassen -- 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 Mon Jun 18 23:43:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J6hYi11490 for linux-xfs-outgoing; Mon, 18 Jun 2001 23:43:34 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J6hXV11487 for ; Mon, 18 Jun 2001 23:43:33 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5J6hQf02548 for linux-xfs@oss.sgi.com; Tue, 19 Jun 2001 02:43:26 -0400 Date: Tue, 19 Jun 2001 02:43:26 -0400 From: Alan Eldridge To: linux-xfs@oss.sgi.com Subject: sensor modules in rpms? Message-ID: <20010619024326.A2545@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric, A whole slew of the i2c-* modules is missing from the 2.4.5 RPMs you just announced. What's the story on those (I have a VIAPro chipset, so I need i2c-viapro to monitor the temp/fans)... is it just a rebuild with some options changed, or worse? And yes, the VIAPro has worked 100% reliably for me (I've been using MBs with VIA chips for several years now). -- Alan Eldridge From owner-linux-xfs@oss.sgi.com Tue Jun 19 00:01:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J71eA11759 for linux-xfs-outgoing; Tue, 19 Jun 2001 00:01:40 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J71dV11756 for ; Tue, 19 Jun 2001 00:01:39 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5J71SV18876; Tue, 19 Jun 2001 09:01:28 +0200 Message-Id: <4.3.2.7.2.20010619085055.037b8a18@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Jun 2001 09:01:23 +0200 To: "Juha Saarinen" , "'Giuseppe Zompatori'" , From: Seth Mos Subject: RE: GCC 3.0 In-Reply-To: <020d01c0f871$141afdc0$0a01a8c0@den2> References: <01061905432702.09592@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:36 19-6-2001 +1200, Juha Saarinen wrote: >:: Good News :) >:: >:: http://gcc.gnu.org/gcc-3.0/gcc-3.0.html > >Oh no... yet another gcc version to worry about. Not this is a official release version. If we can just decide to drop 2.96 we can stick with the following ;-) gcc 2.91.66 (egcs) gcc 2.95.{234} gcc 3.0.{01} Number 1 is tested and known too compile decent kernels Number 2 (2.95.3) and higher als seem to produce working kernels but is lest tested, except for the SuSE or debian folks Number 3 is untested but it compiles and boots but that is about it. 2.96 has been a weird product that could have been avoided, but we can't turn it back. Let's try to make RedHat ship a gcc 3 rpm and we can continue developing software using a officially released version ;) Bye -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Jun 19 00:12:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J7CHr11941 for linux-xfs-outgoing; Tue, 19 Jun 2001 00:12:17 -0700 Received: from dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J7CGV11933 for ; Tue, 19 Jun 2001 00:12:16 -0700 Received: (from ak@localhost) by dkp.com (8.9.3/8.9.3) id DAA20238 for linux-xfs@oss.sgi.com; Tue, 19 Jun 2001 03:12:15 -0400 Date: Tue, 19 Jun 2001 03:12:15 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: RedHat Rawhide + XFS rpm available for testing. Message-ID: <20010619031215.C16601@key.dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3B299D51.85A6B204@thebarn.com> <20010618210211.H2209@key.dkp.com> <3B2EF30D.2765AA76@ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3B2EF30D.2765AA76@ch.sauter-bc.com>; from simon.matter@ch.sauter-bc.com on Tue, Jun 19, 2001 at 08:37:01AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jun 19, 2001 at 08:37:01AM +0200, Simon Matter wrote: > Andrew Klaassen schrieb: > > hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } > > hda: dma_intr: error=0x84 { DriveStatusError BadCRC } > I guess that the reason for the messages is that the kernel > tries to drive the disks too hard and they (or the controller) > complain and the kernel then reduces the transfer mode or > whatever to a lower level. Saw the similar with Promise > Ultra100TX2 and SoftRAID5 on 4*60G IBM drive, when I put heavy > load on the not yet synced RAID. Actually, there's a very, very good chance that in this case it was a cabling issue. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Tue Jun 19 01:47:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J8lu313144 for linux-xfs-outgoing; Tue, 19 Jun 2001 01:47:56 -0700 Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J8luV13141 for ; Tue, 19 Jun 2001 01:47:56 -0700 Received: from heppcl.ph.qmw.ac.uk ([138.37.50.187]) by zeta.qmw.ac.uk with esmtp (Exim 3.16 #1) id 15CHAw-0002yf-00 for linux-xfs@oss.sgi.com; Tue, 19 Jun 2001 09:47:54 +0100 Received: from heppct.ph.qmw.ac.uk (heppct.ph.qmw.ac.uk [138.37.50.246]) by heppcl.ph.qmw.ac.uk (8.9.3/8.9.3) with ESMTP id JAA20085 for ; Tue, 19 Jun 2001 09:47:54 +0100 Received: from localhost (pd@localhost) by heppct.ph.qmw.ac.uk (8.11.2/8.9.3) with ESMTP id f5J8lsf28659 for ; Tue, 19 Jun 2001 09:47:54 +0100 X-Authentication-Warning: heppct.ph.qmw.ac.uk: pd owned process doing -bs Date: Tue, 19 Jun 2001 09:47:54 +0100 (BST) From: "P.Dixon" To: Subject: Re: kernel panic with Rawhide RPM In-Reply-To: <200106181625.f5IGPAO32163@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Also, is this something you have successfully done before with other > xfs kernels? > rsync -rulHpogtS --delete --force /export/users/ root@hepserv2:/export/users/ with kernel-smp-2.4.2-SGI_XFS_1.0 installed on our backup server worked without any problems. Or main server is running kernel-smp-2.4.2-SGI_XFS_1.0 with the quota patch applied. Paul From owner-linux-xfs@oss.sgi.com Tue Jun 19 02:18:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5J9I4I13656 for linux-xfs-outgoing; Tue, 19 Jun 2001 02:18:04 -0700 Received: from dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5J9I2V13653 for ; Tue, 19 Jun 2001 02:18:02 -0700 Received: (from ak@localhost) by dkp.com (8.9.3/8.9.3) id FAA22202 for linux-xfs@oss.sgi.com; Tue, 19 Jun 2001 05:17:56 -0400 Date: Tue, 19 Jun 2001 05:17:56 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: kernel panic with Rawhide RPM Message-ID: <20010619051756.G16601@key.dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3B2DE89C.DEF5D5B7@pasteur.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from P.Dixon@qmw.ac.uk on Mon, Jun 18, 2001 at 05:10:58PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Jun 18, 2001 at 05:10:58PM +0100, P.Dixon wrote: > I just had a kernel panic on our backup server while rsyncing > a file system from our main server: > > Kernel Panic: Kmem_zone_Zalloc: NULL memory on KM_SLEEP request! > > Nothing else appears im the log files. > > I was using kernel-smp-2.4.5-0.2.9_SGI_XFS_20010613 > > Dunno of this is xfs related, but I've posted FYI, just in > case. I just got the same error a few times in a row with the same kernel (2.4.5-0.2.9_SGI_XFS_20010613 - no smp in my case, though). I could trigger it fairly consistently by running a find command on the directory being created by a running mongo.pl. Someone mentioned possible memory issues: The box has 1Gig of RAM and 3Gig of swap, which were, I'm quite sure, not even close to being filled. Oddly - it seemed odd to me, anyway - the machine kept right on running; I believe that the find and mongo.pl commands hung ("uninterruptable sleep" according to the ps man page), but everything else seemed to move along as usual. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Tue Jun 19 03:11:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JABs314636 for linux-xfs-outgoing; Tue, 19 Jun 2001 03:11:54 -0700 Received: from troll.dimensional.de (dimensional.komed.de [195.185.110.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JABqV14626 for ; Tue, 19 Jun 2001 03:11:52 -0700 Received: from skera.dimensional.de ([192.168.1.100] helo=skera ident=lukas) by troll.dimensional.de with smtp (Exim 3.12 #1 (Debian)) id 15CIQn-0004dA-00; Tue, 19 Jun 2001 12:08:21 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Christoph Lukas To: ivanr@melbourne.sgi.com (Ivan Rayner) Subject: Re: using xfsdump with 'file device' Date: Tue, 19 Jun 2001 12:18:27 +0200 X-Mailer: KMail [version 1.2] References: In-Reply-To: Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Message-Id: <01061912182701.00418@skera> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Ivan, thanks for your reply ! > I would think that 'dd if=/dev/null' will give you a 0 byte file .. what > happens with 'dd if=/dev/zero of=/mnt/testfile bs=1024 count=3145728' ? 'dd if=/dev/null of=../testfile' creates a testfile filled up with '0' bytes until you terminate dd. I ran: 'dd if=/dev/zero of=/mnt/ddfile bs=1024 count=3000000' and got: treya:~# ls -la /mnt/ddfile -rw-r--r-- 1 root root 3072000000 Jun 18 17:45 /mnt/ddfile which seems to indicate that >2GB support is working correctly. > > xfsdump: dumping non-directory files > > File size limit exceeded > > This message is not produced by xfsdump, but is the result of a failed > write (errno == 25). Who is producing this error message? A libc routine? The kernel? > By default xfsdump is compiled with -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE > which should be enough to make it work properly. I build the debian package running 'dpkg-buildpackage'. This creates a include/builddefs.in containing: CFLAGS += $(OPTIMIZER) $(DEBUG) -funsigned-char -Wall -Wno-parentheses \ $(LCFLAGS) $(CPPFLAGS) '-DVERSION="$(PKG_VERSION)"' \ -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DXFS_BIG_FILES=1 \ -DXFS_BIG_FILESYSTEMS=1 > If you still have problems, could you run xfsdump with '-v5' to get lots > of verbose output so we can get an idea of where exactly xfsdump fails. I did this and got the output appended. This all seems to me like the problem is outside xfsdump. But where?? Some additional info: kernel 2.4.3-xfs libc6 2.1.3 recompiled with kernel 2.4.3-xfs the two filesystems (source and destination) both are xfs filesystems on top of lvms. To exclude lvm as reason for this problem i tried the same on a system with xfs but without lvm which lead to the same result. Any ideas? Thanks in advance, christoph xfsdump: RLIMIT_AS org cur 0x7fffffffffffffff max 0x7fffffffffffffff xfsdump: RLIMIT_STACK org cur 0x800000 max 0x7fffffffffffffff xfsdump: raising stack size soft limit from 0x800000 to 0x2000000 xfsdump: RLIMIT_STACK new cur 0x2000000 max 0x7fffffffffffffff xfsdump: RLIMIT_DATA org cur 0x7fffffffffffffff max 0x7fffffffffffffff xfsdump: RLIMIT_FSIZE org cur 0x7fffffffffffffff max 0x7fffffffffffffff xfsdump: RLIMIT_FSIZE now cur 0x7fffffffffffffff max 0x7fffffffffffffff xfsdump: RLIMIT_CPU cur 0x7fffffffffffffff max 0x7fffffffffffffff xfsdump: RLIMIT_CPU now cur 0x7fffffffffffffff max 0x7fffffffffffffff xfsdump: INTGENMAX == 2147483647 (0x7fffffff) xfsdump: UINTGENMAX == 4294967295 (0xffffffff) xfsdump: OFF64MAX == 9223372036854775807 (0x7fffffffffffffff) xfsdump: OFFMAX == -1 (0x7fffffff) xfsdump: SIZEMAX == 4294967295 (0xffffffff) xfsdump: INOMAX == 4294967295 (0xffffffff) xfsdump: TIMEMAX == 2147483647 (0x7fffffff) xfsdump: SIZE64MAX == 18446744073709551615 (0xffffffffffffffff) xfsdump: INO64MAX == 18446744073709551615 (0xffffffffffffffff) xfsdump: UINT64MAX == 18446744073709551615 (0xffffffffffffffff) xfsdump: INT64MAX == 9223372036854775807 (0x7fffffffffffffff) xfsdump: UINT32MAX == 4294967295 (0xffffffff) xfsdump: INT32MAX == 2147483647 (0x7fffffff) xfsdump: INT16MAX == 32767 (0x7fff) xfsdump: UINT16MAX == 65535 (0xffff) xfsdump: getpagesize( ) returns 4096 xfsdump: parent pid is 15620 xfsdump: effective user id is 0 xfsdump: stack pid 15620: sz 0x2000000 min 0xbdfffba3 max 0xbffffba3 xfsdump: instantiating drive_simple xfsdump: version 3.0 - Running single-threaded xfsdump: WARNING: no session label specified xfsdump: fs /var/lib/zope/var uuid [83d2253a-ef1a-44d7-bfe3-c3e1184b3904] xfsdump: creating directory /var/xfsdump xfsdump: resume range stream 0 ino 0:0 to end xfsdump: WARNING: most recent level 0 dump was interrupted, but not resuming that dump since resume (-R) option not specified xfsdump: level 0 dump of treya:/var/lib/zope/var xfsdump: dump date: Tue Jun 19 11:13:36 2001 xfsdump: session id: 7ef2e95e-186d-4389-bf55-b2fbc620eb4f xfsdump: session label: "" xfsdump: ino map phase 1: skipping (no subtrees specified) xfsdump: ino map phase 2: constructing initial dump list xfsdump: bulkstat iteration initiated: start_ino == 0 xfsdump: calling bulkstat xfsdump: bulkstat returns buflen 900 ino 128 xfsdump: calling bulkstat xfsdump: bulkstat returns buflen 0 xfsdump: ino map phase 3: skipping (no pruning necessary) xfsdump: ino map phase 4: skipping (size estimated in phase 2) xfsdump: ino map phase 5: skipping (only one dump stream) xfsdump: bulkstat iteration initiated: start_ino == 0 xfsdump: calling bulkstat xfsdump: bulkstat returns buflen 900 ino 128 xfsdump: inomap_state backed up 0 times xfsdump: ino map construction complete xfsdump: estimated dump size: 45360801024 bytes xfsdump: Media op: begin media file xfsdump: drive_simple begin_read( ) xfsdump: drive_simple read( want 4096 ) xfsdump: WARNING: no media label specified xfsdump: drive_simple begin_write( ) [...] xfsdump: flushing write buf addr 0x400f7000 size 0x40000 xfsdump: drive_simple get_write_buf( want 14286848 ) xfsdump: read ino 8388778 offset 220587008 sz 262144 actual 262144 xfsdump: drive_simple write( offset 2145648640 (0x7fe40000 017771000000) size 262144 (0x40000 01000000) ) xfsdump: flushing write buf addr 0x400f7000 size 0x40000 xfsdump: drive_simple get_write_buf( want 14024704 ) xfsdump: read ino 8388778 offset 220849152 sz 262144 actual 262144 xfsdump: drive_simple write( offset 2145910784 (0x7fe80000 017772000000) size 262144 (0x40000 01000000) ) xfsdump: flushing write buf addr 0x400f7000 size 0x40000 xfsdump: drive_simple get_write_buf( want 13762560 ) xfsdump: read ino 8388778 offset 221111296 sz 262144 actual 262144 xfsdump: drive_simple write( offset 2146172928 (0x7fec0000 017773000000) size 262144 (0x40000 01000000) ) xfsdump: flushing write buf addr 0x400f7000 size 0x40000 xfsdump: drive_simple get_write_buf( want 13500416 ) xfsdump: read ino 8388778 offset 221373440 sz 262144 actual 262144 xfsdump: drive_simple write( offset 2146435072 (0x7ff00000 017774000000) size 262144 (0x40000 01000000) ) xfsdump: flushing write buf addr 0x400f7000 size 0x40000 xfsdump: drive_simple get_write_buf( want 13238272 ) xfsdump: read ino 8388778 offset 221635584 sz 262144 actual 262144 xfsdump: drive_simple write( offset 2146697216 (0x7ff40000 017775000000) size 262144 (0x40000 01000000) ) xfsdump: flushing write buf addr 0x400f7000 size 0x40000 xfsdump: drive_simple get_write_buf( want 12976128 ) xfsdump: read ino 8388778 offset 221897728 sz 262144 actual 262144 xfsdump: drive_simple write( offset 2146959360 (0x7ff80000 017776000000) size 262144 (0x40000 01000000) ) xfsdump: flushing write buf addr 0x400f7000 size 0x40000 xfsdump: drive_simple get_write_buf( want 12713984 ) xfsdump: read ino 8388778 offset 222159872 sz 262144 actual 262144 xfsdump: drive_simple write( offset 2147221504 (0x7ffc0000 017777000000) size 262144 (0x40000 01000000) ) xfsdump: flushing write buf addr 0x400f7000 size 0x40000 From owner-linux-xfs@oss.sgi.com Tue Jun 19 03:11:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JABrx14631 for linux-xfs-outgoing; Tue, 19 Jun 2001 03:11:53 -0700 Received: from troll.dimensional.de (dimensional.komed.de [195.185.110.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JABqV14625 for ; Tue, 19 Jun 2001 03:11:52 -0700 Received: from skera.dimensional.de ([192.168.1.100] helo=skera ident=lukas) by troll.dimensional.de with smtp (Exim 3.12 #1 (Debian)) id 15CIQh-0004d8-00; Tue, 19 Jun 2001 12:08:15 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Christoph Lukas To: Steve Lord Subject: Re: using xfsdump with 'file device' Date: Tue, 19 Jun 2001 12:18:20 +0200 X-Mailer: KMail [version 1.2] References: <200106181525.f5IFP1918677@jen.americas.sgi.com> In-Reply-To: <200106181525.f5IFP1918677@jen.americas.sgi.com> Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Message-Id: <0106181851340F.01455@skera> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve, thanks for your reply. > This is odd, I just created a 2621561952 byte dump file here. Where did you > get the xfsdump program from - an RPM we built, or did you compile it > yourself? We are running a debian system so I build the debian package changing to the source dir and running 'dpkg-buildpackage'. > There are current command rpms here: > > ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/ I will try to take these and convert them into .deb packages. Although I have come to the opinion that this problem is not a direct xfsdump problem. (see separate mail). christoph From owner-linux-xfs@oss.sgi.com Tue Jun 19 05:03:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JC32P16875 for linux-xfs-outgoing; Tue, 19 Jun 2001 05:03:02 -0700 Received: from web14607.mail.yahoo.com (web14607.mail.yahoo.com [216.136.224.87]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JC31V16872 for ; Tue, 19 Jun 2001 05:03:01 -0700 Message-ID: <20010619120301.47086.qmail@web14607.mail.yahoo.com> Received: from [203.197.98.2] by web14607.mail.yahoo.com; Tue, 19 Jun 2001 05:03:01 PDT Date: Tue, 19 Jun 2001 05:03:01 -0700 (PDT) From: Rajarshi Chakraborty Subject: documentation for xfs code To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi folks, i just wanted to know is there any dcent documentation on the code structure of XFS available in the net?... Rajarshi __________________________________________________ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ From owner-linux-xfs@oss.sgi.com Tue Jun 19 05:14:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JCEUj17081 for linux-xfs-outgoing; Tue, 19 Jun 2001 05:14:30 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JCESV17075 for ; Tue, 19 Jun 2001 05:14:29 -0700 Received: (qmail 15637 invoked from network); 19 Jun 2001 12:14:24 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 19 Jun 2001 12:14:24 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Rajarshi Chakraborty cc: linux-xfs@oss.sgi.com Subject: Re: documentation for xfs code In-reply-to: Your message of "Tue, 19 Jun 2001 05:03:01 MST." <20010619120301.47086.qmail@web14607.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Jun 2001 22:14:23 +1000 Message-ID: <19685.992952863@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 19 Jun 2001 05:03:01 -0700 (PDT), Rajarshi Chakraborty wrote: >i just wanted to know is there any dcent documentation >on the code structure of XFS available in the net?... Please read http://oss.sgi.com/projects/xfs/faq.html before asking. From owner-linux-xfs@oss.sgi.com Tue Jun 19 05:32:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JCW9F17431 for linux-xfs-outgoing; Tue, 19 Jun 2001 05:32:09 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JCW8V17428 for ; Tue, 19 Jun 2001 05:32:09 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5JCW3t23784 for linux-xfs@oss.sgi.com; Tue, 19 Jun 2001 08:32:03 -0400 Date: Tue, 19 Jun 2001 08:32:03 -0400 From: Alan Eldridge To: linux-xfs@oss.sgi.com Subject: kernel modules: never mind Message-ID: <20010619083203.A23781@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I guess I shoulda just looked at the previous source RPMs for my answer. They're RH's addons... -- Alan Eldridge From owner-linux-xfs@oss.sgi.com Tue Jun 19 05:50:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JCoNC17689 for linux-xfs-outgoing; Tue, 19 Jun 2001 05:50:23 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JCoLV17686 for ; Tue, 19 Jun 2001 05:50:21 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id FAA05950 for ; Tue, 19 Jun 2001 05:49:55 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (gibble.americas.sgi.com [128.162.195.80]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id FAA21500; Tue, 19 Jun 2001 05:48:53 -0700 (PDT) Message-ID: <3B2F499F.2BEC213E@sgi.com> Date: Tue, 19 Jun 2001 07:46:23 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Alan Eldridge CC: linux-xfs@oss.sgi.com Subject: Re: sensor modules in rpms? References: <20010619024326.A2545@wwweasel.geeksrus.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alan Eldridge wrote: > > Eric, > > A whole slew of the i2c-* modules is missing from the 2.4.5 RPMs you just > announced. What's the story on those (I have a VIAPro chipset, so I need > i2c-viapro to monitor the temp/fans)... is it just a rebuild with some > options changed, or worse? And yes, the VIAPro has worked 100% reliably for > me (I've been using MBs with VIA chips for several years now). Hi Alan - The I2C code is not part of the standard kernel yet, as far as I know. Since the 2.4.5 RPMs I made are just standard kernel code, no other additions, the I2C stuff won't be there. If you need it, grab the Red Hat / 2.4.2 RPMs, or patch the 2.4.5 kernel yourself with both our XFS patches and the I2C sensor patches. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Jun 19 06:35:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JDZ3218408 for linux-xfs-outgoing; Tue, 19 Jun 2001 06:35:03 -0700 Received: from horus.its.uow.edu.au (horus.its.uow.edu.au [130.130.68.25]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JDZ0V18405 for ; Tue, 19 Jun 2001 06:35:01 -0700 Received: from uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12]) by horus.its.uow.edu.au (8.9.3/8.9.3) with ESMTP id XAA27403 for ; Tue, 19 Jun 2001 23:34:55 +1000 (EST) Message-ID: <3B2F555F.341B5016@uow.edu.au> Date: Tue, 19 Jun 2001 23:36:31 +1000 From: Andrew Morton X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "'XFS Mailing List'" Subject: Re: Oops removing files on a full f/s References: <015801c0f85d$2cdde340$0a01a8c0@den2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juha Saarinen wrote: > > fsstress filled up /usr 100% so I was going remove the p* directories > and files. This provoked an oops: > > Kernel BUG at ll_rw_blk.c:700! > Ah. ll_rw_blk.c:700. I know it well. My bet: A buffer was unmapped in block_flushpage() but somehow somebody set it dirty again, and bdflush/kupdate tried to write the thing out. For ext3 I have implemented a "buffer tracing" mechanism. At any interesting pointin the lifecycle of a buffer_head you call BUFFER_TRACE(bh, "some descriptive text") then, thoughout the code I've added things like: J_ASSERT_BH(bh, some_expression); If the assertion fails you get a 64-slot backtrace of all the buffer's state transitions. There's an example output trace from when I was hitting exactly this same BUG() at http://www.zip.com.au/~akpm/buffer-trace.txt - it's great. See how journal_commit_transaction incorrectly sets the buffer dirty and then flush_dirty_buffers grabs it. I guess it's a bit late in XFS's development cycle to incorporate something like this though. From owner-linux-xfs@oss.sgi.com Tue Jun 19 08:00:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JF0nT20488 for linux-xfs-outgoing; Tue, 19 Jun 2001 08:00:49 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JF0lV20485 for ; Tue, 19 Jun 2001 08:00:47 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id RAA572311 for ; Tue, 19 Jun 2001 17:00:42 +0200 (CEST) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2197367 for ; Tue, 19 Jun 2001 09:59:25 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.184.30]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA67112 for ; Tue, 19 Jun 2001 09:59:25 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id JAA76874; Tue, 19 Jun 2001 09:59:25 -0500 (CDT) Message-Id: <200106191459.JAA76874@slobber.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: Re: XFS module problems -- usage count incorrect Date: Tue, 19 Jun 2001 09:59:25 -0500 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: Keith Owens >dmapi needs to bump the module use count when it provides services to >another piece of code, not at init time. MOD_INC_USE_COUNT is the >correct method but dmapi_init is the wrong place. Find a point where >dmapi starts providing services and put MOD_INC_USE_COUNT there, >probably dmapi_open. Same for MOD_DEC_USE_COUNT. dmapi_open() is where the HSM comes in. That's one place where we could bump the count. We also have event threads coming in, when someone mounts with "-o dmapi" and we'd have to bump the count in that place, too, because that event thread might come in before an HSM is started. Then we'd no longer know how many times we've bumped it, unless we kept our own counter. It seems so much more obvious--to me--to just bump it, and then during the module unload check to see if there are any registered filesystems or sessions before dropping the reference. It's not yet clear to me that there was a bug :) If the person who reported the unload problem was using dmapi and didn't clean up their sessions then I cannot let them unload the module--it wouldn't matter where we bumped and dropped reference counts. Is that person still following this thread? Dean From owner-linux-xfs@oss.sgi.com Tue Jun 19 08:21:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JFLVW20826 for linux-xfs-outgoing; Tue, 19 Jun 2001 08:21:31 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JFLSV20823 for ; Tue, 19 Jun 2001 08:21:28 -0700 Received: (qmail 17104 invoked from network); 19 Jun 2001 15:21:25 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 19 Jun 2001 15:21:25 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Dean Roehrich cc: linux-xfs@oss.sgi.com Subject: Re: XFS module problems -- usage count incorrect In-reply-to: Your message of "Tue, 19 Jun 2001 09:59:25 EST." <200106191459.JAA76874@slobber.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Jun 2001 01:21:24 +1000 Message-ID: <21330.992964084@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 19 Jun 2001 09:59:25 -0500, Dean Roehrich wrote: >It's not yet clear to me that there was a bug :) If the person who reported >the unload problem was using dmapi and didn't clean up their sessions then I >cannot let them unload the module--it wouldn't matter where we bumped and >dropped reference counts. Is that person still following this thread? The problem is that MOD_DEC_USE_COUNT is only called from dmapi_uninit(). That is called from exit_xfs_fs() in fs/xfs/linux/xfs_super.c. exit_xfs_fs() is declared as module_exit. module_exit routines are only called when the module is being removed, i.e. after the use count has already gone to zero. So MOD_DEC_USE_COUNT is only issued when the module is being removed but the module cannot be removed until MOD_DEC_USE_COUNT has been issued. Catch 22. Looking at dmapi_uninit, it calls dm_uninit() which checks if dmapi can be removed. Modules support another mechanism besides use counts, a module can set its own 'can_unload' function in struct module __this_module. When can_unload is set, the use count is ignored, instead that function is called to see if the module can be unloaded. The only problem is that modules with a can_unload function have a use count of -1 which confuses a lot of users, even though it is in the l-k FAQ. I would prefer use counts to be set instead of using can_unload. BTW, if dm_uninit fails then dmapi_dev is not unregistered. But the module will still be unloaded, module_exit routines are not allowed to fail. From owner-linux-xfs@oss.sgi.com Tue Jun 19 09:04:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JG40u21990 for linux-xfs-outgoing; Tue, 19 Jun 2001 09:04:00 -0700 Received: from deliverator.sgi.com ([204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JG3xV21987 for ; Tue, 19 Jun 2001 09:03:59 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA15453 for ; Tue, 19 Jun 2001 09:03:01 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA2202694; Tue, 19 Jun 2001 11:00:38 -0500 (CDT) Received: from lord.americas.sgi.com (IDENT:root@lord.americas.sgi.com [128.162.187.39]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA25478; Tue, 19 Jun 2001 11:00:37 -0500 (CDT) Received: from lord.americas.sgi.com by lord.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5JG4Hc01768; Tue, 19 Jun 2001 11:04:17 -0500 Message-Id: <200106191604.f5JG4Hc01768@lord.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andrew Morton cc: "'XFS Mailing List'" Subject: Re: Oops removing files on a full f/s In-Reply-To: Message from Andrew Morton of "Tue, 19 Jun 2001 23:36:31 +1000." <3B2F555F.341B5016@uow.edu.au> Date: Tue, 19 Jun 2001 11:04:17 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Juha Saarinen wrote: > > > > fsstress filled up /usr 100% so I was going remove the p* directories > > and files. This provoked an oops: > > > > Kernel BUG at ll_rw_blk.c:700! > > > > Ah. ll_rw_blk.c:700. I know it well. > > My bet: A buffer was unmapped in block_flushpage() but somehow > somebody set it dirty again, and bdflush/kupdate tried to write > the thing out. We managed to get into the read path without mapping the buffer, the information I really need to diagnose this is elsewhere else in the kernel, not the buffer_head, time to do a debug by induction. > > For ext3 I have implemented a "buffer tracing" mechanism. At > any interesting pointin the lifecycle of a buffer_head you > call > > BUFFER_TRACE(bh, "some descriptive text") > > then, thoughout the code I've added things like: > > J_ASSERT_BH(bh, some_expression); > > If the assertion fails you get a 64-slot backtrace of > all the buffer's state transitions. There's an example > output trace from when I was hitting exactly this same BUG() > at http://www.zip.com.au/~akpm/buffer-trace.txt - it's great. > See how journal_commit_transaction incorrectly sets the > buffer dirty and then flush_dirty_buffers grabs it. We do have buffer tracing, but at the pagebuf buffer level, not the buffer head level, all metadata is managed through a different structure. buffer heads only come into play when we actually do I/O. But it looks useful for the I/O path end of things, I may take a look if I can find the time. Steve From owner-linux-xfs@oss.sgi.com Tue Jun 19 10:54:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JHsbw23718 for linux-xfs-outgoing; Tue, 19 Jun 2001 10:54:37 -0700 Received: from mailout02.sul.t-online.de (mailout02.sul.t-online.com [194.25.134.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JHsYV23715 for ; Tue, 19 Jun 2001 10:54:34 -0700 Received: from fwd03.sul.t-online.de by mailout02.sul.t-online.de with smtp id 15CPhq-0001qj-0N; Tue, 19 Jun 2001 19:54:26 +0200 Received: from t-online.de (340024412816-0001@[217.81.143.176]) by fwd03.sul.t-online.com with esmtp id 15CPhj-267ywSC; Tue, 19 Jun 2001 19:54:19 +0200 Message-ID: <3B2F91DE.B3D2AEE1@t-online.de> Date: Tue, 19 Jun 2001 19:54:38 +0200 From: Hasch@t-online.de (Juergen Hasch) X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 To: Timothy Shimmin CC: linux-xfs Subject: Samba panic with ACLs References: <3B2E7B5A.C0088BBF@t-online.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: 340024412816-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk There is a bug in acl.c/acl_get_qualifier. The Posix draft states the object returned by acl_get_qualifier should be cleared using acl_free. This crashes Samba because we only return a pointer from inside an existing object. The patch below fixes this, I somehow missed this before... --- acl.orig Fri Jun 8 22:53:48 2001 +++ acl.c Tue Jun 19 19:43:37 2001 @@ -996,6 +996,8 @@ void * acl_get_qualifier (acl_entry_t entry_d) { + uid_t *retval; + if(entry_d == NULL){ setoserror(EINVAL); return NULL; } - return &entry_d->ae_id; + retval = malloc(sizeof(uid_t)); + if (!retval) + return NULL; + *retval = entry_d->ae_id; + return retval; } int From owner-linux-xfs@oss.sgi.com Tue Jun 19 12:08:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JJ88G02132 for linux-xfs-outgoing; Tue, 19 Jun 2001 12:08:08 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JJ86V02123 for ; Tue, 19 Jun 2001 12:08:06 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id VAA02390; Tue, 19 Jun 2001 21:08:04 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id VAA01579; Tue, 19 Jun 2001 21:08:04 +0200 (CEST) Date: Tue, 19 Jun 2001 21:08:04 +0200 (CEST) From: Seth Mos To: keith_m@sweeney.demon.co.uk cc: linux-xfs@oss.sgi.com Subject: Re: XFS FAQ Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 19 Jun 2001, Wine Development wrote: > Seth, > > on the part regarding resize, it might be a good idea to add something > about shrinking. It has come up at least three times now. I will unfortunately my home machine currently has no motherboard. When I tried to do a BIOS update on of my server machines it screwed the motherboard and I had to replace so they could continue working. I ordererd a new system today which should arive in a week. A Asus A7M266 with a 1.4Ghz Athlon and 256 MB DDR ram. So untill my home machine is working again I'm limping around on my windows notebook. I will see what I can do for the moment. > Keith Matthews Spam trap - my real account at this > node is keith_m > > Frequentous Consultants - Linux Services, > Oracle development & database administration Cheers Seth From owner-linux-xfs@oss.sgi.com Tue Jun 19 13:23:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JKNNS15265 for linux-xfs-outgoing; Tue, 19 Jun 2001 13:23:23 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JKNLV15261 for ; Tue, 19 Jun 2001 13:23:22 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15CS1v-0006J1-00; Wed, 20 Jun 2001 08:23:19 +1200 Date: Wed, 20 Jun 2001 08:23:18 +1200 (NZST) From: Juha Saarinen To: Andrew Morton cc: "'XFS Mailing List'" Subject: Re: Oops removing files on a full f/s In-Reply-To: <3B2F555F.341B5016@uow.edu.au> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Andrew, Bit more testing here... I'm able to oops the box by simply attempting to log in, either locally or remotely (through ssh). This is without f/s activity, so that was just a red herring. Need to run Russell's script next. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 On Tue, 19 Jun 2001, Andrew Morton wrote: > > Ah. ll_rw_blk.c:700. I know it well. > > My bet: A buffer was unmapped in block_flushpage() but somehow > somebody set it dirty again, and bdflush/kupdate tried to write > the thing out. > > For ext3 I have implemented a "buffer tracing" mechanism. At > any interesting pointin the lifecycle of a buffer_head you > call > > BUFFER_TRACE(bh, "some descriptive text") > > then, thoughout the code I've added things like: > > J_ASSERT_BH(bh, some_expression); > > If the assertion fails you get a 64-slot backtrace of > all the buffer's state transitions. There's an example > output trace from when I was hitting exactly this same BUG() > at http://www.zip.com.au/~akpm/buffer-trace.txt - it's great. > See how journal_commit_transaction incorrectly sets the > buffer dirty and then flush_dirty_buffers grabs it. > > I guess it's a bit late in XFS's development cycle to incorporate > something like this though. > > From owner-linux-xfs@oss.sgi.com Tue Jun 19 13:32:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JKWYm16909 for linux-xfs-outgoing; Tue, 19 Jun 2001 13:32:34 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JKWWV16905 for ; Tue, 19 Jun 2001 13:32:33 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA03500 for ; Tue, 19 Jun 2001 13:32:31 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2203725; Tue, 19 Jun 2001 15:31:05 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA87189; Tue, 19 Jun 2001 15:31:04 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5JKYi202072; Tue, 19 Jun 2001 15:34:44 -0500 Message-Id: <200106192034.f5JKYi202072@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Juha Saarinen cc: Andrew Morton , "'XFS Mailing List'" Subject: Re: Oops removing files on a full f/s In-Reply-To: Message from Juha Saarinen of "Wed, 20 Jun 2001 08:23:18 +1200." Date: Tue, 19 Jun 2001 15:34:44 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi Andrew, > > Bit more testing here... > > I'm able to oops the box by simply attempting to log in, either locally or > remotely (through ssh). This is without f/s activity, so that was just a > red herring. > > Need to run Russell's script next. A thought occurs, which compiler are you using, I seem to remember people with things like VIA chipsets needing to use kgcc to get a stable kernel. Also, if you can repeat this I can probably come up with some other kdb commands you can run which may help me work it out, but only if you can get a serial console, otherwise it will HURT! Steve > > > -- > Regards, > > > Juha > > PGP fingerprint: > B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 > > On Tue, 19 Jun 2001, Andrew Morton wrote: > > > > > Ah. ll_rw_blk.c:700. I know it well. > > > > My bet: A buffer was unmapped in block_flushpage() but somehow > > somebody set it dirty again, and bdflush/kupdate tried to write > > the thing out. > > > > For ext3 I have implemented a "buffer tracing" mechanism. At > > any interesting pointin the lifecycle of a buffer_head you > > call > > > > BUFFER_TRACE(bh, "some descriptive text") > > > > then, thoughout the code I've added things like: > > > > J_ASSERT_BH(bh, some_expression); > > > > If the assertion fails you get a 64-slot backtrace of > > all the buffer's state transitions. There's an example > > output trace from when I was hitting exactly this same BUG() > > at http://www.zip.com.au/~akpm/buffer-trace.txt - it's great. > > See how journal_commit_transaction incorrectly sets the > > buffer dirty and then flush_dirty_buffers grabs it. > > > > I guess it's a bit late in XFS's development cycle to incorporate > > something like this though. > > > > From owner-linux-xfs@oss.sgi.com Tue Jun 19 13:52:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JKqjX20432 for linux-xfs-outgoing; Tue, 19 Jun 2001 13:52:45 -0700 Received: from web13204.mail.yahoo.com (web13204.mail.yahoo.com [216.136.174.189]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JKqiV20418 for ; Tue, 19 Jun 2001 13:52:44 -0700 Message-ID: <20010619205244.75348.qmail@web13204.mail.yahoo.com> Received: from [216.26.61.52] by web13204.mail.yahoo.com; Tue, 19 Jun 2001 13:52:44 PDT Date: Tue, 19 Jun 2001 13:52:44 -0700 (PDT) From: Cliff Wells Subject: nVidia driver incompatible To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I know this is just a test release, but you should know that the nVidia driver available from the nVidia website doesn't work when installed on the Redhat 7.1-XFS system. I installed using the Redhat 7.1-XFS CD and everything worked fine (including the XFree86 default nv driver) but when I installed the accelerated nVidia driver my screen just blanks over and over again. I wish I could give you more information, but I had to have my machine back up so I reinstalled the stock Redhat system. I would have stuck with the default nv driver but the accelerated driver from nVidia makes a HUGE difference in performance. Thanks, Cliff Wells __________________________________________________ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ From owner-linux-xfs@oss.sgi.com Tue Jun 19 13:52:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JKqiq20411 for linux-xfs-outgoing; Tue, 19 Jun 2001 13:52:44 -0700 Received: from chimta01.algx.net (chimta01.algx.net [216.99.233.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JKqgV20407 for ; Tue, 19 Jun 2001 13:52:43 -0700 Received: from localhost.localdomain (66-2-81-26.customer.algx.net [66.2.81.26]) by chimmx01.algx.net (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id <0GF700LI73BR50@chimmx01.algx.net> for linux-xfs@oss.sgi.com; Tue, 19 Jun 2001 15:52:40 -0500 (CDT) Date: Tue, 19 Jun 2001 16:52:36 -0400 (EDT) From: jtrostel@connex.com Subject: RE: Samba panic with ACLs In-reply-to: <3B2F91DE.B3D2AEE1@t-online.de> To: Hasch@t-online.de (Juergen Hasch) Cc: linux-xfs Cc: linux-xfs , Timothy Shimmin Reply-to: jtrostel@connex.com Message-id: Organization: Connex MIME-version: 1.0 X-Mailer: XFMail 1.5.0 on Linux Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The standard states, "The acl_get_qualifier() function retrieves the qualifier of the tag for the ACL entry indicated by the argument entry_d into working storage and returns a pointer to that storage." "... Subsequent operations using the returned pointer shall operate on an independant copy of the qualifier in working storage. This function may cause memory to be allocated. The caller should free any releaseable memory, when the new qualifier is no longer required, by calling acl_free() with the void* as an argument." It looks like I designed the original function to just return a pointer. This, however, IS in working storage. The 'real' ACL lies beneath in/on the inode itself. The ACL we are working with here doesn't affect the 'real' ACL until it is written back to the inode/EA. The question is, what should the sentence about 'Subsequent operations ...' mean? If the user should be able to pull up numerous copies of this qualifier and work on them independantly without any cross influence, then I think Juergen is right ... again ;-> It sure looks like a place rife for memory leaks though.... A malloc and no free. On 19-Jun-2001 Juergen Hasch wrote: > > There is a bug in acl.c/acl_get_qualifier. The Posix draft states > the object returned by acl_get_qualifier should be cleared using > acl_free. This crashes Samba because we only return a pointer from > inside an existing object. > The patch below fixes this, I somehow missed this before... > > --- acl.orig Fri Jun 8 22:53:48 2001 > +++ acl.c Tue Jun 19 19:43:37 2001 > @@ -996,6 +996,8 @@ > void * > acl_get_qualifier (acl_entry_t entry_d) > { > + uid_t *retval; > + > if(entry_d == NULL){ > setoserror(EINVAL); > return NULL; > } > > - return &entry_d->ae_id; > + retval = malloc(sizeof(uid_t)); > + if (!retval) > + return NULL; > + *retval = entry_d->ae_id; > + return retval; > } > > int -- John M. Trostel Linux OS Engineer Connex jtrostel@connex.com From owner-linux-xfs@oss.sgi.com Tue Jun 19 13:57:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JKv4h21295 for linux-xfs-outgoing; Tue, 19 Jun 2001 13:57:04 -0700 Received: from sphinx.druber.com (druber-gw.lightband.com [216.129.135.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JKv3V21292 for ; Tue, 19 Jun 2001 13:57:04 -0700 Received: from SWARTZ-D.druber.com (SWARTZ-D.cac.stratus.com [134.111.43.114]) by sphinx.druber.com (Postfix) with ESMTP id 42395116; Tue, 19 Jun 2001 16:50:27 -0400 (EDT) Message-Id: <5.1.0.14.2.20010619165614.03ee7280@druber-gw.lightband.com> X-Sender: dswartz@druber-gw.lightband.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 19 Jun 2001 16:56:56 -0400 To: Cliff Wells , linux-xfs@oss.sgi.com From: Dan Swartzendruber Subject: Re: nVidia driver incompatible In-Reply-To: <20010619205244.75348.qmail@web13204.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 01:52 PM 6/19/2001 -0700, Cliff Wells wrote: >Hi, > >I know this is just a test release, but you should >know that the nVidia driver available from the nVidia >website doesn't work when installed on the Redhat >7.1-XFS system. >I installed using the Redhat 7.1-XFS CD and everything >worked fine (including the XFree86 default nv driver) >but when I installed the accelerated nVidia driver my >screen just blanks over and over again. I wish I could >give you more information, but I had to have my >machine back up so I reinstalled the stock Redhat >system. I would have stuck with the default nv driver >but the accelerated driver from nVidia makes a HUGE >difference in performance. i'm skeptical. i'm running 2.4.6-pre3 with RH7.1 and the nvidia driver i got off their website. works fine. are you sure you have backing store set? From owner-linux-xfs@oss.sgi.com Tue Jun 19 14:01:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JL1EB22133 for linux-xfs-outgoing; Tue, 19 Jun 2001 14:01:14 -0700 Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JL1DV22122 for ; Tue, 19 Jun 2001 14:01:14 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.2/8.11.2) with ESMTP id f5JL02M08212; Tue, 19 Jun 2001 17:00:02 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Tue, 19 Jun 2001 17:00:02 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: To: Cliff Wells cc: Subject: Re: nVidia driver incompatible In-Reply-To: <20010619205244.75348.qmail@web13204.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 19 Jun 2001 at 1:52pm, Cliff Wells wrote > I know this is just a test release, but you should > know that the nVidia driver available from the nVidia > website doesn't work when installed on the Redhat > 7.1-XFS system. The nVidia drivers don't work with devfs (as stated in their README), and the SGI kernels have devfs turned on. Try turning off devfs and see if that helps. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Tue Jun 19 14:02:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JL2nP22477 for linux-xfs-outgoing; Tue, 19 Jun 2001 14:02:49 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JL2mV22474 for ; Tue, 19 Jun 2001 14:02:48 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip91.idcomm.com [209.60.72.218] (may be forged)) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5JL36l06156; Tue, 19 Jun 2001 15:03:06 -0600 Message-ID: <3B2FBE4B.B6386AE3@idcomm.com> Date: Tue, 19 Jun 2001 15:04:11 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: Cliff Wells CC: linux-xfs@oss.sgi.com Subject: Re: nVidia driver incompatible References: <20010619205244.75348.qmail@web13204.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Cliff Wells wrote: > > Hi, > > I know this is just a test release, but you should > know that the nVidia driver available from the nVidia > website doesn't work when installed on the Redhat > 7.1-XFS system. The source version compiles fine against the 2.4.6-pre1-xfs, which I am using. Binary versions don't work against anything except what they were compiled against. > I installed using the Redhat 7.1-XFS CD and everything > worked fine (including the XFree86 default nv driver) > but when I installed the accelerated nVidia driver my > screen just blanks over and over again. I wish I could The kernel module must be recompiled. Set it to runlevel 3 till it is compiled. While it is blinking you can type "init 3" from a root console. Or you can change your default runlevel at start in /etc/inittab to runlevel 3 instead of 5 until you are done. > give you more information, but I had to have my > machine back up so I reinstalled the stock Redhat > system. I would have stuck with the default nv driver > but the accelerated driver from nVidia makes a HUGE > difference in performance. On a 1600x1280 desktop, 24 bit, and 1024x768 window, I'm averaging 97 fps (GeForce I, DDR). D. Stimits, stimits@idcomm.com > > Thanks, > > Cliff Wells > > __________________________________________________ > Do You Yahoo!? > Spot the hottest trends in music, movies, and more. > http://buzz.yahoo.com/ From owner-linux-xfs@oss.sgi.com Tue Jun 19 14:02:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JL2s222514 for linux-xfs-outgoing; Tue, 19 Jun 2001 14:02:54 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JL2rV22511 for ; Tue, 19 Jun 2001 14:02:53 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA29385 for ; Tue, 19 Jun 2001 14:02:43 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2205969; Tue, 19 Jun 2001 16:01:31 -0500 (CDT) Received: from sgi.com (eagdhcp-195-17.americas.sgi.com [128.162.195.187]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA94916; Tue, 19 Jun 2001 16:01:31 -0500 (CDT) Message-ID: <3B2FBD91.7404EDE@sgi.com> Date: Tue, 19 Jun 2001 16:01:05 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Cliff Wells CC: linux-xfs@oss.sgi.com Subject: Re: nVidia driver incompatible References: <20010619205244.75348.qmail@web13204.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Cliff Wells wrote: > > Hi, > > I know this is just a test release, but you should > know that the nVidia driver available from the nVidia > website doesn't work when installed on the Redhat > 7.1-XFS system. Hm, send along the nVidia source code, and we'll work it out. ;-) -Eric From owner-linux-xfs@oss.sgi.com Tue Jun 19 14:36:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JLaPv28419 for linux-xfs-outgoing; Tue, 19 Jun 2001 14:36:25 -0700 Received: from marvin.linux-dude.com (c-f58a70d5.032-6-73746f3.cust.bredbandsbolaget.se [213.112.138.245]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JLaOV28414 for ; Tue, 19 Jun 2001 14:36:24 -0700 Received: from marvin (localhost [127.0.0.1]) by marvin.linux-dude.com (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with SMTP id f5JLaJR00809; Tue, 19 Jun 2001 23:36:19 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Jarek Luberek To: Cliff Wells Subject: Re: nVidia driver incompatible Date: Tue, 19 Jun 2001 23:36:19 +0200 X-Mailer: KMail [version 1.2] References: <20010619205244.75348.qmail@web13204.mail.yahoo.com> In-Reply-To: <20010619205244.75348.qmail@web13204.mail.yahoo.com> Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Message-Id: <01061923361900.00792@marvin> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tuesday 19 June 2001 22:52, you wrote: > Hi, > > I know this is just a test release, but you should > know that the nVidia driver available from the nVidia > website doesn't work when installed on the Redhat > 7.1-XFS system. > I installed using the Redhat 7.1-XFS CD and everything > worked fine (including the XFree86 default nv driver) > but when I installed the accelerated nVidia driver my > screen just blanks over and over again. I wish I could > give you more information, but I had to have my > machine back up so I reinstalled the stock Redhat > system. I would have stuck with the default nv driver > but the accelerated driver from nVidia makes a HUGE > difference in performance. FWIW, it did not work properly for me (i.e. random lockups) until 2.4.6-pre3-xfs. Greetings, Jarek From owner-linux-xfs@oss.sgi.com Tue Jun 19 14:42:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JLgBu29521 for linux-xfs-outgoing; Tue, 19 Jun 2001 14:42:11 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JLgAV29510 for ; Tue, 19 Jun 2001 14:42:10 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip91.idcomm.com [209.60.72.218] (may be forged)) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5JLgUl15715 for ; Tue, 19 Jun 2001 15:42:30 -0600 Message-ID: <3B2FC787.87F67F42@idcomm.com> Date: Tue, 19 Jun 2001 15:43:35 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: nVidia driver incompatible References: <20010619205244.75348.qmail@web13204.mail.yahoo.com> <3B2FBD91.7404EDE@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > > Cliff Wells wrote: > > > > Hi, > > > > I know this is just a test release, but you should > > know that the nVidia driver available from the nVidia > > website doesn't work when installed on the Redhat > > 7.1-XFS system. > > Hm, send along the nVidia source code, and we'll work it out. ;-) > > -Eric The kernel module source code is available. It is the GLX code (which also does not require recompile when a kernel is changed) that is not open. Apparently part of the reason this is the way it is reflects the same problems SGI had before with XFS...the GLX is not a Mesa look-alike, but is a full OpenGL implementation, and as such it is encumbered with legalities. Between customers that paid for their OpenGL implementation and encumberances, it might be difficult for them to release it. But SGI might be able to help with any OpenGL licensing issues :P D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Tue Jun 19 14:43:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JLh8s29736 for linux-xfs-outgoing; Tue, 19 Jun 2001 14:43:08 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JLh8V29727 for ; Tue, 19 Jun 2001 14:43:08 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip91.idcomm.com [209.60.72.218] (may be forged)) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5JLhRl15935 for ; Tue, 19 Jun 2001 15:43:27 -0600 Message-ID: <3B2FC7C0.E90FA25D@idcomm.com> Date: Tue, 19 Jun 2001 15:44:32 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: nVidia driver incompatible References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Joshua Baker-LePain wrote: > > On Tue, 19 Jun 2001 at 1:52pm, Cliff Wells wrote > > > I know this is just a test release, but you should > > know that the nVidia driver available from the nVidia > > website doesn't work when installed on the Redhat > > 7.1-XFS system. > > The nVidia drivers don't work with devfs (as stated in their README), and > the SGI kernels have devfs turned on. Try turning off devfs and see if > that helps. > > -- > Joshua Baker-LePain > Department of Biomedical Engineering > Duke University I can confirm that my working version does NOT use devfs. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Tue Jun 19 14:46:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JLkXr30413 for linux-xfs-outgoing; Tue, 19 Jun 2001 14:46:33 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JLkWV30410 for ; Tue, 19 Jun 2001 14:46:32 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip91.idcomm.com [209.60.72.218] (may be forged)) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5JLkql16757 for ; Tue, 19 Jun 2001 15:46:52 -0600 Message-ID: <3B2FC88C.8F419816@idcomm.com> Date: Tue, 19 Jun 2001 15:47:56 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: nVidia driver incompatible References: <20010619205244.75348.qmail@web13204.mail.yahoo.com> <01061923361900.00792@marvin> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jarek Luberek wrote: > > On Tuesday 19 June 2001 22:52, you wrote: > > Hi, > > > > I know this is just a test release, but you should > > know that the nVidia driver available from the nVidia > > website doesn't work when installed on the Redhat > > 7.1-XFS system. > > I installed using the Redhat 7.1-XFS CD and everything > > worked fine (including the XFree86 default nv driver) > > but when I installed the accelerated nVidia driver my > > screen just blanks over and over again. I wish I could > > give you more information, but I had to have my > > machine back up so I reinstalled the stock Redhat > > system. I would have stuck with the default nv driver > > but the accelerated driver from nVidia makes a HUGE > > difference in performance. > FWIW, it did not work properly for me (i.e. random lockups) > until 2.4.6-pre3-xfs. > > Greetings, > Jarek I am curious if you tried 2.4.6-pre2-xfs? The one patch I kept mentioning before on fs/block_dev.c caused a lot of problems for me when it wasn't installed. Every 2.4.5+ kernel I've run which had that fixed has been completely stable for me (I don't use many of the advanced features of XFS though, like ACL, or complications like NFS). With that one patch 2.4.6-pre1-xfs has never gone down on me. I have intentionally cut power to test it though, and I can't even begin to say how pleased I am with it (it beats the hell out of all the problems with ReiserFS I see on the kernel list). D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Tue Jun 19 15:01:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JM1bn32648 for linux-xfs-outgoing; Tue, 19 Jun 2001 15:01:37 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JM1ZV32645 for ; Tue, 19 Jun 2001 15:01:35 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15CTX0-0006MU-00; Wed, 20 Jun 2001 09:59:30 +1200 Date: Wed, 20 Jun 2001 09:59:30 +1200 (NZST) From: Juha Saarinen To: Steve Lord cc: Andrew Morton , "'XFS Mailing List'" Subject: Re: Oops removing files on a full f/s In-Reply-To: <200106192034.f5JKYi202072@jen.americas.sgi.com> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've compiled the CVS code with gcc 2.96-85 to see if it would work better than -81. The single mode f/s corruption that I reported before has gone, but it's entirely possible that it's a compiler issue (most of these mysterious things are, it seems...). I'll try to hook up a serial console to the box. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 On Tue, 19 Jun 2001, Steve Lord wrote: > A thought occurs, which compiler are you using, I seem to remember people > with things like VIA chipsets needing to use kgcc to get a stable kernel. > > Also, if you can repeat this I can probably come up with some other > kdb commands you can run which may help me work it out, but only if > you can get a serial console, otherwise it will HURT! > > Steve From owner-linux-xfs@oss.sgi.com Tue Jun 19 15:17:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JMHXJ02722 for linux-xfs-outgoing; Tue, 19 Jun 2001 15:17:33 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JMHVV02707 for ; Tue, 19 Jun 2001 15:17:31 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15CToI-0006Nr-00; Wed, 20 Jun 2001 10:17:22 +1200 Date: Wed, 20 Jun 2001 10:17:21 +1200 (NZST) From: Juha Saarinen To: "D. Stimits" cc: "linux-xfs@oss.sgi.com" Subject: Re: nVidia driver incompatible In-Reply-To: <3B2FC7C0.E90FA25D@idcomm.com> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk It does work, but there's a little more effort required, because you need to recreate some /dev nodes at boot-up. Here's a script, adapted from the one in the nVidia src rpm that'll do it: #!/bin/sh /sbin/rmmod NVdriver for d in 0 1 2 3 do devfile=/dev/nvidia$d rm -f $devfile mknod $devfile c 195 $d chmod 0666 $devfile done devfile=/dev/nvidiactl rm -f $devfile mknod $devfile c 195 255 chmod 0666 $devfile confmod="/etc/conf.modules" [ -f /etc/modules.conf ] && confmod="/etc/modules.conf" conftmp=/tmp/conf$$ sed '/^alias.*char-major-.*NVdriver/d' < $confmod > $conftmp echo "alias char-major-195 NVdriver" >> $conftmp mv $conftmp $confmod /sbin/depmod -a /sbin/modprobe NVdriver echo echo NVdriver installed succesfully! echo exit 0 Could probably be improved upon, but it works for me. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 On Tue, 19 Jun 2001, D. Stimits wrote: > I can confirm that my working version does NOT use devfs. > > D. Stimits, stimits@idcomm.com > > From owner-linux-xfs@oss.sgi.com Tue Jun 19 15:25:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JMPoU04175 for linux-xfs-outgoing; Tue, 19 Jun 2001 15:25:50 -0700 Received: from smtp04.retemail.es (smtp04.iddeo.es [62.81.186.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JMPmV04169 for ; Tue, 19 Jun 2001 15:25:48 -0700 Received: from redestb.es ([62.174.163.41]) by smtp04.retemail.es (InterMail vM.5.01.03.02 201-253-122-118-102-20010403) with ESMTP id <20010619222546.XBLC23751.smtp04.retemail.es@redestb.es>; Wed, 20 Jun 2001 00:25:46 +0200 Message-ID: <3B2FD0AD.DBBDA765@redestb.es> Date: Wed, 20 Jun 2001 00:22:37 +0200 From: Manuel Lopez X-Mailer: Mozilla 4.71 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Cliff Wells CC: linux-xfs@oss.sgi.com Subject: Re: nVidia driver incompatible References: <20010619205244.75348.qmail@web13204.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Cliff Wells wrote: > I installed using the Redhat 7.1-XFS CD and everything > worked fine (including the XFree86 default nv driver) > but when I installed the accelerated nVidia driver my > screen just blanks over and over again. I wish I could > give you more information, but I had to have my > machine back up so I reinstalled the stock Redhat > system. I would have stuck with the default nv driver > but the accelerated driver from nVidia makes a HUGE > difference in performance. This work for me in RH7.1-XFS with XFree86 4.1.0 Download the source tgz from nvidia ftp site, Make "make install" in both packages-tree. Start your xserver with the correct lines in XF86Config-4 if start well, but in the next reboot don't start run only "makedevices.sh" from the Nvidia-kernel soure tree. I run in every start with a line in "rc.local" Manuel Lopez From owner-linux-xfs@oss.sgi.com Tue Jun 19 15:31:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JMVkR05293 for linux-xfs-outgoing; Tue, 19 Jun 2001 15:31:46 -0700 Received: from afaranis1.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JMVjV05289 for ; Tue, 19 Jun 2001 15:31:45 -0700 Received: from [10.2.4.91] ([10.2.4.91]) by afaranis1.afara.com (8.9.3/8.9.3) with ESMTP id PAA22012; Tue, 19 Jun 2001 15:30:53 -0700 (PDT) Subject: Re: nVidia driver incompatible From: Thomas Duffy To: Joshua Baker-LePain Cc: Cliff Wells , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain X-Mailer: Evolution/0.10 (Preview Release) Date: 19 Jun 2001 15:30:47 -0700 Message-Id: <992989848.28180.3.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 19 Jun 2001 17:00:02 -0400, Joshua Baker-LePain wrote: > On Tue, 19 Jun 2001 at 1:52pm, Cliff Wells wrote > > The nVidia drivers don't work with devfs (as stated in their README), and > the SGI kernels have devfs turned on. Try turning off devfs and see if > that helps. it works fine with devfs. using it here right now. (2.4.2-SGI_XFS_1.0 xfs root + NVIDIA_kernel-1.0-1251) just add the following two lines to you /etc/rc.d/rc.local at the end mknod /dev/nvidiactl c 195 255 mknod /dev/nvidia0 c 195 0 so that the dev entries are created on boot up each time. -tduffy From owner-linux-xfs@oss.sgi.com Tue Jun 19 15:46:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JMk9j07921 for linux-xfs-outgoing; Tue, 19 Jun 2001 15:46:09 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JMk8V07916 for ; Tue, 19 Jun 2001 15:46:08 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA16922 for ; Tue, 19 Jun 2001 15:45:58 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2204349 for ; Tue, 19 Jun 2001 17:44:46 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA95109 for ; Tue, 19 Jun 2001 17:44:46 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f5JMmPV03405; Tue, 19 Jun 2001 17:48:25 -0500 Message-Id: <200106192248.f5JMmPV03405@jen.americas.sgi.com> Date: Tue, 19 Jun 2001 17:48:25 -0500 Subject: TAKE - small code cleanup in fs/buffer.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jun 19 15:44:03 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:97223a linux/fs/buffer.c - 1.68 - Change a return zero into a BUG call, if we call write_buffer and there is no page then we need to do something, we cannot just return. This is a code path which cannot happen in theory.... From owner-linux-xfs@oss.sgi.com Tue Jun 19 16:52:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JNqLF18707 for linux-xfs-outgoing; Tue, 19 Jun 2001 16:52:21 -0700 Received: from sphinx.druber.com (druber-gw.lightband.com [216.129.135.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JNqKV18696 for ; Tue, 19 Jun 2001 16:52:20 -0700 Received: from sphinx.druber.com (sphinx.druber.com [10.0.0.2]) by sphinx.druber.com (Postfix) with ESMTP id 58ED6117; Tue, 19 Jun 2001 19:45:44 -0400 (EDT) Date: Tue, 19 Jun 2001 19:45:44 -0400 (EDT) From: Dan Swartzendruber To: "D. Stimits" Cc: Subject: Re: nVidia driver incompatible In-Reply-To: <3B2FC7C0.E90FA25D@idcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 19 Jun 2001, D. Stimits wrote: > Joshua Baker-LePain wrote: > > > > On Tue, 19 Jun 2001 at 1:52pm, Cliff Wells wrote > > > > > I know this is just a test release, but you should > > > know that the nVidia driver available from the nVidia > > > website doesn't work when installed on the Redhat > > > 7.1-XFS system. > > > > The nVidia drivers don't work with devfs (as stated in their README), and > > the SGI kernels have devfs turned on. Try turning off devfs and see if > > that helps. > > > > -- > > Joshua Baker-LePain > > Department of Biomedical Engineering > > Duke University > > I can confirm that my working version does NOT use devfs. ditto. i disabled devfs, since it was hosing other things... From owner-linux-xfs@oss.sgi.com Tue Jun 19 16:59:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JNx2g19302 for linux-xfs-outgoing; Tue, 19 Jun 2001 16:59:02 -0700 Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JNx1V19299 for ; Tue, 19 Jun 2001 16:59:01 -0700 Received: from insanegeeks.com (nic-131-c240-139.mw.mediaone.net [24.131.240.139]) by demai05.mw.mediaone.net (8.11.1/8.11.1) with ESMTP id f5JNx0K20150 for ; Tue, 19 Jun 2001 19:59:00 -0400 (EDT) Message-ID: <3B2FE6EA.D74E0CF5@insanegeeks.com> Date: Tue, 19 Jun 2001 19:57:30 -0400 From: Thomas Suiter X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: bad hash table ... would rebuild?? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm sure this is easy to recover from and a simple xfs_repair will fix it, but I'm wondering what exactly does this mean to me when I see this big time alarm, or just (hopefully) correctable corruption due to something outside of XFS? I was unable to find any additional information in the mailing list, faq, or web anywhere. This is running off the cvs source tree from June 16 I first saw that my xfs cvs source tree had some funky things occurring in it, doing an ls in different directories I received this: # ls ls: README: No such file or directory ls: avl.c: No such file or directory ls: avl64.c: No such file or directory ls: init.c: No such file or directory Which seemed fairly odd that someone knew something about a file but was unable to find it, I did a xfs_repair on a mounted filesystem since # xfs_repair -fn /dev/hdc5 Phase 1 - find and verify superblock... ... Everything's fine until ... No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... bad hash table for directory inode 5620157 (bad stale count): would rebuild bad hash table for directory inode 1532363 (bad stale count): would rebuild bad hash table for directory inode 7603417 (bad stale count): would rebuild bad hash table for directory inode 4968837 (bad stale count): would rebuild bad hash table for directory inode 2862249 (bad stale count): would rebuild - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. # From owner-linux-xfs@oss.sgi.com Tue Jun 19 17:11:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5K0BL920093 for linux-xfs-outgoing; Tue, 19 Jun 2001 17:11:21 -0700 Received: from vaxcave.com (www.liquidbinary.com [204.186.230.205]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5K0BKV20089 for ; Tue, 19 Jun 2001 17:11:20 -0700 Received: from bluebox.juniata.edu ([209.158.26.209]) by vaxcave.com ; Tue, 19 Jun 2001 20:11:16 -30383924 Received: from localhost ([127.0.0.1] helo=vaxcave.com) by bluebox.juniata.edu with esmtp (Exim 3.22 #1 (Debian)) id 15CVaL-0001ag-00 for ; Tue, 19 Jun 2001 20:11:05 -0400 X-Mailer: exmh version 2.3.1 01/18/2001 (debian 2.3.1-1) with nmh-1.0.4+dev To: linux-xfs@oss.sgi.com Subject: Re: nVidia driver incompatible In-Reply-To: Message from Dan Swartzendruber of "Tue, 19 Jun 2001 19:45:44 EDT." References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Jun 2001 20:11:04 -0400 From: Anthony DeStefano Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Tue, 19 Jun 2001, D. Stimits wrote: > > > > > I know this is just a test release, but you should > > > > know that the nVidia driver available from the nVidia > > > > website doesn't work when installed on the Redhat > > > > 7.1-XFS system. > > > > > > The nVidia drivers don't work with devfs (as stated in their README), and > > > the SGI kernels have devfs turned on. Try turning off devfs and see if > > > that helps. > > > > > I can confirm that my working version does NOT use devfs. > > ditto. i disabled devfs, since it was hosing other things... > I have the nvidia driver working perfectly fine on my Debian system with the xfs kernel out of CVS and devfs enabled. Now the Debian devfsd package has support for adding extra devices in /dev by basically using mknod, chmod, and chown on options it parses out of a file. So you may want to try the following in /etc/rc.d/rc.local (NOTE: this was pulled out of the makedevices.sh from the NVIDIA_kernel tarball) major=195 for i in 0 1 2 3; do devfile="/dev/nvidia$i" rm -f $devfile if ! mknod $devfile c $major $i || ! chmod 0666 $devfile; then echo "Couldn't create device \"$devfile\"." exit 1 fi done devfile=/dev/nvidiactl rm -f $devfile mknod $devfile c $major 255 chmod 0666 $devfile Seems to work fine here. ~Tony From owner-linux-xfs@oss.sgi.com Tue Jun 19 17:56:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5K0uXN26235 for linux-xfs-outgoing; Tue, 19 Jun 2001 17:56:33 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5K0uUV26218 for ; Tue, 19 Jun 2001 17:56:30 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id CAA607601 for ; Wed, 20 Jun 2001 02:56:27 +0200 (CEST) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA93589; Wed, 20 Jun 2001 10:55:08 +1000 (EST) Date: Wed, 20 Jun 2001 10:55:08 +1000 From: Timothy Shimmin To: jtrostel@connex.com Cc: Juergen Hasch , linux-xfs@oss.sgi.com Subject: Re: Samba panic with ACLs Message-ID: <20010620105507.O280523@boing.melbourne.sgi.com> References: <3B2F91DE.B3D2AEE1@t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from jtrostel@connex.com on Tue, Jun 19, 2001 at 04:52:36PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Juergen and John, I think it should be changed to malloc() space for the qualifier as Juergen suggested. The pseudo standard is hard to read as normal (IMHO:), but it does indicate that we should call acl_free() when we are done with it. (It does say to do this if it is releasable memory - but how is the caller supposed to know whether it is or isn't). So we have no choice if we are supposed to call acl_free(). I will change it unless someone can convince me otherwise :) Cheers, --Tim On Tue, Jun 19, 2001 at 04:52:36PM -0400, jtrostel@connex.com wrote: > The standard states, > > "The acl_get_qualifier() function retrieves the qualifier of the tag for the ACL > entry indicated by the argument entry_d into working storage and returns a > pointer to that storage." > > "... Subsequent operations using the returned pointer shall operate on an > independant copy of the qualifier in working storage. > > This function may cause memory to be allocated. The caller should > free any releaseable memory, when the new qualifier is no longer required, by > calling acl_free() with the void* as an argument." > > It looks like I designed the original function to just return a pointer. This, > however, IS in working storage. The 'real' ACL lies beneath in/on the inode > itself. The ACL we are working with here doesn't affect the 'real' ACL until it > is written back to the inode/EA. > > The question is, what should the sentence about 'Subsequent operations ...' > mean? If the user should be able to pull up numerous copies of this qualifier > and work on them independantly without any cross influence, then I think > Juergen is right ... again ;-> > > It sure looks like a place rife for memory leaks though.... A malloc and no > free. > > On 19-Jun-2001 Juergen Hasch wrote: > > > > There is a bug in acl.c/acl_get_qualifier. The Posix draft states > > the object returned by acl_get_qualifier should be cleared using > > acl_free. This crashes Samba because we only return a pointer from > > inside an existing object. > > The patch below fixes this, I somehow missed this before... > > > > --- acl.orig Fri Jun 8 22:53:48 2001 > > +++ acl.c Tue Jun 19 19:43:37 2001 > > @@ -996,6 +996,8 @@ > > void * > > acl_get_qualifier (acl_entry_t entry_d) > > { > > + uid_t *retval; > > + > > if(entry_d == NULL){ > > setoserror(EINVAL); > > return NULL; > > } > > > > - return &entry_d->ae_id; > > + retval = malloc(sizeof(uid_t)); > > + if (!retval) > > + return NULL; > > + *retval = entry_d->ae_id; > > + return retval; > > } > > > > int > > -- > John M. Trostel > Linux OS Engineer > Connex > jtrostel@connex.com From owner-linux-xfs@oss.sgi.com Tue Jun 19 18:43:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5K1hkh01205 for linux-xfs-outgoing; Tue, 19 Jun 2001 18:43:46 -0700 Received: from femail4.rdc1.on.home.com (femail4.rdc1.on.home.com [24.2.9.91]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5K1hjV01194 for ; Tue, 19 Jun 2001 18:43:45 -0700 Received: from digitaltux.com ([24.101.49.82]) by femail4.rdc1.on.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010620014339.LUND7002.femail4.rdc1.on.home.com@digitaltux.com>; Tue, 19 Jun 2001 18:43:39 -0700 Received: from localhost ([127.0.0.1] helo=digitaltux.com) by digitaltux.com with smtp (Exim 3.22 #1 (Debian)) id 15CX1t-00008W-00; Tue, 19 Jun 2001 21:43:37 -0400 Date: Tue, 19 Jun 2001 21:43:33 -0400 From: Zoltan Kraus To: Anthony DeStefano Cc: linux-xfs@oss.sgi.com Subject: Re: nVidia driver incompatible Message-Id: <20010619214333.4cb45114.zoltan@digitaltux.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.4.99 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=.3691r?QTjMa4IZ" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=.3691r?QTjMa4IZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Or you could get the devfs patch for the nvidia kernel module found here: http://www.cyber.com.au/users/ashridah/nvidia_1.0.1251_devfs.diff On Tue, 19 Jun 2001 20:11:04 -0400 Anthony DeStefano wrote: > > On Tue, 19 Jun 2001, D. Stimits wrote: > > > > > > > I know this is just a test release, but you should > > > > > know that the nVidia driver available from the nVidia > > > > > website doesn't work when installed on the Redhat > > > > > 7.1-XFS system. > > > > > > > > The nVidia drivers don't work with devfs (as stated in their README), and > > > > the SGI kernels have devfs turned on. Try turning off devfs and see if > > > > that helps. > > > > > > > I can confirm that my working version does NOT use devfs. > > > > ditto. i disabled devfs, since it was hosing other things... > > > > I have the nvidia driver working perfectly fine on my Debian system with the > xfs kernel out of CVS and devfs enabled. Now the Debian devfsd package has > support for adding extra devices in /dev by basically using mknod, chmod, and > chown on options it parses out of a file. So you may want to try the > following in /etc/rc.d/rc.local (NOTE: this was pulled out of the > makedevices.sh from the NVIDIA_kernel tarball) > > > major=195 > > for i in 0 1 2 3; do > devfile="/dev/nvidia$i" > rm -f $devfile > if ! mknod $devfile c $major $i || ! chmod 0666 $devfile; then > echo "Couldn't create device \"$devfile\"." > exit 1 > fi > done > > devfile=/dev/nvidiactl > rm -f $devfile > mknod $devfile c $major 255 > chmod 0666 $devfile > > > Seems to work fine here. > > ~Tony > > > > > -- Thanks, - Zoltan Kraus ________ Windows: A 32 bit hack for a 16 bit operating system, originally written for an 8 bit processor on a 4 bit bus by a 2 bit company that can't stand bit of competition! -------- --=.3691r?QTjMa4IZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7L//Jp0iq+lfR+9YRAldHAJ4uL0+4ZwoQcVVDf3wx20gX0ww0nACdHJso qTxj2Nulz3XUxzcvhyTVKXk= =u6wb -----END PGP SIGNATURE----- --=.3691r?QTjMa4IZ-- From owner-linux-xfs@oss.sgi.com Tue Jun 19 19:26:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5K2Q1E07744 for linux-xfs-outgoing; Tue, 19 Jun 2001 19:26:01 -0700 Received: from io.cox-internet.com (io-cox.cox-internet.com [208.180.118.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5K2Q0V07739 for ; Tue, 19 Jun 2001 19:26:01 -0700 Received: from cdm-143-30-bcs.cox-internet.com ([208.180.143.30]) by io.cox-internet.com (InterMail vK.4.02.00.10 201-232-116-110 license dd72657b95c070b1853187e4f5a0d6a7) with ESMTP id <20010620022452.WNMO29067.io@cdm-143-30-bcs.cox-internet.com>; Tue, 19 Jun 2001 21:24:52 -0500 Subject: Re: turning devfs off From: Michael Vanderford To: Dan Swartzendruber Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.10.99 (Preview Release) Date: 19 Jun 2001 21:29:03 -0500 Message-Id: <993004148.1380.0.camel@cdm-143-30-bcs.cox-internet.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk So how would this read in the lilo.conf file boot=/dev/hd? devfs=nomount Sorry i ask. I would hate to screw this file up. On 18 Jun 2001 22:18:04 -0400, Dan Swartzendruber wrote: > On 18 Jun 2001, Michael Vanderford wrote: > > > Is there an easy way to turn devfs off. > > Thanks in advance. > > either build with it disabled, or in /etc/lilo.conf, append > 'devfs=nomount' to the boot line. > > > From owner-linux-xfs@oss.sgi.com Tue Jun 19 19:41:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5K2fOx09751 for linux-xfs-outgoing; Tue, 19 Jun 2001 19:41:24 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5K2fOV09740 for ; Tue, 19 Jun 2001 19:41:24 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id TAA05532 for ; Tue, 19 Jun 2001 19:41:22 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) 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 MAA20306; Wed, 20 Jun 2001 12:40:04 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Michael Vanderford cc: linux-xfs@oss.sgi.com Subject: Re: turning devfs off In-reply-to: Your message of "19 Jun 2001 21:29:03 EST." <993004148.1380.0.camel@cdm-143-30-bcs.cox-internet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Jun 2001 12:40:04 +1000 Message-ID: <27280.993004804@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 19 Jun 2001 21:29:03 -0500, Michael Vanderford wrote: >So how would this read in the lilo.conf file > >boot=/dev/hd? devfs=nomount image=/test_kernel/2.4.6-pre3-xfs label=2.4.6-pre3-xfs append="devfs=nomount" From owner-linux-xfs@oss.sgi.com Tue Jun 19 20:02:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5K32js13154 for linux-xfs-outgoing; Tue, 19 Jun 2001 20:02:45 -0700 Received: from sphinx.druber.com (druber-gw.lightband.com [216.129.135.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5K32hV13148 for ; Tue, 19 Jun 2001 20:02:43 -0700 Received: from sphinx.druber.com (sphinx.druber.com [10.0.0.2]) by sphinx.druber.com (Postfix) with ESMTP id A5891117; Tue, 19 Jun 2001 22:56:06 -0400 (EDT) Date: Tue, 19 Jun 2001 22:56:06 -0400 (EDT) From: Dan Swartzendruber To: Michael Vanderford Cc: Subject: Re: turning devfs off In-Reply-To: <993004148.1380.0.camel@cdm-143-30-bcs.cox-internet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 19 Jun 2001, Michael Vanderford wrote: > So how would this read in the lilo.conf file > > boot=/dev/hd? devfs=nomount yep From owner-linux-xfs@oss.sgi.com Tue Jun 19 20:18:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5K3IuI15680 for linux-xfs-outgoing; Tue, 19 Jun 2001 20:18:56 -0700 Received: from deliverator.sgi.com ([204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5K3IsV15669 for ; Tue, 19 Jun 2001 20:18:54 -0700 Received: from smack.melbourne.sgi.com (smack.melbourne.sgi.com [134.14.55.210]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA17734 for ; Tue, 19 Jun 2001 20:17:56 -0700 (PDT) mail_from (mg@smack.melbourne.sgi.com) Received: from localhost (mg@localhost) by smack.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id NAA03618; Wed, 20 Jun 2001 13:04:07 +1000 (EST) Date: Wed, 20 Jun 2001 13:04:07 +1000 From: Mike Gigante To: Cliff Wells cc: linux-xfs@oss.sgi.com Subject: Re: nVidia driver incompatible In-Reply-To: <20010619205244.75348.qmail@web13204.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 19 Jun 2001, Cliff Wells wrote: > Hi, > > I know this is just a test release, but you should > know that the nVidia driver available from the nVidia > website doesn't work when installed on the Redhat > 7.1-XFS system. Actually, this is a devfs issue and is actually discussed in the README that comes with the accelerated Nvidia drivers. They suggest re-installing the accelerated drivers each time before starting X. This does work, but even better is to disable devfs In you lilo.conf, add append="devfs=nomount" in the xfs-1.0 section (or in the global section if you like). Mike From owner-linux-xfs@oss.sgi.com Tue Jun 19 22:25:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5K5PMn01654 for linux-xfs-outgoing; Tue, 19 Jun 2001 22:25:22 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5K5PLV01647 for ; Tue, 19 Jun 2001 22:25:21 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id HAA609425 for ; Wed, 20 Jun 2001 07:25:18 +0200 (CEST) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA03204 for linux-xfs@oss.sgi.com; Wed, 20 Jun 2001 15:24:00 +1000 (EST) Date: Wed, 20 Jun 2001 15:24:00 +1000 (EST) From: Timothy Shimmin Message-Id: <200106200524.PAA03204@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - libacl - acl_get_qualifier() change Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This adopts Juergen's suggestion. It changes acl_get_qualifier() to call malloc() to store the qualifier. QA test 058 calls src/acl_test which now calls acl_free() after calling acl_get_qualifier(), and so it will core dump unless the latest libacl is installed. --Tim Date: Tue Jun 19 22:19:09 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:97235a cmd/acl/VERSION - 1.8 - Bump revision to 7 for acl_get_qualifier() change. cmd/acl/libacl/acl.c - 1.11 - Change acl_get_qualifier to dynamically allocate the qualifier, so that acl_free() can operate on it as stated in Posix. This code change was given by Juergen Hasch. cmd/acl/doc/CHANGES - 1.8 - Mention acl_get_qualifier() change for revision 7. cmd/xfstests/src/acl_test.c - 1.4 - Add acl_get_qualifier() tests. cmd/xfstests/058.out - 1.3 - Update for acl_get_qualifier() tests in src/acl_test. From owner-linux-xfs@oss.sgi.com Tue Jun 19 22:42:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5K5g1d04298 for linux-xfs-outgoing; Tue, 19 Jun 2001 22:42:01 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5K5g0V04287 for ; Tue, 19 Jun 2001 22:42:00 -0700 Received: from [192.168.1.10] (helo=den2) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15CakT-0006lT-00; Wed, 20 Jun 2001 17:41:53 +1200 From: "Juha Saarinen" To: "'Russell Cattelan'" Cc: "'Keith Owens'" , "'Steve Lord'" , "'XFS Mailing List'" Subject: RE: Oops removing files on a full f/s Date: Wed, 20 Jun 2001 17:41:51 +1200 Message-ID: <004b01c0f94b$b47788d0$0a01a8c0@den2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <3B2EE9A9.B1C4DBCC@thebarn.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well, looks like you should scratch RH GCC 2.96-85 from the XFS compilers list... Those oopses appear to have been caused by file system corruption (in /var/log/ksymoops this time, according to xfs_repair). Once I fixed that, the oopses stopped. Then I recompiled the CVS code (from this morning NZ time) with kgcc, and the system's been rock-solid despite plenty of fsstress abuse. Am I reading it right, though, that XFS doesn't seem to handle corrupt file systems very well? Is there any way to test this, with the kgcc-compiled kernel? -- Juha From owner-linux-xfs@oss.sgi.com Wed Jun 20 00:52:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5K7qSE17395 for linux-xfs-outgoing; Wed, 20 Jun 2001 00:52:28 -0700 Received: from lsd.nurk.org (lsd.nurk.org [63.172.78.98]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5K7qQV17392 for ; Wed, 20 Jun 2001 00:52:27 -0700 Received: by lsd.nurk.org (MAILER-DAEMON, from userid 507) id 8C9732034DE0; Wed, 20 Jun 2001 00:52:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lsd.nurk.org (MAILER-DAEMON) with ESMTP id 89DB318091C4; Wed, 20 Jun 2001 00:52:28 -0700 (PDT) Date: Wed, 20 Jun 2001 00:52:28 -0700 (PDT) From: Sean Swallow To: Mike Gigante Cc: Cliff Wells , Subject: Re: nVidia driver incompatible In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Or, you can patch the nvidia kernel driver with the patch at http://www.cyber.com.au/users/ashridah/ . I've made an SRPM with this patch too; you can download it at, http://nurk.org/NVIDIA_kernel-1.0-1251devfs.src.rpm cheers, -- Sean J. Swallow pgp (6.5.2) keyfile @ https://nurk.org/keyfile.txt On Wed, 20 Jun 2001, Mike Gigante wrote: > > > On Tue, 19 Jun 2001, Cliff Wells wrote: > > > Hi, > > > > I know this is just a test release, but you should > > know that the nVidia driver available from the nVidia > > website doesn't work when installed on the Redhat > > 7.1-XFS system. > > Actually, this is a devfs issue and is actually discussed in the > README that comes with the accelerated Nvidia drivers. > > They suggest re-installing the accelerated drivers each time before > starting X. This does work, but even better is to disable devfs > > In you lilo.conf, add > > append="devfs=nomount" > > in the xfs-1.0 section (or in the global section if you like). > > Mike > > From owner-linux-xfs@oss.sgi.com Wed Jun 20 03:14:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KAENc27933 for linux-xfs-outgoing; Wed, 20 Jun 2001 03:14:23 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KAEMV27928 for ; Wed, 20 Jun 2001 03:14:22 -0700 Received: from apeiba.wanadoo.fr (smtp-rt-2.wanadoo.fr [193.252.19.154]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA05642 for ; Sun, 17 Jun 2001 10:06:27 -0700 (PDT) mail_from (redhat.angus@wanadoo.fr) Received: from citronier.wanadoo.fr (193.252.19.222) by apeiba.wanadoo.fr; 17 Jun 2001 16:51:26 +0200 Received: from ARennes-301-1-1-233.abo.wanadoo.fr (193.251.66.233) by citronier.wanadoo.fr; 17 Jun 2001 16:51:13 +0200 Subject: RedHat Rawhide + XFS rpm : request From: redhat angus To: linux-xfs@oss.sgi.com Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.10.99 (Preview Release) Date: 17 Jun 2001 16:53:29 +0200 Message-Id: <992789620.14562.0.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk After having installed the package kernel-2.4.5-0.2.9_SGI_XFS_20010613.src.rpm I noted that the option REISERFS_CHECK as for the package RedHat rawhide is activate, inducing a degradation of the performances for the reiserfs filesystem. Blow, one is obliged of compile the kernel with REISERFS_CHECK disabled. Would it be possible to disable this option for your next package kernel ? That would not have any particular impact and would facilitate the life of those which want for example to carry out benchmark. Thank you in advance -David From owner-linux-xfs@oss.sgi.com Wed Jun 20 03:26:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KAQRQ28982 for linux-xfs-outgoing; Wed, 20 Jun 2001 03:26:27 -0700 Received: from frey.edico.si (frey.edico.si [193.189.168.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KAQ0V28888 for ; Wed, 20 Jun 2001 03:26:03 -0700 Received: (qmail 14200 invoked from network); 20 Jun 2001 10:25:41 -0000 Received: from thor.edico.si (HELO wks001) (193.189.168.5) by frey.edico.si with SMTP; 20 Jun 2001 10:25:41 -0000 Message-ID: <001d01c0f973$4ac89af0$8201a8c0@wks001> From: "Branko F. Graèner" To: Subject: XFS merge with linux source tree or new patches Date: Wed, 20 Jun 2001 12:25:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hello i was very impressed with xfs for linux features and performance. becouse it is available only for 2.4.x source tree which is currently not very stable yet, kernel must be upgraded frequently. is there any reason why patches for 2.4.4 and 2.4.5 weren't shiped?... also, is there any problem with linus torwalds or with sgi, that xfs source code isn't merged with kernel source? best regards from slovenia, brane From owner-linux-xfs@oss.sgi.com Wed Jun 20 04:17:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KBHtw03636 for linux-xfs-outgoing; Wed, 20 Jun 2001 04:17:55 -0700 Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KBHtV03625 for ; Wed, 20 Jun 2001 04:17:55 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.2/8.11.2) with ESMTP id f5KBHeg09588; Wed, 20 Jun 2001 07:17:40 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Wed, 20 Jun 2001 07:17:40 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: To: "Branko F. GraXner" cc: Subject: Re: XFS merge with linux source tree or new patches In-Reply-To: <001d01c0f973$4ac89af0$8201a8c0@wks001> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 20 Jun 2001 at 12:25pm, Branko F. GraXner wrote > i was very impressed with xfs for linux features and performance. becouse it > is available only for 2.4.x source tree which is currently not very stable > yet, kernel must be upgraded frequently. is there any reason why patches for > 2.4.4 and 2.4.5 weren't shiped?... At the time of the 1.0 release, 2.4.3 was current (I believe). 1.0 patches *were* released against it. The kernel RPM shipped was based on RedHat's 2.4.2-2, since a RedHat installer was also shipped. Both of these releases were extensively tested. Recently, test patches have been put up for 2.4.5, and the (downloadable) CVS tree is tracking 2.4.6pre. > also, is there any problem with linus torwalds or with sgi, that xfs source > code isn't merged with kernel source? Please read through the archvies and the FAQ -- this has been gone over many times. The plan is for XFS to eventually get into the standard kernel, and they're working on it. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Wed Jun 20 04:36:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KBaME07105 for linux-xfs-outgoing; Wed, 20 Jun 2001 04:36:22 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KBaLV07102 for ; Wed, 20 Jun 2001 04:36:21 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA09812 for ; Sun, 17 Jun 2001 09:32:32 -0700 (PDT) mail_from (alane@geeksrus.net) Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5HEWZE24355 for linux-xfs@oss.sgi.com; Sun, 17 Jun 2001 10:32:35 -0400 Date: Sun, 17 Jun 2001 09:34:18 -0400 From: Alan Eldridge To: Juha Saarinen Subject: Re: Newer patches? Message-ID: <20010617093418.A23096@wwweasel.geeksrus.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from juha@saarinen.org on Sun, Jun 17, 2001 at 11:37:06PM +1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Jun 17, 2001 at 11:37:06PM +1200, Juha Saarinen wrote: >Recently, Russell Cattelan (I think) announced that he had built some >kernel RPMs for the Red Hat Rawhide kernels as well. Search the mailing >archives for details They are on oss.sgi.com as well, in the testing/RHrawhide subdir of the project. I've been using the i686 RPM for 3 days now, on a system with moderate disk activity (lots of compilation), and until this morning, had not problems whatsoever. The system locked up last night while I was asleep, and, being in the screensaver, there were no clues as to the cause of the lockup. Nothing was logged to the log files. Reboot went uneventfully, xfs_repair did its thing quickly and transparently, and system was back up. I have no evidence to suggest that the lockup was or was not XFS related. For all I know, the problem could be related to Glide libs or tdfx kernel module, as I have a Voodoo 5500AGP and there have been documented problems with Glide-related lockups on this video adapter. Russell did a great job. I know it was a lot of work for him, since SGI tracks the "Linus" kernel and RedHat tracks the "AC" kernel, and they have diverged significantly recently (enough to make the job of patch merging a long and trying one, it would seem). I am currently working on a skeleton spec file that can be used to build a set of RPMS from a stock "Linus" kernel plus the appropriate SGI patch file(s). Basically, a "roll-your-own-rpm" kit. I'll try to provide something much (cruder and) simpler for people wanting to build RPMS but not caring if they have all the RH bits. I don't have an ETA yet, as I believe there are some AIC7XXX issues I'm going to encounter, if memory serves me right. -- Alan Eldridge From owner-linux-xfs@oss.sgi.com Wed Jun 20 04:42:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KBgWl08283 for linux-xfs-outgoing; Wed, 20 Jun 2001 04:42:32 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KBgVV08278 for ; Wed, 20 Jun 2001 04:42:31 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5KBgSV24757 for ; Wed, 20 Jun 2001 13:42:29 +0200 Message-Id: <4.3.2.7.2.20010620133826.030d10d0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Jun 2001 13:42:23 +0200 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: FAQ update Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just commited a new FAQ version. Faq is updated and the index is splitted which makes it much more readable. Science has proved that when there are more then 6-7 items in one column it just is not readable. So we now have 6 items with about 5-10 thingies per item. I weeded out some double items and updated some others. It should be on the net in an hour or so when oss checks it out. Bye -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Jun 20 07:23:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KENAp30882 for linux-xfs-outgoing; Wed, 20 Jun 2001 07:23:10 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KEN9V30875 for ; Wed, 20 Jun 2001 07:23:09 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id QAA15932; Wed, 20 Jun 2001 16:23:03 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id QAA08734; Wed, 20 Jun 2001 16:23:02 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id ED40657306; Wed, 20 Jun 2001 16:32:23 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id DE1B325835; Wed, 20 Jun 2001 16:40:41 +0200 (CEST) Message-ID: <3B30B2A6.75743675@ch.sauter-bc.com> Date: Wed, 20 Jun 2001 16:26:46 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: redhat angus Cc: linux-xfs@oss.sgi.com Subject: Re: RedHat Rawhide + XFS rpm : request References: <992789620.14562.0.camel@localhost.localdomain> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Right now my laptop at home is compiling new RPM's of kernel-2.4.5-0.2.9_SGI_XFS_20010613 and of kernel-2.4.2-SGI_XFS_1.0.1 with the following modifications: - REISERFS_CHECK is disabled in all .config files - added Patch for the new Promise Ultra100 TX2 controller (pdc20268 chip) If you are interested in them, please let me know. Simon redhat angus schrieb: > > After having installed the package > kernel-2.4.5-0.2.9_SGI_XFS_20010613.src.rpm I noted that > the option REISERFS_CHECK as for the package RedHat rawhide is activate, > inducing a degradation of the performances for the reiserfs filesystem. > Blow, one is obliged of compile the kernel with 14.10 - Mounting disk images in > Would it be possible to disable this option for your next package kernel > ? > That would not have any particular impact and would facilitate the life > of those which want for example to carry out benchmark. > > Thank you in advance > > -David -- 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 Wed Jun 20 07:40:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KEeRe00852 for linux-xfs-outgoing; Wed, 20 Jun 2001 07:40:27 -0700 Received: from mail.tevox.de ([62.8.161.162]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KEeOV00833 for ; Wed, 20 Jun 2001 07:40:24 -0700 Received: from 200.0.0.14 by mail.tevox.de ([200.0.0.4] running VPOP3) with SMTP for ; Wed, 20 Jun 2001 16:39:45 +0200 From: "Lars Weitze" To: Subject: WG: Date: Wed, 20 Jun 2001 16:40:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: High X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Server: VPOP3 V1.4.0b - Registered to: TEVOX GmbH Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am getting kupdate oops when using XFS. dmesg file attached. Below the Machine stats: Pentium III (Katmai) Linux version 2.4.2-XFS (root@bigmama) (gcc version 2.95.4 20010604 (Debian prerelease)) #6 Tue Jun 19 00:46:48 CEST 2001 total used free shared buffers cached Mem: 255184 253268 1916 0 280 82104 -/+ buffers/cache: 170884 84300 Swap: 1012084 7088 1004996 /dev/hda: Model=Maxtor 98196H8, FwRev=ZAH814Y0, SerialNo=V80HCG9C Config={ Fixed } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57 BuffType=3(DualPortCache), BuffSize=2048kB, MaxMultSect=16, MultSect=16 DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=0 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=160086528 tDMA={min:120,rec:120}, DMA modes: mword0 mword1 mword2 IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode3 mode4 UDMA modes: mode0 mode1 *mode2 mode3 mode4 mode5 -- TEVOX GmbH Neusserstr.772 D-50737 Cologne Germany Voice: +49 (22 1) 974 524 70 Fax: +49 (22 1) 974 524 44 > -----Ursprüngliche Nachricht----- > Von: root [mailto:root@bigmama.tevox.de] > Gesendet: Mittwoch, 20. Juni 2001 16:36 > An: lars@tevox.de > Betreff: > > > Linux version 2.4.2-XFS (root@bigmama) (gcc version 2.95.4 > 20010604 (Debian prerelease)) #6 Tue Jun 19 00:46:48 CEST 2001 > BIOS-provided physical RAM map: > BIOS-e820: 000000000009f800 @ 0000000000000000 (usable) > BIOS-e820: 0000000000000800 @ 000000000009f800 (reserved) > BIOS-e820: 0000000000010000 @ 00000000000f0000 (reserved) > BIOS-e820: 000000000fefd000 @ 0000000000100000 (usable) > BIOS-e820: 0000000000002000 @ 000000000fffd000 (ACPI data) > BIOS-e820: 0000000000001000 @ 000000000ffff000 (ACPI NVS) > BIOS-e820: 0000000000010000 @ 00000000ffff0000 (reserved) > On node 0 totalpages: 65533 > zone(0): 4096 pages. > zone(1): 61437 pages. > zone(2): 0 pages. > Kernel command line: auto BOOT_IMAGE=l ro root=801 > Initializing CPU#0 > Detected 551.257 MHz processor. > Console: colour VGA+ 80x50 > Calibrating delay loop... 1101.00 BogoMIPS > Memory: 255000k/262132k available (1523k kernel code, 6744k > reserved, 449k data, 184k init, 0k highmem) > Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) > Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) > Page-cache hash table entries: 65536 (order: 6, 262144 bytes) > Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) > CPU: Before vendor init, caps: 0383f9ff 00000000 00000000, vendor = 0 > CPU: L1 I cache: 16K, L1 D cache: 16K > CPU: L2 cache: 512K > Intel machine check architecture supported. > Intel machine check reporting enabled on CPU#0. > CPU: After vendor init, caps: 0383f9ff 00000000 00000000 00000000 > CPU: After generic, caps: 0383f9ff 00000000 00000000 00000000 > CPU: Common caps: 0383f9ff 00000000 00000000 00000000 > CPU: Intel Pentium III (Katmai) stepping 03 > Enabling fast FPU save and restore... done. > Enabling unmasked SIMD FPU exception support... done. > Checking 'hlt' instruction... OK. > POSIX conformance testing by UNIFIX > mtrr: v1.37 (20001109) Richard Gooch (rgooch@atnf.csiro.au) > mtrr: detected mtrr type: Intel > PCI: PCI BIOS revision 2.10 entry at 0xf0720, last bus=1 > PCI: Using configuration type 1 > PCI: Probing PCI hardware > Unknown bridge resource 0: assuming transparent > Unknown bridge resource 1: assuming transparent > Unknown bridge resource 2: assuming transparent > PCI: Using IRQ router PIIX [8086/7110] at 00:04.0 > Limiting direct PCI/PCI transfers. > isapnp: Scanning for Pnp cards... > isapnp: No Plug & Play device found > Linux NET4.0 for Linux 2.4 > Based upon Swansea University Computer Society NET3.039 > IA-32 Microcode Update Driver: v1.08 > apm: BIOS version 1.2 Flags 0x0b (Driver version 1.14) > Starting kswapd v1.8 > i2c-core.o: i2c core module > i2c-dev.o: i2c /dev entries driver module > i2c-core.o: driver i2c-dev dummy driver registered. > pty: 256 Unix98 ptys configured > block: queued sectors max/low 169437kB/56479kB, 512 slots per queue > Uniform Multi-Platform E-IDE driver Revision: 6.31 > ide: Assuming 33MHz system bus speed for PIO modes; override with > idebus=xx > PIIX4: IDE controller on PCI bus 00 dev 21 > PIIX4: chipset revision 1 > PIIX4: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio > ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio > hda: Maxtor 98196H8, ATA DISK drive > hdc: Maxtor 98196H8, ATA DISK drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > ide1 at 0x170-0x177,0x376 on irq 15 > hda: 160086528 sectors (81964 MB) w/2048KiB Cache, > CHS=9964/255/63, UDMA(33) > hdc: 160086528 sectors (81964 MB) w/2048KiB Cache, > CHS=158816/16/63, UDMA(33) > Partition check: > hda: hda1 > hdc: hdc1 > Floppy drive(s): fd0 is 1.44M > FDC 0 is a post-1991 82077 > Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ > SERIAL_PCI ISAPNP enabled > ttyS00 at 0x03f8 (irq = 4) is a 16550A > ttyS01 at 0x02f8 (irq = 3) is a 16550A > Real Time Clock Driver v1.10d > SCSI subsystem driver Revision: 1.00 > PCI: Found IRQ 5 for device 00:06.0 > PCI: The same IRQ used for device 00:04.2 > (scsi0) found at PCI 0/6/0 > (scsi0) Wide Channel, SCSI ID=7, 32/255 SCBs > (scsi0) Downloading sequencer code... 392 instructions downloaded > scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0 > > (scsi0:0:0:0) Synchronous at 40.0 Mbyte/sec, offset 15. > Vendor: IBM Model: DGHS18V Rev: 03C0 > Type: Direct-Access ANSI SCSI revision: 03 > (scsi0:0:1:0) Synchronous at 40.0 Mbyte/sec, offset 15. > Vendor: IBM Model: DRHS36V Rev: 0270 > Type: Direct-Access ANSI SCSI revision: 03 > Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 > Detected scsi disk sdb at scsi0, channel 0, id 1, lun 0 > SCSI device sda: 35843670 512-byte hdwr sectors (18352 MB) > sda: sda1 sda2 sda3 > SCSI device sdb: 72170879 512-byte hdwr sectors (36951 MB) > sdb: sdb1 sdb2 sdb3 sdb4 > Linux PCMCIA Card Services 3.1.22 > options: [pci] [cardbus] [pm] > NET4: Linux TCP/IP 1.0 for NET4.0 > IP Protocols: ICMP, UDP, TCP, IGMP > IP: routing cache hash table of 2048 buckets, 16Kbytes > TCP: Hash tables configured (established 16384 bind 16384) > Linux IP multicast router 0.06 plus PIM-SM > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > ds: no socket drivers loaded! > VFS: Mounted root (ext2 filesystem) readonly. > Freeing unused kernel memory: 184k freed > Adding Swap: 1012084k swap-space (priority -1) > PCI: Found IRQ 11 for device 00:0b.0 > 3c59x.c:LK1.1.12 06 Jan 2000 Donald Becker and others. > http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $ > See Documentation/networking/vortex.txt > eth0: 3Com PCI 3c905B Cyclone 100baseTx at 0xb800, > 00:10:5a:ef:be:fd, IRQ 11 > product code 'QP' rev 00.12 date 12-19-98 > 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. > MII transceiver found at address 24, status 786d. > Enabling bus-master transmits and whole-frame receives. > NET4: AppleTalk 0.18a for Linux NET4.0 > NTFS version 000607 > piix4.o version 2.5.5 (20010115) > i2c-dev.o: Registered 'SMBus PIIX4 adapter at e800' as minor 0 > i2c-core.o: adapter SMBus PIIX4 adapter at e800 registered as adapter 0. > i2c-piix4.o: PIIX4 bus detected and initialized > sensors.o version 2.5.5 (20010115) > w83781d.o version 2.5.5 (20010115) > i2c-core.o: driver W83781D sensor driver registered. > i2c-core.o: client [W83781D chip] registered to adapter [SMBus > PIIX4 adapter at e800](pos. 0). > i2c-core.o: client [W83781D subclient] registered to adapter > [SMBus PIIX4 adapter at e800](pos. 1). > i2c-core.o: client [W83781D subclient] registered to adapter > [SMBus PIIX4 adapter at e800](pos. 2). > Start mounting filesystem: ide0(3,1) > Ending clean XFS mount for filesystem: ide0(3,1) > EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended > attempt to access beyond end of device > 08:13: rw=0, want=31198228, limit=26370697 > XFS: size check 2 failed > eth0: using NWAY autonegotiation > Start mounting filesystem: sd(8,19) > Ending clean XFS mount for filesystem: sd(8,19) > Start mounting filesystem: sd(8,20) > Ending clean XFS mount for filesystem: sd(8,20) > pimp forgot to set AF_INET in raw sendmsg. Fix it! > EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended > Unable to handle kernel NULL pointer dereference at virtual > address 00000000 > printing eip: > c0113e7b > *pde = 00000000 > Oops: 0002 > CPU: 0 > EIP: 0010:[] > EFLAGS: 00010092 > eax: c27b1d20 ebx: 00000000 ecx: 00000286 edx: c1453ed0 > esi: c1453ec8 edi: c1452000 ebp: ca5fe9dc esp: c1453eb0 > ds: 0018 es: 0018 ss: 0018 > Process kupdate (pid: 7, stackpage=c1453000) > Stack: c27b1d14 c1453ec8 c0107909 cd0e8ad8 cd0e8ad8 c27b1c00 > 00000001 c1452000 > c27b1d20 00000000 c0107a68 c27b1d14 ffffffff c27b1d14 > c027c7b7 c01b0553 > c27b1d14 ca5fe9dc cd0e8ad8 ca5fe9dc 00000001 00000000 > c27b1d14 00000246 > Call Trace: [] [] [] [] > [] [] [] > [] [] [] [] > [] [] [] [] > > Code: 89 13 51 9d 5b 5e c3 89 f6 9c 58 fa 8b 4a 0c 8b 52 08 89 4a > Unable to handle kernel paging request at virtual address 11000018 > printing eip: > c0122787 > *pde = 00000000 > Oops: 0000 > CPU: 0 > EIP: 0010:[] > EFLAGS: 00010206 > eax: 11000000 ebx: c56d0aec ecx: 6a000000 edx: 00000000 > esi: 6b000000 edi: cd6d0aec ebp: 00000000 esp: cb3fff20 > ds: 0018 es: 0018 ss: 0018 > Process nmbd (pid: 226, stackpage=cb3ff000) > Stack: cb3fff48 00000000 cd6d0ae4 cb3fffa4 00000000 cb3fff48 > c012288c cd6d0a40 > c02db7e0 c485dd60 00000000 c01419b0 cd6d0ae4 00000000 > 00000000 c485dd60 > cd6d0a40 c01404f6 cd6d0a40 00000000 cf845da0 c013a479 > c485dd60 c485dd60 > Call Trace: [] [] [] [] > [] [] > > Code: 8b 40 18 a8 80 74 0f 8b 43 08 8b 40 1c 53 8b 40 18 ff d0 83 From owner-linux-xfs@oss.sgi.com Wed Jun 20 07:51:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KEpN002377 for linux-xfs-outgoing; Wed, 20 Jun 2001 07:51:23 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KEpNV02373 for ; Wed, 20 Jun 2001 07:51:23 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA07796 for ; Wed, 20 Jun 2001 07:51:01 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2210874; Wed, 20 Jun 2001 09:49:15 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA93136; Wed, 20 Jun 2001 09:49:15 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f5KEqZW24415; Wed, 20 Jun 2001 09:52:35 -0500 Message-Id: <200106201452.f5KEqZW24415@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Lars Weitze" cc: linux-xfs@oss.sgi.com Subject: Re: WG: In-Reply-To: Message from "Lars Weitze" of "Wed, 20 Jun 2001 16:40:21 +0200." Content-Transfer-Encoding: 8bit Date: Wed, 20 Jun 2001 09:52:35 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I am getting kupdate oops when using XFS. dmesg file attached. > > Below the Machine stats: > > Pentium III (Katmai) > > Linux version 2.4.2-XFS (root@bigmama) (gcc version 2.95.4 20010604 (Debian > prerelease)) #6 Tue Jun 19 00:46:48 CEST 2001 > You need to decode the oops using ksymoops in order for it to be something we can interpret. ksymoops needs to be able to see kernel symbols to function, you will probably need to pass it at least the -m option to point at the System.map file for the kernel. Also, the 2.4.2 kernel is quite old now and a lot of things have been fixed since then, you might benefit from using one of the patches in the patches directory on the ftp site to get you to 2.4.5, the test rpms for 1.0.1, or the cvs tree which is at 2.4.6-pre3 Steve From owner-linux-xfs@oss.sgi.com Wed Jun 20 10:07:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KH77G10152 for linux-xfs-outgoing; Wed, 20 Jun 2001 10:07:07 -0700 Received: from mailout04.sul.t-online.de (mailout04.sul.t-online.com [194.25.134.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KH74V10149 for ; Wed, 20 Jun 2001 10:07:05 -0700 Received: from fwd00.sul.t-online.de by mailout04.sul.t-online.de with smtp id 15ClRM-0002d6-0J; Wed, 20 Jun 2001 19:06:52 +0200 Received: from t-online.de (340024412816-0001@[217.230.15.246]) by fwd00.sul.t-online.com with esmtp id 15ClRI-0ahThwC; Wed, 20 Jun 2001 19:06:48 +0200 Message-ID: <3B30D838.E7395A25@t-online.de> Date: Wed, 20 Jun 2001 19:07:04 +0200 From: Hasch@t-online.de (Juergen Hasch) X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 To: Timothy Shimmin CC: jtrostel@connex.com, linux-xfs@oss.sgi.com Subject: Re: Samba panic with ACLs References: <3B2F91DE.B3D2AEE1@t-online.de> <20010620105507.O280523@boing.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: 340024412816-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Timothy Shimmin schrieb: > > Hi Juergen and John, > > I think it should be changed to malloc() space for the > qualifier as Juergen suggested. > > The pseudo standard is hard to read as normal (IMHO:), > but it does indicate that we should call acl_free() when > we are done with it. (It does say to do this if it is releasable > memory - but how is the caller supposed to know whether it is > or isn't). > > So we have no choice if we are supposed to call acl_free(). > I will change it unless someone can convince me otherwise :) This is what I was thinking of, I believe it's the right way to do so. A big thank you for adding it so quick !! ...Juergen From owner-linux-xfs@oss.sgi.com Wed Jun 20 10:35:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KHZec10639 for linux-xfs-outgoing; Wed, 20 Jun 2001 10:35:40 -0700 Received: from afaranis1.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KHZdV10636 for ; Wed, 20 Jun 2001 10:35:39 -0700 Received: from [10.2.4.91] ([10.2.4.91]) by afaranis1.afara.com (8.9.3/8.9.3) with ESMTP id KAA18045; Wed, 20 Jun 2001 10:34:47 -0700 (PDT) Subject: Re: FAQ update From: Thomas Duffy To: Seth Mos Cc: linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20010620133826.030d10d0@pop.xs4all.nl> References: <4.3.2.7.2.20010620133826.030d10d0@pop.xs4all.nl> Content-Type: text/plain X-Mailer: Evolution/0.10 (Preview Release) Date: 20 Jun 2001 10:34:38 -0700 Message-Id: <993058478.12047.0.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 20 Jun 2001 13:42:23 +0200, Seth Mos wrote: > Just commited a new FAQ version. > > Faq is updated and the index is splitted which makes it much more readable. > Science has proved that when there are more then 6-7 items in one column it > just is not readable. > > So we now have 6 items with about 5-10 thingies per item. > I weeded out some double items and updated some others. > > It should be on the net in an hour or so when oss checks it out. > > Bye I noticed a couple little things: 1) there are repeats of the first 2 items in the FAQ at the top 2) there is an extra bullet at the end of the list of questions -tduffy From owner-linux-xfs@oss.sgi.com Wed Jun 20 11:42:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KIgxr12109 for linux-xfs-outgoing; Wed, 20 Jun 2001 11:42:59 -0700 Received: from www.quasihorse.com (cs666824-51.austin.rr.com [66.68.24.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KIgwV12106 for ; Wed, 20 Jun 2001 11:42:59 -0700 Received: by www.quasihorse.com (Postfix, from userid 500) id 06B1E6CD; Wed, 20 Jun 2001 13:40:48 -0500 (CDT) Date: Wed, 20 Jun 2001 13:40:47 -0500 From: pac@fortuitous.com To: linux-xfs@oss.sgi.com Subject: Large File support and Glibc 2.X Message-ID: <20010620134047.A24193@bistro.marx> Reply-To: pac@fortuitous.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.17i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Do I need Glibc 2.2 (Linux) to get files larger athan 2³¹ (2 GB) ? I found that i had to upgrade once or twice to get that to work. Someone is telling me that Glibc 2.1.3 will work too. Thanx, -Phil C. .--------------------------------------------------------- | P. A. Carinhas, Ph.D. | pac@fortuitous.com | | Fortuitous Technologies Inc. | http://fortuitous.com | | Linux Training Services | Tel : 1-512 467-2154 | | Contract, In-house, & Onsite | 800 : 1-877 467-2154 | --------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Jun 20 11:50:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KIoTV12330 for linux-xfs-outgoing; Wed, 20 Jun 2001 11:50:29 -0700 Received: from hermes.aoe.vt.edu (IDENT:root@hps.aoe.vt.edu [128.173.191.43]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KIoRV12326 for ; Wed, 20 Jun 2001 11:50:27 -0700 Received: from localhost (jmd@localhost) by hermes.aoe.vt.edu (8.9.3/8.9.3) with ESMTP id OAA06712; Wed, 20 Jun 2001 14:50:25 -0400 Date: Wed, 20 Jun 2001 14:50:25 -0400 (EDT) From: Josh Durham To: pac@fortuitous.com cc: linux-xfs@oss.sgi.com Subject: Re: Large File support and Glibc 2.X In-Reply-To: <20010620134047.A24193@bistro.marx> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f5KIoRV12328 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In the FAQ at http://oss.sgi.com/projects/xfs/faq.html Q: Does XFS support large files (bigger then 2GB)? Yes, XFS supports files larger then 2GB. The large file support (LFS) is largely dependent on the C library of your computer. Glibc 2.2 and higher has full LFS support. If your C lib does not support it you will get errors that the valued is too large for the defined data type. Userland software needs to be compiled against the LFS compliant C lib in order to work. You will be able to create 10GB files on non LFS systems but the tools will not be able to stat them. Distributions based on Glibc 2.2.x and higher will function normally. Note that some userspace programs like tcsh do not correctly behave even if they are compiled against glibc 2.2.x You may need to contact your vendor/developer if this is the case. - Josh On Wed, 20 Jun 2001 pac@fortuitous.com wrote: > > Do I need Glibc 2.2 (Linux) to get files larger athan 2³¹ (2 GB) ? > I found that i had to upgrade once or twice to get that to work. > Someone is telling me that Glibc 2.1.3 will work too. > Thanx, > -Phil C. > .--------------------------------------------------------- > | P. A. Carinhas, Ph.D. | pac@fortuitous.com | > | Fortuitous Technologies Inc. | http://fortuitous.com | > | Linux Training Services | Tel : 1-512 467-2154 | > | Contract, In-house, & Onsite | 800 : 1-877 467-2154 | > --------------------------------------------------------- > From owner-linux-xfs@oss.sgi.com Wed Jun 20 12:58:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KJwcg13389 for linux-xfs-outgoing; Wed, 20 Jun 2001 12:58:38 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KJwbV13385 for ; Wed, 20 Jun 2001 12:58:37 -0700 Received: from chuckle.americas.sgi.com (chuckle.americas.sgi.com [128.162.184.123]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA01102 for ; Wed, 20 Jun 2001 12:58:36 -0700 (PDT) mail_from (sandeen@sgi.com) Received: (from sandeen@localhost) by chuckle.americas.sgi.com (8.12.0.Beta7/8.12.0.Beta7) id f5KJwW7p002528 for linux-xfs@oss.sgi.com; Wed, 20 Jun 2001 14:58:32 -0500 Date: Wed, 20 Jun 2001 14:58:32 -0500 From: Eric Sandeen Message-Id: <200106201958.f5KJwW7p002528@chuckle.americas.sgi.com> Subject: TAKE - page_lock spinlock init conditional on kernel version Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Jun 20 12:56:33 PDT 2001 Workarea: chuckle.americas.sgi.com:/export/xfs1/eric/linux-2.4-xfs/workarea This spinlock went away after 2.4.4, so the init isn't needed after that. But since we're still merging back to pre-2.4.4, we'll make it conditional on the kernel version for now, to save back-porters some grief. The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:97373a linux/fs/pagebuf/page_buf_locking.c - 1.13 - Make page_lock spinlock init dependent on kernel version (we can lose this again down the road...) From owner-linux-xfs@oss.sgi.com Wed Jun 20 14:09:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KL9Ha20166 for linux-xfs-outgoing; Wed, 20 Jun 2001 14:09:17 -0700 Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KL9GV20163 for ; Wed, 20 Jun 2001 14:09:16 -0700 Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:61424 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Wed, 20 Jun 2001 23:09:13 +0200 Message-Id: <4.3.2.7.2.20010620230647.031f85e8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Jun 2001 23:08:43 +0200 To: Thomas Duffy From: Seth Mos Subject: Re: FAQ update Cc: linux-xfs@oss.sgi.com In-Reply-To: <993058478.12047.0.camel@tduffy-lnx.afara.com> References: <4.3.2.7.2.20010620133826.030d10d0@pop.xs4all.nl> <4.3.2.7.2.20010620133826.030d10d0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10:34 20-6-2001 -0700, Thomas Duffy wrote: >On 20 Jun 2001 13:42:23 +0200, Seth Mos wrote: > > Just commited a new FAQ version. > > > > Faq is updated and the index is splitted which makes it much more readable. > > Science has proved that when there are more then 6-7 items in one > column it > > just is not readable. > > > > So we now have 6 items with about 5-10 thingies per item. > > I weeded out some double items and updated some others. > > > > It should be on the net in an hour or so when oss checks it out. > > > > Bye > >I noticed a couple little things: > >1) there are repeats of the first 2 items in the FAQ at the top Fixed, merge issue when splitting the index in parts. >2) there is an extra bullet at the end of the list of questions a
  • that should have been a
    • . It just that your browser thinks that a new item starts here in that case. Cheerio, ps: my new mobo may arive tommorow already. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Jun 21 04:30:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LBUwB03025 for linux-xfs-outgoing; Thu, 21 Jun 2001 04:30:58 -0700 Received: from relay2.flashnet.it (libra.cyb.it [212.11.95.209]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LBUtV03019 for ; Thu, 21 Jun 2001 04:30:56 -0700 Received: from ip038.pool-04.cyb.it (ip038.pool-04.cyb.it [195.191.3.167]) by relay2.flashnet.it (EMS-RELAY/8.10.0) with SMTP id f5LBUeM17024 for ; Thu, 21 Jun 2001 13:30:40 +0200 From: daedalus@freemail.it To: linux-xfs@oss.sgi.com Subject: Re: XFS 1.0.1 testing Date: Thu, 21 Jun 2001 13:39:00 +0200 Message-ID: References: <3B2ECC33.9514CDB5@sgi.com> In-Reply-To: <3B2ECC33.9514CDB5@sgi.com> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5LBUvV03022 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 18 Jun 2001 22:51:15 -0500, Eric Sandeen wrote: >If any of the Mandrake/SuSE/Debian people on the list want to package >kernels for those distros, let me know, and I'll keep you up to date on >the status of the patches so we can put out unsupported/unofficial >kernel packages for them as well. I am not an official packager, but I dare to say I am both a power user and an everlasting newbie :-) I have made a set of 2 floppy disk (minix fs) images (boot 1440 and root 1600), derived from bare.i and color.gz, featuring a Slackware 8.0.0 (not yet released) installer. I like slackware beacuse it is featuring glibc-2.2.3, binutils-2.11.90.0.15, gcc-2.95.3, so it makes building linux-xfs code easy: I am a maniac of the "make install"! :) I have added XFS, so I can choose between ext2, xfs and reiserfs at install-time. I have used a Slackware-current on ext2, to build anything from tars and patches from XFS 1.0.1 testing, so this big kernel is supporting xfs and many fs. mkfs.xfs is not linked to any liblvm. the kernel has no support for debugging. All of the cmd_tars have to built once you get the system up and running, beacause only mkfs.xfs is provided and it is avaible only during installation. I don't know if this stuff is really useful to the end users, but I have used it at home and it does seem to work for my bare, intel based with only 1 ide hd, desktop pc of course the first kernel is to be installed to the target partition from the bootdisk and not from the packages ide or scsi. I don't know if the official modules will be loadable in such kernel... I mean it is very close to the config.gz of the official bare.i disk, but it misses System.map.gz and some fs modules are already built in. I hope it is 100% compatible with an official Slackware-current set. anyway I hope you will take a look and test and do whatever you want with this stuff at http://village.flashnet.it/users/fn048069/files/XFS/ From owner-linux-xfs@oss.sgi.com Thu Jun 21 06:49:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LDnHH07669 for linux-xfs-outgoing; Thu, 21 Jun 2001 06:49:17 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LDnFV07664 for ; Thu, 21 Jun 2001 06:49:15 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA01637 for ; Sun, 17 Jun 2001 13:59:18 -0700 (PDT) mail_from (knuffie@xs4all.nl) Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA09141; Sun, 17 Jun 2001 22:58:17 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA00332; Sun, 17 Jun 2001 22:58:17 +0200 (CEST) Date: Sun, 17 Jun 2001 22:58:17 +0200 (CEST) From: Seth Mos To: Knuth Posern cc: linux-xfs@oss.sgi.com Subject: Re: XFS at all? AND XFS and gcc ?! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 17 Jun 2001, Knuth Posern wrote: > Hi. > > I would like to build a Software RAID-5. I don't have a > backup of my data (because it is too much data and backup-solutions are > too expansive for a student). That's why I want to use a Software-RAID-5 > with redundancy. > > But what FS to use? > > Thats the point where XFS comes to play. Ext2 would be too slow with > fsck.ext2! - That's why it has to be a Journaling Filesystem. > > I know you said: You don't recommend to use XFS in > productivity-environments. > > But would you recommend me to NOT use XFS for my RAID-5, because with a > little bug all my data could be lost?!?!?! - Or are there versions which > are stable enough. If XFS is not PERFECT at the moment and needs debugging > would be o.k. for me and I would try to help you improving it. But it must > be at least a bit SAVE against (complete) DATA-LOSS... I use XFS on my home system since the 2.4.0-test kernels came out and have not suffered data as of yet. (knock on wood). I have no expierence about XFS over Raid5. I have the number of disks for it but unfortunately not the time to test it. I have to get rid of one system before I can put my backup machine to action. There are already a fair number of people out there using it. I at work even have it working in my production environment with good succes. YMMV when using it. If something goes wring with a XFS system you will notic fairly soon. It will either not mount or crash. The utilities on the FS are relatively mature so they can save you in some cases. The only problems with md is running in degraded mode. But it does work. > I tried to build a 2.4.3-XFS kernel (but failed with the gcc - see > below). How UNsafe is 2.4.3-XFS against 2.4.2-XFS? And when will there be > an update which supports 2.4.4 or 2.4.5? It is on the FTP site. ftp://oss.sgi.com/projects/xfs/download/patches/ The cvs tree is currently at 2.4.6-pre3. > O.k. you wrote in your FAQ: about gcc 2.95: Hmmm there may be > problems ... but under Debian... and... ?!?! Most people reported succes with 2.95.3+ and there have been some fixes for the tree for compiling with newer kernels. > So what? - Is it possible to use the gcc 3.0 or gcc 2.96 or do I have to > use the old 2.91.66 at the moment? And is there a x in 2.95.x which is > safe to use with the XFS-kernel? 3.0 is untested, if someone did try to compile it let me know. It is also largely untested for the rest of the kernel. It's almost released but not just yet. > And how long will it take till it is save to use the newer 2.95.x or 2.96 > gcc-version?! 2.96 needs to be tested fr some cases. I'd rather skip the work on 2.96 and start on 3 when it will be released. > I tried to get the 2.91.66 C and C++ compiler installed on my system. But > it failed. And I don't know exactly why... Try compiling the tree first with your native compiler and see what happens. Debian should work ok. And if you are on debian there are probably debs out there that you can fetch the pre made compiler. Bye From owner-linux-xfs@oss.sgi.com Thu Jun 21 06:59:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LDxkG07932 for linux-xfs-outgoing; Thu, 21 Jun 2001 06:59:46 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LDxiV07929 for ; Thu, 21 Jun 2001 06:59:44 -0700 Received: from mailhost.Mathematik.Uni-Marburg.de (pc12418.Mathematik.Uni-Marburg.DE [137.248.123.44]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA07403 for ; Sun, 17 Jun 2001 12:30:26 -0700 (PDT) mail_from (posern@Mathematik.Uni-Marburg.de) Received: from su1239.Mathematik.Uni-Marburg.DE (posern@hadar [137.248.122.55]) by mailhost.Mathematik.Uni-Marburg.de (8.11.0/8.11.0) with ESMTP id f5HJPLQ20998; Sun, 17 Jun 2001 21:25:21 +0200 Received: from localhost (posern@localhost) by su1239.Mathematik.Uni-Marburg.DE (8.9.3/8.9.3) with ESMTP id VAA25612; Sun, 17 Jun 2001 21:25:22 +0200 (MET DST) X-Authentication-Warning: hadar.Mathematik.Uni-Marburg.DE: posern owned process doing -bs Date: Sun, 17 Jun 2001 21:25:22 +0200 (MET DST) From: Knuth Posern X-Sender: posern@hadar To: linux-xfs@oss.sgi.com cc: seth.mos@xs4all.nl Subject: XFS at all? AND XFS and gcc ?! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi. I would like to build a Software RAID-5. I don't have a backup of my data (because it is too much data and backup-solutions are too expansive for a student). That's why I want to use a Software-RAID-5 with redundancy. But what FS to use? Thats the point where XFS comes to play. Ext2 would be too slow with fsck.ext2! - That's why it has to be a Journaling Filesystem. I know you said: You don't recommend to use XFS in productivity-environments. But would you recommend me to NOT use XFS for my RAID-5, because with a little bug all my data could be lost?!?!?! - Or are there versions which are stable enough. If XFS is not PERFECT at the moment and needs debugging would be o.k. for me and I would try to help you improving it. But it must be at least a bit SAVE against (complete) DATA-LOSS... --- I tried to build a 2.4.3-XFS kernel (but failed with the gcc - see below). How UNsafe is 2.4.3-XFS against 2.4.2-XFS? And when will there be an update which supports 2.4.4 or 2.4.5? --- O.k. you wrote in your FAQ: about gcc 2.95: Hmmm there may be problems ... but under Debian... and... ?!?! So what? - Is it possible to use the gcc 3.0 or gcc 2.96 or do I have to use the old 2.91.66 at the moment? And is there a x in 2.95.x which is safe to use with the XFS-kernel? And how long will it take till it is save to use the newer 2.95.x or 2.96 gcc-version?! I tried to get the 2.91.66 C and C++ compiler installed on my system. But it failed. And I don't know exactly why... We tried to build egcs-1.1.2 C and C++ on TWO different systems: A) SuSE 7.2 with kernel 2.4.4 gcc-2.95.3-52 gnu-libc6-2.2.2-38 gnu-libc-devel-2.2.2-38 B) Debian unstable with kernel 2.2.17 gcc-2.95.4-1 gnu-libc6-2.2.3-6 gnu-libc6-devel-2.2.3-6 We downloaded: egcs-core-1.1.2.tar.bz2 egcs-g++-1.1.2.tar.bz2 Extracted it, mkdir , cd , /configure. This built a Makefile for the target-system: i586-pc-linux-gnu. "make bootstrap" on bouth machines A and B in brought the following error-messages: make[2]: Leaving directory `/usr/src/prg/gcc/egcs-1.1.2_objdir/i586-pc-linux-gnumake[2]: Entering directory `/usr/src/prg/gcc/egcs-1.1.2_objdir/i586-pc-linux-gntest x"no" != xyes || \ /usr/src/prg/gcc/egcs-1.1.2_objdir/gcc/xgcc -B/usr/src/prg/gcc/egcs-1.1.2_objd/usr/src/prg/gcc/egcs-1.1.2_objdir/gcc/xgcc -B/usr/src/prg/gcc/egcs-1.1.2 _objdir/usr/src/prg/gcc/egcs-1.1.2/libio/indstream.cc: In method `struct streampos indi/usr/src/prg/gcc/egcs-1.1.2/libio/indstream.cc:82: `struct streampos' used where/usr/src/prg/gcc/egcs-1.1.2/libio/indstream.cc:85: `struct streampos' used where/usr/src/prg/gcc/egcs-1.1.2/libio/indstream.cc:87: `struct streampos' used where/usr/src/prg/gcc/egcs-1.1.2/libio/indstream.cc:89: conversion from `int' to non-/usr/src/prg/gcc/egcs-1.1.2/libio/indstream.cc: In method `struct streampos indi/usr/src/prg/gcc/egcs-1.1.2/libio/indstream.cc:99: `struct streampos' used where/usr/src/prg/gcc/egcs-1.1.2/libio/indstream.cc:102: `struct streampos' used wher/usr/src/prg/gcc/egcs-1.1.2/libio/indstream.cc:104: `struct streampos' used wher/usr/src/prg/gcc/egcs-1.1.2/libio/indstream.cc:106: conversion from `int' to nonmake[2]: *** [indstream.o] Error 1 make[2]: Leaving directory `/usr/src/prg/gcc/egcs-1.1.2_objdir/i586-pc-linux-gnumake[1]: *** [all-target-libio] Error 2 make[1]: Leaving directory `/usr/src/prg/gcc/egcs-1.1.2_objdir' _______________________________________________________________ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ But what went wrong ??? Help would be very apreciated!! Greetings, Knuth Posern. From owner-linux-xfs@oss.sgi.com Thu Jun 21 07:36:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LEavQ08741 for linux-xfs-outgoing; Thu, 21 Jun 2001 07:36:57 -0700 Received: from grumpy.ekky.org (kbl-ternzn181.zeelandnet.nl [62.238.32.181]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LEatV08738 for ; Thu, 21 Jun 2001 07:36:56 -0700 Received: from sneezy.ekky.org (sneezy.ekky.org [192.168.1.102]) by grumpy.ekky.org (8.11.2/8.11.2) with ESMTP id f5LEam303782 for ; Thu, 21 Jun 2001 16:36:49 +0200 Date: Thu, 21 Jun 2001 16:35:43 +0200 (CEST) From: Reggy Ekkebus To: Subject: Xfs Compile problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I have a problem compileing Xfs with linux-2.4.2. I installed XFS with the XFS+RH7.1 ISO and that works great, but when I try to compile the kernel I get the following error(s): xfs_bmap.c:543:9: warning: pasting "." and "xs_add_exlist" does not give a valid preprocessing token xfs_bmap.c:2830:9: warning: pasting "." and "xs_del_exlist" does not give a valid preprocessing token xfs_bmap.c: In function `xfs_bmap_alloc': xfs_bmap.c:2721: Unrecognizable insn: (insn/i 137 3604 3598 (parallel[ (set (reg:SI 0 eax) (asm_operands ("") ("=a") 0[ (reg:DI 1 edx) ] [ (asm_input:DI ("A")) ] ("linux/xfs_linux.h") 287)) (set (reg:SI 1 edx) (asm_operands ("") ("=d") 1[ (reg:DI 1 edx) ] [ (asm_input:DI ("A")) ] ("linux/xfs_linux.h") 287)) (clobber (reg:QI 19 dirflag)) (clobber (reg:QI 18 fpsr)) (clobber (reg:QI 17 flags)) ] ) -1 (nil) (nil)) xfs_bmap.c:2721: confused by earlier errors, bailing out make[3]: *** [xfs_bmap.o] Error 2 make[2]: *** [first_rule] Error 2 make[1]: *** [_subdir_xfs] Error 2 make: *** [_dir_fs] Error 2 ------------------ If you need any additional information please mail me back. Best Regards, Reggy Ekkebus From owner-linux-xfs@oss.sgi.com Thu Jun 21 07:37:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LEbma08853 for linux-xfs-outgoing; Thu, 21 Jun 2001 07:37:48 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LEblV08850 for ; Thu, 21 Jun 2001 07:37:48 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id E7B721E7EE; Thu, 21 Jun 2001 16:37:41 +0200 (MEST) Date: Thu, 21 Jun 2001 16:37:36 +0200 From: Andi Kleen To: Knuth Posern Cc: linux-xfs@oss.sgi.com Subject: Re: XFS at all? AND XFS and gcc ?! Message-ID: <20010621163736.A14051@gruyere.muc.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from posern@Mathematik.Uni-Marburg.de on Sun, Jun 17, 2001 at 09:25:22PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk It's very simple: Software or any RAID is definitely not a replacement for backups. If you care about your data, always backup it. If you don't care about it feel free to use experimental software to store it, like XFS, but when you should lose it later blame nobody but yourself. -Andi From owner-linux-xfs@oss.sgi.com Thu Jun 21 07:45:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LEjbr09081 for linux-xfs-outgoing; Thu, 21 Jun 2001 07:45:37 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LEjaV09078 for ; Thu, 21 Jun 2001 07:45:36 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5LEiUB16087; Thu, 21 Jun 2001 10:44:30 -0400 Date: Thu, 21 Jun 2001 10:44:29 -0400 From: Alan Eldridge To: Reggy Ekkebus Cc: linux-xfs@oss.sgi.com Subject: Re: Xfs Compile problem Message-ID: <20010621104429.A13589@wwweasel.geeksrus.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from reggy@ekky.org on Thu, Jun 21, 2001 at 04:35:43PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Jun 21, 2001 at 04:35:43PM +0200, Reggy Ekkebus wrote: > >Hello, > > >I have a problem compileing Xfs with linux-2.4.2. >I installed XFS with the XFS+RH7.1 ISO and that works great, >but when I try to compile the kernel I get the following error(s): > > >xfs_bmap.c:543:9: warning: pasting "." and "xs_add_exlist" does not give a >valid preprocessing token >xfs_bmap.c:2830:9: warning: pasting "." and "xs_del_exlist" does not give >a valid preprocessing token This looks like RH's gcc-2.96, or is it gcc-3.0? Try using: CC=kgcc rpm -ba kernel-....spec That particular diagnostic message post-dates gcc-2.95, IIRC. >xfs_bmap.c: In function `xfs_bmap_alloc': >xfs_bmap.c:2721: Unrecognizable insn: >(insn/i 137 3604 3598 (parallel[ > (set (reg:SI 0 eax) > (asm_operands ("") ("=a") 0[ > (reg:DI 1 edx) > ] That's pretty cool. That's a compiler back-end bug. Which architecture are you building? i686? Athlon? If it's RH gcc-2.96, then you can bugzilla it (http://bugzilla.redhat.com), but given that 3.0 is out it probably won't get fixed in 2.96. If it's gcc-3.0, then you need to follow the instructions on the gcc pages for submitting a compiler bug report (making the dump files, etc). See http://gcc.gnu.org/ to get started. -- Alan Eldridge From owner-linux-xfs@oss.sgi.com Thu Jun 21 07:55:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LEtGO09392 for linux-xfs-outgoing; Thu, 21 Jun 2001 07:55:16 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LEtEV09387 for ; Thu, 21 Jun 2001 07:55:14 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5LEt9V29251; Thu, 21 Jun 2001 16:55:11 +0200 Message-Id: <4.3.2.7.2.20010621165320.039804c8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Jun 2001 16:55:03 +0200 To: Reggy Ekkebus , From: Seth Mos Subject: Re: Xfs Compile problem In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 16:35 21-6-2001 +0200, Reggy Ekkebus wrote: >Hello, > > >I have a problem compileing Xfs with linux-2.4.2. >I installed XFS with the XFS+RH7.1 ISO and that works great, >but when I try to compile the kernel I get the following error(s): This is a problenm in earlier kernels (2.4.2) that barfs in compilers other then 2.91.66 (kgcc / egcs 1.1.2) See the FAQ for details under Build issues. in short, edit Makefile to use kgcc. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Jun 21 07:57:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LEvYT09526 for linux-xfs-outgoing; Thu, 21 Jun 2001 07:57:34 -0700 Received: from grumpy.ekky.org (kbl-ternzn181.zeelandnet.nl [62.238.32.181]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LEvXV09523 for ; Thu, 21 Jun 2001 07:57:33 -0700 Received: from sneezy.ekky.org (sneezy.ekky.org [192.168.1.102]) by grumpy.ekky.org (8.11.2/8.11.2) with ESMTP id f5LEsH303807; Thu, 21 Jun 2001 16:54:17 +0200 Date: Thu, 21 Jun 2001 16:53:11 +0200 (CEST) From: Reggy Ekkebus To: Alan Eldridge cc: Subject: Re: Xfs Compile problem In-Reply-To: <20010621104429.A13589@wwweasel.geeksrus.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 21 Jun 2001, Alan Eldridge wrote: Thanks for the fast answering > > > >I have a problem compileing Xfs with linux-2.4.2. > >I installed XFS with the XFS+RH7.1 ISO and that works great, > >but when I try to compile the kernel I get the following error(s): > > > > > >xfs_bmap.c:543:9: warning: pasting "." and "xs_add_exlist" does not give a > >valid preprocessing token > >xfs_bmap.c:2830:9: warning: pasting "." and "xs_del_exlist" does not give > >a valid preprocessing token > > This looks like RH's gcc-2.96, or is it gcc-3.0? Try using: > > CC=kgcc rpm -ba kernel-....spec > > That particular diagnostic message post-dates gcc-2.95, IIRC. > I'm now trying kgcc. I linked /usr/bin/gcc to /usr/bin/kgcc, so that must be the problem. If it doesn't work, i'll be submitting a bug report. > >xfs_bmap.c: In function `xfs_bmap_alloc': > >xfs_bmap.c:2721: Unrecognizable insn: > >(insn/i 137 3604 3598 (parallel[ > > (set (reg:SI 0 eax) > > (asm_operands ("") ("=a") 0[ > > (reg:DI 1 edx) > > ] > > That's pretty cool. That's a compiler back-end bug. Which architecture are > you building? i686? Athlon? I'm buiding on AMD Athlon Thunderbird > If it's RH gcc-2.96, then you can bugzilla it (http://bugzilla.redhat.com), > but given that 3.0 is out it probably won't get fixed in 2.96. > > If it's gcc-3.0, then you need to follow the instructions on the gcc pages > for submitting a compiler bug report (making the dump files, etc). See > http://gcc.gnu.org/ to get started. > > Best Regards, Reggy Ekkebus From owner-linux-xfs@oss.sgi.com Thu Jun 21 08:06:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LF64W09794 for linux-xfs-outgoing; Thu, 21 Jun 2001 08:06:04 -0700 Received: from grumpy.ekky.org (kbl-ternzn181.zeelandnet.nl [62.238.32.181]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LF62V09790 for ; Thu, 21 Jun 2001 08:06:03 -0700 Received: from sneezy.ekky.org (sneezy.ekky.org [192.168.1.102]) by grumpy.ekky.org (8.11.2/8.11.2) with ESMTP id f5LF5t303871 for ; Thu, 21 Jun 2001 17:05:55 +0200 Date: Thu, 21 Jun 2001 17:04:50 +0200 (CEST) From: Reggy Ekkebus To: Subject: Why isn't XFS included in mainstreem kernels, provided by www.kernel.org??? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk See topic :) Best Regards, Reggy Ekkebus From owner-linux-xfs@oss.sgi.com Thu Jun 21 08:12:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LFCaZ09966 for linux-xfs-outgoing; Thu, 21 Jun 2001 08:12:36 -0700 Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LFCZV09963 for ; Thu, 21 Jun 2001 08:12:35 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.2/8.11.2) with ESMTP id f5LFBlO13619; Thu, 21 Jun 2001 11:12:15 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 21 Jun 2001 11:11:46 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: To: Reggy Ekkebus cc: Subject: Re: Why isn't XFS included in mainstreem kernels, provided by www.kernel.org??? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 21 Jun 2001 at 5:04pm, Reggy Ekkebus wrote > See topic :) Why didn't you read the FAQ before posting to the mailing list? http://oss.sgi.com/projects/xfs/faq.html#linuskernel -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu Jun 21 08:31:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LFVra10373 for linux-xfs-outgoing; Thu, 21 Jun 2001 08:31:53 -0700 Received: from grumpy.ekky.org (kbl-ternzn181.zeelandnet.nl [62.238.32.181]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LFVpV10369 for ; Thu, 21 Jun 2001 08:31:51 -0700 Received: from sneezy.ekky.org (sneezy.ekky.org [192.168.1.102]) by grumpy.ekky.org (8.11.2/8.11.2) with ESMTP id f5LFUb303900; Thu, 21 Jun 2001 17:30:37 +0200 Date: Thu, 21 Jun 2001 17:29:32 +0200 (CEST) From: Reggy Ekkebus To: Steve Lord cc: Subject: Re: Xfs Compile problem In-Reply-To: <200106211520.KAA32147@daisy-e185.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 21 Jun 2001, Steve Lord wrote: > > Hi, > > You either need an older compiler (install compat-egcs-6.2-1.1.2.14 on > redhat 7.1 and use kgcc to build), or a newer kernel. The xfs code > appears to stretch the compiler to its limits and break it in a few > places. Some people have reported problems with xfs and the gcc in > RedHat 7.1. I have been running OK with it for a while, but I just > bumped up to the latest rawhide version. I have also tried gcc 3.0 > and it mostly works, I have at least one code section which it messes > up register assignments - in general gcc and 64 bit assignments can > tend to lead to it forgetting it has reused a register. > > The particular problem in xfs_bmap.c is worked around in the latest > cvs tree, there are also kernel patches against newer kernels here: > > ftp://oss.sgi.com/projects/xfs/download/patches/ > > and newer rpms here: > > ftp://oss.sgi.com/projects/xfs/download/testing/Release-1.0.1-PR1/ > > Steve > > > > > > Hello, > > > > > > I have a problem compileing Xfs with linux-2.4.2. > > I installed XFS with the XFS+RH7.1 ISO and that works great, > > but when I try to compile the kernel I get the following error(s): > > > > > > xfs_bmap.c:543:9: warning: pasting "." and "xs_add_exlist" does not give a > > valid preprocessing token > > xfs_bmap.c:2830:9: warning: pasting "." and "xs_del_exlist" does not give > > a valid preprocessing token > > xfs_bmap.c: In function `xfs_bmap_alloc': > > xfs_bmap.c:2721: Unrecognizable insn: > > (insn/i 137 3604 3598 (parallel[ > > (set (reg:SI 0 eax) > > (asm_operands ("") ("=a") 0[ > > (reg:DI 1 edx) > > ] > > [ > > (asm_input:DI ("A")) > > ] ("linux/xfs_linux.h") 287)) > > (set (reg:SI 1 edx) > > (asm_operands ("") ("=d") 1[ > > (reg:DI 1 edx) > > ] > > [ > > (asm_input:DI ("A")) > > ] ("linux/xfs_linux.h") 287)) > > (clobber (reg:QI 19 dirflag)) > > (clobber (reg:QI 18 fpsr)) > > (clobber (reg:QI 17 flags)) > > ] ) -1 (nil) > > (nil)) > > xfs_bmap.c:2721: confused by earlier errors, bailing out > > make[3]: *** [xfs_bmap.o] Error 2 > > make[2]: *** [first_rule] Error 2 > > make[1]: *** [_subdir_xfs] Error 2 > > make: *** [_dir_fs] Error 2 > > > > ------------------ > > > > If you need any additional information please mail me back. > > > > > > > > Best Regards, > > > > > > Reggy Ekkebus > > From owner-linux-xfs@oss.sgi.com Thu Jun 21 08:48:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LFmKr10891 for linux-xfs-outgoing; Thu, 21 Jun 2001 08:48:20 -0700 Received: from linux.compucomis.net (linux.CompuComIS.net [216.140.122.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LFmBV10883 for ; Thu, 21 Jun 2001 08:48:14 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id 751B813997; Thu, 21 Jun 2001 11:47:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id 7227313993; Thu, 21 Jun 2001 11:47:57 -0400 (EDT) Date: Thu, 21 Jun 2001 11:47:57 -0400 (EDT) From: Mike Burger To: Reggy Ekkebus Cc: Subject: Re: Why isn't XFS included in mainstreem kernels, provided by www.kernel.org??? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Because Linus Torvalds has not yet seen fit to include it in the mainstream kernel source. Nuff said. On Thu, 21 Jun 2001, Reggy Ekkebus wrote: > See topic :) > > > Best Regards, > > > Reggy Ekkebus > > From owner-linux-xfs@oss.sgi.com Thu Jun 21 08:49:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LFnS411003 for linux-xfs-outgoing; Thu, 21 Jun 2001 08:49:28 -0700 Received: from grumpy.ekky.org (kbl-ternzn181.zeelandnet.nl [62.238.32.181]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LFnRV11000 for ; Thu, 21 Jun 2001 08:49:27 -0700 Received: from sneezy.ekky.org (sneezy.ekky.org [192.168.1.102]) by grumpy.ekky.org (8.11.2/8.11.2) with ESMTP id f5LFnK303918 for ; Thu, 21 Jun 2001 17:49:20 +0200 Date: Thu, 21 Jun 2001 17:48:14 +0200 (CEST) From: Reggy Ekkebus To: Subject: Can XFS be used on a production machine Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, This time a read the FAQ, but It's not completely clear to me, because the answer in the FAQ says it's stable, but it also says it's unstable. So my question is, is it stable for a server in a company with about 10 people working. The server will be a file server and will not be very busy. I don't want to reinstall the server every year. Best Regards, Reggy Ekkebus From owner-linux-xfs@oss.sgi.com Thu Jun 21 08:50:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LFoRs11123 for linux-xfs-outgoing; Thu, 21 Jun 2001 08:50:27 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LFoMV11119 for ; Thu, 21 Jun 2001 08:50:22 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA04412 for ; Thu, 21 Jun 2001 08:50:21 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2213665 for ; Thu, 21 Jun 2001 10:49:06 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA86909 for ; Thu, 21 Jun 2001 10:49:05 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f5LFqek13793; Thu, 21 Jun 2001 10:52:40 -0500 Message-Id: <200106211552.f5LFqek13793@jen.americas.sgi.com> Date: Thu, 21 Jun 2001 10:52:40 -0500 Subject: TAKE - merge up to 2.4.6-pre5 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk merge up to 2.4.6-pre5, should show up in cvs sometime today, however, internal machines involved in the cvs update are being relocated today due to office moves, so it may get delayed a while. Date: Thu Jun 21 08:45:04 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:97445a linux/drivers/acpi/ospm/ec/ecgpe.c - 1.1 linux/drivers/acpi/executer/exstore.c - 1.1 linux/drivers/acpi/ospm/ec/ec_osl.c - 1.1 linux/drivers/acpi/ospm/ec/Makefile - 1.1 linux/drivers/acpi/ospm/include/pr.h - 1.1 linux/drivers/acpi/ospm/button/bn_osl.c - 1.1 linux/drivers/acpi/utilities/utxface.c - 1.1 linux/drivers/acpi/utilities/utobject.c - 1.1 linux/drivers/acpi/utilities/utmisc.c - 1.1 linux/drivers/acpi/utilities/utinit.c - 1.1 linux/drivers/acpi/utilities/utglobal.c - 1.1 linux/drivers/acpi/utilities/uteval.c - 1.1 linux/drivers/acpi/utilities/utdelete.c - 1.1 linux/arch/alpha/lib/udelay.c - 1.1 linux/drivers/acpi/utilities/utdebug.c - 1.1 linux/drivers/acpi/utilities/utcopy.c - 1.1 linux/drivers/acpi/utilities/utalloc.c - 1.1 linux/drivers/acpi/utilities/Makefile - 1.1 linux/drivers/acpi/ospm/button/bn.c - 1.1 linux/drivers/acpi/ospm/button/Makefile - 1.1 linux/drivers/acpi/ospm/busmgr/bmutils.c - 1.1 linux/drivers/acpi/ospm/busmgr/bmsearch.c - 1.1 linux/drivers/acpi/ospm/thermal/tz.c - 1.1 linux/drivers/acpi/ospm/busmgr/bmrequest.c - 1.1 linux/drivers/acpi/ospm/busmgr/bmpower.c - 1.1 linux/drivers/acpi/ospm/busmgr/bmpm.c - 1.1 linux/drivers/acpi/ospm/busmgr/bmnotify.c - 1.1 linux/drivers/acpi/ospm/busmgr/bmdriver.c - 1.1 linux/drivers/acpi/ospm/busmgr/bm_osl.c - 1.1 linux/drivers/acpi/ospm/busmgr/bm.c - 1.1 linux/drivers/acpi/ospm/busmgr/Makefile - 1.1 linux/drivers/acpi/ospm/thermal/Makefile - 1.1 linux/drivers/acpi/ospm/battery/bt_osl.c - 1.1 linux/drivers/acpi/ospm/battery/bt.c - 1.1 linux/drivers/acpi/Config.in - 1.1 linux/drivers/acpi/include/acstruct.h - 1.1 linux/drivers/acpi/ospm/system/sm_osl.c - 1.1 linux/drivers/acpi/ospm/thermal/tz_osl.c - 1.1 linux/drivers/acpi/ospm/thermal/tzpolicy.c - 1.1 linux/drivers/acpi/ospm/system/sm.c - 1.1 linux/drivers/net/wireless/airo_cs.c - 1.1 linux/drivers/usb/catc.c - 1.1 linux/drivers/usb/serial/pl2303.h - 1.1 linux/drivers/acpi/ospm/include/bt.h - 1.1 linux/drivers/acpi/ospm/include/bn.h - 1.1 linux/drivers/acpi/include/acutils.h - 1.1 linux/drivers/net/wireless/airo.c - 1.1 linux/drivers/acpi/include/platform/acenv.h - 1.1 linux/drivers/acpi/ospm/include/bmpower.h - 1.1 linux/drivers/acpi/include/platform/acgcc.h - 1.1 linux/drivers/acpi/include/platform/aclinux.h - 1.1 linux/drivers/acpi/debugger/dbcmds.c - 1.1 linux/drivers/acpi/debugger/dbdisasm.c - 1.1 linux/drivers/acpi/debugger/dbdisply.c - 1.1 linux/drivers/acpi/debugger/dbexec.c - 1.1 linux/drivers/acpi/debugger/dbfileio.c - 1.1 linux/drivers/acpi/debugger/dbhistry.c - 1.1 linux/drivers/acpi/debugger/dbinput.c - 1.1 linux/drivers/acpi/debugger/dbstats.c - 1.1 linux/drivers/acpi/debugger/dbutils.c - 1.1 linux/drivers/acpi/debugger/dbxface.c - 1.1 linux/drivers/acpi/ospm/system/Makefile - 1.1 linux/drivers/acpi/ospm/include/ec.h - 1.1 linux/drivers/acpi/ospm/processor/prpower.c - 1.1 linux/drivers/acpi/ospm/processor/prperf.c - 1.1 linux/drivers/acpi/ospm/battery/Makefile - 1.1 linux/drivers/acpi/ospm/processor/pr_osl.c - 1.1 linux/drivers/acpi/ospm/ac_adapter/ac_osl.c - 1.1 linux/drivers/acpi/ospm/processor/pr.c - 1.1 linux/drivers/acpi/ospm/processor/Makefile - 1.1 linux/drivers/acpi/ospm/ac_adapter/ac.c - 1.1 linux/drivers/acpi/executer/exxface.c - 1.1 linux/drivers/acpi/executer/exutils.c - 1.1 linux/drivers/acpi/executer/exsystem.c - 1.1 linux/drivers/acpi/ospm/ac_adapter/Makefile - 1.1 linux/drivers/acpi/executer/exstorob.c - 1.1 linux/drivers/acpi/ospm/Makefile - 1.1 linux/drivers/acpi/executer/exstoren.c - 1.1 linux/drivers/acpi/ospm/include/bm.h - 1.1 linux/drivers/acpi/ospm/ec/ecmain.c - 1.1 linux/drivers/acpi/ospm/include/sm.h - 1.1 linux/drivers/acpi/ospm/include/tz.h - 1.1 linux/drivers/acpi/ospm/ec/ecspace.c - 1.1 linux/drivers/acpi/ospm/ec/ectransx.c - 1.1 linux/drivers/acpi/ospm/include/ac.h - 1.1 linux/drivers/acpi/executer/Makefile - 1.1 linux/drivers/acpi/executer/exconfig.c - 1.1 linux/drivers/acpi/executer/exconvrt.c - 1.1 linux/drivers/acpi/executer/excreate.c - 1.1 linux/drivers/acpi/executer/exdump.c - 1.1 linux/drivers/acpi/executer/exdyadic.c - 1.1 linux/drivers/acpi/executer/exfield.c - 1.1 linux/drivers/acpi/executer/exfldio.c - 1.1 linux/drivers/acpi/executer/exmisc.c - 1.1 linux/drivers/acpi/executer/exmonad.c - 1.1 linux/drivers/acpi/executer/exmutex.c - 1.1 linux/drivers/acpi/executer/exnames.c - 1.1 linux/drivers/acpi/executer/exprep.c - 1.1 linux/drivers/acpi/executer/exregion.c - 1.1 linux/drivers/acpi/executer/exresnte.c - 1.1 linux/drivers/acpi/executer/exresolv.c - 1.1 linux/drivers/acpi/executer/exresop.c - 1.1 linux/net/sunrpc/svc.c - 1.7 linux/net/netsyms.c - 1.32 linux/net/ipv6/udp.c - 1.21 linux/net/ipv6/tcp_ipv6.c - 1.24 linux/net/ipv6/raw.c - 1.18 linux/net/ipv6/ip6_fib.c - 1.9 linux/net/ipv6/icmp.c - 1.11 linux/net/ipv6/exthdrs.c - 1.5 linux/net/ipv6/af_inet6.c - 1.17 linux/net/ipv6/addrconf.c - 1.17 linux/net/ipv4/raw.c - 1.19 linux/net/ipv4/icmp.c - 1.18 linux/net/ipv4/af_inet.c - 1.26 linux/net/core/dev.c - 1.35 linux/net/802/hippi.c - 1.4 linux/mm/page_alloc.c - 1.43 linux/init/main.c - 1.55 linux/include/net/snmp.h - 1.9 linux/include/net/protocol.h - 1.7 linux/include/net/irda/irdacall.h - 1.3 linux/include/linux/sunrpc/xprt.h - 1.8 linux/include/linux/smb_fs_i.h - 1.6 linux/include/linux/smb_fs.h - 1.14 linux/include/linux/mm.h - 1.56 linux/include/linux/if_hippi.h - 1.3 linux/include/linux/if_arp.h - 1.10 linux/include/asm-sparc64/socket.h - 1.6 linux/include/asm-sparc64/bitops.h - 1.10 linux/include/asm-sparc/socket.h - 1.6 linux/include/asm-ppc/socket.h - 1.7 linux/include/asm-mips/socket.h - 1.8 linux/include/asm-m68k/socket.h - 1.6 linux/include/asm-i386/softirq.h - 1.8 linux/include/asm-i386/socket.h - 1.6 linux/include/asm-arm/socket.h - 1.6 linux/include/asm-alpha/socket.h - 1.6 linux/include/asm-alpha/delay.h - 1.9 linux/fs/super.c - 1.49 linux/fs/smbfs/proc.c - 1.11 linux/fs/smbfs/inode.c - 1.22 linux/fs/smbfs/file.c - 1.20 linux/fs/locks.c - 1.16 linux/fs/ext2/dir.c - 1.15 linux/fs/autofs/inode.c - 1.9 linux/fs/autofs/autofs_i.h - 1.7 linux/fs/Config.in - 1.61 linux/drivers/usb/Makefile - 1.37 linux/drivers/usb/Config.in - 1.41 linux/drivers/scsi/qlogicisp.c - 1.21 linux/drivers/scsi/gdth.c - 1.13 linux/drivers/sbus/char/sab82532.c - 1.19 linux/drivers/sbus/char/pcikbd.c - 1.19 linux/drivers/pci/quirks.c - 1.21 linux/drivers/net/yellowfin.c - 1.22 linux/drivers/net/wd.c - 1.13 linux/drivers/net/via-rhine.c - 1.24 linux/drivers/net/tlan.c - 1.20 linux/drivers/net/sunhme.c - 1.26 linux/drivers/net/smc9194.c - 1.14 linux/drivers/net/smc-ultra.c - 1.16 linux/drivers/net/smc-mca.c - 1.12 linux/drivers/net/slip.c - 1.16 linux/drivers/net/shaper.c - 1.17 linux/drivers/net/seeq8005.c - 1.13 linux/drivers/net/plip.c - 1.19 linux/drivers/net/ni65.c - 1.10 linux/drivers/net/ni52.c - 1.13 linux/drivers/net/ni5010.c - 1.13 linux/drivers/net/ne3210.c - 1.12 linux/drivers/net/ne2k-pci.c - 1.21 linux/drivers/net/ne2.c - 1.13 linux/drivers/net/ne.c - 1.17 linux/drivers/net/mace.c - 1.14 linux/drivers/net/lne390.c - 1.13 linux/drivers/net/lance.c - 1.19 linux/drivers/net/hp.c - 1.12 linux/drivers/net/hp-plus.c - 1.13 linux/drivers/net/fmv18x.c - 1.14 linux/drivers/net/ewrk3.c - 1.16 linux/drivers/net/ethertap.c - 1.10 linux/drivers/net/eth16i.c - 1.17 linux/drivers/net/es3210.c - 1.14 linux/drivers/net/epic100.c - 1.21 linux/drivers/net/eexpress.c - 1.16 linux/drivers/net/eepro100.c - 1.30 linux/drivers/net/eepro.c - 1.19 linux/drivers/net/e2100.c - 1.13 linux/drivers/net/dgrs.c - 1.16 linux/drivers/net/depca.c - 1.15 linux/drivers/net/de620.c - 1.11 linux/drivers/net/de600.c - 1.12 linux/drivers/net/de4x5.c - 1.21 linux/drivers/net/cs89x0.c - 1.18 linux/drivers/net/atp.c - 1.15 linux/drivers/net/atarilance.c - 1.9 linux/drivers/net/atari_pamsnet.c - 1.10 linux/drivers/net/atari_bionet.c - 1.10 linux/drivers/net/at1700.c - 1.11 linux/drivers/net/acenic.c - 1.26 linux/drivers/net/ac3200.c - 1.14 linux/drivers/net/Makefile - 1.43 linux/drivers/net/Config.in - 1.39 linux/drivers/net/82596.c - 1.17 linux/drivers/net/3c59x.c - 1.26 linux/drivers/net/3c523.c - 1.15 linux/drivers/net/3c515.c - 1.18 linux/drivers/net/3c509.c - 1.21 linux/drivers/net/3c507.c - 1.18 linux/drivers/net/3c505.c - 1.19 linux/drivers/net/3c503.c - 1.17 linux/drivers/net/3c501.c - 1.13 linux/arch/sparc64/kernel/sys_sparc32.c - 1.36 linux/arch/ppc/kernel/prep_pci.c - 1.10 linux/arch/i386/kernel/traps.c - 1.37 linux/arch/i386/kernel/irq.c - 1.35 linux/arch/i386/kernel/io_apic.c - 1.28 linux/arch/i386/kernel/head.S - 1.19 linux/arch/i386/defconfig - 1.58 linux/arch/i386/config.in - 1.58 linux/arch/alpha/lib/Makefile - 1.12 linux/arch/alpha/kernel/sys_sio.c - 1.13 linux/arch/alpha/kernel/process.c - 1.17 linux/arch/alpha/kernel/irq.c - 1.18 linux/arch/alpha/kernel/alpha_ksyms.c - 1.22 linux/Makefile - 1.91 linux/MAINTAINERS - 1.61 linux/Documentation/networking/vortex.txt - 1.9 linux/Documentation/filesystems/00-INDEX - 1.9 linux/Documentation/Configure.help - 1.83 linux/drivers/sbus/char/aurora.h - 1.3 linux/arch/sparc64/math-emu/sfp-util.h - 1.3 linux/Documentation/kernel-parameters.txt - 1.13 linux/drivers/net/bagetlance.c - 1.10 linux/drivers/net/arlan.c - 1.16 linux/drivers/net/ppp_async.c - 1.12 linux/drivers/net/macsonic.c - 1.7 linux/include/linux/irq.h - 1.8 linux/include/asm-i386/hw_irq.h - 1.18 linux/arch/i386/kernel/i8259.c - 1.22 linux/drivers/net/sis900.c - 1.22 linux/drivers/net/sb1000.c - 1.13 linux/drivers/net/fc/iph5526.c - 1.14 linux/arch/sparc64/kernel/pci_sabre.c - 1.22 linux/arch/sparc64/kernel/pci_psycho.c - 1.19 linux/arch/sparc64/kernel/pci_impl.h - 1.8 linux/arch/sparc64/kernel/pci_common.c - 1.12 linux/arch/sparc64/kernel/pci.c - 1.21 linux/include/asm-sh/socket.h - 1.6 linux/include/asm-i386/pci.h - 1.9 linux/drivers/pcmcia/cs.c - 1.27 linux/drivers/net/sun3lance.c - 1.8 linux/drivers/net/starfire.c - 1.14 linux/drivers/net/pcmcia/Makefile - 1.17 linux/drivers/net/pcmcia/Config.in - 1.23 linux/include/linux/acpi.h - 1.21 linux/drivers/net/dmfe.c - 1.15 linux/drivers/net/tokenring/olympic.h - 1.8 linux/drivers/net/tokenring/olympic.c - 1.14 linux/arch/i386/kernel/pci-pc.c - 1.23 linux/arch/i386/kernel/pci-i386.h - 1.6 linux/include/linux/pci_ids.h - 1.37 linux/drivers/video/aty128fb.c - 1.20 linux/drivers/pci/pci.ids - 1.29 linux/drivers/net/aironet4500_core.c - 1.13 linux/drivers/net/aironet4500_card.c - 1.12 linux/drivers/char/agp/agpgart_be.c - 1.16 linux/drivers/char/agp/agp.h - 1.11 linux/drivers/pcmcia/yenta.c - 1.23 linux/drivers/telephony/ixj.c - 1.14 linux/drivers/net/tokenring/smctr.c - 1.12 linux/arch/i386/kernel/apic.c - 1.17 linux/include/asm-i386/io_apic.h - 1.3 linux/drivers/net/mac89x0.c - 1.6 linux/drivers/sound/via82cxxx_audio.c - 1.15 linux/include/asm-ia64/socket.h - 1.6 linux/drivers/net/8139too.c - 1.20 linux/Documentation/filesystems/devfs/ChangeLog - 1.9 linux/fs/devfs/base.c - 1.17 linux/drivers/net/tulip/tulip_core.c - 1.22 linux/drivers/net/tulip/tulip.h - 1.13 linux/drivers/net/tulip/timer.c - 1.9 linux/drivers/net/tulip/pnic.c - 1.8 linux/drivers/net/tulip/media.c - 1.10 linux/drivers/net/tulip/interrupt.c - 1.11 linux/drivers/net/tulip/21142.c - 1.9 linux/include/asm-mips64/socket.h - 1.6 linux/drivers/atm/fore200e_mkfirm.c - 1.2 linux/drivers/usb/serial/usb-serial.h - 1.13 linux/drivers/ide/piix.c - 1.10 linux/drivers/ide/ide-pci.c - 1.13 linux/drivers/ide/ide-floppy.c - 1.6 linux/scripts/kernel-doc - 1.9 linux/scripts/docproc.c - 1.4 linux/scripts/docgen - 1.2 linux/drivers/net/tokenring/lanstreamer.c - 1.7 linux/net/ipv4/netfilter/ipt_unclean.c - 1.4 linux/drivers/net/pcmcia/xircom_tulip_cb.c - 1.11 linux/drivers/net/pcmcia/ibmtr_cs.c - 1.5 linux/arch/i386/kernel/pci-irq.c - 1.15 linux/include/linux/ibmtr.h - 1.2 linux/drivers/usb/serial/keyspan_pda.c - 1.15 linux/drivers/usb/serial/ftdi_sio.c - 1.18 linux/drivers/usb/serial/usbserial.c - 1.17 linux/drivers/usb/serial/whiteheat.c - 1.15 linux/drivers/usb/serial/visor.c - 1.18 linux/drivers/usb/serial/omninet.c - 1.14 linux/include/linux/raid/raid5.h - 1.5 linux/include/asm-s390/socket.h - 1.4 linux/drivers/char/drm/r128_drv.h - 1.5 linux/drivers/usb/serial/keyspan.c - 1.11 linux/drivers/acpi/tables/tbxface.c - 1.5 linux/drivers/acpi/tables/tbutils.c - 1.5 linux/drivers/acpi/tables/tbinstal.c - 1.5 linux/drivers/acpi/tables/tbget.c - 1.5 linux/drivers/acpi/sys.c - 1.6 linux/drivers/acpi/resources/rsxface.c - 1.5 linux/drivers/acpi/resources/rsutils.c - 1.5 linux/drivers/acpi/resources/rsmisc.c - 1.5 linux/drivers/acpi/resources/rsmemory.c - 1.5 linux/drivers/acpi/resources/rslist.c - 1.6 linux/drivers/acpi/resources/rsirq.c - 1.5 linux/drivers/acpi/resources/rsio.c - 1.5 linux/drivers/acpi/resources/rsdump.c - 1.6 linux/drivers/acpi/resources/rscreate.c - 1.6 linux/drivers/acpi/resources/rscalc.c - 1.6 linux/drivers/acpi/resources/rsaddr.c - 1.5 linux/drivers/acpi/parser/psxface.c - 1.5 linux/drivers/acpi/parser/pswalk.c - 1.5 linux/drivers/acpi/parser/psutils.c - 1.5 linux/drivers/acpi/parser/pstree.c - 1.5 linux/drivers/acpi/parser/psscope.c - 1.5 linux/drivers/acpi/parser/psparse.c - 1.6 linux/drivers/acpi/parser/psopcode.c - 1.5 linux/drivers/acpi/parser/psargs.c - 1.6 linux/drivers/acpi/os.c - 1.5 linux/drivers/acpi/namespace/nsxfobj.c - 1.8 linux/drivers/acpi/namespace/nsxfname.c - 1.5 linux/drivers/acpi/namespace/nswalk.c - 1.4 linux/drivers/acpi/namespace/nsutils.c - 1.5 linux/drivers/acpi/namespace/nssearch.c - 1.6 linux/drivers/acpi/namespace/nsobject.c - 1.5 linux/drivers/acpi/namespace/nsnames.c - 1.6 linux/drivers/acpi/namespace/nsload.c - 1.5 linux/drivers/usb/bluetooth.c - 1.12 linux/drivers/acpi/namespace/nseval.c - 1.6 linux/drivers/acpi/namespace/nsalloc.c - 1.5 linux/drivers/acpi/namespace/nsaccess.c - 1.6 linux/drivers/acpi/interpreter/amxface.c - 1.4 linux/drivers/acpi/interpreter/amutils.c - 1.7 linux/drivers/acpi/interpreter/amsystem.c - 1.5 linux/drivers/acpi/interpreter/amstorob.c - 1.6 linux/drivers/acpi/interpreter/amstoren.c - 1.5 linux/drivers/acpi/interpreter/amstore.c - 1.7 linux/drivers/acpi/interpreter/amresop.c - 1.5 linux/drivers/acpi/interpreter/amresolv.c - 1.5 linux/drivers/acpi/interpreter/amresnte.c - 1.5 linux/drivers/acpi/interpreter/amregion.c - 1.5 linux/drivers/acpi/interpreter/amprep.c - 1.6 linux/drivers/acpi/interpreter/amnames.c - 1.5 linux/drivers/acpi/interpreter/ammonad.c - 1.6 linux/drivers/acpi/interpreter/ammisc.c - 1.5 linux/drivers/acpi/interpreter/amfldio.c - 1.6 linux/drivers/acpi/interpreter/amfield.c - 1.5 linux/drivers/acpi/interpreter/amdyadic.c - 1.5 linux/drivers/acpi/interpreter/amcreate.c - 1.5 linux/drivers/acpi/interpreter/amconfig.c - 1.5 linux/drivers/acpi/include/amlcode.h - 1.5 linux/drivers/acpi/include/actypes.h - 1.7 linux/drivers/acpi/include/actables.h - 1.5 linux/drivers/acpi/include/acpixf.h - 1.6 linux/drivers/acpi/include/acpiosxf.h - 1.6 linux/drivers/acpi/include/acpi.h - 1.4 linux/drivers/acpi/include/acobject.h - 1.5 linux/drivers/acpi/include/acexcep.h - 1.5 linux/drivers/acpi/include/acenv.h - 1.5 linux/drivers/acpi/hardware/hwregs.c - 1.6 linux/drivers/acpi/hardware/hwgpe.c - 1.5 linux/drivers/acpi/hardware/hwacpi.c - 1.6 linux/drivers/acpi/events/evxfregn.c - 1.6 linux/drivers/acpi/events/evxfevnt.c - 1.5 linux/drivers/acpi/events/evxface.c - 1.5 linux/drivers/acpi/events/evsci.c - 1.6 linux/drivers/acpi/events/evrgnini.c - 1.5 linux/drivers/acpi/events/evregion.c - 1.7 linux/drivers/acpi/events/evmisc.c - 1.5 linux/drivers/acpi/events/evevent.c - 1.7 linux/drivers/acpi/ec.c - 1.7 linux/drivers/acpi/driver.h - 1.5 linux/drivers/acpi/driver.c - 1.10 linux/drivers/acpi/dispatcher/dswstate.c - 1.6 linux/drivers/acpi/dispatcher/dswscope.c - 1.5 linux/drivers/acpi/dispatcher/dswload.c - 1.5 linux/drivers/acpi/dispatcher/dswexec.c - 1.5 linux/drivers/acpi/dispatcher/dsutils.c - 1.5 linux/drivers/acpi/dispatcher/dsopcode.c - 1.6 linux/drivers/acpi/dispatcher/dsobject.c - 1.6 linux/drivers/acpi/dispatcher/dsmthdat.c - 1.5 linux/drivers/acpi/dispatcher/dsmethod.c - 1.5 linux/drivers/acpi/dispatcher/dsfield.c - 1.4 linux/drivers/acpi/cpu.c - 1.6 linux/drivers/acpi/common/cmxface.c - 1.6 linux/drivers/acpi/common/cmutils.c - 1.6 linux/drivers/acpi/common/cmobject.c - 1.7 linux/drivers/acpi/common/cminit.c - 1.6 linux/drivers/acpi/common/cmglobal.c - 1.5 linux/drivers/acpi/common/cmeval.c - 1.5 linux/drivers/acpi/common/cmdelete.c - 1.5 linux/drivers/acpi/common/cmdebug.c - 1.5 linux/drivers/acpi/common/cmcopy.c - 1.7 linux/drivers/acpi/common/cmalloc.c - 1.5 linux/drivers/acpi/Makefile - 1.7 linux/drivers/net/ibmlana.c - 1.5 linux/fs/smbfs/ChangeLog - 1.6 linux/drivers/sound/cs46xx.c - 1.10 linux/drivers/net/natsemi.c - 1.8 linux/drivers/media/video/bttv-driver.c - 1.9 linux/drivers/md/raid1.c - 1.9 linux/drivers/md/raid5.c - 1.16 linux/drivers/acpi/common/Makefile - 1.3 linux/drivers/acpi/common/cmclib.c - 1.4 linux/drivers/acpi/dispatcher/Makefile - 1.3 linux/drivers/acpi/events/Makefile - 1.3 linux/drivers/acpi/hardware/Makefile - 1.3 linux/drivers/acpi/include/accommon.h - 1.5 linux/drivers/acpi/include/acconfig.h - 1.6 linux/drivers/acpi/include/acdebug.h - 1.5 linux/drivers/acpi/include/acdispat.h - 1.4 linux/drivers/acpi/include/acevents.h - 1.5 linux/drivers/acpi/include/acglobal.h - 1.4 linux/drivers/acpi/include/achware.h - 1.4 linux/drivers/acpi/include/acinterp.h - 1.5 linux/drivers/acpi/include/aclocal.h - 1.6 linux/drivers/acpi/include/acmacros.h - 1.5 linux/drivers/acpi/include/acnamesp.h - 1.6 linux/drivers/acpi/include/acoutput.h - 1.5 linux/drivers/acpi/include/acresrc.h - 1.3 linux/drivers/acpi/include/actbl.h - 1.4 linux/drivers/acpi/interpreter/Makefile - 1.3 linux/drivers/acpi/namespace/Makefile - 1.3 linux/drivers/acpi/parser/Makefile - 1.3 linux/drivers/acpi/parser/psfind.c - 1.3 linux/drivers/acpi/resources/Makefile - 1.3 linux/drivers/acpi/table.c - 1.4 linux/drivers/acpi/tables/Makefile - 1.3 linux/drivers/md/md.c - 1.15 linux/drivers/md/raid0.c - 1.3 linux/drivers/net/hamachi.c - 1.7 linux/drivers/net/sundance.c - 1.6 linux/drivers/net/winbond-840.c - 1.7 linux/drivers/scsi/cpqfcTSinit.c - 1.6 linux/fs/minix/itree_common.c - 1.3 linux/drivers/net/tulip/ChangeLog - 1.7 linux/drivers/usb/serial/belkin_sa.c - 1.8 linux/drivers/net/lasi_82596.c - 1.3 linux/drivers/usb/serial/mct_u232.c - 1.7 linux/drivers/usb/serial/empeg.c - 1.7 linux/include/asm-parisc/socket.h - 1.3 linux/drivers/acpi/tables/tbconvrt.c - 1.4 linux/drivers/acpi/tables/tbxfroot.c - 1.3 linux/drivers/acpi/namespace/nsinit.c - 1.5 linux/drivers/acpi/include/actbl71.h - 1.3 linux/drivers/acpi/include/actbl2.h - 1.3 linux/drivers/acpi/include/aclinux.h - 1.5 linux/drivers/acpi/include/acgcc.h - 1.4 linux/drivers/acpi/cmbatt.c - 1.5 linux/drivers/acpi/power.c - 1.3 linux/drivers/acpi/ec.h - 1.2 linux/drivers/acpi/acpi_ksyms.c - 1.3 linux/drivers/acpi/hardware/hwsleep.c - 1.3 linux/drivers/acpi/hardware/hwtimer.c - 1.3 linux/arch/sparc64/kernel/pci_schizo.c - 1.7 linux/fs/reiserfs/inode.c - 1.5 linux/drivers/acpi/interpreter/amconvrt.c - 1.2 linux/drivers/sound/cs4281/cs4281m.c - 1.4 linux/include/asm-s390x/socket.h - 1.3 linux/include/asm-cris/socket.h - 1.3 linux/drivers/net/pci-skeleton.c - 1.4 linux/drivers/net/sungem.c - 1.3 linux/drivers/net/saa9730.c - 1.2 linux/Documentation/networking/TODO - 1.2 linux/drivers/net/fealnx.c - 1.2 linux/drivers/net/wireless/Config.in - 1.2 linux/drivers/net/wireless/Makefile - 1.2 linux/drivers/net/wireless/orinoco_cs.c - 1.3 linux/drivers/usb/pwc.h - 1.2 linux/drivers/usb/pwc-uncompress.h - 1.2 linux/drivers/usb/pwc-uncompress.c - 1.2 linux/drivers/usb/pwc-if.c - 1.2 linux/drivers/usb/pwc-ctrl.c - 1.2 From owner-linux-xfs@oss.sgi.com Thu Jun 21 08:55:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LFt3o11338 for linux-xfs-outgoing; Thu, 21 Jun 2001 08:55:03 -0700 Received: from relay2.flashnet.it (libra.cyb.it [212.11.95.209]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LFt1V11334 for ; Thu, 21 Jun 2001 08:55:02 -0700 Received: from ip114.pool-02.cyb.it (ip114.pool-02.cyb.it [195.191.2.243]) by relay2.flashnet.it (EMS-RELAY/8.10.0) with SMTP id f5LFslC20740 for ; Thu, 21 Jun 2001 17:54:49 +0200 From: daedalus@freemail.it To: linux-xfs@oss.sgi.com Subject: Re: XFS 1.0.1 testing Date: Thu, 21 Jun 2001 18:03:03 +0200 Message-ID: References: <3B2ECC33.9514CDB5@sgi.com> In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5LFt2V11336 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 21 Jun 2001 13:39:00 +0200, daedalus@freemail.it wrote: >I have made a set of 2 floppy disk (minix fs) images (boot 1440 and >root 1600), derived from bare.i and color.gz, >featuring a Slackware 8.0.0 (not yet released) installer. [snip] >anyway I hope you will take a look and test and do whatever you want >with this stuff at >http://village.flashnet.it/users/fn048069/files/XFS/ I apologize for the inconvinience... I should have known my ISP doesn't allow directory listing! I am uploading a tarball with all the contents of that dir http://village.flashnet.it/users/fn048069/files/XFS.tar.gz From owner-linux-xfs@oss.sgi.com Thu Jun 21 09:01:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LG10P11611 for linux-xfs-outgoing; Thu, 21 Jun 2001 09:01:00 -0700 Received: from dns2.dreamworks.com (garm.dreamworks.com [64.173.252.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LG0wV11608 for ; Thu, 21 Jun 2001 09:00:58 -0700 Received: from mail.anim.dreamworks.com (mail.anim.dreamworks.com [192.168.4.50]) by dns2.dreamworks.com (8.9.3/8.8.8) with ESMTP id JAA25555; Thu, 21 Jun 2001 09:00:48 -0700 (PDT) Received: from anim.dreamworks.com (lovelace.anim.dreamworks.com [192.168.1.66]) by mail.anim.dreamworks.com (8.8.8/8.8.8) with ESMTP id JAA23850; Thu, 21 Jun 2001 09:00:48 -0700 (PDT) Message-ID: <3B321A30.28C5991A@anim.dreamworks.com> Date: Thu, 21 Jun 2001 09:00:48 -0700 From: Skottie Miller X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Reggy Ekkebus CC: linux-xfs@oss.sgi.com Subject: Re: Can XFS be used on a production machine References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk As with all things, it depends. It depends on your tolerence to risk, the value you place on your data, the value you place on fast reboots, the size of your filesystems, your backup policies, your ability to handle possible downtimes if there is a failure, your performance requirements. That said, we're evaluating and testing Linux XFS for use in "limited production". the first Linux XFS file servers will be for transient, re-creatable data, for departments that can tolerate short outages. Once we think that's stable, more file services will migrate to Linux XFS (from IRIX XFS). It took me years to really get comfortable with IRIX XFS, given that it too had lots of problems early on. I now trust XFS on IRIX, and time (and testing) will hopefully give that same trust for XFS on Linux. -Skottie Reggy Ekkebus wrote: > > Hello, > > This time a read the FAQ, but It's not completely clear to me, because > the answer in the FAQ says it's stable, but it also says it's unstable. > > So my question is, is it stable for a server in a company with about 10 > people working. The server will be a file server and will not be very > busy. I don't want to reinstall the server every year. > > Best Regards, > > Reggy Ekkebus -- ---- Scott Miller | Animation Technology work: skottie@dreamworks.com | Dreamworks Feature Animation life: skottie@pobox.com From owner-linux-xfs@oss.sgi.com Thu Jun 21 09:06:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LG6Y911966 for linux-xfs-outgoing; Thu, 21 Jun 2001 09:06:34 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LG6YV11959 for ; Thu, 21 Jun 2001 09:06:34 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA01888 for ; Thu, 21 Jun 2001 09:07:02 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA2218480; Thu, 21 Jun 2001 11:05:14 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA68171; Thu, 21 Jun 2001 11:05:14 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5LG8m713919; Thu, 21 Jun 2001 11:08:48 -0500 Message-Id: <200106211608.f5LG8m713919@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Reggy Ekkebus cc: linux-xfs@oss.sgi.com Subject: Re: Can XFS be used on a production machine In-Reply-To: Message from Reggy Ekkebus of "Thu, 21 Jun 2001 17:48:14 +0200." Date: Thu, 21 Jun 2001 11:08:48 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Hello, > > > This time a read the FAQ, but It's not completely clear to me, because > the answer in the FAQ says it's stable, but it also says it's unstable. > > So my question is, is it stable for a server in a company with about 10 > people working. The server will be a file server and will not be very > busy. I don't want to reinstall the server every year. We use it here, but generally we have upgraded beyond the 1.0 release and run later kernels. The machine hosting the oss website was recently upgraded to the 1.0 release, but was getting an uptime of about 24 hours before it hung. We have bumped it up to a more recent version of XFS, the one in the test 1.0.1 rpms here ftp://oss.sgi.com/projects/xfs/download/testing/Release-1.0.1-PR1/ and so far it is staying up, 359 Gbytes of data read in 3 days 14 hours. You might want to wait until we have done more testing on the 1.0.1 rpms and use those. Steve > > > Best Regards, > > > Reggy Ekkebus > > > From owner-linux-xfs@oss.sgi.com Thu Jun 21 09:14:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LGElN12372 for linux-xfs-outgoing; Thu, 21 Jun 2001 09:14:47 -0700 Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LGEjV12368 for ; Thu, 21 Jun 2001 09:14:45 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.2/8.11.2) with ESMTP id f5LGES813835; Thu, 21 Jun 2001 12:14:28 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 21 Jun 2001 12:14:28 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: To: Reggy Ekkebus cc: Subject: Re: Can XFS be used on a production machine In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 21 Jun 2001 at 5:48pm, Reggy Ekkebus wrote > So my question is, is it stable for a server in a company with about 10 > people working. The server will be a file server and will not be very > busy. I don't want to reinstall the server every year. I've got XFS on a 560GB RAID NFS served to about 10-15 clients. It's been "in production" since early April running a pre-release kernel pulled out of CVS in mid-March. I haven't had *any* XFS related issues, and XFS has saved my butt on multiple occasions. The box will be upgraded to RH7.1 and XFS 1.0.1 when that comes out. It never got upgraded to the 1.0 release simply b/c it's being used and it's working (knock wood). -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu Jun 21 09:26:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LGQlZ12821 for linux-xfs-outgoing; Thu, 21 Jun 2001 09:26:47 -0700 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LGQkV12817 for ; Thu, 21 Jun 2001 09:26:46 -0700 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 11:26:11 -0500 Message-ID: <85063BBE668FD411944400D0B744267A481AA3@AUSMAIL> From: "Gonyou, Austin" To: linux-xfs@oss.sgi.com Subject: XFS + LVM + GFS + Oracle(or any other DB) Date: Thu, 21 Jun 2001 11:26:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is there anyone doing any combination of the above, with some kind of production database, preferrably on Fibre. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com From owner-linux-xfs@oss.sgi.com Thu Jun 21 09:58:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LGwoL13699 for linux-xfs-outgoing; Thu, 21 Jun 2001 09:58:50 -0700 Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LGwlV13696 for ; Thu, 21 Jun 2001 09:58:47 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f5LGw4884309; Thu, 21 Jun 2001 11:58:04 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <3B32279C.4853601E@thebarn.com> Date: Thu, 21 Jun 2001 11:58:04 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Richard Houston CC: linux-xfs@oss.sgi.com Subject: Re: Redhat 6.2 References: <200106211518.f5LFIxe10112@oss.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Richard Houston wrote: > This message was sent from http://oss.sgi.com/projects/xfs/news.html > > ---- > > Good Day > > First off, bravo!! Great job. So far so good in my experience. > > Do you have or does anyone else have plans to do an installer for Redhat 6.2\? I know 6.2 is a 2.2.14 kernel but a 6.2 install with 2.4.X > kernel and all around XFS would be nice. The reason I ask is that the company I consult for uses Redhat 6.2 for it's DB2 servers. > IBM does not seem to support DB2 on servers higher than RH 6.2 at this time. This would be a lot of work since the kernel rpm's have all sorts of dependencies on 7.1 stuff. I would say your best bet to get a system running 6.2 + xfs on an ext2 partition and then use the installer iso in rescue mode to manually create the xfs filesystems and copy the system over. http:/oss.sgi.com/projects/xfs/xfsroot.html > > > Any info would be great. > > Thanks > > Rich -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Thu Jun 21 10:02:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LH2m113914 for linux-xfs-outgoing; Thu, 21 Jun 2001 10:02:48 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LH2hV13911 for ; Thu, 21 Jun 2001 10:02:43 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA09854 for ; Thu, 21 Jun 2001 10:02:40 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2222454 for ; Thu, 21 Jun 2001 12:01:23 -0500 (CDT) Received: from sgi.com (eagdhcp-195-17.americas.sgi.com [128.162.195.187]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA51891; Thu, 21 Jun 2001 12:01:23 -0500 (CDT) Message-ID: <3B32284C.BC69444F@sgi.com> Date: Thu, 21 Jun 2001 12:01:00 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: TAKE - merge up to 2.4.6-pre5 References: <200106211552.f5LFqek13793@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > > merge up to 2.4.6-pre5, should show up in cvs sometime today, > however, internal machines involved in the cvs update are being > relocated today due to office moves, so it may get delayed a > while. Actually, the machine that does the push is still intact, and this has already been pushed out to external CVS. But just a heads up, that machine will also be moving, so cvs may be affected. I'll send a message under a new subject to make sure everyone on the list has some warning. :) -Eric From owner-linux-xfs@oss.sgi.com Thu Jun 21 10:06:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LH6aa14059 for linux-xfs-outgoing; Thu, 21 Jun 2001 10:06:36 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LH6PV14051 for ; Thu, 21 Jun 2001 10:06:25 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA07961 for ; Thu, 21 Jun 2001 10:06:24 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2225425; Thu, 21 Jun 2001 12:05:08 -0500 (CDT) Received: from sgi.com (eagdhcp-195-17.americas.sgi.com [128.162.195.187]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA67810; Thu, 21 Jun 2001 12:05:07 -0500 (CDT) Message-ID: <3B32292D.7E6C60B8@sgi.com> Date: Thu, 21 Jun 2001 12:04:45 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Russell Cattelan CC: Richard Houston , linux-xfs@oss.sgi.com Subject: Re: Redhat 6.2 References: <200106211518.f5LFIxe10112@oss.sgi.com> <3B32279C.4853601E@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Russell Cattelan wrote: > This would be a lot of work since the kernel rpm's have all sorts of dependencies on > 7.1 stuff. That, and 6.2 is not particularly "2.4 ready" so you would need to get many other system RPMs updated to support a 2.4 kernel... see the "Changes" document in the 2.4.x kernel trees. Then, after those (and all of THEIR dependencies) have been upgraded, you could possibly install the 2.4/XFS kernel RPMs, make your XFS filesystems, and migrate your data. Sounds like a lot of work. :) -Eric From owner-linux-xfs@oss.sgi.com Thu Jun 21 10:08:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LH8Ld14169 for linux-xfs-outgoing; Thu, 21 Jun 2001 10:08:21 -0700 Received: from smtp1.mts.net (smtp1.mts.net [205.200.16.74]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LH8IV14166 for ; Thu, 21 Jun 2001 10:08:19 -0700 Received: from b-38-236-res1.mts.net (b-38-236-res1.mts.net [209.202.38.236]) by smtp1.mts.net (8.11.3/8.8.8) with ESMTP id f5LH86U08264; Thu, 21 Jun 2001 12:08:14 -0500 (CDT) Received: (from shutdown@localhost) by b-38-236-res1.mts.net (8.11.0/8.11.0) id f5LG8xw11735; Thu, 21 Jun 2001 11:08:59 -0500 X-Authentication-Warning: b-38-236-res1.mts.net: shutdown set sender to using -f Received: from vader.rlhc.net(10.1.1.5) by b-38-236-res1.mts.net via smap (V2.1) id xma011733; Thu, 21 Jun 01 11:08:29 -0500 Message-ID: <3B321BA7.205B4C84@rlhc.net> Date: Thu, 21 Jun 2001 12:07:03 -0400 From: Richard Houston Reply-To: rhouston@rlhc.net Organization: RLH Consulting X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Russell Cattelan CC: linux-xfs@oss.sgi.com Subject: Re: Redhat 6.2 References: <200106211518.f5LFIxe10112@oss.sgi.com> <3B32279C.4853601E@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks Russell What I have been doing is loading RH6.2 into a 1 gig ext2 partition and than creating XFS partitions after the new kernel and supporting programs are all setup. I than do a migration of the relevant partition to the new xfs partition. I am left with only the root FS on ext2. That's fine but not optimal. I tried doing a root to XFS migration and Lilo was not happy at all. Just spit out a continuos stream of 1 and 0. I have to admit that I have not spent a bunch of time on this part. Thanks again Rich Russell Cattelan wrote: > Richard Houston wrote: > > > This message was sent from http://oss.sgi.com/projects/xfs/news.html > > > > ---- > > > > Good Day > > > > First off, bravo!! Great job. So far so good in my experience. > > > > Do you have or does anyone else have plans to do an installer for Redhat 6.2\? I know 6.2 is a 2.2.14 kernel but a 6.2 install with 2.4.X > > kernel and all around XFS would be nice. The reason I ask is that the company I consult for uses Redhat 6.2 for it's DB2 servers. > > IBM does not seem to support DB2 on servers higher than RH 6.2 at this time. > > This would be a lot of work since the kernel rpm's have all sorts of dependencies on > 7.1 stuff. > I would say your best bet to get a system running 6.2 + xfs on an ext2 partition and then > use the installer iso in rescue mode to manually create the xfs filesystems and copy the > system over. > http:/oss.sgi.com/projects/xfs/xfsroot.html > > > > > > > Any info would be great. > > > > Thanks > > > > Rich > > -- > Russell Cattelan > cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Thu Jun 21 10:09:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LH9oK14271 for linux-xfs-outgoing; Thu, 21 Jun 2001 10:09:50 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LH9nV14268 for ; Thu, 21 Jun 2001 10:09:49 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA19720 for ; Thu, 21 Jun 2001 10:09:44 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2223097 for ; Thu, 21 Jun 2001 12:08:32 -0500 (CDT) Received: from sgi.com (eagdhcp-195-17.americas.sgi.com [128.162.195.187]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA86670 for ; Thu, 21 Jun 2001 12:08:32 -0500 (CDT) Message-ID: <3B3229FA.3C716C7A@sgi.com> Date: Thu, 21 Jun 2001 12:08:10 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Heads Up - CVS updates may be broken for a bit. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We're moving many internal machines this week, and in particular, the machine that handles the push from our internal source tree to external CVS will be moving either this afternoon, or tomorrow. CVS should still be available, since it's hosted on an external machine, but updates from internal sources may not happen in a timely fashion. If things move on Friday, updates might not get resumed until early next week. Hopefully things will go smoothly, but here's your fair warning. :) -Eric From owner-linux-xfs@oss.sgi.com Thu Jun 21 10:28:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LHS2o14710 for linux-xfs-outgoing; Thu, 21 Jun 2001 10:28:02 -0700 Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LHS0V14707 for ; Thu, 21 Jun 2001 10:28:00 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f5LHRO884387; Thu, 21 Jun 2001 12:27:24 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <3B322E7B.BE2EBE6@thebarn.com> Date: Thu, 21 Jun 2001 12:27:24 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: rhouston@rlhc.net CC: linux-xfs@oss.sgi.com Subject: Re: Redhat 6.2 References: <200106211518.f5LFIxe10112@oss.sgi.com> <3B32279C.4853601E@thebarn.com> <3B321BA7.205B4C84@rlhc.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Richard Houston wrote: > Thanks Russell > > What I have been doing is loading RH6.2 into a 1 gig ext2 partition and than creating XFS partitions after the new kernel and supporting > programs are all setup. I than do a migration of the relevant partition to the new xfs partition. I am left with only the root FS on ext2. > That's fine but not optimal. I tried doing a root to XFS migration and Lilo was not happy at all. Just spit out a continuos stream of 1 and 0. > I have to admit that I have not spent a bunch of time on this part. I've seen that 0 1 thing before but I don't remember what the problem is; the lilo docs may help. Also make sure you don't move your drives after you write out lilo if the bios drive number changes lilo gets really confused. (hey nobody ever said lilo was good, but it does work) Note you can not put lilo on an xfs partition, it will clobber the super block. lilo must live in the mbr or non xfs partition (I've used swap in the past) -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Thu Jun 21 11:38:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LIcsf16348 for linux-xfs-outgoing; Thu, 21 Jun 2001 11:38:54 -0700 Received: from msg.ecetra.com (dollar.ecetra.com [193.164.224.209]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LIcqV16345 for ; Thu, 21 Jun 2001 11:38:52 -0700 Received: from vie-ac.office.ecetra.com (vie-ac.office.ecetra.com [10.251.148.147] (may be forged)) by msg.ecetra.com (8.9.3/8.9.3) with ESMTP id UAA26834; Thu, 21 Jun 2001 20:38:44 +0200 Received: from localhost (localhost [127.0.0.1]) by vie-ac.office.ecetra.com (8.11.4/8.11.3) with ESMTP id f5LIciU11633; Thu, 21 Jun 2001 20:38:44 +0200 Date: Thu, 21 Jun 2001 20:38:44 +0200 (CEST) From: Adam Cioccarelli To: "Gonyou, Austin" cc: Subject: Re: XFS + LVM + GFS + Oracle(or any other DB) In-Reply-To: <85063BBE668FD411944400D0B744267A481AA3@AUSMAIL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Austin, just XFS + Oracle so far and just on our development database. But so far no problems at all. LVM would be a great addition to this setup and I will be using it on our next development db. ------------------------------------------------------------------------------- Adam Cioccarelli (B.E Mechanical) Adam.Cioccarelli@ecetra.com Database Administrator Phone: +43 1 536 89 7725 Fax: +43 1 536 89 7719 ecetra Central European e-Finance AG Mobile:+43 664 181 4195 ------------------------------------------------------------------------------- On Thu, 21 Jun 2001, Gonyou, Austin wrote: > Is there anyone doing any combination of the above, with some kind of > production database, preferrably on Fibre. > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-796-9023 > email: austin@coremetrics.com > From owner-linux-xfs@oss.sgi.com Thu Jun 21 12:38:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LJc5A18385 for linux-xfs-outgoing; Thu, 21 Jun 2001 12:38:05 -0700 Received: from afaranis1.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LJc4V18382 for ; Thu, 21 Jun 2001 12:38:04 -0700 Received: from tduffy-lnx.afara.com (tduffy-lnx.afara.com [10.2.4.191]) by afaranis1.afara.com (8.9.3/8.9.3) with ESMTP id MAA05045; Thu, 21 Jun 2001 12:37:36 -0700 (PDT) Subject: Re: XFS at all? AND XFS and gcc ?! From: Thomas Duffy To: Knuth Posern Cc: linux-xfs@oss.sgi.com, seth.mos@xs4all.nl In-Reply-To: References: Content-Type: text/plain X-Mailer: Evolution/0.10 (Preview Release) Date: 21 Jun 2001 12:37:22 -0700 Message-Id: <993152242.17274.6.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have a 180G RAID 5 array with xfs that spans 12 disks. It has been serving ~50 clients daily without reboot for 4 months and no corruption. I even had one disk go bad, replaced it an the array was able to reincorporate it and be happy. And I just setup a RAID 0 array with 4 disks that is 120G. I have had good luck with both. -tduffy From owner-linux-xfs@oss.sgi.com Thu Jun 21 13:29:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LKT1N20447 for linux-xfs-outgoing; Thu, 21 Jun 2001 13:29:01 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LKSxV20444 for ; Thu, 21 Jun 2001 13:29:00 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15DB49-0008Ca-00; Fri, 22 Jun 2001 08:28:37 +1200 Date: Fri, 22 Jun 2001 08:28:37 +1200 (NZST) From: Juha Saarinen To: Seth Mos cc: Knuth Posern , "linux-xfs@oss.sgi.com" Subject: Re: XFS at all? AND XFS and gcc ?! In-Reply-To: Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 17 Jun 2001, Seth Mos wrote: > On Sun, 17 Jun 2001, Knuth Posern wrote: > > 2.96 needs to be tested fr some cases. I'd rather skip the work on 2.96 > and start on 3 when it will be released. 2.96 -{81|85} have both produced file system corruption for me > > I tried to get the 2.91.66 C and C++ compiler installed on my system. But > > it failed. And I don't know exactly why... On RH, you'll need the compat-egcs packages, plus the compat-libs one. -- Juha From owner-linux-xfs@oss.sgi.com Thu Jun 21 13:38:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LKcl620720 for linux-xfs-outgoing; Thu, 21 Jun 2001 13:38:47 -0700 Received: from hal.bizland-inc.net (pop.bizland.com [64.28.88.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LKckV20714 for ; Thu, 21 Jun 2001 13:38:46 -0700 Received: from aeneas.int.bizland.net ([10.1.1.204] helo=bizland.com) by hal.bizland-inc.net with smtp (Exim 3.16 #1) id 15DBDp-0002R1-00 for linux-xfs@oss.sgi.com; Thu, 21 Jun 2001 16:38:37 -0400 Received: from 198.4.92.5 (SquirrelMail authenticated user crossfs) by webmail.bizland.com with HTTP; Thu, 21 Jun 2001 16:36:43 -0400 (EDT) Message-ID: <54319.198.4.92.5.993155803.squirrel@webmail.bizland.com> Date: Thu, 21 Jun 2001 16:36:43 -0400 (EDT) Subject: XFS source before porting to linux From: To: X-Mailer: SquirrelMail (version 1.1.3 [cvs]) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, How can I get the reference XFS source before it was ported to Linux, i.e I want the vanilla XFS source that used VFS & buf interface instead of these linux pagebuf stuff. That way it would be lot easier to port since I already have FreeBSD VFS & buf interface in NT. If it is already in CVS please let me know what release tag to specify for checkout. thanks From owner-linux-xfs@oss.sgi.com Thu Jun 21 14:08:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LL8mF21147 for linux-xfs-outgoing; Thu, 21 Jun 2001 14:08:48 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LL8lV21144 for ; Thu, 21 Jun 2001 14:08:47 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA26518 for ; Thu, 21 Jun 2001 14:08:42 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2227577; Thu, 21 Jun 2001 16:07:31 -0500 (CDT) Received: from sgi.com (eagdhcp-195-17.americas.sgi.com [128.162.195.187]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA93152; Thu, 21 Jun 2001 16:07:30 -0500 (CDT) Message-ID: <3B3261FB.9109531B@sgi.com> Date: Thu, 21 Jun 2001 16:07:07 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: crossfs@bizland.com CC: linux-xfs@oss.sgi.com Subject: Re: XFS source before porting to linux References: <54319.198.4.92.5.993155803.squirrel@webmail.bizland.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk crossfs@bizland.com wrote: > How can I get the reference XFS source before it was ported to Linux My guess is that you can't - a lot of effort went into making sure there was no cross-licensing in the XFS code, removing any encumbrance that may have been there due to code that SGI did not own the copyright on. I believe that the code was made available shortly after the licensing review, so the earliest files in CVS probably represents the oldest code available under the GPL. The original Irix code is not available, due to licensing issues. I wasn't with the project at the start, Russell can probably chime in for you - he may know if there's a tag for the first CVS versions. -Eric From owner-linux-xfs@oss.sgi.com Thu Jun 21 14:14:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LLEmA21382 for linux-xfs-outgoing; Thu, 21 Jun 2001 14:14:48 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LLElV21379 for ; Thu, 21 Jun 2001 14:14:47 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA27433; Thu, 21 Jun 2001 23:14:45 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA12518; Thu, 21 Jun 2001 23:14:45 +0200 (CEST) Date: Thu, 21 Jun 2001 23:14:44 +0200 (CEST) From: Seth Mos To: Eric Sandeen cc: crossfs@bizland.com, linux-xfs@oss.sgi.com Subject: Re: XFS source before porting to linux In-Reply-To: <3B3261FB.9109531B@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 21 Jun 2001, Eric Sandeen wrote: > crossfs@bizland.com wrote: > > > How can I get the reference XFS source before it was ported to Linux > > My guess is that you can't - a lot of effort went into making sure there > was no cross-licensing in the XFS code, removing any encumbrance that > may have been there due to code that SGI did not own the copyright on. > > I believe that the code was made available shortly after the licensing > review, so the earliest files in CVS probably > represents the oldest code available under the GPL. The original Irix > code is not available, due to licensing issues. > > I wasn't with the project at the start, Russell can probably chime in > for you - he may know if there's a tag for the first CVS versions. > > -Eric > The oldest I see in CVS is for some early 2.3.x kernel. That is a long time ago but it probably already had those interfaces by then. Cheers Seth From owner-linux-xfs@oss.sgi.com Thu Jun 21 14:22:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LLMch21615 for linux-xfs-outgoing; Thu, 21 Jun 2001 14:22:38 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LLMaV21612 for ; Thu, 21 Jun 2001 14:22:36 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA28929; Thu, 21 Jun 2001 23:22:34 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA15718; Thu, 21 Jun 2001 23:22:32 +0200 (CEST) Date: Thu, 21 Jun 2001 23:22:32 +0200 (CEST) From: Seth Mos To: daedalus@freemail.it cc: linux-xfs@oss.sgi.com Subject: Re: XFS 1.0.1 testing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 21 Jun 2001 daedalus@freemail.it wrote: > On Thu, 21 Jun 2001 13:39:00 +0200, daedalus@freemail.it wrote: > > >I have made a set of 2 floppy disk (minix fs) images (boot 1440 and > >root 1600), derived from bare.i and color.gz, > >featuring a Slackware 8.0.0 (not yet released) installer. > > [snip] > > >anyway I hope you will take a look and test and do whatever you want > >with this stuff at > >http://village.flashnet.it/users/fn048069/files/XFS/ > > > I apologize for the inconvinience... I should have known my ISP > doesn't allow directory listing! > > I am uploading a tarball with all the contents of that dir > http://village.flashnet.it/users/fn048069/files/XFS.tar.gz > I will add the link to the FAQ. Can you also upload your explanation of the contents to the site so I can link to the README. Thanks you Seth From owner-linux-xfs@oss.sgi.com Thu Jun 21 14:58:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LLw4w22275 for linux-xfs-outgoing; Thu, 21 Jun 2001 14:58:04 -0700 Received: from biobio.vexcel.com (biobio.vexcel.com [192.92.90.108]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LLw3V22272 for ; Thu, 21 Jun 2001 14:58:03 -0700 Received: from [192.92.90.17] (binks.vexcel.com [192.92.90.17]) by biobio.vexcel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA12563 for ; Thu, 21 Jun 2001 15:57:53 -0600 (MDT) Mime-Version: 1.0 X-Sender: brissing@mail.vexcel.com (Unverified) Message-Id: Date: Thu, 21 Jun 2001 15:57:24 -0600 To: linux-xfs@oss.sgi.com From: Dean Brissinger Subject: NFS bugs w/ SGI's Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! I'm encountering something that keeps me from using Linux in my environment. There is a bug in the linux kernel 2.2.18 and 2.4.present kernels that will cause some files not to show up over NFS mounts from Irix systems. I found my problem is discussed in detail at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=30944 and there is a patch for my problem: http://www.fys.uio.no/~trondmy/src/2.4.2/ BUT! I cannot get the patch to compile with the XFS kernel with devfs. I thought it would take me an hour or two but have now spent all day on it. I get though the compile with a vanilla config file (all defaults) but when linking get the following message: >/tmp/cc9HoxYq.s: Assembler messages: >/tmp/cc9HoxYq.s:1056: Error: suffix or operands invalid for `shl' >/tmp/cc9HoxYq.s:1112: Error: suffix or operands invalid for `shl' >make[1]: *** [entry.o] Error 1 >make[1]: Leaving directory `src/linux-2.4-xfs-r1.0/linux/arch/i386/kernel' >make: *** [_dir_arch/i386/kernel] Error 2 A quick search on google resulted in a couple of anonymous posts that claim to have this working. Has anyone got this patch working with the XFS kernel? I'd love either for a binary RPM (RH 7.1) of the patched kernel or a working source tree. Can ya help? -- . . . . . . . . ooo . . . . ooo . . . . . . . . . . . . Dean Brissinger - Systems Administrator . . Direct: 303-583-0278 Main: 303-444-0094 . . Fax: 303-583-0246 http://www.vexcel.com/ . . . . . . . . . . oOOo . . A . . oOOo . . . . . . . . 0 0 '```` From owner-linux-xfs@oss.sgi.com Thu Jun 21 15:53:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LMrp023253 for linux-xfs-outgoing; Thu, 21 Jun 2001 15:53:51 -0700 Received: from mta1n.bluewin.ch (mta1n.bluewin.ch [195.186.1.210]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LMrnV23250 for ; Thu, 21 Jun 2001 15:53:50 -0700 Received: from rubistar (195.186.136.190) by mta1n.bluewin.ch (Bluewin AG MX engine 5.5.031) id 3B2F46B0000A8210; Fri, 22 Jun 2001 00:51:20 +0200 Message-ID: <01f901c0faa5$71404880$6402a8c0@rubistar> From: "Thomas von Steiger" To: "Deti Fliegl" , "Joshua Baker-LePain" Cc: References: <3B2B9A04.12BDDC7A@fliegl.de> Subject: Re: lost+found Date: Fri, 22 Jun 2001 00:56:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks, If a xfs Filesystem is 100% full, is it posible for xfs_repair to build a temp lost+found ? Repair is wunderfull, if i have a power interrupt...!! regards, thomas > Joshua Baker-LePain wrote: > > > > On Sat, 16 Jun 2001 at 7:20pm, Thomas von Steiger wrote > > > > > If i create a XFS Filesystem on Disk, has this Filesystem a lost+found > > > inside ? > > > I have a XFS Filesystem on a old Redhat 6.1, becose there is no lost+found. > > > > There's no lost+found. I'm assuming that's because of the journal and the > > fact that "lost" items are "found" in place. They may be corrupt if they > > were being written, but they won't be lost. > > A lost+found directory will be created automatically when using > xfs_repair. This utility corresponds to the well known fsck which checks > and repairs a filesystem. Under normal circumstances you never need to > run xfs_repair (unless something goes badly wrong). > > Have a lot of fun with XFS... > > Deti From owner-linux-xfs@oss.sgi.com Thu Jun 21 15:59:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LMxuN23445 for linux-xfs-outgoing; Thu, 21 Jun 2001 15:59:56 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LMxtV23442 for ; Thu, 21 Jun 2001 15:59:55 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA04076 for ; Thu, 21 Jun 2001 15:59:55 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2229181; Thu, 21 Jun 2001 17:58:37 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA04837; Thu, 21 Jun 2001 17:58:37 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5LN28H27325; Thu, 21 Jun 2001 18:02:08 -0500 Message-Id: <200106212302.f5LN28H27325@jen.americas.sgi.com> To: "Thomas von Steiger" cc: "Deti Fliegl" , "Joshua Baker-LePain" , linux-xfs@oss.sgi.com Subject: Re: lost+found References: <3B2B9A04.12BDDC7A@fliegl.de> <01f901c0faa5$71404880$6402a8c0@rubistar> Comments: In-reply-to "Thomas von Steiger" message dated "Fri, 22 Jun 2001 00:56:43 +0200." Date: Thu, 21 Jun 2001 18:02:08 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Thanks, > > If a xfs Filesystem is 100% full, is it posible for xfs_repair to build a > temp lost+found ? > Repair is wunderfull, if i have a power interrupt...!! > > regards, > thomas > Well, since lost+found is relinking existing files from elsewhere which have become disconnected it potentially does not consume any space at all, presuming that: o there is room in the root directory for one extra entry without adding a new disk block. o there is a spare inode somewhere - remember these are allocated in chunks and never freed, so chances are good. o All the lost+found entries fit in the directory inode. But even if all of these fail, 4 disk blocks is probably all it takes at maximum, maybe more if there are lots of entries to recover. So it depends on your definition of full. Steve From owner-linux-xfs@oss.sgi.com Thu Jun 21 16:03:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LN3uA23609 for linux-xfs-outgoing; Thu, 21 Jun 2001 16:03:56 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LN3tV23606 for ; Thu, 21 Jun 2001 16:03:55 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA00848 for ; Thu, 21 Jun 2001 16:03:55 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA2146410; Thu, 21 Jun 2001 18:02:29 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA90082; Thu, 21 Jun 2001 18:02:29 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5LN61327351; Thu, 21 Jun 2001 18:06:01 -0500 Message-Id: <200106212306.f5LN61327351@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Dean Brissinger cc: linux-xfs@oss.sgi.com Subject: Re: NFS bugs w/ SGI's In-Reply-To: Message from Dean Brissinger of "Thu, 21 Jun 2001 15:57:24 MDT." Date: Thu, 21 Jun 2001 18:06:01 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This looks more like general kernel compilation problems than something about the patch itself. Which compiler and tools are you using? Steve > Hi! > > I'm encountering something that keeps me from using Linux in > my environment. There is a bug in the linux kernel 2.2.18 and > 2.4.present kernels that will cause some files not to show up over > NFS mounts from Irix systems. I found my problem is discussed in > detail at: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=30944 > > and there is a patch for my problem: > > http://www.fys.uio.no/~trondmy/src/2.4.2/ > > > BUT! I cannot get the patch to compile with the XFS kernel with > devfs. I thought it would take me an hour or two but have now spent > all day on it. I get though the compile with a vanilla config file > (all defaults) but when linking get the following message: > > >/tmp/cc9HoxYq.s: Assembler messages: > >/tmp/cc9HoxYq.s:1056: Error: suffix or operands invalid for `shl' > >/tmp/cc9HoxYq.s:1112: Error: suffix or operands invalid for `shl' > >make[1]: *** [entry.o] Error 1 > >make[1]: Leaving directory `src/linux-2.4-xfs-r1.0/linux/arch/i386/kernel' > >make: *** [_dir_arch/i386/kernel] Error 2 > > > A quick search on google resulted in a couple of anonymous posts that > claim to have this working. Has anyone got this patch working with > the XFS kernel? > > I'd love either for a binary RPM (RH 7.1) of the patched > kernel or a working source tree. Can ya help? > > -- > . . . . . . . . ooo . . . . ooo . . . . . . . . . > . . > . Dean Brissinger - Systems Administrator . > . Direct: 303-583-0278 Main: 303-444-0094 . > . Fax: 303-583-0246 http://www.vexcel.com/ . > . . > . . . . . . . oOOo . . A . . oOOo . . . . . . . . > 0 0 > '```` From owner-linux-xfs@oss.sgi.com Thu Jun 21 16:41:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LNfih24087 for linux-xfs-outgoing; Thu, 21 Jun 2001 16:41:44 -0700 Received: from foo.penguincomputing.com (gateway.penguincomputing.com [63.143.102.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LNfhV24084 for ; Thu, 21 Jun 2001 16:41:43 -0700 Received: from localhost (jwright@localhost) by foo.penguincomputing.com (8.11.0/8.11.0) with ESMTP id f5LNfPB13780; Thu, 21 Jun 2001 16:41:39 -0700 X-Authentication-Warning: foo.penguincomputing.com: jwright owned process doing -bs Date: Thu, 21 Jun 2001 16:41:25 -0700 (PDT) From: Jim Wright Reply-To: Jim Wright To: Steve Lord cc: , Jim Wright Subject: Re: oops with 2.4.5 + xfs + md raid0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 18 Jun 2001, I reported an oops when using XFS. While I can't confirm with certainty, I believe the problem was bad memory and not software. Jim From owner-linux-xfs@oss.sgi.com Thu Jun 21 19:59:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5M2xSR26156 for linux-xfs-outgoing; Thu, 21 Jun 2001 19:59:28 -0700 Received: from io.cox-internet.com (io-cox.cox-internet.com [208.180.118.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5M2xRV26153 for ; Thu, 21 Jun 2001 19:59:27 -0700 Received: from powerhouse ([208.180.6.185]) by io.cox-internet.com (InterMail vK.4.02.00.10 201-232-116-110 license dd72657b95c070b1853187e4f5a0d6a7) with SMTP id <20010622025818.CLVP29067.io@powerhouse> for ; Thu, 21 Jun 2001 21:58:18 -0500 Message-ID: <000701c0fac7$66291c20$0201a8c0@powerhouse> From: "Stephen Parker" To: Subject: xfs kernel src Date: Thu, 21 Jun 2001 21:59:48 -0500 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I recently installed Linux xfs using the install cd for Redhat7.1. I use an Nvidia card and tried to compile the driver (using SYSINCLUDE=/usr/src/linux-2.4/include). I keep getting unresolved symbols. Is the xfs kernel src significantly different than the normal 2.4.2 distribution? I tried to install the nvidia driver the easy way and the long way. I get the same results, unresolved symbols. I am assuming that the correct kernel tree was installed to my system even though I used the xfs install cd. I have to imagine someone there used the xfs install on an smp system and then upgraded the nvidia driver to the hardware accelerated one from their site. Of course, I could be wrong. I am somewhat of a neophyte to all of this. But I have used a compiler before and I get the general idea of what's going on, things don't match up. I used the rpm install first, which failed, then went on to use the src tarball. I know you guys aren't responsible for fixing problems with other people's hardware, but was curious to see if anyone in-house came across this problem. Thanks, Stephen Parker From owner-linux-xfs@oss.sgi.com Thu Jun 21 21:36:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5M4apm27159 for linux-xfs-outgoing; Thu, 21 Jun 2001 21:36:51 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5M4aoV27156 for ; Thu, 21 Jun 2001 21:36:50 -0700 Received: from idcomm.com (IDENT:stimits@x2-pip15.idcomm.com [209.60.72.26]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5M4bQl16546 for ; Thu, 21 Jun 2001 22:37:26 -0600 Message-ID: <3B32CBBC.D07E7D40@idcomm.com> Date: Thu, 21 Jun 2001 22:38:20 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: xfs kernel src References: <000701c0fac7$66291c20$0201a8c0@powerhouse> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Stephen Parker wrote: > > I recently installed Linux xfs using the install cd for Redhat7.1. I use an > Nvidia card and tried to compile the driver (using > SYSINCLUDE=/usr/src/linux-2.4/include). I keep getting unresolved symbols. > Is the xfs kernel src significantly different than the normal 2.4.2 > distribution? I tried to install the nvidia driver the easy way and the long > way. I get the same results, unresolved symbols. I am assuming that the > correct kernel tree was installed to my system even though I used the xfs > install cd. > > I have to imagine someone there used the xfs install on an smp system and > then upgraded the nvidia driver to the hardware accelerated one from their > site. Of course, I could be wrong. I am somewhat of a neophyte to all of > this. But I have used a compiler before and I get the general idea of what's > going on, things don't match up. I used the rpm install first, which failed, > then went on to use the src tarball. I know you guys aren't responsible for > fixing problems with other people's hardware, but was curious to see if > anyone in-house came across this problem. > > Thanks, > Stephen Parker One snag you might be running into is that RH 7.1 makes directories /usr/include/asm, /usr/include/linux, and /usr/include/scsi hard copies of their kernel. You probably want to cd to /usr/include, and rename (mv) asm, linux, and scsi, to some backup. Then also expand on their symbolic links at /usr/src/. Currently, they create a sym link from linux-2.4.2-whatever to linux-2.4; you want to make an additional link from linux-2.4 to linux: cd /usr/src ln -s linux-2.4 linux Then move the original kernel source over for reference, something like linux-2.4.2-something, change the sym link to point at your xfs source, e.g., install the xfs source as directory /usr/src/linux-2.4.5-xfs, and add this sym link: cd /usr/src ln -s linux-2.4.5-xfs linux-2.4 Then make sym links at /usr/include to point at your current source: cd /usr/include ln -s /usr/src/linux/include/asm-i386 asm ln -s /usr/src/linux/include/linux linux ln -s /usr/src/linux/include/scsi scsi Until you do that, you don't know you are compiling the NVidia drivers against the XFS source. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Thu Jun 21 21:55:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5M4t4E27369 for linux-xfs-outgoing; Thu, 21 Jun 2001 21:55:04 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5M4t3V27366 for ; Thu, 21 Jun 2001 21:55:04 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id VAA06067 for ; Thu, 21 Jun 2001 21:55:01 -0700 (PDT) mail_from (kaos@ocs.com.au) 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 OAA07827; Fri, 22 Jun 2001 14:53:41 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: stimits@idcomm.com cc: linux-xfs@oss.sgi.com Subject: Re: xfs kernel src In-reply-to: Your message of "Thu, 21 Jun 2001 22:38:20 CST." <3B32CBBC.D07E7D40@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Jun 2001 14:53:41 +1000 Message-ID: <22036.993185621@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 21 Jun 2001 22:38:20 -0600, "D. Stimits" wrote: >One snag you might be running into is that RH 7.1 makes directories >/usr/include/asm, /usr/include/linux, and /usr/include/scsi hard copies >of their kernel. You probably want to cd to /usr/include, and rename >(mv) asm, linux, and scsi, to some backup. Then also expand on their >symbolic links at /usr/src/. Please do not do that. Linus and other kernel maintainers fought a long and hard battle to stop distributions making symlinks from /usr/include to /usr/src/linux, or to any other active kernel. The files in /usr/include are for user space applications that need a stable set of includes. These must not change depending on which kernel you have installed this week. User space code cannot assume that it has current kernel headers, instead they get headers that match glibc and other tools. User space code should not read kernel headers directly, instead the package should contain a copy of the required definitions. It is almost always a bad idea for user space applications to depend on kernel headers. Even code like modutils that hooks right into the kernel has its own copy of the required kernel headers, it is the only way to ensure that it ca be compiled on any kernel. Kernel based code must be compiled against kernel headers, not against /usr/include. The kernel makefiles try to avoid reading from anything outside the kernel. From owner-linux-xfs@oss.sgi.com Thu Jun 21 23:13:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5M6DwN28774 for linux-xfs-outgoing; Thu, 21 Jun 2001 23:13:58 -0700 Received: from epithumia.math.uh.edu (IDENT:root@epithumia.math.uh.edu [129.7.128.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5M6DvV28771 for ; Thu, 21 Jun 2001 23:13:57 -0700 Received: (from tibbs@localhost) by epithumia.math.uh.edu (8.11.0/8.11.1) id f5M6Dq230754; Fri, 22 Jun 2001 01:13:52 -0500 To: Tru Huynh Cc: linux-xfs@oss.sgi.com Subject: Re: 3ware (was Re: XFS and RAID5) References: <3B2DE89C.DEF5D5B7@pasteur.fr> From: Jason L Tibbitts III Date: 22 Jun 2001 01:13:52 -0500 In-Reply-To: Tru Huynh's message of "Mon, 18 Jun 2001 16:40:12 +0500" Message-ID: Lines: 17 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "TH" == Tru Huynh writes: TH> We are testing the 7+1 raid5 solution on a Rocky 3782-EV motherboard TH> (i815E) and a p3-800eb with 2x256MB ram. And the performace with the TH> raid5 hardware was "bad": I had some problems when I originally set up my box (XFS/RedHat 1.0, 3ware Escalalade 6800, 8xIBM 76GB disks). The array was horribly, incredibly slow. It turns out that for some reason it needed to do a full rebuild. This doesn't show up as activity on the external activity LED and since 3ware doesn't provide any command line tools the only way to see that it's rebuilding is to run their stupid web-based thing. But after six or so hours the speed went back up to something reasonable; hdparm reports around 51MB/sec reads (versus less than 1MB/sec before). - J< From owner-linux-xfs@oss.sgi.com Fri Jun 22 00:41:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5M7fEP29879 for linux-xfs-outgoing; Fri, 22 Jun 2001 00:41:14 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5M7fCV29876 for ; Fri, 22 Jun 2001 00:41:13 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id JAA25448; Fri, 22 Jun 2001 09:41:02 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id JAA11927; Fri, 22 Jun 2001 09:41:01 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 508DF57306; Fri, 22 Jun 2001 09:50:21 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 2567625835; Fri, 22 Jun 2001 09:58:38 +0200 (CEST) Message-ID: <3B32F76A.16229BA5@ch.sauter-bc.com> Date: Fri, 22 Jun 2001 09:44:42 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Steve Lord Cc: linux-xfs Subject: LVM and XFS in 1.0.1-PR1 and usability in production References: <200106211608.f5LG8m713919@jen.americas.sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, One question regarding kernel RPM's: I've built new RPM's from kernel-2.4.5-0.2.9_SGI_XFS_20010613.src.rpm and from kernel-2.4.2-SGI_XFS_1.0.1_PR1.src.rpm. I patched the them to support the new Promise Ultra100 TX2 chipset and I disabled REISERFS_CHECK to make reiserfs usable as well. I'm not using it but if it's compiled in, it should be done right. Beside those two changes I didn't touch enything in the .spec or any .config file. After booting the PR1 kernel I found out that LVM support has gone. I was checking the .config files against Release-1.0 and found out that quite alot changes were there. Why? Are there so many XFS related changes or did it just happen by chance. I enabled LVM in all Intel .configs, rebuilt tonight and tested now. Seems to work fine. Is there a problem with LVM in PR1 or is it as (un)safe to use than in 1.0? About usability and stability: I'm installing a 200GB server and a second one as mirror. The system will serve samba to ~50 users. System comes on SoftRAID1, data on SoftRAID5 with LVM on top and XFS on the server, ext2 on the mirror because of snapshotting. I've built a similar setup at home on my old Pentium200MMX with 64M ram and it was absolutely stable under heavy load. The problem with the new servers is that they will be located in London and I'm sitting in Basel/Switzerland. I did not find any big problem with XFS until now and I really don't want ext2. Yesterday you said > We use it here, but generally we have upgraded beyond the 1.0 release and > run later kernels. The machine hosting the oss website was recently upgraded > to the 1.0 release, but was getting an uptime of about 24 hours before it > hung. We have bumped it up to a more recent version of XFS, the one in the > test 1.0.1 rpms here Will it crash after a week or so? Did I missunderstand? Am I very crazy? If I'm doing it what version should I take, 1.0 or 1.0.1-PR1. Is it a big difference regarding stability? Greetings Simon -- 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 Fri Jun 22 01:08:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5M884Y30336 for linux-xfs-outgoing; Fri, 22 Jun 2001 01:08:04 -0700 Received: from pipt.oz.cc.utah.edu (jdr1529@pipt.oz.cc.utah.edu [155.99.2.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5M883V30333 for ; Fri, 22 Jun 2001 01:08:03 -0700 Received: from localhost (jdr1529@localhost) by pipt.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id CAA12457; Fri, 22 Jun 2001 02:07:56 -0600 (MDT) Date: Fri, 22 Jun 2001 02:07:55 -0600 (MDT) From: james rich To: daedalus@freemail.it cc: linux-xfs@oss.sgi.com Subject: Re: XFS 1.0.1 testing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 21 Jun 2001 daedalus@freemail.it wrote: > I have made a set of 2 floppy disk (minix fs) images (boot 1440 and > root 1600), derived from bare.i and color.gz, > featuring a Slackware 8.0.0 (not yet released) installer. Fantastic!! I was going to do the same, but another project deadline took priority. All my boxes are slackware and not having an XFS aware kernel on a boot floppy has been a pain when upgrading my machines (more correctly - erasing everything and starting over, nothing like a clean slate). Feel free to contact me if you want these images mirrored at my slackware mirror site. James Rich james.rich@m.cc.utah.edu From owner-linux-xfs@oss.sgi.com Fri Jun 22 01:13:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5M8DI230468 for linux-xfs-outgoing; Fri, 22 Jun 2001 01:13:18 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5M8DGV30465 for ; Fri, 22 Jun 2001 01:13:16 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5M8D8V01142; Fri, 22 Jun 2001 10:13:08 +0200 Message-Id: <4.3.2.7.2.20010622100300.02d946f0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Jun 2001 10:13:02 +0200 To: Simon Matter , Steve Lord From: Seth Mos Subject: Re: LVM and XFS in 1.0.1-PR1 and usability in production Cc: linux-xfs In-Reply-To: <3B32F76A.16229BA5@ch.sauter-bc.com> References: <200106211608.f5LG8m713919@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 09:44 22-6-2001 +0200, Simon Matter wrote: >Hi, > >One question regarding kernel RPM's: >I've built new RPM's from kernel-2.4.5-0.2.9_SGI_XFS_20010613.src.rpm >and from kernel-2.4.2-SGI_XFS_1.0.1_PR1.src.rpm. I patched the them to >support the new Promise Ultra100 TX2 chipset and I disabled >REISERFS_CHECK to make reiserfs usable as well. I'm not using it but if >it's compiled in, it should be done right. Beside those two changes I >didn't touch enything in the .spec or any .config file. After booting >the PR1 kernel I found out that LVM support has gone. I was checking the >.config files against Release-1.0 and found out that quite alot changes >were there. Why? Are there so many XFS related changes or did it just >happen by chance. I enabled LVM in all Intel .configs, rebuilt tonight >and tested now. Seems to work fine. Is there a problem with LVM in PR1 >or is it as (un)safe to use than in 1.0? The intial rpms were spun by Russel who just took the src.rpm from redhat rawhide and forked all the patches in so that it compiled. He did not alter the .config file in any way. That is probably the reason it got overlooked. Russel is now doing this in his spare time which is probably the reason he overlooked it. >About usability and stability: >I'm installing a 200GB server and a second one as mirror. The system >will serve samba to ~50 users. System comes on SoftRAID1, data on >SoftRAID5 with LVM on top and XFS on the server, ext2 on the mirror >because of snapshotting. I've built a similar setup at home on my old >Pentium200MMX with 64M ram and it was absolutely stable under heavy >load. The problem with the new servers is that they will be located in >London and I'm sitting in Basel/Switzerland. I did not find any big >problem with XFS until now and I really don't want ext2. Yesterday you >said > > We use it here, but generally we have upgraded beyond the 1.0 release and > > run later kernels. The machine hosting the oss website was recently > upgraded > > to the 1.0 release, but was getting an uptime of about 24 hours before it > > hung. We have bumped it up to a more recent version of XFS, the one in the > > test 1.0.1 rpms here >Will it crash after a week or so? Did I missunderstand? Am I very crazy? >If I'm doing it what version should I take, 1.0 or 1.0.1-PR1. Is it a >big difference regarding stability? What Steve ment was that the original 1.0 release (2.4.2) crashed within a day. The later CVS kernels and the rawhide kernels are a lot better on stability. If oss.sgi.com can move 350GB in 3 days you can too. The problem is that we get bitten more by general 2.4 problems and not really any XFS problems. The 2.4 kernel is going the right direction and getting better. I think that when it reaches 2.4.10 you can probably throw everything and kitchensink against it and it will survive. By then most distributions will even include it as the default kernel. But for now the CVS and rawhide kernels hold up fairly wel. Test it for your environment and demands and see if it plays out well. For lighter loads you are safe. On higher loads and highmem machines it is better to avoid 2.4 for now. And I mean 2.4 not XFS perse. Bye -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Jun 22 01:14:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5M8Exa30566 for linux-xfs-outgoing; Fri, 22 Jun 2001 01:14:59 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5M8EvV30563 for ; Fri, 22 Jun 2001 01:14:57 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5M8EkV01171; Fri, 22 Jun 2001 10:14:46 +0200 Message-Id: <4.3.2.7.2.20010622101319.02e44e80@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Jun 2001 10:14:41 +0200 To: james rich , daedalus@freemail.it From: Seth Mos Subject: Re: XFS 1.0.1 testing Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 02:07 22-6-2001 -0600, james rich wrote: >On Thu, 21 Jun 2001 daedalus@freemail.it wrote: > > > I have made a set of 2 floppy disk (minix fs) images (boot 1440 and > > root 1600), derived from bare.i and color.gz, > > featuring a Slackware 8.0.0 (not yet released) installer. > >Fantastic!! I was going to do the same, but another project deadline took >priority. All my boxes are slackware and not having an XFS aware kernel >on a boot floppy has been a pain when upgrading my machines (more >correctly - erasing everything and starting over, nothing like a clean >slate). Feel free to contact me if you want these images mirrored at my >slackware mirror site. > >James Rich >james.rich@m.cc.utah.edu Make sure to use the CURRENT tree because the older 7 does not have large file support. This was one of the first things I noticed on a Slackware system with a XFS kernel. But for the rest it functions properly. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Jun 22 01:35:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5M8Z1a30929 for linux-xfs-outgoing; Fri, 22 Jun 2001 01:35:01 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5M8YxV30926 for ; Fri, 22 Jun 2001 01:35:00 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id F2E511E09B for ; Fri, 22 Jun 2001 10:34:53 +0200 (MEST) Date: Fri, 22 Jun 2001 10:34:53 +0200 From: Andi Kleen To: linux-xfs@oss.sgi.com Subject: [PATCH] Add nouuid option Message-ID: <20010622103453.A29958@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Following patch adds a nouuid mount option to XFS, which makes it not check if the file system uuid is unique on the system. This is useful to mount LVM snapshot volumes without having to play games with xfsdb. -Andi --- linux-xfs/fs/xfs/linux/xfs_super.c-NOUUID Wed May 30 23:58:59 2001 +++ linux-xfs/fs/xfs/linux/xfs_super.c Mon Jun 18 21:59:12 2001 @@ -78,6 +78,7 @@ #define MNTOPT_QUOTANOENF "qnoenforce" /* same as uqnoenforce */ #define MNTOPT_RO "ro" /* read only */ #define MNTOPT_RW "rw" /* read/write */ +#define MNTOPT_NOUUID "nouuid" /* Ignore FS uuid */ STATIC int mountargs_xfs( @@ -225,6 +226,8 @@ args->flags |= MS_RDONLY; } else if (!strcmp(this_char, MNTOPT_NOSUID)) { args->flags |= MS_NOSUID; + } else if (!strcmp(this_char, MNTOPT_NOUUID)) { + args->flags |= XFSMNT_NOUUID; } else { printk( "mount: unknown mount option \"%s\".\n", this_char); --- linux-xfs/fs/xfs/xfs_mount.h-NOUUID Fri May 18 17:47:22 2001 +++ linux-xfs/fs/xfs/xfs_mount.h Mon Jun 18 21:59:10 2001 @@ -341,6 +341,7 @@ #define XFS_MOUNT_SHARED 0x00000800 /* shared mount */ #define XFS_MOUNT_DFLT_IOSIZE 0x00001000 /* set default i/o size */ #define XFS_MOUNT_OSYNCISDSYNC 0x00002000 /* treat o_sync like o_dsync */ +#define XFS_MOUNT_NOUUID 0x00004000 /* ignore uuid during mount */ /* * Flags for m_cxfstype --- linux-xfs/fs/xfs/xfs_clnt.h-NOUUID Fri May 18 17:47:20 2001 +++ linux-xfs/fs/xfs/xfs_clnt.h Mon Jun 18 21:59:13 2001 @@ -221,5 +221,6 @@ #define XFSMNT_GQUOTA 0x00400000 /* group quota accounting */ #define XFSMNT_GQUOTAENF 0x00800000 /* group quota limit * enforcement */ +#define XFSMNT_NOUUID 0x01000000 /* Ignore fs uuid */ #endif /* __XFS_CLNT_H__ */ --- linux-xfs/fs/xfs/xfs_vfsops.c-NOUUID Thu May 24 10:40:15 2001 +++ linux-xfs/fs/xfs/xfs_vfsops.c Mon Jun 18 21:59:10 2001 @@ -424,6 +424,9 @@ } mp->m_flags |= XFS_MOUNT_NORECOVERY; } + + if (ap->flags & XFSMNT_NOUUID) + mp->m_flags |= XFS_MOUNT_NOUUID; } /* --- linux-xfs/fs/xfs/xfs_mount.c-NOUUID Fri May 18 17:47:22 2001 +++ linux-xfs/fs/xfs/xfs_mount.c Mon Jun 18 21:59:09 2001 @@ -604,7 +604,7 @@ * since a single partition filesystem is identical to a single * partition volume/filesystem. */ - if ((mfsi_flags & XFS_MFSI_SECOND) == 0) { + if ((mfsi_flags & XFS_MFSI_SECOND) == 0 && (mp->m_flags & XFS_MOUNT_NOUUID) == 0) { if (xfs_uuid_mount(mp)) { error = XFS_ERROR(EINVAL); goto error1; --- linux-xfs/Documentation/filesystems/xfs.txt-NOUUID Mon Jun 18 23:16:03 2001 +++ linux-xfs/Documentation/filesystems/xfs.txt Mon Jun 18 23:18:33 2001 @@ -105,3 +105,7 @@ instead of buffer heads. This is implemented for ide and scsi devices, it is not available for lvm or md at the moment. + nouuid + Don't check for double mounted file systems using the file system uuid. + This is useful to mount LVM snapshot volumes. + From owner-linux-xfs@oss.sgi.com Fri Jun 22 01:44:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5M8iNf31101 for linux-xfs-outgoing; Fri, 22 Jun 2001 01:44:23 -0700 Received: from pipt.oz.cc.utah.edu (jdr1529@pipt.oz.cc.utah.edu [155.99.2.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5M8iMV31098 for ; Fri, 22 Jun 2001 01:44:22 -0700 Received: from localhost (jdr1529@localhost) by pipt.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id CAA13089; Fri, 22 Jun 2001 02:44:16 -0600 (MDT) Date: Fri, 22 Jun 2001 02:44:15 -0600 (MDT) From: james rich To: Seth Mos cc: linux-xfs@oss.sgi.com Subject: Re: XFS 1.0.1 testing In-Reply-To: <4.3.2.7.2.20010622101319.02e44e80@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 22 Jun 2001, Seth Mos wrote: > At 02:07 22-6-2001 -0600, james rich wrote: > >On Thu, 21 Jun 2001 daedalus@freemail.it wrote: > > > > > I have made a set of 2 floppy disk (minix fs) images (boot 1440 and > > > root 1600), derived from bare.i and color.gz, > > > featuring a Slackware 8.0.0 (not yet released) installer. > > > >slate). Feel free to contact me if you want these images mirrored at my > >slackware mirror site. > > Make sure to use the CURRENT tree because the older 7 does not have large > file support. This was one of the first things I noticed on a Slackware > system with a XFS kernel. But for the rest it functions properly. I only mirror -current due to space limitations (and to the fact that since I have 7.1 CD I don't need a 7.1 mirror). So no problem there. James Rich james.rich@m.cc.utah.edu From owner-linux-xfs@oss.sgi.com Fri Jun 22 02:22:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5M9Mob31687 for linux-xfs-outgoing; Fri, 22 Jun 2001 02:22:50 -0700 Received: from mail.cc.kuleuven.ac.be (mail.cc.kuleuven.ac.be [134.58.10.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5M9MmV31684 for ; Fri, 22 Jun 2001 02:22:49 -0700 Received: from pclab (pc-10-33-6-229.cc.kuleuven.ac.be [10.33.6.229]) by mail.cc.kuleuven.ac.be (8.9.3/8.9.0) with SMTP id LAA1003784 for ; Fri, 22 Jun 2001 11:22:45 +0200 Message-Id: <3.0.6.32.20010622112214.007b7db0@mail.cc.kuleuven.ac.be> X-Sender: pb429905@mail.cc.kuleuven.ac.be X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 22 Jun 2001 11:22:14 +0200 To: linux-xfs@oss.sgi.com From: werner maes Subject: XFS installation on Compaq ML 350 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I tried to install RH 7.1 & XFS on a Compaq ML 350 server using the ISO image provided by SGI. The server has two SCSI-disks configured in RAID-1. The installation seemed to worked fine, but after the reboot several problems occured. Several files were not found (e.g. chgrp, locate, network information,...). It was not possible to install programs using rpm. My question: Is this a known problem? Or are the drivers for the Compaq RAID card not included (Compaq RAID LC2 controller)? If you want, I can provide a more detailed description of the error messages. Werner Maes KULeuven From owner-linux-xfs@oss.sgi.com Fri Jun 22 02:49:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5M9n2k32118 for linux-xfs-outgoing; Fri, 22 Jun 2001 02:49:02 -0700 Received: from electre.pasteur.fr (electre.pasteur.fr [157.99.64.120]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5M9mvV32115 for ; Fri, 22 Jun 2001 02:48:58 -0700 Received: from pasteur.fr (xiii.bis.pasteur.fr [157.99.90.14]) by electre.pasteur.fr (8.11.4/8.11.4) with ESMTP id f5M9mM058323; Fri, 22 Jun 2001 11:48:27 +0200 (CEST) Message-ID: <3B331466.54E7918A@pasteur.fr> Date: Fri, 22 Jun 2001 14:48:22 +0500 From: Tru Huynh Organization: Institut Pasteur X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jason L Tibbitts III CC: linux-xfs@oss.sgi.com Subject: Re: 3ware (was Re: XFS and RAID5) References: <3B2DE89C.DEF5D5B7@pasteur.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jason L Tibbitts III wrote: > > I had some problems when I originally set up my box (XFS/RedHat 1.0, 3ware > Escalalade 6800, 8xIBM 76GB disks). The array was horribly, incredibly > slow. It turns out that for some reason it needed to do a full rebuild. > This doesn't show up as activity on the external activity LED and since > 3ware doesn't provide any command line tools the only way to see that it's > rebuilding is to run their stupid web-based thing. > I did see that behaviour too, but it was not the case. the 3dm 3ware daemon reportsed ready (not rebuilding). > But after six or so hours the speed went back up to something reasonable; > hdparm reports around 51MB/sec reads (versus less than 1MB/sec before). > I am now thinking that is is not related to the 3ware card nor to xfs. Even with de-activating the 3ware driver ans accessing the system disk only the memory access measured by hdparm tops at 100MB/s. It is not related to xfs at all, and does not depend on the following kernels 2.4.2-2 (Redhat 7.1) 2.4.5ac13 2.4.2-2_SGI_xfs and 2.4.5_xfs_1.0.1. When sharing the system disk on 3 different interfaces (eepro100/ 2x 3c59x) and writing to the rocky at the same time ~1-2GB, the two 3com NIC lose random packets.. Thank you for your experience, Tru -- Dr Tru Huynh | Bioinformatique Structurale mailto:tru@pasteur.fr | tel/fax +33 1 45 68 87 37/19 Institut Pasteur, 25-28 rue du Docteur Roux, 75724 Paris CEDEX 15 France From owner-linux-xfs@oss.sgi.com Fri Jun 22 02:54:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5M9sCU32262 for linux-xfs-outgoing; Fri, 22 Jun 2001 02:54:12 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5M9sBV32259 for ; Fri, 22 Jun 2001 02:54:11 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15DNdJ-0000bc-00; Fri, 22 Jun 2001 21:53:45 +1200 Date: Fri, 22 Jun 2001 21:53:45 +1200 (NZST) From: Juha Saarinen To: Tru Huynh cc: Jason L Tibbitts III , "linux-xfs@oss.sgi.com" Subject: Re: 3ware (was Re: XFS and RAID5) In-Reply-To: <3B331466.54E7918A@pasteur.fr> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 22 Jun 2001, Tru Huynh wrote: > Even with de-activating the 3ware driver ans accessing the system disk only > the memory access measured by hdparm tops at 100MB/s. VIA chip set? Try disabling USB. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Fri Jun 22 03:26:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MAQ6X32707 for linux-xfs-outgoing; Fri, 22 Jun 2001 03:26:06 -0700 Received: from smtp-server1.tampabay.rr.com (smtp-server1.tampabay.rr.com [65.32.1.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MAQ4V32704 for ; Fri, 22 Jun 2001 03:26:05 -0700 Received: from cfl.rr.com (ubr-35.87.175.wmelbourne.cfl.rr.com [65.35.87.175]) by smtp-server1.tampabay.rr.com (8.11.2/8.11.2) with ESMTP id f5MAQ3500614 for ; Fri, 22 Jun 2001 06:26:03 -0400 (EDT) Message-ID: <3B331EAA.4B4CCEE3@cfl.rr.com> Date: Fri, 22 Jun 2001 06:32:10 -0400 From: Mark Hounschell Reply-To: dmarkh@cfl.rr.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4.SuSE i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: xfs kernel src References: <22036.993185621@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > > On Thu, 21 Jun 2001 22:38:20 -0600, > "D. Stimits" wrote: > >One snag you might be running into is that RH 7.1 makes directories > >/usr/include/asm, /usr/include/linux, and /usr/include/scsi hard copies > >of their kernel. You probably want to cd to /usr/include, and rename > >(mv) asm, linux, and scsi, to some backup. Then also expand on their > >symbolic links at /usr/src/. > > Please do not do that. Linus and other kernel maintainers fought a > long and hard battle to stop distributions making symlinks from > /usr/include to /usr/src/linux, or to any other active kernel. > > The files in /usr/include are for user space applications that need a > stable set of includes. These must not change depending on which > kernel you have installed this week. > > User space code cannot assume that it has current kernel headers, > instead they get headers that match glibc and other tools. User space > code should not read kernel headers directly, instead the package > should contain a copy of the required definitions. It is almost always > a bad idea for user space applications to depend on kernel headers. > Even code like modutils that hooks right into the kernel has its own > copy of the required kernel headers, it is the only way to ensure that > it ca be compiled on any kernel. > > Kernel based code must be compiled against kernel headers, not against > /usr/include. The kernel makefiles try to avoid reading from anything > outside the kernel. Ideally this should be the case. Why do the instructions for glibc installation tell you to make those links after moving the old glibc out from under you and before you install the new one? Confused... Mark -- Mark Hounschell dmarkh@cfl.rr.com From owner-linux-xfs@oss.sgi.com Fri Jun 22 03:31:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MAVnD00377 for linux-xfs-outgoing; Fri, 22 Jun 2001 03:31:49 -0700 Received: from mailhost.Mathematik.Uni-Marburg.de (IDENT:root@pc12418.Mathematik.Uni-Marburg.DE [137.248.123.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MAVmV00374 for ; Fri, 22 Jun 2001 03:31:48 -0700 Received: from su1239.Mathematik.Uni-Marburg.DE (posern@hadar [137.248.122.55]) by mailhost.Mathematik.Uni-Marburg.de (8.11.0/8.11.0) with ESMTP id f5MAVig12467 for ; Fri, 22 Jun 2001 12:31:44 +0200 Received: from localhost (posern@localhost) by su1239.Mathematik.Uni-Marburg.DE (8.9.3/8.9.3) with ESMTP id MAA18316 for ; Fri, 22 Jun 2001 12:31:45 +0200 (MET DST) X-Authentication-Warning: hadar.Mathematik.Uni-Marburg.DE: posern owned process doing -bs Date: Fri, 22 Jun 2001 12:31:45 +0200 (MET DST) From: Knuth Posern X-Sender: posern@hadar To: linux-xfs@oss.sgi.com Subject: xfsprogs-devel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi. Why isn't there a tar-ball of the xfsprogs-devel?! There is only a rpm and this needs xfsprogs although installed as rpm - but I'd like to use the tar-balls. Greetings, Knuth Posern. From owner-linux-xfs@oss.sgi.com Fri Jun 22 03:34:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MAY9X00504 for linux-xfs-outgoing; Fri, 22 Jun 2001 03:34:09 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MAY8V00501 for ; Fri, 22 Jun 2001 03:34:08 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5MAY5V01856; Fri, 22 Jun 2001 12:34:05 +0200 Message-Id: <4.3.2.7.2.20010622123209.032d2a48@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Jun 2001 12:34:00 +0200 To: werner maes , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: XFS installation on Compaq ML 350 In-Reply-To: <3.0.6.32.20010622112214.007b7db0@mail.cc.kuleuven.ac.be> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:22 22-6-2001 +0200, werner maes wrote: > Hello, > >I tried to install RH 7.1 & XFS on a Compaq ML 350 server using the ISO image >provided by SGI. The server has two SCSI-disks configured in RAID-1. >The installation seemed to worked fine, but after the reboot several >problems occured. >Several files were not found (e.g. chgrp, locate, network information,...). >It was not >possible to install programs using rpm. > >My question: >Is this a known problem? Or are the drivers for the Compaq RAID card not >included (Compaq >RAID LC2 controller)? It might be possible that you have been bitten by blocksize problems that occured on various raid controllers in the 1.0 version. I don't know if there is a driver/update install disk that has correct drivers for this raid controller. >If you want, I can provide a more detailed description of the error messages. Yes, please. Bye -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Jun 22 04:15:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MBF6S01242 for linux-xfs-outgoing; Fri, 22 Jun 2001 04:15:06 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MBF4V01239 for ; Fri, 22 Jun 2001 04:15:04 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5MBF2V02137; Fri, 22 Jun 2001 13:15:02 +0200 Message-Id: <4.3.2.7.2.20010622131326.032c6c08@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Jun 2001 13:14:57 +0200 To: Knuth Posern , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: xfsprogs-devel In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:31 22-6-2001 +0200, Knuth Posern wrote: >Hi. > >Why isn't there a tar-ball of the xfsprogs-devel?! > >There is only a rpm and this needs xfsprogs although installed as rpm - >but I'd like to use the tar-balls. A make install-dev in the sources for the xfsprogs tarbal will do the trick. I think it is also installed by a make install. It's included in the tarball, but for rpms it is splitted out so you can install a system without headers to save space. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Jun 22 04:49:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MBnY001691 for linux-xfs-outgoing; Fri, 22 Jun 2001 04:49:34 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MBnVV01688 for ; Fri, 22 Jun 2001 04:49:31 -0700 Received: (qmail 13844 invoked from network); 22 Jun 2001 11:49:27 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 22 Jun 2001 11:49:27 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: dmarkh@cfl.rr.com cc: linux-xfs@oss.sgi.com Subject: Re: xfs kernel src In-reply-to: Your message of "Fri, 22 Jun 2001 06:32:10 -0400." <3B331EAA.4B4CCEE3@cfl.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Jun 2001 21:49:26 +1000 Message-ID: <24596.993210566@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 22 Jun 2001 06:32:10 -0400, Mark Hounschell wrote: >Keith Owens wrote: >> Linus and other kernel maintainers fought a >> long and hard battle to stop distributions making symlinks from >> /usr/include to /usr/src/linux, or to any other active kernel. > >Ideally this should be the case. Why do the instructions for glibc >installation >tell you to make those links after moving the old glibc out from under >you and >before you install the new one? The glibc maintainer and Linus disagree on this point. Most kernel developers agree with Linus and the distributions are following the no-symlink model. For old versions of glibc the symlinks were the recommended method, it may just be that glibc INSTALL is out of date. After all, it talks about kernel 2.2.1. From owner-linux-xfs@oss.sgi.com Fri Jun 22 06:21:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MDLBe02794 for linux-xfs-outgoing; Fri, 22 Jun 2001 06:21:11 -0700 Received: from msg.ecetra.com (dollar.ecetra.com [193.164.224.209]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MDL9V02791 for ; Fri, 22 Jun 2001 06:21:09 -0700 Received: from vie-ac.office.ecetra.com (vie-ac.office.ecetra.com [10.251.148.147] (may be forged)) by msg.ecetra.com (8.9.3/8.9.3) with ESMTP id PAA04328 for ; Fri, 22 Jun 2001 15:21:03 +0200 Received: from localhost (localhost [127.0.0.1]) by vie-ac.office.ecetra.com (8.11.4/8.11.3) with ESMTP id f5MDL3U10659 for ; Fri, 22 Jun 2001 15:21:03 +0200 Date: Fri, 22 Jun 2001 15:21:03 +0200 (CEST) From: Adam Cioccarelli To: Subject: xfs-progs and gcc-3.0 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I'm not sure if anyone is interested as I am sure there are bigger fish to fry at the moment, but the compilation of the xfs-progs fails when I try and use gcc-3.0 to compile them. By the way the kernel compiles and runs (24 hours uptime as I write...) === logprint === gcc-3.0 -O1 -g -DDEBUG -funsigned-char -Wall -I../include '-DVERSION="1.2.7"' -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -c -o log_print_trans.o log_print_trans.c gcc-3.0 -O1 -g -DDEBUG -funsigned-char -Wall -I../include '-DVERSION="1.2.7"' -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -c -o log_print_all.o log_print_all.c gcc-3.0 -O1 -g -DDEBUG -funsigned-char -Wall -I../include '-DVERSION="1.2.7"' -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -c -o log_misc.o log_misc.c log_misc.c:225:1: directives may not be used inside a macro argument log_misc.c:225:1: unterminated argument list invoking macro "printf" log_misc.c: In function `xlog_print_trans_header': log_misc.c:226: parse error before "magic_c" log_misc.c:226: warning: left-hand operand of comma expression has no effect log_misc.c:226: warning: left-hand operand of comma expression has no effect log_misc.c:226: warning: left-hand operand of comma expression has no effect log_misc.c:226: parse error before ')' token make[1]: *** [log_misc.o] Error 1 make: *** [default] Error 2 ------------------------------------------------------------------------------- Adam Cioccarelli (B.E Mechanical) Adam.Cioccarelli@ecetra.com Database Administrator Phone: +43 1 536 89 7725 Fax: +43 1 536 89 7719 ecetra Central European e-Finance AG Mobile:+43 664 181 4195 ------------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Fri Jun 22 06:36:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MDajG03216 for linux-xfs-outgoing; Fri, 22 Jun 2001 06:36:45 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MDagV03213 for ; Fri, 22 Jun 2001 06:36:42 -0700 Received: (qmail 14490 invoked from network); 22 Jun 2001 13:36:39 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 22 Jun 2001 13:36:39 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Adam Cioccarelli cc: linux-xfs@oss.sgi.com Subject: Re: xfs-progs and gcc-3.0 In-reply-to: Your message of "Fri, 22 Jun 2001 15:21:03 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Jun 2001 23:36:38 +1000 Message-ID: <2509.993216998@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 22 Jun 2001 15:21:03 +0200 (CEST), Adam Cioccarelli wrote: >I'm not sure if anyone is interested as I am sure there are bigger fish to >fry at the moment, but the compilation of the xfs-progs fails when I try >and use gcc-3.0 to compile them. > >gcc-3.0 -O1 -g -DDEBUG -funsigned-char -Wall -I../include >'-DVERSION="1.2.7"' -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DXFS_BIG_FILES=1 >-DXFS_BIG_FILESYSTEMS=1 -c -o log_misc.o log_misc.c >log_misc.c:225:1: directives may not be used inside a macro argument >log_misc.c:225:1: unterminated argument list invoking macro "printf" printf is allowed to be a macro and is in gcc 3.0, this change has bitten quite a few projects. I will update the tree, in the meantime apply this patch. --- cmd/xfsprogs/logprint/log_misc.c.orig Fri Jun 22 23:34:12 2001 +++ cmd/xfsprogs/logprint/log_misc.c Fri Jun 22 23:34:51 2001 @@ -220,13 +220,15 @@ magic=*(__uint32_t*)cptr; /* XXX INT_GET soon */ - if (len >= 4) - printf("%c%c%c%c:", + if (len >= 4) { #if __BYTE_ORDER == __LITTLE_ENDIAN + printf("%c%c%c%c:", magic_c[3], magic_c[2], magic_c[1], magic_c[0]); #else + printf("%c%c%c%c:", magic_c[0], magic_c[1], magic_c[2], magic_c[3]); #endif + } if (len != sizeof(xfs_trans_header_t)) { printf(" Not enough data to decode further\n"); return 1; From owner-linux-xfs@oss.sgi.com Fri Jun 22 06:42:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MDg8h03346 for linux-xfs-outgoing; Fri, 22 Jun 2001 06:42:08 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MDg7V03342 for ; Fri, 22 Jun 2001 06:42:07 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA09662 for ; Fri, 22 Jun 2001 06:41:52 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id XAA22709; Fri, 22 Jun 2001 23:41:41 +1000 Date: Fri, 22 Jun 2001 23:41:41 +1000 From: Keith Owens Message-Id: <200106221341.XAA22709@sherman.melbourne.sgi.com> Subject: TAKE - gcc 3.0 fix Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk gcc 3.0 uses a macro for printf instead of a function. That prevents the use of #ifdef within the print parameters. Date: Fri Jun 22 06:39:31 PDT 2001 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:97520a cmd/xfsprogs/logprint/log_misc.c - 1.6 From owner-linux-xfs@oss.sgi.com Fri Jun 22 06:52:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MDqZP03543 for linux-xfs-outgoing; Fri, 22 Jun 2001 06:52:35 -0700 Received: from mail.cc.kuleuven.ac.be (mail.cc.kuleuven.ac.be [134.58.10.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MDqWV03540 for ; Fri, 22 Jun 2001 06:52:33 -0700 Received: from pclab (pc-10-33-6-229.cc.kuleuven.ac.be [10.33.6.229]) by mail.cc.kuleuven.ac.be (8.9.3/8.9.0) with SMTP id PAA1524068; Fri, 22 Jun 2001 15:52:30 +0200 Message-Id: <3.0.6.32.20010622155224.00808420@mail.cc.kuleuven.ac.be> X-Sender: pb429905@mail.cc.kuleuven.ac.be X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 22 Jun 2001 15:52:24 +0200 To: Seth Mos , linux-xfs@oss.sgi.com From: werner maes Subject: Re: XFS installation on Compaq ML 350 In-Reply-To: <4.3.2.7.2.20010622123209.032d2a48@pop.xs4all.nl> References: <3.0.6.32.20010622112214.007b7db0@mail.cc.kuleuven.ac.be> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:34 22/06/2001 +0200, Seth Mos wrote: >At 11:22 22-6-2001 +0200, werner maes wrote: > >> Hello, >> >>I tried to install RH 7.1 & XFS on a Compaq ML 350 server using the ISO image >>provided by SGI. The server has two SCSI-disks configured in RAID-1. >>The installation seemed to worked fine, but after the reboot several >>problems occured. >>Several files were not found (e.g. chgrp, locate, network information,...). >>It was not >>possible to install programs using rpm. >> >>My question: >>Is this a known problem? Or are the drivers for the Compaq RAID card not >>included (Compaq >>RAID LC2 controller)? > >It might be possible that you have been bitten by blocksize problems that >occured on various raid controllers in the 1.0 version. I don't know if >there is a driver/update install disk that has correct drivers for this >raid controller. > >>If you want, I can provide a more detailed description of the error messages. When booting up for the first time: * several messages: /var/run/wtmp, /var/lock/subsys/kudzu, network, ipchains: No such file or directory * mounting local filesystems: device does not exist ==> several partitions are not mounted. * eth0: failed * Starting system logger ==> takes a LOT of time. Al these problems do NOT occur if I simply install RH 7.1. It only happens if I use XFS 1.0 Werner Maes KULeuven From owner-linux-xfs@oss.sgi.com Fri Jun 22 06:53:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MDrZJ03708 for linux-xfs-outgoing; Fri, 22 Jun 2001 06:53:35 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MDrSV03701 for ; Fri, 22 Jun 2001 06:53:29 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id PAA30635 for ; Fri, 22 Jun 2001 15:53:26 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA2232807; Fri, 22 Jun 2001 08:52:08 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA67842; Fri, 22 Jun 2001 08:52:08 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5MDtXA28456; Fri, 22 Jun 2001 08:55:33 -0500 Message-Id: <200106221355.f5MDtXA28456@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: thomas graichen cc: linux-xfs@oss.sgi.com Subject: Re: content In-Reply-To: Message from thomas graichen of "Mon, 18 Jun 2001 09:12:06 +0200." Date: Fri, 22 Jun 2001 08:55:33 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > just a small wish: can we please stay on the topic of XFS on this > list here? ... the XFS list now has reached close to half of the > traffic of the kernel list and thus i would really like to see it NO wonder I feel frazzled all the time! Unfortunately I do not have the luxury Linus has of not being subscribed to ANY mailing lists. > > p.s.: i also still think it would be a good idea to create a > xfs-users list to separate the technical stuff from things > like "the XFS kernel does not like USB" or similar I sort of agree with this, we just have not had time to talk about or do anything about it. Steve > > -- > thomas graichen ... perfection is reached, not > when there is no longer anything to add, but when there is no > longer anything to take away. --- antoine de saint-exupery From owner-linux-xfs@oss.sgi.com Fri Jun 22 07:03:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5ME35t03979 for linux-xfs-outgoing; Fri, 22 Jun 2001 07:03:05 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5ME34V03976 for ; Fri, 22 Jun 2001 07:03:04 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA07489 for ; Fri, 22 Jun 2001 07:03:03 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2163578; Fri, 22 Jun 2001 09:01:03 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA86589; Fri, 22 Jun 2001 09:00:56 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5ME4Lf28531; Fri, 22 Jun 2001 09:04:21 -0500 Message-Id: <200106221404.f5ME4Lf28531@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Adam Cioccarelli cc: linux-xfs@oss.sgi.com Subject: Re: xfs-progs and gcc-3.0 In-Reply-To: Message from Adam Cioccarelli of "Fri, 22 Jun 2001 15:21:03 +0200." Date: Fri, 22 Jun 2001 09:04:21 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi, > > I'm not sure if anyone is interested as I am sure there are bigger fish to > fry at the moment, but the compilation of the xfs-progs fails when I try > and use gcc-3.0 to compile them. > > By the way the kernel compiles and runs (24 hours uptime as I write...) > I too have a system up and running with a 3.0 kernel. I thought I had one chunk of code which was failing under 3.0 which did not fail before, but it appears to have gone intermittent on me. Also remember that in the past we have been bitten by different back ends to gcc having different problems. Adam, which platform are you compiling for? Steve From owner-linux-xfs@oss.sgi.com Fri Jun 22 07:03:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5ME3fv04073 for linux-xfs-outgoing; Fri, 22 Jun 2001 07:03:41 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5ME3eV04070 for ; Fri, 22 Jun 2001 07:03:40 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA08209 for ; Fri, 22 Jun 2001 07:03:37 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2227513; Fri, 22 Jun 2001 09:02:20 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA65183; Fri, 22 Jun 2001 09:02:20 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5ME5ja29035; Fri, 22 Jun 2001 09:05:45 -0500 Message-Id: <200106221405.f5ME5ja29035@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: werner maes cc: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: XFS installation on Compaq ML 350 In-Reply-To: Message from werner maes of "Fri, 22 Jun 2001 15:52:24 +0200." <3.0.6.32.20010622155224.00808420@mail.cc.kuleuven.ac.be> Date: Fri, 22 Jun 2001 09:05:45 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > >>If you want, I can provide a more detailed description of the error > messages. > > When booting up for the first time: > > * several messages: /var/run/wtmp, /var/lock/subsys/kudzu, network, > ipchains: No such file or directory > > * mounting local filesystems: device does not exist ==> several partitions > are not mounted. > > * eth0: failed > > * Starting system logger ==> takes a LOT of time. > > Al these problems do NOT occur if I simply install RH 7.1. It only happens > if I use XFS 1.0 > > Werner Maes > KULeuven > OK, on the initial release we still had a default in xfs which caused the rpm database files to get a lot larger than they normally do, this caused a higher load on the root filesystem which in turn caused it to fill the partition containing /var in some circumstances. If /var was also / then you end up with lots of missing files. You can tell if this is happening from the install log which gets created. Try making /var it's own partition, or making your root partition larger. You should then probably upgrade to the 1.0.1 kernel rpm (the 2.4.2 version seems to behave better at the moment), although this is in testing still. The other thing is that devfs is turned on in the 1.0 release, we are leaning towards compiling it in, but defaulting to not mounting it at startup in the final version of the 1.0.1 rpms. In the meantime, the lilo option : append="devfs=nomount" Steve From owner-linux-xfs@oss.sgi.com Fri Jun 22 07:04:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5ME4dh04167 for linux-xfs-outgoing; Fri, 22 Jun 2001 07:04:39 -0700 Received: from michael.dnvr.vpmonline.com (ns1.vpmonline.com [63.225.117.33] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5ME4cV04164 for ; Fri, 22 Jun 2001 07:04:38 -0700 Received: from vpmonline.com (IDENT:michael@localhost [127.0.0.1]) by michael.dnvr.vpmonline.com (8.11.2/8.11.0) with ESMTP id f5ME4Rf18879; Fri, 22 Jun 2001 08:04:27 -0600 Message-ID: <3B33506B.7090108@vpmonline.com> Date: Fri, 22 Jun 2001 08:04:27 -0600 From: "Michael G. Martin" User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; rv:0.9.1+) Gecko/20010606 X-Accept-Language: en-us MIME-Version: 1.0 To: werner maes CC: linux-xfs@oss.sgi.com Subject: Re: XFS installation on Compaq ML 350 References: <3.0.6.32.20010622112214.007b7db0@mail.cc.kuleuven.ac.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I recently put xfs redhat 7.1 on compaq dl360s and a dl380. The main changes I had to do were: 1) Use the compaq server setup disk and tell it I was using Linux for the OS. If this was not done, my network cards did not work. 2) Install Linux with xfs cd for redhat 7.1. The dl360s used their default raid controller (cpqarray driver). The 380 uses a smart array 5300 raid controller (cciss driver). 3) XFS enables devfs by default. When enabled, the raid controllers were not found and mounted correctly by devfs. I disabled devfs because I did not have the time to even start looking into it. Use the devfs=nomount to disable it--you have to boot with it disabled before you can add it to your lilo.conf. So when booting, hit ctrl-x and type in linux devfs=nomount at the lilo prompt. Then edit you lilo.conf and add to the append="... devfs=nomount" (the xfs cdrom has this info in the readme or install file) 4) From there, it should mount your devices correctly. I did have problems with the cciss driver when trying to load a postgres database--crashes of the database. I found that the Alan Cox patches fixed problems with this driver in 2.4.5. However, I could not easily apply the AC patches and the XFS patches without problems, so after trying multiple kernels and xfs versions, I removed xfs from the dl380 and kept a straight 7.1 install. At least my database built. I did just notice the Folk project which may have helped get all the patches into 1 kernel I needed. But, I'll probably wait a bit before I go down that road again. Seems like lots of changes are happening in the 2.4.x kernel and drivers right now (read something usually breaks). --Michael werner maes wrote: > Hello, > >I tried to install RH 7.1 & XFS on a Compaq ML 350 server using the ISO image >provided by SGI. The server has two SCSI-disks configured in RAID-1. >The installation seemed to worked fine, but after the reboot several >problems occured. >Several files were not found (e.g. chgrp, locate, network information,...). >It was not >possible to install programs using rpm. > >My question: >Is this a known problem? Or are the drivers for the Compaq RAID card not >included (Compaq >RAID LC2 controller)? > >If you want, I can provide a more detailed description of the error messages. > >Werner Maes >KULeuven > > From owner-linux-xfs@oss.sgi.com Fri Jun 22 07:18:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MEIGb04528 for linux-xfs-outgoing; Fri, 22 Jun 2001 07:18:16 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MEIEV04525 for ; Fri, 22 Jun 2001 07:18:14 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id QAA18421 for ; Fri, 22 Jun 2001 16:18:13 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id QAA14426 for linux-xfs@oss.sgi.com; Fri, 22 Jun 2001 16:18:11 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id A54CA57306 for ; Fri, 22 Jun 2001 16:27:41 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id CE29A25835 for ; Fri, 22 Jun 2001 16:35:58 +0200 (CEST) Message-ID: <3B33548B.3AAA41D@ch.sauter-bc.com> Date: Fri, 22 Jun 2001 16:22:03 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: linux-xfs Subject: Re: XFS installation on Compaq ML 350 References: <200106221405.f5ME5ja29035@jen.americas.sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord schrieb: > > > >>If you want, I can provide a more detailed description of the error > > messages. > > > > When booting up for the first time: > > > > * several messages: /var/run/wtmp, /var/lock/subsys/kudzu, network, > > ipchains: No such file or directory > > > > * mounting local filesystems: device does not exist ==> several partitions > > are not mounted. > > > > * eth0: failed > > > > * Starting system logger ==> takes a LOT of time. > > > > Al these problems do NOT occur if I simply install RH 7.1. It only happens > > if I use XFS 1.0 > > > > Werner Maes > > KULeuven > > > > OK, on the initial release we still had a default in xfs which caused > the rpm database files to get a lot larger than they normally do, this > caused a higher load on the root filesystem which in turn caused it to > fill the partition containing /var in some circumstances. If /var > was also / then you end up with lots of missing files. You can > tell if this is happening from the install log which gets created. > > Try making /var it's own partition, or making your root partition > larger. You should then probably upgrade to the 1.0.1 kernel rpm (the 2.4.2 > version seems to behave better at the moment), although this is in > testing still. > > The other thing is that devfs is turned on in the 1.0 release, we are > leaning towards compiling it in, but defaulting to not mounting it > at startup in the final version of the 1.0.1 rpms. In the meantime, > the lilo option : > > append="devfs=nomount" > > Steve I was having similar problems when installing on a new system. Some programs just dumped core, after reboot ather progs dumped, other where missing and so on. rpm -Va told me that lots of files had wrong MD5 sums. I posted to this list but there was just one reply about bad hardware. Well, it was NOT cheap hardware, DELL Precision WS with i820 Camino Chipset, Promise controller... Well it could be bad hardware anyway but I felt unsure because I have never had a system wich was unreliable and I tried really everything and changed every peace of hardware. /var was big enough. If you are able to run the system and rpm -Va works, try to run rpm -Va > file.[#] several times and compare them. Would be interesting to know what comes out. Simon From owner-linux-xfs@oss.sgi.com Fri Jun 22 07:18:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MEIra04621 for linux-xfs-outgoing; Fri, 22 Jun 2001 07:18:53 -0700 Received: from msg.ecetra.com (dollar.ecetra.com [193.164.224.209]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MEIpV04618 for ; Fri, 22 Jun 2001 07:18:52 -0700 Received: from vie-ac.office.ecetra.com (vie-ac.office.ecetra.com [10.251.148.147] (may be forged)) by msg.ecetra.com (8.9.3/8.9.3) with ESMTP id QAA07697; Fri, 22 Jun 2001 16:18:45 +0200 Received: from localhost (localhost [127.0.0.1]) by vie-ac.office.ecetra.com (8.11.4/8.11.3) with ESMTP id f5MEIjU15331; Fri, 22 Jun 2001 16:18:45 +0200 Date: Fri, 22 Jun 2001 16:18:45 +0200 (CEST) From: Adam Cioccarelli To: Steve Lord cc: Subject: Re: xfs-progs and gcc-3.0 In-Reply-To: <200106221404.f5ME4Lf28531@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve, it's a Slackware install on i386 (PIII) with everything from slackware-current so glibc 2.2.3, ld 2.11.90.0.15, GNU Make version 3.79.1, etc so it's pretty up to date. Although it is just a desktop PC it is my everyday workstation and it has never had a problem with XFS.. ------------------------------------------------------------------------------- Adam Cioccarelli (B.E Mechanical) Adam.Cioccarelli@ecetra.com Database Administrator Phone: +43 1 536 89 7725 Fax: +43 1 536 89 7719 ecetra Central European e-Finance AG Mobile:+43 664 181 4195 ------------------------------------------------------------------------------- On Fri, 22 Jun 2001, Steve Lord wrote: > > Hi, > > > > I'm not sure if anyone is interested as I am sure there are bigger fish to > > fry at the moment, but the compilation of the xfs-progs fails when I try > > and use gcc-3.0 to compile them. > > > > By the way the kernel compiles and runs (24 hours uptime as I write...) > > > > I too have a system up and running with a 3.0 kernel. I thought I had one > chunk of code which was failing under 3.0 which did not fail before, but > it appears to have gone intermittent on me. Also remember that in the > past we have been bitten by different back ends to gcc having different > problems. Adam, which platform are you compiling for? > > Steve > From owner-linux-xfs@oss.sgi.com Fri Jun 22 07:25:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MEPxF04833 for linux-xfs-outgoing; Fri, 22 Jun 2001 07:25:59 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MEPvV04830 for ; Fri, 22 Jun 2001 07:25:57 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA08885 for ; Fri, 22 Jun 2001 07:23:03 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2231551; Fri, 22 Jun 2001 09:24:40 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA49153; Fri, 22 Jun 2001 09:24:39 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5MES5B32337; Fri, 22 Jun 2001 09:28:05 -0500 Message-Id: <200106221428.f5MES5B32337@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andi Kleen cc: linux-xfs@oss.sgi.com Subject: Re: [PATCH] Add nouuid option In-Reply-To: Message from Andi Kleen of "Fri, 22 Jun 2001 10:34:53 +0200." <20010622103453.A29958@gruyere.muc.suse.de> Date: Fri, 22 Jun 2001 09:28:05 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Following patch adds a nouuid mount option to XFS, which makes it not check > if the file system uuid is unique on the system. This is useful to mount > LVM snapshot volumes without having to play games with xfsdb. > > -Andi > Andi, Seems like a reasonable idea, but I would extend it in a couple of ways: 1. only allow the nouuid in combination with the ro flag - otherwise you could get two mounts of the same physical media at the same time, you will trash the filesystem very quickly. Enforcing this combination will at least stop people from writing from multiple places, it will still have the potential for a read only and a read/write copy of the same filesystem, the readonly copy will get out of date metadata in its buffers, and possibly crash, so this is definitely a use only if you really know what you are doing feature. 2. You also need to skip the call to xfs_uuid_unmount() in xfs_unmountfs(), this will be happily removing the uuid for the original filesystem even while it is still mounted. This would let you get into the same case as above and trash the filesystem later on. This whole thing is based on the theory that recovery does not have to run on the snapshot, which it should not if I got the snapshot code right. Steve From owner-linux-xfs@oss.sgi.com Fri Jun 22 07:41:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MEfTe05236 for linux-xfs-outgoing; Fri, 22 Jun 2001 07:41:29 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MEfRV05233 for ; Fri, 22 Jun 2001 07:41:27 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 02C3B1E858; Fri, 22 Jun 2001 16:41:22 +0200 (MEST) Date: Fri, 22 Jun 2001 16:41:15 +0200 From: Andi Kleen To: Steve Lord Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: [PATCH] Add nouuid option Message-ID: <20010622164115.A5484@gruyere.muc.suse.de> References: <200106221428.f5MES5B32337@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106221428.f5MES5B32337@jen.americas.sgi.com>; from lord@sgi.com on Fri, Jun 22, 2001 at 09:28:05AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Jun 22, 2001 at 09:28:05AM -0500, Steve Lord wrote: > 1. only allow the nouuid in combination with the ro flag - otherwise you > could get two mounts of the same physical media at the same time, you > will trash the filesystem very quickly. Enforcing this combination will > at least stop people from writing from multiple places, it will still > have the potential for a read only and a read/write copy of the same > filesystem, the readonly copy will get out of date metadata in its > buffers, and possibly crash, so this is definitely a use only if you > really know what you are doing feature. That would defeat the purpose I've done it for completely -- mounting an writable snapshot volume and letting it replay the log there. When the user specifies nouuid he should know what he is doing. > 2. You also need to skip the call to xfs_uuid_unmount() in xfs_unmountfs(), > this will be happily removing the uuid for the original filesystem even > while it is still mounted. This would let you get into the same case as > above and trash the filesystem later on. True, will add that. Handling it for the remount case will be slightly tricky though. > > This whole thing is based on the theory that recovery does not have to > run on the snapshot, which it should not if I got the snapshot code right. It is assuming that you can run recovery and that the user ensured that the snapshot device has some mechanism to deal with that; like some block level COW handler. The default without this option is still safe of course. -Andi From owner-linux-xfs@oss.sgi.com Fri Jun 22 07:43:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MEhYO05347 for linux-xfs-outgoing; Fri, 22 Jun 2001 07:43:34 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MEhXV05344 for ; Fri, 22 Jun 2001 07:43:33 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA00989 for ; Fri, 22 Jun 2001 07:40:39 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (gibble.americas.sgi.com [128.162.195.80]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA39071; Fri, 22 Jun 2001 07:42:59 -0700 (PDT) Message-ID: <3B3358E4.C19F489C@sgi.com> Date: Fri, 22 Jun 2001 09:40:36 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Simon Matter CC: Steve Lord , linux-xfs Subject: Re: LVM and XFS in 1.0.1-PR1 and usability in production References: <200106211608.f5LG8m713919@jen.americas.sgi.com> <3B32F76A.16229BA5@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter wrote: > After booting > the PR1 kernel I found out that LVM support has gone. Whoops, that was not intentional, I'll take a look - probably just an error. That's why I put out test RPMs. :) Thanks, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Jun 22 07:44:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MEixv05513 for linux-xfs-outgoing; Fri, 22 Jun 2001 07:44:59 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MEiwV05510 for ; Fri, 22 Jun 2001 07:44:58 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA02547 for ; Fri, 22 Jun 2001 07:42:04 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (gibble.americas.sgi.com [128.162.195.80]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA94559; Fri, 22 Jun 2001 07:44:25 -0700 (PDT) Message-ID: <3B33593C.100FEEA@sgi.com> Date: Fri, 22 Jun 2001 09:42:04 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Simon Matter CC: linux-xfs Subject: Re: LVM and XFS in 1.0.1-PR1 and usability in production References: <200106211608.f5LG8m713919@jen.americas.sgi.com> <3B32F76A.16229BA5@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter wrote: > If I'm doing it what version should I take, 1.0 or 1.0.1-PR1. Is it a > big difference regarding stability? Oh, and I would probably vote for 1.0.1-PR1, but even better, wait just a bit for the official 1.0.1 release, as you found out, there may be a couple snags in 1.0.1-PR1. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Jun 22 07:47:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MElub05692 for linux-xfs-outgoing; Fri, 22 Jun 2001 07:47:56 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MEltV05689 for ; Fri, 22 Jun 2001 07:47:55 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA02022 for ; Fri, 22 Jun 2001 07:45:01 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (gibble.americas.sgi.com [128.162.195.80]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA04736; Fri, 22 Jun 2001 07:47:22 -0700 (PDT) Message-ID: <3B3359ED.470CC922@sgi.com> Date: Fri, 22 Jun 2001 09:45:01 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: werner maes CC: linux-xfs@oss.sgi.com Subject: Re: XFS installation on Compaq ML 350 References: <3.0.6.32.20010622112214.007b7db0@mail.cc.kuleuven.ac.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk werner maes wrote: > I tried to install RH 7.1 & XFS on a Compaq ML 350 server using the ISO image > provided by SGI. The server has two SCSI-disks configured in RAID-1. > The installation seemed to worked fine, but after the reboot several > problems occured. This probably is a known problem with the 1.0 kernels, if you can wait just a bit, 1.0.1 will be out, which should fix this. Feel free to send detailed error messages to be sure, though. Thanks, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Jun 22 07:52:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MEqJU05949 for linux-xfs-outgoing; Fri, 22 Jun 2001 07:52:19 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MEqHV05936 for ; Fri, 22 Jun 2001 07:52:18 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA35348 for ; Fri, 22 Jun 2001 16:52:15 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2233119; Fri, 22 Jun 2001 09:50:58 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA15567; Fri, 22 Jun 2001 09:50:58 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5MEsNR32437; Fri, 22 Jun 2001 09:54:23 -0500 Message-Id: <200106221454.f5MEsNR32437@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andi Kleen cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: [PATCH] Add nouuid option In-Reply-To: Message from Andi Kleen of "Fri, 22 Jun 2001 16:41:15 +0200." <20010622164115.A5484@gruyere.muc.suse.de> Date: Fri, 22 Jun 2001 09:54:22 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Fri, Jun 22, 2001 at 09:28:05AM -0500, Steve Lord wrote: > > 1. only allow the nouuid in combination with the ro flag - otherwise you > > could get two mounts of the same physical media at the same time, you > > will trash the filesystem very quickly. Enforcing this combination will > > at least stop people from writing from multiple places, it will still > > have the potential for a read only and a read/write copy of the same > > filesystem, the readonly copy will get out of date metadata in its > > buffers, and possibly crash, so this is definitely a use only if you > > really know what you are doing feature. > > That would defeat the purpose I've done it for completely -- mounting an > writable snapshot volume and letting it replay the log there. When the user > specifies nouuid he should know what he is doing. OK, I just get nervous, we have had so many people work out ways to mount the same filesystem from two places and walk all over it. > > > 2. You also need to skip the call to xfs_uuid_unmount() in xfs_unmountfs(), > > this will be happily removing the uuid for the original filesystem even > > while it is still mounted. This would let you get into the same case as > > above and trash the filesystem later on. > > True, will add that. Handling it for the remount case will be slightly > tricky though. > > > > > This whole thing is based on the theory that recovery does not have to > > run on the snapshot, which it should not if I got the snapshot code right. > > It is assuming that you can run recovery and that the user > ensured that the snapshot device has some mechanism to deal with that; like > some block level COW handler. The default without this option is still > safe of course. Is recovery running for you? If you use the freeze/thaw code I put into XFS and the LVM patch to call them from the snapshot creation path then in theory it should not be running. > > -Andi Steve From owner-linux-xfs@oss.sgi.com Fri Jun 22 07:53:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MEriR06076 for linux-xfs-outgoing; Fri, 22 Jun 2001 07:53:44 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MErfV06073 for ; Fri, 22 Jun 2001 07:53:41 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA36100 for ; Fri, 22 Jun 2001 16:53:39 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2230053; Fri, 22 Jun 2001 09:52:21 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA91086; Fri, 22 Jun 2001 09:52:21 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5MEtkB32455; Fri, 22 Jun 2001 09:55:46 -0500 Message-Id: <200106221455.f5MEtkB32455@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Simon Matter cc: linux-xfs Subject: Re: XFS installation on Compaq ML 350 In-Reply-To: Message from Simon Matter of "Fri, 22 Jun 2001 16:22:03 +0200." <3B33548B.3AAA41D@ch.sauter-bc.com> Date: Fri, 22 Jun 2001 09:55:46 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > I was having similar problems when installing on a new system. Some > programs just dumped core, after reboot ather progs dumped, other where > missing and so on. rpm -Va told me that lots of files had wrong MD5 > sums. I posted to this list but there was just one reply about bad > hardware. Well, it was NOT cheap hardware, DELL Precision WS with i820 > Camino Chipset, Promise controller... Well it could be bad hardware > anyway but I felt unsure because I have never had a system wich was > unreliable and I tried really everything and changed every peace of > hardware. /var was big enough. > > If you are able to run the system and rpm -Va works, try to run rpm -Va > > file.[#] several times and compare them. Would be interesting to know what > comes out. > > Simon > Yes, I vaguely remember this, I apologise for letting you fall through the cracks, it is difficult to keep track of everything which is going on. Have you tried running with ext2 on this hardware, but with an xfs kernel and trying some tests on an xfs partition? It would be nice to establish what is really going on here. Steve From owner-linux-xfs@oss.sgi.com Fri Jun 22 08:45:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MFjIg07355 for linux-xfs-outgoing; Fri, 22 Jun 2001 08:45:18 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MFjHV07352 for ; Fri, 22 Jun 2001 08:45:17 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id RAA02230; Fri, 22 Jun 2001 17:45:11 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id RAA20602; Fri, 22 Jun 2001 17:45:11 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 6031357306; Fri, 22 Jun 2001 17:54:48 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 73BC825835; Fri, 22 Jun 2001 18:03:05 +0200 (CEST) Message-ID: <3B3368F5.FE4E298D@ch.sauter-bc.com> Date: Fri, 22 Jun 2001 17:49:09 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Steve Lord Cc: linux-xfs Subject: Re: XFS installation on Compaq ML 350 References: <200106221455.f5MEtkB32455@jen.americas.sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord schrieb: > > > > > I was having similar problems when installing on a new system. Some > > programs just dumped core, after reboot ather progs dumped, other where > > missing and so on. rpm -Va told me that lots of files had wrong MD5 > > sums. I posted to this list but there was just one reply about bad > > hardware. Well, it was NOT cheap hardware, DELL Precision WS with i820 > > Camino Chipset, Promise controller... Well it could be bad hardware > > anyway but I felt unsure because I have never had a system wich was > > unreliable and I tried really everything and changed every peace of > > hardware. /var was big enough. > > > > If you are able to run the system and rpm -Va works, try to run rpm -Va > > > file.[#] several times and compare them. Would be interesting to know what > > comes out. > > > > Simon > > > > Yes, I vaguely remember this, I apologise for letting you fall through the > cracks, it is difficult to keep track of everything which is going on. > > Have you tried running with ext2 on this hardware, but with an xfs kernel > and trying some tests on an xfs partition? It would be nice to establish > what is really going on here. > > Steve I didn't try ext2. All filesystems were on top of SoftRAID1 or SoftRAID5. / was on md1(hda5/hdb5). Usually I do RAID over two channels (md1(hda5/hdc5)) but for testing I didn't because of lack of UDMA cables. I then found out that randomly different files were corrupt. For example vi dumped core, after reboot vi went fine but rpm dumped core and so on. Since UDMA uses CRC I thought it should be safe and I was using 2 different UDMA controllers with the same effect. By now I'm sure it has something to do with having two disks on one channel (corrupt DMA transfers, errors in i820 chipset) because I made a new install on just one disk and there was not one problem again. Unfortunately I don't have the machines anymore to make more test. If anybody is using i820 based motherboards and has two UDMA disks on the same IDE channel, please try a SoftRAID1 install of RH-7.1-XFS and test around with it. Simon From owner-linux-xfs@oss.sgi.com Fri Jun 22 09:42:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MGgwX09047 for linux-xfs-outgoing; Fri, 22 Jun 2001 09:42:58 -0700 Received: from biobio.vexcel.com (biobio.vexcel.com [192.92.90.108]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MGgvV09044 for ; Fri, 22 Jun 2001 09:42:57 -0700 Received: from [192.168.1.17] (router.vexcel.com [192.92.90.254]) by biobio.vexcel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA25701; Fri, 22 Jun 2001 10:42:46 -0600 (MDT) Mime-Version: 1.0 X-Sender: brissing@mail.vexcel.com (Unverified) Message-Id: In-Reply-To: <200106212306.f5LN61327351@jen.americas.sgi.com> References: <200106212306.f5LN61327351@jen.americas.sgi.com> Date: Fri, 22 Jun 2001 10:42:41 -0600 To: Steve Lord From: Dean Brissinger Subject: Re: NFS bugs w/ SGI's Cc: linux-xfs@oss.sgi.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Using kgcc enabled me to compile, but it didn't work then either (unable to find a console device). This was because of the way I configured the kernel. Is the NFS getdents64 patch going to be included in the 1.0.1 release? >This looks more like general kernel compilation problems than something >about the patch itself. Which compiler and tools are you using? > >Steve > >> Hi! >> >> I'm encountering something that keeps me from using Linux in >> my environment. There is a bug in the linux kernel 2.2.18 and >> 2.4.present kernels that will cause some files not to show up over >> NFS mounts from Irix systems. I found my problem is discussed in >> detail at: >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=30944 >> >> and there is a patch for my problem: >> >> http://www.fys.uio.no/~trondmy/src/2.4.2/ >> >> >> BUT! I cannot get the patch to compile with the XFS kernel with >> devfs. I thought it would take me an hour or two but have now spent >> all day on it. I get though the compile with a vanilla config file >> (all defaults) but when linking get the following message: >> >> >/tmp/cc9HoxYq.s: Assembler messages: >> >/tmp/cc9HoxYq.s:1056: Error: suffix or operands invalid for `shl' >> >/tmp/cc9HoxYq.s:1112: Error: suffix or operands invalid for `shl' >> >make[1]: *** [entry.o] Error 1 >> >make[1]: Leaving directory `src/linux-2.4-xfs-r1.0/linux/arch/i386/kernel' >> >make: *** [_dir_arch/i386/kernel] Error 2 >> >> >> A quick search on google resulted in a couple of anonymous posts that >> claim to have this working. Has anyone got this patch working with >> the XFS kernel? >> >> I'd love either for a binary RPM (RH 7.1) of the patched >> kernel or a working source tree. Can ya help? >> >> -- >> . . . . . . . . ooo . . . . ooo . . . . . . . . . >> . . >> . Dean Brissinger - Systems Administrator . >> . Direct: 303-583-0278 Main: 303-444-0094 . >> . Fax: 303-583-0246 http://www.vexcel.com/ . >> . . >> . . . . . . . oOOo . . A . . oOOo . . . . . . . . >> 0 0 >> '```` -- . . . . . . . . ooo . . . . ooo . . . . . . . . . . . . Dean Brissinger - Systems Administrator . . Direct: 303-583-0278 Main: 303-444-0094 . . Fax: 303-583-0246 http://www.vexcel.com/ . . . . . . . . . . oOOo . . A . . oOOo . . . . . . . . 0 0 '```` From owner-linux-xfs@oss.sgi.com Fri Jun 22 10:11:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MHBku09727 for linux-xfs-outgoing; Fri, 22 Jun 2001 10:11:46 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MHBiV09721 for ; Fri, 22 Jun 2001 10:11:44 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip74.idcomm.com [209.60.72.201] (may be forged)) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5MHCPl03613 for ; Fri, 22 Jun 2001 11:12:25 -0600 Message-ID: <3B337CAD.58813A61@idcomm.com> Date: Fri, 22 Jun 2001 11:13:17 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: xfs kernel src References: <22036.993185621@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > > On Thu, 21 Jun 2001 22:38:20 -0600, > "D. Stimits" wrote: > >One snag you might be running into is that RH 7.1 makes directories > >/usr/include/asm, /usr/include/linux, and /usr/include/scsi hard copies > >of their kernel. You probably want to cd to /usr/include, and rename > >(mv) asm, linux, and scsi, to some backup. Then also expand on their > >symbolic links at /usr/src/. > > Please do not do that. Linus and other kernel maintainers fought a > long and hard battle to stop distributions making symlinks from > /usr/include to /usr/src/linux, or to any other active kernel. > > The files in /usr/include are for user space applications that need a > stable set of includes. These must not change depending on which > kernel you have installed this week. Conceptually, in most practical ways, I understand this. But in the case of device drivers or hardware that might be compiled, if it does something like #include , and something.h has changed in the kernel, it could cause other problems than just compile incompatibilities. For example, modules that are compiled separately from the kernel (because they are not patched in to the kernel or otherwise not part of the kernel source tree, such as cvs releases of many modules). If all of the writers of kernel-dependent code (distributed separately from a kernel) use a #include with an absolute path, e.g.: #include "/usr/src/linux/include/something.h" ...then it would always work as advertised. It sounds like maybe it is a good idea to keep the headers constant, but it also seems that it will cause older software that is hardware dependent to break if it wasn't written with this in mind. I have not grepped the NVidia code, but I wonder if they have used the format: #include #include In any case, I hadn't heard about this till now, so I guess it is time to change then. D. Stimits, stimits@idcomm.com > > User space code cannot assume that it has current kernel headers, > instead they get headers that match glibc and other tools. User space > code should not read kernel headers directly, instead the package > should contain a copy of the required definitions. It is almost always > a bad idea for user space applications to depend on kernel headers. > Even code like modutils that hooks right into the kernel has its own > copy of the required kernel headers, it is the only way to ensure that > it ca be compiled on any kernel. > > Kernel based code must be compiled against kernel headers, not against > /usr/include. The kernel makefiles try to avoid reading from anything > outside the kernel. From owner-linux-xfs@oss.sgi.com Fri Jun 22 10:16:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MHGN309886 for linux-xfs-outgoing; Fri, 22 Jun 2001 10:16:23 -0700 Received: from mail.levigo.de (mail.levigo.de [193.197.156.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MHGLV09883 for ; Fri, 22 Jun 2001 10:16:22 -0700 Received: from levigo.de (zoidberg.cogito.de [193.197.156.88]) by mail.levigo.de (Postfix) with ESMTP id 4620E7E73 for ; Fri, 22 Jun 2001 19:14:07 +0200 (CEST) Message-ID: <3B337D64.9802AC76@levigo.de> Date: Fri, 22 Jun 2001 19:16:20 +0200 From: Klaus Rein Organization: levigo systems gmbh X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre2-xfs i686) X-Accept-Language: de, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs_force_shutdown Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, what are possible reasons for the shutdown of a xfs filesystem? Jun 21 14:28:48 probiernix4 kernel: xfs_force_shutdown(md(9,0),0x1) called from line 4069 of file xfs_bmap.c. Return address = 0xc0181890 Jun 21 14:28:48 probiernix4 kernel: I/O Error Detected. Shutting down filesystem: md(9,0) Jun 21 14:28:48 probiernix4 kernel: Please umount the filesystem, and rectify the problem(s) The system runs xfs (cvs version from jun, 11th), the filesystem is on two scsi-drives (raid1) exported via nfs. At the time the error occured two clients had the fs mounted, one creating and deleting directories and files randomly, the other one copying them to /dev/null. After that error message the filesystem was still mounted and df showed some percents of filesystem usage, but the mount point was empty. After unmounting it and running xfs_repair we found some files and dirs in lost+found. Klaus. From owner-linux-xfs@oss.sgi.com Fri Jun 22 10:56:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MHutm10734 for linux-xfs-outgoing; Fri, 22 Jun 2001 10:56:55 -0700 Received: from wrath.cs.utah.edu (wrath.cs.utah.edu [155.99.198.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MHurV10731 for ; Fri, 22 Jun 2001 10:56:54 -0700 Received: from famine.cs.utah.edu (famine.cs.utah.edu [155.99.198.114]) by wrath.cs.utah.edu (8.11.1/8.11.1) with ESMTP id f5MHuhT29776; Fri, 22 Jun 2001 11:56:43 -0600 (MDT) Date: Fri, 22 Jun 2001 11:56:43 -0600 (MDT) From: Jesse Hall X-Sender: jehall@famine.cs.utah.edu Reply-To: Jesse Hall To: "D. Stimits" cc: linux-xfs@oss.sgi.com Subject: Re: xfs kernel src In-Reply-To: <3B337CAD.58813A61@idcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The NVidia Makefiles are designed to handle this correctly. Try $ make SYSINCLUDE=/usr/src/linux-2.4/include (adjust path as appropriate). This will pull all kernel headers (and versioned symbols if enabled) from the specified directory. This is documented in their README. I use both 2.2 and 2.4 kernels, and this is far easier than switching symlinks in /usr, or even switching a /usr/src/linux symlink. Jesse On Fri, 22 Jun 2001, D. Stimits wrote: > Keith Owens wrote: > > > > On Thu, 21 Jun 2001 22:38:20 -0600, > > "D. Stimits" wrote: > > >One snag you might be running into is that RH 7.1 makes directories > > >/usr/include/asm, /usr/include/linux, and /usr/include/scsi hard copies > > >of their kernel. You probably want to cd to /usr/include, and rename > > >(mv) asm, linux, and scsi, to some backup. Then also expand on their > > >symbolic links at /usr/src/. > > > > Please do not do that. Linus and other kernel maintainers fought a > > long and hard battle to stop distributions making symlinks from > > /usr/include to /usr/src/linux, or to any other active kernel. > > > > The files in /usr/include are for user space applications that need a > > stable set of includes. These must not change depending on which > > kernel you have installed this week. > > Conceptually, in most practical ways, I understand this. But in the case > of device drivers or hardware that might be compiled, if it does > something like #include , and something.h has changed > in the kernel, it could cause other problems than just compile > incompatibilities. For example, modules that are compiled separately > from the kernel (because they are not patched in to the kernel or > otherwise not part of the kernel source tree, such as cvs releases of > many modules). If all of the writers of kernel-dependent code > (distributed separately from a kernel) use a #include with an absolute > path, e.g.: > #include "/usr/src/linux/include/something.h" > > ...then it would always work as advertised. It sounds like maybe it is a > good idea to keep the headers constant, but it also seems that it will > cause older software that is hardware dependent to break if it wasn't > written with this in mind. I have not grepped the NVidia code, but I > wonder if they have used the format: > #include > #include > > In any case, I hadn't heard about this till now, so I guess it is time > to change then. > > D. Stimits, stimits@idcomm.com > > > > > User space code cannot assume that it has current kernel headers, > > instead they get headers that match glibc and other tools. User space > > code should not read kernel headers directly, instead the package > > should contain a copy of the required definitions. It is almost always > > a bad idea for user space applications to depend on kernel headers. > > Even code like modutils that hooks right into the kernel has its own > > copy of the required kernel headers, it is the only way to ensure that > > it ca be compiled on any kernel. > > > > Kernel based code must be compiled against kernel headers, not against > > /usr/include. The kernel makefiles try to avoid reading from anything > > outside the kernel. > From owner-linux-xfs@oss.sgi.com Fri Jun 22 11:02:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MI21411006 for linux-xfs-outgoing; Fri, 22 Jun 2001 11:02:01 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MI1xV10994 for ; Fri, 22 Jun 2001 11:01:59 -0700 Received: (qmail 16914 invoked from network); 22 Jun 2001 18:01:56 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 22 Jun 2001 18:01:55 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: stimits@idcomm.com cc: linux-xfs@oss.sgi.com Subject: Re: xfs kernel src In-reply-to: Your message of "Fri, 22 Jun 2001 11:13:17 CST." <3B337CAD.58813A61@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Jun 2001 04:01:55 +1000 Message-ID: <8899.993232915@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 22 Jun 2001 11:13:17 -0600, "D. Stimits" wrote: >of device drivers or hardware that might be compiled, if it does >something like #include , and something.h has changed >in the kernel, it could cause other problems than just compile >incompatibilities. For example, modules that are compiled separately >from the kernel (because they are not patched in to the kernel or >otherwise not part of the kernel source tree, such as cvs releases of >many modules). Seperate compilation of modules, in particular for binary only modules, is known to be riddled with risks. Module symbol versions attempt to detect mismatches between the kernel and the module by creating a hash over the API of each exported symbol, if the hash does not match then the module does not load. Alas module symbol versions has several fundamental design flaws. The version data is abused by third party binary modules in such a way as to defeat the check. Modversions causes so many compile and build problems that most people disable modversions on their own kernels. I certainly do and I am the kernel build and modutils maintainer! Kernel 2.5 and modutils 2.5 will have a completely new method for checking the ABI between kernels and modules. Or it will once I find time to do the coding. From owner-linux-xfs@oss.sgi.com Fri Jun 22 11:18:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MIIAV11402 for linux-xfs-outgoing; Fri, 22 Jun 2001 11:18:10 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MII9V11399 for ; Fri, 22 Jun 2001 11:18:09 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA02530 for ; Fri, 22 Jun 2001 11:18:03 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2235086; Fri, 22 Jun 2001 13:16:51 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA45905; Fri, 22 Jun 2001 13:16:50 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5MIKEi01932; Fri, 22 Jun 2001 13:20:14 -0500 Message-Id: <200106221820.f5MIKEi01932@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Klaus Rein cc: linux-xfs@oss.sgi.com Subject: Re: xfs_force_shutdown In-Reply-To: Message from Klaus Rein of "Fri, 22 Jun 2001 19:16:20 +0200." <3B337D64.9802AC76@levigo.de> Date: Fri, 22 Jun 2001 13:20:14 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hello, > > what are possible reasons for the shutdown of a xfs filesystem? Forced shutdown is used when an I/O error is reported by the underlying layers. If everything else is working correctly it usually means there is a hardware problem. Once this has happened you can no longer access the filesystem, which is why it looked empty, the only recourse is the one you took, unmount and run repair. The reasoning behind it is that if hardware is failing the best thing to do is to stop writing to it and ask for administrative action to clean it up. On Linux there is a chance you have been bitten by a compiler whih does not like the xfs code. I suppose with Raid 1 you may have stumbled across a case where the raid reconstruction and xfs got in each other's way. Is there any way you can tell if reconstruction was in progress? Steve From owner-linux-xfs@oss.sgi.com Fri Jun 22 11:55:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MItxd12587 for linux-xfs-outgoing; Fri, 22 Jun 2001 11:55:59 -0700 Received: from zion.rivenstone.net (dhcp065-024-121-117.columbus.rr.com [65.24.121.117]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MItvV12584 for ; Fri, 22 Jun 2001 11:55:57 -0700 Received: by zion.rivenstone.net (Postfix, from userid 500) id A845D630B2; Fri, 22 Jun 2001 10:08:52 -0400 (EDT) Date: Fri, 22 Jun 2001 10:08:52 -0400 From: Joseph Fannin To: linux-xfs@oss.sgi.com Subject: Re: Xfs Compile problem Message-ID: <20010622100852.A17303@zion.rivenstone.net> References: <20010621104429.A13589@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010621104429.A13589@wwweasel.geeksrus.net>; from alane@geeksrus.net on Thu, Jun 21, 2001 at 10:44:29AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > If it's RH gcc-2.96, then you can bugzilla it (http://bugzilla.redhat.com), > but given that 3.0 is out it probably won't get fixed in 2.96. In the past, RedHat has always released three minor versions of each major -- i.e. 5.0, 5.1, 5.2; 6.0, 6.1, 6.2. If RedHat decides to release a version 7.2 of their distribution, it *will* ship with 2.96 -- they won't break binary compatiblity within a major release series. I'm not saying XFS development effort should be directed at 2.96, but I don't think it's going to go away just yet. (Please, no beating of the 2.96-is-bad dead horse.) -- Joseph Fannin jhf@rivenstone.net "Bull in pure form is rare; there is usually contamination by data." -- William Graves Perry Jr. From owner-linux-xfs@oss.sgi.com Fri Jun 22 12:24:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MJOs014416 for linux-xfs-outgoing; Fri, 22 Jun 2001 12:24:54 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MJOqV14411 for ; Fri, 22 Jun 2001 12:24:53 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5MJOkI02885 for linux-xfs@oss.sgi.com; Fri, 22 Jun 2001 15:24:46 -0400 Date: Fri, 22 Jun 2001 15:24:46 -0400 From: Alan Eldridge To: linux-xfs@oss.sgi.com Subject: 1.0.1 PR1 stability Message-ID: <20010622152446.B2875@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've been running the linus-2.4.5 kernel out of PR1 now since the day Eric put it up for ftp and I've had great results. It's a testament to XFS as well, when you consider: 1. Had electrical probs in my apt bldg. 2. UPS had gone on battery over 150 times since Thurs night. 3. Voltage went too low to keep off battery, so I had to run w/o UPS. 4. Power cycled at least 20 times since (3) last night. Every single time: system came up, xfs_repair did, and not a file was damaged AFAIK. I've got 15 filesystems, 2 of which are 30 gig each. If I had been using ext2, well, it'd still be fscking itself. -- Alan Eldridge From owner-linux-xfs@oss.sgi.com Fri Jun 22 12:43:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MJhK715760 for linux-xfs-outgoing; Fri, 22 Jun 2001 12:43:20 -0700 Received: from relay.flashnet.it (ems.flashnet.it [194.247.160.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MJhIV15754 for ; Fri, 22 Jun 2001 12:43:19 -0700 Received: from ip063.pool-05.cyb.it (ip063.pool-05.cyb.it [195.191.4.64]) by relay.flashnet.it (8.11.3/8.11.3) with SMTP id f5MJhFs24030 for ; Fri, 22 Jun 2001 21:43:15 +0200 From: daedalus@freemail.it To: linux-xfs@oss.sgi.com Subject: Re: GCC 3.0 Date: Fri, 22 Jun 2001 21:51:59 +0200 Message-ID: <2d87jtgi85qrqfcc4k9upbg2bi8roapj1f@4ax.com> References: <01061905432702.09592@localhost.localdomain> <020d01c0f871$141afdc0$0a01a8c0@den2> <4.3.2.7.2.20010619085055.037b8a18@pop.xs4all.nl> In-Reply-To: <4.3.2.7.2.20010619085055.037b8a18@pop.xs4all.nl> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5MJhJV15756 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 19 Jun 2001 09:01:23 +0200, Seth Mos wrote: >we can continue developing software using a officially released version ;) So far I have only noticed a problem with a structure in kernel/timer.c (I have not yet tested 1.0.1-PR1 and 1.0.1-PR2 patches) gcc-3.0 doesn't like the differences between /* The current time */ volatile struct timeval xtime __attribute__ ((aligned (16))); linux/kernel/timer.c --------------^^^^^^^^^^^^^^^^^^^^^ and extern struct timeval xtime; linux/include/linux/sched.h -^ I have tried to copy the content of timer.c to sched.h and build and it did work, I mean I got a vmlinuz with no unresolved symbol, but I don't know if this is a correct solution. I have not took a look at the lkml archives, I hope I am not bothering you with already known issues. From owner-linux-xfs@oss.sgi.com Fri Jun 22 13:09:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MK9IB17352 for linux-xfs-outgoing; Fri, 22 Jun 2001 13:09:18 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MK9GV17347 for ; Fri, 22 Jun 2001 13:09:17 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA28300; Fri, 22 Jun 2001 22:09:15 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA14979; Fri, 22 Jun 2001 22:09:14 +0200 (CEST) Date: Fri, 22 Jun 2001 22:09:14 +0200 (CEST) From: Seth Mos To: Alan Eldridge cc: linux-xfs@oss.sgi.com Subject: Re: 1.0.1 PR1 stability In-Reply-To: <20010622152446.B2875@wwweasel.geeksrus.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 22 Jun 2001, Alan Eldridge wrote: > I've been running the linus-2.4.5 kernel out of PR1 now since the day Eric > put it up for ftp and I've had great results. It's a testament to XFS as > well, when you consider: > > 1. Had electrical probs in my apt bldg. > 2. UPS had gone on battery over 150 times since Thurs night. > 3. Voltage went too low to keep off battery, so I had to run w/o UPS. > 4. Power cycled at least 20 times since (3) last night. > > Every single time: system came up, xfs_repair did, and not a file was > damaged AFAIK. > > I've got 15 filesystems, 2 of which are 30 gig each. If I had been using > ext2, well, it'd still be fscking itself. Hmmm, automated jfs testing ;-) Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Jun 22 13:16:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MKG7i17892 for linux-xfs-outgoing; Fri, 22 Jun 2001 13:16:07 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MKG6V17886 for ; Fri, 22 Jun 2001 13:16:06 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15DXLR-0000zX-00; Sat, 23 Jun 2001 08:15:57 +1200 Date: Sat, 23 Jun 2001 08:15:57 +1200 (NZST) From: Juha Saarinen To: Adam Cioccarelli cc: "linux-xfs@oss.sgi.com" Subject: Re: xfs-progs and gcc-3.0 In-Reply-To: Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 22 Jun 2001, Adam Cioccarelli wrote: > Hi, > > I'm not sure if anyone is interested as I am sure there are bigger fish to > fry at the moment, but the compilation of the xfs-progs fails when I try > and use gcc-3.0 to compile them. > > By the way the kernel compiles and runs (24 hours uptime as I write...) Adam, Could you try a simple test that my machine has problems with...? Go into single mode from multiuser mode, and then back again, a few times? I usually end up with bits of /var getting corrupted (lock files, PID files e.g.) if I do it on a system that's been compiled with anything newer than 2.91. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Fri Jun 22 13:37:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MKbnB19346 for linux-xfs-outgoing; Fri, 22 Jun 2001 13:37:49 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MKblV19341 for ; Fri, 22 Jun 2001 13:37:47 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA52361 for ; Fri, 22 Jun 2001 22:37:45 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2236128 for ; Fri, 22 Jun 2001 15:36:28 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA58503 for ; Fri, 22 Jun 2001 15:36:28 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f5MKdpT02753; Fri, 22 Jun 2001 15:39:51 -0500 Message-Id: <200106222039.f5MKdpT02753@jen.americas.sgi.com> Date: Fri, 22 Jun 2001 15:39:51 -0500 Subject: TAKE - workaround for gcc 3.0 problem Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Without this xfsdump could have problems, gcc appears to get its registers in a twist, trial and error produced a working version. Date: Fri Jun 22 13:35:18 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-base The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:97548a linux/fs/xfs/linux/xfs_ioctl.c - 1.41 - workaround for problem with gcc 3.0 From owner-linux-xfs@oss.sgi.com Fri Jun 22 13:44:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MKi6919905 for linux-xfs-outgoing; Fri, 22 Jun 2001 13:44:06 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MKi5V19902 for ; Fri, 22 Jun 2001 13:44:05 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA02836; Fri, 22 Jun 2001 22:44:02 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA17487; Fri, 22 Jun 2001 22:44:02 +0200 (CEST) Date: Fri, 22 Jun 2001 22:44:01 +0200 (CEST) From: Seth Mos To: Joseph Fannin cc: linux-xfs@oss.sgi.com Subject: Re: Xfs Compile problem In-Reply-To: <20010622100852.A17303@zion.rivenstone.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 22 Jun 2001, Joseph Fannin wrote: > > > If it's RH gcc-2.96, then you can bugzilla it (http://bugzilla.redhat.com), > > but given that 3.0 is out it probably won't get fixed in 2.96. > > In the past, RedHat has always released three minor versions of each > major -- i.e. 5.0, 5.1, 5.2; 6.0, 6.1, 6.2. If RedHat decides to release a > version 7.2 of their distribution, it *will* ship with 2.96 -- they won't > break binary compatiblity within a major release series. > > I'm not saying XFS development effort should be directed at 2.96, but I > don't think it's going to go away just yet. If we can support 2.91.66 2.95.3/4 and 3.0 and leave 2.96 for what it is worth. If this policy is maintained 2.91.66 (kgcc) will also still be available. So we can point to them to this package instead. We only now that there are more systems out there with a "older" gcc then redhat 7.x systems with 2.96. Systems will be released with 3.0 fairly soon I think which will mean that it is "available" for all the other distro's. Speaking off, can't we just build in the default compiler selection logic that is included in the kbuild script that is included in default kernels? This one selects kgcc if it is installed on the system and leaves all the other systems out there like SuSe, Debian, Slackware alone and selects gcc if there is no other installed. If that does happen we will not be bitten by accidentally compiling the kernel with 2.96 even when you don't want it. (it even happens to me). > (Please, no beating of the 2.96-is-bad dead horse.) If we can change the selection process it does not directly matter. If you do want to build it with something newer they will now where to find it. Cheerio Seth ps: New machine is in, will update FAQ soon. and nerwer kernels compile a lot faster too ;-) From owner-linux-xfs@oss.sgi.com Fri Jun 22 15:24:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MMOxq32511 for linux-xfs-outgoing; Fri, 22 Jun 2001 15:24:59 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MMOvV32504 for ; Fri, 22 Jun 2001 15:24:57 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip71.idcomm.com [209.60.72.198] (may be forged)) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5MMPel00546 for ; Fri, 22 Jun 2001 16:25:40 -0600 Message-ID: <3B33C616.89D755FF@idcomm.com> Date: Fri, 22 Jun 2001 16:26:30 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: xfs kernel src References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jesse Hall wrote: > > The NVidia Makefiles are designed to handle this correctly. Try > > $ make SYSINCLUDE=/usr/src/linux-2.4/include > > (adjust path as appropriate). This will pull all kernel headers (and > versioned symbols if enabled) from the specified directory. This is > documented in their README. > > I use both 2.2 and 2.4 kernels, and this is far easier than switching > symlinks in /usr, or even switching a /usr/src/linux symlink. I'll file this one away in my list of tips. It should mix well with using non-sym links for the /usr/include/linux/ and similar include directories. D. Stimits, stimits@idcomm.com > > Jesse > > On Fri, 22 Jun 2001, D. Stimits wrote: > > Keith Owens wrote: > > > > > > On Thu, 21 Jun 2001 22:38:20 -0600, > > > "D. Stimits" wrote: > > > >One snag you might be running into is that RH 7.1 makes directories > > > >/usr/include/asm, /usr/include/linux, and /usr/include/scsi hard copies > > > >of their kernel. You probably want to cd to /usr/include, and rename > > > >(mv) asm, linux, and scsi, to some backup. Then also expand on their > > > >symbolic links at /usr/src/. > > > > > > Please do not do that. Linus and other kernel maintainers fought a > > > long and hard battle to stop distributions making symlinks from > > > /usr/include to /usr/src/linux, or to any other active kernel. > > > > > > The files in /usr/include are for user space applications that need a > > > stable set of includes. These must not change depending on which > > > kernel you have installed this week. > > > > Conceptually, in most practical ways, I understand this. But in the case > > of device drivers or hardware that might be compiled, if it does > > something like #include , and something.h has changed > > in the kernel, it could cause other problems than just compile > > incompatibilities. For example, modules that are compiled separately > > from the kernel (because they are not patched in to the kernel or > > otherwise not part of the kernel source tree, such as cvs releases of > > many modules). If all of the writers of kernel-dependent code > > (distributed separately from a kernel) use a #include with an absolute > > path, e.g.: > > #include "/usr/src/linux/include/something.h" > > > > ...then it would always work as advertised. It sounds like maybe it is a > > good idea to keep the headers constant, but it also seems that it will > > cause older software that is hardware dependent to break if it wasn't > > written with this in mind. I have not grepped the NVidia code, but I > > wonder if they have used the format: > > #include > > #include > > > > In any case, I hadn't heard about this till now, so I guess it is time > > to change then. > > > > D. Stimits, stimits@idcomm.com > > > > > > > > User space code cannot assume that it has current kernel headers, > > > instead they get headers that match glibc and other tools. User space > > > code should not read kernel headers directly, instead the package > > > should contain a copy of the required definitions. It is almost always > > > a bad idea for user space applications to depend on kernel headers. > > > Even code like modutils that hooks right into the kernel has its own > > > copy of the required kernel headers, it is the only way to ensure that > > > it ca be compiled on any kernel. > > > > > > Kernel based code must be compiled against kernel headers, not against > > > /usr/include. The kernel makefiles try to avoid reading from anything > > > outside the kernel. > > From owner-linux-xfs@oss.sgi.com Fri Jun 22 16:59:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MNx2f15723 for linux-xfs-outgoing; Fri, 22 Jun 2001 16:59:02 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MNx0V15712 for ; Fri, 22 Jun 2001 16:59:00 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15DapH-00018f-00 for ; Sat, 23 Jun 2001 11:58:59 +1200 Date: Sat, 23 Jun 2001 11:58:59 +1200 (NZST) From: Juha Saarinen To: Subject: Looks good... Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk GCC 2.96-88 from RH Rawhide, that is. Installed it, and compiled the 2.4.6-pre5 from CVS this morning, and ran the usual things, filling up partitions, and removing the files, as well as going into single mode. No f/s corruption... :-) This is on a dual P3 -500, VIA Apollo Pro 133A (Tyan Tiger 133), single EIDE disk at the moment. Next to see if SCSI behaves. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Fri Jun 22 18:01:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5N11uC25914 for linux-xfs-outgoing; Fri, 22 Jun 2001 18:01:56 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5N11sV25911 for ; Fri, 22 Jun 2001 18:01:54 -0700 Received: (qmail 19394 invoked from network); 23 Jun 2001 01:01:51 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 23 Jun 2001 01:01:51 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: Re: Xfs Compile problem In-reply-to: Your message of "Fri, 22 Jun 2001 22:44:01 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Jun 2001 11:01:50 +1000 Message-ID: <11229.993258110@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 22 Jun 2001 22:44:01 +0200 (CEST), Seth Mos wrote: >Speaking off, can't we just build in the default compiler selection logic >that is included in the kbuild script that is included in default kernels? Linus does not like the kernel Makefile guessing which version of cc to use, he wants the user to set it explicitly. 2.2 has such code, 2.4 does not, not even in the -ac tree. From owner-linux-xfs@oss.sgi.com Sat Jun 23 00:01:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5N71AW16802 for linux-xfs-outgoing; Sat, 23 Jun 2001 00:01:10 -0700 Received: from legba.tvnet.hu (legba.tvnet.hu [195.38.96.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5N718V16796 for ; Sat, 23 Jun 2001 00:01:09 -0700 Received: from dumballah.tvnet.hu (zeus.city.tvnet.hu [195.38.100.182]) by legba.tvnet.hu (8.9.3+Sun/8.9.3) with ESMTP id JAA16887 for ; Sat, 23 Jun 2001 09:01:06 +0200 (MEST) Message-ID: <3B343F10.1090901@dumballah.tvnet.hu> Date: Sat, 23 Jun 2001 09:02:40 +0200 From: Sipos Ferenc User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.6-pre5-xfs i686; en-US; rv:0.9.1) Gecko/20010608 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: off: raw devices under devfs Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! I know it's a bit offtopic, but I can't find the answer for the following question: I'm using redhat 7.1 with xfs and devfs enabled, and unable to make raw devices, because raw can't find /dev/rawctl. If I make rawctl with mknod /dev/rawctl c 161 0 and raw /dev/raw1 /dev/cdrom, it won't work. Perhaps, there's another naming scheme under devfs or something has to be compiled into the kernel? I'm using the latest cvs from oss.sgi.com, and gcc 3.0 if that matters. I'd like to make my dvd drive to be a raw device, because of smoother dvd playing. Thx in advance for any help. Paco From owner-linux-xfs@oss.sgi.com Sat Jun 23 09:29:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5NGTWu31717 for linux-xfs-outgoing; Sat, 23 Jun 2001 09:29:32 -0700 Received: from msg.ecetra.com (dollar.ecetra.com [193.164.224.209]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5NGTVV31714 for ; Sat, 23 Jun 2001 09:29:31 -0700 Received: from vie-ac.office.ecetra.com (vie-ac.office.ecetra.com [10.251.148.147] (may be forged)) by msg.ecetra.com (8.9.3/8.9.3) with ESMTP id SAA29015; Sat, 23 Jun 2001 18:29:24 +0200 Received: from localhost (localhost [127.0.0.1]) by vie-ac.office.ecetra.com (8.11.4/8.11.3) with ESMTP id f5NGTOU28381; Sat, 23 Jun 2001 18:29:24 +0200 Date: Sat, 23 Jun 2001 18:29:24 +0200 (CEST) From: Adam Cioccarelli To: Juha Saarinen cc: "linux-xfs@oss.sgi.com" Subject: Re: xfs-progs and gcc-3.0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Juha, I tried it about 5 times and everything is fine... or at least I can't find anything yet. Adam On Sat, 23 Jun 2001, Juha Saarinen wrote: > On Fri, 22 Jun 2001, Adam Cioccarelli wrote: > > > Hi, > > > > I'm not sure if anyone is interested as I am sure there are bigger fish to > > fry at the moment, but the compilation of the xfs-progs fails when I try > > and use gcc-3.0 to compile them. > > > > By the way the kernel compiles and runs (24 hours uptime as I write...) > > Adam, > > Could you try a simple test that my machine has problems with...? Go into > single mode from multiuser mode, and then back again, a few times? I > usually end up with bits of /var getting corrupted (lock files, PID files > e.g.) if I do it on a system that's been compiled with anything newer than > 2.91. > > -- > Regards, > > > Juha > > PGP fingerprint: > B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 > From owner-linux-xfs@oss.sgi.com Sat Jun 23 10:57:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5NHvHJ32507 for linux-xfs-outgoing; Sat, 23 Jun 2001 10:57:17 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5NHvGV32504 for ; Sat, 23 Jun 2001 10:57:16 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA07109 for ; Sat, 23 Jun 2001 10:54:23 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA98404; Sat, 23 Jun 2001 10:56:42 -0700 (PDT) Message-ID: <3B34D7C8.50BED21F@sgi.com> Date: Sat, 23 Jun 2001 12:54:16 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Sipos Ferenc CC: linux-xfs@oss.sgi.com Subject: Re: off: raw devices under devfs References: <3B343F10.1090901@dumballah.tvnet.hu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sipos Ferenc wrote: > I know it's a bit offtopic, but I can't find the answer for the > following question: I'm using redhat 7.1 with xfs and devfs enabled, and > unable to make raw devices The devfs mailing list would probably be the right place for this question: mail majordomo@oss.sgi.com with "subscribe devfs" in the body. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sat Jun 23 11:39:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5NIdQ200373 for linux-xfs-outgoing; Sat, 23 Jun 2001 11:39:26 -0700 Received: from carlo.dirksteinberg.de (pD9583B82.dip.t-dialin.net [217.88.59.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5NIdLV00370 for ; Sat, 23 Jun 2001 11:39:24 -0700 Received: from dirksteinberg.de (localhost [127.0.0.1]) by carlo.dirksteinberg.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id f5NIdBK17020; Sat, 23 Jun 2001 20:39:11 +0200 X-Authentication-Warning: carlo.dirksteinberg.de: Host localhost [127.0.0.1] claimed to be dirksteinberg.de Message-ID: <3B34E24F.6673BD36@dirksteinberg.de> Date: Sat, 23 Jun 2001 20:39:11 +0200 From: Dirk Steinberg X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.2-4GB i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs Subject: XFS on recent -ac kernels Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5NIdPV00371 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, is there any version of XFS that patches into recent versions of the -ac series kernels, such as 2.4.5-ac17? The problem with the CVS tree is that it contains a lot of other stuff besides the actual XFS fs (IOAPIC, kdb, lvm patches, ...) that conflicts with the -ac patches. Alternatively, is there any way to cleanly extract only the XFS/kio portion from the CVS tree as a patch against plain 2.4.5? Or else, can anyone provide the original patches that went into CVS of the non-XFS stuff (kdb, ...)? TIA for any help. Cheers Dirk ------------------------------------------ Ingenieurbüro Dipl.-Ing. Dirk W. Steinberg Ringstr. 2, D-53567 Buchholz, Germany Phone: +49-2683-9793-20, fax: -29 Mobile/GSM: +49-170-818-9793 Email: dws@dirksteinberg.de From owner-linux-xfs@oss.sgi.com Sat Jun 23 11:44:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5NIite00501 for linux-xfs-outgoing; Sat, 23 Jun 2001 11:44:55 -0700 Received: from carlo.dirksteinberg.de (p3E9B9306.dip.t-dialin.net [62.155.147.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5NIiqV00498 for ; Sat, 23 Jun 2001 11:44:54 -0700 Received: from dirksteinberg.de (localhost [127.0.0.1]) by carlo.dirksteinberg.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id f5NIhlK17476; Sat, 23 Jun 2001 20:43:47 +0200 X-Authentication-Warning: carlo.dirksteinberg.de: Host localhost [127.0.0.1] claimed to be dirksteinberg.de Message-ID: <3B34E363.96AA4917@dirksteinberg.de> Date: Sat, 23 Jun 2001 20:43:47 +0200 From: Dirk Steinberg X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.2-4GB i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs Subject: kiocluster Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5NIitV00499 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I remember that some time ago there were mount options for XFS named kio and kiocluster. Inspecting my copy of the XFS CVS tree I was unable to locate these options in the source, so apparently they are gone. Does this mean that the corresponding functionality has been removed, or is this now default? Should kiocluster indeed be enabled by default nowadays, does it work with both SCSI and EIDE, as well as with MD and LVM? Cheers, Dirk ------------------------------------------ Ingenieurbüro Dipl.-Ing. Dirk W. Steinberg Ringstr. 2, D-53567 Buchholz, Germany Phone: +49-2683-9793-20, fax: -29 Mobile/GSM: +49-170-818-9793 Email: dws@dirksteinberg.de From owner-linux-xfs@oss.sgi.com Sat Jun 23 11:48:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5NImBx00655 for linux-xfs-outgoing; Sat, 23 Jun 2001 11:48:11 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5NImAV00652 for ; Sat, 23 Jun 2001 11:48:10 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA01022 for ; Sat, 23 Jun 2001 11:45:17 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA56516; Sat, 23 Jun 2001 11:47:37 -0700 (PDT) Message-ID: <3B34E3B6.20345C51@sgi.com> Date: Sat, 23 Jun 2001 13:45:10 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Dirk Steinberg CC: linux-xfs Subject: Re: XFS on recent -ac kernels References: <3B34E24F.6673BD36@dirksteinberg.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk For starters, you can get the kdb patch for any of Linus' kernels from oss.sgi.com/projects/kdb, to back that out of XFS CVS (possibly with a conflict or two). Alternatively, look in the testing/Release-1.0.1/patches directory on the XFS ftp site, this actually has some patches broken down into xfs-only, lvm, kdb, etc. These patches reflect the state of CVS about 2-3 weeks ago. -Eric Dirk Steinberg wrote: > > Hi, > > is there any version of XFS that patches into > recent versions of the -ac series kernels, such > as 2.4.5-ac17? > > The problem with the CVS tree is that it contains > a lot of other stuff besides the actual XFS fs > (IOAPIC, kdb, lvm patches, ...) that conflicts > with the -ac patches. > > Alternatively, is there any way to cleanly extract only > the XFS/kio portion from the CVS tree as a patch against > plain 2.4.5? > > Or else, can anyone provide the original patches that > went into CVS of the non-XFS stuff (kdb, ...)? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sat Jun 23 12:54:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5NJs6Q02564 for linux-xfs-outgoing; Sat, 23 Jun 2001 12:54:06 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5NJs5V02561 for ; Sat, 23 Jun 2001 12:54:05 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA23405 for ; Sat, 23 Jun 2001 12:54:00 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA90280 for ; Sat, 23 Jun 2001 12:53:33 -0700 (PDT) Message-ID: <3B34F32A.86F96F13@sgi.com> Date: Sat, 23 Jun 2001 14:51:06 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: 1.0.1 testing - PR2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, here's a new release of the XFS 1.0.1 *TESTING* packages and patches. The main difference is that the last few fixes & updates from CVS have been added. Kernel configs in the RPMS have been changed a little - devfs is enabled, but NOT mounted by default (please, hold your applause until the end...). Reiserfs check has been DISabled for the 2.4.5 RPMs, but left as-is in the Red Hat RPMs. Fixed a couple missing symbols in the Red Hat BOOT kernel, which probably didn't matter to anyone anyway. :) The acl package has been updated to 1.0.7. ftp://oss.sgi.com/www/projects/xfs/download/testing/Release-1.0.1-PR2/ Also, since Red Hat has just released new "official" 2.4.3 kernels for 7.1, I'll look at merging 1.0.1 XFS into those kernels, if time allows. Have fun, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sat Jun 23 13:20:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5NKKKT07251 for linux-xfs-outgoing; Sat, 23 Jun 2001 13:20:20 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5NKKJV07247 for ; Sat, 23 Jun 2001 13:20:19 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA24357; Sat, 23 Jun 2001 22:20:17 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA19178; Sat, 23 Jun 2001 22:20:17 +0200 (CEST) Date: Sat, 23 Jun 2001 22:20:16 +0200 (CEST) From: Seth Mos To: Dirk Steinberg cc: linux-xfs Subject: Re: XFS on recent -ac kernels In-Reply-To: <3B34E24F.6673BD36@dirksteinberg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 23 Jun 2001, Dirk Steinberg wrote: > Hi, > > is there any version of XFS that patches into > recent versions of the -ac series kernels, such > as 2.4.5-ac17? The testing release is based on a -ac series kernel and took a lot of time to patch. Normally only patches against linus kernels are made. Cheers Seth From owner-linux-xfs@oss.sgi.com Sat Jun 23 13:22:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5NKMWO07720 for linux-xfs-outgoing; Sat, 23 Jun 2001 13:22:32 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5NKMVV07713 for ; Sat, 23 Jun 2001 13:22:31 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA24570; Sat, 23 Jun 2001 22:22:29 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA19299; Sat, 23 Jun 2001 22:22:29 +0200 (CEST) Date: Sat, 23 Jun 2001 22:22:29 +0200 (CEST) From: Seth Mos To: Dirk Steinberg cc: linux-xfs Subject: Re: kiocluster In-Reply-To: <3B34E363.96AA4917@dirksteinberg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 23 Jun 2001, Dirk Steinberg wrote: > Hi, > > I remember that some time ago there were mount > options for XFS named kio and kiocluster. > > Inspecting my copy of the XFS CVS tree I was unable > to locate these options in the source, so apparently > they are gone. > > Does this mean that the corresponding functionality > has been removed, or is this now default? > > Should kiocluster indeed be enabled by default nowadays, > does it work with both SCSI and EIDE, as well as with > MD and LVM? kiocluster is gone and not available untill there is decided what to build into the kernel. In this case we are following standard kernels. There is probably going to be some form of kiocluster in 2.5 but the actual shape has yet to be formed. Cheers Seth From owner-linux-xfs@oss.sgi.com Sat Jun 23 14:59:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5NLx9I24137 for linux-xfs-outgoing; Sat, 23 Jun 2001 14:59:09 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5NLx7V24133 for ; Sat, 23 Jun 2001 14:59:07 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15DvQk-0003Hs-00; Sun, 24 Jun 2001 09:59:02 +1200 Date: Sun, 24 Jun 2001 09:59:02 +1200 (NZST) From: Juha Saarinen To: Adam Cioccarelli cc: "linux-xfs@oss.sgi.com" Subject: Re: xfs-progs and gcc-3.0 In-Reply-To: Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 23 Jun 2001, Adam Cioccarelli wrote: > Hi Juha, > > I tried it about 5 times and everything is fine... or at least I can't > find anything yet. > > Adam Sounds good -- I've done the same plus beaten up the f/s with parallell bonnies, fsstress, rm -rf's, tar/untar, and it's all working still. This is with gcc 2.96-88 from RH Rawhide. Wonder what changed? Is it the compiler or is it the CVS XFS code? -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Sat Jun 23 16:20:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5NNK3g05315 for linux-xfs-outgoing; Sat, 23 Jun 2001 16:20:03 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5NNK2V05310 for ; Sat, 23 Jun 2001 16:20:02 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5NNJr018080; Sat, 23 Jun 2001 19:19:53 -0400 Date: Sat, 23 Jun 2001 19:19:53 -0400 From: Alan Eldridge To: sandeen@sgi.com Cc: linux-xfs@oss.sgi.com Subject: No read permission on 2.4.5-PR2.i686 Message-ID: <20010623191953.A18077@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You've got mode 600 on the 2.4.5 i686 kernel rpm. Kinda hard to ftp the file when it's like that ... -- Alan Eldridge "Smart Tags? We don't need no steenking Smart Tags!" From owner-linux-xfs@oss.sgi.com Sat Jun 23 17:21:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5O0L2m15587 for linux-xfs-outgoing; Sat, 23 Jun 2001 17:21:02 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5O0L0V15584 for ; Sat, 23 Jun 2001 17:21:01 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA09298 for ; Sat, 23 Jun 2001 17:18:07 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA61165; Sat, 23 Jun 2001 17:20:19 -0700 (PDT) Message-ID: <3B3531AF.B45E879D@sgi.com> Date: Sat, 23 Jun 2001 19:17:51 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Alan Eldridge CC: linux-xfs@oss.sgi.com Subject: Re: No read permission on 2.4.5-PR2.i686 References: <20010623191953.A18077@wwweasel.geeksrus.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alan Eldridge wrote: > > You've got mode 600 on the 2.4.5 i686 kernel rpm. Kinda hard to ftp the file > when it's like that ... Whoops... s/b better now. Sorry! -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sun Jun 24 00:51:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5O7pXl25550 for linux-xfs-outgoing; Sun, 24 Jun 2001 00:51:33 -0700 Received: from piro.kabuki.sfarc.net (mail@[203.36.158.121]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5O7pUV25540 for ; Sun, 24 Jun 2001 00:51:30 -0700 Received: from daniel by piro.kabuki.sfarc.net with local (Exim 3.22 #1 (Debian)) id 15E4gG-000506-00; Sun, 24 Jun 2001 17:51:40 +1000 Date: Sun, 24 Jun 2001 17:51:39 +1000 From: Daniel Stone To: linux-xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: [OOPS] XFS in large Maildir Message-ID: <20010624175139.A19220@kabuki.sfarc.net> Mail-Followup-To: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline User-Agent: Mutt/1.3.18i Organisation: Sadly lacking Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi guys, I've attached the ksymoops output from Linux 2.4.6-pre3-xfs (CVS tree from some point). I'll try an update now, but when I try to access stuff in ~/Maildir/netfilter/cur (~7k files in it), XFS just OOPSes. The OOPS I attached was from mutt, but it also successfully hangs ls, so I doubt it's a mutt bug. :) d -- Daniel Stone "can NE1 help me aim nuclear weaponz????? /MSG ME!!" --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=oops2 ksymoops 2.4.1 on i586 2.4.6-pre3-xfs. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.6-pre3-xfs/ (default) -m /boot/System.map-2.4.6-pre3-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. No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Error (regular_file): read_system_map stat /boot/System.map-2.4.6-pre3-xfs failed Unable to handle kernel paging request at virtual address e5a8b460 c01a7a0b *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010082 eax: e5a8b440 ebx: 224d7000 ecx: c5a8b440 edx: c5c7d9c0 esi: c5a8c1e0 edi: e5a8b440 ebp: c467ba9c esp: c467ba98 ds: 0018 es: 0018 ss: 0018 Process mutt (pid: 7299, stackpage=c467b000) Stack: c45bd7e0 c467bab8 c01a3f11 c5c7d9c0 e5a8b440 00000000 c467bcc4 c5a8d0c0 c467bc70 c01a3d10 c5a8c1e0 c5a8b440 c467badc 00000000 c467bcc4 c5a8d0c0 c01c3052 c589a470 c589a470 22508000 00000000 00001000 c467bb00 c589a550 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 48 20 8b 52 24 8b 40 24 39 cb 75 0c 39 c2 75 08 8d 74 26 >>EIP; c01a7a0b <===== Trace; c01a3f11 Trace; e5a8b440 Trace; c01a3d10 Trace; c01c3052 Trace; c01a3c4f Trace; c01a4722 Trace; c020b840 Trace; c01a3f67 Trace; c01a7bca Trace; c01cfd10 Trace; c01a4079 Trace; c01a7c50 Trace; c01a7c68 Trace; c01a46fa Trace; c01f78e0 Trace; c01e45d3 Trace; c01e5643 Trace; c01e36c9 Trace; c01e3aa6 Trace; c01f8baa Trace; c01fd1d1 Trace; c020592e Trace; c01367a8 Trace; c0136e6d Trace; c01375db Trace; c012c49e Trace; c012c7a6 Trace; c0106b13 <__up_wakeup+102b/23dc> Code; c01a7a0b 0000000000000000 <_EIP>: Code; c01a7a0b <===== 0: 8b 48 20 mov 0x20(%eax),%ecx <===== Code; c01a7a0e 3: 8b 52 24 mov 0x24(%edx),%edx Code; c01a7a11 6: 8b 40 24 mov 0x24(%eax),%eax Code; c01a7a14 9: 39 cb cmp %ecx,%ebx Code; c01a7a16 b: 75 0c jne 19 <_EIP+0x19> c01a7a24 Code; c01a7a18 d: 39 c2 cmp %eax,%edx Code; c01a7a1a f: 75 08 jne 19 <_EIP+0x19> c01a7a24 Code; c01a7a1c 11: 8d 74 26 00 lea 0x0(%esi,1),%esi 2 warnings and 1 error issued. Results may not be reliable. --YiEDa0DAkWCtVeE4-- From owner-linux-xfs@oss.sgi.com Sun Jun 24 01:57:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5O8vo404305 for linux-xfs-outgoing; Sun, 24 Jun 2001 01:57:50 -0700 Received: from carlo.dirksteinberg.de (pD9583A0C.dip.t-dialin.net [217.88.58.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5O8vlV04294 for ; Sun, 24 Jun 2001 01:57:48 -0700 Received: from dirksteinberg.de (localhost [127.0.0.1]) by carlo.dirksteinberg.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id f5O8uGK23786; Sun, 24 Jun 2001 10:56:26 +0200 X-Authentication-Warning: carlo.dirksteinberg.de: Host localhost [127.0.0.1] claimed to be dirksteinberg.de Message-ID: <3B35AB2F.8D12FD2D@dirksteinberg.de> Date: Sun, 24 Jun 2001 10:56:15 +0200 From: Dirk Steinberg X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.2-4GB i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs Subject: Re: XFS on recent -ac kernels References: <3B34E24F.6673BD36@dirksteinberg.de> <3B34E3B6.20345C51@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > For starters, you can get the kdb patch for any of Linus' kernels from > oss.sgi.com/projects/kdb, to back that out of XFS CVS (possibly with a > conflict or two). > > Alternatively, look in the testing/Release-1.0.1/patches directory on > the XFS ftp site, this actually has some patches broken down into > xfs-only, lvm, kdb, etc. These patches reflect the state of CVS about > 2-3 weeks ago. > > -Eric What has changed in CVS since then? Is there any CVS tag from the time the Release-1.0.1 snapshot was made? - Dirk > Dirk Steinberg wrote: > > is there any version of XFS that patches into > > recent versions of the -ac series kernels, such > > as 2.4.5-ac17? > > > > The problem with the CVS tree is that it contains > > a lot of other stuff besides the actual XFS fs > > (IOAPIC, kdb, lvm patches, ...) that conflicts > > with the -ac patches. > > > > Alternatively, is there any way to cleanly extract only > > the XFS/kio portion from the CVS tree as a patch against > > plain 2.4.5? > > > > Or else, can anyone provide the original patches that > > went into CVS of the non-XFS stuff (kdb, ...)? From owner-linux-xfs@oss.sgi.com Sun Jun 24 02:01:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5O913804911 for linux-xfs-outgoing; Sun, 24 Jun 2001 02:01:03 -0700 Received: from carlo.dirksteinberg.de (pD9583A0C.dip.t-dialin.net [217.88.58.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5O90rV04868 for ; Sun, 24 Jun 2001 02:00:55 -0700 Received: from dirksteinberg.de (localhost [127.0.0.1]) by carlo.dirksteinberg.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id f5O8xhK23790; Sun, 24 Jun 2001 10:59:50 +0200 X-Authentication-Warning: carlo.dirksteinberg.de: Host localhost [127.0.0.1] claimed to be dirksteinberg.de Message-ID: <3B35ABFF.73079924@dirksteinberg.de> Date: Sun, 24 Jun 2001 10:59:43 +0200 From: Dirk Steinberg X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.2-4GB i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: linux-xfs Subject: Re: XFS on recent -ac kernels References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Which testing release are you referring to? The one in ftp://oss.sgi.com/projects/xfs/download/testing/RHrawhide/ ? I'll try to patch that from -ac4 to -ac17 and see what happens... Cheers Dirk Seth Mos wrote: > On Sat, 23 Jun 2001, Dirk Steinberg wrote: > > is there any version of XFS that patches into > > recent versions of the -ac series kernels, such > > as 2.4.5-ac17? > > The testing release is based on a -ac series kernel and took a lot of time > to patch. Normally only patches against linus kernels are made. > > Cheers > Seth From owner-linux-xfs@oss.sgi.com Sun Jun 24 03:18:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OAI7d18184 for linux-xfs-outgoing; Sun, 24 Jun 2001 03:18:07 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OAI5V18180 for ; Sun, 24 Jun 2001 03:18:06 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id MAA23278; Sun, 24 Jun 2001 12:18:01 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id MAA14762; Sun, 24 Jun 2001 12:18:01 +0200 (CEST) Date: Sun, 24 Jun 2001 12:18:00 +0200 (CEST) From: Seth Mos To: Daniel Stone cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [OOPS] XFS in large Maildir In-Reply-To: <20010624175139.A19220@kabuki.sfarc.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 24 Jun 2001, Daniel Stone wrote: > Hi guys, > I've attached the ksymoops output from Linux 2.4.6-pre3-xfs (CVS tree from > some point). I'll try an update now, but when I try to access stuff in > ~/Maildir/netfilter/cur (~7k files in it), XFS just OOPSes. The OOPS I > attached was from mutt, but it also successfully hangs ls, so I doubt it's a > mutt bug. Have you tried running xfs_repair -n on the filesystem to see if something is wrong? Was the kernel compiled with 2.96-?? of 2.91.66? From owner-linux-xfs@oss.sgi.com Sun Jun 24 03:43:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OAhqE22690 for linux-xfs-outgoing; Sun, 24 Jun 2001 03:43:52 -0700 Received: from citadel.oehansen.pp.se (sdu99-201.ppp.algonet.se [195.163.201.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OAhoV22679 for ; Sun, 24 Jun 2001 03:43:50 -0700 Received: from citadel.oehansen.pp.se (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f5OAdUW12715 for ; Sun, 24 Jun 2001 12:39:30 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se To: linux-xfs@oss.sgi.com Subject: Access control lists Date: Sun, 24 Jun 2001 12:39:29 +0200 X-Mailer: KMail [version 1.2] X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 X-MIME-Autoconverted: from 8bit to quoted-printable by citadel.oehansen.pp.se id f5OAdUW12715 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5OAhqV22688 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I don't know if this is relevant, but I'm using linux 2.4.3, compiled with XFS support. And had a few starting problems, first was that the kernel hung up on me, if I didn't compile ACL cupport into the kernel along with XFS. This is not mentioned in the howto. The second, is the use of the acl :-) I've got the XFS file system mounted under /opt/xfs ... and then I've got the following file in that directory: -rw-r--r-- 1 root root 46 Jún 24 12:16 testing It's parent directory looks like this: drwxrwxrwx 2 root root 20 Jún 24 12:16 xfs Anybody can write to the directory... now the acl of the file testing looks like this: /opt/xfs/testing [] And then another user logs in, and edits the file with 'vi' and writes with ':w!' this is what it looks like after that ordeal: -rw-r--r-- 1 asta users 21 Jún 24 12:27 testing Then I try setting access control... to see if its the missing acl that is the problem. /opt/xfs/testing [u::rw-,g::r--,o::r--,u:oehansen:rw-,m::r--] and make root the owner again... and again, the user asta tries to edit the file: -rw-r--r-- 1 asta users 29 Jún 24 12:32 /opt/xfs/testing I think this is a major concern... Sincerely, Orn From owner-linux-xfs@oss.sgi.com Sun Jun 24 03:50:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OAouH23964 for linux-xfs-outgoing; Sun, 24 Jun 2001 03:50:56 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OAosV23958 for ; Sun, 24 Jun 2001 03:50:55 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id MAA27866; Sun, 24 Jun 2001 12:50:52 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id MAA17932; Sun, 24 Jun 2001 12:50:52 +0200 (CEST) Date: Sun, 24 Jun 2001 12:50:52 +0200 (CEST) From: Seth Mos To: Dirk Steinberg cc: linux-xfs Subject: Re: XFS on recent -ac kernels In-Reply-To: <3B35ABFF.73079924@dirksteinberg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 24 Jun 2001, Dirk Steinberg wrote: > Which testing release are you referring to? The one in > ftp://oss.sgi.com/projects/xfs/download/testing/RHrawhide/ ? > > I'll try to patch that from -ac4 to -ac17 and see what happens... The RedHat rawhide kernel is -ac based an Russel needed 3 hours(!) to patch XFS with this kernel. Cheers Seth > Cheers > Dirk > > Seth Mos wrote: > > On Sat, 23 Jun 2001, Dirk Steinberg wrote: > > > is there any version of XFS that patches into > > > recent versions of the -ac series kernels, such > > > as 2.4.5-ac17? > > > > The testing release is based on a -ac series kernel and took a lot of time > > to patch. Normally only patches against linus kernels are made. > > > > Cheers > > Seth > From owner-linux-xfs@oss.sgi.com Sun Jun 24 03:52:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OAqx624413 for linux-xfs-outgoing; Sun, 24 Jun 2001 03:52:59 -0700 Received: from piro.kabuki.sfarc.net (mail@[203.36.158.121]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OAqwV24404 for ; Sun, 24 Jun 2001 03:52:58 -0700 Received: from daniel by piro.kabuki.sfarc.net with local (Exim 3.22 #1 (Debian)) id 15E7Vd-0006w2-00; Sun, 24 Jun 2001 20:52:53 +1000 Date: Sun, 24 Jun 2001 20:52:53 +1000 From: Daniel Stone To: Seth Mos Cc: Daniel Stone , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [OOPS] XFS in large Maildir Message-ID: <20010624205252.A26659@kabuki.sfarc.net> Mail-Followup-To: Seth Mos , Daniel Stone , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i Organisation: Sadly lacking Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Jun 24, 2001 at 12:18:00PM +0200, Seth Mos wrote: > On Sun, 24 Jun 2001, Daniel Stone wrote: > > > Hi guys, > > I've attached the ksymoops output from Linux 2.4.6-pre3-xfs (CVS tree from > > some point). I'll try an update now, but when I try to access stuff in > > ~/Maildir/netfilter/cur (~7k files in it), XFS just OOPSes. The OOPS I > > attached was from mutt, but it also successfully hangs ls, so I doubt it's a > > mutt bug. > > Have you tried running xfs_repair -n on the filesystem to see if something > is wrong? Was the kernel compiled with 2.96-?? of 2.91.66? I haven't tried anything on the filesystem yet, and it was compiled with Debian (sid aka unstable)'s 2.95.3 snapshot. -- Daniel Stone "can NE1 help me aim nuclear weaponz????? /MSG ME!!" From owner-linux-xfs@oss.sgi.com Sun Jun 24 04:07:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OB7je27141 for linux-xfs-outgoing; Sun, 24 Jun 2001 04:07:45 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OB7iV27126 for ; Sun, 24 Jun 2001 04:07:44 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id NAA00730; Sun, 24 Jun 2001 13:07:41 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id NAA19680; Sun, 24 Jun 2001 13:07:40 +0200 (CEST) Date: Sun, 24 Jun 2001 13:07:40 +0200 (CEST) From: Seth Mos To: Daniel Stone cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [OOPS] XFS in large Maildir In-Reply-To: <20010624205252.A26659@kabuki.sfarc.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 24 Jun 2001, Daniel Stone wrote: > On Sun, Jun 24, 2001 at 12:18:00PM +0200, Seth Mos wrote: > > On Sun, 24 Jun 2001, Daniel Stone wrote: > > > > > Hi guys, > > > I've attached the ksymoops output from Linux 2.4.6-pre3-xfs (CVS tree from > > > some point). I'll try an update now, but when I try to access stuff in > > > ~/Maildir/netfilter/cur (~7k files in it), XFS just OOPSes. The OOPS I > > > attached was from mutt, but it also successfully hangs ls, so I doubt it's a > > > mutt bug. > > > > Have you tried running xfs_repair -n on the filesystem to see if something > > is wrong? Was the kernel compiled with 2.96-?? of 2.91.66? > > I haven't tried anything on the filesystem yet, and it was compiled with > Debian (sid aka unstable)'s 2.95.3 snapshot. if you can run xfs_repair -n to see if it produces error output. xfs_repair -n works on a mounted filesystem but does not change anything. If you do see errors you need to unmount the fs and run xfs_repair and see if you can reproduce the oops after that there must be other issues. Can you also apt-get 2.95.4? I believe that one currently is in unstable. Even if it is just to test for compiler differences. Thanks Seth From owner-linux-xfs@oss.sgi.com Sun Jun 24 04:11:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OBBsg27859 for linux-xfs-outgoing; Sun, 24 Jun 2001 04:11:54 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OBBrV27855 for ; Sun, 24 Jun 2001 04:11:53 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id NAA01340; Sun, 24 Jun 2001 13:11:52 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id NAA20092; Sun, 24 Jun 2001 13:11:46 +0200 (CEST) Date: Sun, 24 Jun 2001 13:11:46 +0200 (CEST) From: Seth Mos To: Dirk Steinberg cc: Eric Sandeen , linux-xfs Subject: Re: XFS on recent -ac kernels In-Reply-To: <3B35AB2F.8D12FD2D@dirksteinberg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 24 Jun 2001, Dirk Steinberg wrote: > Eric Sandeen wrote: > > For starters, you can get the kdb patch for any of Linus' kernels from > > oss.sgi.com/projects/kdb, to back that out of XFS CVS (possibly with a > > conflict or two). > > > > Alternatively, look in the testing/Release-1.0.1/patches directory on > > the XFS ftp site, this actually has some patches broken down into > > xfs-only, lvm, kdb, etc. These patches reflect the state of CVS about > > 2-3 weeks ago. > > > > -Eric > > What has changed in CVS since then? Is there any CVS tag from the > time the Release-1.0.1 snapshot was made? They take a current kernel release (2.4.5) and stabilize that by backporting fixes that are inserted in CVS. Currently the CVS tree is tracking the linus -pre versions and releases. Cheers Seth From owner-linux-xfs@oss.sgi.com Sun Jun 24 04:31:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OBVtX03589 for linux-xfs-outgoing; Sun, 24 Jun 2001 04:31:55 -0700 Received: from piro.kabuki.sfarc.net (mail@[203.36.158.121]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OBVrV03578 for ; Sun, 24 Jun 2001 04:31:53 -0700 Received: from daniel by piro.kabuki.sfarc.net with local (Exim 3.22 #1 (Debian)) id 15E87L-00074b-00; Sun, 24 Jun 2001 21:31:51 +1000 Date: Sun, 24 Jun 2001 21:31:51 +1000 From: Daniel Stone To: Seth Mos Cc: Daniel Stone , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [OOPS] XFS in large Maildir Message-ID: <20010624213151.A27190@kabuki.sfarc.net> Mail-Followup-To: Seth Mos , Daniel Stone , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i Organisation: Sadly lacking Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Jun 24, 2001 at 01:07:40PM +0200, Seth Mos wrote: > On Sun, 24 Jun 2001, Daniel Stone wrote: > > > On Sun, Jun 24, 2001 at 12:18:00PM +0200, Seth Mos wrote: > > > On Sun, 24 Jun 2001, Daniel Stone wrote: > > > > > > > Hi guys, > > > > I've attached the ksymoops output from Linux 2.4.6-pre3-xfs (CVS tree from > > > > some point). I'll try an update now, but when I try to access stuff in > > > > ~/Maildir/netfilter/cur (~7k files in it), XFS just OOPSes. The OOPS I > > > > attached was from mutt, but it also successfully hangs ls, so I doubt it's a > > > > mutt bug. > > > > > > Have you tried running xfs_repair -n on the filesystem to see if something > > > is wrong? Was the kernel compiled with 2.96-?? of 2.91.66? > > > > I haven't tried anything on the filesystem yet, and it was compiled with > > Debian (sid aka unstable)'s 2.95.3 snapshot. > > if you can run xfs_repair -n to see if it produces error output. > xfs_repair -n works on a mounted filesystem but does not change anything. > > If you do see errors you need to unmount the fs and run xfs_repair and see > if you can reproduce the oops after that there must be other issues. > > Can you also apt-get 2.95.4? I believe that one currently is in unstable. > Even if it is just to test for compiler differences. Er, it's the latest from unstable, whichever one that happens to be. -- Daniel Stone "can NE1 help me aim nuclear weaponz????? /MSG ME!!" From owner-linux-xfs@oss.sgi.com Sun Jun 24 04:57:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OBvsC08087 for linux-xfs-outgoing; Sun, 24 Jun 2001 04:57:54 -0700 Received: from ii.uib.no (eik-192.ii.uib.no [129.177.192.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OBvqV08076 for ; Sun, 24 Jun 2001 04:57:53 -0700 Received: from apal-192.ii.uib.no (apal.ii.uib.no) [129.177.192.27] by ii.uib.no with esmtp (Exim 3.03) id 15E8WU-0002cn-00 ; Sun, 24 Jun 2001 13:57:51 +0200 Received: (from janfrode@localhost) by apal.ii.uib.no (8.9.3+Sun/8.9.3) id NAA21279; Sun, 24 Jun 2001 13:57:50 +0200 (MEST) Date: Sun, 24 Jun 2001 13:57:50 +0200 From: Jan-Frode Myklebust To: "Orn E. Hansen" Cc: linux-xfs@oss.sgi.com Subject: Re: Access control lists Message-ID: <20010624135750.A20895@ii.uib.no> References: <01062412392901.01807@citadel.oehansen.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <01062412392901.01807@citadel.oehansen.pp.se>; from oe.hansen@gamma.telenordia.se on Sun, Jun 24, 2001 at 12:39:29PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [snip] > > drwxrwxrwx 2 root root 20 Jún 24 12:16 xfs > Anybody kan write and delete files in this directory. If you want to limit deletions to the owner of the file, you'll have to add the sticky bit. chmod +t /opt/xfs [snip] > And then another user logs in, and edits the file with 'vi' and writes with > ':w!' this is what it looks like after that ordeal: > I believe 'vi' overrides the file permissions by deleting and creating a new file, which is allowed by the directory permission. Try it on a ext2 filesystem, and you should get the same results. -jf From owner-linux-xfs@oss.sgi.com Sun Jun 24 05:19:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OCJKY11876 for linux-xfs-outgoing; Sun, 24 Jun 2001 05:19:20 -0700 Received: from piro.kabuki.sfarc.net (mail@[203.36.158.121]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OCJIV11870 for ; Sun, 24 Jun 2001 05:19:18 -0700 Received: from daniel by piro.kabuki.sfarc.net with local (Exim 3.22 #1 (Debian)) id 15E8rH-00005a-00; Sun, 24 Jun 2001 22:19:19 +1000 Date: Sun, 24 Jun 2001 22:19:19 +1000 From: Daniel Stone To: Daniel Stone Cc: Seth Mos , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [OOPS] XFS in large Maildir Message-ID: <20010624221919.B331@kabuki.sfarc.net> Mail-Followup-To: Daniel Stone , Seth Mos , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: <20010624213151.A27190@kabuki.sfarc.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010624213151.A27190@kabuki.sfarc.net> User-Agent: Mutt/1.3.18i Organisation: Sadly lacking Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > if you can run xfs_repair -n to see if it produces error output. > > xfs_repair -n works on a mounted filesystem but does not change anything. > > > > If you do see errors you need to unmount the fs and run xfs_repair and see > > if you can reproduce the oops after that there must be other issues. > > > > Can you also apt-get 2.95.4? I believe that one currently is in unstable. > > Even if it is just to test for compiler differences. xfs_repair saw nothing, and it works just fine with -pre5-xfs. :) d -- Daniel Stone "can NE1 help me aim nuclear weaponz????? /MSG ME!!" From owner-linux-xfs@oss.sgi.com Sun Jun 24 06:14:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5ODElP21228 for linux-xfs-outgoing; Sun, 24 Jun 2001 06:14:47 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5ODEjV21222 for ; Sun, 24 Jun 2001 06:14:46 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id PAA29565; Sun, 24 Jun 2001 15:14:42 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id PAA02667; Sun, 24 Jun 2001 15:14:42 +0200 (CEST) Date: Sun, 24 Jun 2001 15:14:41 +0200 (CEST) From: Seth Mos To: Daniel Stone cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [OOPS] XFS in large Maildir In-Reply-To: <20010624221919.B331@kabuki.sfarc.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 24 Jun 2001, Daniel Stone wrote: > > > if you can run xfs_repair -n to see if it produces error output. > > > xfs_repair -n works on a mounted filesystem but does not change anything. > > > > > > If you do see errors you need to unmount the fs and run xfs_repair and see > > > if you can reproduce the oops after that there must be other issues. > > > > > > Can you also apt-get 2.95.4? I believe that one currently is in unstable. > > > Even if it is just to test for compiler differences. > > xfs_repair saw nothing, and it works just fine with -pre5-xfs. > :) d It might be that some general compiler bugs are still being fixed in the linus tree. There a lot of people out their that test various compilers. The linus kernel also had a lot of compiler fixes. > Daniel Stone > "can NE1 help me aim nuclear weaponz????? /MSG ME!!" Hit the shiny red button that says do not touch. Cheers Seth From owner-linux-xfs@oss.sgi.com Sun Jun 24 06:26:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5ODQth22997 for linux-xfs-outgoing; Sun, 24 Jun 2001 06:26:55 -0700 Received: from citadel.oehansen.pp.se (sdu123-203.ppp.algonet.se [195.163.203.123]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5ODQrV22994 for ; Sun, 24 Jun 2001 06:26:53 -0700 Received: from citadel.oehansen.pp.se (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f5ODROw01335 for ; Sun, 24 Jun 2001 15:27:25 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se To: linux-xfs@oss.sgi.com Subject: Filesystem sizes Date: Sun, 24 Jun 2001 15:27:24 +0200 X-Mailer: KMail [version 1.2] X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'd like to move much of my data to a journaling file system, especially since the kernels at late af a tendancy of crashing from time to time :-) and I've seen several files "vanish" as a result. Now I tried backing up the following ext2 file system... /dev/hdb13 326682 7814 302002 3% /usr/doc And made the file system an xfs, and remounted and putting the archived data back into the directory results in... /dev/hdb13 332532 115728 216804 35% /usr/doc Any explanation? and in case anyone asks, yes I tried making the file system an ext2 filesystem again, and then the used size is normal. Orn From owner-linux-xfs@oss.sgi.com Sun Jun 24 07:08:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OE8cd29859 for linux-xfs-outgoing; Sun, 24 Jun 2001 07:08:38 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OE8aV29855 for ; Sun, 24 Jun 2001 07:08:36 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id QAA07252; Sun, 24 Jun 2001 16:08:34 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id QAA08241; Sun, 24 Jun 2001 16:08:04 +0200 (CEST) Date: Sun, 24 Jun 2001 16:08:04 +0200 (CEST) From: Seth Mos To: "Orn E. Hansen" cc: linux-xfs@oss.sgi.com Subject: Re: Filesystem sizes In-Reply-To: <01062415272400.01212@citadel.oehansen.pp.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 24 Jun 2001, Orn E. Hansen wrote: > > I'd like to move much of my data to a journaling file system, especially > since the kernels at late af a tendancy of crashing from time to time :-) and > I've seen several files "vanish" as a result. > > Now I tried backing up the following ext2 file system... > > /dev/hdb13 326682 7814 302002 3% /usr/doc > > > And made the file system an xfs, and remounted and putting the archived > data back into the directory results in... > > /dev/hdb13 332532 115728 216804 35% /usr/doc > > > Any explanation? and in case anyone asks, yes I tried making the file > system an ext2 filesystem again, and then the used size is normal. What size does du report when using it on that dir. Cheers Seth From owner-linux-xfs@oss.sgi.com Sun Jun 24 07:26:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OEQ1Z32512 for linux-xfs-outgoing; Sun, 24 Jun 2001 07:26:01 -0700 Received: from carlo.dirksteinberg.de (p3E9D3D43.dip.t-dialin.net [62.157.61.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OEPxV32508 for ; Sun, 24 Jun 2001 07:25:59 -0700 Received: from dirksteinberg.de (localhost [127.0.0.1]) by carlo.dirksteinberg.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id f5OEOxK26202; Sun, 24 Jun 2001 16:24:59 +0200 X-Authentication-Warning: carlo.dirksteinberg.de: Host localhost [127.0.0.1] claimed to be dirksteinberg.de Message-ID: <3B35F83B.39E43E35@dirksteinberg.de> Date: Sun, 24 Jun 2001 16:24:59 +0200 From: Dirk Steinberg X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.2-4GB i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: linux-xfs Subject: Re: kiocluster References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > On Sat, 23 Jun 2001, Dirk Steinberg wrote: > > I remember that some time ago there were mount > > options for XFS named kio and kiocluster. > > > > Inspecting my copy of the XFS CVS tree I was unable > > to locate these options in the source, so apparently > > they are gone. > > > > Does this mean that the corresponding functionality > > has been removed, or is this now default? > > > > Should kiocluster indeed be enabled by default nowadays, > > does it work with both SCSI and EIDE, as well as with > > MD and LVM? > > kiocluster is gone and not available untill there is decided what to build > into the kernel. In this case we are following standard kernels. > There is probably going to be some form of kiocluster in 2.5 but the > actual shape has yet to be formed. What about kio? I see it's implemented for both SCSI and EIDE. How about MD and LVM? Should I expect a significant performance penalty for using XFS on top of LVM or MD instead of running it directly on the physical disk partition? - Dirk From owner-linux-xfs@oss.sgi.com Sun Jun 24 07:31:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OEVRj00966 for linux-xfs-outgoing; Sun, 24 Jun 2001 07:31:27 -0700 Received: from citadel.oehansen.pp.se (sdu17-205.ppp.algonet.se [195.163.205.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OEVNV00956 for ; Sun, 24 Jun 2001 07:31:23 -0700 Received: from citadel.oehansen.pp.se (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f5OEWnl01585; Sun, 24 Jun 2001 16:32:49 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se To: Seth Mos Subject: Re: Filesystem sizes Date: Sun, 24 Jun 2001 16:32:48 +0200 X-Mailer: KMail [version 1.2] References: In-Reply-To: Cc: linux-xfs@oss.sgi.com X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 X-MIME-Autoconverted: from 8bit to quoted-printable by citadel.oehansen.pp.se id f5OEWnl01585 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5OEVPV00960 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk sunnudagur 24. júní 2001 16:08, þú skrifaðir: > > What size does du report when using it on that dir. > > Cheers > Seth The files inside the directories, have the same sizes in both cases... I took a peek at some of the directories. An example, is a file inside the graphics9help/en/paint9_linux/default directory, which is 3150 bytes in size, occupying 5k in ext2, but occupying 64k in xfs. The graphics9help/en/paint9_linux/filter80 contains 62 files, occupies 198k in ext2. But occupies 3972k (62*64=3968) in xfs. When an ext2 file system... it reports: [root@citadel /]# du -k /usr/doc/ 1 /usr/doc/lost+found 1 /usr/doc/alsa-lib-0.9.0beta4 4 /usr/doc/graphics9-common 5 /usr/doc/graphics9help/en/paint9_linux/default 198 /usr/doc/graphics9help/en/paint9_linux/filter80 933 /usr/doc/graphics9help/en/paint9_linux/glos_com 435 /usr/doc/graphics9help/en/paint9_linux/image 4 /usr/doc/graphics9help/en/paint9_linux/include 199 /usr/doc/graphics9help/en/paint9_linux/p_cdrgfx 149 /usr/doc/graphics9help/en/paint9_linux/p_cdrui 89 /usr/doc/graphics9help/en/paint9_linux/p_color 100 /usr/doc/graphics9help/en/paint9_linux/p_conver 37 /usr/doc/graphics9help/en/paint9_linux/p_filter 47 /usr/doc/graphics9help/en/paint9_linux/p_intro 249 /usr/doc/graphics9help/en/paint9_linux/p_mask 58 /usr/doc/graphics9help/en/paint9_linux/p_movie 201 /usr/doc/graphics9help/en/paint9_linux/p_paint 99 /usr/doc/graphics9help/en/paint9_linux/p_path 50 /usr/doc/graphics9help/en/paint9_linux/p_pdf 10 /usr/doc/graphics9help/en/paint9_linux/p_record 147 /usr/doc/graphics9help/en/paint9_linux/p_retouc 414 /usr/doc/graphics9help/en/paint9_linux/p_specfx 194 /usr/doc/graphics9help/en/paint9_linux/p_start 207 /usr/doc/graphics9help/en/paint9_linux/p_textob 27 /usr/doc/graphics9help/en/paint9_linux/p_web 20 /usr/doc/graphics9help/en/paint9_linux/pop_clr 5 /usr/doc/graphics9help/en/paint9_linux/pop_pdf 32 /usr/doc/graphics9help/en/paint9_linux/pop_prn 590 /usr/doc/graphics9help/en/paint9_linux/poptool 6446 /usr/doc/graphics9help/en/paint9_linux 97 /usr/doc/graphics9help/en/techsupport_linux/corelts 5 /usr/doc/graphics9help/en/techsupport_linux/image 609 /usr/doc/graphics9help/en/techsupport_linux 1 /usr/doc/graphics9help/en/draw9_linux/default 1 /usr/doc/graphics9help/en/draw9_linux/drawpop 1 /usr/doc/graphics9help/en/draw9_linux/filter80 1 /usr/doc/graphics9help/en/draw9_linux/glos_com 1 /usr/doc/graphics9help/en/draw9_linux/image 1 /usr/doc/graphics9help/en/draw9_linux/include 1 /usr/doc/graphics9help/en/draw9_linux/p_bitmap 1 /usr/doc/graphics9help/en/draw9_linux/p_cdrgfx 1 /usr/doc/graphics9help/en/draw9_linux/p_cdrtxt 1 /usr/doc/graphics9help/en/draw9_linux/p_cdrui 1 /usr/doc/graphics9help/en/draw9_linux/p_color 1 /usr/doc/graphics9help/en/draw9_linux/p_drwint 1 /usr/doc/graphics9help/en/draw9_linux/p_effect 1 /usr/doc/graphics9help/en/draw9_linux/p_fill 1 /usr/doc/graphics9help/en/draw9_linux/p_filter 1 /usr/doc/graphics9help/en/draw9_linux/p_getsta 1 /usr/doc/graphics9help/en/draw9_linux/p_intern 1 /usr/doc/graphics9help/en/draw9_linux/p_organ 1 /usr/doc/graphics9help/en/draw9_linux/p_pdf 1 /usr/doc/graphics9help/en/draw9_linux/p_shapes 1 /usr/doc/graphics9help/en/draw9_linux/p_styles 1 /usr/doc/graphics9help/en/draw9_linux/p_tran 1 /usr/doc/graphics9help/en/draw9_linux/pop_clr 1 /usr/doc/graphics9help/en/draw9_linux/pop_pdf 1 /usr/doc/graphics9help/en/draw9_linux/pop_prn 26 /usr/doc/graphics9help/en/draw9_linux 1 /usr/doc/graphics9help/en/writingtools9_linux/c_wt_9 1 /usr/doc/graphics9help/en/writingtools9_linux/image 1 /usr/doc/graphics9help/en/writingtools9_linux/wt9en 1 /usr/doc/graphics9help/en/writingtools9_linux/wtpop 5 /usr/doc/graphics9help/en/writingtools9_linux 7782 /usr/doc/graphics9help/en 7783 /usr/doc/graphics9help 4 /usr/doc/graphics9-help 3 /usr/doc/graphics9-paint 3 /usr/doc/libaps 4 /usr/doc/menusupport-redhat-2000.06.20.12.00-1 10 /usr/doc/xforms-0.88.1 7814 /usr/doc ...and when an xfs, it reports: [root@citadel /]# du -k /usr/doc 0 /usr/doc/alsa-lib-0.9.0beta4 192 /usr/doc/graphics9-common 64 /usr/doc/graphics9help/en/paint9_linux/default 3972 /usr/doc/graphics9help/en/paint9_linux/filter80 20432 /usr/doc/graphics9help/en/paint9_linux/glos_com 20428 /usr/doc/graphics9help/en/paint9_linux/image 64 /usr/doc/graphics9help/en/paint9_linux/include 3844 /usr/doc/graphics9help/en/paint9_linux/p_cdrgfx 3140 /usr/doc/graphics9help/en/paint9_linux/p_cdrui 1668 /usr/doc/graphics9help/en/paint9_linux/p_color 1860 /usr/doc/graphics9help/en/paint9_linux/p_conver 772 /usr/doc/graphics9help/en/paint9_linux/p_filter 964 /usr/doc/graphics9help/en/paint9_linux/p_intro 4548 /usr/doc/graphics9help/en/paint9_linux/p_mask 1092 /usr/doc/graphics9help/en/paint9_linux/p_movie 3652 /usr/doc/graphics9help/en/paint9_linux/p_paint 1988 /usr/doc/graphics9help/en/paint9_linux/p_path 1028 /usr/doc/graphics9help/en/paint9_linux/p_pdf 192 /usr/doc/graphics9help/en/paint9_linux/p_record 2820 /usr/doc/graphics9help/en/paint9_linux/p_retouc 7880 /usr/doc/graphics9help/en/paint9_linux/p_specfx 3972 /usr/doc/graphics9help/en/paint9_linux/p_start 4036 /usr/doc/graphics9help/en/paint9_linux/p_textob 452 /usr/doc/graphics9help/en/paint9_linux/p_web 516 /usr/doc/graphics9help/en/paint9_linux/pop_clr 128 /usr/doc/graphics9help/en/paint9_linux/pop_pdf 772 /usr/doc/graphics9help/en/paint9_linux/pop_prn 13900 /usr/doc/graphics9help/en/paint9_linux/poptool 108348 /usr/doc/graphics9help/en/paint9_linux 1668 /usr/doc/graphics9help/en/techsupport_linux/corelts 256 /usr/doc/graphics9help/en/techsupport_linux/image 4936 /usr/doc/graphics9help/en/techsupport_linux 0 /usr/doc/graphics9help/en/draw9_linux/default 0 /usr/doc/graphics9help/en/draw9_linux/drawpop 0 /usr/doc/graphics9help/en/draw9_linux/filter80 0 /usr/doc/graphics9help/en/draw9_linux/glos_com 0 /usr/doc/graphics9help/en/draw9_linux/image 0 /usr/doc/graphics9help/en/draw9_linux/include 0 /usr/doc/graphics9help/en/draw9_linux/p_bitmap 0 /usr/doc/graphics9help/en/draw9_linux/p_cdrgfx 0 /usr/doc/graphics9help/en/draw9_linux/p_cdrtxt 0 /usr/doc/graphics9help/en/draw9_linux/p_cdrui 0 /usr/doc/graphics9help/en/draw9_linux/p_color 0 /usr/doc/graphics9help/en/draw9_linux/p_drwint 0 /usr/doc/graphics9help/en/draw9_linux/p_effect 0 /usr/doc/graphics9help/en/draw9_linux/p_fill 0 /usr/doc/graphics9help/en/draw9_linux/p_filter 0 /usr/doc/graphics9help/en/draw9_linux/p_getsta 0 /usr/doc/graphics9help/en/draw9_linux/p_intern 0 /usr/doc/graphics9help/en/draw9_linux/p_organ 0 /usr/doc/graphics9help/en/draw9_linux/p_pdf 0 /usr/doc/graphics9help/en/draw9_linux/p_shapes 0 /usr/doc/graphics9help/en/draw9_linux/p_styles 0 /usr/doc/graphics9help/en/draw9_linux/p_tran 0 /usr/doc/graphics9help/en/draw9_linux/pop_clr 0 /usr/doc/graphics9help/en/draw9_linux/pop_pdf 0 /usr/doc/graphics9help/en/draw9_linux/pop_prn 4 /usr/doc/graphics9help/en/draw9_linux 0 /usr/doc/graphics9help/en/writingtools9_linux/c_wt_9 0 /usr/doc/graphics9help/en/writingtools9_linux/image 0 /usr/doc/graphics9help/en/writingtools9_linux/wt9en 0 /usr/doc/graphics9help/en/writingtools9_linux/wtpop 0 /usr/doc/graphics9help/en/writingtools9_linux 114060 /usr/doc/graphics9help/en 114060 /usr/doc/graphics9help 192 /usr/doc/graphics9-help 128 /usr/doc/graphics9-paint 128 /usr/doc/libaps 0 /usr/doc/lost+found 128 /usr/doc/menusupport-redhat-2000.06.20.12.00-1 256 /usr/doc/xforms-0.88.1 115088 /usr/doc From owner-linux-xfs@oss.sgi.com Sun Jun 24 07:37:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OEbeb02059 for linux-xfs-outgoing; Sun, 24 Jun 2001 07:37:40 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OEbdV02054 for ; Sun, 24 Jun 2001 07:37:39 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA04091 for ; Sun, 24 Jun 2001 07:34:47 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2224123; Sun, 24 Jun 2001 09:36:21 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA94597; Sun, 24 Jun 2001 09:36:21 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5OEctO11543; Sun, 24 Jun 2001 09:38:55 -0500 Message-Id: <200106241438.f5OEctO11543@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: oe.hansen@gamma.telenordia.se cc: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: Filesystem sizes In-Reply-To: Message from "Orn E. Hansen" of "Sun, 24 Jun 2001 16:32:48 +0200." <01062416324802.01212@citadel.oehansen.pp.se> Content-Transfer-Encoding: 8bit Date: Sun, 24 Jun 2001 09:38:55 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > sunnudagur 24. jznm 2001 16:08, ~z skrifapir: > > > > What size does du report when using it on that dir. > > > > Cheers > > Seth > > The files inside the directories, have the same sizes in both cases... I took > > a peek at some of the directories. An example, is a file inside the > graphics9help/en/paint9_linux/default directory, which is 3150 bytes in size, > > occupying 5k in ext2, but occupying 64k in xfs. The > graphics9help/en/paint9_linux/filter80 contains 62 files, occupies 198k in > ext2. But occupies 3972k (62*64=3968) in xfs. > How did you copy the files into XFS, are you using NFS? and which kernel version are you using? I just did some quick checks and I am not seeing similar behavior. It appears that space preallocated into files on your system is not getting freed when the file closes. XFS presumes you are going to keep writing to a file, so tends to overallocate, but the extra space is supposed to be removed at close time. Also, if you unmount the filesystem, and remount it does the size increase persist? Thanks Steve From owner-linux-xfs@oss.sgi.com Sun Jun 24 07:45:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OEj0w03247 for linux-xfs-outgoing; Sun, 24 Jun 2001 07:45:00 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OEixV03243 for ; Sun, 24 Jun 2001 07:44:59 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id QAA11909; Sun, 24 Jun 2001 16:44:57 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id QAA11928; Sun, 24 Jun 2001 16:44:57 +0200 (CEST) Date: Sun, 24 Jun 2001 16:44:57 +0200 (CEST) From: Seth Mos To: Dirk Steinberg cc: linux-xfs Subject: Re: kiocluster In-Reply-To: <3B35F83B.39E43E35@dirksteinberg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 24 Jun 2001, Dirk Steinberg wrote: > Seth Mos wrote: > > On Sat, 23 Jun 2001, Dirk Steinberg wrote: > > > I remember that some time ago there were mount > > > options for XFS named kio and kiocluster. > > > > > > Inspecting my copy of the XFS CVS tree I was unable > > > to locate these options in the source, so apparently > > > they are gone. > > > > > > Does this mean that the corresponding functionality > > > has been removed, or is this now default? > > > > > > Should kiocluster indeed be enabled by default nowadays, > > > does it work with both SCSI and EIDE, as well as with > > > MD and LVM? > > > > kiocluster is gone and not available untill there is decided what to build > > into the kernel. In this case we are following standard kernels. > > There is probably going to be some form of kiocluster in 2.5 but the > > actual shape has yet to be formed. > > What about kio? I see it's implemented for both SCSI and EIDE. > How about MD and LVM? Should I expect a significant performance > penalty for using XFS on top of LVM or MD instead of running > it directly on the physical disk partition? Same story, MD and LVM produce a light overhead but are not really getting in the way to much. The disk will be the bottleneck. Andyou don't get the possibility to stripe across disk to improve speed/redundancy/space. using software raid or LVM can improve your situation a lot in some cases. Cheers Seth From owner-linux-xfs@oss.sgi.com Sun Jun 24 08:00:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OF0iC05379 for linux-xfs-outgoing; Sun, 24 Jun 2001 08:00:44 -0700 Received: from tux.mkp.net (tux.mkp.net [130.225.60.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OF0gV05376 for ; Sun, 24 Jun 2001 08:00:42 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net) by tux.mkp.net with esmtp (Exim 3.16 #1) id 15EBNK-0007hW-00; Sun, 24 Jun 2001 17:00:34 +0200 Received: (from mkp@localhost) by jcb.mkp.net (8.11.0/8.9.3) id f5OF0VS24575; Sun, 24 Jun 2001 11:00:31 -0400 X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f To: Dirk Steinberg Cc: Seth Mos , linux-xfs Subject: Re: kiocluster References: <3B35F83B.39E43E35@dirksteinberg.de> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 24 Jun 2001 11:00:30 -0400 In-Reply-To: <3B35F83B.39E43E35@dirksteinberg.de> Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Dirk" == Dirk Steinberg writes: Dirk> What about kio? I see it's implemented for both SCSI and EIDE. Dirk> How about MD and LVM? It's implemented for MD RAID1 (by Marcelo) and I implemented it for MD RAID0 + LVM. We decided to pull the kiobuf support from the tree mostly due to all the controversy about it on linux-kernel. However, we still have the patches kicking around so we can adapt them to whatever I/O entity will be agreed upon for 2.5. Dirk> Should I expect a significant performance penalty for using XFS Dirk> on top of LVM or MD instead of running it directly on the Dirk> physical disk partition? Chances are your CPUs are so fast that the overhead is negligible. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Sun Jun 24 09:12:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OGCG012306 for linux-xfs-outgoing; Sun, 24 Jun 2001 09:12:16 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OGCFV12303 for ; Sun, 24 Jun 2001 09:12:15 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id SAA23633; Sun, 24 Jun 2001 18:12:14 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id SAA20845; Sun, 24 Jun 2001 18:12:13 +0200 (CEST) Date: Sun, 24 Jun 2001 18:12:13 +0200 (CEST) From: Seth Mos To: "Orn E. Hansen" cc: linux-xfs@oss.sgi.com Subject: Re: Access control lists In-Reply-To: <01062412392901.01807@citadel.oehansen.pp.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 24 Jun 2001, Orn E. Hansen wrote: > > I don't know if this is relevant, but I'm using linux 2.4.3, compiled with > XFS support. And had a few starting problems, first was that the kernel hung > up on me, if I didn't compile ACL cupport into the kernel along with XFS. > This is not mentioned in the howto. The second, is the use of the acl :-) Maybe the Australia XFS people can comment on this. I believe they understand acls the best in regard to XFS. But It's not quite monday over there yet. Cheers Seth From owner-linux-xfs@oss.sgi.com Sun Jun 24 09:49:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OGnPB12657 for linux-xfs-outgoing; Sun, 24 Jun 2001 09:49:25 -0700 Received: from relay2.flashnet.it (libra.cyb.it [212.11.95.209]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OGnOV12654 for ; Sun, 24 Jun 2001 09:49:24 -0700 Received: from ip098.pool-04.cyb.it (ip098.pool-04.cyb.it [195.191.3.227]) by relay2.flashnet.it (EMS-RELAY/8.10.0) with SMTP id f5OGnDu29403 for ; Sun, 24 Jun 2001 18:49:13 +0200 From: daedalus@freemail.it To: linux-xfs@oss.sgi.com Subject: Re: GCC 3.0 Date: Sun, 24 Jun 2001 18:58:18 +0200 Message-ID: References: <01061905432702.09592@localhost.localdomain> <020d01c0f871$141afdc0$0a01a8c0@den2> <4.3.2.7.2.20010619085055.037b8a18@pop.xs4all.nl> <2d87jtgi85qrqfcc4k9upbg2bi8roapj1f@4ax.com> In-Reply-To: <2d87jtgi85qrqfcc4k9upbg2bi8roapj1f@4ax.com> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5OGnPV12655 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 22 Jun 2001 21:51:59 +0200, daedalus@freemail.it wrote: >linux/kernel/timer.c >linux/include/linux/sched.h Andrea Arcangeli had already answered to a question like mine on the LKML and even before answering he had already put a patch at: ftp.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre2aa2/00_gcc-30-volatile-xtime-1 Do you think it is worth to be merged into patch-2.4.x-xfs-1.0.x-core? From owner-linux-xfs@oss.sgi.com Sun Jun 24 09:59:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OGxmR12843 for linux-xfs-outgoing; Sun, 24 Jun 2001 09:59:48 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OGxmV12840 for ; Sun, 24 Jun 2001 09:59:48 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA03252 for ; Sun, 24 Jun 2001 09:56:55 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA2250219; Sun, 24 Jun 2001 11:58:30 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA85416; Sun, 24 Jun 2001 11:58:30 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5OH12I11944; Sun, 24 Jun 2001 12:01:02 -0500 Message-Id: <200106241701.f5OH12I11944@jen.americas.sgi.com> To: daedalus@freemail.it cc: linux-xfs@oss.sgi.com Subject: Re: GCC 3.0 References: <01061905432702.09592@localhost.localdomain> <020d01c0f871$141afdc0$0a01a8c0@den2> <4.3.2.7.2.20010619085055.037b8a18@pop.xs4all.nl> <2d87jtgi85qrqfcc4k9upbg2bi8roapj1f@4ax.com> Comments: In-reply-to daedalus@freemail.it message dated "Sun, 24 Jun 2001 18:58:18 +0200." Date: Sun, 24 Jun 2001 12:01:02 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Fri, 22 Jun 2001 21:51:59 +0200, daedalus@freemail.it wrote: > > >linux/kernel/timer.c > >linux/include/linux/sched.h > > Andrea Arcangeli had already answered to a question like mine on the > LKML and even before answering he had already put a patch at: > > ftp.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre2aa2/00_gc > c-30-volatile-xtime-1 > > > Do you think it is worth to be merged into patch-2.4.x-xfs-1.0.x-core? I think we will keep the gcc 3.0 changes in the cvs tree, there are other core kernel changes on their way which fix varioug gcc 3.0 things. The cvs tree already being at 2.4.6-pre5 already has some of these. In releasing 1.0.1 we will be very conservative with the compilers we use. Steve From owner-linux-xfs@oss.sgi.com Sun Jun 24 13:33:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OKXMm31129 for linux-xfs-outgoing; Sun, 24 Jun 2001 13:33:22 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OKXLV31118 for ; Sun, 24 Jun 2001 13:33:21 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15EGZA-00047a-00; Mon, 25 Jun 2001 08:33:08 +1200 Date: Mon, 25 Jun 2001 08:33:06 +1200 (NZST) From: Juha Saarinen To: Seth Mos cc: "Orn E. Hansen" , "linux-xfs@oss.sgi.com" Subject: Re: Access control lists In-Reply-To: Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 24 Jun 2001, Seth Mos wrote: > Maybe the Australia XFS people can comment on this. I believe they > understand acls the best in regard to XFS. But It's not quite monday over > there yet. It is now! But those lazy Aussie bludgers haven't got out of bed yet... ;-) -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Sun Jun 24 14:08:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OL8PY04084 for linux-xfs-outgoing; Sun, 24 Jun 2001 14:08:25 -0700 Received: from citadel.oehansen.pp.se (sdu180-201.ppp.algonet.se [195.163.201.180]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OL8MV04081 for ; Sun, 24 Jun 2001 14:08:22 -0700 Received: from citadel.oehansen.pp.se (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f5OKnYO01181; Sun, 24 Jun 2001 22:49:34 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se To: Steve Lord Subject: Re: Filesystem sizes Date: Sun, 24 Jun 2001 22:49:33 +0200 X-Mailer: KMail [version 1.2] References: <200106241438.f5OEctO11543@jen.americas.sgi.com> In-Reply-To: <200106241438.f5OEctO11543@jen.americas.sgi.com> Cc: linux-xfs@oss.sgi.com X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 X-MIME-Autoconverted: from 8bit to quoted-printable by citadel.oehansen.pp.se id f5OKnYO01181 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5OL8OV04082 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk sunnudagur 24. júní 2001 16:38, þú skrifaðir: > > How did you copy the files into XFS, are you using NFS? and which kernel > version are you using? > I'm running redhat 7.1, using a vanilla kernel 2.4.3, with the 2.4.3 core and kernel xfs tarballs. XFS release 1.0. I backup the files, using 'tar -jcf .tar.bz2 ' and untar them in the same way. > I just did some quick checks and I am not seeing similar behavior. It > appears that space preallocated into files on your system is not getting > freed when the file closes. XFS presumes you are going to keep writing to a > file, so tends to overallocate, but the extra space is supposed to be > removed at close time. > > Also, if you unmount the filesystem, and remount it does the size increase > persist? > No, it doesn't persist... but the system is unusable. I unmount the directory, and the moment I remount it... the system hangs up. bad(tm). I need to reboot the system, and it will come up... some hassle as the file systems need to be checked, but the red hat boot script can't handle the xfs system, making me end up checking the file systems manually. After that, I remount the xfs file system and it shows normal sizes.... but after a few minutes of running, the system hangs up again. The same behaviour the kernel had, before I added ACL support into it. The system continues to behave this way... The file system, that contains the tarball, is also an xfs. That file system has only the base directory, and file sizes are normal. The system also works fine with it mounted... Orn From owner-linux-xfs@oss.sgi.com Sun Jun 24 14:36:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OLa7i08475 for linux-xfs-outgoing; Sun, 24 Jun 2001 14:36:07 -0700 Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OLa6V08469 for ; Sun, 24 Jun 2001 14:36:06 -0700 Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:64607 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Sun, 24 Jun 2001 23:36:10 +0200 Message-Id: <4.3.2.7.2.20010624233124.03362320@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 24 Jun 2001 23:34:45 +0200 To: oe.hansen@gamma.telenordia.se, Steve Lord From: Seth Mos Subject: Re: Filesystem sizes Cc: linux-xfs@oss.sgi.com In-Reply-To: <01062422493300.01143@citadel.oehansen.pp.se> References: <200106241438.f5OEctO11543@jen.americas.sgi.com> <200106241438.f5OEctO11543@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5OLa6V08471 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 22:49 24-6-2001 +0200, Orn E. Hansen wrote: >sunnudagur 24. júní 2001 16:38, þú skrifaðir: > > > > How did you copy the files into XFS, are you using NFS? and which kernel > > version are you using? > > > I'm running redhat 7.1, using a vanilla kernel 2.4.3, with the 2.4.3 core >and kernel xfs tarballs. XFS release 1.0. > >I backup the files, using 'tar -jcf .tar.bz2 ' and untar >them in the same way. > > > I just did some quick checks and I am not seeing similar behavior. It > > appears that space preallocated into files on your system is not getting > > freed when the file closes. XFS presumes you are going to keep writing to a > > file, so tends to overallocate, but the extra space is supposed to be > > removed at close time. > > > > Also, if you unmount the filesystem, and remount it does the size increase > > persist? > > > No, it doesn't persist... but the system is unusable. > > I unmount the directory, and the moment I remount it... the system hangs >up. bad(tm). I need to reboot the system, and it will come up... some >hassle as the file systems need to be checked, but the red hat boot script >can't handle the xfs system, making me end up checking the file systems >manually. > > After that, I remount the xfs file system and it shows normal sizes.... > but >after a few minutes of running, the system hangs up again. The same >behaviour the kernel had, before I added ACL support into it. The system >continues to behave this way... > > The file system, that contains the tarball, is also an xfs. That file >system has only the base directory, and file sizes are normal. The system >also works fine with it mounted... This sounds like something going seriously wrong. Can you try the 1.0.1 PR2 test RPMS/tarballs or patches? ftp://oss.sgi.com/projects/xfs/download/testing/Release-1.0.1-PR2 The real 1.0.1 release will be coming along soon which should be a "recommended" upgrade to improve stability. If you can see if those help resolve the problems that would be helpfull. I used the same thing to move my system but I did not see this behaviour. Cheers Seth -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sun Jun 24 15:01:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5OM1SC12350 for linux-xfs-outgoing; Sun, 24 Jun 2001 15:01:28 -0700 Received: from cotse.com (packetderm.cotse.com [216.112.42.58]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5OM1RV12343 for ; Sun, 24 Jun 2001 15:01:27 -0700 Received: (from nobody@localhost) by cotse.com (5.7.4/5.7.4) id f5OLxss10188; Sun, 24 Jun 2001 17:59:54 -0400 (EDT) Received: from Cotse Public Webmail (authenticated user alan) by packetderm.cotse.com with HTTP; Sun, 24 Jun 2001 17:59:54 -0400 (EDT) Message-ID: <6800dd87c5498cd0f41cdac91d72ca6b@public.webmail.cotse.com> Date: Sun, 24 Jun 2001 17:59:54 -0400 (EDT) X-User-Agent: http://www.cotse.com X-Abuse-To: abuse@cotse.com Subject: Other projects From: To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I would like to begin testing xfs with lids (www.lids.org) and rtlinux (www.rtlinux.com) to see if the inclusion of lids will play nicely with xfs, and if both methods of creating acls will be interchangeable (i.e, can lidsadm modify chacl created acl's) and rtlinux, to see if the realtime section's performance could be made truly 'realtime'. I'd like other's thoughts on this, as I am not a programmer, and I can barely read code, so as to tell whether or not these projects would or should work together. The realtime section could also be marked at least 'experimental' in the cvs tree, since it does build quite well, and having to add 'CONFIG_XFS_RT' to .config by hand would be a lot easier if it would just be made a regular (albeit experimental) option. It does work. lmdd is the only program that I have been able to use to open inodes with a realtime flag though (thanks steve lord). Any input on this would be greatly appreciated. Thanks, -alan P.S: I know that GRIO is not a real possibility for 2.4, but is it being thought of as a 2.5 kernel subject at least? From owner-linux-xfs@oss.sgi.com Sun Jun 24 16:13:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5ONDvU23212 for linux-xfs-outgoing; Sun, 24 Jun 2001 16:13:57 -0700 Received: from femail13.sdc1.sfba.home.com (femail13.sdc1.sfba.home.com [24.0.95.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5ONDuV23209 for ; Sun, 24 Jun 2001 16:13:56 -0700 Received: from eclipse ([65.4.56.167]) by femail13.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010624231351.GMYN26767.femail13.sdc1.sfba.home.com@eclipse> for ; Sun, 24 Jun 2001 16:13:51 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Micah Yoder To: linux-xfs@oss.sgi.com Subject: Update Date: Sun, 24 Jun 2001 16:14:48 -0400 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01062416144800.01155@eclipse> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, I'm the one that had the hang and minor FS corruption a couple weeks ago, on an Abit VP6 motherboard. I upgraded to the CVS snapshot from Tuesday the 12th, and everything seems to be working great ever since. It had one reboot since then, due to the co-lo guys moving it to a different cage. The process that gave me trouble last time (by hanging inkillable and hogging 99% of a CPU, and locking me out of its log dir) has been running for over a week now. No additional trouble. Of course, the box has pretty close to zero load currently. If you wanna stress test it, see my sig. :-) I guess I should probably upgrade again at some point -- perhaps when 2.4.6 final is out and you have a good, tested XFS patch against it. -- Like to travel? http://TravTalk.org Micah Yoder Internet Development http://yoderdev.com From owner-linux-xfs@oss.sgi.com Sun Jun 24 20:45:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5P3j4j15169 for linux-xfs-outgoing; Sun, 24 Jun 2001 20:45:04 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5P3j2V15161 for ; Sun, 24 Jun 2001 20:45:02 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA00341 for ; Sun, 24 Jun 2001 20:44:56 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA07683; Mon, 25 Jun 2001 13:43:40 +1000 (EST) Date: Mon, 25 Jun 2001 13:43:40 +1000 From: Timothy Shimmin To: "Orn E. Hansen" , Seth Mos , Juha Saarinen , Jan-Frode Myklebust Cc: linux-xfs@oss.sgi.com Subject: Re: Access control lists Message-ID: <20010625134340.F280523@boing.melbourne.sgi.com> References: <01062412392901.01807@citadel.oehansen.pp.se> <20010624135750.A20895@ii.uib.no> <01062412392901.01807@citadel.oehansen.pp.se> <01062412392901.01807@citadel.oehansen.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 1.0us In-Reply-To: <01062412392901.01807@citadel.oehansen.pp.se>; from oe.hansen@gamma.telenordia.se on Sun, Jun 24, 2001 at 12:39:29PM +0200 X-MIME-Autoconverted: from 8bit to quoted-printable by deliverator.sgi.com id UAA00341 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5P3j3V15162 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Orn, On Sun, Jun 24, 2001 at 12:39:29PM +0200, Orn E. Hansen wrote: > > I don't know if this is relevant, but I'm using linux 2.4.3, compiled with > XFS support. And had a few starting problems, first was that the kernel hung > up on me, if I didn't compile ACL cupport into the kernel along with XFS. > This is not mentioned in the howto. Probably because it should work. How exactly did you create your XFS kernel ? > The second, is the use of the acl :-) > I've got the XFS file system mounted under /opt/xfs ... and then I've got > the following file in that directory: > -rw-r--r-- 1 root root 46 Jún 24 12:16 testing > It's parent directory looks like this: > drwxrwxrwx 2 root root 20 Jún 24 12:16 xfs > Anybody can write to the directory... now the acl of the file testing looks > like this: > /opt/xfs/testing [] > And then another user logs in, and edits the file with 'vi' and writes with > ':w!' this is what it looks like after that ordeal: > -rw-r--r-- 1 asta users 21 Jún 24 12:27 testing > Then I try setting access control... to see if its the missing acl that is > the problem. > /opt/xfs/testing [u::rw-,g::r--,o::r--,u:oehansen:rw-,m::r--] > and make root the owner again... and again, the user asta tries to edit the > file: > -rw-r--r-- 1 asta users 29 Jún 24 12:32 /opt/xfs/testing > I think this is a major concern... > Sincerely, > Orn Jan-Frode answered this well. On Sun, Jun 24, 2001 at 01:57:50PM +0200, Jan-Frode Myklebust wrote: > > And then another user logs in, and edits the file with 'vi' and writes with > > ':w!' this is what it looks like after that ordeal: > > > > I believe 'vi' overrides the file permissions by > deleting and creating a new file, which is allowed > by the directory permission. Try it on a ext2 > filesystem, and you should get the same results. Try using something simpler than vi, such as touch or echo blah >file they won't work as the file is not deleted prior to attempting to write to it. On Mon, Jun 25, 2001 at 08:33:06AM +1200, Juha Saarinen wrote: > On Sun, 24 Jun 2001, Seth Mos wrote: > > > Maybe the Australia XFS people can comment on this. I believe they > > understand acls the best in regard to XFS. But It's not quite monday over > > there yet. > > It is now! But those lazy Aussie bludgers haven't got out of bed yet... > ;-) :) I doesn't often pay to reply too quickly to emails, otherwise you miss out on other's replying, such as Jan-Frode ! :) BTW, a question for you, Juha: Q: What is a Hindu ? A: It lays eggs, eh. ;-) Cheers, Tim. From owner-linux-xfs@oss.sgi.com Sun Jun 24 21:01:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5P41t016344 for linux-xfs-outgoing; Sun, 24 Jun 2001 21:01:55 -0700 Received: from shell.izap.com (root@shell.izap.com [207.211.45.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5P41tV16341 for ; Sun, 24 Jun 2001 21:01:55 -0700 Received: from shell.izap.com ([207.211.45.10]:13545 "EHLO shell.izap.com") by izap.com with ESMTP id ; Sun, 24 Jun 2001 21:01:43 -0700 Date: Sun, 24 Jun 2001 21:01:33 -0700 (PDT) From: Dusan X-Sender: dusan@shell.izap.com To: linux-xfs@oss.sgi.com Subject: /dev/sound Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk i recently tried xfs rh7.1 installer, and it seem to me that there are two problems first during boot there's attempt to do fstab entry for cdrom /hdc and the file already exists. second no matter what, it looks to me that sound doesn't work for anybody but root there's another problem with keyboard lockups after exit from xsessions and troubles accessing serial devices. d From owner-linux-xfs@oss.sgi.com Sun Jun 24 21:11:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5P4BVM17062 for linux-xfs-outgoing; Sun, 24 Jun 2001 21:11:31 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5P4BUV17059 for ; Sun, 24 Jun 2001 21:11:30 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA05911 for ; Sun, 24 Jun 2001 21:08:39 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id VAA13479; Sun, 24 Jun 2001 21:10:57 -0700 (PDT) Message-ID: <3B36B942.EA68B99A@sgi.com> Date: Sun, 24 Jun 2001 23:08:34 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Dusan CC: linux-xfs@oss.sgi.com Subject: Re: /dev/sound References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dusan wrote: > first during boot there's attempt to do fstab entry for cdrom /hdc > and the file already exists. Yep, that's a funky red-hat-ism, it's harmless. You can take "updfstab" out of the initscripts if it annoys you too much. > second no matter what, it looks to me that sound doesn't work for anybody > but root That's due to devfs permissions, you can enable permissions persistence in devfsd to get around it if you'd like. > there's another problem with keyboard lockups after exit from xsessions > and troubles accessing serial devices. Ok, that's a new one, I have not heard of this problem before. (Although serial device problems may be devfs releated, as well). Have you checked Red Hat's bugzilla regarding keyboard lockups, or have you run standard RH 7.1 on this same machine? It doesn't look XFS related at first glance. You might want to try the Release-1.0.1 testing RPMs under the /testing directory on the FTP site, they have quite a few updates since the 1.0 release. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sun Jun 24 21:32:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5P4W8X18390 for linux-xfs-outgoing; Sun, 24 Jun 2001 21:32:08 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5P4W6V18383 for ; Sun, 24 Jun 2001 21:32:07 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5P4Vr304514; Mon, 25 Jun 2001 00:31:53 -0400 Date: Mon, 25 Jun 2001 00:31:53 -0400 From: Alan Eldridge To: Dusan Cc: linux-xfs@oss.sgi.com Subject: Re: /dev/sound Message-ID: <20010625003153.A4433@wwweasel.geeksrus.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dusan@palka.com on Sun, Jun 24, 2001 at 09:01:33PM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk WARNING. HEAV:Y SARCASM AHEAD. It's late, and these are things that bit me and generally annoyed the crap out of me when I ws getting 7.1 up and running. These things are *not* the fault of the SGI dudes! It's the kernel interface from hell... yes, it's (shield your kid's eyes, folks, you don't want them to see this) DEVFS. On Sun, Jun 24, 2001 at 09:01:33PM -0700, Dusan wrote: >i recently tried xfs rh7.1 installer, and it seem to me that there are two >problems >first during boot there's attempt to do fstab entry for cdrom /hdc >and the file already exists. If it's what I think it is, this is some RedHat drain-bamage, hiding in the "kudzu" hardware registry startup ... just put your cdrom mount points into /etc/fstab yourself, like: /dev/cdrom /mnt/cdrom iso9660 noauto,owner,ro 0 0 /dev/cdrom1 /mnt/cdrom1 iso9660 noauto,owner,ro 0 0 and don't worry about it, the error is harmless. It's a *devfs* thing. But you do need some devfsd magic ... aaah, devfs, you either hate it or you hate it. # Manage CD burners too : #REGISTER ^cdroms/cdrom. EXECUTE /bin/ln -sf $devname . ^^^ comment this one out vvv and add these (only use cdrom1 if you got it) # ...and /dev/cdrom # In case no cdrom modules loaded, point link over to /dev/cdroms/cdrom? LOOKUP cdrom EXECUTE /bin/ln -sf cdroms/cdrom0 cdrom LOOKUP cdrom1 EXECUTE /bin/ln -sf cdroms/cdrom1 cdrom1 # Similarly, if the module loaded, create the /dev/cdrom link REGISTER cdroms/cdrom0 EXECUTE /bin/ln -sf cdroms/cdrom0 cdrom REGISTER cdroms/cdrom1 EXECUTE /bin/ln -sf cdroms/cdrom1 cdrom1 >second no matter what, it looks to me that sound doesn't work for anybody >but root Dunno if this is your problem, but ... More RH weirdness ... put the line "options sound dmabuf=1" in /etc/modules.conf, just like that, spaces, not tabs. to force loading of sound modules at boot. Yup. It's a MAGIC MODULE OPTION! Don't get too close to it; it sucks harder than most small black holes. >there's another problem with keyboard lockups after exit from xsessions >and troubles accessing serial devices. Keyboard lockups? You got a USB keyboard? Devices... like serial ports... well, you gotta set perms on these things.... devfs will do its best to save them across boots in /dev-state unless it gets alzheimers, in which case .... set 'em to 664 or 660 and make yourself a member of the group holding the device; or set 'em to 666 if nobody else uses the box and it's preferebly not on a network... note also that if your cdrom drivers are modules (i've got scsi, so mine are), then they can get unloaded. and i don't care what devfsd is *supposed* to do, be prepared for an open to fail with ENODEV or ENOENT while the driver gets loaded again. this happens regularly to me and i haven't got it tracked down yet. ive been thinking about rewriting devfsd in python so its comprehensible. OK, thanks for listening. I feel *MUCH* better. Hope this rant helps you out. -- Alan Eldridge "Smart Tags? We don't need no steenking Smart Tags!" From owner-linux-xfs@oss.sgi.com Sun Jun 24 21:37:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5P4btF18884 for linux-xfs-outgoing; Sun, 24 Jun 2001 21:37:55 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5P4bsV18881 for ; Sun, 24 Jun 2001 21:37:54 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15EO8D-0000ep-00; Mon, 25 Jun 2001 16:37:49 +1200 Date: Mon, 25 Jun 2001 16:37:49 +1200 (NZST) From: Juha Saarinen To: Eric Sandeen cc: Dusan , "linux-xfs@oss.sgi.com" Subject: Re: /dev/sound In-Reply-To: <3B36B942.EA68B99A@sgi.com> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 24 Jun 2001, Eric Sandeen wrote: > > there's another problem with keyboard lockups after exit from xsessions > > and troubles accessing serial devices. > > Ok, that's a new one, I have not heard of this problem before. > (Although serial device problems may be devfs releated, as well). Have > you checked Red Hat's bugzilla regarding keyboard lockups, or have you > run standard RH 7.1 on this same machine? It doesn't look XFS related > at first glance. No, the k/b lock-up isn't XFS related. Seen it here a couple of time with an Ext2fs RH 7.1 box. Could be XF86 4-related, but since nothing gets entered into the logs, it's kind of hard to figure out... -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Sun Jun 24 21:45:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5P4j1019437 for linux-xfs-outgoing; Sun, 24 Jun 2001 21:45:01 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5P4j0V19432 for ; Sun, 24 Jun 2001 21:45:00 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA08252 for ; Sun, 24 Jun 2001 21:42:09 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id VAA17222; Sun, 24 Jun 2001 21:44:27 -0700 (PDT) Message-ID: <3B36C11C.A46B60F3@sgi.com> Date: Sun, 24 Jun 2001 23:42:04 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Alan Eldridge CC: Dusan , linux-xfs@oss.sgi.com Subject: Re: /dev/sound References: <20010625003153.A4433@wwweasel.geeksrus.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alan Eldridge wrote: > > These things are *not* the fault of the SGI dudes! Well, it WAS our (ill-advised?) decision to enable devfs in our RPMs... FWIW, in the 1.0.1 testing RPMs, devfs is enabled, but NOT mounted by default. That way you can edit lilo.conf to get devfs if you want it, otherwise you get your good old familiar 10,000-entry inode-eating on-disk /dev. And maybe we'll be able to stop talking about devfs on this list in 6 months or so. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sun Jun 24 21:52:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5P4qc620005 for linux-xfs-outgoing; Sun, 24 Jun 2001 21:52:38 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5P4qbV19999 for ; Sun, 24 Jun 2001 21:52:37 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5P4qVs04924 for linux-xfs@oss.sgi.com; Mon, 25 Jun 2001 00:52:31 -0400 Date: Mon, 25 Jun 2001 00:52:31 -0400 From: Alan Eldridge To: linux-xfs@oss.sgi.com Subject: One other deadly RH weirdness Message-ID: <20010625005231.A4884@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Since I just ranted on devfs oddities, I figure I'll let you guys know about this non-devfs thing so you don't go nuts if it bites you... In a reboot or halt script, do *not* use the words "daemon" or "action", not even in a comment. If you do, the script will get run in a subshell of /etc/rc, rather than being exec'd. This will result in the halt or reboot script having a file open on /usr, with the consequence that .... [drum roll, please] ... the halt script will kill itself trying to free up /usr so it can unmount it! This is actually a bit more twisted... the halt scripts are exec'd after cleaning out any references to locales in the environment. So that's the killer.... it's run in a subshell, so it has locale refs, so it holds a file on /usr, and, well... blammo! The rest of the story: you have to modify the halt script if you use the Network UPS Tools package (a great UPS daemon). I have a UPS. So, being a nice programmer, I commented the addition with "tell UPS daemon to kill the power". Words fail me at this point. -- Alan Eldridge "Smart Tags? We don't need no steenking Smart Tags!" From owner-linux-xfs@oss.sgi.com Sun Jun 24 22:04:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5P54xM20909 for linux-xfs-outgoing; Sun, 24 Jun 2001 22:04:59 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5P54vV20904 for ; Sun, 24 Jun 2001 22:04:58 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15EOYI-0000hX-00; Mon, 25 Jun 2001 17:04:46 +1200 Date: Mon, 25 Jun 2001 17:04:46 +1200 (NZST) From: Juha Saarinen To: Alan Eldridge cc: "linux-xfs@oss.sgi.com" Subject: Re: One other deadly RH weirdness In-Reply-To: <20010625005231.A4884@wwweasel.geeksrus.net> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alan, You should post this one on the RH Seawolf list, and Bugzilla it. On Mon, 25 Jun 2001, Alan Eldridge wrote: > Since I just ranted on devfs oddities, I figure I'll let you guys know about > this non-devfs thing so you don't go nuts if it bites you... > > In a reboot or halt script, do *not* use the words "daemon" or "action", not > even in a comment. If you do, the script will get run in a subshell of > /etc/rc, rather than being exec'd. This will result in the halt or reboot > script having a file open on /usr, with the consequence that .... [drum > roll, please] ... the halt script will kill itself trying to free up /usr so > it can unmount it! > > This is actually a bit more twisted... the halt scripts are exec'd after > cleaning out any references to locales in the environment. So that's the > killer.... it's run in a subshell, so it has locale refs, so it holds a file > on /usr, and, well... blammo! > > The rest of the story: you have to modify the halt script if you use the > Network UPS Tools package (a great UPS daemon). I have a UPS. So, being a > nice programmer, I commented the addition with "tell UPS daemon to kill the > power". Words fail me at this point. > > -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Sun Jun 24 22:32:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5P5W2X23206 for linux-xfs-outgoing; Sun, 24 Jun 2001 22:32:02 -0700 Received: from blipvert.blank.org (blipvert.blank.org [216.112.239.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5P5W1V23203 for ; Sun, 24 Jun 2001 22:32:01 -0700 Received: (qmail 24190 invoked by uid 500); 25 Jun 2001 05:32:00 -0000 Date: Mon, 25 Jun 2001 01:31:59 -0400 From: "Nathan J. Mehl" To: Eric Sandeen Cc: Dusan , linux-xfs@oss.sgi.com Subject: Re: /dev/sound Message-ID: <20010625013159.L8330@blank.org> References: <3B36B942.EA68B99A@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B36B942.EA68B99A@sgi.com>; from sandeen@sgi.com on Sun, Jun 24, 2001 at 11:08:34PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In the immortal words of Eric Sandeen (sandeen@sgi.com): > Dusan wrote: > > > first during boot there's attempt to do fstab entry for cdrom /hdc > > and the file already exists. > > Yep, that's a funky red-hat-ism, it's harmless. You can take "updfstab" > out of the initscripts if it annoys you too much. Actually, it's not entirely harmless -- unless updfstab runs at least once, you won't get an fstab entry created for your cdrom device, which is kinda aggravating for people who like to do weird things like install software or play music. :-) After poking around a bit, I found that there's no way to make it work as redhat seems to want it to. (I say "seems" because updfstab is completely undocumented other than the source code.) You have to do it by hand. The following command, run as root, will probably do the right thing: /usr/sbin/updfstab --test | grep cdrom >> /etc/fstab (I'm sorry, I don't remember the specifics of why manually appending from the --test output worked while the actual command didn't -- it was some sort of chicken-vs-egg deal.) -n ------------------------------------------------------ Don't blame me -- I voted for the Unabomber! ---------------------------------------------- From owner-linux-xfs@oss.sgi.com Sun Jun 24 22:51:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5P5pLO24987 for linux-xfs-outgoing; Sun, 24 Jun 2001 22:51:21 -0700 Received: from blipvert.blank.org (blipvert.blank.org [216.112.239.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5P5pJV24982 for ; Sun, 24 Jun 2001 22:51:19 -0700 Received: (qmail 24269 invoked by uid 500); 25 Jun 2001 05:51:18 -0000 Date: Mon, 25 Jun 2001 01:51:17 -0400 From: "Nathan J. Mehl" To: Alan Eldridge Cc: Dusan , linux-xfs@oss.sgi.com Subject: Re: /dev/sound Message-ID: <20010625015117.M8330@blank.org> References: <20010625003153.A4433@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010625003153.A4433@wwweasel.geeksrus.net>; from alane@geeksrus.net on Mon, Jun 25, 2001 at 12:31:53AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In the immortal words of Alan Eldridge (alane@geeksrus.net): > WARNING. HEAV:Y SARCASM AHEAD. It's late, and these are things that bit me > and generally annoyed the crap out of me when I ws getting 7.1 up and > running. These things are *not* the fault of the SGI dudes! It's the kernel > interface from hell... yes, it's (shield your kid's eyes, folks, you don't > want them to see this) DEVFS. Eh. Devfs itself is fine. Coming from a solaris background, it's nice to see one of the free unices catch up and join the mid-90s. Of course, it would be even nicer if devfs' namespace in some way corresponded to the bios' view of the system bus (a la OpenBoot), but we can't really hold Richard Gooch responsible for lousy design decisions made by IBM ~15 years ago... It's the transition issues that are currently biting everyone right now. Devfsd is a step in the right direction, but it could be a lot better, both in implementation and documentation. (Well, and "/dev-state" is an atrocity...) I suspect that a lot of the pain will Go Away once (well, if) one of the "big three" distributions (redhat/suse/debian) take the leap and enable it for their next release. What devfs/devfsd need more than anything else now is a solid run through an organized QA cycle. In that respect I'm grateful to SGI for sneaking it into the XFS 1.0 release -- the archives of this list will provide good starting material for whoever wants to make their distribution work with it. (Hint hint, redhat lurkers. :) > vvv and add these (only use cdrom1 if you got it) > > # ...and /dev/cdrom > # In case no cdrom modules loaded, point link over to /dev/cdroms/cdrom? > LOOKUP cdrom EXECUTE /bin/ln -sf cdroms/cdrom0 cdrom > LOOKUP cdrom1 EXECUTE /bin/ln -sf cdroms/cdrom1 cdrom1 > # Similarly, if the module loaded, create the /dev/cdrom link > REGISTER cdroms/cdrom0 EXECUTE /bin/ln -sf cdroms/cdrom0 cdrom > REGISTER cdroms/cdrom1 EXECUTE /bin/ln -sf cdroms/cdrom1 cdrom1 Addendum: if one of your cdrom devices is a CD-R[W] that you're managing under the ide-scsi module in order to use with xcdroast, you'll probably want to add the following as well: LOOKUP scd0 EXECUTE /bin/ln -sf cdroms/cdrom0 scd0 -n ------------------------------------------------------------ no plans / I'll go where the machine goes / the past is a placebo / dissolving in a drain / I'll sleep beside the railroad tracks / with no more rent or income tax / I got no fixed address now / I'm waiting for a train. (--Firewater, "So Long Superman") ---------------------------------------------------- From owner-linux-xfs@oss.sgi.com Sun Jun 24 23:10:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5P6API27792 for linux-xfs-outgoing; Sun, 24 Jun 2001 23:10:25 -0700 Received: from nationalcontractors.com (nationalcontractors.com [207.173.117.117]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5P6AMV27783 for ; Sun, 24 Jun 2001 23:10:23 -0700 Received: from w2kpro01 (ppp-206-170-210-20.lsan03.pacbell.net [206.170.210.20]) by nationalcontractors.com (8.9.3/8.9.3) with SMTP id XAA78315 for ; Sun, 24 Jun 2001 23:14:56 -0700 (MST) (envelope-from stuart@bh90210.net) Reply-To: From: "IT3 Stuart B. Tener, USNR-R" To: Subject: Date: Sun, 24 Jun 2001 23:10:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0003_01C0FD02.D5701BF0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C0FD02.D5701BF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit List members: I am currently using the ext2fs under RH7.1 running kernel 2.4.2-2. I am considering the implementation of either the SGI XFS or ReiserFS journaling file system ("JFS"), I plan to try XFS first. One of the issues I am concerned with in the implementation of either, is if it will allow (a) "on the fly compression"; and (b) "on the fly encryption". Now, I am aware of software which operates on a file by file level to do either of those (gzip, or crypt (crude for encryption I know but a good example), but I am talking about encryption or compression on a filesystem level. I was told that using the loopback filesystem additional layers of filesystem can be added to yield these sorts of "on the fly" additions. Predicated on a choice of either JFS (XFS or ReiserFS, I know there is also ext3fs, but it doesn't really work yet I hear), what are the best methods to assure on the fly compression and also encryption of the highest order of magnitude. Thank you for your time and consideration in advance. Very Respectfully, Stuart Blake Tener, IT3, USNR-R, N3GWG VTU 1904G (Volunteer Training Unit) stuart@bh90210.net west coast: (310)-358-0202 P.O. Box 16043, Beverly Hills, CA 90209-2043 east coast: (215)-338-6005 P.O. Box 45859, Philadelphia, PA 19149-5859 Telecopier: (419)-715-6073 fax to email gateway via www.efax.com (it's free!) JOIN THE US NAVY RESERVE, SERVE YOUR COUNTRY, AND BENEFIT FROM IT ALL. Sunday, June 24, 2001 11:08 PM From owner-linux-xfs@oss.sgi.com Mon Jun 25 00:49:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5P7ndC08161 for linux-xfs-outgoing; Mon, 25 Jun 2001 00:49:39 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5P7nbV08158 for ; Mon, 25 Jun 2001 00:49:37 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id JAA02225; Mon, 25 Jun 2001 09:49:16 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id JAA02942; Mon, 25 Jun 2001 09:49:16 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 432A357306; Mon, 25 Jun 2001 09:58:03 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 21D8325835; Mon, 25 Jun 2001 10:06:16 +0200 (CEST) Message-ID: <3B36EDB3.138AA66D@ch.sauter-bc.com> Date: Mon, 25 Jun 2001 09:52:19 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Seth Mos Cc: oe.hansen@gamma.telenordia.se, Steve Lord , linux-xfs@oss.sgi.com Subject: Re: Filesystem sizes References: <200106241438.f5OEctO11543@jen.americas.sgi.com> <200106241438.f5OEctO11543@jen.americas.sgi.com> <4.3.2.7.2.20010624233124.03362320@pop.xs4all.nl> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by relay.xlink.net id JAA02225 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5P7ncV08159 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Stupid question: do you have enough swap space configured? Last time when I did migration of filesystems with tar, I was running out of mem because of no swap configured. I was doing the same without XFS before without any problems. Seth Mos schrieb: > > At 22:49 24-6-2001 +0200, Orn E. Hansen wrote: > >sunnudagur 24. júní 2001 16:38, þú skrifaðir: > > > > > > How did you copy the files into XFS, are you using NFS? and which kernel > > > version are you using? > > > > > I'm running redhat 7.1, using a vanilla kernel 2.4.3, with the 2.4.3 core > >and kernel xfs tarballs. XFS release 1.0. > > > >I backup the files, using 'tar -jcf .tar.bz2 ' and untar > >them in the same way. > > > > > I just did some quick checks and I am not seeing similar behavior. It > > > appears that space preallocated into files on your system is not getting > > > freed when the file closes. XFS presumes you are going to keep writing to a > > > file, so tends to overallocate, but the extra space is supposed to be > > > removed at close time. > > > > > > Also, if you unmount the filesystem, and remount it does the size increase > > > persist? > > > > > No, it doesn't persist... but the system is unusable. > > > > I unmount the directory, and the moment I remount it... the system hangs > >up. bad(tm). I need to reboot the system, and it will come up... some > >hassle as the file systems need to be checked, but the red hat boot script > >can't handle the xfs system, making me end up checking the file systems > >manually. > > > > After that, I remount the xfs file system and it shows normal sizes.... > > but > >after a few minutes of running, the system hangs up again. The same > >behaviour the kernel had, before I added ACL support into it. The system > >continues to behave this way... > > > > The file system, that contains the tarball, is also an xfs. That file > >system has only the base directory, and file sizes are normal. The system > >also works fine with it mounted... > > This sounds like something going seriously wrong. Can you try the 1.0.1 PR2 > test RPMS/tarballs or patches? > ftp://oss.sgi.com/projects/xfs/download/testing/Release-1.0.1-PR2 > The real 1.0.1 release will be coming along soon which should be a > "recommended" upgrade to improve stability. > > If you can see if those help resolve the problems that would be helpfull. > I used the same thing to move my system but I did not see this behaviour. > > Cheers > Seth > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. -- 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 Mon Jun 25 02:37:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5P9bvE20256 for linux-xfs-outgoing; Mon, 25 Jun 2001 02:37:57 -0700 Received: from rebel.net.au (IDENT:root@www.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5P9bpV20246 for ; Mon, 25 Jun 2001 02:37:55 -0700 Received: from rebel.net.au (dialup-3.rebel.net.au [203.20.69.73]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id TAA01783 for ; Mon, 25 Jun 2001 19:07:51 +0930 Message-ID: <3B370640.A7CFE5BC@rebel.net.au> Date: Mon, 25 Jun 2001 19:07:04 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Undelete Functions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hmmmm... It strikes me that it would be easier to implement an undelete function using a journalling filesystem than not. I theorise that if you logged what you'd deleted, then a [relatively speaking] simple reverse run of the relevant log entries _might_ get you your file back. Pseudo Code would be: 1) extract from the log where foo file actually was 2) forcibly lock all those blocks/cylinders or whatever 3) put it back together 4) write foo_file somewhere else Naturally because of the nature of the cached writing system and such it's not a guaranteed thing, but it would be better than having to wander around the file system following inodes etc manually... DSL -- "And the winner is InUnifiedCanadianAboriginalSyllabics" - Larry Wall et al in Programming Perl From owner-linux-xfs@oss.sgi.com Mon Jun 25 04:35:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PBZ7H28318 for linux-xfs-outgoing; Mon, 25 Jun 2001 04:35:07 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PBZ6V28315 for ; Mon, 25 Jun 2001 04:35:06 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id EAA05262 for ; Mon, 25 Jun 2001 04:35:00 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA2255062; Mon, 25 Jun 2001 06:32:42 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA82160; Mon, 25 Jun 2001 06:32:42 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5PBZ7C13201; Mon, 25 Jun 2001 06:35:07 -0500 Message-Id: <200106251135.f5PBZ7C13201@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: David Lloyd cc: linux-xfs@oss.sgi.com Subject: Re: Undelete Functions In-Reply-To: Message from David Lloyd of "Mon, 25 Jun 2001 19:07:04 +0930." <3B370640.A7CFE5BC@rebel.net.au> Date: Mon, 25 Jun 2001 06:35:07 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Not really, log space is a circular buffer, and can be over written as soon as the metadata itself has gone to disk. The file data itself is also not protected against reuse. On a busy system the log can wrap several times a second. Steve > > Hmmmm... > > It strikes me that it would be easier to implement an undelete function > using a journalling filesystem than not. I theorise that if you logged > what you'd deleted, then a [relatively speaking] simple reverse run of > the relevant log entries _might_ get you your file back. > > Pseudo Code would be: > > 1) extract from the log where foo file actually was > 2) forcibly lock all those blocks/cylinders or whatever > 3) put it back together > 4) write foo_file somewhere else > > Naturally because of the nature of the cached writing system and such > it's not a guaranteed thing, but it would be better than having to > wander around the file system following inodes etc manually... > > DSL > -- > "And the winner is > InUnifiedCanadianAboriginalSyllabics" > - Larry Wall et al in Programming Perl From owner-linux-xfs@oss.sgi.com Mon Jun 25 04:41:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PBf7q28522 for linux-xfs-outgoing; Mon, 25 Jun 2001 04:41:07 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PBf7V28519 for ; Mon, 25 Jun 2001 04:41:07 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id EAA06420 for ; Mon, 25 Jun 2001 04:38:15 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA2248542; Mon, 25 Jun 2001 06:39:49 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA10967; Mon, 25 Jun 2001 06:39:49 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5PBgEZ13246; Mon, 25 Jun 2001 06:42:14 -0500 Message-Id: <200106251142.f5PBgEZ13246@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Micah Yoder cc: linux-xfs@oss.sgi.com Subject: Re: Update In-Reply-To: Message from Micah Yoder of "Sun, 24 Jun 2001 16:14:48 EDT." <01062416144800.01155@eclipse> Date: Mon, 25 Jun 2001 06:42:14 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ah ha, so if we ignore problems they just get fixed! No seriously, thanks for the update. Steve > Hi all, > > I'm the one that had the hang and minor FS corruption a couple weeks ago, on > an Abit VP6 motherboard. > > I upgraded to the CVS snapshot from Tuesday the 12th, and everything seems to > > be working great ever since. It had one reboot since then, due to the co-lo > guys moving it to a different cage. > > The process that gave me trouble last time (by hanging inkillable and hogging > > 99% of a CPU, and locking me out of its log dir) has been running for over a > week now. No additional trouble. > > Of course, the box has pretty close to zero load currently. If you wanna > stress test it, see my sig. :-) > > I guess I should probably upgrade again at some point -- perhaps when 2.4.6 > final is out and you have a good, tested XFS patch against it. > -- > Like to travel? http://TravTalk.org > Micah Yoder Internet Development http://yoderdev.com From owner-linux-xfs@oss.sgi.com Mon Jun 25 04:52:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PBqNA28844 for linux-xfs-outgoing; Mon, 25 Jun 2001 04:52:23 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PBqKV28839 for ; Mon, 25 Jun 2001 04:52:20 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id NAA153006 for ; Mon, 25 Jun 2001 13:52:14 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA2252093; Mon, 25 Jun 2001 06:50:56 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA44040; Mon, 25 Jun 2001 06:50:56 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5PBrKe13306; Mon, 25 Jun 2001 06:53:20 -0500 Message-Id: <200106251153.f5PBrKe13306@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: stuart@bh90210.net cc: linux-xfs@oss.sgi.com In-Reply-To: Message from "IT3 Stuart B. Tener, USNR-R" of "Sun, 24 Jun 2001 23:10:17 PDT." Date: Mon, 25 Jun 2001 06:53:20 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > List members: > > I am currently using the ext2fs under RH7.1 running kernel 2.4.2-2. > I am considering the implementation of either the SGI XFS or ReiserFS > journaling file system ("JFS"), I plan to try XFS first. One of the issues I > am concerned with in the implementation of either, is if it will allow (a) > "on the fly compression"; and (b) "on the fly encryption". Now, I am aware > of software which operates on a file by file level to do either of those > (gzip, or crypt (crude for encryption I know but a good example), but I am > talking about encryption or compression on a filesystem level. I was told > that using the loopback filesystem additional layers of filesystem can be > added to yield these sorts of "on the fly" additions. > > Predicated on a choice of either JFS (XFS or ReiserFS, I know there > is also ext3fs, but it doesn't really work yet I hear), what are the best > methods to assure on the fly compression and also encryption of the highest > order of magnitude. None of these filesystems directly support encryption or compression, but they can all use the loop device which does have some support for encryption at least. Look at the manpage for losetup. There may be optional extensions to the loop device for better encryption and compression, you will probably get better answers by asking this question on the linux kernel mailing list. One caveat on this is that the loop device pretends to be a block device under the filesystem and talks to some underlying storage which is either a file, or another block device. In the case of a file then the data coming out the back end of the loop device is just written into that file's memory, and flushing to disk is going to happen later. This will DESTROY the ordering constraints required by journalling filesystems and probably result in filesystems which are corrupted after recovery. I am not so sure what happens with loop over a block device, but I would recommend you do extensive testing before relying on something like this. Steve > > Thank you for your time and consideration in advance. > > > Very Respectfully, > > Stuart Blake Tener, IT3, USNR-R, N3GWG From owner-linux-xfs@oss.sgi.com Mon Jun 25 04:57:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PBvAq29010 for linux-xfs-outgoing; Mon, 25 Jun 2001 04:57:10 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PBv7V29007 for ; Mon, 25 Jun 2001 04:57:07 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id NAA153466 for ; Mon, 25 Jun 2001 13:57:04 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA2253332; Mon, 25 Jun 2001 06:55:47 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA49990; Mon, 25 Jun 2001 06:55:46 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5PBwBw13359; Mon, 25 Jun 2001 06:58:11 -0500 Message-Id: <200106251158.f5PBwBw13359@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Seth Mos cc: oe.hansen@gamma.telenordia.se, Steve Lord , linux-xfs@oss.sgi.com Subject: Re: Filesystem sizes In-Reply-To: Message from Seth Mos of "Sun, 24 Jun 2001 23:34:45 +0200." <4.3.2.7.2.20010624233124.03362320@pop.xs4all.nl> Content-Transfer-Encoding: 8bit Date: Mon, 25 Jun 2001 06:58:11 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I would concur with Seth, please try a later kernel, the rpms he refers to should help. We did at one point see problems similar to those you describe with file sizes, but that was a long time ago, probably before 2.4 came out. Steve Seth Mos wrote: > > This sounds like something going seriously wrong. Can you try the 1.0.1 PR2 > test RPMS/tarballs or patches? > ftp://oss.sgi.com/projects/xfs/download/testing/Release-1.0.1-PR2 > The real 1.0.1 release will be coming along soon which should be a > "recommended" upgrade to improve stability. > > If you can see if those help resolve the problems that would be helpfull. > I used the same thing to move my system but I did not see this behaviour. > > Cheers > Seth > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Jun 25 05:25:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PCPvE29577 for linux-xfs-outgoing; Mon, 25 Jun 2001 05:25:57 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PCPuV29574 for ; Mon, 25 Jun 2001 05:25:56 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15EVQt-0000tR-00; Tue, 26 Jun 2001 00:25:35 +1200 Date: Tue, 26 Jun 2001 00:25:34 +1200 (NZST) From: Juha Saarinen To: Steve Lord cc: "stuart@bh90210.net" , "linux-xfs@oss.sgi.com" Subject: Re: your mail In-Reply-To: <200106251153.f5PBrKe13306@jen.americas.sgi.com> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 25 Jun 2001, Steve Lord wrote: > None of these filesystems directly support encryption or compression, Hmmm... hate to say this, but for that, you would need to go with NTFS 5, AFAIK. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Mon Jun 25 05:47:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PClmJ29998 for linux-xfs-outgoing; Mon, 25 Jun 2001 05:47:48 -0700 Received: from rebel.net.au (IDENT:root@rebel.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PCljV29995 for ; Mon, 25 Jun 2001 05:47:46 -0700 Received: from rebel.net.au (dialup-3.rebel.net.au [203.20.69.73]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id WAA06730 for ; Mon, 25 Jun 2001 22:17:43 +0930 Message-ID: <3B3732C3.76E797B0@rebel.net.au> Date: Mon, 25 Jun 2001 22:16:59 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: RedHat 7.1 (XFS 1.0) + OpenOffice 627 or 625 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Has anyone noticed whether OpenOffice runs extraordinarily slowly under that combination? It's not a fast program by all means, but it seems to have really slowed down since I installed RH 7.1/XFS by SGI et al... DSL -- "And the winner is InUnifiedCanadianAboriginalSyllabics" - Larry Wall et al in Programming Perl From owner-linux-xfs@oss.sgi.com Mon Jun 25 05:53:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PCr2Q30163 for linux-xfs-outgoing; Mon, 25 Jun 2001 05:53:02 -0700 Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PCr1V30160 for ; Mon, 25 Jun 2001 05:53:01 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id 47DD6139A4; Mon, 25 Jun 2001 08:53:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id 3F8E4139A3 for ; Mon, 25 Jun 2001 08:53:03 -0400 (EDT) Date: Mon, 25 Jun 2001 08:53:03 -0400 (EDT) From: Mike Burger To: "linux-xfs@oss.sgi.com" Subject: Re: your mail In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk How is one supposed to embark upon a journey of NTFS5 under Linux. There are additional encryption and compression packages out there that will run under Linux...though I don't, as a rule, recommend running compression utilities on a hard drive. On Tue, 26 Jun 2001, Juha Saarinen wrote: > On Mon, 25 Jun 2001, Steve Lord wrote: > > > None of these filesystems directly support encryption or compression, > > Hmmm... hate to say this, but for that, you would need to go with NTFS 5, > AFAIK. > > > From owner-linux-xfs@oss.sgi.com Mon Jun 25 06:11:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PDBw030389 for linux-xfs-outgoing; Mon, 25 Jun 2001 06:11:58 -0700 Received: from algonet.se (sinclair.tninet.se [195.100.94.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PDBvV30386 for ; Mon, 25 Jun 2001 06:11:57 -0700 Received: from CITADEL (sdu27-202.ppp.algonet.se [195.163.202.27]) by sinclair.tninet.se (BLUETAIL Mail Robustifier 2.2.2) with ESMTP id 256015.474698.993sinclair-s2 ; Mon, 25 Jun 2001 15:11:38 +0200 Message-ID: <005a01c0fd67$d8305980$0101a8c0@CITADEL> From: "Örn E. Hansen" To: "Timothy Shimmin" , "Seth Mos" , "Juha Saarinen" , "Jan-Frode Myklebust" Cc: References: <01062412392901.01807@citadel.oehansen.pp.se> <20010624135750.A20895@ii.uib.no> <01062412392901.01807@citadel.oehansen.pp.se> <01062412392901.01807@citadel.oehansen.pp.se> <20010625134340.F280523@boing.melbourne.sgi.com> Subject: Re: Access control lists Date: Mon, 25 Jun 2001 13:13:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.5600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [snip] > > Jan-Frode answered this well. > Yes, he did... What I was looking for, was the thing that 'vi' can delete a file, with access control... when it doesn't have write permission for it. That kinda took me by surprise :-) Orn From owner-linux-xfs@oss.sgi.com Mon Jun 25 07:29:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PETSi31577 for linux-xfs-outgoing; Mon, 25 Jun 2001 07:29:28 -0700 Received: from citadel.oehansen.pp.se (sdu239-234.ppp.algonet.se [195.163.234.239]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PETPV31574 for ; Mon, 25 Jun 2001 07:29:26 -0700 Received: from citadel.oehansen.pp.se (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f5PEUSW01399; Mon, 25 Jun 2001 16:30:28 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se To: Seth Mos , oe.hansen@gamma.telenordia.se, Steve Lord Subject: Re: Filesystem sizes Date: Mon, 25 Jun 2001 16:30:28 +0200 X-Mailer: KMail [version 1.2] Cc: linux-xfs@oss.sgi.com References: <200106241438.f5OEctO11543@jen.americas.sgi.com> <4.3.2.7.2.20010624233124.03362320@pop.xs4all.nl> In-Reply-To: <4.3.2.7.2.20010624233124.03362320@pop.xs4all.nl> X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk As suggested, I checked out the swap and memory space on my system. My setup is a 700MHz cpu, 128Mb of ram and equal swap space. The 'free' command shows, that there are approximately 100Mb in use, and an equal amount of swap space unused. I built the kernel in the following manner.... Untar the linux 2.4.3 kernel tree... enter that directory. zcat /linux-2.4.3-core.patch.gz | patch -p1 zcat /linux-xfs-patch.gz | patch -p1 make xconfig { enabled entities are: athlon, ne2k network card, parallel port, usb, busmouse,nfs v3, server v3,automount,ppp async/sync,i2c,video, ntfs (read only),udf,ufs,reiser fs,xfs,advanced partitions,xfs partition, sound,acl support } make dep make bzImage { put the arch/i386/boot/bzImage into the /boot and edit lilo etc :-) } cp System.map /boot/System.map- and symlink. reboot. into the new kernel. side note on compile: GCC that comes with RedHat 7.1, does not work for compiling the XFS kernel, as it will break on compiling the XFS code for anything except i386. The setup also uses kgcc to compile the kernel, which is provided with compat-egcs, which compiles the kernel ok. Other kernel modules are added, such as Alsa and Nvidia, but I don't think they effect this. The same thing as above, was done for the redhat 2.4.2-2 kernel. But that time, the xfs core file for that RH kernel was used, along with the linux-xfs patch, to alter the kernel. This kernel behaves the same way as the vanilla 2.4.3 one. This time, I'm using the 1.0.1 tree of XFS on kernel 2.4.5 (vanilla), and without ACL compiled into the kernel. It works well, no problems and the kernel is far more stable than the 1.0 one. No hangups yet, whatsoever. But the differences in sizes of the filesystem after the data has been untarred onto it, persists. But the sizes are not constant this time, rather vary each time I do it. After I unmount and remount the drive, the size is fixed to normal (well, a little larger than ext2fs, but that is due to difference in block sizes,etc). Orn From owner-linux-xfs@oss.sgi.com Mon Jun 25 07:53:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PErEg32024 for linux-xfs-outgoing; Mon, 25 Jun 2001 07:53:14 -0700 Received: from mail.spylog.com (mail.spylog.com [194.67.35.220]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PErDV32021 for ; Mon, 25 Jun 2001 07:53:13 -0700 Received: from an.local (an.local [192.168.4.50]) by mail.spylog.com (Postfix) with ESMTP id 507422C555; Mon, 25 Jun 2001 18:53:06 +0400 (MSD) Received: by an.local (Postfix, from userid 506) id 2992B50532; Mon, 25 Jun 2001 18:53:03 +0400 (MSD) Received: from localhost (localhost.localdomain [127.0.0.1]) by an.local (Postfix) with ESMTP id 7DA7950534 for ; Mon, 25 Jun 2001 18:53:02 +0400 (MSD) X-Sieve: cmu-sieve 2.0 Received: from suse.local [192.168.4.39] by localhost with IMAP (fetchmail-5.8.2) for andy@localhost (single-drop); Mon, 25 Jun 2001 18:53:02 +0400 (MSD) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by mail.spylog.com (Postfix) with ESMTP id 9CDBD2C555 for ; Mon, 25 Jun 2001 18:30:33 +0400 (MSD) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PETmr31615; Mon, 25 Jun 2001 07:29:48 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Mon, 25 Jun 2001 07:29:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PETSi31577 for linux-xfs-outgoing; Mon, 25 Jun 2001 07:29:28 -0700 Received: from citadel.oehansen.pp.se (sdu239-234.ppp.algonet.se [195.163.234.239]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PETPV31574 for ; Mon, 25 Jun 2001 07:29:26 -0700 Received: from citadel.oehansen.pp.se (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f5PEUSW01399; Mon, 25 Jun 2001 16:30:28 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se To: Seth Mos , oe.hansen@gamma.telenordia.se, Steve Lord Subject: Re: Filesystem sizes Date: Mon, 25 Jun 2001 16:30:28 +0200 X-Mailer: KMail [version 1.2] Cc: linux-xfs@oss.sgi.com References: <200106241438.f5OEctO11543@jen.americas.sgi.com> <4.3.2.7.2.20010624233124.03362320@pop.xs4all.nl> In-Reply-To: <4.3.2.7.2.20010624233124.03362320@pop.xs4all.nl> X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk As suggested, I checked out the swap and memory space on my system. My setup is a 700MHz cpu, 128Mb of ram and equal swap space. The 'free' command shows, that there are approximately 100Mb in use, and an equal amount of swap space unused. I built the kernel in the following manner.... Untar the linux 2.4.3 kernel tree... enter that directory. zcat /linux-2.4.3-core.patch.gz | patch -p1 zcat /linux-xfs-patch.gz | patch -p1 make xconfig { enabled entities are: athlon, ne2k network card, parallel port, usb, busmouse,nfs v3, server v3,automount,ppp async/sync,i2c,video, ntfs (read only),udf,ufs,reiser fs,xfs,advanced partitions,xfs partition, sound,acl support } make dep make bzImage { put the arch/i386/boot/bzImage into the /boot and edit lilo etc :-) } cp System.map /boot/System.map- and symlink. reboot. into the new kernel. side note on compile: GCC that comes with RedHat 7.1, does not work for compiling the XFS kernel, as it will break on compiling the XFS code for anything except i386. The setup also uses kgcc to compile the kernel, which is provided with compat-egcs, which compiles the kernel ok. Other kernel modules are added, such as Alsa and Nvidia, but I don't think they effect this. The same thing as above, was done for the redhat 2.4.2-2 kernel. But that time, the xfs core file for that RH kernel was used, along with the linux-xfs patch, to alter the kernel. This kernel behaves the same way as the vanilla 2.4.3 one. This time, I'm using the 1.0.1 tree of XFS on kernel 2.4.5 (vanilla), and without ACL compiled into the kernel. It works well, no problems and the kernel is far more stable than the 1.0 one. No hangups yet, whatsoever. But the differences in sizes of the filesystem after the data has been untarred onto it, persists. But the sizes are not constant this time, rather vary each time I do it. After I unmount and remount the drive, the size is fixed to normal (well, a little larger than ext2fs, but that is due to difference in block sizes,etc). Orn From owner-linux-xfs@oss.sgi.com Mon Jun 25 08:01:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PF1ag32353 for linux-xfs-outgoing; Mon, 25 Jun 2001 08:01:36 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PF1YV32350 for ; Mon, 25 Jun 2001 08:01:34 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id RAA171469 for ; Mon, 25 Jun 2001 17:01:29 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2254925 for ; Mon, 25 Jun 2001 10:00:13 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA75287 for ; Mon, 25 Jun 2001 10:00:12 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f5PF2aF15740; Mon, 25 Jun 2001 10:02:36 -0500 Message-Id: <200106251502.f5PF2aF15740@jen.americas.sgi.com> Date: Mon, 25 Jun 2001 10:02:36 -0500 Subject: TAKE - remove printk from realtime allocator Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Every realtime allocate was coming out on the console. Date: Mon Jun 25 07:59:32 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:97596a linux/fs/xfs/xfs_rtalloc.c - 1.66 - Remove very chatty print message from realtime allocator. From owner-linux-xfs@oss.sgi.com Mon Jun 25 08:04:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PF4YP32469 for linux-xfs-outgoing; Mon, 25 Jun 2001 08:04:34 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PF4PV32465 for ; Mon, 25 Jun 2001 08:04:25 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id RAA174633 for ; Mon, 25 Jun 2001 17:04:22 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2251383; Mon, 25 Jun 2001 10:03:06 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA36798; Mon, 25 Jun 2001 10:03:05 -0500 (CDT) Message-ID: <3B375281.191EA9E6@sgi.com> Date: Mon, 25 Jun 2001 10:02:25 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Simon Matter CC: linux-xfs@oss.sgi.com Subject: Re: /dev/sound References: <20010625003153.A4433@wwweasel.geeksrus.net> <3B36C11C.A46B60F3@sgi.com> <3B36F1C3.7CDBB608@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter wrote: > > I remember tha I ran into one problem that I didn't expext. The devfs > RPM on the installer CD has a different /etc/modules.devfs file than the > updated RPM's from oss.sgi.com. I just wondered why the system behaved > strange after upgrading the kernel and found that downgrading the devfs > RPM resolved my problem. Yep, the 1.0 release had a stand-alone devfsd that was adapted from a Mandrake package. The Red Hat kernel RPM build spits out it's own devfsd package, which I mistakenly copied out for the first test release. You'll notice that it's missing from the 2nd test release (PR2), for the reason you mentioned above - we'll just stick with the original devfsd package from 1.0. -Eric From owner-linux-xfs@oss.sgi.com Mon Jun 25 08:05:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PF59v32573 for linux-xfs-outgoing; Mon, 25 Jun 2001 08:05:09 -0700 Received: from mail.spylog.com (mail.spylog.com [194.67.35.220]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PF58V32569 for ; Mon, 25 Jun 2001 08:05:08 -0700 Received: from an.local (an.local [192.168.4.50]) by mail.spylog.com (Postfix) with ESMTP id 07ED32C55E; Mon, 25 Jun 2001 19:05:02 +0400 (MSD) Received: by an.local (Postfix, from userid 506) id BDE5050532; Mon, 25 Jun 2001 19:05:01 +0400 (MSD) Received: from localhost (localhost.localdomain [127.0.0.1]) by an.local (Postfix) with ESMTP id 1CFA750532 for ; Mon, 25 Jun 2001 19:05:01 +0400 (MSD) X-Sieve: cmu-sieve 2.0 Received: from suse.local [192.168.4.39] by localhost with IMAP (fetchmail-5.8.2) for andy@localhost (single-drop); Mon, 25 Jun 2001 19:05:01 +0400 (MSD) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by mail.spylog.com (Postfix) with ESMTP id 3E3552C55E for ; Mon, 25 Jun 2001 19:04:53 +0400 (MSD) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PF4dM32514; Mon, 25 Jun 2001 08:04:39 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Mon, 25 Jun 2001 08:04:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PF4YP32469 for linux-xfs-outgoing; Mon, 25 Jun 2001 08:04:34 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PF4PV32465 for ; Mon, 25 Jun 2001 08:04:25 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id RAA174633 for ; Mon, 25 Jun 2001 17:04:22 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2251383; Mon, 25 Jun 2001 10:03:06 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA36798; Mon, 25 Jun 2001 10:03:05 -0500 (CDT) Message-ID: <3B375281.191EA9E6@sgi.com> Date: Mon, 25 Jun 2001 10:02:25 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Simon Matter Cc: linux-xfs@oss.sgi.com Subject: Re: /dev/sound References: <20010625003153.A4433@wwweasel.geeksrus.net> <3B36C11C.A46B60F3@sgi.com> <3B36F1C3.7CDBB608@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter wrote: > > I remember tha I ran into one problem that I didn't expext. The devfs > RPM on the installer CD has a different /etc/modules.devfs file than the > updated RPM's from oss.sgi.com. I just wondered why the system behaved > strange after upgrading the kernel and found that downgrading the devfs > RPM resolved my problem. Yep, the 1.0 release had a stand-alone devfsd that was adapted from a Mandrake package. The Red Hat kernel RPM build spits out it's own devfsd package, which I mistakenly copied out for the first test release. You'll notice that it's missing from the 2nd test release (PR2), for the reason you mentioned above - we'll just stick with the original devfsd package from 1.0. -Eric From owner-linux-xfs@oss.sgi.com Mon Jun 25 08:25:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PFPsm00579 for linux-xfs-outgoing; Mon, 25 Jun 2001 08:25:54 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PFPrV00576 for ; Mon, 25 Jun 2001 08:25:53 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA09597 for ; Mon, 25 Jun 2001 08:23:02 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2252826; Mon, 25 Jun 2001 10:24:32 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA65102; Mon, 25 Jun 2001 10:24:32 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5PFQuu15808; Mon, 25 Jun 2001 10:26:56 -0500 Message-Id: <200106251526.f5PFQuu15808@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: oe.hansen@gamma.telenordia.se cc: linux-xfs@oss.sgi.com Subject: Re: Filesystem sizes In-Reply-To: Message from "Orn E. Hansen" of "Mon, 25 Jun 2001 16:30:28 +0200." <01062516302800.01265@citadel.oehansen.pp.se> Date: Mon, 25 Jun 2001 10:26:55 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > As suggested, I checked out the swap and memory space on my system. My > setup is a 700MHz cpu, 128Mb of ram and equal swap space. The 'free' command > > shows, that there are approximately 100Mb in use, and an equal amount of swap > > space unused. > > I built the kernel in the following manner.... > > Untar the linux 2.4.3 kernel tree... enter that directory. > zcat /linux-2.4.3-core.patch.gz | patch -p1 > zcat /linux-xfs-patch.gz | patch -p1 > make xconfig > { > enabled entities are: athlon, ne2k network card, parallel port, usb, > busmouse,nfs v3, server v3,automount,ppp async/sync,i2c,video, > ntfs (read only),udf,ufs,reiser fs,xfs,advanced partitions,xfs partition, > sound,acl support > } > make dep > make bzImage > { put the arch/i386/boot/bzImage into the /boot and edit lilo etc :-) } > cp System.map /boot/System.map- and symlink. > reboot. into the new kernel. > > side note on compile: GCC that comes with RedHat 7.1, does not work > for compiling the XFS kernel, as it will > break on compiling the XFS code for anything > except i386. The setup also uses kgcc to > compile the kernel, which is provided with > compat-egcs, which compiles the kernel ok. > > Other kernel modules are added, such as Alsa and Nvidia, but I don't think > they effect this. The same thing as above, was done for the redhat 2.4.2-2 > kernel. But that time, the xfs core file for that RH kernel was used, along > with the linux-xfs patch, to alter the kernel. This kernel behaves the same > way as the vanilla 2.4.3 one. > > This time, I'm using the 1.0.1 tree of XFS on kernel 2.4.5 (vanilla), and > without ACL compiled into the kernel. It works well, no problems and the > kernel is far more stable than the 1.0 one. No hangups yet, whatsoever. But > > the differences in sizes of the filesystem after the data has been untarred > onto it, persists. But the sizes are not constant this time, rather vary > each time I do it. After I unmount and remount the drive, the size is fixed > to normal (well, a little larger than ext2fs, but that is due to difference > in block sizes,etc). > Hmm, I tried untaring the linux kernel (I am pretty sure Linus is not using xfs to create these...) the end result was as expected, the files come out the correct size, du reports sizes as expected. df reports free space as expected. Can you provide an example ls -lsR of part of the tree from ext2 and xfs, can you also run xfs_bmap -v -v on one of the files which appears larger than it should be. Also, do you have quotas enabled and are you accessing the filesystem via NFS at any point? Steve > > > Orn From owner-linux-xfs@oss.sgi.com Mon Jun 25 09:08:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PG8Uv01522 for linux-xfs-outgoing; Mon, 25 Jun 2001 09:08:30 -0700 Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PG8TV01519 for ; Mon, 25 Jun 2001 09:08:29 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f5PG7e852118; Mon, 25 Jun 2001 11:07:47 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <3B3761CB.3F83945A@thebarn.com> Date: Mon, 25 Jun 2001 11:07:39 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Nathan J. Mehl" CC: Alan Eldridge , Dusan , linux-xfs@oss.sgi.com Subject: Re: /dev/sound References: <20010625003153.A4433@wwweasel.geeksrus.net> <20010625015117.M8330@blank.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Nathan J. Mehl" wrote: > In the immortal words of Alan Eldridge (alane@geeksrus.net): > > WARNING. HEAV:Y SARCASM AHEAD. It's late, and these are things that bit me > > and generally annoyed the crap out of me when I ws getting 7.1 up and > > running. These things are *not* the fault of the SGI dudes! It's the kernel > > interface from hell... yes, it's (shield your kid's eyes, folks, you don't > > want them to see this) DEVFS. > > Eh. Devfs itself is fine. Coming from a solaris background, it's > nice to see one of the free unices catch up and join the mid-90s. Right with you on this one. > Of > course, it would be even nicer if devfs' namespace in some way > corresponded to the bios' view of the system bus (a la OpenBoot), but > we can't really hold Richard Gooch responsible for lousy design > decisions made by IBM ~15 years ago... It always amazes me how sometimes the worst designs are the most popular, guess money does really talk or in this case what cost less talks. > I suspect that a lot of the pain will Go Away once (well, if) one of > the "big three" distributions (redhat/suse/debian) take the leap and > enable it for their next release. What devfs/devfsd need more than > anything else now is a solid run through an organized QA cycle. In > that respect I'm grateful to SGI for sneaking it into the XFS 1.0 > release -- the archives of this list will provide good starting > material for whoever wants to make their distribution work with it. > (Hint hint, redhat lurkers. :) This is right on! while devfs isn't necessary for XFS it will be crucial in the future for salability and the management of large disk farms. I made the decision for XFS 1.0 to enable devfs by default knowing very well that many apps would have issues. But given that none of the distributions are working to clean up apps to be devfs friendly this seemed like a good test bed to smoke out some of the problems. In retrospect it was a bit of a headache to deal with since every devfs question came our way rather than to the devfs lists. What is apparent at this time, most people do not have large disk farms and as such can work quite comfortably in the current but horribly broken device naming scheme. The current plan (and I think Eric already did this) is to enable devfs but not have it mount on /dev by default. This will allow for mounting either on /dev or some other mount point such as /devfs but only as an option. Hopefully one of the big distros will bit the bullet and start fixing the apps that are not devfs friendly. -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Mon Jun 25 09:29:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PGTpS01844 for linux-xfs-outgoing; Mon, 25 Jun 2001 09:29:51 -0700 Received: from vortex.nsstc.uah.edu (vortex.nsstc.uah.edu [192.67.108.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PGToV01841 for ; Mon, 25 Jun 2001 09:29:50 -0700 Received: from nsstc.uah.edu (ceres.nsstc.uah.edu [192.67.108.72]) by vortex.nsstc.uah.edu (8.9.3/8.8.7) with ESMTP id LAA15154; Mon, 25 Jun 2001 11:29:43 -0500 Message-ID: <3B3766F7.449B6499@nsstc.uah.edu> Date: Mon, 25 Jun 2001 11:29:43 -0500 From: Todd Berendes Organization: University of Alabama in Huntsville X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com, Denise Berendes Subject: New Redhat 7.1 kernel patch Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Just last week Red Hat released a kernel patch which fixes a bunch of fairly major problems. We need that patch primarily to fix the IRIX NFS server bug #36897. ( http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=36897 ) We have already installed the SGI XFS installer disk on our systems and do not want to undo any of that by installing Red Hat's patch. Someone has already released an NFS patched XFS installer disk at ftp://ftp.crc.dk/pub/rh71irixnfspatch with a "use at own risk" warning. Are you planning to release an update of your installer and patch RPM's using the new patched kernel anytime soon? Any idea when the XFS patches will be integrated into the standard kernel and/or when RedHat will ship it? We were very happy to find XFS available for Linux. We have a number of SGI's using XFS and have been very pleased with the filesystem. Keep up the good work! Thanks, Todd -- ********************************************* Todd Berendes Research Scientist National Space Science & Technology Center University of Alabama in Huntsville 320 Sparkman Drive Huntsville, AL 35805 (256) 961-7943 fax:(256) 961-7755 todd@nsstc.uah.edu ********************************************* From owner-linux-xfs@oss.sgi.com Mon Jun 25 10:31:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PHVBQ03052 for linux-xfs-outgoing; Mon, 25 Jun 2001 10:31:11 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PHVAV03049 for ; Mon, 25 Jun 2001 10:31:10 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA17013 for ; Mon, 25 Jun 2001 10:30:59 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2255144; Mon, 25 Jun 2001 12:29:29 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA44720; Mon, 25 Jun 2001 12:29:29 -0500 (CDT) Message-ID: <3B3774D0.7B812B77@sgi.com> Date: Mon, 25 Jun 2001 12:28:48 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Todd Berendes CC: linux-xfs@oss.sgi.com, Denise Berendes Subject: Re: New Redhat 7.1 kernel patch References: <3B3766F7.449B6499@nsstc.uah.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Todd Berendes wrote: > Are you planning to release an update of your installer and patch > RPM's using the new patched kernel anytime soon? Yep, working on it as we speak... for the 1.0.1 release. -Eric From owner-linux-xfs@oss.sgi.com Mon Jun 25 12:18:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PJIPi04830 for linux-xfs-outgoing; Mon, 25 Jun 2001 12:18:25 -0700 Received: from citadel.oehansen.pp.se (sdu81-234.ppp.algonet.se [195.163.234.81]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PJHkV04808 for ; Mon, 25 Jun 2001 12:17:46 -0700 Received: from citadel.oehansen.pp.se (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f5PJFOc02315; Mon, 25 Jun 2001 21:15:24 +0200 Content-Type: Multipart/Mixed; charset="iso-8859-1"; boundary="------------Boundary-00=_NT2I35W7KT0YHATO3893" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se To: Steve Lord , oe.hansen@gamma.telenordia.se Subject: Re: Filesystem sizes Date: Mon, 25 Jun 2001 21:15:23 +0200 X-Mailer: KMail [version 1.2] Cc: linux-xfs@oss.sgi.com References: <200106251526.f5PFQuu15808@jen.americas.sgi.com> In-Reply-To: <200106251526.f5PFQuu15808@jen.americas.sgi.com> X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --------------Boundary-00=_NT2I35W7KT0YHATO3893 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by citadel.oehansen.pp.se id f5PJFOc02315 m=E1nudagur 25. j=FAn=ED 2001 17:26, Steve Lord skrifa=F0i: > > Hmm, I tried untaring the linux kernel (I am pretty sure Linus is not > using xfs to create these...) the end result was as expected, the files > come out the correct size, du reports sizes as expected. df reports fre= e > space as expected. > > Can you provide an example ls -lsR of part of the tree from ext2 and xf= s, > can you also run xfs_bmap -v -v on one of the files which appears large= r > than it should be. > > Also, do you have quotas enabled and are you accessing the filesystem v= ia > NFS at any point? > No, NFS is not active at this moment... I take this one step at a time. Ok, I did what you requested and took ls -lsR of the /usr/doc dir, in t= hree=20 different situation. The bziped output is attached to this email. Doing= the=20 requested bmap command, reveals: [root@citadel oehansen]# xfs_bmap -v -v /usr/doc xfs_bmap: fsgeo.agblocks=3D10542, fsgeo.blocksize=3D4096, fsgeo.agcount=3D= 8 xfs_bmap: fsx.dsx_xflags=3D0, fsx.fsx_extsize=3D0, fsx.fsx_nextents=3D1 xfs_bmap: i=3D0 map.bmv_offset=3D8, map.bmv_block=3D0, map.bmv_length=3D0= ,=20 map.bmv_count=3D32, map.bmv_entries=3D1 /usr/doc: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..7]: 4032..4039 0 (4032..4039) 8 And now, a small revelation... the 1.0.1 does *fix* this, but only afte= r a=20 minute (timeout?). Here are two listings, taken a minute apart from each= =20 other. No other operation is taking place inbetween... [root@citadel oehansen]# df Filesystem 1k-blocks Used Available Use% Mounted on [snip] /dev/hdb13 332532 17596 314936 6% /usr/doc [root@citadel oehansen]# df Filesystem 1k-blocks Used Available Use% Mounted on [snip] /dev/hdb13 332532 10856 321676 4% /usr/doc Orn --------------Boundary-00=_NT2I35W7KT0YHATO3893 Content-Type: application/x-bzip2; charset="iso-8859-1"; name="xfs.dir.bz2" Content-Description: The file system, after untar... Content-Disposition: attachment; filename="xfs.dir.bz2" Content-Transfer-Encoding: base64 QlpoOTFBWSZTWU7CR2IAedlfge/QQAv/8T8SEAC////wAAIAEGAvvu9l8MQd8AAAAAMcfAaAAAAM 943HPffQ0sffHejYb75efPHxKfHmcFxx9rWZ512tbm47LubtHbuwjsAX1b6GgPrlaGnV2670alSq mRd93cYfTRKVL7udzHczq993k9Xtrk7aJbDOxDVPBABAEAJoRQ0AIB6noGp5BkqkUhowAmAJgAEw ANT0ARCEBT9UxD1NpAAMEABKekiMiaJRop6m1MhoxAAAAAiSITJHkRk0RtCTEJtINGmQ08oESJAB BE1BGKeo00AGQABw0FQFE4cD9CAP8fr9X+cRL2olP0xP9lvnnlTpf6/uF+Pv+E+/28st7fdvroi/ GO3kfOK7hDpP22G2jt0g6J/p7PP+CYvq/Mzt7/ouJ9uNUVyhX0hQsRISp7tbFhPpBC8BKgiEg2gs gKBIoyAISKDIImMaigSAwghI1X2SIpSiqCIiFZY0tVhLuUoJIpIAcRVG4qVDEBqJrFzio6QFZFMo CBcQTWKDiBpEBxAQkKgrpEUxBArVM4BIW70aZ0GxRrmYj80XZRAgGREESoKBtM+sAXISZ0anOumZ Rxj4WDhu1Mu7P5Kgb/zAQ6iIiAB+AAKjiECCsiocwAUFxBQoiCCjcFDNoery56/T6WBFvABLrGLw igg56wnyUUIqIxfpYUr89fD9wc7SEPvss6orDhBAUtWylBQ/u/aoG4KGa+KbSBDmEh1ZZ4wWGCKK AtZYXAIgLeIen/3C2XWLjISGnVlqKiMISKRhLkgUrOv0j8H9/JQmyDhEI54fkIE1DuXDFNsFqqEE 2WhzN0HUtLE9yVvqGzrldKIoQYGOHCxAh7R6xg4QWCEK9vZkErrV66d8sJHYRktdkhqPK4I0hrit Odfp23aMeTtbrZLbhq+rpV1Dtt7xd6+FWo0QjnXgqwRHz7Zsa0Uc58edIZUY7t1ceigfqD0mrOxi Zl7ncN3aa3End95nZMAt0TxrmzWd3IHcLb2d1xUlkmDQn2MCXTaMKNYQ47xNQbKiGdKVrMvXqPXv XyYgOTDlx9e8uIpXKDruVO3mVqwIvstdl9jrA2D2ZDXNHCj1dwYpjs6o7tWG+uOdUpoGjur2X09V lrSZSdLjuDq4j8OW+nxazh2VQVtb1T4euqzntk6Kl86DNz0vY2QxHkNTuUubLYqadYnlFWDUhZpm r42ZmZDpNYvS2sQ0N45eZmu0epuz0pVBARlDkrolKuu+S4vZylTLVLL0yhypO82UV44KtI2fdhrW OdJ872+J7JvIyxPVnGtc3r6wqnZL7u3FSuatU5bxwY615XA8a8B7j4C01WZpJq6cqxTSotWjunYR Rrbq9vm8LhpWVBVGF5gvcrMroF28cOzqgtckKLvuq1ubg7NOlT1gsVig5YcF21D0qep83ReO1o2H aCxhtLb4mjQy4VWNnezrx36ducsl1EnkXVA4dlHtvrIaSsF9Q1ZHtqQdSW5VdO3AbF6hNfaaRnbx MmbfY6lvONQqEY7zbuFkPDp4dWzL6uZ06qyyqWnCNt2LOLMIJNVrD5X1ECbSdU+48Wz1y8OtO67q fAngcRuCCSTBBycpl5zOtXBJikx8lAct8zZ3CK7T2uZwh8tamje26WJraRnJ7KvzHcbjwWRt4K3Y cxPLubdI1SirXKeng3tYt6Yr09d09Fbl5cElPdp12SqW7nHLIcfG7dTnu63lnJ3dpC3he1sVO4HW bu3MMtN64pBNL0Zl71n1Abm5posKhN6TaMtInmz1m6WbQyqT3nBaLmHcBwu9rMKKtaazit3fWoHi G5U9WdqOVuvgTldtZdysS9WN4vSa6aUXk3FAkFBdoA7QESvVANRARLKoFCVSKClyS4IhaGsVEFNq EM4b65K2QEUITOUyS1JRFXIEHOZxUUvHdA7zoiCo+AiCo+ZyMD+DE704h8CGaIKj9UQVHAwBBUdA UDYzMjssWK4GogH4/9A6jIIVPe4///+jvH8uUeHGca/vfT93T3yl9w/G44f2sOiRgKcr5Fq5v29b T0/b80H3+/blxn867bkOm/FN91pRzyPdOv6N35hR8W7CAcDECFg8QDBwrQ3Y9btstfXEnXaOXnT9 OnTzTl57Rss/27W0dv39y2e/wP3CHTmZ8jFAWcbEnTqeaJ1KRrDV4ny8pXiGhPLnUT+ay2laNs77 CC8CmN/I2yf2JI9KByOYU124yyJICOEUSRhPScod3+Max8wdqXBS2syg77c2YUZxrsbMxhSw7kJR ZG1SKiSSOeOOmMJ8euO8vHjnL52zy019+ufXxrnjtEUE2YK1nJ1CTNDCFO3jsgKmk5q1SAdqeBm2 k8D0yB+PhlzGcfFwzTLp2avc+TtIY/N2j40zdlBYwHdIyY2yXvyklnCdo7dMaP66Xoo0LIvGPtO/ BjbkmaqhplmjVd41VsyuQ8v7460tQbXltD4f5KE0zyj5rXOVoCed6faY62QVhBK9XG6U4ttDIhdR 2cYXP1z1s4iz9eU1JuXNL8bz4k4cM5N0OzvFetH85lH4e28/aHQn6Z9keZ3iUqpqtzjRdTrrLLbh bWcNTy8b6RLTGEec/T/rKL3a+ERCLW2pbNOT38uWXxSI6+Oc7G0OUoyzd700opZ9IkqGiQedpOCT 5P6lHWuMOuacWn0No8uJXLOVo8WktWj3052fo96CGL2vnY3zVPOjJWWvc2kzp6Xbl6gJQcbvhVj0 bcF1Z2/HTDl5hN4t0klF5rXnqvbTflOGsU15wde19eWhWmUTwQZ/TJfpPW231V1C8Ozo9yydbTNz SVd+dvJ59W6S6uTU+nXG+IYn/OM9fGjqFv6V0lJ7+IKIlXTomPqZOs3S3duttNs41zhCra/Wcpw0 t56oFrOJv2cwzqyC/BLpyi4RBcRybno5Mr1tKr1y4JsmECHpWS2EsZFF09zhCBxj9IE8k4e67raf EpCdZpKMe72CyMZqrgS3heXwW2sYQSMmdyrTk0nPmHhSRlipuZZuepQI4OD0VxAyhjarQFNuV70C 81SL9NbsVDdZZSkjC5UIsfHOsNIRONl0kaV0mqjNWscjLZ62hWJeIm7Rw0MyylQT79HaLOhqkpZz ZYT5wBkRWxmdlros8ZtKzoJp20XGJAiuh0zPCbszJrTg8Xh3zaBZufWVd42ylnvJaNW7PWMbQUnl E42ZK5ZHFpQFLnXssZmsq3MyhYV2q+d74qLTWxg3OtWWMkScEKIvR70uqPeJUunDXREFEkhVEk0d Gs6k+wqsEaFHKeSHPdebpJasJW2WtH1QQ5+Ja6Z55Mt4ir7VChxYrlIzzxk7e79aOS8plSbpENCx beuM92vjZL20QUF2prDLNoPydquGjjvGM6PjeeSYYv3pMhpB869XPmZE4OobXyJJbselZFqsC1Wr lQhMhV7JKubBusT6ALYWwD6OvQWkXGcZeh5HvczuNjs9Dx+AWRA0j5iNsBVgYCAQYEQCyjFvT+QC H4UlzCyAdYTv07VQJ3epuUQi+jmWDmQVqPEXTBquVCNEFGRbFKG3K200OdjQacIYTTCuTK43LezJ ZLMLmU5tE4eI2jLVZ1LfPrRtcs9tZq00xyrVuFpjamrFdGxtw3BO2iufZ73gENFQIIKl4IMimcsk VAQLH4gecvrTxt16MPx9j5lJXduTeUHX3X0UZXOj/xXF5Rbwt70z9Stt2xtOX2u0sw+1st9tKz33 z95HPaFlWzNPaCUQVjF+0Jm05RaD8yfqT+EotsZaFOdy78rW+gto20nCEzOi3JL471VT7FHSWaIU qCVQId/Yy4Yp5LuwS6osy5Xse4SHhV8bExhoEenyRm8pyPPyy0piet+tWC+eUk17/X8+e+g8eaw9 3zYigL/oQy9w+1AqArRGT7XRC39tV3nvO9Y5IZ6nHd5q+gZCIoDMvow7I3Z6xFps4NiCJZJ8T7yI JKClJ1DjnNc31jHXGcX1xkDaC0KCo1XLUapl6ZXGddXeDjmwtoGQIwQiFGLlUtG9zjiJjjUxQctK oKGWqg1SNC1S0iK3eHPGOzkoyhylRDNyrYrIpCKbl53RjXe9sqMqahKaGESRFEHnF8maGWWp1jl/ s1zSgtZaqNKC0KtGTfByaTicZz1eWlFFClB1UGgIkaklBUHSsi9Fi8P7+nPacZ9HNnAYPnq+TBwn 5zpEuLQ4Z59LKJsXDKrTpGCZo4I9wvLCe1mul0pGC25sVHqrsy9WZKqUKwneq+fXNWzU+CKllsUj tcocyhutnutWdVCWD80EVGdp5cOXh6H3nU8MPb5dfb5mG/GHlQqkaoFpqvu86xaAjFTRYvr8PcVa Zgo3b5QJNakC9yQvZgy9sOrjHdkJGK8YhCN1uzKRF1ibyA7Mi97eVUTBLXykOpqFWpA8I4lQML9e KYlMjIaOwlf8FsqnFyUwJ+tJzbTJ3TlbT/CluGKx0H4Z+PF44z+PHDk2/X158RfrvR4SRhAkSHuV d1PFDzBxiUFQI4X14x3DQr1iry1x6y/U8efHjzU77OH63PPgyIZXbPV2S70/iZBgyKamLK8F/xsK 2x6wfEOJlWIXX+T79+T170O4nmbzzKKxZhvmYQiuYtfZBFC3bNA6GWWQktjGBkbzvgp6IYK54HRx c8777M1vf4QiWMlQaSG7KsaJ3R7+5+sGW2vGn6888PWvokVfGp4QmBg33135mHxO/Xo64EM/Cyyn uHiXmHqT4dhanffeuaRfcZXRdcphDCD9byHdQfh333vpOjMl8FVudYM7mUIxyMg+v346zNPRdGBB AxhEDBkCc1VuYgMHCxzUqUXsanoheHaIBu7CM7SLg1buu3WXcpNCrjp6xfBEqodobt4O47XUt3TQ iyxm1wZM7BNzSSLIs2s0tMWUMJi3uRDwpc2LWXUxLqy17vrwAAGFB50H5H5Cff3wnr5+GZhNXuX7 ge8CNfVUk9oSeX4k9CH1yTD2xMwNHgtvr7hiTdylAx3Lr172dEBxYaFcS8jj6dsq87q2L0azavxP Yv5fHh2qKAvqfcdpA8GAF4J8TXQsiHSqBHJylKDUAWqoQJVKBIgmgGeRPZRM6ueJXhO+++OAAm01 tVqyhSJVKEppGQUkEeiqBZyIIC+3PiaSPPfvIkx4h3330vuC9xEQBa9IctRt9mMGBN9HZPc776Nd NbuqitUpP2zumlq87lHb692Trjnpoa3KklaaqSVWLlYkqrqjfzb066nWqNpskKUBQ3gwitnfG22d cB3KKMcY44z4U52oRxFGoMqh4y0zsrg3rXfbjnnLHKkio0Q6INNUVnXkNGb7z+7uF3jgcEhL57xu ijbRXpAuLzBmKBkBYVSG8ByOzLnLTiQhVnJh0k0rnjdE25oBeYvMNPy/bmZHJx1titTydmn85tOV bf/MrYjHuJc/TYKhpVx0nryTJL6jd0gd59oqbOpvbD3ZR4at2hvK9blOzp7pcNdqF2ufPAh2kLro M4sPZTzorAOD2Vz1LD6r9D6Gw7ae/n5Bp5Z0XumTfOPwrPKPxMbZLghYFuZ+/k5km7SZea8rurEG 3IsyHkY4uHQCYM3nf8kHiKHUQPZBqCFQT89t5uG8znHGHG3vHPA8wDOCyIGsP0IofntDLXjrJvnF Xv1611VVmiMiARK42Xr0Y63W9VnmH8aV0ihtqON446947cyu9zHe+gR7CSgjxbA+dd634JFvzGL1 +uq9Q69D6E9vzMWq1nZ4PiC1x6+euTv93fg0a3lQ77u1lE3fFb6EvWG/kweuN7ecnM27BRaPDPHJ tDh5nPTFf5D4gfpWmVdXdFiKiPd8446LoOzIrW3msu5eVGiEae43003tbm5Fm9bIyRwXi6XlCi7p 72y6BI0qPmMNYXj63E+MxEFrBW05Ze6F1RyW11PcyIG8uGblYDF1dK3rI2QiirF79Dvl7HsegrNL toD+O+DJRELQtcvIR7kzUJoZ6EPSGPR8YnXlCtuQqpggI1xr5mvWB4GMBhA4BTacnDNwCPmtKRmp gTkQmazYGTBTkERiwIgSRCVU4MekHUZi0GXUBztCLnIa0QINCNspoji0iCCfZfQa+oVBBUlCyT8o K6byA4XYVJZmUQQcKiG0p8VtssiZoYzpxmRnZOAYmC8h8kBFQwLPc3mbXDsQhi4fEIWEymlzWS4Q I3Tko8TjAoNz6WdJsNg4lnxMPTuN5eJhA1saYvDVdTGaXu5eZYrLykUuWg0fMUfI9KGKqq9rCdF5 SToXoa7U3r5ctd1mq6wQiFJ0EDnQWKYYdLdh2Cbr0sMeApCJ4lWt+gykfOQgWRdEdoohXUMRERtY KbGxDpVwVWHSWODEJdAaHvBvWN10t71+bpPz82G8/acbJleus+CfGsGjzq8a2Jnq3LEE1n2d9m66 VzXO2jYo3vDNCoKnDUON842rF5sqCSCRtCafIONcYqVRGTq9WwXfXXNehrzjVjLaNc88Fdci1wb9 zSSEZGICSD6tEjivj7D7CTudBxP4Ro+ZvDk6VQmN8YXWtlH1Jvms5EqoLqkttCyYVbQzM+NZzWjJ MG7laTvI/Fmk0q4NKqq1wmdTHV851yiqoKNLSqKpu8c83JmZ62/hbYV1W0mqD241mtm9u63TWkL4 3y2pdmRdGHyCTWZsTRdLfNU5RCucGMZEFz84gcdh2HYJbt17Ji3MiIsb9s3jPXRo9e00LDdjHEVn tOimKYBQSmDAKzm60R5YSLqCxnA5ZFSqpgRBjap0jhwPzOqGh8CiDkx79sj0wIdAHPl8CyCba0da 20fpN+61ve+52K0rfR569BbWUNfPWsmE2Cjw6mRK33k5zq6JfPNUfBzho2cbu6al88UdtJfmj1sx ZsjEseYamB+NbevEcy+9y4iVYCSCCWfOY2IIOGyX4t1CDQ1GdIcvFd7xCrE8o7xlTMusrJDBY7Mu WaMFQVV2K270W7zHmGweLKp56lT3H1VN10sIlkWKUNC20lXipc2qiFZ2Np1Gwz4Hw7+4eBTa8p33 s6FcSZMSEZQXKcpEkyKEDWah5EQA+DhHfIpw6sREdzO+Dbw1yII1PE6mL56/HJ13O+q6Glo/FNdd rzrGNqje+QrHeoJ5N6CF9Wt2xADRIzlZjJxhnlVgpN4Y4a0uFIA4vX5Ug6hUz3qwDfntEGyt33q7 5IfBZLTvre6Kn46iWXTLIQuqp4rZmxzfWDHrdcdAi5dq3QS+SF72zkJPWDulLN7O7Xx7MT59qxPT 1GNyldXfPFUjvLDKTnMl3a7qfLnKT0t9Koy3W5ZPdwd1YvoCF3EqRvc8oKHOM3qNhSeux54T0OxP Y5TnVXWvrPbnIs5eOrth868xmOW3n1sDOpSlGD3OOTUnSm8t4hMWgRCB4CrHTfN0zRqNZAk0RhKl hIRpVWx4fQeEZxBqgTSQS+F8NCID4IhuSq7LHVXcI64DsfT00dO+mxS5b3CblG81pA9G4v4tcePa dRIJ0d7vHejsREBMa4xbc23smov6jeTfpioCIUoqh+Xq+ujvs9T1gwknz1qu1aFp/XnPC765NmSF jb5xlfNIwGq+eu9V71zcc1YbKwvmh2wwdeG6ydu9m7jy4Q7eBO+eAzOTPKkubtEvUIY1KOX14HKw 3FfS7xZTJCT6ZLsN1B7igqHF6KjigCL4GFxEccuWV6xra/GNJY8jYg5cnPLWMOxPO+UD7Na145Hm eOua0CCpSiY497nMLu9OtFaRLSBDWdchjru66666aVRRDtqpycVwrz1euOaFNwlUitAjQo0uee3l DjrqXON62gilCJS0oKBvvU1KQvUoDSdDWUw8JvnVBtKFCupKRGkOjgNve+uzN96NtC0tKUq0rmnf O9D1wRcYL1yaFUOYQpTM71aJOb28u93vSO4EqQj9vt+z9EkRVkiiiogo0otKKqqpKkqAAefy2+v2 ZhP0bbsY9HzzH8qg1Q95n/CY/NYBWSP8LxG0cZ4kWX2P5bZ4a2y9Z3Y4Vtl28uxXy6/kn6PyT935 J9X7N0UQX9cCwGvqufbuD5s5F44G3HH5wwgkIRfNIh5um9GiIkMM4gdYJ7Q35FIHrNVMihDUsDCE zlCqGsXVn6Nl/cOBzAiKfX6SYPbmgOShwRIEhGEAglEFhD3ZiKWYCloISDSUpSh5IYPV0WUKNUgo O8QsaE4ISoIQEUUFGhPlwaE/VggIiilNCNj8aLKeEIKKA0hD6s9eoc8FSkpSAgTh8JLBTMNa9WYB 7YRkEkVSWLEgwhDKJQQgmcGSlHFyxfwENXUDBxY2SkoEQbLllCqKVZIIiJgxtwVX+CUZFD3yWFkR ghBBCJx7995I1yzgOJvBiqFJi6LK0NAIkOjJm8CCZE+rgCgKWIRFB+cjzeA/jhUBqkESuBCKiIco aswNjUIBIXLGk4Kn3NhkmKGgskIDQXBh0JZSNDGAO8DK0fIGAWBQboK7bl6eCvrEQ2544aRfI5eq QY+fljWfqb8rCukBTOL2FyzfebzgYOmSUTTGZ8GuSByWNZ+B2znGOPBdbmANFcGSUHUTbUemJUKc 6qS4oFQPRneAEMVWx6xYfXZE6JwVcv/mfWPVHxbPqt4bf/fxx5ipOs7tsSikkUDYO/ZzbeCc0Zqg TsX8RJuXHPp2LpRaOM7AisYFAgOwjBFixadE5b6mRvAMjDEHkkkjIaHj706OnB5AIfagoEgbKvAe EqB+X1z+wi+iuNe7r/Pm6zokB11sN7TY/ceDQ0HosKHgKHRCaRzhVATaz8TkouGIHuFAp0QlY49f OX2Odc9e+N8YwPBvMMeYwZ5a4AoOFbRsohJUIi9bfjZjL+Qsu5q51Lr7YKnC/dY6GanWlB0PRQG6 oQPJShVrpVG9GzWHUwJRAMyAlkjgAb6UqJeEYMD4kLlqhIEQJqUIdyzaaQC0WikzIWGtqgdmukJB yFihALmSGQ75rNdMc9sNMJzrCWnCYyjiDAbQ65JdBKvLEo/2CoTGII7BfgJxjA0Nb57SXoGR6rt9 k0sShkhJ5Bt7PI+z6KOPf3jNqqah1fiZo4o+NUpwBwUjT3RMpjPKQtJ0ghlRMFFFJW/upjIRjMBh g2ogoEIZgbwniaSTur01Mv6XxKNtf16+OWv/OkeU3cJi1K4stiWa1jOdigCr1yjjFgNimI5YPgWE gaZ13oEe4jaXuAXqlaqkANajKx9pMT2No30vIzh87WhYOLSL6/ZYvZ96bzji5HcsKM4d6VVCE2k5 d1jySHOHaPvTlWZfwxrCsi5IMBzIUWqdd2ORzwHgBDVDBZOwsrVfOW8jXiTnv449UVhnWRoaDhIZ 77YATUvcPBoumvjBNta84NbWhkyzPePjN9F6GhQusRQK35215yyrzFjDjoaNNwz1fgmVjDQwVKzg Hn7pEDMkAg0TXaPESHGGMxsOjQ2kYiCmkPmHnAFBaWZuRT+WEywDSPpFyeZQ0RcZt6yqY/9J29CZ Fhyez4Frjy6RmxiGuFg48Odk33taxjliqC8t7lGEmQSLxkG7dZGQXsjDGryAimemAQ44q88cFAO8 iKrrvDHSBLmEkkiqyy5V+lDZnNQEV4FERPHzrPNyBDIKLrm5EliEyhKM6KD7RQLpuhseJfdD5efM IKsJWDfsHM6VA4MGWPjcDQy05JmoWBdiQ1kxroZ2vgDoNlBETFAXnpgZ6OXt/D3aA1Ms+07865eq HGOcec5Oxo1ulEyolc8pkq1NJC2VcneTcZFhA4saUzmoxZxVOCQZ3cqeTIsJSOQjem2WsxD5D9CN ELzvKXcpfZRWg/fscBD7pz1pn4+XM+TLbQ9qgaGxzg85HIFIoHACKam1bTI15OTghDTzxci49zBD 1nPECojd1LDCYHgAgDEONzOhiCSLM5Ua6jB4ZUUmLAsTZpduUtOO3k5/K7v7fbm1EfyYyGZDXObe VYQvOqf1R4CbZeyrZY8DVpA3mDwsI5eOQmKLywJd4rGBMXQlVQkgnep6PZPHvATEawkdjuTVeRrd sBdQYgQQgCA1yQZE8puhJm8Zq3jrmXhnWr+z7a0SevRAkIrSiqoFj0nvBhUEeLu7zfOPNbb3p9y0 w+TyqVRSlfbAJNV5CYGkhE1Ku9yWUd7joH0HXr4CL8nrSpigW45QsNQqKQn1Z2gBA1ONgzTwZlw9 fHh3IeD6LPWEkTQkPig98h4Odec0yHsNE2L5TL5vP4yaA9aoclE/ADYMvo6zuoSZ9FHyc0mKBBuA YdID9/JsAYAYoekV0ZijfMpbrcvRX0FH2NTE9318jtkac1U0xWJcKqiqkhOMYTmL87Z88HOTmUF9 Som6XhymOS7VMymvuIux11nJJ+09fwY7MkHEIdCNCM7ugA0fD9JDRmvnNEnTuY+0201N4SyGaXUg 6BbbmuPYgCXjqeMnQ+gIcwEC9ATbRM6HN+E7Qmq6J5271IL2SifHz9u8sYwoIiXbJ1jFTm8devOL 9O+MHsxxNrXAw95DVHohQwE27LANIc+rCH5XR+VZ+2h5s4cI2SCHFpCuaLdR+7Ilm2RmeZLaWwNV OtXodTo70mpsTfzZw8izTf/1FBQVTvrOR1MrjCuW8NSF3hawYl2XhhhjUQFBStyVVLV0Us1oorKg WiAhCIkIoQihCKo1VIhS1VDwuM3MSL7Gg0dACbEL10XG1XguokGqC1sMY0pTPbPSKGkSQFBiSChV DpAu7vMM8GXrIk+qNDWYQzE4dAaTjJ+ZJQctfg3dgXL5uqAtGiClsbhZACxAhIpOhrOWmFd+7llw m7BQqzKzPitHjhKvl2P36fv3iKfbLIq8SslmKqCAVYfJ6yQszThC6+6igEIYAqig5ouz8jU9YePA c7bBtGzvXav3SbkPO3HVnJ2cZCYK2Qgh4g1GoHpMeNy/M/A+uM8dEKCzj0iEcVDeACgt9CggGECo Bk81l0Lt3cHtDR51oNjzIZl4SHGlCjCSGqaIq5eIyEhnuunJQHe9X3YgCWeVCqCEoAFBc/nymgCE TGEM98+9DjEjqfGTxyVJIUKgUibbkYbrv4OcifhSYJgK1XGX68sM63USeu666rZUAAC5BhwoIxhh DqEr1+lEVEgQgqqqIskVcSbJFXEGK0SKqqqqs4qj00H6vtxwo4xae7Pof0CsEWBBez9kfAcmDWlr 1DwfbYBFbS1QJrLQ8+tftk5E+yZ62PIYcsCxfnkLqaIYYAQ5+NgqqNDmQhCElbhv55ISTDacu7yd C2P9ZoaD1E1S6KAYAzHjDpo6Y5bXXdhnbPuqqmp0EQVHYFADQrnWEC1JSRaLq+L8zykzREnkmF8A MAL0TGZrXyvKf/o+g9iKm693QVl5RKpD1+GFJIpAtYy/DWpziMwMDw5KgZ5T8u6mqrxuY6MrD4ne B4x78uSd6l4WYxrvIn3Eoqs1Xu59jZ84xlNFCNAnVCWB7lRKaWguHiQQjg6zMX4C3ra8G4bQyzJo fePjfrlE0D7xmWVAq1xQORUEJHg8zvrHVhi6K8ACgv2AFBbcJIHBLpuO/X/ByKDabWkqxYGqGoSB IybnPcoOLPJmCgfIIKjk9EgoETsS5xmfQ2954kHyOpjx5Z5dOGFcu8vuVZjRgw1Z2D03ic8XquXf rSUqzoRdCBECkYMgww3GAAcGnWeigGcUBO4CpR2G5rz5IEBOW8wuhc+7YbFqAJUwsKQwLplgKVcC 2wTB4MCX+cokJyahcSgagHVFHqBdbDg0QbWrLhGlrmS+TN1g5BJS4oKD6MnH5hVCEGn7dG7xBYmv S+DQXuGRxQ2YLhKo1i378uZA17zSz1j5lffXrIOAAUFy1OjU01vGvZ1vrl62/LFGuXdr1EBTNSUq MMnNJnrB5FHITcuVYDIiidhayGZpR1GM0aDGMYLjR0FV+J9/y9OcT1XBPmQxfb4Swmovoz6yvTQB Dk1HELTGWWlneuofLNjo+6Sq5OK2hw6Glpoid2TI9C+n7ZbserhxTQb420vPGZqN2RqzRJMayeJG lBVFpFpGSiCDJGU1eE21QiKSFSh1IHGOS/QIiJCEIPwS85B9nIFnYYrUaPgx+A/r7QzPX/QCHs2+ z19HWpkn1ICG0SeffRabModGqT71SgifgfeefKbCRxMHQWt01iY2/Wa2PeL6OM7lggQaYCRFgIf6 IbRy054S9fKcHAeZJB8EkD8yFlG6G/P4GUMTPU6hL2RLPxQQ/MKH5JtnvxZ5SfBeeiAH1xXJZRpr cu7lgEq7ll30TGDvA3ZKIDQKBgM0PN0gLIIaOqWBkQRVUpRWkF5uBJmigqqKzm2CNUGmlDiqKbW8 TghTg/uuiBh4E5OMCYIq4E4JdKq5VYIiW8fJj7k9hQMtNt+t6ILDWmEx7BTEUFfJEEH7Dt3mWdGg nIoHQAnzbIGf1tK/Cqyn35/GDgMj3kG3ow7Cz672PoyK6yHv0KIib/O0JE5IPqWb9n9UQQX/4u5I pwoSCdhI7EA= --------------Boundary-00=_NT2I35W7KT0YHATO3893 Content-Type: application/x-bzip2; charset="iso-8859-1"; name="xfs-remount.dir.bz2" Content-Description: The file system, after remount... Content-Disposition: attachment; filename="xfs-remount.dir.bz2" Content-Transfer-Encoding: base64 QlpoOTFBWSZTWdK+PKQAedffge/QQAv/8T8SEAC////wAAIAEGAv3r59FwxPAB9FKoAC4c+AfQAA ABr599w1u+AdnsevXW6Lxx9w9UPHmODj7znZdZxq5cc9Odm8R3aHY64Kb77lAA61DVsqqtt2ADbX Md82IOmgde7U9aBEpvYOuRlkxe2qg1DUwQAQCAEBERGg2piMnoGqfpoZKkTUgANAAAAAADTEE1KF DZQ9TQG0gABoAAEp6SIZIJAknpPI0m0QGgaANAIkiI1D0Gink1J5TTGoG1A0DI9MoESIgmIIJqCY iGIBoADTJu6hUBRN24+JAHy/nzfziJe1Ep8cT/C325a/5f+Pl/YvD6zD2OHxILd/86GP6H/zkLf+ g1SaWY5ig/nlFwdID5gJJUIUUz572WJ++CGICVBEJBuCyAoEijIAhIoMgicSo1QChSJQLVVykRSl FUERIDmVGRcQu6ZASRSQA/dFUbipUMQGom0XSKjrAVkUzAQLiCbRQcQNYgOICEhUFdYimIIFdUcI Cl1uGRDRDnJhr+MLsgggZGgRKgoGuY51lhnpuLfP58dXy4ZW3cezTZtrMC8hJXrsYkxtRnoUbo9t g5Zdhq2ZeCoHZ+QCHeIiIAH3gAqOIQIKyKhoACguKA0RAFRugOTSHe9PXs8fGwIt4AJdYxeEUEHT aE+CikBFGL8rCgD46936DneQh+VlnVFYcIIClq2UoKH+H6hA7IDovim0gw5hIdW2eMFhgiigLhdb 3BEBZeG99LrYtV7RkJDVnZsIIowhIpGEsRKAJn7Y8D9NqFe9D4qiPoeZ8w0ObmHBZr38NybQfG9w voGpdVlPci3xDZ1xdEQhBgY4cLEFDzR5YwcILBFBeb2ZBF11etO+rCR2EZLrskKjxcKKoa5V051+ Ttu6MeTtbWyW3Cr5dFah2294u9fBXUdEUc68CsER8+2bHWhHOfdTSGKMd27XHpUD8QekqzsYmZe5 3Dd1Otyqd33jOuYBbsniubKzu6gdwtvZ3XKVVkmDRT7GBLTdGGisIcd5TqDYpQzoqusy9e0evevq YgOTDlx9e9XEKriDXdSdvMW1govsuuy+xrA2D2ZCudHDR5dwYTHZyju6sN9cc5ROgUdtRU7yHJxW TxrGtN0NekfJU5vOpVaNpsK3W8p6etLOe2ToUvmgzc8l7GyGI8hU7qlzZbCmnWIKMKwbVCymVfGz MzIdJWV5LdZQ0N45eZmu6PJuz0VKCAjEOSlkpPZnUtOXzVx8qU1U2eMamsmr4yoOBXVGz52FaxzV Pne3xPZN6jLE8WcVrm9fWKU7Jfd25Sq5tbU6t44Ma14uB4rwCNMASsTqrJLl5xyHiTOKUbs3whl3 Kvb5vC4VVmoEjC8wXuLMXQV28cOzlBK1IM5O65V1dDas2VyJBwOlwaqNCZxQ9FPE+bReO60bDqFY w3VbfEooZcNLGzvZ1478nbnVktSqeSuUDh2I9t9ZDqqsF8htZHt1IOVVuJdO3AbF7QmvtKozt4mT NvsalvOKhqEY7zbuFkPDp4ctmXy5nTtLLNKtOEbbsWcrMIJKWsPqvkQJqppPuPFs9cvDrp2u5PgT wOUbggkkwQdTiZeczrq4JMqTH1VAct8zZ3CF2ntczvIRWupo3ttVlOtVGdT2K/GO43HgsjbwLdhz KeXc21RSqUtcT08G9WVvTKvT12noW5eXBInuprsiVbuccshx8btqc93W8s5O7tIreF6tlJ3A1m7t zDLpvXKkE0vRmXvWfEBubmlFikJvSajLqiebPWbVZqGJU95wXRcw7gOF3qqiipVl1pV3cSuDKQun yHW2jTu80E093su5WJezG8XrNtdaLy3FAkFBd4A7wMbi5ibGBEokIJp6oBqICJqVQKEqhUFLJcEQ tDMVEFO1CGsNdsq2QEUITeUyS6SiKuqIO+VKil464HA5ogqPIRBUe44mB5GJwTeHgQyRBUfNEFRw MAQVHqBcAMCQgKoEB5C4QD8f/AdhmEKvxx///eXEv1eo8vM5W/WFf06/HOf3H8cDlDvcdUlEV54z LZ7fv7b01/f81H3+u/Plp87b8EOvHKvHC1q+BHwnb+LeOgUe9+4iHgxEhcQEQweLVN+XbDbrb25T fhpZ+tf49evqvP13ldafv3vq/jx8T3hDyP0EevQz5mKgtJXJOvY9ETsUzWO0BTn6S3KOpQLpYU+b T3neV9MbiK8hXLHob5w7kkutQ9HsK7b8s8ySIk6SJMwnsnOPiHnK0vUX7FyKe92UHjfozCrPNdzZ mMKTvBCcmRtkkomkzpllrlGnLOl2xirbSe0I6Z1z32lBsOADnAo3SUBOVPSvFwt8e/1fhY+fr33j PlDj7SpNv1zB+fdlzGcfNwzci37tbwfN+scvnDS866PzisojwkpsbZr45zS7xS8t+uVYdtcVUalm XnL4TxyMb800VUNM9Eaz/OytoWCHqHjLat6jfE94+8PRRommcvVraTvEU0xX7TLa6C0Ypbs83zpJ t45kMKO7zC6e3Ta7yLT29JsTc+iY5cU5TeOTPThDu/zbtWHShS94NxT4Q6lDXTukDPEinZNlwcqr sdtp578lvd42PPzxrItcoy6U9ofWcoP28oiEW19i3ak4Q588/esh289KXNo85yno/411qpadZEqG iRgd5vCU5w7FLa2Ue2icr06m0ufKeC0neXK81s0vGvS8NYQQRyg2NLnCip61ZLT28G02fTXDc/aI nF5v91WXVuAXZn8curufqNIC/WaVXotumy99eOdI7STbpF+L4256lehSNyDT6ZMdabX3+rPqXl+l YPWb766Paarx0v6PTs3WfZ6bH17ZYyDFD5ypt51fUuPZXzUoQ5RUSK2vVMvahPu3W/hu19d9JW0j GzbfWk6R1v67IFtSRw3ew0syDHIl15yeJAuUs26avTPFrztBc+RNmwiQ9lZLunlMpPpwcYxOUvpA nonj4twt6cpzFLUScpeIMFmY0VXglxHE/ct9pRikps/navNpvhQQCkjLJTey0fBSiRxeIIryBlHK 9miK788YqF6Kkoa7YYqm+6znNGGCqRZeelo6xkcrrrM0trRVGitc5mW8FvG0i8yN+rxqZlnOop46 v1WlTVJz0oyxp0iDIivlQ7rbVaZUad3xTXvquUiBFhDrobqP0MmvSMBiPjRolo+Fp24lfOenE1q1 sNBZSvFSgUjldktnmcmnEVwdu6yoaztgzKNxbe0KYxkovRbmDe+9p5TRKRQpDFYQTCpCAnXCcmwi IKpNCsJpq+VqWKFxZYo0avU80OnC9HzS9ozvutqwsgj08z2100zZcSFoXsFDyyXOZnplN/GIbVem J0KtHzIalk3FsqcNjK6YvqgqMNXaOejRhm/ZXavPEpUrCWKZo7KHFaENYwpbs+FDInh9TbGZJPhj 1tMtliWy2eqEKELQZJ20YN2kfUBbi7gfONoZWGKFz1pOvXyEBukNBgV8jn7gI4OAEye4RtgKsDAQ CDAiAWUYt6fgA4D8m4KGRwAHgi1nqhg9vC4e807ZEoYoAki/kJSxc5oVe6aulwlQ24tunQ52NBTh DFOmKuTFxuW9mSyWYXMTmonDxGoy6Wc1cZsoytVRbq1ZeDU7V0cWC3y1SlmReNpjY230uVvrvlUE OwKQQVMQQZFEiRwJznABwAQfoB6z+tfO/bqw/H2Pmc1f35t6Qdvi3sUp4OsPxbKBSbyuMV09p337 5XpP7Xeeghe+fG+tqccafGZ03jdVuzU3ilUFpShvGhtScmjDQobFDklVvlPUqUwXjne/0FvK+tIx oZ1XBETO3REL7QZwVXvQkBEhgy7vllxJXk+6Qt5wzL6ffW2rq2/HRlxNi/f8lM+WTH17zWBuh0l8 ooT6mZFG/v5rewGMjV10qgcHOADnf7kM+0PmgVAWJUqve0ouftXjPGd9salGfVb7LPF6ANUKIJAZ l9GHZG7PLErTZwbIReVaWqiIgpSbhxzmub3jG+M4vfGQNILQoKjVctRqmdYlcZ63d4OObC2gZAjB CIUYuVS0a1OOImOOpig5aVQUMtVBqkaFqlpEVu8OeMdnJRlDlKiGblWxqlqhGqNl8XDHW71mGZUR lQpGhaKRB56c46OKGWWpvHT/DXNKC1lqo0oLQq0ZN8HJ0nE4znd5aUUUKUHqoNANDUVgRK5mS+ap qqO/FnPkVH2FUFAFFXnSAJiKsZRiZyKBiQZ0JRU0TYuGJadIwTNHCj3C8sU9Wa1XRUYLbmykeS7M vazIlEFhO8r59c2tm0+FFck5gaNvVw1THHvGtSILA+yAIERAg9w8+W3HkfgeBw3t9ePb7DUfH0oV SNUC12X4xS0miJSU0WULe8HlaugKWG+UCUWxAviaF8GDL4YdnmPDISMWJSCEb792UiLtI4EB3ZF8 X9KooCW3pI9jUKtiBullOTJ4/H658ziVD30e1/5rZVOLkpgT9lJzbTJc3Mjjd/0bnIQU1sBs2Cei vbd7yYSLLK2CBFlSI8kkYQJEh6lXcfcK8JWMMCINYqvl7xchAHmpo0VzaI9xjLGMjJ9xR3ExlgMC DIjizRAW89QoCRQUIywvXD9TAWz5pHgR2GlJDX5R39+Qz0gLk4ZFMsiMGqB3GhhCLBi+N0EkLhtE D455/I3j1Cozme6xD6XBueQ2cXPPffZmta+sIlkqmiMKN7GyJXCd/U84My49RnnXrro538kir5an JCYGDfe+/OYe078eDfAhn2WWU9w8peYeJPZ2Fqd999c0i+oytl1ymEMIPxrId1B9nffetps4G+yT Z5wcW5RprJkPt+7HWhr6LowIIC1RgxRXm7x5NDBkvTyijS+lcyEL4y90Hu4UZ2kXBtbuu2su4qdB XGnrF8KJpQ6hu3g7jq5Vu6UJWWM1cGTOwTc0kiyLPJxSzaFh72cxuajhSEkgyE+DIqR/ZR+XAAAh UetR+R+Qn398k9vlVUT94PX7ifESNfayTg0ZwL8TghD65o74YmYGkAW/19xyJvBTiY8F27eLvkA8 nakMCfoZ+bEaloeApi5YP9B7Benv3ZqKAvsPcZkDkwR95s6iyIc6oEcXSUoNQBaqhAlUoEiCbAaZ J7FE0q54leE79+/HAATebWq1ZQpEqlCU0JxGoKSCPRVAssQQF9nTiayPPf2ySY8Q79+/S+0F7xIQ AkeYGsalzuYwYE1s7J6nfezrbWrqorVKT907ppavOpR3Oe9ldtNe0SO9NVTtFqqXF04qltTfxvO0 63N9UaTRIUoChtKRqqs9d61xOw9MKMcY4404U53oRxFGoMqh4zrpZXB2rbtvxzznHKkio0Q6INRR z1DUxfHb93FF3jQmCqKvXjG6JvEeYBcXmDMUDICwqkO0BydzPOdeJCFWcmHWTWueOyJvzQC8x89y H9z59GD3Ht8uuoPoD4KfvNTitv5otlGPcqufk2BQqlx0nryTJL5G7VA7z7Qps5N7Ye7EeG1uob1X rcTs6e6XCu2hd1z54DEnkDkqCBMbFJkg0pLEPEGV8FJ31b6H0Nx31+Pn5Bp6Z8oPoTfOXurQKXvQ b5q5CcXBn8fJ0JOGmy9F54f1uVn7p7Q/Q8+dD8A4Kp57fkg8RQ6iB7EGoIVBPz37TsHaaTjjDjf2 xzwPMA0gsiBtD9CKH57wztx1lvnFXvzzt2VylSqgBUHTcvrwY3qtdVnmH5JW0UNNRxrHG/WO3Mrv Ux3rYI9hJQR4tge999a8iRb84xfX7KrxDfgfAnp95i1XWdHkfKC1x49+OTv9/fkaOtZUO+7tZRNX xWtiX1hv3MHjjWnnJzNOgUWjyZ45NIcPM52xX+g9oH64c5nmJCiqoor1fjHt8gqA+BgqLz3rPgrK KIop7jfTTerc3JWb1sjJHBeV0vEEXae9stAkaaj5jCsLx9blPjMogusC1OWXuiuUcluuT3MlAzU8 PLp0Dxa9472SqZOzR6iIHp9Hweb0j0j0UaNqd9Qfv4cyWRC2LfT0Eg9NVCbGexD2Qx7HzyO3KNr8 xZTBAStlb1Re0TcYcHROIU2pN40eAkKLWsqKYd7TuY7yRyYmy7y0oqcTrrmnj8B743xqG82GXxxL 3sxqQh2ceNztNPMiItZxro450goIFIhZJ9oF03qA4dwVO7tDSD4qo8cWdGtUgIQiHTownATqdwUg YL0ITQEVTAvB7eqNgPyCGMCEghOoVEwazV0SFjwg5E5wiFyzkVD9x7jA7zx7kzB8nmvaF9ZTF4Uu TGaXu5eVIdTTRS1WCzGBmEd4xSbc26JsTTSxC9DrtpvX1dWu1m1awThZ2Ibsvl559r4+cdwnC9bj LkFISPIrWx1Gcz6TESzLqj9VEbbBiIiNrhTY2IdbPCqw6zycxCfUGguolFZOmRJKPUokOvnQaz9J xomV3vPkT21g6PO7x1oTO7csQTrPo77NVtXNc6aNCjesYxxcOuax0evO68dVremxUU8cTvOxrv1X XNyYTd9WwXW9814GvOxA0j4I3o89ME+aO+KhJFGRiAkg+LROuepjTWWsq8Z10aX8zjw6rK93ZK81 V99+LP3z5ep69BpA4qd++pnUuouZ61nNdGSYN3FpN6j1JaxJ6MSbcrRyulPTyuDCCSCASDBMEkgk ka5zGlSrrc6VyFLdtYmMueZWa2b27W6VpFet8rVLssdDuevCJ6fBw5UmnGLEZkk3E90w8mKXoQF+ 47juEf37d0yboREWWO+kBptq0u3eiE7hjHKS03pVTFXBQSmDAK727VSBAdhQ8qROeZVsqOIgxtY6 ydIFUnnEkEwhAmi0H/ildZIa6DnrvZhFxzODfWmj8DXmuta13OxWlb2efHgLayh178dZMJoFHh6m RK13k5ztaVeuqngmcRNzTe7Y1euicRhfWxzuYs3IxLHmHUwPtrTvyjnnPnXOTjm8ByiLjO98eEWs bc+tZsh2d8b7jnGZjHGkl5nObeNPSmZaxZIYLHZlyyjAoErsLbvRbvMeYbB4s0nnipPcfJTdaW1X EcIherrZWbIMUkQPRWUpH0FRPguN9hwVGxOmOLvjbImTIhKcV+Xe9t9r11Md4OVQP2fS9b30Kcur ERHczvg28NciCNT0m5i+d/bJvud7rY0tH2TrfaXLviSCuYHl+0oEfFdBRz25d1kAXrHr0nfRiJrG 7KzYkxOrbZAGnLyE0MfCuVEOgL7bZBkq7iHvYh0cJxHet2BC9biIZyYLchBCYiDkaKYNPqRPb1F6 CJ5MqcYS7EJvdnUJPLB3TVZvZ3a+PZlPn21lPTyMbiq1d88pSO8sM1TnMl3ddyfVzip6W+iRltbl k93B2rF9ARXcTZp6zLG7XpTB9UVrtuejq6ngoMc6Uur8ZbU36TLWdiiiEYxOysZMSFz40BnqUpRg 9Tjk6k2prOP0ErUJEPuOtHy+Xrpd77b7egGYR5UdhiraTY8HyeEZxBSBbkJNzfMOoG06cddXes4N 1dwj1wHY+HbRt1tsUuW9wmpRrNdIHg1F+zXHl7TcSCbO9Xjvo7ERATHXGLbmm9E6i/iaya8MVARC lFUP0eL3s77PE8YMJJ78dV2pgEwfKqsnesGiggwWe66XakeAt9t5Nqb25uObWGzWF86HbDB14bWT t3s3ceXCHbwU754DM6mepVXN3RL2hDHURy+vA4sNyr6XeViZIqn0yXYbUemWq5q1pgJ9w7AkOXPn ni0rXxyyrPLmbEHrm8oE5VKQIWpAgBqfJPkcBdfIx+QAgEkeEgi9+Op0ElDIPIiWkCHWeuQxvu63 ve2lUUQ7aqcnFcK87vrjmhTUJVIrQI0KNLnnt5Q43uXONdaQRShEpaUFA7531KQvqUB0mxrKYeE1 z1QaShQrclIjSGzgNPet9mb76NNC0tKUq0rmnXOuh3wRcWFGICSQHQoeEjK9oiCKa4s9y6EHqBKk I/T6fn98kRVkiiiogo0otKKqqpKkqAAef22+Pz+Zf9uft+EPyn3/M/h5Jiz4of8KD8wCLaX8MSG8 sqZEWf2P98Wm+6x9Fo9jyhfaznO6d/wT4vgnyfBPN9G6KIL9GJx+zPTl3ldMMbX58z5+vr967Xtt vrxe5rWnGt53N4O8QPygn64calIH631VHJCg9FhSI6YKodYurPv0X8hwOYERT4/AmD05oDkocDQg o0iAiUQWEPazEUswFLQUVRGDIMgeZDB4uiyhRqkFB1iFjQnBCVBCAiigo0J7uDQn44ICIopTQjY+ 2iynhCCigNIQ+LPHiHPBUpKUgIE4fJJYKZh114syH5ZaUoWqqhssUpETlogIlGkZKUcXLF+oh1dQ MHFjZKSgRBsuWUKopVkgiImDGnBVf5JRkUPXJYWRGCEEEInHr13kjXLOA4msGKoUmLosroaARIbM mbwIJkT4uAKApYhEUH3yPN4D8oVAapBErgQioiHKHVmBsahAJC5Y0nBU+TYZJihoLJCA0FwYbEsp GhjAHWDd9P7B4HAw8w61lBos8k+Q962K91gJYKbRiYXHJYtkcrOUiKJABTOL0FyzXebzgYPTJKHn HB9DrNAeCypp4HfScY48F12MAaq4MpQdRN9h6YlQp4kW2qAiHyOLwBQYk0O8WHx2RNk4Kur/8rzj lPElnl3xLn8vnHWGq60u2xKKSRQNw7+xzbeCc0aKgTuL+BrN9cnn17XxZvWTtyQ2U2IGcGjDc3N6 9V464mTtAMmGIPJJJGQ1PH3J0dODyAQ+aCgSBuq8B4QyA8U47A3OzB0jdD/aqG8wRAOjFAJo4SH0 MCAgPRYUPAUOqE1jpCqAm9n4HJRcMQPYgYDnCwIEa0z2bcVi+N6TVVBPEmMLZVDQJzwFBwraNlEJ KhEXev02Yz+RZdvVcRufOCpwv1Y6minWtB0PRQHZUIHkpQq11qjtRu1h2MCUQDQgJaRyAcUpUowj SUh+0TBcRQaAeiFB6bNPKBaLRSaELDa1QO5trCQdRYoQDBzQcldvp16417zvh+0y2/DxzMnDwY7P v2uYc3nXElZ/rNtKXSHsb/Y1VODjtpvJeoZPVd32JrZRClRfgKuvR8FfM+4h36+YzSqnUN35TKaJ 4iyGgGgwjOErKY0zIWk6QQzBwQhKJv5xxkoppwGKSrglUAiaAKAcxMkI9C83EP5K8GMX/bxzht/T WXOj+SZNW2TLclpjrfjjvNidfj63875D5nBv6ddoyB23r3QI+xG5jAAtVWCSgA9RpnH5Lwfke2sb wtPx+67Swb2kX2eixez7k6zfi6jRYUZQ4JVUITxJ8e1n3pD5h0P4p8VuY+2lZrJckGA6EKLVOu9j k54DwAhshgsnJatV+2X9539E+ePWn5IrDetTsdhzIb8XkCbF9g8Gq67X4k32rzg2taGTOh7Y99H0 XqalC7RFArtzvtznNeYsYcdDRr2DTZ9yZsYdjKpW8A/V+EiBuSAQaJ38R9CQ9Q0mlh0am7BAUkDW HxDzgCgtLNHJT+WEzkO0fzi6vyUNEXSfp5qU0/xJ19E1LHV5/YXgfg+oTwaB3zYevPzacYu7NNdF QX44dYwkyEi8ZDs3WTIXujDGzyAimmuAQ44rE+7KgHuRFV78Bp2gTBmSSRVZa61+lDZpNgEV7Koo oo9/Xp+LUEyELni1obEeUYahQekUC6a4bTtL64eHd6ggqwqrnVsBxM1QODBnHv2XWTOvJNFCwLsS G0mNtTS12gZhkoIiXoC2Oq4zedvu1c9WPAq9TTu69vS2ftU5S0l0pN+VWv1qmdUtpnQlWxpMXztm /0bzInROTGldKKMmeVjikWf4KvoyJ05nMSSEmiSkNgPQJxkL0vMu5S+xRWo/ducBD6nPWunj4dD4 M76nsqBqbnODzk5ApFA4ARTY3reZNuTk4IQ188XIuPaYIetJ4gVEbvqLwH5hAo2+vuk8Q6vb85vx n3grkzi8OWn4mWl05S047eTPFt+HhjJBB8SikKSHMpnCqIUY3niIA5cnL45w4IBcpAzVCBIRqaih AlB1IgNzWMCYuhKqhJBO+x6PYnj2Tg3627V3rxM9ayY95o94IdJaCH1+VnyeXvjrbNYzVvG+ZeGb 6v6Pprok8eCBIRWlFVQLHaesGFQR4u7vN8489ab10+paYfM81SqKUr6YBVbPVFYIwoqG1N3vVWJ3 7DqH2Dr17hF+PU1kxQLccwsNgqKQn2s7oAQNjjcNE8GhcPXv4exDwfYs9YSRNZH3oPbkPBztzomR 7hqm5fKZ+L098tAetkOSifeBuGfsdaXUJNOij4OaTFAg3AHNaGe/zhBDEss3xzVSNfKEvSUGiSdi NqlGD4bcbB0mEKmZQU1JIVVFVJCcYwnMX43054OcuhQX1KidkvDmY5LtU0Ka+iLuddaSSfkevxxw ZKJiijsQaEZ3dAB0ez8CHRmvfNEfNbMfZ1z0bRshol1IOoW26Lj2EAS8dTxl1PsBDmAgXqCb6ppQ 6PundCbLqnnfvsQXuSie/x8984xhQREuyTrGKnN469daXzN9DB3MaVvI6Eo75DZOShJQQ3m5YBtA 15sKPq0+nPvsTWzSYhLKogaXCh1S3YfrJLN8mh5ktpbA2U62eh2OjvrNjcm/jc0mslbXV/zSAIAi HvV2DxUTMkmi5MJBuSYkSmw5NGJUagEgSDvVKyNorNqKKzQLRAQhESEUIRQhFYRWEBkVHhcZuYkX 0NB0bAE0IX1zVY1LwXGiDVBa2GMa0ppvprFDWJICgxJBQkK5Qu7vgOMGflkX7ocnThDMTh6A6TTJ +BVIax+Jd2t1etmIgGINkFMaYC0ALIEJFJ9HefHbNe+3xr5m2bLvXW9dfq9p37nGWNG3o29nvi1Z qaJeCQJVJEBAA0A2GbOAQPThC6+qKAQhgCqKDmi7PyNj1h48BzvuGmrPXWp+a7E+Nd+bPB6O8lGC tEIIeUFqNBzDHUur6z4DzpnTsUIWafnEI6KHAAKC47FBAMwKgGr8rMIYcOwfrh2fmuw2fqIbmISH qlCjMkO6aoq58QkZDTsuvJQHftV97EASzyoVQQlAAoLp8eU1AQiYwhp2076nGJHY98vHJUkhQqBS Jv2Iw7L28HOSffSYIl42307Z+/w4zeuuOX7/N9/femwANcjxksSqwQ3CV4/BEVEgQgqqqIskVcSa JFVMEVokVVVVVZxVHhA/F+nHFUVeLo+dn3D+gVgiwIL3Pxj4DkwbUteoeD53ARW0tUCbS0PPrb5y 5J8pptY8hn4yWY+dRe5ugzkBPt/NYSQ2fYRERZ0Vf18CK4q05ezydC2P9pqaj1E2S6KAYAzT1D67 PbTXxhds7+2O1VR3PoRBUfAKBjbr2622nxMEi1XaEoaHnNmkJwJHYcA4DFUyoapRWSHkWg+JkuXe XdgqppkpoRMCikkUgYU15+I9smDIwPDlUDTM/LvU2VeOxjozYeIcYJpjv1dVXG1XiSsY24yQ9FIu V73XubnjTGYbCQiEOyQsDvTUGMiF0dQogRwdaGL8Bb1veDsG8M6E1PuHx265RNQ+4ZnNAq1xQOai hI8Hmd+sdWGLorwAKC/yAFBb8qh8UYo6Pp6/ifUge33ayywqQqIoLTOxz3lBxZ5NAUD4BBUcv0kF AicoUZlLkMdhzBB3QeA/PaUOWTHtqFi5WY0YMNme6CcSOmUFXPx2rOdqVIupAiBTMGQYOmHEAABQ Qs/VQDSKAneAqUdw7G3PkgQE+ODOEMH9HgbLoAlTNikMmE1yKVcC2wTB4MCX+cokJybBcSgagHSJ zQW7hodEG1qy4Rpa5kvkzdYOQSUuKCg+DJx+kKoQg0/TZq8RY114XyVAvYZO4VZguEqjaLft5dCB t30Sy/X3V5wGL+eAAUHOSIsFDRRY3FpxbOXhTEWujnWQ6GpKVWGb2m0FjAilmKPXO0RmRSNruvdT M0rCpGRyEgFVVCGSbgvye3i9pnFcuhXjIYvidFWE2F9GnWb11AQ5NhxC0xnOtnfbYPhm50eqpdTR 3gaTYaWmiJ3ZMjsXw/TLdju4cU0GuNNLzxmdRuyNWdEkx1k8pGlBVFpFpGSiCDJGU1eE01QiKKRh XQh3jwX6BERIQhB9yXpIPscgWdwxWw0e5foPt0QxN/kAhoZepz5GeswTdVBAyhCs9EtNGUNnVJ81 SgifU+Z59+PsbmoTwevX6frqHz/HjHevtvrzpVeI2We6dpE2/nDeOdeeEvbynBwHwqlexUP1CWQ3 Qb8feZTDx0eUb1RRZ+CCH5hQ/BN9O3FnlJ7l6aoAfbiuSyjXa27tsAZdtl35HGD1gq7GCFQKoDAa IebpAWQQ1dksDJCEkkgyEkYEmt0FVlEFRzm5RCKG0ZA0UZcl4rQoZg/haUGJoQ1NMEMoq5J5TCVW CqyiJf3ffCE/BP1iga9vHHe9UFhtTCY9gUxFBXyRBB+R376FnRqJyKB0AJxsyBjyyldKrCduPC51 hgaYBlvLuQs5bMj7GSusj39CiInb43hInJB/Qtxz/BEEF/8XckU4UJDSvjyk --------------Boundary-00=_NT2I35W7KT0YHATO3893 Content-Type: application/x-bzip2; charset="iso-8859-1"; name="ext2.dir.bz2" Content-Description: As seen by an EXT2 file system... Content-Disposition: attachment; filename="ext2.dir.bz2" Content-Transfer-Encoding: base64 QlpoOTFBWSZTWS109YoAedpfge/QQAv/8T8SEAC////wAAIAEGAv/n2t9tSBrwAB9KBQEw8+AaAA OgA149j174AfG4qqjlxx9x5Qd4mDX2OO3d2Yw513aJzud0O2uFnd0BvqwADdvgFKttOvQ5C1nNq8 u43o9dFLbSvVaLTA7dc9t2wNN6Z23WQ8NTBABAIAmQhRpNAyZDCBqn6BiqKnqQABoDQAAAADU8QJ E0pqPUeSAAAAAAASakExESJlE8j1MiabUAAABoIlEmJpGyU8p5T1GmyjEDTQ0A00yBEiIIyBCaEn pNI0D1AGgDTRlgKgKJlkdpAHv+/g9kRLK0JR67TuK9V9p2YYI+iJfAJDQ20OHGgdxkc9xZH5UK1K ECAZIgiVBQNJjxxxxwf73r+6Zz606df8nPrX+B/0DH9TH8o/1zf/Q8DYbpeYYGmHnjB5rAB1iAcC IyBFFM+ebLE94IdICVEAMTf/n19rzzoh8wcILICgSKMgCEigyCJujSKAoREgLJPvSkUiiqCIiE8l RkX9YXdMgJIpIAaRVHEVNIVAeuJlFyio1gK2RSkBArEE0QQfxP2QNogPqAhxDaCtRFN4InEhspSY zykNE34lDdHmqHmv3l23P7VQNHxAQ4iIiAB8AAVG0IEUGQQ3AAoLoqiBRAEVDCbsEVSg+z7WAKfX t9fvYIuYAJdXWMIoIOukJ7kBAAKIAIxgMD6LVEX359n6/f7E+88cX2MFmMlY8GhlHCoJ4UAALAEc g7G2xqoKH9/4VeydV6Xaqqd5RVeKOuEwEYAKYIooC1nC4BEBbPZz/LC4vVwsCSAACnVfVC0AhEEk UERLI1CBCBzzHk7d7K4tfDOxg010zmZMSvfhxvqC+gc7SowreVW0u133ljnMdx2RYY0IQQYGKHnD zBogYwEULAmYwrmVkVrJWkiaRryprZtrbgo3Q5OspOZ452ZRa1zkr5vEmbyXHeWz2I7D2b0F5SVE UdeaLwENRTnzVcLOxSh1QbbQk7qZjpheWNCN4eaD3c7ZB3dartqlmU4ynEBiwlG4kb2SUD2lJc5M dXVa3o4UpqAeWlRZo3pCashcxzvqGyXWVu5y6jM6ZKQYOvTuNTOlQi6x2FclWsW7fVooqblTcmq9 CQM3Wbio6aMuQIWhNltZlYEpjTlu1QNnurzcj8vCq4l3Suoe0S4R8+4o/WVsE27FYq6W/S5Xexdh PC3kVhHH485pEINazbkp4+eIW+PIMUWYiNQ2w9vcOF7us8Te148VbQ4Janm7vLKMtLDHdWwwRtiV WWTVXMyVUK5ynb3E1MUcY2mriaxlaMhwkYOtyXVjdtXu4rITNfSi8D8vYb5PpkwVbmvJJ21dY+rq crodGq+W3AYbQ4kgeEgkAmVRIPW1N3hJcO8cB2kzahGqNYQy6hxUbu5N4brDTF2WVujO2924xU6H TzlsZUqhZWSXldvaJvHjT8wFC9piVp0ZipmO35aiVlasrhzPWK1BKq7ITZsbjNXqR6bM1Z452yte W6pa6lsJnnZnZMIVVWAqWOrWuymxLqu27jnaDgzqD5TjdFzoS3vZNVvFsNs0yNWb2YyiFp4wS+e5 LiPHk5gpqjJFRcCDKmSCS3Vi9qNsgZTVtqQwpGY808qWXJagJgO0cYYbb0MSk7RWxHlWMN7TeqVT B3FEcPaRc4zk9vzzNvtCfZdbUrroyUud54hIca0YR2aL7md2luY+y6N3Tq+TtcYEuva6PazjMy1w vtzcYbtd1q5ru67th3CE1DmK3F3cluHXJOIrpednOr3GFe93Y9LykuTpsPiuG7nTD5YHb28bKFWH 0b6y8qiYkZBhqaYltXW7wQjeSakGTcU5koqFRc7Kqq1CwXKFS8053SMuqvYJl72w2VBesOrhrNpm itG4oEgoLcAdoxEcgXrrplM6CaeaAaiAiYKoFCVQqClkuCIWiGDSOsRC4O0C9KwICSRdqVAAKgKj ISSCKhqiDtmlRSsc0DWbkQVHaIgqPMbDMd5aa0yDoIZ0QVHwRBUcxmBBUcAUDAkICqBAeQuEA/P/ oHYZhCr8/4/tHpH9/RR5eZ/X+cP/Zp9wo0xsIh4MRIUEBEMHi1Tf1vo35W2v6m/DSz7a/u5/tyr+ 3j1K60/x+b6v4/f5nvCHkfkR69DPmYqC0lck69j0ROxTNY7QFOfwluUdSgXSwp7tPed5X0xuIryF csfA3zh3JJdah6PYV235Z5kkRJ0kSZhPSc4+IecrS+Iv2LkU97soPG/RmFWea7mzMYUneCE5MjbJ JRNJnTLLXKNOWdLtjFW2k9oR0zrnuCXNmf+MviuI8/I2hxcdklEV5Y1Lh7dN+Ka/5/hUdeu/Plp8 bb8EOvHKvHC1q+BcQg+gcHM4nAOUErpIfMk0ui59OPv+lk7eevXGeYGnimqsPv5KOFRJMwfvky6D Sm2QZql49Nbufh+0cvGGl130fnFZRHwkpsbZr46TS7xS8t+WVYdtcVUalmXrL6TxyMb800VUNM9E az/OytoWCHxDxltW+1hvlRY+4eijRNM5fFraTvEU0xX8JltdBaMUt2eb50k28cyGFHd5hdPXTa7y LT18JsTc+iY5cU5TeOTPThDu/zbtWHShS9wbin0h1KGundIGeJFOybLg5VXY7bTz35Le7xsefnjW Ra5Rl0p6h9Zyg/byiIRbX2LdqThDnzz91kO3npS5tHnOU9H/OutVLTrIlQ0SMDvN4SnOHYpbWyj2 0TlenU2lz5TwWk7y5Xmtml416XhrCCCOUGxpc4UVPjVktPbwbTZ9NcNz9RE4vN/tVl1bgF2Z/HLq 7n8RpAX6zSq9Ft02XvrxzpHaSbdIvxfG3PUr0KRuQafbJjrTa+/3Z9S8v0rB6zffXR7TVeOl/g9O zdZ9npsfXtljIMUPrKm3nV9S49K+alCHKKiRW16pl6oT7t1v4btfXfSVtIxs233pOkdb/HZAtqSO G72GlmQY5EuvOTxIFylm3TV6Z4tedoLnyJs2ESHpWS7p5TKT6cHGMTlL7QJ8E8fNuFvTlOYpaiTl LxBgszGiq8EuI4n7LfaUYpKbV6eu3pnir5FiC5jcKpjmrg4VlC3FEI54d+pwV354xUL0VJQ12wxV N91nOaMMFUiy89LR1jI5XXWZpbWiqNFa5zMt4LeNpF5kb9XjUzLOdRTx1fqtKmqTnpRljTpEGRFf Kh3W2q0yo07vimvfVcpECLCHXQ3UfoZNekYDEfGjRLR8LTtxK+c9OJrVrYaCyleKlApHK7JbPM5N OIrg7d1lQ1nbBmUbi29oUxjJRei3MG997TymiUihSGKwgmFSEBOuE5NhEQVSaFYTTV8rUsULiyxR o1ep5odOF6Pml7RnfdbVhZBHp5ntrppmy4kLQvYKHlkuczPTKb+MQ2q9MToVaPmQ1LJuLZU4bGV0 xfVBUYau0c9GjDN+yu1eeJSpWEsUzR2UOK0IaxhS3Z8KGRPD6m2MySfDHraZbLEtls9UIUIWgyTt owbtI1kd5Cjy45dNc9PIYM6QzGQr5HL2Ajg4ATJ3YODeRVgZEAgwIgFqMXFP6gIf1U4KGRznO77F MH3S27GnXBKGKAJOH8hKKhYyggNe41lXA6ZxO+ylQiwcDaZCFKkKxvbhx4uevCUWU9tPrJ0wjrLy r2XXeKZRypW+dfHTyEq+rtKpDrfVtZZwdjOMOdZrPdYgoJSCDIpdMEioCBU9wc+rp1wfn8D5e9e3 XdvKDn77eSlP2dYfm3uBSbyuMV09TuFom/bJaT/C700EL1z431tTjjX5zOm8bqt2am8UqgtKUN40 NqTk0YaFDYockqt8p6lSmC7873+gt5X1pGNDOq4IiZ26Nn42PUuIqmWCWgj18kPUFe++oC3mGIfD 9Wd0b2eicpCD3K8P7/ZqvuEx9+5rA3Q6S+kUJ9zMijf35lx25Dv4rDm+LEUBf9iGfUPigVAWJUqv paFFn+EneO8b1fooxys92xLcBqikUOnV966OrpnOpc1WW7gzqil6VEkWSRSRJSIgpE5RnrE6ty9+ Zxe3M4A2gsFBUZOmUyOr3mca5a1zPVgswGqCmhCkIXtQApN7rOaS+dVeB0xVBQwyUMiMFkWIitrX cZv2dEMIdJKQxapZpkWQRkOFs2ovrlt4oxUpGpSwRgsIiDfrF+jMGrFlOXy/266igswyUxQWCrDB vJ0aTNZxjlsMUUUIoLImqCknVYLdSMnc8/PPVo6oACFtvt/A+SwwMD6vaB0n5HG6qFUIN8UeGicG Mu748Roe8IKMgzcFLr3ldR3RYxJ86sy7m7nVuu7di9J6XkUx9XPqUFGnhSF1NL3raZzZte+11vVQ l9BFj/cgiozk+PzPyPA25evvv6/Abq+Pn0rOJiNkDW3X5jS0miJSU0WULe4PK1dAUsN9IEotiBfM 0L5MGXyw7vMeWQkYsSkEI338MpEXeRwIDwyL5v6VRQEtvSR7GoVbEDdLIqjJ3/L548TrKh7aPS/8 1sqnFyUisCROtNMljcqON3/BuchBTWHzYDaGCiixbd7yYULLK+CBFlTY7lVUooKqFHim7qQesG7l BUCPfz3x2IQB5qaNFc29jGWMZGVhN3EhlcMCDIjiMwR5/8jAWYKa9VZO5/pQb35s9odZmsQuv4Pr 14PPrU5jhkUyyIwaoHcaGEItMkGMt0E0LhtUD5aaaCa4MO183jevDnNy6JdXyHU0xXPHHBl6dPei oWSqaIwo3sbInXt5njQzLjzGeOeeTjbwVUknMah4rB2KwSuOvHbNHiHHPJ00IGfBZYyHaFXo7qvk cCynOc11EX3TU4WnSXQug+/jmQ8lD8HnnnO07O+qv4VXZi5m1qwiU1MFofn84s5oQQF11POVQSvF 408GpgyXp4uXKv6ePWRfy7ncDJBR1xEawqXc8V7mO6VDGuXIZBRNWz1juzRIeuXXdxsOtwb1wIlz Q+3iSMIwy03ZvBgXTYh29Z0wS1qE+DIqR/nRwH6cAAHi40H6H6Hv8fjknr6P2zIKKIPX8RPlEjX1 ZJwaM4F+ZwQh99Ed8sTMDSALj7/EcibyU4mPJd+/m75APJ2uB3GfmpHYtDwFMXLB/uHoL0+srOcF AXges5SBtYI9BpwKohupRFb7m6VUGoAtVQgSqUCRBLA0yT0UTSrneV3Tt27deoATebWq1ZQpEqlC U0jIKSCPJVAs4EEBfTp1msjx29ZJMd4e/fv1J9ySe2CIAs8Q6Qs+y1y4m+HZXuu++Gg1UlKyKV/C uRizkm8FEVFYcdqECou+m8SO1NVTrFqqDmNxxVLfCE58be3fdd7hxFIoCh2kRknJ773vNdh40UX7 v33nuQ83RCXZCUkaol+3rNiuzla5vvzzF/JBZIShPQkpkJ5k6L+vO+0q2BsVRX59echDbCekDpk9 JG9BFCRqoHEJg8MeY67USrHhedL1XNwkDjJxC+O9nAOAAAYTEqSU4jIVJIXi9IRRYQvFHxMortqo vHzFs3Vw8TM1vW8lnMugeinC3zlpdgXc7MHV3WOlZyTtYeMjxm51DMqKLRQnEVMsI7Wmba2TGOC3 OWHx+j4PnP2Psbjtr8/W30EX4fB8H2JvrT2rQKXug5aq5CcWZn8/R0JOTTZeq9MPtIG3QtCHwMsn jsBQGbqz8OAdQnOAswD7hJTIFJD7fjzt7Dt6fPLy/Ppf14T0gZSRYBpPyGQPZfrv13LeXq2/PNck mIU1SAUkzstrwvzc/dJzczqj9yTtFDjKb8vnv4v44qebq/e+Aj2FVApzZoN8616EpbeXvbria4PB PG77qpK6xo8HxBZ13686O/z89DA5pIHv3dk14Kl95PQIt4b+WsHydIVoVQwCiw9GM9G0MvVdcaV/ lPhAfydJvnosANDXfYAiK6DQHcSEe710pjhQxRagssxd1ylPjXX29rremIjW0/PM2o82xZWWuHg8 nPLBI401ENN6VqmJ0oXtEFVovrTwruFS2m8VS11jzu50Dyxnu29Co1LjvopGyEUohnkbh898vkfI +PkExtTvqD9+HMlkQrFtn8BIPTRQmpnqQ9IY9HyyN9K8hRTBAQpinnJe0TcY6ySQY31o8aPASFVt aVasgFaEKmtWBkwU6BEYnKKma3vqOd/YrzrvrlHeLBh9Zq3fZfdUUeGfj1XsiFVRBBPl6Yxyli9Y Yx5Ywk+2LjraA30eOBCyIhiyDppHhbnW+unJsW8GuO0icBOxxDRBgimYDqt8N8Ta4fkEMZOwIzCk 6pVTFX7vNo/FH8iZ1U2/LwJQHfz8eq6NGjN8TvONTI6uaukI3BdiJLe3YmjdVMTMBzEtFLaoFnVh nSO8YlNuKck0IlpWxFC1uld1cjkb4KjPNUYRkFJ8UD3xWXW/cdwnC9bjPkFIVPIrWx1Gcz6TESzL qj9VEbbBiIiNrhTY2IVYIijpLDmIcT6BFF1E5LN1CJJx6FGnWQEl1N8gbEU5tYT4Zc0euWvrYmOW cNIJrHs77NziuJ1thsUbbve+bUa6l9Hv3yeam+bbCop5mu8cGbOs91V05bVmhd851OxnPOt3GrMN 61knZ0LMnPVaVKda6NcaUZfo3vW6vxmGYVzj0xCfnEQvBD6Hvzz37bB9/CcHXYOmvW8S6O8pwzeo pLR3bfE86Mw3Sqr41VXTC2VkdzhUy0rU7y9qoChumrTF1GWpq7MVEOuN8RU7yut5hQjPapzHI7T2 LC6Nzw95s/IYW7DsOwS/br2TJuZERYv20gM9tWl17UQncMYik9ud3o7hcb0UD6zjlZQ/Afe81r4e d3tFMVjuvc8gPv7tK4bHsWQemvmR49FCMBP36GEE51WTmtsP1G/wNb3vuuxWK24evPAszCGu+rlk 0Cjh6rAk1zB1jVoVbrqQ9ji7DZndrRlW6zDjEyX6OhqqSw4ozVx9s6bGu0aW+4tHK8ARBBOb69cP ggHJ8Ot0e+a9dYoIe+9+qO5tZnQir2ltnoXb3cvb1ssYJu5kFnA8DcQHURQi4mbmTAOzZTudNO6m 9t5VW3SWyNjGIp7iy5rLk7bFOJg74fpHYU3LfbUblVsp1y3w+NsyZMyEpxXSk5klCKMTWmjCJKB+ 2t85oUy7sIiPKxzJtyzoQRPq2+E7rFtd1c53Xe5sYsOJrXF61e+1RtvoJnp0CPioxR33LkwgDOQ9 erXej55qruNKeYdRtbpkAbN1ek0LeFZOtOQKlEFlTOtPOKEKJVFyTweae5OsHxl+YHtetGe/fneg RjzKxWKr1WNRTKDYwHuNVvTZOUM3aUU6o+NYX3K6y8yLattIAb2izVJxErMqS1Kid0uKUd2Xivtw mSBZeDIwRUhOGoPgUVD3nNIsKbCuux5uroeCixzpS6vxlrTbmNZWKDZQ9G+0SjJZvnoATi0SNCB3 VWMS4JG5jyFeShVED6zg+l8eo8zvfe/QCLI8prAhWK7SHgzrKIqCC2CWkEuFxaGIDgjDGY3uYHGn ainWQ7Hx4w4742FLVZ7ordQ3iaQPDdKGPHibpKE2c1a/NHBEQE/RjfVYtXG3Ct0v6zmDnjSoCIRR VD7erc4d9nleXLpVfHmp2rBY49/td2rlaKLG7XW/ezswIMFnvUrpI4C3xVxSitxlTeUpMFSb3aG+ ZYmacvXO6b3atxkLFopZFoL2UjKuqiWUSuoMtU7O5M0J3px1keZtbaJFUpRaKqIQSMHlFUOUEVHl EF6DshIcufPTFp2vjllWeX31hM3+eXpl7uxPXfSB9Wa16cD1Xp11NAgSRokOu+20Gsi6Gr8UEIIQ CG63gEc9nrnvnGKooh4yV3o6nSuu7b61BTlFSIrARgoxcdbekM85VqzvW0EUgiRYoKBnxnR5rVjg zF+7c63A4kFCd1URGIa4dBT5vnZi3ejbBYsUirFfL5lua5se8lLe5bnRwVQ6ooil8cb+bsiVi3HT zluaR3QVKoofr9f3/hVUirVUooqIKMUWKKqqpQ1VCAB6/lQq/WoT+DcdzHo+ug/jYGqHxQ/2r+ax ri5lU/v+KnSfFknS3HPSvCytfJddfjlrx67dSu/n96drxT9PSng+LYiiA5393E4U9a9dAfZWRefM duvXl+nOkspTjVJiBvrBGkM8HPEDfBOMNFxRA88xUuKCGkqDCE20KoavaWPw2W+Y3HFBSKfL9hVz 24gHRBuMEFGIgJChJET7rF2QsXCpKCiqGJFIoeqoueWhYgoyIKDu9FhgmSipQhQIooKME+LUME/G 5QIiikYI2H4YWI5QoUUBiFHyseeUdZJUSKUCBWX0VVgUxR1ryxgP2l0WAoBGxYUiInTCgRIbRqoo 3tVhfqIatKC5mw2KiQEQbFqsQVRSWKoRES5fbck/xSGBQ99FgsUjQhQghSZ9++8FM6ayGa3cvIKV e0LE0MARKOGDFriCYE+VqAUBSwhSKD8dD1a4fuolAyIIkyIUqIh0hqxcbDKKAqi1WGJklfNsGCrw YFiqKBgWoaOCWIjBpoAKSiaRL0CeCUEYsYgyPixIWv0IQWxXusRPBUnMQj0ecZPgt9agk4QASJh7 AaY3zLmAUDjVVB6vk+hrEA8LErPwTeXu/x42rhcDqSXMpQcxN9h5YlQp0qpLigVA8ml4AQk3zK6X YeOpUOhWg3V/914xwneSzw74hf8vjHOWq50u2xKKSRQNw7eji28E4o0VAnYX7ms31yePPq+tm9ZO OshspsQM4NGG5ub15rvz1mTpAMmGIPBJJGQ1O/1Tk5cHgAh8UFAkDdV6h3SoH46/T8il8lddu11/ rxdaUSA7bWHS03P3nc1NR5LCh6hQ6oTWOkKoCb2fc4KLhiB6hQKckJWOvn3z8GNO3T1zmc5HBvFF /V7mNMyBAyrZGxCiqlFQnSt/vRjP6Fl3NnSpdfGCp1X5sdTRTnWg5HkoDoqEDwUoVa61R0o3cXDY wJRAMiELQZgA7qQphdGJEP3iXLUjAiBNihDtLN5rALRaKTQhYbWqB7NHSpOiRkBAudQOidvt371T +iuO6+V1PgYpULNCOR7HBMoW5uCVPzjKWtUR6o35C9KdTfO3WqrUMnmuz6JrYlDJCTwDb2PA+j9J R7+701W1VNUct6TEMw+GRTIGSIydUrKY0zIWk5QQzRMFFFJXT1UxkRjMBhg3RBQIQ3A6h9TpdFeu dP8MZKO3P8O/KGv9NJcqP4Q/eMnQvhoLglqt6Vrgogr9sSykwG5UG/nUNiB03r2QI+iNzGADBVKy IAdqkhS3jJacTGNmBYEy6q1hUNTRF4eKxeX2JoPOjqelhRvD2SqoQneT39WfZIfEOR/JPetzH00r NZLkgwHQhRapz2scnHUO4CGyGCycFq1X9E+3bzpdX8dfOn4RWG9anQ6DmQ363kCbF9A7mq67d8E3 2rxg2taWZ0PV+2j5L6OiiTTCQCueb15jFfJkYnfolHXAzqfQcWInDEkK2gfb9SwDYoCSh9/DPmQT zDSaWHJqICG4QUDWHvDxgCgtLNHJT+MJnIdI/nF1fgoaIuk/b4qU0/xJ8nY1LHV4/cXgfc+YTuaB Hz4+L87UnXTN2Z11VBffq6xhJkJF65Do3WTIXujDGzwAimerhA77q79+JAD6DCSSe+wzxBuYVVVW VW6nCg1LZeAiugUREx2XzKsgQwFFq8ssGwj0jRuig/+ZALw0nwfeX2h+X7/gKFWErB07A6HKoHUw Zx7dF1kzrwTRQsC7EhtJjbU0te4HIbqCImKAEfBQ4sxzzDQMsu0rc/l/SVbZ+mN9dK9L2flhr9ap lVLaaUJVsaTF87Zv+DeZE6JyY0rpRQrZHZIpFn+Cr+VLOcrhu3W8abp9Q/IZQls2w2s1J9xRXRPr udQh8zjnXTv7uh7md9T0qBqbnGDxk4ApGAdgQkNG624NeHnYxOvl3ZZL/c3E+eX4gVEbvmL1D8wg UbfP0quKNr6T1XTjPfA6mcODJ0fBSdE7MkMiuTYvzbfj42yQQfMopCUhlyzZUkLVt35jQGVBuscW bGgXCQMTImCpnGXImKLzgS7xWMCYuhKqhJBLxGY0BY0cKCVozO54JrQI1wzhhQYiQQgCA2zsfN6e 8641u+JZzzqrXa5q30fbNFV54UFUUrFFVQLDxPdy6oI5ta1sW6v61ttvT7qyXfVepFUUivtoCq1P VFXGJRSapu96qxO3QdQ+gc+fYIvv5msmKBbjmFhsFIpCbamlACBeaM4WpiWlYateLgQxNpZ5wkia yPtQeuA7nG3GiZHsGqbl8Jn3vT2y0B52Q4KJ9gNwz9DNcySTTko9zikxQINwBzWhnt8YQQqedNvO DbPdLxp+dzP26b56R+0VPRy6v1vLqBW+zZsxCZCSCRJB5iNDsda999OOpxl0KC+ZUTol4czHBdqm hTXyRdz16yq/Y+f679mKVvRRwRgjXdoAGj4PsUbGXvqlTl6Hxk312OkJZDRLqQdQtt0XHoQBLxzO +X6OxEhxAQL1BN9U0odH2TshNl1Txv22IL2JRJ7e8nx2igiJjBH1i9Plr+vn6zbx3kuey+a2syNH vAah4UQaCG83LANoGvFhR82ny59tia2aTEJZVEDS4UOqW7Dj5ks3yaHiS2lsDZTnZ5HR6PfTo2O/ jZlOlrTX8YQIEl981m626VkuIIK02IcE6gQmw4KEFHSIAJAJGt1SsjaKzaiis0C0QEIREhFCDICM kRkiIRZIOVvi1Xql9jA0dACG5AvbVcb1eC6iQaoLWwxjWlNN9NYoaxJAUGJIKFUOsC7u9A0wZ+eB f00dGm6GKTLoDSZwfqKqB0z6trWAur1tQLg0QUvTAWgBZAhIpPk7en6pgmYtrSN4eyqkY8kkV7nG WNG3o29nvjWcFQ0vC9ZjEuyAVYe55yhZonVC6+aKAQhgAZgwKmEQeBEZq6mAKykBInILxkf2RTBD KVLIcHY65EwO5RRA5gRqNBxjmyru+c9w8aYzwogWM/iwGZkDsAJAkvwoEDCFQDV+FmEMOHYf06Px fQbP2ENzEJDzShRmSHZNUVe+jIyGnRdeCgO3Sr7WIAlnhQqghKABQXT38JqAhExhDTpp76O7rNH0 xO/ClUokgFQhvgxOSc+DzDgXQwoJwSMmmvSOHM9ZM+BdLJTokiQAACUAT2LCSXKOUVPPsiKiUFFC qqoi1VKt6rZVKqXKRQqlVVVVWsyHEA/E9tNFG8Wnqz6D+0KwRYEF7H5R7hwYNqWvMO58bgIraWqB NpaHjzt8Zck+E02seAz75LMfGovY6IZyBD4+thVUdD4IQhCSthv34ISTDacPR4ORbH9TU1HmJsl0 UAwBmnmHz0emmvfC7Z3s3PROx8iIKj3BQOfXOmm3W/eaTOnGPfffX1XnpnO501lvdBoD0dn4cqHz Eu/dHV1iKyquZopTEslNDUaGGhpaGVfH4ap8uxuRD4mJIBnD+z3TqSOpMLYMgGCFFBPW9kMzpFFU zNVitCIZg3Bzmk92r6GzHxfCaIIwE5BLAe6lJGLAujmFECODnQxfcLeel4OgbwzoTU+o9+nPCJqH 1GZzQKtdaBzUUJHqeJ25xzYYuimIAoL4gCgtcpIGSWJea9P2NhQMZjZasWCVRKRQWLw89tB3Y+Rk JAPqCCo5flIKBE4T8j5ND2nX6nnQfsfgzt89vR66BN7Pi6DQNIBhsz3STiR0ygq5+O1ZztSpF1IE QeUUmCcIgAdnrWepADLIBD2hJCjsHQ248ECAnv0M4QwfzdxsugCVM2KQyYTXIpVwLbBMHcwJf5yi QnBsFxKBqAconFBbuGhsUS5Gy6KjI61V6mbcGoQpkwgh4Mmn3BSBRGe3Qq9ySo7cScjQX0DJ1obM FwlUbRb9eHQgbdtEsL8/WvExj4rqACgt7HJk041vPnP4xR0zzx0Rcg9zrKYY4EpQYZvajQWUCKeY q9c7xGZFI7uve6qr404lStjYMYxguonQF+D13vbNGOHQvvkMX1nJVhNhfRpzm9dQEODYcQtMZzrZ 222D6x2ej51UnRmbQy6GLGFJ3YxZeC+PjJbB4aFaOgN1s6JupWIthHTGBJRkjolMUFUWIsRqoUIN VTUZa6bZBEUUpomhDu/hb5hCEIIiJPoNtJB9HAFnYMVsNHsY+w/u9IaHn/wBD0b/Dz9DnYyniqCB vCFc+kuG5mB0NmHqSCFENhoLYruJnIwdRbrtlJBv/ei3PiEKvM8E5Ag1Dpk1/FNsx153C2vlDs7D 5KpPgVD8RLFHIHTj7GYYmmxzCXuiWfdBD8wofcm+nTrZ4Q+IdXoAAeXK7BhC8ZbZYABTZYb6BiB3 wN2SiA0CgYDRDxdICyCGrslgYERVUiisQXq1BVYhAkhL04iMgaYoZkI2W16yURuf32hQXcidGmCG UVck8JhKrBVZREv6n2kJ90/QUDXp369r1QWGxTJj0CmIoK+CIIPwO/bQs5NROBQOQBPe2QPpvNj7 bhd6T66+2DB6wG/kw7Cz6dtj6GSucj28iiInT33hInIQeBVs5PmiCC/8XckU4UJAtdPWKA== --------------Boundary-00=_NT2I35W7KT0YHATO3893-- From owner-linux-xfs@oss.sgi.com Mon Jun 25 12:26:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PJQJf05036 for linux-xfs-outgoing; Mon, 25 Jun 2001 12:26:19 -0700 Received: from citadel.oehansen.pp.se (sdu81-234.ppp.algonet.se [195.163.234.81]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PJQHV05033 for ; Mon, 25 Jun 2001 12:26:18 -0700 Received: from citadel.oehansen.pp.se (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f5PJRlY02483 for ; Mon, 25 Jun 2001 21:27:51 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se To: linux-xfs@oss.sgi.com Subject: double error Date: Mon, 25 Jun 2001 21:27:47 +0200 X-Mailer: KMail [version 1.2] References: <200106251526.f5PFQuu15808@jen.americas.sgi.com> <01062521152305.01265@citadel.oehansen.pp.se> In-Reply-To: <01062521152305.01265@citadel.oehansen.pp.se> X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sorry about the double post, that was due to network error... From owner-linux-xfs@oss.sgi.com Mon Jun 25 12:49:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PJncZ05451 for linux-xfs-outgoing; Mon, 25 Jun 2001 12:49:38 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PJnaV05448 for ; Mon, 25 Jun 2001 12:49:36 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id VAA15216; Mon, 25 Jun 2001 21:49:26 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id VAA29507; Mon, 25 Jun 2001 21:49:26 +0200 (CEST) Date: Mon, 25 Jun 2001 21:49:26 +0200 (CEST) From: Seth Mos To: Todd Berendes cc: linux-xfs@oss.sgi.com, Denise Berendes Subject: Re: New Redhat 7.1 kernel patch In-Reply-To: <3B3766F7.449B6499@nsstc.uah.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 25 Jun 2001, Todd Berendes wrote: > Hi, > > Just last week Red Hat released a kernel patch which fixes a bunch > of fairly major problems. We need that patch primarily to fix the > IRIX NFS server bug #36897. > ( http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=36897 ) > > We have already installed the SGI XFS installer disk on our systems > and do not want to undo any of that by installing Red Hat's patch. > > Someone has already released an NFS patched XFS installer disk at > ftp://ftp.crc.dk/pub/rh71irixnfspatch with a "use at own risk" > warning. > > Are you planning to release an update of your installer and patch > RPM's using the new patched kernel anytime soon? They are working on the 1.0.1 release which will be 2.4.5 based and a lot better in stablity. It's "just around the corner". > Any idea when the XFS patches will be integrated into the standard > kernel and/or when RedHat will ship it? See FAQ for kernel inclusion policy, there are distributions around that might include it. So far the score is a RedHat 7.1 installer, Mandrake 8 kernels and possible inclusion, debian also has the patches floating around as debian packages and beta install disks, slackware has some test bootdisks (should add link to faq) and SuSE also seems to be slumbering on the list. > We were very happy to find XFS available for Linux. We have a number > of SGI's using XFS and have been very pleased with the filesystem. > > Keep up the good work! Nice to hear, we will. From owner-linux-xfs@oss.sgi.com Mon Jun 25 13:16:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PKGpO05956 for linux-xfs-outgoing; Mon, 25 Jun 2001 13:16:51 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PKGoV05953 for ; Mon, 25 Jun 2001 13:16:50 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15EcmZ-00017A-00; Tue, 26 Jun 2001 08:16:27 +1200 Date: Tue, 26 Jun 2001 08:16:26 +1200 (NZST) From: Juha Saarinen To: Mike Burger cc: "linux-xfs@oss.sgi.com" Subject: Re: your mail In-Reply-To: Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 25 Jun 2001, Mike Burger wrote: > How is one supposed to embark upon a journey of NTFS5 under Linux. With very great difficulty, I expect ;-). -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Mon Jun 25 13:17:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PKHXo06055 for linux-xfs-outgoing; Mon, 25 Jun 2001 13:17:33 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PKHWV06051 for ; Mon, 25 Jun 2001 13:17:32 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA12313 for ; Mon, 25 Jun 2001 13:17:27 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2258111 for ; Mon, 25 Jun 2001 15:16:16 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA07946 for ; Mon, 25 Jun 2001 15:16:15 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f5PKIbr17778; Mon, 25 Jun 2001 15:18:37 -0500 Message-Id: <200106252018.f5PKIbr17778@jen.americas.sgi.com> Date: Mon, 25 Jun 2001 15:18:37 -0500 Subject: TAKE - fix du and ls -s output on directories Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The block count on a directory can get out of date when we expand it so that it uses more blocks. The size and link count were correct, but the block count was wedged unless the inode got re-read from disk. Date: Mon Jun 25 13:12:14 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:97629a linux/fs/xfs/xfs_vnodeops.c - 1.505 - reorder xfs_getattr a little so we can get the blockcount of a directory cheaply. linux/fs/xfs/linux/xfs_iops.c - 1.110 - Add the count of blocks to the fields updated in a directory when we do a directory op within it. From owner-linux-xfs@oss.sgi.com Mon Jun 25 13:18:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PKIOr06157 for linux-xfs-outgoing; Mon, 25 Jun 2001 13:18:24 -0700 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PKINV06154 for ; Mon, 25 Jun 2001 13:18:23 -0700 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 15:17:30 -0500 Message-ID: <85063BBE668FD411944400D0B744267A481AED@AUSMAIL> From: "Gonyou, Austin" To: linux-xfs@oss.sgi.com Subject: Installing RH 7.1 XFS from a network using a floppy Date: Mon, 25 Jun 2001 15:17:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is that possible? Does it work ok with the 1.0 release or will I have to do something else? -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com From owner-linux-xfs@oss.sgi.com Mon Jun 25 13:21:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PKLbe06309 for linux-xfs-outgoing; Mon, 25 Jun 2001 13:21:37 -0700 Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PKLaV06306 for ; Mon, 25 Jun 2001 13:21:36 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id A666B139A4; Mon, 25 Jun 2001 16:21:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id A3A99139A3; Mon, 25 Jun 2001 16:21:41 -0400 (EDT) Date: Mon, 25 Jun 2001 16:21:41 -0400 (EDT) From: Mike Burger To: Juha Saarinen Cc: "linux-xfs@oss.sgi.com" Subject: Re: your mail In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk As do I. On Tue, 26 Jun 2001, Juha Saarinen wrote: > On Mon, 25 Jun 2001, Mike Burger wrote: > > > How is one supposed to embark upon a journey of NTFS5 under Linux. > > With very great difficulty, I expect ;-). > > > From owner-linux-xfs@oss.sgi.com Mon Jun 25 13:22:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PKMpt06430 for linux-xfs-outgoing; Mon, 25 Jun 2001 13:22:51 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PKMoV06427 for ; Mon, 25 Jun 2001 13:22:50 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA02328 for ; Mon, 25 Jun 2001 13:19:59 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2253178; Mon, 25 Jun 2001 15:21:32 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA47269; Mon, 25 Jun 2001 15:21:32 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5PKNrE17812; Mon, 25 Jun 2001 15:23:53 -0500 Message-Id: <200106252023.f5PKNrE17812@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Gonyou, Austin" cc: linux-xfs@oss.sgi.com Subject: Re: Installing RH 7.1 XFS from a network using a floppy In-Reply-To: Message from "Gonyou, Austin" of "Mon, 25 Jun 2001 15:17:29 CDT." <85063BBE668FD411944400D0B744267A481AED@AUSMAIL> Date: Mon, 25 Jun 2001 15:23:53 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Is that possible? Does it work ok with the 1.0 release or will I have to do > something else? It works just fine, there are some instructions in the release notes for redhat. I think you have to copy all the cds into a single directory structure and nfs export it. You then need the network inst image bootnet.img on a floppy. This is how I do all my installs. Steve > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-796-9023 > email: austin@coremetrics.com From owner-linux-xfs@oss.sgi.com Mon Jun 25 13:22:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PKMtO06488 for linux-xfs-outgoing; Mon, 25 Jun 2001 13:22:55 -0700 Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PKMsV06476 for ; Mon, 25 Jun 2001 13:22:54 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id 681B9139A4; Mon, 25 Jun 2001 16:23:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id 65638139A3; Mon, 25 Jun 2001 16:23:00 -0400 (EDT) Date: Mon, 25 Jun 2001 16:23:00 -0400 (EDT) From: Mike Burger To: "Gonyou, Austin" Cc: Subject: Re: Installing RH 7.1 XFS from a network using a floppy In-Reply-To: <85063BBE668FD411944400D0B744267A481AED@AUSMAIL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'd imagine that you'd need to use the same procedure you'd use to install the non-XFS version of 7.1. Create the bootnet floppy, and make sure that your 7.1 CD or install file directory structure is available via NFS, HTTP or FTP. On Mon, 25 Jun 2001, Gonyou, Austin wrote: > Is that possible? Does it work ok with the 1.0 release or will I have to do > something else? > > From owner-linux-xfs@oss.sgi.com Mon Jun 25 13:23:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PKNFU06616 for linux-xfs-outgoing; Mon, 25 Jun 2001 13:23:15 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PKNFV06613 for ; Mon, 25 Jun 2001 13:23:15 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA02285 for ; Mon, 25 Jun 2001 13:20:23 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2252459; Mon, 25 Jun 2001 15:21:57 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA11500; Mon, 25 Jun 2001 15:21:57 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5PKOIE17818; Mon, 25 Jun 2001 15:24:18 -0500 Message-Id: <200106252024.f5PKOIE17818@jen.americas.sgi.com> To: Juha Saarinen cc: Mike Burger , "linux-xfs@oss.sgi.com" Subject: Re: your mail References: Comments: In-reply-to Juha Saarinen message dated "Tue, 26 Jun 2001 08:16:26 +1200." Date: Mon, 25 Jun 2001 15:24:18 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Mon, 25 Jun 2001, Mike Burger wrote: > > > How is one supposed to embark upon a journey of NTFS5 under Linux. > > With very great difficulty, I expect ;-). Well, I am sure Win2K will be happy to blow linux off your harddrive, but apart from that..... Steve From owner-linux-xfs@oss.sgi.com Mon Jun 25 13:23:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PKNIm06649 for linux-xfs-outgoing; Mon, 25 Jun 2001 13:23:18 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PKNHV06637 for ; Mon, 25 Jun 2001 13:23:17 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA09627 for ; Mon, 25 Jun 2001 13:20:26 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2259473; Mon, 25 Jun 2001 15:22:00 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA61047; Mon, 25 Jun 2001 15:22:00 -0500 (CDT) Message-ID: <3B379D3F.C246E636@sgi.com> Date: Mon, 25 Jun 2001 15:21:19 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Gonyou, Austin" CC: linux-xfs@oss.sgi.com Subject: Re: Installing RH 7.1 XFS from a network using a floppy References: <85063BBE668FD411944400D0B744267A481AED@AUSMAIL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Gonyou, Austin" wrote: > > Is that possible? Does it work ok with the 1.0 release or will I have to do > something else? Yes, it works. Follow the instructions from Red Hat on setting up a network install source, and just copy over the SGI CDROM files last, so they overwrite any original Red Hat files - should work fine, we've used it here several times. -Eric From owner-linux-xfs@oss.sgi.com Mon Jun 25 13:23:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PKNnl06802 for linux-xfs-outgoing; Mon, 25 Jun 2001 13:23:49 -0700 Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PKNlV06799 for ; Mon, 25 Jun 2001 13:23:47 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id 809EE139A4; Mon, 25 Jun 2001 16:23:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id 7B0BE139A3; Mon, 25 Jun 2001 16:23:53 -0400 (EDT) Date: Mon, 25 Jun 2001 16:23:53 -0400 (EDT) From: Mike Burger To: Steve Lord Cc: Juha Saarinen , "linux-xfs@oss.sgi.com" Subject: Re: your mail In-Reply-To: <200106252024.f5PKOIE17818@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk No thanks...I'll keep my Linux setup, and leave Win2K to the masochists out there. On Mon, 25 Jun 2001, Steve Lord wrote: > > On Mon, 25 Jun 2001, Mike Burger wrote: > > > > > How is one supposed to embark upon a journey of NTFS5 under Linux. > > > > With very great difficulty, I expect ;-). > > Well, I am sure Win2K will be happy to blow linux off your harddrive, > but apart from that..... > > Steve > > From owner-linux-xfs@oss.sgi.com Mon Jun 25 13:25:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PKPai06905 for linux-xfs-outgoing; Mon, 25 Jun 2001 13:25:36 -0700 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PKPZV06902 for ; Mon, 25 Jun 2001 13:25:35 -0700 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 15:24:41 -0500 Message-ID: <85063BBE668FD411944400D0B744267A481AEE@AUSMAIL> From: "Gonyou, Austin" To: "'Mike Burger'" , "Gonyou, Austin" Cc: linux-xfs@oss.sgi.com Subject: RE: Installing RH 7.1 XFS from a network using a floppy Date: Mon, 25 Jun 2001 15:24:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk So do I need to use the RH 7.1 Disk1 XFS installer cd to do the boot-net? Also do I need to copy the RPMS from the XFS RH7.1 install cd into my dir tree for the rest of the rpms? Thanks in advance. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Mike Burger [mailto:mburger@compucomis.net] > Sent: Monday, June 25, 2001 3:23 PM > To: Gonyou, Austin > Cc: linux-xfs@oss.sgi.com > Subject: Re: Installing RH 7.1 XFS from a network using a floppy > > > I'd imagine that you'd need to use the same procedure you'd > use to install > the non-XFS version of 7.1. Create the bootnet floppy, and > make sure that > your 7.1 CD or install file directory structure is available > via NFS, HTTP > or FTP. > > On Mon, 25 Jun 2001, Gonyou, Austin wrote: > > > Is that possible? Does it work ok with the 1.0 release or > will I have to do > > something else? > > > > > From owner-linux-xfs@oss.sgi.com Mon Jun 25 13:29:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PKTdj07037 for linux-xfs-outgoing; Mon, 25 Jun 2001 13:29:39 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PKTbV07033 for ; Mon, 25 Jun 2001 13:29:37 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA194209 for ; Mon, 25 Jun 2001 22:29:34 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2258865; Mon, 25 Jun 2001 15:28:18 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA59062; Mon, 25 Jun 2001 15:28:18 -0500 (CDT) Message-ID: <3B379EB8.9734D57F@sgi.com> Date: Mon, 25 Jun 2001 15:27:36 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Gonyou, Austin" CC: linux-xfs@oss.sgi.com Subject: Re: Installing RH 7.1 XFS from a network using a floppy References: <85063BBE668FD411944400D0B744267A481AEE@AUSMAIL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Gonyou, Austin" wrote: > > So do I need to use the RH 7.1 Disk1 XFS installer cd to do the boot-net? > Also do I need to copy the RPMS from the XFS RH7.1 install cd into my dir > tree for the rest of the rpms? Thanks in advance. yes, make your boot floppy from the SGI cd. And also yes, you need all the RPMs from the original 2 Red Hat discs as well, the SGI disc only contains the files & packages that were changed to support XFS. -Eric From owner-linux-xfs@oss.sgi.com Mon Jun 25 13:40:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PKeCG07413 for linux-xfs-outgoing; Mon, 25 Jun 2001 13:40:12 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PKeAV07410 for ; Mon, 25 Jun 2001 13:40:10 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15Ed9O-00018A-00; Tue, 26 Jun 2001 08:40:02 +1200 Date: Tue, 26 Jun 2001 08:40:02 +1200 (NZST) From: Juha Saarinen To: Eric Sandeen cc: Todd Berendes , "linux-xfs@oss.sgi.com" , Denise Berendes Subject: Re: New Redhat 7.1 kernel patch In-Reply-To: <3B3774D0.7B812B77@sgi.com> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 25 Jun 2001, Eric Sandeen wrote: > Yep, working on it as we speak... for the 1.0.1 release. Is the stuff in the CVS already? -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Mon Jun 25 13:46:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PKksC07929 for linux-xfs-outgoing; Mon, 25 Jun 2001 13:46:54 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PKksV07924 for ; Mon, 25 Jun 2001 13:46:54 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA05724 for ; Mon, 25 Jun 2001 13:44:02 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2251699; Mon, 25 Jun 2001 15:45:37 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA62299; Mon, 25 Jun 2001 15:45:37 -0500 (CDT) Message-ID: <3B37A2C6.A67EC827@sgi.com> Date: Mon, 25 Jun 2001 15:44:54 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Juha Saarinen CC: "linux-xfs@oss.sgi.com" Subject: Re: New Redhat 7.1 kernel patch References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juha Saarinen wrote: > > On Mon, 25 Jun 2001, Eric Sandeen wrote: > > > Yep, working on it as we speak... for the 1.0.1 release. > > Is the stuff in the CVS already? The Red Hat Linux-specific stuff doesn't really have a place in CVS, since we only have the vanilla tree there... I'll probably make a directory to dump RH-specific patches into, though, for posterity. I should have RPMs for the new RH kernel out for ftp tomorrow, if all goes well. -Eric From owner-linux-xfs@oss.sgi.com Mon Jun 25 13:52:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PKqhC08449 for linux-xfs-outgoing; Mon, 25 Jun 2001 13:52:43 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PKqfV08446 for ; Mon, 25 Jun 2001 13:52:42 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15EdLV-00018W-00; Tue, 26 Jun 2001 08:52:33 +1200 Date: Tue, 26 Jun 2001 08:52:33 +1200 (NZST) From: Juha Saarinen To: Eric Sandeen cc: "linux-xfs@oss.sgi.com" Subject: Re: New Redhat 7.1 kernel patch In-Reply-To: <3B37A2C6.A67EC827@sgi.com> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 25 Jun 2001, Eric Sandeen wrote: > The Red Hat Linux-specific stuff doesn't really have a place in CVS, > since we only have the vanilla tree there... I'll probably make a > directory to dump RH-specific patches into, though, for posterity. I'm not sure about this... tracking "pukka" kernels for the CVS, and patching RH's for the RPM version. Since Linux XFS is based on RH's distro, wouldn't it make more sense to work with just RH's kernels? I guess it's possible to manually add the RH patches though. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Mon Jun 25 13:58:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PKwVF08873 for linux-xfs-outgoing; Mon, 25 Jun 2001 13:58:31 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PKwVV08870 for ; Mon, 25 Jun 2001 13:58:31 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA03765 for ; Mon, 25 Jun 2001 13:55:40 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2176887; Mon, 25 Jun 2001 15:57:14 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA63220; Mon, 25 Jun 2001 15:57:14 -0500 (CDT) Message-ID: <3B37A581.5D0F333F@sgi.com> Date: Mon, 25 Jun 2001 15:56:33 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Juha Saarinen CC: "linux-xfs@oss.sgi.com" Subject: Re: New Redhat 7.1 kernel patch References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juha Saarinen wrote: > I'm not sure about this... tracking "pukka" kernels for the CVS, and > patching RH's for the RPM version. > > Since Linux XFS is based on RH's distro, wouldn't it make more sense to > work with just RH's kernels? I guess it's possible to manually add the > RH patches though. Linux XFS is _not_ based on RH's distro, that's just one convenient way that we package it for the masses. :) XFS development has always been based on Linus' tree. Red Hat RPMs are just a "fun" (?!) side project for Linux XFS. -Eric From owner-linux-xfs@oss.sgi.com Mon Jun 25 14:01:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PL1nl09250 for linux-xfs-outgoing; Mon, 25 Jun 2001 14:01:49 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PL1mV09246 for ; Mon, 25 Jun 2001 14:01:48 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA10275; Mon, 25 Jun 2001 23:01:46 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA04832; Mon, 25 Jun 2001 23:01:46 +0200 (CEST) Date: Mon, 25 Jun 2001 23:01:46 +0200 (CEST) From: Seth Mos To: "Gonyou, Austin" cc: linux-xfs@oss.sgi.com Subject: Re: Installing RH 7.1 XFS from a network using a floppy In-Reply-To: <85063BBE668FD411944400D0B744267A481AED@AUSMAIL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 25 Jun 2001, Gonyou, Austin wrote: > Is that possible? Does it work ok with the 1.0 release or will I have to do > something else? It should work. are uou using a local source for the install like ftp or nfs? Or do you intend to do it over the internet? From owner-linux-xfs@oss.sgi.com Mon Jun 25 14:02:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PL2Je09382 for linux-xfs-outgoing; Mon, 25 Jun 2001 14:02:19 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PL2HV09375 for ; Mon, 25 Jun 2001 14:02:18 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15EdUo-00019n-00; Tue, 26 Jun 2001 09:02:10 +1200 Date: Tue, 26 Jun 2001 09:02:10 +1200 (NZST) From: Juha Saarinen To: Eric Sandeen cc: "linux-xfs@oss.sgi.com" Subject: Re: New Redhat 7.1 kernel patch In-Reply-To: <3B37A581.5D0F333F@sgi.com> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 25 Jun 2001, Eric Sandeen wrote: > Linux XFS is _not_ based on RH's distro, that's just one convenient way > that we package it for the masses. :) XFS development has always been > based on Linus' tree. > > Red Hat RPMs are just a "fun" (?!) side project for Linux XFS. Aiiee... OK, lemme rephrase the question, your honour: if I would like to set up an XFS server, which part should I go with? As it is, won't most people use the "RH XFS" version, ie. install from the ISOs? -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Mon Jun 25 14:09:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PL9n410008 for linux-xfs-outgoing; Mon, 25 Jun 2001 14:09:49 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PL9lV09997 for ; Mon, 25 Jun 2001 14:09:47 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA195189 for ; Mon, 25 Jun 2001 23:09:45 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2258339; Mon, 25 Jun 2001 16:08:28 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA63053; Mon, 25 Jun 2001 16:08:28 -0500 (CDT) Message-ID: <3B37A822.15A160F9@sgi.com> Date: Mon, 25 Jun 2001 16:07:46 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Juha Saarinen CC: "linux-xfs@oss.sgi.com" Subject: Re: New Redhat 7.1 kernel patch References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juha Saarinen wrote: > Aiiee... OK, lemme rephrase the question, your honour: if I would like to > set up an XFS server, which part should I go with? Hard to say what is best for you - the "pure" linux tree (in this case 2.4.5) is probably most tested internally at SGI, since that's what we use every day. If you need the added features (and bugfixes) in the Red Hat kernels, you can grab our xfs-enabled versions of those. FWIW, oss.sgi.com is running the Red Hat-based XFS kernels. > As it is, won't most people use the "RH XFS" version, ie. install from the > ISOs? Only people who want to use Red Hat. :) Everyone else will probably want to use the patches, at least until the fine folks who have done slack/debian/mandrake/suse packaging catch up with the 1.0.1 release. -Eric From owner-linux-xfs@oss.sgi.com Mon Jun 25 14:13:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PLDxH10364 for linux-xfs-outgoing; Mon, 25 Jun 2001 14:13:59 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PLDvV10359 for ; Mon, 25 Jun 2001 14:13:58 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id XAA12442; Mon, 25 Jun 2001 23:13:56 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA05653; Mon, 25 Jun 2001 23:13:51 +0200 (CEST) Date: Mon, 25 Jun 2001 23:13:51 +0200 (CEST) From: Seth Mos To: Juha Saarinen cc: Eric Sandeen , "linux-xfs@oss.sgi.com" Subject: Re: New Redhat 7.1 kernel patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 26 Jun 2001, Juha Saarinen wrote: > On Mon, 25 Jun 2001, Eric Sandeen wrote: > > > Linux XFS is _not_ based on RH's distro, that's just one convenient way > > that we package it for the masses. :) XFS development has always been > > based on Linus' tree. > > > > Red Hat RPMs are just a "fun" (?!) side project for Linux XFS. > > Aiiee... OK, lemme rephrase the question, your honour: if I would like to > set up an XFS server, which part should I go with? Depends on what you are installing. RedHat works with the -ac tree but most other distributions work with vanilla trees as a starting point. The linus tree in general is the starting point for most distributions kernel. If you make a patch for that it becomes obviously easier to let other distros use the XFS patches. Let's just say that it makes the sharing easier. > As it is, won't most people use the "RH XFS" version, ie. install from the > ISOs? They will, but there are also a lot of people out there like me that rather have a linus tree with XFS on top. I can see on lkml if a kernel has specific problems and that I can expect them too. If I then look at what the redhat kernel looks like, I don't know what problems are related to which of the 240 patches. It's probably more about personal prefence in the end, and if it works? Great! Blah Seth From owner-linux-xfs@oss.sgi.com Mon Jun 25 14:53:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PLrgp14634 for linux-xfs-outgoing; Mon, 25 Jun 2001 14:53:42 -0700 Received: from citadel.oehansen.pp.se (sdu108-205.ppp.algonet.se [195.163.205.108]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PLrcV14628 for ; Mon, 25 Jun 2001 14:53:40 -0700 Received: from citadel.oehansen.pp.se (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f5PLspY03476; Mon, 25 Jun 2001 23:54:51 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se To: Mike Burger Subject: Re: your mail Date: Mon, 25 Jun 2001 23:54:51 +0200 X-Mailer: KMail [version 1.2] References: In-Reply-To: Cc: linux-xfs@oss.sgi.com X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 X-MIME-Autoconverted: from 8bit to quoted-printable by citadel.oehansen.pp.se id f5PLspY03476 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5PLrfV14630 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk mánudagur 25. júní 2001 22:23, þú skrifaðir: > No thanks...I'll keep my Linux setup, and leave Win2K to the masochists > out there. > masochist? Maybe I'd better format my win2k partition over, and start getting some Windows eXperienSe From owner-linux-xfs@oss.sgi.com Mon Jun 25 15:04:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PM4Hj16485 for linux-xfs-outgoing; Mon, 25 Jun 2001 15:04:17 -0700 Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PM4FV16479 for ; Mon, 25 Jun 2001 15:04:16 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id 57520139A4; Mon, 25 Jun 2001 18:04:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id 548A5139A3; Mon, 25 Jun 2001 18:04:21 -0400 (EDT) Date: Mon, 25 Jun 2001 18:04:21 -0400 (EDT) From: Mike Burger To: "Orn E. Hansen" Cc: Subject: Re: your mail In-Reply-To: <01062523540500.03069@citadel.oehansen.pp.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk There you go...let the masochism really begin. On Mon, 25 Jun 2001, Orn E. Hansen wrote: > mánudagur 25. júní 2001 22:23, þú skrifaðir: > > No thanks...I'll keep my Linux setup, and leave Win2K to the masochists > > out there. > > > masochist? > > Maybe I'd better format my win2k partition over, and start getting some > Windows eXperienSe > > > > From owner-linux-xfs@oss.sgi.com Mon Jun 25 15:06:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PM6xC16986 for linux-xfs-outgoing; Mon, 25 Jun 2001 15:06:59 -0700 Received: from isis.telemach.net (isis.telemach.net [213.143.65.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PM6vV16969 for ; Mon, 25 Jun 2001 15:06:57 -0700 Received: from telemach.net (TM-68-212.cable.telemach.net [213.143.68.212]) by isis.telemach.net (Postfix) with ESMTP id 64B487A10B; Tue, 26 Jun 2001 00:06:54 +0200 (CEST) Message-ID: <3B37B5FD.79B70CAF@telemach.net> Date: Tue, 26 Jun 2001 00:06:53 +0200 From: Jure Pecar Organization: Select Technology X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com, nfs@lists.sourceforge.net Subject: nfs lockups with xfs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi list, I'm expiriencig some yet-to-be-determined problems using xfs with nfs, on two different boxen in two different setups. 1. Redhat71, 2.4.2-2+xfs kernel and other relevant xfs RPMs from oss.sgi.com ftp; two 180gb scsi disks in raid1; stock rh71 nfs-utils rpm. Client is solaris7. Mount works ok, copying files back and forth works ok, then, after some time, nfs dies ('nfs server not responding' in solaris logs) altough there are no error msgs in redhat logs. Restarting nfs service on redhat does not make any difference for the current stalled mount on solaris. 2. Redhat71, 2.4.5-0.2.9+xfs rawhide kernel and other relevant xfs RPMs; raid5 array of 8 ide disks hanging on 3ware card; stock rh71 nfs-utils rpm. Client is OpenBSD 2.9. Mount works (v3, udp), for testing i tried to copy a whole openbsd cvs tree to the nfs server. About 220mb was copied over, then the server hung; couldn't ssh to it, didn't respond to console input, but ping worked. I rebooted it, exported an ext2 partition, mounted it on openbsd and succesfully copied cvs tree back and forth a couple of times. Then I exported the xfs partition again, tried the same copy, got another lockup. No msgs in the logs, no kdb, nothing. Both servers are using intel NICs with intel's e100 v1.6.6 driver. While the second setup always near me, I can only access first setup via ssh. I know that people are running xfs with success on production fileservers, so i'd prefer to think it's me doing something wrong. But both setups are basic stuff, without any fancy nfs export or mount options. I'd like to figure out what exactly is the problem here and who's to blame :) Just finishing the mail, something popped up on the nfs server's console here: Kernel panic: kmem_zone_zalloc: NULL memory on KM_SLEEP request! ... that would be? Thanks for any help. -- Jure Pecar From owner-linux-xfs@oss.sgi.com Mon Jun 25 15:21:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PMLAK19093 for linux-xfs-outgoing; Mon, 25 Jun 2001 15:21:10 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PMLAV19089 for ; Mon, 25 Jun 2001 15:21:10 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA01679 for ; Mon, 25 Jun 2001 15:21:04 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2258868 for ; Mon, 25 Jun 2001 17:19:53 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA64968 for ; Mon, 25 Jun 2001 17:19:53 -0500 (CDT) Message-ID: <3B37B8DF.8A008F3D@sgi.com> Date: Mon, 25 Jun 2001 17:19:11 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS patches for Red Hat 2.4.3-12 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, these are very rough, they have passed the "does it boot" test, and the "does it run through QA tests without an OOPS" test. I have not done any NFS-related testing. Patches for Red Hat's latest official "2.4.3-12" kernel are in ftp://oss.sgi.com/projects/xfs/download/testing/Release-1.0.1-PR2/patches/ Apply the "patch-RH2.4.3-nfs-fixup" after the xfs-only patch, some things changed in the nfs header files in the RH kernel, and this should fix it. I'm seeing some quota -related problems, but that could be on my end, if anyone is using quotas and tests these out, let me know how it goes. I'll build RPMs overnight, if the build succeeds (!) I'll put them out tomorrow. -Eric From owner-linux-xfs@oss.sgi.com Mon Jun 25 15:38:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PMcoS21518 for linux-xfs-outgoing; Mon, 25 Jun 2001 15:38:50 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PMcnV21513 for ; Mon, 25 Jun 2001 15:38:49 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5PMchw02270 for linux-xfs@oss.sgi.com; Mon, 25 Jun 2001 18:38:43 -0400 Date: Mon, 25 Jun 2001 18:38:43 -0400 From: Alan Eldridge To: linux-xfs@oss.sgi.com Subject: unkillable process Message-ID: <20010625183843.A2197@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm seeing one anomaly with PR2, resulting in an unkillable process that is *not* in Device Wait. 1. The cdrom device: brw-rw---- 1 alane disk 11, 0 Dec 31 1969 /dev/scsi/host0/bus0/target3/lun0/cd 2. I am a member of the "disk" group. If cdda2wav is not setuid root, which I really don't want it to be, it seems, about 90% of the time, to get locked in "R" state, *not* reading the cdrom drive, using as much CPU as it can, and immune to kill -9. It's also immune to tracing ... any attempt to trace it results in strace locking up, and becoming a member of the undead also. That's pretty neat ... so not only can't you kill cdda2wav, you can't kill the strace, either. How can a process, running as a regular user, in the R state, actively spinning its wheels, be immune to a kill -9? And now can it pass that immunity on? This is *weird*. After a few seconds of cdda2wav spinning like this, the keyboard and mouse both lock up. No ctl-atl-backspace.... no nothing. Only way to clear the condition is to kill the process by the only way possible: /sbin/shutdown. Note that it does not die as part of the shutdown killall, either, but hey, a reboot is a reboot. The machine is not locked up, though, just the local input devices. I can shut it down (and this is the only way) by ssh'ing in over the LAN to issue the shutdown. OK, now for the punchline: the SCSI controller is .... an Adaptec 2930CU. Yup, it's on the aic7xxx driver. The CDRW, also on the Adaptec (at target 4), is blissfully unaffected by the hubub going on around it. It would seem that no diagnostics are possible. How can you debug an uninterruptible, non-waiting process that hangs anything trying to attach to it? This behavior does not occur on PR1, which is presumably the same except for the XFS code, right? However, this behavior is quite reproducible, for all the good that does me. -- Alan Eldridge "Smart Tags? We don't need no steenking Smart Tags!" From owner-linux-xfs@oss.sgi.com Mon Jun 25 16:01:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PN1Kb23710 for linux-xfs-outgoing; Mon, 25 Jun 2001 16:01:20 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PN1HV23700 for ; Mon, 25 Jun 2001 16:01:17 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id BAA00208 for ; Mon, 25 Jun 2001 01:07:30 -0700 (PDT) mail_from (simon.matter@ch.sauter-bc.com) Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id KAA06078; Mon, 25 Jun 2001 10:06:01 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id KAA04284; Mon, 25 Jun 2001 10:06:01 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 506D357306; Mon, 25 Jun 2001 10:15:22 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 0C34025835; Mon, 25 Jun 2001 10:23:36 +0200 (CEST) Message-ID: <3B36F1C3.7CDBB608@ch.sauter-bc.com> Date: Mon, 25 Jun 2001 10:09:39 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Eric Sandeen Cc: Alan Eldridge , Dusan , linux-xfs@oss.sgi.com Subject: Re: /dev/sound References: <20010625003153.A4433@wwweasel.geeksrus.net> <3B36C11C.A46B60F3@sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I remember tha I ran into one problem that I didn't expext. The devfs RPM on the installer CD has a different /etc/modules.devfs file than the updated RPM's from oss.sgi.com. I just wondered why the system behaved strange after upgrading the kernel and found that downgrading the devfs RPM resolved my problem. Eric Sandeen schrieb: > > Alan Eldridge wrote: > > > > These things are *not* the fault of the SGI dudes! > > Well, it WAS our (ill-advised?) decision to enable devfs in our > RPMs... FWIW, in the 1.0.1 testing RPMs, devfs is enabled, but NOT > mounted by default. That way you can edit lilo.conf to get devfs if you > want it, otherwise you get your good old familiar 10,000-entry > inode-eating on-disk /dev. And maybe we'll be able to stop talking > about devfs on this list in 6 months or so. :) > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. -- 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 Mon Jun 25 16:04:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PN42Z24013 for linux-xfs-outgoing; Mon, 25 Jun 2001 16:04:02 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PN41V24010 for ; Mon, 25 Jun 2001 16:04:01 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA05826 for ; Mon, 25 Jun 2001 14:32:58 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2261249 for ; Mon, 25 Jun 2001 16:31:42 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA20814 for ; Mon, 25 Jun 2001 16:31:35 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f5PLXub18227; Mon, 25 Jun 2001 16:33:56 -0500 Message-Id: <200106252133.f5PLXub18227@jen.americas.sgi.com> Date: Mon, 25 Jun 2001 16:33:56 -0500 Subject: TAKE - another realtime fix Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk With this change you can actually really do I/O to the realtime device, provided you have the correct user space incantations.... Even buffered I/O appears to work, which is more than you can say for the Irix version! I would treat this as a handle with care feature right now, it has not had much testing, xfs_check does not like the filesystem afterwards, but this may be an endian issue in xfs_check. Date: Mon Jun 25 14:28:43 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:97632a linux/fs/pagebuf/page_buf_io.c - 1.85 - More realtime device fixup From owner-linux-xfs@oss.sgi.com Mon Jun 25 16:09:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PN9Qx24493 for linux-xfs-outgoing; Mon, 25 Jun 2001 16:09:26 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PN9IV24482 for ; Mon, 25 Jun 2001 16:09:18 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA09172 for ; Mon, 25 Jun 2001 12:53:20 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2259062; Mon, 25 Jun 2001 14:51:51 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA23392; Mon, 25 Jun 2001 14:51:51 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5PJsCN17223; Mon, 25 Jun 2001 14:54:12 -0500 Message-Id: <200106251954.f5PJsCN17223@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: oe.hansen@gamma.telenordia.se cc: linux-xfs@oss.sgi.com Subject: Re: Filesystem sizes References: <200106251526.f5PFQuu15808@jen.americas.sgi.com> <01062521152305.01265@citadel.oehansen.pp.se> <200106251920.f5PJKHK16812@jen.americas.sgi.com> <01062521324608.01265@citadel.oehansen.pp.se> Comments: In-reply-to "Orn E. Hansen" message dated "Mon, 25 Jun 2001 21:32:46 +0200." Content-Transfer-Encoding: 8bit Date: Mon, 25 Jun 2001 14:54:12 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > manudagur 25. jznm 2001 21:20, ~z skrifapir: > > > > Ah, sorry I should have specified that you do this on one of the files > > which appears to be oversized after the untar, the directory itself is > > not really interesting. Sorry about that, I will go look at your output. > > The 1 minute thing is interesting I will have to think about that. > > > > Ah, but that's just it... the files are all *correct* size... It's the > *link* count in the listing that's a bit off... you can see this by taking a > diff between xfs-remount and xfs listings. They show, that each directory in > > the listing, where the sizes are too large, is due to that each directory has > > 4 links in it? Hmm, there are two things going on, one being that the size field in a directory is not getting updated when we add new entries to it. XFS allows small directories to live totally within the inode, they will show up with a 0 in the first column of ls -ls, as the directory grows, it gets too big to fit in the inode and we have to allocate a block for it. It looks like the block count field in the inode stat output is not getting updated correctly - the remount forces the upper layers to get the information from the xfs inode again. The second is that you are moving from a 1K block ext2 filesystem to a 4K block xfs filesystem. This means that any file smaller that 4K will use 4K of disk space. Summing the space usage shown by the first column of the ls output between the ext2 numbers and the xfs after remount numbers shows you went from 7813K on ext2 to 10212K on xfs. If you made a 4K block ext2 filesystem which appears to be the standard now, and untarred your archive there, the numbers would probably be a lot closer. I will go fix the block count in directories thing, it should be easy. Steve From owner-linux-xfs@oss.sgi.com Mon Jun 25 16:12:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PNCqW24847 for linux-xfs-outgoing; Mon, 25 Jun 2001 16:12:52 -0700 Received: from mail.spylog.com (mail.spylog.com [194.67.35.220]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PNCoV24838 for ; Mon, 25 Jun 2001 16:12:51 -0700 Received: from an.local (an.local [192.168.4.50]) by mail.spylog.com (Postfix) with ESMTP id DB0212C2A5; Tue, 26 Jun 2001 03:12:44 +0400 (MSD) Received: by an.local (Postfix, from userid 506) id CCEE950611; Tue, 26 Jun 2001 03:12:44 +0400 (MSD) Received: from localhost (localhost.localdomain [127.0.0.1]) by an.local (Postfix) with ESMTP id 6802450532 for ; Tue, 26 Jun 2001 03:12:44 +0400 (MSD) X-Sieve: cmu-sieve 2.0 Received: from suse.local [192.168.4.39] by localhost with IMAP (fetchmail-5.8.2) for andy@localhost (single-drop); Tue, 26 Jun 2001 03:12:44 +0400 (MSD) Received: from oss.sgi.com (oss.sgi.com [216.32.174.27]) by mail.spylog.com (Postfix) with ESMTP id 911A62C2A5 for ; Tue, 26 Jun 2001 03:10:31 +0400 (MSD) Received: from localhost (mail@localhost) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PNAMI24606; Mon, 25 Jun 2001 16:10:22 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Mon, 25 Jun 2001 16:09:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PN9Qx24493 for linux-xfs-outgoing; Mon, 25 Jun 2001 16:09:26 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PN9IV24482 for ; Mon, 25 Jun 2001 16:09:18 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA09172 for ; Mon, 25 Jun 2001 12:53:20 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2259062; Mon, 25 Jun 2001 14:51:51 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA23392; Mon, 25 Jun 2001 14:51:51 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5PJsCN17223; Mon, 25 Jun 2001 14:54:12 -0500 Message-Id: <200106251954.f5PJsCN17223@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: oe.hansen@gamma.telenordia.se Cc: linux-xfs@oss.sgi.com Subject: Re: Filesystem sizes References: <200106251526.f5PFQuu15808@jen.americas.sgi.com> <01062521152305.01265@citadel.oehansen.pp.se> <200106251920.f5PJKHK16812@jen.americas.sgi.com> <01062521324608.01265@citadel.oehansen.pp.se> Comments: In-reply-to "Orn E. Hansen" message dated "Mon, 25 Jun 2001 21:32:46 +0200." Content-Transfer-Encoding: 8bit Date: Mon, 25 Jun 2001 14:54:12 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > manudagur 25. jznm 2001 21:20, ~z skrifapir: > > > > Ah, sorry I should have specified that you do this on one of the files > > which appears to be oversized after the untar, the directory itself is > > not really interesting. Sorry about that, I will go look at your output. > > The 1 minute thing is interesting I will have to think about that. > > > > Ah, but that's just it... the files are all *correct* size... It's the > *link* count in the listing that's a bit off... you can see this by taking a > diff between xfs-remount and xfs listings. They show, that each directory in > > the listing, where the sizes are too large, is due to that each directory has > > 4 links in it? Hmm, there are two things going on, one being that the size field in a directory is not getting updated when we add new entries to it. XFS allows small directories to live totally within the inode, they will show up with a 0 in the first column of ls -ls, as the directory grows, it gets too big to fit in the inode and we have to allocate a block for it. It looks like the block count field in the inode stat output is not getting updated correctly - the remount forces the upper layers to get the information from the xfs inode again. The second is that you are moving from a 1K block ext2 filesystem to a 4K block xfs filesystem. This means that any file smaller that 4K will use 4K of disk space. Summing the space usage shown by the first column of the ls output between the ext2 numbers and the xfs after remount numbers shows you went from 7813K on ext2 to 10212K on xfs. If you made a 4K block ext2 filesystem which appears to be the standard now, and untarred your archive there, the numbers would probably be a lot closer. I will go fix the block count in directories thing, it should be easy. Steve From owner-linux-xfs@oss.sgi.com Mon Jun 25 16:22:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PNMhe25800 for linux-xfs-outgoing; Mon, 25 Jun 2001 16:22:43 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PNMYV25784 for ; Mon, 25 Jun 2001 16:22:34 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id FAA03392 for ; Mon, 25 Jun 2001 05:01:24 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA2249541; Mon, 25 Jun 2001 06:59:51 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA80367; Mon, 25 Jun 2001 06:59:51 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5PC2F413382; Mon, 25 Jun 2001 07:02:15 -0500 Message-Id: <200106251202.f5PC2F413382@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: alan@cotse.com cc: linux-xfs@oss.sgi.com Subject: Re: Other projects In-Reply-To: Message from of "Sun, 24 Jun 2001 17:59:54 EDT." <6800dd87c5498cd0f41cdac91d72ca6b@public.webmail.cotse.com> Date: Mon, 25 Jun 2001 07:02:15 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I would be REALLY careful with the realtime device, up until recently it was guaranteed to write to the wrong device, this is one reason the realtime option is hidden. A recent change (in the cvs tree) means it possibly write to the correct device, but there is no real guarantee of that yet. How much testing have you done? Steve p.s. I do see Irix realtime calls in lmdd, but these would need changing for linux - have you done this? > I would like to begin testing xfs with lids (www.lids.org) and rtlinux (ww > w.rtlinux.com) to see if the inclusion of lids will play nicely with xfs, and > if both methods of creating acls will be interchangeable (i.e, can lidsadm m > odify chacl created acl's) and rtlinux, to see if the realtime section's perf > ormance could be made truly 'realtime'. I'd like other's thoughts on this, a > s I am not a programmer, and I can barely read code, so > as to tell whether or not these projects would or should work together. > The realtime section could also be marked at least 'experimental' in the cvs > tree, since it does build quite well, and having to add 'CONFIG_XFS_RT' to .c > onfig by hand would be a lot easier if it would just be made a regular > (albeit experimental) option. It does work. lmdd is the only program that I > have been able to use to open inodes with a realtime flag though (thanks stev > e lord). > > Any input on this would be greatly appreciated. > > Thanks, > -alan > > P.S: I know that GRIO is not a real possibility for 2.4, but is it being thou > ght of as a 2.5 kernel subject at least? From owner-linux-xfs@oss.sgi.com Mon Jun 25 16:47:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PNljA27832 for linux-xfs-outgoing; Mon, 25 Jun 2001 16:47:45 -0700 Received: from dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PNliV27827 for ; Mon, 25 Jun 2001 16:47:44 -0700 Received: (from ak@localhost) by dkp.com (8.9.3/8.9.3) id TAA05757 for linux-xfs@oss.sgi.com; Mon, 25 Jun 2001 19:47:43 -0400 Date: Mon, 25 Jun 2001 19:47:43 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Oops - 2.4.2-SGI_XFS_1.0.1_PR1 Message-ID: <20010625194743.A5726@key.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.2i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, all. Okay - I've got an oops, and this time I've got a serial console attached. There's a pretty little kdb prompt sitting there waiting for me. What do I do for maximum debugging pleasure? Andrew Klaassen From owner-linux-xfs@oss.sgi.com Mon Jun 25 18:45:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5Q1j5T02524 for linux-xfs-outgoing; Mon, 25 Jun 2001 18:45:05 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5Q1j4V02521 for ; Mon, 25 Jun 2001 18:45:04 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id SAA06419 for ; Mon, 25 Jun 2001 18:42:13 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) 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 LAA02740; Tue, 26 Jun 2001 11:43:38 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Alan Eldridge cc: linux-xfs@oss.sgi.com Subject: Re: unkillable process In-reply-to: Your message of "Mon, 25 Jun 2001 18:38:43 -0400." <20010625183843.A2197@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Jun 2001 11:43:37 +1000 Message-ID: <4886.993519817@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 25 Jun 2001 18:38:43 -0400, Alan Eldridge wrote: >If cdda2wav is not setuid root, which I really don't want it to be, it >seems, about 90% of the time, to get locked in "R" state, *not* reading the >cdrom drive, using as much CPU as it can, and immune to kill -9. It's also >immune to tracing ... any attempt to trace it results in strace locking up, >and becoming a member of the undead also. That's pretty neat ... so not only >can't you kill cdda2wav, you can't kill the strace, either. > >How can a process, running as a regular user, in the R state, actively >spinning its wheels, be immune to a kill -9? And now can it pass that >immunity on? This is *weird*. Because the task is running in the kernel, not in user space, 'R' means running anywhere. The task has issued a system call and the kernel code is looping. All signals, including -9 are noticed while in kernel space but they are not actioned until the code returns from the kernel back to user space. No return, no signal checking. >How can you debug an uninterruptible, non-waiting process that hangs >anything trying to attach to it? With a kernel debugger. Ensure that your kernel was compiled with CONFIG_KDB=y. Turn kdb on, either with CONFIG_KDB_OFF=n, by booting with "kdb=on" or by 'echo "1" > /proc/sys/kernel/kdb'. When the task hangs, invoke kdb with the Pause key (keyboard) or control-A (serial console). Use ps to get the process number then 'btp pid' to get a backtrace on the offending task. If your disk is still working, before issuing btp, 'set LOGGING=1'. When you type 'go' to exit kdb, the output will be sent to syslog which will send it to disk, if it can. If your disk is not working after this problem, write the backtrace down by hand or use a serial console and capture the output there. Serial consoles are by far the best option for serious kernel debugging. From owner-linux-xfs@oss.sgi.com Mon Jun 25 18:47:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5Q1laL02723 for linux-xfs-outgoing; Mon, 25 Jun 2001 18:47:36 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5Q1lZV02720 for ; Mon, 25 Jun 2001 18:47:35 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id DAA197773 for ; Tue, 26 Jun 2001 03:47:32 +0200 (CEST) mail_from (kaos@melbourne.sgi.com) 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 LAA02789; Tue, 26 Jun 2001 11:46:13 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Andrew Klaassen cc: linux-xfs@oss.sgi.com Subject: Re: Oops - 2.4.2-SGI_XFS_1.0.1_PR1 In-reply-to: Your message of "Mon, 25 Jun 2001 19:47:43 -0400." <20010625194743.A5726@key.dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Jun 2001 11:46:12 +1000 Message-ID: <4914.993519972@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 25 Jun 2001 19:47:43 -0400, Andrew Klaassen wrote: >Okay - I've got an oops, and this time I've got a serial console >attached. There's a pretty little kdb prompt sitting there >waiting for me. > >What do I do for maximum debugging pleasure? Capture the serial console output. 'bt' to trace the failing task is probably all you need at this stage. For an oops it is usually only the current task that is interesting. For loops and hangs, 'ps' and 'bta' are useful to get backtrace for all processes. From owner-linux-xfs@oss.sgi.com Mon Jun 25 19:36:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5Q2aPI05620 for linux-xfs-outgoing; Mon, 25 Jun 2001 19:36:25 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5Q2aOV05616 for ; Mon, 25 Jun 2001 19:36:24 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5Q2aIb02123 for linux-xfs@oss.sgi.com; Mon, 25 Jun 2001 22:36:18 -0400 Date: Mon, 25 Jun 2001 22:35:52 -0400 From: Alan Eldridge To: Keith Owens Subject: Re: unkillable process Message-ID: <20010625223552.A2115@wwweasel.geeksrus.net> References: <20010625215348.A6001@wwweasel.geeksrus.net> <5337.993521178@kao2.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5337.993521178@kao2.melbourne.sgi.com>; from kaos@melbourne.sgi.com on Tue, Jun 26, 2001 at 12:06:18PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >That does puzzle me, normally a kernel loop stops everything else from >running on that cpu. Either you are running SMP or the problem is >stranger than we thought. kdb will tell us, instead of guessing. 0xc7ca6000 00007437 00007405 0 000 run 0xc7ca6260*cdda2wav kdb> btp 7437 EBP EIP Function(args) 0xc0129a0b page_launder+0x87 (0x7, 0x1) kernel .text 0xc0100000 0xc0129984 0xc012a1b0 0xc7ca7cf4 0xc012b25b __alloc_pages+0x163 kernel .text 0xc0100000 0xc012b0f8 0xc012b34c 0xc7ca7cfc 0xc012b363 __get_free_pages+0x17 kernel .text 0xc0100000 0xc012b34c 0xc012b378 0xc7ca7d20 0xd69f19ff [sg]sg_low_malloc+0x13f (0x8000, 0x0, 0x1, 0x0) sg .text 0xd69ee060 0xd69f18c0 0xd69f1a5c 0xc7ca7d4c 0xd69f1ac8 [sg]sg_malloc+0x6c (0xcd045000, 0x8000, 0xc7ca7d94, 0xc7ca7d98) sg .text 0xd69ee060 0xd69f1a5c 0xd69f1bd8 0xc7ca7d9c 0xd69f07e2 [sg]sg_build_indi+0x18e (0xcd04501c, 0xcd045000, 0x6400000) sg .text 0xd69ee060 0xd69f0654 0xd69f0880 0xc7ca7dbc 0xd69f1196 [sg]sg_build_reserve+0x4a (0xcd045000, 0x6400000, 0xcd04501c) sg .text 0xd69ee060 0xd69f114c 0xd69f11c0 0xc7ca7f90 0xd69ef622 [sg]sg_ioctl+0x76e (0xc7fee040, 0xca8e9480, 0x2275, 0xbffff254, 0xc7ca6000) sg .text 0xd69ee060 0xd69eeeb4 0xd69efb24 0xc7ca7fbc 0xc013f0d4 sys_ioctl+0x174 (0x3, 0x2275, 0xbffff254, 0x0, 0x3) kernel .text 0xc0100000 0xc013ef60 0xc013f0f0 0xc0106dbb system_call+0x33 kernel .text 0xc0100000 0xc0106d88 0xc0106dc0 kdb> go -- Alan Eldridge "Smart Tags? We don't need no steenking Smart Tags!" From owner-linux-xfs@oss.sgi.com Mon Jun 25 19:47:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5Q2ljk06227 for linux-xfs-outgoing; Mon, 25 Jun 2001 19:47:45 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5Q2lhV06224 for ; Mon, 25 Jun 2001 19:47:43 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5Q2lQB02211; Mon, 25 Jun 2001 22:47:26 -0400 Date: Mon, 25 Jun 2001 22:47:26 -0400 From: Alan Eldridge To: kaos@melbourne.sgi.com Cc: linux-xfs@oss.sgi.com Subject: [alane@geeksrus.net: Re: unkillable process] Message-ID: <20010625224726.A2170@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Additional data points: 1. cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping : 6 cpu MHz : 731.490 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 3 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 1458.17 2. I had to repeat the test 7 times before I could get it to stay hung. Switching to a text console would unwedge the process. Yes, just hitting "Ctl-Alt-F1" to switch over would cause the process to unwedge and continue. That's gotta be significant, but hell if I know what it could mean. 3. System is *not* low on memory. Typical state (this is now, but it's representative): [alane@wwweasel linux-2.4]$ free total used free shared buffers cached Mem: 254608 245620 8988 0 2584 158656 -/+ buffers/cache: 84380 170228 Swap: 803208 53528 749680 4. System was *not* heavily loaded. It was in the same state as it is now ... just an xterm open (I couldn't get grip to reproduce, see above, so I ran it from an xterm). [alane@wwweasel linux-2.4]$ uptime 10:47pm up 17 min, 2 users, load average: 0.12, 0.06, 0.07 ----- Forwarded message from Alan Eldridge ----- >That does puzzle me, normally a kernel loop stops everything else from >running on that cpu. Either you are running SMP or the problem is >stranger than we thought. kdb will tell us, instead of guessing. 0xc7ca6000 00007437 00007405 0 000 run 0xc7ca6260*cdda2wav kdb> btp 7437 EBP EIP Function(args) 0xc0129a0b page_launder+0x87 (0x7, 0x1) kernel .text 0xc0100000 0xc0129984 0xc012a1b0 0xc7ca7cf4 0xc012b25b __alloc_pages+0x163 kernel .text 0xc0100000 0xc012b0f8 0xc012b34c 0xc7ca7cfc 0xc012b363 __get_free_pages+0x17 kernel .text 0xc0100000 0xc012b34c 0xc012b378 0xc7ca7d20 0xd69f19ff [sg]sg_low_malloc+0x13f (0x8000, 0x0, 0x1, 0x0) sg .text 0xd69ee060 0xd69f18c0 0xd69f1a5c 0xc7ca7d4c 0xd69f1ac8 [sg]sg_malloc+0x6c (0xcd045000, 0x8000, 0xc7ca7d94, 0xc7ca7d98) sg .text 0xd69ee060 0xd69f1a5c 0xd69f1bd8 0xc7ca7d9c 0xd69f07e2 [sg]sg_build_indi+0x18e (0xcd04501c, 0xcd045000, 0x6400000) sg .text 0xd69ee060 0xd69f0654 0xd69f0880 0xc7ca7dbc 0xd69f1196 [sg]sg_build_reserve+0x4a (0xcd045000, 0x6400000, 0xcd04501c) sg .text 0xd69ee060 0xd69f114c 0xd69f11c0 0xc7ca7f90 0xd69ef622 [sg]sg_ioctl+0x76e (0xc7fee040, 0xca8e9480, 0x2275, 0xbffff254, 0xc7ca6000) sg .text 0xd69ee060 0xd69eeeb4 0xd69efb24 0xc7ca7fbc 0xc013f0d4 sys_ioctl+0x174 (0x3, 0x2275, 0xbffff254, 0x0, 0x3) kernel .text 0xc0100000 0xc013ef60 0xc013f0f0 0xc0106dbb system_call+0x33 kernel .text 0xc0100000 0xc0106d88 0xc0106dc0 kdb> go -- Alan Eldridge "Smart Tags? We don't need no steenking Smart Tags!" From owner-linux-xfs@oss.sgi.com Mon Jun 25 19:50:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5Q2oKo06460 for linux-xfs-outgoing; Mon, 25 Jun 2001 19:50:20 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5Q2oJV06457 for ; Mon, 25 Jun 2001 19:50:20 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5Q2oCu02221; Mon, 25 Jun 2001 22:50:12 -0400 Date: Mon, 25 Jun 2001 22:50:12 -0400 From: Alan Eldridge To: kaos@melbourne.sgi.com, linux-xfs@oss.sgi.com Subject: Thanks, taking this offline... Message-ID: <20010625225012.A2216@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Re: unkillable process Thanks to Keith and the magical kdb, I know how to proceed. Taking this offline to the linux-kernel list. -- Alan Eldridge From owner-linux-xfs@oss.sgi.com Mon Jun 25 20:40:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5Q3e9K09118 for linux-xfs-outgoing; Mon, 25 Jun 2001 20:40:09 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5Q3e8V09115 for ; Mon, 25 Jun 2001 20:40:08 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA06925 for ; Mon, 25 Jun 2001 20:40:03 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id UAA29017 for ; Mon, 25 Jun 2001 20:39:36 -0700 (PDT) Message-ID: <3B380365.495495AA@sgi.com> Date: Mon, 25 Jun 2001 22:37:09 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS patches for Red Hat 2.4.3-12 References: <3B37B8DF.8A008F3D@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > > Ok, these are very rough, they have passed the "does it boot" test, and > the "does it run through QA tests without an OOPS" test. I have not > done any NFS-related testing. Ah, but I didn't build LVM on that trial run, so of course it's what's borked. If you need LVM, you don't want this patch set. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Jun 25 23:49:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5Q6nAd19712 for linux-xfs-outgoing; Mon, 25 Jun 2001 23:49:10 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5Q6n8V19709 for ; Mon, 25 Jun 2001 23:49:09 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA14999; Tue, 26 Jun 2001 08:49:01 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA00889; Tue, 26 Jun 2001 08:49:00 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id B020B57306; Tue, 26 Jun 2001 08:58:55 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 35B6125835; Tue, 26 Jun 2001 09:07:09 +0200 (CEST) Message-ID: <3B383158.386E9559@ch.sauter-bc.com> Date: Tue, 26 Jun 2001 08:53:12 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Eric Sandeen Cc: "linux-xfs@oss.sgi.com" Subject: Re: New Redhat 7.1 kernel patch References: <3B37A581.5D0F333F@sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen schrieb: > > Juha Saarinen wrote: > > > I'm not sure about this... tracking "pukka" kernels for the CVS, and > > patching RH's for the RPM version. > > > > Since Linux XFS is based on RH's distro, wouldn't it make more sense to > > work with just RH's kernels? I guess it's possible to manually add the > > RH patches though. > > Linux XFS is _not_ based on RH's distro, that's just one convenient way > that we package it for the masses. :) XFS development has always been > based on Linus' tree. > > Red Hat RPMs are just a "fun" (?!) side project for Linux XFS. > > -Eric Anyway, RedHat RPM's are VERY important for the corporate world. I mean there are places where you are not able to tell the managment why you have to compile a custom kernel before you can install a new server. Beside that RH kernel's have enhanced features (be it good or not) and thus if you depend on some of them, it can be very difficult to modify linus kernel by hand to achieve the same. It's good that XFS does not depend on RedHat but on the other side it's very important to support distros in a convenient way. Simon From owner-linux-xfs@oss.sgi.com Tue Jun 26 01:10:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5Q8A9o23433 for linux-xfs-outgoing; Tue, 26 Jun 2001 01:10:09 -0700 Received: from doppstadt-sbk.de ([194.173.186.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5Q8A7V23430 for ; Tue, 26 Jun 2001 01:10:07 -0700 Received: from svnt0002.doppstadt-sbk.de ([172.21.1.11]) by svfw0001.doppstadt-sbk.de with ESMTP id <119042>; Tue, 26 Jun 2001 10:09:58 +0200 Received: from pcli0001.doppstadt-sbk.de ([172.21.1.101]) by svnt0002.doppstadt-sbk.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MXCPA9VR; Tue, 26 Jun 2001 10:09:57 +0200 Subject: xfsdump From: ThH To: linux-xfs@oss.sgi.com Content-Type: text/plain X-Mailer: Evolution/0.10 (Preview Release) Date: 26 Jun 2001 09:13:54 +0200 Message-Id: <993539634.7412.0.camel@pcli0001.doppstadt-sbk.de> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm testing XFS on an alpha with RedHat Linux 7.0. I normaly backup this alpha with dump for ext2 fs. So I want to use xfsdump. It may work on x86 but on the alpha there are many problems with sizes like sizeof(time_t) != 4, so xfsdump stops its operation. The bug was on 1.0.5 an than on 1.0.9. What have I to do to use xfsdump. I want to use XFS for my file server, but without a chance to backup I won't. From owner-linux-xfs@oss.sgi.com Tue Jun 26 01:32:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5Q8Wtl23923 for linux-xfs-outgoing; Tue, 26 Jun 2001 01:32:55 -0700 Received: from indonesia.kscanners.no (indonesia.kscanners.no [193.214.130.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5Q8WhV23920 for ; Tue, 26 Jun 2001 01:32:50 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=kscanners.com) by indonesia.kscanners.no with esmtp (Exim 3.22 #1) id 15EoGq-0004xE-00 for linux-xfs@oss.sgi.com; Tue, 26 Jun 2001 10:32:28 +0200 Message-ID: <3B38489B.85B3EB49@kscanners.com> Date: Tue, 26 Jun 2001 10:32:27 +0200 From: Toralf Lund Organization: Kongsberg Scanners AS X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-0.2.9 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Integration of XFS into Linux source/major dists? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk What exactly is your plans on integration of XFS with the official kernel sources and/or the major Linux dists? I'm a bit concerned about the following: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=45497 > > --- shadow/45497 Fri Jun 22 05:35:09 2001 > +++ shadow/45497.tmp.19362 Fri Jun 22 05:50:24 2001 > @@ -3,8 +3,8 @@ > Version: 7.1 > Platform: i386 > OS/Version: Linux > -Status: NEW > -Resolution: > +Status: RESOLVED > +Resolution: NOTABUG > Severity: enhancement > Priority: normal > Component: kernel > @@ -34,3 +34,12 @@ > Also note that there are certain issues related to installing kernel RPMs > from SGI on a Red Hat 7.1 system, such as the fact that devfsd from Red Hat > is not quite compatible with the SGI kernel. > + > +------- Additional comments from arjanv@redhat.com 2001-06-22 05:50:43 ------- > +XFS is not a candidate for 7.1 kernels unless it gets merged into Linus' > +2.4 tree (their patch touches a lot of core code, and they add syscalls > +which is something we only do when Linus approves them) > + > + > +Also, please take bugs against the SGI kernel to SGI not us, as they changed > +several things we put in explicitly in order not to break things. > > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug report. We're currently using XFS on a 180Gb RAID volume, by the way, and everything looks good so far. -- Toralf Lund +47 66 85 51 22 Kongsberg Scanners AS +47 66 85 51 00 (switchboard) http://www.kscanners.no/~toralf +47 66 85 51 01 (fax) From owner-linux-xfs@oss.sgi.com Tue Jun 26 03:34:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QAYk425854 for linux-xfs-outgoing; Tue, 26 Jun 2001 03:34:46 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QAYiV25851 for ; Tue, 26 Jun 2001 03:34:45 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5QAYdV28947; Tue, 26 Jun 2001 12:34:39 +0200 Message-Id: <4.3.2.7.2.20010626123256.02e185a0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Jun 2001 12:34:35 +0200 To: ThH , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: xfsdump In-Reply-To: <993539634.7412.0.camel@pcli0001.doppstadt-sbk.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 09:13 26-6-2001 +0200, ThH wrote: >I'm testing XFS on an alpha with RedHat Linux 7.0. I normaly backup this >alpha with dump for ext2 fs. So I want to use xfsdump. It may work on >x86 but on the alpha there are many problems with sizes like >sizeof(time_t) != 4, so xfsdump stops its operation. The bug was on >1.0.5 an than on 1.0.9. What have I to do to use xfsdump. >I want to use XFS for my file server, but without a chance to backup I >won't. Tar? ;) Seriously, can you give the error output and if possible a strace output of the failing xfsdump including command line parameters and the backup device if used?. Cheers Seth -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Jun 26 03:40:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QAeGe25966 for linux-xfs-outgoing; Tue, 26 Jun 2001 03:40:16 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QAeEV25963 for ; Tue, 26 Jun 2001 03:40:14 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5QAeAV28986; Tue, 26 Jun 2001 12:40:10 +0200 Message-Id: <4.3.2.7.2.20010626123529.03fc80f8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Jun 2001 12:40:06 +0200 To: Toralf Lund , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Integration of XFS into Linux source/major dists? In-Reply-To: <3B38489B.85B3EB49@kscanners.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10:32 26-6-2001 +0200, Toralf Lund wrote: >What exactly is your plans on integration of XFS with the official kernel >sources >and/or the major Linux dists? I'm a bit concerned about the following: The FAQ explains that. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=45497 > > > > --- shadow/45497 Fri Jun 22 05:35:09 2001 > > +++ shadow/45497.tmp.19362 Fri Jun 22 05:50:24 2001 > > @@ -3,8 +3,8 @@ > > Version: 7.1 > > Platform: i386 > > OS/Version: Linux > > -Status: NEW > > -Resolution: > > +Status: RESOLVED > > +Resolution: NOTABUG > > Severity: enhancement > > Priority: normal > > Component: kernel > > @@ -34,3 +34,12 @@ > > Also note that there are certain issues related to installing kernel RPMs > > from SGI on a Red Hat 7.1 system, such as the fact that devfsd from > Red Hat > > is not quite compatible with the SGI kernel. > > + > > +------- Additional comments from arjanv@redhat.com 2001-06-22 05:50:43 > ------- > > +XFS is not a candidate for 7.1 kernels unless it gets merged into Linus' > > +2.4 tree (their patch touches a lot of core code, and they add syscalls > > +which is something we only do when Linus approves them) > > + > > + > > +Also, please take bugs against the SGI kernel to SGI not us, as they > changed > > +several things we put in explicitly in order not to break things. > > > > Please do not reply directly to this email. All additional > > comments should be made in the comments box of this bug report. RedHat deserves the right to withhold from merging in a relatively intrusive patch. You don't just add complicated filesystems every day. >We're currently using XFS on a 180Gb RAID volume, by the way, and >everything looks >good so far. It does work, and extremely well in my own case. But that does not mean it will automatically get inserted in the mainstream kernel. We are working on it, but it will take some time to resolve all the items that linus asks for in a patch. Cheers Seth -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Jun 26 03:51:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QAp4I26102 for linux-xfs-outgoing; Tue, 26 Jun 2001 03:51:04 -0700 Received: from indonesia.kscanners.no (indonesia.kscanners.no [193.214.130.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QAp2V26099 for ; Tue, 26 Jun 2001 03:51:02 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=kscanners.com) by indonesia.kscanners.no with esmtp (Exim 3.22 #1) id 15EqQI-0005Oy-00; Tue, 26 Jun 2001 12:50:22 +0200 Message-ID: <3B3868EE.94DD2C29@kscanners.com> Date: Tue, 26 Jun 2001 12:50:22 +0200 From: Toralf Lund Organization: Kongsberg Scanners AS X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-0.2.9 i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: linux-xfs@oss.sgi.com Subject: Re: Integration of XFS into Linux source/major dists? References: <4.3.2.7.2.20010626123529.03fc80f8@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > At 10:32 26-6-2001 +0200, Toralf Lund wrote: > >What exactly is your plans on integration of XFS with the official kernel > >sources > >and/or the major Linux dists? I'm a bit concerned about the following: > > The FAQ explains that. OK. > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=45497 [ ... ] > > > > > RedHat deserves the right to withhold from merging in a relatively > intrusive patch. You don't just add complicated filesystems every day. > Fair enough. > > >We're currently using XFS on a 180Gb RAID volume, by the way, and > >everything looks > >good so far. > > It does work, and extremely well in my own case. But that does not mean it > will automatically get inserted in the mainstream kernel. > We are working on it, but it will take some time to resolve all the items > that linus asks for in a patch. Will you there be a new release any time soon? I'm currently using a patched version due to certain NFS client issues. Also, would it be possible to make it work properly along with devfs from Red Hat? -- Toralf Lund +47 66 85 51 22 Kongsberg Scanners AS +47 66 85 51 00 (switchboard) http://www.kscanners.no/~toralf +47 66 85 51 01 (fax) From owner-linux-xfs@oss.sgi.com Tue Jun 26 04:06:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QB6iH26457 for linux-xfs-outgoing; Tue, 26 Jun 2001 04:06:44 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QB6eV26454 for ; Tue, 26 Jun 2001 04:06:41 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5QB6cV29206; Tue, 26 Jun 2001 13:06:38 +0200 Message-Id: <4.3.2.7.2.20010626130421.03fc6d00@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Jun 2001 13:06:33 +0200 To: Toralf Lund From: Seth Mos Subject: Re: Integration of XFS into Linux source/major dists? Cc: linux-xfs@oss.sgi.com In-Reply-To: <3B3868EE.94DD2C29@kscanners.com> References: <4.3.2.7.2.20010626123529.03fc80f8@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:50 26-6-2001 +0200, Toralf Lund wrote: > > >We're currently using XFS on a 180Gb RAID volume, by the way, and > > >everything looks > > >good so far. > > > > It does work, and extremely well in my own case. But that does not mean it > > will automatically get inserted in the mainstream kernel. > > We are working on it, but it will take some time to resolve all the items > > that linus asks for in a patch. > >Will you there be a new release any time soon? I'm currently using a patched >version due to certain NFS client issues. Also, would it be possible to >make it >work properly along with devfs from Red Hat? 1.0.1 releas (2.4.5 based) is just around the corner. There is not a specific release date for it yet. But "soon" is the best I can give. The devfs issue is something I can not comment upon. I don't use devfs on any of my machines. The default for 1.0.1 is to not mount it at bootup. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Jun 26 04:07:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QB7c526503 for linux-xfs-outgoing; Tue, 26 Jun 2001 04:07:38 -0700 Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QB7ZV26499 for ; Tue, 26 Jun 2001 04:07:35 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id F27BD139A4; Tue, 26 Jun 2001 07:07:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id E9872139A2; Tue, 26 Jun 2001 07:07:34 -0400 (EDT) Date: Tue, 26 Jun 2001 07:07:34 -0400 (EDT) From: Mike Burger To: Toralf Lund Cc: Subject: Re: Integration of XFS into Linux source/major dists? In-Reply-To: <3B38489B.85B3EB49@kscanners.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk They're plans are exactly what the Red Hat source said...they're working toward getting their code approved, for inclusion, by Linus Torvalds. Not much winds up in a distribution level kernel unless it's already been approved by Linus. On Tue, 26 Jun 2001, Toralf Lund wrote: > What exactly is your plans on integration of XFS with the official kernel sources > and/or the major Linux dists? I'm a bit concerned about the following: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=45497 > > > > --- shadow/45497 Fri Jun 22 05:35:09 2001 > > +++ shadow/45497.tmp.19362 Fri Jun 22 05:50:24 2001 > > @@ -3,8 +3,8 @@ > > Version: 7.1 > > Platform: i386 > > OS/Version: Linux > > -Status: NEW > > -Resolution: > > +Status: RESOLVED > > +Resolution: NOTABUG > > Severity: enhancement > > Priority: normal > > Component: kernel > > @@ -34,3 +34,12 @@ > > Also note that there are certain issues related to installing kernel RPMs > > from SGI on a Red Hat 7.1 system, such as the fact that devfsd from Red Hat > > is not quite compatible with the SGI kernel. > > + > > +------- Additional comments from arjanv@redhat.com 2001-06-22 05:50:43 ------- > > +XFS is not a candidate for 7.1 kernels unless it gets merged into Linus' > > +2.4 tree (their patch touches a lot of core code, and they add syscalls > > +which is something we only do when Linus approves them) > > + > > + > > +Also, please take bugs against the SGI kernel to SGI not us, as they changed > > +several things we put in explicitly in order not to break things. > > > > Please do not reply directly to this email. All additional > > comments should be made in the comments box of this bug report. > > We're currently using XFS on a 180Gb RAID volume, by the way, and everything looks > good so far. > > -- > Toralf Lund +47 66 85 51 22 > Kongsberg Scanners AS +47 66 85 51 00 (switchboard) > http://www.kscanners.no/~toralf +47 66 85 51 01 (fax) > > > > From owner-linux-xfs@oss.sgi.com Tue Jun 26 04:12:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QBCZo26691 for linux-xfs-outgoing; Tue, 26 Jun 2001 04:12:35 -0700 Received: from indonesia.kscanners.no (indonesia.kscanners.no [193.214.130.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QBCXV26688 for ; Tue, 26 Jun 2001 04:12:33 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=kscanners.com) by indonesia.kscanners.no with esmtp (Exim 3.22 #1) id 15Eql8-0005Qn-00; Tue, 26 Jun 2001 13:11:54 +0200 Message-ID: <3B386DF9.AAC07E7@kscanners.com> Date: Tue, 26 Jun 2001 13:11:53 +0200 From: Toralf Lund Organization: Kongsberg Scanners AS X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-0.2.9 i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: linux-xfs@oss.sgi.com Subject: Re: Integration of XFS into Linux source/major dists? References: <4.3.2.7.2.20010626123529.03fc80f8@pop.xs4all.nl> <4.3.2.7.2.20010626130421.03fc6d00@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > At 12:50 26-6-2001 +0200, Toralf Lund wrote: > > > >We're currently using XFS on a 180Gb RAID volume, by the way, and > > > >everything looks > > > >good so far. > > > > > > It does work, and extremely well in my own case. But that does not mean it > > > will automatically get inserted in the mainstream kernel. > > > We are working on it, but it will take some time to resolve all the items > > > that linus asks for in a patch. > > > >Will you there be a new release any time soon? I'm currently using a patched > >version due to certain NFS client issues. Also, would it be possible to > >make it > >work properly along with devfs from Red Hat? > > 1.0.1 releas (2.4.5 based) is just around the corner. There is not a > specific release date for it yet. But "soon" is the best I can give. Good! > > > The devfs issue is something I can not comment upon. I don't use devfs on > any of my machines. The default for 1.0.1 is to not mount it at bootup. So what you are saying is that this has been changed since 1.0? I seem to remember that this wouldn't boot at all when I first installed it, and that installing devfs via "rescue mode" resolved the problems. - Toralf From owner-linux-xfs@oss.sgi.com Tue Jun 26 04:18:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QBI8O26828 for linux-xfs-outgoing; Tue, 26 Jun 2001 04:18:08 -0700 Received: from bakterius.eggenet.de (bakterius.eggenet.de [195.60.113.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QBI4V26799 for ; Tue, 26 Jun 2001 04:18:06 -0700 Received: from koepfer (sven.eggenet.de [192.168.113.66]) by bakterius.eggenet.de (8.9.3/8.9.3) with ESMTP id NAA08146 for ; Tue, 26 Jun 2001 13:21:51 +0200 Message-Id: <4.2.0.58.20010626105358.01328980@mail.eggenet.de> X-Sender: koepfer_firma@mail.eggenet.de X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 26 Jun 2001 11:19:29 +0000 To: linux-xfs@oss.sgi.com From: Sven Koepfer Subject: Compile Problems Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5QBI7V26826 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, we are an ISP and i try to use your XFS. The normal installation with the iso Installer works fine but when i try to compile the 2.4.3 Kernel i get these errors: ************** schnipp gcc -D__KERNEL__ -I/usr/src/linux-2.4.3/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pi pe -mpreferred-stack-boundary=2 -march=i686 -Wno-unused -Wno-parentheses -Wno-uninitialized -I. -I/usr/src/linux-2.4.3/fs -funsigned-char -Wno-unknown-pragmas -c -o xfs_bmap.o xfs_bmap.c xfs_bmap.c:543:9: warning: pasting "." and "xs_add_exlist" does not give a valid preprocessing token xfs_bmap.c:2830:9: warning: pasting "." and "xs_del_exlist" does not give a valid preprocessing token xfs_bmap.c: In function `xfs_bmap_alloc': xfs_bmap.c:2721: Unrecognizable insn: (insn/i 137 3604 3598 (parallel[ (set (reg:SI 0 eax) (asm_operands ("") ("=a") 0[ (reg:DI 1 edx) ] [ (asm_input:DI ("A")) ] ("linux/xfs_linux.h") 287)) (set (reg:SI 1 edx) (asm_operands ("") ("=d") 1[ (reg:DI 1 edx) ] [ (asm_input:DI ("A")) ] ("linux/xfs_linux.h") 287)) (clobber (reg:QI 19 dirflag)) (clobber (reg:QI 18 fpsr)) (clobber (reg:QI 17 flags)) ] ) -1 (nil) (nil)) xfs_bmap.c:2721: confused by earlier errors, bailing out make[3]: *** [xfs_bmap.o] Fehler 2 make[3]: Verlassen des Verzeichnisses Verzeichnis »/usr/src/linux-2.4.3/fs/xfs« make[2]: *** [first_rule] Fehler 2 make[2]: Verlassen des Verzeichnisses Verzeichnis »/usr/src/linux-2.4.3/fs/xfs« make[1]: *** [_subdir_xfs] Fehler 2 make[1]: Verlassen des Verzeichnisses Verzeichnis »/usr/src/linux-2.4.3/fs« make: *** [_dir_fs] Fehler 2 ************** schnapp I use Red Hat 7.1 (installed with your installer) Kernel 2.4.3 (from kernel.org) with the patches "linux-2.4-xfs-1.0.patch.gz / linux-2.4.3-core-xfs-1.0.patch.gz" on an AMD-K6 3D+ Prozessor with IDE and 128 MB RAM. Any idea ???????????? Thanks Mit freundlichen Grüßen / Best regards / Muy Atentamente Sven Köpfer -------------------------------------------------------------- Sven Koepfer mailto:s.koepfer@eggenet.com Leiter IP-Systemtechnik http://www.eggenet.com EGGENET GmbH Tel: +49 (0)5251 8988-32 Rolandsweg 80 Fax: +49 (0)5251 8988-99 33102 Paderborn -------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Jun 26 04:18:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QBI5c26803 for linux-xfs-outgoing; Tue, 26 Jun 2001 04:18:05 -0700 Received: from relay.flashnet.it (ems.flashnet.it [194.247.160.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QBI4V26800 for ; Tue, 26 Jun 2001 04:18:04 -0700 Received: from ip073.pool-03.cyb.it (ip073.pool-03.cyb.it [195.191.3.74]) by relay.flashnet.it (8.11.3/8.11.3) with SMTP id f5QBI1U32373 for ; Tue, 26 Jun 2001 13:18:01 +0200 From: daedalus@freemail.it To: linux-xfs@oss.sgi.com Subject: Re: RedHat 7.1 (XFS 1.0) + OpenOffice 627 or 625 Date: Tue, 26 Jun 2001 13:27:22 +0200 Message-ID: <41qgjt8ksvoin7ojgb160jav5dokgbbe64@4ax.com> References: <3B3732C3.76E797B0@rebel.net.au> In-Reply-To: <3B3732C3.76E797B0@rebel.net.au> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5QBI5V26801 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 25 Jun 2001 22:16:59 +0930, David Lloyd wrote: >Has anyone noticed whether OpenOffice runs extraordinarily slowly under >that combination? It's not a fast program by all means, but it seems to >have really slowed down since I installed RH 7.1/XFS by SGI et al... > >DSL It may be a bare hd speed difference? I mean the kernels may have different hw support for example I have noticed that sometimes kernels are patched with code from http://www.linux-ide.org I rember I got 3.90 MB/s with 2.2.19, when I got the patch and built the via82Cxxxx support I reached 21 MB/s !!! I have never reached such performance on the same hw even using the 2.4.5 patch for the vanilla tree: the best I could get is 10 MB/s From owner-linux-xfs@oss.sgi.com Tue Jun 26 04:48:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QBmgZ27251 for linux-xfs-outgoing; Tue, 26 Jun 2001 04:48:42 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QBmeV27248 for ; Tue, 26 Jun 2001 04:48:40 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5QBmYV29592; Tue, 26 Jun 2001 13:48:36 +0200 Message-Id: <4.3.2.7.2.20010626134654.02e9fba8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Jun 2001 13:48:30 +0200 To: daedalus@freemail.it, linux-xfs@oss.sgi.com, lloy0076@rebel.net.au From: Seth Mos Subject: Re: RedHat 7.1 (XFS 1.0) + OpenOffice 627 or 625 In-Reply-To: <41qgjt8ksvoin7ojgb160jav5dokgbbe64@4ax.com> References: <3B3732C3.76E797B0@rebel.net.au> <3B3732C3.76E797B0@rebel.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:27 26-6-2001 +0200, daedalus@freemail.it wrote: >On Mon, 25 Jun 2001 22:16:59 +0930, David Lloyd > wrote: > > >Has anyone noticed whether OpenOffice runs extraordinarily slowly under > >that combination? It's not a fast program by all means, but it seems to > >have really slowed down since I installed RH 7.1/XFS by SGI et al... > > > >DSL > >It may be a bare hd speed difference? >I mean the kernels may have different hw support >for example I have noticed that sometimes kernels are patched with >code from http://www.linux-ide.org >I rember I got 3.90 MB/s with 2.2.19, when I got the patch and built >the via82Cxxxx support I reached 21 MB/s !!! >I have never reached such performance on the same hw even using the >2.4.5 patch for the vanilla tree: the best I could get is 10 MB/s Where do I find OpenOffice? I will try it for you. Although my home system is probably a bit on the new side to really compare. I have a 1.4GHz Athlon with 256MB ram and a 60GB IDE disk that can read up to 35MB/s. I can always try on my notebook. That one is mostly 1.0. But I can at least check. I also noticed that the system feels slower with the mostly modular 1.0 kernel. I recompiled it with most things like IDE and scsi compiled in which "felt" faster. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Jun 26 04:49:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QBnkI27288 for linux-xfs-outgoing; Tue, 26 Jun 2001 04:49:46 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QBnjV27285 for ; Tue, 26 Jun 2001 04:49:45 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5QBnZV29599; Tue, 26 Jun 2001 13:49:35 +0200 Message-Id: <4.3.2.7.2.20010626134851.02e46838@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Jun 2001 13:49:30 +0200 To: Sven Koepfer , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Compile Problems In-Reply-To: <4.2.0.58.20010626105358.01328980@mail.eggenet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:19 26-6-2001 +0000, Sven Koepfer wrote: >Hi, > >we are an ISP and i try to use your XFS. The normal installation with the >iso Installer works fine but when i try to compile the 2.4.3 Kernel i get >these errors: Ahem I notice gcc and direct you to reading the FAQ. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Jun 26 04:49:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QBnsX27322 for linux-xfs-outgoing; Tue, 26 Jun 2001 04:49:54 -0700 Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QBnrV27319 for ; Tue, 26 Jun 2001 04:49:53 -0700 Received: from dsl-squash.corp.sgi.com (nic-30-c48-217.mw.mediaone.net [24.30.48.217]) by demai05.mw.mediaone.net (8.11.1/8.11.1) with ESMTP id f5QBnpK24953 for ; Tue, 26 Jun 2001 07:49:51 -0400 (EDT) Date: Tue, 26 Jun 2001 07:49:44 -0400 (EDT) From: J Landman X-X-Sender: To: Subject: A possible xfs bug: cp/mv to/from an xfs filesystem In-Reply-To: <3B386DF9.AAC07E7@kscanners.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Folks: Let me know if this is not the appropriate forum for this. I have what I will call an annoying problem. It seems that cp/mv have stopped working between xfs and the other file systems. Here are the basics: uname -a : Linux genome.dtw.macsch.com 2.4.5-xfs #2 Thu Jun 21 03:06:30 EDT 2001 i686 unknown (plain 2.4.5 using the xfs patches from last week for 2.4.5) file system /work is a RAID 0 /dev/md0 device, striped across two disks on one controller. Other file systems are reiserfs (or some ext2). Here is the problem (from a reiserfs filesystem) [landman@genome.dtw.macsch.com:~] 11 >cp XML-Config-0.2.tar.gz /work/ Segmentation fault (core dumped) (whoops) [landman@genome.dtw.macsch.com:~] 12 >cp XML-Config-0.2.tar.gz xml.tgz (ok) now cd to /work (the xfs filesystem) [landman@genome.dtw.macsch.com:/work] 15 >cp installer i Segmentation fault so we see that it may be independent of where it starts from (xfs/reiserfs to xfs) so I ran strace on the file, and this is what I got near the end (after the umask) umask(0) = 02 lstat64("i", {st_mode=S_IFREG|0755, st_size=0, ...}) = 0 stat64("i", {st_mode=S_IFREG|0755, st_size=0, ...}) = 0 stat64("installer", {st_mode=S_IFREG|0755, st_size=4332356, ...}) = 0 stat64("i", {st_mode=S_IFREG|0755, st_size=0, ...}) = 0 open("installer", O_RDONLY|O_LARGEFILE) = 3 open("i", O_WRONLY|O_TRUNC|O_LARGEFILE) = 4 fstat64(4, {st_mode=S_IFREG|0755, st_size=0, ...}) = 0 fstat64(3, {st_mode=S_IFREG|0755, st_size=4332356, ...}) = 0 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ looking at /bin/cp, I see [landman@genome.dtw.macsch.com:/work] 17 >ldd /bin/cp libc.so.6 => /lib/libc.so.6 (0x40029000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [landman@genome.dtw.macsch.com:/work] 18 >rpm -qf /lib/libc.so.6 glibc-2.2.2-4mdk This is a mandrake 8.0 system. I used the original Russell Mandrake patched kernel until I started to notice this. I can move files around using tar. Tar uses the same libraries as cp, with the additional librt, and libpthread. This is all being done using the tcsh. This uses the fileutils-4.0. I downloaded and handcompiled 4.1 of fileutils, and I get the same behavior. What else should I do? I just want to make this go away. File system was built using the 1.0 mkfs. I have run xfs_check and xfs_repair -n on it. I can back it up and rebuild the FS if needed. Let me know what you think. Joe -- Joe Landman, landman@mediaone.net joe.landman@mscsoftware.com From owner-linux-xfs@oss.sgi.com Tue Jun 26 04:53:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QBrJ427570 for linux-xfs-outgoing; Tue, 26 Jun 2001 04:53:19 -0700 Received: from smoke.zoop.org (toad-1348-51.dslbr.toad.net [162.33.229.51] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QBrHV27567 for ; Tue, 26 Jun 2001 04:53:17 -0700 Received: from localhost (localhost [127.0.0.1]) by smoke.zoop.org (8.11.2/8.11.2) with ESMTP id f5QBqrK02364 for ; Tue, 26 Jun 2001 07:53:03 -0400 Date: Tue, 26 Jun 2001 07:52:53 -0400 (EDT) From: Karl Hiramoto X-X-Sender: To: Subject: missing file / bad file descriptor Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk how do i fix this? [root@smoke /etc]# ls -la socks* -rw-r--r-- 1 root root 75 May 21 20:36 socks5.conf -rw-r--r-- 1 root root 109 May 23 19:13 socks5.conf2 -rw-r--r-- 1 root root 109 May 21 20:50 socks5.conf.bak [root@smoke /etc]# rm socks5.conf rm: cannot remove `socks5.conf': No such file or directory [root@smoke /etc]# -- my syslog gives me: Jun 20 21:58:27 smoke Socks5[1065]: 000000: Config: Error opening config file (/etc/socks5.conf): Bad file descriptor -- I installed XFS with the redhat 7.1 installer. and i have it running all on my file systems now. usually works great. === Karl Hiramoto Home: 978-266-1962 Cell: 508-517-4819 Personal web page: http://karl.hiramoto.ws/ PGP key available Zoop Productions: http://www.zoop.org/ KTEQ Rapid City: http://www.kteq.org/ AOL IM ID = KarlH420 ICQ#'s = 52003056 & 16617452 --- You are taking yourself far too seriously. From owner-linux-xfs@oss.sgi.com Tue Jun 26 05:21:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QCLF128065 for linux-xfs-outgoing; Tue, 26 Jun 2001 05:21:15 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QCLDV28062 for ; Tue, 26 Jun 2001 05:21:13 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5QCKmV29793; Tue, 26 Jun 2001 14:20:50 +0200 Message-Id: <4.3.2.7.2.20010626141914.02faf688@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Jun 2001 14:20:42 +0200 To: Karl Hiramoto , From: Seth Mos Subject: Re: missing file / bad file descriptor In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 07:52 26-6-2001 -0400, Karl Hiramoto wrote: >how do i fix this? > > >[root@smoke /etc]# ls -la socks* >-rw-r--r-- 1 root root 75 May 21 20:36 socks5.conf >-rw-r--r-- 1 root root 109 May 23 19:13 socks5.conf2 >-rw-r--r-- 1 root root 109 May 21 20:50 >socks5.conf.bak >[root@smoke /etc]# rm socks5.conf >rm: cannot remove `socks5.conf': No such file or directory >[root@smoke /etc]# > >-- > >my syslog gives me: > >Jun 20 21:58:27 smoke Socks5[1065]: 000000: Config: Error opening >config file (/etc/socks5.conf): Bad file descriptor > >-- Can you run "xfs_repair -n" on the fs to see if it wants to change something? Corruption somewhere maybe? I am guessin a bit. Bye -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Jun 26 05:28:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QCS4N28227 for linux-xfs-outgoing; Tue, 26 Jun 2001 05:28:04 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QCS2V28224 for ; Tue, 26 Jun 2001 05:28:03 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5QCRxV29826; Tue, 26 Jun 2001 14:28:00 +0200 Message-Id: <4.3.2.7.2.20010626142055.02faabf0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Jun 2001 14:27:54 +0200 To: J Landman , From: Seth Mos Subject: Re: A possible xfs bug: cp/mv to/from an xfs filesystem In-Reply-To: References: <3B386DF9.AAC07E7@kscanners.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 07:49 26-6-2001 -0400, J Landman wrote: >Folks: > > Let me know if this is not the appropriate forum for this. I have what >I will call an annoying problem. It seems that cp/mv have stopped working >between xfs and the other file systems. Here are the basics: > >uname -a : Linux genome.dtw.macsch.com 2.4.5-xfs #2 Thu Jun 21 03:06:30 >EDT 2001 i686 >unknown > >(plain 2.4.5 using the xfs patches from last week for 2.4.5) > >file system /work is a RAID 0 /dev/md0 device, striped across two disks on >one controller. Other file systems are reiserfs (or some ext2). >This is a mandrake 8.0 system. I used the original Russell Mandrake >patched kernel until I started to notice this. I can move files around >using tar. Tar uses the same libraries as cp, with the additional librt, >and libpthread. This is all being done using the tcsh. This uses the >fileutils-4.0. I downloaded and handcompiled 4.1 of fileutils, and I get >the same behavior. Did you compile the kernel with gcc or kgcc/egcs? >What else should I do? I just want to make this go away. File system was >built using the 1.0 mkfs. I have run xfs_check and xfs_repair -n on it. >I can back it up and rebuild the FS if needed. Let me know what you >think. xfs_repair -n will not modify your filesystem. You need to run it normally to actually repair the fs. I hardly think that rebuilding your fs is needed. Nothing changed in the on-disk format. There have been more reports of on-disk reporting with a kernel compiled with 2.96 based compilers. So avoid using 2.96 to compile your kernel when your data is valuable. I made this point about compilers a lot clearer in the FAQ. Cheers. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Jun 26 05:41:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QCfhC28563 for linux-xfs-outgoing; Tue, 26 Jun 2001 05:41:43 -0700 Received: from relay.flashnet.it (ems.flashnet.it [194.247.160.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QCfgV28560 for ; Tue, 26 Jun 2001 05:41:42 -0700 Received: from ip098.pool-02.cyb.it (ip098.pool-02.cyb.it [195.191.2.227]) by relay.flashnet.it (8.11.3/8.11.3) with SMTP id f5QCfdU11481 for ; Tue, 26 Jun 2001 14:41:40 +0200 From: daedalus@freemail.it To: linux-xfs@oss.sgi.com Subject: Re: Compile Problems Date: Tue, 26 Jun 2001 14:51:01 +0200 Message-ID: References: <4.2.0.58.20010626105358.01328980@mail.eggenet.de> In-Reply-To: <4.2.0.58.20010626105358.01328980@mail.eggenet.de> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5QCfhV28561 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 26 Jun 2001 11:19:29 +0000, Sven Koepfer wrote: >Hi, > >we are an ISP and i try to use your XFS. The normal installation with the >iso Installer works fine but when i try to compile the 2.4.3 Kernel i get >these errors: >[snip] >xfs_bmap.c: In function `xfs_bmap_alloc': >xfs_bmap.c:2721: Unrecognizable insn: >[snip] I happened the same using gcc-2.95.3 with 1.0 release. You should use egcs (2.91.66), but I guess turning off additional debugging support (both flags) for xfs could let gcc-2.95.3 build an "at least booting" kernel. why don't you get 2.4.5 from kernel.org and use the 1.0.1 patches? From owner-linux-xfs@oss.sgi.com Tue Jun 26 05:48:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QCmcX28746 for linux-xfs-outgoing; Tue, 26 Jun 2001 05:48:38 -0700 Received: from piro.kabuki.sfarc.net (mail@[203.36.158.121]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QCmYV28742 for ; Tue, 26 Jun 2001 05:48:35 -0700 Received: from daniel by piro.kabuki.sfarc.net with local (Exim 3.22 #1 (Debian)) id 15EsGb-0001Kd-00; Tue, 26 Jun 2001 22:48:29 +1000 Date: Tue, 26 Jun 2001 22:48:28 +1000 From: Daniel Stone To: Seth Mos Cc: Toralf Lund , linux-xfs@oss.sgi.com Subject: Re: Integration of XFS into Linux source/major dists? Message-ID: <20010626224828.A5060@sfarc.net> Mail-Followup-To: Seth Mos , Toralf Lund , linux-xfs@oss.sgi.com References: <4.3.2.7.2.20010626123529.03fc80f8@pop.xs4all.nl> <4.3.2.7.2.20010626130421.03fc6d00@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20010626130421.03fc6d00@pop.xs4all.nl> User-Agent: Mutt/1.3.18i Organisation: Sadly lacking Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jun 26, 2001 at 01:06:33PM +0200, Seth Mos wrote: > At 12:50 26-6-2001 +0200, Toralf Lund wrote: > > > >We're currently using XFS on a 180Gb RAID volume, by the way, and > > > >everything looks > > > >good so far. > > > > > > It does work, and extremely well in my own case. But that does not mean it > > > will automatically get inserted in the mainstream kernel. > > > We are working on it, but it will take some time to resolve all the items > > > that linus asks for in a patch. > > > >Will you there be a new release any time soon? I'm currently using a patched > >version due to certain NFS client issues. Also, would it be possible to > >make it > >work properly along with devfs from Red Hat? > > 1.0.1 releas (2.4.5 based) is just around the corner. There is not a > specific release date for it yet. But "soon" is the best I can give. > > The devfs issue is something I can not comment upon. I don't use devfs on > any of my machines. The default for 1.0.1 is to not mount it at bootup. I use devfs (without devfsd), and XFS works fine (not that I have it on root, mind, I have XFS on /home and ReiserFS on everything else). Just a general comment, that XFS is rather invasive. It includes some heavy page buffering code, and is also shipped with the kernel debugger patch. Just the fact that I had to hand-edit twenty-two files to try and get it working with the -ac series (it actually touched countless others). It's no small thing, and you wouldn't believe the firey hoops ReiserFS had to jump through. I honestly think that XFS would be very hard-pressed to get into 2.4.x, but it may make it. Just depends on how good Linus is feeling - follow "Care and Feeding of Your Linus" ;) :) d -- Daniel Stone "can NE1 help me aim nuclear weaponz????? /MSG ME!!" From owner-linux-xfs@oss.sgi.com Tue Jun 26 05:51:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QCppl28866 for linux-xfs-outgoing; Tue, 26 Jun 2001 05:51:51 -0700 Received: from piro.kabuki.sfarc.net (mail@[203.36.158.121]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QCpnV28863 for ; Tue, 26 Jun 2001 05:51:49 -0700 Received: from daniel by piro.kabuki.sfarc.net with local (Exim 3.22 #1 (Debian)) id 15EsJh-0001LA-00; Tue, 26 Jun 2001 22:51:41 +1000 Date: Tue, 26 Jun 2001 22:51:40 +1000 From: Daniel Stone To: Mike Burger Cc: Toralf Lund , linux-xfs@oss.sgi.com Subject: Re: Integration of XFS into Linux source/major dists? Message-ID: <20010626225140.B5060@sfarc.net> Mail-Followup-To: Mike Burger , Toralf Lund , linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i Organisation: Sadly lacking Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jun 26, 2001 at 07:07:34AM -0400, Mike Burger wrote: > They're plans are exactly what the Red Hat source said...they're working > toward getting their code approved, for inclusion, by Linus Torvalds. > Not much winds up in a distribution level kernel unless it's already been > approved by Linus. Um, you haven't actually seen this for yourself, have you? Not much goes into Debian (most that does is stuff that's already in the latest -pre, just backported by Xu), but RedHat is absolutely amazing. Download their kernel source one time, at one stage they had over 200 individual patches in. It's like all of their packages, they have stacks of patches that generally break stuff, and that they never submit upstream anyway. -- Daniel Stone "can NE1 help me aim nuclear weaponz????? /MSG ME!!" From owner-linux-xfs@oss.sgi.com Tue Jun 26 05:56:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QCu2u28991 for linux-xfs-outgoing; Tue, 26 Jun 2001 05:56:02 -0700 Received: from indonesia.kscanners.no (indonesia.kscanners.no [193.214.130.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QCu0V28988 for ; Tue, 26 Jun 2001 05:56:00 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=kscanners.com) by indonesia.kscanners.no with esmtp (Exim 3.22 #1) id 15EsNf-0006Lu-00; Tue, 26 Jun 2001 14:55:47 +0200 Message-ID: <3B388653.FD293A68@kscanners.com> Date: Tue, 26 Jun 2001 14:55:47 +0200 From: Toralf Lund Organization: Kongsberg Scanners AS X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-0.2.9 i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Stone CC: Mike Burger , linux-xfs@oss.sgi.com Subject: Re: Integration of XFS into Linux source/major dists? References: <20010626225140.B5060@sfarc.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Daniel Stone wrote: > On Tue, Jun 26, 2001 at 07:07:34AM -0400, Mike Burger wrote: > > They're plans are exactly what the Red Hat source said...they're working > > toward getting their code approved, for inclusion, by Linus Torvalds. > > Not much winds up in a distribution level kernel unless it's already been > > approved by Linus. > > Um, you haven't actually seen this for yourself, have you? Not much goes > into Debian (most that does is stuff that's already in the latest -pre, just > backported by Xu), but RedHat is absolutely amazing. Download their kernel > source one time, at one stage they had over 200 individual patches in. It's > like all of their packages, they have stacks of patches that generally break > stuff, and that they never submit upstream anyway. Red Hat's only claim regarding this, is that they never make changes that add system calls, or modify their API. - Toralf From owner-linux-xfs@oss.sgi.com Tue Jun 26 06:37:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QDbSn29570 for linux-xfs-outgoing; Tue, 26 Jun 2001 06:37:28 -0700 Received: from dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QDbPV29567 for ; Tue, 26 Jun 2001 06:37:25 -0700 Received: (from ak@localhost) by dkp.com (8.9.3/8.9.3) id JAA17157 for linux-xfs@oss.sgi.com; Tue, 26 Jun 2001 09:37:19 -0400 Date: Tue, 26 Jun 2001 09:37:18 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: Oops - 2.4.2-SGI_XFS_1.0.1_PR1 Message-ID: <20010626093718.A16841@key.dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20010625194743.A5726@key.dkp.com> <4914.993519972@kao2.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <4914.993519972@kao2.melbourne.sgi.com>; from kaos@melbourne.sgi.com on Tue, Jun 26, 2001 at 11:46:12AM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jun 26, 2001 at 11:46:12AM +1000, Keith Owens wrote: > Capture the serial console output. 'bt' to trace the failing > task is probably all you need at this stage. For an oops it > is usually only the current task that is interesting. For > loops and hangs, 'ps' and 'bta' are useful to get backtrace > for all processes. Okay... This happened during... either test 13 or 14 or 15 of the checks in the cmd/xfstests directory. (Unfortunately, the screen saver on the machine's console appears to have kicked in overnight....(?)) Will anything else from kdb be useful to have before I reboot and try again? Andrew Klaassen Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: c0156c6a pgd entry f68ff000: 0000000000000000 pmd entry f68ff000: 0000000000000000 ... pmd not present! Entering kdb (current=0xf68b8000, pid 649) Oops: Oops due to oops @ 0xc0156c6a eax = 0x00000000 ebx = 0x00001000 ecx = 0x00000400 edx = 0xe6be8e60 esi = 0x00000001 edi = 0x00000000 esp = 0xf68b9ddc eip = 0xc0156c6a ebp = 0x00003dbd xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010246 xds = 0xe6be0018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf68b9da8 kdb> bt EBP EIP Function(args) 0x00003dbd 0xc0156c6a ext2_alloc_branch+0xf2 (0xf6b6a040, 0x2, 0x3dbc, 0xf68b9e) kernel .text 0xc0100000 0xc0156b78 0xc0156d9c 0xc01570d0 ext2_get_block+0x334 (0xf6b6a040, 0xc, 0xe6bd75a0, 0x1, 0) kernel .text 0xc0100000 0xc0156d9c 0xc0157298 0xc0135e21 __block_prepare_write+0x139 (0xf6b6a040, 0xc209bd48, 0x0,) kernel .text 0xc0100000 0xc0135ce8 0xc0135fe4 0xc0136776 block_prepare_write+0x22 (0xc209bd48, 0x0, 0x60, 0xc0156d) kernel .text 0xc0100000 0xc0136754 0xc01367c4 0xc01574b1 ext2_prepare_write+0x19 (0xf6978860, 0xc209bd48, 0x0, 0x6) kernel .text 0xc0100000 0xc0157498 0xc01574b8 0xc0127c39 generic_file_write+0x401 (0xf6978860, 0x4001900c, 0x60, 0) kernel .text 0xc0100000 0xc0127838 0xc0127ec8 0xc01338ba sys_write+0x8e (0x2, 0x40019000, 0x6c, 0x6c, 0x40019000) kernel .text 0xc0100000 0xc013382c 0xc01338f0 0xc0108edb system_call+0x33 kernel .text 0xc0100000 0xc0108ea8 0xc0108ee0 From owner-linux-xfs@oss.sgi.com Tue Jun 26 06:55:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QDtI029877 for linux-xfs-outgoing; Tue, 26 Jun 2001 06:55:18 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QDtGV29874 for ; Tue, 26 Jun 2001 06:55:16 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA28340 for ; Tue, 26 Jun 2001 06:55:11 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA2259190; Tue, 26 Jun 2001 08:53:59 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA15118; Tue, 26 Jun 2001 08:53:59 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5QDuDv22566; Tue, 26 Jun 2001 08:56:13 -0500 Message-Id: <200106261356.f5QDuDv22566@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andrew Klaassen cc: linux-xfs@oss.sgi.com Subject: Re: Oops - 2.4.2-SGI_XFS_1.0.1_PR1 In-Reply-To: Message from Andrew Klaassen of "Tue, 26 Jun 2001 09:37:18 EDT." <20010626093718.A16841@key.dkp.com> Date: Tue, 26 Jun 2001 08:56:13 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Tue, Jun 26, 2001 at 11:46:12AM +1000, > Keith Owens wrote: > > > Capture the serial console output. 'bt' to trace the failing > > task is probably all you need at this stage. For an oops it > > is usually only the current task that is interesting. For > > loops and hangs, 'ps' and 'bta' are useful to get backtrace > > for all processes. > > Okay... > > This happened during... either test 13 or 14 or 15 of the checks > in the cmd/xfstests directory. (Unfortunately, the screen saver > on the machine's console appears to have kicked in > overnight....(?)) > > Will anything else from kdb be useful to have before I reboot > and try again? OK, I know what this is - thanks for the stack trace, you have a highmem system correct? There was a core kernel bug which xfs appeared to be able to find. I will check with Eric that the fix goes into the 1.0.1 code before we finalize it. This patch (cut and pasted, so hand apply) should fix it: --- S6-pre2/fs/buffer.c Fri Jun 8 18:29:03 2001 +++ /tmp/buffer.c Tue Jun 12 13:17:57 2001 @@ -646,8 +646,8 @@ /* Another device? */ if (bh->b_dev != dev) continue; - /* Part of a mapping? */ - if (bh->b_page->mapping) + /* Not hashed? */ + if (!bh->b_pprev) continue; if (buffer_locked(bh)) { atomic_inc(&bh->b_count); @@ -710,6 +710,8 @@ for (i = nr_buffers_type[nlist]; i > 0 ; bh = bh_next, i--) { bh_next = bh->b_next_free; if (bh->b_dev != dev || bh->b_size == size) + continue; + if (!bh->b_pprev) continue; if (buffer_locked(bh)) { atomic_inc(&bh->b_count); Steve > > Andrew Klaassen > > > Unable to handle kernel NULL pointer dereference at virtual address 00000000 > printing eip: > c0156c6a > pgd entry f68ff000: 0000000000000000 > pmd entry f68ff000: 0000000000000000 > ... pmd not present! > > Entering kdb (current=0xf68b8000, pid 649) Oops: Oops > due to oops @ 0xc0156c6a > eax = 0x00000000 ebx = 0x00001000 ecx = 0x00000400 edx = 0xe6be8e60 > esi = 0x00000001 edi = 0x00000000 esp = 0xf68b9ddc eip = 0xc0156c6a > ebp = 0x00003dbd xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010246 > xds = 0xe6be0018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf68b9da8 > kdb> bt > EBP EIP Function(args) > 0x00003dbd 0xc0156c6a ext2_alloc_branch+0xf2 (0xf6b6a040, 0x2, 0x3dbc, 0xf68b > 9e) > kernel .text 0xc0100000 0xc0156b78 0xc0156d9c > 0xc01570d0 ext2_get_block+0x334 (0xf6b6a040, 0xc, 0xe6bd75a0, 0x1, > 0) > kernel .text 0xc0100000 0xc0156d9c 0xc0157298 > 0xc0135e21 __block_prepare_write+0x139 (0xf6b6a040, 0xc209bd48, 0x > 0,) > kernel .text 0xc0100000 0xc0135ce8 0xc0135fe4 > 0xc0136776 block_prepare_write+0x22 (0xc209bd48, 0x0, 0x60, 0xc015 > 6d) > kernel .text 0xc0100000 0xc0136754 0xc01367c4 > 0xc01574b1 ext2_prepare_write+0x19 (0xf6978860, 0xc209bd48, 0x0, 0 > x6) > kernel .text 0xc0100000 0xc0157498 0xc01574b8 > 0xc0127c39 generic_file_write+0x401 (0xf6978860, 0x4001900c, 0x60, > 0) > kernel .text 0xc0100000 0xc0127838 0xc0127ec8 > 0xc01338ba sys_write+0x8e (0x2, 0x40019000, 0x6c, 0x6c, 0x40019000 > ) > kernel .text 0xc0100000 0xc013382c 0xc01338f0 > 0xc0108edb system_call+0x33 > kernel .text 0xc0100000 0xc0108ea8 0xc0108ee0 From owner-linux-xfs@oss.sgi.com Tue Jun 26 07:09:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QE9nk30207 for linux-xfs-outgoing; Tue, 26 Jun 2001 07:09:49 -0700 Received: from dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QE9mV30204 for ; Tue, 26 Jun 2001 07:09:48 -0700 Received: (from ak@localhost) by dkp.com (8.9.3/8.9.3) id KAA17847 for linux-xfs@oss.sgi.com; Tue, 26 Jun 2001 10:09:47 -0400 Date: Tue, 26 Jun 2001 10:09:47 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: Oops - 2.4.2-SGI_XFS_1.0.1_PR1 Message-ID: <20010626100947.D16841@key.dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200106261356.f5QDuDv22566@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200106261356.f5QDuDv22566@jen.americas.sgi.com>; from lord@sgi.com on Tue, Jun 26, 2001 at 08:56:13AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jun 26, 2001 at 08:56:13AM -0500, Steve Lord wrote: > OK, I know what this is - thanks for the stack trace, you have > a highmem system correct? Ummmm.... Is 1 Gig highmem? Is there a /proc file that I can cat to find out? (I assume this means I can hit the reset button...?) Andrew Klaassen From owner-linux-xfs@oss.sgi.com Tue Jun 26 07:14:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QEEtj30357 for linux-xfs-outgoing; Tue, 26 Jun 2001 07:14:55 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QEEsV30354 for ; Tue, 26 Jun 2001 07:14:54 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA03670 for ; Tue, 26 Jun 2001 07:12:04 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2266492; Tue, 26 Jun 2001 09:13:37 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA82516; Tue, 26 Jun 2001 09:13:37 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5QEFoW22635; Tue, 26 Jun 2001 09:15:50 -0500 Message-Id: <200106261415.f5QEFoW22635@jen.americas.sgi.com> To: Andrew Klaassen cc: linux-xfs@oss.sgi.com Subject: Re: Oops - 2.4.2-SGI_XFS_1.0.1_PR1 References: <200106261356.f5QDuDv22566@jen.americas.sgi.com> <20010626100947.D16841@key.dkp.com> Comments: In-reply-to Andrew Klaassen message dated "Tue, 26 Jun 2001 10:09:47 -0400." Date: Tue, 26 Jun 2001 09:15:50 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Tue, Jun 26, 2001 at 08:56:13AM -0500, > Steve Lord wrote: > > > OK, I know what this is - thanks for the stack trace, you have > > a highmem system correct? > > Ummmm.... > > Is 1 Gig highmem? It is if you are running the correct kernel, cat /proc/meminfo if the HighTotal line is non-zero you are running highmem. > > Is there a /proc file that I can cat to find out? > > (I assume this means I can hit the reset button...?) Yes, we do not need any other info from this. Thanks Steve > > Andrew Klaassen From owner-linux-xfs@oss.sgi.com Tue Jun 26 07:34:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QEYqQ30897 for linux-xfs-outgoing; Tue, 26 Jun 2001 07:34:52 -0700 Received: from dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QEYpV30894 for ; Tue, 26 Jun 2001 07:34:51 -0700 Received: (from ak@localhost) by dkp.com (8.9.3/8.9.3) id KAA18162 for linux-xfs@oss.sgi.com; Tue, 26 Jun 2001 10:34:48 -0400 Date: Tue, 26 Jun 2001 10:34:48 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: Oops - 2.4.2-SGI_XFS_1.0.1_PR1 Message-ID: <20010626103448.E16841@key.dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200106261356.f5QDuDv22566@jen.americas.sgi.com> <20010626100947.D16841@key.dkp.com> <200106261415.f5QEFoW22635@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200106261415.f5QEFoW22635@jen.americas.sgi.com>; from lord@sgi.com on Tue, Jun 26, 2001 at 09:15:50AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jun 26, 2001 at 09:15:50AM -0500, Steve Lord wrote: > > Is 1 Gig highmem? > It is if you are running the correct kernel, cat /proc/meminfo > if the HighTotal line is non-zero you are running highmem. Ah. Indeed. Thanks much. Will upgrade to PR2 promptly. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Tue Jun 26 07:44:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QEiU331199 for linux-xfs-outgoing; Tue, 26 Jun 2001 07:44:30 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QEiTV31196 for ; Tue, 26 Jun 2001 07:44:30 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA04020 for ; Tue, 26 Jun 2001 07:44:24 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2265633; Tue, 26 Jun 2001 09:43:12 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA01069; Tue, 26 Jun 2001 09:43:12 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5QEjPC23079; Tue, 26 Jun 2001 09:45:25 -0500 Message-Id: <200106261445.f5QEjPC23079@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andrew Klaassen cc: linux-xfs@oss.sgi.com Subject: Re: Oops - 2.4.2-SGI_XFS_1.0.1_PR1 In-Reply-To: Message from Andrew Klaassen of "Tue, 26 Jun 2001 10:34:48 EDT." <20010626103448.E16841@key.dkp.com> Date: Tue, 26 Jun 2001 09:45:25 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Tue, Jun 26, 2001 at 09:15:50AM -0500, > Steve Lord wrote: > > > > Is 1 Gig highmem? > > > It is if you are running the correct kernel, cat /proc/meminfo > > if the HighTotal line is non-zero you are running highmem. > > Ah. Indeed. Thanks much. Will upgrade to PR2 promptly. > > Andrew Klaassen I just looked, the fix is indeed in there, there should be a PR3 today which will be based on the newer kernel from RedHat which came out over the weekend. Steve From owner-linux-xfs@oss.sgi.com Tue Jun 26 08:04:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QF4SY31556 for linux-xfs-outgoing; Tue, 26 Jun 2001 08:04:28 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QF4RV31552 for ; Tue, 26 Jun 2001 08:04:27 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA06655 for ; Tue, 26 Jun 2001 08:01:37 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2263019; Tue, 26 Jun 2001 10:01:35 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA60757; Tue, 26 Jun 2001 10:01:34 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5QF3mR26633; Tue, 26 Jun 2001 10:03:48 -0500 Message-Id: <200106261503.f5QF3mR26633@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: J Landman cc: linux-xfs@oss.sgi.com Subject: Re: A possible xfs bug: cp/mv to/from an xfs filesystem In-Reply-To: Message from J Landman of "Tue, 26 Jun 2001 07:49:44 EDT." Date: Tue, 26 Jun 2001 10:03:47 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Please take a look in the system log to see if you got an oops report to go with this. Also, can you report the compiler version you used, and did xfs_repair -n report anything? This is certainly something I have not seen before by the way. Any chance of building a debug version of cp and running it in gdb? Thanks Steve > Folks: > > Let me know if this is not the appropriate forum for this. I have what > I will call an annoying problem. It seems that cp/mv have stopped working > between xfs and the other file systems. Here are the basics: > > uname -a : Linux genome.dtw.macsch.com 2.4.5-xfs #2 Thu Jun 21 03:06:30 EDT 2 > 001 i686 > unknown > > (plain 2.4.5 using the xfs patches from last week for 2.4.5) > > file system /work is a RAID 0 /dev/md0 device, striped across two disks on > one controller. Other file systems are reiserfs (or some ext2). > > Here is the problem > > (from a reiserfs filesystem) > > [landman@genome.dtw.macsch.com:~] > 11 >cp XML-Config-0.2.tar.gz /work/ > Segmentation fault (core dumped) > > (whoops) > > [landman@genome.dtw.macsch.com:~] > 12 >cp XML-Config-0.2.tar.gz xml.tgz > > (ok) > > now cd to /work (the xfs filesystem) > [landman@genome.dtw.macsch.com:/work] > 15 >cp installer i > Segmentation fault > > so we see that it may be independent of where it starts from (xfs/reiserfs > to xfs) > > so I ran strace on the file, and this is what I got near the end (after > the umask) > > umask(0) = 02 > lstat64("i", {st_mode=S_IFREG|0755, st_size=0, ...}) = 0 > stat64("i", {st_mode=S_IFREG|0755, st_size=0, ...}) = 0 > stat64("installer", {st_mode=S_IFREG|0755, st_size=4332356, ...}) = 0 > stat64("i", {st_mode=S_IFREG|0755, st_size=0, ...}) = 0 > open("installer", O_RDONLY|O_LARGEFILE) = 3 > open("i", O_WRONLY|O_TRUNC|O_LARGEFILE) = 4 > fstat64(4, {st_mode=S_IFREG|0755, st_size=0, ...}) = 0 > fstat64(3, {st_mode=S_IFREG|0755, st_size=4332356, ...}) = 0 > --- SIGSEGV (Segmentation fault) --- > +++ killed by SIGSEGV +++ > > looking at /bin/cp, I see > > [landman@genome.dtw.macsch.com:/work] > 17 >ldd /bin/cp > libc.so.6 => /lib/libc.so.6 (0x40029000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > > [landman@genome.dtw.macsch.com:/work] > 18 >rpm -qf /lib/libc.so.6 > glibc-2.2.2-4mdk > > This is a mandrake 8.0 system. I used the original Russell Mandrake > patched kernel until I started to notice this. I can move files around > using tar. Tar uses the same libraries as cp, with the additional librt, > and libpthread. This is all being done using the tcsh. This uses the > fileutils-4.0. I downloaded and handcompiled 4.1 of fileutils, and I get > the same behavior. > > What else should I do? I just want to make this go away. File system was > built using the 1.0 mkfs. I have run xfs_check and xfs_repair -n on it. > I can back it up and rebuild the FS if needed. Let me know what you > think. > > Joe > > -- > Joe Landman, > landman@mediaone.net > joe.landman@mscsoftware.com From owner-linux-xfs@oss.sgi.com Tue Jun 26 09:04:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QG4bG32688 for linux-xfs-outgoing; Tue, 26 Jun 2001 09:04:37 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QG4ZV32685 for ; Tue, 26 Jun 2001 09:04:36 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA15606 for ; Tue, 26 Jun 2001 09:04:29 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA2265266; Tue, 26 Jun 2001 11:03:19 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA00598; Tue, 26 Jun 2001 11:03:17 -0500 (CDT) Message-ID: <3B38B0AE.6F52AD0@sgi.com> Date: Tue, 26 Jun 2001 10:56:30 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Toralf Lund CC: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: Integration of XFS into Linux source/major dists? References: <4.3.2.7.2.20010626123529.03fc80f8@pop.xs4all.nl> <4.3.2.7.2.20010626130421.03fc6d00@pop.xs4all.nl> <3B386DF9.AAC07E7@kscanners.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Toralf Lund wrote: > > The devfs issue is something I can not comment upon. I don't use devfs on > > any of my machines. The default for 1.0.1 is to not mount it at bootup. > > So what you are saying is that this has been changed since 1.0? I seem to > remember that this wouldn't boot at all when I first installed it, and that > installing devfs via "rescue mode" resolved the problems. For XFS 1.0 / RH 7.1, we released our own version of devfsd, which was essentially Mandrake's patched devfsd, with some config file magic to try to handle /dev/mouse and /dev/cdrom transparently. I'm not aware of any real problems with using Red Hat's devfsd instead - there may be some - but I think it's more of a feature issue than a compatibility issue. In any case, mounting devfs on /dev will not be the default in 1.0.1. :) -Eric From owner-linux-xfs@oss.sgi.com Tue Jun 26 10:11:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QHBiN01332 for linux-xfs-outgoing; Tue, 26 Jun 2001 10:11:44 -0700 Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QHBgV01329 for ; Tue, 26 Jun 2001 10:11:42 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f5QHA2503945; Tue, 26 Jun 2001 12:10:03 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <3B38C1EA.F5C3435@thebarn.com> Date: Tue, 26 Jun 2001 12:10:02 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Andrew Klaassen , linux-xfs@oss.sgi.com Subject: Re: Oops - 2.4.2-SGI_XFS_1.0.1_PR1 References: <200106261356.f5QDuDv22566@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Note: the rawhide RPMs does have this patch applied/ Steve Lord wrote: > > On Tue, Jun 26, 2001 at 11:46:12AM +1000, > > Keith Owens wrote: > > > > > Capture the serial console output. 'bt' to trace the failing > > > task is probably all you need at this stage. For an oops it > > > is usually only the current task that is interesting. For > > > loops and hangs, 'ps' and 'bta' are useful to get backtrace > > > for all processes. > > > > Okay... > > > > This happened during... either test 13 or 14 or 15 of the checks > > in the cmd/xfstests directory. (Unfortunately, the screen saver > > on the machine's console appears to have kicked in > > overnight....(?)) > > > > Will anything else from kdb be useful to have before I reboot > > and try again? > > OK, I know what this is - thanks for the stack trace, you have a highmem > system correct? There was a core kernel bug which xfs appeared to be > able to find. I will check with Eric that the fix goes into the 1.0.1 > code before we finalize it. This patch (cut and pasted, so hand apply) > should fix it: > > --- S6-pre2/fs/buffer.c Fri Jun 8 18:29:03 2001 > +++ /tmp/buffer.c Tue Jun 12 13:17:57 2001 > @@ -646,8 +646,8 @@ > /* Another device? */ > if (bh->b_dev != dev) > continue; > - /* Part of a mapping? */ > - if (bh->b_page->mapping) > + /* Not hashed? */ > + if (!bh->b_pprev) > continue; > if (buffer_locked(bh)) { > atomic_inc(&bh->b_count); > @@ -710,6 +710,8 @@ > for (i = nr_buffers_type[nlist]; i > 0 ; bh = bh_next, i--) { > bh_next = bh->b_next_free; > if (bh->b_dev != dev || bh->b_size == size) > + continue; > + if (!bh->b_pprev) > continue; > if (buffer_locked(bh)) { > atomic_inc(&bh->b_count); > > Steve > > > > > Andrew Klaassen > > > > > > Unable to handle kernel NULL pointer dereference at virtual address 00000000 > > printing eip: > > c0156c6a > > pgd entry f68ff000: 0000000000000000 > > pmd entry f68ff000: 0000000000000000 > > ... pmd not present! > > > > Entering kdb (current=0xf68b8000, pid 649) Oops: Oops > > due to oops @ 0xc0156c6a > > eax = 0x00000000 ebx = 0x00001000 ecx = 0x00000400 edx = 0xe6be8e60 > > esi = 0x00000001 edi = 0x00000000 esp = 0xf68b9ddc eip = 0xc0156c6a > > ebp = 0x00003dbd xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010246 > > xds = 0xe6be0018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf68b9da8 > > kdb> bt > > EBP EIP Function(args) > > 0x00003dbd 0xc0156c6a ext2_alloc_branch+0xf2 (0xf6b6a040, 0x2, 0x3dbc, 0xf68b > > 9e) > > kernel .text 0xc0100000 0xc0156b78 0xc0156d9c > > 0xc01570d0 ext2_get_block+0x334 (0xf6b6a040, 0xc, 0xe6bd75a0, 0x1, > > 0) > > kernel .text 0xc0100000 0xc0156d9c 0xc0157298 > > 0xc0135e21 __block_prepare_write+0x139 (0xf6b6a040, 0xc209bd48, 0x > > 0,) > > kernel .text 0xc0100000 0xc0135ce8 0xc0135fe4 > > 0xc0136776 block_prepare_write+0x22 (0xc209bd48, 0x0, 0x60, 0xc015 > > 6d) > > kernel .text 0xc0100000 0xc0136754 0xc01367c4 > > 0xc01574b1 ext2_prepare_write+0x19 (0xf6978860, 0xc209bd48, 0x0, 0 > > x6) > > kernel .text 0xc0100000 0xc0157498 0xc01574b8 > > 0xc0127c39 generic_file_write+0x401 (0xf6978860, 0x4001900c, 0x60, > > 0) > > kernel .text 0xc0100000 0xc0127838 0xc0127ec8 > > 0xc01338ba sys_write+0x8e (0x2, 0x40019000, 0x6c, 0x6c, 0x40019000 > > ) > > kernel .text 0xc0100000 0xc013382c 0xc01338f0 > > 0xc0108edb system_call+0x33 > > kernel .text 0xc0100000 0xc0108ea8 0xc0108ee0 -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Tue Jun 26 10:53:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QHrvj03577 for linux-xfs-outgoing; Tue, 26 Jun 2001 10:53:57 -0700 Received: from mail.levigo.de (mail.levigo.de [193.197.156.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QHrrV03574 for ; Tue, 26 Jun 2001 10:53:53 -0700 Received: from levigo.de (zoidberg.cogito.de [193.197.156.88]) by mail.levigo.de (Postfix) with ESMTP id 587D27EA4 for ; Tue, 26 Jun 2001 19:51:27 +0200 (CEST) Message-ID: <3B38CC2F.5615165E@levigo.de> Date: Tue, 26 Jun 2001 19:53:51 +0200 From: Klaus Rein Organization: levigo systems gmbh X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: xfs_force_shutdown References: <200106221820.f5MIKEi01932@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Forced shutdown is used when an I/O error is reported by the > underlying layers. If everything else is working correctly it > usually means there is a hardware problem. I had already assumed that, but wanted to know for sure. The hardware is ok. > On Linux there is a chance you have been bitten by a compiler whih > does not like the xfs code. # gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81) We never had similar problems without the soft raid. At least not with cvs snapshots after the 1.0-Release. But at that point we only had one server machine, no shared SCSI and no heartbeat (see below). > I suppose with Raid 1 you may have > stumbled across a case where the raid reconstruction and xfs got in each > other's way. Is there any way you can tell if reconstruction was in > progress? It was. The setup a little more in detail: There are two SCSI disks in an external box, connected via SCSI with two server machines and heartbeat running on both of them. The filesystem is xfs with raid1 (md-tools) exported via nfs. The heartbeat script starts and stops nfs, the raid and does the (un)loading of the corresponding kernel modules. Two clients mount the exported filesystem and try to stress it. The system disks of the servers are IDE. The power of the primary (as defined in heartbeat) server is controlled from a timeswitch (2h on, 2h off). What I do not understand (and I'm not sure if it is a xfs or a md/vfs/etc problem): - the primary server gets switched off - when the secondary server takes the disks the raid seems to be ok and never gets sync'ed (takes about 30 minutes) - after the primary server is back up again two hours later the raid is always sync'ed [1] I would have expected it the other way round. Klaus. [1] At this point the failure described in my previous posting occured while the 'test cycle' had been running for a few days without any problem. From owner-linux-xfs@oss.sgi.com Tue Jun 26 10:59:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QHxXM03731 for linux-xfs-outgoing; Tue, 26 Jun 2001 10:59:33 -0700 Received: from afaranis1.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QHxWV03728 for ; Tue, 26 Jun 2001 10:59:32 -0700 Received: from tduffy-lnx.afara.com (tduffy-lnx.afara.com [10.2.4.191]) by afaranis1.afara.com (8.9.3/8.9.3) with ESMTP id KAA25655; Tue, 26 Jun 2001 10:58:30 -0700 (PDT) Subject: Re: RedHat 7.1 (XFS 1.0) + OpenOffice 627 or 625 From: Thomas Duffy To: Seth Mos Cc: linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20010626134654.02e9fba8@pop.xs4all.nl> References: <3B3732C3.76E797B0@rebel.net.au> <3B3732C3.76E797B0@rebel.net.au> <4.3.2.7.2.20010626134654.02e9fba8@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.10.99 (Preview Release) Date: 26 Jun 2001 10:57:59 -0700 Message-Id: <993578279.16386.0.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 26 Jun 2001 13:48:30 +0200, Seth Mos wrote: > Where do I find OpenOffice? I will try it for you. openoffice.org of course! watch out, it is a *big* download. -tduffy From owner-linux-xfs@oss.sgi.com Tue Jun 26 11:14:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QIEOv04101 for linux-xfs-outgoing; Tue, 26 Jun 2001 11:14:24 -0700 Received: from biobio.vexcel.com (biobio.vexcel.com [192.92.90.108]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QIENV04098 for ; Tue, 26 Jun 2001 11:14:23 -0700 Received: from [192.168.1.17] (router.vexcel.com [192.92.90.254]) by biobio.vexcel.com (8.9.3+Sun/8.9.1) with ESMTP id MAA09207 for ; Tue, 26 Jun 2001 12:14:16 -0600 (MDT) Mime-Version: 1.0 X-Sender: brissing@mail.vexcel.com (Unverified) Message-Id: In-Reply-To: <3B38B0AE.6F52AD0@sgi.com> References: <4.3.2.7.2.20010626123529.03fc80f8@pop.xs4all.nl> <4.3.2.7.2.20010626130421.03fc6d00@pop.xs4all.nl> <3B386DF9.AAC07E7@kscanners.com> <3B38B0AE.6F52AD0@sgi.com> Date: Tue, 26 Jun 2001 12:10:35 -0600 To: linux-xfs@oss.sgi.com From: Dean Brissinger Subject: To devfs or not to devfs Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10:56 AM -0500 6/26/01, Eric Sandeen wrote: >Toralf Lund wrote: > > > So what you are saying is that this has been changed since 1.0? I seem to > > remember that this wouldn't boot at all when I first installed it, and that > > installing devfs via "rescue mode" resolved the problems. > >For XFS 1.0 / RH 7.1, we released our own version of devfsd, which was >essentially Mandrake's patched devfsd, with some config file magic to >try to handle /dev/mouse and /dev/cdrom transparently. > >In any case, mounting devfs on /dev will not be the default in 1.0.1. I personally have had problems keeping /dev/cdrom working but have been under the impression that devfs was needed for most of the SGI tools to work. Will all the other [non XFS] OSS SGI stuff work regardless? I also heard a rumor that devfs was used to work around some problems booting from an XFS partition (much like one can't boot from ReiserFS). It all boils down to one question. Is devfs a good thing to use or not? -- . . . . . . . . ooo . . . . ooo . . . . . . . . . . . . Dean Brissinger - Systems Administrator . . Direct: 303-583-0278 Main: 303-444-0094 . . Fax: 303-583-0246 http://www.vexcel.com/ . . . . . . . . . . oOOo . . A . . oOOo . . . . . . . . 0 0 '```` From owner-linux-xfs@oss.sgi.com Tue Jun 26 11:21:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QILVs04309 for linux-xfs-outgoing; Tue, 26 Jun 2001 11:21:31 -0700 Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QILUV04306 for ; Tue, 26 Jun 2001 11:21:30 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f5QILL523321; Tue, 26 Jun 2001 13:21:22 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <3B38D2A0.190849D1@thebarn.com> Date: Tue, 26 Jun 2001 13:21:20 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Dean Brissinger CC: linux-xfs@oss.sgi.com Subject: Re: To devfs or not to devfs References: <4.3.2.7.2.20010626123529.03fc80f8@pop.xs4all.nl> <4.3.2.7.2.20010626130421.03fc6d00@pop.xs4all.nl> <3B386DF9.AAC07E7@kscanners.com> <3B38B0AE.6F52AD0@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dean Brissinger wrote: > At 10:56 AM -0500 6/26/01, Eric Sandeen wrote: > >Toralf Lund wrote: > > > > > So what you are saying is that this has been changed since 1.0? I seem to > > > remember that this wouldn't boot at all when I first installed it, and that > > > installing devfs via "rescue mode" resolved the problems. > > > >For XFS 1.0 / RH 7.1, we released our own version of devfsd, which was > >essentially Mandrake's patched devfsd, with some config file magic to > >try to handle /dev/mouse and /dev/cdrom transparently. > > > >In any case, mounting devfs on /dev will not be the default in 1.0.1. > > I personally have had problems keeping /dev/cdrom working but > have been under the impression that devfs was needed for most of the > SGI tools to work. Nope not true. > Will all the other [non XFS] OSS SGI stuff work > regardless? I also heard a rumor that devfs was used to work around > some problems booting from an XFS partition (much like one can't boot > from ReiserFS). Also not true. > > > It all boils down to one question. Is devfs a good thing to > use or not? It is a good thing to use, linux has a horribly broken device naming scheme devfs it a good start at fixing it. > > > -- > . . . . . . . . ooo . . . . ooo . . . . . . . . . > . . > . Dean Brissinger - Systems Administrator . > . Direct: 303-583-0278 Main: 303-444-0094 . > . Fax: 303-583-0246 http://www.vexcel.com/ . > . . > . . . . . . . oOOo . . A . . oOOo . . . . . . . . > 0 0 > '```` -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Tue Jun 26 11:22:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QIMfW04444 for linux-xfs-outgoing; Tue, 26 Jun 2001 11:22:41 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QIMeV04440 for ; Tue, 26 Jun 2001 11:22:40 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA09289 for ; Tue, 26 Jun 2001 11:22:39 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2252256; Tue, 26 Jun 2001 13:21:22 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA88181; Tue, 26 Jun 2001 13:21:22 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5QINY306518; Tue, 26 Jun 2001 13:23:34 -0500 Message-Id: <200106261823.f5QINY306518@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Dean Brissinger cc: linux-xfs@oss.sgi.com Subject: Re: To devfs or not to devfs In-Reply-To: Message from Dean Brissinger of "Tue, 26 Jun 2001 12:10:35 MDT." Date: Tue, 26 Jun 2001 13:23:34 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > At 10:56 AM -0500 6/26/01, Eric Sandeen wrote: > >Toralf Lund wrote: > > > > > So what you are saying is that this has been changed since 1.0? I seem t > o > > > remember that this wouldn't boot at all when I first installed it, and t > hat > > > installing devfs via "rescue mode" resolved the problems. > > > >For XFS 1.0 / RH 7.1, we released our own version of devfsd, which was > >essentially Mandrake's patched devfsd, with some config file magic to > >try to handle /dev/mouse and /dev/cdrom transparently. > > > >In any case, mounting devfs on /dev will not be the default in 1.0.1. > > I personally have had problems keeping /dev/cdrom working but > have been under the impression that devfs was needed for most of the > SGI tools to work. Will all the other [non XFS] OSS SGI stuff work > regardless? I also heard a rumor that devfs was used to work around > some problems booting from an XFS partition (much like one can't boot > from ReiserFS). What things are you thinking of? There is nothing that I am aware of which depends on it, there are internal projects here which will require it, but nothing we have released. XFS has no dependency on devfs at all, I run without it all the time on XFS only machines. devfs and XFS are totally independent of each other. > > It all boils down to one question. Is devfs a good thing to > use or not? In theory devfs is a good thing, but a lot of Linux user space is not ready for it. We will be packaging the 1.0.1 version of xfs with it turned off - currently debating if it should even be compiled into the kernel as Redhat has pointed out some problems with devfs to us. I would say you can live without it quite nicely, but if you want to do funky things with device handling and want to be able to read the output of ls in /dev then try turning it on. Steve > > -- > . . . . . . . . ooo . . . . ooo . . . . . . . . . > . . > . Dean Brissinger - Systems Administrator . > . Direct: 303-583-0278 Main: 303-444-0094 . > . Fax: 303-583-0246 http://www.vexcel.com/ . > . . > . . . . . . . oOOo . . A . . oOOo . . . . . . . . > 0 0 > '```` From owner-linux-xfs@oss.sgi.com Tue Jun 26 11:23:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QIN6T04484 for linux-xfs-outgoing; Tue, 26 Jun 2001 11:23:06 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QIN5V04481 for ; Tue, 26 Jun 2001 11:23:05 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA02882 for ; Tue, 26 Jun 2001 11:23:05 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2267885; Tue, 26 Jun 2001 13:21:49 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA85151; Tue, 26 Jun 2001 13:21:48 -0500 (CDT) Message-ID: <3B38D08F.7292B48D@sgi.com> Date: Tue, 26 Jun 2001 13:12:31 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dean Brissinger CC: linux-xfs@oss.sgi.com Subject: Re: To devfs or not to devfs References: <4.3.2.7.2.20010626123529.03fc80f8@pop.xs4all.nl> <4.3.2.7.2.20010626130421.03fc6d00@pop.xs4all.nl> <3B386DF9.AAC07E7@kscanners.com> <3B38B0AE.6F52AD0@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dean Brissinger wrote: > I personally have had problems keeping /dev/cdrom working but > have been under the impression that devfs was needed for most of the > SGI tools to work. Will all the other [non XFS] OSS SGI stuff work > regardless? I also heard a rumor that devfs was used to work around > some problems booting from an XFS partition (much like one can't boot > from ReiserFS). No, devfs did mask one problem early on in the 1.0 prereleases, but it's no longer required in any way for XFS. > It all boils down to one question. Is devfs a good thing to > use or not? It can solve a lot of problems in some situations, but the migration can be painful, and it takes up a lot of OT bandwidth on this list, so it will probably be disabled next time around. -Eric From owner-linux-xfs@oss.sgi.com Tue Jun 26 11:48:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QImG204959 for linux-xfs-outgoing; Tue, 26 Jun 2001 11:48:16 -0700 Received: from dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QImFV04954 for ; Tue, 26 Jun 2001 11:48:15 -0700 Received: (from ak@localhost) by dkp.com (8.9.3/8.9.3) id OAA23310 for linux-xfs@oss.sgi.com; Tue, 26 Jun 2001 14:48:14 -0400 Date: Tue, 26 Jun 2001 14:48:14 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: Oops - 2.4.2-SGI_XFS_1.0.1_PR1 Message-ID: <20010626144814.F16841@key.dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200106261356.f5QDuDv22566@jen.americas.sgi.com> <3B38C1EA.F5C3435@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3B38C1EA.F5C3435@thebarn.com>; from cattelan@thebarn.com on Tue, Jun 26, 2001 at 12:10:02PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jun 26, 2001 at 12:10:02PM -0500, Russell Cattelan wrote: > Note: the rawhide RPMs does have this patch applied/ I'm trying it out as I type. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Tue Jun 26 12:05:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QJ51Z05308 for linux-xfs-outgoing; Tue, 26 Jun 2001 12:05:01 -0700 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QJ50V05304 for ; Tue, 26 Jun 2001 12:05:00 -0700 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Jun 2001 14:04:15 -0500 Message-ID: <85063BBE668FD411944400D0B744267A481B0B@AUSMAIL> From: "Gonyou, Austin" To: linux-xfs@oss.sgi.com Subject: XFSDUMP and multiple filesystems on one tape Date: Tue, 26 Jun 2001 14:04:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is that possible? I didn't see any syntax which showed it was. Any ideas on how to do this would be helpful, or else I guess it's back to tar for me. :) -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com From owner-linux-xfs@oss.sgi.com Tue Jun 26 12:09:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QJ9Zl05471 for linux-xfs-outgoing; Tue, 26 Jun 2001 12:09:35 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QJ9YV05467 for ; Tue, 26 Jun 2001 12:09:34 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip22.idcomm.com [209.60.72.149]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5QJAjl08790 for ; Tue, 26 Jun 2001 13:10:45 -0600 Message-ID: <3B38DE54.37037A97@idcomm.com> Date: Tue, 26 Jun 2001 13:11:16 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: fatal error -- couldn't initialize XFS library Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I had a RH 7.1 system (2.4.6-pre1-xfs) fail to boot properly, most likely because I had swapped drives around. Well, it wasn't exactly a failure, it was that irritating kudzu losing all hardware information. It wanted to reconfigure every single device, it claimed it had never seen them before. I rebooted and reset the drives, but it still claimed the items were new. But since I did not know with certainty that it really was the hard drive placement (I've made this rearrangement before, it never lost its memory of all devices before...and I mean everything), I tried running xfs_repair. First I tried on a read-only single user mode, and it gave the "fatal error --coudn't initialize XFS library". I rebooted to another install on another drive that has XFS, and ran xfs_repair...somewhat indicating maybe there was a problem. Here is the output, some parts snipped that are uninteresting: ~# xfs_repair /dev/sda6 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 .......snip.... - agno = 30 - agno = 31 - agno = 32 - 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 ......snip... - agno = 30 - agno = 31 - agno = 32 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected inode 1266147, moving to lost+found Phase 7 - verify and correct link counts... done Now I rebooted back to the original drive partition, which works fine after telling kudzu to shut up and not reconfigure all the devices and to not prompt me again. Btw, the disconnected inode was empty, size 0. But it appears that xfs_repair is broken on it, because running xfs_repair -n claims it could not initialize the xfs library. The end of an strace makes me believe xfs_repair with "-n" will still refuse to look at a partition that is mounted: open("/etc/mtab", O_RDONLY) = 3 brk(0x80d2000) = 0x80d2000 fstat64(3, {st_mode=S_IFREG|0644, st_size=150, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000 read(3, "/dev/sda6 / xfs rw 0 0\nnone /pro"..., 4096) = 150 read(3, "", 4096) = 0 write(2, "xfs_repair: /dev/sda6 contains a"..., 61xfs_repair: /dev/sda6 contains a writable mounted filesystem ) = 61 close(3) = 0 munmap(0x40018000, 4096) = 0 write(2, "\nfatal error -- ", 16 fatal error -- ) = 16 write(2, "couldn\'t initialize XFS library\n", 32couldn't initialize XFS library ) = 32 _exit(1) = ? Shouldn't xfs_repair allow me to at least attempt to see what it would do with "-n"? I noticed one other thing during the process that is definitely a bug, but not necessarily xfs...it could be a mount bug. While in single user mode, after remounting the partition read-only, it was falsely listed as read/write when the mount command was run to see current mounts. I know it was incorrect becase I tried intentionally to write to a file as a test, and it correctly told me the file could not be saved because the partition was read-only. The output of mount while in single user mode and after sda6 was remounted read-only: /dev/sda6 on / type xfs (rw) none on /proc type proc (rw) /dev/sda5 on /boot type ext2 (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) One more question related to this. Assuming my xfs_repair had not been broken, that whatever caused it to be "unable to initialize xfs library" had not occurred, and that I have the partition mounted read-only, is this still supposed to disallow xfs_repair? Is it still a risk to corruption if one runs xfs_repair on a read-only mounted partition? FYI, none of this seems to have actually harmed anything in any way. I suspect the one inode it unlinked during repair was there because when kudzu came up and it started to setup hardware again, I gave it the three finger salute (which should properly close things down, but possibly it killed kudzu's version of an editor without closing). D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Tue Jun 26 12:11:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QJBOE05586 for linux-xfs-outgoing; Tue, 26 Jun 2001 12:11:24 -0700 Received: from mailhub2.stratus.com (mailhub2.stratus.com [134.111.1.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QJBNV05583 for ; Tue, 26 Jun 2001 12:11:23 -0700 Received: from SWARTZ-D.druber.com (SWARTZ-D.cac.stratus.com [134.111.43.114]) by mailhub2.stratus.com (8.9.3/8.9.3) with ESMTP id PAA16994; Tue, 26 Jun 2001 15:02:05 -0400 (EDT) Message-Id: <5.1.0.14.2.20010626151013.03f132e0@druber-gw.lightband.com> X-Sender: dswartz@druber-gw.lightband.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Jun 2001 15:11:06 -0400 To: "Gonyou, Austin" , linux-xfs@oss.sgi.com From: Dan Swartzendruber Subject: Re: XFSDUMP and multiple filesystems on one tape In-Reply-To: <85063BBE668FD411944400D0B744267A481B0B@AUSMAIL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 02:04 PM 6/26/2001 -0500, Gonyou, Austin wrote: >Is that possible? I didn't see any syntax which showed it was. Any ideas on >how to do this would be helpful, or else I guess it's back to tar for me. :) sorry if i'm coming into the middle of this. i'm putting multiple filesystems on individual tapes (xfs) with no problems, but i'm not doing it directly (i use amanda to backup my server - it works fine with xfs). From owner-linux-xfs@oss.sgi.com Tue Jun 26 12:11:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QJBtC05624 for linux-xfs-outgoing; Tue, 26 Jun 2001 12:11:55 -0700 Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QJBsV05620 for ; Tue, 26 Jun 2001 12:11:55 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.2/8.11.2) with ESMTP id f5QJBbI16383; Tue, 26 Jun 2001 15:11:37 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Tue, 26 Jun 2001 15:11:37 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: To: "Gonyou, Austin" cc: Subject: Re: XFSDUMP and multiple filesystems on one tape In-Reply-To: <85063BBE668FD411944400D0B744267A481B0B@AUSMAIL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 26 Jun 2001 at 2:04pm, Gonyou, Austin wrote > Is that possible? I didn't see any syntax which showed it was. Any ideas on > how to do this would be helpful, or else I guess it's back to tar for me. :) > Just xfsdump to /dev/nst0 (or whatever non-rewinding tape device you want to use). When one filesystem is done, do the next. When the time comes to restore 'mt fsf' to the appropriate filemark and then start up xfsrestore. Or am I missing something? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Tue Jun 26 12:14:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QJEeL05815 for linux-xfs-outgoing; Tue, 26 Jun 2001 12:14:40 -0700 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QJEdV05812 for ; Tue, 26 Jun 2001 12:14:39 -0700 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Jun 2001 14:13:46 -0500 Message-ID: <85063BBE668FD411944400D0B744267A481B0C@AUSMAIL> From: "Gonyou, Austin" To: linux-xfs@oss.sgi.com Subject: RE: XFSDUMP and multiple filesystems on one tape Date: Tue, 26 Jun 2001 14:13:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I see. Well. I was going to use Amanda, but I don't want to run inetd or xinetd. I do run IP tables, but the less software(especially the port or socket kind) the better. So, backing up other computers across ssh or something is pretty easy too, but I really just want this ONE system to backup itself. So was curious if xfsdump can handle multiple filesystems to one tape. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Dan Swartzendruber [mailto:dswartz@druber.com] > Sent: Tuesday, June 26, 2001 2:11 PM > To: Gonyou, Austin; linux-xfs@oss.sgi.com > Subject: Re: XFSDUMP and multiple filesystems on one tape > > > At 02:04 PM 6/26/2001 -0500, Gonyou, Austin wrote: > >Is that possible? I didn't see any syntax which showed it > was. Any ideas on > >how to do this would be helpful, or else I guess it's back > to tar for me. :) > > sorry if i'm coming into the middle of this. i'm putting multiple > filesystems on > individual tapes (xfs) with no problems, but i'm not doing it > directly (i use > amanda to backup my server - it works fine with xfs). > > > > From owner-linux-xfs@oss.sgi.com Tue Jun 26 12:19:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QJJ3e05948 for linux-xfs-outgoing; Tue, 26 Jun 2001 12:19:03 -0700 Received: from mailhub2.stratus.com (mailhub.stratus.com [134.111.1.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QJJ2V05945 for ; Tue, 26 Jun 2001 12:19:03 -0700 Received: from SWARTZ-D.druber.com (SWARTZ-D.cac.stratus.com [134.111.43.114]) by mailhub2.stratus.com (8.9.3/8.9.3) with ESMTP id PAA17353; Tue, 26 Jun 2001 15:09:58 -0400 (EDT) Message-Id: <5.1.0.14.2.20010626151833.00ad00d0@druber-gw.lightband.com> X-Sender: dswartz@druber-gw.lightband.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Jun 2001 15:19:00 -0400 To: "Gonyou, Austin" , linux-xfs@oss.sgi.com From: Dan Swartzendruber Subject: RE: XFSDUMP and multiple filesystems on one tape In-Reply-To: <85063BBE668FD411944400D0B744267A481B0C@AUSMAIL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 02:13 PM 6/26/2001 -0500, Gonyou, Austin wrote: >I see. Well. I was going to use Amanda, but I don't want to run inetd or >xinetd. I do run IP tables, but the less software(especially the port or >socket kind) the better. So, backing up other computers across ssh or >something is pretty easy too, but I really just want this ONE system to >backup itself. So was curious if xfsdump can handle multiple filesystems to >one tape. amanda works fine in single system mode (that is how i use it). i.e. the server is a server and client. From owner-linux-xfs@oss.sgi.com Tue Jun 26 12:20:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QJK8d06056 for linux-xfs-outgoing; Tue, 26 Jun 2001 12:20:08 -0700 Received: from vortex.xnote.com ([65.105.237.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QJK7V06053 for ; Tue, 26 Jun 2001 12:20:07 -0700 Received: from xnote.com (slccheck01.firsthealth.com [209.180.88.28]) by vortex.xnote.com (8.11.0/8.8.7) with ESMTP id f5QIPL408878; Tue, 26 Jun 2001 12:25:21 -0600 Message-ID: <3B38E03E.1010407@xnote.com> Date: Tue, 26 Jun 2001 13:19:26 -0600 From: Vernon McPherron User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.1) Gecko/20010607 X-Accept-Language: en-us MIME-Version: 1.0 To: Karl Hiramoto CC: linux-xfs@oss.sgi.com Subject: Re: missing file / bad file descriptor References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Karl Hiramoto wrote: > how do i fix this? > > > [root@smoke /etc]# ls -la socks* > -rw-r--r-- 1 root root 75 May 21 20:36 socks5.conf > -rw-r--r-- 1 root root 109 May 23 19:13 socks5.conf2 > -rw-r--r-- 1 root root 109 May 21 20:50 > socks5.conf.bak > [root@smoke /etc]# rm socks5.conf > rm: cannot remove `socks5.conf': No such file or directory > [root@smoke /etc]# have you tried rm -i * ??? -- -=/Vernon McPherron/=- From owner-linux-xfs@oss.sgi.com Tue Jun 26 12:21:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QJLGr06226 for linux-xfs-outgoing; Tue, 26 Jun 2001 12:21:16 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QJLFV06223 for ; Tue, 26 Jun 2001 12:21:15 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA288693 for ; Tue, 26 Jun 2001 21:21:06 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2260011; Tue, 26 Jun 2001 14:19:41 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA02480; Tue, 26 Jun 2001 14:19:41 -0500 (CDT) Message-ID: <3B38DE20.C0BBE53A@sgi.com> Date: Tue, 26 Jun 2001 14:10:24 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: stimits@idcomm.com CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: fatal error -- couldn't initialize XFS library References: <3B38DE54.37037A97@idcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "D. Stimits" wrote: > I noticed one other thing during the process that is definitely a bug, > but not necessarily xfs...it could be a mount bug. While in single user > mode, after remounting the partition read-only, it was falsely listed as > read/write when the mount command was run to see current mounts. I know > it was incorrect becase I tried intentionally to write to a file as a > test, and it correctly told me the file could not be saved because the > partition was read-only. I've seen this before... I think it's a result of /etc/mtab not being updated before the / partition is made read-only. (ext2 root does this for me, too, at least on RH7.1) Try cat /proc/mounts and see what you get - it should say "ro". -Eric From owner-linux-xfs@oss.sgi.com Tue Jun 26 12:22:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QJMhL06331 for linux-xfs-outgoing; Tue, 26 Jun 2001 12:22:43 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QJMgV06328 for ; Tue, 26 Jun 2001 12:22:42 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA289932 for ; Tue, 26 Jun 2001 21:22:40 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2267299; Tue, 26 Jun 2001 14:21:22 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA51601; Tue, 26 Jun 2001 14:21:22 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5QJNX307690; Tue, 26 Jun 2001 14:23:33 -0500 Message-Id: <200106261923.f5QJNX307690@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Gonyou, Austin" cc: linux-xfs@oss.sgi.com Subject: Re: XFSDUMP and multiple filesystems on one tape In-Reply-To: Message from "Gonyou, Austin" of "Tue, 26 Jun 2001 14:13:39 CDT." <85063BBE668FD411944400D0B744267A481B0C@AUSMAIL> Content-Transfer-Encoding: 8bit Date: Tue, 26 Jun 2001 14:23:33 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I see. Well. I was going to use Amanda, but I don't want to run inetd or > xinetd. I do run IP tables, but the less software(especially the port or > socket kind) the better. So, backing up other computers across ssh or > something is pretty easy too, but I really just want this ONE system to > backup itself. So was curious if xfsdump can handle multiple filesystems to > one tape. See the xfsdump man page: Media Management A single media object can contain many dump streams. Con- versely, a single dump stream can span multiple media objects. If a dump stream is sent to a media object already containing one or more dumps, xfsdump appends the new dump stream after the last dump stream. Media files are never overwritten. If end-of-media is encountered during the course of a dump, the operator is prompted to insert a new media object into the drive. The dump stream continuation is appended after the last media file on the new media object. Of course I am not quite sure how this translates to linux tapes. Steve > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-796-9023 > email: austin@coremetrics.com > > > -----Original Message----- > > From: Dan Swartzendruber [mailto:dswartz@druber.com] > > Sent: Tuesday, June 26, 2001 2:11 PM > > To: Gonyou, Austin; linux-xfs@oss.sgi.com > > Subject: Re: XFSDUMP and multiple filesystems on one tape > > > > > > At 02:04 PM 6/26/2001 -0500, Gonyou, Austin wrote: > > >Is that possible? I didn't see any syntax which showed it > > was. Any ideas on > > >how to do this would be helpful, or else I guess it's back > > to tar for me. :) > > > > sorry if i'm coming into the middle of this. i'm putting multiple > > filesystems on > > individual tapes (xfs) with no problems, but i'm not doing it > > directly (i use > > amanda to backup my server - it works fine with xfs). > > > > > > > > From owner-linux-xfs@oss.sgi.com Tue Jun 26 12:41:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QJfoa07945 for linux-xfs-outgoing; Tue, 26 Jun 2001 12:41:50 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QJfmV07941 for ; Tue, 26 Jun 2001 12:41:48 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id VAA08015; Tue, 26 Jun 2001 21:41:47 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id VAA22936; Tue, 26 Jun 2001 21:41:47 +0200 (CEST) Date: Tue, 26 Jun 2001 21:41:47 +0200 (CEST) From: Seth Mos To: "D. Stimits" cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: fatal error -- couldn't initialize XFS library In-Reply-To: <3B38DE54.37037A97@idcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 26 Jun 2001, D. Stimits wrote: > Now I rebooted back to the original drive partition, which works fine > after telling kudzu to shut up and not reconfigure all the devices and > to not prompt me again. Btw, the disconnected inode was empty, size 0. > > But it appears that xfs_repair is broken on it, because running > xfs_repair -n claims it could not initialize the xfs library. The end of xfs_repair -n should always work. What version do you use of xfs_repair? If you really want to repair it unmount it. > an strace makes me believe xfs_repair with "-n" will still refuse to > look at a partition that is mounted: > open("/etc/mtab", O_RDONLY) = 3 > brk(0x80d2000) = 0x80d2000 > fstat64(3, {st_mode=S_IFREG|0644, st_size=150, ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > 0) = 0x40018000 > read(3, "/dev/sda6 / xfs rw 0 0\nnone /pro"..., 4096) = 150 > read(3, "", 4096) = 0 > write(2, "xfs_repair: /dev/sda6 contains a"..., 61xfs_repair: /dev/sda6 > contains a writable mounted filesystem > ) = 61 > close(3) = 0 > munmap(0x40018000, 4096) = 0 > write(2, "\nfatal error -- ", 16 > fatal error -- ) = 16 > write(2, "couldn\'t initialize XFS library\n", 32couldn't initialize XFS > library > ) = 32 > _exit(1) = ? > > > Shouldn't xfs_repair allow me to at least attempt to see what it would > do with "-n"? It would, I believe there are older versions of xfs_repair that barf when it is mounted. Cheers Seth From owner-linux-xfs@oss.sgi.com Tue Jun 26 12:45:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QJjhv08635 for linux-xfs-outgoing; Tue, 26 Jun 2001 12:45:43 -0700 Received: from dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QJjfV08630 for ; Tue, 26 Jun 2001 12:45:41 -0700 Received: (from ak@localhost) by dkp.com (8.9.3/8.9.3) id PAA24311 for linux-xfs@oss.sgi.com; Tue, 26 Jun 2001 15:45:41 -0400 Date: Tue, 26 Jun 2001 15:45:41 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Core dump during test 58 Message-ID: <20010626154541.G16841@key.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.2i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This struck me as a little odd - a core dump during one of the checks (058, to be specific): 145,243c145 < 25: < Get 26th entry on filled ACL < acl_get_entry -> 0 < Get 27th entry on filled ACL < acl_get_entry -> 0 < dump empty ACL < Get 1st entry on filled ACL < acl_get_entry -> 0 < Get 2th entry on filled ACL < acl_get_entry -> 0 < fill an ACL with known bogus values < Get 1st entry on filled ACL < acl_get_entry -> 1 < 1: < Get 2th entry on filled ACL < acl_get_entry -> 1 < 2: < Get 3th entry on filled ACL < acl_get_entry -> 1 < 3: < Get 4th entry on filled ACL < acl_get_entry -> 1 ...... < 23: < Get 24th entry on filled ACL < acl_get_entry -> 1 < 24: < Get 25th entry on filled ACL < acl_get_entry -> 1 < 25: < Get 26th entry on filled ACL < acl_get_entry -> 0 < Get 27th entry on filled ACL < acl_get_entry -> 0 < *** test out ACL to text for empty ACL*** < acl_to_text(empty_acl,NULL) -> "" < acl_to_text(empty_acl,NULL) -> "", len = 0 < acl_to_text(NULL,NULL) -> "NULL" < *** test out acl_get_qualifier *** < uid = 1 < uid = 1 < uidp is NULL: Invalid argument < uidp is NULL: Invalid argument --- > 25: <./058: line 56: 29522 Segmentation fault (core dumped) src/acl_test This is with 2.4.5-0.2.9_SGI_XFS_20010613. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Tue Jun 26 12:54:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QJsJp09992 for linux-xfs-outgoing; Tue, 26 Jun 2001 12:54:19 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QJsIV09981 for ; Tue, 26 Jun 2001 12:54:18 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id VAA11321; Tue, 26 Jun 2001 21:54:17 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id VAA23516; Tue, 26 Jun 2001 21:54:16 +0200 (CEST) Date: Tue, 26 Jun 2001 21:54:16 +0200 (CEST) From: Seth Mos To: "D. Stimits" cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: fatal error -- couldn't initialize XFS library In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 26 Jun 2001, Seth Mos wrote: > On Tue, 26 Jun 2001, D. Stimits wrote: > > > Now I rebooted back to the original drive partition, which works fine > > after telling kudzu to shut up and not reconfigure all the devices and > > to not prompt me again. Btw, the disconnected inode was empty, size 0. > > > > But it appears that xfs_repair is broken on it, because running > > xfs_repair -n claims it could not initialize the xfs library. The end of > > xfs_repair -n should always work. What version do you use of xfs_repair? > If you really want to repair it unmount it. It indeed does NOT work with -n. Thats weird because I remember using it at work. I have to figure out what version that was then. Strange. Cheers Seth From owner-linux-xfs@oss.sgi.com Tue Jun 26 13:10:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QKAfJ12461 for linux-xfs-outgoing; Tue, 26 Jun 2001 13:10:41 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QKAeV12457 for ; Tue, 26 Jun 2001 13:10:40 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA04908 for ; Tue, 26 Jun 2001 13:10:33 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2268905; Tue, 26 Jun 2001 15:09:17 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA29205; Tue, 26 Jun 2001 15:09:16 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5QKBSh08140; Tue, 26 Jun 2001 15:11:28 -0500 Message-Id: <200106262011.f5QKBSh08140@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andrew Klaassen cc: linux-xfs@oss.sgi.com Subject: Re: Core dump during test 58 In-Reply-To: Message from Andrew Klaassen of "Tue, 26 Jun 2001 15:45:41 EDT." <20010626154541.G16841@key.dkp.com> Date: Tue, 26 Jun 2001 15:11:28 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Do you have the very latest acl packages installed, and have you rebuilt the tests with them? There was an interface change in user space which may have bitten you. Test 58 works for me: [root@lord xfstests]# ./check 058 make: Nothing to be done for `default'. 058 0s ... Passed all 1 tests [root@lord xfstests]# rpm -qa | grep acl acl-devel-1.0.7-0 acl-1.0.7-0 [root@lord xfstests]# > This struck me as a little odd - a core dump during one of the > checks (058, to be specific): > > 145,243c145 > < 25: > < Get 26th entry on filled ACL > < acl_get_entry -> 0 > < Get 27th entry on filled ACL > < acl_get_entry -> 0 > < dump empty ACL > < Get 1st entry on filled ACL > < acl_get_entry -> 0 > < Get 2th entry on filled ACL > < acl_get_entry -> 0 > < fill an ACL with known bogus values > < Get 1st entry on filled ACL > < acl_get_entry -> 1 > < 1: > < Get 2th entry on filled ACL > < acl_get_entry -> 1 > < 2: > < Get 3th entry on filled ACL > < acl_get_entry -> 1 > < 3: > < Get 4th entry on filled ACL > < acl_get_entry -> 1 > > ...... > > < 23: > < Get 24th entry on filled ACL > < acl_get_entry -> 1 > < 24: > < Get 25th entry on filled ACL > < acl_get_entry -> 1 > < 25: > < Get 26th entry on filled ACL > < acl_get_entry -> 0 > < Get 27th entry on filled ACL > < acl_get_entry -> 0 > < *** test out ACL to text for empty ACL*** > < acl_to_text(empty_acl,NULL) -> "" > < acl_to_text(empty_acl,NULL) -> "", len = 0 > < acl_to_text(NULL,NULL) -> "NULL" > < *** test out acl_get_qualifier *** > < uid = 1 > < uid = 1 > < uidp is NULL: Invalid argument > < uidp is NULL: Invalid argument > --- > > 25: <./058: line 56: 29522 Segmentation fault (core dumped) src/acl_te > st > > This is with 2.4.5-0.2.9_SGI_XFS_20010613. > > Andrew Klaassen From owner-linux-xfs@oss.sgi.com Tue Jun 26 13:22:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QKM8C14303 for linux-xfs-outgoing; Tue, 26 Jun 2001 13:22:08 -0700 Received: from dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QKM7V14292 for ; Tue, 26 Jun 2001 13:22:07 -0700 Received: (from ak@localhost) by dkp.com (8.9.3/8.9.3) id QAA25114 for linux-xfs@oss.sgi.com; Tue, 26 Jun 2001 16:22:07 -0400 Date: Tue, 26 Jun 2001 16:22:07 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: Core dump during test 58 Message-ID: <20010626162207.H16841@key.dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200106262011.f5QKBSh08140@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200106262011.f5QKBSh08140@jen.americas.sgi.com>; from lord@sgi.com on Tue, Jun 26, 2001 at 03:11:28PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jun 26, 2001 at 03:11:28PM -0500, Steve Lord wrote: > Do you have the very latest acl packages installed, and have > you rebuilt the tests with them? There was an interface change > in user space which may have bitten you. Ah. That's better. Thanks. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Tue Jun 26 13:55:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QKtbL18700 for linux-xfs-outgoing; Tue, 26 Jun 2001 13:55:37 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QKtZV18696 for ; Tue, 26 Jun 2001 13:55:36 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA291315 for ; Tue, 26 Jun 2001 22:55:33 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2267275 for ; Tue, 26 Jun 2001 15:54:17 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA85097 for ; Tue, 26 Jun 2001 15:54:17 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f5QKuS609219; Tue, 26 Jun 2001 15:56:28 -0500 Message-Id: <200106262056.f5QKuS609219@jen.americas.sgi.com> Date: Tue, 26 Jun 2001 15:56:28 -0500 Subject: TAKE - improve xfs behavior in low memory situations Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk With this change I now have a kernel build with make -j triggering the oom handler and killing processes rather than killing the machine by panicing in the XFS memory allocation path. Date: Tue Jun 26 13:52:59 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:97686a linux/fs/xfs/xfs_trans_buf.c - 1.94 - Fix a problem with the buffer flags we pass into pagebuf. We were being too restrictive in the flag settings. The meaning of BUF_BUSY in linux and Irix is different in this case, we do not want to use BUF_BUSY in the non-transactional case. From owner-linux-xfs@oss.sgi.com Tue Jun 26 14:10:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QLAxH21145 for linux-xfs-outgoing; Tue, 26 Jun 2001 14:10:59 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QLAxV21142 for ; Tue, 26 Jun 2001 14:10:59 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA05189 for ; Tue, 26 Jun 2001 14:10:58 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2271014 for ; Tue, 26 Jun 2001 16:09:42 -0500 (CDT) Received: from laptop.americas.sgi.com (eagdhcp-187-12.americas.sgi.com [128.162.187.182]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA66044 for ; Tue, 26 Jun 2001 16:09:42 -0500 (CDT) From: Steve Lord Received: by laptop.americas.sgi.com (8.11.2/SGI-client-1.7) id f5QL2d210590; Tue, 26 Jun 2001 16:02:39 -0500 Message-Id: <200106262102.f5QL2d210590@laptop.americas.sgi.com> Date: Tue, 26 Jun 2001 16:02:39 -0500 Subject: TAKE - turn realtime back into an actual option Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Realtime is starting to function, enable the config option, use with caution. Date: Tue Jun 26 14:08:42 PDT 2001 Workarea: eagdhcp-187-12.americas.sgi.com:/src/lord/xfs-linux-2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:97688a linux/fs/Config.in - 1.62 - Add the realtime subvolume back as a config option linux/Documentation/Configure.help - 1.84 - Add help text for xfs realtime subvolume linux/fs/xfs/xfs_rtalloc.c - 1.67 - fix compile warnings in realtime code From owner-linux-xfs@oss.sgi.com Tue Jun 26 15:09:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QM9di30723 for linux-xfs-outgoing; Tue, 26 Jun 2001 15:09:39 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QM9bV30708 for ; Tue, 26 Jun 2001 15:09:37 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA07905 for ; Tue, 26 Jun 2001 15:06:47 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2271007 for ; Tue, 26 Jun 2001 17:08:21 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA39940 for ; Tue, 26 Jun 2001 17:08:21 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f5QMAVD13451; Tue, 26 Jun 2001 17:10:31 -0500 Message-Id: <200106262210.f5QMAVD13451@jen.americas.sgi.com> Date: Tue, 26 Jun 2001 17:10:31 -0500 Subject: TAKE - fix regression suite failure Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Create on top of an existing zero length file was updating the ctime, but not the mtime. This should fix it. Date: Tue Jun 26 15:07:29 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:97694a linux/fs/xfs/xfs_vnodeops.c - 1.506 - Set the mtime on a zero length file when a create is being done on top of it. From owner-linux-xfs@oss.sgi.com Tue Jun 26 15:12:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QMCsx31356 for linux-xfs-outgoing; Tue, 26 Jun 2001 15:12:54 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QMCrV31352 for ; Tue, 26 Jun 2001 15:12:53 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip4.idcomm.com [209.60.72.131]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5QME7l16401 for ; Tue, 26 Jun 2001 16:14:07 -0600 Message-ID: <3B39094D.A5D867F7@idcomm.com> Date: Tue, 26 Jun 2001 16:14:37 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: fatal error -- couldn't initialize XFS library References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > > On Tue, 26 Jun 2001, D. Stimits wrote: > > > Now I rebooted back to the original drive partition, which works fine > > after telling kudzu to shut up and not reconfigure all the devices and > > to not prompt me again. Btw, the disconnected inode was empty, size 0. > > > > But it appears that xfs_repair is broken on it, because running > > xfs_repair -n claims it could not initialize the xfs library. The end of > > xfs_repair -n should always work. What version do you use of xfs_repair? > If you really want to repair it unmount it. I'll do some more testing tonight. But it does sound like an earlier reply about not updating mtab before remount could be the problem for the read-only flag not being correct. For xfs_repair itself, it is from 2.4.6-pre1-xfs cvs. I'll try recompiling it later. As for unmounting, how do you do this with the root partition (no rescue floppies have worked so far, and I am struggling to create an ISO image for CD and then burn it from a windows machine...the linux machine doesn't have a burner, and windows insists on turning anything I do into a UDF filesystem regular file). > > > an strace makes me believe xfs_repair with "-n" will still refuse to > > look at a partition that is mounted: > > open("/etc/mtab", O_RDONLY) = 3 > > brk(0x80d2000) = 0x80d2000 > > fstat64(3, {st_mode=S_IFREG|0644, st_size=150, ...}) = 0 > > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > > 0) = 0x40018000 > > read(3, "/dev/sda6 / xfs rw 0 0\nnone /pro"..., 4096) = 150 > > read(3, "", 4096) = 0 > > write(2, "xfs_repair: /dev/sda6 contains a"..., 61xfs_repair: /dev/sda6 > > contains a writable mounted filesystem > > ) = 61 > > close(3) = 0 > > munmap(0x40018000, 4096) = 0 > > write(2, "\nfatal error -- ", 16 > > fatal error -- ) = 16 > > write(2, "couldn\'t initialize XFS library\n", 32couldn't initialize XFS > > library > > ) = 32 > > _exit(1) = ? > > > > > > Shouldn't xfs_repair allow me to at least attempt to see what it would > > do with "-n"? > > It would, I believe there are older versions of xfs_repair that barf when > it is mounted. > > Cheers > Seth Are there significant changes to xfs_repair later than those of 2.4.6-pre1-xfs? D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Tue Jun 26 15:13:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QMDlP31515 for linux-xfs-outgoing; Tue, 26 Jun 2001 15:13:47 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QMDlV31511 for ; Tue, 26 Jun 2001 15:13:47 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip4.idcomm.com [209.60.72.131]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5QMF0l16598 for ; Tue, 26 Jun 2001 16:15:00 -0600 Message-ID: <3B390983.409416C2@idcomm.com> Date: Tue, 26 Jun 2001 16:15:31 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: fatal error -- couldn't initialize XFS library References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > > On Tue, 26 Jun 2001, Seth Mos wrote: > > > On Tue, 26 Jun 2001, D. Stimits wrote: > > > > > Now I rebooted back to the original drive partition, which works fine > > > after telling kudzu to shut up and not reconfigure all the devices and > > > to not prompt me again. Btw, the disconnected inode was empty, size 0. > > > > > > But it appears that xfs_repair is broken on it, because running > > > xfs_repair -n claims it could not initialize the xfs library. The end of > > > > xfs_repair -n should always work. What version do you use of xfs_repair? > > If you really want to repair it unmount it. > > It indeed does NOT work with -n. Thats weird because I remember using > it at work. I have to figure out what version that was then. > > Strange. > > Cheers > Seth FYI, mine claims xfs_repair 1.2.7. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Tue Jun 26 15:18:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QMI8t32303 for linux-xfs-outgoing; Tue, 26 Jun 2001 15:18:08 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QMI7V32300 for ; Tue, 26 Jun 2001 15:18:07 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA297481 for ; Wed, 27 Jun 2001 00:18:05 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2267669; Tue, 26 Jun 2001 17:16:47 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA14177; Tue, 26 Jun 2001 17:16:47 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5QMIvJ13487; Tue, 26 Jun 2001 17:18:57 -0500 Message-Id: <200106262218.f5QMIvJ13487@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: stimits@idcomm.com cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: fatal error -- couldn't initialize XFS library In-Reply-To: Message from "D. Stimits" of "Tue, 26 Jun 2001 16:14:37 MDT." <3B39094D.A5D867F7@idcomm.com> Date: Tue, 26 Jun 2001 17:18:57 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Are there significant changes to xfs_repair later than those of > 2.4.6-pre1-xfs? > > D. Stimits, stimits@idcomm.com No, repair itself has not changed, the messages you got about all the devices on your system having gone away make me nervous. I have not had a chance to read this thread yet. Steve From owner-linux-xfs@oss.sgi.com Tue Jun 26 15:18:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QMICK32330 for linux-xfs-outgoing; Tue, 26 Jun 2001 15:18:12 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QMIBV32327 for ; Tue, 26 Jun 2001 15:18:11 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA01927; Wed, 27 Jun 2001 00:18:09 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA09727; Wed, 27 Jun 2001 00:18:09 +0200 (CEST) Date: Wed, 27 Jun 2001 00:18:09 +0200 (CEST) From: Seth Mos To: "D. Stimits" cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: fatal error -- couldn't initialize XFS library In-Reply-To: <3B39094D.A5D867F7@idcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 26 Jun 2001, D. Stimits wrote: > Seth Mos wrote: > I'll do some more testing tonight. But it does sound like an earlier > reply about not updating mtab before remount could be the problem for > the read-only flag not being correct. For xfs_repair itself, it is from > 2.4.6-pre1-xfs cvs. I'll try recompiling it later. As for unmounting, > how do you do this with the root partition (no rescue floppies have > worked so far, and I am struggling to create an ISO image for CD and > then burn it from a windows machine...the linux machine doesn't have a > burner, and windows insists on turning anything I do into a UDF > filesystem regular file). The Linux XFS installer disk doubles as a rescue disk Just type rescue at the prompt. What software are you using to burn CD's? I have made installer disks using cdrecord on linux nero and Easy CD creator under windows. All of them have a burn cd from image option. > Are there significant changes to xfs_repair later than those of > 2.4.6-pre1-xfs? Not that I know of but I can't get it to work anymore too. Don't if something broke or if it was a change in behaviuour. From owner-linux-xfs@oss.sgi.com Tue Jun 26 15:19:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QMJMQ32508 for linux-xfs-outgoing; Tue, 26 Jun 2001 15:19:22 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QMJLV32505 for ; Tue, 26 Jun 2001 15:19:21 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA02196; Wed, 27 Jun 2001 00:19:20 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA09819; Wed, 27 Jun 2001 00:19:20 +0200 (CEST) Date: Wed, 27 Jun 2001 00:19:20 +0200 (CEST) From: Seth Mos To: "D. Stimits" cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: fatal error -- couldn't initialize XFS library In-Reply-To: <3B390983.409416C2@idcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 26 Jun 2001, D. Stimits wrote: > Seth Mos wrote: > > > > On Tue, 26 Jun 2001, Seth Mos wrote: > > > > > On Tue, 26 Jun 2001, D. Stimits wrote: > > > > > > > Now I rebooted back to the original drive partition, which works fine > > > > after telling kudzu to shut up and not reconfigure all the devices and > > > > to not prompt me again. Btw, the disconnected inode was empty, size 0. > > > > > > > > But it appears that xfs_repair is broken on it, because running > > > > xfs_repair -n claims it could not initialize the xfs library. The end of > > > > > > xfs_repair -n should always work. What version do you use of xfs_repair? > > > If you really want to repair it unmount it. > > > > It indeed does NOT work with -n. Thats weird because I remember using > > it at work. I have to figure out what version that was then. > > > > Strange. > > > > Cheers > > Seth > > FYI, mine claims xfs_repair 1.2.7. That is the most recent version yes. From owner-linux-xfs@oss.sgi.com Tue Jun 26 15:43:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QMhRa00379 for linux-xfs-outgoing; Tue, 26 Jun 2001 15:43:27 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QMhQV00376 for ; Tue, 26 Jun 2001 15:43:26 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip4.idcomm.com [209.60.72.131]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5QMibl22650 for ; Tue, 26 Jun 2001 16:44:38 -0600 Message-ID: <3B391074.FD44176@idcomm.com> Date: Tue, 26 Jun 2001 16:45:08 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: fatal error -- couldn't initialize XFS library References: <200106262218.f5QMIvJ13487@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > > > > > Are there significant changes to xfs_repair later than those of > > 2.4.6-pre1-xfs? > > > > D. Stimits, stimits@idcomm.com > > No, repair itself has not changed, the messages you got about all the devices > on your system having gone away make me nervous. I have not had a chance to > read this thread yet. > > Steve I will look at some things later tonight, but it may be of interest that Redhat's kudzu does not distinguish between devices "missing" and having changed. As an example, depending on whether I run with APIC or not, the irq of the modem changes. Each time it changes, it says it has detected new or missing hardware, and asks to configure it. In this case, it wanted to reconfigure all pci slot cards, video, sound, modem, and even the integrated scsi controller and psaux mouse. It is a fact that I had previously removed and placed a drive back in its bay (it is a hot swap bay, it never gets removed/added with power on though), to test another setup that is completely independent (pull out one drive, put in the other, test, swap back). I have never seen it do this with all things, and in theory the configuration was 100% unchanged, since the drive was pulled and added back without power. But mechanical device connections are always suspect to me, I tend doubt them if an error occurs after pulling and adding a drive back ends up with such an error. On the other hand, I am absolutely positive that it was correctly/fully seated, it uses a positive-lock mechanism on a high-end hot swap backplane, and scsi was in fact detected correctly...the strangeness is that it said all configurations changed. On another note, it was shut down correctly with the normal shutdown sequence before this. One really big concern I have is that had I not created an IDE hard drive install (I also have a removable IDE tray...I can boot to that by setting the bios to boot IDE first instead of integrated SCSI), I would not have been able to run xfs_repair (so far all boot floppy systems have failed for me, I'm still working on it). Although I cannot guarantee that anything was actually wrong with the filesystem (and I doubt there was a filesystem error), it did find one node that ended up in lost+found, but it was size 0...I have no idea if normal journaling would have had any problems coping with it. Is there no way to run xfs_repair with "no actual modify by -n" on a mounted xfs partition, or read-only mounted xfs partition? D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Tue Jun 26 15:52:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QMqL300608 for linux-xfs-outgoing; Tue, 26 Jun 2001 15:52:21 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QMqKV00605 for ; Tue, 26 Jun 2001 15:52:20 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip4.idcomm.com [209.60.72.131]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5QMrXl24305 for ; Tue, 26 Jun 2001 16:53:34 -0600 Message-ID: <3B39128C.9F31980D@idcomm.com> Date: Tue, 26 Jun 2001 16:54:04 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: fatal error -- couldn't initialize XFS library References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > > On Tue, 26 Jun 2001, D. Stimits wrote: > > > Seth Mos wrote: > > I'll do some more testing tonight. But it does sound like an earlier > > reply about not updating mtab before remount could be the problem for > > the read-only flag not being correct. For xfs_repair itself, it is from > > 2.4.6-pre1-xfs cvs. I'll try recompiling it later. As for unmounting, > > how do you do this with the root partition (no rescue floppies have > > worked so far, and I am struggling to create an ISO image for CD and > > then burn it from a windows machine...the linux machine doesn't have a > > burner, and windows insists on turning anything I do into a UDF > > filesystem regular file). > > The Linux XFS installer disk doubles as a rescue disk > Just type rescue at the prompt. > What software are you using to burn CD's? I have made installer disks > using cdrecord on linux nero and Easy CD creator under windows. All of > them have a burn cd from image option. I don't have the installer disk...I am assuming you mean CD? I created this by install to a hot swap disk on ext2, upgrade of kernel, creation of xfs on a 2nd hot swap disk, copy to that disk, add lilo to that disk (and appropriate fstab mods), then shutting down and swapping so that the mirror is now boot disk, and other disk is mountable as a partition. Then I wiped the original disk, formatted xfs, and remigrated back to it. Except for this, which might or might not actually be xfs related, it has been perfect. My problem on cdrom burning is that this machine does not have a burner. I have to create any image here, then try to load it to someone else's machine (win 2k, which *really* sucks with its diluted cd burn abilities) to burn. The transfer requires me to upload it from my machine on 56k, then download from the other machine on a 33.6k. So testing is *really* slow. > > > Are there significant changes to xfs_repair later than those of > > 2.4.6-pre1-xfs? > > Not that I know of but I can't get it to work anymore too. > Don't if something broke or if it was a change in behaviuour. Maybe more people with 2.4.6-pre1-xfs or newer can comment on whether xfs_repair with the -n option fails. It seems like what is broken is that it says you can't run it on a mounted partition, even if it is -n and won't write. If not, it seems that the call that responds with "fatal error -- couldn't initialize XFS library" is saying that some sort of internal function failed...don't know, I'm not familiar with it. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Tue Jun 26 15:58:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QMw6k00818 for linux-xfs-outgoing; Tue, 26 Jun 2001 15:58:06 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QMw5V00815 for ; Tue, 26 Jun 2001 15:58:05 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA03717 for ; Tue, 26 Jun 2001 15:58:05 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2264604; Tue, 26 Jun 2001 17:56:48 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA54023; Tue, 26 Jun 2001 17:56:48 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5QMwwS13616; Tue, 26 Jun 2001 17:58:58 -0500 Message-Id: <200106262258.f5QMwwS13616@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: stimits@idcomm.com cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: fatal error -- couldn't initialize XFS library In-Reply-To: Message from "D. Stimits" of "Tue, 26 Jun 2001 16:45:08 MDT." <3B391074.FD44176@idcomm.com> Date: Tue, 26 Jun 2001 17:58:58 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I will look at some things later tonight, but it may be of interest that > Redhat's kudzu does not distinguish between devices "missing" and having > changed. As an example, depending on whether I run with APIC or not, the > irq of the modem changes. Each time it changes, it says it has detected > new or missing hardware, and asks to configure it. In this case, it > wanted to reconfigure all pci slot cards, video, sound, modem, and even > the integrated scsi controller and psaux mouse. It is a fact that I had > previously removed and placed a drive back in its bay (it is a hot swap > bay, it never gets removed/added with power on though), to test another > setup that is completely independent (pull out one drive, put in the > other, test, swap back). I have never seen it do this with all things, > and in theory the configuration was 100% unchanged, since the drive was > pulled and added back without power. But mechanical device connections > are always suspect to me, I tend doubt them if an error occurs after > pulling and adding a drive back ends up with such an error. On the other > hand, I am absolutely positive that it was correctly/fully seated, it > uses a positive-lock mechanism on a high-end hot swap backplane, and > scsi was in fact detected correctly...the strangeness is that it said > all configurations changed. On another note, it was shut down correctly > with the normal shutdown sequence before this. One really big concern I > have is that had I not created an IDE hard drive install (I also have a > removable IDE tray...I can boot to that by setting the bios to boot IDE > first instead of integrated SCSI), I would not have been able to run > xfs_repair (so far all boot floppy systems have failed for me, I'm still > working on it). Although I cannot guarantee that anything was actually > wrong with the filesystem (and I doubt there was a filesystem error), it > did find one node that ended up in lost+found, but it was size 0...I > have no idea if normal journaling would have had any problems coping > with it. Is there no way to run xfs_repair with "no actual modify by -n" > on a mounted xfs partition, or read-only mounted xfs partition? > > D. Stimits, stimits@idcomm.com To answer the question at the end of your message, no you generally cannot run xfs_repair on a mounted filesystem, even with the -n option. This is deliberate. Steve From owner-linux-xfs@oss.sgi.com Tue Jun 26 16:02:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QN2B401062 for linux-xfs-outgoing; Tue, 26 Jun 2001 16:02:11 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QN2AV01059 for ; Tue, 26 Jun 2001 16:02:10 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA29521 for ; Tue, 26 Jun 2001 16:02:04 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id JAA39764; Wed, 27 Jun 2001 09:00:52 +1000 (EST) Message-Id: <200106262300.JAA39764@snort.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: stimits@idcomm.com cc: linux-xfs@oss.sgi.com Subject: Re: fatal error -- couldn't initialize XFS library In-reply-to: Your message of "Tue, 26 Jun 2001 16:54:04 CST." <3B39128C.9F31980D@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Jun 2001 09:00:52 +1000 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk => Maybe more people with 2.4.6-pre1-xfs or newer can comment on whether => xfs_repair with the -n option fails. It seems like what is broken is => that it says you can't run it on a mounted partition, even if it is -n => and won't write. If not, it seems that the call that responds with => "fatal error -- couldn't initialize XFS library" is saying that some => sort of internal function failed...don't know, I'm not familiar with it. I came in half way through on this thread... Why would you want to run xfs_repair (with -n or otherwise) on a mounted partition? The FS is almost certain to be inconsistent given that xfs_repair doesn't look at the log. I suspect you're encountering a feature here. ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Jun 26 16:38:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QNc7T01691 for linux-xfs-outgoing; Tue, 26 Jun 2001 16:38:07 -0700 Received: from ima.pl (mail.ima.pl [195.117.13.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QNc3V01688 for ; Tue, 26 Jun 2001 16:38:04 -0700 Received: [from ip122 (ip122.ima.pl [195.117.13.122]) by ima.pl with SMTP id f5QNbv928949 for ; Tue, 26 Jun 2001 23:37:57 GMT] Message-ID: <003701c0ff60$3386f600$7a0d75c3@ima.pl> From: "Blizbor (i)" To: References: <200106252023.f5PKNrE17812@jen.americas.sgi.com> Subject: Odp: Installing RH 7.1 XFS from a network using a floppy Date: Tue, 26 Jun 2001 22:20:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2417.2000 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ----- Original Message ----- From: Steve Lord To: Gonyou, Austin Cc: Sent: Monday, June 25, 2001 10:23 PM Subject: Re: Installing RH 7.1 XFS from a network using a floppy > > Is that possible? Does it work ok with the 1.0 release or will I have to do > > something else? > > It works just fine, there are some instructions in the release notes for > redhat. I think you have to copy all the cds into a single directory > structure and nfs export it. You then need the network inst image bootnet.img > on a floppy. This is how I do all my installs. It's also possible without copying files. But then you must watch when another CD is required, then stop ftp daemon, umount CD, mount next, start ftpdaemon, and again ... stop, umount, mount, start, and again ... painful but it works. :))) I've tested this. Starting and stopping ftp daemon doesnt interrupt install procedure. IMVHO there is a bug in installer, normally when ftp server cant be contacted some kind of dialog box should appear.RH installer does nothing but seems hunging until you switch (in text mode usingalt-F1...alt-F4) to another console. Regards, Blizbor From owner-linux-xfs@oss.sgi.com Tue Jun 26 16:47:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QNl1Q01812 for linux-xfs-outgoing; Tue, 26 Jun 2001 16:47:01 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QNl0V01809 for ; Tue, 26 Jun 2001 16:47:00 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15F2Xn-0002IF-00; Wed, 27 Jun 2001 11:46:55 +1200 Date: Wed, 27 Jun 2001 11:46:55 +1200 (NZST) From: Juha Saarinen To: "D. Stimits" cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: fatal error -- couldn't initialize XFS library In-Reply-To: <3B39128C.9F31980D@idcomm.com> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 26 Jun 2001, D. Stimits wrote: > My problem on cdrom burning is that this machine does not have a burner. > I have to create any image here, then try to load it to someone else's > machine (win 2k, which *really* sucks with its diluted cd burn > abilities) to burn. No, Win2K is fine for CD burning. I've done it enough times here. If you want to do it with freeware tools, check out http://www.nu2.nu/bootcd > The transfer requires me to upload it from my > machine on 56k, then download from the other machine on a 33.6k. So > testing is *really* slow. Understatement of the year. ;-) -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Tue Jun 26 17:55:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R0tmN02489 for linux-xfs-outgoing; Tue, 26 Jun 2001 17:55:48 -0700 Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R0tlV02486 for ; Tue, 26 Jun 2001 17:55:47 -0700 Received: from insanegeeks.com (nic-131-c240-139.mw.mediaone.net [24.131.240.139]) by demai05.mw.mediaone.net (8.11.1/8.11.1) with ESMTP id f5R0tiK07301; Tue, 26 Jun 2001 20:55:45 -0400 (EDT) Message-ID: <3B392EE6.51190E7D@insanegeeks.com> Date: Tue, 26 Jun 2001 20:55:02 -0400 From: Thomas Suiter X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: stimits@idcomm.com CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: fatal error -- couldn't initialize XFS library References: <200106262218.f5QMIvJ13487@jen.americas.sgi.com> <3B391074.FD44176@idcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Maybe I shouldn't say this since nobody is mentioning (maybe some voodo that shouldn't be done), but I was able to use "xfs_repair -fn " I might have even had the same problem as you, check for the "bad hash table... would rebuild" subject line from 6/19/01. My system froze a couple of times, filesystems shutdown, and did other weird things (files disapearing but ls would know about them), etc. I believe it's something hardware related with me, I haven't had the time to run it down yet (I ran the memtest86 with no problems, so I'm guessing maybe a hd issue). "D. Stimits" wrote: > > have no idea if normal journaling would have had any problems coping > with it. Is there no way to run xfs_repair with "no actual modify by -n" > on a mounted xfs partition, or read-only mounted xfs partition? > > D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Tue Jun 26 18:19:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R1Jl002727 for linux-xfs-outgoing; Tue, 26 Jun 2001 18:19:47 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R1JkV02724 for ; Tue, 26 Jun 2001 18:19:46 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id SAA06997 for ; Tue, 26 Jun 2001 18:16:55 -0700 (PDT) mail_from (ivanr@melbourne.sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA11060; Wed, 27 Jun 2001 11:18:23 +1000 From: ivanr@melbourne.sgi.com (Ivan Rayner) Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA38634; Wed, 27 Jun 2001 11:18:22 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Wed, 27 Jun 2001 11:18:22 +1000 To: ThH cc: Subject: Re: xfsdump In-Reply-To: <993539634.7412.0.camel@pcli0001.doppstadt-sbk.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 26 Jun 2001, ThH wrote: > I'm testing XFS on an alpha with RedHat Linux 7.0. I normaly backup this > alpha with dump for ext2 fs. So I want to use xfsdump. It may work on > x86 but on the alpha there are many problems with sizes like > sizeof(time_t) != 4, so xfsdump stops its operation. The bug was on > 1.0.5 an than on 1.0.9. What have I to do to use xfsdump. > I want to use XFS for my file server, but without a chance to backup I > won't. Unfortunately we don't have the time nor access to hardware to do porting or testing work for alpha. One of wonders of open source, of course, is that it allows interested parties to do the work themselves. We'd be happy to review and incorporate patches that have been submitted by the open source community. Note that you can use good ol' tar and cpio, etc to do your backups. You wont be able to backup information stored in extended attributes (eg. ACLs) but if this isn't a problem for you, then not having xfsdump should be more an inconvenience than a showstopper. Ivan -- Ivan Rayner ivanr@melbourne.sgi.com From owner-linux-xfs@oss.sgi.com Tue Jun 26 19:41:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R2fLh03470 for linux-xfs-outgoing; Tue, 26 Jun 2001 19:41:21 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R2fKV03467 for ; Tue, 26 Jun 2001 19:41:20 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip15.idcomm.com [209.60.72.142]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5R2gZl25717 for ; Tue, 26 Jun 2001 20:42:35 -0600 Message-ID: <3B394839.7A7E0F65@idcomm.com> Date: Tue, 26 Jun 2001 20:43:05 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: fatal error -- couldn't initialize XFS library References: <200106262300.JAA39764@snort.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Daniel Moore wrote: > > => Maybe more people with 2.4.6-pre1-xfs or newer can comment on whether > => xfs_repair with the -n option fails. It seems like what is broken is > => that it says you can't run it on a mounted partition, even if it is -n > => and won't write. If not, it seems that the call that responds with > => "fatal error -- couldn't initialize XFS library" is saying that some > => sort of internal function failed...don't know, I'm not familiar with it. > > I came in half way through on this thread... > > Why would you want to run xfs_repair (with -n or otherwise) on a mounted > partition? The FS is almost certain to be inconsistent given that xfs_repair > doesn't look at the log. I had hoped it would at least comment on its thought about what is or isn't consistent. I can't unmount the root partition, and so far am unable to create any kind of boot medium other than a removable IDE hard drive (the ultimate floppy). The slackware style boot floppies are not working for me either, partly it seems because I have no ability to format a floppy to the size 1600. I have 1660 and 1680, but no device file for 1600 even, and this is apparently required to be exact. I absolutely require a boot image that supports both XFS and SCSI aic7xxx, so I have to use larger than 1.44 MB. I have used yard to create all kinds of variations, but under no circumstances is it possible for me to create an image less than 2.3 MB, and no floppy will go that far (from a 1.44 MB drive). Therefore I am experimenting with cd rom images, which must be 2.88 MB or smaller. My problem here is I must create it on linux, and transfer it to a braindead win 2k machine that does not have the aspi layer mandatory for writing images directly, and apparently there is no support for this on win 2k without a miracle. So I wanted a means to at least do *some* kind of test to see if things have gone horribly wrong while it is still mounted, read-only. After rebooting and having it forget all settings for all pci devices, I felt there was a need. D. Stimits, stimits@idcomm.com > > I suspect you're encountering a feature here. > > ----------------------------------------------------- > Daniel Moore dxm@sgi.com > R&D Software Engineer Phone: +61-3-98348209 > SGI Performance Tools Group Fax: +61-3-98132378 > ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Jun 26 19:51:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R2pJE03615 for linux-xfs-outgoing; Tue, 26 Jun 2001 19:51:19 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R2pIV03612 for ; Tue, 26 Jun 2001 19:51:18 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA00551 for ; Tue, 26 Jun 2001 19:48:28 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id MAA76807; Wed, 27 Jun 2001 12:50:00 +1000 (EST) Message-Id: <200106270250.MAA76807@snort.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: stimits@idcomm.com cc: linux-xfs@oss.sgi.com Subject: Re: fatal error -- couldn't initialize XFS library In-reply-to: Your message of "Tue, 26 Jun 2001 20:43:05 CST." <3B394839.7A7E0F65@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Jun 2001 12:49:59 +1000 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "D. Stimits" writes: => I had hoped it would at least comment on its thought about what is or => isn't consistent. I can't unmount the root partition, and so far am => unable to create any kind of boot medium other than a removable IDE hard => drive (the ultimate floppy). If it could tell you anything useful it wouldn't be able to tell you if it was accurate or not. => So I wanted a means to at least do *some* kind of test to see if things => have gone horribly wrong while it is still mounted, read-only. After => rebooting and having it forget all settings for all pci devices, I felt => there was a need. The aim of the journalling in XFS is to stop the filesystem becoming inconsistent. Therefore it's not something you should need to do often (or I would hope ever!). ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Jun 26 20:05:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R35UL03782 for linux-xfs-outgoing; Tue, 26 Jun 2001 20:05:30 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R35GV03779 for ; Tue, 26 Jun 2001 20:05:17 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5R34vw16606; Tue, 26 Jun 2001 23:04:57 -0400 Date: Tue, 26 Jun 2001 23:04:56 -0400 From: Alan Eldridge To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: SG patches Message-ID: <20010626230456.A16389@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline There's a scsi generic (sg) patch that needs to go against 2.4.5 to zap that unkillable process condition I was running into. I know you try to track just the Linus kernels, but you might want to consider putting this into CVS as well, since the bug's consequences are (operationally) pretty severe. These are the patches against sg.h and sg.c in the 2.4.5-ac18 patch. (The header patch is cosmetic, but it keeps the two files in sync.) There are other scsi patches, lots in fact, that could probably safely go in as well. However, this is the only really critical one that I am aware of, since the error condition it fixes forces you to do a shutdown, and can result in a hung machine requiring a power cycle (if you aren't near another box to ssh in and shut it down). -- Alan Eldridge "Smart Tags? We don't need no steenking Smart Tags!" --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-2.4.5-ac18-1006.patch" diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla/drivers/scsi/sg.c linux.ac/drivers/scsi/sg.c --- linux.vanilla/drivers/scsi/sg.c Mon Jan 15 21:08:15 2001 +++ linux.ac/drivers/scsi/sg.c Mon Jun 25 09:50:33 2001 @@ -7,7 +7,7 @@ * Original driver (sg.c): * Copyright (C) 1992 Lawrence Foard * Version 2 and 3 extensions to driver: - * Copyright (C) 1998 - 2000 Douglas Gilbert + * Copyright (C) 1998 - 2001 Douglas Gilbert * * Modified 19-JAN-1998 Richard Gooch Devfs support * @@ -19,9 +19,9 @@ */ #include #ifdef CONFIG_PROC_FS - static char * sg_version_str = "Version: 3.1.17 (20001002)"; + static char sg_version_str[] = "Version: 3.1.19 (20010623)"; #endif - static int sg_version_num = 30117; /* 2 digits for each component */ + static int sg_version_num = 30119; /* 2 digits for each component */ /* * D. P. Gilbert (dgilbert@interlog.com, dougg@triode.net.au), notes: * - scsi logging is available via SCSI_LOG_TIMEOUT macros. First @@ -76,8 +76,9 @@ #include #endif /* LINUX_VERSION_CODE */ -/* #define SG_ALLOW_DIO */ -#ifdef SG_ALLOW_DIO +#define SG_ALLOW_DIO_DEF 0 +#define SG_ALLOW_DIO_CODE /* compile out be commenting this define */ +#ifdef SG_ALLOW_DIO_CODE #include #endif @@ -89,6 +90,7 @@ readable via /proc/sys/kernel/sg-big-buff if the sg driver is built into the kernel (i.e. it is not a module).] */ static int def_reserved_size = -1; /* picks up init parameter */ +static int sg_allow_dio = SG_ALLOW_DIO_DEF; #define SG_SECTOR_SZ 512 #define SG_SECTOR_MSK (SG_SECTOR_SZ - 1) @@ -112,7 +114,7 @@ static int sg_detect(Scsi_Device *); static void sg_detach(Scsi_Device *); -static Scsi_Request * dummy_cmdp = 0; /* only used for sizeof */ +static Scsi_Request * dummy_cmdp; /* only used for sizeof */ static rwlock_t sg_dev_arr_lock = RW_LOCK_UNLOCKED; /* Also used to lock file descriptor list for device */ @@ -157,7 +159,7 @@ char res_used; /* 1 -> using reserve buffer, 0 -> not ... */ char orphan; /* 1 -> drop on sight, 0 -> normal */ char sg_io_owned; /* 1 -> packet belongs to SG_IO */ - char done; /* 0->before bh, 1->before read, 2->read */ + volatile char done; /* 0->before bh, 1->before read, 2->read */ } Sg_request; /* 168 bytes long on i386 */ typedef struct sg_fd /* holds the state of a file descriptor */ @@ -174,12 +176,12 @@ Sg_request req_arr[SG_MAX_QUEUE]; /* used as singly-linked list */ char low_dma; /* as in parent but possibly overridden to 1 */ char force_packid; /* 1 -> pack_id input to read(), 0 -> ignored */ - char closed; /* 1 -> fd closed but request(s) outstanding */ + volatile char closed; /* 1 -> fd closed but request(s) outstanding */ char fd_mem_src; /* heap whereabouts of this Sg_fd object */ char cmd_q; /* 1 -> allow command queuing, 0 -> don't */ char next_cmd_len; /* 0 -> automatic (def), >0 -> use on next write() */ char keep_orphan; /* 0 -> drop orphan (def), 1 -> keep for read() */ -} Sg_fd; /* 2768 bytes long on i386 */ +} Sg_fd; /* 2760 bytes long on i386 */ typedef struct sg_device /* holds the state of each scsi generic device */ { @@ -189,10 +191,10 @@ Sg_fd * headfp; /* first open fd belonging to this device */ devfs_handle_t de; kdev_t i_rdev; /* holds device major+minor number */ - char exclude; /* opened for exclusive access */ + volatile char detached; /* 0->attached, 1->detached pending removal */ + volatile char exclude; /* opened for exclusive access */ char sgdebug; /* 0->off, 1->sense, 9->dump dev, 10-> all devs */ - char detached; /* 0->attached, 1->detached pending removal */ -} Sg_device; /* 44 bytes long on i386 */ +} Sg_device; /* 36 bytes long on i386 */ static int sg_fasync(int fd, struct file * filp, int mode); @@ -225,13 +227,12 @@ static void sg_low_free(char * buff, int size, int mem_src); static Sg_fd * sg_add_sfp(Sg_device * sdp, int dev); static int sg_remove_sfp(Sg_device * sdp, Sg_fd * sfp); +static void __sg_remove_sfp(Sg_device * sdp, Sg_fd * sfp); static Sg_request * sg_get_rq_mark(Sg_fd * sfp, int pack_id); static Sg_request * sg_add_request(Sg_fd * sfp); static int sg_remove_request(Sg_fd * sfp, Sg_request * srp); static int sg_res_in_use(Sg_fd * sfp); -static int sg_dio_in_use(Sg_fd * sfp); static void sg_clr_srpnt(Scsi_Request * SRpnt); -static void sg_shorten_timeout(Scsi_Request * srpnt); static int sg_ms_to_jif(unsigned int msecs); static unsigned sg_jif_to_ms(int jifs); static int sg_allow_access(unsigned char opcode, char dev_type); @@ -244,10 +245,10 @@ static Sg_device ** sg_dev_arr = NULL; -static const int size_sg_header = sizeof(struct sg_header); -static const int size_sg_io_hdr = sizeof(sg_io_hdr_t); -static const int size_sg_iovec = sizeof(sg_iovec_t); -static const int size_sg_req_info = sizeof(sg_req_info_t); +#define SZ_SG_HEADER sizeof(struct sg_header) +#define SZ_SG_IO_HDR sizeof(sg_io_hdr_t) +#define SZ_SG_IOVEC sizeof(sg_iovec_t) +#define SZ_SG_REQ_INFO sizeof(sg_req_info_t) static int sg_open(struct inode * inode, struct file * filp) @@ -257,43 +258,56 @@ Sg_device * sdp; Sg_fd * sfp; int res; + int retval = -EBUSY; + SCSI_LOG_TIMEOUT(3, printk("sg_open: dev=%d, flags=0x%x\n", dev, flags)); sdp = sg_get_dev(dev); - if ((! sdp) || (! sdp->device) || (! sdp->device->host)) - return -ENXIO; - if (sdp->i_rdev != inode->i_rdev) - printk("sg_open: inode maj=%d, min=%d sdp maj=%d, min=%d\n", - MAJOR(inode->i_rdev), MINOR(inode->i_rdev), - MAJOR(sdp->i_rdev), MINOR(sdp->i_rdev)); - /* If we are in the middle of error recovery, don't let anyone - * else try and use this device. Also, if error recovery fails, it - * may try and take the device offline, in which case all further - * access to the device is prohibited. */ - if (! ((flags & O_NONBLOCK) || - scsi_block_when_processing_errors(sdp->device))) + if ((! sdp) || (! sdp->device)) return -ENXIO; + if (sdp->detached) + return -ENODEV; - SCSI_LOG_TIMEOUT(3, printk("sg_open: dev=%d, flags=0x%x\n", dev, flags)); + /* This driver's module count bumped by fops_get in */ + /* Prevent the device driver from vanishing while we sleep */ + if (sdp->device->host->hostt->module) + __MOD_INC_USE_COUNT(sdp->device->host->hostt->module); + + if (! ((flags & O_NONBLOCK) || + scsi_block_when_processing_errors(sdp->device))) { + retval = -ENXIO; + /* we are in error recovery for this device */ + goto error_out; + } if (flags & O_EXCL) { - if (O_RDONLY == (flags & O_ACCMODE)) - return -EACCES; /* Can't lock it with read only access */ - if (sdp->headfp && (flags & O_NONBLOCK)) - return -EBUSY; - res = 0; /* following is a macro that beats race condition */ + if (O_RDONLY == (flags & O_ACCMODE)) { + retval = -EACCES; /* Can't lock it with read only access */ + goto error_out; + } + if (sdp->headfp && (flags & O_NONBLOCK)) + goto error_out; + res = 0; __wait_event_interruptible(sdp->o_excl_wait, ((sdp->headfp || sdp->exclude) ? 0 : (sdp->exclude = 1)), res); - if (res) - return res; /* -ERESTARTSYS because signal hit process */ + if (res) { + retval = res; /* -ERESTARTSYS because signal hit process */ + goto error_out; + } } else if (sdp->exclude) { /* some other fd has an exclusive lock on dev */ if (flags & O_NONBLOCK) - return -EBUSY; - res = 0; /* following is a macro that beats race condition */ + goto error_out; + res = 0; __wait_event_interruptible(sdp->o_excl_wait, (! sdp->exclude), res); - if (res) - return res; /* -ERESTARTSYS because signal hit process */ + if (res) { + retval = res; /* -ERESTARTSYS because signal hit process */ + goto error_out; + } + } + if (sdp->detached) { + retval = -ENODEV; + goto error_out; } if (! sdp->headfp) { /* no existing opens on this device */ sdp->sgdebug = 0; @@ -303,12 +317,15 @@ filp->private_data = sfp; else { if (flags & O_EXCL) sdp->exclude = 0; /* undo if error */ - return -ENOMEM; + retval = -ENOMEM; + goto error_out; } - - if (sdp->device->host->hostt->module) - __MOD_INC_USE_COUNT(sdp->device->host->hostt->module); return 0; + +error_out: + if ((! sdp->detached) && sdp->device->host->hostt->module) + __MOD_DEC_USE_COUNT(sdp->device->host->hostt->module); + return retval; } /* Following function was formerly called 'sg_close' */ @@ -324,14 +341,12 @@ } SCSI_LOG_TIMEOUT(3, printk("sg_release: dev=%d\n", MINOR(sdp->i_rdev))); sg_fasync(-1, filp, 0); /* remove filp from async notification list */ - sg_remove_sfp(sdp, sfp); - if (! sdp->headfp) - filp->private_data = NULL; - - if (sdp->device->host->hostt->module) - __MOD_DEC_USE_COUNT(sdp->device->host->hostt->module); - sdp->exclude = 0; - wake_up_interruptible(&sdp->o_excl_wait); + if (0 == sg_remove_sfp(sdp, sfp)) { /* Returns 1 when sdp gone */ + if ((! sdp->detached) && sdp->device->host->hostt->module) + __MOD_DEC_USE_COUNT(sdp->device->host->hostt->module); + sdp->exclude = 0; + wake_up_interruptible(&sdp->o_excl_wait); + } unlock_kernel(); return 0; } @@ -356,11 +371,11 @@ ; /* FIXME: Hmm. Seek to the right place, or fail? */ if ((k = verify_area(VERIFY_WRITE, buf, count))) return k; - if (sfp->force_packid && (count >= size_sg_header)) { - __copy_from_user(&old_hdr, buf, size_sg_header); + if (sfp->force_packid && (count >= SZ_SG_HEADER)) { + __copy_from_user(&old_hdr, buf, SZ_SG_HEADER); if (old_hdr.reply_len < 0) { - if (count >= size_sg_io_hdr) { - __copy_from_user(&new_hdr, buf, size_sg_io_hdr); + if (count >= SZ_SG_IO_HDR) { + __copy_from_user(&new_hdr, buf, SZ_SG_IO_HDR); req_pack_id = new_hdr.pack_id; } } @@ -369,25 +384,26 @@ } srp = sg_get_rq_mark(sfp, req_pack_id); if (! srp) { /* now wait on packet to arrive */ + if (sdp->detached) + return -ENODEV; if (filp->f_flags & O_NONBLOCK) return -EAGAIN; while (1) { - int dio = sg_dio_in_use(sfp); res = 0; /* following is a macro that beats race condition */ - __wait_event_interruptible(sfp->read_wait, - (srp = sg_get_rq_mark(sfp, req_pack_id)), - res); + __wait_event_interruptible(sfp->read_wait, (sdp->detached || + (srp = sg_get_rq_mark(sfp, req_pack_id))), res); + if (sdp->detached) + return -ENODEV; if (0 == res) break; - else if (! dio) /* only let signal out if no dio */ - return res; /* -ERESTARTSYS because signal hit process */ + return res; /* -ERESTARTSYS because signal hit process */ } } if (srp->header.interface_id != '\0') return sg_new_read(sfp, buf, count, srp); hp = &srp->header; - memset(&old_hdr, 0, size_sg_header); + memset(&old_hdr, 0, SZ_SG_HEADER); old_hdr.reply_len = (int)hp->timeout; old_hdr.pack_len = old_hdr.reply_len; /* very old, strange behaviour */ old_hdr.pack_id = hp->pack_id; @@ -430,13 +446,13 @@ } /* Now copy the result back to the user buffer. */ - if (count >= size_sg_header) { - __copy_to_user(buf, &old_hdr, size_sg_header); - buf += size_sg_header; + if (count >= SZ_SG_HEADER) { + __copy_to_user(buf, &old_hdr, SZ_SG_HEADER); + buf += SZ_SG_HEADER; if (count > old_hdr.reply_len) count = old_hdr.reply_len; - if (count > size_sg_header) - sg_read_oxfer(srp, buf, count - size_sg_header); + if (count > SZ_SG_HEADER) + sg_read_oxfer(srp, buf, count - SZ_SG_HEADER); } else count = (old_hdr.result == 0) ? 0 : -EIO; @@ -447,11 +463,14 @@ static ssize_t sg_new_read(Sg_fd * sfp, char * buf, size_t count, Sg_request * srp) { - sg_io_hdr_t * hp = &srp->header; - int k, len; + sg_io_hdr_t * hp = &srp->header; + int err = 0; + int len; - if (count < size_sg_io_hdr) - return -EINVAL; + if (count < SZ_SG_IO_HDR) { + err = -EINVAL; + goto err_out; + } hp->sb_len_wr = 0; if ((hp->mx_sb_len > 0) && hp->sbp) { if ((CHECK_CONDITION & hp->masked_status) || @@ -460,20 +479,19 @@ sb_len = (hp->mx_sb_len > sb_len) ? sb_len : hp->mx_sb_len; len = 8 + (int)srp->sense_b[7]; /* Additional sense length field */ len = (len > sb_len) ? sb_len : len; - if ((k = verify_area(VERIFY_WRITE, hp->sbp, len))) - return k; + if ((err = verify_area(VERIFY_WRITE, hp->sbp, len))) + goto err_out; __copy_to_user(hp->sbp, srp->sense_b, len); hp->sb_len_wr = len; } } if (hp->masked_status || hp->host_status || hp->driver_status) hp->info |= SG_INFO_CHECK; - copy_to_user(buf, hp, size_sg_io_hdr); - - k = sg_read_xfer(srp); - if (k) return k; /* probably -EFAULT, bad addr in dxferp or iovec list */ + copy_to_user(buf, hp, SZ_SG_IO_HDR); + err = sg_read_xfer(srp); +err_out: sg_finish_rem_req(srp); - return count; + return (0 == err) ? count : err; } @@ -494,7 +512,8 @@ return -ENXIO; SCSI_LOG_TIMEOUT(3, printk("sg_write: dev=%d, count=%d\n", MINOR(sdp->i_rdev), (int)count)); - + if (sdp->detached) + return -ENODEV; if (! ((filp->f_flags & O_NONBLOCK) || scsi_block_when_processing_errors(sdp->device))) return -ENXIO; @@ -503,20 +522,20 @@ if ((k = verify_area(VERIFY_READ, buf, count))) return k; /* protects following copy_from_user()s + get_user()s */ - if (count < size_sg_header) + if (count < SZ_SG_HEADER) return -EIO; - __copy_from_user(&old_hdr, buf, size_sg_header); + __copy_from_user(&old_hdr, buf, SZ_SG_HEADER); blocking = !(filp->f_flags & O_NONBLOCK); if (old_hdr.reply_len < 0) return sg_new_write(sfp, buf, count, blocking, 0, NULL); - if (count < (size_sg_header + 6)) + if (count < (SZ_SG_HEADER + 6)) return -EIO; /* The minimum scsi command length is 6 bytes. */ if (! (srp = sg_add_request(sfp))) { SCSI_LOG_TIMEOUT(1, printk("sg_write: queue full\n")); return -EDOM; } - buf += size_sg_header; + buf += SZ_SG_HEADER; __get_user(opcode, buf); if (sfp->next_cmd_len > 0) { if (sfp->next_cmd_len > MAX_COMMAND_SIZE) { @@ -539,8 +558,8 @@ input_size = count - cmd_size; mxsize = (input_size > old_hdr.reply_len) ? input_size : old_hdr.reply_len; - mxsize -= size_sg_header; - input_size -= size_sg_header; + mxsize -= SZ_SG_HEADER; + input_size -= SZ_SG_HEADER; if (input_size < 0) { sg_remove_request(sfp, srp); return -EIO; /* User did not pass enough bytes for this command. */ @@ -550,16 +569,12 @@ hp->cmd_len = (unsigned char)cmd_size; hp->iovec_count = 0; hp->mx_sb_len = 0; -#if 0 - hp->dxfer_direction = SG_DXFER_UNKNOWN; -#else if (input_size > 0) - hp->dxfer_direction = ((old_hdr.reply_len - size_sg_header) > 0) ? + hp->dxfer_direction = ((old_hdr.reply_len - SZ_SG_HEADER) > 0) ? SG_DXFER_TO_FROM_DEV : SG_DXFER_TO_DEV; else hp->dxfer_direction = (mxsize > 0) ? SG_DXFER_FROM_DEV : SG_DXFER_NONE; -#endif hp->dxfer_len = mxsize; hp->dxferp = (unsigned char *)buf + cmd_size; hp->sbp = NULL; @@ -581,7 +596,7 @@ unsigned char cmnd[sizeof(dummy_cmdp->sr_cmnd)]; int timeout; - if (count < size_sg_io_hdr) + if (count < SZ_SG_IO_HDR) return -EINVAL; if ((k = verify_area(VERIFY_READ, buf, count))) return k; /* protects following copy_from_user()s + get_user()s */ @@ -592,7 +607,7 @@ return -EDOM; } hp = &srp->header; - __copy_from_user(hp, buf, size_sg_io_hdr); + __copy_from_user(hp, buf, SZ_SG_IO_HDR); if (hp->interface_id != 'S') { sg_remove_request(sfp, srp); return -ENOSYS; @@ -648,7 +663,10 @@ sg_finish_rem_req(srp); return k; } -/* SCSI_LOG_TIMEOUT(7, printk("sg_write: allocating device\n")); */ + if (sdp->detached) { + sg_finish_rem_req(srp); + return -ENODEV; + } SRpnt = scsi_allocate_request(sdp->device); if(SRpnt == NULL) { SCSI_LOG_TIMEOUT(1, printk("sg_write: no mem\n")); @@ -656,17 +674,15 @@ return -ENOMEM; } -/* SCSI_LOG_TIMEOUT(7, printk("sg_write: device allocated\n")); */ srp->my_cmdp = SRpnt; SRpnt->sr_request.rq_dev = sdp->i_rdev; SRpnt->sr_request.rq_status = RQ_ACTIVE; SRpnt->sr_sense_buffer[0] = 0; SRpnt->sr_cmd_len = hp->cmd_len; -/* Set the LUN field in the command structure, overriding user input */ - if (! (hp->flags & SG_FLAG_LUN_INHIBIT)) - cmnd[1] = (cmnd[1] & 0x1f) | (sdp->device->lun << 5); - -/* SCSI_LOG_TIMEOUT(7, printk("sg_write: do cmd\n")); */ + if (! (hp->flags & SG_FLAG_LUN_INHIBIT)) { + if (sdp->device->scsi_level <= SCSI_2) + cmnd[1] = (cmnd[1] & 0x1f) | (sdp->device->lun << 5); + } SRpnt->sr_use_sg = srp->data.k_use_sg; SRpnt->sr_sglist_len = srp->data.sglist_len; SRpnt->sr_bufflen = srp->data.bufflen; @@ -719,30 +735,31 @@ { int blocking = 1; /* ignore O_NONBLOCK flag */ + if (sdp->detached) + return -ENODEV; if(! scsi_block_when_processing_errors(sdp->device) ) return -ENXIO; - result = verify_area(VERIFY_WRITE, (void *)arg, size_sg_io_hdr); + result = verify_area(VERIFY_WRITE, (void *)arg, SZ_SG_IO_HDR); if (result) return result; - result = sg_new_write(sfp, (const char *)arg, size_sg_io_hdr, + result = sg_new_write(sfp, (const char *)arg, SZ_SG_IO_HDR, blocking, read_only, &srp); if (result < 0) return result; srp->sg_io_owned = 1; while (1) { - int dio = sg_dio_in_use(sfp); result = 0; /* following macro to beat race condition */ __wait_event_interruptible(sfp->read_wait, - (sfp->closed || srp->done), result); + (sdp->detached || sfp->closed || srp->done), result); + if (sdp->detached) + return -ENODEV; if (sfp->closed) return 0; /* request packet dropped already */ if (0 == result) break; - else if (! dio) { /* only let signal out if no dio */ - srp->orphan = 1; - return result; /* -ERESTARTSYS because signal hit process */ - } + srp->orphan = 1; + return result; /* -ERESTARTSYS because signal hit process */ } srp->done = 2; - result = sg_new_read(sfp, (char *)arg, size_sg_io_hdr, srp); + result = sg_new_read(sfp, (char *)arg, SZ_SG_IO_HDR, srp); return (result < 0) ? result : 0; } case SG_SET_TIMEOUT: @@ -765,8 +782,11 @@ sg_build_reserve(sfp, val); } } - else + else { + if (sdp->detached) + return -ENODEV; sfp->low_dma = sdp->device->host->unchecked_isa_dma; + } return 0; case SG_GET_LOW_DMA: return put_user((int)sfp->low_dma, (int *)arg); @@ -775,6 +795,9 @@ if (result) return result; else { sg_scsi_id_t * sg_idp = (sg_scsi_id_t *)arg; + + if (sdp->detached) + return -ENODEV; __put_user((int)sdp->device->host->host_no, &sg_idp->host_no); __put_user((int)sdp->device->channel, &sg_idp->channel); __put_user((int)sdp->device->id, &sg_idp->scsi_id); @@ -853,7 +876,7 @@ return put_user(sg_version_num, (int *)arg); case SG_GET_REQUEST_TABLE: result = verify_area(VERIFY_WRITE, (void *) arg, - size_sg_req_info * SG_MAX_QUEUE); + SZ_SG_REQ_INFO * SG_MAX_QUEUE); if (result) return result; else { sg_req_info_t rinfo[SG_MAX_QUEUE]; @@ -861,7 +884,7 @@ read_lock_irqsave(&sfp->rq_list_lock, iflags); for (srp = sfp->headrp, val = 0; val < SG_MAX_QUEUE; ++val, srp = srp ? srp->nextrp : srp) { - memset(&rinfo[val], 0, size_sg_req_info); + memset(&rinfo[val], 0, SZ_SG_REQ_INFO); if (srp) { rinfo[val].req_state = srp->done + 1; rinfo[val].problem = srp->header.masked_status & @@ -876,12 +899,16 @@ } } read_unlock_irqrestore(&sfp->rq_list_lock, iflags); - __copy_to_user((void *)arg, rinfo, size_sg_req_info * SG_MAX_QUEUE); + __copy_to_user((void *)arg, rinfo, SZ_SG_REQ_INFO * SG_MAX_QUEUE); return 0; } case SG_EMULATED_HOST: + if (sdp->detached) + return -ENODEV; return put_user(sdp->device->host->hostt->emulated, (int *)arg); case SG_SCSI_RESET: + if (sdp->detached) + return -ENODEV; if (filp->f_flags & O_NONBLOCK) { if (sdp->device->host->in_recovery) return -EBUSY; @@ -907,13 +934,16 @@ default: return -EINVAL; } - if(! capable(CAP_SYS_ADMIN)) return -EACCES; + if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SYS_RAWIO)) + return -EACCES; return (scsi_reset_provider(sdp->device, val) == SUCCESS) ? 0 : -EIO; #else SCSI_LOG_TIMEOUT(1, printk("sg_ioctl: SG_RESET_SCSI not supported\n")); result = -EINVAL; #endif case SCSI_IOCTL_SEND_COMMAND: + if (sdp->detached) + return -ENODEV; if (read_only) { unsigned char opcode = WRITE_6; Scsi_Ioctl_Command * siocp = (void *)arg; @@ -932,6 +962,8 @@ case SCSI_IOCTL_GET_BUS_NUMBER: case SCSI_IOCTL_PROBE_HOST: case SG_GET_TRANSFORM: + if (sdp->detached) + return -ENODEV; return scsi_ioctl(sdp->device, cmd_in, (void *)arg); default: if (read_only) @@ -949,7 +981,8 @@ int count = 0; unsigned long iflags; - if ((! (sfp = (Sg_fd *)filp->private_data)) || (! (sdp = sfp->parentdp))) + if ((! (sfp = (Sg_fd *)filp->private_data)) || (! (sdp = sfp->parentdp)) + || sfp->closed) return POLLERR; poll_wait(filp, &sfp->read_wait, wait); read_lock_irqsave(&sfp->rq_list_lock, iflags); @@ -960,7 +993,10 @@ ++count; } read_unlock_irqrestore(&sfp->rq_list_lock, iflags); - if (! sfp->cmd_q) { + + if (sdp->detached) + res |= POLLHUP; + else if (! sfp->cmd_q) { if (0 == count) res |= POLLOUT | POLLWRNORM; } @@ -1001,9 +1037,9 @@ if (dev < sg_template.dev_max) sdp = sg_dev_arr[dev]; } - if (NULL == sdp) { + if ((NULL == sdp) || sdp->detached) { read_unlock(&sg_dev_arr_lock); - SCSI_LOG_TIMEOUT(1, printk("sg...bh: bad args dev=%d\n", dev)); + SCSI_LOG_TIMEOUT(1, printk("sg...bh: dev=%d gone\n", dev)); scsi_release_request(SRpnt); SRpnt = NULL; return; @@ -1020,8 +1056,8 @@ break; sfp = sfp->nextfp; } - read_unlock(&sg_dev_arr_lock); if (! srp) { + read_unlock(&sg_dev_arr_lock); SCSI_LOG_TIMEOUT(1, printk("sg...bh: req missing, dev=%d\n", dev)); scsi_release_request(SRpnt); SRpnt = NULL; @@ -1035,6 +1071,7 @@ sg_clr_srpnt(SRpnt); srp->my_cmdp = NULL; srp->done = 1; + read_unlock(&sg_dev_arr_lock); SCSI_LOG_TIMEOUT(4, printk("sg...bh: dev=%d, pack_id=%d, res=0x%x\n", dev, srp->header.pack_id, (int)SRpnt->sr_result)); @@ -1071,7 +1108,6 @@ if (sfp->closed) { /* whoops this fd already released, cleanup */ SCSI_LOG_TIMEOUT(1, printk("sg...bh: already closed, freeing ...\n")); - /* should check if module is unloaded <<<<<<< */ sg_finish_rem_req(srp); srp = NULL; if (NULL == sfp->headrp) { @@ -1080,6 +1116,10 @@ sg_remove_sfp(sdp, sfp); sfp = NULL; } + if (sg_template.module) + __MOD_DEC_USE_COUNT(sg_template.module); + if (sdp->device->host->hostt->module) + __MOD_DEC_USE_COUNT(sdp->device->host->hostt->module); } else if (srp && srp->orphan) { if (sfp->keep_orphan) @@ -1110,19 +1150,6 @@ static int sg_detect(Scsi_Device * scsidp) { - switch (scsidp->type) { - case TYPE_DISK: - case TYPE_MOD: - case TYPE_ROM: - case TYPE_WORM: - case TYPE_TAPE: break; - default: - printk("Detected scsi generic sg%d at scsi%d," - " channel %d, id %d, lun %d, type %d\n", - sg_template.dev_noticed, - scsidp->host->host_no, scsidp->channel, - scsidp->id, scsidp->lun, scsidp->type); - } sg_template.dev_noticed++; return 1; } @@ -1241,51 +1268,73 @@ sg_template.nr_dev++; sg_dev_arr[k] = sdp; write_unlock_irqrestore(&sg_dev_arr_lock, iflags); + switch (scsidp->type) { + case TYPE_DISK: + case TYPE_MOD: + case TYPE_ROM: + case TYPE_WORM: + case TYPE_TAPE: break; + default: + printk("Attached scsi generic sg%d at scsi%d, channel %d, id %d," + " lun %d, type %d\n", k, scsidp->host->host_no, + scsidp->channel, scsidp->id, scsidp->lun, scsidp->type); + } return 0; } /* Called at 'finish' of init process, after all attaches */ static void sg_finish(void) -{ - SCSI_LOG_TIMEOUT(3, printk("sg_finish: dma_free_sectors=%u\n", - scsi_dma_free_sectors)); -} +{ } static void sg_detach(Scsi_Device * scsidp) { Sg_device * sdp; unsigned long iflags; Sg_fd * sfp; + Sg_fd * tsfp; Sg_request * srp; - int k; + Sg_request * tsrp; + int k, delay; if (NULL == sg_dev_arr) return; + delay = 0; write_lock_irqsave(&sg_dev_arr_lock, iflags); for (k = 0; k < sg_template.dev_max; k++) { sdp = sg_dev_arr[k]; if ((NULL == sdp) || (sdp->device != scsidp)) continue; /* dirty but lowers nesting */ if (sdp->headfp) { - for (sfp = sdp->headfp; sfp; sfp = sfp->nextfp) { - /* no lock on request list here */ - for (srp = sfp->headrp; srp; srp = srp->nextrp) { - if (! srp->done) { - write_unlock_irqrestore(&sg_dev_arr_lock, iflags); - sg_shorten_timeout(srp->my_cmdp); - write_lock_irqsave(&sg_dev_arr_lock, iflags); - } - } + sdp->detached = 1; + for (sfp = sdp->headfp; sfp; sfp = tsfp) { + tsfp = sfp->nextfp; + for (srp = sfp->headrp; srp; srp = tsrp) { + tsrp = srp->nextrp; + if (sfp->closed || (0 == srp->done)) + sg_finish_rem_req(srp); + } + if (sfp->closed) { + if (sg_template.module) + __MOD_DEC_USE_COUNT(sg_template.module); + if (sdp->device->host->hostt->module) + __MOD_DEC_USE_COUNT(sdp->device->host->hostt->module); + __sg_remove_sfp(sdp, sfp); + } + else { + delay = 1; + wake_up_interruptible(&sfp->read_wait); + kill_fasync(&sfp->async_qp, SIGPOLL, POLL_HUP); + } } - write_unlock_irqrestore(&sg_dev_arr_lock, iflags); - SCSI_LOG_TIMEOUT(3, printk("sg_detach: dev=%d, dirty, sleep(3)\n", k)); - scsi_sleep(3); /* sleep 3 jiffies, hoping for timeout to go off */ + SCSI_LOG_TIMEOUT(3, printk("sg_detach: dev=%d, dirty\n", k)); devfs_unregister (sdp->de); sdp->de = NULL; - sdp->detached = 1; - write_lock_irqsave(&sg_dev_arr_lock, iflags); + if (NULL == sdp->headfp) { + kfree((char *)sdp); + sg_dev_arr[k] = NULL; + } } - else { + else { /* nothing active, simple case */ SCSI_LOG_TIMEOUT(3, printk("sg_detach: dev=%d\n", k)); devfs_unregister (sdp->de); kfree((char *)sdp); @@ -1293,13 +1342,12 @@ } scsidp->attached--; sg_template.nr_dev--; -/* avoid associated device /dev/sg? being incremented - * each time module is inserted/removed , */ - sg_template.dev_noticed--; + sg_template.dev_noticed--; /* from */ break; } write_unlock_irqrestore(&sg_dev_arr_lock, iflags); - return; + if (delay) + scsi_sleep(2); /* dirty detach so delay device destruction */ } MODULE_AUTHOR("Douglas Gilbert"); @@ -1322,8 +1370,6 @@ scsi_unregister_module(MODULE_SCSI_DEV, &sg_template); devfs_unregister_chrdev(SCSI_GENERIC_MAJOR, "sg"); if(sg_dev_arr != NULL) { -/* Really worrying situation of writes still pending and get here */ -/* Strategy: shorten timeout on release + wait on detach ... */ kfree((char *)sg_dev_arr); sg_dev_arr = NULL; } @@ -1331,29 +1377,6 @@ } -#if 0 -extern void scsi_times_out (Scsi_Cmnd * SCpnt); -extern void scsi_old_times_out (Scsi_Cmnd * SCpnt); -#endif - -/* Can't see clean way to abort a command so shorten timeout to 1 jiffy */ -static void sg_shorten_timeout(Scsi_Request * srpnt) -{ -#if 0 /* scsi_syms.c is very miserly about exported functions */ - scsi_delete_timer(scpnt); - if (! scpnt) - return; - scpnt->timeout_per_command = 1; /* try 1 jiffy (perhaps 0 jiffies) */ - if (scpnt->host->hostt->use_new_eh_code) - scsi_add_timer(scpnt, scpnt->timeout_per_command, scsi_times_out); - else - scsi_add_timer(scpnt, scpnt->timeout_per_command, - scsi_old_times_out); -#else - scsi_sleep(HZ); /* just sleep 1 second and hope ... */ -#endif -} - static int sg_start_req(Sg_request * srp) { int res; @@ -1367,9 +1390,8 @@ SCSI_LOG_TIMEOUT(4, printk("sg_start_req: dxfer_len=%d\n", dxfer_len)); if ((dxfer_len <= 0) || (dxfer_dir == SG_DXFER_NONE)) return 0; - if ((hp->flags & SG_FLAG_DIRECT_IO) && - (dxfer_dir != SG_DXFER_UNKNOWN) && - (0 == hp->iovec_count) && + if (sg_allow_dio && (hp->flags & SG_FLAG_DIRECT_IO) && + (dxfer_dir != SG_DXFER_UNKNOWN) && (0 == hp->iovec_count) && (! sfp->parentdp->device->host->unchecked_isa_dma)) { res = sg_build_dir(srp, sfp, dxfer_len); if (res <= 0) /* -ve -> error, 0 -> done, 1 -> try indirect */ @@ -1427,7 +1449,7 @@ static void sg_unmap_and(Sg_scatter_hold * schp, int free_also) { -#ifdef SG_ALLOW_DIO +#ifdef SG_ALLOW_DIO_CODE if (schp && schp->kiobp) { if (schp->mapped) { unmap_kiobuf(schp->kiobp); @@ -1443,7 +1465,7 @@ static int sg_build_dir(Sg_request * srp, Sg_fd * sfp, int dxfer_len) { -#ifdef SG_ALLOW_DIO +#ifdef SG_ALLOW_DIO_CODE int res, k, split, offset, num, mx_sc_elems, rem_sz; struct kiobuf * kp; char * mem_src_arr; @@ -1519,7 +1541,7 @@ return 0; #else return 1; -#endif /* SG_ALLOW_DIO */ +#endif /* SG_ALLOW_DIO_CODE */ } static int sg_build_indi(Sg_scatter_hold * schp, Sg_fd * sfp, int buff_size) @@ -1629,7 +1651,7 @@ if (iovec_count) { onum = iovec_count; if ((k = verify_area(VERIFY_READ, hp->dxferp, - size_sg_iovec * onum))) + SZ_SG_IOVEC * onum))) return k; } else @@ -1707,8 +1729,8 @@ } else { __copy_from_user(&u_iovec, - (unsigned char *)hp->dxferp + (ind * size_sg_iovec), - size_sg_iovec); + (unsigned char *)hp->dxferp + (ind * SZ_SG_IOVEC), + SZ_SG_IOVEC); p = (unsigned char *)u_iovec.iov_base; count = (int)u_iovec.iov_len; } @@ -1778,7 +1800,7 @@ if (iovec_count) { onum = iovec_count; if ((k = verify_area(VERIFY_READ, hp->dxferp, - size_sg_iovec * onum))) + SZ_SG_IOVEC * onum))) return k; } else @@ -2124,6 +2146,34 @@ return sfp; } +static void __sg_remove_sfp(Sg_device * sdp, Sg_fd * sfp) +{ + Sg_fd * fp; + Sg_fd * prev_fp; + + prev_fp = sdp->headfp; + if (sfp == prev_fp) + sdp->headfp = prev_fp->nextfp; + else { + while ((fp = prev_fp->nextfp)) { + if (sfp == fp) { + prev_fp->nextfp = fp->nextfp; + break; + } + prev_fp = fp; + } + } + if (sfp->reserve.bufflen > 0) { + SCSI_LOG_TIMEOUT(6, printk("__sg_remove_sfp: bufflen=%d, k_use_sg=%d\n", + (int)sfp->reserve.bufflen, (int)sfp->reserve.k_use_sg)); + sg_remove_scat(&sfp->reserve); + } + sfp->parentdp = NULL; + SCSI_LOG_TIMEOUT(6, printk("__sg_remove_sfp: sfp=0x%p\n", sfp)); + sg_low_free((char *)sfp, sizeof(Sg_fd), sfp->fd_mem_src); +} + +/* Returns 0 in normal case, 1 when detached and sdp object removed */ static int sg_remove_sfp(Sg_device * sdp, Sg_fd * sfp) { Sg_request * srp; @@ -2131,44 +2181,18 @@ int dirty = 0; int res = 0; - srp = sfp->headrp; - if (srp) { - while (srp) { - tsrp = srp->nextrp; - if (srp->done) - sg_finish_rem_req(srp); - else - ++dirty; - srp = tsrp; - } + for (srp = sfp->headrp; srp; srp = tsrp) { + tsrp = srp->nextrp; + if (srp->done) + sg_finish_rem_req(srp); + else + ++dirty; } if (0 == dirty) { - Sg_fd * fp; - Sg_fd * prev_fp; unsigned long iflags; write_lock_irqsave(&sg_dev_arr_lock, iflags); - prev_fp = sdp->headfp; - if (sfp == prev_fp) - sdp->headfp = prev_fp->nextfp; - else { - while ((fp = prev_fp->nextfp)) { - if (sfp == fp) { - prev_fp->nextfp = fp->nextfp; - break; - } - prev_fp = fp; - } - } - write_unlock_irqrestore(&sg_dev_arr_lock, iflags); - if (sfp->reserve.bufflen > 0) { -SCSI_LOG_TIMEOUT(6, printk("sg_remove_sfp: bufflen=%d, k_use_sg=%d\n", - (int)sfp->reserve.bufflen, (int)sfp->reserve.k_use_sg)); - sg_remove_scat(&sfp->reserve); - } - sfp->parentdp = NULL; - SCSI_LOG_TIMEOUT(6, printk("sg_remove_sfp: sfp=0x%p\n", sfp)); - sg_low_free((char *)sfp, sizeof(Sg_fd), sfp->fd_mem_src); + __sg_remove_sfp(sdp, sfp); if (sdp->detached && (NULL == sdp->headfp)) { int k, maxd; @@ -2180,11 +2204,17 @@ if (k < maxd) sg_dev_arr[k] = NULL; kfree((char *)sdp); + res = 1; } - res = 1; + write_unlock_irqrestore(&sg_dev_arr_lock, iflags); } else { sfp->closed = 1; /* flag dirty state on this fd */ + /* MOD_INC's to inhibit unloading sg and associated adapter driver */ + if (sg_template.module) + __MOD_INC_USE_COUNT(sg_template.module); + if (sdp->device->host->hostt->module) + __MOD_INC_USE_COUNT(sdp->device->host->hostt->module); SCSI_LOG_TIMEOUT(1, printk( "sg_remove_sfp: worrisome, %d writes pending\n", dirty)); } @@ -2203,31 +2233,15 @@ return srp ? 1 : 0; } -static int sg_dio_in_use(Sg_fd * sfp) -{ - const Sg_request * srp; - unsigned long iflags; - - read_lock_irqsave(&sfp->rq_list_lock, iflags); - for (srp = sfp->headrp; srp; srp = srp->nextrp) - if ((! srp->done) && srp->data.kiobp) break; - read_unlock_irqrestore(&sfp->rq_list_lock, iflags); - return srp ? 1 : 0; -} - /* If retSzp==NULL want exact size or fail */ -/* sg_low_malloc() should always be called from a process context allowing - GFP_KERNEL to be used instead of GFP_ATOMIC */ static char * sg_low_malloc(int rqSz, int lowDma, int mem_src, int * retSzp) { char * resp = NULL; - int page_mask = lowDma ? (GFP_KERNEL | GFP_DMA) : GFP_KERNEL; + int page_mask = lowDma ? (GFP_ATOMIC | GFP_DMA) : GFP_ATOMIC; if (rqSz <= 0) return resp; if (SG_HEAP_KMAL == mem_src) { - page_mask = lowDma ? (GFP_ATOMIC | GFP_DMA) : GFP_ATOMIC; - /* Seen kmalloc(..,GFP_KERNEL) hang for 40 secs! */ resp = kmalloc(rqSz, page_mask); if (resp && retSzp) *retSzp = rqSz; return resp; @@ -2355,7 +2369,7 @@ case SG_USER_MEM: break; /* nothing to do */ default: - printk("sg_low_free: bad mem_src=%d, buff=0x%p, rqSz=%df\n", + printk("sg_low_free: bad mem_src=%d, buff=0x%p, rqSz=%d\n", mem_src, buff, size); break; } @@ -2451,11 +2465,17 @@ static struct proc_dir_entry * sg_proc_sgp = NULL; -static const char * sg_proc_sg_dirname = "sg"; -static const char * sg_proc_leaf_names[] = {"def_reserved_size", "debug", - "devices", "device_hdr", "device_strs", - "hosts", "host_hdr", "host_strs", "version"}; +static char sg_proc_sg_dirname[] = "sg"; +static const char * sg_proc_leaf_names[] = {"allow_dio", "def_reserved_size", + "debug", "devices", "device_hdr", "device_strs", + "hosts", "host_hdr", "host_strs", "version"}; +static int sg_proc_adio_read(char * buffer, char ** start, off_t offset, + int size, int * eof, void * data); +static int sg_proc_adio_info(char * buffer, int * len, off_t * begin, + off_t offset, int size); +static int sg_proc_adio_write(struct file * filp, const char * buffer, + unsigned long count, void * data); static int sg_proc_dressz_read(char * buffer, char ** start, off_t offset, int size, int * eof, void * data); static int sg_proc_dressz_info(char * buffer, int * len, off_t * begin, @@ -2495,12 +2515,12 @@ static int sg_proc_version_info(char * buffer, int * len, off_t * begin, off_t offset, int size); static read_proc_t * sg_proc_leaf_reads[] = { - sg_proc_dressz_read, sg_proc_debug_read, + sg_proc_adio_read, sg_proc_dressz_read, sg_proc_debug_read, sg_proc_dev_read, sg_proc_devhdr_read, sg_proc_devstrs_read, sg_proc_host_read, sg_proc_hosthdr_read, sg_proc_hoststrs_read, sg_proc_version_read}; static write_proc_t * sg_proc_leaf_writes[] = { - sg_proc_dressz_write, 0, 0, 0, 0, 0, 0, 0, 0}; + sg_proc_adio_write, sg_proc_dressz_write, 0, 0, 0, 0, 0, 0, 0, 0}; #define PRINT_PROC(fmt,args...) \ do { \ @@ -2562,6 +2582,32 @@ remove_proc_entry(sg_proc_sg_dirname, proc_scsi); } +static int sg_proc_adio_read(char * buffer, char ** start, off_t offset, + int size, int * eof, void * data) +{ SG_PROC_READ_FN(sg_proc_adio_info); } + +static int sg_proc_adio_info(char * buffer, int * len, off_t * begin, + off_t offset, int size) +{ + PRINT_PROC("%d\n", sg_allow_dio); + return 1; +} + +static int sg_proc_adio_write(struct file * filp, const char * buffer, + unsigned long count, void * data) +{ + int num; + char buff[11]; + + if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SYS_RAWIO)) + return -EACCES; + num = (count < 10) ? count : 10; + copy_from_user(buff, buffer, num); + buff[num] = '\0'; + sg_allow_dio = simple_strtoul(buff, 0, 10) ? 1 : 0; + return count; +} + static int sg_proc_dressz_read(char * buffer, char ** start, off_t offset, int size, int * eof, void * data) { SG_PROC_READ_FN(sg_proc_dressz_info); } @@ -2580,7 +2626,7 @@ unsigned long k = ULONG_MAX; char buff[11]; - if (! capable(CAP_SYS_ADMIN)) + if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SYS_RAWIO)) return -EACCES; num = (count < 10) ? count : 10; copy_from_user(buff, buffer, num); @@ -2620,8 +2666,9 @@ Sg_request * srp; struct scsi_device * scsidp; int dev, k, m, blen, usg; - - if (! (scsidp = sdp->device)) { + + scsidp = sdp->device; + if (NULL == scsidp) { PRINT_PROC("device %d detached ??\n", j); continue; } @@ -2629,10 +2676,14 @@ if (sg_get_nth_sfp(sdp, 0)) { PRINT_PROC(" >>> device=sg%d ", dev); - PRINT_PROC("scsi%d chan=%d id=%d lun=%d em=%d sg_tablesize=%d" - " excl=%d\n", scsidp->host->host_no, scsidp->channel, - scsidp->id, scsidp->lun, scsidp->host->hostt->emulated, - sdp->sg_tablesize, sdp->exclude); + if (sdp->detached) + PRINT_PROC("detached pending close "); + else + PRINT_PROC("scsi%d chan=%d id=%d lun=%d em=%d", + scsidp->host->host_no, scsidp->channel, + scsidp->id, scsidp->lun, scsidp->host->hostt->emulated); + PRINT_PROC(" sg_tablesize=%d excl=%d\n", sdp->sg_tablesize, + sdp->exclude); } for (k = 0; (fp = sg_get_nth_sfp(sdp, k)); ++k) { PRINT_PROC(" FD(%d): timeout=%dms bufflen=%d " @@ -2683,13 +2734,14 @@ max_dev = sg_last_dev(); for (j = 0; j < max_dev; ++j) { sdp = sg_get_dev(j); - if (sdp && (scsidp = sdp->device)) - PRINT_PROC("%d\t%d\t%d\t%d\t%d\t%d\t%d\t%d\n", + if (sdp && (scsidp = sdp->device) && (! sdp->detached)) + PRINT_PROC("%d\t%d\t%d\t%d\t%d\t%d\t%d\t%d\t%d\n", scsidp->host->host_no, scsidp->channel, scsidp->id, scsidp->lun, (int)scsidp->type, (int)scsidp->access_count, - (int)scsidp->queue_depth, (int)scsidp->device_busy); + (int)scsidp->queue_depth, (int)scsidp->device_busy, + (int)scsidp->online); else - PRINT_PROC("-1\t-1\t-1\t-1\t-1\t-1\t-1\t-1\n"); + PRINT_PROC("-1\t-1\t-1\t-1\t-1\t-1\t-1\t-1\t-1\n"); } return 1; } @@ -2701,7 +2753,7 @@ static int sg_proc_devhdr_info(char * buffer, int * len, off_t * begin, off_t offset, int size) { - PRINT_PROC("host\tchan\tid\tlun\ttype\tbopens\tqdepth\tbusy\n"); + PRINT_PROC("host\tchan\tid\tlun\ttype\tbopens\tqdepth\tbusy\tonline\n"); return 1; } @@ -2719,7 +2771,7 @@ max_dev = sg_last_dev(); for (j = 0; j < max_dev; ++j) { sdp = sg_get_dev(j); - if (sdp && (scsidp = sdp->device)) + if (sdp && (scsidp = sdp->device) && (! sdp->detached)) PRINT_PROC("%8.8s\t%16.16s\t%4.4s\n", scsidp->vendor, scsidp->model, scsidp->rev); else --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-2.4.5-ac18-1716.patch" diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla/include/scsi/sg.h linux.ac/include/scsi/sg.h --- linux.vanilla/include/scsi/sg.h Fri Sep 22 04:48:05 2000 +++ linux.ac/include/scsi/sg.h Mon Jun 25 09:50:33 2001 @@ -9,89 +9,43 @@ Original driver (sg.h): * Copyright (C) 1992 Lawrence Foard Version 2 and 3 extensions to driver: -* Copyright (C) 1998 - 2000 Douglas Gilbert +* Copyright (C) 1998 - 2001 Douglas Gilbert - Version: 3.1.17 (20000921) + Version: 3.1.19 (20010623) This version is for 2.4 series kernels. - Changes since 3.1.16 (20000716) - - changes for new scsi subsystem initialization - - change Scsi_Cmnd usage to Scsi_Request - - cleanup for no procfs - Changes since 3.1.15 (20000528) - - further (scatter gather) buffer length changes - Changes since 3.1.14 (20000503) - - fix aha1542 odd length buffer problem - - make multiple readers on same fd safe - Changes since 3.1.13 (20000324) - - revert change so sg_header interface doesn't send _UNKNOWN - - "discon" and "tq" in /proc/scsi/sg/devices replaced with - "bopens" and "busy"; correct duration output in procfs - - provision for SG_RESET - - lock file descriptor and request lists - Changes since 3.1.12 (20000222) - - make sg_header interface use SCSI_DATA_UNKNOWN - - add SG_DXFER_UNKNOWN define to sg interface - - stop allocating data buffers to non data transfer commands - Changes since 3.1.10 (20000123) - - make device allocation dynamic (get rid of SG_EXTRA_DEVS) - - move to sg0,sg1,sg2 rather than sga,sgb,sgc - - make sg_io_hdr_t safer across architectures - Changes since 2.1.34 (990603) and 2.3.35 (990708) - - add new interface structure: sg_io_hdr_t - - supports larger sense buffer, DMA residual count + direct IO - - add SG_IO ioctl (combines function of write() + read() ) - - remove SG_SET_MERGE_FD, UNDERRUN_FLAG + _GET_ ioctls + logic - - add proc_fs support in /proc/scsi/sg/ directory - - add queuing info into struct sg_scsi_id - - def_reserved_size can be given at driver or module load time - Changes since 2.1.33 (990521) - - implement SG_SET_RESERVED_SIZE and associated memory re-org. - - add SG_NEXT_CMD_LEN to override SCSI command lengths - - add SG_GET_VERSION_NUM to get version expressed as an integer - Changes since 2.1.32 (990501) - - fix race condition in sg_read() and sg_open() - Changes since 2.1.31 (990327) - - add ioctls SG_GET_UNDERRUN_FLAG and _SET_. Change the default - to _not_ flag underruns (affects aic7xxx driver) - - clean up logging of pointers to use %p (for 64 bit architectures) - - rework usage of get_user/copy_to_user family of kernel calls - - "disown" scsi_command blocks before releasing them + Changes since 3.1.18 (20010505) + - fix bug that caused long wait when large buffer requested + - fix leak in error case of sg_new_read() [report: Eric Barton] + - add 'online' column to /proc/scsi/sg/devices + Changes since 3.1.17 (20000921) + - add CAP_SYS_RAWIO capability for sensitive stuff + - compile in dio stuff, procfs 'allow_dio' defaulted off (0) + - make premature close and detach more robust + - lun masked into commands <= SCSI_2 + - poll() and async notification now yield POLL_HUP on detach + - various 3rd party tweaks tracking lk 2.4 internal changes Map of SG verions to the Linux kernels in which they appear: ---------- ---------------------------------- original all kernels < 2.2.6 - 2.1.31 2.2.6 and 2.2.7 - 2.1.32 2.2.8 and 2.2.9 - 2.1.34 2.2.10 to 2.2.13 - 2.1.36 2.2.14 and 2.2.15 + 2.1.38 2.2.16 + 2.1.39 2.2.17 - 2.2.19 3.0.x optional version 3 sg driver for 2.2 series - 3.1.x first appeared in lk 2.3.43 + 3.1.17 2.4.0 ++ Major new features in SG 3.x driver (cf SG 2.x drivers) - SG_IO ioctl() combines function if write() and read() - new interface (sg_io_hdr_t) but still supports old interface - scatter/gather in user space and direct IO supported -Major features in SG 2.x driver (cf original SG driver) - - per file descriptor (fd) write-read sequencing - - command queuing supported - - scatter-gather supported at kernel level allowing potentially - large transfers - - more SCSI status information returned - - asynchronous notification support added (SIGPOLL, SIGIO) - - read() can fetch by given pack_id - - uses kernel memory as appropriate for SCSI adapter being used - - single SG_BIG_BUFF replaced by per file descriptor "reserve - buffer" whose size can be manipulated by ioctls() - The term "indirect IO" refers a method by which data is DMAed into kernel buffers from the hardware and afterwards is transferred into the user space (or vice versa if you are writing). Transfer speeds of up to 20 to 30MBytes/sec have been measured using indirect IO. For faster throughputs "direct IO" which cuts out the double handling of data is required. - Direct IO is supported by the SG 3.x drivers on 2.3 series Linux kernels - (or later) and requires the use of the new interface. + Direct IO is supported by the SG 3.x drivers on 2.4 series Linux kernels + and requires the use of the new interface. Requests for direct IO with the new interface will automatically fall back to indirect IO mode if they cannot be fulfilled. An example of such a case @@ -107,6 +61,9 @@ kernel memory that is suitable for DMA may be constrained by the architecture of the SCSI adapter (e.g. ISA adapters). + ** N.B. To use direct IO 'echo 1 > /proc/scsi/sg/allow_dio' may be + needed. That pseudo file's content is defaulted to 0. ** + Documentation ============= A web site for SG device drivers can be found at: @@ -116,9 +73,10 @@ http://www.torque.net/sg/p/scsi-generic_long.txt Documentation on the changes and additions in 3.x version of the sg driver can be found at: http://www.torque.net/sg/p/scsi-generic_v3.txt - This document can also be found in the kernel source tree, probably at: + A version of this document (potentially out of date) may also be found in + the kernel source tree, probably at: /usr/src/linux/Documentation/scsi-generic.txt . - Utility and test programs are also available at that web site. + Utility and test programs are available at the sg web site. */ /* New interface introduced in the 3.x SG drivers follows */ --tKW2IUtsqtDRztdT-- From owner-linux-xfs@oss.sgi.com Tue Jun 26 20:05:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R35nc03809 for linux-xfs-outgoing; Tue, 26 Jun 2001 20:05:49 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R35mV03806 for ; Tue, 26 Jun 2001 20:05:48 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip33.idcomm.com [209.60.72.160]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5R373l29197 for ; Tue, 26 Jun 2001 21:07:03 -0600 Message-ID: <3B394DF5.EFF68DDB@idcomm.com> Date: Tue, 26 Jun 2001 21:07:33 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "XFS: linux-xfs@oss.sgi.com" Subject: Re: fatal error -- couldn't initialize XFS library References: <200106262218.f5QMIvJ13487@jen.americas.sgi.com> <3B391074.FD44176@idcomm.com> <3B392EE6.51190E7D@insanegeeks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thomas Suiter wrote: > > Maybe I shouldn't say this since nobody is mentioning (maybe some voodo that > shouldn't be done), but I was able to use "xfs_repair -fn " I might have > even had the same problem as you, check for the "bad hash table... would rebuild" > subject line from 6/19/01. My system froze a couple of times, filesystems > shutdown, and did other weird things (files disapearing but ls would know about > them), etc. I believe it's something hardware related with me, I haven't had the > time to run it down yet (I ran the memtest86 with no problems, so I'm guessing > maybe a hd issue). When I first installed an XFS kernel, which was out of date and somewhere in the 2.4.2 area, I ran into a similar problem, but the cause was apparently my tcsh shell. That shell does not properly support large files, and the file I was testing was over 16 GB. I could see it with ls, but could not rm it by any means. I had the ability to create a single tar archive file of an entire main partition from ext2, with the output being saved on XFS. XFS supported it, so it was able to create it, but the shell itself did not, and the shell was required to interact with rm, but not tar. catch 22. The particular kernel did have LFS support, but on occasion you will still see individual applications that don't live with it. D. Stimits, stimits@idcomm.com > > "D. Stimits" wrote: > > > > > > > have no idea if normal journaling would have had any problems coping > > with it. Is there no way to run xfs_repair with "no actual modify by -n" > > on a mounted xfs partition, or read-only mounted xfs partition? > > > > D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Tue Jun 26 20:05:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R35uT03836 for linux-xfs-outgoing; Tue, 26 Jun 2001 20:05:56 -0700 Received: from rebel.net.au (IDENT:root@news.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R35sV03833 for ; Tue, 26 Jun 2001 20:05:54 -0700 Received: from rebel.net.au (dialup-5.rebel.net.au [203.20.69.75]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id MAA28999; Wed, 27 Jun 2001 12:35:40 +0930 Message-ID: <3B394D5A.5B245469@rebel.net.au> Date: Wed, 27 Jun 2001 12:34:58 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Dean Brissinger , linux-xfs@oss.sgi.com Subject: Re: To devfs or not to devfs References: <200106261823.f5QINY306518@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yikes! > In theory devfs is a good thing, but a lot of Linux user space is not > ready for it. We will be packaging the 1.0.1 version of xfs with > it turned off - currently debating if it should even be compiled into > the kernel as Redhat has pointed out some problems with devfs to us. > > I would say you can live without it quite nicely, but if you want to do > funky things with device handling and want to be able to read the output > of ls in /dev then try turning it on. I use the RedHat kernel distro. Would it be asking too much to have two ISO's, one with devfs on and the other not? Or perhaps to have an option in anaconda-SGI-MODIFIED that will install a devfs kernel if you check it? After a few teething problems I'm starting to understand devfs and being able to do things like "Oh, it's on bus0/target0" blah is really good when you can't work out what the device is called. (For example, I would really love to have it on my FreeBSD box because I just can't understand what ad1se1 actually means. At least if I had devfs lumbering along I could say something like /dev/ide/bus0/target0/lun0/part1 - it's long winded but it gets there.) DSL -- "And the winner is InUnifiedCanadianAboriginalSyllabics" - Larry Wall et al in Programming Perl From owner-linux-xfs@oss.sgi.com Tue Jun 26 20:12:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R3CSe04128 for linux-xfs-outgoing; Tue, 26 Jun 2001 20:12:28 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R3CRV04125 for ; Tue, 26 Jun 2001 20:12:28 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15F5kK-0002QC-00; Wed, 27 Jun 2001 15:12:04 +1200 Date: Wed, 27 Jun 2001 15:12:04 +1200 (NZST) From: Juha Saarinen To: David Lloyd cc: Steve Lord , Dean Brissinger , "linux-xfs@oss.sgi.com" Subject: Re: To devfs or not to devfs In-Reply-To: <3B394D5A.5B245469@rebel.net.au> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 27 Jun 2001, David Lloyd wrote: > (For example, I would really love to have it on my FreeBSD box because I > just can't understand what ad1se1 actually means. At least if I had > devfs lumbering along I could say something like > /dev/ide/bus0/target0/lun0/part1 - it's long winded but it gets there.) If you got to FreeBSD-CURRENT, I believe they have a devfs working with it. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Tue Jun 26 20:14:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R3EPt04215 for linux-xfs-outgoing; Tue, 26 Jun 2001 20:14:25 -0700 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R3EOV04212 for ; Tue, 26 Jun 2001 20:14:24 -0700 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Jun 2001 22:13:48 -0500 Message-ID: <85063BBE668FD411944400D0B744267A481B26@AUSMAIL> From: "Gonyou, Austin" To: linux-xfs@oss.sgi.com Subject: RE: Installing RH 7.1 XFS from a network using a floppy Date: Tue, 26 Jun 2001 22:13:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-2" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ahh..yes..I did get it working. I just used apache 2.0.19-dev and made my LVM + XFS stripe /web the docroot. It worked like a champ! Thanks for the feedback -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Blizbor (i) [mailto:tb670725@ima.pl] > Sent: Tuesday, June 26, 2001 3:20 PM > To: linux-xfs@oss.sgi.com > Subject: Odp: Installing RH 7.1 XFS from a network using a floppy > > > > ----- Original Message ----- > From: Steve Lord > To: Gonyou, Austin > Cc: > Sent: Monday, June 25, 2001 10:23 PM > Subject: Re: Installing RH 7.1 XFS from a network using a floppy > > > > > Is that possible? Does it work ok with the 1.0 release or > will I have to > do > > > something else? > > > > It works just fine, there are some instructions in the > release notes for > > redhat. I think you have to copy all the cds into a single directory > > structure and nfs export it. You then need the network inst image > bootnet.img > > on a floppy. This is how I do all my installs. > > It's also possible without copying files. > But then you must watch when another CD is required, > then stop ftp daemon, umount CD, mount next, start > ftpdaemon, and again ... stop, umount, mount, start, > and again ... painful but it works. :))) I've tested this. > Starting and stopping ftp daemon doesnt interrupt install > procedure. IMVHO there is a bug in installer, normally > when ftp server cant be contacted some kind of dialog box > should appear.RH installer does nothing but seems hunging > until you switch (in text mode usingalt-F1...alt-F4) to another > console. > > Regards, > Blizbor > From owner-linux-xfs@oss.sgi.com Tue Jun 26 20:28:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R3SVd04414 for linux-xfs-outgoing; Tue, 26 Jun 2001 20:28:31 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R3SVV04411 for ; Tue, 26 Jun 2001 20:28:31 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA01162 for ; Tue, 26 Jun 2001 20:28:24 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) 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 NAA11868; Wed, 27 Jun 2001 13:27:04 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: David Lloyd cc: linux-xfs@oss.sgi.com Subject: Re: To devfs or not to devfs In-reply-to: Your message of "Wed, 27 Jun 2001 12:34:58 +0930." <3B394D5A.5B245469@rebel.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Jun 2001 13:27:04 +1000 Message-ID: <17376.993612424@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 27 Jun 2001 12:34:58 +0930, David Lloyd wrote: >I use the RedHat kernel distro. Would it be asking too much to have two >ISO's, one with devfs on and the other not? Just boot with "devfs=nomount". No need for two images. From owner-linux-xfs@oss.sgi.com Tue Jun 26 20:44:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R3iOr04682 for linux-xfs-outgoing; Tue, 26 Jun 2001 20:44:24 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R3iMV04679 for ; Tue, 26 Jun 2001 20:44:22 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id FAA310226 for ; Wed, 27 Jun 2001 05:44:19 +0200 (CEST) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA43895; Wed, 27 Jun 2001 13:43:01 +1000 (EST) Date: Wed, 27 Jun 2001 13:43:01 +1000 From: Timothy Shimmin To: Joshua Baker-LePain Cc: "Gonyou, Austin" , linux-xfs@oss.sgi.com Subject: Re: XFSDUMP and multiple filesystems on one tape Message-ID: <20010627134300.X280523@boing.melbourne.sgi.com> References: <85063BBE668FD411944400D0B744267A481B0B@AUSMAIL> <200106261923.f5QJNX307690@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200106261923.f5QJNX307690@jen.americas.sgi.com>; from lord@sgi.com on Tue, Jun 26, 2001 at 02:23:33PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, xfsdump really seems to be written with having tapes with only xfs dumps on them. It will actually do a rewind to the start and read the xfsdump header info. If it can't decipher the header then you're stuffed. However, there is a -o option which will allow the non-xfsdump data to be overwritten (-F will suppress the confirmation prompt). This option actually stops xfsdump from trying to read the header. This will allow one (as Joshua suggested) to fsf to the appropriate position and then do the xfsdump to the non-rewinding device. One can then (as Joshua suggested) fsf to the correct position on the non-rewinding device and do an xfsrestore. I have tried this out successfully on IRIX. However, you can't put say and do a restore with a session label in the 2nd dump and expect xfsrestore to skip over the intervening files. However, you could "mt fsf" to the start of the 2nd xfs-dump and restore it. I haven't tried this out on the Linux version. --Tim On Tue, Jun 26, 2001 at 03:11:37PM -0400, Joshua Baker-LePain wrote: > On Tue, 26 Jun 2001 at 2:04pm, Gonyou, Austin wrote > > > Is that possible? I didn't see any syntax which showed it was. Any ideas on > > how to do this would be helpful, or else I guess it's back to tar for me. :) > > > Just xfsdump to /dev/nst0 (or whatever non-rewinding tape device you want > to use). When one filesystem is done, do the next. > > When the time comes to restore 'mt fsf' to the appropriate filemark and > then start up xfsrestore. > > Or am I missing something? > > -- > Joshua Baker-LePain > Department of Biomedical Engineering > Duke University > From owner-linux-xfs@oss.sgi.com Tue Jun 26 21:00:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R40bD05036 for linux-xfs-outgoing; Tue, 26 Jun 2001 21:00:37 -0700 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R40aV05032 for ; Tue, 26 Jun 2001 21:00:36 -0700 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Jun 2001 22:59:59 -0500 Message-ID: <85063BBE668FD411944400D0B744267A481B27@AUSMAIL> From: "Gonyou, Austin" To: "'Timothy Shimmin'" , Joshua Baker-LePain Cc: "Gonyou, Austin" , linux-xfs@oss.sgi.com Subject: RE: XFSDUMP and multiple filesystems on one tape Date: Tue, 26 Jun 2001 22:59:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well, my problem reall is that I just want to know how to do multiple xfs filesystems dumped to one tape, utilizing xfsdump. I don't want to overwrite one dump with another. Here is what I'm talking about for example 1. Put a brand new blank tape into the drive 2. xfsdump -f /dev/st0 / 3. 4. xfsdump -f /dev/st0 /usr 5. 6. xfsdump -f /dev/st0 /home 7. etc... Will those actions yield a tape which only has the last dump on it, or will it seek to the end of the last dump, and then start writing? If it does do that, then I'm set. As I'm led to believe that it does from Steve Lord's previous post. I just didn't see that behaviour with dump I don't think, so I'm just skeptical without getting it substantiated first. Thanks for the feedback. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Timothy Shimmin [mailto:tes@boing.melbourne.sgi.com] > Sent: Tuesday, June 26, 2001 10:43 PM > To: Joshua Baker-LePain > Cc: Gonyou, Austin; linux-xfs@oss.sgi.com > Subject: Re: XFSDUMP and multiple filesystems on one tape > > > Hi, > > xfsdump really seems to be written with having tapes with > only xfs dumps on them. > It will actually do a rewind to the start and read the xfsdump > header info. If it can't decipher the header then you're stuffed. > > However, > there is a -o option which will allow the non-xfsdump data > to be overwritten (-F will suppress the confirmation prompt). > This option actually stops xfsdump from trying to read the header. > This will allow one (as Joshua suggested) to fsf to the appropriate > position and then do the xfsdump to the non-rewinding device. > One can then (as Joshua suggested) fsf to the correct position > on the non-rewinding device and do an xfsrestore. > I have tried this out successfully on IRIX. > > However, you can't put say > and do a restore with > a session label in the 2nd dump and expect xfsrestore to skip > over the intervening files. However, you could "mt fsf" to > the start of the 2nd xfs-dump and restore it. > > I haven't tried this out on the Linux version. > > --Tim > > On Tue, Jun 26, 2001 at 03:11:37PM -0400, Joshua Baker-LePain wrote: > > On Tue, 26 Jun 2001 at 2:04pm, Gonyou, Austin wrote > > > > > Is that possible? I didn't see any syntax which showed it > was. Any ideas on > > > how to do this would be helpful, or else I guess it's > back to tar for me. :) > > > > > Just xfsdump to /dev/nst0 (or whatever non-rewinding tape > device you want > > to use). When one filesystem is done, do the next. > > > > When the time comes to restore 'mt fsf' to the appropriate > filemark and > > then start up xfsrestore. > > > > Or am I missing something? > > > > -- > > Joshua Baker-LePain > > Department of Biomedical Engineering > > Duke University > > > From owner-linux-xfs@oss.sgi.com Tue Jun 26 21:18:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R4IlA05404 for linux-xfs-outgoing; Tue, 26 Jun 2001 21:18:47 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R4IkV05401 for ; Tue, 26 Jun 2001 21:18:46 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA08365 for ; Tue, 26 Jun 2001 21:18:40 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id VAA46197 for ; Tue, 26 Jun 2001 21:18:13 -0700 (PDT) Message-ID: <3B395DED.FDFC6C3D@sgi.com> Date: Tue, 26 Jun 2001 23:15:41 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: To devfs or not to devfs References: <17376.993612424@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > > On Wed, 27 Jun 2001 12:34:58 +0930, > David Lloyd wrote: > >I use the RedHat kernel distro. Would it be asking too much to have two > >ISO's, one with devfs on and the other not? > > Just boot with "devfs=nomount". No need for two images. Although... Red Hat tells us that there are race conditions and root exploits when using devfs, even if it is not mounted. I have not investigated this.... but I'm more and more inclined to just ship the new RPMs with no devfs at all, and let the power-users who want the cutting edge devfs stuff recompile their kernel... And yes, 2 isos just for devfs options is too much to ask for. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Jun 26 22:04:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R548805961 for linux-xfs-outgoing; Tue, 26 Jun 2001 22:04:08 -0700 Received: from roujin.gargoylecc.com (roujin.gargoylecc.com [65.100.85.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R546V05958 for ; Tue, 26 Jun 2001 22:04:06 -0700 Received: from roujin.gargoylecc.com ([65.100.85.34] ident=ringram) by roujin.gargoylecc.com with esmtp (Exim 3.13 #1) id 15F8Rz-0000L1-00; Wed, 27 Jun 2001 00:05:19 -0600 Date: Wed, 27 Jun 2001 00:05:12 -0600 (MDT) From: Russel Ingram To: "Gonyou, Austin" cc: "'Timothy Shimmin'" , Joshua Baker-LePain , Subject: RE: XFSDUMP and multiple filesystems on one tape In-Reply-To: <85063BBE668FD411944400D0B744267A481B27@AUSMAIL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 26 Jun 2001, Gonyou, Austin wrote: > Well, my problem reall is that I just want to know how to do multiple xfs > filesystems dumped to one tape, utilizing xfsdump. I don't want to overwrite > one dump with another. Here is what I'm talking about for example > > 1. Put a brand new blank tape into the drive > 2. xfsdump -f /dev/st0 / > 3. > 4. xfsdump -f /dev/st0 /usr > 5. > 6. xfsdump -f /dev/st0 /home > 7. > etc... > Will those actions yield a tape which only has the last dump on it, or will > it seek to the end of the last dump, and then start writing? If it does do > that, then I'm set. As I'm led to believe that it does from Steve Lord's > previous post. I just didn't see that behaviour with dump I don't think, so > I'm just skeptical without getting it substantiated first. Thanks for the > feedback. Doing it with that particular device will result in several dumps that overwrite each other (I'm pretty sure). To be sure to avoid overwriting individual dumps use the non-rewinding device: 1. Put a brand new blank tape into the drive 2. xfsdump -f /dev/nst0 / 3. 4. xfsdump -f /dev/nst0 /usr 5. 6. xfsdump -f /dev/nst0 /home 7. This is how I do my xfsdump backups on my Irix servers and it works perfectly. If you would like to see a scripted version of this in action let me know and I'll post my backup scripts. Now, since I just finally got a tape drive working on my Linux system with XFS, I have a quick question for the xfsdump folks. xfsdump on Irix gives sort of a progress report with percent of job done. Is there a reason this is no in the Linux version? -- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Tue Jun 26 22:27:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R5RVm06207 for linux-xfs-outgoing; Tue, 26 Jun 2001 22:27:31 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R5RUV06204 for ; Tue, 26 Jun 2001 22:27:30 -0700 Received: from fuzzy.melbourne.sgi.com (fuzzy.melbourne.sgi.com [134.14.55.199]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id WAA01639 for ; Tue, 26 Jun 2001 22:27:29 -0700 (PDT) mail_from (fsgqa@fuzzy.melbourne.sgi.com) Received: (from fsgqa@localhost) by fuzzy.melbourne.sgi.com (8.9.3/8.9.3) id PAA21614 for linux-xfs@oss.sgi.com; Wed, 27 Jun 2001 15:42:43 +1000 Date: Wed, 27 Jun 2001 15:42:43 +1000 From: FSG QA Account Message-Id: <200106270542.PAA21614@fuzzy.melbourne.sgi.com> Subject: TAKE - auto-qa (heads up for auto-qa users) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jun 26 22:26:13 PDT 2001 Workarea: fuzzy.melbourne.sgi.com:/home/fsgqa/isms/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:97719a cmd/xfstests/tools/auto-qa - 1.16 - auto-detect kernel version. install to /boot/vmlinuz-xfs-qa and /lib/modules/2.4.6-xfs-qa to avoid playing version number catch-up From owner-linux-xfs@oss.sgi.com Tue Jun 26 22:28:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R5SmR06282 for linux-xfs-outgoing; Tue, 26 Jun 2001 22:28:48 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R5SlV06279 for ; Tue, 26 Jun 2001 22:28:47 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id WAA19336 for ; Tue, 26 Jun 2001 22:28:41 -0700 (PDT) mail_from (ivanr@melbourne.sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA12578; Wed, 27 Jun 2001 15:27:29 +1000 From: ivanr@melbourne.sgi.com (Ivan Rayner) Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id PAA40073; Wed, 27 Jun 2001 15:27:29 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Wed, 27 Jun 2001 15:27:29 +1000 To: Russel Ingram cc: "Gonyou, Austin" , Joshua Baker-LePain , Subject: RE: XFSDUMP and multiple filesystems on one tape In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 27 Jun 2001, Russel Ingram wrote: > On Tue, 26 Jun 2001, Gonyou, Austin wrote: > > Will those actions yield a tape which only has the last dump on it, or will > > it seek to the end of the last dump, and then start writing? If it does do > > that, then I'm set. As I'm led to believe that it does from Steve Lord's > > previous post. I just didn't see that behaviour with dump I don't think, so > > I'm just skeptical without getting it substantiated first. Thanks for the > > feedback. > > Doing it with that particular device will result in several dumps that > overwrite each other (I'm pretty sure). To be sure to avoid overwriting > individual dumps use the non-rewinding device: xfsdump will actually skip over dumps that may already exist on the tape. The way it works is that it will read the tape and if it finds a dump, it will skip past it and then do another read. It will fail if it finds something that is not a dump otherwise it will write after all the other dumps. Specifying '-o' (overwrite) disables this behaviour, causing xfsdump to just write wherever the tape is positioned. (If you find that xfsdump doesn't behave as advertised, please let us know.) > Now, since I just finally got a tape drive working on my Linux system with > XFS, I have a quick question for the xfsdump folks. xfsdump on Irix gives > sort of a progress report with percent of job done. Is there a reason > this is no in the Linux version? xfsdump on linux does not include threading, ie. it runs in a single thread. Progress reporting is a feature of xfsdump's multi-threaded mode. The reason the Linux version is single threaded is simply that I was moved onto other things before I finished the port. The only real functionality lost is the ability to write several tapes at once and it was felt that this probably wouldn't be a big issue for the Linux folk at the moment. Ivan -- Ivan Rayner ivanr@melbourne.sgi.com From owner-linux-xfs@oss.sgi.com Tue Jun 26 22:31:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R5VFJ06429 for linux-xfs-outgoing; Tue, 26 Jun 2001 22:31:15 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R5VFV06426 for ; Tue, 26 Jun 2001 22:31:15 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA19743 for ; Tue, 26 Jun 2001 22:31:08 -0700 (PDT) mail_from (alane@geeksrus.net) Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5R5EB920297 for linux-xfs@oss.sgi.com; Wed, 27 Jun 2001 01:14:11 -0400 Date: Wed, 27 Jun 2001 01:14:11 -0400 From: Alan Eldridge To: linux-xfs@oss.sgi.com Subject: Re: To devfs or not to devfs Message-ID: <20010627011411.A17429@wwweasel.geeksrus.net> References: <17376.993612424@kao2.melbourne.sgi.com> <3B395DED.FDFC6C3D@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B395DED.FDFC6C3D@sgi.com>; from sandeen@sgi.com on Tue, Jun 26, 2001 at 11:15:41PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jun 26, 2001 at 11:15:41PM -0500, Eric Sandeen wrote: >Keith Owens wrote: >> >> On Wed, 27 Jun 2001 12:34:58 +0930, >> David Lloyd wrote: >> >I use the RedHat kernel distro. Would it be asking too much to have two >> >ISO's, one with devfs on and the other not? >> >> Just boot with "devfs=nomount". No need for two images. > >Although... Red Hat tells us that there are race conditions and root >exploits when using devfs, even if it is not mounted. I have not >investigated this.... but I'm more and more inclined to just ship the >new RPMs with no devfs at all, and let the power-users who want the >cutting edge devfs stuff recompile their kernel... Eric, Could you point to the source of RH's warnings about devfs? I'd like to read what they've got to say about it. -- Alan Eldridge "Smart Tags? We don't need no steenking Smart Tags!" From owner-linux-xfs@oss.sgi.com Tue Jun 26 23:40:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R6eN607481 for linux-xfs-outgoing; Tue, 26 Jun 2001 23:40:23 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R6eLV07478 for ; Tue, 26 Jun 2001 23:40:21 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA20338; Wed, 27 Jun 2001 08:40:16 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA03703; Wed, 27 Jun 2001 08:40:15 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 03DCD57306; Wed, 27 Jun 2001 08:48:39 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 8FDD925835; Wed, 27 Jun 2001 08:56:51 +0200 (CEST) Message-ID: <3B3980C5.CA14733E@ch.sauter-bc.com> Date: Wed, 27 Jun 2001 08:44:21 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Eric Sandeen Cc: linux-xfs Subject: Re: fatal error -- couldn't initialize XFS library References: <3B38DE54.37037A97@idcomm.com> <3B38DE20.C0BBE53A@sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen schrieb: > > "D. Stimits" wrote: > > > I noticed one other thing during the process that is definitely a bug, > > but not necessarily xfs...it could be a mount bug. While in single user > > mode, after remounting the partition read-only, it was falsely listed as > > read/write when the mount command was run to see current mounts. I know > > it was incorrect becase I tried intentionally to write to a file as a > > test, and it correctly told me the file could not be saved because the > > partition was read-only. > > I've seen this before... I think it's a result of /etc/mtab not being > updated before the / partition is made read-only. (ext2 root does this > for me, too, at least on RH7.1) Try cat /proc/mounts and see what you > get - it should say "ro". > > -Eric Even worse, when you expext the mount command really shows what and how it is mounted. Not so, try booting with something like 'linux init=/bin/sh' and check with mount, it will falsely tell you / is mounted rw. Of course mount can not read from /proc/mounts cos it is not mounted already. Simon From owner-linux-xfs@oss.sgi.com Tue Jun 26 23:54:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R6sdV07739 for linux-xfs-outgoing; Tue, 26 Jun 2001 23:54:39 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R6sdV07736 for ; Tue, 26 Jun 2001 23:54:39 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA09528 for ; Tue, 26 Jun 2001 23:51:49 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id QAA23673; Wed, 27 Jun 2001 16:54:36 +1000 Date: Wed, 27 Jun 2001 16:54:36 +1000 From: Keith Owens Message-Id: <200106270654.QAA23673@sherman.melbourne.sgi.com> Subject: TAKE - Adjust position of CONFIG_XFS_RT in config.in Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk For the purposes of splitting XFS into core, kernel and acl code, it is easier when CONFIG_XFS_RT is directly under CONFIG_FS_XFS. Moving the line makes no difference to the build process. Date: Tue Jun 26 23:52:23 PDT 2001 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:97721a linux/fs/Config.in - 1.63 From owner-linux-xfs@oss.sgi.com Tue Jun 26 23:59:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R6xjw07881 for linux-xfs-outgoing; Tue, 26 Jun 2001 23:59:45 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R6xiV07878 for ; Tue, 26 Jun 2001 23:59:44 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id XAA02403 for ; Tue, 26 Jun 2001 23:59:37 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA74655; Wed, 27 Jun 2001 16:58:24 +1000 (EST) Date: Wed, 27 Jun 2001 16:58:24 +1000 From: Timothy Shimmin To: Ivan Rayner Cc: Russel Ingram , "Gonyou, Austin" , Joshua Baker-LePain , linux-xfs@oss.sgi.com Subject: Re: XFSDUMP and multiple filesystems on one tape Message-ID: <20010627165824.Y280523@boing.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from ivanr@melbourne.sgi.com on Wed, Jun 27, 2001 at 03:27:29PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Jun 27, 2001 at 03:27:29PM +1000, Ivan Rayner wrote: > On Wed, 27 Jun 2001, Russel Ingram wrote: > > > On Tue, 26 Jun 2001, Gonyou, Austin wrote: > > > Will those actions yield a tape which only has the last dump on it, or will > > > it seek to the end of the last dump, and then start writing? If it does do > > > that, then I'm set. As I'm led to believe that it does from Steve Lord's > > > previous post. I just didn't see that behaviour with dump I don't think, so > > > I'm just skeptical without getting it substantiated first. Thanks for the > > > feedback. > > > > Doing it with that particular device will result in several dumps that > > overwrite each other (I'm pretty sure). To be sure to avoid overwriting > > individual dumps use the non-rewinding device: > > xfsdump will actually skip over dumps that may already exist on the tape. > The way it works is that it will read the tape and if it finds a dump, it > will skip past it and then do another read. It will fail if it finds > something that is not a dump otherwise it will write after all the other > dumps. > So, in other words, you don't need to use the non-rewinding device :) An xfsdump to tape consists of a number of tape files, and the final file is a terminator file. When you go to dump to a tape which already has dump sessions on it, it rewinds to the start, and if the header looks good, then it searches through the tape for this terminator file. It then overwrites this terminator and places one at the end when it finishes dumping the data. > Specifying '-o' (overwrite) disables this behaviour, causing xfsdump to > just write wherever the tape is positioned. > > (If you find that xfsdump doesn't behave as advertised, please let us > know.) > > > Now, since I just finally got a tape drive working on my Linux system with > > XFS, I have a quick question for the xfsdump folks. xfsdump on Irix gives > > sort of a progress report with percent of job done. Is there a reason > > this is no in the Linux version? > > xfsdump on linux does not include threading, ie. it runs in a single > thread. Progress reporting is a feature of xfsdump's multi-threaded mode. > The reason the Linux version is single threaded is simply that I was moved > onto other things before I finished the port. The only real functionality > lost is the ability to write several tapes at once and it was felt that > this probably wouldn't be a big issue for the Linux folk at the moment. > Have you tried the -p option ? Cheers, Tim. From owner-linux-xfs@oss.sgi.com Wed Jun 27 00:34:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R7YRW08417 for linux-xfs-outgoing; Wed, 27 Jun 2001 00:34:27 -0700 Received: from mx.linux.net.cn ([210.82.190.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R7YOV08414 for ; Wed, 27 Jun 2001 00:34:25 -0700 Received: from dfbbb.cn.mvd (unknown [211.99.247.66]) by mx.linux.net.cn (Postfix) with ESMTP id 2E370C16 for ; Wed, 27 Jun 2001 15:33:15 +0800 (CST) Received: (from dfbb@localhost) by dfbbb.cn.mvd (8.11.2/8.11.2) id f5R7YX005817 for linux-xfs@oss.sgi.com; Wed, 27 Jun 2001 15:34:33 +0800 Date: Wed, 27 Jun 2001 15:34:33 +0800 From: Fang Han To: linux-xfs@oss.sgi.com Subject: Re: TAKE - merge up to 2.4.6-pre5 Message-ID: <20010627153433.C1417@dfbbb.cn.mvd> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200106211552.f5LFqek13793@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106211552.f5LFqek13793@jen.americas.sgi.com>; from lord@sgi.com on Thu, Jun 21, 2001 at 10:52:40AM -0500 Organization: None X-Attribution: dfbb Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Lord: Three files of linux-2.4.6-pre5 are missed drivers/char/defkeymap.c drivers/scsi/aic7xxx/aic7xxx_reg.h drivers/scsi/aic7xxx/aic7xxx_seq.h Regards dfbb From owner-linux-xfs@oss.sgi.com Wed Jun 27 01:39:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R8duU09341 for linux-xfs-outgoing; Wed, 27 Jun 2001 01:39:56 -0700 Received: from smtp1.hk.outblaze.com (smtp1.hk.outblaze.com [202.77.223.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R8dsV09338 for ; Wed, 27 Jun 2001 01:39:54 -0700 Received: (qmail 13785 invoked from network); 27 Jun 2001 06:15:42 -0000 Received: from unknown (HELO yusufg.portal2.com) (202.77.181.217) by smtp1.hk.outblaze.com with SMTP; 27 Jun 2001 06:15:42 -0000 Received: (qmail 23349 invoked by uid 500); 27 Jun 2001 06:22:03 -0000 Date: 27 Jun 2001 06:22:03 -0000 Message-ID: <20010627062203.23348.qmail@yusufg.portal2.com> From: Yusuf Goolamabbas To: linux-xfs@oss.sgi.com Subject: make install failures whilst installing XFS over 2.4.5 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I usually install a linux kernel by the following mechanism untar in appropiate place, rename linux directory to linux-. Make a sym link from /usr/src/linux to that dir. cd to /usr/src/linux make menuconfig ; make dep;make clean ; make bzImage ; make modules ; make modules_install ; Edit /etc/lilo.conf to add a new stanza for this kernel Then type make install This has worked for a long time for me with stock kernels, linus pre kernels and ac kernels When I tried the same with 2.4.5 and the XFS patches with the following lilo.conf boot=/dev/sda map=/boot/map install=/boot/boot.b prompt timeout=50 message=/boot/message linear #default=linux image=/boot/vmlinuz-2.4.5-xfs label=new read-only root=/dev/sda8 append="ramdisk_size=2500" image=/boot/vmlinuz-2.4.2-SGI_XFS_1.0 label=linux initrd=/boot/initrd-2.4.2-SGI_XFS_1.0.img read-only root=/dev/sda8 append="ramdisk_size=2500" I got this error when I did make install objcopy -O binary -R .note -R .comment -S compressed/bvmlinux compressed/bvmlinux.out tools/build -b bbootsect bsetup compressed/bvmlinux.out CURRENT > bzImage Root device is (8, 8) Boot sector 512 bytes. Setup is 2400 bytes. System is 974 kB sh -x ./install.sh 2.4.5-xfs bzImage /usr/src/linux-2.4.5/System.map "" + '[' -x /sbin/installkernel ']' + '[' -f /vmlinuz ']' + mv /vmlinuz /vmlinuz.old + '[' -f /System.map ']' + mv /System.map /System.old + cat bzImage + cp /usr/src/linux-2.4.5/System.map /System.map + '[' -x /sbin/lilo ']' + /sbin/lilo Fatal: open /boot/vmlinuz-2.4.5-xfs: No such file or directory make[1]: *** [install] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4.5/arch/i386/boot' make: *** [install] Error 2 I reinstalled stock RH 7.1 and did a plain 2.4.5 upgrade with the above mechanism [changing the image line to /boot/vmlinuz-2.4.5] and it works perfectly. I can ofcourse copy the image and system map from the kernel source dir to the right places and run lilo by hand but I am surprised as to why the usual "make install" mechanisms breaks. Maybe I am doing kernel builds incorrectly. I can't remember when I started doing it this way or if this is the correct way Any insight would be appreciated Regards, Yusuf -- Yusuf Goolamabbas yusufg@outblaze.com From owner-linux-xfs@oss.sgi.com Wed Jun 27 01:47:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R8laa09502 for linux-xfs-outgoing; Wed, 27 Jun 2001 01:47:36 -0700 Received: from mail.cc.kuleuven.ac.be (mail.cc.kuleuven.ac.be [134.58.10.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R8lYV09499 for ; Wed, 27 Jun 2001 01:47:35 -0700 Received: from kc.kuleuven.ac.be (isdn-050.dial.kulnet.kuleuven.ac.be [134.58.220.113]) by mail.cc.kuleuven.ac.be (8.9.3/8.9.0) with ESMTP id KAA996634 for ; Wed, 27 Jun 2001 10:47:32 +0200 Message-ID: <3B399DD5.456672E2@kc.kuleuven.ac.be> Date: Wed, 27 Jun 2001 10:48:21 +0200 From: Hubert Christiaen X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XLS and SuSE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dear Sir, Do you have any knowledge of compatibility problems of XFS and SuSE Linux? Sincerely, Hubert -- H. Christiaen Katholieke Universiteit Leuven Kandidatuurcentrum Tel.: + 32 (0)16 327075 Celestijnenlaan 200A Fax : + 32 (0)16 327997 B-3001 Heverlee Hubert.Christiaen@kc.kuleuven.ac.be Belgium http://www.kuleuven.ac.be/~hchrist/ ESP projects : http://www.kc.kuleuven.ac.be/esp/ From owner-linux-xfs@oss.sgi.com Wed Jun 27 02:23:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5R9NnD10093 for linux-xfs-outgoing; Wed, 27 Jun 2001 02:23:49 -0700 Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5R9NmV10090 for ; Wed, 27 Jun 2001 02:23:48 -0700 Received: from vimfuego.saarinen.org ([192.168.1.1]) by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack)) id 15FBXx-0002cJ-00; Wed, 27 Jun 2001 21:23:41 +1200 Date: Wed, 27 Jun 2001 21:23:41 +1200 (NZST) From: Juha Saarinen To: Yusuf Goolamabbas cc: "linux-xfs@oss.sgi.com" Subject: Re: make install failures whilst installing XFS over 2.4.5 In-Reply-To: <20010627062203.23348.qmail@yusufg.portal2.com> Message-ID: X-S: Always MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 27 Jun 2001, Yusuf Goolamabbas wrote: > Edit /etc/lilo.conf to add a new stanza for this kernel > > Then type make install Editing lilo.conf is redundant -- the 'make install' target does that for you, AFAICT. > Fatal: open /boot/vmlinuz-2.4.5-xfs: No such file or directory > make[1]: *** [install] Error 1 > make[1]: Leaving directory `/usr/src/linux-2.4.5/arch/i386/boot' > make: *** [install] Error 2 > > I reinstalled stock RH 7.1 and did a plain 2.4.5 upgrade with the > above mechanism [changing the image line to /boot/vmlinuz-2.4.5] and > it works perfectly. > > I can ofcourse copy the image and system map from the kernel source > dir to the right places and run lilo by hand but I am surprised as to > why the usual "make install" mechanisms breaks. Maybe I am doing > kernel builds incorrectly. I can't remember when I started doing it > this way or if this is the correct way > > Any insight would be appreciated Edit the top-level Makefile, and uncomment: #export INSTALL_PATH=/boot ? -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 From owner-linux-xfs@oss.sgi.com Wed Jun 27 03:11:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RABx710847 for linux-xfs-outgoing; Wed, 27 Jun 2001 03:11:59 -0700 Received: from dmz.tecosim.de ([194.24.222.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RABtV10844 for ; Wed, 27 Jun 2001 03:11:57 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f5RA0nJ04209; Wed, 27 Jun 2001 12:00:49 +0200 Received: from ns.tecosim.de(194.24.222.9) via SMTP by dmz.tecosim.de, id smtpdIRzsOA; Wed Jun 27 12:00:47 2001 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with ESMTP id f5RAABi04234; Wed, 27 Jun 2001 12:10:11 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f5RAABv02831; Wed, 27 Jun 2001 12:10:11 +0200 Date: Wed, 27 Jun 2001 12:10:11 +0200 From: Utz Lehmann To: Hubert Christiaen Cc: linux-xfs@oss.sgi.com Subject: Re: XLS and SuSE Message-ID: <20010627121011.B1143@de.tecosim.com> References: <3B399DD5.456672E2@kc.kuleuven.ac.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B399DD5.456672E2@kc.kuleuven.ac.be>; from Hubert.Christiaen@kc.kuleuven.ac.be on Wed, Jun 27, 2001 at 10:48:21AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Hubert Christiaen [Hubert.Christiaen@kc.kuleuven.ac.be] wrote: > Dear Sir, > > Do you have any knowledge of compatibility problems of XFS and SuSE Linux? I have running some SuSE Linux 7.0 and 7.1 Boxes with XFS here at work. No Problems. But you should use egcs-2.91.66 to compile the kernel. It's more stable than the SuSE gcc-2.95.2 for this. You can just install the Redhat 7.0 kgcc rpm (= egcs-2.91.66) on SuSE 7.0/7.1 and changing the kernel Makefile to use kgcc. ftp://ftp.redhat.com/redhat/linux/7.0/en/os/i386/RedHat/RPMS/kgcc-1.1.2-40.i386.rpm utz From owner-linux-xfs@oss.sgi.com Wed Jun 27 07:03:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RE3ri14331 for linux-xfs-outgoing; Wed, 27 Jun 2001 07:03:53 -0700 Received: from exocore.com ([203.200.0.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RE3nV14326 for ; Wed, 27 Jun 2001 07:03:50 -0700 Received: (from shanu@localhost) by exocore.com (8.11.2/8.8.7) id f5RE3iW03922 for linux-xfs@oss.sgi.com; Wed, 27 Jun 2001 19:33:44 +0530 Date: Wed, 27 Jun 2001 19:33:44 +0530 From: Shanker Balan To: Linux-XFS Subject: ACL for Linux OS Message-ID: <20010627193344.A3778@exocore.com> Reply-To: Shanker Balan Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organisation: Exocore Consulting (P) Ltd Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello: I just got down the RHL 7.1 XFS installer and converted one of my machines to XFS yday to run Samba 2_2 CVS with ACL support. The Samba + ACL part is working fine now. I am however quite unclear about the POSIX ACL part for the OS i am running - Linux. What do i have to do further to get the extended attributes working for Linux like its mentioned here http://acl.bestbits.at/about.html. Since i already have a file-system which is ACL capable, what is the next step i have to take to get Linux ACL in place. Any help appreciated! -- Shanu - - - - - - - - - - - ( Shanu ) - - Shanker Balan http://people.exocore.com/shanu shanu at exocore dot com From owner-linux-xfs@oss.sgi.com Wed Jun 27 08:17:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RFHnR15847 for linux-xfs-outgoing; Wed, 27 Jun 2001 08:17:49 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RFHlV15844 for ; Wed, 27 Jun 2001 08:17:47 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA02018 for ; Wed, 27 Jun 2001 08:14:58 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2275240; Wed, 27 Jun 2001 10:16:30 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA45882; Wed, 27 Jun 2001 10:16:29 -0500 (CDT) Message-ID: <3B39F42F.3AA6E9C6@sgi.com> Date: Wed, 27 Jun 2001 09:56:48 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Fang Han CC: linux-xfs@oss.sgi.com Subject: Re: TAKE - merge up to 2.4.6-pre5 References: <200106211552.f5LFqek13793@jen.americas.sgi.com> <20010627153433.C1417@dfbbb.cn.mvd> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Fang Han wrote: > Three files of linux-2.4.6-pre5 are missed > > drivers/char/defkeymap.c > drivers/scsi/aic7xxx/aic7xxx_reg.h > drivers/scsi/aic7xxx/aic7xxx_seq.h I think these were left out on purpose, because those files are generated. However, it takes a few extra tools to generate the aic7xxx headers, so I think we'll probably get those checked in anyway. In the meantime, just enable CONFIG_AIC7XXX_BUILD_FIRMWARE in your .config. -Eric From owner-linux-xfs@oss.sgi.com Wed Jun 27 08:19:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RFJ1A15909 for linux-xfs-outgoing; Wed, 27 Jun 2001 08:19:01 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RFJ1V15905 for ; Wed, 27 Jun 2001 08:19:01 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA02282 for ; Wed, 27 Jun 2001 08:16:12 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2276803; Wed, 27 Jun 2001 10:17:44 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA69622; Wed, 27 Jun 2001 10:17:44 -0500 (CDT) Message-ID: <3B39F478.77AEA2B@sgi.com> Date: Wed, 27 Jun 2001 09:58:00 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Alan Eldridge CC: linux-xfs@oss.sgi.com Subject: Re: To devfs or not to devfs References: <17376.993612424@kao2.melbourne.sgi.com> <3B395DED.FDFC6C3D@sgi.com> <20010627011411.A17429@wwweasel.geeksrus.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alan Eldridge wrote: > Eric, > > Could you point to the source of RH's warnings about devfs? I'd like to read > what they've got to say about it. It was in a private email, but searches on google and red hat's bugzilla haven't turned anything up - I'll follow up to see if I can get more information. I really do like devfs, and the concept behind it is great - I just don't know how much more effort the SGI XFS team can spend on helping it get accepted. :) -Eric From owner-linux-xfs@oss.sgi.com Wed Jun 27 10:02:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RH29c17476 for linux-xfs-outgoing; Wed, 27 Jun 2001 10:02:09 -0700 Received: from proxy.sycor.de ([194.31.241.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RH27V17471 for ; Wed, 27 Jun 2001 10:02:07 -0700 Received: from dsdegoe1.goe1.sycor.de ([192.168.40.10]) by proxy.sycor.de (8.9.3/8.8.7) with ESMTP id SAA29156 for ; Wed, 27 Jun 2001 18:04:12 +0200 From: Michael.Kunze@sycor.de Received: by dsdegoe1 with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Jun 2001 19:01:19 +0200 Message-ID: To: linux-xfs@oss.sgi.com Subject: xfs installer Date: Wed, 27 Jun 2001 19:01:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! Will an xfs installation will be supported in future standard Red Hat Linux CD (without an extra XFS CD)?. Best regards, Michael ------------------------------------------------------------------------ Michael "Mikel" Kunze, Tel: +49 551/490-0 Unix Systems and Networking FAX: +49 551/490-2000 SYCOR AG Heinrich-von-Stephan Str.1-5 37073 Goettingen Germany E-Mail: mailto:michael.kunze@sycor.de WWW: http://www.sycor.ag ------------------------------------------------------------------------ If a train station is where the train stops, what is a workstation? From owner-linux-xfs@oss.sgi.com Wed Jun 27 10:11:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RHBeA17679 for linux-xfs-outgoing; Wed, 27 Jun 2001 10:11:40 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RHBaV17676 for ; Wed, 27 Jun 2001 10:11:36 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA362665 for ; Wed, 27 Jun 2001 19:11:31 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2278521; Wed, 27 Jun 2001 12:10:09 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA76813; Wed, 27 Jun 2001 12:10:08 -0500 (CDT) Message-ID: <3B3A0ECC.54438F2B@sgi.com> Date: Wed, 27 Jun 2001 11:50:20 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael.Kunze@sycor.de CC: linux-xfs@oss.sgi.com Subject: Re: xfs installer References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Michael.Kunze@sycor.de wrote: > Will an xfs installation will be supported in future standard Red Hat Linux > CD (without an extra > XFS CD)?. That's really up to Red Hat, and partly up to Linus - Red Hat may be more likely to support it if it's in Linus' tree. And before you ask, see the FAQ about getting into Linus' tree. :) -Eric From owner-linux-xfs@oss.sgi.com Wed Jun 27 11:51:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RIptp27888 for linux-xfs-outgoing; Wed, 27 Jun 2001 11:51:55 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RIpsV27883 for ; Wed, 27 Jun 2001 11:51:54 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip80.idcomm.com [209.60.72.207] (may be forged)) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5RIrEl20701 for ; Wed, 27 Jun 2001 12:53:14 -0600 Message-ID: <3B3A2BB4.A8CF0D10@idcomm.com> Date: Wed, 27 Jun 2001 12:53:40 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: make install failures whilst installing XFS over 2.4.5 References: <20010627062203.23348.qmail@yusufg.portal2.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yusuf Goolamabbas wrote: > > I usually install a linux kernel by the following mechanism > > untar in appropiate place, rename linux directory to linux-. Make > a sym link from /usr/src/linux to that dir. cd to /usr/src/linux > make menuconfig ; make dep;make clean ; make bzImage ; make modules ; > make modules_install ; Did you actually copy bzImage to /boot/vmlinuz-2.4.2-SGI_XFS_1.0? It is a silly thing to ask, it sounds like the filesystem didn't see it, but first its good to know for sure it was definitely put there (didn't see that in the procedures above). D. Stimits, stimits@idcomm.com > > Edit /etc/lilo.conf to add a new stanza for this kernel > > Then type make install > > This has worked for a long time for me with stock kernels, linus pre > kernels and ac kernels > > When I tried the same with 2.4.5 and the XFS patches with the > following lilo.conf > > boot=/dev/sda > map=/boot/map > install=/boot/boot.b > prompt > timeout=50 > message=/boot/message > linear > #default=linux > > image=/boot/vmlinuz-2.4.5-xfs > label=new > read-only > root=/dev/sda8 > append="ramdisk_size=2500" > > image=/boot/vmlinuz-2.4.2-SGI_XFS_1.0 > label=linux > initrd=/boot/initrd-2.4.2-SGI_XFS_1.0.img > read-only > root=/dev/sda8 > append="ramdisk_size=2500" > > I got this error when I did make install > > objcopy -O binary -R .note -R .comment -S compressed/bvmlinux compressed/bvmlinux.out > tools/build -b bbootsect bsetup compressed/bvmlinux.out CURRENT > bzImage > Root device is (8, 8) > Boot sector 512 bytes. > Setup is 2400 bytes. > System is 974 kB > sh -x ./install.sh 2.4.5-xfs bzImage /usr/src/linux-2.4.5/System.map "" > + '[' -x /sbin/installkernel ']' > + '[' -f /vmlinuz ']' > + mv /vmlinuz /vmlinuz.old > + '[' -f /System.map ']' > + mv /System.map /System.old > + cat bzImage > + cp /usr/src/linux-2.4.5/System.map /System.map > + '[' -x /sbin/lilo ']' > + /sbin/lilo > Fatal: open /boot/vmlinuz-2.4.5-xfs: No such file or directory > make[1]: *** [install] Error 1 > make[1]: Leaving directory `/usr/src/linux-2.4.5/arch/i386/boot' > make: *** [install] Error 2 > > I reinstalled stock RH 7.1 and did a plain 2.4.5 upgrade with the > above mechanism [changing the image line to /boot/vmlinuz-2.4.5] and > it works perfectly. > > I can ofcourse copy the image and system map from the kernel source > dir to the right places and run lilo by hand but I am surprised as to > why the usual "make install" mechanisms breaks. Maybe I am doing > kernel builds incorrectly. I can't remember when I started doing it > this way or if this is the correct way > > Any insight would be appreciated > > Regards, Yusuf > > -- > Yusuf Goolamabbas > yusufg@outblaze.com From owner-linux-xfs@oss.sgi.com Wed Jun 27 13:04:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RK49Z05365 for linux-xfs-outgoing; Wed, 27 Jun 2001 13:04:09 -0700 Received: from mail15b.boca15-verio.com ([208.55.91.59]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RK47V05359 for ; Wed, 27 Jun 2001 13:04:07 -0700 Received: from www.sigmastorage.com (128.241.173.170) by mail15b.boca15-verio.com (RS ver 1.0.60s) with SMTP id 03729756; Wed, 27 Jun 2001 16:03:50 -0400 (EDT) Message-ID: <3B3A3AFC.AB1F940C@sigmastorage.com> Date: Wed, 27 Jun 2001 12:58:52 -0700 From: Matt Ryan X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2-june14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux-XFS CC: Eric Sandeen Subject: misc. problems with 1.0 installer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk here's the (very simple) partition part of the kickstart file I am fooling around with: part /boot --size 50 --ondisk hda part / --size 1000 --ondisk hda part raid.01 --size 500 --ondisk hda part raid.02 --size 500 --ondisk hdc raid /storage --level 1 --device md0 raid.01 raid.02 in this situation, /boot and / are formatted xfs, the raid device is formatted ext2. basically, just now I tried to add the --fs xfs option: raid /storage --fs xfs --level 1 --device md0 raid.01 raid.02 but anaconda barfs when parsing the file (--fs: unknown option). either I'm using the option incorrectly or that's another clue to the problem. ... the other oddity, one I think I've seen mentioned on the list before - when attempting a graphical install (via nfs), the X server can't start, it dies with (hand-copied): Gdk-Error **: Fatal IO error 104 (Connection reset by peer) on X server :1 At first I thought this was just occurring with the intel-815 integrated agp motherboard we have here, but it is the same with an asus motherboard w/ onboard agp. on the other hand I have seen it work recently on a sis chipset/amd motherboard with onboard agp (sorry for the lack of specifics). I just reverified, at least with the 815, that the normal RH 7.1 installer works fine. ... one last little difference between installers: in the xfs-modified version, when installing on the 815 (specifically an intel d815eeal), I am always prompted as it brings the network up to choose the ethernet module type to insert (intel etherexpress pro, onboard); the normal rh7.1 install doesn't bother me with this. Matt From owner-linux-xfs@oss.sgi.com Wed Jun 27 13:14:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RKEre06747 for linux-xfs-outgoing; Wed, 27 Jun 2001 13:14:53 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RKErV06744 for ; Wed, 27 Jun 2001 13:14:53 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA08415 for ; Wed, 27 Jun 2001 13:14:48 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2275886; Wed, 27 Jun 2001 15:13:32 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA90621; Wed, 27 Jun 2001 15:13:32 -0500 (CDT) Message-ID: <3B3A39C7.D5D2EA1E@sgi.com> Date: Wed, 27 Jun 2001 14:53:43 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Matt Ryan CC: Linux-XFS Subject: Re: misc. problems with 1.0 installer References: <3B3A3AFC.AB1F940C@sigmastorage.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Matt Ryan wrote: > raid /storage --fs xfs --level 1 --device md0 raid.01 raid.02 > > but anaconda barfs when parsing the file (--fs: unknown option). either > I'm using the option incorrectly or that's another clue to the problem. Right, sorry, --fs is only for the "part" command, not for the raid command. I have yet to find out where the kickstart and gui/text code converge for filesystem selection.... :/ > ... > > the other oddity, one I think I've seen mentioned on the list before - > when attempting a graphical install (via nfs), the X server can't start, > it dies with (hand-copied): This one baffles me, if it works on RH 7.1 then we did SOMETHING to break this particular X server, but I can't imagine what it would be. Perhaps our new 2.4.3 kernel will fix it. :) > one last little difference between installers: in the xfs-modified > version, when installing on the 815 (specifically an intel d815eeal), I > am always prompted as it brings the network up to choose the ethernet > module type to insert (intel etherexpress pro, onboard); the normal > rh7.1 install doesn't bother me with this. Again... not sure what we might have touched to change this... From owner-linux-xfs@oss.sgi.com Wed Jun 27 14:28:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RLSBL18593 for linux-xfs-outgoing; Wed, 27 Jun 2001 14:28:11 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RLSAV18589 for ; Wed, 27 Jun 2001 14:28:11 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA19350 for ; Wed, 27 Jun 2001 14:28:04 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2281004 for ; Wed, 27 Jun 2001 16:26:54 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA05314 for ; Wed, 27 Jun 2001 16:26:54 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f5RLSoh02252; Wed, 27 Jun 2001 16:28:50 -0500 Message-Id: <200106272128.f5RLSoh02252@jen.americas.sgi.com> Date: Wed, 27 Jun 2001 16:28:50 -0500 Subject: TAKE - add the built aic firmware to the tree Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk After some discussion we are adding the compiled aic firmware to the tree, you will no longer need to turn on the build firmware option. Date: Wed Jun 27 14:25:49 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:97757a linux/drivers/scsi/aic7xxx/aic7xxx_seq.h - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx_reg.h - 1.3 - Adding built aic firmware to the tree From owner-linux-xfs@oss.sgi.com Wed Jun 27 15:06:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RM6vC24148 for linux-xfs-outgoing; Wed, 27 Jun 2001 15:06:57 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RM6uV24145 for ; Wed, 27 Jun 2001 15:06:56 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA00815 for ; Wed, 27 Jun 2001 15:04:05 -0700 (PDT) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2280268 for ; Wed, 27 Jun 2001 17:05:37 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA59257 for ; Wed, 27 Jun 2001 17:05:37 -0500 (CDT) From: Dean Roehrich Received: by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id RAA12984; Wed, 27 Jun 2001 17:05:37 -0500 (CDT) Message-Id: <200106272205.RAA12984@slobber.americas.sgi.com> Date: Wed, 27 Jun 2001 17:05:37 -0500 (CDT) To: linux-xfs@oss.sgi.com Subject: xfsdump/xfsprogs libtoolized Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've been working to libtoolize the XFS userspace commands and to get the installation correct when using RPM. Would someone please try this stuff on a debian installation? I'd like to know that the libraries build and link okay, and if someone could checkout the dpkg packaging. This affects the things in the cmd/xfsdump and cmd/xfsprogs dirs. I have a patch at (or maybe it'll get there in a few minutes) ftp://oss.sgi.com/projects/xfs/download/testing/xfs_cmd_libtoolize.patch.gz Dean From owner-linux-xfs@oss.sgi.com Wed Jun 27 15:11:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RMBhd24832 for linux-xfs-outgoing; Wed, 27 Jun 2001 15:11:43 -0700 Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RMBgV24821 for ; Wed, 27 Jun 2001 15:11:42 -0700 Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id AAA29390 for ; Thu, 28 Jun 2001 00:11:40 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id AAA16351 for ; Thu, 28 Jun 2001 00:11:40 +0200 (MET DST) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 00:11:40 +0200 Message-ID: From: Catalano Michele To: "'linux-xfs@oss.sgi.com'" Subject: xfs on Linux on S/390 Date: Thu, 28 Jun 2001 00:11:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Have any one test a porting of xfs to the Linux on S/390? Or can any body help me to do this? Michele From owner-linux-xfs@oss.sgi.com Wed Jun 27 15:20:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RMKmh26313 for linux-xfs-outgoing; Wed, 27 Jun 2001 15:20:48 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RMKkV26309 for ; Wed, 27 Jun 2001 15:20:46 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA383767 for ; Thu, 28 Jun 2001 00:20:42 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2281647; Wed, 27 Jun 2001 17:19:25 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA98811; Wed, 27 Jun 2001 17:19:24 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5RMLKI02507; Wed, 27 Jun 2001 17:21:20 -0500 Message-Id: <200106272221.f5RMLKI02507@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Catalano Michele cc: "'linux-xfs@oss.sgi.com'" Subject: Re: xfs on Linux on S/390 In-Reply-To: Message from Catalano Michele of "Thu, 28 Jun 2001 00:11:39 +0200." Date: Wed, 27 Jun 2001 17:21:20 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Have any one test a porting of xfs to the Linux on S/390? > Or can any body help me to do this? > > Michele Hi, I am pretty sure no one has ever attempted this, we certainly don't have access to one ;-). The code has run on a few architectures now, and comes from a 64 bit background (again I do not even know if the S/390 is a 32 bit or 64 bit architecture). It should be endian independent, but there will almost certainly be something about the S/390 which will need work - what is the normal page size? XFS is currently restricted to a filesystem block size equal to the system page size. I would attempt a compilation and report back what happens and we can take it from there. Steve From owner-linux-xfs@oss.sgi.com Wed Jun 27 15:26:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RMQMc27172 for linux-xfs-outgoing; Wed, 27 Jun 2001 15:26:22 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RMQLV27166 for ; Wed, 27 Jun 2001 15:26:21 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 80CF21E7A1; Thu, 28 Jun 2001 00:26:15 +0200 (MEST) Date: Thu, 28 Jun 2001 00:26:14 +0200 From: Andi Kleen To: Steve Lord Cc: Catalano Michele , "'linux-xfs@oss.sgi.com'" Subject: Re: xfs on Linux on S/390 Message-ID: <20010628002614.A11249@gruyere.muc.suse.de> References: <200106272221.f5RMLKI02507@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106272221.f5RMLKI02507@jen.americas.sgi.com>; from lord@sgi.com on Wed, Jun 27, 2001 at 05:21:20PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Jun 27, 2001 at 05:21:20PM -0500, Steve Lord wrote: > I am pretty sure no one has ever attempted this, we certainly don't have > access to one ;-). The code has run on a few architectures now, and comes > from a 64 bit background (again I do not even know if the S/390 is a > 32 bit or 64 bit architecture). It should be endian independent, but The normal case (non 390x) is 31bits .. > there will almost certainly be something about the S/390 which will > need work - what is the normal page size? XFS is currently restricted > to a filesystem block size equal to the system page size. Most VM devices have a bigger hw blocksize than 512 bytes, usually 4K, so that will be already a problem for XFS. -Andi From owner-linux-xfs@oss.sgi.com Wed Jun 27 15:35:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RMZND28691 for linux-xfs-outgoing; Wed, 27 Jun 2001 15:35:23 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RMZLV28685 for ; Wed, 27 Jun 2001 15:35:21 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA379330 for ; Thu, 28 Jun 2001 00:35:19 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2278265; Wed, 27 Jun 2001 17:32:21 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA52217; Wed, 27 Jun 2001 17:32:14 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5RMY9m02877; Wed, 27 Jun 2001 17:34:09 -0500 Message-Id: <200106272234.f5RMY9m02877@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andi Kleen cc: Steve Lord , Catalano Michele , "'linux-xfs@oss.sgi.com'" Subject: Re: xfs on Linux on S/390 In-Reply-To: Message from Andi Kleen of "Thu, 28 Jun 2001 00:26:14 +0200." <20010628002614.A11249@gruyere.muc.suse.de> Date: Wed, 27 Jun 2001 17:34:09 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > > there will almost certainly be something about the S/390 which will > > need work - what is the normal page size? XFS is currently restricted > > to a filesystem block size equal to the system page size. > > Most VM devices have a bigger hw blocksize than 512 bytes, usually 4K, > so that will be already a problem for XFS. You know, that does ring a bell somewhere, yes this could be an issue, XFS has some metadata objects on disk which are 512 bytes long and are accessed separately. Getting around this is an interesting exercise in adding read/modify/write logic, or living with an incompatible on disk format. Steve > > > -Andi From owner-linux-xfs@oss.sgi.com Wed Jun 27 15:40:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RMeWF29520 for linux-xfs-outgoing; Wed, 27 Jun 2001 15:40:32 -0700 Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RMeVV29517 for ; Wed, 27 Jun 2001 15:40:31 -0700 Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id AAA00610; Thu, 28 Jun 2001 00:40:29 +0200 (MET DST) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id AAA01096; Thu, 28 Jun 2001 00:40:28 +0200 (MET DST) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 00:40:29 +0200 Message-ID: From: Catalano Michele To: "'Steve Lord'" Cc: "'linux-xfs@oss.sgi.com'" Subject: AW: xfs on Linux on S/390 Date: Thu, 28 Jun 2001 00:40:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5RMeWV29518 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, the S/390 is a 31 bit architecture but at the end of this year i have a new one that is a 64 bit architecture and is named zSeries/900. The filesystem block size are 4k but i don't now who i can fond the system page size. I must also install the 2.4.3 kernel on my system and than i can make a test compilation and send you the report back. I am a new linux user, so can you please say me how i see the system page size? To prepare the system i need about 1 month. Michele > -----Urspr> üngliche Nachricht----- > Von: Steve Lord [SMTP:lord@sgi.com] > Gesendet am: Donnerstag, 28. Juni 2001 00:21 > An: Catalano Michele > Cc: 'linux-xfs@oss.sgi.com' > Betreff: Re: xfs on Linux on S/390 > > > Have any one test a porting of xfs to the Linux on S/390? > > Or can any body help me to do this? > > > > Michele > > Hi, > > I am pretty sure no one has ever attempted this, we certainly don't have > access to one ;-). The code has run on a few architectures now, and comes > from a 64 bit background (again I do not even know if the S/390 is a > 32 bit or 64 bit architecture). It should be endian independent, but > there will almost certainly be something about the S/390 which will > need work - what is the normal page size? XFS is currently restricted > to a filesystem block size equal to the system page size. > > I would attempt a compilation and report back what happens and we can > take it from there. > > Steve > From owner-linux-xfs@oss.sgi.com Wed Jun 27 15:48:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RMmtm30948 for linux-xfs-outgoing; Wed, 27 Jun 2001 15:48:55 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RMmrV30937 for ; Wed, 27 Jun 2001 15:48:53 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA09784 for ; Wed, 27 Jun 2001 15:48:51 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2278741; Wed, 27 Jun 2001 17:47:34 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA83779; Wed, 27 Jun 2001 17:47:34 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5RMnTq03292; Wed, 27 Jun 2001 17:49:29 -0500 Message-Id: <200106272249.f5RMnTq03292@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Catalano Michele cc: "'Steve Lord'" , "'linux-xfs@oss.sgi.com'" Subject: Re: AW: xfs on Linux on S/390 In-Reply-To: Message from Catalano Michele of "Thu, 28 Jun 2001 00:40:29 +0200." Date: Wed, 27 Jun 2001 17:49:29 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi, > > the S/390 is a 31 bit architecture but at the end of this year i have a = > new one that is a 64 bit architecture and is named zSeries/900. > The filesystem block size are 4k but i don't now who i can fond the = > system page size.=20 > I must also install the 2.4.3 kernel on my system and than i can make a = > test compilation and send you the report back. > I am a new linux user, so can you please say me how i see the system = > page size? The page size appears to be 4K which matches your device block size. However, the issue Andi Kleen raised will mean there is code to be written to make XFS function on the S/390, this is not just going to be a port where all that needs to be done is make the code compile. Steve > To prepare the system i need about 1 month. > > Michele > From owner-linux-xfs@oss.sgi.com Wed Jun 27 15:54:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RMsDJ31934 for linux-xfs-outgoing; Wed, 27 Jun 2001 15:54:13 -0700 Received: from femail4.sdc1.sfba.home.com (femail4.sdc1.sfba.home.com [24.0.95.84]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RMsCV31930 for ; Wed, 27 Jun 2001 15:54:12 -0700 Received: from lunkwill.org ([24.20.108.34]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010627225404.SQIU12223.femail4.sdc1.sfba.home.com@lunkwill.org> for ; Wed, 27 Jun 2001 15:54:04 -0700 Message-ID: <3B3A6694.E967B13B@lunkwill.org> Date: Wed, 27 Jun 2001 17:04:52 -0600 From: Jason X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: nfs errors on exported xfs fs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've been getting several different kinds of errors somewhat consistently on my nfs mounted xfs partition in my home network. Here are the vitals: Network: 100Mbit switched NFS server (parsec): Alpha running Debian GNU/Linux parsec:/var/log# uname -a Linux parsec 2.4.2-XFS #4 Mon May 21 17:28:46 MST 2001 alpha unknown Promise UDMA/33 PCI controller 80G Maxtor IDE drive 30G xfs partition (/gulf) exported via user-space Linux nfs server v2.2 second 30G ext2 partition (/memoryhole) also exported linux-2.4-xfs-1.0.patch (yes, I know it's somewhat perverse to be using an IDE hd on a SCSI Alpha with a PC IDE controller to create an SGI partition and then export it via nfs...) NFS client (erg): x86 linux (RH 6.2) First noticed errors of the form: somefile: No such file or directory when untarring a 200MB tarball of my /usr/doc directory to the nfs partition from the client (erg). I've also gotten "Input/Output error"s several times. Untarring locally on parsec wasn't a problem, nor was untarring from erg to the ext2 partition. This script usually gives me errors, but not always. Just now, it ran fine on directories 0 and 1, but then: ... 1+0 records in 1+0 records out 1+0 records in 1+0 records out 1+0 records in 1+0 records out dd: 2/0: No such file or directory dd: 2/1: No such file or directory dd: 2/2: No such file or directory dd: 2/3: No such file or directory dd: 2/4: No such file or directory ... The script: #!/usr/bin/perl #Cause problems on my nfs'ed xfs partition -JH for($i=0; $i<500; $i++) { system("mkdir $i"); for($j=0; $j<100; $j++) { $size = int(rand(10000)); system("dd if=/dev/zero of=$i/$j bs=$size count=1"); # system("cp /tmp/qwerty $i/$j"); } } The script runs fine when the cwd is in the exported ext2 partition, and sometimes even works on the xfs partition. The /usr/doc tarball seems to always have problems. Something screwy seems to be going on with writing to files just after creating directories, but changing it to this also produces occasional I/O errors: #!/usr/bin/perl for($i=0; $i<500; $i++) { for($j=0; $j<100; $j++) { $size = int(rand(10000)); system("dd if=/dev/zero of=$j bs=$size count=1"); } } Interestingly, just now I ran that script and then did this: [jason@erg] /gulf/test$ rm -rf * rm: cannot remove `0': Input/output error And now I get: [jason@erg] /gulf/test$ ls -la ls: 0: Input/output error total 8 drwxrwsr-x 2 jason nfsusers 14 Jun 8 02:34 . drwxrwsr-x 21 root nfsusers 8192 Jun 8 02:02 .. Yet, from parsec locally: parsec:/gulf/test# ls -la total 8 drwxrwsr-x 2 jason nfsusers 14 Jun 8 01:34 . drwxrwsr-x 21 root nfsusers 8192 Jun 8 01:02 .. -rw-rw-r-- 1 jason nfsusers 0 Jun 8 01:33 0 So, something screwy is going on, restricted to nfs accesses of the xfs partition. No troubles locally, and none with the exported ext2 fs. Oddly enough, nothing interesting in the logs of either machine, either. -J From owner-linux-xfs@oss.sgi.com Wed Jun 27 16:35:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RNZ3A06428 for linux-xfs-outgoing; Wed, 27 Jun 2001 16:35:03 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RNZ1V06417 for ; Wed, 27 Jun 2001 16:35:02 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA07347 for ; Wed, 27 Jun 2001 16:34:55 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA2281896 for ; Wed, 27 Jun 2001 18:33:44 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id SAA95743; Wed, 27 Jun 2001 18:33:44 -0500 (CDT) Message-ID: <3B3A6D29.D2120EE4@sgi.com> Date: Wed, 27 Jun 2001 18:32:57 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Release 1.0.1 - PR3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, hopefully the last test version. ftp://oss.sgi.com/projects/xfs/download/testing/Release-1.0.1-PR3/ CHANGES since PR2: - Red Hat-like kernels are now 2.4.3 - devfs is enabled, but not mounted in the Kernel RPMs pass "devfs=mount" in lilo to use devfs. - fix for setting mtime on a zero length file when create is done on top of it. - xfs behavior improved in low memory situations - du and ls -s output on directories fixed I'll work on an updated ISO installer image tomorrow. Have fun, -Eric From owner-linux-xfs@oss.sgi.com Wed Jun 27 17:36:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5S0axk17050 for linux-xfs-outgoing; Wed, 27 Jun 2001 17:36:59 -0700 Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5S0auV17036 for ; Wed, 27 Jun 2001 17:36:56 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.9.3/8.9.3) id CAA03294 for linux-xfs@oss.sgi.com; Thu, 28 Jun 2001 02:36:53 +0200 Date: Thu, 28 Jun 2001 02:36:52 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: linux-xfs@oss.sgi.com Subject: XFS oops Message-ID: <20010628023652.B380@vestdata.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The filesystem was on a broken lvm-volume, but is it supposed to oops? I'd prefer a nice error-message, if I have a choice :-) Unable to handle kernel NULL pointer dereference at virtual address 00000152 c01b989a *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[xfs_iget+138/320] EIP: 0010:[] elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: ffffffe8 ecx: 00000000 edx: c0345100 esi: efa2fb20 edi: c0345100 ebp: f7c57400 esp: f5d37e0c ds: 0018 es: 0018 ss: 0018 Process updatedb (pid: 1072, stackpage=f5d37000) Stack: efa2fb0c 00000000 00000000 f7c57400 00000000 3f000000 efa3e4c8 c01cf3f7 f7c57400 00000000 3f000000 00000000 00000000 f5d37e9c 00000000 00000000 00000000 00000008 0000000e 00000001 00023a00 efa3e4e0 efa3e4c8 00000008 Call Trace: [xfs_dir_lookup_int+295/704] [xfs_lookup+151/272] [linvfs_lookup+104/192] [xfs_access+47/64] [] [real_lookup+115/272] [path_walk+1669/2320] Call Trace: [] [] [] [] [] [] [] [] [__user_walk+58/96] [sys_lstat64+19/112] [system_call+51/56] [stext+43/203] [] [] [] [] [] Code: 66 83 bb 6a 01 00 00 00 75 1a 0f b7 83 50 01 00 00 25 f7 ff >>EIP; c01b989a <===== Trace; c01cf3f7 Trace; c01d3d17 Trace; c01dc8a8 Trace; c01d2a3f Trace; fe1197be Trace; c013d123 Trace; c013d9a5 Trace; fe1197be Trace; fe1197be Trace; c013e10a <__user_walk+3a/60> Trace; c013ab33 Trace; c0106e0b Trace; c010002b Code; c01b989a 00000000 <_EIP>: Code; c01b989a <===== 0: 66 83 bb 6a 01 00 00 cmpw $0x0,0x16a(%ebx) <===== Code; c01b98a1 7: 00 Code; c01b98a2 8: 75 1a jne 24 <_EIP+0x24> c01b98be Code; c01b98a4 a: 0f b7 83 50 01 00 00 movzwl 0x150(%ebx),%eax Code; c01b98ab 11: 25 f7 ff 00 00 and $0xfff7,%eax Used "linux-2.4.5-xfs-06112001.patch", in case it makes a difference. Thanks -- Ragnar Kjorstad Big Storage From owner-linux-xfs@oss.sgi.com Wed Jun 27 18:48:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5S1meP26999 for linux-xfs-outgoing; Wed, 27 Jun 2001 18:48:40 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5S1mdV26996 for ; Wed, 27 Jun 2001 18:48:39 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA00545 for ; Wed, 27 Jun 2001 18:48:38 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA91794; Thu, 28 Jun 2001 11:47:19 +1000 (EST) Date: Thu, 28 Jun 2001 11:47:19 +1000 From: Timothy Shimmin To: Shanker Balan Cc: Linux-XFS Subject: Re: ACL for Linux OS Message-ID: <20010628114719.B280523@boing.melbourne.sgi.com> References: <20010627193344.A3778@exocore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20010627193344.A3778@exocore.com>; from shanu@exocore.com on Wed, Jun 27, 2001 at 07:33:44PM +0530 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Shanker, On Wed, Jun 27, 2001 at 07:33:44PM +0530, Shanker Balan wrote: > > I just got down the RHL 7.1 XFS installer and converted one of my > machines to XFS yday to run Samba 2_2 CVS with ACL support. The Samba + > ACL part is working fine now. > > I am however quite unclear about the POSIX ACL part for the OS i am > running - Linux. What do i have to do further to get the extended > attributes working for Linux like its mentioned here > http://acl.bestbits.at/about.html. > The "bestbits" site has patches for Linux to provied extended attributes and Posix ACLs for ext2 (patches have been made for ext3 as well I believe). The code for extended attributes and ACLs in XFS are provided as part of the distribution and are quite different. The kernel ACL code needs to be configured in (CONFIG_FS_POSIX_ACL=y), but I presume you must have done this as you said you have the SAMBA+ACL stuff working. The XFS distribution has different ACL user tools. The Posix suggested tools of getfacl and setfacl are not provided. The IRIX-ported equivalent ACL tool is chacl(1) (see man page). So if you want to set or get an ACL on a file, use chacl(1). With recent changes to XFS' libacl, one can actually use the bestbits fileutils patch. For example, this will patch ls(1) so that it shows if a file has an associated ACL (see http://acl.bestbits.at/fileutils.html). With the help of Juergen Hasch (Hasch@t-online.de), this was made possible. BTW, both Juergen (Hasch@t-online.de) and John Trostel (jtrostel@connex.com) have suggested fixes for getting ACLs working with Samba (thanks guys), and would probably provide help if you run into problems in this area. :) And as for extended attributes, there is no standard interface for them yet. In XFS we use attr(1) to set and get extended attributes (see attr(1) man page for more info). Cheers, Tim. From owner-linux-xfs@oss.sgi.com Wed Jun 27 22:06:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5S56LL20503 for linux-xfs-outgoing; Wed, 27 Jun 2001 22:06:21 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5S56JV20499 for ; Wed, 27 Jun 2001 22:06:20 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA08249 for ; Wed, 27 Jun 2001 22:03:31 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id AAA2283412; Thu, 28 Jun 2001 00:04:59 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id AAA94727; Thu, 28 Jun 2001 00:04:59 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5S56p008634; Thu, 28 Jun 2001 00:06:51 -0500 Message-Id: <200106280506.f5S56p008634@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jason cc: linux-xfs@oss.sgi.com Subject: Re: nfs errors on exported xfs fs In-Reply-To: Message from Jason of "Wed, 27 Jun 2001 17:04:52 MDT." <3B3A6694.E967B13B@lunkwill.org> Date: Thu, 28 Jun 2001 00:06:51 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hmmm, your kernel was build on May 21st, but how old is your codebase, 2.4.2 predates this by a while. There are a number of NFS related fixes to XFS in later kernels. The most recent 2.4.5 patches are here: ftp://oss.sgi.com/projects/xfs/download/testing/Release-1.0.1-PR3/patches/ patch-2.4.5-bdev-ioctl - fixes initial ram disk creation patch-2.4.5-xfs-1.0.1-core - core kernel changes patch-2.4.5-xfs-1.0.1-kdb - kdb debugger patch-xfs-1.0.1-only - xfs itself Or the cvs tree is also available, just about to go up to 2.4.6-pre6 Steve > I've been getting several different kinds of errors somewhat > consistently > on my nfs mounted xfs partition in my home network. Here are the > vitals: > > Network: 100Mbit switched > > NFS server (parsec): > Alpha running Debian GNU/Linux > parsec:/var/log# uname -a > Linux parsec 2.4.2-XFS #4 Mon May 21 17:28:46 MST 2001 alpha unknown > Promise UDMA/33 PCI controller > 80G Maxtor IDE drive > 30G xfs partition (/gulf) exported via user-space Linux nfs server v2.2 > second 30G ext2 partition (/memoryhole) also exported > linux-2.4-xfs-1.0.patch > (yes, I know it's somewhat perverse to be using an IDE hd on a SCSI > Alpha with a PC IDE controller to create an SGI partition and then > export it via nfs...) > > NFS client (erg): > x86 linux (RH 6.2) > > First noticed errors of the form: > > somefile: No such file or directory > > when untarring a 200MB tarball of my /usr/doc directory to the nfs > partition from the client (erg). I've also gotten "Input/Output error"s > several times. > > Untarring locally on parsec wasn't a problem, nor was untarring from erg > to the ext2 partition. > > This script usually gives me errors, but not always. Just now, it ran > fine on directories 0 and 1, but then: > > ... > 1+0 records in > 1+0 records out > 1+0 records in > 1+0 records out > 1+0 records in > 1+0 records out > dd: 2/0: No such file or directory > dd: 2/1: No such file or directory > dd: 2/2: No such file or directory > dd: 2/3: No such file or directory > dd: 2/4: No such file or directory > ... > > The script: > #!/usr/bin/perl > > #Cause problems on my nfs'ed xfs partition -JH > > for($i=0; $i<500; $i++) { > system("mkdir $i"); > for($j=0; $j<100; $j++) { > $size = int(rand(10000)); > system("dd if=/dev/zero of=$i/$j bs=$size count=1"); > # system("cp /tmp/qwerty $i/$j"); > } > } > > The script runs fine when the cwd is in the exported ext2 partition, > and sometimes even works on the xfs partition. The /usr/doc tarball > seems to always have problems. > > Something screwy seems to be going on with writing to files just after > creating directories, but changing it to this also produces occasional > I/O > errors: > > #!/usr/bin/perl > > for($i=0; $i<500; $i++) { > for($j=0; $j<100; $j++) { > $size = int(rand(10000)); > system("dd if=/dev/zero of=$j bs=$size count=1"); > } > } > > Interestingly, just now I ran that script and then did this: > > [jason@erg] /gulf/test$ rm -rf * > rm: cannot remove `0': Input/output error > > And now I get: > [jason@erg] /gulf/test$ ls -la > ls: 0: Input/output error > total 8 > drwxrwsr-x 2 jason nfsusers 14 Jun 8 02:34 . > drwxrwsr-x 21 root nfsusers 8192 Jun 8 02:02 .. > > Yet, from parsec locally: > parsec:/gulf/test# ls -la > total 8 > drwxrwsr-x 2 jason nfsusers 14 Jun 8 01:34 . > drwxrwsr-x 21 root nfsusers 8192 Jun 8 01:02 .. > -rw-rw-r-- 1 jason nfsusers 0 Jun 8 01:33 0 > > So, something screwy is going on, restricted to nfs accesses of the xfs > partition. No troubles locally, and none with the exported ext2 fs. > Oddly enough, nothing interesting in the logs of either machine, either. > > -J From owner-linux-xfs@oss.sgi.com Wed Jun 27 22:27:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5S5RSd22797 for linux-xfs-outgoing; Wed, 27 Jun 2001 22:27:28 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5S5ROV22791 for ; Wed, 27 Jun 2001 22:27:24 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id HAA406904 for ; Thu, 28 Jun 2001 07:27:19 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id AAA2283186 for ; Thu, 28 Jun 2001 00:26:03 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id AAA90856 for ; Thu, 28 Jun 2001 00:26:03 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f5S5Rt508838; Thu, 28 Jun 2001 00:27:55 -0500 Message-Id: <200106280527.f5S5Rt508838@jen.americas.sgi.com> Date: Thu, 28 Jun 2001 00:27:55 -0500 Subject: TAKE - merge up to 2.4.6-pre6 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk One giant leap for Linux, one small step for XFS. In other words, not a lot happened in filesystem land here. There was a change in linux/drivers/net/Config.in which breaks xconfig, I guessed at the fix based on a post on linux kernel, but I am pretty sure it is not the correct change, I will fix it up once there is a consensus. Or more likely, Keith will fix it before I wake up in the morning. Steve Date: Wed Jun 27 22:21:16 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-base The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:97791a linux/arch/sh/kernel/setup_sh2000.c - 1.1 linux/drivers/usb/se401.c - 1.1 linux/drivers/acorn/char/mouse_ps2.c - 1.1 linux/drivers/usb/se401.h - 1.1 linux/Documentation/usb/se401.txt - 1.1 linux/arch/sh/stboards/setup.c - 1.1 linux/arch/sh/stboards/pcidma.c - 1.1 linux/arch/sh/stboards/mach.c - 1.1 linux/arch/sh/stboards/led.c - 1.1 linux/arch/sh/stboards/irq.c - 1.1 linux/arch/sh/stboards/harp.h - 1.1 linux/arch/sh/stboards/Makefile - 1.1 linux/arch/arm/boot/compressed/head-integrator.S - 1.1 linux/drivers/usb/serial/cyberjack.c - 1.1 linux/drivers/usb/serial/pl2303.c - 1.1 linux/arch/sh/kernel/setup_bigsur.c - 1.1 linux/arch/sh/kernel/pci-sh7751.c - 1.1 linux/arch/sh/kernel/pci-dma.c - 1.1 linux/arch/sh/kernel/pci-dc.c - 1.1 linux/arch/sh/kernel/pci-bigsur.c - 1.1 linux/arch/sh/kernel/pci-7751se.c - 1.1 linux/arch/sh/kernel/mach_bigsur.c - 1.1 linux/arch/arm/mach-ebsa110/hardware.h - 1.1 linux/arch/sh/kernel/led_bigsur.c - 1.1 linux/include/asm-sh/bigsur.h - 1.1 linux/include/asm-sh/dc_sysasic.h - 1.1 linux/arch/sh/kernel/io_sh2000.c - 1.1 linux/include/asm-sh/io_bigsur.h - 1.1 linux/include/asm-sh/io_sh2000.h - 1.1 linux/arch/sh/kernel/io_bigsur.c - 1.1 linux/include/asm-sh/mc146818rtc.h - 1.1 linux/include/asm-sh/pci-sh7751.h - 1.1 linux/include/asm-sh/serial-bigsur.h - 1.1 linux/net/wanrouter/wanproc.c - 1.15 linux/net/wanrouter/wanmain.c - 1.11 linux/net/rose/rose_dev.c - 1.8 linux/net/netrom/nr_subr.c - 1.4 linux/net/netrom/nr_loopback.c - 1.7 linux/net/netrom/nr_dev.c - 1.8 linux/net/netlink/af_netlink.c - 1.14 linux/mm/vmscan.c - 1.59 linux/mm/page_alloc.c - 1.44 linux/kernel/sched.c - 1.36 linux/include/video/macmodes.h - 1.5 linux/include/linux/sockios.h - 1.6 linux/include/asm-arm/proc-armv/system.h - 1.11 linux/include/asm-arm/proc-armo/system.h - 1.9 linux/include/asm-arm/io.h - 1.15 linux/include/asm-arm/bitops.h - 1.6 linux/fs/select.c - 1.16 linux/fs/proc/generic.c - 1.20 linux/fs/proc/base.c - 1.25 linux/fs/nls/Config.in - 1.9 linux/drivers/video/mdacon.c - 1.9 linux/drivers/video/macmodes.c - 1.9 linux/drivers/video/imsttfb.c - 1.13 linux/drivers/usb/Makefile - 1.38 linux/drivers/usb/Config.in - 1.42 linux/drivers/sound/wf_midi.c - 1.9 linux/drivers/sound/wavfront.c - 1.16 linux/drivers/sound/sb_card.c - 1.25 linux/drivers/scsi/sym53c416.h - 1.5 linux/drivers/scsi/sym53c416.c - 1.9 linux/drivers/scsi/scsi_proc.c - 1.10 linux/drivers/scsi/hosts.c - 1.23 linux/drivers/scsi/eata_dma.c - 1.16 linux/drivers/scsi/aha152x.c - 1.19 linux/drivers/scsi/NCR53c406a.c - 1.10 linux/drivers/nubus/nubus.c - 1.7 linux/drivers/net/shaper.c - 1.18 linux/drivers/net/hamradio/soundmodem/sm_wss.c - 1.6 linux/drivers/net/hamradio/soundmodem/sm.h - 1.7 linux/drivers/net/hamradio/scc.c - 1.18 linux/drivers/net/hamradio/bpqether.c - 1.16 linux/drivers/net/ewrk3.c - 1.17 linux/drivers/net/am79c961a.c - 1.12 linux/drivers/net/Config.in - 1.40 linux/drivers/net/3c509.c - 1.22 linux/drivers/macintosh/macserial.h - 1.7 linux/drivers/macintosh/macserial.c - 1.17 linux/drivers/macintosh/mac_keyb.c - 1.14 linux/drivers/isdn/avmb1/capi.c - 1.22 linux/drivers/char/tty_io.c - 1.30 linux/drivers/char/nvram.c - 1.13 linux/drivers/char/esp.c - 1.10 linux/drivers/char/epca.c - 1.16 linux/drivers/char/cyclades.c - 1.17 linux/drivers/cdrom/mcdx.c - 1.8 linux/drivers/block/swim3.c - 1.12 linux/drivers/block/ps2esdi.c - 1.15 linux/drivers/block/paride/pt.c - 1.11 linux/drivers/acorn/scsi/acornscsi.h - 1.6 linux/drivers/acorn/scsi/acornscsi.c - 1.7 linux/drivers/acorn/net/ether3.c - 1.11 linux/drivers/acorn/net/ether1.c - 1.12 linux/drivers/acorn/char/mouse_rpc.c - 1.7 linux/drivers/acorn/char/keyb_ps2.c - 1.9 linux/arch/sparc64/defconfig - 1.38 linux/arch/sparc64/config.in - 1.40 linux/arch/i386/defconfig - 1.59 linux/arch/arm/mm/mm-armv.c - 1.22 linux/arch/arm/mm/fault-armv.c - 1.15 linux/arch/arm/kernel/traps.c - 1.19 linux/arch/arm/kernel/sys_arm.c - 1.17 linux/arch/arm/kernel/fiq.c - 1.10 linux/arch/arm/kernel/entry-armv.S - 1.19 linux/arch/arm/kernel/ecard.c - 1.13 linux/arch/arm/kernel/calls.S - 1.15 linux/arch/arm/boot/compressed/head.S - 1.13 linux/arch/arm/boot/compressed/Makefile - 1.18 linux/arch/arm/boot/Makefile - 1.8 linux/arch/arm/Makefile - 1.21 linux/arch/alpha/kernel/sys_alcor.c - 1.9 linux/Makefile - 1.92 linux/MAINTAINERS - 1.62 linux/Documentation/java.txt - 1.4 linux/Documentation/Configure.help - 1.85 linux/Documentation/Changes - 1.40 linux/CREDITS - 1.55 linux/net/decnet/af_decnet.c - 1.25 linux/drivers/video/cyber2000fb.c - 1.21 linux/drivers/sound/cmpci.c - 1.23 linux/drivers/acorn/char/keyb_arc.c - 1.9 linux/drivers/char/raw.c - 1.17 linux/drivers/char/sx.h - 1.4 linux/drivers/char/sx.c - 1.18 linux/drivers/isdn/avmb1/kcapi.c - 1.14 linux/drivers/net/sis900.c - 1.23 linux/drivers/atm/zatm.c - 1.10 linux/drivers/atm/uPD98402.c - 1.6 linux/drivers/atm/nicstar.c - 1.14 linux/drivers/atm/ambassador.c - 1.12 linux/net/atm/signaling.c - 1.7 linux/net/atm/mpc.c - 1.7 linux/net/atm/lec.c - 1.13 linux/net/atm/common.c - 1.11 linux/net/atm/clip.c - 1.11 linux/arch/sh/mm/init.c - 1.14 linux/arch/sh/mm/fault.c - 1.15 linux/arch/sh/kernel/time.c - 1.15 linux/arch/sh/kernel/sh_ksyms.c - 1.9 linux/arch/sh/kernel/setup.c - 1.15 linux/arch/sh/kernel/irq.c - 1.11 linux/arch/sh/kernel/entry.S - 1.18 linux/arch/sh/kernel/Makefile - 1.12 linux/arch/sh/config.in - 1.17 linux/drivers/char/n_r3964.c - 1.9 linux/include/asm-sh/user.h - 1.4 linux/include/asm-sh/string.h - 1.6 linux/include/asm-sh/softirq.h - 1.7 linux/include/asm-sh/semaphore.h - 1.5 linux/include/asm-sh/processor.h - 1.13 linux/include/asm-sh/pgtable.h - 1.18 linux/include/asm-sh/irq.h - 1.10 linux/include/asm-sh/io.h - 1.10 linux/include/asm-sh/hardirq.h - 1.7 linux/include/asm-sh/bugs.h - 1.8 linux/include/asm-sh/bitops.h - 1.7 linux/drivers/char/drm/proc.c - 1.8 linux/drivers/char/drm/dma.c - 1.8 linux/drivers/char/drm/context.c - 1.6 linux/drivers/net/dmfe.c - 1.16 linux/drivers/net/wan/cosa.c - 1.19 linux/drivers/net/wan/syncppp.c - 1.11 linux/drivers/net/wan/lapbether.c - 1.8 linux/arch/sh/mm/cache.c - 1.12 linux/include/asm-arm/pci.h - 1.11 linux/include/asm-sh/pgtable-2level.h - 1.6 linux/drivers/char/agp/agpgart_fe.c - 1.11 linux/drivers/telephony/ixj.c - 1.15 linux/Documentation/usb/usb-serial.txt - 1.16 linux/drivers/net/tokenring/smctr.c - 1.13 linux/drivers/scsi/3w-xxxx.h - 1.5 linux/drivers/scsi/3w-xxxx.c - 1.10 linux/drivers/usb/usb-uhci.c - 1.22 linux/drivers/usb/usb-ohci.c - 1.22 linux/drivers/atm/iphase.c - 1.9 linux/drivers/atm/idt77105.c - 1.4 linux/drivers/scsi/qla1280.c - 1.10 linux/arch/arm/mm/consistent.c - 1.9 linux/drivers/isdn/avmb1/c4.c - 1.14 linux/drivers/video/matrox/matroxfb_base.h - 1.6 linux/drivers/video/matrox/matroxfb_base.c - 1.10 linux/drivers/video/matrox/matroxfb_accel.c - 1.4 linux/drivers/video/matrox/matroxfb_Ti3026.c - 1.4 linux/drivers/video/matrox/matroxfb_DAC1064.c - 1.7 linux/drivers/char/nwflash.c - 1.7 linux/drivers/atm/fore200e.c - 1.11 linux/drivers/usb/pegasus.c - 1.19 linux/include/asm-sh/pgalloc.h - 1.4 linux/include/asm-sh/pci.h - 1.8 linux/drivers/net/appletalk/ipddp.c - 1.7 linux/drivers/char/sh-sci.h - 1.8 linux/drivers/char/sh-sci.c - 1.12 linux/arch/sh/kernel/pci-sh.c - 1.3 linux/drivers/usb/serial/Makefile - 1.14 linux/drivers/ide/sl82c105.c - 1.4 linux/drivers/ide/rapide.c - 1.5 linux/drivers/ide/ide-pci.c - 1.14 linux/drivers/ide/hpt366.c - 1.9 linux/drivers/net/wan/comx-proto-fr.c - 1.5 linux/drivers/net/wan/comx-hw-mixcom.c - 1.5 linux/drivers/scsi/dmx3191d.h - 1.3 linux/drivers/scsi/dmx3191d.c - 1.7 linux/drivers/net/wan/lmc/lmc_main.c - 1.7 linux/arch/sh/kernel/irq_ipr.c - 1.5 linux/drivers/char/drm/mga_state.c - 1.5 linux/drivers/char/drm/i810_dma.c - 1.6 linux/drivers/char/sbc60xxwdt.c - 1.6 linux/include/asm-sh/serial.h - 1.3 linux/arch/arm/boot/compressed/setup-sa1100.S - 1.6 linux/drivers/acpi/os.c - 1.6 linux/fs/jffs/inode-v23.c - 1.8 linux/arch/arm/mm/mm-l7200.c - 1.5 linux/drivers/mtd/Config.in - 1.5 linux/arch/sh/kernel/setup_od.c - 1.2 linux/include/asm-sh/machvec.h - 1.3 linux/include/asm-sh/io_od.h - 1.3 linux/drivers/sound/cs46xx.c - 1.11 linux/drivers/net/natsemi.c - 1.9 linux/drivers/media/video/zr36120.c - 1.6 linux/drivers/media/video/videodev.c - 1.5 linux/drivers/media/video/planb.h - 1.2 linux/drivers/media/video/planb.c - 1.6 linux/drivers/media/video/i2c-parport.c - 1.2 linux/drivers/isdn/eicon/linchr.c - 1.4 linux/drivers/isdn/eicon/common.c - 1.5 linux/drivers/char/i810-tco.c - 1.5 linux/arch/arm/tools/mach-types - 1.5 linux/arch/i386/kernel/bluesmoke.c - 1.8 linux/drivers/block/cciss.c - 1.9 linux/drivers/macintosh/mac_hid.c - 1.2 linux/drivers/net/sundance.c - 1.7 linux/drivers/net/winbond-840.c - 1.8 linux/drivers/usb/pegasus.h - 1.3 linux/include/asm-arm/xor.h - 1.4 linux/drivers/usb/serial/Config.in - 1.5 linux/drivers/video/matrox/matroxfb_g450.c - 1.2 linux/include/asm-sh/rtc.h - 1.2 linux/arch/sh/kernel/rtc.c - 1.4 linux/drivers/char/drm/radeon_bufs.c - 1.3 linux/drivers/sound/maestro3.c - 1.4 linux/drivers/sound/cs4281/cs4281m.c - 1.5 linux/arch/arm/tools/Makefile - 1.2 linux/arch/arm/tools/getconstants.c - 1.3 linux/drivers/sound/cs46xxpm-24.h - 1.2 linux/arch/sh/kernel/setup_dc.c - 1.3 linux/arch/sh/kernel/pci_st40.c - 1.2 linux/arch/sh/kernel/mach_dc.c - 1.3 linux/arch/sh/kernel/irq_intc2.c - 1.3 linux/arch/sh/kernel/io_hd64465.c - 1.2 linux/arch/sh/kernel/io_dc.c - 1.3 linux/arch/sh/kernel/hd64465_gpio.c - 1.3 linux/arch/arm/mach-ebsa110/arch.c - 1.2 linux/arch/arm/mach-ebsa110/io.c - 1.3 linux/include/asm-sh/hd64465_gpio.h - 1.3 linux/fs/freevxfs/vxfs_super.c - 1.2 linux/drivers/net/fealnx.c - 1.3 linux/fs/freevxfs/vxfs_lookup.c - 1.2 linux/fs/freevxfs/vxfs_inode.h - 1.2 linux/fs/freevxfs/vxfs_inode.c - 1.2 linux/fs/freevxfs/vxfs_fshead.h - 1.2 linux/fs/freevxfs/vxfs_bmap.c - 1.2 linux/include/linux/mii.h - 1.2 From owner-linux-xfs@oss.sgi.com Wed Jun 27 22:45:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5S5jKY25101 for linux-xfs-outgoing; Wed, 27 Jun 2001 22:45:20 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5S5jJV25098 for ; Wed, 27 Jun 2001 22:45:19 -0700 Received: from relay1.corp.sgi.com (corp.sgi.com [198.29.75.13]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id WAA02595 for ; Wed, 27 Jun 2001 22:45:18 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id WAA75943 for ; Wed, 27 Jun 2001 22:44:47 -0700 (PDT) Message-ID: <3B3AC3B2.1399EBB9@sgi.com> Date: Thu, 28 Jun 2001 00:42:10 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: PR3 installer iso Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, the installer iso image will be under testing/Release-1.0.1-PR3/iso in a few minutes. It's not tested, since I can't really get it here over a 28.8 link. :) But if anyone wants to give it a shot and let us all know, there it is. Otherwise I'll check it out tomorrow. The only problem I anticipate is the jump to the 2.4.3 kernel, hopefully that will not be an issue. If you have the old 1.0 ISO laying around, you can probably get creative with rsync to shorten your download time. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Jun 27 23:17:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5S6HS728041 for linux-xfs-outgoing; Wed, 27 Jun 2001 23:17:28 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5S6HRV28038 for ; Wed, 27 Jun 2001 23:17:27 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id XAA18041 for ; Wed, 27 Jun 2001 23:17:20 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id QAA22545; Thu, 28 Jun 2001 16:17:24 +1000 Date: Thu, 28 Jun 2001 16:17:24 +1000 From: Keith Owens Message-Id: <200106280617.QAA22545@sherman.melbourne.sgi.com> Subject: TAKE - 2.4.6-pre6 net config bug Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Somebody changed drivers/net/Config.in in 2.4.6-pre6 without testing it. Date: Wed Jun 27 23:16:16 PDT 2001 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:97793a linux/drivers/net/Config.in - 1.41 From owner-linux-xfs@oss.sgi.com Wed Jun 27 23:56:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5S6uQO29401 for linux-xfs-outgoing; Wed, 27 Jun 2001 23:56:26 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5S6uOV29398 for ; Wed, 27 Jun 2001 23:56:24 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 2B6AB1AB0F for ; Thu, 28 Jun 2001 02:56:18 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id A1CB251F; Thu, 28 Jun 2001 02:56:17 -0400 (EDT) Date: Thu, 28 Jun 2001 02:56:17 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: Release 1.0.1 - PR3 Message-ID: <20010628025617.F3722@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3B3A6D29.D2120EE4@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B3A6D29.D2120EE4@sgi.com> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Jun 27, 2001 at 06:32:57PM -0500, Eric Sandeen wrote: > Ok, hopefully the last test version. > > ftp://oss.sgi.com/projects/xfs/download/testing/Release-1.0.1-PR3/ > > CHANGES since PR2: Is the highmem patch included? (Just checking. Russell's kernel has been doing reasonably well in testing over the past couple of days, so... not critical for me right now.) Andrew Klaassen From owner-linux-xfs@oss.sgi.com Thu Jun 28 02:45:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5S9j6u16924 for linux-xfs-outgoing; Thu, 28 Jun 2001 02:45:06 -0700 Received: from df.unipi.it (mail.df.unipi.it [131.114.19.77]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5S9j4V16921 for ; Thu, 28 Jun 2001 02:45:04 -0700 Received: from [131.114.19.37] (account mau HELO df.unipi.it) by df.unipi.it (CommuniGate Pro SMTP 3.4.6) with ESMTP id 1020701; Thu, 28 Jun 2001 11:49:26 +0200 Message-ID: <3B3AEE91.F238B3F@df.unipi.it> Date: Thu, 28 Jun 2001 10:45:05 +0200 From: Maurizio Davini Reply-To: maurizio.davini@df.unipi.it Organization: Department of Physics University of Pisa X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: PR3 installer iso References: <3B3AC3B2.1399EBB9@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > Ok, the installer iso image will be under testing/Release-1.0.1-PR3/iso > in a few minutes. > > It's not tested, since I can't really get it here over a 28.8 link. :) > But if anyone wants to give it a shot and let us all know, there it is. > Otherwise I'll check it out tomorrow. The only problem I anticipate is > the jump to the 2.4.3 kernel, hopefully that will not be an issue. > > If you have the old 1.0 ISO laying around, you can probably get creative > with rsync to shorten your download time. > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. The PR3 iso images fails in installing with an anaconda problem . Is unable to find En_US..... Regards Maurizio Davini Maurizio Davini Computing Center Department of Physics University of Pisa From owner-linux-xfs@oss.sgi.com Thu Jun 28 03:56:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SAuZJ27968 for linux-xfs-outgoing; Thu, 28 Jun 2001 03:56:35 -0700 Received: from citadel.oehansen.pp.se (sdu248-203.ppp.algonet.se [195.163.203.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SAuVV27945 for ; Thu, 28 Jun 2001 03:56:32 -0700 Received: from citadel.oehansen.pp.se (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f5SArV101990 for ; Thu, 28 Jun 2001 12:53:31 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se To: linux-xfs@oss.sgi.com Subject: Filesystem conversion Date: Thu, 28 Jun 2001 12:53:31 +0200 X-Mailer: KMail [version 1.2] X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I just finished converting most of my file systems to xfs, apart from the boot partition, and found the ordeal ... a bit loooong. And as I closed up on my boot partition, the idea of a filesystem converter popped into mind. Are there any plans to create one, for ext2 -> xfs? Orn From owner-linux-xfs@oss.sgi.com Thu Jun 28 03:56:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SAuVd27933 for linux-xfs-outgoing; Thu, 28 Jun 2001 03:56:31 -0700 Received: from citadel.oehansen.pp.se (sdu248-203.ppp.algonet.se [195.163.203.248]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SAuPV27915 for ; Thu, 28 Jun 2001 03:56:26 -0700 Received: from citadel.oehansen.pp.se (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f5SAte102002 for ; Thu, 28 Jun 2001 12:55:40 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se To: linux-xfs@oss.sgi.com Subject: Page buffering, side effects? Date: Thu, 28 Jun 2001 12:55:40 +0200 X-Mailer: KMail [version 1.2] X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Are there any known issues to page buffering, like slow throughput on ppp lines? Orn From owner-linux-xfs@oss.sgi.com Thu Jun 28 04:02:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SB2oU29382 for linux-xfs-outgoing; Thu, 28 Jun 2001 04:02:50 -0700 Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SB2mV29373 for ; Thu, 28 Jun 2001 04:02:49 -0700 Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 15FZZq-000Att-0W for linux-xfs@oss.sgi.com; Thu, 28 Jun 2001 12:03:14 +0100 Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3]) by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id 4CE7127EF for ; Thu, 28 Jun 2001 07:54:20 +0100 (BST) Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001) id 613EE125E6; Thu, 28 Jun 2001 08:54:18 +0100 (BST) Date: Thu, 28 Jun 2001 08:54:18 +0100 (BST) From: Keith Matthews Subject: Re: misc. problems with 1.0 installer To: Linux-XFS In-Reply-To: <3B3A3AFC.AB1F940C@sigmastorage.com> References: <3B3A3AFC.AB1F940C@sigmastorage.com> X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Disposition: INLINE Message-Id: <20010628075418.613EE125E6@rebutia.sweeney.demon.co.uk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f5SB2nV29376 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 27 Jun 2001 12:58:52 -0700 Matt Ryan > wrote: > the other oddity, one I think I've seen mentioned on the list before - > when attempting a graphical install (via nfs), the X server can't start, > it dies with (hand-copied): > > Gdk-Error **: Fatal IO error 104 (Connection reset by peer) on X server > :1 > This may not be relevant, but the basic RH 7.1 install will not use the graphical installer if you try to install from HD images. I haven't seen any error messages from it though. -- Keith Matthews Spam trap - my real account at this node is keith_m Frequentous Consultants - Linux Services, Oracle development & database administration From owner-linux-xfs@oss.sgi.com Thu Jun 28 04:28:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SBSVH01457 for linux-xfs-outgoing; Thu, 28 Jun 2001 04:28:31 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SBSTV01448 for ; Thu, 28 Jun 2001 04:28:30 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5SBSPH11802; Thu, 28 Jun 2001 13:28:25 +0200 Message-Id: <4.3.2.7.2.20010628132706.02f35300@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Jun 2001 13:28:18 +0200 To: oe.hansen@gamma.telenordia.se, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Page buffering, side effects? In-Reply-To: <01062812554001.01258@citadel.oehansen.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:55 28-6-2001 +0200, Orn E. Hansen wrote: > Are there any known issues to page buffering, like slow throughput on ppp >lines? It is only used for disk buffering. Not for the PPP code. I have a adsl line which runs through a ppp deamon and I am managing a 100KB/s roughly 1Mbit downstream. So I would say, no. Bye -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Jun 28 04:34:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SBYAs02532 for linux-xfs-outgoing; Thu, 28 Jun 2001 04:34:10 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SBY8V02510 for ; Thu, 28 Jun 2001 04:34:08 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5SBY7H11823; Thu, 28 Jun 2001 13:34:07 +0200 Message-Id: <4.3.2.7.2.20010628132843.02f35510@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Jun 2001 13:34:00 +0200 To: oe.hansen@gamma.telenordia.se, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Filesystem conversion In-Reply-To: <01062812533100.01258@citadel.oehansen.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:53 28-6-2001 +0200, Orn E. Hansen wrote: > I just finished converting most of my file systems to xfs, apart from the >boot partition, and found the ordeal ... a bit loooong. And as I closed up >on my boot partition, the idea of a filesystem converter popped into mind. >Are there any plans to create one, for ext2 -> xfs? There have been some others in the past yes, but I have just done another conversion here which was done in under 30 minutes with 5GB of data. I had setup a spare IDE disk for holding dump images connected to a promise PCI IDE controller which makes it easier to stick it in a server. It roughly went like this. Boot single user dump.static -0 -a -f /mnt/hde/var.dump /var umount /var mkfs.xfs -l size=32768b -f /dev/sda7 vi /etc/fstab (change fstype) mount /var cd /var restore.static -rf /mnt/hde/var.dump repeat. btw. If you want to do the root partition too you would need to do it using a rescue/installer disk since the restore.static lives in /sbin. This was by far the easiest method that I attempted. Bye -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Jun 28 06:22:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SDMZr20848 for linux-xfs-outgoing; Thu, 28 Jun 2001 06:22:35 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SDMXV20845 for ; Thu, 28 Jun 2001 06:22:33 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA07483 for ; Thu, 28 Jun 2001 06:19:45 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA2285593; Thu, 28 Jun 2001 08:21:15 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA43142; Thu, 28 Jun 2001 08:21:15 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5SDN4E14987; Thu, 28 Jun 2001 08:23:04 -0500 Message-Id: <200106281323.f5SDN4E14987@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Seth Mos cc: oe.hansen@gamma.telenordia.se, linux-xfs@oss.sgi.com Subject: Re: Filesystem conversion In-Reply-To: Message from Seth Mos of "Thu, 28 Jun 2001 13:34:00 +0200." <4.3.2.7.2.20010628132843.02f35510@pop.xs4all.nl> Date: Thu, 28 Jun 2001 08:23:04 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > At 12:53 28-6-2001 +0200, Orn E. Hansen wrote: > > > I just finished converting most of my file systems to xfs, apart from the > >boot partition, and found the ordeal ... a bit loooong. And as I closed up > >on my boot partition, the idea of a filesystem converter popped into mind. > >Are there any plans to create one, for ext2 -> xfs? An automatic in place converter would be a very large project and is not something we plan on doing. Steve > > There have been some others in the past yes, but I have just done another > conversion here which was done in under 30 minutes with 5GB of data. > > I had setup a spare IDE disk for holding dump images connected to a promise > PCI IDE controller which makes it easier to stick it in a server. > It roughly went like this. > > Boot single user > dump.static -0 -a -f /mnt/hde/var.dump /var > umount /var > mkfs.xfs -l size=32768b -f /dev/sda7 > vi /etc/fstab (change fstype) > mount /var > cd /var > restore.static -rf /mnt/hde/var.dump > > repeat. > > btw. If you want to do the root partition too you would need to do it using > a rescue/installer disk since the restore.static lives in /sbin. > > This was by far the easiest method that I attempted. > > Bye > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Jun 28 06:28:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SDSug21949 for linux-xfs-outgoing; Thu, 28 Jun 2001 06:28:56 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SDStV21944 for ; Thu, 28 Jun 2001 06:28:55 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5SDStH12711 for ; Thu, 28 Jun 2001 15:28:55 +0200 Message-Id: <4.3.2.7.2.20010628152727.02f0ea68@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Jun 2001 15:28:49 +0200 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: PR3 1.0.1 iso fails Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Confirming the problem that it can't find the languages. I have also tried swedish but that one does not work either. May I suggest yanking the ISO please? Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Jun 28 06:33:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SDXNR22805 for linux-xfs-outgoing; Thu, 28 Jun 2001 06:33:23 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SDXMV22802 for ; Thu, 28 Jun 2001 06:33:22 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA00746 for ; Thu, 28 Jun 2001 06:30:30 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id GAA16389; Thu, 28 Jun 2001 06:32:05 -0700 (PDT) Message-ID: <3B3B3136.8E3E3AFA@sgi.com> Date: Thu, 28 Jun 2001 08:29:26 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: maurizio.davini@df.unipi.it CC: linux-xfs@oss.sgi.com Subject: Re: PR3 installer iso References: <3B3AC3B2.1399EBB9@sgi.com> <3B3AEE91.F238B3F@df.unipi.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Maurizio Davini wrote: > The PR3 iso images fails in installing with an anaconda problem . > Is unable to find En_US..... That's a strange one... can you send the exact error message? Thanks, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Jun 28 06:37:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SDbai23592 for linux-xfs-outgoing; Thu, 28 Jun 2001 06:37:36 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SDbZV23589 for ; Thu, 28 Jun 2001 06:37:35 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5SDbYH12748 for ; Thu, 28 Jun 2001 15:37:34 +0200 Message-Id: <4.3.2.7.2.20010628153645.02e57aa8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Jun 2001 15:37:28 +0200 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: PR3 1.0.1 iso fails In-Reply-To: <4.3.2.7.2.20010628152727.02f0ea68@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_3464151==_" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=====================_3464151==_ Content-Type: text/plain; charset="us-ascii"; format=flowed At 15:28 28-6-2001 +0200, Seth Mos wrote: >Confirming the problem that it can't find the languages. I have also tried >swedish but that one does not work either. > >May I suggest yanking the ISO please? Forgot to attach dump. --=====================_3464151==_ Content-Type: text/plain; name="anacdump.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="anacdump.txt" VHJhY2ViYWNrIChpbm5lcm1vc3QgbGFzdCk6CiAgRmlsZSAiL3Zhci90bXAvYW5hY29uZGEtNy4x Ly91c3IvbGliL2FuYWNvbmRhL2l3L3Byb2dyZXNzX2d1aS5weSIsIGxpbmUgMTksIGluIHJ1bgog ICAgcmMgPSBzZWxmLnRvZG8uZG9JbnN0YWxsICgpCiAgRmlsZSAiL3Zhci90bXAvYW5hY29uZGEt Ny4xLy91c3IvbGliL2FuYWNvbmRhL3RvZG8ucHkiLCBsaW5lIDIwNzksIGluIGRvSW5zdGFsbAog ICAgZGVmYXVsdGxhbmcgPSBzZWxmLmxhbmd1YWdlLmdldExhbmdOaWNrQnlOYW1lKHNlbGYubGFu Z3VhZ2UuZ2V0RGVmYXVsdCgpKQogIEZpbGUgIi92YXIvdG1wL2FuYWNvbmRhLTcuMS8vdXNyL2xp Yi9hbmFjb25kYS90b2RvLnB5IiwgbGluZSA0MTAsIGluIGdldERlZmF1bHQKICAgIG5hbWUgPSBz ZWxmLmdldExhbmdOYW1lQnlOaWNrKGxhbmcpCiAgRmlsZSAiL3Zhci90bXAvYW5hY29uZGEtNy4x Ly91c3IvbGliL2FuYWNvbmRhL3RvZG8ucHkiLCBsaW5lIDM5NiwgaW4gZ2V0TGFuZ05hbWVCeU5p Y2sKICAgIHJhaXNlIEtleUVycm9yLCAibGFuZ3VhZ2UgJXMgbm90IGZvdW5kIiAlIG5pY2sKS2V5 RXJyb3I6IGxhbmd1YWdlIGVuX1VTIG5vdCBmb3VuZAoKTG9jYWwgdmFyaWFibGVzIGluIGlubmVy bW9zdCBmcmFtZToKc2VsZjogCmxhbmdOYW1lOiBLb3JlYW4gKFJlcHVibGljIG9mIEtvcmVhKQpm b250OiBsYXQwLTE2Cm5pY2s6IGVuX1VTCm1hcDogaXNvMDEKbGFuZzoga29fS1IuZXVja3IKClRv RG8gb2JqZWN0OgooaXRvZG8KVG9EbwpwMQooZHAyClMncmVzU3RhdGUnCnAzClMnJwpzUydwcm9n cmVzc1dpbmRvdycKcDQKKGlndWkKUHJvZ3Jlc3NXaW5kb3cKKGRwNQpTJ3RvdGFsJwpwNgpJMTYK c1Mnd2luZG93JwpwNwooaWd0awpHdGtXaW5kb3cKKGRwOApTJ19vJwpwOQoKPGZhaWxlZD4K --=====================_3464151==_ Content-Type: text/plain; charset="us-ascii"; format=flowed -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. --=====================_3464151==_-- From owner-linux-xfs@oss.sgi.com Thu Jun 28 06:42:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SDgDx24507 for linux-xfs-outgoing; Thu, 28 Jun 2001 06:42:13 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SDgDV24496 for ; Thu, 28 Jun 2001 06:42:13 -0700 Received: from relay1.corp.sgi.com (corp.sgi.com [198.29.75.13]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA02686 for ; Thu, 28 Jun 2001 06:42:06 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id GAA46753; Thu, 28 Jun 2001 06:41:35 -0700 (PDT) Message-ID: <3B3B3370.16D6BA7@sgi.com> Date: Thu, 28 Jun 2001 08:38:56 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: linux-xfs@oss.sgi.com Subject: Re: PR3 1.0.1 iso fails References: <4.3.2.7.2.20010628152727.02f0ea68@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > May I suggest yanking the ISO please? Yep, I'm awake now, it's gone. Sorry about that. Thanks for the dump, I'll figure out what's going on - this is a strange one, we didn't touch anything related to i8n... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Jun 28 06:43:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SDhdR24840 for linux-xfs-outgoing; Thu, 28 Jun 2001 06:43:39 -0700 Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SDhcV24833 for ; Thu, 28 Jun 2001 06:43:38 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id PAA333524 for ; Thu, 28 Jun 2001 15:43:28 +0200 Received: from d12ml014.de.ibm.com (d12ml014_cs0 [9.165.223.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5SDhSG110528 for ; Thu, 28 Jun 2001 15:43:29 +0200 Subject: Contraint to Blksize 512? To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Holger Smolinski" Date: Thu, 28 Jun 2001 15:37:01 +0200 X-MIMETrack: Serialize by Router on D12ML014/12/M/IBM(Release 5.0.6 |December 14, 2000) at 28/06/2001 15:41:01 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I tried to use XFS with devices of sector sizes larger than 512 Byte and failed. Apparently there are dependencies to a fixed blocksize of 512 Byte all over the code of XFS. Are these contraints unavoidable by the design of XFS or could you imagine running an XFS e.g. on a device with 4k blocksize and what needs to be done to the code in order to do so? Gruesse / Regards Dr. Holger Smolinski -- Linux for eServer Development, IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, D-71032 Boeblingen Phone/FAX: +49 7031 16 (x902) - 4652/3456 From owner-linux-xfs@oss.sgi.com Thu Jun 28 06:53:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SDrkR26677 for linux-xfs-outgoing; Thu, 28 Jun 2001 06:53:46 -0700 Received: from gwyn.tux.org (ident-user@gwyn.tux.org [207.96.122.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SDrjV26674 for ; Thu, 28 Jun 2001 06:53:45 -0700 Received: (from timball@localhost) by gwyn.tux.org (8.9.3/8.9.1) id JAA24203 for linux-xfs@oss.sgi.com; Thu, 28 Jun 2001 09:53:44 -0400 Date: Thu, 28 Jun 2001 09:53:44 -0400 From: Timothy Ball To: XFS Mailing List Subject: Re: Filesystem conversion Message-ID: <20010628095344.D3920@gwyn.tux.org> References: <01062812533100.01258@citadel.oehansen.pp.se> <4.3.2.7.2.20010628132843.02f35510@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <4.3.2.7.2.20010628132843.02f35510@pop.xs4all.nl>; from knuffie@xs4all.nl on Thu, Jun 28, 2001 at 01:34:00PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Jun 28, 2001 at 01:34:00PM +0200, Seth Mos wrote: > Boot single user > dump.static -0 -a -f /mnt/hde/var.dump /var > umount /var > mkfs.xfs -l size=32768b -f /dev/sda7 > vi /etc/fstab (change fstype) > mount /var > cd /var > restore.static -rf /mnt/hde/var.dump I've written some shell scripts ment to be run as a single user that already do this. They're available at www.tux.org/~timball/. It uses spare space on another device and a loopback to do the dump and restore... course I'm using cp -dRp or some flags like that... what's the benifits of using dump? --timball -- Send mail with subject "send pgp key" for public key. pub 1024R/CFF85605 1999-06-10 Timothy L. Ball Key fingerprint = 8A 8E 64 D6 21 C0 90 29 9F D6 1E DC F8 18 CB CD From owner-linux-xfs@oss.sgi.com Thu Jun 28 06:54:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SDsOl26847 for linux-xfs-outgoing; Thu, 28 Jun 2001 06:54:24 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SDsKV26829 for ; Thu, 28 Jun 2001 06:54:20 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id PAA447476 for ; Thu, 28 Jun 2001 15:54:17 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA2201240; Thu, 28 Jun 2001 08:53:00 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA01796; Thu, 28 Jun 2001 08:53:00 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5SDsmp15488; Thu, 28 Jun 2001 08:54:48 -0500 Message-Id: <200106281354.f5SDsmp15488@jen.americas.sgi.com> To: "Holger Smolinski" cc: linux-xfs@oss.sgi.com Subject: Re: Contraint to Blksize 512? References: Comments: In-reply-to "Holger Smolinski" message dated "Thu, 28 Jun 2001 15:37:01 +0200." Date: Thu, 28 Jun 2001 08:54:48 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hello, > I tried to use XFS with devices of sector sizes larger than 512 Byte and > failed. > Apparently there are dependencies to a fixed blocksize of 512 Byte all over > the code of XFS. > Are these contraints unavoidable by the design of XFS or could you imagine > running an XFS e.g. on a device with 4k blocksize and what needs to be done > to the code in order to do so? > > Gruesse / Regards > Dr. Holger Smolinski Yes, unfortunately XFS is built around assumptions about 512 byte block sizes. There was an internal project to clean this up which was shelved a while back, I will ask around and see if the code still exists. I think this would end up with an incompatible on disk format, given that some structures would change size, but I think that would be an acceptable solution for devices with a larger block size. I mentioned one of the aspects in email yesterday, there are some 512 byte long metadata objects which need to be separately accessible on disk. The one I forgot is the log, which is written in 512 byte chunks. Steve From owner-linux-xfs@oss.sgi.com Thu Jun 28 07:13:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SED1q28934 for linux-xfs-outgoing; Thu, 28 Jun 2001 07:13:01 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SED1V28931 for ; Thu, 28 Jun 2001 07:13:01 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA09938 for ; Thu, 28 Jun 2001 07:13:00 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2262705; Thu, 28 Jun 2001 09:11:43 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA92583; Thu, 28 Jun 2001 09:11:43 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5SEDWq15561; Thu, 28 Jun 2001 09:13:32 -0500 Message-Id: <200106281413.f5SEDWq15561@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: stimits@idcomm.com cc: linux-xfs@oss.sgi.com Subject: Re: fatal error -- couldn't initialize XFS library Date: Thu, 28 Jun 2001 09:13:32 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk OK, I had a problem on a system here doing some extreme testing, and had to attempt a repair on a root filesystem myself - from a remote location. I have managed to make xfs_repair -n run, here is what I did: 1. Boot the system single user, I used this: xfs-2.4.6 ro root=/dev/hda1 init=/bin/sh 2. remount the root filesystem read/write: /bin/mount -o remount,rw /dev/hda1 3. edit /etc/mtab and make sure that / shows up with a ro mount: /dev/hda1 / xfs ro 0 0 4. remount the filesystem readonly: /bin/mount -o remount,ro /dev/hda1 You can now run xfs_repair -n on the filesystem, it will still not let you do an actual repair on it. Steve p.s. I faked the header here, so it will not show up as a followup. From owner-linux-xfs@oss.sgi.com Thu Jun 28 07:52:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SEqFE31248 for linux-xfs-outgoing; Thu, 28 Jun 2001 07:52:15 -0700 Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SEqDV31245 for ; Thu, 28 Jun 2001 07:52:13 -0700 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id QAA237006; Thu, 28 Jun 2001 16:52:00 +0200 Received: from d12ml014.de.ibm.com (d12ml014_cs0 [9.165.223.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5SEpsf128340; Thu, 28 Jun 2001 16:51:54 +0200 Subject: Re: Contraint to Blksize 512? To: Steve Lord Cc: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Holger Smolinski" Date: Thu, 28 Jun 2001 16:49:13 +0200 X-MIMETrack: Serialize by Router on D12ML014/12/M/IBM(Release 5.0.6 |December 14, 2000) at 28/06/2001 16:49:28 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> Hello, >> I tried to use XFS with devices of sector sizes larger than 512 Byte and >> failed. >> Apparently there are dependencies to a fixed blocksize of 512 Byte all over >> the code of XFS. >> Are these contraints unavoidable by the design of XFS or could you imagine >> running an XFS e.g. on a device with 4k blocksize and what needs to be done >> to the code in order to do so? >Yes, unfortunately XFS is built around assumptions about 512 byte block >sizes. There was an internal project to clean this up which was shelved >a while back, I will ask around and see if the code still exists. I >think this would end up with an incompatible on disk format, given that >some structures would change size, but I think that would be an acceptable >solution for devices with a larger block size. For sure we would have incompatible layouts between XFS(512) and XFS(4k). I'd imagine sth like replacing any 512 in the XFS code by blksize(device) or blksize(xfs-type) rsp. Do you see any design obstacles in doing so? Gruesse / Regards Dr. Holger Smolinski From owner-linux-xfs@oss.sgi.com Thu Jun 28 09:49:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SGnTV02680 for linux-xfs-outgoing; Thu, 28 Jun 2001 09:49:29 -0700 Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SGnRV02675 for ; Thu, 28 Jun 2001 09:49:28 -0700 Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:64821 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Thu, 28 Jun 2001 18:49:36 +0200 Message-Id: <4.3.2.7.2.20010628184351.030dec00@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Jun 2001 18:49:01 +0200 To: Timothy Ball , XFS Mailing List From: Seth Mos Subject: Re: Filesystem conversion In-Reply-To: <20010628095344.D3920@gwyn.tux.org> References: <4.3.2.7.2.20010628132843.02f35510@pop.xs4all.nl> <01062812533100.01258@citadel.oehansen.pp.se> <4.3.2.7.2.20010628132843.02f35510@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 09:53 28-6-2001 -0400, Timothy Ball wrote: >On Thu, Jun 28, 2001 at 01:34:00PM +0200, Seth Mos wrote: > > Boot single user > > dump.static -0 -a -f /mnt/hde/var.dump /var > > umount /var > > mkfs.xfs -l size=32768b -f /dev/sda7 > > vi /etc/fstab (change fstype) > > mount /var > > cd /var > > restore.static -rf /mnt/hde/var.dump > >I've written some shell scripts ment to be run as a single user that >already do this. They're available at www.tux.org/~timball/. It uses >spare space on another device and a loopback to do the dump and >restore... > >course I'm using cp -dRp or some flags like that... what's the benifits >of using dump? If it's large it will give you a progress counter in hours:minutes to completion. So you can see it as an indicator of how long I can keep interneting before I need to do something useful again. It also keeps within the filesystem and it produces one or more file with an entire filesystem or you could even dump it on tape. We have a Ultrium tape driver over here that can manage more then 10MB/s which means you can dump and restore pretty quick. It also produces errors when something is going bonkers and should be noticed. Tar could also do this, but dump/restore were written specially for this cause. If you decide to edit the script make sure to use the dump.static version in case someone decides to backup their /usr partition on a single user booted system. I made this mistake once already. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Jun 28 10:05:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SH5gR03138 for linux-xfs-outgoing; Thu, 28 Jun 2001 10:05:42 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SH5eV03135 for ; Thu, 28 Jun 2001 10:05:40 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id B598A1AB0F for ; Thu, 28 Jun 2001 13:05:39 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id 1C4C3120B; Thu, 28 Jun 2001 13:05:39 -0400 (EDT) Date: Thu, 28 Jun 2001 13:05:39 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Specify XFS in kickstart file? Message-ID: <20010628130538.C6735@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.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk So... would I be able to specify a filesystem type of xfs for a partition in a kickstart file? (I don't see any option to do so - partition type, yes, filesystem type, no.) Andrew Klaassen From owner-linux-xfs@oss.sgi.com Thu Jun 28 10:12:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SHCSk03286 for linux-xfs-outgoing; Thu, 28 Jun 2001 10:12:28 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SHCQV03283 for ; Thu, 28 Jun 2001 10:12:26 -0700 Received: from thebarn.com ([63.231.179.33]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f5SHC8Ne095555; Thu, 28 Jun 2001 12:12:09 -0500 (CDT) Message-ID: <3B3B588F.F31B7AA@thebarn.com> Date: Thu, 28 Jun 2001 11:17:19 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: PR3 1.0.1 iso fails References: <4.3.2.7.2.20010628152727.02f0ea68@pop.xs4all.nl> <3B3B3370.16D6BA7@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > > Seth Mos wrote: > > > May I suggest yanking the ISO please? > > Yep, I'm awake now, it's gone. Sorry about that. > > Thanks for the dump, I'll figure out what's going on - this is a strange > one, we didn't touch anything related to i8n... Strange things can happen if not all the rpm's that are required for the stage2 image are not available (and not the build script does not report things missing. check for glic-common that is where the NLS stuff comes from. > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Jun 28 10:28:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SHS3503608 for linux-xfs-outgoing; Thu, 28 Jun 2001 10:28:03 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SHS1V03605 for ; Thu, 28 Jun 2001 10:28:01 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id TAA15172 for ; Thu, 28 Jun 2001 19:27:59 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id TAA06183 for linux-xfs@oss.sgi.com; Thu, 28 Jun 2001 19:27:58 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id B9D0457306 for ; Thu, 28 Jun 2001 19:37:12 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id E128A25835 for ; Thu, 28 Jun 2001 19:45:23 +0200 (CEST) Message-ID: <3B3B6A45.3252B37C@ch.sauter-bc.com> Date: Thu, 28 Jun 2001 19:32:53 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: linux-xfs Subject: XFS corruption on SoftRAID5 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I don't know what to try anymore... I'm getting XFS filesystem corruption, I can see this when using ls or du. Filenames are corrupted and also their content. I was doing the first test on a DELL Precision Workstation with 4 IDE drives but I have changed now. So let me explain what exactly I'm doing. I have set up a DELL PowerEdge 1400 Server, PIII800 / 256MB / ServerWorks CNB20LE. Two U160-SCSI Disks on the first onboard controller (AIC-7899). /, /boot and 2x1GB swap are on SoftRAID1 on those two disks. Until here, no problem at all, using kernel PR1-PR3. Then I installed one Promise Ultra100TX2 IDE controller, connecting 4 IBM 60GB drives. I created 1 RAID5 on those 4 drives. I then do a 'sysctl -w dev.raid.speed_limit_min=10000' to resync the raid faster, otherwise it takes days to sync. Then while syncing, I create an XFS filsystem on it and mount it on /home. Now I copy some GB of data from 2 NFS servers (while it is still syncing). This is going slow because of high priority syncing, but beside that, not problem at all. Later then, after the sync has finished and after some reboots, I just made an ls -R /home and found out that the filnames were corrupt. I know that what I did is a torture for the system, but it should be able to handle such situations. Can somebody tell me what could cause the problem. Could it be the combination of RAID5 / XFS / syncing / heavy load? Unfortunately there is absolutely noting to find in the kernel logs. My next steps before giving up: - I have installed a second Prosime controller to make sure every IDE disk has it's own channel. (Don't blame Promise, I had exactly the same prob with the i820 IDE of the DELL Precision 220). Test is running right now... - Configuring the 4 IDE disks as RAID10 and test again. I will loose 60GB, but at least we then know that SoftRAID5 with IDE with XFS with ... with ... is DANGEROUS(tm). - Try with ext2 on the RAID5 :-( Thanks in advance for any help Simon From owner-linux-xfs@oss.sgi.com Thu Jun 28 11:24:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SIOs905158 for linux-xfs-outgoing; Thu, 28 Jun 2001 11:24:54 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SIOrV05144 for ; Thu, 28 Jun 2001 11:24:53 -0700 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA10687 for ; Thu, 28 Jun 2001 11:24:46 -0700 (PDT) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA39999 for ; Thu, 28 Jun 2001 11:29:04 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 6A40A15A471 for ; Thu, 28 Jun 2001 11:23:31 -0700 (PDT) Subject: Re: Release 1.0.1 - PR3 From: Florin Andrei To: linux-xfs@oss.sgi.com In-Reply-To: <3B3A6D29.D2120EE4@sgi.com> References: <3B3A6D29.D2120EE4@sgi.com> Content-Type: text/plain X-Mailer: Evolution/0.10 (Preview Release) Date: 28 Jun 2001 11:23:31 -0700 Message-Id: <993752611.32152.14.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 27 Jun 2001 18:32:57 -0500, Eric Sandeen wrote: > > CHANGES since PR2: > > - Red Hat-like kernels are now 2.4.3 So, these are actually the latest Red Hat kernels, with XFS patch applied, right? > - devfs is enabled, but not mounted in the Kernel RPMs > pass "devfs=mount" in lilo to use devfs. This is great! devfs was such a pain in 1.0, sometimes. -- Florin Andrei From owner-linux-xfs@oss.sgi.com Thu Jun 28 11:28:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SIScC05749 for linux-xfs-outgoing; Thu, 28 Jun 2001 11:28:38 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SISbV05745 for ; Thu, 28 Jun 2001 11:28:37 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA00207 for ; Thu, 28 Jun 2001 11:25:48 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2287287; Thu, 28 Jun 2001 13:27:19 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA97405; Thu, 28 Jun 2001 13:27:19 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5SIT6u22059; Thu, 28 Jun 2001 13:29:06 -0500 Message-Id: <200106281829.f5SIT6u22059@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Florin Andrei cc: linux-xfs@oss.sgi.com Subject: Re: Release 1.0.1 - PR3 In-Reply-To: Message from Florin Andrei of "28 Jun 2001 11:23:31 PDT." <993752611.32152.14.camel@stantz.corp.sgi.com> Date: Thu, 28 Jun 2001 13:29:06 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On 27 Jun 2001 18:32:57 -0500, Eric Sandeen wrote: > > > > CHANGES since PR2: > > > > - Red Hat-like kernels are now 2.4.3 > > So, these are actually the latest Red Hat kernels, with XFS patch > applied, right? Yep, this is the new one from last weekend. Steve > > > - devfs is enabled, but not mounted in the Kernel RPMs > > pass "devfs=mount" in lilo to use devfs. > > This is great! devfs was such a pain in 1.0, sometimes. > > -- > Florin Andrei From owner-linux-xfs@oss.sgi.com Thu Jun 28 11:41:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SIfBT07135 for linux-xfs-outgoing; Thu, 28 Jun 2001 11:41:11 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SIf9V07128 for ; Thu, 28 Jun 2001 11:41:09 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA483846 for ; Thu, 28 Jun 2001 20:41:07 +0200 (CEST) mail_from (sandeen@sgi.com) Received: from sgi.com (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA39515; Thu, 28 Jun 2001 11:40:33 -0700 (PDT) Message-ID: <3B3B7982.6985E0E5@sgi.com> Date: Thu, 28 Jun 2001 13:37:54 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Klaassen CC: linux-xfs@oss.sgi.com Subject: Re: Specify XFS in kickstart file? References: <20010628130538.C6735@dkp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andrew Klaassen wrote: > > So... would I be able to specify a filesystem type of xfs for a > partition in a kickstart file? (I don't see any option to do so > - partition type, yes, filesystem type, no.) Yep, put "--fs xfs" or "--fs ext2" after the "part" command (actually, xfs is the default, anything other than "ext2" will give you xfs on that partitions. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Jun 28 13:41:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SKfAF16721 for linux-xfs-outgoing; Thu, 28 Jun 2001 13:41:10 -0700 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SKf9V16717 for ; Thu, 28 Jun 2001 13:41:09 -0700 Received: from idcomm.com (IDENT:stimits@k56-pip43.idcomm.com [209.60.72.170]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f5SKgbl03402 for ; Thu, 28 Jun 2001 14:42:37 -0600 Message-ID: <3B3B96D0.54416449@idcomm.com> Date: Thu, 28 Jun 2001 14:42:56 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: fatal error -- couldn't initialize XFS library References: <200106281413.f5SEDWq15561@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > > OK, I had a problem on a system here doing some extreme testing, and > had to attempt a repair on a root filesystem myself - from a remote > location. > > I have managed to make xfs_repair -n run, here is what I did: > > 1. Boot the system single user, I used this: > > xfs-2.4.6 ro root=/dev/hda1 init=/bin/sh > > 2. remount the root filesystem read/write: > > /bin/mount -o remount,rw /dev/hda1 > > 3. edit /etc/mtab and make sure that / shows up with a ro mount: > > /dev/hda1 / xfs ro 0 0 > > 4. remount the filesystem readonly: > > /bin/mount -o remount,ro /dev/hda1 > > You can now run xfs_repair -n on the filesystem, it will still not let > you do an actual repair on it. > > Steve > > p.s. > > I faked the header here, so it will not show up as a followup. I'm being delayed by a gnome problem in doing more testing. Basically X11 died (hard lockup, no ping, magic sysrq dead) during a regular user login, and now it is giving me security grief (it messed up something in the Xauth stuff). I can no longer login my regular user with gnome, I have to use KDE or something else other than gnome. I see the advantage of the above approach is that it marks the drive ro from the start, so inaccurate mtab listings will always be inaccurate in the direction of marking ro. I'll add this as part of my experiment list when I get gnome working right again. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Thu Jun 28 13:52:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SKqFG17037 for linux-xfs-outgoing; Thu, 28 Jun 2001 13:52:15 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SKqFV17034 for ; Thu, 28 Jun 2001 13:52:15 -0700 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA02443 for ; Thu, 28 Jun 2001 13:52:08 -0700 (PDT) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA04004 for ; Thu, 28 Jun 2001 13:56:31 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 57F8815A471 for ; Thu, 28 Jun 2001 13:50:58 -0700 (PDT) Subject: upgrade From: Florin Andrei To: linux-xfs@oss.sgi.com Content-Type: text/plain X-Mailer: Evolution/0.10 (Preview Release) Date: 28 Jun 2001 13:50:58 -0700 Message-Id: <993761458.32474.20.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Do you think it's ok to upgrade a system installed from Release-1.0 with the kernel RPMs from PR3? -- Florin Andrei From owner-linux-xfs@oss.sgi.com Thu Jun 28 14:01:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SL18m17227 for linux-xfs-outgoing; Thu, 28 Jun 2001 14:01:08 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SL16V17224 for ; Thu, 28 Jun 2001 14:01:06 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA03849 for ; Thu, 28 Jun 2001 14:00:59 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2290590; Thu, 28 Jun 2001 15:59:35 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA38906; Thu, 28 Jun 2001 15:59:35 -0500 (CDT) Message-ID: <3B3B9A83.18BB4B4A@sgi.com> Date: Thu, 28 Jun 2001 15:58:43 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Florin Andrei CC: linux-xfs@oss.sgi.com Subject: Re: upgrade References: <993761458.32474.20.camel@stantz.corp.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Florin Andrei wrote: > > Do you think it's ok to upgrade a system installed from Release-1.0 with > the kernel RPMs from PR3? Well, that's what they're designed for. At least by the time that they reach the final 1.0.1. ;) There haven't been any horrible problems w/ the RH2.4.3/XFS1.0.1-PR3 RPMS AFAIK, so back up your data (as with any major upgrade) and give it a shot. -Eric From owner-linux-xfs@oss.sgi.com Thu Jun 28 14:04:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SL4ru17362 for linux-xfs-outgoing; Thu, 28 Jun 2001 14:04:53 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SL4qV17358 for ; Thu, 28 Jun 2001 14:04:52 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA04496 for ; Thu, 28 Jun 2001 14:04:45 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2279146; Thu, 28 Jun 2001 16:03:34 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA49101; Thu, 28 Jun 2001 16:03:34 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5SL5Kh23702; Thu, 28 Jun 2001 16:05:20 -0500 Message-Id: <200106282105.f5SL5Kh23702@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Florin Andrei cc: linux-xfs@oss.sgi.com Subject: Re: upgrade In-Reply-To: Message from Florin Andrei of "28 Jun 2001 13:50:58 PDT." <993761458.32474.20.camel@stantz.corp.sgi.com> Date: Thu, 28 Jun 2001 16:05:20 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Do you think it's ok to upgrade a system installed from Release-1.0 with > the kernel RPMs from PR3? > > -- > Florin Andrei This is the intended way of upgrading. You should pick up new command rpms as well. Steve From owner-linux-xfs@oss.sgi.com Thu Jun 28 14:24:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SLOqA17743 for linux-xfs-outgoing; Thu, 28 Jun 2001 14:24:52 -0700 Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SLOnV17740 for ; Thu, 28 Jun 2001 14:24:50 -0700 Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:62698 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Thu, 28 Jun 2001 23:24:53 +0200 Message-Id: <4.3.2.7.2.20010628232151.02ee7890@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Jun 2001 23:24:26 +0200 To: Florin Andrei , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: upgrade In-Reply-To: <993761458.32474.20.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:50 28-6-2001 -0700, Florin Andrei wrote: >Do you think it's ok to upgrade a system installed from Release-1.0 with >the kernel RPMs from PR3? Yes, this is the only change for 1.0.1. I don't know about the stability of the 2.4.3 based kernel but I am using 2.4.5 or later based kernels for my production machines. I probably got hit by lightning or something to think that they are better. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Jun 28 14:46:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SLk6618128 for linux-xfs-outgoing; Thu, 28 Jun 2001 14:46:06 -0700 Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SLk3V18124 for ; Thu, 28 Jun 2001 14:46:03 -0700 Received: from thwaite-clued0.fnal.gov ([131.225.224.130]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GFN00BPLTSQQP@smtp.fnal.gov> for linux-xfs@oss.sgi.com; Thu, 28 Jun 2001 16:46:03 -0500 (CDT) Date: Thu, 28 Jun 2001 16:46:02 -0500 (CDT) From: Roger Moore Subject: Label based mounts with fsck To: linux-xfs@oss.sgi.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, We've just updated our cluster to use XFS and have noticed a problem with using 'LABEL=xxx' in the fstab file. The 'mount' command works fine with XFS labels (once you turn off devfs!). However the problem lies with the fsck command. The RedHat 7.1 system we have runs 'fsck -A...' at boot time which is needed for the remaining ext2 partitions. This complains that it cannont find 'LABEL=xxx' for XFS partitions even when we configure /etc/fstab has f_passno=0 for the XFS mounts. Is there a patch out there for fsck to fix this problem? We are currently using e2fsprogs-1.21 from RawHide since it is needed for the 2.4.5-0.2.9 RawHide kernel which you have patched. Thanks, Roger From owner-linux-xfs@oss.sgi.com Thu Jun 28 14:48:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SLmJh18174 for linux-xfs-outgoing; Thu, 28 Jun 2001 14:48:19 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SLmHV18168 for ; Thu, 28 Jun 2001 14:48:17 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA01382 for ; Thu, 28 Jun 2001 14:45:28 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2289846; Thu, 28 Jun 2001 16:46:56 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA36337; Thu, 28 Jun 2001 16:46:56 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5SLmfw24451; Thu, 28 Jun 2001 16:48:41 -0500 Message-Id: <200106282148.f5SLmfw24451@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Simon Matter cc: linux-xfs Subject: Re: XFS corruption on SoftRAID5 In-Reply-To: Message from Simon Matter of "Thu, 28 Jun 2001 19:32:53 +0200." <3B3B6A45.3252B37C@ch.sauter-bc.com> Date: Thu, 28 Jun 2001 16:48:41 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I don't know what to try anymore... First rule of bug reporting, which version of the kernel are you using? Oh, and what type of NFS servers? Details, details please. Steve > > I'm getting XFS filesystem corruption, I can see this when using ls or > du. Filenames are corrupted and also their content. I was doing the > first test on a DELL Precision Workstation with 4 IDE drives but I have > changed now. So let me explain what exactly I'm doing. > > I have set up a DELL PowerEdge 1400 Server, PIII800 / 256MB / > ServerWorks CNB20LE. Two U160-SCSI Disks on the first onboard controller > (AIC-7899). /, /boot and 2x1GB swap are on SoftRAID1 on those two disks. > Until here, no problem at all, using kernel PR1-PR3. Then I installed > one Promise Ultra100TX2 IDE controller, connecting 4 IBM 60GB drives. I > created 1 RAID5 on those 4 drives. I then do a 'sysctl -w > dev.raid.speed_limit_min=10000' to resync the raid faster, otherwise it > takes days to sync. Then while syncing, I create an XFS filsystem on it > and mount it on /home. Now I copy some GB of data from 2 NFS servers > (while it is still syncing). This is going slow because of high priority > syncing, but beside that, not problem at all. Later then, after the sync > has finished and after some reboots, I just made an ls -R /home and > found out that the filnames were corrupt. I know that what I did is a > torture for the system, but it should be able to handle such situations. > Can somebody tell me what could cause the problem. Could it be the > combination of RAID5 / XFS / syncing / heavy load? Unfortunately there > is absolutely noting to find in the kernel logs. > > My next steps before giving up: > - I have installed a second Prosime controller to make sure every IDE > disk has it's own channel. (Don't blame Promise, I had exactly the same > prob with the i820 IDE of the DELL Precision 220). Test is running right > now... > > - Configuring the 4 IDE disks as RAID10 and test again. I will loose > 60GB, but at least we then know that SoftRAID5 with IDE with XFS with > ... with ... is DANGEROUS(tm). > > - Try with ext2 on the RAID5 :-( > > Thanks in advance for any help > > Simon > From owner-linux-xfs@oss.sgi.com Thu Jun 28 15:46:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SMkJU19034 for linux-xfs-outgoing; Thu, 28 Jun 2001 15:46:19 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SMkHV19031 for ; Thu, 28 Jun 2001 15:46:17 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5SMkBR06702 for linux-xfs@oss.sgi.com; Thu, 28 Jun 2001 18:46:11 -0400 Date: Thu, 28 Jun 2001 18:46:10 -0400 From: Alan Eldridge To: Linux XFS Mailing List Subject: Re: Label based mounts with fsck Message-ID: <20010628184610.A20337@wwweasel.geeksrus.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwmoore@fnal.gov on Thu, Jun 28, 2001 at 04:46:02PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Jun 28, 2001 at 04:46:02PM -0500, Roger Moore wrote: >Hi, > >We've just updated our cluster to use XFS and have noticed a problem with >using 'LABEL=xxx' in the fstab file. 1. fsck has a bug in the LABEL=xxx handling code. It behaves badly (and non-deterministically) iff sizeof(/proc/partitions) > 1K. 1a. If you have a lot of partitions, and a big /proc/partitions, you could be getting stomped by this. But it typically only affects N partitions, where N = sizeof(/proc/partitions)/1024. That is, it pukes at each 1K boundary. 1b. This generally only happens on the initial mount. It's due to the contents of /proc/partitions changing (getting bigger) in between the time that fsck reads the first 1K and the next 1K from the file. The next 1K block does not start, in terms of the file's contents, where the first 1K block ended. The lines become misaligned. 2. Look at your /proc/partitions. Are there XFS volume labels in there? If not, then that's your problem. fsck reads /proc/partitions to get the label information. If they are there, then you might want to run fsck under gdb to watch it go through the fstab file... BTW The label code from mount is NOT the same code used in fsck (reuse? whazzat?) but it is vulnerable to the same error condition as mentioned in 1 above. -- Alan Eldridge "Smart Tags? We don't need no steenking Smart Tags!" From owner-linux-xfs@oss.sgi.com Thu Jun 28 15:52:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SMqDI19170 for linux-xfs-outgoing; Thu, 28 Jun 2001 15:52:13 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SMqCV19165 for ; Thu, 28 Jun 2001 15:52:13 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5SMq7X12724 for linux-xfs@oss.sgi.com; Thu, 28 Jun 2001 18:52:07 -0400 Date: Thu, 28 Jun 2001 18:52:07 -0400 From: Alan Eldridge To: Linux XFS Mailing List Subject: labels and fsck Message-ID: <20010628185207.A11365@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The fsck in Rawhide has my fix for the big /proc/partitions bug. So it isn't that. To check if that is patched, do rpm -q --changelog e2fsprogs | grep geeksrus. If the grep finds my mail address, then that bug is fixed in your version. -- Alan Eldridge "Smart Tags? We don't need no steenking Smart Tags!" From owner-linux-xfs@oss.sgi.com Thu Jun 28 16:02:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SN2RC19370 for linux-xfs-outgoing; Thu, 28 Jun 2001 16:02:27 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SN2QV19367 for ; Thu, 28 Jun 2001 16:02:26 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA21276 for ; Thu, 28 Jun 2001 16:02:20 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA2258631; Thu, 28 Jun 2001 18:00:26 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA76390; Thu, 28 Jun 2001 18:00:26 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5SN2BX30955; Thu, 28 Jun 2001 18:02:11 -0500 Message-Id: <200106282302.f5SN2BX30955@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Holger Smolinski" cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: Contraint to Blksize 512? In-Reply-To: Message from "Holger Smolinski" of "Thu, 28 Jun 2001 16:49:13 +0200." Date: Thu, 28 Jun 2001 18:02:11 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > >> Hello, > >> I tried to use XFS with devices of sector sizes larger than 512 Byte and > >> failed. > >> Apparently there are dependencies to a fixed blocksize of 512 Byte all > over > >> the code of XFS. > >> Are these contraints unavoidable by the design of XFS or could you > imagine > >> running an XFS e.g. on a device with 4k blocksize and what needs to be > done > >> to the code in order to do so? > >Yes, unfortunately XFS is built around assumptions about 512 byte block > >sizes. There was an internal project to clean this up which was shelved > >a while back, I will ask around and see if the code still exists. I > >think this would end up with an incompatible on disk format, given that > >some structures would change size, but I think that would be an acceptable > >solution for devices with a larger block size. > > For sure we would have incompatible layouts between XFS(512) and XFS(4k). > I'd imagine sth like replacing any 512 in the XFS code by blksize(device) > or blksize(xfs-type) rsp. > Do you see any design obstacles in doing so? I have just taken a look at an old project which was doing exactly this, XFS was extended to be runtime switchable between blocksizes. The code is against an old version of Irix, so it is not so easy to extract into a linux tree, but it looks like most of the changes are there. It is a little more complex than just looking for uses of 512 though. I will dig into this some more. Steve > > Gruesse / Regards > Dr. Holger Smolinski > > > > > From owner-linux-xfs@oss.sgi.com Thu Jun 28 16:10:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SNAVf19540 for linux-xfs-outgoing; Thu, 28 Jun 2001 16:10:31 -0700 Received: from citadel.oehansen.pp.se (sdu94-204.ppp.algonet.se [195.163.204.94]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SNASV19537 for ; Thu, 28 Jun 2001 16:10:28 -0700 Received: from citadel.oehansen.pp.se (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f5SN8w002093 for ; Fri, 29 Jun 2001 01:08:58 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se To: linux-xfs@oss.sgi.com Subject: RedHat PR3 i686 kernel Date: Fri, 29 Jun 2001 01:08:58 +0200 X-Mailer: KMail [version 1.2] X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I downloaded the kernel for 1.0.1 PR3, i686 version, and have a few problems using it on a RedHat 7.1 version. 1. The kernel won't load LABEL= mount entries in the fstab. 2. I'm using NVIDIA's kernel driver 0.9-769 and it won't compile, and gives the following reasons, when the compiled driver is insmod'ed. ./NVdriver: unresolved symbol __pollwait_R8f03d002 ./NVdriver: unresolved symbol mem_map_Rfd150a02 ./NVdriver: unresolved symbol init_mm_R2bfca886 ./NVdriver: unresolved symbol remove_proc_entry_R719f1bc6 ./NVdriver: unresolved symbol register_chrdev_R354470b2 ./NVdriver: unresolved symbol irq_stat_R23f3d834 ./NVdriver: unresolved symbol vsprintf_R954cbb26 ./NVdriver: unresolved symbol proc_root_R204b90fc ./NVdriver: unresolved symbol create_proc_entry_R9741b1ea Orn From owner-linux-xfs@oss.sgi.com Thu Jun 28 16:13:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SNDOc19671 for linux-xfs-outgoing; Thu, 28 Jun 2001 16:13:24 -0700 Received: from afaranis1.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SNDOV19668 for ; Thu, 28 Jun 2001 16:13:24 -0700 Received: from tduffy-lnx.afara.com (tduffy-lnx.afara.com [10.2.4.191]) by afaranis1.afara.com (8.9.3/8.9.3) with ESMTP id QAA12071; Thu, 28 Jun 2001 16:13:11 -0700 (PDT) Subject: Re: RedHat PR3 i686 kernel From: Thomas Duffy To: oe.hansen@gamma.telenordia.se Cc: linux-xfs@oss.sgi.com In-Reply-To: <01062901085801.01999@citadel.oehansen.pp.se> References: <01062901085801.01999@citadel.oehansen.pp.se> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.10.99 (Preview Release) Date: 28 Jun 2001 16:12:29 -0700 Message-Id: <993769949.3312.0.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > 2. I'm using NVIDIA's kernel driver 0.9-769 and it won't compile, and > gives the following reasons, when the compiled driver is insmod'ed. I would use the 1.0-1251 for 2.4.x kernels. -tduffy From owner-linux-xfs@oss.sgi.com Thu Jun 28 16:18:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SNIKO19807 for linux-xfs-outgoing; Thu, 28 Jun 2001 16:18:20 -0700 Received: from citadel.oehansen.pp.se (sdu94-204.ppp.algonet.se [195.163.204.94]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SNIFV19804 for ; Thu, 28 Jun 2001 16:18:15 -0700 Received: from citadel.oehansen.pp.se (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f5SNIno02148; Fri, 29 Jun 2001 01:18:57 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se To: Alan Eldridge , Linux XFS Mailing List Subject: Re: Label based mounts with fsck Date: Fri, 29 Jun 2001 01:18:48 +0200 X-Mailer: KMail [version 1.2] References: <20010628184610.A20337@wwweasel.geeksrus.net> In-Reply-To: <20010628184610.A20337@wwweasel.geeksrus.net> X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 X-MIME-Autoconverted: from 8bit to quoted-printable by citadel.oehansen.pp.se id f5SNIno02148 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5SNIJV19805 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk föstudagur 29. júní 2001 00:46, Alan Eldridge skrifaði: > On Thu, Jun 28, 2001 at 04:46:02PM -0500, Roger Moore wrote: > >Hi, > > > >We've just updated our cluster to use XFS and have noticed a problem with > >using 'LABEL=xxx' in the fstab file. > I've used vanilla 2.4.5 kernel, with PR2 code, without problems. The problem only appears, when I use the SGI built kernels. Orn From owner-linux-xfs@oss.sgi.com Thu Jun 28 16:31:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SNVks19966 for linux-xfs-outgoing; Thu, 28 Jun 2001 16:31:46 -0700 Received: from citadel.oehansen.pp.se (sdu94-204.ppp.algonet.se [195.163.204.94]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SNVNV19954 for ; Thu, 28 Jun 2001 16:31:28 -0700 Received: from citadel.oehansen.pp.se (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f5SNVio02212; Fri, 29 Jun 2001 01:32:15 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se To: Thomas Duffy , oe.hansen@gamma.telenordia.se Subject: Re: RedHat PR3 i686 kernel Date: Fri, 29 Jun 2001 01:31:44 +0200 X-Mailer: KMail [version 1.2] Cc: linux-xfs@oss.sgi.com References: <01062901085801.01999@citadel.oehansen.pp.se> <993769949.3312.0.camel@tduffy-lnx.afara.com> In-Reply-To: <993769949.3312.0.camel@tduffy-lnx.afara.com> X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 X-MIME-Autoconverted: from 8bit to quoted-printable by citadel.oehansen.pp.se id f5SNVio02212 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5SNVjV19964 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk föstudagur 29. júní 2001 01:12, Thomas Duffy skrifaði: > > 2. I'm using NVIDIA's kernel driver 0.9-769 and it won't compile, and > > gives the following reasons, when the compiled driver is > > insmod'ed. > > I would use the 1.0-1251 for 2.4.x kernels. > I can't ... that version doesn't work for my card. From owner-linux-xfs@oss.sgi.com Thu Jun 28 16:33:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SNXtg20110 for linux-xfs-outgoing; Thu, 28 Jun 2001 16:33:55 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SNXUV20087 for ; Thu, 28 Jun 2001 16:33:30 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id TAA08141; Thu, 28 Jun 2001 19:27:04 -0400 Message-ID: <3B3BC18C.FF7C9E2E@ieee.org> Date: Thu, 28 Jun 2001 19:45:16 -0400 From: "Bryan J. Smith" Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Simon Matter CC: linux-xfs Subject: Re: XFS corruption on SoftRAID5 References: <3B3B6A45.3252B37C@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter wrote: > Then I installed one Promise Ultra100TX2 IDE controller, > connecting 4 IBM 60GB drives. Ouch! Talk about a performance bottleneck (using ATA drives as "slaves"). And I don't want to even get started with the Promise cards and drivers themselves. > My next steps before giving up: > - I have installed a second Prosime controller to make sure every IDE > disk has it's own channel. (Don't blame Promise, I had exactly the same > prob with the i820 IDE of the DELL Precision 220). Test is running right > now... Er, by this time, you could have spend a few buck more and gotten a 4-channel 3Ware Escalade 6000 or, better yet, 7000-series (~$200-225). Then you'd have _real_, independent, microcontroller-driven hardware RAID-5 from the system perspective. Then "device" would then look like a single, "dumb" drive. Plus the 3Ware driver has been in the stock kernel since 2.2.15. > - Configuring the 4 IDE disks as RAID10 and test again. I will loose > 60GB, but at least we then know that SoftRAID5 with IDE with XFS with > ... with ... is DANGEROUS(tm). > - Try with ext2 on the RAID5 :-( I thought the whole 2.4 kernel and software RAID-5 was not recommended, no matter what fs you use? -- TheBS -- Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 SmithConcepts, Inc. http://www.SmithConcepts.com ========================================================== Linux 'Worms' exploit known security holes that were fixed 3-12 months earlier. NT/2000 'Worms' exploit unknown se- curity holes that won't be fixed for another 3-12 months. From owner-linux-xfs@oss.sgi.com Thu Jun 28 16:35:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SNZZK20248 for linux-xfs-outgoing; Thu, 28 Jun 2001 16:35:35 -0700 Received: from afaranis1.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SNZZV20245 for ; Thu, 28 Jun 2001 16:35:35 -0700 Received: from tduffy-lnx.afara.com (tduffy-lnx.afara.com [10.2.4.191]) by afaranis1.afara.com (8.9.3/8.9.3) with ESMTP id QAA15031; Thu, 28 Jun 2001 16:35:27 -0700 (PDT) Subject: Re: RedHat PR3 i686 kernel From: Thomas Duffy To: oe.hansen@gamma.telenordia.se Cc: linux-xfs@oss.sgi.com In-Reply-To: <01062901314403.01999@citadel.oehansen.pp.se> References: <01062901085801.01999@citadel.oehansen.pp.se> <993769949.3312.0.camel@tduffy-lnx.afara.com> <01062901314403.01999@citadel.oehansen.pp.se> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/0.10.99 (Preview Release) Date: 28 Jun 2001 16:34:46 -0700 Message-Id: <993771286.3313.2.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5SNZZV20246 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 29 Jun 2001 01:31:44 +0200, Orn E. Hansen wrote: > föstudagur 29. júní 2001 01:12, Thomas Duffy skrifaði: > > > 2. I'm using NVIDIA's kernel driver 0.9-769 and it won't compile, and > > > gives the following reasons, when the compiled driver is > > > insmod'ed. > > > > I would use the 1.0-1251 for 2.4.x kernels. > > > I can't ... that version doesn't work for my card. hmmm...which card do you have? i have used that version on everything from a nv6 to an nv16. I think you will be SOL with 796 and a 2.4.x kernel... -tduffy From owner-linux-xfs@oss.sgi.com Thu Jun 28 16:46:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SNkT620500 for linux-xfs-outgoing; Thu, 28 Jun 2001 16:46:29 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SNkSV20495 for ; Thu, 28 Jun 2001 16:46:29 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 294741AB0F for ; Thu, 28 Jun 2001 19:46:28 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id 8503E122B; Thu, 28 Jun 2001 19:46:27 -0400 (EDT) Date: Thu, 28 Jun 2001 19:46:27 -0400 From: Andrew Klaassen To: linux-xfs Subject: Re: XFS corruption on SoftRAID5 Message-ID: <20010628194627.A8778@dkp.com> Mail-Followup-To: linux-xfs References: <3B3B6A45.3252B37C@ch.sauter-bc.com> <3B3BC18C.FF7C9E2E@ieee.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B3BC18C.FF7C9E2E@ieee.org> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Jun 28, 2001 at 07:45:16PM -0400, Bryan J. Smith wrote: > I thought the whole 2.4 kernel and software RAID-5 was not > recommended, no matter what fs you use? Hmm. I hope not - we've just deployed 300G of IDE drive (using an onboard controller, no less) on a box running 2.4.2-SGI_XFS_1.0.1_PR1 over software RAID 5, and plan to deploy 300G more once we've had a chance to tweak and tune and further stress test the second box. Other than the highmem bug - which showed up in testing on the second box, and hasn't yet affected the first - we haven't experienced any difficulties. Should we expect some? Are there some kernel mailing list threads I might want to take a look at before I dig myself in too deep? Andrew Klaassen From owner-linux-xfs@oss.sgi.com Thu Jun 28 16:54:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SNsjw20694 for linux-xfs-outgoing; Thu, 28 Jun 2001 16:54:45 -0700 Received: from localhost.localdomain ([207.231.66.180]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SNshV20688 for ; Thu, 28 Jun 2001 16:54:43 -0700 Received: (from jcoffin@localhost) by localhost.localdomain (8.11.2/8.11.2) id f5T05P217309; Thu, 28 Jun 2001 17:05:25 -0700 X-Authentication-Warning: localhost.localdomain: jcoffin set sender to jcoffin-lists@brown-dog.org using -f To: Thomas Duffy Cc: oe.hansen@gamma.telenordia.se, linux-xfs@oss.sgi.com Subject: Re: RedHat PR3 i686 kernel References: <01062901085801.01999@citadel.oehansen.pp.se> <993769949.3312.0.camel@tduffy-lnx.afara.com> <01062901314403.01999@citadel.oehansen.pp.se> <993771286.3313.2.camel@tduffy-lnx.afara.com> From: Jeff Coffin Date: 28 Jun 2001 17:05:25 -0700 In-Reply-To: Thomas Duffy's message of "28 Jun 2001 16:34:46 -0700" Message-ID: Lines: 30 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5SNsiV20692 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thomas Duffy writes: > On 29 Jun 2001 01:31:44 +0200, Orn E. Hansen wrote: > > föstudagur 29. júní 2001 01:12, Thomas Duffy skrifaði: > > > > 2. I'm using NVIDIA's kernel driver 0.9-769 and it won't compile, and > > > > gives the following reasons, when the compiled driver is > > > > insmod'ed. > > > > > > I would use the 1.0-1251 for 2.4.x kernels. > > > > > I can't ... that version doesn't work for my card. > > hmmm...which card do you have? i have used that version on everything > from a nv6 to an nv16. > > I think you will be SOL with 796 and a 2.4.x kernel... Just FYI: I'm running that NVIDIA driver with 2.4.5 + XFS patches, on a second head with a creative TNT card (PCI). It "compiled" and insmod'ed without issue, though I am running XFree 4.1.0 (binary distribution from XFree86) which was compiled on 2.4.4. The 1.0-1251 one was really flakey as a second head and X crashed a lot. Still does, but much less. --jeff From owner-linux-xfs@oss.sgi.com Thu Jun 28 17:05:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5T053c20923 for linux-xfs-outgoing; Thu, 28 Jun 2001 17:05:03 -0700 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5T052V20920 for ; Thu, 28 Jun 2001 17:05:02 -0700 Received: from [195.20.224.219] (helo=mrvdom03.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 15FlmO-00082z-00 for linux-xfs@oss.sgi.com; Fri, 29 Jun 2001 02:05:00 +0200 Received: from pd901e335.dip.t-dialin.net ([217.1.227.53] helo=kernelpanix.aura.of.mankind) by mrvdom03.kundenserver.de with esmtp (Exim 2.12 #2) id 15FllQ-0003lS-00 for linux-xfs@oss.sgi.com; Fri, 29 Jun 2001 02:04:00 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id f5SNPTN07141 for linux-xfs@oss.sgi.com; Fri, 29 Jun 2001 01:25:29 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Fri, 29 Jun 2001 01:25:29 +0200 From: utz lehmann To: linux-xfs@oss.sgi.com Subject: xfs jfs announcement diff on /. Message-ID: <20010629012529.A7059@s2y4n2c.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric Your diff on slashdot was great! http://slashdot.org/comments.pl?sid=01/06/28/187242&cid=46 utz From owner-linux-xfs@oss.sgi.com Thu Jun 28 17:22:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5T0M9I21170 for linux-xfs-outgoing; Thu, 28 Jun 2001 17:22:09 -0700 Received: from citadel.oehansen.pp.se (sdu227-204.ppp.algonet.se [195.163.204.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5T0M6V21167 for ; Thu, 28 Jun 2001 17:22:07 -0700 Received: from citadel.oehansen.pp.se (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f5T0Ngo04146; Fri, 29 Jun 2001 02:23:43 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se To: Thomas Duffy , oe.hansen@gamma.telenordia.se Subject: Re: RedHat PR3 i686 kernel Date: Fri, 29 Jun 2001 02:23:42 +0200 X-Mailer: KMail [version 1.2] Cc: linux-xfs@oss.sgi.com References: <01062901085801.01999@citadel.oehansen.pp.se> <01062901314403.01999@citadel.oehansen.pp.se> <993771286.3313.2.camel@tduffy-lnx.afara.com> In-Reply-To: <993771286.3313.2.camel@tduffy-lnx.afara.com> X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 X-MIME-Autoconverted: from 8bit to quoted-printable by citadel.oehansen.pp.se id f5T0Ngo04146 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5T0M8V21168 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk föstudagur 29. júní 2001 01:34, Thomas Duffy skrifaði: > > hmmm...which card do you have? i have used that version on everything > from a nv6 to an nv16. > > I think you will be SOL with 796 and a 2.4.x kernel... > I tried 1251, just for arguements sake ... and inserting it, gives the same result... same unresolved symbols. Orn From owner-linux-xfs@oss.sgi.com Thu Jun 28 18:07:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5T17bH21965 for linux-xfs-outgoing; Thu, 28 Jun 2001 18:07:37 -0700 Received: from afaranis1.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5T17aV21962 for ; Thu, 28 Jun 2001 18:07:36 -0700 Received: from tduffy-lnx.afara.com (tduffy-lnx.afara.com [10.2.4.191]) by afaranis1.afara.com (8.9.3/8.9.3) with ESMTP id SAA26406; Thu, 28 Jun 2001 18:07:27 -0700 (PDT) Subject: Re: RedHat PR3 i686 kernel From: Thomas Duffy To: oe.hansen@gamma.telenordia.se Cc: linux-xfs@oss.sgi.com In-Reply-To: <01062902234205.01999@citadel.oehansen.pp.se> References: <01062901085801.01999@citadel.oehansen.pp.se> <01062901314403.01999@citadel.oehansen.pp.se> <993771286.3313.2.camel@tduffy-lnx.afara.com> <01062902234205.01999@citadel.oehansen.pp.se> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.10.99 (Preview Release) Date: 28 Jun 2001 18:06:45 -0700 Message-Id: <993776806.3306.4.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 29 Jun 2001 02:23:42 +0200, Orn E. Hansen wrote: > I tried 1251, just for arguements sake ... and inserting it, gives the same > result... same unresolved symbols. ok, my guess is that you are not pointing the nvidia build at the correct kernel source tree. did you install the kernel-source and kernel-headers packages that came w/ 1.0.1 PR3? when it builds, try to determine where it is pulling the headers from. if it is pointing at an old/different kernel, then it would give this kind of error when you try to insmod the module. -tduffy From owner-linux-xfs@oss.sgi.com Thu Jun 28 18:39:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5T1dof22520 for linux-xfs-outgoing; Thu, 28 Jun 2001 18:39:50 -0700 Received: from citadel.oehansen.pp.se (sdu42-235.ppp.algonet.se [195.163.235.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5T1dlV22517 for ; Thu, 28 Jun 2001 18:39:47 -0700 Received: from citadel.oehansen.pp.se (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f5T1dwU03209; Fri, 29 Jun 2001 03:39:58 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se To: Thomas Duffy , oe.hansen@gamma.telenordia.se Subject: Re: RedHat PR3 i686 kernel Date: Fri, 29 Jun 2001 03:39:58 +0200 X-Mailer: KMail [version 1.2] Cc: linux-xfs@oss.sgi.com References: <01062901085801.01999@citadel.oehansen.pp.se> <01062902234205.01999@citadel.oehansen.pp.se> <993776806.3306.4.camel@tduffy-lnx.afara.com> In-Reply-To: <993776806.3306.4.camel@tduffy-lnx.afara.com> X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 X-MIME-Autoconverted: from 8bit to quoted-printable by citadel.oehansen.pp.se id f5T1dwU03209 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5T1dnV22518 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk föstudagur 29. júní 2001 03:06, Thomas Duffy skrifaði: > On 29 Jun 2001 02:23:42 +0200, Orn E. Hansen wrote: > > I tried 1251, just for arguements sake ... and inserting it, gives the > > same result... same unresolved symbols. > > ok, my guess is that you are not pointing the nvidia build at the > correct kernel source tree. did you install the kernel-source and > kernel-headers packages that came w/ 1.0.1 PR3? > I only installed kernel-2.4.3-SGI_XFS_1.0.1_PR3.i686.rpm doing: /sbin/depmod -a 2.4.3-SGI_XFS_1.0.1_PR3 gives a long list of unresolved symbols... yes, I've cleaned up the module directory and isntalled the package clean. > when it builds, try to determine where it is pulling the headers from. > if it is pointing at an old/different kernel, then it would give this > kind of error when you try to insmod the module. > It takes the include headers from /lib/modules//build/include Orn From owner-linux-xfs@oss.sgi.com Thu Jun 28 18:40:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5T1e2522550 for linux-xfs-outgoing; Thu, 28 Jun 2001 18:40:02 -0700 Received: from citadel.oehansen.pp.se (sdu42-235.ppp.algonet.se [195.163.235.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5T1e0V22545 for ; Thu, 28 Jun 2001 18:40:00 -0700 Received: from citadel.oehansen.pp.se (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f5SNw1o02291; Fri, 29 Jun 2001 01:58:07 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se To: Thomas Duffy , oe.hansen@gamma.telenordia.se Subject: Re: RedHat PR3 i686 kernel Date: Fri, 29 Jun 2001 01:58:01 +0200 X-Mailer: KMail [version 1.2] Cc: linux-xfs@oss.sgi.com References: <01062901085801.01999@citadel.oehansen.pp.se> <01062901314403.01999@citadel.oehansen.pp.se> <993771286.3313.2.camel@tduffy-lnx.afara.com> In-Reply-To: <993771286.3313.2.camel@tduffy-lnx.afara.com> X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 X-MIME-Autoconverted: from 8bit to quoted-printable by citadel.oehansen.pp.se id f5SNw1o02291 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5T1e2V22548 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk föstudagur 29. júní 2001 01:34, Thomas Duffy skrifaði: > > hmmm...which card do you have? i have used that version on everything > from a nv6 to an nv16. > > I think you will be SOL with 796 and a 2.4.x kernel... > TNT 16Mbyte... I've talked to NVidia, and they said they know about the problem and that others have complained about the same thing. Orn From owner-linux-xfs@oss.sgi.com Thu Jun 28 18:43:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5T1htE22799 for linux-xfs-outgoing; Thu, 28 Jun 2001 18:43:55 -0700 Received: from afaranis1.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5T1hsV22796 for ; Thu, 28 Jun 2001 18:43:54 -0700 Received: from tduffy-lnx.afara.com (tduffy-lnx.afara.com [10.2.4.191]) by afaranis1.afara.com (8.9.3/8.9.3) with ESMTP id SAA00741; Thu, 28 Jun 2001 18:43:47 -0700 (PDT) Subject: Re: RedHat PR3 i686 kernel From: Thomas Duffy To: oe.hansen@gamma.telenordia.se Cc: linux-xfs@oss.sgi.com In-Reply-To: <01062903395800.03058@citadel.oehansen.pp.se> References: <01062901085801.01999@citadel.oehansen.pp.se> <01062902234205.01999@citadel.oehansen.pp.se> <993776806.3306.4.camel@tduffy-lnx.afara.com> <01062903395800.03058@citadel.oehansen.pp.se> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.10.99 (Preview Release) Date: 28 Jun 2001 18:43:05 -0700 Message-Id: <993778985.3312.7.camel@tduffy-lnx.afara.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 29 Jun 2001 03:39:58 +0200, Orn E. Hansen wrote: > I only installed kernel-2.4.3-SGI_XFS_1.0.1_PR3.i686.rpm hmm, well you will need kernel-source as well. > doing: > /sbin/depmod -a 2.4.3-SGI_XFS_1.0.1_PR3 > > gives a long list of unresolved symbols... yes, I've cleaned up the module > directory and isntalled the package clean. that is not good. > > when it builds, try to determine where it is pulling the headers from. > > if it is pointing at an old/different kernel, then it would give this > > kind of error when you try to insmod the module. > > > It takes the include headers from /lib/modules//build/include right, but where does that sym link point to? -tduffy From owner-linux-xfs@oss.sgi.com Thu Jun 28 19:24:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5T2OZj23440 for linux-xfs-outgoing; Thu, 28 Jun 2001 19:24:35 -0700 Received: from citadel.oehansen.pp.se (sdu64-235.ppp.algonet.se [195.163.235.64]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5T2OWV23437 for ; Thu, 28 Jun 2001 19:24:33 -0700 Received: from citadel.oehansen.pp.se (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f5T2Pww20358; Fri, 29 Jun 2001 04:25:58 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se To: Thomas Duffy , oe.hansen@gamma.telenordia.se Subject: Re: RedHat PR3 i686 kernel Date: Fri, 29 Jun 2001 04:25:56 +0200 X-Mailer: KMail [version 1.2] Cc: linux-xfs@oss.sgi.com References: <01062901085801.01999@citadel.oehansen.pp.se> <01062902234205.01999@citadel.oehansen.pp.se> <993776806.3306.4.camel@tduffy-lnx.afara.com> In-Reply-To: <993776806.3306.4.camel@tduffy-lnx.afara.com> X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 X-MIME-Autoconverted: from 8bit to quoted-printable by citadel.oehansen.pp.se id f5T2Pww20358 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5T2OYV23438 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk föstudagur 29. júní 2001 03:06, Thomas Duffy skrifaði: > > when it builds, try to determine where it is pulling the headers from. > if it is pointing at an old/different kernel, then it would give this > kind of error when you try to insmod the module. > I'm a bit tired tonite... sorry how dense I am, took a while to seap in :-) Orn From owner-linux-xfs@oss.sgi.com Thu Jun 28 20:04:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5T34AC24172 for linux-xfs-outgoing; Thu, 28 Jun 2001 20:04:10 -0700 Received: from digitaltux.com (zoltan@24.101.49.82.on.wave.home.com [24.101.49.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5T349V24168 for ; Thu, 28 Jun 2001 20:04:09 -0700 Received: from localhost ([127.0.0.1] helo=digitaltux.com) by digitaltux.com with smtp (Exim 3.22 #1 (Debian)) id 15FoZf-00006t-00; Thu, 28 Jun 2001 23:04:03 -0400 Date: Thu, 28 Jun 2001 23:03:59 -0400 From: Zoltan Kraus To: utz lehmann Cc: linux-xfs@oss.sgi.com Subject: Re: xfs jfs announcement diff on /. Message-Id: <20010628230359.43b94c14.zoltan@digitaltux.com> In-Reply-To: <20010629012529.A7059@s2y4n2c.de> References: <20010629012529.A7059@s2y4n2c.de> X-Mailer: Sylpheed version 0.4.99 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=.2mp4sAjQk:t5Jc" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=.2mp4sAjQk:t5Jc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Woah... the similarity between the two announcements is almost scary... On Fri, 29 Jun 2001 01:25:29 +0200 utz lehmann wrote: > Hi Eric > > Your diff on slashdot was great! > > http://slashdot.org/comments.pl?sid=01/06/28/187242&cid=46 > > > utz > -- Thanks, - Zoltan Kraus ________ Windows: A 32 bit hack for a 16 bit operating system, originally written for an 8 bit processor on a 4 bit bus by a 2 bit company that can't stand bit of competition! -------- --=.2mp4sAjQk:t5Jc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7O/Aip0iq+lfR+9YRAldtAJ9SoANUei+t4gP+W1bovfM9Gqv5zQCfXNPA YAJHj0ENyNkAiuXx4KADujo= =n9Ne -----END PGP SIGNATURE----- --=.2mp4sAjQk:t5Jc-- From owner-linux-xfs@oss.sgi.com Thu Jun 28 20:13:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5T3DtH24311 for linux-xfs-outgoing; Thu, 28 Jun 2001 20:13:55 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5T3DsV24308 for ; Thu, 28 Jun 2001 20:13:54 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA22530 for ; Thu, 28 Jun 2001 20:13:48 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id UAA34829; Thu, 28 Jun 2001 20:13:21 -0700 (PDT) Message-ID: <3B3BF1B0.88BF1151@sgi.com> Date: Thu, 28 Jun 2001 22:10:40 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: oe.hansen@gamma.telenordia.se CC: linux-xfs@oss.sgi.com Subject: Re: RedHat PR3 i686 kernel References: <01062901085801.01999@citadel.oehansen.pp.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Orn E. Hansen" wrote: > 2. I'm using NVIDIA's kernel driver 0.9-769 and it won't compile, and > gives the following reasons, when the compiled driver is insmod'ed. > > ./NVdriver: unresolved symbol __pollwait_R8f03d002 > ./NVdriver: unresolved symbol mem_map_Rfd150a02 etc... These look like module versioning problems, try starting with a kernel source tree, do a "make mrproper" and start all over again, but disable kernel module versioning. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Jun 28 23:54:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5T6sGe25962 for linux-xfs-outgoing; Thu, 28 Jun 2001 23:54:16 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5T6sDV25958 for ; Thu, 28 Jun 2001 23:54:14 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA00092; Fri, 29 Jun 2001 08:54:01 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA19858; Fri, 29 Jun 2001 08:54:00 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 7F47C57306; Fri, 29 Jun 2001 09:03:57 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 11FEC25835; Fri, 29 Jun 2001 09:12:08 +0200 (CEST) Message-ID: <3B3C2758.98143EAF@ch.sauter-bc.com> Date: Fri, 29 Jun 2001 08:59:36 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Steve Lord Cc: linux-xfs Subject: Re: XFS corruption on SoftRAID5 References: <200106282148.f5SLmfw24451@jen.americas.sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord schrieb: > > > I don't know what to try anymore... > > First rule of bug reporting, which version of the kernel are you using? I said PR1-PR3. I thought it's just the naming for the RH Kernels 1.0.1 release. > Oh, and what type of NFS servers? Okay, they are linux servers. kernel 2.2.16 and 2.0.36!. Just believe me, they are not the problem. > > Details, details please. Sorry Now, don't worry, it's not XFS! I tried the same with ext2, same corruption. I tried the same with SoftRAID 0, same corruption. I tried the same with just one partition on one disk, NO problem! > > Steve > > > > > I'm getting XFS filesystem corruption, I can see this when using ls or > > du. Filenames are corrupted and also their content. I was doing the > > first test on a DELL Precision Workstation with 4 IDE drives but I have > > changed now. So let me explain what exactly I'm doing. > > > > I have set up a DELL PowerEdge 1400 Server, PIII800 / 256MB / > > ServerWorks CNB20LE. Two U160-SCSI Disks on the first onboard controller > > (AIC-7899). /, /boot and 2x1GB swap are on SoftRAID1 on those two disks. > > Until here, no problem at all, using kernel PR1-PR3. Then I installed > > one Promise Ultra100TX2 IDE controller, connecting 4 IBM 60GB drives. I > > created 1 RAID5 on those 4 drives. I then do a 'sysctl -w > > dev.raid.speed_limit_min=10000' to resync the raid faster, otherwise it > > takes days to sync. Then while syncing, I create an XFS filsystem on it > > and mount it on /home. Now I copy some GB of data from 2 NFS servers > > (while it is still syncing). This is going slow because of high priority > > syncing, but beside that, not problem at all. Later then, after the sync > > has finished and after some reboots, I just made an ls -R /home and > > found out that the filnames were corrupt. I know that what I did is a > > torture for the system, but it should be able to handle such situations. > > Can somebody tell me what could cause the problem. Could it be the > > combination of RAID5 / XFS / syncing / heavy load? Unfortunately there > > is absolutely noting to find in the kernel logs. > > > > My next steps before giving up: > > - I have installed a second Prosime controller to make sure every IDE > > disk has it's own channel. (Don't blame Promise, I had exactly the same > > prob with the i820 IDE of the DELL Precision 220). Test is running right > > now... > > > > - Configuring the 4 IDE disks as RAID10 and test again. I will loose > > 60GB, but at least we then know that SoftRAID5 with IDE with XFS with > > ... with ... is DANGEROUS(tm). > > > > - Try with ext2 on the RAID5 :-( > > > > Thanks in advance for any help > > > > Simon > > From owner-linux-xfs@oss.sgi.com Fri Jun 29 00:05:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5T759a26205 for linux-xfs-outgoing; Fri, 29 Jun 2001 00:05:09 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5T757V26202 for ; Fri, 29 Jun 2001 00:05:07 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id JAA02035; Fri, 29 Jun 2001 09:05:03 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id JAA20621; Fri, 29 Jun 2001 09:05:02 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id E767557306; Fri, 29 Jun 2001 09:14:04 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 8F32E25835; Fri, 29 Jun 2001 09:22:15 +0200 (CEST) Message-ID: <3B3C29B8.6BD0F625@ch.sauter-bc.com> Date: Fri, 29 Jun 2001 09:09:44 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: "Bryan J. Smith" Cc: linux-xfs Subject: Re: XFS corruption on SoftRAID5 References: <3B3B6A45.3252B37C@ch.sauter-bc.com> <3B3BC18C.FF7C9E2E@ieee.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Bryan J. Smith" schrieb: > > Simon Matter wrote: > > Then I installed one Promise Ultra100TX2 IDE controller, > > connecting 4 IBM 60GB drives. > > Ouch! Talk about a performance bottleneck (using ATA drives as > "slaves"). And I don't want to even get started with the Promise > cards and drivers themselves. Forget it! It's not true, believe me. I made ALOT of test now and it really doesn't matter. > > > My next steps before giving up: > > - I have installed a second Prosime controller to make sure every IDE > > disk has it's own channel. (Don't blame Promise, I had exactly the same > > prob with the i820 IDE of the DELL Precision 220). Test is running right > > now... > > Er, by this time, you could have spend a few buck more and gotten a > 4-channel 3Ware Escalade 6000 or, better yet, 7000-series > (~$200-225). Then you'd have _real_, independent, > microcontroller-driven hardware RAID-5 from the system perspective. > Then "device" would then look like a single, "dumb" drive. Plus the > 3Ware driver has been in the stock kernel since 2.2.15. We have lot of servers here with SoftRAID5 and SoftRAID1 on IDE and SCSI and they are running for years now without ANY problem! And when it comes to performance, nothing is faster than having a fast Athlon and a fast operating system (linux) running as your raid controller! We have all the big irons here from IBM, HP, Compaq, Siemens-Fujitsu, DELL with all their super ultra caching raid and disk arrays but Linux SoftRAID5 is faster. Give it a try. > > > - Configuring the 4 IDE disks as RAID10 and test again. I will loose > > 60GB, but at least we then know that SoftRAID5 with IDE with XFS with > > ... with ... is DANGEROUS(tm). > > - Try with ext2 on the RAID5 :-( > > I thought the whole 2.4 kernel and software RAID-5 was not > recommended, no matter what fs you use? > > -- TheBS > > -- > Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 > SmithConcepts, Inc. http://www.SmithConcepts.com > ========================================================== > Linux 'Worms' exploit known security holes that were fixed > 3-12 months earlier. NT/2000 'Worms' exploit unknown se- > curity holes that won't be fixed for another 3-12 months. -- 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 Fri Jun 29 00:21:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5T7L9f26475 for linux-xfs-outgoing; Fri, 29 Jun 2001 00:21:09 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5T7L7V26472 for ; Fri, 29 Jun 2001 00:21:08 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id JAA04556; Fri, 29 Jun 2001 09:21:06 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id JAA21898; Fri, 29 Jun 2001 09:21:05 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id C24B357306; Fri, 29 Jun 2001 09:30:12 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 68F2B25835; Fri, 29 Jun 2001 09:38:23 +0200 (CEST) Message-ID: <3B3C2D80.C0209A42@ch.sauter-bc.com> Date: Fri, 29 Jun 2001 09:25:52 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Andrew Klaassen Cc: linux-xfs Subject: Re: XFS corruption on SoftRAID5 References: <3B3B6A45.3252B37C@ch.sauter-bc.com> <3B3BC18C.FF7C9E2E@ieee.org> <20010628194627.A8778@dkp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andrew Klaassen schrieb: > > On Thu, Jun 28, 2001 at 07:45:16PM -0400, > Bryan J. Smith wrote: > > > I thought the whole 2.4 kernel and software RAID-5 was not > > recommended, no matter what fs you use? > > Hmm. I hope not - we've just deployed 300G of IDE drive (using > an onboard controller, no less) on a box running > 2.4.2-SGI_XFS_1.0.1_PR1 over software RAID 5, and plan to deploy > 300G more once we've had a chance to tweak and tune and further > stress test the second box. Other than the highmem bug - which > showed up in testing on the second box, and hasn't yet affected > the first - we haven't experienced any difficulties. > > Should we expect some? Okay, I'm using SoftRAID5 on Linux for years now on servers with many hundred days of uptime and I have not seen any problem, until now. And, it's not XFS related, it happens with ext2 as well. I'm still trying to find out what's goning wrong here. Simon > > Are there some kernel mailing list threads I might want to take > a look at before I dig myself in too deep? > > Andrew Klaassen From owner-linux-xfs@oss.sgi.com Fri Jun 29 00:27:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5T7RYh26643 for linux-xfs-outgoing; Fri, 29 Jun 2001 00:27:34 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5T7RSV26640 for ; Fri, 29 Jun 2001 00:27:29 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5T7RHH14534; Fri, 29 Jun 2001 09:27:17 +0200 Message-Id: <4.3.2.7.2.20010629090815.02e71aa8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 29 Jun 2001 09:27:12 +0200 To: Simon Matter , Steve Lord From: Seth Mos Subject: Re: XFS corruption on SoftRAID5 Cc: linux-xfs In-Reply-To: <3B3C2758.98143EAF@ch.sauter-bc.com> References: <200106282148.f5SLmfw24451@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 08:59 29-6-2001 +0200, Simon Matter wrote: >Steve Lord schrieb: > > > > > I don't know what to try anymore... > > > > First rule of bug reporting, which version of the kernel are you using? >I said PR1-PR3. I thought it's just the naming for the RH Kernels 1.0.1 >release. > > Oh, and what type of NFS servers? >Okay, they are linux servers. kernel 2.2.16 and 2.0.36!. Just believe >me, they are not the problem. > > > > Details, details please. >Sorry > >Now, don't worry, it's not XFS! >I tried the same with ext2, same corruption. >I tried the same with SoftRAID 0, same corruption. >I tried the same with just one partition on one disk, NO problem! Your complaining on the wrong list. See linux-kernel in that case. Maybe a bit harsh but the md author might just be listening on the linux-kernel list. The people here understand XFS all too well but they don't know the complete kernel in and out (could be wrong though). Another problem is that they unfortunately don't really have the time to fix all sorts of kernel bugs. If you can produce a testcase in which you can generate corruption on the fs no matter what the fs is that would be helpful. Are you just seeing file names being garbled or ar the files themeselves also corrupt. What does a xfs_repair mention when you try to check it? Does it even report anything on that matter at all or does it decide to core dump because it's checking swiss cheese? Can you check out the CVS tree and build a kernel with that to simulate it. 2.4.5+ makes a big difference relative to 2.4.3. There have been some raid fixes in the past time. And 2.4.6 is approaching in a rapid pace. I'm placing my bet on the next version being 2.4.6. If you build a new kernel with the CVS tree (currently at 2.4.6-pre6) and can test if you see corruption again that would be helpful. Then we at least now what issues remain for the 1.0.1 installer. Although shipping a 2.4.5 in 1.0.1 might not be possible. Bye -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Jun 29 01:24:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5T8O9m27997 for linux-xfs-outgoing; Fri, 29 Jun 2001 01:24:09 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5T8O6V27994 for ; Fri, 29 Jun 2001 01:24:07 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id KAA22448; Fri, 29 Jun 2001 10:24:00 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id KAA27878; Fri, 29 Jun 2001 10:23:59 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 3462F57306; Fri, 29 Jun 2001 10:33:31 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id B6B2C25835; Fri, 29 Jun 2001 10:41:41 +0200 (CEST) Message-ID: <3B3C3C56.73D1C11C@ch.sauter-bc.com> Date: Fri, 29 Jun 2001 10:29:10 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Seth Mos Cc: Steve Lord , linux-xfs Subject: Re: XFS corruption on SoftRAID5 References: <200106282148.f5SLmfw24451@jen.americas.sgi.com> <4.3.2.7.2.20010629090815.02e71aa8@pop.xs4all.nl> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos schrieb: > > At 08:59 29-6-2001 +0200, Simon Matter wrote: > >Steve Lord schrieb: > > > > > > > I don't know what to try anymore... > > > > > > First rule of bug reporting, which version of the kernel are you using? > >I said PR1-PR3. I thought it's just the naming for the RH Kernels 1.0.1 > >release. > > > Oh, and what type of NFS servers? > >Okay, they are linux servers. kernel 2.2.16 and 2.0.36!. Just believe > >me, they are not the problem. > > > > > > Details, details please. > >Sorry > > > >Now, don't worry, it's not XFS! > >I tried the same with ext2, same corruption. > >I tried the same with SoftRAID 0, same corruption. > >I tried the same with just one partition on one disk, NO problem! > > Your complaining on the wrong list. See linux-kernel in that case. I'm not complaining. > Maybe a bit harsh but the md author might just be listening on the > linux-kernel list. Until today, it seemed to be XFS related. > > The people here understand XFS all too well but they don't know the > complete kernel in and out (could be wrong though). Another problem is that > they unfortunately don't really have the time to fix all sorts of kernel bugs. > You're right. But on this list we have all those people using big disks and raid volumes. So if the problem was somehow XFS/SoftRAID related, where could I ask. > If you can produce a testcase in which you can generate corruption on the > fs no matter what the fs is that would be helpful. Are you just seeing file > names being garbled or ar the files themeselves also corrupt. What does a > xfs_repair mention when you try to check it? Does it even report anything > on that matter at all or does it decide to core dump because it's checking > swiss cheese? It's the filnames and the files themselve. The hole blockdevice seems to be corrupted. Its not XFS,not SoftRAID. Its something in the IDE subsystem. > > Can you check out the CVS tree and build a kernel with that to simulate it. > 2.4.5+ makes a big difference relative to 2.4.3. There have been some raid > fixes in the past time. And 2.4.6 is approaching in a rapid pace. > > I'm placing my bet on the next version being 2.4.6. > > If you build a new kernel with the CVS tree (currently at 2.4.6-pre6) and > can test if you see corruption again that would be helpful. Then we at > least now what issues remain for the 1.0.1 installer. Although shipping a > 2.4.5 in 1.0.1 might not be possible. Just tried rawhide 2.4.5-20010613 and it's exactly the same. > > Bye > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Jun 29 02:01:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5T91v728460 for linux-xfs-outgoing; Fri, 29 Jun 2001 02:01:57 -0700 Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5T91tV28457 for ; Fri, 29 Jun 2001 02:01:55 -0700 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f5T91oH15200; Fri, 29 Jun 2001 11:01:50 +0200 Message-Id: <4.3.2.7.2.20010629105348.030147a8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 29 Jun 2001 11:01:44 +0200 To: Simon Matter From: Seth Mos Subject: Re: XFS corruption on SoftRAID5 Cc: Steve Lord , linux-xfs In-Reply-To: <3B3C3C56.73D1C11C@ch.sauter-bc.com> References: <200106282148.f5SLmfw24451@jen.americas.sgi.com> <4.3.2.7.2.20010629090815.02e71aa8@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10:29 29-6-2001 +0200, Simon Matter wrote: >Seth Mos schrieb: > >I'm not complaining. Your not. The coffee here must have been a bit on the strong side. > > Maybe a bit harsh but the md author might just be listening on the > > linux-kernel list. > >Until today, it seemed to be XFS related. Oh. I thought you noticed it earlier. > > The people here understand XFS all too well but they don't know the > > complete kernel in and out (could be wrong though). Another problem is that > > they unfortunately don't really have the time to fix all sorts of > kernel bugs. > > > >You're right. But on this list we have all those people using big disks >and raid volumes. So if the problem was somehow XFS/SoftRAID related, >where could I ask. True, but a lot of them are using hardware raid either IDE or scsi or fibre based. > > If you can produce a testcase in which you can generate corruption on the > > fs no matter what the fs is that would be helpful. Are you just seeing file > > names being garbled or ar the files themeselves also corrupt. What does a > > xfs_repair mention when you try to check it? Does it even report anything > > on that matter at all or does it decide to core dump because it's checking > > swiss cheese? > >It's the filnames and the files themselve. The hole blockdevice seems to >be corrupted. >Its not XFS,not SoftRAID. >Its something in the IDE subsystem. What IDE controller was it? A promise I believe? I unfortunately don't have experience with those controllers except for a Promise Ultra66 controller. You don't happen to have another IDE controller to test it with do you :) Do you also see a certain pattern in the fs corruption or is it just /dev/random ? > > Can you check out the CVS tree and build a kernel with that to simulate it. > > 2.4.5+ makes a big difference relative to 2.4.3. There have been some raid > > fixes in the past time. And 2.4.6 is approaching in a rapid pace. > > > > I'm placing my bet on the next version being 2.4.6. > > > > If you build a new kernel with the CVS tree (currently at 2.4.6-pre6) and > > can test if you see corruption again that would be helpful. Then we at > > least now what issues remain for the 1.0.1 installer. Although shipping a > > 2.4.5 in 1.0.1 might not be possible. > >Just tried rawhide 2.4.5-20010613 and it's exactly the same. Crap, so much for my theory. Oh well. Bye -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Jun 29 05:20:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TCKVS31790 for linux-xfs-outgoing; Fri, 29 Jun 2001 05:20:31 -0700 Received: from citadel.oehansen.pp.se (du43-154.ppp.algonet.se [195.100.154.43]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TCKRV31787 for ; Fri, 29 Jun 2001 05:20:28 -0700 Received: from citadel.oehansen.pp.se (localhost.localdomain [127.0.0.1]) by citadel.oehansen.pp.se (8.11.2/8.11.2) with SMTP id f5TCLup01500; Fri, 29 Jun 2001 14:21:58 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Orn E. Hansen" Reply-To: oe.hansen@gamma.telenordia.se To: Seth Mos , Simon Matter , Steve Lord Subject: Re: XFS corruption on SoftRAID5 Date: Fri, 29 Jun 2001 14:21:56 +0200 X-Mailer: KMail [version 1.2] Cc: linux-xfs References: <200106282148.f5SLmfw24451@jen.americas.sgi.com> <4.3.2.7.2.20010629090815.02e71aa8@pop.xs4all.nl> In-Reply-To: <4.3.2.7.2.20010629090815.02e71aa8@pop.xs4all.nl> X-Face: E_zcq`4tZ?pgKcXl2Vy?E.DsIl,aDED%mZEkq[i"_{2x`!#2uiyC(,`^P1u?ni#lDs+k4W.uCn!,W3ZKV0Tpu~p?jOKxKPUJnTZO%$^CW_2zcS\Nx2JJ0QlHJt,C#G+$YYcVcxf`%&@UT[q*4o5~Z>{WG]uJ--;VAJ31/$f`C}4D}F%cL~DS6MiL@gNa:wG_Z`T@b])f~LA_0nj6eB&O.Z$~VM|~jX1073)G6i3r$Z=IZy~=I|%_1 X-MIME-Autoconverted: from 8bit to quoted-printable by citadel.oehansen.pp.se id f5TCLup01500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5TCKUV31788 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk föstudagur 29. júní 2001 09:27, Seth Mos skrifaði: > > > >Now, don't worry, it's not XFS! > >I tried the same with ext2, same corruption. > >I tried the same with SoftRAID 0, same corruption. > >I tried the same with just one partition on one disk, NO problem! > Garbled characters, and corrupted filesystem... but no ide reported errors? Sounds like what I got once, when I put a filesystem on a drive that wasn't low level formatted. Orn From owner-linux-xfs@oss.sgi.com Fri Jun 29 09:28:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TGSN427360 for linux-xfs-outgoing; Fri, 29 Jun 2001 09:28:23 -0700 Received: from tux.mkp.net (tux.mkp.net [130.225.60.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TGSLV27346 for ; Fri, 29 Jun 2001 09:28:21 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net) by tux.mkp.net with esmtp (Exim 3.16 #1) id 15G180-0000PZ-00; Fri, 29 Jun 2001 18:28:20 +0200 Received: (from mkp@localhost) by jcb.mkp.net (8.11.0/8.9.3) id f5TGS6522213; Fri, 29 Jun 2001 12:28:06 -0400 X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f To: Simon Matter Cc: linux-xfs Subject: Re: XFS corruption on SoftRAID5 References: <200106282148.f5SLmfw24451@jen.americas.sgi.com> <4.3.2.7.2.20010629090815.02e71aa8@pop.xs4all.nl> <3B3C3C56.73D1C11C@ch.sauter-bc.com> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 29 Jun 2001 12:28:06 -0400 In-Reply-To: <3B3C3C56.73D1C11C@ch.sauter-bc.com> Message-ID: Lines: 15 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Simon" == Simon Matter writes: Simon> You're right. But on this list we have all those people using Simon> big disks and raid volumes. So if the problem was somehow Simon> XFS/SoftRAID related, where could I ask. It is perfectly fine to ask questions like that here. FWIW, almost all the XFS corruption bugs (with RAID or otherwise) I've seen so far have been incorrect IDE hdparm tuning or bad cabling. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Fri Jun 29 10:06:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TH6kO03895 for linux-xfs-outgoing; Fri, 29 Jun 2001 10:06:46 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TH6iV03887 for ; Fri, 29 Jun 2001 10:06:44 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 147191AB0F for ; Fri, 29 Jun 2001 13:06:42 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id BF2331218; Fri, 29 Jun 2001 13:06:41 -0400 (EDT) Date: Fri, 29 Jun 2001 13:06:41 -0400 From: Andrew Klaassen To: linux-xfs Subject: Re: XFS corruption on SoftRAID5 Message-ID: <20010629130641.B782@dkp.com> Mail-Followup-To: linux-xfs References: <200106282148.f5SLmfw24451@jen.americas.sgi.com> <4.3.2.7.2.20010629090815.02e71aa8@pop.xs4all.nl> <3B3C3C56.73D1C11C@ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Jun 29, 2001 at 12:28:06PM -0400, Martin K. Petersen wrote: > FWIW, almost all the XFS corruption bugs (with RAID or > otherwise) I've seen so far have been incorrect IDE hdparm > tuning or bad cabling. My question is really OT for this list, but how might one go about checking for bad cabling? Is there any software that can find it consistently? Andrew Klaassen From owner-linux-xfs@oss.sgi.com Fri Jun 29 10:43:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5THhOf14074 for linux-xfs-outgoing; Fri, 29 Jun 2001 10:43:24 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5THhNV14064 for ; Fri, 29 Jun 2001 10:43:23 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 8EC1D1AB0F for ; Fri, 29 Jun 2001 13:43:22 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id 60DBA1218; Fri, 29 Jun 2001 13:43:22 -0400 (EDT) Date: Fri, 29 Jun 2001 13:43:22 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: SG patches Message-ID: <20010629134322.D782@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20010626230456.A16389@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010626230456.A16389@wwweasel.geeksrus.net> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jun 26, 2001 at 11:04:56PM -0400, Alan Eldridge wrote: > There's a scsi generic (sg) patch that needs to go against > 2.4.5 to zap that unkillable process condition I was running > into. Is this patch needed for 2.4 kernels under 2.4.5, too? Andrew Klaassen From owner-linux-xfs@oss.sgi.com Fri Jun 29 10:58:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5THwNj20327 for linux-xfs-outgoing; Fri, 29 Jun 2001 10:58:23 -0700 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5THwNV20318 for ; Fri, 29 Jun 2001 10:58:23 -0700 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 8CE6F1AB0F for ; Fri, 29 Jun 2001 13:58:22 -0400 (EDT) Received: by ranma.dkp.com (Postfix, from userid 168) id 6381A1218; Fri, 29 Jun 2001 13:58:22 -0400 (EDT) Date: Fri, 29 Jun 2001 13:58:22 -0400 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: SG patches Message-ID: <20010629135822.F782@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20010626230456.A16389@wwweasel.geeksrus.net> <20010629134322.D782@dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010629134322.D782@dkp.com> User-Agent: Mutt/1.3.18i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Jun 29, 2001 at 01:43:22PM -0400, Andrew Klaassen wrote: > On Tue, Jun 26, 2001 at 11:04:56PM -0400, > Alan Eldridge wrote: > > There's a scsi generic (sg) patch that needs to go against > > 2.4.5 to zap that unkillable process condition I was running > > into. > Is this patch needed for 2.4 kernels under 2.4.5, too? Lemme make that clearer - is the patch needed for 2.4.0 to 2.4.4 kernels? Andrew Klaassen From owner-linux-xfs@oss.sgi.com Fri Jun 29 11:04:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TI4Nw22182 for linux-xfs-outgoing; Fri, 29 Jun 2001 11:04:23 -0700 Received: from server1.metrolink.com (server1.metrolink.com [216.242.72.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TI4LV22172 for ; Fri, 29 Jun 2001 11:04:22 -0700 Message-ID: <3B3CC2F4.53456ED6@metrolink.com> Date: Fri, 29 Jun 2001 14:03:32 -0400 From: Rob Lembree Organization: Metro Link, Inc. MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: kernel build issues Content-Type: multipart/mixed; boundary="------------6B9E4A412E0A6E5429BD992E" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------6B9E4A412E0A6E5429BD992E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi there, I can't seem to build the XFS kernel properly on my RH 7.1 machine. When I can build the bzImage, I can't build the modules (it complains about hex values in the sources). When I adjust the compiler (using native gcc, not kgcc), the following build breakage happens. Do you have any reports of this, or workarounds to suggest? gcc -D__KERNEL__ -I/usr/src/linux-2.4/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -Wno-unused -pipe -mpreferred-stack-boundary=2 -march=athlon -Wno-unused -Wno-parentheses -Wno-uninitialized -I. -I/usr/src/linux-2.4/fs -funsigned-char -Wno-unknown-pragmas -c -o xfs_bmap.o xfs_bmap.c xfs_bmap.c:543:9: warning: pasting "." and "xs_add_exlist" does not give a valid preprocessing token xfs_bmap.c:2830:9: warning: pasting "." and "xs_del_exlist" does not give a valid preprocessing token xfs_bmap.c: In function `xfs_bmap_alloc': xfs_bmap.c:2721: Unrecognizable insn: (insn/i 137 3604 3598 (parallel[ (set (reg:SI 0 eax) (asm_operands ("") ("=a") 0[ (reg:DI 1 edx) ] [ (asm_input:DI ("A")) ] ("linux/xfs_linux.h") 287)) (set (reg:SI 1 edx) (asm_operands ("") ("=d") 1[ (reg:DI 1 edx) ] [ (asm_input:DI ("A")) ] ("linux/xfs_linux.h") 287)) (clobber (reg:QI 19 dirflag)) (clobber (reg:QI 18 fpsr)) (clobber (reg:QI 17 flags)) ] ) -1 (nil) (nil)) xfs_bmap.c:2721: confused by earlier errors, bailing out make[3]: *** [xfs_bmap.o] Error 2 make[3]: Leaving directory `/usr/src/linux-2.4.2/fs/xfs' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.2/fs/xfs' make[1]: *** [_subdir_xfs] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.2/fs' make: *** [_dir_fs] Error 2 -- Rob Lembree Metro Link Incorporated 29 Milk St. lembree@metrolink.com Nashua, NH 03064-1651 http://www.metrolink.com Phone: 954.660.2460 Alternate: 603.577.9714 PGP: 1F EE F8 58 30 F1 B1 20 C5 4F 12 21 AD 0D 6B 29 --------------6B9E4A412E0A6E5429BD992E Content-Type: text/x-vcard; charset=us-ascii; name="lembree.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Rob Lembree Content-Disposition: attachment; filename="lembree.vcf" begin:vcard n:Lembree;Robert tel;cell:603-494-0559 tel;fax:603-577-9714 tel;home:603-880-6768 tel;work:954-660-2460 x-mozilla-html:TRUE url:http://www.lembree.com/rob/ org:Metro Link, Inc.;Automation Technology Division adr:;;29 Milk St.;Nashua;NH;03064-1651;US version:2.1 email;internet:lembree@metrolink.com title:Technical Director note:PGP: 1F EE F8 58 30 F1 B1 20 C5 4F 12 21 AD 0D 6B 29 x-mozilla-cpt:;-31136 fn:Robert Lembree end:vcard --------------6B9E4A412E0A6E5429BD992E-- From owner-linux-xfs@oss.sgi.com Fri Jun 29 11:14:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TIEdE25150 for linux-xfs-outgoing; Fri, 29 Jun 2001 11:14:39 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TIEdV25147 for ; Fri, 29 Jun 2001 11:14:39 -0700 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA02233 for ; Fri, 29 Jun 2001 11:14:38 -0700 (PDT) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA24282 for ; Fri, 29 Jun 2001 11:18:51 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 5A09815A46D for ; Fri, 29 Jun 2001 11:13:17 -0700 (PDT) Subject: Release-1.0 hates mc :-) From: Florin Andrei To: linux-xfs@oss.sgi.com Content-Type: text/plain X-Mailer: Evolution/0.10 (Preview Release) Date: 29 Jun 2001 11:13:17 -0700 Message-Id: <993838397.7718.3.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have a 100 GB RAID5 XFS volume (hardware RAID) on a Red Hat 7.1 SGI version (Release-1.0) machine. The volume usage is approx 70%. Because i'm lazy, i tried to determine directory sizes on that volume using Midnight Commander (mc) instead of du. And guess what: mc was totally frozen. I had to kill the process. Is this related to the du problems? Upgrade to 2.4.3 will solve it? -- Florin Andrei From owner-linux-xfs@oss.sgi.com Fri Jun 29 11:22:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TIMuT26678 for linux-xfs-outgoing; Fri, 29 Jun 2001 11:22:56 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TIMrV26659 for ; Fri, 29 Jun 2001 11:22:53 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5TIMjq19910 for linux-xfs@oss.sgi.com; Fri, 29 Jun 2001 14:22:45 -0400 Date: Fri, 29 Jun 2001 14:22:33 -0400 From: Alan Eldridge To: Andrew Klaassen Subject: Re: SG patches Message-ID: <20010629142233.A19901@wwweasel.geeksrus.net> References: <20010626230456.A16389@wwweasel.geeksrus.net> <20010629134322.D782@dkp.com> <20010629135822.F782@dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010629135822.F782@dkp.com>; from ak@dkp.com on Fri, Jun 29, 2001 at 01:58:22PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Jun 29, 2001 at 01:58:22PM -0400, Andrew Klaassen wrote: >On Fri, Jun 29, 2001 at 01:43:22PM -0400, >Andrew Klaassen wrote: > >> On Tue, Jun 26, 2001 at 11:04:56PM -0400, >> Alan Eldridge wrote: > >> > There's a scsi generic (sg) patch that needs to go against >> > 2.4.5 to zap that unkillable process condition I was running >> > into. > >> Is this patch needed for 2.4 kernels under 2.4.5, too? > >Lemme make that clearer - is the patch needed for 2.4.0 to 2.4.4 >kernels? > >Andrew Klaassen I do not know. I did not experience the process hang on 2.4.2, and I have not used 2.4.[34]. I will mail to ask the sg driver author and post his answer when I receive it. -- Alan Eldridge "Smart Tags? We don't need no steenking Smart Tags!" From owner-linux-xfs@oss.sgi.com Fri Jun 29 11:28:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TIS3V27673 for linux-xfs-outgoing; Fri, 29 Jun 2001 11:28:03 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TIS0V27664 for ; Fri, 29 Jun 2001 11:28:01 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA07448 for ; Fri, 29 Jun 2001 11:25:13 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2299284; Fri, 29 Jun 2001 13:26:42 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA75027; Fri, 29 Jun 2001 13:26:42 -0500 (CDT) Message-ID: <3B3CC829.F7C25F9@sgi.com> Date: Fri, 29 Jun 2001 13:25:45 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Rob Lembree CC: linux-xfs@oss.sgi.com Subject: Re: kernel build issues References: <3B3CC2F4.53456ED6@metrolink.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Rob Lembree wrote: > > Hi there, > I can't seem to build the XFS kernel properly > on my RH 7.1 machine. > > When I can build the bzImage, I can't build the > modules (it complains about hex values in the sources). > > When I adjust the compiler (using native gcc, not > kgcc), the following build breakage happens. Do you have > any reports of this, or workarounds to suggest? Which version of gcc are you using? http://oss.sgi.com/projects/xfs/faq.html#compilersissues -Eric From owner-linux-xfs@oss.sgi.com Fri Jun 29 11:33:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TIX0G28627 for linux-xfs-outgoing; Fri, 29 Jun 2001 11:33:00 -0700 Received: from musuko.uchicago.edu (musuko.uchicago.edu [128.135.39.147]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TIWxV28622 for ; Fri, 29 Jun 2001 11:32:59 -0700 Received: (from sl70@localhost) by musuko.uchicago.edu (8.11.2/8.11.2) id f5TIWw401166 for linux-xfs@oss.sgi.com; Fri, 29 Jun 2001 13:32:58 -0500 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Message-ID: X-Mailer: XFMail 1.5.0 on Linux X-Priority: 3 (Normal) In-Reply-To: <3B3CC2F4.53456ED6@metrolink.com> Date: Fri, 29 Jun 2001 13:32:58 -0500 (CDT) Reply-To: s-luppescu@uchicago.edu Organization: Univ of Chicago From: s-luppescu@uchicago.edu To: linux-xfs@oss.sgi.com Subject: RE: kernel build issues Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 29-Jun-2001 Rob Lembree wrote: > Hi there, > I can't seem to build the XFS kernel properly > on my RH 7.1 machine. > > When I can build the bzImage, I can't build the > modules (it complains about hex values in the sources). What kernel version are you using? And where did you get the kernel source? I had trouble with the kernel-source RPMs I got from the SGI web site (I think the problem may have been that I didn't do make mproper before I built it) -- I could do make bzImage with no problem, but I got those weird hex values errors when I tried to make modules. Then I got the prinstine kernel source tar ball for version 2.4.5, applied the xfs patches and everything went swimmingly. ______________________________________________________________________ Stuart Luppescu -=-=- University of Chicago $(B:MJ8$HCRF`H~$NIc(B -=-=- s-luppescu@uchicago.edu http://www.consortium-chicago.org/people/sl.html http://musuko.uchicago.edu/pubkey.asc for PGP Public Key ICQ #21172047 AIM: psycho7070 Few things are harder to put up with than the annoyance of a good example. -- "Mark Twain, Pudd'nhead Wilson's Calendar" >> Sent on 29-Jun-2001 at 13:27:26 with xfmail From owner-linux-xfs@oss.sgi.com Fri Jun 29 12:37:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TJbmh06697 for linux-xfs-outgoing; Fri, 29 Jun 2001 12:37:48 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TJblV06694 for ; Fri, 29 Jun 2001 12:37:47 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA04098 for ; Fri, 29 Jun 2001 12:37:40 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2300700 for ; Fri, 29 Jun 2001 14:36:30 -0500 (CDT) Received: from sgi.com (eagdhcp-187-26.americas.sgi.com [128.162.187.176]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA84894 for ; Fri, 29 Jun 2001 14:36:30 -0500 (CDT) Message-ID: <3B3CD884.47AD4FC4@sgi.com> Date: Fri, 29 Jun 2001 14:35:32 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-21mdk_XFS_1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: 1.0.1-PR3 installer ISO (tested!) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, there's a new system installer iso at ftp://oss.sgi.com/projects/xfs/download/testing/Release-1.0.1-PR3/iso/ for the new 1.0.1-PR3 XFS code. Again, rsync is your friend here, especially if you got the previous ill-fated iso. Sorry about the bad iso before, Red Hat snuck in some new locales that broke anaconda - so anaconda-7.1 would not build a 7.1 installer. :) The only people who _really_ need this installer are those who had trouble with RAID devices with the 1.0 installer. Everyone else can just upgrade an XFS 1.0 install w/ the new RPMs. But I'll be happy to have several people test this version. There are a couple bugfixes in the installer: - you can't put LILO on the boot partition if it's XFS - choosing to not format an existing ext2 partition won't cause a crash :) - Plus some other misc. fixes from 1.0 that were on the update floppy. Have fun, -Eric From owner-linux-xfs@oss.sgi.com Fri Jun 29 12:39:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TJdAB06907 for linux-xfs-outgoing; Fri, 29 Jun 2001 12:39:10 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TJd8V06903 for ; Fri, 29 Jun 2001 12:39:08 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id VAA00065; Fri, 29 Jun 2001 21:38:54 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id VAA15377; Fri, 29 Jun 2001 21:38:53 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id B794857306; Fri, 29 Jun 2001 18:56:51 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id DCB3925835; Fri, 29 Jun 2001 19:05:01 +0200 (CEST) Message-ID: <3B3CB14A.B38368A8@ch.sauter-bc.com> Date: Fri, 29 Jun 2001 18:48:10 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Seth Mos Cc: Steve Lord , linux-xfs Subject: Re: XFS corruption on SoftRAID5 References: <200106282148.f5SLmfw24451@jen.americas.sgi.com> <4.3.2.7.2.20010629090815.02e71aa8@pop.xs4all.nl> <4.3.2.7.2.20010629105348.030147a8@pop.xs4all.nl> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos schrieb: > > At 10:29 29-6-2001 +0200, Simon Matter wrote: > >Seth Mos schrieb: > > > >I'm not complaining. > > Your not. The coffee here must have been a bit on the strong side. > > > > Maybe a bit harsh but the md author might just be listening on the > > > linux-kernel list. > > > >Until today, it seemed to be XFS related. > > Oh. I thought you noticed it earlier. I meant XFS/SoftRAID related. I read that IBM JFS does not work on SoftRAID, so I thought maybe there is also something with XFS. > > > > The people here understand XFS all too well but they don't know the > > > complete kernel in and out (could be wrong though). Another problem is that > > > they unfortunately don't really have the time to fix all sorts of > > kernel bugs. > > > > > > >You're right. But on this list we have all those people using big disks > >and raid volumes. So if the problem was somehow XFS/SoftRAID related, > >where could I ask. > > True, but a lot of them are using hardware raid either IDE or scsi or fibre > based. I know, unfortunately, otherwise this error was found earlier... > > > > If you can produce a testcase in which you can generate corruption on the > > > fs no matter what the fs is that would be helpful. Are you just seeing file > > > names being garbled or ar the files themeselves also corrupt. What does a > > > xfs_repair mention when you try to check it? Does it even report anything > > > on that matter at all or does it decide to core dump because it's checking > > > swiss cheese? > > > >It's the filnames and the files themselve. The hole blockdevice seems to > >be corrupted. > >Its not XFS,not SoftRAID. > >Its something in the IDE subsystem. > > What IDE controller was it? A promise I believe? I unfortunately don't have > experience with those controllers except for a Promise Ultra66 controller. > You don't happen to have another IDE controller to test it with do you :) I did, with the onboard controller of a DELL Precision220 WS. It's using Intel i820 chipset. I was trying RAID1 there but at this time I just blamed the Intel CS. > > Do you also see a certain pattern in the fs corruption or is it just > /dev/random ? I didn't investigate deeper, but it looks like /dev/random > > > > Can you check out the CVS tree and build a kernel with that to simulate it. > > > 2.4.5+ makes a big difference relative to 2.4.3. There have been some raid > > > fixes in the past time. And 2.4.6 is approaching in a rapid pace. > > > > > > I'm placing my bet on the next version being 2.4.6. > > > > > > If you build a new kernel with the CVS tree (currently at 2.4.6-pre6) and > > > can test if you see corruption again that would be helpful. Then we at > > > least now what issues remain for the 1.0.1 installer. Although shipping a > > > 2.4.5 in 1.0.1 might not be possible. > > > >Just tried rawhide 2.4.5-20010613 and it's exactly the same. > > Crap, so much for my theory. Oh well. > Yes, but this time it's the Linux Kernel! At least the RedHat tuned one. I found a way to reproduce it now. It's not the SoftRAID code, as I manage to get corruption even without RAID. Just heavy load on all four disks. Well, here I found something... http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=44327 Simon From owner-linux-xfs@oss.sgi.com Fri Jun 29 12:41:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TJf4D07191 for linux-xfs-outgoing; Fri, 29 Jun 2001 12:41:04 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TJf3V07187 for ; Fri, 29 Jun 2001 12:41:03 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id VAA00234; Fri, 29 Jun 2001 21:40:50 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id VAA15484; Fri, 29 Jun 2001 21:40:49 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 1E0CA57306; Fri, 29 Jun 2001 19:03:08 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 9817625835; Fri, 29 Jun 2001 19:11:18 +0200 (CEST) Message-ID: <3B3CB2C3.D14936A8@ch.sauter-bc.com> Date: Fri, 29 Jun 2001 18:54:27 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: oe.hansen@gamma.telenordia.se Cc: Seth Mos , Steve Lord , linux-xfs Subject: Re: XFS corruption on SoftRAID5 References: <200106282148.f5SLmfw24451@jen.americas.sgi.com> <4.3.2.7.2.20010629090815.02e71aa8@pop.xs4all.nl> <01062914215601.01354@citadel.oehansen.pp.se> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by relay.xlink.net id VAA00234 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f5TJf3V07189 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Orn E. Hansen" schrieb: > > föstudagur 29. júní 2001 09:27, Seth Mos skrifaði: > > > > > >Now, don't worry, it's not XFS! > > >I tried the same with ext2, same corruption. > > >I tried the same with SoftRAID 0, same corruption. > > >I tried the same with just one partition on one disk, NO problem! > > > Garbled characters, and corrupted filesystem... but no ide reported errors? Thats true, absolutely nothing in the logs. I guess DMA transfers are going the wrong way... > > Sounds like what I got once, when I put a filesystem on a drive that wasn't > low level formatted. > > Orn They have been formatted with the IBM drive fitness test software. Everything okay. If I connect just ONE disk, it's working perfect. If I boot with ide0=autotune..., it seems to be okay but unusable slooooooooooow. I'm just giving up now. Simon From owner-linux-xfs@oss.sgi.com Fri Jun 29 13:22:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TKMRn11559 for linux-xfs-outgoing; Fri, 29 Jun 2001 13:22:27 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TKMPV11556 for ; Fri, 29 Jun 2001 13:22:25 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA03376 for ; Fri, 29 Jun 2001 13:19:38 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA2296441; Fri, 29 Jun 2001 15:21:08 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA25035; Fri, 29 Jun 2001 15:21:07 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.2/SGI-client-1.7) via ESMTP id f5TKMhP03536; Fri, 29 Jun 2001 15:22:43 -0500 Message-Id: <200106292022.f5TKMhP03536@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Rob Lembree cc: linux-xfs@oss.sgi.com Subject: Re: kernel build issues In-Reply-To: Message from Rob Lembree of "Fri, 29 Jun 2001 14:03:32 EDT." <3B3CC2F4.53456ED6@metrolink.com> Date: Fri, 29 Jun 2001 15:22:43 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, can I suggest you get a newer set of rpms from oss.sgi.com, the latest stuff is here: ftp://oss.sgi.com/projects/xfs/download/testing/Release-1.0.1-PR3/ This does compile with the redhat compiler (although the binary rpms are still compiled with kgcc), although we still have had problem reports on some architectures. Redhat did put out a newer compiler last week which appeared to fix some peoples issues. Steve > This is a multi-part message in MIME format. > --------------6B9E4A412E0A6E5429BD992E > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Hi there, > I can't seem to build the XFS kernel properly > on my RH 7.1 machine. > > When I can build the bzImage, I can't build the > modules (it complains about hex values in the sources). > > When I adjust the compiler (using native gcc, not > kgcc), the following build breakage happens. Do you have > any reports of this, or workarounds to suggest? > > > > gcc -D__KERNEL__ -I/usr/src/linux-2.4/include -Wall -Wstrict-prototypes -O2 - > fomit-frame-pointer -fno-strict-aliasing -Wno-unused -pipe -mpreferred-stack- > boundary=2 -march=athlon -Wno-unused -Wno-parentheses -Wno-uninitialized - > I. -I/usr/src/linux-2.4/fs -funsigned-char -Wno-unknown-pragmas -c -o xfs_b > map.o xfs_bmap.c > xfs_bmap.c:543:9: warning: pasting "." and "xs_add_exlist" does not give a va > lid preprocessing token > xfs_bmap.c:2830:9: warning: pasting "." and "xs_del_exlist" does not give a v > alid preprocessing token > xfs_bmap.c: In function `xfs_bmap_alloc': > xfs_bmap.c:2721: Unrecognizable insn: > (insn/i 137 3604 3598 (parallel[ > (set (reg:SI 0 eax) > (asm_operands ("") ("=a") 0[ > (reg:DI 1 edx) > ] > [ > (asm_input:DI ("A")) > ] ("linux/xfs_linux.h") 287)) > (set (reg:SI 1 edx) > (asm_operands ("") ("=d") 1[ > (reg:DI 1 edx) > ] > [ > (asm_input:DI ("A")) > ] ("linux/xfs_linux.h") 287)) > (clobber (reg:QI 19 dirflag)) > (clobber (reg:QI 18 fpsr)) > (clobber (reg:QI 17 flags)) > ] ) -1 (nil) > (nil)) > xfs_bmap.c:2721: confused by earlier errors, bailing out > make[3]: *** [xfs_bmap.o] Error 2 > make[3]: Leaving directory `/usr/src/linux-2.4.2/fs/xfs' > make[2]: *** [first_rule] Error 2 > make[2]: Leaving directory `/usr/src/linux-2.4.2/fs/xfs' > make[1]: *** [_subdir_xfs] Error 2 > make[1]: Leaving directory `/usr/src/linux-2.4.2/fs' > make: *** [_dir_fs] Error 2 > > > -- > > Rob Lembree Metro Link Incorporated > 29 Milk St. lembree@metrolink.com > Nashua, NH 03064-1651 http://www.metrolink.com > Phone: 954.660.2460 Alternate: 603.577.9714 > PGP: 1F EE F8 58 30 F1 B1 20 C5 4F 12 21 AD 0D 6B 29 > --------------6B9E4A412E0A6E5429BD992E > Content-Type: text/x-vcard; charset=us-ascii; > name="lembree.vcf" > Content-Transfer-Encoding: 7bit > Content-Description: Card for Rob Lembree > Content-Disposition: attachment; > filename="lembree.vcf" > > begin:vcard > n:Lembree;Robert > tel;cell:603-494-0559 > tel;fax:603-577-9714 > tel;home:603-880-6768 > tel;work:954-660-2460 > x-mozilla-html:TRUE > url:http://www.lembree.com/rob/ > org:Metro Link, Inc.;Automation Technology Division > adr:;;29 Milk St.;Nashua;NH;03064-1651;US > version:2.1 > email;internet:lembree@metrolink.com > title:Technical Director > note:PGP: 1F EE F8 58 30 F1 B1 20 C5 4F 12 21 AD 0D 6B 29 > x-mozilla-cpt:;-31136 > fn:Robert Lembree > end:vcard > > --------------6B9E4A412E0A6E5429BD992E-- From owner-linux-xfs@oss.sgi.com Fri Jun 29 13:30:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TKUQb12413 for linux-xfs-outgoing; Fri, 29 Jun 2001 13:30:26 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TKUNV12409 for ; Fri, 29 Jun 2001 13:30:24 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA09892; Fri, 29 Jun 2001 22:30:01 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA28330; Fri, 29 Jun 2001 22:29:56 +0200 (CEST) Date: Fri, 29 Jun 2001 22:29:56 +0200 (CEST) From: Seth Mos To: Andrew Klaassen cc: linux-xfs Subject: Re: XFS corruption on SoftRAID5 In-Reply-To: <20010629130641.B782@dkp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 29 Jun 2001, Andrew Klaassen wrote: > On Fri, Jun 29, 2001 at 12:28:06PM -0400, > Martin K. Petersen wrote: > > > FWIW, almost all the XFS corruption bugs (with RAID or > > otherwise) I've seen so far have been incorrect IDE hdparm > > tuning or bad cabling. > > My question is really OT for this list, but how might one go > about checking for bad cabling? Is there any software that can > find it consistently? If the cable is not correct some cards will report it. The promise controllers can report if a IDE cable is 80 pins or not. And the kernel sometimes also gives back errors. I have seen it once already. The ATA66 and ATA100 standard have CRC checking for data sent over the cable. However forcing another a transfer mode is dangerous and does net let a IDE interface set the correct mode on its own. I don't know if scsi has some form of CRC control.\ Bye From owner-linux-xfs@oss.sgi.com Fri Jun 29 13:35:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TKZlA13047 for linux-xfs-outgoing; Fri, 29 Jun 2001 13:35:47 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TKZkV13040 for ; Fri, 29 Jun 2001 13:35:46 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA11118; Fri, 29 Jun 2001 22:35:45 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA28514; Fri, 29 Jun 2001 22:35:45 +0200 (CEST) Date: Fri, 29 Jun 2001 22:35:45 +0200 (CEST) From: Seth Mos To: s-luppescu@uchicago.edu cc: linux-xfs@oss.sgi.com Subject: RE: kernel build issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 29 Jun 2001 s-luppescu@uchicago.edu wrote: > On 29-Jun-2001 Rob Lembree wrote: > > Hi there, > > I can't seem to build the XFS kernel properly > > on my RH 7.1 machine. > > > > When I can build the bzImage, I can't build the > > modules (it complains about hex values in the sources). > > What kernel version are you using? And where did you get the kernel source? I > had trouble with the kernel-source RPMs I got from the SGI web site (I think > the problem may have been that I didn't do make mproper before I built it) -- > I could do make bzImage with no problem, but I got those weird hex values > errors when I tried to make modules. Then I got the prinstine kernel source tar > ball for version 2.4.5, applied the xfs patches and everything went swimmingly. The core XFS version in 2.4.2/3 kernels differ somewhat. The story behind this is that in the 2.4.4 ad 5 releases there were patches commited that make XFS more compiler friendly to compilers other then kgcc (egcs 1.1.2). These fixes might mot be backported yet. I only know that the original 1.0 version source does not compile. Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Jun 29 13:42:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TKgbl14136 for linux-xfs-outgoing; Fri, 29 Jun 2001 13:42:37 -0700 Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TKgaV14128 for ; Fri, 29 Jun 2001 13:42:36 -0700 Received: from dsl-squash.corp.sgi.com (nic-30-c48-217.mw.mediaone.net [24.30.48.217]) by demai05.mw.mediaone.net (8.11.1/8.11.1) with ESMTP id f5TKgYK28590 for ; Fri, 29 Jun 2001 16:42:35 -0400 (EDT) Date: Fri, 29 Jun 2001 16:42:22 -0400 (EDT) From: J Landman X-X-Sender: To: Subject: Problem fixed (I think) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Folks: I had some problems with xfs that I think I fixed. Basically I had cp/mv and others core dump rather than work. What I did is I backed up my xfs based data, rebuilt the raido, rebuilt the filesystem, and it now seems to work properly. No core dumps. I had built the original file system with the RedHat 7.1 iso based images, and tools. I changed distros to Mandrake. Thats when it broke. So, using plain old 2.4.5 + patches under Mandrake, it is running fine (afte rthe little backup bit above). During this time, I was unable to build the development tree (same crashes that everyone else was getting, using wither the 2.91.66 or the 2.96.3 compilers). I was also unable to apply the patches to a 2.4.5-5mdk Mandrake source tree. Got lots of rej's. I am hoping that the work to get it into the kernel accelerates, so we wont have the problems in the not too distant future. Regardless of the minor annoyances, good work folks! -- Joe Landman, landman@mediaone.net From owner-linux-xfs@oss.sgi.com Fri Jun 29 13:49:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TKnIg15378 for linux-xfs-outgoing; Fri, 29 Jun 2001 13:49:18 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TKnGV15352 for ; Fri, 29 Jun 2001 13:49:16 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id WAA03104; Fri, 29 Jun 2001 22:49:15 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id WAA19064; Fri, 29 Jun 2001 22:49:14 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 9724457306; Fri, 29 Jun 2001 22:02:45 +0200 (CEST) Received: from ch.sauter-bc.com (ppp01.cad.sba [10.1.249.1]) by mobile.sauter-bc.com (Postfix) with ESMTP id C0B6B25835; Fri, 29 Jun 2001 22:10:54 +0200 (CEST) Message-ID: <3B3CDC71.C536B5C4@ch.sauter-bc.com> Date: Fri, 29 Jun 2001 21:52:17 +0200 From: Simon Matter X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i586) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Klaassen Cc: linux-xfs Subject: Re: XFS corruption on SoftRAID5 References: <200106282148.f5SLmfw24451@jen.americas.sgi.com> <4.3.2.7.2.20010629090815.02e71aa8@pop.xs4all.nl> <3B3C3C56.73D1C11C@ch.sauter-bc.com> <20010629130641.B782@dkp.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id f5TKnHV15368 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andrew Klaassen schrieb: > On Fri, Jun 29, 2001 at 12:28:06PM -0400, > Martin K. Petersen wrote: > > > FWIW, almost all the XFS corruption bugs (with RAID or > > otherwise) I've seen so far have been incorrect IDE hdparm > > tuning or bad cabling. > > My question is really OT for this list, but how might one go > about checking for bad cabling? Is there any software that can > find it consistently? > > Andrew Klaassen IBM's drive fittness test tool claims to test cabling, but I don't know. From owner-linux-xfs@oss.sgi.com Fri Jun 29 13:49:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TKnFg15330 for linux-xfs-outgoing; Fri, 29 Jun 2001 13:49:15 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TKnDV15325 for ; Fri, 29 Jun 2001 13:49:14 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id WAA03080; Fri, 29 Jun 2001 22:49:12 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id WAA19040; Fri, 29 Jun 2001 22:49:10 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id D02D857306; Fri, 29 Jun 2001 19:11:05 +0200 (CEST) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 1430225835; Fri, 29 Jun 2001 19:19:16 +0200 (CEST) Message-ID: <3B3CB4A0.A4CB5304@ch.sauter-bc.com> Date: Fri, 29 Jun 2001 19:02:24 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: "Martin K. Petersen" Cc: linux-xfs Subject: Re: XFS corruption on SoftRAID5 References: <200106282148.f5SLmfw24451@jen.americas.sgi.com> <4.3.2.7.2.20010629090815.02e71aa8@pop.xs4all.nl> <3B3C3C56.73D1C11C@ch.sauter-bc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Martin K. Petersen" schrieb: > > >>>>> "Simon" == Simon Matter writes: > > Simon> You're right. But on this list we have all those people using > Simon> big disks and raid volumes. So if the problem was somehow > Simon> XFS/SoftRAID related, where could I ask. > > It is perfectly fine to ask questions like that here. > > FWIW, almost all the XFS corruption bugs (with RAID or otherwise) I've > seen so far have been incorrect IDE hdparm tuning or bad cabling. That's the problem, I guess. The RH tuned 2.4 kernels (I didn't test linus kernels) do IDE tuning without using hdparm. I can say the Promise controller performs very good. With a RAID0 on all four disks I get mor than 120MB/sec throughput (yes, the file is big enough to not use caching). It's was also very fast on i820 chipset but it seems not to be reliable. FYI I didn't touch hdparm. I'm just giving up on using multiple IDE disks with kernel 2.4. Sad but no choice. > > -- > Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. > mkp@linuxcare.com, http://www.linuxcare.com/ > SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Fri Jun 29 13:53:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TKrWj16304 for linux-xfs-outgoing; Fri, 29 Jun 2001 13:53:32 -0700 Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TKrUV16293 for ; Fri, 29 Jun 2001 13:53:30 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA14077; Fri, 29 Jun 2001 22:53:29 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA29095; Fri, 29 Jun 2001 22:53:29 +0200 (CEST) Date: Fri, 29 Jun 2001 22:53:29 +0200 (CEST) From: Seth Mos To: J Landman cc: linux-xfs@oss.sgi.com Subject: Re: Problem fixed (I think) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 29 Jun 2001, J Landman wrote: > Folks: > > I had some problems with xfs that I think I fixed. Basically I had > cp/mv and others core dump rather than work. What I did is I backed up my > xfs based data, rebuilt the raido, rebuilt the filesystem, and it now > seems to work properly. No core dumps. Weird, then again some people say that computers follow exact logic. I have seen computers behave like "normal" people so I let go of that statement 1 week after purchasing my 1st PC. > I had built the original file system with the RedHat 7.1 iso based > images, and tools. I changed distros to Mandrake. Thats when it broke. > So, using plain old 2.4.5 + patches under Mandrake, it is running fine > (afte rthe little backup bit above). Good to hear. > During this time, I was unable to build the development tree (same > crashes that everyone else was getting, using wither the 2.91.66 or the > 2.96.3 compilers). I was also unable to apply the patches to a 2.4.5-5mdk > Mandrake source tree. Got lots of rej's. I am hoping that the work to > get it into the kernel accelerates, so we wont have the problems in the > not too distant future. There were 1.0 version Mandrake kernels available a few weeks after the 1.0 release. Those were however unoffical. No word on a XFS/ReiserFS/favoritefs installer yet for the next Mandrake. > Regardless of the minor annoyances, good work folks! Hard work and persistence pays off in the end. Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Jun 29 13:54:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TKs7w16500 for linux-xfs-outgoing; Fri, 29 Jun 2001 13:54:07 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TKs6V16493 for ; Fri, 29 Jun 2001 13:54:06 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id WAA03532; Fri, 29 Jun 2001 22:54:04 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id WAA19326; Fri, 29 Jun 2001 22:54:01 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 9F04157306; Fri, 29 Jun 2001 23:03:58 +0200 (CEST) Received: from ch.sauter-bc.com (ppp01.cad.sba [10.1.249.1]) by mobile.sauter-bc.com (Postfix) with ESMTP id B4A7F25835; Fri, 29 Jun 2001 23:12:07 +0200 (CEST) Message-ID: <3B3CEAC9.D7A11BA@ch.sauter-bc.com> Date: Fri, 29 Jun 2001 22:53:29 +0200 From: Simon Matter X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i586) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos Cc: Andrew Klaassen , linux-xfs Subject: Re: XFS corruption on SoftRAID5 References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id f5TKs6V16498 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos schrieb: > On Fri, 29 Jun 2001, Andrew Klaassen wrote: > > > On Fri, Jun 29, 2001 at 12:28:06PM -0400, > > Martin K. Petersen wrote: > > > > > FWIW, almost all the XFS corruption bugs (with RAID or > > > otherwise) I've seen so far have been incorrect IDE hdparm > > > tuning or bad cabling. > > > > My question is really OT for this list, but how might one go > > about checking for bad cabling? Is there any software that can > > find it consistently? > > If the cable is not correct some cards will report it. > The promise controllers can report if a IDE cable is 80 pins or not. That's correct. But I think they just recognize whether it's 40 or 80 wires cable. Cables have always 40 pins, but 80 wires. > > > And the kernel sometimes also gives back errors. I have seen it once > already. The ATA66 and ATA100 standard have CRC checking for data sent CRC is what they should do, but I'm not shure they really do it always. > > over the cable. However forcing another a transfer mode is dangerous > and does net let a IDE interface set the correct mode on its own. > > I don't know if scsi has some form of CRC control.\ It has, it's not CRC but parity checking. Most controllers let you en/disable it. > > > Bye From owner-linux-xfs@oss.sgi.com Fri Jun 29 14:07:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TL7AO18628 for linux-xfs-outgoing; Fri, 29 Jun 2001 14:07:10 -0700 Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TL79V18619 for ; Fri, 29 Jun 2001 14:07:09 -0700 Received: from dsl-squash.corp.sgi.com (nic-30-c48-217.mw.mediaone.net [24.30.48.217]) by demai05.mw.mediaone.net (8.11.1/8.11.1) with ESMTP id f5TL76K06506; Fri, 29 Jun 2001 17:07:06 -0400 (EDT) Date: Fri, 29 Jun 2001 17:06:53 -0400 (EDT) From: J Landman X-X-Sender: To: Seth Mos cc: Subject: Re: Problem fixed (I think) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 29 Jun 2001, Seth Mos wrote: > There were 1.0 version Mandrake kernels available a few weeks after the > 1.0 release. Those were however unoffical. No word on a > XFS/ReiserFS/favoritefs installer yet for the next Mandrake. Actually, the Mandrake folks have an excellent tool which combines the partitioning and the file system layout/specification/type construction. If you can get the patches into the mandrake peoples hands, they could integrate it into their tool. Right now, I can build a reiserfs based system trivially with their file system config tool. partitioning is trivial (much better than fdisk/disk druid) file system atop the partitions are also trvial to specify (and are done at the same time you lay out the partitions). I cannot say enough good things about it. -- Joe Landman, landman@mediaone.net From owner-linux-xfs@oss.sgi.com Fri Jun 29 14:13:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TLD3219338 for linux-xfs-outgoing; Fri, 29 Jun 2001 14:13:03 -0700 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TLD1V19334 for ; Fri, 29 Jun 2001 14:13:01 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id XAA07892; Fri, 29 Jun 2001 23:13:00 +0200 (MET DST) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id XAA20363; Fri, 29 Jun 2001 23:12:58 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 0C98857306; Fri, 29 Jun 2001 23:22:05 +0200 (CEST) Received: from ch.sauter-bc.com (ppp01.cad.sba [10.1.249.1]) by mobile.sauter-bc.com (Postfix) with ESMTP id 5110C25835; Fri, 29 Jun 2001 23:30:14 +0200 (CEST) Message-ID: <3B3CEF07.479A0857@ch.sauter-bc.com> Date: Fri, 29 Jun 2001 23:11:35 +0200 From: Simon Matter X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.7 i586) X-Accept-Language: en MIME-Version: 1.0 To: J Landman Cc: linux-xfs@oss.sgi.com Subject: Re: Problem fixed (I think) References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id f5TLD2V19336 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk J Landman schrieb: > Folks: > > I had some problems with xfs that I think I fixed. Basically I had > cp/mv and others core dump rather than work. What I did is I backed up my Can you let me know on how many disks your filesystem was. And was it IDE or SCSI. If IDE, what kind of chip and what kind of settings? > > xfs based data, rebuilt the raido, rebuilt the filesystem, and it now Ah, RAID 0, so you have more than one disk? IDE? with DMA (enabled for most chipsets by default in the RH7.1-XFS kernel? > seems to work properly. No core dumps. > > I had built the original file system with the RedHat 7.1 iso based > images, and tools. I changed distros to Mandrake. Thats when it broke. What kernel did you use when it broke? Are you shure you know exactly when it broke? > > So, using plain old 2.4.5 + patches under Mandrake, it is running fine > (afte rthe little backup bit above). > > > During this time, I was unable to build the development tree (same > crashes that everyone else was getting, using wither the 2.91.66 or the > 2.96.3 compilers). I was also unable to apply the patches to a 2.4.5-5mdk > Mandrake source tree. Got lots of rej's. I am hoping that the work to Did you check filesystem consistency somehow? For ex. with rpm -Va which will show all changes in the distribution file? > > get it into the kernel accelerates, so we wont have the problems in the > not too distant future. > > Regardless of the minor annoyances, good work folks! > > -- > Joe Landman, > landman@mediaone.net I was suffering filesystem corruption for awhile now and it was very difficult to reproduce it. In my case it is not XFS or Raid related but has something to do with the IDE subsystem. Simon From owner-linux-xfs@oss.sgi.com Fri Jun 29 14:54:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TLsxD25836 for linux-xfs-outgoing; Fri, 29 Jun 2001 14:54:59 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TLsvV25833 for ; Fri, 29 Jun 2001 14:54:57 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id OAA08421 for ; Fri, 29 Jun 2001 14:54:55 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 HAA04291; Sat, 30 Jun 2001 07:53:39 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id HAA82626; Sat, 30 Jun 2001 07:53:38 +1000 (EST) Date: Sat, 30 Jun 2001 07:53:37 +1000 From: Nathan Scott To: Roger Moore Cc: linux-xfs@oss.sgi.com Subject: [patch] Re: Label based mounts with fsck Message-ID: <20010630075337.A165960@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="M9NhX3UHpAaciwkO" X-Mailer: Mutt 1.0us In-Reply-To: ; from rwmoore@fnal.gov on Thu, Jun 28, 2001 at 04:46:02PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii hi Roger, On Thu, Jun 28, 2001 at 04:46:02PM -0500, Roger Moore wrote: > Hi, > > We've just updated our cluster to use XFS and have noticed a problem with > using 'LABEL=xxx' in the fstab file. > > The 'mount' command works fine with XFS labels (once you turn off devfs!). > However the problem lies with the fsck command. The RedHat 7.1 system we > have runs 'fsck -A...' at boot time which is needed for the remaining ext2 > partitions. This complains that it cannont find 'LABEL=xxx' for XFS > partitions even when we configure /etc/fstab has f_passno=0 for the XFS > mounts. Is there a patch out there for fsck to fix this problem? > could you try the attached patch and let me know how it goes? I think we're getting bitten by the use of DEFAULT_FSTYPE (ext2) in the fsck_device() routine... this should fix that. > We are currently using e2fsprogs-1.21 from RawHide since it is needed for > the 2.4.5-0.2.9 RawHide kernel which you have patched. > the patch is against e2fsprogs-1.22, but this code doesn't seem to have changed for awhile and should patch cleanly to 1.21 too. if it works, let me know & I'll forward on to Ted. thanks. -- Nathan --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="fsck.patch" diff -Naur e2fsprogs-1.22/misc/get_device_by_label.c e2fsprogs/misc/get_device_by_label.c --- e2fsprogs-1.22/misc/get_device_by_label.c Sat Jun 23 06:25:59 2001 +++ e2fsprogs/misc/get_device_by_label.c Sat Jun 30 01:39:54 2001 @@ -48,6 +48,16 @@ }; #define ext2magic(s) ((unsigned int) s.s_magic[0] + (((unsigned int) s.s_magic[1]) << 8)) +#define XFS_SUPER_MAGIC "XFSB" +#define XFS_SUPER_MAGIC2 "BSFX" +struct xfs_super_block { + unsigned char s_magic[4]; + unsigned char s_dummy[28]; + unsigned char s_uuid[16]; + unsigned char s_dummy2[60]; + unsigned char s_fname[12]; +}; + static struct uuidCache_s { struct uuidCache_s *next; char uuid[16]; @@ -55,35 +65,44 @@ char *device; } *uuidCache = NULL; -/* for now, only ext2 is supported */ +/* for now, only ext2 and xfs are supported */ static int get_label_uuid(const char *device, char **label, char *uuid) { - /* start with a test for ext2, taken from mount_guess_fstype */ + /* start with ext2 and xfs tests, taken from mount_guess_fstype */ /* should merge these later */ int fd; + int rv = 1; + size_t namesize; struct ext2_super_block e2sb; + struct xfs_super_block xfsb; fd = open(device, O_RDONLY); if (fd < 0) - return 1; + return rv; - if (lseek(fd, 1024, SEEK_SET) != 1024 - || read(fd, (char *) &e2sb, sizeof(e2sb)) != sizeof(e2sb) - || (ext2magic(e2sb) != EXT2_SUPER_MAGIC)) { - close(fd); - return 1; + if (lseek(fd, 1024, SEEK_SET) == 1024 + && read(fd, (char *) &e2sb, sizeof(e2sb)) == sizeof(e2sb) + && (ext2magic(e2sb) == EXT2_SUPER_MAGIC)) { + memcpy(uuid, e2sb.s_uuid, sizeof(e2sb.s_uuid)); + namesize = sizeof(e2sb.s_volume_name); + if ((*label = calloc(namesize + 1, 1)) != NULL) + memcpy(*label, e2sb.s_volume_name, namesize); + rv = 0; + } + else if (lseek(fd, 0, SEEK_SET) == 0 + && read(fd, (char *) &xfsb, sizeof(xfsb)) == sizeof(xfsb) + && (strncmp((char *) &xfsb.s_magic, XFS_SUPER_MAGIC, 4) == 0 || + strncmp((char *) &xfsb.s_magic, XFS_SUPER_MAGIC2,4) == 0)) { + memcpy(uuid, xfsb.s_uuid, sizeof(xfsb.s_uuid)); + namesize = sizeof(xfsb.s_fname); + if ((*label = calloc(namesize + 1, 1)) != NULL) + memcpy(*label, xfsb.s_fname, namesize); + rv = 0; } close(fd); - - /* superblock is ext2 - now what is its label? */ - memcpy(uuid, e2sb.s_uuid, sizeof(e2sb.s_uuid)); - - *label = calloc(sizeof(e2sb.s_volume_name) + 1, 1); - memcpy(*label, e2sb.s_volume_name, sizeof(e2sb.s_volume_name)); - - return 0; + return rv; } static void --M9NhX3UHpAaciwkO-- From owner-linux-xfs@oss.sgi.com Fri Jun 29 15:11:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TMBaI28773 for linux-xfs-outgoing; Fri, 29 Jun 2001 15:11:36 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TMBXV28770 for ; Fri, 29 Jun 2001 15:11:34 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA23048 for ; Fri, 29 Jun 2001 15:11:26 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) 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 IAA04382 for ; Sat, 30 Jun 2001 08:10:16 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA78613 for linux-xfs@oss.sgi.com; Sat, 30 Jun 2001 08:10:15 +1000 (EST) Date: Sat, 30 Jun 2001 08:10:15 +1000 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: [patch] cfdisk + xfs labels Message-ID: <20010630081014.B165960@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="CdrF4e02JqNVZeln" X-Mailer: Mutt 1.0us Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --CdrF4e02JqNVZeln Content-Type: text/plain; charset=us-ascii hi, so, I went back and checked the other util-linux tools to see if any of them make use of filesystem labels ... afaict, cfdisk is the only remaining one (mount being the other). this patch lets cfdisk display XFS labels too (in addition to ext2) + has the cute side effect of showing you which partitions hold XFS filesystems - if someone (else) could try it out and let me know how it goes, I'll then forward it on to Andries. note - you need curses installed to build cfdisk, and the patch is against version 2.11f of util-linux (but should apply to any recent version). thanks. -- Nathan --CdrF4e02JqNVZeln Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="cfdisk.patch" diff -Naur util-linux-2.11f/fdisk/cfdisk.c util-linux/fdisk/cfdisk.c --- util-linux-2.11f/fdisk/cfdisk.c Thu Jun 7 15:55:16 2001 +++ util-linux/fdisk/cfdisk.c Sat Jun 30 03:25:09 2001 @@ -47,6 +47,8 @@ * Some more i18n. * Sun Jul 18 03:19:42 MEST 1999 * Terabyte-sized disks. + * Sat Jun 30 05:23:19 EST 2001 + * XFS label recognition. * ****************************************************************************/ @@ -397,6 +399,8 @@ else if (p_info[i].id == LINUX) { if (!strcmp(p_info[i].fstype, "ext2")) return _("Linux ext2"); + else if (!strcmp(p_info[i].fstype, "xfs")) + return _("Linux XFS"); else return _("Linux"); } else if (p_info[i].id == OS2_OR_NTFS) { @@ -612,7 +616,7 @@ } static void -get_ext2_label(int i) { +get_linux_label(int i) { #define EXT2_SUPER_MAGIC 0xEF53 #define EXT2LABELSZ 16 struct ext2_super_block { @@ -622,22 +626,48 @@ char s_volume_name[EXT2LABELSZ]; char s_last_mounted[64]; char s_dummy2[824]; - } sb; - char *label = sb.s_volume_name; + } e2fsb; +#define XFS_SUPER_MAGIC "XFSB" +#define XFS_SUPER_MAGIC2 "BFSX" +#define XFSLABELSZ 12 + struct xfs_super_block { + unsigned char s_magic[4]; + unsigned char s_dummy0[104]; + unsigned char s_fname[XFSLABELSZ]; + unsigned char s_dummy1[904]; + } xfsb; + char *label; ext2_loff_t offset; int j; offset = ((ext2_loff_t) p_info[i].first_sector + p_info[i].offset) * SECTOR_SIZE + 1024; if (ext2_llseek(fd, offset, SEEK_SET) == offset - && read(fd, &sb, sizeof(sb)) == sizeof(sb) - && sb.s_magic[0] + 256*sb.s_magic[1] == EXT2_SUPER_MAGIC) { + && read(fd, &e2fsb, sizeof(e2fsb)) == sizeof(e2fsb) + && e2fsb.s_magic[0] + 256*e2fsb.s_magic[1] == EXT2_SUPER_MAGIC) { + label = e2fsb.s_volume_name; for(j=0; j; Fri, 29 Jun 2001 15:23:39 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA09754 for ; Fri, 29 Jun 2001 15:23:38 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2299212 for ; Fri, 29 Jun 2001 17:22:22 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA18816 for ; Fri, 29 Jun 2001 17:22:22 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f5TMNvb26481; Fri, 29 Jun 2001 17:23:57 -0500 Message-Id: <200106292223.f5TMNvb26481@jen.americas.sgi.com> Date: Fri, 29 Jun 2001 17:23:57 -0500 Subject: TAKE - merge up to 2.4.6-pre7 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just a small one Date: Fri Jun 29 15:21:45 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-base The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:97996a linux/Documentation/power/pci.txt - 1.1 linux/mm/vmscan.c - 1.60 linux/include/linux/swap.h - 1.29 linux/include/linux/pci.h - 1.44 linux/drivers/pci/pci.c - 1.38 linux/drivers/net/acenic.h - 1.14 linux/drivers/net/acenic.c - 1.27 linux/Makefile - 1.93 linux/Documentation/pci.txt - 1.13 linux/Documentation/kernel-docs.txt - 1.8 linux/CREDITS - 1.56 linux/include/linux/pm.h - 1.7 linux/drivers/atm/iphase.c - 1.10 linux/net/wanrouter/af_wanpipe.c - 1.2 linux/fs/freevxfs/vxfs_inode.c - 1.3 linux/drivers/mtd/nand/nand_ecc.c - 1.2 linux/drivers/mtd/nand/Makefile - 1.2 From owner-linux-xfs@oss.sgi.com Fri Jun 29 15:34:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TMYO700409 for linux-xfs-outgoing; Fri, 29 Jun 2001 15:34:24 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TMYMV00405 for ; Fri, 29 Jun 2001 15:34:22 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA25679 for ; Fri, 29 Jun 2001 15:34:16 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2299404 for ; Fri, 29 Jun 2001 17:33:06 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA94050 for ; Fri, 29 Jun 2001 17:33:06 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f5TMYfG26629; Fri, 29 Jun 2001 17:34:41 -0500 Message-Id: <200106292234.f5TMYfG26629@jen.americas.sgi.com> Date: Fri, 29 Jun 2001 17:34:41 -0500 Subject: TAKE - add a nouuid mount option for lvm snapshot mounting Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Patch from Andi Kleen, allows mounting of a second copy of a filesystem - on an LVM snapshot volume without doing some editing with xfs_db. Date: Fri Jun 29 15:29:47 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:98000a linux/fs/xfs/xfs_vfsops.c - 1.319 linux/fs/xfs/xfs_clnt.h - 1.23 linux/fs/xfs/xfs_mount.h - 1.129 linux/fs/xfs/xfs_mount.c - 1.257 linux/fs/xfs/linux/xfs_super.c - 1.129 linux/Documentation/filesystems/xfs.txt - 1.6 - Add nouuid mount option From owner-linux-xfs@oss.sgi.com Fri Jun 29 15:36:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5TMawd00965 for linux-xfs-outgoing; Fri, 29 Jun 2001 15:36:58 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5TMavV00958 for ; Fri, 29 Jun 2001 15:36:58 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA25977 for ; Fri, 29 Jun 2001 15:36:51 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA815735 for ; Fri, 29 Jun 2001 17:35:41 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA88185 for ; Fri, 29 Jun 2001 17:35:41 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.2/SGI-client-1.7) id f5TMbGm26714; Fri, 29 Jun 2001 17:37:16 -0500 Message-Id: <200106292237.f5TMbGm26714@jen.americas.sgi.com> Date: Fri, 29 Jun 2001 17:37:16 -0500 Subject: TAKE - Fix O_DIRECT read at EOF Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Patch from Mike Ovsiannikov Date: Fri Jun 29 15:34:58 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:98002a linux/fs/pagebuf/page_buf_io.c - 1.86 - Fix up direct I/O read at end of file only return the amount read upto eof. From owner-linux-xfs@oss.sgi.com Fri Jun 29 18:25:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5U1Peq29354 for linux-xfs-outgoing; Fri, 29 Jun 2001 18:25:40 -0700 Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5U1PcV29348 for ; Fri, 29 Jun 2001 18:25:38 -0700 Received: from qn-212-58-163-247.quicknet.nl ([212.58.163.247]:64347 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Sat, 30 Jun 2001 03:25:34 +0200 Message-Id: <4.3.2.7.2.20010630032456.02e6a848@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 30 Jun 2001 03:25:09 +0200 To: linux-xfs@oss.sgi.com From: Simon Pabst (by way of Seth Mos ) Subject: xfsinvutil Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, just noticed something small in xfsinvutil - if I execute it, but there are no entries in /var/xfsdump/inventory/fstab, it gives me xfsinvutil: abnormal termination. keep up the good work Simon Pabst University of Tuebingen, Germany From owner-linux-xfs@oss.sgi.com Fri Jun 29 19:50:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5U2oNv11662 for linux-xfs-outgoing; Fri, 29 Jun 2001 19:50:23 -0700 Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5U2oLV11625 for ; Fri, 29 Jun 2001 19:50:21 -0700 Received: from dsl-squash.corp.sgi.com (nic-30-c48-217.mw.mediaone.net [24.30.48.217]) by demai05.mw.mediaone.net (8.11.1/8.11.1) with ESMTP id f5U2oEK03280; Fri, 29 Jun 2001 22:50:14 -0400 (EDT) Date: Fri, 29 Jun 2001 22:49:57 -0400 (EDT) From: J Landman X-X-Sender: To: Simon Matter cc: Subject: Re: Problem fixed (I think) In-Reply-To: <3B3CEF07.479A0857@ch.sauter-bc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 29 Jun 2001, Simon Matter wrote: > J Landman schrieb: > > > Folks: > > > > I had some problems with xfs that I think I fixed. Basically I had > > cp/mv and others core dump rather than work. What I did is I backed up my > > Can you let me know on how many disks your filesystem was. And > was it IDE or SCSI. If IDE, what kind of chip and what kind of settings? 2 disks, Seagate 181 GB 7200 RPM Ultra 160's, in LVD connection. Using Adaptec 29160. Using the aic7xxx module. Booting off of a Reiserfs partition (will change that when XFS gets into the kernel). > > xfs based data, rebuilt the raido, rebuilt the filesystem, and it now > > Ah, RAID 0, so you have more than one disk? IDE? with DMA (enabled > for most chipsets by default in the RH7.1-XFS kernel? Not IDE. I dont have enough IDE channels to make a good RAID0. > > > > I had built the original file system with the RedHat 7.1 iso based > > images, and tools. I changed distros to Mandrake. Thats when it broke. > > What kernel did you use when it broke? Are you shure you know exactly > when it broke? I used the 2.4.3 mandrake source (included in 8.0). I made a copy of the original tree, patched my cloned tree, and built from there. This was using the mandrake specific patches of about 1 month ago. > > During this time, I was unable to build the development tree (same > > crashes that everyone else was getting, using wither the 2.91.66 or the > > 2.96.3 compilers). I was also unable to apply the patches to a 2.4.5-5mdk > > Mandrake source tree. Got lots of rej's. I am hoping that the work to > > Did you check filesystem consistency somehow? For ex. with rpm -Va > which will show all changes in the distribution file? ?? I used xfs_check for file system consistency checking, and xfs_repair -n. No errors were flagged. The RPM database shouldn't have been corrupted. I didn't check it, but I can do that. > > > > > get it into the kernel accelerates, so we wont have the problems in the > > not too distant future. > > > > Regardless of the minor annoyances, good work folks! > > > > -- > > Joe Landman, > > landman@mediaone.net > > I was suffering filesystem corruption for awhile now and it was very > difficult > to reproduce it. In my case it is not XFS or Raid related but has something > to > do with the IDE subsystem. This was scsi based. The odd thing is that tar, bru, and others worked just fine. It was the packages in fileutils-4.x that died. Considering my build environment is using makefiles with lots of cp/mv stuff, I had to copy it to my IDE to make it work for the last few weeks. I emulated copy with tar -cf - ./ | (cd /target && tar -xvf - ) which worked fine. No data corruption that I could detect. -- Joe Landman, landman@mediaone.net From owner-linux-xfs@oss.sgi.com Sat Jun 30 04:52:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5UBqP507220 for linux-xfs-outgoing; Sat, 30 Jun 2001 04:52:25 -0700 Received: from epimetheus.hosting4u.net ([209.15.2.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5UBqLV07206 for ; Sat, 30 Jun 2001 04:52:21 -0700 Date: Sat, 30 Jun 2001 04:52:21 -0700 Message-Id: <200106301152.f5UBqLV07206@oss.sgi.com> Received: (qmail 2634 invoked from network); 30 Jun 2001 11:52:20 -0000 Received: from earth.hosting4u.net (209.15.2.7) by mail-gate.hosting4u.net with SMTP; 30 Jun 2001 11:52:20 -0000 To: linux-xfs@oss.sgi.com Subject: Re From: adm@mns.com Content-Type: text/html; charset="windows-1251" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk

    Ladies and gentlemen, If you have your own site you have to care about its promotion and advertising in the web. Newest methods of promotion enables millions of people to collect the information about your site. Besides, it`s really important to give the knowledge of your site to useful partners. Click Advertising Group www.CAG.com; developed a new technology of coaxing users into dissemination of information of your site. www.click.da.ru

     

    From owner-linux-xfs@oss.sgi.com Sat Jun 30 06:41:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5UDfak25859 for linux-xfs-outgoing; Sat, 30 Jun 2001 06:41:36 -0700 Received: from gatekeeper.slim (slimnet.xs4all.nl [194.109.194.192]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5UDfYV25853 for ; Sat, 30 Jun 2001 06:41:35 -0700 Received: from inter.nl.net (paragon.slim [192.168.100.26]) by gatekeeper.slim (8.11.0/8.8.7) with ESMTP id f5UDAjf08450 for ; Sat, 30 Jun 2001 15:10:45 +0200 Message-ID: <3B3DD878.94E256DC@inter.nl.net> Date: Sat, 30 Jun 2001 15:47:36 +0200 From: Jurgen Kramer X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Filesystem on XFS partition no longer accessible after writing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I'm having problems with my XFS partition on one of my systems. The partition contains all my MP3 files. This morning I was trying to add a new album to my collection but as soon as something is written to this filesystem it's no longer accessible. The program who's accessing the partition starts to eat up all CPU time (one one processor) and can't be killed. A hard reset is the only solution. After upgrading to the latest CVS version the problem still persists. What could be the problem? I'm running this on a Red Hat 7.0 SMP system. It all worked all some CVS versions ago...;-) Greetings, Jurgen From owner-linux-xfs@oss.sgi.com Sat Jun 30 06:51:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5UDpvn27745 for linux-xfs-outgoing; Sat, 30 Jun 2001 06:51:57 -0700 Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5UDpuV27742 for ; Sat, 30 Jun 2001 06:51:56 -0700 Received: from qn-212-58-163-247.quicknet.nl ([212.58.163.247]:64766 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Sat, 30 Jun 2001 15:51:58 +0200 Message-Id: <4.3.2.7.2.20010630154857.03910850@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 30 Jun 2001 15:51:32 +0200 To: Jurgen Kramer , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Filesystem on XFS partition no longer accessible after writing In-Reply-To: <3B3DD878.94E256DC@inter.nl.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:47 30-6-2001 +0200, Jurgen Kramer wrote: >Hi, > >I'm having problems with my XFS partition on one of my systems. The >partition contains all my MP3 files. This morning I was trying to add a >new album to my collection but as soon as something is written to this >filesystem it's no longer accessible. The program who's accessing the >partition starts to eat up all CPU time (one one processor) and can't be > >killed. A hard reset is the only solution. Are there any messages on the console or in the log. Is it just one partition you can't write to? Do you have problems writing or reading from other applications? Can you give some statistics about your system and disk configuration? Any used hdpram parameters or mount options? >After upgrading to the latest CVS version the problem still persists. >What could be the problem? >I'm running this on a Red Hat 7.0 SMP system. It all worked all some CVS > >versions ago...;-) It still should work. Can you replicate this with an older kernel? And what kernel are you running now? Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sat Jun 30 07:15:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5UEFLZ31583 for linux-xfs-outgoing; Sat, 30 Jun 2001 07:15:21 -0700 Received: from gatekeeper.slim (slimnet.xs4all.nl [194.109.194.192]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5UEFJV31576 for ; Sat, 30 Jun 2001 07:15:20 -0700 Received: from inter.nl.net (paragon.slim [192.168.100.26]) by gatekeeper.slim (8.11.0/8.8.7) with ESMTP id f5UDhsf08530; Sat, 30 Jun 2001 15:43:54 +0200 Message-ID: <3B3DE03C.4854A10E@inter.nl.net> Date: Sat, 30 Jun 2001 16:20:44 +0200 From: Jurgen Kramer X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: linux-xfs@oss.sgi.com Subject: Re: Filesystem on XFS partition no longer accessible afterwriting References: <4.3.2.7.2.20010630154857.03910850@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > Are there any messages on the console or in the log. No there aren't any messages on the console of in the log. > Is it just one partition you can't write to? Yes, the system contains only one XFS partition the rest is plain old ext2. > Do you have problems writing or reading from other applications? Yes, any application writing to the partition makes the partition unusable. Reading doesn't give any problems. >Can you give some statistics about your system and disk configuration? > Any used hdpram parameters or mount options? >From the top of my head: BP6 with dual 500Mhz Celeron / 192MB mem HDD on HPT366 controller Red Hat 7.0 kernel 2.4.6pre5-XFS (latest CVS) no hdparm parameters of special mount options N.b. this setup did work for a long time running Linux-XFS from SGI CVS. But I didn't use this system for a while only updating the kernel from CVS every one and a while. > It still should work. Can you replicate this with an older kernel? > And what kernel are you running now? I'll check further in a moment. Currently the system is not accessible at all. As it doesn't have a keyboard or monitor so I have to connect these to see what's really happening. Greetings, Jurgen From owner-linux-xfs@oss.sgi.com Sat Jun 30 07:26:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5UEQCE00870 for linux-xfs-outgoing; Sat, 30 Jun 2001 07:26:12 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5UEQBV00866 for ; Sat, 30 Jun 2001 07:26:11 -0700 Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA01245 for ; Sat, 30 Jun 2001 07:26:10 -0700 (PDT) mail_from (knuffie@xs4all.nl) Received: from qn-212-58-163-247.quicknet.nl ([212.58.163.247]:64804 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Sat, 30 Jun 2001 16:21:13 +0200 Message-Id: <4.3.2.7.2.20010630161802.02e619d0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 30 Jun 2001 16:20:47 +0200 To: Jurgen Kramer From: Seth Mos Subject: Re: Filesystem on XFS partition no longer accessible afterwriting Cc: linux-xfs@oss.sgi.com In-Reply-To: <3B3DE03C.4854A10E@inter.nl.net> References: <4.3.2.7.2.20010630154857.03910850@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 16:20 30-6-2001 +0200, Jurgen Kramer wrote: >Seth Mos wrote: > > > Do you have problems writing or reading from other applications? What compiler did you use for compiling your kernel? >Yes, any application writing to the partition makes the partition unusable. >Reading doesn't give any problems. > > >Can you give some statistics about your system and disk configuration? > > Any used hdpram parameters or mount options? > > From the top of my head: > >BP6 with dual 500Mhz Celeron / 192MB mem >HDD on HPT366 controller >Red Hat 7.0 >kernel 2.4.6pre5-XFS (latest CVS) >no hdparm parameters of special mount options > >N.b. this setup did work for a long time running Linux-XFS from SGI CVS. But >I didn't use >this system for a while only updating the kernel from CVS every one and a >while. The setup should be ok. > > It still should work. Can you replicate this with an older kernel? > > And what kernel are you running now? > >I'll check further in a moment. Currently the system is not accessible at >all. >As it doesn't have a keyboard or monitor so I have to connect these to see >what's really happening. The only think that comes up at the moment is kernel compiled with gcc instead of kgcc You could try checking the fs with xfs_repair to see if something is wrong. Bye -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sat Jun 30 08:03:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5UF3rM05918 for linux-xfs-outgoing; Sat, 30 Jun 2001 08:03:53 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5UF3nV05913 for ; Sat, 30 Jun 2001 08:03:50 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA20316 for ; Sat, 30 Jun 2001 08:03:43 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA31974; Sat, 30 Jun 2001 08:03:16 -0700 (PDT) Message-ID: <3B3DE98B.9B7248F0@sgi.com> Date: Sat, 30 Jun 2001 10:00:27 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Jurgen Kramer CC: linux-xfs@oss.sgi.com Subject: Re: Filesystem on XFS partition no longer accessible after writing References: <3B3DD878.94E256DC@inter.nl.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jurgen Kramer wrote: > > The program who's accessing the > partition starts to eat up all CPU time (one one processor) and can't be > killed. A hard reset is the only solution. If you're running the CVS version, then you have kdb source in the tree. If you turned it on in your .config, perhaps we can figure out what's going on. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sat Jun 30 08:20:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5UFKSp07708 for linux-xfs-outgoing; Sat, 30 Jun 2001 08:20:28 -0700 Received: from gatekeeper.slim (slimnet.xs4all.nl [194.109.194.192]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5UFKPV07705 for ; Sat, 30 Jun 2001 08:20:25 -0700 Received: from inter.nl.net (paragon.slim [192.168.100.26]) by gatekeeper.slim (8.11.0/8.8.7) with ESMTP id f5UEn6f08684; Sat, 30 Jun 2001 16:49:06 +0200 Message-ID: <3B3DEF84.D2CC1B15@inter.nl.net> Date: Sat, 30 Jun 2001 17:25:56 +0200 From: Jurgen Kramer X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: linux-xfs@oss.sgi.com Subject: Re: Filesystem on XFS partition no longer accessible afterwriting (problem solved) References: <4.3.2.7.2.20010630154857.03910850@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, After getting the system back up online I checked the Makefile. It defaults to using gcc which is not a problem with RH7.1. After changing it back to kgcc and recompiling the kernel it works like a charm again. So confusing two different systems...;-). So there are no problems with XFS just the usual RH gcc stuff... Cheers, Jurgen Seth Mos wrote: > At 15:47 30-6-2001 +0200, Jurgen Kramer wrote: > >Hi, > > > >I'm having problems with my XFS partition on one of my systems. The > >partition contains all my MP3 files. This morning I was trying to add a > >new album to my collection but as soon as something is written to this > >filesystem it's no longer accessible. The program who's accessing the > >partition starts to eat up all CPU time (one one processor) and can't be > > > >killed. A hard reset is the only solution. > > Are there any messages on the console or in the log. Is it just one > partition you can't write to? > Do you have problems writing or reading from other applications? > Can you give some statistics about your system and disk configuration? > Any used hdpram parameters or mount options? > > >After upgrading to the latest CVS version the problem still persists. > >What could be the problem? > >I'm running this on a Red Hat 7.0 SMP system. It all worked all some CVS > > > >versions ago...;-) > > It still should work. Can you replicate this with an older kernel? > And what kernel are you running now? > > Cheers > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. From owner-linux-xfs@oss.sgi.com Sat Jun 30 15:43:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5UMhZM18965 for linux-xfs-outgoing; Sat, 30 Jun 2001 15:43:35 -0700 Received: from web10406.mail.yahoo.com (web10406.mail.yahoo.com [216.136.130.98]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5UMhYV18962 for ; Sat, 30 Jun 2001 15:43:35 -0700 Message-ID: <20010630224334.56287.qmail@web10406.mail.yahoo.com> Received: from [203.97.2.242] by web10406.mail.yahoo.com; Sun, 01 Jul 2001 08:43:34 EST Date: Sun, 1 Jul 2001 08:43:34 +1000 (EST) From: =?iso-8859-1?q?Steve=20Kieu?= Subject: more patches needed , please ... To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Ok i have just got the root xfs running but I can not find xfs patch for the more recent kernel. Only 2.4.2 and 2.4.3 supported and unfortunately these version contains the loop device bug. I can not use the pre-compiled for redhat as i need full kernel source to compile ltmodem modules and some special module as well, wow things are complicated. All other attempts to patch to higher version result errors. And the file is big, I dont want tp patch by hand. I think sgi should at least provide for 2.4.4 and 2.4.5 no ac series someone complain that alan does release so quick....; thanks ; if some one know where the patch for 2.4.4 etc... is pls let me know. ===== S.KIEU _____________________________________________________________________________ http://messenger.yahoo.com.au - Yahoo! Messenger - Voice chat, mail alerts, stock quotes and favourite news and lots more! From owner-linux-xfs@oss.sgi.com Sat Jun 30 16:18:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5UNIGV25021 for linux-xfs-outgoing; Sat, 30 Jun 2001 16:18:16 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5UNIFV25018 for ; Sat, 30 Jun 2001 16:18:15 -0700 Received: from relay1.corp.sgi.com (corp.sgi.com [198.29.75.13]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA03878 for ; Sat, 30 Jun 2001 16:18:14 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from sgi.com (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA72485; Sat, 30 Jun 2001 16:17:42 -0700 (PDT) Message-ID: <3B3E5D85.9F628DE7@sgi.com> Date: Sat, 30 Jun 2001 18:15:17 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Steve Kieu CC: linux-xfs@oss.sgi.com Subject: Re: more patches needed , please ... References: <20010630224334.56287.qmail@web10406.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Kieu wrote: > I think sgi should at least provide for 2.4.4 and > 2.4.5 ftp://oss.sgi.com/projects/xfs/download/testing/Release-1.0.1-PR3/patches And cvs is at 2.4.6-pre7. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sat Jun 30 16:18:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5UNIxk25169 for linux-xfs-outgoing; Sat, 30 Jun 2001 16:18:59 -0700 Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5UNIwV25166 for ; Sat, 30 Jun 2001 16:18:58 -0700 Received: from mindspring.com (sdn-ar-005watacoP257.dialsprint.net [206.133.237.147]) by barry.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id TAA22720; Sat, 30 Jun 2001 19:18:55 -0400 (EDT) Message-ID: <3B3E6120.4060705@mindspring.com> Date: Sat, 30 Jun 2001 16:30:40 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 X-Accept-Language: en-us MIME-Version: 1.0 To: Steve Kieu CC: linux-xfs@oss.sgi.com Subject: Re: more patches needed , please ... References: <20010630224334.56287.qmail@web10406.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You can always try the cvs code :). It's currently up through 2.4.6-pre7. Also, check in the mailing list itself. I remember seeing link(s) to 2.4.5 etc... -Walt Steve Kieu wrote: >Hi, > >Ok i have just got the root xfs running but I can not >find xfs patch for the more recent kernel. Only 2.4.2 >and 2.4.3 supported and unfortunately these version >contains the loop device bug. I can not use the >pre-compiled for redhat as i need full kernel source >to compile ltmodem modules and some special module as >well, wow things are complicated. All other attempts >to patch to higher version result errors. And the file >is big, I dont want tp patch by hand. > > >I think sgi should at least provide for 2.4.4 and >2.4.5 > >no ac series someone complain that alan does release >so quick....; > >thanks ; if some one know where the patch for 2.4.4 >etc... is pls let me know. > > >===== >S.KIEU > >_____________________________________________________________________________ >http://messenger.yahoo.com.au - Yahoo! Messenger >- Voice chat, mail alerts, stock quotes and favourite news and lots more! > From owner-linux-xfs@oss.sgi.com Sat Jun 30 16:50:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5UNoV630835 for linux-xfs-outgoing; Sat, 30 Jun 2001 16:50:31 -0700 Received: from newone.spinn.net (IDENT:root@spinnone.spinn.net [216.223.224.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5UNoUV30831 for ; Sat, 30 Jun 2001 16:50:30 -0700 Received: from spinn.net (dialip4.spinn.net [216.223.225.4]) by newone.spinn.net (8.9.3/8.9.3) with ESMTP id RAA14072; Sat, 30 Jun 2001 17:49:37 -0600 Message-ID: <3B3DBEBB.528E15A0@spinn.net> Date: Sat, 30 Jun 2001 05:57:47 -0600 From: dru levin X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: hopefully, there is "straight forward" solution Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk howdy, everything is peachy with 7.1 (with xfs) install, but how can I disable the devfs from mounting, even temporarily??? I'm loading XFS support solely to mount several Jaz cartridges that were formated with XFS, and I would like to make changes to /dev in order to get "subsequent" mounts to work (XFS). I tried: append="devfs=nomount" in lilo.conf but "devfs" is mounting elsewhere. is there a "workaround" or a "fix" for "non-hackers" like myself to disable devfs?? I know it is a good daemon, but I would like to disable it. thanx, dru From owner-linux-xfs@oss.sgi.com Sat Jun 30 18:09:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6119xi10584 for linux-xfs-outgoing; Sat, 30 Jun 2001 18:09:59 -0700 Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6119rV10566 for ; Sat, 30 Jun 2001 18:09:53 -0700 Received: from ev1.net ([64.217.125.35]) by mta4.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with ESMTP id <0GFR00CLZSJXKW@mta4.rcsntx.swbell.net> for linux-xfs@oss.sgi.com; Sat, 30 Jun 2001 20:09:33 -0500 (CDT) Date: Sat, 30 Jun 2001 20:09:26 -0500 From: rkelsoe@ev1.net Subject: Re: hopefully, there is "straight forward" solution To: dru levin Cc: linux-xfs@oss.sgi.com Message-id: <3B3E7846.D9154510@ev1.net> MIME-version: 1.0 X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <3B3DBEBB.528E15A0@spinn.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk dru levin wrote: > > howdy, > > everything is peachy with 7.1 (with xfs) install, but how can I disable > the devfs from mounting, even temporarily??? I'm loading XFS support > solely > to mount several Jaz cartridges that were formated with XFS, and I would > like to > make changes to /dev in order to get "subsequent" mounts to work (XFS). > > I tried: > > append="devfs=nomount" in lilo.conf but "devfs" is mounting elsewhere. > > is there a "workaround" or a "fix" for "non-hackers" like myself to > disable devfs?? > I know it is a good daemon, but I would like to disable it. > > thanx, > > dru What does your lilo.conf file look like? My append statement is: append="ramdisk_size=2500 devfs=nomount" and devfs is not running. Do you have more than one append, maybe? RK -- Randy Kelsoe Dae Richt, Fear Nacht