From owner-linux-xfs@oss.sgi.com Thu Nov 1 07:20:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1FKsQ12242 for linux-xfs-outgoing; Thu, 1 Nov 2001 07:20:54 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1FKl012220 for ; Thu, 1 Nov 2001 07:20:48 -0800 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 HAA08628 for ; Thu, 1 Nov 2001 07:20:44 -0800 (PST) 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 JAA3470796; Thu, 1 Nov 2001 09:19:26 -0600 (CST) Received: from jen.americas.sgi.com (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 JAA99165; Thu, 1 Nov 2001 09:19:26 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA1FFUe09765; Thu, 1 Nov 2001 09:15:30 -0600 Subject: Re: I/O error in filesystem ("md(9,2)") meta-data dev 0x903 From: Steve Lord To: Andrew Klaassen Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011031215410.F3514@dkp.com> References: <20011031215410.F3514@dkp.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99+cvs.2001.10.31.06.29 (Preview Release) Date: 01 Nov 2001 09:15:30 -0600 Message-Id: <1004627730.9702.4.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2001-10-31 at 20:54, Andrew Klaassen wrote: > Okay... > > Just had an error on a production fileserver. If I'm reading > the error correctly, it means that there was an I/O error on the > log device, which caused XFS to shut down. The I/O error > appears to have been the result of XFS sending multiple requests > for the same block to the RAID subsystem (whatever that means). > > I killed all daemons accessing the device, unmounted the array, > ran xfs_repair, and put the array back into service. > > Did I do the right thing? > > Is my diagnosis correct? > > Here's the relevant entry from my /etc/fstab: > > /dev/md2 /n/bubba1 xfs rw,defaults,logbufs=4,logdev=/dev/md3 0 0 > > ...and here are the error messages: > > Oct 31 20:29:15 bubba kernel: raid5: multiple 1 requests for sector 65277048 > Oct 31 21:24:00 bubba kernel: I/O error in filesystem ("md(9,2)") meta-data dev 0x903 block 0x17f07 > Oct 31 21:24:00 bubba kernel: ("") error -1070893103 buf count 5 > Oct 31 21:24:00 bubba kernel: xfs_force_shutdown(md(9,2),0x2) called from line 940 of file xfs_log.c. Return address = 0xc01c329c > Oct 31 21:24:00 bubba kernel: Log I/O Error Detected. Shutting down filesystem: md(9,2) > > Hmmm.... I notice there's a long delay between the "multiple 1 > requests..." and the filesystem shutdown. Perhaps they have > nothing to do with each other - and yet that's the only > "multiple 1 requests..." error in the past week of logs. > > Andrew Klaassen Which kernel version was this? Also, can you send me the raidtab which defines the volume? Thanks Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Nov 1 07:49:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1Fn4P12911 for linux-xfs-outgoing; Thu, 1 Nov 2001 07:49:04 -0800 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1Fms012885 for ; Thu, 1 Nov 2001 07:48:54 -0800 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id CFA671AB2C for ; Thu, 1 Nov 2001 10:48:53 -0500 (EST) Received: by ranma.dkp.com (Postfix, from userid 168) id 741ED59E32; Thu, 1 Nov 2001 10:48:53 -0500 (EST) Date: Thu, 1 Nov 2001 10:48:53 -0500 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: I/O error in filesystem ("md(9,2)") meta-data dev 0x903 Message-ID: <20011101104853.A7347@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20011031215410.F3514@dkp.com> <1004627730.9702.4.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1004627730.9702.4.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Nov 01, 2001 at 09:15:30AM -0600, Steve Lord wrote: > On Wed, 2001-10-31 at 20:54, > Andrew Klaassen wrote: > > ...and here are the error messages: > > > > Oct 31 20:29:15 bubba kernel: raid5: multiple 1 requests for sector 65277048 > > Oct 31 21:24:00 bubba kernel: I/O error in filesystem ("md(9,2)") meta-data dev 0x903 block 0x17f07 > > Oct 31 21:24:00 bubba kernel: ("") error -1070893103 buf count 5 > > Oct 31 21:24:00 bubba kernel: xfs_force_shutdown(md(9,2),0x2) called from line 940 of file xfs_log.c. Return address = 0xc01c329c > > Oct 31 21:24:00 bubba kernel: Log I/O Error Detected. Shutting down filesystem: md(9,2) > Which kernel version was this? Also, can you send me the > raidtab which defines the volume? 2.4.9, with, I believe, patch-2.4.9-xfs-2001-08-26.bz2 applied. (Not entirely sure on the exact patch, though; the box we built the kernel on is currently offline.) Here are a couple of the fstab entries again: /dev/md1 / xfs defaults 1 1 /dev/md0 /boot xfs defaults 1 2 /dev/md2 /n/bubba1 xfs rw,defaults,logbufs=4,logdev=/dev/md3 0 0 Here's the raidtab: raiddev /dev/md0 raid-level 1 nr-raid-disks 2 chunk-size 64k persistent-superblock 1 #nr-spare-disks 0 device /dev/hda1 raid-disk 0 device /dev/hdd1 raid-disk 1 raiddev /dev/md1 raid-level 1 nr-raid-disks 2 chunk-size 64k persistent-superblock 1 #nr-spare-disks 0 device /dev/hda5 raid-disk 0 device /dev/hdd5 raid-disk 1 raiddev /dev/md2 raid-level 5 nr-raid-disks 12 chunk-size 64k persistent-superblock 1 device /dev/hde raid-disk 0 device /dev/hdf raid-disk 1 device /dev/hdg raid-disk 2 device /dev/hdh raid-disk 3 device /dev/hdi raid-disk 4 device /dev/hdj raid-disk 5 device /dev/hdk raid-disk 6 device /dev/hdl raid-disk 7 device /dev/hdm raid-disk 8 device /dev/hdn raid-disk 9 device /dev/hdo raid-disk 10 device /dev/hdp raid-disk 11 raiddev /dev/md3 raid-level 1 nr-raid-disks 2 chunk-size 64k persistent-superblock 1 #nr-spare-disks 0 device /dev/hda8 raid-disk 0 device /dev/hdd8 raid-disk 1 Andrew Klaassen From owner-linux-xfs@oss.sgi.com Thu Nov 1 09:31:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1HVJQ16434 for linux-xfs-outgoing; Thu, 1 Nov 2001 09:31:19 -0800 Received: from sa-bwmail1.storageapps.com (smtp.storageapps.com [63.101.83.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1HVD016412 for ; Thu, 1 Nov 2001 09:31:13 -0800 Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Nov 2001 12:28:31 -0500 Message-ID: <23D04BDBA646D411BDDD00D0B774B53904602867@SA-BWMAIL1> From: "Christian, Chip" To: "'Eric Sandeen'" , linux-xfs@oss.sgi.com Subject: RE: More testing RPMs Date: Thu, 1 Nov 2001 12:28:30 -0500 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 I'm sure you'll come back and tell me why I'm being stupid... But I am having trouble compiling from kernel-source + kernel-headers. Configure Quota, POSIX ACL, Page Buffer, XFS, XFS Quota. No XFS RT, no XFS DMAPI. On RHL 7.1: compat-glibc-6.2-2.1.3.2 compat-egcs-6.2-1.1.2.14 glibc-devel-2.2.2-10 # make menuconfig; make dep; make bzImage make[4]: Entering directory `/usr/src/linux-2.4.9-6SGI_XFS_PR4/fs/xfs/linux' kgcc -D__KERNEL__ -I/usr/src/linux-2.4.9-6SGI_XFS_PR4/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -Wno-unused -fomit-frame-pointer -pipe -march=i686 -I .. -I /usr/src/linux-2.4.9-6SGI_XFS_PR4/fs -funsigned-char -c -o xfs_griostubs.o xfs_griostubs.c In file included from ../xfs.h:47, from xfs_griostubs.c:36: ../xfs_trans.h:947: parse error before `*' ../xfs_trans.h:947: warning: type defaults to `int' in declaration of `xfs_trans_start' ../xfs_trans.h:947: warning: data definition has no type or storage class ../xfs_trans.h:948: parse error before `*' ../xfs_trans.h:948: warning: function declaration isn't a prototype make[4]: *** [xfs_griostubs.o] Error 1 -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Wednesday, October 31, 2001 16:38 To: linux-xfs@oss.sgi.com Subject: More testing RPMs Ok gang, this time you get "PR4" ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-6 (for RH7.1) ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-7 (for RH7.2) Changes in PR4: * Disabled (broken) xfs support in intermezzo * Merged in a few recent xfs fixes 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 Thu Nov 1 09:49:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1Hnln16772 for linux-xfs-outgoing; Thu, 1 Nov 2001 09:49:47 -0800 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1Hng016749 for ; Thu, 1 Nov 2001 09:49:42 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id fA1HnbF4064333; Thu, 1 Nov 2001 18:49:38 +0100 (CET) Message-Id: <4.3.2.7.2.20011101184655.02c21a20@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Nov 2001 18:47:49 +0100 To: "Christian, Chip" , "'Eric Sandeen'" , linux-xfs@oss.sgi.com From: Seth Mos Subject: RE: More testing RPMs In-Reply-To: <23D04BDBA646D411BDDD00D0B774B53904602867@SA-BWMAIL1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:28 1-11-2001 -0500, Christian, Chip wrote: >I'm sure you'll come back and tell me why I'm being stupid... But I am >having trouble compiling from kernel-source + kernel-headers. > >Configure Quota, POSIX ACL, Page Buffer, XFS, XFS Quota. No XFS RT, no >XFS DMAPI. > >On RHL 7.1: >compat-glibc-6.2-2.1.3.2 >compat-egcs-6.2-1.1.2.14 >glibc-devel-2.2.2-10 > ># make menuconfig; make dep; make bzImage Did you do a make mrproper before this? Don't forget to rescue your .config I have had no problem at all with exactly the same config at work. 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 Nov 1 09:55:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1HtHi16990 for linux-xfs-outgoing; Thu, 1 Nov 2001 09:55:17 -0800 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 fA1HtE016968 for ; Thu, 1 Nov 2001 09:55:14 -0800 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 JAA27707 for ; Thu, 1 Nov 2001 09:55:06 -0800 (PST) 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 LAA3471062; Thu, 1 Nov 2001 11:53:56 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA93777; Thu, 1 Nov 2001 11:53:56 -0600 (CST) Subject: RE: More testing RPMs From: Eric Sandeen To: Seth Mos Cc: "Christian, Chip" , linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20011101184655.02c21a20@pop.xs4all.nl> References: <4.3.2.7.2.20011101184655.02c21a20@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 01 Nov 2001 11:53:43 -0600 Message-Id: <1004637223.5379.15.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Seth - Pretty sure this one's my fault, intermezzo patch remnants messing things up. I'm guessing Chip is building xfs as a module... I sent him a patch to clean it up, I'll toss it on the ftp if it works. -Eric On Thu, 2001-11-01 at 11:47, Seth Mos wrote: > Did you do a make mrproper before this? Don't forget to rescue your .config > > I have had no problem at all with exactly the same config at work. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Nov 1 09:57:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1Hv8T17141 for linux-xfs-outgoing; Thu, 1 Nov 2001 09:57:08 -0800 Received: from linux.nameip.net ([211.187.6.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1Hv1017118 for ; Thu, 1 Nov 2001 09:57:01 -0800 Received: (qmail 1290 invoked from network); 1 Nov 2001 17:59:59 -0000 Received: from unknown (HELO orgio.net) (211.187.6.46) by 0 with SMTP; 1 Nov 2001 17:59:59 -0000 Message-ID: <3BE18D9F.8040300@orgio.net> Date: Fri, 02 Nov 2001 02:59:59 +0900 From: Seung-young Oh User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011013 X-Accept-Language: ko MIME-Version: 1.0 To: "Christian, Chip" CC: "'Eric Sandeen'" , linux-xfs@oss.sgi.com Subject: Re: More testing RPMs References: <23D04BDBA646D411BDDD00D0B774B53904602867@SA-BWMAIL1> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Christian, Chip wrote: > I'm sure you'll come back and tell me why I'm being stupid... But I am having trouble compiling from kernel-source + kernel-headers. > > Configure Quota, POSIX ACL, Page Buffer, XFS, XFS Quota. No XFS RT, no XFS DMAPI. > > On RHL 7.1: > compat-glibc-6.2-2.1.3.2 > compat-egcs-6.2-1.1.2.14 > glibc-devel-2.2.2-10 > > # make menuconfig; make dep; make bzImage > > make[4]: Entering directory `/usr/src/linux-2.4.9-6SGI_XFS_PR4/fs/xfs/linux' > kgcc -D__KERNEL__ -I/usr/src/linux-2.4.9-6SGI_XFS_PR4/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -Wno-unused -fomit-frame-pointer -pipe -march=i686 -I .. -I /usr/src/linux-2.4.9-6SGI_XFS_PR4/fs -funsigned-char -c -o xfs_griostubs.o xfs_griostubs.c > In file included from ../xfs.h:47, > from xfs_griostubs.c:36: > ../xfs_trans.h:947: parse error before `*' > ../xfs_trans.h:947: warning: type defaults to `int' in declaration of `xfs_trans_start' > ../xfs_trans.h:947: warning: data definition has no type or storage class > ../xfs_trans.h:948: parse error before `*' > ../xfs_trans.h:948: warning: function declaration isn't a prototype > make[4]: *** [xfs_griostubs.o] Error 1 > > -----Original Message----- > From: Eric Sandeen [mailto:sandeen@sgi.com] > Sent: Wednesday, October 31, 2001 16:38 > To: linux-xfs@oss.sgi.com > Subject: More testing RPMs > > > Ok gang, this time you get "PR4" > > ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-6 (for RH7.1) > ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-7 (for RH7.2) > > Changes in PR4: > > * Disabled (broken) xfs support in intermezzo > > * Merged in a few recent xfs fixes > > Have fun, > > -Eric > > Hello, I use fully updated RHL7.1, and didn't have any problem with compiling kernel-source w/ kernel-headers. The only differences I found between your setup & mine are; 1. I did configure XFS DMAPI. 2. I've got the updated glibc from RedHat, which is 2.2.4. I don't guarantee the success, but suggest you update your glibc-related RPM's. Happy testing... -- ICQ#: 103231199 From owner-linux-xfs@oss.sgi.com Thu Nov 1 10:18:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1IIew17705 for linux-xfs-outgoing; Thu, 1 Nov 2001 10:18:40 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1IIS017682 for ; Thu, 1 Nov 2001 10:18:29 -0800 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Nov 2001 12:17:40 -0600 Message-ID: <85063BBE668FD411944400D0B744267A8886CA@AUSMAIL> From: "Gonyou, Austin" To: "Gonyou, Austin" , Linux XFS Mailing List Subject: RE: Linux + XFS + SCSI = Problems? Date: Thu, 1 Nov 2001 12:17:34 -0600 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 Can SOMEONE please test this and help out? I'm using pretty generic hardware/software config here. This is a very critical issue. Please help if you can just take 15mins to run the scripts. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Gonyou, Austin [mailto:austin@coremetrics.com] > Sent: Wednesday, October 31, 2001 4:29 PM > To: Linux XFS Mailing List > Subject: RE: Linux + XFS + SCSI = Problems? > > > I just started trying it. Sorry for the conusion. I started > using it because > I put a sleep(1); just after the print garbage and noticed > that the system > was writing out in 4096 byte chunks. The mount options there > are from a > progression of trying different things. > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-796-9023 > email: austin@coremetrics.com > > > -----Original Message----- > > From: Steve Lord [mailto:lord@sgi.com] > > Sent: Wednesday, October 31, 2001 3:45 PM > > To: Gonyou, Austin > > Cc: Linux XFS Mailing List > > Subject: Re: Linux + XFS + SCSI = Problems? > > > > > > On Wed, 2001-10-31 at 15:37, Gonyou, Austin wrote: > > > I'm trying to uncover the root of an issue. > > > The issue is this: > > > When running a perl script I can get perl to jump up to > > 99% cpu. When this > > > happens, I can't kill the process. > > > The only thing I can do to recover properly is reset the > > system. Either > > > power cycle or reset. > > > Is there anyone who could attempt to run the attatched > > script and let me > > > know if they experience something similar? > > > > > > The targe configuration of the box I'm most concerned with > > is as follows: > > > 512MB RAM (ecc, parity, registered) > > > 1x 9GB SCSI HDD(seagate) > > > 1x PCI RAID controller(AMI MegaRAID express) wrthru and > read-cached. > > > DUAL 550 PIII > > > RH 7.1 SGI XFS 1.0 installed or later. > > > non-updated perl 5.6.0(installed with 7.1) > > > Mount options for the filesystem I'm testing with. > > > /dev/sda5 on /home type xfs (rw,biosize=13,logbufs=8,osyncisdsync) > > > > > > 2.4.13 Vanilla kernel + SGI XFS patch for 2.4.13. > > > Attatched are the perl scripts I use to test with. Also the > > kernel config > > > I'm using. I'm pretty desparate here. > > > If you can offer help on this, please help! > > > > > > > > > -- > > > Austin Gonyou > > > Systems Architect, CCNA > > > Coremetrics, Inc. > > > Phone: 512-796-9023 > > > email: austin@coremetrics.com > > > > > > ---- > > > > > > > Austin, you did not tell me you were using biosize, have you tried > > without it? > > > > Steve > > > > -- > > > > Steve Lord voice: > +1-651-683-3511 > > Principal Engineer, Filesystem Software email: lord@sgi.com > > > From owner-linux-xfs@oss.sgi.com Thu Nov 1 11:29:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1JTZi19362 for linux-xfs-outgoing; Thu, 1 Nov 2001 11:29:35 -0800 Received: from sa-bwmail1.storageapps.com (smtp.storageapps.com [63.101.83.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1JTR019336 for ; Thu, 1 Nov 2001 11:29:28 -0800 Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Nov 2001 14:26:45 -0500 Message-ID: <23D04BDBA646D411BDDD00D0B774B5390460286B@SA-BWMAIL1> From: "Christian, Chip" To: "'Seung-young Oh'" , "Christian, Chip" Cc: "'Eric Sandeen'" , linux-xfs@oss.sgi.com Subject: RE: More testing RPMs Date: Thu, 1 Nov 2001 14:26:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Must have been asleep at the switch. I didn't even notice the newer glibc. I was able to build with the patch Eric sent me. Should try with new glibc rpms without the patch... -----Original Message----- From: Seung-young Oh [mailto:so1713@orgio.net] Sent: Thursday, November 01, 2001 13:00 To: Christian, Chip Cc: 'Eric Sandeen'; linux-xfs@oss.sgi.com Subject: Re: More testing RPMs Christian, Chip wrote: > I'm sure you'll come back and tell me why I'm being stupid... But I am having trouble compiling from kernel-source + kernel-headers. > > Configure Quota, POSIX ACL, Page Buffer, XFS, XFS Quota. No XFS RT, no XFS DMAPI. > > On RHL 7.1: > compat-glibc-6.2-2.1.3.2 > compat-egcs-6.2-1.1.2.14 > glibc-devel-2.2.2-10 > > # make menuconfig; make dep; make bzImage > > make[4]: Entering directory `/usr/src/linux-2.4.9-6SGI_XFS_PR4/fs/xfs/linux' > kgcc -D__KERNEL__ -I/usr/src/linux-2.4.9-6SGI_XFS_PR4/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -Wno-unused -fomit-frame-pointer -pipe -march=i686 -I .. -I /usr/src/linux-2.4.9-6SGI_XFS_PR4/fs -funsigned-char -c -o xfs_griostubs.o xfs_griostubs.c > In file included from ../xfs.h:47, > from xfs_griostubs.c:36: > ../xfs_trans.h:947: parse error before `*' > ../xfs_trans.h:947: warning: type defaults to `int' in declaration of `xfs_trans_start' > ../xfs_trans.h:947: warning: data definition has no type or storage class > ../xfs_trans.h:948: parse error before `*' > ../xfs_trans.h:948: warning: function declaration isn't a prototype > make[4]: *** [xfs_griostubs.o] Error 1 > > -----Original Message----- > From: Eric Sandeen [mailto:sandeen@sgi.com] > Sent: Wednesday, October 31, 2001 16:38 > To: linux-xfs@oss.sgi.com > Subject: More testing RPMs > > > Ok gang, this time you get "PR4" > > ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-6 (for RH7.1) > ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-7 (for RH7.2) > > Changes in PR4: > > * Disabled (broken) xfs support in intermezzo > > * Merged in a few recent xfs fixes > > Have fun, > > -Eric > > Hello, I use fully updated RHL7.1, and didn't have any problem with compiling kernel-source w/ kernel-headers. The only differences I found between your setup & mine are; 1. I did configure XFS DMAPI. 2. I've got the updated glibc from RedHat, which is 2.2.4. I don't guarantee the success, but suggest you update your glibc-related RPM's. Happy testing... -- ICQ#: 103231199 From owner-linux-xfs@oss.sgi.com Thu Nov 1 12:23:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1KNhA20611 for linux-xfs-outgoing; Thu, 1 Nov 2001 12:23:43 -0800 Received: from sa-bwmail1.storageapps.com (smtp.storageapps.com [63.101.83.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1KNb020566 for ; Thu, 1 Nov 2001 12:23:37 -0800 Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Nov 2001 15:20:55 -0500 Message-ID: <23D04BDBA646D411BDDD00D0B774B5390460286D@SA-BWMAIL1> From: "Christian, Chip" To: "'Eric Sandeen'" , linux-xfs@oss.sgi.com Subject: RE: More testing RPMs Date: Thu, 1 Nov 2001 15:20:54 -0500 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 Upgrading glibc-devel didn't make a difference, but backing out the intermezzo patch sure did help. Thanks. -Chip -----Original Message----- From: Christian, Chip [mailto:chip_christian@hp.com] Sent: Thursday, November 01, 2001 12:29 To: 'Eric Sandeen'; linux-xfs@oss.sgi.com Subject: RE: More testing RPMs I'm sure you'll come back and tell me why I'm being stupid... But I am having trouble compiling from kernel-source + kernel-headers. Configure Quota, POSIX ACL, Page Buffer, XFS, XFS Quota. No XFS RT, no XFS DMAPI. On RHL 7.1: compat-glibc-6.2-2.1.3.2 compat-egcs-6.2-1.1.2.14 glibc-devel-2.2.2-10 # make menuconfig; make dep; make bzImage make[4]: Entering directory `/usr/src/linux-2.4.9-6SGI_XFS_PR4/fs/xfs/linux' kgcc -D__KERNEL__ -I/usr/src/linux-2.4.9-6SGI_XFS_PR4/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -Wno-unused -fomit-frame-pointer -pipe -march=i686 -I .. -I /usr/src/linux-2.4.9-6SGI_XFS_PR4/fs -funsigned-char -c -o xfs_griostubs.o xfs_griostubs.c In file included from ../xfs.h:47, from xfs_griostubs.c:36: ../xfs_trans.h:947: parse error before `*' ../xfs_trans.h:947: warning: type defaults to `int' in declaration of `xfs_trans_start' ../xfs_trans.h:947: warning: data definition has no type or storage class ../xfs_trans.h:948: parse error before `*' ../xfs_trans.h:948: warning: function declaration isn't a prototype make[4]: *** [xfs_griostubs.o] Error 1 -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Wednesday, October 31, 2001 16:38 To: linux-xfs@oss.sgi.com Subject: More testing RPMs Ok gang, this time you get "PR4" ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-6 (for RH7.1) ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-7 (for RH7.2) Changes in PR4: * Disabled (broken) xfs support in intermezzo * Merged in a few recent xfs fixes 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 Thu Nov 1 12:23:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1KNCF20526 for linux-xfs-outgoing; Thu, 1 Nov 2001 12:23:12 -0800 Received: from localhost.localdomain (p3EE217DA.dip.t-dialin.net [62.226.23.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1KMx020498 for ; Thu, 1 Nov 2001 12:22:59 -0800 Received: from hrz.tu-chemnitz.de (IDENT:cradeke@usher [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id VAA25907; Thu, 1 Nov 2001 21:25:19 +0100 Message-ID: <3BE1AFAF.24AE8F08@hrz.tu-chemnitz.de> Date: Thu, 01 Nov 2001 21:25:19 +0100 From: cradeke X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Gonyou, Austin" , linux-xfs@oss.sgi.com Subject: Re: Linux + XFS + SCSI = Problems? References: <85063BBE668FD411944400D0B744267A8886CA@AUSMAIL> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id fA1KN0020501 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Gonyou, Austin" wrote: > Can SOMEONE please test this and help out? I'm using pretty generic > hardware/software config here. This is a very critical issue. Please help if > you can just take 15mins to run the scripts. > sorry, but I can't do it because my data on disk are important for me.. I also use a dual machine (p3@asus p2b-d) and had the same problem sometimes... I heard that there is a problem with kupdatd... A.C. say somewhere in a kernel mailinglist "it is mysteriuos.. no solution at the moment".. the problem exists since the kernel is SMP-able... what it caused is not easy to say.. for me it occures since I work with ramfs enabled in the kernel and if I use a scsi scannner too... I could not find out when exactly the problem happens. but at the moment the system seems save: no scanner is connected and the ramfs is not touched/mounted and all goes well for about 3 weeks uptime [cradeke@usher radeke]$ uname -a Linux usher 2.4.5-xfs-1.0.1 #7 SMP Wed Oct 31 20:50:40 CET 2001 i686 unknown is the actual kernel.. I saw it with xfs-1.0 and 1.0.1 too may that helps a bit regards c.radeke > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-796-9023 > email: austin@coremetrics.com > > > -----Original Message----- > > From: Gonyou, Austin [mailto:austin@coremetrics.com] > > Sent: Wednesday, October 31, 2001 4:29 PM > > To: Linux XFS Mailing List > > Subject: RE: Linux + XFS + SCSI = Problems? > > > > > > I just started trying it. Sorry for the conusion. I started > > using it because > > I put a sleep(1); just after the print garbage and noticed > > that the system > > was writing out in 4096 byte chunks. The mount options there > > are from a > > progression of trying different things. > > > > -- > > Austin Gonyou > > Systems Architect, CCNA > > Coremetrics, Inc. > > Phone: 512-796-9023 > > email: austin@coremetrics.com > > > > > -----Original Message----- > > > From: Steve Lord [mailto:lord@sgi.com] > > > Sent: Wednesday, October 31, 2001 3:45 PM > > > To: Gonyou, Austin > > > Cc: Linux XFS Mailing List > > > Subject: Re: Linux + XFS + SCSI = Problems? > > > > > > > > > On Wed, 2001-10-31 at 15:37, Gonyou, Austin wrote: > > > > I'm trying to uncover the root of an issue. > > > > The issue is this: > > > > When running a perl script I can get perl to jump up to > > > 99% cpu. When this > > > > happens, I can't kill the process. > > > > The only thing I can do to recover properly is reset the > > > system. Either > > > > power cycle or reset. > > > > Is there anyone who could attempt to run the attatched > > > script and let me > > > > know if they experience something similar? > > > > > > > > The targe configuration of the box I'm most concerned with > > > is as follows: > > > > 512MB RAM (ecc, parity, registered) > > > > 1x 9GB SCSI HDD(seagate) > > > > 1x PCI RAID controller(AMI MegaRAID express) wrthru and > > read-cached. > > > > DUAL 550 PIII > > > > RH 7.1 SGI XFS 1.0 installed or later. > > > > non-updated perl 5.6.0(installed with 7.1) > > > > Mount options for the filesystem I'm testing with. > > > > /dev/sda5 on /home type xfs (rw,biosize=13,logbufs=8,osyncisdsync) > > > > > > > > 2.4.13 Vanilla kernel + SGI XFS patch for 2.4.13. > > > > Attatched are the perl scripts I use to test with. Also the > > > kernel config > > > > I'm using. I'm pretty desparate here. > > > > If you can offer help on this, please help! > > > > > > > > > > > > -- > > > > Austin Gonyou > > > > Systems Architect, CCNA > > > > Coremetrics, Inc. > > > > Phone: 512-796-9023 > > > > email: austin@coremetrics.com > > > > > > > > ---- > > > > > > > > > > Austin, you did not tell me you were using biosize, have you tried > > > without it? > > > > > > Steve > > > > > > -- > > > > > > Steve Lord voice: > > +1-651-683-3511 > > > Principal Engineer, Filesystem Software email: lord@sgi.com > > > > > From owner-linux-xfs@oss.sgi.com Thu Nov 1 14:09:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1M9al22809 for linux-xfs-outgoing; Thu, 1 Nov 2001 14:09:36 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1M9L022776 for ; Thu, 1 Nov 2001 14:09:21 -0800 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Nov 2001 16:08:36 -0600 Message-ID: <85063BBE668FD411944400D0B744267A8886CE@AUSMAIL> From: "Gonyou, Austin" To: "'cradeke'" , "Gonyou, Austin" , linux-xfs@oss.sgi.com Subject: RE: Linux + XFS + SCSI = Problems? Date: Thu, 1 Nov 2001 16:08:25 -0600 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 Thanks VERY much for the response. I sure do appreciate it. That is the one thing I've not done yet, (removed smp), but I hope to do it soon. Of note, it seems to be XFS + SMP, but not EXT2 + SMP, or REISER+ SMP. That much I know so far. Austin -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: cradeke [mailto:chrad@hrz.tu-chemnitz.de] > Sent: Thursday, November 01, 2001 2:25 PM > To: Gonyou, Austin; linux-xfs@oss.sgi.com > Subject: Re: Linux + XFS + SCSI = Problems? > > > "Gonyou, Austin" wrote: > > > Can SOMEONE please test this and help out? I'm using pretty generic > > hardware/software config here. This is a very critical > issue. Please help if > > you can just take 15mins to run the scripts. > > > > sorry, but I can't do it because my data on disk are > important for me.. I also > use a dual machine (p3@asus p2b-d) and had the same problem > sometimes... I > heard that there is a problem with kupdatd... A.C. say > somewhere in a kernel > mailinglist "it is mysteriuos.. no solution at the moment".. > the problem exists > since the kernel is SMP-able... what it caused is not easy to > say.. for me it > occures since I work with ramfs enabled in the kernel and if > I use a scsi > scannner too... I could not find out when exactly the problem > happens. but at > the moment the system seems save: no scanner is connected and > the ramfs is not > touched/mounted and all goes well for about 3 weeks uptime > > [cradeke@usher radeke]$ uname -a > Linux usher 2.4.5-xfs-1.0.1 #7 SMP Wed Oct 31 20:50:40 CET > 2001 i686 unknown > > is the actual kernel.. I saw it with xfs-1.0 and 1.0.1 too > > may that helps a bit > > regards > > c.radeke > > > > > > -- > > Austin Gonyou > > Systems Architect, CCNA > > Coremetrics, Inc. > > Phone: 512-796-9023 > > email: austin@coremetrics.com > > > > > -----Original Message----- > > > From: Gonyou, Austin [mailto:austin@coremetrics.com] > > > Sent: Wednesday, October 31, 2001 4:29 PM > > > To: Linux XFS Mailing List > > > Subject: RE: Linux + XFS + SCSI = Problems? > > > > > > > > > I just started trying it. Sorry for the conusion. I started > > > using it because > > > I put a sleep(1); just after the print garbage and noticed > > > that the system > > > was writing out in 4096 byte chunks. The mount options there > > > are from a > > > progression of trying different things. > > > > > > -- > > > Austin Gonyou > > > Systems Architect, CCNA > > > Coremetrics, Inc. > > > Phone: 512-796-9023 > > > email: austin@coremetrics.com > > > > > > > -----Original Message----- > > > > From: Steve Lord [mailto:lord@sgi.com] > > > > Sent: Wednesday, October 31, 2001 3:45 PM > > > > To: Gonyou, Austin > > > > Cc: Linux XFS Mailing List > > > > Subject: Re: Linux + XFS + SCSI = Problems? > > > > > > > > > > > > On Wed, 2001-10-31 at 15:37, Gonyou, Austin wrote: > > > > > I'm trying to uncover the root of an issue. > > > > > The issue is this: > > > > > When running a perl script I can get perl to jump up to > > > > 99% cpu. When this > > > > > happens, I can't kill the process. > > > > > The only thing I can do to recover properly is reset the > > > > system. Either > > > > > power cycle or reset. > > > > > Is there anyone who could attempt to run the attatched > > > > script and let me > > > > > know if they experience something similar? > > > > > > > > > > The targe configuration of the box I'm most concerned with > > > > is as follows: > > > > > 512MB RAM (ecc, parity, registered) > > > > > 1x 9GB SCSI HDD(seagate) > > > > > 1x PCI RAID controller(AMI MegaRAID express) wrthru and > > > read-cached. > > > > > DUAL 550 PIII > > > > > RH 7.1 SGI XFS 1.0 installed or later. > > > > > non-updated perl 5.6.0(installed with 7.1) > > > > > Mount options for the filesystem I'm testing with. > > > > > /dev/sda5 on /home type xfs > (rw,biosize=13,logbufs=8,osyncisdsync) > > > > > > > > > > 2.4.13 Vanilla kernel + SGI XFS patch for 2.4.13. > > > > > Attatched are the perl scripts I use to test with. Also the > > > > kernel config > > > > > I'm using. I'm pretty desparate here. > > > > > If you can offer help on this, please help! > > > > > > > > > > > > > > > -- > > > > > Austin Gonyou > > > > > Systems Architect, CCNA > > > > > Coremetrics, Inc. > > > > > Phone: 512-796-9023 > > > > > email: austin@coremetrics.com > > > > > > > > > > ---- > > > > > > > > > > > > > Austin, you did not tell me you were using biosize, > have you tried > > > > without it? > > > > > > > > Steve > > > > > > > > -- > > > > > > > > Steve Lord voice: > > > +1-651-683-3511 > > > > Principal Engineer, Filesystem Software email: > lord@sgi.com > > > > > > > > From owner-linux-xfs@oss.sgi.com Thu Nov 1 14:57:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1Mv0D23882 for linux-xfs-outgoing; Thu, 1 Nov 2001 14:57:00 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1Muu023858 for ; Thu, 1 Nov 2001 14:56:56 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fA1MupT04452 for ; Thu, 1 Nov 2001 14:56:51 -0800 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 QAA3398158; Thu, 1 Nov 2001 16:55:34 -0600 (CST) Received: from jen.americas.sgi.com (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 QAA58686; Thu, 1 Nov 2001 16:55:34 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.6/SGI-client-1.7) via ESMTP id fA1MpYP11161; Thu, 1 Nov 2001 16:51:35 -0600 Message-Id: <200111012251.fA1MpYP11161@jen.americas.sgi.com> To: "Sean Kormilo" cc: Linux XFS Subject: Re: Kernel OOPS 2.4.5-XFS-1.0.1 w/Feral FC drivers References: <1004476153.21484.32.camel@wmery000.ca.nortel.com> <1004476985.28795.46.camel@jen.americas.sgi.com> <1004547713.21484.64.camel@wmery000.ca.nortel.com> Comments: In-reply-to "Sean Kormilo" message dated "31 Oct 2001 12:01:53 -0500." Date: Thu, 01 Nov 2001 16:51:34 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Steve, > > Thanks for the quick response. > > I made this change, and the panic no longer occurs there (the one with > the oops output), but I still get the other "scsi_free:Bad offset" > panic. For some reason, that particular panic does not produce the > "oops" type output, so there is no traceback to follow. Any idea how I > can get it to supply me with the oops output? I realize this is likely > no longer an XFS problem, but something in the SCSI layer. You might ask on linux kernel, there are people out there who may recognize the error. > > In terms of this modification you described, are there any system level > impacts to removing this code? Based on the comments there, it doesn't > seem like there should be. Incidentally, I immediately unmount and ther > remount the filesystem once I'm able to do so (ie: once the FC link is > plugged back in). There should be no problem removing the code, other parts of the system will eventually have the same effect. Steve From owner-linux-xfs@oss.sgi.com Thu Nov 1 17:56:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA21uYi28084 for linux-xfs-outgoing; Thu, 1 Nov 2001 17:56:34 -0800 Received: from eclectic.kluge.net (IDENT:root@dsl092-071-242.bos1.dsl.speakeasy.net [66.92.71.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA21uU028062 for ; Thu, 1 Nov 2001 17:56:30 -0800 Received: (from felicity@localhost) by eclectic.kluge.net (8.11.6/8.11.6) id fA21uTS07438 for linux-xfs@oss.sgi.com; Thu, 1 Nov 2001 20:56:29 -0500 Date: Thu, 1 Nov 2001 20:56:29 -0500 From: Theo Van Dinter To: linux-xfs@oss.sgi.com Subject: Re: More testing RPMs Message-ID: <20011101205629.A7408@kluge.net> References: <1004564262.2022.9.camel@stout.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: <1004564262.2022.9.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Wed, Oct 31, 2001 at 03:37:42PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Oct 31, 2001 at 03:37:42PM -0600, Eric Sandeen wrote: > Ok gang, this time you get "PR4" I just started fooling around with PR4 (previously running the available 2.4.3 XFS-patched kernel) on my RH 7.2 boxes. It seems to be working just fine on my Athlon (PR4-athlon installed), but it's having nothing but problems on my Pentium 150 box... The main issues that I've found are completely not XFS related, so they may just be 2.4.9 issues: 1) The box requires a "mem=64M" parameter appended to the kernel parameter line (there's a memory hole at 15-16M, so the 64M can't be detected...) No matter what the lilo.conf file says, 2.4.9PR4 will only see 16M RAM. 2) nfsd won't start up, saying "rpc.nfsd: nfssvc: Address already in use". For the time being, I've reverted to the 2.4.3 kernel which works fine. Has anyone else run into these problems? I'm going to be switching to a new Pentium set of hardware in the near future, which should fix that 16M problem (the current box is a Compaq w/ no BIOS available at bootup. The "system configuration" disks don't give an option for the memory hole...) However, I'm not sure what to make of the nfs problem. (BTW: nfs serving on the 2.4.9PR4 athlon kernel is working fine.) -- Randomly Generated Tagline: Feel free to contact me (flames about my english and the useless of this driver will be redirected to /dev/null, oh no, it's full...). (Michael Beck, describing the PC-speaker sound device) From owner-linux-xfs@oss.sgi.com Thu Nov 1 20:26:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA24QPC30777 for linux-xfs-outgoing; Thu, 1 Nov 2001 20:26:25 -0800 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 fA24QM030755 for ; Thu, 1 Nov 2001 20:26:22 -0800 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 UAA17601 for ; Thu, 1 Nov 2001 20:26:13 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id PAA22337; Fri, 2 Nov 2001 15:25:18 +1100 Date: Fri, 2 Nov 2001 15:25:18 +1100 From: Keith Owens Message-Id: <200111020425.PAA22337@sherman.melbourne.sgi.com> Subject: TAKE - Move definition of CONFIG_XFS_QUOTA Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Nov 1 20:24:47 PST 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:105964a linux/fs/Config.in - 1.68 From owner-linux-xfs@oss.sgi.com Thu Nov 1 20:42:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA24gUb31041 for linux-xfs-outgoing; Thu, 1 Nov 2001 20:42:30 -0800 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 fA24gR031018 for ; Thu, 1 Nov 2001 20:42:28 -0800 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 UAA00621 for ; Thu, 1 Nov 2001 20:41:51 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id PAA31358; Fri, 2 Nov 2001 15:42:10 +1100 Date: Fri, 2 Nov 2001 15:42:10 +1100 From: Keith Owens Message-Id: <200111020442.PAA31358@sherman.melbourne.sgi.com> Subject: TAKE - Allow for XFS compile without any dmapi patch Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I want to be able to build XFS with just the core components, without the lvm, kdb and dmapi patches. That required wrapping a couple of dmapi references in the main XFS code with #ifdef CONFIG_XFS_DMAPI. Date: Thu Nov 1 20:39:46 PST 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:105965a linux/fs/xfs/linux/xfs_file.c - 1.51 From owner-linux-xfs@oss.sgi.com Thu Nov 1 20:53:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA24rdY31329 for linux-xfs-outgoing; Thu, 1 Nov 2001 20:53:39 -0800 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 fA24ra031307 for ; Thu, 1 Nov 2001 20:53:36 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id FAA1468509 for ; Fri, 2 Nov 2001 05:53:34 +0100 (CET) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id PAA32715; Fri, 2 Nov 2001 15:53:21 +1100 Date: Fri, 2 Nov 2001 15:53:21 +1100 From: Keith Owens Message-Id: <200111020453.PAA32715@sherman.melbourne.sgi.com> Subject: TAKE - Revert one CONFIG_XFS_DMAPI change Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Revert one CONFIG_XFS_DMAPI change. The difference between p_integrate Locking and p_integrate Locking/Merging is subtle. Date: Thu Nov 1 20:51:40 PST 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:105966a linux/fs/xfs/linux/xfs_file.c - 1.52 From owner-linux-xfs@oss.sgi.com Thu Nov 1 21:33:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA25XM431971 for linux-xfs-outgoing; Thu, 1 Nov 2001 21:33:22 -0800 Received: from mail15a.boca15-verio.com (mail15a.boca15-verio.com [208.55.91.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA25XH031946 for ; Thu, 1 Nov 2001 21:33:17 -0800 Received: from www.sigmastorage.com (128.241.173.170) by mail15a.boca15-verio.com (RS ver 1.0.60s) with SMTP id 051561732; Fri, 2 Nov 2001 00:32:41 -0500 (EST) Message-ID: <3BE22FA7.D80505E5@sigmastorage.com> Date: Thu, 01 Nov 2001 21:31:19 -0800 From: Matt Ryan X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.12-0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: More testing RPMs References: <1004564262.2022.9.camel@stout.americas.sgi.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 hi - I have a dual-PIII 1GB test box with an adaptec 2400A (ide raid, dpt_i2o module) card. I have a 150GB raid0 array on the card. the box has a roswell install + the 7.2 errata kernel (2.4.9-7). in this configuration, with reiserfs on the raid array, the raid card has been stable (if not showing stellar performance). with the PR4 2.4.9-7 kernel + XFS, however, I can copy 20-30 mb files onto the array, but Bonnie -s 2000 on the array quickly ends up in D state. for reference - going back to reiserfs (but keeping the xfs kernel) works ok. also, the *exact* same test, only with a 3ware 7410 raid0 array instead of the adaptec, is ok. please let me know if there's any other information you'd like me to collect. Matt Eric Sandeen wrote: > > Ok gang, this time you get "PR4" > > ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-6 (for RH7.1) > ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-7 (for RH7.2) > > Changes in PR4: > > * Disabled (broken) xfs support in intermezzo > > * Merged in a few recent xfs fixes > > 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 Thu Nov 1 22:04:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA264qf00851 for linux-xfs-outgoing; Thu, 1 Nov 2001 22:04:52 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA264n000824 for ; Thu, 1 Nov 2001 22:04:49 -0800 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 WAA02685 for ; Thu, 1 Nov 2001 22:04:49 -0800 (PST) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id WAA12570; Thu, 1 Nov 2001 22:04:16 -0800 (PST) Message-ID: <3BE23660.E5C0BF23@sgi.com> Date: Fri, 02 Nov 2001 00:00:00 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Matt Ryan CC: linux-xfs@oss.sgi.com Subject: Re: More testing RPMs References: <1004564262.2022.9.camel@stout.americas.sgi.com> <3BE22FA7.D80505E5@sigmastorage.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Matt - We found a bug in DMAPI today that exhibited similar problems... you might try either recompiling with DMAPI off, or if you'd like to verify, cat 1 > /proc/sys/kdb and take a look at the hung processes in kdb - if they are in mraccessf, waiting for a lock, it's probably the same thing. Thanks, -Eric Matt Ryan wrote: > with the PR4 2.4.9-7 kernel + XFS, however, I can copy 20-30 mb files > onto the array, but Bonnie -s 2000 on the array quickly ends up in D > state. att -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Nov 2 02:30:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA2AUjc04778 for linux-xfs-outgoing; Fri, 2 Nov 2001 02:30:45 -0800 Received: from asterix.hrz.tu-chemnitz.de (asterix.hrz.tu-chemnitz.de [134.109.132.84]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA2AUf004754 for ; Fri, 2 Nov 2001 02:30:41 -0800 Received: from pat.hrz.tu-chemnitz.de ([134.109.132.143] ident=mail) by asterix.hrz.tu-chemnitz.de with esmtp (Exim 3.32 #1) id 15zbav-0003tg-00; Fri, 02 Nov 2001 11:30:37 +0100 Received: from janus.hrz.tu-chemnitz.de ([134.109.132.79] ident=root) by pat.hrz.tu-chemnitz.de with esmtp (Exim 3.32 #2) id 15zbat-0003Si-00; Fri, 02 Nov 2001 11:30:35 +0100 Received: from hrz.tu-chemnitz.de (chrad@localhost.localdomain [127.0.0.1]) by janus.hrz.tu-chemnitz.de (8.9.3/8.9.3) with ESMTP id LAA08811; Fri, 2 Nov 2001 11:30:35 +0100 Message-ID: <3BE275CB.26A76787@hrz.tu-chemnitz.de> Date: Fri, 02 Nov 2001 11:30:35 +0100 From: Charles Radeke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.10smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Gonyou, Austin" , linux-xfs@oss.sgi.com Subject: Re: Linux + XFS + SCSI = Problems? References: <85063BBE668FD411944400D0B744267A8886CE@AUSMAIL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Gonyou, Austin" wrote: > Thanks VERY much for the response. I sure do appreciate it. That is the one > thing I've not done yet, (removed smp), but I hope to do it soon. Of note, > it seems to be XFS + SMP, but not EXT2 + SMP, or REISER+ SMP. That much I > know so far. > Austin > yes, I used reiserfs over a year before I changed (of course 8-)) to xfs.. also at SMP machine and I never had problems as described... possibly xfs is not the basic reason.. I read messegas about 99% cpu running kupdated at a time where xfs was not released... I think more that xfs points out a problem deep in the kernel source.. someone of the freaks will solve it next time I hope, because no one wil run xfs on a SMP server in a view to such problem.. xfs filesystem was mountable after that but files created, changed or opened after the kupdated starts the long run are completely desapeared or filled with "@" after reboot.. very strange situation. that means all you or the system do after the bug occure is complete sensless, no aktion is really done with the filesystem but you can maybe untar 400MB, go in, and compile successfull, make install, or anyrthing, you can work with the installed app; BUT if you reboot all ist lost. c. radeke From owner-linux-xfs@oss.sgi.com Fri Nov 2 04:33:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA2CX0X06543 for linux-xfs-outgoing; Fri, 2 Nov 2001 04:33:00 -0800 Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA2CWt006521 for ; Fri, 2 Nov 2001 04:32:55 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 09144400E0A; Fri, 2 Nov 2001 07:33:05 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 03C942400216; Fri, 2 Nov 2001 07:33:05 -0500 (EST) Date: Fri, 2 Nov 2001 07:33:04 -0500 (EST) From: Mike Burger To: Theo Van Dinter Cc: Subject: Re: More testing RPMs In-Reply-To: <20011101205629.A7408@kluge.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Can you turn off the memory hole? On Thu, 1 Nov 2001, Theo Van Dinter wrote: > On Wed, Oct 31, 2001 at 03:37:42PM -0600, Eric Sandeen wrote: > > Ok gang, this time you get "PR4" > > I just started fooling around with PR4 (previously running the available > 2.4.3 XFS-patched kernel) on my RH 7.2 boxes. It seems to be working > just fine on my Athlon (PR4-athlon installed), but it's having nothing > but problems on my Pentium 150 box... > > The main issues that I've found are completely not XFS related, so they may > just be 2.4.9 issues: > 1) The box requires a "mem=64M" parameter appended to the kernel > parameter line (there's a memory hole at 15-16M, so the 64M can't be > detected...) No matter what the lilo.conf file says, 2.4.9PR4 will > only see 16M RAM. > > 2) nfsd won't start up, saying "rpc.nfsd: nfssvc: Address already in > use". > > For the time being, I've reverted to the 2.4.3 kernel which works fine. Has > anyone else run into these problems? > > I'm going to be switching to a new Pentium set of hardware in the near > future, which should fix that 16M problem (the current box is a Compaq w/ no > BIOS available at bootup. The "system configuration" disks don't give an > option for the memory hole...) However, I'm not sure what to make of the nfs > problem. (BTW: nfs serving on the 2.4.9PR4 athlon kernel is working fine.) > > From owner-linux-xfs@oss.sgi.com Fri Nov 2 06:36:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA2Eaqx09293 for linux-xfs-outgoing; Fri, 2 Nov 2001 06:36:52 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA2Eal009271 for ; Fri, 2 Nov 2001 06:36:47 -0800 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 GAA04534 for ; Fri, 2 Nov 2001 06:36:48 -0800 (PST) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id GAA88631; Fri, 2 Nov 2001 06:36:14 -0800 (PST) Message-ID: <3BE2AE5C.1F307A46@sgi.com> Date: Fri, 02 Nov 2001 08:31:56 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: derek.richardson@pgs.com CC: linux-xfs@oss.sgi.com Subject: Re: XFS use in production environment References: <200111021421.fA2ELTh08913@oss.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Derek - Please don't send HTML mail to the list, our overzealous filters bounce it. :( But welcome to the list, and hopefully someone can answer your questions below... -Eric Derek Richardson wrote: > All, > Hello, I'm a new subscribee, was wondering if anyone knows of any > statistics regarding XFS filesystem use in a serious production > environment, or has personal experience (I take it there's quite a bit > here...). By serious production, I mean a cluster environment (12+ > racks of 32+1 nodes, external fibre disk array, large - 10+ GB - file > r/w's, etc.) that needs to maintain 99% or better uptime. I'm planning > on using either the 2.4.3-12 kernel (standard RedHat, XFS patched in by > SGI - retrieved from the 1.0.1 release section of oss.sgi.com) or > 2.4.9-7 (same) from the testing series (depending on stability and if it > offers any features we need). Also, I need to check w/ my employer, but > I might have a machine or two that I would be willing to do > stability/benchmark testing on. I'll get back to yall on this. But any > suggestions/advice/etc. about this issue would be very much > appreciated. Thanks in advance. > Regards, > Derek R. > -- > Junior Linux Geek > 713-817-1197 (cell) > 713-781-4000 x2267 (office) > "Linux users, fanatical. No way... > HEY! Get that MCSE up on the altar, > Tux must be appeased!" -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Nov 2 06:57:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA2EvP409893 for linux-xfs-outgoing; Fri, 2 Nov 2001 06:57:25 -0800 Received: from eclectic.kluge.net (IDENT:root@dsl092-071-242.bos1.dsl.speakeasy.net [66.92.71.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA2EvL009871 for ; Fri, 2 Nov 2001 06:57:22 -0800 Received: (from felicity@localhost) by eclectic.kluge.net (8.11.6/8.11.6) id fA2EvHu10040; Fri, 2 Nov 2001 09:57:17 -0500 Date: Fri, 2 Nov 2001 09:57:17 -0500 From: Theo Van Dinter To: Mike Burger Cc: linux-xfs@oss.sgi.com Subject: Re: More testing RPMs Message-ID: <20011102095717.A9981@kluge.net> References: <20011101205629.A7408@kluge.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mburger@bubbanfriends.org on Fri, Nov 02, 2001 at 07:33:04AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Nov 02, 2001 at 07:33:04AM -0500, Mike Burger wrote: > Can you turn off the memory hole? # From the original message... "(the current box is a Compaq w/ no BIOS available at bootup. The "system configuration" disks don't give an option for the memory hole...)" This box is an old Compaq Presario "server". There is no accessible BIOS at bootup like on other standard PCs, you have to download the utility disks from Compaq and boot off them (5x 3.5" floppies). When I went through the menus, there were configuration options for a lot of things (onboard SCSI/network, etc.) but memory was: "640k starting at 0", "15M starting at 1M", "48M starting at 16M". No options were able to be changed. To install Linux in the first place (with the standard RH 7.1 installer), I had to do: "mem=exactmap mem=640k@0 mem=63m@1m". I haven't tried that for the running system, but I'm all set to move the hard drive from the Presario to another box I have which I know works very well and avoids the memory hole issue. -- Randomly Generated Tagline: That's not to say that I don't think there are strong arguments for doing it the other way too. I've been trying to warp my brain to see Ilya's point of view, and almost succeeding. :-) -- Larry Wall in <199909010313.UAA16345@kiev.wall.org> From owner-linux-xfs@oss.sgi.com Fri Nov 2 07:11:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA2FBUT10185 for linux-xfs-outgoing; Fri, 2 Nov 2001 07:11:30 -0800 Received: from mailboy.pgs.com (mailboy.pgs.com [157.147.25.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA2FBO010163 for ; Fri, 2 Nov 2001 07:11:24 -0800 Received: from hap.hstn.tensor.pgs.com ([157.147.136.17]) by mailboy.pgs.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25014; Fri, 2 Nov 2001 09:11:22 -0600 (CST) Received: from idoru.hstn.tensor.pgs.com (idoru.hstn.tensor.pgs.com [157.147.92.80]) by hap.hstn.tensor.pgs.com (8.9.3/8.9.3) with ESMTP id JAA06008; Fri, 2 Nov 2001 09:11:23 -0600 (CST) Subject: Re: XFS use in production environment From: Derek Richardson To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <3BE2AE5C.1F307A46@sgi.com> References: <200111021421.fA2ELTh08913@oss.sgi.com> <3BE2AE5C.1F307A46@sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 02 Nov 2001 09:11:09 -0600 Message-Id: <1004713869.1914.17.camel@idoru.hstn.tensor.pgs.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric, My apologies, I'm used to our version/settings of Mailman, which don't mind HTMl. Also, I spoke w/ my employer, and I should be fine to do a bit of stability testing/benchmarking on a machine I have. I can't dedicate a lot (more than a few hours each week) of time, but I'm willing to help. Regards, Derek R. On Fri, 2001-11-02 at 08:31, Eric Sandeen wrote: > Hi Derek - > > Please don't send HTML mail to the list, our overzealous filters bounce > it. :( But welcome to the list, and hopefully someone can answer your > questions below... > > -Eric > > Derek Richardson wrote: > > > All, > > Hello, I'm a new subscribee, was wondering if anyone knows of any > > statistics regarding XFS filesystem use in a serious production > > environment, or has personal experience (I take it there's quite a bit > > here...). By serious production, I mean a cluster environment (12+ > > racks of 32+1 nodes, external fibre disk array, large - 10+ GB - file > > r/w's, etc.) that needs to maintain 99% or better uptime. I'm planning > > on using either the 2.4.3-12 kernel (standard RedHat, XFS patched in by > > SGI - retrieved from the 1.0.1 release section of oss.sgi.com) or > > 2.4.9-7 (same) from the testing series (depending on stability and if it > > offers any features we need). Also, I need to check w/ my employer, but > > I might have a machine or two that I would be willing to do > > stability/benchmark testing on. I'll get back to yall on this. But any > > suggestions/advice/etc. about this issue would be very much > > appreciated. Thanks in advance. > > Regards, > > Derek R. > > -- > > Junior Linux Geek > > 713-817-1197 (cell) > > 713-781-4000 x2267 (office) > > "Linux users, fanatical. No way... > > HEY! Get that MCSE up on the altar, > > Tux must be appeased!" > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. -- Junior Linux Geek 713-817-1197 (cell) 713-781-4000 x2267 (office) "Linux users, fanatical. No way... HEY! Get that MCSE up on the altar, Tux must be appeased!" From owner-linux-xfs@oss.sgi.com Fri Nov 2 09:36:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA2HabI12872 for linux-xfs-outgoing; Fri, 2 Nov 2001 09:36:37 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA2HaT012850 for ; Fri, 2 Nov 2001 09:36:29 -0800 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Nov 2001 11:35:55 -0600 Message-ID: <85063BBE668FD411944400D0B744267A8886D6@AUSMAIL> From: "Gonyou, Austin" To: "'Charles Radeke'" , "Gonyou, Austin" , linux-xfs@oss.sgi.com Subject: RE: Linux + XFS + SCSI = Problems? Date: Fri, 2 Nov 2001 11:35:54 -0600 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 Thanks for the reply Charles. Viele Danke! Anyway, I have concerns which are aligned with what you are speaking of. It is a difficult thing to understand as well since I can make the problem happen at will, but there is not traceable data on it. Strace won't show me anything. Is there something else I could do, while watching my process run away, that could help me diagnose this? Thanks again. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Charles Radeke [mailto:charles.radeke@hrz.tu-chemnitz.de] > Sent: Friday, November 02, 2001 4:31 AM > To: Gonyou, Austin; linux-xfs@oss.sgi.com > Subject: Re: Linux + XFS + SCSI = Problems? > > > "Gonyou, Austin" wrote: > > > Thanks VERY much for the response. I sure do appreciate it. > That is the one > > thing I've not done yet, (removed smp), but I hope to do it > soon. Of note, > > it seems to be XFS + SMP, but not EXT2 + SMP, or REISER+ > SMP. That much I > > know so far. > > Austin > > > > yes, I used reiserfs over a year before I changed (of course > 8-)) to xfs.. > also at SMP machine and I never had problems as described... > possibly xfs is > not the basic reason.. I read messegas about 99% cpu running > kupdated at a > time where xfs was not released... I think more that xfs > points out a problem > deep in the kernel source.. someone of the freaks will solve > it next time I > hope, because no one wil run xfs on a SMP server in a view to > such problem.. > xfs filesystem was mountable after that but files created, > changed or opened > after the kupdated starts the long run are completely > desapeared or filled > with "@" after reboot.. very strange situation. that means > all you or the > system do after the bug occure is complete sensless, no > aktion is really done > with the filesystem but you can maybe untar 400MB, go in, and compile > successfull, make install, or anyrthing, you can work with > the installed app; > BUT if you reboot all ist lost. > > c. radeke > From owner-linux-xfs@oss.sgi.com Fri Nov 2 11:40:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA2Jeb915534 for linux-xfs-outgoing; Fri, 2 Nov 2001 11:40:37 -0800 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 fA2JeY015512 for ; Fri, 2 Nov 2001 11:40:34 -0800 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 LAA15295 for ; Fri, 2 Nov 2001 11:40:25 -0800 (PST) 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 NAA3472106 for ; Fri, 2 Nov 2001 13:39:16 -0600 (CST) Received: from jen.americas.sgi.com (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 NAA05001 for ; Fri, 2 Nov 2001 13:39:16 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA2JZ8G17636; Fri, 2 Nov 2001 13:35:08 -0600 Message-Id: <200111021935.fA2JZ8G17636@jen.americas.sgi.com> Date: Fri, 2 Nov 2001 13:35:08 -0600 Subject: TAKE - merge up to 2.4.14-pre7 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Nov 2 11:38:31 PST 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:105999a linux/mm/vmscan.c - 1.87 linux/mm/swapfile.c - 1.44 linux/mm/swap_state.c - 1.36 linux/mm/page_alloc.c - 1.66 linux/mm/memory.c - 1.68 linux/mm/filemap.c - 1.97 linux/kernel/softirq.c - 1.15 linux/kernel/ksyms.c - 1.117 linux/include/linux/pagemap.h - 1.36 linux/include/linux/mm.h - 1.72 linux/Makefile - 1.148 linux/mm/shmem.c - 1.23 From owner-linux-xfs@oss.sgi.com Fri Nov 2 11:44:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA2Jia815697 for linux-xfs-outgoing; Fri, 2 Nov 2001 11:44:36 -0800 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 fA2JiY015675 for ; Fri, 2 Nov 2001 11:44:34 -0800 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 LAA15591 for ; Fri, 2 Nov 2001 11:44:25 -0800 (PST) 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 NAA3482709 for ; Fri, 2 Nov 2001 13:43:16 -0600 (CST) Received: from jen.americas.sgi.com (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 NAA53336 for ; Fri, 2 Nov 2001 13:43:16 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA2Jd8Q17709; Fri, 2 Nov 2001 13:39:08 -0600 Message-Id: <200111021939.fA2Jd8Q17709@jen.americas.sgi.com> Date: Fri, 2 Nov 2001 13:39:08 -0600 Subject: TAKE - code simplification Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Be nice to the compiler and simplify calls into pagebuf from xfs. Date: Fri Nov 2 11:40:58 PST 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:106000a linux/fs/xfs/xfs_buf.h - 1.76 linux/fs/pagebuf/page_buf.c - 1.101 - Reduce code complexity by making pagebuf interface block not byte based From owner-linux-xfs@oss.sgi.com Fri Nov 2 11:46:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA2Jkxc15862 for linux-xfs-outgoing; Fri, 2 Nov 2001 11:46:59 -0800 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 fA2Jkq015840 for ; Fri, 2 Nov 2001 11:46:54 -0800 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.11.6/8.11.6) id fA2JknT24573 for linux-xfs@oss.sgi.com; Fri, 2 Nov 2001 20:46:49 +0100 Date: Fri, 2 Nov 2001 20:46:49 +0100 From: Krzysztof Rusocki To: linux-xfs@oss.sgi.com Subject: test message. please ignore. Message-ID: <20011102204649.A24564@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 . From owner-linux-xfs@oss.sgi.com Fri Nov 2 12:02:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA2K2QH16381 for linux-xfs-outgoing; Fri, 2 Nov 2001 12:02:26 -0800 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 fA2K2F016359 for ; Fri, 2 Nov 2001 12:02:16 -0800 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.11.6/8.11.6) id fA2K2Cb25406 for linux-xfs@oss.sgi.com; Fri, 2 Nov 2001 21:02:12 +0100 Date: Fri, 2 Nov 2001 21:02:12 +0100 From: Krzysztof Rusocki To: linux-xfs@oss.sgi.com Subject: oops on 2.4.10-xfs Message-ID: <20011102210212.A25054@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 [I was about to write about spam filters right now ... thanks for the hint Steve :) ] Venerable XFS developers, after being up almost a month, my machine, which is acting mainly as a file (ftp/smb) server crashed with 150kB+ of Oops messages, all of which were reported as a 'kernel BUG at page_alloc.c:199!' I was working remotely, and side effect of that behaviour (oops) was inability of execing() anything at shell level - any binary i tried to run exited with segfault. I hesitated if i should attach oops output to this post, and decided not to. If any would like to see that output (also ksymoops filtered) visit http://braxis.co.uk/~kszysiu/xfs/2.4.10/ please. Note also that output provided is everything what was caught by klogd/syslogd until power-down. Kernel was compiled with gcc-3.0.1 (release). What might seem interesting - few hours before crash i noticed Tx timeouts on DM9102 based ethernet but i don't know if it can be related in any way to this... I'll try 2.4.14-pre6/7-xfs in few hours, but as you can see i can't be helpful with reproducing this... - no ideas at all.... Cheers, Krzysztof From owner-linux-xfs@oss.sgi.com Fri Nov 2 12:37:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA2KbxK17173 for linux-xfs-outgoing; Fri, 2 Nov 2001 12:37:59 -0800 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 fA2Kbt017151 for ; Fri, 2 Nov 2001 12:37:55 -0800 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 VAA1406321 for ; Fri, 2 Nov 2001 21:37:53 +0100 (CET) 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 OAA3484331 for ; Fri, 2 Nov 2001 14:36:36 -0600 (CST) Received: from jen.americas.sgi.com (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 OAA10756 for ; Fri, 2 Nov 2001 14:36:36 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA2KWR321600; Fri, 2 Nov 2001 14:32:27 -0600 Message-Id: <200111022032.fA2KWR321600@jen.americas.sgi.com> Date: Fri, 2 Nov 2001 14:32:27 -0600 Subject: TAKE - be nice to the compiler Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This generates better code for the byteswapping code when dealing with constants. It reduces code complexity in a few spots and should reduce the chances of being bitten by the register spill problem. I have been running this for about a week without problems. Date: Fri Nov 2 12:35:02 PST 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:106007a cmd/xfsprogs/include/arch.h - 1.3 linux/fs/xfs_support/arch.h - 1.3 - Change byteswapping macro to allow compiler to generate better code From owner-linux-xfs@oss.sgi.com Sat Nov 3 03:42:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA3BgDG31927 for linux-xfs-outgoing; Sat, 3 Nov 2001 03:42:13 -0800 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 fA3Bg7031905 for ; Sat, 3 Nov 2001 03:42:08 -0800 Received: (from uucp@localhost) by downtown.oche.de (8.9.3/8.9.3/Debian 8.9.3-21) with UUCP id MAA08231 for linux-xfs@oss.sgi.com; Sat, 3 Nov 2001 12:42:04 +0100 Received: (from martin@localhost) by foehn.quickstep.oche.de (8.9.3/8.6.12) id MAA07221; Sat, 3 Nov 2001 12:40:08 +0100 (MET) Date: Sat, 3 Nov 2001 12:40:08 +0100 (MET) Message-Id: <200111031140.MAA07221@foehn.quickstep.oche.de> From: Martin Spott To: linux-xfs@oss.sgi.com Subject: Re: XFS use in production environment X-Newsgroups: list.linux-xfs In-Reply-To: <9ruob6$j9f$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 Derek Richardson wrote: > Hello, I'm a new subscribee, was wondering if anyone knows of any > statistics regarding XFS filesystem use in a serious production > environment, or has personal experience (I take it there's quite a bit > here...). Sorry, I don't know of any statistics. But I might approve that i'm running 2.4.4-XFS on a customers 'PPS' ("Production Planning System", as we call it in Germany). This means the customer _really_ depends on a working machine, otherwise they would be in " real trouble' (TM) after short time. The machine is running since July with only one reboot (to switch power supplies), havingpretty used > 40 GByte filesystems on external FibreChannel array. They're running a OO database in filesystem, so you can imagine that it's I/O dependent. I believe you don't want to use such an old kernel. You'd better want to try a recent one (2.4.13) because of all the fixes that went in. I'm pretty happy with 2.4.13-XFS on the fileserver at work. The only reason I didn't upgrade the kernel on our customer's machine is not to touch the uptime ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Sat Nov 3 08:22:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA3GMK903361 for linux-xfs-outgoing; Sat, 3 Nov 2001 08:22:20 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA3GMH003339 for ; Sat, 3 Nov 2001 08:22:17 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.32 #1 (Debian)) id 1603Yn-0004S9-00; Sat, 03 Nov 2001 08:22:17 -0800 To: Linux XFS Subject: LVM version gone from 0.9.1_beta6 to 0.9.1_beta2 From: Sean Neakums X-Message-Flag: Message text advisory: RANTING, BRAZEN SELF-DECEIT X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Sat, 03 Nov 2001 16:22:17 +0000 Message-ID: <6upu6z964m.fsf@zork.zork.net> Lines: 18 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk All along, the version of LVM in the XFS tree has been 0.9.1_beta6. However, I updated my tree to 2.4.14-pre7, and the version in that tree is 0.9.1_beta2, which is having difficulty with my volume group, perhaps due to a mismatch with the user-space tools. vgscan sees my volume group, but fails to create the /dev/ directory and the block nodes within. Was this version change by accident or design? I had a quick skim over the archives and none of the TAKEs really jumped out as relating to an LVM downgrade. Regards, Sean. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Sat Nov 3 10:06:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA3I6su04473 for linux-xfs-outgoing; Sat, 3 Nov 2001 10:06:54 -0800 Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.6.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA3I6n004451 for ; Sat, 3 Nov 2001 10:06:49 -0800 Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44]) by mxzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id fA3I6l4J083933; Sat, 3 Nov 2001 19:06:47 +0100 (CET) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id TAA21297; Sat, 3 Nov 2001 19:06:47 +0100 (CET) Date: Sat, 3 Nov 2001 19:06:46 +0100 (CET) From: Seth Mos To: Martin Spott cc: linux-xfs@oss.sgi.com Subject: Re: XFS use in production environment In-Reply-To: <200111031140.MAA07221@foehn.quickstep.oche.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, 3 Nov 2001, Martin Spott wrote: > Derek Richardson wrote: > > > Hello, I'm a new subscribee, was wondering if anyone knows of any > > statistics regarding XFS filesystem use in a serious production > > environment, or has personal experience (I take it there's quite a bit > > here...). > > Sorry, I don't know of any statistics. But I might approve that i'm running > 2.4.4-XFS on a customers 'PPS' ("Production Planning System", as we call it > in Germany). This means the customer _really_ depends on a working machine, > otherwise they would be in " real trouble' (TM) after short time. > > The machine is running since July with only one reboot (to switch power > supplies), havingpretty used > 40 GByte filesystems on external FibreChannel > array. They're running a OO database in filesystem, so you can imagine that > it's I/O dependent. > > I believe you don't want to use such an old kernel. You'd better want to try > a recent one (2.4.13) because of all the fixes that went in. I'm pretty > happy with 2.4.13-XFS on the fileserver at work. The only reason I didn't > upgrade the kernel on our customer's machine is not to touch the uptime ;-) You could also use the newer 2.4.9 redhat errata kernels that you can find in the testing directory on the FTP site which works very well on the database server at work. Cheers Seth From owner-linux-xfs@oss.sgi.com Sat Nov 3 10:08:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA3I8Mq04535 for linux-xfs-outgoing; Sat, 3 Nov 2001 10:08:22 -0800 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 fA3I8J004513 for ; Sat, 3 Nov 2001 10:08:19 -0800 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 KAA05310 for ; Sat, 3 Nov 2001 10:07:47 -0800 (PST) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA57766; Sat, 3 Nov 2001 10:07:46 -0800 (PST) Message-ID: <3BE4316B.2E1D71CE@sgi.com> Date: Sat, 03 Nov 2001 12:03:23 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Sean Neakums CC: Linux XFS Subject: Re: LVM version gone from 0.9.1_beta6 to 0.9.1_beta2 References: <6upu6z964m.fsf@zork.zork.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Sean - It was by design... Steve's kernel merge on 10/27 did the deed. > The change in here which may affect people is that the > lvm version has been reverted to the one in Linus's tree. > A later LVM from sistina could be applied over this We had some LVM changes in there for XFS, but no more - I'd suggest getting 1.0.1rc4 and using that w/ the xfs-patched kernel. That's what's in the test RPMs I've put out, and we've had reports of it working well. -Eric Sean Neakums wrote: > Was this version change by accident or design? I had a quick skim > over the archives and none of the TAKEs really jumped out as relating > to an LVM downgrade. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sat Nov 3 10:53:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA3IrHS04985 for linux-xfs-outgoing; Sat, 3 Nov 2001 10:53:17 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA3IrF004963 for ; Sat, 3 Nov 2001 10:53:15 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.32 #1 (Debian)) id 1605ut-00067P-00; Sat, 03 Nov 2001 10:53:15 -0800 To: Linux XFS Subject: Re: LVM version gone from 0.9.1_beta6 to 0.9.1_beta2 References: <6upu6z964m.fsf@zork.zork.net> <3BE4316B.2E1D71CE@sgi.com> From: Sean Neakums X-Message-Flag: Message text advisory: ARGUMENTUM AD HOMINEM, IGNORATIO ELENCHI X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Sat, 03 Nov 2001 18:53:14 +0000 In-Reply-To: <3BE4316B.2E1D71CE@sgi.com> (Eric Sandeen's message of "Sat, 03 Nov 2001 12:03:23 -0600") Message-ID: <6ulmhn8z51.fsf@zork.zork.net> Lines: 13 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk begin Eric Sandeen quotation: > We had some LVM changes in there for XFS, but no more - I'd suggest > getting 1.0.1rc4 and using that w/ the xfs-patched kernel. That's > what's in the test RPMs I've put out, and we've had reports of it > working well. Ah, success. It's working perfectly with 1.0.1-rc4. Thank you! -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Sat Nov 3 12:15:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA3KFw005780 for linux-xfs-outgoing; Sat, 3 Nov 2001 12:15:58 -0800 Received: from graze.net (graze.net [65.207.24.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA3KFs005758 for ; Sat, 3 Nov 2001 12:15:54 -0800 Received: from graze.net (shepherd.graze.net [127.0.0.1]) by graze.net (8.11.2/8.11.2) with SMTP id fA3KFmn13324 for ; Sat, 3 Nov 2001 15:15:48 -0500 Received: from 65.207.24.3 (SquirrelMail authenticated user sheep) by graze.net with HTTP; Sat, 3 Nov 2001 15:15:48 -0500 (EST) Message-ID: <34617.65.207.24.3.1004818548.squirrel@graze.net> Date: Sat, 3 Nov 2001 15:15:48 -0500 (EST) Subject: XFS aware 7.2 installer From: "Brian C. Huffman" To: Reply-To: huffman@graze.net X-Mailer: SquirrelMail (version 1.2.0 [rc2]) 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 All, Has anyone made an XFS aware RH7.2 installer yet? Just curious - I know it takes time to get these things done, but I've been busy and haven't had time to keep up w/ the list. Anxiously awaiting, Brian From owner-linux-xfs@oss.sgi.com Sat Nov 3 12:18:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA3KIYE05880 for linux-xfs-outgoing; Sat, 3 Nov 2001 12:18:34 -0800 Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.6.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA3KIW005858 for ; Sat, 3 Nov 2001 12:18:32 -0800 Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44]) by mxzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id fA3KITvp003580; Sat, 3 Nov 2001 21:18:29 +0100 (CET) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id VAA27000; Sat, 3 Nov 2001 21:18:28 +0100 (CET) Date: Sat, 3 Nov 2001 21:18:28 +0100 (CET) From: Seth Mos To: "Brian C. Huffman" cc: linux-xfs@oss.sgi.com Subject: Re: XFS aware 7.2 installer In-Reply-To: <34617.65.207.24.3.1004818548.squirrel@graze.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 3 Nov 2001, Brian C. Huffman wrote: > All, > > Has anyone made an XFS aware RH7.2 installer yet? Just curious - I know > it takes time to get these things done, but I've been busy and haven't had > time to keep up w/ the list. Not done yet. From owner-linux-xfs@oss.sgi.com Sat Nov 3 15:19:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA3NJBj07595 for linux-xfs-outgoing; Sat, 3 Nov 2001 15:19:11 -0800 Received: from linux.nameip.net ([211.187.6.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA3NJ9007573 for ; Sat, 3 Nov 2001 15:19:09 -0800 Received: (qmail 1577 invoked from network); 3 Nov 2001 23:22:42 -0000 Received: from unknown (HELO orgio.net) (211.187.6.46) by 0 with SMTP; 3 Nov 2001 23:22:42 -0000 Message-ID: <3BE47C42.9040406@orgio.net> Date: Sun, 04 Nov 2001 08:22:42 +0900 From: Seung-young Oh User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011013 X-Accept-Language: ko MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Dear RedHat-XFS developers, Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I wonder if anyone noticed that there are updated 2.4.9 RH kernels available for RH7.1 & 7.2... http://www.redhat.com/support/errata/RHSA-2001-142.html -- ICQ#: 103231199 From owner-linux-xfs@oss.sgi.com Sat Nov 3 15:27:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA3NRxt07767 for linux-xfs-outgoing; Sat, 3 Nov 2001 15:27:59 -0800 Received: from k-7.stesmi.com (IDENT:root@as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA3NRu007745 for ; Sat, 3 Nov 2001 15:27:56 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by k-7.stesmi.com (8.11.2/8.8.7) with ESMTP id fA3NQsN09979; Sun, 4 Nov 2001 00:26:54 +0100 Message-ID: <3BE47D86.8090309@stesmi.com> Date: Sun, 04 Nov 2001 00:28:06 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20010913 X-Accept-Language: en-us MIME-Version: 1.0 To: Seung-young Oh CC: linux-xfs@oss.sgi.com Subject: Re: Dear RedHat-XFS developers, References: <3BE47C42.9040406@orgio.net> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi. > I wonder if anyone noticed that there are updated 2.4.9 RH kernels > available for RH7.1 & 7.2... > > http://www.redhat.com/support/errata/RHSA-2001-142.html Considering the latest SGI RH-Beta kernels are just those kernels I'd say it's a fair bet. Also, please look at the mailing list archives at http://oss.sgi.com/projects/xfs before posting something similar to list please. This subject has been discussed previously. // Stefan From owner-linux-xfs@oss.sgi.com Sat Nov 3 15:33:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA3NXbV07936 for linux-xfs-outgoing; Sat, 3 Nov 2001 15:33:37 -0800 Received: from k-7.stesmi.com (IDENT:root@as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA3NXV007913 for ; Sat, 3 Nov 2001 15:33:31 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by k-7.stesmi.com (8.11.2/8.8.7) with ESMTP id fA3NWXN09999 for ; Sun, 4 Nov 2001 00:32:33 +0100 Message-ID: <3BE47EDA.6000301@stesmi.com> Date: Sun, 04 Nov 2001 00:33:46 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20010913 X-Accept-Language: en-us MIME-Version: 1.0 To: Linux-XFS Subject: Re: Dear RedHat-XFS developers, References: <3BE47C42.9040406@orgio.net> <3BE47D86.8090309@stesmi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Stefan Smietanowski wrote: > Hi. > > >>I wonder if anyone noticed that there are updated 2.4.9 RH kernels >>available for RH7.1 & 7.2... >> >>http://www.redhat.com/support/errata/RHSA-2001-142.html >> > > Considering the latest SGI RH-Beta kernels are just those kernels I'd > say it's a fair bet. Also, please look at the mailing list archives at > http://oss.sgi.com/projects/xfs before posting something similar to list > please. This subject has been discussed previously. > > // Stefan > > Hmm, replying to myself. No no, I AM sane. I think. Anyway, did the last mail go away as a text mail or a HTML mail? if(html) be(very_sorry); I just noticed my mozilla changed the mail to a different font all of a sudden and it seems to be a html mail although I didn't get the HTML mail editor. Hmm.. Sorry, I take that back, I might be insane after all. // Stefan PS. Great job with XFS. I ran it for a long while at my last job (on linux of course), in several testing and production machines. Not a glitch. :) From owner-linux-xfs@oss.sgi.com Sat Nov 3 15:52:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA3NqWS08142 for linux-xfs-outgoing; Sat, 3 Nov 2001 15:52:32 -0800 Received: from linux.nameip.net ([211.187.6.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA3NqQ008120 for ; Sat, 3 Nov 2001 15:52:26 -0800 Received: (qmail 1622 invoked from network); 3 Nov 2001 23:56:01 -0000 Received: from unknown (HELO orgio.net) (211.187.6.46) by 0 with SMTP; 3 Nov 2001 23:56:01 -0000 Message-ID: <3BE48410.6000207@orgio.net> Date: Sun, 04 Nov 2001 08:56:00 +0900 From: Seung-young Oh User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011013 X-Accept-Language: ko MIME-Version: 1.0 To: Stefan Smietanowski CC: Linux-XFS Subject: Re: Dear RedHat-XFS developers, References: <3BE47C42.9040406@orgio.net> <3BE47D86.8090309@stesmi.com> <3BE47EDA.6000301@stesmi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Stefan Smietanowski wrote: > Stefan Smietanowski wrote: > >> Hi. >> >> >> Considering the latest SGI RH-Beta kernels are just those kernels I'd >> say it's a fair bet. Also, please look at the mailing list archives at >> http://oss.sgi.com/projects/xfs before posting something similar to list >> please. This subject has been discussed previously. >> >> // Stefan >> >> > > > Hmm, replying to myself. No no, I AM sane. I think. > > Anyway, did the last mail go away as a text mail or a HTML mail? > > if(html) > be(very_sorry); > > I just noticed my mozilla changed the mail to a different font all of a > sudden and it seems to be a html mail although I didn't get the HTML > mail editor. > > Hmm.. > > Sorry, I take that back, I might be insane after all. > > // Stefan > > PS. Great job with XFS. I ran it for a long while at my last job (on > linux of course), in several testing and production machines. Not a > glitch. :) > > > I think you're talking about; http://www.redhat.com/support/errata/RHSA-2001-129.html , which the RedHat-XFS test versions are based on. But I was talking about newer 2.4.9; http://www.redhat.com/support/errata/RHSA-2001-142.html -- ICQ#: 103231199 From owner-linux-xfs@oss.sgi.com Sat Nov 3 20:06:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA446Lj10263 for linux-xfs-outgoing; Sat, 3 Nov 2001 20:06:21 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA446H010240 for ; Sat, 3 Nov 2001 20:06:17 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=jaguar.mkp.net) by rover with esmtp (Exim 3.33 #1) id 160EY1-0003me-00; Sat, 03 Nov 2001 23:06:14 -0500 Received: (from mkp@localhost) by jaguar.mkp.net (8.11.2/8.9.3) id fA446AQ05816; Sat, 3 Nov 2001 23:06:10 -0500 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: Seung-young Oh Cc: Linux-XFS Subject: Re: Dear RedHat-XFS developers, References: <3BE47C42.9040406@orgio.net> <3BE47D86.8090309@stesmi.com> <3BE47EDA.6000301@stesmi.com> <3BE48410.6000207@orgio.net> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 03 Nov 2001 23:06:09 -0500 In-Reply-To: <3BE48410.6000207@orgio.net> Message-ID: Lines: 17 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 >>>>> " " == Seung-young Oh writes: > I think you're talking about; > http://www.redhat.com/support/errata/RHSA-2001-129.html > , which the RedHat-XFS test versions are based on. But I was > talking about newer 2.4.9; > http://www.redhat.com/support/errata/RHSA-2001-142.html And the answer is yes. 2.4.9-13 is what we have on the latest ISO. -- 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 Sat Nov 3 20:42:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA44gxP10661 for linux-xfs-outgoing; Sat, 3 Nov 2001 20:42:59 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA44gd010633 for ; Sat, 3 Nov 2001 20:42:40 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) 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 UAA04437 for ; Sat, 3 Nov 2001 20:42:38 -0800 (PST) mail_from (austin@coremetrics.com) Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Sat, 3 Nov 2001 22:40:36 -0600 Message-ID: <85063BBE668FD411944400D0B744267A8886E8@AUSMAIL> From: "Gonyou, Austin" To: "Gonyou, Austin" , "'Charles Radeke'" , "'linux-xfs@oss.sgi.com'" Subject: High disk I/O causes unkillable Processes.(Was Linux + XFS + SCS I = Problems?) Date: Sat, 3 Nov 2001 22:40:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C164EA.D85860C0" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C164EA.D85860C0 Content-Type: text/plain; charset="iso-8859-1" All, After doing some pretty extensive testing I've found the following. Is there someone at SGI who can please please help substantiate my findings this weekend? Here's what I've found so far. 1. RAJavatest.tgz will cause a runaway process almost 100% of the time if using append(>> instead of >) to redirect stdout or stderr to a file(s). 2. spew.pl will cause a runaway process almost 100% of the time unless the system is booted with 'noapic'. I did this on systems with and without i820 or i840. 3. spew-fork.pl will cause a runaway system lock about 50% of the time, a XFS shutdown and kernel oops 25%of the time and nothing another 25% of the time. Either the IO is just too great when writing to 4 files at a time, or something else is wrong. I've seen perl break systems plenty of times before, but the problem here though is that it is successful about 25% of the time. Something is inconsistent I think. So, there you have it. From what I've seen so far, if you are using UP type of system, then it will not happen, only SMP + SCSI seems to be affected.I've tested this on a Dell 1550, 4400, 4350, desktops, and Cubix Density 8xxx series systems. Both with/without MegaRaid drivers. Also to be known, the Java program with it's output redirected is nowhere near as fast as the perl script, but still way beyond the bounds of standard logging. I'm going to test without ACLs turned on and quota off, etc and see what happens. I've reproduced this on far too much hardware to not find this worrysome. I emplore someone to see if they can find the cause of this. I don't know what to do next to profile the system to see what's causing the issue. Of note: Kernel versions: 2.4.5 and > + xfs Optimal Target System: Dual PIII 550, Single 9gb SCSI hdd, AMI MegaRAID Express. (I have reproduced it using just AIC7xxx too though). Could not reproduce the error on 2.4.2 installed 1.0 XFS when using the perl scripts. (the RH Merged kernel I believe no?) If I change the partition which is getting written to to ReiserFS and leaving all the other partitions alone, then the problem is not realized. After running it by AC for a thirdparty opinion, he thinks it might just be a FS deadlock issue somwhere. Seems logical. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com ------_=_NextPart_000_01C164EA.D85860C0 Content-Type: application/octet-stream; name="RAJavatest.tgz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="RAJavatest.tgz" H4sIAAUW4zsAA+2W3U4bRxTH/4sNthcnUApJ+pF2QttkHZPd9WLsC6e+aJOISiSpgDSKEBdre8CL 1rvWfoQixF1foQ/QK66bC5AaqQ/Qd+krND2zNjFxHHFFSKT5XeycM3vOzJmP/WuXuev6T/3AbelN 1w5DnANmyTQr5TJMkyxrqd9WRCsoLZbJri5WzaWKVa6aFF+uVitg5nkUM0wcRnbAGHbacafbDvje O+LOev+R8s9/f/2NFO7AUjGFaxl8lsXnKsbwRRZfZnBdxQSuicdXovPrHBhuCIvceXwj3G8z+C6D mwom7jqeE9UVpLTCLwrSP/otrmBqxfH4o7jT4MG63XCpJ92xHU/BFW1jZcd+bhuu7W0ba1HgeNs1 kaiu+XHQ5A8cETy1PLigIjqPaXxCycOZP8RbWzxQkN1YW7/3+Mn6pgi81ffvr65uKric5MSR4xr3 7IjnoaGQx20UM1jI0w7oGRh5mLiVRwk61TGYWsH0YMLHjR3ejBTMaaPrz0Z+z1MwqxXejqGdsrtd 7tGoC6OGeKurt7baG0Ws7YUR79Be+7EopZfj+MbPlBBRGrc7lPDpiG4Fma7wXDqDFA8C3MBlOnrB GBSxvfScIe86tQq147ePofxJBo1Hz4mkM4UcZjHXD/2d/HFqnxwi9RJjz2ZSx0ivJNY4WQ9fYuLZ MTJHyD5KVdKHmCneOULu6ULy/C2tzKWnZ/949e8LqMUjTB4h/wKXFnrW4avB1DomkwJSyOASsrhK RcxDpYOcpHd5lMmu01qWaRWrSaFXklVdvYgv6+Ng6PM6lznO0n/TXBzW/4ppSv1/Hzidrh9ETJy9 LqRRF9JYU9Vu3HCdJkv+Cdjgkqj7KiP6b2nrImqe+06LCVFnWk+wNjaZHWyHBbav5nbbpONMi4KY J75IPy1rrBFvldj3zOO7b/Rr8ydKPl+ojU6z3pkmBH8ojbXCKOgniDVqBf1Ep7WTyC0/YBpJI3Mo 0KxRc5dZoi0Wk9pzola9J96aGE8kik5ruFOMdqD250+kWieh1vvCqyXjDKZ/XWkvkkT5dKQ1ItIw omCP7bN1upF2Sw9dzrvaIn1MhRo7YE07araZ9pMX0VBxN+Kt+782eTdyfI854hgO1NyB2qvxQL3o Kyi5QILY6/BznuMM/TfNavm1/i+Z1F+yqmVL6v/7QAj/KX1n9Toz4jAwXL9pu8ZOww9DsreNtgjZ Tf4TyGVW/WZJCodEIpFIJBKJRCKRSCQSiUQikUgkEskHyP+9KvMRACgAAA== ------_=_NextPart_000_01C164EA.D85860C0 Content-Type: application/octet-stream; name="spew.pl" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="spew.pl" #!/usr/bin/perl -w=0A= =0A= $|=3D1;=0A= open(FD, ">>spew.out");=0A= while (true) {=0A= print FD "asdklfasd;kfjsad;kfjs;dlj = a;sdlkfnas,nfp9ibvp98ay085hq325l;mndfg'adfa=0A= 'sd;lmf,m/,sd\fasdfna.,mdnf.m,ansdflkjanfoiuahsel;kjrqwe\as\df]adfh\||PP= Ot'rq[tjwq.,mnt/>M>spew.out.$$");=0A= while (true) {=0A= print FD "asdklfasd;kfjsad;kfjs;dlj = a;sdlkfnas,nfp9ibvp98ay085hq325l;mndfg'adfa=0A= 'sd;lmf,m/,sd\fasdfna.,mdnf.m,ansdflkjanfoiuahsel;kjrqwe\as\df]adfh\||PP= Ot'rq[tjwq.,mnt/>M; Sat, 3 Nov 2001 20:43:47 -0800 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 UAA09748 for ; Sat, 3 Nov 2001 20:43:15 -0800 (PST) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id UAA59873; Sat, 3 Nov 2001 20:43:14 -0800 (PST) Message-ID: <3BE4C659.8C699564@sgi.com> Date: Sat, 03 Nov 2001 22:38:49 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Seung-young Oh CC: linux-xfs@oss.sgi.com Subject: Re: Dear RedHat-XFS developers, References: <3BE47C42.9040406@orgio.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Through twists and turns, through 2.4.7, 2.4.9-6, 2.4.9-7, 2.4.9-12, 2.4.9-13, symlink, ptrace, and syncookie exploits, Red Hat has done their best to shake me off their trail... but no luck. I'm a tenacious guy. It'll take more than 5 kernel releases in 3 weeks to thwart me!* ;-) New 7.2 RPMS are available at ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-13/ 7.1 versions will follow in a day or two; in a pinch, you could use the 7.2 RPMs on a 7.1 system - DRM config options are the only difference. Have fun, -Eric *With the help of mkp's excellent intelligence on RH activities... Seung-young Oh wrote: > > I wonder if anyone noticed that there are updated 2.4.9 RH kernels > available for RH7.1 & 7.2... > > http://www.redhat.com/support/errata/RHSA-2001-142.html -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sat Nov 3 21:15:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA45F8311223 for linux-xfs-outgoing; Sat, 3 Nov 2001 21:15:08 -0800 Received: from linux.nameip.net ([211.187.6.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA45F2011201 for ; Sat, 3 Nov 2001 21:15:03 -0800 Received: (qmail 3062 invoked from network); 4 Nov 2001 05:18:39 -0000 Received: from unknown (HELO orgio.net) (211.187.6.46) by 0 with SMTP; 4 Nov 2001 05:18:39 -0000 Message-ID: <3BE4CFAF.4060800@orgio.net> Date: Sun, 04 Nov 2001 14:18:39 +0900 From: Seung-young Oh User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011013 X-Accept-Language: ko MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: Dear RedHat-XFS developers, References: <3BE47C42.9040406@orgio.net> <3BE4C659.8C699564@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > Through twists and turns, through 2.4.7, 2.4.9-6, 2.4.9-7, 2.4.9-12, > 2.4.9-13, symlink, ptrace, and syncookie exploits, Red Hat has done > their best to shake me off their trail... but no luck. I'm a tenacious > guy. It'll take more than 5 kernel releases in 3 weeks to thwart me!* > ;-) > > New 7.2 RPMS are available at > > ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-13/ > > 7.1 versions will follow in a day or two; in a pinch, you could use the > 7.2 RPMs on a 7.1 system - DRM config options are the only difference. > > Have fun, > > -Eric > > *With the help of mkp's excellent intelligence on RH activities... > Aprox. in a couple of days... Cool. By the way, when does this test kernel versions period end? Haven't got any proplem with the test kernel, but just curious... -- ICQ#: 103231199 From owner-linux-xfs@oss.sgi.com Sat Nov 3 21:23:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA45Nuq11390 for linux-xfs-outgoing; Sat, 3 Nov 2001 21:23:56 -0800 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 fA45Nr011368 for ; Sat, 3 Nov 2001 21:23:53 -0800 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 GAA1595296 for ; Sun, 4 Nov 2001 06:23:52 +0100 (CET) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id VAA73714; Sat, 3 Nov 2001 21:23:19 -0800 (PST) Message-ID: <3BE4CFBD.170BAE1B@sgi.com> Date: Sat, 03 Nov 2001 23:18:53 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Seung-young Oh CC: linux-xfs@oss.sgi.com Subject: Re: Dear RedHat-XFS developers, References: <3BE47C42.9040406@orgio.net> <3BE4C659.8C699564@sgi.com> <3BE4CFAF.4060800@orgio.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Soon, I hope! They still need some rigorous internal testing, but I think we're just about there. -Eric Seung-young Oh wrote: > By the way, when does this test kernel versions period end? > Haven't got any proplem with the test kernel, but just curious... -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sun Nov 4 00:37:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA48bhd12659 for linux-xfs-outgoing; Sun, 4 Nov 2001 00:37:43 -0800 Received: from k-7.stesmi.com (IDENT:root@as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA48bd012637 for ; Sun, 4 Nov 2001 00:37:39 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by k-7.stesmi.com (8.11.2/8.8.7) with ESMTP id fA48aVN17347; Sun, 4 Nov 2001 09:36:31 +0100 Message-ID: <3BE4FE5C.3010508@stesmi.com> Date: Sun, 04 Nov 2001 09:37:48 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20010913 X-Accept-Language: en-us MIME-Version: 1.0 To: Seung-young Oh CC: Linux-XFS Subject: Re: Dear RedHat-XFS developers, References: <3BE47C42.9040406@orgio.net> <3BE47D86.8090309@stesmi.com> <3BE47EDA.6000301@stesmi.com> <3BE48410.6000207@orgio.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi. >>> Considering the latest SGI RH-Beta kernels are just those kernels I'd >>> say it's a fair bet. Also, please look at the mailing list archives at >>> http://oss.sgi.com/projects/xfs before posting something similar to list >>> please. This subject has been discussed previously. > http://www.redhat.com/support/errata/RHSA-2001-129.html > > , which the RedHat-XFS test versions are based on. But I was talking > about newer 2.4.9; > > http://www.redhat.com/support/errata/RHSA-2001-142.html It's all in the details. You are right of course and I appologize. I shouldn't answer emails at 00:30 (or whatever it was) on a sunday morning. // Stefan From owner-linux-xfs@oss.sgi.com Sun Nov 4 03:56:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA4BuLq14028 for linux-xfs-outgoing; Sun, 4 Nov 2001 03:56:21 -0800 Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.6.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA4BuI014006 for ; Sun, 4 Nov 2001 03:56:18 -0800 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by mxzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id fA4BuE4K008248; Sun, 4 Nov 2001 12:56:14 +0100 (CET) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id MAA28771; Sun, 4 Nov 2001 12:56:09 +0100 (CET) Date: Sun, 4 Nov 2001 12:56:09 +0100 (CET) From: Seth Mos To: Seung-young Oh cc: Stefan Smietanowski , Linux-XFS Subject: Re: Dear RedHat-XFS developers, In-Reply-To: <3BE48410.6000207@orgio.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, 4 Nov 2001, Seung-young Oh wrote: > I think you're talking about; > > http://www.redhat.com/support/errata/RHSA-2001-129.html > > , which the RedHat-XFS test versions are based on. But I was talking > about newer 2.4.9; > > http://www.redhat.com/support/errata/RHSA-2001-142.html This would be because of the "syncookie incident". You can work around this by disabling syncookies in /etc/sysctl.conf. It is off by default on redhat. You have to enable it specifically. From owner-linux-xfs@oss.sgi.com Sun Nov 4 04:06:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA4C6OA14466 for linux-xfs-outgoing; Sun, 4 Nov 2001 04:06:24 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA4C6H014444 for ; Sun, 4 Nov 2001 04:06:17 -0800 Received: (qmail 2002 invoked from network); 4 Nov 2001 12:06:13 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 4 Nov 2001 12:06:13 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id B1DF6300095; Sun, 4 Nov 2001 23:06:10 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 74F1A9A; Sun, 4 Nov 2001 23:06:10 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Gonyou, Austin" Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: High disk I/O causes unkillable Processes.(Was Linux + XFS + SCS I = Problems?) In-reply-to: Your message of "Sat, 03 Nov 2001 22:40:35 MDT." <85063BBE668FD411944400D0B744267A8886E8@AUSMAIL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Nov 2001 23:06:04 +1100 Message-ID: <1826.1004875564@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 3 Nov 2001 22:40:35 -0600 , "Gonyou, Austin" wrote: >3. spew-fork.pl will cause a runaway system lock about 50% of the time, a >XFS shutdown and kernel oops 25%of the time and nothing another 25% of the >time. Either the IO is just too great when writing to 4 files at a time, or >something else is wrong. I've seen perl break systems plenty of times >before, but the problem here though is that it is successful about 25% of >the time. Something is inconsistent I think. I am running a slightly modified spew.pl in a tight loop on a dual Celeron 466 (Abit BP6), 2.4.14-pre7-xfs, no acl or quota, ncr53c875, a pair of IBM SCSI drivers, no raid. It runs for me with no problems. while (true) ; do rm -f spew.out ; \time ./spew.pl ; done It runs out of space after a while and aborts, but it does not hang for me. Sorry, I cannot reproduce your problem. #!/usr/bin/perl -w $|=1; open(FD, ">>spew.out"); while (1) { print FD "asdklfasd;kfjsad;kfjs;dlj a;sdlkfnas,nfp9ibvp98ay085hq325l;mndfg'adfa 'sd;lmf,m/,sd\fasdfna.,mdnf.m,ansdflkjanfoiuahsel;kjrqwe\as\df]adfh\||PPOt'rq[tjwq.,mnt/>M; Sun, 4 Nov 2001 04:52:30 -0800 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 EAA14516 for ; Sun, 4 Nov 2001 04:52:22 -0800 (PST) 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 GAA3471211 for ; Sun, 4 Nov 2001 06:51:14 -0600 (CST) Received: from jen.americas.sgi.com (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 GAA75423 for ; Sun, 4 Nov 2001 06:51:14 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA4Cknk03793; Sun, 4 Nov 2001 06:46:49 -0600 Message-Id: <200111041246.fA4Cknk03793@jen.americas.sgi.com> Date: Sun, 4 Nov 2001 06:46:49 -0600 Subject: TAKE - merge up to 2.4.14-pre8 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Sun Nov 4 04:49:53 PST 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:106056a linux/mm/vmscan.c - 1.88 linux/mm/swapfile.c - 1.45 linux/mm/page_alloc.c - 1.67 linux/mm/memory.c - 1.69 linux/kernel/printk.c - 1.14 linux/include/linux/timer.h - 1.12 linux/include/linux/tcp.h - 1.8 linux/include/linux/swap.h - 1.47 linux/include/linux/ntfs_fs.h - 1.6 linux/include/asm-ppc/unistd.h - 1.16 linux/include/asm-ppc/smplock.h - 1.8 linux/include/asm-ppc/serial.h - 1.10 linux/include/asm-ppc/pgtable.h - 1.27 linux/include/asm-ppc/machdep.h - 1.19 linux/include/asm-ppc/io.h - 1.15 linux/include/asm-ppc/fcntl.h - 1.8 linux/include/asm-ppc/fads.h - 1.5 linux/include/asm-ppc/cache.h - 1.9 linux/include/asm-ppc/byteorder.h - 1.7 linux/include/asm-ppc/atomic.h - 1.9 linux/include/asm-alpha/hwrpb.h - 1.6 linux/include/asm-alpha/a.out.h - 1.3 linux/fs/ntfs/dir.c - 1.10 linux/fs/nfs/nfs3xdr.c - 1.7 linux/fs/nfs/nfs2xdr.c - 1.9 linux/fs/exec.c - 1.49 linux/fs/binfmt_aout.c - 1.24 linux/drivers/usb/Config.in - 1.49 linux/drivers/char/tty_io.c - 1.37 linux/drivers/char/misc.c - 1.27 linux/drivers/char/Makefile - 1.52 linux/arch/ppc/lib/string.S - 1.7 linux/arch/ppc/kernel/traps.c - 1.23 linux/arch/ppc/kernel/syscalls.c - 1.11 linux/arch/ppc/kernel/smp.c - 1.28 linux/arch/ppc/kernel/setup.c - 1.36 linux/arch/ppc/kernel/prep_setup.c - 1.26 linux/arch/ppc/kernel/ppc_ksyms.c - 1.37 linux/arch/ppc/kernel/ppc_htab.c - 1.15 linux/arch/ppc/kernel/pmac_setup.c - 1.26 linux/arch/ppc/kernel/pci.c - 1.22 linux/arch/ppc/kernel/open_pic.h - 1.10 linux/arch/ppc/kernel/open_pic.c - 1.21 linux/arch/ppc/kernel/misc.S - 1.32 linux/arch/ppc/kernel/idle.c - 1.18 linux/arch/ppc/kernel/head.S - 1.29 linux/arch/ppc/kernel/apus_setup.c - 1.19 linux/arch/ppc/kernel/Makefile - 1.25 linux/arch/ppc/defconfig - 1.35 linux/arch/ppc/config.in - 1.40 linux/arch/ppc/8xx_io/uart.c - 1.16 linux/arch/ppc/8xx_io/commproc.c - 1.11 linux/arch/i386/kernel/io_apic.c - 1.32 linux/arch/i386/kernel/entry.S - 1.42 linux/arch/i386/defconfig - 1.79 linux/arch/i386/config.in - 1.67 linux/arch/alpha/kernel/time.c - 1.19 linux/arch/alpha/kernel/setup.c - 1.23 linux/arch/alpha/kernel/osf_sys.c - 1.27 linux/Makefile - 1.149 linux/Documentation/Configure.help - 1.113 linux/drivers/block/ida_cmd.h - 1.4 linux/drivers/block/cpqarray.c - 1.32 linux/drivers/parport/parport_pc.c - 1.42 linux/drivers/char/ip2main.c - 1.14 linux/drivers/char/ip2/i2lib.h - 1.5 linux/drivers/char/ip2/i2lib.c - 1.6 linux/Documentation/computone.txt - 1.7 linux/arch/ppc/kernel/ppc_asm.h - 1.9 linux/arch/ppc/kernel/head_8xx.S - 1.14 linux/arch/ppc/kernel/gemini_setup.c - 1.19 linux/arch/ppc/kernel/gemini_pci.c - 1.8 linux/arch/alpha/kernel/pci.c - 1.18 linux/include/asm-ppc/m48t35.h - 1.3 linux/arch/ppc/kernel/m8xx_setup.c - 1.19 linux/include/asm-ppc/mpc8xx.h - 1.7 linux/arch/ppc/kernel/oak_setup.c - 1.8 linux/arch/ppc/configs/walnut_defconfig - 1.15 linux/arch/ppc/configs/oak_defconfig - 1.15 linux/arch/ppc/configs/mbx_defconfig - 1.10 linux/arch/ppc/configs/gemini_defconfig - 1.17 linux/arch/ppc/configs/common_defconfig - 1.23 linux/arch/ppc/configs/apus_defconfig - 1.11 linux/include/asm-ppc/oak.h - 1.6 linux/drivers/usb/devio.c - 1.19 linux/arch/ppc/kernel/walnut_setup.c - 1.5 linux/Documentation/filesystems/devfs/ChangeLog - 1.14 linux/fs/devfs/base.c - 1.23 linux/drivers/parport/ChangeLog - 1.22 linux/Documentation/DocBook/Makefile - 1.21 linux/arch/ppc/kernel/m8260_setup.c - 1.12 linux/arch/ppc/8260_io/commproc.c - 1.4 linux/include/asm-ppc/time.h - 1.8 linux/arch/ppc/configs/rpxlite_defconfig - 1.10 linux/arch/ppc/configs/rpxcllf_defconfig - 1.11 linux/arch/ppc/configs/est8260_defconfig - 1.11 linux/arch/ppc/configs/bseip_defconfig - 1.10 linux/include/net/tcp_ecn.h - 1.4 linux/drivers/block/cciss.c - 1.19 linux/drivers/block/cciss_cmd.h - 1.4 linux/include/asm-ppc/uninorth.h - 1.5 linux/mm/oom_kill.c - 1.10 linux/arch/ppc/configs/power3_defconfig - 1.8 linux/arch/ppc/configs/ibmchrp_defconfig - 1.8 linux/include/asm-ppc/spd8xx.h - 1.4 linux/include/asm-ppc/ivms8.h - 1.4 linux/arch/ppc/configs/TQM860L_defconfig - 1.9 linux/arch/ppc/configs/TQM850L_defconfig - 1.8 linux/arch/ppc/configs/TQM823L_defconfig - 1.8 linux/arch/ppc/configs/SPD823TS_defconfig - 1.8 linux/arch/ppc/configs/SM850_defconfig - 1.8 linux/arch/ppc/configs/IVMS8_defconfig - 1.9 linux/fs/char_dev.c - 1.2 linux/arch/ppc/mm/4xx_mmu.c - 1.2 linux/drivers/usb/usbnet.c - 1.5 linux/arch/ppc/mm/cachemap.c - 1.2 linux/arch/ppc/mm/mmu_decl.h - 1.2 linux/include/asm-ppc/ppcboot.h - 1.3 linux/drivers/usb/serial/ir-usb.c - 1.3 From owner-linux-xfs@oss.sgi.com Sun Nov 4 08:43:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA4Ghlv21940 for linux-xfs-outgoing; Sun, 4 Nov 2001 08:43:47 -0800 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 fA4Ghh021917 for ; Sun, 4 Nov 2001 08:43:43 -0800 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 RAA1597261 for ; Sun, 4 Nov 2001 17:43:42 +0100 (CET) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA46408; Sun, 4 Nov 2001 08:43:08 -0800 (PST) Message-ID: <3BE56F10.72A80B4F@sgi.com> Date: Sun, 04 Nov 2001 10:38:40 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Seung-young Oh , linux-xfs@oss.sgi.com Subject: Re: Dear RedHat-XFS developers, References: <3BE47C42.9040406@orgio.net> <3BE4C659.8C699564@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, 7.1 versions are available at ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-12/ -Eric Eric Sandeen wrote: > 7.1 versions will follow in a day or two; in a pinch, you could use the > 7.2 RPMs on a 7.1 system - DRM config options are the only difference. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sun Nov 4 10:06:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA4I6QQ22723 for linux-xfs-outgoing; Sun, 4 Nov 2001 10:06:26 -0800 Received: from dns.securities.com (mail.securities.com [216.74.147.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA4I6L022701 for ; Sun, 4 Nov 2001 10:06:21 -0800 Received: from localhost (venevene@localhost) by dns.securities.com (8.11.6/8.11.6) with ESMTP id fA4I6Ls17076; Sun, 4 Nov 2001 13:06:21 -0500 Date: Sun, 4 Nov 2001 13:06:20 -0500 (EST) From: Benito Venegas To: cc: Eric Sandeen Subject: Re: Dear RedHat-XFS developers, In-Reply-To: <3BE56F10.72A80B4F@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks for this update Eric. One question, I have a lot of Dell PE2450 with perc raid, and I need to apply tha lates patch for this card (linux-2.4.9-aacraid-20010816.patch) that you can find at http://domsch.com/linux/ . I 've been trying to apply in the previous stable kernel 2.4.9-7, but I had some problems. Is it possible you can put in the next beta or release distribution (2.4.9-12.1 :) Thanks for your work . I've learned so much with this list and the labor of this team to make XFS a dream came true in Linux (sorry my english it's a little today in the morning) Cheers.- Benito On Sun, 4 Nov 2001, Eric Sandeen wrote: > Ok, 7.1 versions are available at > > ftp://oss.sgi.com/projects/xfs/download/testing/RH2.4.9-12/ > > -Eric > > Eric Sandeen wrote: > > 7.1 versions will follow in a day or two; in a pinch, you could use the > > 7.2 RPMs on a 7.1 system - DRM config options are the only difference. > > -- Benito A. Venegas System Engineer, Technology 488 Madison Ave. New York, NY 10022 A Euromoney Institutional Investor company. From owner-linux-xfs@oss.sgi.com Sun Nov 4 10:40:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA4Ie4O26388 for linux-xfs-outgoing; Sun, 4 Nov 2001 10:40:04 -0800 Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.6.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA4Ie0026364 for ; Sun, 4 Nov 2001 10:40:00 -0800 Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45]) by mxzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id fA4IdvPV075573; Sun, 4 Nov 2001 19:39:57 +0100 (CET) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id TAA20090; Sun, 4 Nov 2001 19:39:57 +0100 (CET) Date: Sun, 4 Nov 2001 19:39:57 +0100 (CET) From: Seth Mos To: Benito Venegas cc: linux-xfs@oss.sgi.com, Eric Sandeen Subject: Re: Dear RedHat-XFS developers, 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, 4 Nov 2001, Benito Venegas wrote: > > Thanks for this update Eric. > One question, I have a lot of Dell PE2450 with perc raid, and I need to > apply tha lates patch for this card (linux-2.4.9-aacraid-20010816.patch) > that you can find at http://domsch.com/linux/ . > > I 've been trying to apply in the previous stable kernel 2.4.9-7, but I > had some problems. Is it possible you can put in the next beta > or release distribution (2.4.9-12.1 :) If you install these update kernels the driver should be in there. Don't forget to run the mkinitrd command. Those drivers should be in the standard redhat kernels. They have since at least version 7.0 and maybe even 6.2. So I wonder, Eric have you taken these out? Cheers Seth From owner-linux-xfs@oss.sgi.com Sun Nov 4 10:47:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA4Ilac26587 for linux-xfs-outgoing; Sun, 4 Nov 2001 10:47:36 -0800 Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA4IlX026565 for ; Sun, 4 Nov 2001 10:47:33 -0800 Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45]) by mxzilla4.xs4all.nl (8.12.0/8.12.0) with ESMTP id fA4IlJOk029207; Sun, 4 Nov 2001 19:47:19 +0100 (CET) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id TAA20486; Sun, 4 Nov 2001 19:47:19 +0100 (CET) Date: Sun, 4 Nov 2001 19:47:18 +0100 (CET) From: Seth Mos To: Eric Sandeen cc: Seung-young Oh , linux-xfs@oss.sgi.com Subject: RedHat 7.2 In-Reply-To: <3BE56F10.72A80B4F@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 Eric, Have you been able to get some work done on the 7.2 installer with these kernel updates passing through? I just tried a laptop install on my now reformatted harddrive (sigh) but it either fails with an invalid argument or a "you do not seem to have formatted your partition". Does the 1.0.1 Update disk help in this scenario or is this something you have not seen before. I was using the 1.0.1 installer. I don't have 1.0 handy at the moment. Cheers Seth From owner-linux-xfs@oss.sgi.com Sun Nov 4 11:18:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA4JIst27228 for linux-xfs-outgoing; Sun, 4 Nov 2001 11:18:54 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA4JIl027204 for ; Sun, 4 Nov 2001 11:18:47 -0800 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 LAA04154 for ; Sun, 4 Nov 2001 11:18:48 -0800 (PST) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA72306 for ; Sun, 4 Nov 2001 11:18:15 -0800 (PST) Message-ID: <3BE5936A.D9D8A5EA@sgi.com> Date: Sun, 04 Nov 2001 13:13:46 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Test RH 7.2 installer available. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, at long last, for your testing pleasure, the XFS Installer for Red Hat Linux 7.2 is available in "prerelease" form... This installer includes the latest 2.4.9-13 kernel update as well. ftp://oss.sgi.com/projects/xfs/download/testing/RH7.2-installer/ rsync://oss.sgi.com/xfsftp/download/testing/RH7.2-installer/ should also work, but rsync on oss seems to be stuffed up at the moment. Many, many thanks go out to mkp@linuxcare, msw@redhat, and arjanv@redhat for their help with this, as well. Known issues: * Grub support is dicey - sometimes it works, sometimes not. (manually installing grub works fine, but there's a problem with grub installation during setup). Lilo works fine. Any of the grub-heads on the list want to look at this? * Installer will let you put the bootloader on the first sector of a partition - don't do this, only use the MBR. * Boot floppy creation may not work, due to the size of an xfs-enabled kernel. * Some reports of problems with partition editing in text mode. You will need the original Red Hat Linux installation media (both CDs) to complete this installation. Back up your data first, and report problems to the list. 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 Sun Nov 4 11:24:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA4JOr127437 for linux-xfs-outgoing; Sun, 4 Nov 2001 11:24:53 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA4JOo027415 for ; Sun, 4 Nov 2001 11:24:50 -0800 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 LAA04477 for ; Sun, 4 Nov 2001 11:23:35 -0800 (PST) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA19103; Sun, 4 Nov 2001 11:24:17 -0800 (PST) Message-ID: <3BE594D5.DDCA2DF4@sgi.com> Date: Sun, 04 Nov 2001 13:19:49 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: Benito Venegas , linux-xfs@oss.sgi.com Subject: Re: Dear RedHat-XFS developers, References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Seth, Benito - Seth Mos wrote: > Those drivers should be in the standard redhat kernels. They have since at > least version 7.0 and maybe even 6.2. > So I wonder, Eric have you taken these out? The only change made to these RPMs is adding XFS and kdb, and upgrading LVM to 1.0.1rc4. I'm not particularly inclined to start adding various other drivers not related to the filesystem - especially ones I can't test. I'm not certain which version of aacraid is in the RPMs - the module happily reports the version as the date it was built - in this case, yesterday. ;) The patch claims to be linux-2.4.1-aacraid.patch, which doesn't sound terribly up to date. If you're having trouble with aacraid in the RH kernels, I'd file a report at bugzilla.redhat.com. -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 Nov 4 11:30:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA4JUcC27651 for linux-xfs-outgoing; Sun, 4 Nov 2001 11:30:38 -0800 Received: from dns.securities.com (mail.securities.com [216.74.147.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA4JUX027624 for ; Sun, 4 Nov 2001 11:30:33 -0800 Received: from localhost (venevene@localhost) by dns.securities.com (8.11.6/8.11.6) with ESMTP id fA4JUUm18400; Sun, 4 Nov 2001 14:30:30 -0500 Date: Sun, 4 Nov 2001 14:30:30 -0500 (EST) From: Benito Venegas To: Eric Sandeen cc: Seth Mos , Subject: Re: Dear RedHat-XFS developers, In-Reply-To: <3BE594D5.DDCA2DF4@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 will give you my comments later. Now I am testing 2.4.9-12 (amd -13 too) in one test server before to put into production. Thanks for your soon reply Eirc and enjoy this sunday. On Sun, 4 Nov 2001, Eric Sandeen wrote: > > I'm not certain which version of aacraid is in the RPMs - the module > happily reports the version as the date it was built - in this case, > yesterday. ;) The patch claims to be linux-2.4.1-aacraid.patch, which > doesn't sound terribly up to date. > > If you're having trouble with aacraid in the RH kernels, I'd file a > report at bugzilla.redhat.com. > > -Eric > > -- Benito A. Venegas System Engineer, Technology 488 Madison Ave. New York, NY 10022 A Euromoney Institutional Investor company. *************************************************************************** This communication contains information which is confidential. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note any distribution, copying or use of this communication or the information in it is strictly prohibited. If you have received this communication in error please notify us by e-mail or by telephone (as above) and then delete the e-mail and all attachments and any copies thereof. *************************************************************************** From owner-linux-xfs@oss.sgi.com Sun Nov 4 11:41:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA4Jfs227990 for linux-xfs-outgoing; Sun, 4 Nov 2001 11:41:54 -0800 Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.6.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA4Jfn027938 for ; Sun, 4 Nov 2001 11:41:49 -0800 Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44]) by mxzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id fA4Jfm4S087166; Sun, 4 Nov 2001 20:41:48 +0100 (CET) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id UAA24112; Sun, 4 Nov 2001 20:41:48 +0100 (CET) Date: Sun, 4 Nov 2001 20:41:47 +0100 (CET) From: Seth Mos To: Eric Sandeen cc: Benito Venegas , linux-xfs@oss.sgi.com Subject: Re: Dear RedHat-XFS developers, In-Reply-To: <3BE594D5.DDCA2DF4@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 Sun, 4 Nov 2001, Eric Sandeen wrote: > Hi Seth, Benito - > > Seth Mos wrote: > > > Those drivers should be in the standard redhat kernels. They have since at > > least version 7.0 and maybe even 6.2. > > So I wonder, Eric have you taken these out? > > The only change made to these RPMs is adding XFS and kdb, and upgrading > LVM to 1.0.1rc4. I'm not particularly inclined to start adding various > other drivers not related to the filesystem - especially ones I can't > test. OK, then they are included by default. > I'm not certain which version of aacraid is in the RPMs - the module > happily reports the version as the date it was built - in this case, > yesterday. ;) The patch claims to be linux-2.4.1-aacraid.patch, which > doesn't sound terribly up to date. There are probably some other patches lingering around that affects it. The driver is maintained by Adaptec, but Dell is still pushing them to release a opensource driver that is written for solaris. > If you're having trouble with aacraid in the RH kernels, I'd file a > report at bugzilla.redhat.com. I suspect it will work OK. Note that on 2.4.10+ the read speed of the raid controller is about double that of a 2.4.9 kernel. This was noted by people on the linux-poweredge list. Scary! Cheers From owner-linux-xfs@oss.sgi.com Sun Nov 4 11:42:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA4JgB528081 for linux-xfs-outgoing; Sun, 4 Nov 2001 11:42:11 -0800 Received: from home.smithconcepts.com (65.34.25.157.oviedo-ubr-a.cfl.rr.com [65.34.25.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA4Jg7028059 for ; Sun, 4 Nov 2001 11:42:07 -0800 Received: from ieee.org (IDENT:2+ZhpVKesbuyEY8MRClk9QzgfNt5eVQg@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id OAA17941; Sun, 4 Nov 2001 14:35:21 -0500 Message-ID: <3BE59A45.40AFF209@ieee.org> Date: Sun, 04 Nov 2001 14:43:01 -0500 From: Bryan-TheBS-Smith Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-7SGI_XFS_PR3smp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS Installer and GRUB v. LILO ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I just read the following: ftp://oss.sgi.com/projects/xfs/download/testing/RH7.2-installer/CAVEATS And noticed this: > * Grub support is dicey - sometimes it works, sometimes not. > (manually installing grub works fine, but there's a problem > with grub installation during setup). Since LILO is included in RedHat 7.2 as well as GRUB, why doesn't the XFS installer just install LILO instead? > * Installer will let you put the bootloader on the first sector > of a partition - don't do this, only use the MBR. Is this because of GRUB or XFS? I understand that XFS cannot boot this way, but some of us still use Ext2 for our / (root) partition (with no separate /boot) and XFS for everything else. Some of us like to use XOSL loader (among others) as a 3rd party MBR boot loader. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- * Pentium stop, Pentium SMP go, Athlon MP go ... go very fast! * From owner-linux-xfs@oss.sgi.com Sun Nov 4 11:55:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA4Jthh28466 for linux-xfs-outgoing; Sun, 4 Nov 2001 11:55:43 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA4Jtd028444 for ; Sun, 4 Nov 2001 11:55:39 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fA4JtYT09169 for ; Sun, 4 Nov 2001 11:55:34 -0800 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA33245; Sun, 4 Nov 2001 11:55:02 -0800 (PST) Message-ID: <3BE59C0A.4AAB2EC1@sgi.com> Date: Sun, 04 Nov 2001 13:50:34 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Bryan-TheBS-Smith CC: linux-xfs@oss.sgi.com Subject: Re: XFS Installer and GRUB v. LILO ... References: <3BE59A45.40AFF209@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Bryan-TheBS-Smith wrote: > Since LILO is included in RedHat 7.2 as well as GRUB, why doesn't the > XFS installer just install LILO instead? It could, if we don't get grub figured out. > > * Installer will let you put the bootloader on the first sector > > of a partition - don't do this, only use the MBR. > > Is this because of GRUB or XFS? I understand that XFS cannot boot this > way, but some of us still use Ext2 for our / (root) partition (with no > separate /boot) and XFS for everything else. It's because XFS puts filesystem data there. Yep, I should have been more clear - don't put the bootloader on the first sector of an _XFS_ partition. -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 Nov 4 14:43:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA4MhO132058 for linux-xfs-outgoing; Sun, 4 Nov 2001 14:43:24 -0800 Received: from e4.eyal.emu.id.au (CPE-61-9-148-175.vic.bigpond.net.au [61.9.148.175]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA4MhK032036 for ; Sun, 4 Nov 2001 14:43:20 -0800 Received: from eyal.emu.id.au (eyal.emu.id.au [192.168.2.7]) by e4.eyal.emu.id.au (8.11.6/8.11.2) with ESMTP id fA4Mh4e14762 for ; Mon, 5 Nov 2001 09:43:04 +1100 Received: from eyal.emu.id.au (really [127.0.0.1]) by eyal.emu.id.au via in.smtpd with esmtp id (Debian Smail3.2.0.102) for ; Mon, 5 Nov 2001 09:39:34 +1100 (EST) Message-ID: <3BE5C3A6.E023FB24@eyal.emu.id.au> Date: Mon, 05 Nov 2001 09:39:34 +1100 From: Eyal Lebedinsky Organization: Eyal at Home X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.14-pre8 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs list Subject: Re: TAKE - merge up to 2.4.14-pre8 References: <200111041246.fA4Cknk03793@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk It seems that drivers/char/Makefile refers to i8k.o which is nowhere to be found. The missing files (which are in -pre8): drivers/char/i8k.c include/linux/i8k.h I just copied these over and it builds OK. From owner-linux-xfs@oss.sgi.com Sun Nov 4 15:50:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA4Noeu00796 for linux-xfs-outgoing; Sun, 4 Nov 2001 15:50:40 -0800 Received: from home.smithconcepts.com (65.34.25.157.oviedo-ubr-a.cfl.rr.com [65.34.25.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA4Noa000772 for ; Sun, 4 Nov 2001 15:50:36 -0800 Received: from ieee.org (IDENT:Oawy+YRXNz1sFU3JhARAsEZrfxlmPAF5@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id SAA19273; Sun, 4 Nov 2001 18:43:30 -0500 Message-ID: <3BE5D46B.47D835B6@ieee.org> Date: Sun, 04 Nov 2001 18:51:07 -0500 From: Bryan-TheBS-Smith Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-7SGI_XFS_PR3smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: XFS Installer and GRUB v. LILO ... References: <3BE59A45.40AFF209@ieee.org> <3BE59C0A.4AAB2EC1@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: > It could, if we don't get grub figured out. It's always best to stick with what works, especially since it is included in RedHat. You can always change it later when everything is humming with GRUB. > It's because XFS puts filesystem data there. Because of this, I still make my / (root, including /boot) Ext2. That way I can boot any recovery disk/CD. But I don't put much in / (separate out /tmp, /var, /usr, /home, etc...). > Yep, I should have been more clear - don't put the bootloader > on the first sector of an _XFS_ partition. Not a big deal, just a suggestion. Might want to put the warning in the installer as well. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- * Pentium stop, Pentium SMP go, Athlon MP go ... go very fast! * From owner-linux-xfs@oss.sgi.com Sun Nov 4 19:46:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA53kFY07236 for linux-xfs-outgoing; Sun, 4 Nov 2001 19:46:15 -0800 Received: from queen.bee.lk (queen.bee.lk [203.143.12.182]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA53kA007206 for ; Sun, 4 Nov 2001 19:46:11 -0800 Received: from anuradha by queen.bee.lk with local (Exim 3.12 #1 (Debian)) id 160ai0-0003n3-00; Mon, 05 Nov 2001 09:46:00 +0600 Date: Mon, 5 Nov 2001 09:46:00 +0600 From: Anuradha Ratnaweera To: Eric Sandeen Cc: derek.richardson@pgs.com, linux-xfs@oss.sgi.com Subject: Re: XFS use in production environment Message-ID: <20011105094600.A14482@bee.lk> References: <200111021421.fA2ELTh08913@oss.sgi.com> <3BE2AE5C.1F307A46@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: <3BE2AE5C.1F307A46@sgi.com>; from sandeen@sgi.com on Fri, Nov 02, 2001 at 08:31:56AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Derek Richardson wrote: > > Hello, I'm a new subscribee, was wondering if anyone knows of any statistics > regarding XFS filesystem use in a serious production environment, or has > personal experience ... I have 3 machines running XFS + latest stable linux 2.4 kernel running on serious production environments without problems. Anuradha -- Debian GNU/Linux (kernel 2.4.13) Living your life is a task so difficult, it has never been attempted before. From owner-linux-xfs@oss.sgi.com Sun Nov 4 19:53:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA53rv207474 for linux-xfs-outgoing; Sun, 4 Nov 2001 19:53:57 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA53rr007452 for ; Sun, 4 Nov 2001 19:53:53 -0800 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Sun, 4 Nov 2001 21:53:03 -0600 Message-ID: <85063BBE668FD411944400D0B744267A8886F8@AUSMAIL> From: "Gonyou, Austin" To: linux-xfs@oss.sgi.com Subject: RE: XFS use in production environment Date: Sun, 4 Nov 2001 21:53:03 -0600 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've got got several databases on this running for our pre-production and our development environments. Not to mention we use XFS on our webservers as well. Works well for us so far. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Anuradha Ratnaweera [mailto:anuradha@gnu.org] > Sent: Sunday, November 04, 2001 9:46 PM > To: Eric Sandeen > Cc: derek.richardson@pgs.com; linux-xfs@oss.sgi.com > Subject: Re: XFS use in production environment > > > Derek Richardson wrote: > > > > Hello, I'm a new subscribee, was wondering if anyone knows > of any statistics > > regarding XFS filesystem use in a serious production > environment, or has > > personal experience ... > > I have 3 machines running XFS + latest stable linux 2.4 > kernel running on serious > production environments without problems. > > Anuradha > > -- > > Debian GNU/Linux (kernel 2.4.13) > > Living your life is a task so difficult, it has never been > attempted before. > From owner-linux-xfs@oss.sgi.com Sun Nov 4 23:35:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA57Zm411221 for linux-xfs-outgoing; Sun, 4 Nov 2001 23:35:48 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA57Zh011199 for ; Sun, 4 Nov 2001 23:35:44 -0800 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Nov 2001 01:34:54 -0600 Message-ID: <85063BBE668FD411944400D0B744267A888700@AUSMAIL> From: "Gonyou, Austin" To: "'linux-xfs@oss.sgi.com'" Subject: RE: High disk I/O causes unkillable Processes.(Was Linux + XFS + SCS I = Problems?) Date: Mon, 5 Nov 2001 01:34:53 -0600 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 DMAPI Strikes again. I tested my target system and my Dell 1550 with a kernel that didn't have DMAPI in it. Voila! All tests, both the Java test and my spew.pl scripts have been working like a champ! I just removed the append="noapic" from my lilo.conf and now I'm retesting. I think it will go well there also. Thanks to all the people who've helped me through this. I've got one last question though. Is there a way to pass a parameter to a kernel to turn off dmapi at boot time so I don't have to compile a new kernel until I'm able to deploy it to all of them? Maybe something like append="nodmapi" in lilo.conf? Thanks for your time. You all have been especially great! I LOVE OSS! -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com From owner-linux-xfs@oss.sgi.com Mon Nov 5 01:44:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA59ic913267 for linux-xfs-outgoing; Mon, 5 Nov 2001 01:44:38 -0800 Received: from got02.vikingtelecom.com (gw.viking-telecom.com [212.247.15.77]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA59iT013245 for ; Mon, 5 Nov 2001 01:44:30 -0800 Subject: XFS with LVM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 5 Nov 2001 10:43:29 +0100 Message-ID: From: "Turbo Fredriksson" To: "Linux LVM Mailinglist (E-mail)" Cc: "Linux XFS Mailinglist (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fA59iU013246 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have resently re-mkfs'ed all of my partitions to use XFS. Previously I had an Software RAID (Linear) system which used ext2. But using LVM instead would give me much more freedom to replace disks etc. And XFS so it don't take ages to fsck 60Gb (not much, but takes long enough! :). I tried to use LVM on that, which worked fine. Mkfs'ed it to XFS which also worked fine, to start with. The problem started when to processes tried to write to LVM/XFS disk simultaneous. When I was to change fs on the disk, I borrowed a 62Gb IDE disk to which I moved all the data, configured LVM (default params) and then mkfs.xfs that device. Then all the info was copied back (find | cpio). If I didn't accessed the LVM device, everthing went well, but if I started to copy some (large) files from my homedirectory to the LVM disk, the kernel hung/freezed... Now, I talked to a friend that tried LVM+XFS about a year ago, and he had the same problem then. So, I thought that since I don't have much time to play around with this, the machine must be up and running propperly, I went back to using SW-RAID. Now I get the same problem, but 'earlier', ie I don't even have to 'dual access' the device! Is there any special tricks that have to be done here? How important is the kernel option [ ] Build Adapter Firmware with Kernel Build I currently have NOT enabled this option. As most of us, I read the HOWTO/FAQ/manual only when things go wrong :) I'm currently compiling a kernel with this option, but how important is it really? Is that the source of my problems? The LVM consists of the following devices: Device Size (MB) Type /dev/sdb1 5.88 GB 0x83 /dev/sdc1 1008 MB 0x83 /dev/sdd10 2.37 GB 0x83 /dev/sde1 8.51 GB 0x83 /dev/sdf1 17.09 GB 0x83 /dev/sdg1 15.55 GB 0x83 I have a Adaptec 2940U2W SCSI Card (AIC7xxx driver). The kernel is a 2.4.9, but I can't remember which XFS patch I used, the machine have crashed again (and I have no physical access to it at the moment). Best regards/Med vänlig hälsning Turbo Fredriksson, System developer From owner-linux-xfs@oss.sgi.com Mon Nov 5 01:58:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA59wtQ13636 for linux-xfs-outgoing; Mon, 5 Nov 2001 01:58:55 -0800 Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.247.6.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA59wk013614 for ; Mon, 5 Nov 2001 01:58:46 -0800 Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id fA59wha18120 for ; Mon, 5 Nov 2001 18:58:44 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id fA59wga11130 for ; Mon, 5 Nov 2001 18:58:43 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id fA59wci10744 for ; Mon, 5 Nov 2001 18:58:39 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA266 for ; Mon, 5 Nov 2001 18:58:36 +0900 Received: FROM noshiro.bsd.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Mon Nov 05 18:58:35 2001 +0900 Received: from localhost (localhost [127.0.0.1]) by noshiro.bsd.tnes.nec.co.jp (Postfix) with ESMTP id A90166619 for ; Mon, 5 Nov 2001 18:58:36 +0900 (JST) To: linux-xfs@oss.sgi.com Subject: POSIX error code X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Artificial Intelligence) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011105185836G.masano@tnes.nec.co.jp> Date: Mon, 05 Nov 2001 18:58:36 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 70 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, When a file name is longer than 255 bytes, XFS returns with EINVAL. Why EINVAL? I guess it should be ENAMETOOLONG. Here is a patch. Index: linux/fs/xfs/xfs_vnodeops.c =================================================================== RCS file: /usr/localmnt/xfs/cvsroot/linux-2.4-xfs/linux/fs/xfs/xfs_vnodeops.c,v retrieving revision 1.512 diff -u -r1.512 xfs_vnodeops.c --- linux/fs/xfs/xfs_vnodeops.c 2001/09/18 20:56:42 1.512 +++ linux/fs/xfs/xfs_vnodeops.c 2001/11/05 07:11:31 @@ -2168,7 +2168,7 @@ dm_di_mode = vap->va_mode|VTTOIF(vap->va_type); namelen = strlen(name); if (namelen >= MAXNAMELEN) - return XFS_ERROR(EINVAL); + return XFS_ERROR(ENAMETOOLONG); if (DM_EVENT_ENABLED(dir_vp->v_vfsp, dp, DM_EVENT_CREATE)) { error = xfs_dm_send_create_event(dir_bdp, name, @@ -3063,7 +3063,7 @@ namelen = strlen(name); if (namelen >= MAXNAMELEN) - return XFS_ERROR(EINVAL); + return XFS_ERROR(ENAMETOOLONG); if (DM_EVENT_ENABLED(dir_vp->v_vfsp, dp, DM_EVENT_REMOVE)) { error = dm_send_namesp_event(DM_EVENT_REMOVE, dir_bdp, DM_RIGHT_NULL, NULL, DM_RIGHT_NULL, @@ -3363,7 +3363,7 @@ target_namelen = strlen(target_name); if (target_namelen >= MAXNAMELEN) - return XFS_ERROR(EINVAL); + return XFS_ERROR(ENAMETOOLONG); /* * Get the real vnode. */ @@ -3601,7 +3601,7 @@ dir_namelen = strlen(dir_name); if (dir_namelen >= MAXNAMELEN) - return XFS_ERROR(EINVAL); + return XFS_ERROR(ENAMETOOLONG); tp = NULL; dp_joined_to_trans = B_FALSE; @@ -3866,7 +3866,7 @@ return XFS_ERROR(EIO); namelen = strlen(name); if (namelen >= MAXNAMELEN) - return XFS_ERROR(EINVAL); + return XFS_ERROR(ENAMETOOLONG); if (DM_EVENT_ENABLED(dir_vp->v_vfsp, dp, DM_EVENT_REMOVE)) { error = dm_send_namesp_event(DM_EVENT_REMOVE, @@ -4221,7 +4221,7 @@ link_namelen = strlen(link_name); if (link_namelen >= MAXNAMELEN) - return XFS_ERROR(EINVAL); + return XFS_ERROR(ENAMETOOLONG); /* * Check component lengths of the target path name. */ -- masano From owner-linux-xfs@oss.sgi.com Mon Nov 5 03:53:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5Brso21694 for linux-xfs-outgoing; Mon, 5 Nov 2001 03:53:54 -0800 Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.247.6.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5Brm021668 for ; Mon, 5 Nov 2001 03:53:48 -0800 Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id fA5BrkO06660 for ; Mon, 5 Nov 2001 20:53:46 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id fA5BrjU22117 for ; Mon, 5 Nov 2001 20:53:45 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id fA5Brji18588 for ; Mon, 5 Nov 2001 20:53:45 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA444 for ; Mon, 5 Nov 2001 20:53:44 +0900 Received: FROM noshiro.bsd.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Mon Nov 05 20:53:43 2001 +0900 Received: from localhost (localhost [127.0.0.1]) by noshiro.bsd.tnes.nec.co.jp (Postfix) with ESMTP id 9556F6619 for ; Mon, 5 Nov 2001 20:53:42 +0900 (JST) To: linux-xfs@oss.sgi.com Subject: Re: execute lvchange while mounting XFS filesystem In-Reply-To: <20011001225331N.masano@tnes.nec.co.jp> References: <20011001225331N.masano@tnes.nec.co.jp> X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Artificial Intelligence) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011105205342A.masano@tnes.nec.co.jp> Date: Mon, 05 Nov 2001 20:53:42 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 39 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk From: me Date: Mon, 01 Oct 2001 22:53:31 +0900 (JST) Message-ID: <20011001225331N.masano@tnes.nec.co.jp> > Hi, > > I encountered an oops and you can reproduce it with the following > operations: > > # lvcreate -L 32m -n masano1 /dev/vg0 > # mkfs.xfs /dev/vg0/masano1 > # mount /dev/vg0/masano1 /mnt/masano1 > # lvchange -p r /dev/vg0/masano1 > # touch /mnt/masano1/dummy > # sync > > I think that these operations may have no special meaning, however, > it seems that there is an issue in the error handling of writing > log operation. > > I looked into XFS kernel sources but I could not find what led to this > oops. I found that this oops occurred because of a linkage of buffer_head lru/free list was broken. The I/O completion routine for pagebuf I/O such as _end_pagebuf_page_io() free the buffer_head with kmem_cache_free(). But when I/O error is detected in LVM by above operations, the buffer_head is listed into lru/free list by buffer_IO_error(). The lru/free list is broken when the freed buffer_head is reallocated and reused. Which is rough in manner, calling kmem_cache_free() or calling buffer_IO_error()? > Thanks in advance, -- masano From owner-linux-xfs@oss.sgi.com Mon Nov 5 05:17:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5DHIl28409 for linux-xfs-outgoing; Mon, 5 Nov 2001 05:17:18 -0800 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 fA5DFt028381 for ; Mon, 5 Nov 2001 05:17:14 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=indonesia) by indonesia.kscanners.no with esmtp (Exim 3.33 #1) id 160jbB-0000mt-00 for linux-xfs@oss.sgi.com; Mon, 05 Nov 2001 14:15:33 +0100 Date: Mon, 5 Nov 2001 14:15:31 +0100 From: Toralf Lund To: linux-xfs@oss.sgi.com Subject: "Red Hat 7.2" RPMs? Message-ID: <20011105141531.C2890@indonesia.kscanners.no> References: <20011105141528.B2890@indonesia.kscanners.no> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <20011105141528.B2890@indonesia.kscanners.no>; from toralf@kscanners.com on Mon, Nov 05, 2001 at 14:15:28 +0100 X-Mailer: Balsa 1.2.2 Lines: 4 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Any chance for a distribution based on kernel-2.4.7 from Red Hat 7.2 and/or kernel-2.4.9 from Red Hat Updates any time soon? -- - Toralf From owner-linux-xfs@oss.sgi.com Mon Nov 5 05:36:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5Dalp00512 for linux-xfs-outgoing; Mon, 5 Nov 2001 05:36:47 -0800 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 fA5Dac000486 for ; Mon, 5 Nov 2001 05:36:39 -0800 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.11.6/8.11.6) id fA5DZ9k01434; Mon, 5 Nov 2001 14:35:09 +0100 Date: Mon, 5 Nov 2001 14:35:09 +0100 From: Krzysztof Rusocki To: linux-kernel@vger.kernel.org Cc: linux-xfs@oss.sgi.com Subject: 2.4.14-pre7 KERNEL: assertion (sk->pprev==NULL) failed at tcp_ipv4.c(345):__tcp_v4_hash Message-ID: <20011105143508.A1327@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, After about 40 hours 2.4.14-pre7-xfs (Nov 3 chekout) locked up (I think - no SysRQ response) leaving in klogs what's below: Nov 5 12:00:20 main kernel: KERNEL: assertion (sk->pprev==NULL) failed at tcp_ipv4.c(345):__tcp_v4_hash I believe, that it's related to -pre6 David Miller's net updates. Now I downgraded to 2.4.10-xfs, which I had been running more successfully then 2.4.14-pre7 but not flawlessly... http://marc.theaimsgroup.com/?l=linux-xfs&m=100473129726291&w=2 Any hints ? Cheers, Krzysztof PS. linux-kernel subscribers please CC for obvious reasons :> From owner-linux-xfs@oss.sgi.com Mon Nov 5 05:42:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5Dg0o00810 for linux-xfs-outgoing; Mon, 5 Nov 2001 05:42:00 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5Dfv000788 for ; Mon, 5 Nov 2001 05:41:57 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id fA5Dfege083510; Mon, 5 Nov 2001 14:41:41 +0100 (CET) Message-Id: <4.3.2.7.2.20011105143910.02ca5198@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Nov 2001 14:39:43 +0100 To: Toralf Lund , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: "Red Hat 7.2" RPMs? In-Reply-To: <20011105141531.C2890@indonesia.kscanners.no> References: <20011105141528.B2890@indonesia.kscanners.no> <20011105141528.B2890@indonesia.kscanners.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 14:15 5-11-2001 +0100, Toralf Lund wrote: >Any chance for a distribution based on kernel-2.4.7 from Red Hat 7.2 >and/or kernel-2.4.9 from Red Hat Updates any time soon? They are in the testing directory on the oss.sgi.com/projects/xfs 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 Mon Nov 5 05:44:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5Dibu00961 for linux-xfs-outgoing; Mon, 5 Nov 2001 05:44:37 -0800 Received: from linux.nameip.net ([211.187.6.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5DiZ000939 for ; Mon, 5 Nov 2001 05:44:35 -0800 Received: (qmail 1248 invoked from network); 5 Nov 2001 13:48:32 -0000 Received: from unknown (HELO orgio.net) (211.187.6.46) by 0 with SMTP; 5 Nov 2001 13:48:32 -0000 Message-ID: <3BE698B0.9040606@orgio.net> Date: Mon, 05 Nov 2001 22:48:32 +0900 From: Seung-young Oh User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011013 X-Accept-Language: ko MIME-Version: 1.0 To: Toralf Lund CC: linux-xfs@oss.sgi.com Subject: Re: "Red Hat 7.2" RPMs? References: <20011105141528.B2890@indonesia.kscanners.no> <20011105141531.C2890@indonesia.kscanners.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Toralf Lund wrote: > Any chance for a distribution based on kernel-2.4.7 from Red Hat 7.2 > and/or kernel-2.4.9 from Red Hat Updates any time soon? Hello, according to the FAQ, the installer you're talking about will be out very soon... -- ICQ#: 103231199 From owner-linux-xfs@oss.sgi.com Mon Nov 5 05:46:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5Dkf801118 for linux-xfs-outgoing; Mon, 5 Nov 2001 05:46:41 -0800 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5Dkc001096 for ; Mon, 5 Nov 2001 05:46:38 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id fA5Dkak6066271 for ; Mon, 5 Nov 2001 14:46:36 +0100 (CET) Message-Id: <4.3.2.7.2.20011105143949.02ca2840@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Nov 2001 14:44:44 +0100 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: RH 7.2 Installer - Lilo mishap Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, If you have a space in of of your boot images' labels lilo will fail. I rebooted from the cd in rescue mode and put " around the label which made it work. If you don't put the " around the label in this case lilo complained the the sector was higher then 1024 even with the lba32 option. I don't know if anyone changed the behaviour for this part of the installer. Adding qoutes around the boot label will always work, with our without spaces. The installer never complained about it although producing a warning if lilo fails in unexpected ways would be nice. 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 Nov 5 05:49:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5DnxB01332 for linux-xfs-outgoing; Mon, 5 Nov 2001 05:49:59 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5Dnv001310 for ; Mon, 5 Nov 2001 05:49:57 -0800 Received: from localhost (IDENT:davem@pizda.ninka.net [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id FAA15235; Mon, 5 Nov 2001 05:49:18 -0800 Date: Mon, 05 Nov 2001 05:49:17 -0800 (PST) Message-Id: <20011105.054917.21928205.davem@redhat.com> To: kszysiu@main.braxis.co.uk Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.14-pre7 KERNEL: assertion (sk->pprev==NULL) failed at tcp_ipv4.c(345):__tcp_v4_hash From: "David S. Miller" In-Reply-To: <20011105143508.A1327@main.braxis.co.uk> References: <20011105143508.A1327@main.braxis.co.uk> X-Mailer: Mew version 2.0 on Emacs 21.0 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk From: Krzysztof Rusocki Date: Mon, 5 Nov 2001 14:35:09 +0100 I believe, that it's related to -pre6 David Miller's net updates. It's Andi Kleen's connect port allocation changes. If he can't figure out a fix we'll just revert that stuff. Franks a lot, David S. Miller davem@redhat.com From owner-linux-xfs@oss.sgi.com Mon Nov 5 06:42:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5Egnb04068 for linux-xfs-outgoing; Mon, 5 Nov 2001 06:42:49 -0800 Received: from mustard.heime.net (mustard.heime.net [194.234.65.222]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5Egk004045 for ; Mon, 5 Nov 2001 06:42:46 -0800 Received: from localhost (roy@localhost) by mustard.heime.net (8.11.2/8.9.3) with ESMTP id fA5Egeh19389 for ; Mon, 5 Nov 2001 15:42:40 +0100 Date: Mon, 5 Nov 2001 15:42:39 +0100 (CET) From: Roy Sigurd Karlsbakk X-Sender: To: XFS Mailing list Subject: Downloading a specific version from cvs? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi I need the patch (or the whole tree) for version 2.4.13. Is it possible to download that from cvs without downloading the files separately? --- Computers are like air conditioners. They stop working when you open Windows. From owner-linux-xfs@oss.sgi.com Mon Nov 5 06:54:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5EsEu04353 for linux-xfs-outgoing; Mon, 5 Nov 2001 06:54:14 -0800 Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5Es9004330 for ; Mon, 5 Nov 2001 06:54:10 -0800 Received: (qmail 11461 invoked by uid 1000); 5 Nov 2001 14:55:17 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Nov 2001 14:55:17 -0000 Date: Mon, 5 Nov 2001 16:55:17 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Tux mailing list cc: XFS Mailing list Subject: Re: Tux server with 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 Mon, 5 Nov 2001, Roy Sigurd Karlsbakk wrote: > hi > > Are there any known problems when using Tux from an XFS file system? > Hi first of all how did you patched them two? did you used the XFS CVS version and manually patched the latest TUX release? ---------------------------- Mihai RUSU "... and what if this is as good as it gets ?" From owner-linux-xfs@oss.sgi.com Mon Nov 5 06:54:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5EsPi04475 for linux-xfs-outgoing; Mon, 5 Nov 2001 06:54:25 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5EsL004423 for ; Mon, 5 Nov 2001 06:54:21 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id fA5EsDCA012061; Mon, 5 Nov 2001 15:54:13 +0100 (CET) Message-Id: <4.3.2.7.2.20011105155200.02c53d28@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Nov 2001 15:52:21 +0100 To: Roy Sigurd Karlsbakk , XFS Mailing list From: Seth Mos Subject: Re: Downloading a specific version from cvs? 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:42 5-11-2001 +0100, Roy Sigurd Karlsbakk wrote: >hi > >I need the patch (or the whole tree) for version 2.4.13. Is it possible to >download that from cvs without downloading the files separately? The 2.4.13 patches are on the FTP site. 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 Nov 5 07:19:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5FJHJ05036 for linux-xfs-outgoing; Mon, 5 Nov 2001 07:19:17 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5FJD005014 for ; Mon, 5 Nov 2001 07:19:13 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fA5FJ8T04260 for ; Mon, 5 Nov 2001 07:19:08 -0800 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA56973; Mon, 5 Nov 2001 07:18:36 -0800 (PST) Message-ID: <3BE6ACBC.CAF15308@sgi.com> Date: Mon, 05 Nov 2001 09:14:04 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: linux-xfs@oss.sgi.com Subject: Re: RH 7.2 Installer - Lilo mishap References: <4.3.2.7.2.20011105143949.02ca2840@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Seth - Labels aren't even supported in the installer for XFS filesystems* - so this sounds like a generic anaconda bug to me... can you check it out on standard RH7.2? If you find it there, you might file it in bugzilla. -Eric *Labels work on XFS filesystems, just no installer support yet. Seth Mos wrote: > If you have a space in of of your boot images' labels lilo will fail. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Nov 5 07:20:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5FKJb05168 for linux-xfs-outgoing; Mon, 5 Nov 2001 07:20:19 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5FKH005146 for ; Mon, 5 Nov 2001 07:20:17 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fA5FKCT04328 for ; Mon, 5 Nov 2001 07:20:12 -0800 Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA74526; Mon, 5 Nov 2001 07:19:41 -0800 (PST) Message-ID: <3BE6ACFC.40942224@sgi.com> Date: Mon, 05 Nov 2001 09:15:08 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: linux-xfs@oss.sgi.com Subject: Re: RH 7.2 Installer - Lilo mishap References: <4.3.2.7.2.20011105143949.02ca2840@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Argh, too early in the morning. You're talking about lilo labels... still, same issue - I don't _think_ anything was changed for XFS in this area. -Eric Seth Mos wrote: > > Hi, > > If you have a space in of of your boot images' labels lilo will fail. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Nov 5 07:26:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5FQ5I05342 for linux-xfs-outgoing; Mon, 5 Nov 2001 07:26:05 -0800 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 fA5FQ2005320 for ; Mon, 5 Nov 2001 07:26:02 -0800 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 HAA05965 for ; Mon, 5 Nov 2001 07:25:54 -0800 (PST) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA98099; Mon, 5 Nov 2001 07:25:29 -0800 (PST) Message-ID: <3BE6AE58.E7662D3D@sgi.com> Date: Mon, 05 Nov 2001 09:20:56 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: Roy Sigurd Karlsbakk , XFS Mailing list Subject: Re: Downloading a specific version from cvs? References: <4.3.2.7.2.20011105155200.02c53d28@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk And if you do need some particular version that doesn't exist as a patch on the ftp, you can use the CVS -D command to check out the repository as of a certain date. It's a little roundabout, but you can look at the mailing list to see when a version changed, and specify that date... -Eric Seth Mos wrote: > > At 15:42 5-11-2001 +0100, Roy Sigurd Karlsbakk wrote: > >hi > > > >I need the patch (or the whole tree) for version 2.4.13. Is it possible to > >download that from cvs without downloading the files separately? > > The 2.4.13 patches are on the FTP site. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Nov 5 07:35:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5FZVj05598 for linux-xfs-outgoing; Mon, 5 Nov 2001 07:35:31 -0800 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5FZS005576 for ; Mon, 5 Nov 2001 07:35:28 -0800 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id D851C1AB2A; Mon, 5 Nov 2001 10:35:22 -0500 (EST) Received: by ranma.dkp.com (Postfix, from userid 168) id 09EB75A52F; Mon, 5 Nov 2001 10:35:21 -0500 (EST) Date: Mon, 5 Nov 2001 10:35:21 -0500 From: Andrew Klaassen To: linux-xfs@oss.sgi.com, linux-raid@vger.kernel.org Subject: Oops - XFS mount after replacing wrong RAID5 drive Message-ID: <20011105103521.A3864@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com, linux-raid@vger.kernel.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I think I may have just replaced the wrong drive after a SW RAID5 drive failure. And then I mounted the XFS filesystem read-write. (Doh!) Can I put the old probably-good drive back into the array and replace the actually-bad drive? Would XFS's log replay have written enough to the array to get the RAID5 hopelessly out of sync with the old probably-good drive? (The XFS filesystem did not unmount cleanly after the first drive failure. That's why I'm assuming that it replayed its log when I mounted it after replacing the drive.) How do I mount the filesystem without writing anything at all to the array? Thanks. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Mon Nov 5 07:37:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5Fb4R05729 for linux-xfs-outgoing; Mon, 5 Nov 2001 07:37:04 -0800 Received: from mailboy.pgs.com (mailboy.hstn.tensor.pgs.com [157.147.25.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5Faw005707 for ; Mon, 5 Nov 2001 07:36:59 -0800 Received: from hap.hstn.tensor.pgs.com ([157.147.136.17]) by mailboy.pgs.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22678; Mon, 5 Nov 2001 09:36:46 -0600 (CST) Received: from idoru.hstn.tensor.pgs.com (idoru.hstn.tensor.pgs.com [157.147.92.80]) by hap.hstn.tensor.pgs.com (8.9.3/8.9.3) with ESMTP id JAA08141; Mon, 5 Nov 2001 09:36:46 -0600 (CST) Subject: Re: XFS use in production environment From: Derek Richardson To: Martin Spott Cc: linux-xfs@oss.sgi.com In-Reply-To: <200111031140.MAA07221@foehn.quickstep.oche.de> References: <200111031140.MAA07221@foehn.quickstep.oche.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 05 Nov 2001 09:36:42 -0600 Message-Id: <1004974603.1895.159.camel@idoru.hstn.tensor.pgs.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Martin, Thanks for the info, I appreciate it. I wasn't really all that worried about using XFS, I've done a bit of stability testing myself, proved fine. But we're going to stick w/ one of the RedHat distro kernels, patched for XFS (probably 2.4.9 at this point), because I want to stick away from the new VM (I agree that it's probably an improvement, but I've had 2.4.9 and 2.4.12 kernels blow up on me - locked the box completely - and I'm not willing to bet my job on it) and because this more or less keeps w/ the standard around here. Thanks for the testimonial and advice! Regards, Derek R. On Sat, 2001-11-03 at 05:40, Martin Spott wrote: > Derek Richardson wrote: > > > Hello, I'm a new subscribee, was wondering if anyone knows of any > > statistics regarding XFS filesystem use in a serious production > > environment, or has personal experience (I take it there's quite a bit > > here...). > > Sorry, I don't know of any statistics. But I might approve that i'm running > 2.4.4-XFS on a customers 'PPS' ("Production Planning System", as we call it > in Germany). This means the customer _really_ depends on a working machine, > otherwise they would be in " real trouble' (TM) after short time. > > The machine is running since July with only one reboot (to switch power > supplies), havingpretty used > 40 GByte filesystems on external FibreChannel > array. They're running a OO database in filesystem, so you can imagine that > it's I/O dependent. > > I believe you don't want to use such an old kernel. You'd better want to try > a recent one (2.4.13) because of all the fixes that went in. I'm pretty > happy with 2.4.13-XFS on the fileserver at work. The only reason I didn't > upgrade the kernel on our customer's machine is not to touch the uptime ;-) > > Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends are ! > -------------------------------------------------------------------------- > -- Junior Linux Geek 713-817-1197 (cell) 713-781-4000 x2267 (office) "Linux users, fanatical. No way... HEY! Get that MCSE up on the altar, Tux must be appeased!" From owner-linux-xfs@oss.sgi.com Mon Nov 5 07:43:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5FhER05923 for linux-xfs-outgoing; Mon, 5 Nov 2001 07:43:14 -0800 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 fA5Fh9005898 for ; Mon, 5 Nov 2001 07:43:09 -0800 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 HAA06973 for ; Mon, 5 Nov 2001 07:43:00 -0800 (PST) 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 JAA3498425; Mon, 5 Nov 2001 09:41:52 -0600 (CST) Received: from jen.americas.sgi.com (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 JAA18705; Mon, 5 Nov 2001 09:41:52 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA5FbGC10365; Mon, 5 Nov 2001 09:37:16 -0600 Subject: Re: Oops - XFS mount after replacing wrong RAID5 drive From: Steve Lord To: Andrew Klaassen Cc: linux-xfs@oss.sgi.com, linux-raid@vger.kernel.org In-Reply-To: <20011105103521.A3864@dkp.com> References: <20011105103521.A3864@dkp.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.100+cvs.2001.11.02.21.57 (Preview Release) Date: 05 Nov 2001 09:37:16 -0600 Message-Id: <1004974636.7318.5.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2001-11-05 at 09:35, Andrew Klaassen wrote: > I think I may have just replaced the wrong drive after a SW > RAID5 drive failure. > > And then I mounted the XFS filesystem read-write. (Doh!) > > Can I put the old probably-good drive back into the array and > replace the actually-bad drive? > > Would XFS's log replay have written enough to the array to get > the RAID5 hopelessly out of sync with the old probably-good > drive? > > (The XFS filesystem did not unmount cleanly after the first > drive failure. That's why I'm assuming that it replayed its log > when I mounted it after replacing the drive.) It will have replayed its log - and that information is now gone, so it is a little hard to say what state the filesystem is really in now. > > How do I mount the filesystem without writing anything at all to > the array? > mount -o ro,norecovery Even a readonly mount without the norecovery will attempt to run recovery. > Thanks. > > Andrew Klaassen Best of luck! Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Nov 5 07:47:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5FlRp06156 for linux-xfs-outgoing; Mon, 5 Nov 2001 07:47:27 -0800 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 fA5FlM006133 for ; Mon, 5 Nov 2001 07:47:22 -0800 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 HAA07445 for ; Mon, 5 Nov 2001 07:47:13 -0800 (PST) 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 JAA3502436; Mon, 5 Nov 2001 09:46:05 -0600 (CST) Received: from jen.americas.sgi.com (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 JAA53021; Mon, 5 Nov 2001 09:46:05 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA5FfSj10399; Mon, 5 Nov 2001 09:41:28 -0600 Subject: RE: High disk I/O causes unkillable Processes.(Was Linux + XFS + SCS I = Problems?) From: Steve Lord To: "Gonyou, Austin" Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: <85063BBE668FD411944400D0B744267A888700@AUSMAIL> References: <85063BBE668FD411944400D0B744267A888700@AUSMAIL> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.100+cvs.2001.11.02.21.57 (Preview Release) Date: 05 Nov 2001 09:41:28 -0600 Message-Id: <1004974888.7298.9.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2001-11-05 at 01:34, Gonyou, Austin wrote: > DMAPI Strikes again. > > I tested my target system and my Dell 1550 with a kernel that didn't have > DMAPI in it. Voila! > All tests, both the Java test and my spew.pl scripts have been working like > a champ! > I just removed the append="noapic" from my lilo.conf and now I'm retesting. > I think it will go > well there also. Thanks to all the people who've helped me through this. > > I've got one last question though. Is there a way to pass a parameter to a > kernel to turn off > dmapi at boot time so I don't have to compile a new kernel until I'm able to > deploy it to all of them? > Maybe something like append="nodmapi" in lilo.conf? Thanks for your time. > You all have been especially > great! I LOVE OSS! > > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-796-9023 > email: austin@coremetrics.com Thanks for your persistance on looking at this one Austin, oddly enough we had a dmapi enabled kernel go into a cpu loop last week - in the write path, but I did not associate the problem with your configuration. As a rule I would keep dmapi off, it is really no use to anyone who does not have a dmapi application to run on the filesystem. All it buys you in any other case is more code getting exected. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Nov 5 07:53:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5FrbS06356 for linux-xfs-outgoing; Mon, 5 Nov 2001 07:53:37 -0800 Received: from mustard.heime.net (mustard.heime.net [194.234.65.222]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5FrY006333 for ; Mon, 5 Nov 2001 07:53:34 -0800 Received: from localhost (roy@localhost) by mustard.heime.net (8.11.2/8.9.3) with ESMTP id fA5FrSp19727; Mon, 5 Nov 2001 16:53:28 +0100 Date: Mon, 5 Nov 2001 16:53:28 +0100 (CET) From: Roy Sigurd Karlsbakk X-Sender: To: XFS Mailing list , Tux mailing list Subject: XFS+Tux = patch trouble Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Does anyone know how to merge the XFS and Tux patches? thanks --- Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA Computers are like air conditioners. They stop working when you open Windows. From owner-linux-xfs@oss.sgi.com Mon Nov 5 07:57:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5Fvjk06547 for linux-xfs-outgoing; Mon, 5 Nov 2001 07:57:45 -0800 Received: from mustard.heime.net (mustard.heime.net [194.234.65.222]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5Fvg006524 for ; Mon, 5 Nov 2001 07:57:42 -0800 Received: from localhost (roy@localhost) by mustard.heime.net (8.11.2/8.9.3) with ESMTP id fA5FvTR19751; Mon, 5 Nov 2001 16:57:29 +0100 Date: Mon, 5 Nov 2001 16:57:29 +0100 (CET) From: Roy Sigurd Karlsbakk X-Sender: To: Mihai RUSU cc: XFS Mailing list Subject: Re: Tux server with 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 > Hi > > first of all how did you patched them two? I didn't. I tried to 'patch -p1 < patch' twice. It didn't work... I don't want to use ext2, so if I can't, then I'll use reiserfs, or ext3 --- Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA Computers are like air conditioners. They stop working when you open Windows. From owner-linux-xfs@oss.sgi.com Mon Nov 5 08:07:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5G7Mu06833 for linux-xfs-outgoing; Mon, 5 Nov 2001 08:07:22 -0800 Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5G7J006808 for ; Mon, 5 Nov 2001 08:07:19 -0800 Received: (qmail 16797 invoked by uid 1000); 5 Nov 2001 16:08:41 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Nov 2001 16:08:41 -0000 Date: Mon, 5 Nov 2001 18:08:41 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Roy Sigurd Karlsbakk cc: XFS Mailing list Subject: Re: Tux server with 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 Mon, 5 Nov 2001, Roy Sigurd Karlsbakk wrote: > > Hi > > > > first of all how did you patched them two? > > I didn't. I tried to 'patch -p1 < patch' twice. It didn't work... > I don't want to use ext2, so if I can't, then I'll use reiserfs, or ext3 > oh i see :( i HAVE to use XFS (reiserfs already made me loose some data), so ill try to patch them by hand whenever i have time this week ---------------------------- Mihai RUSU "... and what if this is as good as it gets ?" From owner-linux-xfs@oss.sgi.com Mon Nov 5 08:11:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5GBUt07011 for linux-xfs-outgoing; Mon, 5 Nov 2001 08:11:30 -0800 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 fA5GBQ006989 for ; Mon, 5 Nov 2001 08:11:26 -0800 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 IAA02900 for ; Mon, 5 Nov 2001 08:10:56 -0800 (PST) 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 KAA3292800; Mon, 5 Nov 2001 10:10:09 -0600 (CST) Received: from jen.americas.sgi.com (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 KAA45320; Mon, 5 Nov 2001 10:10:09 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA5G5XA11056; Mon, 5 Nov 2001 10:05:33 -0600 Subject: Re: Tux server with XFS? From: Steve Lord To: Mihai RUSU Cc: Roy Sigurd Karlsbakk , XFS Mailing list In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.100+cvs.2001.11.02.21.57 (Preview Release) Date: 05 Nov 2001 10:05:33 -0600 Message-Id: <1004976333.10860.0.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2001-11-05 at 10:08, Mihai RUSU wrote: > On Mon, 5 Nov 2001, Roy Sigurd Karlsbakk wrote: > > > > Hi > > > > > > first of all how did you patched them two? > > > > I didn't. I tried to 'patch -p1 < patch' twice. It didn't work... > > I don't want to use ext2, so if I can't, then I'll use reiserfs, or ext3 > > > oh i see :( > i HAVE to use XFS (reiserfs already made me loose some data), so ill try > to patch them by hand whenever i have time this week > > ---------------------------- > Mihai RUSU > "... and what if this is as good as it gets ?" Take a look at the 7.2 kernel rpms on the oss.sgi.com ftp site - they are in projects/xfs/download/testing. I think these should have tux turned on. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Nov 5 08:22:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5GMwT07321 for linux-xfs-outgoing; Mon, 5 Nov 2001 08:22:58 -0800 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5GMp007299 for ; Mon, 5 Nov 2001 08:22:51 -0800 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id B93671AB2A; Mon, 5 Nov 2001 11:22:50 -0500 (EST) Received: by ranma.dkp.com (Postfix, from userid 168) id 9B3DE5A52F; Mon, 5 Nov 2001 11:22:50 -0500 (EST) Date: Mon, 5 Nov 2001 11:22:50 -0500 From: Andrew Klaassen To: linux-xfs@oss.sgi.com, linux-raid@vger.kernel.org Subject: Re: Oops - XFS mount after replacing wrong RAID5 drive Message-ID: <20011105112231.B3864@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com, linux-raid@vger.kernel.org References: <20011105103521.A3864@dkp.com> <1004974636.7318.5.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1004974636.7318.5.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Nov 05, 2001 at 09:37:16AM -0600, Steve Lord wrote: > On Mon, 2001-11-05 at 09:35, > Andrew Klaassen wrote: > > I think I may have just replaced the wrong drive after a SW > > RAID5 drive failure. > > > > And then I mounted the XFS filesystem read-write. (Doh!) > > > > Can I put the old probably-good drive back into the array > > and replace the actually-bad drive? > > > > Would XFS's log replay have written enough to the array to > > get the RAID5 hopelessly out of sync with the old > > probably-good drive? > > > > (The XFS filesystem did not unmount cleanly after the first > > drive failure. That's why I'm assuming that it replayed its > > log when I mounted it after replacing the drive.) > It will have replayed its log - and that information is now > gone, so it is a little hard to say what state the filesystem > is really in now. So... mount it ro,norecovery, then run xfs_repair -n? Or just mount it ro,norecovery and try to grab the info we absolutely need? How much is it likely to have written while replaying the log? (There's a reasonably good chance that it sync'd before the box went down the first time.) For the RAID5 people: How much has to be written to the array before the old probably-good drive will be useless? What will happen if I put it back in and it's too far out of sync? > > How do I mount the filesystem without writing anything at > > all to the array? > mount -o ro,norecovery > > Even a readonly mount without the norecovery will attempt to run > recovery. So there's no way at all to mount the filesystem without some writing occuring? > Best of luck! We've been knocking on wood this whole project, and it doesn't seem to have done us any good. :) Andrew Klaassen From owner-linux-xfs@oss.sgi.com Mon Nov 5 08:29:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5GTAj07539 for linux-xfs-outgoing; Mon, 5 Nov 2001 08:29:10 -0800 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 fA5GT7007517 for ; Mon, 5 Nov 2001 08:29:08 -0800 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 RAA1511675 for ; Mon, 5 Nov 2001 17:28:07 +0100 (CET) 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 KAA3501992 for ; Mon, 5 Nov 2001 10:27:49 -0600 (CST) Received: from jen.americas.sgi.com (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 KAA47655 for ; Mon, 5 Nov 2001 10:27:49 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA5GNCA11158; Mon, 5 Nov 2001 10:23:12 -0600 Message-Id: <200111051623.fA5GNCA11158@jen.americas.sgi.com> Date: Mon, 5 Nov 2001 10:23:12 -0600 Subject: TAKE - 2 new files missed in the 2.4.14-pre8 merge Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Nov 5 08:26:13 PST 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:106073a linux/drivers/char/i8k.c - 1.1 linux/include/linux/i8k.h - 1.1 - New file from 2.4.14-pre8 From owner-linux-xfs@oss.sgi.com Mon Nov 5 08:31:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5GV6i07680 for linux-xfs-outgoing; Mon, 5 Nov 2001 08:31:06 -0800 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 fA5GV1007658 for ; Mon, 5 Nov 2001 08:31:01 -0800 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 RAA1577911 for ; Mon, 5 Nov 2001 17:30:01 +0100 (CET) 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 KAA3292208; Mon, 5 Nov 2001 10:29:42 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA58574; Mon, 5 Nov 2001 10:29:41 -0600 (CST) Subject: Re: XFS+Tux = patch trouble From: Eric Sandeen To: Roy Sigurd Karlsbakk Cc: XFS Mailing list , Tux mailing list In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 05 Nov 2001 10:29:20 -0600 Message-Id: <1004977760.1592.5.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Roy - As Steve said on another thread, look at the 2.4.9 RPMS in the testing/ directory on the xfs ftp site. They have both XFS and Tux in them (and a ton of other things, as well...) The issues I ran into on the merge had to do with fine-grained pagecache locking, i.e. lots of things like: - spin_lock(&pagecache_lock); + spin_lock(__PAGECACHE_LOCK(mapping, index)); We use a couple of these spin_locks new functions in mm/filemap.c, so they'll need to be converted as well - the tux patch won't catch these. -Eric On Mon, 2001-11-05 at 09:53, Roy Sigurd Karlsbakk wrote: > hi > > Does anyone know how to merge the XFS and Tux patches? > > thanks > > --- > Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA > > Computers are like air conditioners. > They stop working when you open Windows. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Nov 5 08:40:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5GeMU07923 for linux-xfs-outgoing; Mon, 5 Nov 2001 08:40:22 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5GeD007900 for ; Mon, 5 Nov 2001 08:40:13 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fA5Ge8T10660 for ; Mon, 5 Nov 2001 08:40:08 -0800 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 KAA3490916; Mon, 5 Nov 2001 10:38:51 -0600 (CST) Received: from jen.americas.sgi.com (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 KAA98652; Mon, 5 Nov 2001 10:38:51 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA5GYFh11218; Mon, 5 Nov 2001 10:34:15 -0600 Subject: Re: POSIX error code From: Steve Lord To: ASANO Masahiro Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011105185836G.masano@tnes.nec.co.jp> References: <20011105185836G.masano@tnes.nec.co.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.100+cvs.2001.11.02.21.57 (Preview Release) Date: 05 Nov 2001 10:34:14 -0600 Message-Id: <1004978054.10877.8.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yes, this does appear wrong, the Irix man pages say ENAMETOOLONG as well, but the code says EINVAL, your code should show up in the tree before too long. Thanks Steve On Mon, 2001-11-05 at 03:58, ASANO Masahiro wrote: > Hi, > > When a file name is longer than 255 bytes, XFS returns with EINVAL. > Why EINVAL? I guess it should be ENAMETOOLONG. > > Here is a patch. > > Index: linux/fs/xfs/xfs_vnodeops.c > =================================================================== > RCS file: /usr/localmnt/xfs/cvsroot/linux-2.4-xfs/linux/fs/xfs/xfs_vnodeops.c,v > retrieving revision 1.512 > diff -u -r1.512 xfs_vnodeops.c > --- linux/fs/xfs/xfs_vnodeops.c 2001/09/18 20:56:42 1.512 > +++ linux/fs/xfs/xfs_vnodeops.c 2001/11/05 07:11:31 > @@ -2168,7 +2168,7 @@ > dm_di_mode = vap->va_mode|VTTOIF(vap->va_type); > namelen = strlen(name); > if (namelen >= MAXNAMELEN) > - return XFS_ERROR(EINVAL); > + return XFS_ERROR(ENAMETOOLONG); > > if (DM_EVENT_ENABLED(dir_vp->v_vfsp, dp, DM_EVENT_CREATE)) { > error = xfs_dm_send_create_event(dir_bdp, name, > @@ -3063,7 +3063,7 @@ > > namelen = strlen(name); > if (namelen >= MAXNAMELEN) > - return XFS_ERROR(EINVAL); > + return XFS_ERROR(ENAMETOOLONG); > if (DM_EVENT_ENABLED(dir_vp->v_vfsp, dp, DM_EVENT_REMOVE)) { > error = dm_send_namesp_event(DM_EVENT_REMOVE, dir_bdp, DM_RIGHT_NULL, > NULL, DM_RIGHT_NULL, > @@ -3363,7 +3363,7 @@ > > target_namelen = strlen(target_name); > if (target_namelen >= MAXNAMELEN) > - return XFS_ERROR(EINVAL); > + return XFS_ERROR(ENAMETOOLONG); > /* > * Get the real vnode. > */ > @@ -3601,7 +3601,7 @@ > > dir_namelen = strlen(dir_name); > if (dir_namelen >= MAXNAMELEN) > - return XFS_ERROR(EINVAL); > + return XFS_ERROR(ENAMETOOLONG); > > tp = NULL; > dp_joined_to_trans = B_FALSE; > @@ -3866,7 +3866,7 @@ > return XFS_ERROR(EIO); > namelen = strlen(name); > if (namelen >= MAXNAMELEN) > - return XFS_ERROR(EINVAL); > + return XFS_ERROR(ENAMETOOLONG); > > if (DM_EVENT_ENABLED(dir_vp->v_vfsp, dp, DM_EVENT_REMOVE)) { > error = dm_send_namesp_event(DM_EVENT_REMOVE, > @@ -4221,7 +4221,7 @@ > > link_namelen = strlen(link_name); > if (link_namelen >= MAXNAMELEN) > - return XFS_ERROR(EINVAL); > + return XFS_ERROR(ENAMETOOLONG); > /* > * Check component lengths of the target path name. > */ > -- > masano -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Nov 5 09:27:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5HR9I13543 for linux-xfs-outgoing; Mon, 5 Nov 2001 09:27:09 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5HR1013520 for ; Mon, 5 Nov 2001 09:27:01 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fA5HQtK11649 for ; Mon, 5 Nov 2001 09:26:55 -0800 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 LAA3500562; Mon, 5 Nov 2001 11:25:39 -0600 (CST) Received: from jen.americas.sgi.com (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 LAA59566; Mon, 5 Nov 2001 11:25:39 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA5HL2X11323; Mon, 5 Nov 2001 11:21:02 -0600 Subject: Re: Oops - XFS mount after replacing wrong RAID5 drive From: Steve Lord To: Andrew Klaassen Cc: linux-xfs@oss.sgi.com, linux-raid@vger.kernel.org In-Reply-To: <20011105112231.B3864@dkp.com> References: <20011105103521.A3864@dkp.com> <1004974636.7318.5.camel@jen.americas.sgi.com> <20011105112231.B3864@dkp.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.100+cvs.2001.11.02.21.57 (Preview Release) Date: 05 Nov 2001 11:21:02 -0600 Message-Id: <1004980862.10860.54.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2001-11-05 at 10:22, Andrew Klaassen wrote: > On Mon, Nov 05, 2001 at 09:37:16AM -0600, > Steve Lord wrote: > > > On Mon, 2001-11-05 at 09:35, > > Andrew Klaassen wrote: > > > > > > > (The XFS filesystem did not unmount cleanly after the first > > > drive failure. That's why I'm assuming that it replayed its > > > log when I mounted it after replacing the drive.) > > > It will have replayed its log - and that information is now > > gone, so it is a little hard to say what state the filesystem > > is really in now. > > So... mount it ro,norecovery, then run xfs_repair -n? Or just > mount it ro,norecovery and try to grab the info we absolutely > need? I was assuming you had replaced the wrong drive and remounted the filesystem, at which point recovery would have run. Once the log is updated then recovery will not run again - although if you switch drives again it is very hard to say what will happen - it depends on which portions of the fs were on the bad drive. Given raid5 this is not something I could predict. xfs_repair -n is only useful if you want to see how inconsistent the filesystem is. Sounds like the ro,norecovery options and an xfs_repair -n would be a good thing to do if you did swap back in the good drive. You can also use xfs_logprint -t to give you an idea of how much will happen during log recovery, although the output is really pretty developer centric. What you should actually do at this point sort of depends on what the raid folks think your chances are. If all you did was mount the fs and run recovery with the bad drive still in there then things may not be so bad. I am not sure you can flip out one drive and then do another in the middle of raid rebuild, that would almost certainly toast the volume. You might need to let raid rebuild complete on the current set of drives, and then replace the real bad drive with a good one. Wait for the raid experts to respond on this point, do not take my word for it! > > How much is it likely to have written while replaying the log? > (There's a reasonably good chance that it sync'd before the box > went down the first time.) In that case there would have been nothing much in there - xfs writes out a record into the log after a period of inactivity which basically marks the log as empty. However, another record is written at unmount time, if this unmount record is not present then xfs will assume a crash and replay the log - which can consist of doing nothing. > > For the RAID5 people: How much has to be written to the array > before the old probably-good drive will be useless? What will > happen if I put it back in and it's too far out of sync? > > > > How do I mount the filesystem without writing anything at > > > all to the array? > > > mount -o ro,norecovery > > > > Even a readonly mount without the norecovery will attempt to run > > recovery. > > So there's no way at all to mount the filesystem without some > writing occuring? No, if you use the combination of the two options then there should be no disk I/O at all. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Nov 5 09:35:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5HZSv13762 for linux-xfs-outgoing; Mon, 5 Nov 2001 09:35:28 -0800 Received: from rain.CC.Lehigh.EDU (rain.CC.Lehigh.EDU [128.180.39.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5HZO013738 for ; Mon, 5 Nov 2001 09:35:25 -0800 Received: from Lehigh.EDU (hooch.CC.Lehigh.EDU [128.180.3.11]) by rain.CC.Lehigh.EDU (8.12.1/8.12.0) with ESMTP id fA5HYXZa008097 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Nov 2001 12:34:43 -0500 Message-ID: <3BE6C909.6070308@Lehigh.EDU> Date: Mon, 05 Nov 2001 12:14:49 -0500 From: Jim Eshleman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Jason Allen CC: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.13 Mem Related Hangs Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > We have a 8 CPU/8GB Dell 8450 running 2.4.13 (NFS and XFS patches) > which hangs regularly. > > I'd say that the problem is memory related. What seems to occur is > that mem cache grows until physical mem is exhausted at which time > the system hangs. FWIW me too, on an 8-way 8.5GB (64GB HIGHMEM enabled) IBM Netfinity x370 (8500R) which functions as a production mail server. I currently run 2.4.9 with XFS and it stays up for about a week under heavy load. 2.4.13 lasted about 4 hours under light load until all memory was consumed by cache then it became unresponsive. 2.4.13 on a 2-way 1GB (64GB HIGHMEM enabled) Netfinity x350 test box with the same kernel config and XFS works fine even under stress, so perhaps our problem is similar to the discussion on l-k "Google's mm problems"... Anything I can do to help please ask. Jim From owner-linux-xfs@oss.sgi.com Mon Nov 5 10:01:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5I1PZ14333 for linux-xfs-outgoing; Mon, 5 Nov 2001 10:01:25 -0800 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5I1G014311 for ; Mon, 5 Nov 2001 10:01:17 -0800 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 494211AB2F; Mon, 5 Nov 2001 13:01:16 -0500 (EST) Received: by ranma.dkp.com (Postfix, from userid 168) id 161D05A52F; Mon, 5 Nov 2001 13:01:16 -0500 (EST) Date: Mon, 5 Nov 2001 13:01:15 -0500 From: Andrew Klaassen To: linux-xfs@oss.sgi.com, linux-raid@vger.kernel.org Subject: Re: Oops - XFS mount after replacing wrong RAID5 drive Message-ID: <20011105130115.A3979@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com, linux-raid@vger.kernel.org References: <20011105103521.A3864@dkp.com> <1004974636.7318.5.camel@jen.americas.sgi.com> <20011105112231.B3864@dkp.com> <1004980862.10860.54.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1004980862.10860.54.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Nov 05, 2001 at 11:21:02AM -0600, Steve Lord wrote: > What you should actually do at this point sort of depends on > what the raid folks think your chances are. If all you did was > mount the fs and run recovery with the bad drive still in > there then things may not be so bad. I am not sure you can > flip out one drive and then do another in the middle of raid > rebuild, that would almost certainly toast the volume. You > might need to let raid rebuild complete on the current set of > drives, and then replace the real bad drive with a good one. Unfortunately, there was an unclean unmount the second time, too. Here's the full sordid sequence of events: - hdp giving errors (SectorIdNotFound). - hdn fails (dma_status=0x00, or something like that); the array goes into degraded mode. - The system hangs on shutdown, and has to be taken down hard. - I assume that hdp is actually the problem; I replace hdp. (IDE is just that way sometimes...) - When the box comes back up, the array isn't recognized. - I mark hdp as a failed-drive and run mkraid -f. Now the array is recognized. - I mount the filesystem read-write. The data appears to be there. - I raidhotadd hdp to the array. Reconstruction begins, but stalls almost immediately. (/proc/mdstat reports 0K done and a long, long time to finish.) - I attempt to unmount the filesystem. It stalls. I attempt to reboot; again, it stalls. I wait for a couple of minutes before taking the box down hard. And now, it looks like the probably-good drive may be heading for a failure itself. :( I'm attempting to clone it before I try putting it back in. > Wait for the raid experts to respond on this point, do not take > my word for it! I think I might take a look at the raid code myself before I go too far, just for the fun of it. Might be a useless exercise, but worth a shot. Anyone know of any design docs other than the code itself, to ease me into it? > > > > How do I mount the filesystem without writing anything at > > > > all to the array? > > > mount -o ro,norecovery > > > > > > Even a readonly mount without the norecovery will attempt to run > > > recovery. > > So there's no way at all to mount the filesystem without some > > writing occuring? > No, if you use the combination of the two options then there should be > no disk I/O at all. Sorry; I misread your first reply. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Mon Nov 5 10:07:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5I7TP14587 for linux-xfs-outgoing; Mon, 5 Nov 2001 10:07:29 -0800 Received: from imapserverb.fnal.gov (imapserverb.fnal.gov [131.225.9.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5I7I014563 for ; Mon, 5 Nov 2001 10:07:18 -0800 Received: from imapserverb.fnal.gov ([131.225.9.17]) by imapserverb.fnal.gov (Netscape Messaging Server 4.15) with SMTP id GMCAC400.UN0 for ; Mon, 5 Nov 2001 12:07:16 -0600 Received: from fnal.gov ([131.225.7.82]) by imapserverb.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001110512071630677 ; Mon, 05 Nov 2001 12:07:16 -0600 Message-ID: <3BE6D555.D903B2DB@fnal.gov> Date: Mon, 05 Nov 2001 12:07:17 -0600 From: Dan Yocum 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 , xfs-list Subject: Re: Who / What's using Linux XFS? References: <1004379839.13361.47.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric, Sorry, I didn't respond early to this one. Here's a "press release" of how we're using XFS: The Sloan Digital Sky Survey is an ambitious effort to map 1/4 of the visible sky at optical and very-near infrared wavelengths, and take spectra of 1 million extra-galactic objects. The estimated amount of data that will be taken over the 5 year lifespan of the project is 15TB, however, the total amount of storage space required for object informational databases, corrected frames, and reduced spectra will be several factors more than this. The goal is to have all the data online and available to the collaborators at all times, and provide this within strict budget constraints. To accomplish this goal we are using COTS machines with IDE disks configured as RAID50 arrays using XFS. Each machine has 16 81.9GB disks resulting in 1.12TB of usable space. At current hardware prices, these machines cost approximately $11,000 USD, or just under a penny per megabyte. Currently, 10 machines are in production and plans for 12TB more space is in the works. For complete details and status of the project please see http://www.sdss.org. Cheers, Dan Eric Sandeen wrote: > > Hi all - > > I'd like to put a page up on the web site detailing the various > applications, distributions, installations, and embedded products using > XFS for Linux. > > I'd appreciate some submissions; examples below. > > Applications > ------------ > Grub > GNU parted > Ferris > Samba, supports XFS acls. > > Distributions > ------------- > Mandrake 8.1 > Debian "sid" has xfs patches > JBLinux > J-B linux > > Installations > ------------- > Hm, no examples here... what I'm _not_ looking for is "my home > fileserver." What I _am_ looking for is something like "The human > genome project stores all data on Linux/XFS" :) Basically, something > that someone else contemplating a substantial Linux/XFS deployment would > be interested in. > > Products > -------- > I know of some embedded projects using XFS, but I'm not sure I'm free to > mention them. If you're using XFS in your whiz-bang toaster or set-top > box, that'd be a good data point as well. > > If you have something to submit, please include a URL for the > project/distro/installation site for more info, and a brief description > of features, capabilities, etc of the submission. > > I'll reserve the right to filter all this for things that I feel are > substantial enough to mention. > > This thread has the potential to get fairly off-topic, so let's not > delve too far into discussions of the relative merits of various > distros, etc... > > Thanks! > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Mon Nov 5 10:43:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5IhPm16331 for linux-xfs-outgoing; Mon, 5 Nov 2001 10:43:25 -0800 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 fA5IhM016309 for ; Mon, 5 Nov 2001 10:43:22 -0800 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 KAA04745 for ; Mon, 5 Nov 2001 10:42:51 -0800 (PST) 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 MAA3500553 for ; Mon, 5 Nov 2001 12:42:04 -0600 (CST) Received: from jen.americas.sgi.com (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 MAA71157 for ; Mon, 5 Nov 2001 12:42:04 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA5IbRR13720; Mon, 5 Nov 2001 12:37:27 -0600 Message-Id: <200111051837.fA5IbRR13720@jen.americas.sgi.com> Date: Mon, 5 Nov 2001 12:37:27 -0600 Subject: TAKE - Fix error return on too long pathname component Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Code from ASANO Masahiro. Steve Date: Mon Nov 5 10:40:15 PST 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:106089a linux/fs/xfs/xfs_vnodeops.c - 1.513 - Fix error return on too long pathname component. From owner-linux-xfs@oss.sgi.com Mon Nov 5 11:05:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5J5cb17003 for linux-xfs-outgoing; Mon, 5 Nov 2001 11:05:38 -0800 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 fA5J5Y016981 for ; Mon, 5 Nov 2001 11:05:35 -0800 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 UAA1705904 for ; Mon, 5 Nov 2001 20:04:40 +0100 (CET) mail_from (roehrich@sgi.com) Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA3500767 for ; Mon, 5 Nov 2001 13:04:15 -0600 (CST) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA94794 for ; Mon, 5 Nov 2001 13:04:14 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX) id NAA54565 for linux-xfs@oss.sgi.com; Mon, 5 Nov 2001 13:04:12 -0600 (CST) Date: Mon, 5 Nov 2001 13:04:12 -0600 (CST) From: Dean Roehrich Message-Id: <200111051904.NAA54565@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix loop in dmapi code in xfs_write. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Nov 5 11:02:06 PST 2001 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:106094a linux/fs/xfs/linux/xfs_lrw.c - 1.116 - When CONFIG_XFS_DMAPI is set we can get into an infinite loop in xfs_write on the "goto start". Once savedsize is determined to be out of date we never update it for subsequent passes (a porting bug), so we stay in the loop. This check shouldn't be performed unless we're calling xfs_dm_send_data_event anyway, so move it into that if-block. Now we don't have to update savedsize because we get into that if-block only once per call to xfs_write, and savedsize has no other purpose. From owner-linux-xfs@oss.sgi.com Mon Nov 5 11:20:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5JKgR17477 for linux-xfs-outgoing; Mon, 5 Nov 2001 11:20:42 -0800 Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5JKT017444 for ; Mon, 5 Nov 2001 11:20:30 -0800 Received: from chemraeker1 (chemraeker1.Chem.LSA.UMich.Edu [141.211.69.17]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with SMTP id OAA20611 for ; Mon, 5 Nov 2001 14:20:28 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Todd Raeker To: linux-xfs@oss.sgi.com Subject: Re: shell filesize limit of 4 GB Date: Mon, 5 Nov 2001 14:20:09 -0500 X-Mailer: KMail [version 1.2] References: <01102909435902.11332@chemraeker1> <3BE0C2A6.C1D891BE@umbi.umd.edu> <20011101171046.E541473@wobbly.melbourne.sgi.com> In-Reply-To: <20011101171046.E541473@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Message-Id: <01110514200900.01355@chemraeker1> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thursday 01 November 2001 01:10, Nathan Scott wrote: > hi Jonathan, > > [For the tcsh-bugs@mx.gw.com folk, this is a Linux+XFS system > with glibc 2.2.4, the problem involves setting any high limits > with large file support enabled - its a tcsh/glibc header file > interaction bug, by the look of things] > > On Wed, Oct 31, 2001 at 10:33:58PM -0500, Jonathan Dill wrote: > > Steve Lord wrote: > > > I do know that if you use the limits interface then there is only 4 > > > bytes of space in the kernel to store limits. Which means you cannot > > > impose a limit of greater than 4G bytes. The rollover you are seeing > > > is probably because of this. Setting a limit to RLIM_INFINITY which > > > is 0xffffffff on i386 effectively disables the limit checking and this > > > is the only way to get into higher order files. > > > > How do I set the limit to RLIM_INFINITY? Trying to do it with the limit > > command seems to have no effect: > > > > [root@amanda ~]# limit -h filesize > > filesize 4194303 kbytes > > [root@amanda ~]# limit -h filesize 68719476736 > > [root@amanda ~]# limit -h filesize > > filesize 0 kbytes > > > > It's curious that I was still able to create a 4.7 GB file. With the > > old tcsh without -D_FILE_OFFSET_BITS=64, this is what I get even though > > I can't create > 2 GB files: > > > > [root@bit ~]# limit -h filesize > > filesize unlimited > > > > If I have problems the next time I'm trying to create large files, I > > guess I'll have to try bash and see what I can do with that. > > Okay... I've had another quick look at this problem. Firstly, > there is a more recent version of tcsh at http://www.tcsh.org/ > - so, I'm using that one (which has fixed the O_LARGEFILE issue, > btw). The limit problem you describe above remains, however. > > So, poking around in tcsh-6.11.00/sh.func.c for my first time, > the problem would appear to be a type-related bug in sh.func.c > in its definition of RLIM_TYPE. Try out this patch (and verify > that you get the "debug" output at compile time)... > > diff -Naur tcsh-6.11.00/sh.func.c tcsh-6.11.00-ns/sh.func.c > --- tcsh-6.11.00/sh.func.c Tue Mar 13 23:53:50 2001 > +++ tcsh-6.11.00-ns/sh.func.c Thu Nov 1 16:39:02 2001 > @@ -1720,7 +1720,8 @@ > # if defined(_SX) > typedef long long RLIM_TYPE; > # else /* _SX */ > - typedef unsigned long RLIM_TYPE; > +# warning debug - using unsigned long long RLIM_TYPE > + typedef unsigned long long RLIM_TYPE; > # endif /* _SX */ > # endif /* SOLARIS2 || (sgi && SYSVREL > 3) */ > # endif /* BSD4_4 && !__386BSD__ */ > > > tcsh-6.11.00-ns# ./tcsh > tcsh-6.11.00-ns# limit filesize > filesize unlimited > tcsh-6.11.00-ns# dd if=/dev/zero of=big bs=1024 seek=687194 count=1 > 1+0 records in > 1+0 records out > tcsh-6.11.00-ns# ls -lh big > -rw-rw-r-- 1 root root 671M Nov 1 16:56 big > tcsh-6.11.00-ns# dd if=/dev/zero of=bigger bs=1024 seek=6871947673 count=1 > 1+0 records in > 1+0 records out > tcsh-6.11.00-ns# ls -lh bigger > -rw-rw-r-- 1 root root 6.4T Nov 1 16:56 bigger > tcsh-6.11.00-ns# dd if=/dev/zero of=sick bs=1024 seek=6871947673699 count=1 > 1+0 records in > 1+0 records out > tcsh-6.11.00-ns# ls -lh sick > -rw-rw-r-- 1 root root 6.3P Nov 1 16:57 sick > tcsh-6.11.00-ns# > tcsh-6.11.00-ns# > tcsh-6.11.00-ns# limit filesize 68719476736 > tcsh-6.11.00-ns# limit filesize > filesize unlimited > tcsh-6.11.00-ns# > tcsh-6.11.00-ns# limit filesize 4194303 > tcsh-6.11.00-ns# limit filesize > filesize 4194303 kbytes > tcsh-6.11.00-ns# limit filesize 4194304 > tcsh-6.11.00-ns# limit filesize > filesize unlimited > tcsh-6.11.00-ns# uname -a > Linux troppo 2.4.14-pre6-xfs #65 Thu Nov 1 13:06:14 EST 2001 i686 unknown > tcsh-6.11.00-ns# > > > So, that seems to work now - and not an XFS related problem. > Definately a tcsh bug though. > > cheers. Hi All, I started this large file limit issue and am still having problems. Applying the patches above and numerous suggestions still limit me to 4 GB even though tcsh I have supports large files and limit reports unlimited filesize. I even tried the above dd commands and notice that ls -l reports the correct size but df shows no change. More important an intended 6 GB file took less than a second to create. Has anybody else been working/try to solve this problem and who has advice? Thanks. Todd. -- Todd Raeker Department of Chemistry University of Michigan (734) 647-2867 Phone (734) 615-6950 FAX From owner-linux-xfs@oss.sgi.com Mon Nov 5 11:32:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5JWFp17782 for linux-xfs-outgoing; Mon, 5 Nov 2001 11:32:15 -0800 Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5JWC017755 for ; Mon, 5 Nov 2001 11:32:12 -0800 Received: from umbi.umd.edu (amanda.carb.nist.gov [129.6.113.5]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GMCE9Q00.3R6; Mon, 5 Nov 2001 14:32:14 -0500 Message-ID: <3BE6E93A.35043940@umbi.umd.edu> Date: Mon, 05 Nov 2001 14:32:10 -0500 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-12SGI_XFS_PR1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Todd Raeker CC: linux-xfs@oss.sgi.com Subject: Re: shell filesize limit of 4 GB References: <01102909435902.11332@chemraeker1> <3BE0C2A6.C1D891BE@umbi.umd.edu> <20011101171046.E541473@wobbly.melbourne.sgi.com> <01110514200900.01355@chemraeker1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Stupid question, but have you tried changing the shell to bash to see what happens? My current status is that I downloaded tcsh-6.11-3mdk.src.rpm from Mandrake Cooker and built binary RPMs. tcsh from that RPM has O_LARGEFILE, but still reports a limit of 4 GB. I haven't tested creating a file > 4 GB yet, and I haven't patched the source yet. -- "Jonathan F. Dill" (dill@umbi.umd.edu) CARB IT Coordinator Experimental Support Site http://concept.umbi.umd.edu From owner-linux-xfs@oss.sgi.com Mon Nov 5 12:11:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5KBwG18861 for linux-xfs-outgoing; Mon, 5 Nov 2001 12:11:58 -0800 Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5KBr018839 for ; Mon, 5 Nov 2001 12:11:53 -0800 Received: from umbi.umd.edu (amanda.carb.nist.gov [129.6.113.5]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GMCG3W00.SQH; Mon, 5 Nov 2001 15:11:56 -0500 Message-ID: <3BE6F286.8B8BC9C6@umbi.umd.edu> Date: Mon, 05 Nov 2001 15:11:50 -0500 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-12SGI_XFS_PR1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Todd Raeker CC: linux-xfs@oss.sgi.com Subject: Re: shell filesize limit of 4 GB References: <01102909435902.11332@chemraeker1> <3BE0C2A6.C1D891BE@umbi.umd.edu> <20011101171046.E541473@wobbly.melbourne.sgi.com> <01110514200900.01355@chemraeker1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Despite the nonsense that tcsh reports on limits, I can create files > 4 GB without problems, from tcsh, from the Mandrake Cooker src.rpm--Here, demonstrated with a 5 GB file: [root@amanda tmp]# dd if=/dev/zero of=test.img bs=128M count=40 40+0 records in 40+0 records out [root@amanda tmp]# ls test.img [root@amanda tmp]# du -h test.img 5.1G test.img [root@amanda tmp]# limit -h cputime 0:0-1 filesize 4194303 kbytes datasize 4194303 kbytes stacksize 4194303 kbytes coredumpsize 4194303 kbytes memoryuse 4194303 kbytes vmemoryuse 4194303 kbytes descriptors 1024 memorylocked 4194303 kbytes maxproc 2045 openfiles 1024 -- "Jonathan F. Dill" (dill@umbi.umd.edu) CARB IT Coordinator Experimental Support Site http://concept.umbi.umd.edu From owner-linux-xfs@oss.sgi.com Mon Nov 5 12:46:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5KkRh20284 for linux-xfs-outgoing; Mon, 5 Nov 2001 12:46:27 -0800 Received: from cpw.math.columbia.edu (root@cpw.math.columbia.edu [128.59.209.25]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5KkM020261 for ; Mon, 5 Nov 2001 12:46:22 -0800 Received: from intel5.math.columbia.edu (root@intel5.math.columbia.edu [128.59.209.155]) by cpw.math.columbia.edu (8.11.4/8.11.6) with ESMTP id fA5KkHv27725 for ; Mon, 5 Nov 2001 15:46:17 -0500 Received: from localhost (atici@localhost) by intel5.math.columbia.edu (8.11.3/8.11.3) with ESMTP id fA5KkB007294 for ; Mon, 5 Nov 2001 15:46:20 -0500 X-Authentication-Warning: intel5.math.columbia.edu: atici owned process doing -bs Date: Mon, 5 Nov 2001 15:46:11 -0500 (EST) From: Alp ATICI To: Subject: NVidia & XFS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I wonder whether anyone had the same problem with me. I have a GeForce 3 video card and it works perfectly on a usual 7.2 system with the binaries provided in nvidia.com. However now I'm using a customised kernel (since I'd like to use XFS), therefore I got the SRPMs, rebuilt and installed them. The previous version had slight problems whereas 1.0.1541 simply doesn't work at all. I have no idea how it might clash with XFS resources or XFS capable kernel but I'd appreciate if someone could shed some light. When I observe the XFree86.0.log I see the drivers loaded perfectly and GeForce 3 is recognised at PCI 1:5:0 but then I get the following problem... The final lines in XFree86.0.log is: ----- (==) NVIDIA(0): Write-combining range (0xf0000000,0x4000000) (WW) NVIDIA(0): Failed to allocate a DMA push buffer using AGP memory... (WW) NVIDIA(0): attempting to use PCI memory (EE) NVIDIA(0): Failed to allocate a DMA push buffer context (EE) NVIDIA(0): *** Aborting *** (EE) NVIDIA(0): Failed to allocate DMA push buffer (EE) NVIDIA(0): *** Aborting *** ----- I reported the problem to Nvidia but they didn't even respond. I don't think they care much about linux. Yet if you had the same problem or have an idea on the cause let me know. Alp BTW I think XFS is great and I appreciate your efforts. Looking forward to see the 1.1.0 release... From owner-linux-xfs@oss.sgi.com Mon Nov 5 12:58:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5KwU320569 for linux-xfs-outgoing; Mon, 5 Nov 2001 12:58:30 -0800 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5KwR020547 for ; Mon, 5 Nov 2001 12:58:27 -0800 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id PAA20257; Mon, 5 Nov 2001 15:58:12 -0500 Message-ID: <3BE6FD6B.1699051A@ieee.org> Date: Mon, 05 Nov 2001 15:58:19 -0500 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Alp ATICI CC: linux-xfs@oss.sgi.com Subject: Re: NVidia & XFS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alp ATICI wrote: > I reported the problem to Nvidia but they didn't even respond. > I don't think they care much about linux. Yet if you had the same > problem or have an idea on the cause let me know. Actually, I have XFS + nVidia working great on Linux, but get total hangs on Windows. It's clearly an AMD/nVidia AGPgart issue and they won't even respond for Windows support! ;-PPP -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- "The [US] Constitution guarantees you Free, not Fair. 'Fair' is a socialist concept." -- Shawn McMahon From owner-linux-xfs@oss.sgi.com Mon Nov 5 13:03:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5L3Ta20798 for linux-xfs-outgoing; Mon, 5 Nov 2001 13:03:29 -0800 Received: from eclectic.kluge.net (IDENT:root@dsl092-071-242.bos1.dsl.speakeasy.net [66.92.71.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5L3Q020776 for ; Mon, 5 Nov 2001 13:03:26 -0800 Received: (from felicity@localhost) by eclectic.kluge.net (8.11.6/8.11.6) id fA5L30l05158; Mon, 5 Nov 2001 16:03:00 -0500 Date: Mon, 5 Nov 2001 16:03:00 -0500 From: Theo Van Dinter To: Bryan-TheBS-Smith Cc: Alp ATICI , linux-xfs@oss.sgi.com Subject: Re: NVidia & XFS Message-ID: <20011105160300.K3560@kluge.net> References: <3BE6FD6B.1699051A@ieee.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BE6FD6B.1699051A@ieee.org>; from b.j.smith@ieee.org on Mon, Nov 05, 2001 at 03:58:19PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Nov 05, 2001 at 03:58:19PM -0500, Bryan-TheBS-Smith wrote: > Actually, I have XFS + nVidia working great on Linux, but get total > hangs on Windows. It's clearly an AMD/nVidia AGPgart issue and they > won't even respond for Windows support! ;-PPP It works fine for me as well. I have a GeForce2, and everything works great. I found that after upgrading from RH 7.1 to 7.2, I had to reinstall both the NVIDIA_kernel and GLX packages, and then redo the XF86Config and XF86Config-4 files. After that, everything worked great. -- Randomly Generated Tagline: Personally, I think my choice in the mostest-superlative-computer wars has to be the HP-48 series of calculators. They'll run almost anything. And if they can't, while I'll just plug a Linux box into the serial port and load up the HP-48 VT-100 emulator. (By jdege@winternet.com, Jeff Dege) From owner-linux-xfs@oss.sgi.com Mon Nov 5 13:06:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5L6DF20955 for linux-xfs-outgoing; Mon, 5 Nov 2001 13:06:13 -0800 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5L69020933 for ; Mon, 5 Nov 2001 13:06:09 -0800 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id QAA20302; Mon, 5 Nov 2001 16:05:56 -0500 Message-ID: <3BE6FF3B.5FFF190E@ieee.org> Date: Mon, 05 Nov 2001 16:06:03 -0500 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Theo Van Dinter CC: Alp ATICI , linux-xfs@oss.sgi.com Subject: Re: NVidia & XFS References: <3BE6FD6B.1699051A@ieee.org> <20011105160300.K3560@kluge.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Theo Van Dinter wrote: > It works fine for me as well. I have a GeForce2, and everything works great. > I found that after upgrading from RH 7.1 to 7.2, I had to reinstall both the > NVIDIA_kernel and GLX packages, Of course, the kernel changed. You have to at least re-install the "NVIDIA_kernel" package. > and then redo the XF86Config and XF86Config-4 files. > After that, everything worked great. ??? Not me ??? -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- "The [US] Constitution guarantees you Free, not Fair. 'Fair' is a socialist concept." -- Shawn McMahon From owner-linux-xfs@oss.sgi.com Mon Nov 5 13:15:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5LFG721264 for linux-xfs-outgoing; Mon, 5 Nov 2001 13:15:16 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5LFC021241 for ; Mon, 5 Nov 2001 13:15:13 -0800 Received: from cpw.math.columbia.edu (cpw.math.columbia.edu [128.59.209.25]) 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 NAA07830 for ; Mon, 5 Nov 2001 13:15:11 -0800 (PST) mail_from (atici@math.columbia.edu) Received: from intel5.math.columbia.edu (root@intel5.math.columbia.edu [128.59.209.155]) by cpw.math.columbia.edu (8.11.4/8.11.6) with ESMTP id fA5LA3v28247 for ; Mon, 5 Nov 2001 16:10:03 -0500 Received: from localhost (atici@localhost) by intel5.math.columbia.edu (8.11.3/8.11.3) with ESMTP id fA5LA5T07325 for ; Mon, 5 Nov 2001 16:10:05 -0500 X-Authentication-Warning: intel5.math.columbia.edu: atici owned process doing -bs Date: Mon, 5 Nov 2001 16:10:05 -0500 (EST) From: Alp ATICI To: Subject: Re: NVidia & XFS In-Reply-To: <85063BBE668FD411944400D0B744267A888710@AUSMAIL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I've got a GeForce2 and use 1541 with no issues. I do exactly what you > described, and I always use a vanilla kernel + XFS patch. I'm using RedHat 7.1 with XFS 1.0.1 from the iso's provided. Only thing differs is that I have a gcc 3.0. Do you think it might be sth about Red Hat kernel or installation of gcc? > I think you might need to ensure that you've properly rebuilt your NV > modules and there are no symbol errors. Also, I've had issues > where the RPMs didn't overwrite my old module for some reason and I had to > install using --replacepkgs. I read the nvidia README thoroughly and stuck to that. About the symbol errors, someone else proposed the same. I didn't think there might be an error in those because I didn't modify anything after I installed the iso images and then the gcc (since 7.1 gcc was buggy). > NVIDIA_kernel and GLX packages, and then redo the XF86Config and > XF86Config-4 files. Could someone attach these to me in private? I did everything in README but I want to double check. Thanks, Alp From owner-linux-xfs@oss.sgi.com Mon Nov 5 13:18:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5LIif21426 for linux-xfs-outgoing; Mon, 5 Nov 2001 13:18:44 -0800 Received: from eclectic.kluge.net (IDENT:root@dsl092-071-242.bos1.dsl.speakeasy.net [66.92.71.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5LIf021403 for ; Mon, 5 Nov 2001 13:18:41 -0800 Received: (from felicity@localhost) by eclectic.kluge.net (8.11.6/8.11.6) id fA5LIYp05262; Mon, 5 Nov 2001 16:18:34 -0500 Date: Mon, 5 Nov 2001 16:18:34 -0500 From: Theo Van Dinter To: Bryan-TheBS-Smith Cc: Alp ATICI , linux-xfs@oss.sgi.com Subject: Re: NVidia & XFS Message-ID: <20011105161834.L3560@kluge.net> References: <3BE6FD6B.1699051A@ieee.org> <20011105160300.K3560@kluge.net> <3BE6FF3B.5FFF190E@ieee.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BE6FF3B.5FFF190E@ieee.org>; from b.j.smith@ieee.org on Mon, Nov 05, 2001 at 04:06:03PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Nov 05, 2001 at 04:06:03PM -0500, Bryan-TheBS-Smith wrote: > Of course, the kernel changed. You have to at least re-install the > "NVIDIA_kernel" package. Yeah, I'd been doing that. Then with the update to RH 7.2, Mesa and the XFree packages got upgraded so I needed to redo GLX. (that and I upgraded kernel to 1541 ...) > ??? Not me ??? It was the XFree upgrade that seemed to have moved the old configs out of the way. I found the old versions and installed them and everything went fine from there. So everything's working great right now. :) -- Randomly Generated Tagline: "Programming isn't so much a profession as it is an obsessive-compulsive disorder." - Unknown From owner-linux-xfs@oss.sgi.com Mon Nov 5 13:20:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5LKqh21577 for linux-xfs-outgoing; Mon, 5 Nov 2001 13:20:52 -0800 Received: from eclectic.kluge.net (IDENT:root@dsl092-071-242.bos1.dsl.speakeasy.net [66.92.71.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5LKm021555 for ; Mon, 5 Nov 2001 13:20:49 -0800 Received: (from felicity@localhost) by eclectic.kluge.net (8.11.6/8.11.6) id fA5LKh805316; Mon, 5 Nov 2001 16:20:43 -0500 Date: Mon, 5 Nov 2001 16:20:43 -0500 From: Theo Van Dinter To: Alp ATICI Cc: linux-xfs@oss.sgi.com Subject: Re: NVidia & XFS Message-ID: <20011105162043.M3560@kluge.net> References: <85063BBE668FD411944400D0B744267A888710@AUSMAIL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from atici@math.columbia.edu on Mon, Nov 05, 2001 at 04:10:05PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Nov 05, 2001 at 04:10:05PM -0500, Alp ATICI wrote: > Could someone attach these to me in private? I did everything in > README but I want to double check. Thanks, Take a look at: ftp://209.213.197.10/XFree86_40/1.0-1541/ Specifically: ftp://209.213.197.10/XFree86_40/1.0-1541/NVIDIA_GLX-1.0-1541.i386.rpm ftp://209.213.197.10/XFree86_40/1.0-1541/NVIDIA_kernel-1.0-1541.src.rpm Then do a "rpm --rebuild" on NVIDIA_kernel and install the resulting RPM. -- Randomly Generated Tagline: "Give a man a fish and he will eat for a day. Teach him how to fish, and he will sit in a boat & drink beer all day." - Zen Musings From owner-linux-xfs@oss.sgi.com Mon Nov 5 13:24:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5LO3g21750 for linux-xfs-outgoing; Mon, 5 Nov 2001 13:24:03 -0800 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5LNx021727 for ; Mon, 5 Nov 2001 13:23:59 -0800 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id QAA20389; Mon, 5 Nov 2001 16:23:48 -0500 Message-ID: <3BE7036B.D55BBE5D@ieee.org> Date: Mon, 05 Nov 2001 16:23:55 -0500 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Alp ATICI CC: linux-xfs@oss.sgi.com Subject: Re: NVidia & XFS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alp ATICI wrote: > I read the nvidia README thoroughly and stuck to that. About the symbol > errors, someone else proposed the same. I didn't think there might be an > error in those because I didn't modify anything after I installed the > iso images and then the gcc (since 7.1 gcc was buggy). I got symbol errors when I built NVIDIA_KERNEL against a different modversions.h header than SGI did. I found my problem lay in the fact that mrproper wipes out modversions.h in /usr/src/linux and if you don't completely compile a new kernel, the one in /usr/include/linux gets used instead. Not the same, but you won't know it until you try to load a module. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- "The [US] Constitution guarantees you Free, not Fair. 'Fair' is a socialist concept." -- Shawn McMahon From owner-linux-xfs@oss.sgi.com Mon Nov 5 13:28:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5LSD421959 for linux-xfs-outgoing; Mon, 5 Nov 2001 13:28:13 -0800 Received: from eclectic.kluge.net (IDENT:root@dsl092-071-242.bos1.dsl.speakeasy.net [66.92.71.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5LSA021937 for ; Mon, 5 Nov 2001 13:28:10 -0800 Received: (from felicity@localhost) by eclectic.kluge.net (8.11.6/8.11.6) id fA5LS6a05381; Mon, 5 Nov 2001 16:28:06 -0500 Date: Mon, 5 Nov 2001 16:28:06 -0500 From: Theo Van Dinter To: Alp ATICI Cc: linux-xfs@oss.sgi.com Subject: Re: NVidia & XFS Message-ID: <20011105162806.N3560@kluge.net> References: <85063BBE668FD411944400D0B744267A888710@AUSMAIL> <20011105162043.M3560@kluge.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011105162043.M3560@kluge.net>; from felicity@kluge.net on Mon, Nov 05, 2001 at 04:20:43PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Nov 05, 2001 at 04:20:43PM -0500, Theo Van Dinter wrote: > Then do a "rpm --rebuild" on NVIDIA_kernel and install the resulting RPM. Oh, and make sure you have kernel-source installed, otherwise the build has problems. -- Randomly Generated Tagline: "Security is a process, not a patch" - Bruce Schneier From owner-linux-xfs@oss.sgi.com Mon Nov 5 13:40:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5Leoa22227 for linux-xfs-outgoing; Mon, 5 Nov 2001 13:40:50 -0800 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 fA5Lej022202 for ; Mon, 5 Nov 2001 13:40:45 -0800 Received: from idcomm.com (IDENT:of9dU4cD7lVerMAmrO9toNQshqj4J5tT@k56-pip86.idcomm.com [209.60.72.213] (may be forged)) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id fA5LglL31433 for ; Mon, 5 Nov 2001 14:42:48 -0700 Message-ID: <3BE707AA.A7AF539@idcomm.com> Date: Mon, 05 Nov 2001 14:42:02 -0700 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 & XFS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Alp ATICI wrote: > > > I've got a GeForce2 and use 1541 with no issues. I do exactly what you > > described, and I always use a vanilla kernel + XFS patch. > > I'm using RedHat 7.1 with XFS 1.0.1 from the iso's provided. Only thing > differs is that I have a gcc 3.0. Do you think it might be sth about > Red Hat kernel or installation of gcc? Something that will almost always bite you in the ass is if you use a different version of gcc for the kernel than what you use on the modules. If your kernel is being compiled with kgcc, but nvidia module with gcc 3, this probably broke it. kgcc just seems to be more reliable with weird kernel compiles, I'm not even going to bother with any other kernel or module compiler (other than kgcc) until both the XFS maintainers and the regular kernel maintainers all agree that it's time to do so. D. Stimits, stimits@idcomm.com > > > I think you might need to ensure that you've properly rebuilt your NV > > modules and there are no symbol errors. Also, I've had issues > > where the RPMs didn't overwrite my old module for some reason and I had to > > install using --replacepkgs. > > I read the nvidia README thoroughly and stuck to that. About the symbol > errors, someone else proposed the same. I didn't think there might be an > error in those because I didn't modify anything after I installed the > iso images and then the gcc (since 7.1 gcc was buggy). > > > NVIDIA_kernel and GLX packages, and then redo the XF86Config and > > XF86Config-4 files. > > Could someone attach these to me in private? I did everything in > README but I want to double check. Thanks, > Alp From owner-linux-xfs@oss.sgi.com Mon Nov 5 13:45:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5LjJv22430 for linux-xfs-outgoing; Mon, 5 Nov 2001 13:45:19 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5LjD022408 for ; Mon, 5 Nov 2001 13:45:13 -0800 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 NAA04069 for ; Mon, 5 Nov 2001 13:45:12 -0800 (PST) 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 IAA12145; Tue, 6 Nov 2001 08:43:55 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA72305; Tue, 6 Nov 2001 08:43:54 +1100 (AEDT) Date: Tue, 6 Nov 2001 08:43:54 +1100 From: Nathan Scott To: Todd Raeker Cc: linux-xfs@oss.sgi.com Subject: Re: shell filesize limit of 4 GB Message-ID: <20011106084354.B589522@wobbly.melbourne.sgi.com> References: <01102909435902.11332@chemraeker1> <3BE0C2A6.C1D891BE@umbi.umd.edu> <20011101171046.E541473@wobbly.melbourne.sgi.com> <01110514200900.01355@chemraeker1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01110514200900.01355@chemraeker1>; from raeker@umich.edu on Mon, Nov 05, 2001 at 02:20:09PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hello Todd, On Mon, Nov 05, 2001 at 02:20:09PM -0500, Todd Raeker wrote: > On Thursday 01 November 2001 01:10, Nathan Scott wrote: > > tcsh-6.11.00-ns# dd if=/dev/zero of=big bs=1024 seek=687194 count=1 > > 1+0 records in > > 1+0 records out > > tcsh-6.11.00-ns# ls -lh big > > -rw-rw-r-- 1 root root 671M Nov 1 16:56 big > > tcsh-6.11.00-ns# dd if=/dev/zero of=bigger bs=1024 seek=6871947673 count=1 > > 1+0 records in > > 1+0 records out > > tcsh-6.11.00-ns# ls -lh bigger > > -rw-rw-r-- 1 root root 6.4T Nov 1 16:56 bigger > > tcsh-6.11.00-ns# dd if=/dev/zero of=sick bs=1024 seek=6871947673699 count=1 > > 1+0 records in > > 1+0 records out > > tcsh-6.11.00-ns# ls -lh sick > > -rw-rw-r-- 1 root root 6.3P Nov 1 16:57 sick > > tcsh-6.11.00-ns# > > ... > Hi All, > > I started this large file limit issue and am still having problems. > Applying the patches above and numerous suggestions still limit me to 4 GB > even though tcsh I have supports large files and limit reports unlimited > filesize. > > I even tried the above dd commands and notice that ls -l reports the > correct size but df shows no change. More important an intended 6 GB file > took less than a second to create. You seem to be contradicting yourself here, or I am reading your mail wrong... you say you are limited to 4Gb files, then you say the dd commands report the correct size (clearly greater than 4Gb in the above cases) and that you created a 6Gb file. (?) The above dd commands are creating files with holes, so complete very quickly and take up very little filesystem space, but do demonstrate the large file support and limit enforcement. Run xfs_bmap on the created files and you'll see the holes. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Nov 5 14:37:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5Mb3Z23741 for linux-xfs-outgoing; Mon, 5 Nov 2001 14:37:03 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5Mav023719 for ; Mon, 5 Nov 2001 14:36:57 -0800 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Nov 2001 16:36:24 -0600 Message-ID: <85063BBE668FD411944400D0B744267A888715@AUSMAIL> From: "Gonyou, Austin" To: "'Alp ATICI'" , linux-xfs@oss.sgi.com Subject: RE: NVidia & XFS Date: Mon, 5 Nov 2001 16:36:22 -0600 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 use GCC 3.0.1 to compile all my kernels on the machine I described. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Alp ATICI [mailto:atici@math.columbia.edu] > Sent: Monday, November 05, 2001 3:10 PM > To: linux-xfs@oss.sgi.com > Subject: Re: NVidia & XFS > > > > > I've got a GeForce2 and use 1541 with no issues. I do > exactly what you > > described, and I always use a vanilla kernel + XFS patch. > > I'm using RedHat 7.1 with XFS 1.0.1 from the iso's provided. > Only thing > differs is that I have a gcc 3.0. Do you think it might be sth about > Red Hat kernel or installation of gcc? > > > I think you might need to ensure that you've properly > rebuilt your NV > > modules and there are no symbol errors. Also, I've had issues > > where the RPMs didn't overwrite my old module for some > reason and I had to > > install using --replacepkgs. > > I read the nvidia README thoroughly and stuck to that. About > the symbol > errors, someone else proposed the same. I didn't think there > might be an > error in those because I didn't modify anything after I installed the > iso images and then the gcc (since 7.1 gcc was buggy). > > > NVIDIA_kernel and GLX packages, and then redo the XF86Config and > > XF86Config-4 files. > > Could someone attach these to me in private? I did everything in > README but I want to double check. Thanks, > Alp > From owner-linux-xfs@oss.sgi.com Mon Nov 5 14:39:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5MdOX24411 for linux-xfs-outgoing; Mon, 5 Nov 2001 14:39:24 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5MdG023923 for ; Mon, 5 Nov 2001 14:39:16 -0800 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Nov 2001 16:38:24 -0600 Message-ID: <85063BBE668FD411944400D0B744267A888716@AUSMAIL> From: "Gonyou, Austin" To: "'Nathan Scott'" , Todd Raeker Cc: linux-xfs@oss.sgi.com Subject: RE: shell filesize limit of 4 GB Date: Mon, 5 Nov 2001 16:38:20 -0600 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 It seems that is his dilemma. He's feeling somehow that he's limited to 4gb, perhaps a program states it(perl) or some such thing, but he can still make files larger than 4gb. That might make one disconcerted, no? -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Nathan Scott [mailto:nathans@sgi.com] > Sent: Monday, November 05, 2001 3:44 PM > To: Todd Raeker > Cc: linux-xfs@oss.sgi.com > Subject: Re: shell filesize limit of 4 GB > > > hello Todd, > > On Mon, Nov 05, 2001 at 02:20:09PM -0500, Todd Raeker wrote: > > On Thursday 01 November 2001 01:10, Nathan Scott wrote: > > > tcsh-6.11.00-ns# dd if=/dev/zero of=big bs=1024 > seek=687194 count=1 > > > 1+0 records in > > > 1+0 records out > > > tcsh-6.11.00-ns# ls -lh big > > > -rw-rw-r-- 1 root root 671M Nov 1 16:56 big > > > tcsh-6.11.00-ns# dd if=/dev/zero of=bigger bs=1024 > seek=6871947673 count=1 > > > 1+0 records in > > > 1+0 records out > > > tcsh-6.11.00-ns# ls -lh bigger > > > -rw-rw-r-- 1 root root 6.4T Nov 1 16:56 bigger > > > tcsh-6.11.00-ns# dd if=/dev/zero of=sick bs=1024 > seek=6871947673699 count=1 > > > 1+0 records in > > > 1+0 records out > > > tcsh-6.11.00-ns# ls -lh sick > > > -rw-rw-r-- 1 root root 6.3P Nov 1 16:57 sick > > > tcsh-6.11.00-ns# > > > ... > > > Hi All, > > > > I started this large file limit issue and am still having > problems. > > Applying the patches above and numerous suggestions still > limit me to 4 GB > > even though tcsh I have supports large files and limit > reports unlimited > > filesize. > > > > I even tried the above dd commands and notice that ls -l > reports the > > correct size but df shows no change. More important an > intended 6 GB file > > took less than a second to create. > > You seem to be contradicting yourself here, or I am reading your > mail wrong... you say you are limited to 4Gb files, then you say > the dd commands report the correct size (clearly greater than 4Gb > in the above cases) and that you created a 6Gb file. (?) > > The above dd commands are creating files with holes, so complete > very quickly and take up very little filesystem space, but do > demonstrate the large file support and limit enforcement. Run > xfs_bmap on the created files and you'll see the holes. > > cheers. > > -- > Nathan > From owner-linux-xfs@oss.sgi.com Mon Nov 5 15:56:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5Nu2w26438 for linux-xfs-outgoing; Mon, 5 Nov 2001 15:56:02 -0800 Received: from uucp.gnuu.de (uucp.gnuu.de [151.189.0.84]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5Ntl026412 for ; Mon, 5 Nov 2001 15:55:48 -0800 Received: (from uucp@localhost) by uucp.gnuu.de (8.11.1/8.11.1) with UUCP id fA5Ntj131531 for linux-xfs@oss.sgi.com; Tue, 6 Nov 2001 00:55:45 +0100 (CET) Received: from asterix.gallien.de (asterix.gallien.de [192.168.1.2]) by mail.gallien.de (Postfix) with ESMTP id 5847E2B6A1 for ; Mon, 5 Nov 2001 22:50:13 +0100 (CET) Received: by asterix.gallien.de (Postfix, from userid 1000) id C86DA10014; Mon, 5 Nov 2001 22:50:39 +0100 (CET) Date: Mon, 5 Nov 2001 22:50:39 +0100 From: Stefan Frank To: linux-xfs@oss.sgi.com Subject: Damaged XFS partition after moving to SMP Message-ID: <20011105225039.A599@asterix.gallien.de> 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.21i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, a few days ago i retired my old P166 Mhz machine and moved to a new 2x866 PIII box. In the beginning i used the same kernel (UP !) as before (2.4.10 + XFS patch (i BELIEVE the 10/03 dated one, but i also have the 09/25). Later on while i was working on my 2nd machine reading news, suddenly GNUS got stuck. When i went back to the new SMP machine i realised that XFS had unmounted the /var partition. On the console was a message like "kernel: access beyound end of device" and the notification of XFS that it closed down the /var partition. Note that there was no indication of a Kernel oops. When i rebooted, this partition could'nt be mounted. The error message is: XFS: mounting filesystem sd(8,6) XFS: failed to read root inode Running xfs_check yields in : bad magic # 0x58465342 in btbno block 0/0 bad magic # 0x58465342 in btcnt block 0/0 bad magic # 0x58465342 in inobt block 0/0 block 3/69 expected type unknown got free2 Also xfs_repair is not able to fix the problem. See it's log below : Phase 1 - find and verify superblock... sb root inode value 18446744073709551615 inconsistent with calculated value 13835049534067048576 resetting superblock root inode pointer to 18446744069414584448 sb realtime bitmap inode 18446744073709551615 inconsistent with calculated value 13835049534067048577 resetting superblock realtime bitmap ino pointer to 18446744069414584449 sb realtime summary inode 18446744073709551615 inconsistent with calculated value 13835049534067048578 resetting superblock realtime summary ino pointer to 18446744069414584450 Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... bad agbno 0 for btbno root, agno 0 bad agbno 0 for btbcnt root, agno 0 bad agbno 0 for inobt root, agno 0 root inode chunk not found Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 imap claims in-use inode 131 is free, correcting imap imap claims in-use inode 132 is free, correcting imap imap claims in-use inode 133 is free, correcting imap imap claims in-use inode 134 is free, correcting imap imap claims in-use inode 135 is free, correcting imap imap claims in-use inode 136 is free, correcting imap imap claims in-use inode 137 is free, correcting imap imap claims in-use inode 138 is free, correcting imap imap claims in-use inode 139 is free, correcting imap imap claims in-use inode 140 is free, correcting imap imap claims in-use inode 141 is free, correcting imap imap claims in-use inode 142 is free, correcting imap imap claims in-use inode 143 is free, correcting imap imap claims in-use inode 144 is free, correcting imap imap claims in-use inode 145 is free, correcting imap imap claims in-use inode 146 is free, correcting imap imap claims in-use inode 147 is free, correcting imap imap claims in-use inode 148 is free, correcting imap imap claims in-use inode 149 is free, correcting imap imap claims in-use inode 150 is free, correcting imap imap claims in-use inode 151 is free, correcting imap imap claims in-use inode 152 is free, correcting imap imap claims in-use inode 153 is free, correcting imap imap claims in-use inode 154 is free, correcting imap imap claims in-use inode 155 is free, correcting imap imap claims in-use inode 156 is free, correcting imap imap claims in-use inode 157 is free, correcting imap imap claims in-use inode 158 is free, correcting imap imap claims in-use inode 159 is free, correcting imap imap claims in-use inode 160 is free, correcting imap imap claims in-use inode 161 is free, correcting imap imap claims in-use inode 162 is free, correcting imap imap claims in-use inode 163 is free, correcting imap imap claims in-use inode 164 is free, correcting imap imap claims in-use inode 165 is free, correcting imap imap claims in-use inode 166 is free, correcting imap imap claims in-use inode 167 is free, correcting imap imap claims in-use inode 168 is free, correcting imap imap claims in-use inode 169 is free, correcting imap imap claims in-use inode 170 is free, correcting imap imap claims in-use inode 171 is free, correcting imap imap claims in-use inode 172 is free, correcting imap imap claims in-use inode 173 is free, correcting imap imap claims in-use inode 174 is free, correcting imap imap claims in-use inode 175 is free, correcting imap imap claims in-use inode 176 is free, correcting imap imap claims in-use inode 177 is free, correcting imap imap claims in-use inode 178 is free, correcting imap imap claims in-use inode 179 is free, correcting imap imap claims in-use inode 180 is free, correcting imap imap claims in-use inode 181 is free, correcting imap imap claims in-use inode 182 is free, correcting imap imap claims in-use inode 183 is free, correcting imap imap claims in-use inode 184 is free, correcting imap imap claims in-use inode 185 is free, correcting imap imap claims in-use inode 186 is free, correcting imap imap claims in-use inode 187 is free, correcting imap imap claims in-use inode 188 is free, correcting imap imap claims in-use inode 189 is free, correcting imap imap claims in-use inode 190 is free, correcting imap imap claims in-use inode 191 is free, correcting imap - agno = 1 - agno = 2 - agno = 3 data fork in ino 12583049 claims free block 786501 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... imap claims in-use inode 26209 is free, correcting imap imap claims in-use inode 26210 is free, correcting imap imap claims in-use inode 26211 is free, correcting imap imap claims in-use inode 26212 is free, correcting imap imap claims in-use inode 26213 is free, correcting imap imap claims in-use inode 26214 is free, correcting imap [ Snipped a _LOT_ of similar lines referring to different inodes ] imap claims in-use inode 656542 is free, correcting imap imap claims in-use inode 656543 is free, correcting imap avl_insert: Warning! duplicate range [0xa1d20,0xa1d60) fatal error -- xfs_repair: duplicate inode range Any idea what could have caused this? I don't think it's a hardware problem as all other partitions (mixed ext2 and XFS) are still working fine and this problem appeared _exactly_ after i switched to a SMP system. For now i switched to another HDD and FS (ext2/ext3). Is there still hope to get my data back? (No i don't have a backup, but already learned my lesson ;-( ) If you need more info's just let me know! Bye, Stefan -- The things that interest people most are usually none of their business. From owner-linux-xfs@oss.sgi.com Mon Nov 5 15:57:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5NvhU26566 for linux-xfs-outgoing; Mon, 5 Nov 2001 15:57:43 -0800 Received: from mailboy.pgs.com (mailboy.hstn.tensor.pgs.com [157.147.25.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5Nvc026543 for ; Mon, 5 Nov 2001 15:57:38 -0800 Received: from hap.hstn.tensor.pgs.com ([157.147.136.17]) by mailboy.pgs.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08378; Mon, 5 Nov 2001 17:57:35 -0600 (CST) Received: from idoru.hstn.tensor.pgs.com (idoru.hstn.tensor.pgs.com [157.147.92.80]) by hap.hstn.tensor.pgs.com (8.9.3/8.9.3) with ESMTP id RAA10800; Mon, 5 Nov 2001 17:56:51 -0600 (CST) Subject: Re: XFS use in production environment From: Derek Richardson To: Anuradha Ratnaweera Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011105094600.A14482@bee.lk> References: <200111021421.fA2ELTh08913@oss.sgi.com> <3BE2AE5C.1F307A46@sgi.com> <20011105094600.A14482@bee.lk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 05 Nov 2001 17:56:41 -0600 Message-Id: <1005004602.28557.258.camel@idoru.hstn.tensor.pgs.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Anuradha, Thanks for the info. Regards, Derek R. On Sun, 2001-11-04 at 21:46, Anuradha Ratnaweera wrote: > Derek Richardson wrote: > > > > Hello, I'm a new subscribee, was wondering if anyone knows of any statistics > > regarding XFS filesystem use in a serious production environment, or has > > personal experience ... > > I have 3 machines running XFS + latest stable linux 2.4 kernel running on serious > production environments without problems. > > Anuradha > > -- > > Debian GNU/Linux (kernel 2.4.13) > > Living your life is a task so difficult, it has never been attempted before. > -- Junior Linux Geek 713-817-1197 (cell) 713-781-4000 x2267 (office) "Linux users, fanatical. No way... HEY! Get that MCSE up on the altar, Tux must be appeased!" From owner-linux-xfs@oss.sgi.com Mon Nov 5 23:22:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA67MOb06945 for linux-xfs-outgoing; Mon, 5 Nov 2001 23:22:24 -0800 Received: from posta2.elte.hu (posta2.elte.hu [157.181.151.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA67MK006917 for ; Mon, 5 Nov 2001 23:22:21 -0800 Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by posta2.elte.hu (Postfix) with ESMTP id DFF3048010; Tue, 6 Nov 2001 08:22:11 +0100 (CET) Received: by chiara.elte.hu (Postfix, from userid 17806) id D9CD51FCE; Tue, 6 Nov 2001 08:22:10 +0100 (CET) Date: Tue, 6 Nov 2001 09:20:08 +0100 (CET) From: Ingo Molnar Reply-To: To: Tux mailing list Cc: XFS Mailing list Subject: Re: XFS+Tux = patch trouble 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, 5 Nov 2001, Roy Sigurd Karlsbakk wrote: > Does anyone know how to merge the XFS and Tux patches? it would be nice if SGI folks pushed harder for XFS's integration into the mainstream kernel. That would 'automatically' merge TUX (and any other, potentially not yet merged piece of kernel code) to XFS as well. (because i merge against the -ac tree and the -linus tree. [right now there is no TUX merge against the Linus tree until the Andrea/Linus VM is merged into -ac.]) Ingo From owner-linux-xfs@oss.sgi.com Mon Nov 5 23:44:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA67i5P07353 for linux-xfs-outgoing; Mon, 5 Nov 2001 23:44:05 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA67i0007331 for ; Mon, 5 Nov 2001 23:44:00 -0800 Received: (qmail 25699 invoked from network); 6 Nov 2001 07:43:57 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 6 Nov 2001 07:43:57 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 2A273300095; Tue, 6 Nov 2001 18:43:47 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id A29A096; Tue, 6 Nov 2001 18:43:47 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: mingo@elte.hu Cc: Tux mailing list , XFS Mailing list Subject: Re: XFS+Tux = patch trouble In-reply-to: Your message of "Tue, 06 Nov 2001 09:20:08 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Nov 2001 18:43:41 +1100 Message-ID: <18795.1005032621@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 6 Nov 2001 09:20:08 +0100 (CET), Ingo Molnar wrote: >it would be nice if SGI folks pushed harder for XFS's integration into the >mainstream kernel. We have been trying hard since at least 2.4.5. I split the big XFS patch into digestible chunks, separating the core XFS code from the add on stuff like kdb, lvm, dmapi, quota. We have been sending mail to Linus about the core XFS patches since June 5, 2001. Response - total silence. Not even "I don't like it", we get no response at all. From owner-linux-xfs@oss.sgi.com Tue Nov 6 00:54:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA68sYs09376 for linux-xfs-outgoing; Tue, 6 Nov 2001 00:54:34 -0800 Received: from posta2.elte.hu (posta2.elte.hu [157.181.151.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA68sS009347 for ; Tue, 6 Nov 2001 00:54:28 -0800 Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by posta2.elte.hu (Postfix) with ESMTP id 0A7D548010; Tue, 6 Nov 2001 09:54:18 +0100 (CET) Received: by chiara.elte.hu (Postfix, from userid 17806) id 6886D1FCE; Tue, 6 Nov 2001 09:54:16 +0100 (CET) Date: Tue, 6 Nov 2001 10:52:13 +0100 (CET) From: Ingo Molnar Reply-To: To: Keith Owens Cc: Tux mailing list , XFS Mailing list Subject: Re: XFS+Tux = patch trouble In-Reply-To: <18795.1005032621@ocs3.intra.ocs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 6 Nov 2001, Keith Owens wrote: > On Tue, 6 Nov 2001 09:20:08 +0100 (CET), > Ingo Molnar wrote: > >it would be nice if SGI folks pushed harder for XFS's integration into the > >mainstream kernel. > > We have been trying hard since at least 2.4.5. I split the big XFS > patch into digestible chunks, separating the core XFS code from the > add on stuff like kdb, lvm, dmapi, quota. We have been sending mail > to Linus about the core XFS patches since June 5, 2001. Response - > total silence. Not even "I don't like it", we get no response at all. i dont think Linus is the first step needed. XFS is pretty intrusive in the VFS area, so i guess you should first sort out the necessery VFS modifications with Al Viro? And then go step by step forward. I mean, we are in a stable kernel branch and this is a pretty big patch even just counting the core changes. Ingo From owner-linux-xfs@oss.sgi.com Tue Nov 6 02:49:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6AnYf12394 for linux-xfs-outgoing; Tue, 6 Nov 2001 02:49:34 -0800 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 fA6AnU012372 for ; Tue, 6 Nov 2001 02:49:31 -0800 Received: from pclab.cc.kuleuven.ac.be (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 ESMTP id LAA200022 for ; Tue, 6 Nov 2001 11:49:27 +0100 Message-Id: <5.1.0.14.2.20011106104743.00a475f0@pb429905.kuleuven.be> X-Sender: pb429905@pb429905.kuleuven.be X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 06 Nov 2001 11:49:17 +0100 To: linux-xfs@oss.sgi.com From: werner maes Subject: re: Test RH 7.2 installer available Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I've tried the redhat 7.2 installer and I only have a little problem with kickstart installations. When I start a kickstart installation I still get one screen (XFS) where I need to select "Next". After this, the kickstart installation commences. I also changed the syslinux.cfg on the boot disk. Besides this issue everything seems to work fine. Kind regards, Werner Maes From owner-linux-xfs@oss.sgi.com Tue Nov 6 06:38:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6Ec0D19326 for linux-xfs-outgoing; Tue, 6 Nov 2001 06:38:00 -0800 Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6Ebu019304 for ; Tue, 6 Nov 2001 06:37:57 -0800 Received: from chemraeker1 (chemraeker1.Chem.LSA.UMich.Edu [141.211.69.17]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with SMTP id JAA27170 for ; Tue, 6 Nov 2001 09:37:55 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Todd Raeker To: linux-xfs@oss.sgi.com Subject: Re: encounter a 4 GB file size limit Date: Tue, 6 Nov 2001 09:37:33 -0500 X-Mailer: KMail [version 1.2] References: <01102909435902.11332@chemraeker1> <3BDD8E31.9C817A5@umbi.umd.edu> In-Reply-To: <3BDD8E31.9C817A5@umbi.umd.edu> MIME-Version: 1.0 Message-Id: <01110609373300.01912@chemraeker1> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk O.K. everyone. It appears I do not know what I am doing with respect to enabling large files in my fortran code. I am using g77 and just writting into an unformatted file. I use -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE as command line options. There must also be an option in the open statement that sets up the correct file characteristics but I cannot find it anywhere. I see the way to do it using gcc but not g77. Any suggestions? Thanks Todd. -- Todd Raeker Department of Chemistry University of Michigan (734) 647-2867 Phone (734) 615-6950 FAX From owner-linux-xfs@oss.sgi.com Tue Nov 6 06:44:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6Ei4L19521 for linux-xfs-outgoing; Tue, 6 Nov 2001 06:44:04 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6Ehx019498 for ; Tue, 6 Nov 2001 06:44:00 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fA6EhsK25973 for ; Tue, 6 Nov 2001 06:43:54 -0800 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 IAA3513288; Tue, 6 Nov 2001 08:42:38 -0600 (CST) Received: from jen.americas.sgi.com (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 IAA56339; Tue, 6 Nov 2001 08:42:38 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA6EbqD15337; Tue, 6 Nov 2001 08:37:52 -0600 Subject: Re: encounter a 4 GB file size limit From: Steve Lord To: Todd Raeker Cc: linux-xfs@oss.sgi.com In-Reply-To: <01110609373300.01912@chemraeker1> References: <01102909435902.11332@chemraeker1> <3BDD8E31.9C817A5@umbi.umd.edu> <01110609373300.01912@chemraeker1> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/0.16.100+cvs.2001.11.02.21.57 (Preview Release) Date: 06 Nov 2001 08:37:52 -0600 Message-Id: <1005057472.15278.3.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fA6Ei0019499 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From the man page of the open system call: O_LARGEFILE On 32-bit systems that support the Large Files Sys­ tem, allow files whose sizes cannot be represented in 31 bits to be opened. I am not sure how you get this down to the open call with fortran, but you can use the strace command to see it going into the kernel: open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3 Steve On Tue, 2001-11-06 at 08:37, Todd Raeker wrote: > O.K. everyone. > > It appears I do not know what I am doing with respect to enabling large files > in my fortran code. I am using g77 and just writting into an unformatted > file. I use -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE as > command line options. There must also be an option in the open statement > that sets up the correct file characteristics but I cannot find it anywhere. > I see the way to do it using gcc but not g77. Any suggestions? > > Thanks > > Todd. > > -- > Todd Raeker > Department of Chemistry > University of Michigan > (734) 647-2867 Phone > (734) 615-6950 FAX -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Nov 6 07:03:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6F3Xk20944 for linux-xfs-outgoing; Tue, 6 Nov 2001 07:03:33 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6F3E020918 for ; Tue, 6 Nov 2001 07:03:14 -0800 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 HAA05473 for ; Tue, 6 Nov 2001 07:03:12 -0800 (PST) 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 JAA3499567; Tue, 6 Nov 2001 09:01:54 -0600 (CST) Received: from jen.americas.sgi.com (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 JAA92331; Tue, 6 Nov 2001 09:01:54 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA6Ev8d15438; Tue, 6 Nov 2001 08:57:08 -0600 Subject: Re: Damaged XFS partition after moving to SMP From: Steve Lord To: Stefan Frank Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011105225039.A599@asterix.gallien.de> References: <20011105225039.A599@asterix.gallien.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.100+cvs.2001.11.02.21.57 (Preview Release) Date: 06 Nov 2001 08:57:08 -0600 Message-Id: <1005058628.15251.15.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sorry, but your disk would appear to be in very bad shape after this, those bad magic number values actually appear to be copies of the xfs super block. There appears to have been some random splattering of data onto the disk. Do you have any syslog messages from before the system went down? Also, what type of partition was this? Were you using md/lvm, what was the hardware involved. Also, which compiler did you use? Steve p.s. 2.4.10 is supposedly not the best kernel to be running, 2.4.13 is out on the ftp site, and 2.4.14 should arrive there today. On Mon, 2001-11-05 at 15:50, Stefan Frank wrote: > Hi, > > a few days ago i retired my old P166 Mhz machine and moved to a new > 2x866 PIII box. In the beginning i used the same kernel (UP !) as before > (2.4.10 + XFS patch (i BELIEVE the 10/03 dated one, but i also have the > 09/25). Later on while i was working on my 2nd machine reading news, > suddenly GNUS got stuck. When i went back to the new SMP machine > i realised that XFS had unmounted the /var partition. On the console > was a message like "kernel: access beyound end of device" and the > notification of XFS that it closed down the /var partition. > Note that there was no indication of a Kernel oops. > > When i rebooted, this partition could'nt be mounted. The error message > is: XFS: mounting filesystem sd(8,6) > XFS: failed to read root inode > > Running xfs_check yields in : > > bad magic # 0x58465342 in btbno block 0/0 > bad magic # 0x58465342 in btcnt block 0/0 > bad magic # 0x58465342 in inobt block 0/0 > block 3/69 expected type unknown got free2 > > Also xfs_repair is not able to fix the problem. > See it's log below : > > Phase 1 - find and verify superblock... > sb root inode value 18446744073709551615 inconsistent with calculated value 13835049534067048576 > resetting superblock root inode pointer to 18446744069414584448 > sb realtime bitmap inode 18446744073709551615 inconsistent with calculated value 13835049534067048577 > resetting superblock realtime bitmap ino pointer to 18446744069414584449 > sb realtime summary inode 18446744073709551615 inconsistent with calculated value 13835049534067048578 > resetting superblock realtime summary ino pointer to 18446744069414584450 > Phase 2 - using internal log > - zero log... > - scan filesystem freespace and inode maps... > bad agbno 0 for btbno root, agno 0 > bad agbno 0 for btbcnt root, agno 0 > bad agbno 0 for inobt root, agno 0 > root inode chunk not found > Phase 3 - for each AG... > - scan and clear agi unlinked lists... > - process known inodes and perform inode discovery... > - agno = 0 > imap claims in-use inode 131 is free, correcting imap > imap claims in-use inode 132 is free, correcting imap > imap claims in-use inode 133 is free, correcting imap > imap claims in-use inode 134 is free, correcting imap > imap claims in-use inode 135 is free, correcting imap > imap claims in-use inode 136 is free, correcting imap > imap claims in-use inode 137 is free, correcting imap > imap claims in-use inode 138 is free, correcting imap > imap claims in-use inode 139 is free, correcting imap > imap claims in-use inode 140 is free, correcting imap > imap claims in-use inode 141 is free, correcting imap > imap claims in-use inode 142 is free, correcting imap > imap claims in-use inode 143 is free, correcting imap > imap claims in-use inode 144 is free, correcting imap > imap claims in-use inode 145 is free, correcting imap > imap claims in-use inode 146 is free, correcting imap > imap claims in-use inode 147 is free, correcting imap > imap claims in-use inode 148 is free, correcting imap > imap claims in-use inode 149 is free, correcting imap > imap claims in-use inode 150 is free, correcting imap > imap claims in-use inode 151 is free, correcting imap > imap claims in-use inode 152 is free, correcting imap > imap claims in-use inode 153 is free, correcting imap > imap claims in-use inode 154 is free, correcting imap > imap claims in-use inode 155 is free, correcting imap > imap claims in-use inode 156 is free, correcting imap > imap claims in-use inode 157 is free, correcting imap > imap claims in-use inode 158 is free, correcting imap > imap claims in-use inode 159 is free, correcting imap > imap claims in-use inode 160 is free, correcting imap > imap claims in-use inode 161 is free, correcting imap > imap claims in-use inode 162 is free, correcting imap > imap claims in-use inode 163 is free, correcting imap > imap claims in-use inode 164 is free, correcting imap > imap claims in-use inode 165 is free, correcting imap > imap claims in-use inode 166 is free, correcting imap > imap claims in-use inode 167 is free, correcting imap > imap claims in-use inode 168 is free, correcting imap > imap claims in-use inode 169 is free, correcting imap > imap claims in-use inode 170 is free, correcting imap > imap claims in-use inode 171 is free, correcting imap > imap claims in-use inode 172 is free, correcting imap > imap claims in-use inode 173 is free, correcting imap > imap claims in-use inode 174 is free, correcting imap > imap claims in-use inode 175 is free, correcting imap > imap claims in-use inode 176 is free, correcting imap > imap claims in-use inode 177 is free, correcting imap > imap claims in-use inode 178 is free, correcting imap > imap claims in-use inode 179 is free, correcting imap > imap claims in-use inode 180 is free, correcting imap > imap claims in-use inode 181 is free, correcting imap > imap claims in-use inode 182 is free, correcting imap > imap claims in-use inode 183 is free, correcting imap > imap claims in-use inode 184 is free, correcting imap > imap claims in-use inode 185 is free, correcting imap > imap claims in-use inode 186 is free, correcting imap > imap claims in-use inode 187 is free, correcting imap > imap claims in-use inode 188 is free, correcting imap > imap claims in-use inode 189 is free, correcting imap > imap claims in-use inode 190 is free, correcting imap > imap claims in-use inode 191 is free, correcting imap > - agno = 1 > - agno = 2 > - agno = 3 > data fork in ino 12583049 claims free block 786501 > - agno = 4 > - agno = 5 > - agno = 6 > - agno = 7 > - process newly discovered inodes... > imap claims in-use inode 26209 is free, correcting imap > imap claims in-use inode 26210 is free, correcting imap > imap claims in-use inode 26211 is free, correcting imap > imap claims in-use inode 26212 is free, correcting imap > imap claims in-use inode 26213 is free, correcting imap > imap claims in-use inode 26214 is free, correcting imap > > [ Snipped a _LOT_ of similar lines referring to different inodes ] > > imap claims in-use inode 656542 is free, correcting imap > imap claims in-use inode 656543 is free, correcting imap > avl_insert: Warning! duplicate range [0xa1d20,0xa1d60) > > fatal error -- xfs_repair: duplicate inode range > > > > Any idea what could have caused this? I don't think it's a hardware > problem as all other partitions (mixed ext2 and XFS) are still working > fine and this problem appeared _exactly_ after i switched to a SMP > system. > > For now i switched to another HDD and FS (ext2/ext3). > Is there still hope to get my data back? (No i don't have a backup, > but already learned my lesson ;-( ) > > If you need more info's just let me know! > > Bye, Stefan > > -- > The things that interest people most are usually none of their business. -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Nov 6 07:35:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6FZXB21842 for linux-xfs-outgoing; Tue, 6 Nov 2001 07:35:33 -0800 Received: from secure3.developerschoice.net ([209.69.203.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6FZR021820 for ; Tue, 6 Nov 2001 07:35:27 -0800 Received: from [209.69.206.248] (helo=office3) by secure3.developerschoice.net with smtp (Exim 3.20 #27) id 16188I-0000l6-00 for linux-xfs@oss.sgi.com; Tue, 06 Nov 2001 10:27:22 -0500 Content-Type: text/plain; charset="iso-8859-1" From: Jeff Breitner Reply-To: memptr@gatecom.com To: linux-xfs@oss.sgi.com Subject: Interesting XFS Behavior Date: Tue, 6 Nov 2001 10:36:07 -0500 X-Mailer: KMail [version 1.2] References: <20011105225039.A599@asterix.gallien.de> <1005058628.15251.15.camel@jen.americas.sgi.com> In-Reply-To: <1005058628.15251.15.camel@jen.americas.sgi.com> MIME-Version: 1.0 Message-Id: <01110610360706.01823@office3> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have been goofing around trying to mimic the chattr -/+i features of ext2. I figured out that I can keep directories from being deleted if I copy /dev/null into a hidden file, say .donotdelete and then chmod 000 .donotdelete. This keeps users from killing off the directory as they are greeted with a "permission denied" if they try an rm -r or rmdir. However, what's interesting is that after the user attempts this, the null file ".donotdelete" disappears. Where does it go? And even though it's gone, further attempts at removal are still met with "permission denied". As user root, the file can't be listed nor deleted by name -- it just vanishes although something thinks it is there because only root can kill the directory containing the null file. This is the behavior on my Irix 6.2 box as well (a feather in the cap of consistency). Any ideas what's going on? From owner-linux-xfs@oss.sgi.com Tue Nov 6 07:42:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6Fgkc22766 for linux-xfs-outgoing; Tue, 6 Nov 2001 07:42:46 -0800 Received: from ns.iolinux.co.kr ([211.43.167.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6Fgg022744 for ; Tue, 6 Nov 2001 07:42:42 -0800 Received: from sakura (Sakura@sakura.iolinux.co.kr [211.43.167.56]) by ns.iolinux.co.kr (8.11.0/8.11.0) with SMTP id fA6FenW27671 for ; Wed, 7 Nov 2001 00:40:49 +0900 Message-ID: <006601c166d9$85949c50$38a72bd3@sakura> From: "=?ks_c_5601-1987?B?vcLIvw==?=" To: Subject: Date: Wed, 7 Nov 2001 00:41:37 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 auth 5e579ce7 subscribe linux-xfs \ sakura@iolinux.co.kr From owner-linux-xfs@oss.sgi.com Tue Nov 6 07:43:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6Fhnq22826 for linux-xfs-outgoing; Tue, 6 Nov 2001 07:43:49 -0800 Received: from ns.iolinux.co.kr ([211.43.167.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6Fhk022798 for ; Tue, 6 Nov 2001 07:43:47 -0800 Received: from sakura (Sakura@sakura.iolinux.co.kr [211.43.167.56]) by ns.iolinux.co.kr (8.11.0/8.11.0) with SMTP id fA6FfvW27676 for ; Wed, 7 Nov 2001 00:41:57 +0900 Message-ID: <007201c166d9$adfab670$38a72bd3@sakura> From: "=?ks_c_5601-1987?B?vcLIvw==?=" To: Subject: Date: Wed, 7 Nov 2001 00:42:45 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 auth 5e579ce7 subscribe linux-xfs \ sakura@iolinux.co.kr From owner-linux-xfs@oss.sgi.com Tue Nov 6 08:10:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6GAD324253 for linux-xfs-outgoing; Tue, 6 Nov 2001 08:10:13 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6GAA024231 for ; Tue, 6 Nov 2001 08:10:10 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fA6GA5T11257 for ; Tue, 6 Nov 2001 08:10:05 -0800 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3513176 for ; Tue, 6 Nov 2001 10:08:49 -0600 (CST) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA44240 for ; Tue, 6 Nov 2001 10:08:49 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX) id KAA23650 for linux-xfs@oss.sgi.com; Tue, 6 Nov 2001 10:08:43 -0600 (CST) Date: Tue, 6 Nov 2001 10:08:43 -0600 (CST) From: Dean Roehrich Message-Id: <200111061608.KAA23650@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Fix dmapi invisible I/O Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Nov 6 08:08:33 PST 2001 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:106149a linux/fs/xfs/xfs_dmapi.c - 1.42 - fix the VOP_READ/VOP_WRITE calls that dmapi uses for invisible I/O. From owner-linux-xfs@oss.sgi.com Tue Nov 6 08:16:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6GGSc24485 for linux-xfs-outgoing; Tue, 6 Nov 2001 08:16:28 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6GGO024462 for ; Tue, 6 Nov 2001 08:16:24 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fA6GGJK30754 for ; Tue, 6 Nov 2001 08:16:19 -0800 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 KAA3514963; Tue, 6 Nov 2001 10:15:03 -0600 (CST) 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 KAA01724; Tue, 6 Nov 2001 10:15:02 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id KAA19724; Tue, 6 Nov 2001 10:15:02 -0600 (CST) Message-Id: <200111061615.KAA19724@slobber.americas.sgi.com> To: Takayuki Sasaki cc: linux-xfs@oss.sgi.com Subject: Re: wbee (sample_hsm) dumped core Date: Tue, 06 Nov 2001 10:15:01 -0600 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: Takayuki Sasaki >Hi, > >Thank you for your time, Dean. > >Dean Roehrich wrote: >> >> >Takayuki Sasaki wrote: >> > >> >> migin daemon in sample_hsm started with the patch which I >> >> posted, but if I try to read the migrated file then it >> >> stalled. It was caused by >> >> linux-2.4-xfs/cmd/xfstests/dmapi/src/sample_hsm/wbee which was >> >> dispatched by migin dumped core. >> > >> >In the above situation, I killed the stalled command ( cp ) and >> >migin by pressing Ctrl + c to find out what is wrong. Then, >> >unmount the XFS file system, the following console messages >> >appeared: >> > >> > XFS unmount got error 16 >> > linvfs_put_super: vfsp/0xc2acb38c left dangling! >> > VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice >day I didn't forget about you :) The problem happens because invisible I/O was not invisible, causing DMAPI to deadlock on itself. Then you end up with busy vnodes and a mess. The VOP_READ/VOP_WRITE calls in xfs_dm_rdwr() were not sending the O_INVISIBLE flag. I just checked in a fix, and it should make its way to CVS soon. Dean From owner-linux-xfs@oss.sgi.com Tue Nov 6 08:24:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6GOg224842 for linux-xfs-outgoing; Tue, 6 Nov 2001 08:24:42 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6GOW024812 for ; Tue, 6 Nov 2001 08:24:32 -0800 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 IAA08986 for ; Tue, 6 Nov 2001 08:24:26 -0800 (PST) mail_from (eric@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 KAA3509886 for ; Tue, 6 Nov 2001 10:23:09 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA74689 for ; Tue, 6 Nov 2001 10:23:09 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id fA6GMb305300; Tue, 6 Nov 2001 10:22:37 -0600 Message-Id: <200111061622.fA6GMb305300@stout.americas.sgi.com> Date: Tue, 6 Nov 2001 10:22:37 -0600 From: Eric Sandeen Subject: TAKE - merge up to 2.4.14 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk merge up to 2.4.14 Includes loop.c fix not in original 2.4.14, but discussed and blessed by Linus on LKML. Date: Tue Nov 6 08:21:41 PST 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:106152a linux/include/linux/zlib_fs.h - 1.1 linux/arch/alpha/lib/dec_and_lock.c - 1.1 linux/net/unix/af_unix.c - 1.37 linux/net/netsyms.c - 1.39 linux/net/ipv6/tcp_ipv6.c - 1.31 linux/net/ipv4/tcp_output.c - 1.25 linux/net/ipv4/tcp_ipv4.c - 1.39 linux/net/ipv4/af_inet.c - 1.30 linux/mm/vmscan.c - 1.89 linux/mm/swap.c - 1.19 linux/mm/page_alloc.c - 1.68 linux/mm/mmap.c - 1.44 linux/mm/memory.c - 1.70 linux/mm/filemap.c - 1.98 linux/kernel/ksyms.c - 1.118 linux/include/net/tcp.h - 1.27 linux/include/linux/swap.h - 1.48 linux/include/linux/skbuff.h - 1.22 linux/include/linux/pci.h - 1.51 linux/include/linux/pagemap.h - 1.37 linux/fs/Makefile - 1.40 linux/fs/Config.in - 1.69 linux/drivers/scsi/sg.c - 1.23 linux/drivers/pci/quirks.c - 1.25 linux/drivers/pci/proc.c - 1.20 linux/drivers/pci/pci.c - 1.45 linux/drivers/pci/compat.c - 1.8 linux/drivers/char/serial.c - 1.49 linux/drivers/acorn/scsi/powertec.c - 1.11 linux/drivers/acorn/scsi/eesox.c - 1.10 linux/drivers/acorn/scsi/cumana_2.c - 1.10 linux/arch/sparc64/kernel/ioctl32.c - 1.45 linux/arch/i386/defconfig - 1.80 linux/arch/alpha/lib/Makefile - 1.13 linux/arch/alpha/kernel/traps.c - 1.17 linux/arch/alpha/kernel/alpha_ksyms.c - 1.28 linux/arch/alpha/config.in - 1.35 linux/Makefile - 1.150 linux/MAINTAINERS - 1.81 linux/Documentation/pci.txt - 1.16 linux/Documentation/Configure.help - 1.114 linux/CREDITS - 1.65 linux/arch/i386/kernel/pci-visws.c - 1.6 linux/arch/i386/kernel/pci-pc.c - 1.28 linux/arch/i386/kernel/pci-i386.c - 1.17 linux/drivers/pci/gen-devlist.c - 1.8 linux/drivers/pci/pci.ids - 1.37 linux/drivers/net/arcnet/com90xx.c - 1.8 linux/drivers/net/arcnet/com90io.c - 1.8 linux/drivers/net/arcnet/com20020.c - 1.4 linux/drivers/net/arcnet/com20020-pci.c - 1.9 linux/drivers/net/arcnet/com20020-isa.c - 1.7 linux/drivers/net/arcnet/arcnet.c - 1.11 linux/drivers/net/arcnet/arc-rimi.c - 1.6 linux/drivers/pnp/quirks.c - 1.7 linux/arch/alpha/kernel/pci_iommu.c - 1.16 linux/net/ipv4/netfilter/ipt_LOG.c - 1.8 linux/arch/i386/kernel/pci-irq.c - 1.18 linux/drivers/usb/storage/sddr09.c - 1.11 linux/drivers/zorro/gen-devlist.c - 1.2 linux/net/core/dv.c - 1.5 linux/include/asm-sparc64/xor.h - 1.2 linux/mm/shmem.c - 1.24 linux/drivers/scsi/osst.c - 1.9 linux/arch/sh/kernel/pci-sh7751.c - 1.3 linux/drivers/pcmcia/i82092aa.h - 1.2 linux/net/ipv6/netfilter/ip6t_LOG.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Nov 6 08:29:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6GTbs24992 for linux-xfs-outgoing; Tue, 6 Nov 2001 08:29:37 -0800 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 fA6GRg024961 for ; Tue, 6 Nov 2001 08:27:43 -0800 Received: from heppcl.ph.qmw.ac.uk ([138.37.50.187]) by zeta.qmw.ac.uk with esmtp (Exim 3.32 #1) id 16194d-0002KL-00 for linux-xfs@oss.sgi.com; Tue, 06 Nov 2001 16:27:39 +0000 Received: from heppct.ph.qmw.ac.uk (heppct.ph.qmw.ac.uk [138.37.50.246]) by heppcl.ph.qmw.ac.uk (8.11.6/8.9.3) with ESMTP id fA6GRdh28296 for ; Tue, 6 Nov 2001 16:27:39 GMT Received: from localhost (pd@localhost) by heppct.ph.qmw.ac.uk (8.11.6/8.9.3) with ESMTP id fA6GRdn12702 for ; Tue, 6 Nov 2001 16:27:39 GMT X-Authentication-Warning: heppct.ph.qmw.ac.uk: pd owned process doing -bs Date: Tue, 6 Nov 2001 16:27:39 +0000 (GMT) From: "P.Dixon" To: Subject: 7.2 installer crash In-Reply-To: <200111061608.KAA23650@clink.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Just tried the XFS 7.2 installer (text mode) and it crashed while installing tetex. Note that the Red Hat 7.2 CDROMS have been used previously to install Red Hat 7.2 on other systems using ext3. System: 60GB IBM Hard Disk Dual 1GHz PIII (Tyan SMP Motherboard) 512MB RAM Matrox G550 video Here's the anaconda dump file: Traceback (innermost last): File "/usr/bin/anaconda", line 620, in ? intf.run(id, dispatch, configFileData) File "/usr/lib/anaconda/text.py", line 407, in run dispatch.gotoNext() File "/usr/lib/anaconda/dispatch.py", line 144, in gotoNext self.moveStep() File "/usr/lib/anaconda/dispatch.py", line 209, in moveStep rc = apply(func, self.bindArgs(args)) File "/usr/lib/anaconda/packages.py", line 563, in doInstall problems = ts.run(0, ~rpm.RPMPROB_FILTER_DISKSPACE, cb.cb, 0) File "/usr/lib/anaconda/packages.py", line 225, in cb fn = self.method.getFilename(h, self.pkgTimer) File "/usr/lib/anaconda/image.py", line 88, in getFilename isys.umount("/mnt/source") File "/usr/lib/anaconda/isys.py", line 152, in umount rc = _isys.umount(what) SystemError: (16, 'Device or resource busy') Local variables in innermost frame: what: /mnt/source removeDir: 1 Package Group selection status: Base: 1 Printing Support: 1 Classic X Window System: 1 X Window System: 1 Laptop Support: 0 Spelling: 0 GNOME: 1 KDE: 1 Sound and Multimedia Support: 1 Network Support: 1 Dialup Support: 0 Messaging and Web Tools: 1 Graphics and Image Manipulation: 1 Network Server: 0 News Server: 0 NFS File Server: 1 Windows File Server: 1 Anonymous FTP Server: 0 SQL Database Server: 0 Web Server: 0 Router / Firewall: 1 DNS Name Server: 0 Network Managed Workstation: 1 Authoring and Publishing: 1 Emacs: 1 Utilities: 1 Legacy Application Support: 1 Software Development: 1 Kernel Development: 1 Windows Compatibility / Interoperability: 0 Games and Entertainment: 1 Everything Include: 0 Workstation Common: 0 Server: 0 Everything: 0 Individual package selection status: 4Suite: 1, Canna: 0, Canna-devel: 0, Canna-libs: 0, Distutils: 0, ElectricFence: 0, FreeWnn: 0, FreeWnn-common: 0, FreeWnn-devel: 0, FreeWnn-libs: 0, GConf: 1, GConf-devel: 1, Gtk-Perl: 0, Guppi: 0, Guppi-devel: 0, ImageMagick: 1, ImageMagick-c++: 0, ImageMagick-c++-devel: 0, ImageMagick-devel: 0, ImageMagick-perl: 0, LPRng: 1, MAKEDEV: 1, Maelstrom: 1, MagicPoint: 0, Mesa: 1, Mesa-demos: 1, Mesa-devel: 1, MyODBC: 0, MySQL-python: 0, ORBit: 1, ORBit-devel: 1, PyQt: 0, PyQt-devel: 0, PyQt-examples: 0, PyXML: 1, SDL: 1, SDL-devel: 0, SDL_image: 1, SDL_image-devel: 0, SDL_mixer: 1, SDL_mixer-devel: 0, SDL_net: 1, SDL_net-devel: 0, SysVinit: 1, VFlib2: 1, VFlib2-VFjfm: 0, VFlib2-devel: 1, WindowMaker: 0, WindowMaker-libs: 0, Wnn6-SDK: 0, Wnn6-SDK-devel: 0, XFree86: 1, XFree86-100dpi-fonts: 1, XFree86-3DLabs: 0, XFree86-75dpi-fonts: 1, XFree86-8514: 0, XFree86-AGX: 0, XFree86-FBDev: 0, XFree86-ISO8859-15-100dpi-fonts: 1, XFree86-ISO8859-15-75dpi-fonts: 1, XFree86-ISO8859-2-100dpi! -fonts: 0, XFree86-ISO8859-2-75dpi-fonts: 0, XFree86-ISO8859-7: 0, XFree86-ISO8859-7-100dpi-fonts: 0, XFree86-ISO8859-7-75dpi-fonts: 0, XFree86-ISO8859-7-Type1-fonts: 0, XFree86-ISO8859-9-100dpi-fonts: 0, XFree86-ISO8859-9-75dpi-fonts: 0, XFree86-KOI8-R: 0, XFree86-KOI8-R-100dpi-fonts: 0, XFree86-KOI8-R-75dpi-fonts: 0, XFree86-Mach32: 0, XFree86-Mach64: 0, XFree86-Mach8: 0, XFree86-Mono: 0, XFree86-P9000: 0, XFree86-S3: 0, XFree86-S3V: 0, XFree86-SVGA: 0, XFree86-VGA16: 0, XFree86-W32: 0, XFree86-Xnest: 0, XFree86-Xvfb: 0, XFree86-compat-libs: 1, XFree86-compat-modules: 0, XFree86-cyrillic-fonts: 0, XFree86-devel: 1, XFree86-doc: 0, XFree86-jpfonts: 0, XFree86-libs: 1, XFree86-tools: 1, XFree86-twm: 1, XFree86-xdm: 1, XFree86-xf86cfg: 0, XFree86-xfs: 1, Xaw3d: 1, Xaw3d-devel: 1, Xconfigurator: 1, Xdialog: 0, a2ps: 1, abiword: 1, acl: 0, acl-devel: 0, adjtimex: 0, alchemist: 1, alchemist-devel: 0, alien: 0, am-utils: 0, amanda: 0, amanda-client: 0, amanda-devel: 0, amanda-ser! ver: 0, ami: 0, ami-gnome: 0, anaconda: 0, anaconda-runtime: 0, anacron: 1, anonftp: 0, apache: 0, apache-devel: 0, apache-manual: 0, apacheconf: 0, apel: 0, apmd: 1, arpwatch: 1, arts: 1, ash: 1, asp2php: 0, asp2php-gtk: 0, aspell: 1, aspell-ca: 0, aspell-da: 0, aspell-de: 0, aspell-devel: 0, aspell-en-ca: 0, aspell-en-gb: 1, aspell-es: 0, aspell-fr: 0, aspell-it: 0, aspell-nl: 0, aspell-no: 0, aspell-pt: 0, aspell-pt_BR: 0, aspell-sv: 0, at: 1, attr: 0, attr-devel: 0, audiofile: 1, audiofile-devel: 1, aumix: 1, aumix-X11: 0, auth_ldap: 0, authconfig: 1, autoconf: 1, autoconvert: 0, autoconvert-xchat: 0, autofs: 1, automake: 1, autorun: 1, awesfx: 1, balsa: 1, basesystem: 1, bash: 1, bash-doc: 0, bc: 1, bcm5820: 0, bdflush: 1, bg5ps: 0, bind: 0, bind-devel: 0, bind-utils: 1, bindconf: 0, binutils: 1, bison: 1, blas: 0, blas-man: 0, blt: 0, bonobo: 1, bonobo-devel: 1, bootparamd: 0, bug-buddy: 1, busybox: 0, busybox-anaconda: 0, byacc: 1, bzip2: 1, bzip2-devel: 1, bzip2-libs! : 1, cWnn: 0, cWnn-common: 0, cWnn-devel: 0, caching-nameserver: 0, cadaver: 0, cdda2wav: 1, cdecl: 1, cdlabelgen: 1, cdp: 1, cdparanoia: 1, cdparanoia-devel: 0, cdrdao: 0, cdrecord: 1, cdrecord-devel: 1, cervisia: 0, chkconfig: 1, chkfontpath: 1, chromium: 1, cipe: 1, cleanfeed: 0, compat-egcs: 1, compat-egcs-c++: 1, compat-egcs-g77: 1, compat-egcs-objc: 0, compat-glibc: 1, compat-libs: 0, compat-libstdc++: 1, comsat: 0, console-tools: 1, control-center: 1, control-center-devel: 1, cpio: 1, cpp: 1, cproto: 0, cracklib: 1, cracklib-dicts: 1, crontabs: 1, ctags: 1, curl: 1, curl-devel: 1, cvs: 1, cyrus-sasl: 1, cyrus-sasl-devel: 1, cyrus-sasl-gssapi: 0, cyrus-sasl-md5: 1, cyrus-sasl-plain: 1, dateconfig: 1, db1: 1, db1-devel: 1, db2: 1, db2-devel: 0, db3: 1, db3-devel: 1, db3-utils: 1, db31: 0, dbskkd-cdb: 0, ddd: 1, ddskk: 0, dejagnu: 0, desktop-backgrounds: 1, dev: 1, dev86: 1, dhcp: 0, dhcpcd: 1, dia: 1, dialog: 1, diffstat: 1, diffutils: 1, dip: 0, diskcheck: 0, dmalloc: ! 0, dmapi: 0, dmapi-devel: 0, docbook-dtd30-sgml: 1, docbook-dtd31-sgml: 1, docbook-dtd40-sgml: 1, docbook-dtd41-sgml: 1, docbook-dtd41-xml: 0, docbook-dtd412-xml: 0, docbook-style-dsssl: 1, docbook-utils: 1, docbook-utils-pdf: 1, dos2unix: 0, dosfstools: 1, doxygen: 1, doxygen-doxywizard: 0, dump: 1, e2fsprogs: 1, e2fsprogs-devel: 1, ed: 1, ee: 1, eel: 1, eel-devel: 0, efax: 1, eject: 1, elm: 0, emacs: 1, emacs-X11: 1, emacs-el: 0, emacs-leim: 0, emacs-nox: 1, enlightenment: 0, enscript: 0, eruby: 0, esound: 1, esound-devel: 1, ethereal: 0, ethereal-gnome: 0, ethtool: 0, exmh: 1, expat: 1, expat-devel: 1, expect: 0, ext2ed: 0, extace: 1, fam: 1, fam-devel: 1, fbset: 0, fetchmail: 1, fetchmailconf: 0, file: 1, filesystem: 1, fileutils: 1, findutils: 1, finger: 1, finger-server: 1, firewall-config: 1, flex: 1, fnlib: 0, fnlib-devel: 0, foomatic: 1, fortune-mod: 1, freecdb: 0, freeciv: 1, freetype: 1, freetype-devel: 1, freetype-utils: 0, ftp: 1, ftpcopy: 0, fvwm2: 0, fvwm2-ico! ns: 0, g-wrap: 0, g-wrap-devel: 0, gaim: 1, gal: 1, gal-devel: 0, galeon: 1, gated: 0, gawk: 1, gcc: 1, gcc-c++: 1, gcc-chill: 0, gcc-g77: 1, gcc-java: 0, gcc-objc: 1, gcc3: 0, gcc3-c++: 0, gcc3-g77: 0, gcc3-java: 0, gcc3-objc: 0, gd: 1, gd-devel: 1, gd-progs: 0, gdb: 1, gdbm: 1, gdbm-devel: 1, gdk-pixbuf: 1, gdk-pixbuf-devel: 1, gdk-pixbuf-gnome: 1, gdm: 1, gedit: 1, genromfs: 0, gettext: 1, gftp: 1, ggv: 0, ghostscript: 1, ghostscript-fonts: 1, giftrans: 1, gimp: 1, gimp-data-extras: 0, gimp-devel: 1, gimp-perl: 0, gkermit: 0, gkrellm: 0, glade: 1, glib: 1, glib-devel: 1, glib10: 1, glibc: 1, glibc-common: 1, glibc-devel: 1, glibc-profile: 0, glms: 0, gmc: 1, gmp: 1, gmp-devel: 1, gnome-applets: 1, gnome-audio: 1, gnome-audio-extra: 1, gnome-core: 1, gnome-core-devel: 1, gnome-games: 1, gnome-games-devel: 1, gnome-kerberos: 0, gnome-libs: 1, gnome-libs-devel: 1, gnome-linuxconf: 0, gnome-lokkit: 1, gnome-media: 1, gnome-pim: 1, gnome-pim-devel: 1, gnome-print: 1, gnome-pri! nt-devel: 0, gnome-user-docs: 1, gnome-utils: 1, gnome-vfs: 1, gnome-vfs-devel: 0, gnome-vfs-extras: 1, gnomeicu: 0, gnorpm: 1, gnucash: 0, gnuchess: 1, gnumeric: 1, gnumeric-devel: 0, gnupg: 1, gnuplot: 0, gperf: 0, gphoto: 1, gpm: 1, gpm-devel: 1, gq: 1, gqview: 1, grep: 1, grip: 0, groff: 1, groff-gxditview: 0, groff-perl: 1, grub: 1, gsl: 0, gsm: 1, gsm-devel: 1, gtk+: 1, gtk+-devel: 1, gtk+10: 1, gtk-doc: 0, gtk-engines: 1, gtkglarea: 0, gtkhtml: 1, gtkhtml-devel: 0, gtoaster: 0, gtop: 1, guile: 1, guile-devel: 0, gv: 0, gzip: 1, h2ps: 0, hanterm-xf: 0, hdparm: 1, hexedit: 0, hotplug: 1, hotplug-gtk: 0, htdig: 1, htdig-web: 0, htmlview: 1, hwbrowser: 1, ical: 1, im: 0, imap: 0, imap-devel: 0, imlib: 1, imlib-cfgeditor: 1, imlib-devel: 1, indent: 1, indexhtml: 1, inews: 0, info: 1, initscripts: 1, inn: 0, inn-devel: 0, ipchains: 1, iproute: 1, iptables: 1, iptables-ipv6: 1, iptraf: 0, iputils: 1, ipxutils: 0, irb: 0, ircii: 0, irda-utils: 0, isapnptools: 0, iscsi: 0, isd! n4k-utils: 1, isdn4k-utils-vboxgetty: 0, isicom: 0, itcl: 0, jadetex: 1, jcode.pl: 0, jed: 0, jed-common: 0, jed-xjed: 0, jikes: 0, jisksp14: 0, jisksp16-1990: 0, joe: 0, joystick: 1, jpilot: 0, junkbuster: 0, kWnn: 0, kWnn-devel: 0, kaffe: 0, kakasi: 0, kakasi-devel: 0, kakasi-dict: 0, kappa20: 0, kbdconfig: 1, kcc: 0, kdbg: 1, kde-i18n-British: 1, kde-i18n-Bulgarian: 0, kde-i18n-Chinese: 0, kde-i18n-Chinese-Big5: 0, kde-i18n-Czech: 0, kde-i18n-Danish: 0, kde-i18n-Dutch: 0, kde-i18n-Estonian: 0, kde-i18n-Finnish: 0, kde-i18n-French: 0, kde-i18n-German: 0, kde-i18n-Hebrew: 0, kde-i18n-Hungarian: 0, kde-i18n-Icelandic: 0, kde-i18n-Italian: 0, kde-i18n-Japanese: 0, kde-i18n-Korean: 0, kde-i18n-Lithuanian: 0, kde-i18n-Norwegian: 0, kde-i18n-Norwegian-Nynorsk: 0, kde-i18n-Polish: 0, kde-i18n-Portuguese: 0, kde-i18n-Romanian: 0, kde-i18n-Russian: 0, kde-i18n-Slovak: 0, kde-i18n-Slovenian: 0, kde-i18n-Spanish: 0, kde-i18n-Swedish: 0, kde-i18n-Turkish: 0, kde-i18n-Ukrainian: 0, kde! 1-compat: 1, kde1-compat-devel: 0, kdeaddons-kate: 1, kdeaddons-kicker: 1, kdeaddons-knewsticker: 0, kdeaddons-konqueror: 1, kdeaddons-noatun: 1, kdeadmin: 1, kdeartwork: 1, kdeartwork-locolor: 1, kdebase: 1, kdebase-devel: 0, kdebindings: 1, kdebindings-devel: 0, kdebindings-kmozilla: 1, kdebindings-perl: 0, kdebindings-python: 0, kdegames: 1, kdegraphics: 1, kdegraphics-devel: 0, kdelibs: 1, kdelibs-devel: 1, kdelibs-sound: 1, kdelibs-sound-devel: 1, kdemultimedia: 1, kdemultimedia-devel: 0, kdenetwork: 1, kdenetwork-ppp: 1, kdepim: 1, kdepim-cellphone: 0, kdepim-devel: 0, kdepim-pilot: 0, kdesdk: 1, kdesdk-devel: 1, kdetoys: 1, kdeutils: 1, kdevelop: 1, kdoc: 1, kernel: 1, kernel-BOOT: 0, kernel-doc: 0, kernel-enterprise: 0, kernel-headers: 1, kernel-pcmcia-cs: 0, kernel-smp: 1, kernel-source: 1, kinput2-canna-wnn6: 0, knm_new: 0, koffice: 1, koffice-devel: 0, kon2: 0, kon2-fonts: 0, kpppload: 1, krb5-devel: 1, krb5-libs: 1, krb5-server: 0, krb5-workstation: 0, krbafs: 1,! krbafs-devel: 1, krbafs-utils: 0, ksconfig: 1, ksymoops: 1, kterm: 0, kudzu: 1, kudzu-devel: 1, lam: 0, lapack: 0, lapack-man: 0, lclint: 1, less: 1, lesstif: 1, lesstif-devel: 1, lftp: 0, lha: 0, libPropList: 0, libao: 1, libao-devel: 1, libcap: 1, libcap-devel: 0, libelf: 0, libesmtp: 1, libesmtp-devel: 0, libgal7: 1, libgcc: 0, libgcj: 0, libgcj-devel: 0, libgcj3: 0, libgcj3-devel: 0, libghttp: 1, libghttp-devel: 1, libglade: 1, libglade-devel: 1, libgnomeprint15: 1, libgtop: 1, libgtop-devel: 1, libgtop-examples: 0, libjpeg: 1, libjpeg-devel: 1, libjpeg6a: 1, libmng: 1, libmng-devel: 1, libmng-static: 0, libodbc++: 0, libodbc++-devel: 0, libodbc++-qt: 0, libogg: 1, libogg-devel: 1, libole2: 1, libole2-devel: 0, libpcap: 1, libpng: 1, libpng-devel: 1, librep: 1, librep-devel: 1, librsvg: 1, librsvg-devel: 0, libsigc++: 0, libsigc++-devel: 0, libstdc++: 1, libstdc++-devel: 1, libstdc++3: 0, libstdc++3-devel: 0, libtabe: 0, libtabe-devel: 0, libtermcap: 1, libtermcap-devel! : 1, libtiff: 1, libtiff-devel: 1, libtool: 1, libtool-libs: 1, libtool-libs13: 0, libungif: 1, libungif-devel: 1, libungif-progs: 0, libunicode: 1, libunicode-devel: 1, libuser: 1, libuser-devel: 0, libvorbis: 1, libvorbis-devel: 1, libxml: 1, libxml-devel: 1, libxml10: 1, libxml2: 1, libxml2-devel: 0, libxslt: 1, libxslt-devel: 0, licq: 1, licq-gnome: 1, licq-kde: 1, licq-qt: 0, licq-text: 0, lilo: 1, links: 1, linuxconf: 0, linuxconf-devel: 0, lm_sensors: 1, lm_sensors-devel: 0, locale_config: 1, lockdev: 1, lockdev-devel: 1, logrotate: 1, logwatch: 1, lokkit: 1, losetup: 1, lout: 0, lout-doc: 0, lrzsz: 1, lslk: 0, lsof: 1, ltrace: 1, lv: 1, lvm-tools: 1, lynx: 0, m2crypto: 0, m4: 1, macutils: 0, magicdev: 1, mailcap: 1, mailman: 0, mailx: 1, make: 1, man: 1, man-pages: 1, man-pages-cs: 0, man-pages-da: 0, man-pages-de: 0, man-pages-es: 0, man-pages-fr: 0, man-pages-it: 0, man-pages-ja: 0, man-pages-ko: 0, man-pages-pl: 0, man-pages-ru: 0, mars-nwe: 0, mawk: 0, mc: 1, mcs! erv: 0, memprof: 1, metamail: 1, mew: 0, mgetty: 0, mgetty-sendfax: 0, mgetty-viewfax: 0, mgetty-voice: 0, micq: 1, mikmod: 1, mingetty: 1, miniChinput: 0, minicom: 1, mkbootdisk: 1, mkinitrd: 1, mkisofs: 1, mkkickstart: 0, mktemp: 1, mkxauth: 1, mm: 1, mm-devel: 1, mod_auth_any: 0, mod_auth_mysql: 0, mod_auth_pgsql: 0, mod_bandwidth: 0, mod_dav: 0, mod_perl: 0, mod_put: 0, mod_python: 0, mod_roaming: 0, mod_ssl: 0, mod_throttle: 0, modutils: 1, mount: 1, mouseconfig: 1, mozilla: 1, mozilla-chat: 0, mozilla-devel: 0, mozilla-mail: 1, mozilla-psm: 1, mpage: 1, mpg321: 1, mrtg: 0, mt-st: 1, mtools: 0, mtr: 1, mtr-gtk: 1, mtx: 0, mutt: 1, mx: 0, mysql: 0, mysql-devel: 0, mysql-server: 0, mysqlclient9: 0, nasm: 0, nasm-doc: 0, nasm-rdoff: 0, nautilus: 1, nautilus-devel: 0, nautilus-mozilla: 1, nc: 0, ncftp: 1, ncompress: 1, ncpfs: 0, ncurses: 1, ncurses-devel: 1, ncurses4: 1, nedit: 0, net-tools: 1, netconfig: 1, netpbm: 1, netpbm-devel: 1, netpbm-progs: 1, netscape-common: 1, n! etscape-communicator: 1, netscape-navigator: 0, newt: 1, newt-devel: 1, nfs-utils: 1, nhpf: 0, njamd: 1, nkf: 1, nmap: 1, nmap-frontend: 1, nmh: 1, nscd: 1, nss_db: 0, nss_db-compat: 0, nss_ldap: 1, ntp: 1, ntsysv: 1, nut: 0, nut-cgi: 0, nut-client: 0, nvi-m17n: 0, nvi-m17n-canna: 0, nvi-m17n-nocanna: 0, oaf: 1, oaf-devel: 1, octave: 0, open: 0, openjade: 1, openldap: 1, openldap-clients: 1, openldap-devel: 1, openldap-servers: 0, openldap12: 1, openssh: 1, openssh-askpass: 1, openssh-askpass-gnome: 1, openssh-clients: 1, openssh-server: 1, openssl: 1, openssl-devel: 1, openssl-perl: 0, openssl095a: 1, openssl096: 1, p2c: 0, pam: 1, pam-devel: 1, pam_krb5: 1, pam_smb: 0, pan: 1, parted: 1, parted-devel: 0, passwd: 1, patch: 1, pax: 1, pccts: 0, pciutils: 1, pciutils-devel: 1, pcre: 1, pcre-devel: 1, pdksh: 0, perl: 1, perl-DBD-MySQL: 0, perl-DBD-Pg: 0, perl-DBI: 0, perl-DateManip: 1, perl-Digest-MD5: 1, perl-File-MMagic: 0, perl-HTML-Parser: 1, perl-HTML-Tagset: 1, perl-MIME! -Base64: 1, perl-NKF: 0, perl-Parse-Yapp: 1, perl-SGMLSpm: 1, perl-Storable: 1, perl-Text-Kakasi: 0, perl-URI: 1, perl-XML-Dumper: 1, perl-XML-Encoding: 1, perl-XML-Grove: 1, perl-XML-Parser: 1, perl-XML-Twig: 1, perl-libnet: 1, perl-libwww-perl: 1, perl-libxml-enno: 1, perl-libxml-perl: 1, php: 0, php-devel: 0, php-imap: 0, php-ldap: 0, php-manual: 0, php-mysql: 0, php-odbc: 0, php-pgsql: 0, pidentd: 1, pilot-link: 1, pilot-link-devel: 1, pine: 1, pinfo: 1, pkgconfig: 0, playmidi: 1, playmidi-X11: 0, plugger: 0, pmake: 1, pnm2ppa: 1, popt: 1, portmap: 1, postgresql: 0, postgresql-contrib: 0, postgresql-devel: 0, postgresql-docs: 0, postgresql-jdbc: 0, postgresql-libs: 0, postgresql-odbc: 0, postgresql-perl: 0, postgresql-python: 0, postgresql-server: 0, postgresql-tcl: 0, postgresql-tk: 0, ppp: 1, printconf: 1, printconf-gui: 1, procinfo: 1, procmail: 1, procps: 1, procps-X11: 0, psacct: 0, psgml: 1, psmisc: 1, pspell: 1, pspell-devel: 0, psutils: 1, pump: 0, pump-devel: 0,! pvm: 0, pvm-gui: 0, pwdb: 1, pxe: 0, pychecker: 0, pygnome: 1, pygnome-applet: 0, pygnome-capplet: 0, pygnome-devel: 0, pygnome-gtkhtml: 0, pygnome-libglade: 1, pygtk: 1, pygtk-devel: 0, pygtk-glarea: 0, pygtk-libglade: 1, python: 1, python-devel: 1, python-docs: 0, python-tools: 0, python-xmlrpc: 1, python2: 0, python2-devel: 0, qt: 1, qt-Xt: 0, qt-designer: 1, qt-devel: 1, qt-static: 0, qt1x: 1, qt1x-GL: 1, qt1x-devel: 0, quanta: 0, quota: 1, radvd: 1, raidtools: 1, rarpd: 1, rcs: 1, rdate: 1, rdist: 1, readline: 1, readline-devel: 1, readline2.2.1: 1, readline41: 0, redhat-config-network: 1, redhat-config-users: 1, redhat-logos: 1, redhat-release: 1, reiserfs-utils: 1, rep-gtk: 1, rep-gtk-gnome: 1, rep-gtk-libglade: 1, rhmask: 0, rhn_register: 1, rhn_register-gnome: 1, rmt: 1, rootfiles: 1, routed: 0, rp-pppoe: 1, rp3: 1, rpm: 1, rpm-build: 1, rpm-devel: 1, rpm-perl: 0, rpm-python: 1, rpm2html: 0, rpmdb-redhat: 0, rpmfind: 0, rpmlint: 0, rsh: 1, rsh-server: 1, rsync: 1, ! ruby: 0, ruby-devel: 0, ruby-docs: 0, ruby-libs: 0, ruby-tcltk: 0, rusers: 1, rusers-server: 1, rwall: 0, rwall-server: 1, rwho: 1, rxvt: 0, samba: 1, samba-client: 1, samba-common: 1, samba-swat: 0, sane-backends: 1, sane-backends-devel: 1, sane-frontends: 1, sash: 0, sawfish: 1, sawfish-themer: 0, screen: 1, scrollkeeper: 1, sed: 1, semi: 0, semi-xemacs: 0, sendmail: 1, sendmail-cf: 1, sendmail-doc: 0, serviceconf: 1, setserial: 1, setup: 1, setuptool: 1, sgml-common: 1, sgml-tools: 1, sh-utils: 1, shadow-utils: 1, shapecfg: 1, sharutils: 1, sip: 0, sip-devel: 0, skkdic: 0, skkinput: 0, slang: 1, slang-devel: 1, sliplogin: 0, slocate: 1, slrn: 0, slrn-pull: 0, smpeg: 1, smpeg-devel: 0, smpeg-xmms: 0, snavigator: 0, sndconfig: 1, sox: 1, sox-devel: 0, specspo: 0, squid: 0, stat: 1, statserial: 1, strace: 1, stunnel: 1, sudo: 1, swig: 1, switchdesk: 1, switchdesk-gnome: 1, switchdesk-kde: 1, sylpheed: 0, symlinks: 1, sysctlconfig: 0, sysklogd: 1, syslinux: 1, sysreport: 0, s! ysstat: 1, tWnn: 0, taipeifonts: 0, talk: 1, talk-server: 1, tamago: 1, taper: 0, tar: 1, tcl: 1, tcllib: 0, tclx: 0, tcp_wrappers: 1, tcpdump: 1, tcsh: 1, telnet: 1, telnet-server: 1, termcap: 1, tetex: 1, tetex-afm: 1, tetex-doc: 0, tetex-dvilj: 1, tetex-dvips: 1, tetex-fonts: 1, tetex-latex: 1, tetex-xdvi: 1, texinfo: 1, textutils: 1, tftp: 0, tftp-server: 0, time: 1, timeconfig: 1, timidity++: 1, tix: 1, tk: 1, tkinter: 1, tmake: 0, tmpwatch: 1, traceroute: 1, transfig: 0, tree: 1, tripwire: 1, ttcp: 0, ttfm: 0, ttfonts: 1, ttfonts-ja: 1, ttfonts-ko: 0, ttfonts-zh_CN: 0, ttfonts-zh_TW: 0, ttfprint: 0, tux: 0, tuxracer: 1, ucd-snmp: 1, ucd-snmp-devel: 0, ucd-snmp-utils: 1, umb-scheme: 1, unarj: 0, units: 1, unix2dos: 0, unixODBC: 0, unixODBC-devel: 0, unixODBC-kde: 0, unzip: 1, up2date: 1, up2date-gnome: 1, urw-fonts: 1, usbview: 1, usermode: 1, utempter: 1, util-linux: 1, uucp: 0, vim-X11: 0, vim-common: 1, vim-enhanced: 0, vim-minimal: 1, vixie-cron: 1, vlock: 0, vnc: 1! , vnc-doc: 0, vnc-server: 1, vorbis: 1, w3c-libwww: 1, w3c-libwww-apps: 0, w3c-libwww-devel: 0, w3m: 0, w3m-el: 0, watanabe-vf: 1, webalizer: 0, wget: 1, which: 1, whois: 1, wine: 0, wine-devel: 0, wireless-tools: 0, wl: 0, wl-xemacs: 0, wmakerconf: 0, words: 1, wu-ftpd: 0, wvdial: 1, x3270: 0, x3270-tcl: 0, x3270-text: 0, x3270-x11: 0, xalf: 0, xawtv: 1, xbill: 1, xbl: 0, xboard: 1, xcdroast: 0, xchat: 1, xcin: 0, xcpustate: 0, xdaliclock: 0, xdelta: 1, xdelta-devel: 0, xemacs: 0, xemacs-el: 0, xemacs-info: 0, xfig: 0, xfsdump: 0, xfsprogs: 1, xfsprogs-devel: 0, xinetd: 1, xinitrc: 1, xisdnload: 1, xloadimage: 1, xlockmore: 0, xmailbox: 0, xml-i18n-tools: 0, xmms: 1, xmms-devel: 0, xmms-gnome: 1, xmms-skins: 0, xmorph: 0, xosview: 0, xpdf: 1, xpilot: 1, xrn: 0, xsane: 1, xsane-gimp: 0, xscreensaver: 1, xsnow: 1, xsri: 1, xsysinfo: 0, xtoolwait: 0, xtraceroute: 0, yp-tools: 1, ypbind: 1, ypserv: 1, ytalk: 0, zebra: 0, zip: 1, zlib: 1, zlib-devel: 1, zsh: 0, Dispatcher instance, containing members: skipSteps: {'reconfigwelcome': 1, 'addswap': 1, 'indivpackage': 1, 'upgrademigratefs': 1, 'findpackages': 1, 'reconfigkeyboard': 1, 'makebootdisk': 1, 'network': 1, 'dependencies': 1, 'autopartitionexecute': 1, 'upgrademount': 1, 'autopartition': 1, 'confirmupgrade': 1, 'upgradeswapsuggestion': 1, 'upgrademigfind': 1, 'findinstall': 1, 'findrootparts': 1, 'reconfigcomplete': 1, 'upgradecontinue': 1} dir: 1 id: InstallData instance, containing members: configFileData: {'Splashscreen': pixmaps/first.png, 'WelcomeScreen': pixmaps/splash.png, 'TitleBar': pixmaps/anaconda_header.png, 'Title': Red Hat Linux Beta} upgradeSwapInfo: None langSupport: Language instance, containing members: langList: None allSupportedLangs: None supported: [English (Great Britain), English (USA)] langNicks: None default: English (Great Britain) langInfoByName: {'Spanish (Colombia)': ('es_CO', 'iso01', 'lat0-sun16'), 'Spanish (Argentina)': ('es_AR', 'iso01', 'lat0-sun16'), 'Italian (Italy)': ('it_IT@euro', 'iso15', 'lat0-sun16'), 'Arabic (Lebanon)': ('ar_LB', 'iso06', 'LatArCyrHeb-16'), 'Spanish (Guatemala)': ('es_GT', 'iso01', 'lat0-sun16'), 'Malay (Malaysia)': ('ms_MY', 'iso01', 'lat0-sun16'), 'Arabic (Libyan Arab Jamahiriya)': ('ar_LY', 'iso06', 'LatArCyrHeb-16'), 'Arabic (Oman)': ('ar_OM', 'iso06', 'LatArCyrHeb-16'), 'Arabic (Iraq)': ('ar_IQ', 'iso06', 'LatArCyrHeb-16'), 'Arabic (Kuwait)': ('ar_KW', 'iso06', 'LatArCyrHeb-16'), 'English (South Africa)': ('en_ZA', 'iso01', 'lat0-sun16'), 'French (Switzerland)': ('fr_CH', 'iso01', 'lat0-sun16'), 'Arabic (Bahrein)': ('ar_BH', 'iso06', 'LatArCyrHeb-16'), 'Croatian': ('hr_HR', 'iso02', 'lat2-sun16'), 'French (France)': ('fr_FR@euro', 'iso15', 'lat0-sun16'), 'Greenlandic (Greenland)': ('kl_GL', 'iso01', 'lat0-sun16'), 'Korean (Republic of Korea)': ('ko_KR.eucKR', '! iso01', 'lat0-sun16'), 'Ukrainian': ('uk_UA', 'koi8-u', 'cyr-sun16'), 'Spanish (Mexico)': ('es_MX', 'iso01', 'lat0-sun16'), 'Greek': ('el_GR', 'iso07', 'iso07.16'), 'Spanish (El Salvador)': ('es_SV', 'iso01', 'lat0-sun16'), 'Spanish (Peru)': ('es_PE', 'iso01', 'lat0-sun16'), 'Spanish (Honduras)': ('es_HN', 'iso01', 'lat0-sun16'), 'Spanish (Costa Rica)': ('es_CR', 'iso01', 'lat0-sun16'), 'English (Denmark)': ('en_DK', 'iso01', 'lat0-sun16'), 'Dutch (Netherlands)': ('nl_NL@euro', 'iso15', 'lat0-sun16'), 'Serbian (Yugoslavia)': ('sr_YU@cyrillic', 'iso05', 'cyr-sun16'), 'Bosnian (Bosnia and Herzegowina)': ('bs_BA', 'iso02', 'lat2-sun16'), 'Russian (Ukraine)': ('ru_UA', 'koi8-u', 'cyr-sun16'), 'Portuguese (Portugal)': ('pt_PT@euro', 'iso15', 'lat0-sun16'), 'Afrikaans (South Africa)': ('af_ZA', 'iso01', 'lat0-sun16'), 'Norwegian': ('no_NO', 'iso01', 'lat0-sun16'), 'Arabic (Morocco)': ('ar_MA', 'iso06', 'LatArCyrHeb-16'), 'English (Philippines)': ('en_PH', 'iso01', 'lat0-sun16'), '! Arabic (Algeria)': ('ar_DZ', 'iso06', 'LatArCyrHeb-16'), 'Indonesian': ('id_ID', 'iso01', 'lat0-sun16'), 'Danish': ('da_DK', 'iso01', 'lat0-sun16'), 'Chinese (Taiwan R.O.C.)': ('zh_TW.Big5', 'iso01', 'lat0-sun16'), 'Faroese (Faroe Islands)': ('fo_FO', 'iso01', 'lat0-sun16'), 'Galician (Spain)': ('gl_ES@euro', 'iso15', 'lat0-sun16'), 'English (New Zealand)': ('en_NZ', 'iso01', 'lat0-sun16'), 'Spanish (Bolivia)': ('es_BO', 'iso01', 'lat0-sun16'), 'Cornish (Britain)': ('kw_GB', 'iso01', 'lat0-sun16'), 'Arabic (United Arab Emirates)': ('ar_AE', 'iso06', 'LatArCyrHeb-16'), 'Spanish (Nicaragua)': ('es_NI', 'iso01', 'lat0-sun16'), 'German (Austria)': ('de_AT@euro', 'iso15', 'lat0-sun16'), 'Romanian': ('ro_RO', 'iso02', 'lat2-sun16'), 'Spanish (Paraguay)': ('es_PY', 'iso01', 'lat0-sun16'), 'Hebrew (Israel)': ('he_IL', 'iso08', 'LatArCyrHeb-16'), 'German (Luxemburg)': ('de_LU@euro', 'iso15', 'lat0-sun16'), 'Spanish (USA)': ('es_US', 'iso01', 'lat0-sun16'), 'Portuguese (Brasil)': ('pt! _BR', 'iso01', 'lat0-sun16'), 'Spanish (Equador)': ('es_EC', 'iso01', 'lat0-sun16'), 'Polish': ('pl_PL', 'iso02', 'lat2-sun16'), 'Slovak': ('sk_SK', 'iso02', 'lat2-sun16'), 'Macedonian': ('mk_MK', 'iso05', 'cyr-sun16'), 'Spanish (Spain)': ('es_ES@euro', 'iso15', 'lat0-sun16'), 'Spanish (Chile)': ('es_CL', 'iso01', 'lat0-sun16'), 'Arabic (Syrian Arab Republic)': ('ar_SY', 'iso06', 'LatArCyrHeb-16'), 'Czech': ('cs_CZ', 'iso02', 'lat2-sun16'), 'Irish': ('ga_IE@euro', 'iso15', 'lat0-sun16'), 'Arabic (Jordan)': ('ar_JO', 'iso06', 'LatArCyrHeb-16'), 'Italian (Switzerland)': ('it_CH', 'iso01', 'lat0-sun16'), 'German (Belgium)': ('de_BE@euro', 'iso15', 'lat0-sun16'), 'Albanian': ('sq_AL', 'iso01', 'lat0-sun16'), 'Occitan (France)': ('oc_FR', 'iso01', 'lat0-sun16'), 'Finnish': ('fi_FI@euro', 'iso15', 'lat0-sun16'), 'Swedish (Sweden)': ('sv_SE', 'iso01', 'lat0-sun16'), 'English (Singapore)': ('en_SG', 'iso01', 'lat0-sun16'), 'Dutch (Belgium)': ('nl_BE@euro', 'iso15', 'lat0-sun16'), 'S! panish (Panama)': ('es_PA', 'iso01', 'lat0-sun16'), 'Spanish (Venezuela)': ('es_VE', 'iso01', 'lat0-sun16'), 'English (Great Britain)': ('en_GB', 'iso01', 'lat0-sun16'), 'Russian': ('ru_RU.koi8r', 'koi8-u', 'cyr-sun16'), 'Norwegian, Nynorsk (Norway)': ('nn_NO', 'iso01', 'lat0-sun16'), 'English (Zimbabwe)': ('en_ZW', 'iso01', 'lat0-sun16'), 'English (USA)': ('en_US', 'iso01', 'lat0-sun16'), 'Tagalog (Philipines)': ('tl_PH', 'iso01', 'lat0-sun16'), 'Breton (France)': ('br_FR', 'iso01', 'lat0-sun16'), 'Chinese (P.R. of China)': ('zh_CN.GB2312', 'iso01', 'lat0-sun16'), 'Arabic (Yemen)': ('ar_YE', 'iso06', 'LatArCyrHeb-16'), 'Basque (Spain)': ('eu_ES@euro', 'iso15', 'lat0-sun16'), 'Arabic (Qatar)': ('ar_QA', 'iso06', 'LatArCyrHeb-16'), 'Arabic (Egypt)': ('ar_EG', 'iso06', 'LatArCyrHeb-16'), 'French (Belgium)': ('fr_BE@euro', 'iso15', 'lat0-sun16'), 'English (Ireland)': ('en_IE@euro', 'iso15', 'lat0-sun16'), 'Hungarian': ('hu_HU', 'iso02', 'lat2-sun16'), 'Arabic (Tunisia)': ('ar_T! N', 'iso06', 'LatArCyrHeb-16'), 'French (Luxemburg)': ('fr_LU@euro', 'iso15', 'lat0-sun16'), 'Japanese': ('ja_JP.eucJP', 'iso01', 'lat0-sun16'), 'Uzbek (Uzbekistan)': ('uz_UZ', 'iso01', 'lat0-sun16'), 'Swedish (Finland)': ('sv_FI@euro', 'iso15', 'lat0-sun16'), 'Arabic (Saudi Arabia)': ('ar_SA', 'iso06', 'LatArCyrHeb-16'), 'Spanish (Dominican Republic)': ('es_DO', 'iso01', 'lat0-sun16'), 'French (Canada)': ('fr_CA', 'iso01', 'lat0-sun16'), 'English (Canada)': ('en_CA', 'iso01', 'lat0-sun16'), 'German (Germany)': ('de_DE@euro', 'iso15', 'lat0-sun16'), 'Slovenian (Slovenia)': ('sl_SI', 'iso02', 'lat2-sun16'), 'Spanish (Uruguay)': ('es_UY', 'iso01', 'lat0-sun16'), 'German (Switzerland)': ('de_CH', 'iso01', 'lat0-sun16'), 'English (Hong Kong)': ('en_HK', 'iso01', 'lat0-sun16'), 'English (Australia)': ('en_AU', 'iso01', 'lat0-sun16'), 'Catalan (Spain)': ('ca_ES@euro', 'iso15', 'lat0-sun16'), 'Spanish (Puerto Rico)': ('es_PR', 'iso01', 'lat0-sun16'), 'Turkish': ('tr_TR', 'iso09', '! lat5-sun16'), 'Estonian': ('et_EE', 'iso01', 'lat0-sun16'), 'Arabic (Sudan)': ('ar_SD', 'iso06', 'LatArCyrHeb-16'), 'Icelandic': ('is_IS', 'iso01', 'lat0-sun16'), 'English (Botswana)': ('en_BW', 'iso01', 'lat0-sun16'), 'Manx Gaelic (Britain)': ('gv_GB', 'iso01', 'lat0-sun16')} info: {'SYSFONT': lat0-sun16, 'SUPPORTED': en_GB:en:en_US:en, 'SYSFONTACM': iso01, 'LANG': en_GB} rootPassword: None diskset: DiskSet instance, containing members: disks: {'hda': } tmpData: {'Splashscreen': pixmaps/first.png, 'WelcomeScreen': pixmaps/splash.png, 'TitleBar': pixmaps/anaconda_header.png, 'Title': Red Hat Linux Beta} instLanguage: InstallTimeLanguage instance, containing members: kbd: {'Italian': it, 'Korean': us, 'Russian': ru, 'English': us, 'Norwegian': no-latin1, 'Swedish': se-latin1, 'French': fr-latin1, 'Japanese': jp106, 'Slovenian': slovene, 'Czech': cz-lat2, 'Ukrainian': ua, 'Spanish': es, 'German': de-latin1-nodeadkeys, 'Danish': us, 'Icelandic': is-latin1} font: {'Italian': lat0-sun16, 'Korean': None, 'Russian': cyr-sun16, 'English': default8x16, 'Norwegian': lat0-sun16, 'Swedish': lat0-sun16, 'French': lat0-sun16, 'Japanese': Kon, 'Slovenian': lat2-sun16, 'Czech': lat2-sun16, 'Ukrainian': cyr-sun16, 'Spanish': lat0-sun16, 'German': lat0-16, 'Danish': lat0-sun16, 'Icelandic': lat0-sun16} langNicks: {'Italian': it_IT, 'Korean': ko_KR.eucKR, 'Russian': ru_RU.koi8r, 'English': en_US, 'Norwegian': no_NO, 'Swedish': sv_SE, 'French': fr_FR, 'Japanese': ja_JP.eucJP, 'Slovenian': sl_SI, 'Czech': cs_CZ, 'Ukrainian': uk_UA, 'Spanish': es_ES, 'German': de_DE, 'Danish': da_DK, 'Icelandic': is_IS} langList: [Czech, Danish, English, French, German, Icelandic, Italian, Japanese, Korean, Norwegian, Russian, Slovenian, Spanish, Swedish, Ukrainian] tz: {'Italian': Europe/Rome, 'Korean': Asia/Seoul, 'Russian': Europe/Moscow, 'English': America/New_York, 'Norwegian': Europe/Oslo, 'Swedish': Europe/Stockholm, 'French': Europe/Paris, 'Japanese': Asia/Tokyo, 'Slovenian': Europe/Ljubljana, 'Czech': Europe/Prague, 'Ukrainian': Europe/Kiev, 'Spanish': Europe/Madrid, 'German': Europe/Berlin, 'Danish': Europe/Copenhagen, 'Icelandic': Atlantic/Reykjavik} tempDefault: map: {'Italian': iso15, 'Korean': None, 'Russian': koi8-r, 'English': iso01, 'Norwegian': iso15, 'Swedish': iso15, 'French': iso15, 'Japanese': None, 'Slovenian': iso02, 'Czech': iso02, 'Ukrainian': koi8-u, 'Spanish': iso15, 'German': iso09, 'Danish': iso15, 'Icelandic': iso15} current: en_US instProgress: InstallProgressWindow instance, containing members: size: Label instance, containing members: w: timeRemainingW: Label instance, containing members: w: numTotal: 667 total: Scale instance, containing members: w: drawn: 1 sizeRemainingW: Label instance, containing members: w: numRemainingW: Label instance, containing members: w: numComplete: 485 sizeTotal: 1861508 timeTotalW: Label instance, containing members: w: timeCompleteW: Label instance, containing members: w: summ: Textbox instance, containing members: w: sizeComplete: 1308256 numCompleteW: Label instance, containing members: w: screen: SnackScreen instance, containing members: height: 25 width: 80 helpCb: g: GridForm instance, containing members: childList: [Grid instance, containing members: gridmembers: [Label instance, containing members: w: , Label instance, containing members: w: , Label instance, containing members: w: , Already dumped ] g: , Grid instance, containing members: gridmembers: [Label instance, containing members: w: , Already dumped ] g: , Scale instance, containing members: w: , Grid instance, containing members: gridmembers: [Label instance, containing members: w: , Label instance, containing members: w: , Label instance, containing members: w: , Label instance, containing members: w: , Label instance, containing members: w: , Label instance, containing members: w: , Label instance, containing members: w: , Already dumped , Label instance, containing members: w: , Already dumped , Label instance, containing members: w: , Already dumped , Label instance, containing members: w: , Already dumped , Already dumped , Already dumped ] g: , Already dumped ] g: screen: Already dumped title: Package Installation form: Form instance, containing members: filemap: {} w: helpArg: None trans: {165774880: Already dumped , 165775912: Already dumped , 165540912: Already dumped , 165776824: Already dumped , 165777096: Already dumped , 165310936: Already dumped , 165309040: Already dumped , 165224096: Already dumped , 165541088: Already dumped , 165774256: Already dumped , 165781288: Already dumped , 165308760: Already dumped , 165310688: Already dumped , 165311840: Already dumped , 161727256: Already dumped , 165776152: Already dumped , 165776360: Already dumped , 165781008: Already dumped , 165308568: Already dumped , 165308328: Already dumped , 165776584: Already dumped , 165311560: Already dumped , 165774576: Already dumped , 165777344: Already dumped } gridmembers: [Already dumped , Already dumped , Already dumped , Already dumped , Already dumped ] form_created: 1 timeStarted: -1 s: Already dumped name: Already dumped sizeCompleteW: Already dumped desktop: Desktop instance, containing members: runlevel: 5 info: {'DESKTOP': GNOME} videocard: primary: 0 vidCards: [] Primary Video Card Info: device: None descr : Matrox Millennium G450 server: XFree86 cardManf: Matrox Graphics Inc. vidRam: 32768 carddata: {'NAME': 'Matrox Millennium G450', 'DRIVER': 'mga', 'NOCLOCKPROBE': '', 'CHIPSET': 'mgag450', 'VENDOR': 'Matrox Graphics Inc.'} devID: Matrox Millennium G450 fbmodes: None fbbpp: None floppyDevice: fd0 xconfig: XF86Config instance, containing members: keyLayout: us manualModes: {} mouse: FULLNAME="Microsoft - IntelliMouse (PS/2)" MOUSETYPE="imps2" XEMU3="no" XMOUSETYPE="IMPS/2" monlist: {} keyRules: xfree86 keyModel: pc101 device: None monids: {} files: # The location of the RGB database. Note, this is the name of the # file minus the extension (like ".txt" or ".db"). There is normally # no need to change the default. RgbPath "/usr/X11R6/lib/X11/rgb" # Multiple FontPath entries are allowed (they are concatenated together) # By default, Red Hat 6.0 and later now use a font server independent of # the X server to render fonts. FontPath "unix/:7100" keyVariant: videocard: device: None descr : Matrox Millennium G450 server: XFree86 cardManf: Matrox Graphics Inc. vidRam: 32768 carddata: {'NAME': 'Matrox Millennium G450', 'DRIVER': 'mga', 'NOCLOCKPROBE': '', 'CHIPSET': 'mgag450', 'VENDOR': 'Matrox Graphics Inc.'} devID: Matrox Millennium G450 fbmodes: None fbbpp: None keyOptions: modes: {'16': ['640x480', '800x600', '1024x768', '1152x864', '1280x1024', '1400x1050', '1600x1200'], '32': ['640x480', '800x600', '1024x768', '1152x864', '1280x1024', '1400x1050', '1600x1200'], '8': ['640x480', '800x600', '1024x768', '1152x864', '1280x1024', '1400x1050', '1600x1200']} res: 800x600 monitor: monEisa: None monName: None monID: Unprobed Monitor fbmonSect: monHoriz: 31.5-48.5 monVert: 50-70 skipx: 0 fallbackModes: {'16': ['800x600']} skip: 0 fbDepth: 16 monitor: Already dumped upgrade: Boolean instance, containing members: val: 0 instClass: InstallClass instance, containing members: partitions: Partitions instance, containing members: deletes: [] reinitializeDisks: 0 autoPartitionRequests: [mountpoint: / type: xfs uniqueID:None size: 700M requestSize: 700M grow: 1 max: None start: None end: None partnum: None drive: None primary: None format: 1, options: None device: None, currentDrive: None raidlevel: None raidspares: None raidmembers: [] , mountpoint: /boot type: xfs uniqueID:None size: 50M requestSize: 50M grow: 0 max: None start: None end: None partnum: None drive: None primary: None format: 1, options: None device: None, currentDrive: None raidlevel: None raidspares: None raidmembers: [] , mountpoint: None type: swap uniqueID:None size: 512M requestSize: 512M grow: 1 max: 1024 start: None end: None partnum: None drive: None primary: None format: 1, options: None device: None, currentDrive: None raidlevel: None raidspares: None raidmembers: [] ] nextUniqueID: 7 zeroMbr: 0 autoClearPartType: 1 requests: [mountpoint: / type: xfs uniqueID:3 size: 4000.53076172M requestSize: 4000.53076172M grow: 0 max: None start: 63L end: 8193149L partnum: None drive: hda primary: None format: 1, options: None device: hda1, currentDrive: None raidlevel: None raidspares: None raidmembers: [] , mountpoint: /export/data63 type: xfs uniqueID:6 size: 50611.0253906M requestSize: 50611.0253906M grow: 0 max: None start: 16450560L end: 120101939L partnum: None drive: hda primary: None format: 1, options: None device: hda4, currentDrive: None raidlevel: None raidspares: None raidmembers: [] , mountpoint: /export/scratch type: xfs uniqueID:4 size: 3004.34326172M requestSize: 3004.34326172M grow: 0 max: None start: 8193150L end: 14346044L partnum: None drive: hda primary: None format: 1, options: None device: hda2, currentDrive: None raidlevel: None raidspares: None raidmembers: [] , mountpoint: None type: swap uniqueID:5 size: 1027.59521484M requestSize: 1027.59521484M grow: 0 max: None start: 14346045L end: 16450559L partnum: None drive: hda primary: None format: 1, options: None device: hda3, currentDrive: None raidlevel: None raidspares: None raidmembers: [] ] autoClearPartDrives: [] useFdisk: 1 useAutopartitioning: 0 extraModules: [] mouse: Already dumped bootloader: x86BootloaderInfo instance, containing members: useGrubVal: 0 forceLBA32: 0 password: None images: BootImages instance, containing members: images: {'hda1': ('linux', 'Red Hat Linux', 'xfs')} default: hda1 pure: None device: hda configfile: /etc/lilo.conf above1024: 0 kernelLocation: /boot/ args: KernelArguments instance, containing members: args: defaultDevice: None useLinear: 1 timezone: Timezone instance, containing members: dst: 0 tz: Europe/London arc: 0 utcOffset: 0 utc: 1 keyboard: Keyboard instance, containing members: beenset: 1 layout: None model: None type: PC info: {'KEYBOARDTYPE': pc, 'KEYTABLE': uk} accounts: None dependencies: [] comps: None upgradeRoot: None auth: Authentication instance, containing members: useNIS: 1 nisServer: useLdap: 0 krb5Kdc: useHesiod: 0 ldapServer: hesiodRhs: useLdapauth: 0 enableCache: 0 krb5Admin: ldapBasedn: useSamba: 0 krb5Realm: useMD5: 0 ldapTLS: 0 sambaWorkgroup: nisDomain: qmwhep sambaServer: useShadow: 0 nisuseBroadcast: 1 useKrb5: 0 hesiodLhs: upgradeDeps: firewall: Firewall instance, containing members: ports: [] trustdevs: [] dhcp: 0 policy: 1 ssh: 0 custom: 1 telnet: 0 smtp: 0 enabled: 1 portlist: http: 0 ftp: 0 dbpath: None network: Network instance, containing members: netdevices: {} gateway: secondaryNS: hostname: localhost.localdomain primaryNS: domains: [] isConfigured: 0 readData: 0 ternaryNS: fsset: FileSystemSet instance, containing members: migratedfs: 1 mountcount: 6 entries: [FileSystemSetEntry instance, containing members: origfsystem: ForeignFileSystem instance, containing members: partedFileSystemType: None formattable: 0 extraFormatArgs: [] maxSize: 2097152 defaultOptions: defaults linuxnativefs: 0 deviceArguments: {} migratetofs: None name: foreign checked: 0 partedPartitionFlags: [] supported: -1 mountcount: 1 options: defaults order: 1 mountpoint: / device: PartitionDevice instance, containing members: label: None isSetup: 0 fsoptions: {} device: hda1 label: None fsck: 1 fsystem: xfsFileSystem instance, containing members: partedFileSystemType: formattable: 1 extraFormatArgs: [] maxSize: 2097152 defaultOptions: defaults linuxnativefs: 1 deviceArguments: {} migratetofs: None name: xfs checked: 1 partedPartitionFlags: [] supported: 1 migrate: 0 format: 1 badblocks: 0 , FileSystemSetEntry instance, containing members: origfsystem: None mountcount: 1 options: gid=5,mode=620 order: 0 mountpoint: /dev/pts device: Device instance, containing members: label: None isSetup: 0 fsoptions: {} device: none label: None fsck: 0 fsystem: DevptsFileSystem instance, containing members: partedFileSystemType: None formattable: 0 extraFormatArgs: [] maxSize: 2097152 defaultOptions: gid=5,mode=620 linuxnativefs: 0 deviceArguments: {} migratetofs: None name: devpts checked: 0 partedPartitionFlags: [] supported: 0 migrate: 0 format: 0 badblocks: 0 , FileSystemSetEntry instance, containing members: origfsystem: Already dumped mountcount: 1 options: defaults order: 2 mountpoint: /export/data63 device: PartitionDevice instance, containing members: label: None isSetup: 0 fsoptions: {} device: hda4 label: None fsck: 1 fsystem: Already dumped migrate: 0 format: 1 badblocks: 0 , FileSystemSetEntry instance, containing members: origfsystem: Already dumped mountcount: 1 options: defaults order: 2 mountpoint: /export/scratch device: PartitionDevice instance, containing members: label: None isSetup: 0 fsoptions: {} device: hda2 label: None fsck: 1 fsystem: Already dumped migrate: 0 format: 1 badblocks: 0 , FileSystemSetEntry instance, containing members: origfsystem: None mountcount: 1 options: defaults order: 0 mountpoint: /proc device: Device instance, containing members: label: None isSetup: 0 fsoptions: {} device: none label: None fsck: 0 fsystem: ProcFileSystem instance, containing members: partedFileSystemType: None formattable: 0 extraFormatArgs: [] maxSize: 2097152 defaultOptions: defaults linuxnativefs: 0 deviceArguments: {} migratetofs: None name: proc checked: 0 partedPartitionFlags: [] supported: 0 migrate: 0 format: 0 badblocks: 0 , FileSystemSetEntry instance, containing members: origfsystem: Already dumped mountcount: 1 options: defaults order: 0 mountpoint: swap device: PartitionDevice instance, containing members: label: None isSetup: 0 fsoptions: {} device: hda3 label: None fsck: 0 fsystem: swapFileSystem instance, containing members: partedFileSystemType: formattable: 1 extraFormatArgs: [] maxSize: 2048 defaultOptions: defaults linuxnativefs: 1 deviceArguments: {} migratetofs: None name: swap checked: 0 partedPartitionFlags: [] supported: 1 migrate: 0 format: 1 badblocks: 0 ] progressWindow: waitWindow: messageWindow: hdList: None firstStep: 0 method: CdromInstallMethod instance, containing members: currentDisc: 2 tree: /mnt/source device: hdc progressWindow: loopbackFile: /mnt/sysimage/export/data63/rhinstall-stage2.img messageWindow: instPath: /mnt/sysimage flags: Flags instance, containing members: flags: {'autostep': 0, 'expert': 0, 'setupFilesystems': 1, 'serial': 0, 'reconfig': 0, 'test': 0} intf: InstallInterface instance, containing members: showingHelpOnHelp: 0 instLanguage: Already dumped welcomeText: Red Hat Linux (C) 2001 Red Hat, Inc. langSearchPath: [en_US, en, C] screen: Already dumped step: 48 dispatch: Already dumped /tmp/syslog: <4>Linux version 2.4.9-13SGI_XFS_PR1BOOT (root@gibble) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Fri Nov 2 21:45:37 CST 2001 <6>BIOS-provided physical RAM map: <4> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) <4> BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) <4> BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) <4> BIOS-e820: 0000000000100000 - 000000001fff0000 (usable) <4> BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS) <4> BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data) <4> BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved) <4>found SMP MP-table at 000f5610 <4>hm, page 000f5000 reserved twice. <4>hm, page 000f6000 reserved twice. <4>hm, page 000f1000 reserved twice. <4>hm, page 000f2000 reserved twice. <4>On node 0 totalpages: 131056 <4>zone(0): 4096 pages. <4>zone(1): 126960 pages. <4>zone(2): 0 pages. <4>Intel MultiProcessor Specification v1.4 <4> Virtual Wire compatibility mode. <4>OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000 <4>Processor #0 Pentium(tm) Pro APIC version 17 <4>Processor #1 Pentium(tm) Pro APIC version 17 <4>I/O APIC #2 Version 17 at 0xFEC00000. <4>Processors: 2 <4>Kernel command line: initrd=initrd.img lang= text devfs=nomount ramdisk_size=8192 BOOT_IMAGE=vmlinuz <6>Initializing CPU#0 <4>Detected 999.680 MHz processor. <4>Console: colour VGA+ 80x25 <4>Calibrating delay loop... 1992.29 BogoMIPS <4>Memory: 509356k/524224k available (1153k kernel code, 12416k reserved, 90k data, 108k init, 0k highmem) <4>Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes) <4>Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) <4>Mount-cache hash table entries: 8192 (order: 4, 65536 bytes) <4>Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) <4>Page-cache hash table entries: 131072 (order: 8, 1048576 bytes) <7>CPU: Before vendor init, caps: 0387fbff 00000000 00000000, vendor = 0 <6>CPU: L1 I cache: 16K, L1 D cache: 16K <6>CPU: L2 cache: 256K <6>Intel machine check architecture supported. <6>Intel machine check reporting enabled on CPU#0. <7>CPU: After vendor init, caps: 0387fbff 00000000 00000000 00000000 <5>CPU serial number disabled. <7>CPU: After generic, caps: 0383fbff 00000000 00000000 00000000 <7>CPU: Common caps: 0383fbff 00000000 00000000 00000000 <4>CPU: Intel Pentium III (Coppermine) stepping 0a <6>Enabling fast FPU save and restore... done. <6>Enabling unmasked SIMD FPU exception support... done. <6>Checking 'hlt' instruction... OK. <6>Checking for popad bug... OK. <4>POSIX conformance testing by UNIFIX <4>mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) <4>mtrr: detected mtrr type: Intel <4>PCI: PCI BIOS revision 2.10 entry at 0xfb4a0, last bus=1 <4>PCI: Using configuration type 1 <4>PCI: Probing PCI hardware <3>Unknown bridge resource 0: assuming transparent <6>PCI: Using IRQ router VIA [1106/0686] at 00:07.0 <6>PCI: Enabling Via external APIC routing <6>Linux NET4.0 for Linux 2.4 <6>Based upon Swansea University Computer Society NET3.039 <4>Starting kswapd v1.8 <4>pty: 256 Unix98 ptys configured <6>Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled <6>ttyS00 at 0x03f8 (irq = 4) is a 16550A <6>ttyS01 at 0x02f8 (irq = 3) is a 16550A <4>block: queued sectors max/low 338210kB/207138kB, 1024 slots per queue <4>RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize <6>Uniform Multi-Platform E-IDE driver Revision: 6.31 <6>ide: Assuming 33MHz PCI bus speed for PIO modes; override with idebus=xx <4>VP_IDE: IDE controller on PCI bus 00 dev 39 <4>VP_IDE: chipset revision 6 <4>VP_IDE: not 100% native mode: will probe irqs later <6>ide: Assuming 33MHz PCI bus speed for PIO modes; override with idebus=xx <6>VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1 <4> ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:pio <4> ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:pio <4>hda: IC35L060AVER07-0, ATA DISK drive <4>hdc: SAMSUNG CD-ROM SC-152L, ATAPI CD/DVD-ROM drive <4>ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 <4>ide1 at 0x170-0x177,0x376 on irq 15 <6>hda: 120103200 sectors (61493 MB) w/1916KiB Cache, CHS=7476/255/63, UDMA(33) <4>hdc: ATAPI 52X CD-ROM DVD-RAM drive, 128kB Cache, DMA <6>Uniform CD-ROM driver Revision: 3.12 <4>ide-floppy driver 0.97.sv <6>Partition check: <6> hda: unknown partition table <6>Floppy drive(s): fd0 is 1.44M <6>FDC 0 is a post-1991 82077 <6>loop: loaded (max 8 devices) <4>ide-floppy driver 0.97.sv <6>md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 <6>md: Autodetecting RAID arrays. <4>md: autorun ... <4>md: ... autorun DONE. <6>NET4: Linux TCP/IP 1.0 for NET4.0 <6>IP Protocols: ICMP, UDP, TCP <4>IP: routing cache hash table of 4096 buckets, 32Kbytes <4>TCP: Hash tables configured (established 32768 bind 32768) <6>NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. <5>RAMDISK: Compressed image found at block 0 <4>Freeing initrd memory: 1920k freed <4>VFS: Mounted root (ext2 filesystem). <6>SCSI subsystem driver Revision: 1.00 <6>usb.c: registered new driver usbdevfs <6>usb.c: registered new driver hub <6>usb-uhci.c: $Revision: 1.259 $ time 21:52:53 Nov 2 2001 <6>usb-uhci.c: High bandwidth mode enabled <6>PCI: Found IRQ 10 for device 00:07.2 <6>PCI: Sharing IRQ 10 with 00:07.3 <4>PCI: Setting latency timer of device 00:07.2 to 64 <6>usb-uhci.c: USB UHCI at I/O 0xe400, IRQ 10 <4>usb-uhci.c: Detected 2 ports <6>usb.c: new USB bus registered, assigned bus number 1 <6>hub.c: USB hub found <6>hub.c: 2 ports detected <6>PCI: Found IRQ 10 for device 00:07.3 <6>PCI: Sharing IRQ 10 with 00:07.2 <4>PCI: Setting latency timer of device 00:07.3 to 64 <6>usb-uhci.c: USB UHCI at I/O 0xe800, IRQ 10 <4>usb-uhci.c: Detected 2 ports <6>usb.c: new USB bus registered, assigned bus number 2 <6>hub.c: USB hub found <6>hub.c: 2 ports detected <6>usb-uhci.c: v1.251:USB Universal Host Controller Interface driver <6>usb.c: registered new driver hid <6>usb.c: registered new driver hiddev <6>hid-core.c: v1.8 Andreas Gal, Vojtech Pavlik <6>hid-core.c: USB HID support drivers <6>Initializing USB Mass Storage driver... <6>usb.c: registered new driver usb-storage <6>USB Mass Storage support registered. <7>ISO 9660 Extensions: RRIP_1991A <4>Unable to identify CD-ROM format. <4>VFS: Can't find ext2 filesystem on dev loop(7,0). <6>md: raid0 personality registered as nr 2 <6>md: raid1 personality registered as nr 3 <6>raid5: measuring checksumming speed <4> 8regs : 1330.000 MB/sec <4> 32regs : 884.800 MB/sec <4> pII_mmx : 2254.800 MB/sec <4> p5_mmx : 2396.800 MB/sec <4>raid5: using function: p5_mmx (2396.800 MB/sec) <6>md: raid5 personality registered as nr 4 <6>Journalled Block Device driver loaded <6>SGI XFS with EAs, no debug enabled <6> hda: <6> hda: hda1 hda2 hda3 hda4 <6> hda: hda1 hda2 hda3 hda4 <6> hda: hda1 hda2 hda3 hda4 <6>Adding Swap: 1052248k swap-space (priority -1) <4>XFS mounting filesystem ide0(3,1) <4>XFS mounting filesystem ide0(3,4) <4>XFS mounting filesystem ide0(3,2) <7>ISO 9660 Extensions: RRIP_1991A <7>ISO 9660 Extensions: RRIP_1991A <7>ISO 9660 Extensions: RRIP_1991A <7>ISO 9660 Extensions: RRIP_1991A <4>hdc: command error: status=0x51 { DriveReady SeekComplete Error } <4>hdc: command error: error=0x54 <4>end_request: I/O error, dev 16:00 (hdc), sector 295356 <4>hdc: command error: status=0x51 { DriveReady SeekComplete Error } <4>hdc: command error: error=0x54 <4>end_request: I/O error, dev 16:00 (hdc), sector 391856 <4>hdc: command error: status=0x51 { DriveReady SeekComplete Error } <4>hdc: command error: error=0x54 <4>end_request: I/O error, dev 16:00 (hdc), sector 229288 <4>hdc: command error: status=0x51 { DriveReady SeekComplete Error } <4>hdc: command error: error=0x54 <4>end_request: I/O error, dev 16:00 (hdc), sector 229744 <4>hdc: command error: status=0x51 { DriveReady SeekComplete Error } <4>hdc: command error: error=0x54 <4>end_request: I/O error, dev 16:00 (hdc), sector 229748 <4>hdc: command error: status=0x51 { DriveReady SeekComplete Error } <4>hdc: command error: error=0x54 <4>end_request: I/O error, dev 16:00 (hdc), sector 230000 <4>hdc: command error: status=0x51 { DriveReady SeekComplete Error } <4>hdc: command error: error=0x54 <4>end_request: I/O error, dev 16:00 (hdc), sector 230004 <4>hdc: command error: status=0x51 { DriveReady SeekComplete Error } <4>hdc: command error: error=0x54 <4>end_request: I/O error, dev 16:00 (hdc), sector 230008 <4>hdc: command error: status=0x51 { DriveReady SeekComplete Error } <4>hdc: command error: error=0x54 <4>end_request: I/O error, dev 16:00 (hdc), sector 230012 /mnt/sysimage/tmp/install.log: Installing 667 packages Installing glibc-common. Installing indexhtml. Installing mailcap. Installing redhat-logos. Installing setup. Installing filesystem. Installing basesystem. Installing glibc. Installing bdflush. Installing bzip2-libs. Installing chkconfig. Installing cracklib. Installing db1. Installing db2. Installing db3. Installing dosfstools. Installing e2fsprogs. Installing eject. Installing file. Installing gdbm. Installing glib. Installing hdparm. Installing iputils. Installing ksymoops. Installing losetup. Installing mailx. Installing mingetty. Installing mktemp. Installing net-tools. Installing parted. Installing pcre. Installing perl. Installing popt. Installing pwdb. Installing reiserfs-utils. Installing setserial. Installing shadow-utils. Installing slang. Installing newt. Installing netconfig. Installing ntsysv. Installing setuptool. Installing syslinux. Installing termcap. Installing libtermcap. Installing bash. Installing bzip2. Installing crontabs. Installing hotplug. Installing iproute. Installing libstdc++. Installing groff. Installing logrotate. Installing MAKEDEV. Installing modutils. Installing ncurses. Installing info. Installing cpio. Installing diffutils. Installing ed. Installing fileutils. Installing at. Installing findutils. Installing gawk. Installing grep. Installing ash. Installing dhcpcd. Installing gzip. Installing less. Installing man. Installing openssl. Installing procmail. Installing procps. Installing psmisc. Installing raidtools. Installing readline. Installing redhat-release. Installing rootfiles. Installing sed. Installing console-tools. Installing kbdconfig. Installing slocate. Installing sysklogd. Installing tar. Installing tcsh. Installing textutils. Installing dev. Installing mount. Installing mkinitrd. Installing compat-egcs. Installing compat-egcs-c++. Installing compat-egcs-g77. Installing compat-glibc. Installing kernel-headers. Installing kernel-smp. /sbin/new-kernel-pkg: uname: command not found /sbin/new-kernel-pkg: [: =: unary operator expected /sbin/mkinitrd: uname: command not found /sbin/mkinitrd: [: =: unary operator expected Installing kernel. /sbin/new-kernel-pkg: uname: command not found /sbin/new-kernel-pkg: [: =: unary operator expected /sbin/mkinitrd: uname: command not found /sbin/mkinitrd: [: =: unary operator expected Installing kernel-source. Installing xfsprogs. Installing lvm-tools. Installing grub. Installing lilo. Installing mkbootdisk. Installing mouseconfig. Installing time. Installing tmpwatch. Installing utempter. Installing vim-common. Installing vim-minimal. Installing which. Installing words. Installing cracklib-dicts. Installing pam. Installing authconfig. Installing cyrus-sasl. Installing cyrus-sasl-md5. Installing cyrus-sasl-plain. Installing gpm. Installing kudzu. Installing passwd. Installing sh-utils. Installing krb5-libs. Installing openldap. Installing sendmail. Installing SysVinit. Installing zlib. Installing rpm. Installing util-linux. Installing initscripts. Installing apmd. Installing ipchains. Installing iptables. Installing lokkit. Installing pciutils. Installing quota. Installing timeconfig. Installing vixie-cron. Installing anacron. Installing expat. Installing freetype. Installing ghostscript-fonts. Installing gmp. Installing groff-perl. Installing libpng. Installing libxml2. Installing libxslt. Installing LPRng. Installing m4. Installing mpage. Installing nkf. Installing perl-DateManip. Installing perl-Digest-MD5. Installing perl-HTML-Tagset. Installing perl-HTML-Parser. Installing perl-libnet. Installing perl-MIME-Base64. Installing perl-Parse-Yapp. Installing perl-Storable. Installing perl-URI. Installing perl-libwww-perl. Installing perl-XML-Encoding. Installing perl-XML-Grove. Installing perl-XML-Parser. Installing perl-libxml-perl. Installing perl-libxml-enno. Installing perl-XML-Dumper. Installing perl-XML-Twig. Installing foomatic. Installing pnm2ppa. Installing psutils. Installing a2ps. Installing python. Installing alchemist. Installing PyXML. Installing 4Suite. Installing watanabe-vf. Installing XFree86-libs. Installing VFlib2. Installing XFree86-xfs. Installing chkfontpath. Installing ttfonts-ja. Installing urw-fonts. Installing ghostscript. Installing printconf. Installing fortune-mod. Installing gtk+. Installing lesstif. Installing libjpeg. Installing libtiff. Installing gdk-pixbuf. Installing switchdesk. Installing ttfonts. Installing Xaw3d. Installing XFree86. Installing Mesa. Installing mkxauth. Installing Xconfigurator. Installing XFree86-100dpi-fonts. Installing XFree86-75dpi-fonts. Installing XFree86-ISO8859-15-100dpi-fonts. Installing XFree86-ISO8859-15-75dpi-fonts. Installing XFree86-tools. Installing XFree86-twm. Installing xinitrc. Installing XFree86-xdm. Installing xloadimage. Installing audiofile. Installing arts. Installing esound. Installing gnome-audio. Installing libcap. Installing libmng. Installing libungif. Installing libuser. Installing libxml. Installing netpbm. Installing netpbm-progs. Installing imlib. Installing ntp. Installing ORBit. Installing gnome-libs. Installing libglade. Installing pygtk. Installing pygnome. Installing pygtk-libglade. Installing pygnome-libglade. Installing qt. Installing tcl. Installing tk. Installing tix. Installing tkinter. Installing usermode. Installing dateconfig. Installing hwbrowser. Installing ksconfig. Installing locale_config. Installing printconf-gui. Installing redhat-config-users. Installing serviceconf. Installing xsri. Installing libtool-libs. Installing pspell. Installing aspell. Installing aumix. Installing desktop-backgrounds. Installing dia. Installing ee. Installing extace. Installing gal. Installing gdk-pixbuf-gnome. Installing gftp. Installing gnome-audio-extra. Installing gnome-pim. Installing gnome-user-docs. Installing gqview. Installing gtk-engines. Installing ImageMagick. Installing imlib-cfgeditor. Installing libghttp. Installing gnorpm. Installing libgnomeprint15. Installing gnome-print. Installing gedit. Installing libgal7. Installing libgtop. Installing gtop. Installing libole2. Installing librep. Installing librsvg. Installing libunicode. Installing abiword. Installing mc. Installing gmc. Installing mozilla. Installing oaf. Installing bonobo. Installing GConf. Installing gnome-vfs. Installing bug-buddy. Installing eel. Installing gnome-vfs-extras. Installing portmap. Installing rep-gtk. Installing rep-gtk-gnome. Installing rep-gtk-libglade. Installing scrollkeeper. Installing gdm. Installing switchdesk-gnome. Installing umb-scheme. Installing guile. Installing gnumeric. Installing xchat. Installing xinetd. Installing fam. Installing xscreensaver. Installing control-center. Installing gtkhtml. Installing sawfish. Installing gnome-core. Installing gnome-applets. Installing gnome-utils. Installing nautilus. Installing nautilus-mozilla. Installing htdig. Installing kdeartwork-locolor. Installing kdelibs. Installing kdeadmin. Installing kdeartwork. Installing kdelibs-sound. Installing kdepim. Installing koffice. Installing libogg. Installing libvorbis. Installing lm_sensors. Installing kdebase. Installing kdeaddons-kate. Installing kdeaddons-kicker. Installing kdeaddons-konqueror. Installing make. Installing efax. Installing pilot-link. Installing switchdesk-kde. Installing unzip. Installing zip. Installing kdeutils. Installing autorun. Installing awesfx. Installing cdda2wav. Installing cdlabelgen. Installing cdp. Installing cdparanoia. Installing cdrecord. Installing gnome-media. Installing gsm. Installing libao. Installing magicdev. Installing mikmod. Installing mkisofs. Installing mpg321. Installing playmidi. Installing SDL. Installing SDL_image. Installing SDL_net. Installing smpeg. Installing SDL_mixer. Installing sox. Installing sndconfig. Installing timidity++. Installing kdemultimedia. Installing kdeaddons-noatun. Installing vorbis. Installing xawtv. Installing xmms. Installing xmms-gnome. Installing autofs. Installing bind-utils. Installing cipe. Installing compat-libstdc++. Installing finger. Installing ftp. Installing gnupg. Installing gq. Installing htmlview. Installing firewall-config. Installing kdenetwork. Installing krbafs. Installing libpcap. Installing logwatch. Installing micq. Installing ncftp. Installing nfs-utils. Installing nmap. Installing nmap-frontend. Installing nscd. Installing nss_ldap. Installing openldap-clients. Installing openssh. Installing openssh-askpass. Installing openssh-askpass-gnome. Installing openssh-clients. Installing pam_krb5. Installing pidentd. Installing python-xmlrpc. Installing radvd. Installing rdate. Installing redhat-config-network. Installing rmt. Installing rpm-python. Installing rhn_register. Installing rhn_register-gnome. Installing rsh. Installing rusers. Installing rwho. Installing sendmail-cf. Installing stunnel. Installing talk. Installing tcp_wrappers. Installing telnet. Installing traceroute. Installing ucd-snmp. Installing up2date. Installing up2date-gnome. Installing wget. Installing whois. Installing ypbind. Installing yp-tools. Installing isdn4k-utils. Installing kdenetwork-ppp. Installing kpppload. Installing lockdev. Installing lrzsz. Installing minicom. Installing ppp. Installing rp-pppoe. Installing statserial. Installing wvdial. Installing rp3. Installing xisdnload. Installing fetchmail. Installing gaim. Installing galeon. Installing kdebindings. Installing kdebindings-kmozilla. Installing libesmtp. Installing balsa. Installing licq. Installing licq-gnome. Installing licq-kde. Installing links. Installing mozilla-mail. Installing mozilla-psm. Installing mutt. Installing netscape-common. Installing netscape-communicator. Installing nmh. Installing exmh. Installing pan. Installing pine. Installing sharutils. Installing metamail. Installing giftrans. Installing gimp. Installing gphoto. Installing sane-backends. Installing kdegraphics. Installing sane-frontends. Installing xsane. Installing finger-server. Installing openssh-server. Installing rsh-server. Installing rusers-server. Installing rwall-server. Installing sysstat. Installing talk-server. Installing telnet-server. Installing vnc. Installing vnc-server. Installing ypserv. Installing samba-common. Installing samba. Installing samba-client. Installing cpp. Installing curl. Installing gd. Installing mm. Installing gnome-lokkit. Installing iptables-ipv6. Installing mtr. Installing mtr-gtk. Installing rarpd. Installing tripwire. Installing mt-st. Installing rdist. Installing tcpdump. Installing ucd-snmp-utils. Installing dialog. Installing sgml-common. Installing docbook-dtd30-sgml. Installing docbook-dtd31-sgml. Installing docbook-dtd40-sgml. Installing docbook-dtd41-sgml. Installing openjade. Installing docbook-style-dsssl. Installing perl-SGMLSpm. Installing docbook-utils. Installing sgml-tools. Installing tetex-fonts. From owner-linux-xfs@oss.sgi.com Tue Nov 6 08:57:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6GvbE25986 for linux-xfs-outgoing; Tue, 6 Nov 2001 08:57:37 -0800 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 fA6GvX025964 for ; Tue, 6 Nov 2001 08:57:34 -0800 Received: from heppcl.ph.qmw.ac.uk ([138.37.50.187]) by zeta.qmw.ac.uk with esmtp (Exim 3.32 #1) id 1619XZ-0002md-00 for linux-xfs@oss.sgi.com; Tue, 06 Nov 2001 16:57:33 +0000 Received: from heppct.ph.qmw.ac.uk (heppct.ph.qmw.ac.uk [138.37.50.246]) by heppcl.ph.qmw.ac.uk (8.11.6/8.9.3) with ESMTP id fA6GvWh28589 for ; Tue, 6 Nov 2001 16:57:32 GMT Received: from localhost (pd@localhost) by heppct.ph.qmw.ac.uk (8.11.6/8.9.3) with ESMTP id fA6GvRa12838 for ; Tue, 6 Nov 2001 16:57:27 GMT X-Authentication-Warning: heppct.ph.qmw.ac.uk: pd owned process doing -bs Date: Tue, 6 Nov 2001 16:57:27 +0000 (GMT) From: "P.Dixon" To: Subject: Re: 7.2 installer crash 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 tried the XFS 7.2 installer (text mode) and it crashed while > installing tetex. Note that the Red Hat 7.2 CDROMS have been used > previously to install Red Hat 7.2 on other systems using ext3. > Just tried the graphical installer and that worked - although when returning from testing the X configuration, it put my monitor into power save mode - finally resulting in me pressing ctrl-alt-delete. As this is the last part of installation, I now have a working Red Hat 7.2 system with XFS. Cheers! Paul From owner-linux-xfs@oss.sgi.com Tue Nov 6 09:07:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6H7mp27360 for linux-xfs-outgoing; Tue, 6 Nov 2001 09:07:48 -0800 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 fA6H7h027335 for ; Tue, 6 Nov 2001 09:07:43 -0800 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 JAA06765 for ; Tue, 6 Nov 2001 09:07:14 -0800 (PST) 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 LAA3512831 for ; Tue, 6 Nov 2001 11:06:26 -0600 (CST) Received: from jen.americas.sgi.com (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 LAA81091 for ; Tue, 6 Nov 2001 11:06:26 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA6H1eU08807; Tue, 6 Nov 2001 11:01:40 -0600 Message-Id: <200111061701.fA6H1eU08807@jen.americas.sgi.com> Date: Tue, 6 Nov 2001 11:01:40 -0600 Subject: TAKE - Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Nov 6 09:06:08 PST 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:106155a linux/drivers/block/loop.c - 1.41 - Remove deactivate_page call - it no longer exists From owner-linux-xfs@oss.sgi.com Tue Nov 6 09:09:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6H9KT27509 for linux-xfs-outgoing; Tue, 6 Nov 2001 09:09:20 -0800 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 fA6H9I027486 for ; Tue, 6 Nov 2001 09:09:18 -0800 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 JAA06918 for ; Tue, 6 Nov 2001 09:08:49 -0800 (PST) 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 LAA3514038 for ; Tue, 6 Nov 2001 11:08:02 -0600 (CST) Received: from jen.americas.sgi.com (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 LAA80866 for ; Tue, 6 Nov 2001 11:08:02 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA6H3FK08915; Tue, 6 Nov 2001 11:03:15 -0600 Message-Id: <200111061703.fA6H3FK08915@jen.americas.sgi.com> Date: Tue, 6 Nov 2001 11:03:15 -0600 Subject: TAKE - Make raid5 less chatty with xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Nov 6 09:07:47 PST 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:106156a linux/drivers/md/raid5.c - 1.22 - Make raid5 less chatty with xfs From owner-linux-xfs@oss.sgi.com Tue Nov 6 10:23:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6INip00712 for linux-xfs-outgoing; Tue, 6 Nov 2001 10:23:44 -0800 Received: from smtpstore.strencom.net ([217.75.0.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6INe000688 for ; Tue, 6 Nov 2001 10:23:40 -0800 Received: from raptor.raidtec.ie (unknown [217.75.2.18]) by smtpstore.strencom.net (Postfix) with SMTP id 86D7A638E9 for ; Tue, 6 Nov 2001 18:21:58 +0000 (GMT) Received: from no.name.available by raptor.raidtec.ie via smtpd (for [217.75.0.68]) with SMTP; 6 Nov 2001 18:29:37 UT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Q.. X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Date: Tue, 6 Nov 2001 18:23:38 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 7.2 installer crash Thread-Index: AcFm4F2qrJamzITuTKen7sQpCKcshgADw8Vg From: "Juer Lee" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fA6INf000690 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Guys, This Q-A is got from http://oss.sgi.com/projects/xfs/faq.html#backingupxfs. But how to make xfsdump work with amanda? I want to backup ACLs. Canany gurus answer me, thanks in advance. Q: How can I backup an XFS filesystem and acls? You can backup a XFS filesystem with utilities like xfsdump and standard tar for standard files. If you want to backup acls you will need to use xfsdump. This is the only tool at the moment that supports backing up of acls. Support for XFS and acls is underway at several commercial backup tools. xfsdump can be made to work with amanda. Juer From owner-linux-xfs@oss.sgi.com Tue Nov 6 10:29:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6ITBT01260 for linux-xfs-outgoing; Tue, 6 Nov 2001 10:29:11 -0800 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 fA6IT8001238 for ; Tue, 6 Nov 2001 10:29:08 -0800 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id fA6IT5f25165; Tue, 6 Nov 2001 13:29:06 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Tue, 6 Nov 2001 13:29:05 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: To: Juer Lee cc: Subject: Re: Q.. 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, 6 Nov 2001 at 6:23pm, Juer Lee wrote > This Q-A is got from > http://oss.sgi.com/projects/xfs/faq.html#backingupxfs. But how to make > xfsdump work with amanda? I want to backup ACLs. Canany gurus answer me, > thanks in advance. It should work automagically, given that xfsdump was present when you configured amanda. At backup time, amanda checkes the filesystem type and uses the appropriate dump command. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Tue Nov 6 10:30:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6IUIQ01414 for linux-xfs-outgoing; Tue, 6 Nov 2001 10:30:18 -0800 Received: from smtpstore.strencom.net ([217.75.0.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6IUC001349 for ; Tue, 6 Nov 2001 10:30:12 -0800 Received: from raptor.raidtec.ie (unknown [217.75.2.18]) by smtpstore.strencom.net (Postfix) with SMTP id 676DB638F0; Tue, 6 Nov 2001 18:28:31 +0000 (GMT) Received: from no.name.available by raptor.raidtec.ie via smtpd (for [217.75.0.68]) with SMTP; 6 Nov 2001 18:36:10 UT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Q.. X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Date: Tue, 6 Nov 2001 18:30:11 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Q.. Thread-Index: AcFm8OwBPepsCigGQRKrqoqtSE0isgAABDrA From: "Juer Lee" To: "Joshua Baker-LePain" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fA6IUD001363 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks a lot. >-----Original Message----- >From: Joshua Baker-LePain [mailto:jlb17@duke.edu] >Sent: 06 November 2001 18:29 >To: Juer Lee >Cc: linux-xfs@oss.sgi.com >Subject: Re: Q.. > > >On Tue, 6 Nov 2001 at 6:23pm, Juer Lee wrote > >> This Q-A is got from >> http://oss.sgi.com/projects/xfs/faq.html#backingupxfs. But >how to make >> xfsdump work with amanda? I want to backup ACLs. Canany >gurus answer me, >> thanks in advance. > >It should work automagically, given that xfsdump was present when you >configured amanda. At backup time, amanda checkes the >filesystem type and >uses the appropriate dump command. > >-- >Joshua Baker-LePain >Department of Biomedical Engineering >Duke University > > From owner-linux-xfs@oss.sgi.com Tue Nov 6 11:15:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6JFbQ07240 for linux-xfs-outgoing; Tue, 6 Nov 2001 11:15:37 -0800 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6JFS007217 for ; Tue, 6 Nov 2001 11:15:28 -0800 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id F31D71AB2A; Tue, 6 Nov 2001 14:15:24 -0500 (EST) Received: by ranma.dkp.com (Postfix, from userid 168) id 17C6D5A8FC; Tue, 6 Nov 2001 14:15:23 -0500 (EST) Date: Tue, 6 Nov 2001 14:15:23 -0500 From: Andrew Klaassen To: linux-xfs@oss.sgi.com, linux-raid@vger.kernel.org Subject: Re: Oops - XFS mount after replacing wrong RAID5 drive Message-ID: <20011106141523.B5048@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com, linux-raid@vger.kernel.org References: <20011105103521.A3864@dkp.com> <1004974636.7318.5.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1004974636.7318.5.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Nov 05, 2001 at 09:37:16AM -0600, Steve Lord wrote: > On Mon, 2001-11-05 at 09:35, > Andrew Klaassen wrote: > > I think I may have just replaced the wrong drive after a SW > > RAID5 drive failure. > > > > And then I mounted the XFS filesystem read-write. (Doh!) > > How do I mount the filesystem without writing anything at all to > > the array? > mount -o ro,norecovery Steve Lord is good to me And so I thank Steve Lord For giving me the things I need Like XFS mounts that only read. Steve Lord is good to me. - to the tune of Johnny Appleseed ;) Well, things are going very, very well. We've already rescued the critical data, and it looks like we'll be able to rescue everything. Here's what I did, in case anyone is interested; the goal of everything was to make sure absolutely no writing would happen, so that we could back out any changes in case anything went wrong. With the server off: - I cloned the original hdp, the drive I had originally replaced (which was showing signs of failure but not completely failed yet), and put the clone into the server. - I disconnected hdn (the drive that had completely failed). Using an install CD - just using the Alt-F2 shell from the text installer, not using rescue mode, so that it wouldn't try to initialize any RAID devices that I didn't want initialized: - I marked hdn as a failed-drive in the raidtab. - I changed the array mount options to ro,norecovery,noauto,... in the fstab. - I added an append="single ..." line to lilo.conf and ran lilo, just to be safe. After rebooting: - I ran mkraid -f on the array to re-initialize the raid superblocks. - I mounted the array using the ro,norecovery options. That's about $1/2 million you just helped me rescue. Thanks. :) Andrew Klaassen From owner-linux-xfs@oss.sgi.com Tue Nov 6 13:04:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6L4CV10420 for linux-xfs-outgoing; Tue, 6 Nov 2001 13:04:12 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6L48010398 for ; Tue, 6 Nov 2001 13:04:08 -0800 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Nov 2001 15:03:29 -0600 Message-ID: <85063BBE668FD411944400D0B744267A88871D@AUSMAIL> From: "Gonyou, Austin" To: "'Juer Lee'" , linux-xfs@oss.sgi.com Subject: RE: Q.. Date: Tue, 6 Nov 2001 15:03:26 -0600 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 something like DD on an unmounted volume wouldn't work? -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Juer Lee [mailto:Juer.Lee@raidtec.ie] > Sent: Tuesday, November 06, 2001 12:24 PM > To: linux-xfs@oss.sgi.com > Subject: Q.. > > > Hi, Guys, > > This Q-A is got from > http://oss.sgi.com/projects/xfs/faq.html#backingupxfs. But how to make > xfsdump work with amanda? I want to backup ACLs. Canany gurus > answer me, > thanks in advance. > > Q: How can I backup an XFS filesystem and acls? > You can backup a XFS filesystem with utilities like xfsdump > and standard > tar for standard files. If you want to backup acls you will > need to use > xfsdump. This is the only tool at the moment that supports > backing up of > acls. Support for XFS and acls is underway at several > commercial backup > tools. xfsdump can be made to work with amanda. > > Juer > From owner-linux-xfs@oss.sgi.com Tue Nov 6 13:02:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6L2tl10319 for linux-xfs-outgoing; Tue, 6 Nov 2001 13:02:55 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6L2n010296 for ; Tue, 6 Nov 2001 13:02:49 -0800 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Nov 2001 15:02:19 -0600 Message-ID: <85063BBE668FD411944400D0B744267A88871C@AUSMAIL> From: "Gonyou, Austin" To: "'mingo@elte.hu'" , Keith Owens Cc: Tux mailing list , XFS Mailing list Subject: RE: XFS+Tux = patch trouble Date: Tue, 6 Nov 2001 15:02:09 -0600 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 Sounds like Al Viro and Andrea Arcangelli. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Ingo Molnar [mailto:mingo@elte.hu] > Sent: Tuesday, November 06, 2001 3:52 AM > To: Keith Owens > Cc: Tux mailing list; XFS Mailing list > Subject: Re: XFS+Tux = patch trouble > > > > On Tue, 6 Nov 2001, Keith Owens wrote: > > > On Tue, 6 Nov 2001 09:20:08 +0100 (CET), > > Ingo Molnar wrote: > > >it would be nice if SGI folks pushed harder for XFS's > integration into the > > >mainstream kernel. > > > > We have been trying hard since at least 2.4.5. I split the big XFS > > patch into digestible chunks, separating the core XFS code from the > > add on stuff like kdb, lvm, dmapi, quota. We have been sending mail > > to Linus about the core XFS patches since June 5, 2001. Response - > > total silence. Not even "I don't like it", we get no > response at all. > > i dont think Linus is the first step needed. XFS is pretty > intrusive in > the VFS area, so i guess you should first sort out the necessery VFS > modifications with Al Viro? And then go step by step forward. > I mean, we > are in a stable kernel branch and this is a pretty big patch even just > counting the core changes. > > Ingo > From owner-linux-xfs@oss.sgi.com Tue Nov 6 13:11:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6LBTH13197 for linux-xfs-outgoing; Tue, 6 Nov 2001 13:11:29 -0800 Received: from posta2.elte.hu (posta2.elte.hu [157.181.151.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6LBQ013175 for ; Tue, 6 Nov 2001 13:11:26 -0800 Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by posta2.elte.hu (Postfix) with ESMTP id 1F0A548010; Tue, 6 Nov 2001 22:11:16 +0100 (CET) Received: by chiara.elte.hu (Postfix, from userid 17806) id F34971FCF; Tue, 6 Nov 2001 22:11:12 +0100 (CET) Date: Tue, 6 Nov 2001 23:09:11 +0100 (CET) From: Ingo Molnar Reply-To: To: "Gonyou, Austin" Cc: Keith Owens , Tux mailing list , XFS Mailing list Subject: RE: XFS+Tux = patch trouble In-Reply-To: <85063BBE668FD411944400D0B744267A88871C@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, 6 Nov 2001, Gonyou, Austin wrote: > Sounds like Al Viro and Andrea Arcangelli. (i'd say most of the intrusive stuff is in the VFS area, so it's Al mostly. And for VM design stuff the authority is Linus'.) Ingo From owner-linux-xfs@oss.sgi.com Tue Nov 6 13:20:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6LKi013488 for linux-xfs-outgoing; Tue, 6 Nov 2001 13:20:44 -0800 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 fA6LKg013466 for ; Tue, 6 Nov 2001 13:20:42 -0800 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id fA6LKcF25648; Tue, 6 Nov 2001 16:20:38 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Tue, 6 Nov 2001 16:20:37 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: To: "Gonyou, Austin" cc: "'Juer Lee'" , Subject: RE: Q.. In-Reply-To: <85063BBE668FD411944400D0B744267A88871D@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, 6 Nov 2001 at 3:03pm, Gonyou, Austin wrote > so something like DD on an unmounted volume wouldn't work? > Not in the context of amanda, which is what the question was referencing. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Tue Nov 6 13:27:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6LRhm13723 for linux-xfs-outgoing; Tue, 6 Nov 2001 13:27:43 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6LRd013700 for ; Tue, 6 Nov 2001 13:27:39 -0800 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Nov 2001 15:27:09 -0600 Message-ID: <85063BBE668FD411944400D0B744267A88871E@AUSMAIL> From: "Gonyou, Austin" To: "'Joshua Baker-LePain'" , "Gonyou, Austin" Cc: "'Juer Lee'" , linux-xfs@oss.sgi.com Subject: RE: Q.. Date: Tue, 6 Nov 2001 15:27:06 -0600 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 Hehe..Yeah..Sorry about that. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Joshua Baker-LePain [mailto:jlb17@duke.edu] > Sent: Tuesday, November 06, 2001 3:21 PM > To: Gonyou, Austin > Cc: 'Juer Lee'; linux-xfs@oss.sgi.com > Subject: RE: Q.. > > > On Tue, 6 Nov 2001 at 3:03pm, Gonyou, Austin wrote > > > so something like DD on an unmounted volume wouldn't work? > > > Not in the context of amanda, which is what the question was > referencing. > > -- > Joshua Baker-LePain > Department of Biomedical Engineering > Duke University > From owner-linux-xfs@oss.sgi.com Tue Nov 6 13:44:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6LiJN14089 for linux-xfs-outgoing; Tue, 6 Nov 2001 13:44:19 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6LiC014065 for ; Tue, 6 Nov 2001 13:44:12 -0800 Received: from uucp.gnuu.de (uucp.gnuu.de [151.189.0.84]) 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 NAA06944 for ; Tue, 6 Nov 2001 13:44:00 -0800 (PST) mail_from (sfr@gallien.de) Received: (from uucp@localhost) by uucp.gnuu.de (8.11.1/8.11.1) with UUCP id fA6LcvK89391 for linux-xfs@oss.sgi.com; Tue, 6 Nov 2001 22:38:57 +0100 (CET) Received: by mail.gallien.de (Postfix, from userid 1000) id ECEFC2B6A1; Tue, 6 Nov 2001 20:16:33 +0100 (CET) Date: Tue, 6 Nov 2001 20:16:33 +0100 From: Stefan Frank To: linux-xfs@oss.sgi.com Subject: Re: Damaged XFS partition after moving to SMP Message-ID: <20011106201633.A17599@obelix.gallien.de> References: <20011105225039.A599@asterix.gallien.de> <1005058628.15251.15.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1005058628.15251.15.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.23i X-MIME-Autoconverted: from 8bit to quoted-printable by sgi.com id NAA06944 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fA6LiC014066 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve! On Tue, 06 Nov 2001, Steve Lord wrote: > Sorry, but your disk would appear to be in very bad shape after this, > those bad magic number values actually appear to be copies of the xfs > super block. There appears to have been some random splattering of > data onto the disk. > > Do you have any syslog messages from before the system went down? Sorry, no further messages logged. All i can say is that this new SMP system has been working fine for about 1/2 hour before this happened. > Also, what type of partition was this? Were you using md/lvm, what > was the hardware involved. Also, which compiler did you use? > > Steve > > p.s. 2.4.10 is supposedly not the best kernel to be running, 2.4.13 > is out on the ftp site, and 2.4.14 should arrive there today. > > >From the dmesg output: sym53c8xx: at PCI bus 0, device 11, function 0 sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) sym53c8xx: 53c895 detected with Tekram NVRAM sym53c895-0: rev 0x1 on pci bus 0 device 11 function 0 irq 10 sym53c895-0: Tekram format NVRAM, ID 7, Fast-40, Parity Checking scsi0 : sym53c8xx-1.7.3c-20010512 Vendor: SEAGATE Model: ST39216N Rev: 0010 Type: Direct-Access ANSI SCSI revision: 03 Vendor: IBM Model: DPSS-309170N Rev: S93E Type: Direct-Access ANSI SCSI revision: 03 This partition (mounted as /var) was located on the Seagete disk. It's an Ultra SCSI model on a Tekram DC-390U2W controller. Here's the partitioning layout: Name Flags Part. Typ Dateisystemtyp [Bezeichner] Größe (MB) ------------------------------------------------------------------------------ sda1 Boot Primäre Linux ext2 [boot] 10,49 sda2 Primäre Linux ext2 [/] 169,87 sda3 Primäre Linux ext2 [usr] 1399,85 sda5 Logische Linux XFS [home] 2999,98 sda6 Logische Linux XFS [var] 4500,49 sda7 Logische Linux swap 105,91 The kernel was actually compiled on another machine which has Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20010721 (Debian prerelease) Somehow i have the feeling that it was SMP related. The same setup has been working nicely on my old box for 1/2 year with different 2.4.x + XFS kernels. Also i can still access all other partitions. After the reinstall i copied the whole /home (with only one user) to the 2nd disk. >From your answer i guess there's little chance to rescue some data from this partition? Bye, Stefan From owner-linux-xfs@oss.sgi.com Tue Nov 6 14:03:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6M35D14748 for linux-xfs-outgoing; Tue, 6 Nov 2001 14:03:05 -0800 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 fA6M33014726 for ; Tue, 6 Nov 2001 14:03:03 -0800 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 OAA06324 for ; Tue, 6 Nov 2001 14:02:34 -0800 (PST) mail_from (eric@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 QAA3468792 for ; Tue, 6 Nov 2001 16:01:46 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA48376 for ; Tue, 6 Nov 2001 16:01:46 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id fA6M1Cj06762; Tue, 6 Nov 2001 16:01:12 -0600 Message-Id: <200111062201.fA6M1Cj06762@stout.americas.sgi.com> Date: Tue, 6 Nov 2001 16:01:12 -0600 From: Eric Sandeen Subject: TAKE - Let xfs_admin read labels & uuids on mounted filesystems Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk xfs_admin is a wrapper around xfs_db, which can take an "-r" option to extract data from a filesystem even if it's mounted. Adding "-r" to the -l and -u commands in xfs_admin will allow uuid and label to be read even if the filesystem is mounted. Date: Tue Nov 6 14:00:03 PST 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:106208a cmd/xfsprogs/db/xfs_admin.sh - 1.2 - Let xfs_admin read labels and uuids on mounted filesystems From owner-linux-xfs@oss.sgi.com Tue Nov 6 15:44:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6Ni2N17066 for linux-xfs-outgoing; Tue, 6 Nov 2001 15:44:02 -0800 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 fA6Ni0017044 for ; Tue, 6 Nov 2001 15:44:00 -0800 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 PAA05146 for ; Tue, 6 Nov 2001 15:43:31 -0800 (PST) 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 RAA3519061; Tue, 6 Nov 2001 17:42:42 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA46349; Tue, 6 Nov 2001 17:42:42 -0600 (CST) Subject: Re: Convert another FS to XFS From: Eric Sandeen To: linux-xfs@oss.sgi.com Cc: "Quang Nguyen (Ngo)" In-Reply-To: <200111062340.fA6NeaZ16986@oss.sgi.com> References: <200111062340.fA6NeaZ16986@oss.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 06 Nov 2001 17:42:07 -0600 Message-Id: <1005090128.1925.47.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Quang - Backup and restore is your only option. There are no filesystem conversion tools between these filesystems. -Eric On Tue, 2001-11-06 at 17:40, Quang wrote: > How do you convert a partition currenly having a different file system, such > reiserfs or ext2, to xfs without destroying data? > > -- > Quang -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Nov 6 16:11:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA70BBu17645 for linux-xfs-outgoing; Tue, 6 Nov 2001 16:11:11 -0800 Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA70B5017623 for ; Tue, 6 Nov 2001 16:11:05 -0800 Received: from static031-81-151-24.nm01-c3.cpe.charter-ne.com ([24.151.81.31] helo=dhcp10) by scaup.prod.itd.earthlink.net with smtp (Exim 3.33 #1) id 161GIz-00003v-00; Tue, 06 Nov 2001 16:11:01 -0800 Message-ID: <02bb01c16720$7fd7d470$0a00a8c0@intranet.mp3s.com> Reply-To: "Sean Elble" From: "Sean Elble" To: , "Keith Owens" Cc: "Tux mailing list" , "XFS Mailing list" References: Subject: Re: XFS+Tux = patch trouble Date: Tue, 6 Nov 2001 19:08:58 -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 Good point . . . if we (XFS users) _really_ want to get XFS in 2.4, that is exactly what we have to do. The XFS patch is huge, but it works well (JFS doesn't, yet, and it doesn't have any of the features that XFS has, like ACLs, or even quota support, but that's another discussion.). By getting more of the code XFS _depends_ on in the 2.4 tree, you decrease the number of mods required to patch XFS to a mainline kernel; eventually, this could get to the point where JFS is now, and we wouldn't need to touch nearly as many files. I'm no developer, let alone a XFS developer :-), but is this idea reasonable from a programmer's point of view? ----------------------------------------------- Sean P. Elble Editor, Writer, Co-Webmaster ReactiveLinux.com (Formerly MaximumLinux.org) http://www.reactivelinux.com/ elbles@reactivelinux.com ----------------------------------------------- ----- Original Message ----- From: "Ingo Molnar" To: "Keith Owens" Cc: "Tux mailing list" ; "XFS Mailing list" Sent: Tuesday, November 06, 2001 4:52 AM Subject: Re: XFS+Tux = patch trouble > > On Tue, 6 Nov 2001, Keith Owens wrote: > > > On Tue, 6 Nov 2001 09:20:08 +0100 (CET), > > Ingo Molnar wrote: > > >it would be nice if SGI folks pushed harder for XFS's integration into the > > >mainstream kernel. > > > > We have been trying hard since at least 2.4.5. I split the big XFS > > patch into digestible chunks, separating the core XFS code from the > > add on stuff like kdb, lvm, dmapi, quota. We have been sending mail > > to Linus about the core XFS patches since June 5, 2001. Response - > > total silence. Not even "I don't like it", we get no response at all. > > i dont think Linus is the first step needed. XFS is pretty intrusive in > the VFS area, so i guess you should first sort out the necessery VFS > modifications with Al Viro? And then go step by step forward. I mean, we > are in a stable kernel branch and this is a pretty big patch even just > counting the core changes. > > Ingo From owner-linux-xfs@oss.sgi.com Tue Nov 6 16:25:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA70PYj18000 for linux-xfs-outgoing; Tue, 6 Nov 2001 16:25:34 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA70PM017975 for ; Tue, 6 Nov 2001 16:25:22 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id fA70PGT14441 for ; Tue, 6 Nov 2001 16:25:16 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA18738; Wed, 7 Nov 2001 11:23:59 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA86617; Wed, 7 Nov 2001 11:23:58 +1100 (AEDT) Date: Wed, 7 Nov 2001 11:23:58 +1100 From: Nathan Scott To: Linus Torvalds , Andreas Gruenbacher Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, acl-devel@bestbits.at, linux-xfs@oss.sgi.com Subject: Re: [RFC][PATCH] extended attributes Message-ID: <20011107112358.D591676@wobbly.melbourne.sgi.com> References: <20011107111224.C591676@wobbly.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: <20011107111224.C591676@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Wed, Nov 07, 2001 at 11:12:24AM +1100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Quick follow up - I had to botch _one_ of the CC'd lists I guess... "linux-xfs@oss.sgi.comc" -> "linux-xfs@oss.sgi.com". *sigh* cheers. On Wed, Nov 07, 2001 at 11:12:24AM +1100, Nathan Scott wrote: > hi folks, > > I've been discussing a filesystem extended attributes API with Andreas > Gruenbacher (maintainer of the ext2/ext3 extended attributes patch[1]) > which is suitable for other Linux filesystems as well, in an effort to > remove the differences between our current implementations and to help > out the people building services layered above this (especially Samba). > In doing so we have reviewed the earlier discussion[2,3] on this topic, > and have attempted to produce a new interface which I believe satisfies > many of the issues and ideas put forward there, while at the same time > ensuring that the interface is simple, and remains true to the design > of extended attributes being name:value pairs. > > A manual page describing the system call interface can be found here[4]. > We're very interested in feedback on this. In partiular, Linus - would > you consider the patch below, which reserves system call numbers for > this interface? That would be a big help to our collaborative effort. > > We have written most of the code for XFS, and Andreas is working away on > the ext2/ext3 version. Switching to a new syscall interface is going to > cause several compatibility issues for our existing users, of course, so > is not something we want to rush into before soliciting feedback and > (hopefully) getting some system call numbers reserved - otherwise we may > find ourselves needing to do a similar transition again later. > > As a test case for the interface, we will now be able to use the same > POSIX ACL userspace[1,5] between XFS and ext2 without any on-disk format > changes in XFS - this was an important interface design goal for us XFS > folk, where our format is fixed in stone as it is also used by IRIX. > > We have also begun discussions with some of the LSM developers, with the > goal of implementing POSIX capabilities and POSIX MAC (mandatory access > control) security extensions in Linux also, Here we again expect to be > able to provide a filesystem independent view of these attributes, while > still preserving the on-disk XFS format for these attributes using the > simple namespace abstraction mechanism this new interface provides. > > I've included some pointers[6,7,8,9,10] to other projects, developers, > discussions, etc. which I've come across who are in some way or another > interested in an extended attributes implementation in the base kernel > - just as examples of how various people are using (or planning to use) > the current ext2/ext3 and XFS interfaces on Linux. > > cheers. > > -- > Nathan > > > [1] Extended attributes for ext2/ext3 and POSIX ACLs > http://acl.bestbits.at/ > [2] fs-devel extended attributes discussion > http://marc.theaimsgroup.com/?l=linux-fsdevel&m=97222475218787&w=2 > [3] Andrew Gildfind's interface comparison whitepaper > http://acl.bestbits.at/pre/gildfind-acls.pdf > [4] New extattr(2) system call man pages > http://acl.bestbits.at/man/extattr.2.html > http://acl.bestbits.at/man/extattr.5.html > http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/attr2/man/man2/extattr.2 > [5] Common POSIX ACL implementation for Linux > http://acl.bestbits.at/pipermail/acl-devel/2001-February/000495.html > http://www.samba.org/samba/whatsnew/samba-2.2.0.html > [6] Andrew Morgan's Filesystem Capability patches > http://www.kernel.org/pub/linux/libs/security/linux-privs/README > [7] LSM - Linux Security Module project > http://www.linuxsecurity.com/articles/forums_article-2854.html > http://mail.wirex.com/pipermail/linux-security-module/2001-October/002310.html > [8] DMAPI/XDSM specification - implemented in XFS via extended attributes > http://www.opengroup.org/onlinepubs/9657099/ > http://oss.sgi.com/projects/xfs/dmapi.html > [9] SnapFS snapshot filesystem > http://lwn.net/2001/0308/a/snapfs.php3 > [10] Will Dyson's resurrection of BeFS for Linux 2.4 > http://cs.earlham.edu/~will/software/linux/kernel/BeFS.html > http://marc.theaimsgroup.com/?l=linux-fsdevel&m=100431033704112&w=2 > > > diff -Naur 2.4.14-pristine/arch/i386/kernel/entry.S 2.4.14-reserved/arch/i386/kernel/entry.S > --- 2.4.14-pristine/arch/i386/kernel/entry.S Sat Nov 3 12:18:49 2001 > +++ 2.4.14-reserved/arch/i386/kernel/entry.S Wed Nov 7 10:02:59 2001 > @@ -622,6 +622,9 @@ > .long SYMBOL_NAME(sys_ni_syscall) /* Reserved for Security */ > .long SYMBOL_NAME(sys_gettid) > .long SYMBOL_NAME(sys_readahead) /* 225 */ > + .long SYMBOL_NAME(sys_ni_syscall) /* reserved for extattr */ > + .long SYMBOL_NAME(sys_ni_syscall) /* reserved for lextattr */ > + .long SYMBOL_NAME(sys_ni_syscall) /* reserved for fextattr */ > > .rept NR_syscalls-(.-sys_call_table)/4 > .long SYMBOL_NAME(sys_ni_syscall) > diff -Naur 2.4.14-pristine/include/asm-i386/unistd.h 2.4.14-reserved/include/asm-i386/unistd.h > --- 2.4.14-pristine/include/asm-i386/unistd.h Thu Oct 18 03:03:03 2001 > +++ 2.4.14-reserved/include/asm-i386/unistd.h Wed Nov 7 10:02:59 2001 > @@ -230,6 +230,9 @@ > #define __NR_security 223 /* syscall for security modules */ > #define __NR_gettid 224 > #define __NR_readahead 225 > +#define __NR_extattr 226 /* syscall for extended attributes */ > +#define __NR_lextattr 227 /* syscall for extended attributes */ > +#define __NR_fextattr 228 /* syscall for extended attributes */ > > /* user-visible error numbers are in the range -1 - -124: see */ > > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Nathan From owner-linux-xfs@oss.sgi.com Tue Nov 6 18:51:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA72pW925913 for linux-xfs-outgoing; Tue, 6 Nov 2001 18:51:32 -0800 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 fA72pS025888 for ; Tue, 6 Nov 2001 18:51:28 -0800 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 SAA00901 for ; Tue, 6 Nov 2001 18:50:59 -0800 (PST) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA13638; Tue, 6 Nov 2001 18:50:52 -0800 (PST) Message-ID: <3BE8A074.8494050A@sgi.com> Date: Tue, 06 Nov 2001 20:46:12 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: Sean Elble CC: mingo@elte.hu, Keith Owens , Tux mailing list , XFS Mailing list Subject: Re: XFS+Tux = patch trouble References: <02bb01c16720$7fd7d470$0a00a8c0@intranet.mp3s.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just wanted to interject something amidst the talk about huge xfs patches... the xfs filesystem code is pretty big, yes, but the core xfs-only kernel patch for 2.4.13 is only around 48k. That includes context lines, Makefiles, Configure.help, MAINTAINERS, Changes, and other documentation that's really not a change to the kernel. Yes, XFS affects the core kernel. But it's not as much code as the conventional wisdom seems to think it is. :) -Eric (Plenty of snipping below) Sean Elble wrote: > > The XFS patch is huge, > > > Ingo Molnar wrote: > > this is a pretty big patch even just > > counting the core changes. > > > > Ingo -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Nov 6 19:03:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA733iH26290 for linux-xfs-outgoing; Tue, 6 Nov 2001 19:03:44 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA733c026267 for ; Tue, 6 Nov 2001 19:03:38 -0800 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 TAA03106 for ; Tue, 6 Nov 2001 19:03:40 -0800 (PST) mail_from (sandeen@sgi.com) Received: from sgi.com (root@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA34714; Tue, 6 Nov 2001 19:03:05 -0800 (PST) Message-ID: <3BE8A352.DC62DE63@sgi.com> Date: Tue, 06 Nov 2001 20:58:26 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i586) X-Accept-Language: en MIME-Version: 1.0 To: William Ey CC: linux-xfs@oss.sgi.com Subject: Re: Adaptec dpt_i2o SCSI raid card References: <200111070124.fA71OJg24074@oss.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi William - Are you talking about the XFS/RH installer CD, I assume? If you have a driver disk, you probably have modules which were compiled for a different kernel version - i.e. Red Hat's kernel, not the XFS-enabled kernel. (Also probably the original RH 2.4.7 kernel; ours is now at 2.4.9). The modules from your driver disk probably aren't even loaded - this is why you don't have the devices available. You can check with "lsmod" on virtual console #2 during the install. There's no _particularly_ easy way around this, I'm afraid. Doug Ledford has a driver disk development kit on his web site at redhat.com, that would be the place to start. http://people.redhat.com/dledford/ -Eric > Hi > > In the faq for linux-xfs there is reference to the Aic7xxx driver = > crashing during kernel boot. I have a adaptec 2100S SCSI raid controller = > that needs a RH driver disk during boot, as a part of this driver disk = > the Aic7xxx and the dpt_i2o modules are loaded, when it comes time to = > partition drives etc a message comes up saying no vaild devices on which = > to create new file system, is this because the aic7xxx driver is = > crashing and if so is there a fix for this. > > Thank > > Will -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Nov 6 19:07:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA737al27521 for linux-xfs-outgoing; Tue, 6 Nov 2001 19:07:36 -0800 Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA737P027194 for ; Tue, 6 Nov 2001 19:07:25 -0800 Received: from static031-81-151-24.nm01-c3.cpe.charter-ne.com ([24.151.81.31] helo=dhcp10) by scaup.prod.itd.earthlink.net with smtp (Exim 3.33 #1) id 161J3j-0004nQ-00; Tue, 06 Nov 2001 19:07:23 -0800 Message-ID: <03bd01c16739$2318cff0$0a00a8c0@intranet.mp3s.com> Reply-To: "Sean Elble" From: "Sean Elble" To: "Eric Sandeen" Cc: "Tux mailing list" , "XFS Mailing list" References: <02bb01c16720$7fd7d470$0a00a8c0@intranet.mp3s.com> <3BE8A074.8494050A@sgi.com> Subject: Re: XFS+Tux = patch trouble Date: Tue, 6 Nov 2001 22:05:40 -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 Whoa . . . I didn't realize that the patch was only 48k. But does that include all the XFS "dependences", like the Page Buffer code, etc.? I would imagine that it does, but just checking . . . If that is indeed the case, why no response from Linus? Maybe each one of the XFS Mailing List members should "remind" him about what a great file system we have over here. :-) And if Linus doesn't accept it, try Alan Cox, or any other Linux developer who often sees his/her changes merged in to the Linus tree . . . with any luck, maybe Linus will "miss" XFS. There are quite a few changes with XFS, but they are stable, that's for sure. Hell, considering the level of testing on recent kernels (2.4.14's loop.c problem, for example), Linux/XFS kernels are probably _more_ stable than any Linus kernel, especially with the fact that SGI tests released kernels! Anyway, enough ranting . . . back to work. :-) ----------------------------------------------- Sean P. Elble Editor, Writer, Co-Webmaster ReactiveLinux.com (Formerly MaximumLinux.org) http://www.reactivelinux.com/ elbles@reactivelinux.com ----------------------------------------------- ----- Original Message ----- From: "Eric Sandeen" To: "Sean Elble" Cc: ; "Keith Owens" ; "Tux mailing list" ; "XFS Mailing list" Sent: Tuesday, November 06, 2001 9:46 PM Subject: Re: XFS+Tux = patch trouble > Just wanted to interject something amidst the talk about huge xfs > patches... the xfs filesystem code is pretty big, yes, but the core > xfs-only kernel patch for 2.4.13 is only around 48k. That includes > context lines, Makefiles, Configure.help, MAINTAINERS, Changes, and > other documentation that's really not a change to the kernel. > > Yes, XFS affects the core kernel. But it's not as much code as the > conventional wisdom seems to think it is. :) > > -Eric > > (Plenty of snipping below) > > Sean Elble wrote: > > > > The XFS patch is huge, > > > > > Ingo Molnar wrote: > > > > this is a pretty big patch even just > > > counting the core changes. > > > > > > Ingo > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Nov 6 19:21:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA73LRL29143 for linux-xfs-outgoing; Tue, 6 Nov 2001 19:21:27 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA73LL029119 for ; Tue, 6 Nov 2001 19:21:22 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id fA73LFK01143 for ; Tue, 6 Nov 2001 19:21:16 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA19840; Wed, 7 Nov 2001 14:19:58 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA08715; Wed, 7 Nov 2001 14:19:57 +1100 (AEDT) Date: Wed, 7 Nov 2001 14:19:56 +1100 From: Nathan Scott To: Andi Kleen Cc: Linus Torvalds , Andreas Gruenbacher , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, acl-devel@bestbits.at, linux-xfs@oss.sgi.com Subject: Re: [RFC][PATCH] extended attributes Message-ID: <20011107141956.F591676@wobbly.melbourne.sgi.com> References: <20011107111224.C591676@wobbly.melbourne.sgi.com> <20011107023218.A4754@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011107023218.A4754@wotan.suse.de>; from ak@suse.de on Wed, Nov 07, 2001 at 02:32:18AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hello again Andi, On Wed, Nov 07, 2001 at 02:32:18AM +0100, Andi Kleen wrote: > I think it would be better to have a statefull readdir instead. > The kernel supports it via the ->private_data field of struct file > (not through fork,but that looks like a generic vfs bug) > > EA_FIRST_ENTRY to reset the fd the first entry, EA_READ_ENTRY to > read the next one. I'm not sure this would work for the extattr/lextattr variants where we don't have an fd to hold the state. Should the list operation be restricted to the fextattr variant, perhaps? I'm not sure about all the implications of that, will have to see what everyone else thinks I guess. eg. the opening of the file before allowing a list operation could have implications for XFSs DMAPI support (open might recall data from tape), where the management tools need to be able to list these DMAPI related attributes without affecting the backing storage, I believe - I'll have to ask some DMAPI gurus about that one though. Thanks for the input. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Nov 6 20:39:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA74d9930217 for linux-xfs-outgoing; Tue, 6 Nov 2001 20:39:09 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA74d3030194 for ; Tue, 6 Nov 2001 20:39:03 -0800 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 UAA07364 for ; Tue, 6 Nov 2001 20:38:59 -0800 (PST) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA79567; Wed, 7 Nov 2001 15:37:40 +1100 (AEDT) Date: Wed, 7 Nov 2001 15:37:40 +1100 From: Timothy Shimmin To: Jeff Breitner Cc: linux-xfs@oss.sgi.com Subject: Re: Interesting XFS Behavior Message-ID: <20011107153740.L52179@boing.melbourne.sgi.com> References: <20011105225039.A599@asterix.gallien.de> <1005058628.15251.15.camel@jen.americas.sgi.com> <01110610360706.01823@office3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <01110610360706.01823@office3>; from memptr@gatecom.com on Tue, Nov 06, 2001 at 10:36:07AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Jeff, On Tue, Nov 06, 2001 at 10:36:07AM -0500, Jeff Breitner wrote: > > I have been goofing around trying to mimic the chattr -/+i features of ext2. > I figured out that I can keep directories from being deleted if I copy > /dev/null into a hidden file, say .donotdelete and then chmod 000 > .donotdelete. > > This keeps users from killing off the directory as they are greeted with a > "permission denied" if they try an rm -r or rmdir. > > However, what's interesting is that after the user attempts this, the null > file ".donotdelete" disappears. Where does it go? And even though it's > gone, further attempts at removal are still met with "permission denied". > As user root, the file can't be listed nor deleted by name -- it just > vanishes although something thinks it is there because only root can kill the > directory containing the null file. > > This is the behavior on my Irix 6.2 box as well (a feather in the cap of > consistency). > > Any ideas what's going on? > I can't make this happen on 6.2 or linux. I must not be doing what you're doing. What were the exact steps ? mkdir testdir cd testdir cp /dev/null .donotdelete (or use dd or touch) chmod 000 .donotdelete cd .. rm -r ./testdir --Tim From owner-linux-xfs@oss.sgi.com Tue Nov 6 20:47:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA74lRw30474 for linux-xfs-outgoing; Tue, 6 Nov 2001 20:47:27 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA74lI030452 for ; Tue, 6 Nov 2001 20:47:19 -0800 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 UAA03914 for ; Tue, 6 Nov 2001 20:47:18 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id PAA25368; Wed, 7 Nov 2001 15:46:16 +1100 Date: Wed, 7 Nov 2001 15:46:16 +1100 From: Keith Owens Message-Id: <200111070446.PAA25368@sherman.melbourne.sgi.com> Subject: TAKE - Update XFS kbuild 2.5 support to release 1.5 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk kbuild 2.5 release 1.5 (against kernel 2.4.14) removed some special case commands. Update the XFS files to reflect the change. For the record, this is the process to compile XFS using kbuild 2.5. ========== Using kbuild 2.5 with the current XFS tree is a little unusual because it must not disturb the existing kbuild 2.4 code, XFS must still build using the old method. To build XFS using kbuild 2.5 you need 3 directories, source tree 000 containing the main kbuild 2.5 code, source tree 001 containing XFS, KDB plus the full kernel and an object tree. This is not the normal configuration but it works without including all of kbuild 2.5 in the XFS tree. Create a file which sets and exports the required variables, replacing /build/kaos with your build area, and source that file to set the variables. Note that source tree 001 is the linux sub directory of your XFS workarea or CVS tree, do not point at the top of the workarea or CVS tree. # cat trees-2.4.x-xfs export KBUILD_SRCTREE_000=/build/kaos/2.4.x-xfs-kbuild-2.5 export KBUILD_SRCTREE_001=/build/kaos/2.4.x-xfs/linux export KBUILD_OBJTREE=/build/kaos/object-2.4.x-xfs # source trees-2.4.x-xfs Remove any files in the main kbuild 2.5 tree and the object tree. Create the object tree and copy in an initial config. # rm -rf $KBUILD_SRCTREE_000 $KBUILD_OBJTREE # mkdir $KBUILD_OBJTREE # cp .config $KBUILD_OBJTREE Fetch the kbuild 2.5 patch that corresponds to the current XFS kernel from http://sourceforge.net/projects/kbuild/. This was tested on kbuild-2.5-2.4.14-1.bz2. kbuild 2.5 is designed to patch a current kernel but we want a separate tree containing just the kbuild 2.5 code plus the critical files that kbuild 2.5 needs, leaving the XFS tree untouched. # cp -al $KBUILD_SRCTREE_001 $KBUILD_SRCTREE_000 # cd $KBUILD_SRCTREE_000 # bzcat ~/kbuild-2.5-2.4.14-1.bz2 | patch -p1 # find \( -path ./scripts -prune \) -o \( -type f -links +1 \! -name Makefile -print \) | xargs rm # find -type d -depth | xargs rmdir 2>/dev/null That leaves source tree 000 containing just the main kbuild 2.5 files plus the scripts (for make *config) and the kbuild 2.4 top level Makefile (for kernel version). You can now build XFS+KDB using kbuild 2.5. On a 4 way processor with plenty of memory, I do this # make -j8 -f $KBUILD_SRCTREE_000/Makefile-2.5 oldconfig installable # sudo make -j8 -f $KBUILD_SRCTREE_000/Makefile-2.5 install The only disadvantage with this approach is that the configure help is read from the XFS tree so you do not get help for the kbuild 2.5 specific options. Can't have everything. You can browse $KBUILD_SRCTREE_000/Documentation/Configure.help for the kbuild 2.5 entries. As always, Documentation/kbuild/kbuild-2.5.txt is your friend. Enjoy. ========== Date: Tue Nov 6 20:31:46 PST 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:106234a linux/fs/Makefile.in.append - 1.3 linux/fs/xfs/Makefile.in - 1.5 linux/fs/xfs_support/Makefile.in - 1.2 linux/kdb/Makefile.in - 1.4 linux/kdb/modules/Makefile.in - 1.4 linux/drivers/md/Makefile.in - 1.3 From owner-linux-xfs@oss.sgi.com Tue Nov 6 20:50:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA74oN330631 for linux-xfs-outgoing; Tue, 6 Nov 2001 20:50:23 -0800 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 fA74oL030609 for ; Tue, 6 Nov 2001 20:50:21 -0800 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 UAA23079 for ; Tue, 6 Nov 2001 20:50:11 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id PAA26390; Wed, 7 Nov 2001 15:49:18 +1100 Date: Wed, 7 Nov 2001 15:49:18 +1100 From: Keith Owens Message-Id: <200111070449.PAA26390@sherman.melbourne.sgi.com> Subject: TAKE - Correct link order of xfs and xfsidbg in kbuild 2.5 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Correct link order of xfs and xfsidbg in kbuild 2.5 Date: Tue Nov 6 20:48:51 PST 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:106236a linux/fs/xfs/Makefile.in - 1.6 From owner-linux-xfs@oss.sgi.com Tue Nov 6 21:06:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA756gb31042 for linux-xfs-outgoing; Tue, 6 Nov 2001 21:06:42 -0800 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 fA756a031020 for ; Tue, 6 Nov 2001 21:06:36 -0800 Received: from fuzzy.melbourne.sgi.com (root@fuzzy.melbourne.sgi.com [134.14.55.199]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA00059 for ; Tue, 6 Nov 2001 21:06:07 -0800 (PST) mail_from (fsgqa@fuzzy.melbourne.sgi.com) Received: (from fsgqa@localhost) by fuzzy.melbourne.sgi.com (8.9.3/8.9.3) id PAA17892 for linux-xfs@oss.sgi.com; Wed, 7 Nov 2001 15:26:46 +1100 Date: Wed, 7 Nov 2001 15:26:46 +1100 From: FSG QA Account Message-Id: <200111070426.PAA17892@fuzzy.melbourne.sgi.com> Subject: TAKE - xfstests for xfsdump/xfsrestore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Change xfstests/common.dump so that we don't need the 4 quota variants for output files - go back to having just one .out file for each test. (a p_delete of the quota output files will be coming shortly) This has been a _real_ pain when one needs to update the output files when xfsdump/xfsrestore output has changed. --Tim Date: Tue Nov 6 20:57:23 PST 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:106235a cmd/xfstests/common.dump - 1.19 - Add code to do the checking of quota output from dump and restore when the quotas are turned on. The output is filtered so that we no longer need 4 versions of the output files for the different user/group quota variants. cmd/xfstests/047 - 1.3 cmd/xfstests/028 - 1.3 - Don't set up a quota output file - no longer need this. cmd/xfstests/047.out - 1.3 cmd/xfstests/046.out - 1.3 cmd/xfstests/043.out - 1.3 cmd/xfstests/039.out - 1.3 cmd/xfstests/038.out - 1.3 cmd/xfstests/037.out - 1.3 cmd/xfstests/036.out - 1.3 cmd/xfstests/035.out - 1.3 cmd/xfstests/028.out - 1.3 cmd/xfstests/027.out - 1.3 cmd/xfstests/026.out - 1.3 cmd/xfstests/025.out - 1.3 cmd/xfstests/024.out - 1.3 cmd/xfstests/023.out - 1.3 cmd/xfstests/022.out - 1.3 cmd/xfstests/055.out - 1.3 cmd/xfstests/056.out - 1.3 - Only need 1 out file as the quota output is now checked and then filtered out. cmd/xfstests/061 - 1.2 - Make sure that the quota checks aren't done for restoring of the checked in dump file which doesn't have quotas. From owner-linux-xfs@oss.sgi.com Tue Nov 6 21:21:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA75LTX31330 for linux-xfs-outgoing; Tue, 6 Nov 2001 21:21:29 -0800 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 fA75LP031308 for ; Tue, 6 Nov 2001 21:21:25 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id GAA1766678 for ; Wed, 7 Nov 2001 06:21:16 +0100 (CET) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id QAA04464; Wed, 7 Nov 2001 16:20:13 +1100 Date: Wed, 7 Nov 2001 16:20:13 +1100 From: Keith Owens Message-Id: <200111070520.QAA04464@sherman.melbourne.sgi.com> Subject: TAKE - Sync with kdb v1.9-2.4.14 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Nov 6 21:19:47 PST 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:106237a linux/kdb/ChangeLog - 1.10 From owner-linux-xfs@oss.sgi.com Tue Nov 6 21:43:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA75hmj31640 for linux-xfs-outgoing; Tue, 6 Nov 2001 21:43:48 -0800 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 fA75he031618 for ; Tue, 6 Nov 2001 21:43:40 -0800 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 VAA26306 for ; Tue, 6 Nov 2001 21:43:30 -0800 (PST) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA85382 for linux-xfs@oss.sgi.com; Wed, 7 Nov 2001 16:42:21 +1100 (EST) Date: Wed, 7 Nov 2001 16:42:21 +1100 (EST) From: Timothy Shimmin Message-Id: <200111070542.QAA85382@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsdump/xfsrestore xfstests quota out files Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Delete the quota out files for the dump tests. --Tim Date: Tue Nov 6 21:40:40 PST 2001 Workarea: snort.melbourne.sgi.com:/hosts/snort/home/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:106238a cmd/xfstests/026.noquota - 1.3 cmd/xfstests/027.noquota - 1.3 cmd/xfstests/046.noquota - 1.3 cmd/xfstests/056.noquota - 1.3 cmd/xfstests/046.ugquota - 1.4 cmd/xfstests/026.grpquota - 1.4 cmd/xfstests/026.ugquota - 1.4 cmd/xfstests/026.usrquota - 1.4 cmd/xfstests/027.grpquota - 1.4 cmd/xfstests/027.ugquota - 1.4 cmd/xfstests/027.usrquota - 1.4 cmd/xfstests/046.grpquota - 1.4 cmd/xfstests/056.usrquota - 1.4 cmd/xfstests/046.usrquota - 1.4 cmd/xfstests/056.grpquota - 1.5 cmd/xfstests/056.ugquota - 1.5 cmd/xfstests/028.usrquota - 1.3 cmd/xfstests/028.grpquota - 1.3 cmd/xfstests/028.noquota - 1.4 cmd/xfstests/047.usrquota - 1.3 cmd/xfstests/028.ugquota - 1.3 cmd/xfstests/047.noquota - 1.3 cmd/xfstests/047.ugquota - 1.3 cmd/xfstests/047.grpquota - 1.3 cmd/xfstests/022.grpquota - 1.4 cmd/xfstests/022.noquota - 1.3 cmd/xfstests/036.ugquota - 1.4 cmd/xfstests/022.ugquota - 1.4 cmd/xfstests/022.usrquota - 1.4 cmd/xfstests/023.grpquota - 1.4 cmd/xfstests/023.noquota - 1.3 cmd/xfstests/036.usrquota - 1.4 cmd/xfstests/023.ugquota - 1.4 cmd/xfstests/023.usrquota - 1.4 cmd/xfstests/024.grpquota - 1.4 cmd/xfstests/024.noquota - 1.3 cmd/xfstests/055.usrquota - 1.4 cmd/xfstests/024.ugquota - 1.4 cmd/xfstests/024.usrquota - 1.4 cmd/xfstests/025.grpquota - 1.4 cmd/xfstests/025.noquota - 1.3 cmd/xfstests/055.ugquota - 1.4 cmd/xfstests/025.ugquota - 1.4 cmd/xfstests/025.usrquota - 1.4 cmd/xfstests/035.grpquota - 1.4 cmd/xfstests/035.noquota - 1.3 cmd/xfstests/055.noquota - 1.3 cmd/xfstests/035.ugquota - 1.4 cmd/xfstests/035.usrquota - 1.4 cmd/xfstests/036.grpquota - 1.4 cmd/xfstests/036.noquota - 1.3 cmd/xfstests/055.grpquota - 1.4 cmd/xfstests/043.usrquota - 1.4 cmd/xfstests/043.ugquota - 1.4 cmd/xfstests/037.grpquota - 1.4 cmd/xfstests/037.noquota - 1.3 cmd/xfstests/043.noquota - 1.3 cmd/xfstests/037.ugquota - 1.4 cmd/xfstests/037.usrquota - 1.4 cmd/xfstests/038.grpquota - 1.4 cmd/xfstests/038.noquota - 1.3 cmd/xfstests/043.grpquota - 1.4 cmd/xfstests/038.ugquota - 1.4 cmd/xfstests/038.usrquota - 1.4 cmd/xfstests/039.grpquota - 1.4 cmd/xfstests/039.noquota - 1.3 cmd/xfstests/039.usrquota - 1.4 cmd/xfstests/039.ugquota - 1.4 - The separate quota output files are not longer needed. The output is filtered and so there is only a .out file again. From owner-linux-xfs@oss.sgi.com Tue Nov 6 21:52:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA75qeF31881 for linux-xfs-outgoing; Tue, 6 Nov 2001 21:52:40 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA75qb031859 for ; Tue, 6 Nov 2001 21:52:37 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fA75qVT24354 for ; Tue, 6 Nov 2001 21:52:31 -0800 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id QAA07458; Wed, 7 Nov 2001 16:51:30 +1100 Date: Wed, 7 Nov 2001 16:51:30 +1100 From: Keith Owens Message-Id: <200111070551.QAA07458@sherman.melbourne.sgi.com> Subject: TAKE - Delete some leftovers from the old lvm patch Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Nov 6 21:51:04 PST 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:106240a linux/drivers/md/lvm-internal.h - 1.2 linux/drivers/md/lvm-fs.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Nov 6 23:22:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA77MJA01169 for linux-xfs-outgoing; Tue, 6 Nov 2001 23:22:19 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA77ME001146 for ; Tue, 6 Nov 2001 23:22:15 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 161N2G-0000k4-00; Wed, 07 Nov 2001 08:22:08 +0100 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Date: Wed, 07 Nov 2001 08:22:07 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2370) For Windows 2000 (5.0.2195;2) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: WANTED: most stable 2.4 kernel ver. plus XFS patches for SMP machines Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi there, we would like to migrate our fileserver to XFS as quickly as possible. Therefore, can you recommend the most stable 2.4.x kernel version plus suitable XFS patches? In case it matters we run Debian stable. We will add the "Bunk" repository to our APT sources list in order to update the system to be 2.4-ready when it's time to migrate. Thanks, Ralf -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Nov 6 23:31:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA77VuD01439 for linux-xfs-outgoing; Tue, 6 Nov 2001 23:31:56 -0800 Received: from mail.hs.tecmath.com (www.tecmath.de [213.69.212.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA77Vq001416 for ; Tue, 6 Nov 2001 23:31:52 -0800 Received: from tmsgi7.humanmodeling.tecmath.de ([192.168.98.14]) by mail.hs.tecmath.com with esmtp (Exim 3.33 #1) id 161NBM-0001tx-00; Wed, 07 Nov 2001 08:31:32 +0100 Date: Wed, 7 Nov 2001 08:31:35 +0100 From: Martin Apel X-X-Sender: apel@tmsgi7.humanmodeling.tecmath.de To: "Ralf G. R. Bergs" cc: Linux XFS Mailing List Subject: Re: WANTED: most stable 2.4 kernel ver. plus XFS patches for SMP machines 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, 7 Nov 2001, Ralf G. R. Bergs wrote: > Hi there, > > we would like to migrate our fileserver to XFS as quickly as possible. > > Therefore, can you recommend the most stable 2.4.x kernel version plus suitable > XFS patches? > > In case it matters we run Debian stable. We will add the "Bunk" repository to > our APT sources list in order to update the system to be 2.4-ready when it's > time to migrate. We are currently running a 2.4.12 kernel on a SMP machine serving 270 G from a hardware RAID 5 system via NFS and Samba. I used a standard kernel and then applied the following patches: linux-2.4.12-xfs-2001-10-11.patch.bz2 LVM 1.0.1-rc4 If you are planning to serve NFS you should also apply one patch which is part of 2.4.13. I can send it to you if you want to. The setup described above works very stable at our site. Martin From owner-linux-xfs@oss.sgi.com Wed Nov 7 00:11:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA78BUB02145 for linux-xfs-outgoing; Wed, 7 Nov 2001 00:11:30 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA78BP002123 for ; Wed, 7 Nov 2001 00:11:25 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 161Nnr-0000od-00; Wed, 07 Nov 2001 09:11:19 +0100 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Cc: "Martin Apel" Date: Wed, 07 Nov 2001 09:11:18 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2370) For Windows 2000 (5.0.2195;2) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: WANTED: most stable 2.4 kernel ver. plus XFS patches for SMP machines Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 07 Nov 2001 08:31:35 +0100, Martin Apel wrote: [...] >We are currently running a 2.4.12 kernel on a SMP machine serving 270 G >from a hardware RAID 5 system via NFS and Samba. I used a standard kernel This is roughly the same size we will be serving. We also use a hardware RAID. We will mainly serve for Windows boxen, i.e. using Samba, but there is also a minor need for NFS service. >and then applied the following patches: > linux-2.4.12-xfs-2001-10-11.patch.bz2 > LVM 1.0.1-rc4 Just for my education: Why is it that you use LVM? To be able to grow the filesystem while it's online? Please reply off-list if you feel this is off- topic here. >If you are planning to serve NFS you should also apply one patch which >is part of 2.4.13. I can send it to you if you want to. Interesting question: Then why aren't you using 2.4.13? :-) Thanks so far for your advice. -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Wed Nov 7 00:46:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA78kRa03164 for linux-xfs-outgoing; Wed, 7 Nov 2001 00:46:27 -0800 Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA78kJ003142 for ; Wed, 7 Nov 2001 00:46:21 -0800 Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id fA78kAR13235 for ; Wed, 7 Nov 2001 17:46:11 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id fA78k9w29918 for ; Wed, 7 Nov 2001 17:46:09 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id fA78k8i00395 for ; Wed, 7 Nov 2001 17:46:09 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA440 for ; Wed, 7 Nov 2001 17:46:05 +0900 Received: FROM noshiro.bsd.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Wed Nov 07 17:46:03 2001 +0900 Received: from localhost (localhost [127.0.0.1]) by noshiro.bsd.tnes.nec.co.jp (Postfix) with ESMTP id 6C8816619; Wed, 7 Nov 2001 17:46:03 +0900 (JST) To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: POSIX error code In-Reply-To: <1004978054.10877.8.camel@jen.americas.sgi.com> References: <20011105185836G.masano@tnes.nec.co.jp> <1004978054.10877.8.camel@jen.americas.sgi.com> X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Artificial Intelligence) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011107174602S.masano@tnes.nec.co.jp> Date: Wed, 07 Nov 2001 17:46:02 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 40 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks for the quick response. But I left out the `rename'... ;-( Index: linux/fs/xfs/xfs_rename.c =================================================================== RCS file: /usr/localmnt/xfs/cvsroot/linux-2.4-xfs/linux/fs/xfs/xfs_rename.c,v retrieving revision 1.31 diff -u -r1.31 xfs_rename.c --- linux/fs/xfs/xfs_rename.c 2001/04/11 01:44:54 1.31 +++ linux/fs/xfs/xfs_rename.c 2001/11/07 07:42:07 @@ -665,10 +665,10 @@ } src_namelen = strlen(src_name); if (src_namelen >= MAXNAMELEN) - return XFS_ERROR(EINVAL); + return XFS_ERROR(ENAMETOOLONG); target_namelen = strlen(target_name); if (target_namelen >= MAXNAMELEN) - return XFS_ERROR(EINVAL); + return XFS_ERROR(ENAMETOOLONG); src_dp = XFS_BHVTOI(src_dir_bdp); target_dp = XFS_BHVTOI(target_dir_bdp); if (DM_EVENT_ENABLED(src_dir_vp->v_vfsp, src_dp, DM_EVENT_RENAME) || From: Steve Lord Subject: Re: POSIX error code Date: 05 Nov 2001 10:34:14 -0600 Message-ID: <1004978054.10877.8.camel@jen.americas.sgi.com> > Yes, this does appear wrong, the Irix man pages say ENAMETOOLONG as > well, but the code says EINVAL, your code should show up in the tree > before too long. > > Thanks > > Steve Cheers -- masano From owner-linux-xfs@oss.sgi.com Wed Nov 7 01:53:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA79r6O04243 for linux-xfs-outgoing; Wed, 7 Nov 2001 01:53:06 -0800 Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA79qt004219 for ; Wed, 7 Nov 2001 01:52:55 -0800 Received: from erbenson.alaska.net (247-pm32.nwc.alaska.net [209.112.158.247]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id fA79qpY44800 for ; Wed, 7 Nov 2001 00:52:51 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 473F7394D for ; Wed, 7 Nov 2001 00:52:50 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id A649B1026B; Wed, 7 Nov 2001 00:52:50 -0900 (AKST) Date: Wed, 7 Nov 2001 00:52:50 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Interesting XFS Behavior Message-ID: <20011107005250.V887@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20011105225039.A599@asterix.gallien.de> <1005058628.15251.15.camel@jen.americas.sgi.com> <01110610360706.01823@office3> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QZH4cHGkEF3sxbiD" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01110610360706.01823@office3>; from memptr@gatecom.com on Tue, Nov 06, 2001 at 10:36:07AM -0500 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --QZH4cHGkEF3sxbiD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 06, 2001 at 10:36:07AM -0500, Jeff Breitner wrote: >=20 > I have been goofing around trying to mimic the chattr -/+i features of ex= t2. =20 > I figured out that I can keep directories from being deleted if I copy=20 > /dev/null into a hidden file, say .donotdelete and then chmod 000=20 > .donotdelete. that won't work, its the directory permissions that control whether you are allowed to delete a file, not the file's permissions. rm (or maybe only GNU rm) does warn you by default if you tell it to remove a file which you don't have write permission to, but if you answer y is will still remove it. > This keeps users from killing off the directory as they are greeted with = a=20 > "permission denied" if they try an rm -r or rmdir. i don't see how, unless the directory is sticky and owned by someone other then the user. adding support to XFS for chattr +i and +a should not be that difficult, these attributes should be storable in an extended attribute (root only and restricted by capabilities somehow). then just teach XFS about whatver syscall chattr is using. =20 > However, what's interesting is that after the user attempts this, the nul= l=20 > file ".donotdelete" disappears. Where does it go? And even though it's= =20 > gone, further attempts at removal are still met with "permission denied". > As user root, the file can't be listed nor deleted by name -- it just=20 > vanishes although something thinks it is there because only root can kill= the=20 > directory containing the null file. >=20 > This is the behavior on my Irix 6.2 box as well (a feather in the cap of= =20 > consistency). >=20 > Any ideas what's going on? =20 perhaps you don't have write permission to the parent directory? a directory like a file can only be removed if you have permission to the directory that contains it. of course root should not be affected by that. removing a non-empty directory results in `directory not empty' not a permission denied. =20 observe: eb@socrates ~$ ls -ld foo drwxr-xr-x 3 eb eb 4096 Nov 7 00:50 foo eb@socrates ~$ ls -lAR foo foo: total 8 drwxr-xr-x 2 root root 4096 Nov 7 00:48 bar drwxr-xr-x 2 root root 4096 Nov 7 00:49 root foo/bar: total 0 -rw-r--r-- 1 root root 0 Nov 7 00:48 baz foo/root: total 0 eb@socrates ~$ rm -rf foo rm: cannot unlink `foo/bar/baz': Permission denied rm: cannot remove directory `foo/bar': Directory not empty rm: cannot remove directory `foo': Directory not empty eb@socrates ~$ ls -l foo/ total 4 drwxr-xr-x 2 root root 4096 Nov 7 00:48 bar whereas say: eb@socrates ~$ ls -lAR /lost+found/ /lost+found/: total 0 eb@socrates ~$ rm -rf /lost+found/ rm: cannot remove directory `/lost+found': Permission denied eb@socrates ~$ hope that clears things up. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --QZH4cHGkEF3sxbiD 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 iEYEARECAAYFAjvpBHIACgkQJKx7GixEevxhmQCfc9r2SYA7h3XyO7qpkbyW+azO IyAAniK7xebx/LjsRnEuZcYvBcuc+ocg =CuS5 -----END PGP SIGNATURE----- --QZH4cHGkEF3sxbiD-- From owner-linux-xfs@oss.sgi.com Wed Nov 7 02:12:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7ACX404812 for linux-xfs-outgoing; Wed, 7 Nov 2001 02:12:33 -0800 Received: from ns.procomp.net (ns.procomp.net [195.109.47.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7ACP004788 for ; Wed, 7 Nov 2001 02:12:26 -0800 Received: from port001 (floink.xs4all.nl [213.84.65.168]) by ns.procomp.net (8.10.0/8.10.0) with SMTP id fA7ABhs17233 for ; Wed, 7 Nov 2001 11:11:43 +0100 Reply-To: From: "Joost van der Locht" To: Subject: RE: Adaptec dpt_i2o SCSI raid card Date: Wed, 7 Nov 2001 11:12:23 +0100 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) In-Reply-To: <3BE8A352.DC62DE63@sgi.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, First of all try using kernel 2.4.10 and later because there is the Adaptec driver standard available. For Redhat 7.1 is on the website of Adaptec (http://linuix.adaptec.com/linux_raid_unsupported.html) a driver disk available for Redhat 7.1 Creating an own driver disk can be done like this (thanks to Richard Sharpe, sharpe@ns.aus.com) www.cantech.net.au/plug/2001-06/msg00248.html greetings Joost van der Locht Technisch Directeur E*Cube BV Toernooiveld 214 - 6525 EC Nijmegen T: 024-3500437 - F: 024-3500613 http://www.e-cube.nl e-mail: joost@e-cube.nl ICQ UIN: 494145 > -----Oorspronkelijk bericht----- > Van: owner-linux-xfs@oss.sgi.com > [mailto:owner-linux-xfs@oss.sgi.com]Namens Eric Sandeen > Verzonden: woensdag 7 november 2001 3:58 > Aan: William Ey > CC: linux-xfs@oss.sgi.com > Onderwerp: Re: Adaptec dpt_i2o SCSI raid card > > > Hi William - > > Are you talking about the XFS/RH installer CD, I assume? If you have a > driver disk, you probably have modules which were compiled for a > different kernel version - i.e. Red Hat's kernel, not the XFS-enabled > kernel. (Also probably the original RH 2.4.7 kernel; ours is now at > 2.4.9). > > The modules from your driver disk probably aren't even loaded - this is > why you don't have the devices available. You can check with "lsmod" on > virtual console #2 during the install. > > There's no _particularly_ easy way around this, I'm afraid. Doug > Ledford has a driver disk development kit on his web site at redhat.com, > that would be the place to start. > http://people.redhat.com/dledford/ > > -Eric > > > Hi > > > > In the faq for linux-xfs there is reference to the Aic7xxx driver = > > crashing during kernel boot. I have a adaptec 2100S SCSI raid > controller = > > that needs a RH driver disk during boot, as a part of this driver disk = > > the Aic7xxx and the dpt_i2o modules are loaded, when it comes time to = > > partition drives etc a message comes up saying no vaild devices > on which = > > to create new file system, is this because the aic7xxx driver is = > > crashing and if so is there a fix for this. > > > > Thank > > > > Will > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > From owner-linux-xfs@oss.sgi.com Wed Nov 7 02:47:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7Ale205692 for linux-xfs-outgoing; Wed, 7 Nov 2001 02:47:40 -0800 Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7AlW005669 for ; Wed, 7 Nov 2001 02:47:33 -0800 Received: from toutatis.ipgp.jussieu.fr (root@toutatis.ipgp.jussieu.fr [134.157.26.27]) by shiva.jussieu.fr (8.11.3/jtpda-5.3.3) with ESMTP id fA7AlUN56734 for ; Wed, 7 Nov 2001 11:47:30 +0100 (CET) Received: from elrond.ipgp.jussieu.fr (elrond.ipgp.jussieu.fr [134.157.28.172]) by toutatis.ipgp.jussieu.fr (8.11.4/jtpda-5.3.3) with ESMTP id fA7AlNu19241 for ; Wed, 7 Nov 2001 11:47:23 +0100 (MET) From: moguilny@ipgp.jussieu.fr ( MOGUILNY Genevieve) Received: from (moguilny@localhost) by elrond.ipgp.jussieu.fr (8.8.8/jtpda-5.3) id LAA26443 for linux-xfs@oss.sgi.com; Wed, 7 Nov 2001 11:47:30 +0100 (MET) Date: Wed, 7 Nov 2001 11:47:30 +0100 (MET) Message-Id: <200111071047.LAA26443@elrond.ipgp.jussieu.fr> To: linux-xfs@oss.sgi.com Subject: xfs and nfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, We have installed XFS 1.0 on a RedHat 7.1 system with MegaRAID controller. On this machine, there are a hundred of homes, samba server... As we had problems with Remote/Local accesses on xfs partitions, we installed XFS 1.0.1. Since then, nfs stopiped working several times a day. In the var log, we have messages like : Nov 5 17:39:00 hera kernel: invalid operand: 0000 Nov 5 17:39:00 hera kernel: CPU: 0 Nov 5 17:39:00 hera kernel: EIP: 0010:[dput+20/324] Nov 5 17:39:00 hera kernel: EIP: 0010:[] Nov 5 17:39:00 hera kernel: EFLAGS: 00010246 Nov 5 17:39:00 hera kernel: eax: 00000000 ebx: d7878d60 ecx: c458de44 edx: 00178780 Nov 5 17:39:00 hera kernel: esi: d7878d60 edi: d7878ae0 ebp: d7878ae0 esp: c458de4c Nov 5 17:39:00 hera kernel: ds: 0018 es: 0018 ss: 0018 Nov 5 17:39:00 hera kernel: Process nfsd (pid: 1707, stackpage=c458d000) Nov 5 17:39:00 hera kernel: Stack: ffffffea d7878d60 d8903ee1 d7878d60 00000000 10482e8e d890 4258 d7878ae0 Nov 5 17:39:00 hera kernel: 00000000 c54ebe14 11270000 c54ebe04 4c1b9d86 c60779f8 0000 0000 ffffff8c Nov 5 17:39:00 hera kernel: 00000000 d89045d4 c6077800 10482e8e 00000000 00000000 0000 0001 c54ebe04 Nov 5 17:39:00 hera kernel: Call Trace: [] [] [] [] [ schedule+647/976] Nov 5 17:39:00 hera kernel: Call Trace: [] [] [] [] [ ] Nov 5 17:39:00 hera kernel: [] [] [] [] [] [] Nov 5 17:39:00 hera kernel: [] [] [] [] [] [kernel_thread+35/48] Nov 5 17:39:00 hera kernel: [] [] [] [] [] [] Nov 5 17:39:00 hera kernel: Nov 5 17:39:00 hera kernel: Code: 0f 0b ff 0b 0f 94 c0 84 c0 0f 84 1e 01 00 00 8d 73 20 39 73 And after that message, nobody could access their home space from a remote host. Do you have any idea of what could cause the problem ? Thank you in advance, Genevieve Moguilny DMPN - IPGP Case 89 - Tour 24 4 place Jussieu 75252 Paris cedex 05 Tel. 01 44 27 24 15 Fax 01 44 27 38 94 moguilny@ipgp.jussieu.fr From owner-linux-xfs@oss.sgi.com Wed Nov 7 03:09:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7B9eB06357 for linux-xfs-outgoing; Wed, 7 Nov 2001 03:09:40 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7B9a006329 for ; Wed, 7 Nov 2001 03:09:36 -0800 Received: (qmail 6159 invoked from network); 7 Nov 2001 11:09:33 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 7 Nov 2001 11:09:33 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 77630300090; Wed, 7 Nov 2001 22:09:30 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 5F14696; Wed, 7 Nov 2001 22:09:30 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: moguilny@ipgp.jussieu.fr ( MOGUILNY Genevieve) Cc: linux-xfs@oss.sgi.com Subject: Re: xfs and nfs In-reply-to: Your message of "Wed, 07 Nov 2001 11:47:30 BST." <200111071047.LAA26443@elrond.ipgp.jussieu.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Nov 2001 22:09:25 +1100 Message-ID: <2511.1005131365@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 7 Nov 2001 11:47:30 +0100 (MET), moguilny@ipgp.jussieu.fr ( MOGUILNY Genevieve) wrote: >Nov 5 17:39:00 hera kernel: EIP: 0010:[dput+20/324] >Nov 5 17:39:00 hera kernel: Call Trace: [] [] [] >[] [ >] You need to decode that oops before anybody can look at it. Run it through ksymoops, making sure that your modules environment has not changed since the oops. ftp://ftp.kernel.org/pub/linux/utils/kernel/ksymoops/v2.4 From owner-linux-xfs@oss.sgi.com Wed Nov 7 03:09:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7B9Po06301 for linux-xfs-outgoing; Wed, 7 Nov 2001 03:09:25 -0800 Received: from mta4-rme.xtra.co.nz (mta4-rme.xtra.co.nz [210.86.15.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7B9L006278 for ; Wed, 7 Nov 2001 03:09:21 -0800 Received: from mdew ([210.86.28.126]) by mta4-rme.xtra.co.nz with ESMTP id <20011107110914.HXXR13078.mta4-rme.xtra.co.nz@mdew> for ; Thu, 8 Nov 2001 00:09:14 +1300 Subject: XFS Limitations rather? From: mdew To: xfs Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 08 Nov 2001 11:21:36 +1300 Message-Id: <1005171696.369.7.camel@mdew> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I was looking at this page... http://www.suse.de/~aj/linux_lfs.html and notice that XFS indicates theres a 2T limitation under Linux, yet every other FS (ext2/resierfs/jfs) dont seem to have this limitation, why doesnt this "2T limitation" affect other file systems? From owner-linux-xfs@oss.sgi.com Wed Nov 7 03:30:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7BU3F06957 for linux-xfs-outgoing; Wed, 7 Nov 2001 03:30:03 -0800 Received: from atlas.cc.itu.edu.tr (atlas.cc.itu.edu.tr [160.75.2.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7BTo006922 for ; Wed, 7 Nov 2001 03:29:51 -0800 Received: from aontws4044 (AONTWS4044.cc.itu.edu.tr [160.75.5.44]) by atlas.cc.itu.edu.tr (8.11.2/8.11.2) with SMTP id fA7BTQZ01947; Wed, 7 Nov 2001 13:29:26 +0200 From: =?iso-8859-9?Q?=DEeref_Tufan_=DEen?= To: "'MOGUILNY Genevieve'" , Subject: RE: xfs and nfs Date: Wed, 7 Nov 2001 13:35:39 +0200 Message-ID: <003501c16780$53e00670$2c054ba0@aontws4044> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200111071047.LAA26443@elrond.ipgp.jussieu.fr> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I had the same problems with NFS (RH 7.1 + MegaRAID Controler too) . I was using RPMS from SGI (2.4.3) , then I compiled 2.4.9 with XFS patch. And the problem has gone. > -----Original Message----- > From: owner-linux-xfs@oss.sgi.com > [mailto:owner-linux-xfs@oss.sgi.com]On > Behalf Of MOGUILNY Genevieve > Sent: Wednesday, November 07, 2001 12:48 PM > To: linux-xfs@oss.sgi.com > Subject: xfs and nfs > > > Hello, > > We have installed XFS 1.0 on a RedHat 7.1 system > with MegaRAID controller. On this machine, > there are a hundred of homes, samba server... > As we had problems with Remote/Local accesses > on xfs partitions, we installed XFS 1.0.1. > Since then, nfs stopiped working several times a day. > In the var log, we have messages like : > > Nov 5 17:39:00 hera kernel: invalid operand: 0000 > Nov 5 17:39:00 hera kernel: CPU: 0 > Nov 5 17:39:00 hera kernel: EIP: 0010:[dput+20/324] > Nov 5 17:39:00 hera kernel: EIP: 0010:[] > Nov 5 17:39:00 hera kernel: EFLAGS: 00010246 > Nov 5 17:39:00 hera kernel: eax: 00000000 ebx: d7878d60 > ecx: c458de44 edx: 00178780 > Nov 5 17:39:00 hera kernel: esi: d7878d60 edi: d7878ae0 > ebp: d7878ae0 esp: c458de4c > Nov 5 17:39:00 hera kernel: ds: 0018 es: 0018 ss: 0018 > Nov 5 17:39:00 hera kernel: Process nfsd (pid: 1707, > stackpage=c458d000) > Nov 5 17:39:00 hera kernel: Stack: ffffffea d7878d60 > d8903ee1 d7878d60 00000000 10482e8e > d890 > 4258 d7878ae0 > Nov 5 17:39:00 hera kernel: 00000000 c54ebe14 > 11270000 c54ebe04 4c1b9d86 c60779f8 > 0000 > 0000 ffffff8c > Nov 5 17:39:00 hera kernel: 00000000 d89045d4 > c6077800 10482e8e 00000000 00000000 > 0000 > 0001 c54ebe04 > Nov 5 17:39:00 hera kernel: Call Trace: [] > [] [] > [] [ > schedule+647/976] > Nov 5 17:39:00 hera kernel: Call Trace: [] > [] [] > [] [ > ] > Nov 5 17:39:00 hera kernel: [] [] > [] [] > [ >] [] > Nov 5 17:39:00 hera kernel: [] [] > [] [] > [ >] [kernel_thread+35/48] > Nov 5 17:39:00 hera kernel: [] [] > [] [] > [ >] [] > Nov 5 17:39:00 hera kernel: > Nov 5 17:39:00 hera kernel: Code: 0f 0b ff 0b 0f 94 c0 84 c0 > 0f 84 1e 01 00 00 8d 73 20 39 > 73 > > > And after that message, nobody could access their home space > from a remote host. > > Do you have any idea of what could cause the problem ? > Thank you in advance, > > > Genevieve Moguilny > DMPN - IPGP > Case 89 - Tour 24 > 4 place Jussieu > 75252 Paris cedex 05 > Tel. 01 44 27 24 15 > Fax 01 44 27 38 94 > moguilny@ipgp.jussieu.fr From owner-linux-xfs@oss.sgi.com Wed Nov 7 03:51:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7BpKF07409 for linux-xfs-outgoing; Wed, 7 Nov 2001 03:51:20 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7BpB007387 for ; Wed, 7 Nov 2001 03:51:11 -0800 Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) 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 DAA05680 for ; Wed, 7 Nov 2001 03:51:09 -0800 (PST) mail_from (tbd@sgi.com) Received: from fsgi158.americas.sgi.com (fsgi158.americas.sgi.com [128.162.191.39]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id FAA30612; Wed, 7 Nov 2001 05:49:52 -0600 (CST) From: tbd@sgi.com Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id FAA02885; Wed, 7 Nov 2001 05:49:41 -0600 (CST) Message-Id: <200111071149.FAA02885@fsgi158.americas.sgi.com> Subject: Re: xfs and nfs To: tufan@itu.edu.tr (=?iso-8859-9?Q?=DEeref_Tufan_=DEen?=) Date: Wed, 7 Nov 2001 05:49:40 -0600 (CST) Cc: moguilny@ipgp.jussieu.fr ('MOGUILNY Genevieve'), linux-xfs@oss.sgi.com In-Reply-To: <003501c16780$53e00670$2c054ba0@aontws4044> from "=?iso-8859-9?Q?=DEeref_Tufan_=DEen?=" at Nov 07, 2001 01:35:39 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 had the same problems with NFS (RH 7.1 + MegaRAID Controler too) . I was > using RPMS from SGI (2.4.3) , then I compiled 2.4.9 with XFS patch. And the > problem has gone. > We saw the problem here too with 1.0.1 (SGI PV number 833948). In our case, it was also resolved with 2.4.9. Tad > > -----Original Message----- > > From: owner-linux-xfs@oss.sgi.com > > [mailto:owner-linux-xfs@oss.sgi.com]On > > Behalf Of MOGUILNY Genevieve > > Sent: Wednesday, November 07, 2001 12:48 PM > > To: linux-xfs@oss.sgi.com > > Subject: xfs and nfs > > > > > > Hello, > > > > We have installed XFS 1.0 on a RedHat 7.1 system > > with MegaRAID controller. On this machine, > > there are a hundred of homes, samba server... > > As we had problems with Remote/Local accesses > > on xfs partitions, we installed XFS 1.0.1. > > Since then, nfs stopiped working several times a day. > > In the var log, we have messages like : > > > > Nov 5 17:39:00 hera kernel: invalid operand: 0000 > > Nov 5 17:39:00 hera kernel: CPU: 0 > > Nov 5 17:39:00 hera kernel: EIP: 0010:[dput+20/324] > > Nov 5 17:39:00 hera kernel: EIP: 0010:[] > > Nov 5 17:39:00 hera kernel: EFLAGS: 00010246 > > Nov 5 17:39:00 hera kernel: eax: 00000000 ebx: d7878d60 > > ecx: c458de44 edx: 00178780 > > Nov 5 17:39:00 hera kernel: esi: d7878d60 edi: d7878ae0 > > ebp: d7878ae0 esp: c458de4c > > Nov 5 17:39:00 hera kernel: ds: 0018 es: 0018 ss: 0018 > > Nov 5 17:39:00 hera kernel: Process nfsd (pid: 1707, > > stackpage=c458d000) > > Nov 5 17:39:00 hera kernel: Stack: ffffffea d7878d60 > > d8903ee1 d7878d60 00000000 10482e8e > > d890 > > 4258 d7878ae0 > > Nov 5 17:39:00 hera kernel: 00000000 c54ebe14 > > 11270000 c54ebe04 4c1b9d86 c60779f8 > > 0000 > > 0000 ffffff8c > > Nov 5 17:39:00 hera kernel: 00000000 d89045d4 > > c6077800 10482e8e 00000000 00000000 > > 0000 > > 0001 c54ebe04 > > Nov 5 17:39:00 hera kernel: Call Trace: [] > > [] [] > > [] [ > > schedule+647/976] > > Nov 5 17:39:00 hera kernel: Call Trace: [] > > [] [] > > [] [ > > ] > > Nov 5 17:39:00 hera kernel: [] [] > > [] [] > > [ > >] [] > > Nov 5 17:39:00 hera kernel: [] [] > > [] [] > > [ > >] [kernel_thread+35/48] > > Nov 5 17:39:00 hera kernel: [] [] > > [] [] > > [ > >] [] > > Nov 5 17:39:00 hera kernel: > > Nov 5 17:39:00 hera kernel: Code: 0f 0b ff 0b 0f 94 c0 84 c0 > > 0f 84 1e 01 00 00 8d 73 20 39 > > 73 > > > > > > And after that message, nobody could access their home space > > from a remote host. > > > > Do you have any idea of what could cause the problem ? > > Thank you in advance, > > > > > > Genevieve Moguilny > > DMPN - IPGP > > Case 89 - Tour 24 > > 4 place Jussieu > > 75252 Paris cedex 05 > > Tel. 01 44 27 24 15 > > Fax 01 44 27 38 94 > > moguilny@ipgp.jussieu.fr > From owner-linux-xfs@oss.sgi.com Wed Nov 7 04:13:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7CDdC08163 for linux-xfs-outgoing; Wed, 7 Nov 2001 04:13:39 -0800 Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7CDV008139 for ; Wed, 7 Nov 2001 04:13:33 -0800 Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id fA7CDPR12241 for ; Wed, 7 Nov 2001 21:13:25 +0900 (JST) Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id fA7CDOa00939 for ; Wed, 7 Nov 2001 21:13:24 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv.nec.co.jp (8.11.6/3.7W-MAILSV-NEC) with ESMTP id fA7CDNR17699 for ; Wed, 7 Nov 2001 21:13:23 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA120 for ; Wed, 7 Nov 2001 21:13:22 +0900 Received: FROM noshiro.bsd.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Wed Nov 07 21:13:21 2001 +0900 Received: from localhost (localhost [127.0.0.1]) by noshiro.bsd.tnes.nec.co.jp (Postfix) with ESMTP id 1C5CC6619 for ; Wed, 7 Nov 2001 21:13:21 +0900 (JST) To: linux-xfs@oss.sgi.com Subject: xfs_growfs -m X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Artificial Intelligence) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011107211320I.masano@tnes.nec.co.jp> Date: Wed, 07 Nov 2001 21:13:20 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 44 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk May I reduce the maximum percentage of inodes with "xfs_growfs -m" ? `df' showed an negative value: $ df -i /mnt/masano1 Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda7 13216 9472 3744 72% /mnt/masano1 # xfs_growfs -m 5 /mnt/masano1 ... inode max percent changed from 25 to 5 $ df -i /mnt/masano1 Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda7 13216 9472 3744 72% /mnt/masano1 # xfs_growfs -m 3 /mnt/masano1 ... inode max percent changed from 5 to 3 $ df -i /mnt/masano1 Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda7 13216 9472 3744 72% /mnt/masano1 # xfs_growfs -m 2 /mnt/masano1 ... inode max percent changed from 3 to 2 $ df -i /mnt/masano1 Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda7 10912 9472 1440 87% /mnt/masano1 # xfs_growfs -m 1 /mnt/masano1 ... inode max percent changed from 2 to 1 $ df -i /mnt/masano1 Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda7 5456 -18446744069414593792 4294963280 101% /mnt/masano1 And if I had allocated a large number of inodes and removed them previously, I could allocate inodes over the maximum percentage after reducing it. I wonder why. Any comments and suggestions are welcome. Environment: Red Hat 7.1 (fileutils-4.0.36-4) + XFS (CVS tree 2001-11-06) Cheers -- masano From owner-linux-xfs@oss.sgi.com Wed Nov 7 04:20:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7CK7G08413 for linux-xfs-outgoing; Wed, 7 Nov 2001 04:20:07 -0800 Received: from smtpstore.strencom.net ([217.75.0.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7CK4008390 for ; Wed, 7 Nov 2001 04:20:04 -0800 Received: from raptor.raidtec.ie (unknown [217.75.2.18]) by smtpstore.strencom.net (Postfix) with SMTP id D0BB863983 for ; Wed, 7 Nov 2001 12:18:21 +0000 (GMT) Received: from no.name.available by raptor.raidtec.ie via smtpd (for [217.75.0.68]) with SMTP; 7 Nov 2001 12:27:03 UT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: ACL-XFS X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Date: Wed, 7 Nov 2001 12:19:55 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: xfs_growfs -m Thread-Index: AcFnhcpvNUZN8zdZStu3fpTUikr/sQAABdEw From: "Juer Lee" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fA7CK5008391 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, Everybody, It seems that chacl can not change ACLs like #chacl u::rwx,g::rw-,o::r--,g:space\ group:r--,m::rwx acl Error message is: chacl: "u::rwx,g::rw-,o::r--,g:space group:r--,m::rwx" is an invalid ACL specification. I think this command can not handle the group name 'space group', right? Or I have to modify the source code of chacl to do that? Thanks in advance. Juer From owner-linux-xfs@oss.sgi.com Wed Nov 7 04:24:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7CO4g08624 for linux-xfs-outgoing; Wed, 7 Nov 2001 04:24:04 -0800 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 fA7CO2008602 for ; Wed, 7 Nov 2001 04:24:02 -0800 Received: from heppcl.ph.qmw.ac.uk ([138.37.50.187]) by zeta.qmw.ac.uk with esmtp (Exim 3.32 #1) id 161RkO-0001WF-00 for linux-xfs@oss.sgi.com; Wed, 07 Nov 2001 12:24:00 +0000 Received: from heppct.ph.qmw.ac.uk (heppct.ph.qmw.ac.uk [138.37.50.246]) by heppcl.ph.qmw.ac.uk (8.11.6/8.9.3) with ESMTP id fA7CO0h03793 for ; Wed, 7 Nov 2001 12:24:00 GMT Received: from localhost (pd@localhost) by heppct.ph.qmw.ac.uk (8.11.6/8.9.3) with ESMTP id fA7CO0818011 for ; Wed, 7 Nov 2001 12:24:00 GMT X-Authentication-Warning: heppct.ph.qmw.ac.uk: pd owned process doing -bs Date: Wed, 7 Nov 2001 12:24:00 +0000 (GMT) From: "P.Dixon" To: Subject: Re: 7.2 installer crash 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 I've had some time to play with Red Hat 7.2 installed via the test XFS installer. When the system booted, it claimed that it couldn't find fsck.xfs. rpm -ql xfsprogs clains that fsck.xfs lives in /sbin, but it wasn't there. Reinstalling xfsprogs seems to have cured that problem though. Paul From owner-linux-xfs@oss.sgi.com Wed Nov 7 04:31:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7CVlU08939 for linux-xfs-outgoing; Wed, 7 Nov 2001 04:31:47 -0800 Received: from camelot.virtualavalon.net (127bus50.tampabay.rr.com [24.94.127.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7CVi008917 for ; Wed, 7 Nov 2001 04:31:44 -0800 Received: from arthur.virtualavalon.net (arthur.virtualavalon.net [172.20.1.10]) by camelot.virtualavalon.net (8.12.0/8.12.0) with ESMTP id fA7CVirh023637 for ; Wed, 7 Nov 2001 07:31:44 -0500 Received: from tampabay.rr.com (wayfarer.virtualavalon.net [172.20.1.15]) by arthur.virtualavalon.net (8.12.0/8.12.0) with ESMTP id fA7CVa7g017117 for ; Wed, 7 Nov 2001 07:31:38 -0500 (EST) Message-ID: <3BE9299E.6000702@tampabay.rr.com> Date: Wed, 07 Nov 2001 07:31:26 -0500 From: "Jesse W. Asher" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS, Linux, and Solaris. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm using XFS on RH7.1 successfully so far and I'm pretty happy with it. My problem is a little off topic for this list, but it is semi-related. Because I don't want to have to manage another type of journaling filesystem, I'd like to run XFS on Solaris 8 and I was wondering if it was available for Solaris 8. I have a bunch of Linux boxes and one Solaris box and I'd rather not have to go through the extra work and I can't get rid of the Solaris box (unfortunately). Any pointers to a Solaris version of XFS would be appreciated.... -- Jesse W. Asher "They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty or safety." - Benjamin Franklin From owner-linux-xfs@oss.sgi.com Wed Nov 7 05:13:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7DDc010218 for linux-xfs-outgoing; Wed, 7 Nov 2001 05:13:38 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7DDX010194 for ; Wed, 7 Nov 2001 05:13:33 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id fA7DDU3L095467; Wed, 7 Nov 2001 14:13:31 +0100 (CET) Message-Id: <4.3.2.7.2.20011107140934.0323c578@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Nov 2001 14:11:33 +0100 To: "Jesse W. Asher" , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: XFS, Linux, and Solaris. In-Reply-To: <3BE9299E.6000702@tampabay.rr.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:31 7-11-2001 -0500, Jesse W. Asher wrote: >I'm using XFS on RH7.1 successfully so far and I'm pretty happy with it. >My problem is a little off topic for this list, but it is semi-related. >Because I don't want to have to manage another type of journaling >filesystem, I'd like to run XFS on Solaris 8 and I was wondering if it was >available for Solaris 8. I have a bunch of Linux boxes and one Solaris >box and I'd rather not have to go through the extra work and I can't get >rid of the Solaris box (unfortunately). You will have to convert that solaris box to Linux then. Solaris is not planned and unless they do some really groovy things with their code and licenses I don't think it's even possible. >Any pointers to a Solaris version of XFS would be appreciated.... There are none. XFS was specifically put under the GPL to prevent Sun from "just" incorporating XFS into Solaris at no development cost. 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 Nov 7 06:05:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7E5sY13067 for linux-xfs-outgoing; Wed, 7 Nov 2001 06:05:54 -0800 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7E5l013044 for ; Wed, 7 Nov 2001 06:05:47 -0800 Received: (qmail 32594 invoked from network); 7 Nov 2001 14:05:47 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 7 Nov 2001 14:05:47 -0000 Received: (qmail 9644 invoked from network); 7 Nov 2001 14:05:44 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by raman.epigenomics.epi with SMTP; 7 Nov 2001 14:05:44 -0000 Received: (qmail 20152 invoked by uid 9); 7 Nov 2001 14:05:43 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: Re: xfs and nfs Date: Wed, 7 Nov 2001 14:05:43 +0000 (UTC) Organization: Epigenomics AG Lines: 50 Message-ID: References: <200111071047.LAA26443@elrond.ipgp.jussieu.fr> X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.2 (Linux) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! We got today 4 times this oops: Nov 7 14:33:24 raman kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Nov 7 14:33:24 raman kernel: 00000000 Nov 7 14:33:24 raman kernel: *pde = 00000000 Nov 7 14:33:24 raman kernel: Oops: 0000 Nov 7 14:33:24 raman kernel: CPU: 0 Nov 7 14:33:24 raman kernel: EIP: 0010:[<00000000>] Nov 7 14:33:24 raman kernel: EFLAGS: 00010286 Nov 7 14:33:24 raman kernel: eax: 00000000 ebx: f6c8cd60 ecx: 00000000 edx: c0279de0 Nov 7 14:33:24 raman kernel: esi: f6c8c960 edi: f6c8cd60 ebp: f6c8cd60 esp: f63a3e4c Nov 7 14:33:24 raman kernel: ds: 0018 es: 0018 ss: 0018 Nov 7 14:33:24 raman kernel: Process nfsd (pid: 455, stackpage=f63a3000) Nov 7 14:33:24 raman kernel: Stack: f8a5efd4 d25fd6e0 f6c8c960 f5dab404 f75e1c00 f8a5f419 f6c8cd60 f5dab404 Nov 7 14:33:24 raman kernel: 00000002 f5d17000 11270000 00000000 f75e1e08 00000002 f8a5f739 f75e1c00 Nov 7 14:33:24 raman kernel: f5dab414 00000002 00000001 00000001 00000003 00000003 f6d708b2 f5dab404 Nov 7 14:33:24 raman kernel: Call Trace: [] [] [] [reschedule_idle+575/588] [] Nov 7 14:33:24 raman kernel: [] [] [] [] [] [] Nov 7 14:33:24 raman kernel: [] [] [] [] [kernel_thread+35/48] Nov 7 14:33:24 raman kernel: Code: Bad EIP value. >>EIP; 00000000 Before first symbol Trace; f8a5efd4 <[nfsd]nfsd_findparent+34/fc> Trace; f8a5f419 <[nfsd]find_fh_dentry+209/32c> Trace; f8a5f739 <[nfsd]fh_verify+1fd/40c> Trace; f8a65fc2 <[nfsd]nfsd3_proc_lookup+13a/14c> Trace; f8a6d700 <[nfsd]nfsd_procedures3+60/2c0> Trace; f8a67c7c <[nfsd]nfs3svc_decode_diropargs+98/10c> Trace; f8a6d700 <[nfsd]nfsd_procedures3+60/2c0> Trace; f8a5d5a3 <[nfsd]nfsd_dispatch+cb/168> Trace; f8a6d700 <[nfsd]nfsd_procedures3+60/2c0> Trace; f8a44198 <[sunrpc]svc_process+2ac/544> Trace; f8a6d640 <[nfsd]nfsd_svcstats+0/40> Trace; f8a6d118 <[nfsd]nfsd_version3+0/10> Trace; f8a5d349 <[nfsd]nfsd+1b9/348> running the 2.4.8 Mandrake kernel with XFS. Yesterday we got a test machine where I can test the latest kernels, so maybe an upgrade happens at saturday. Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Nov 7 06:30:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7EUh817368 for linux-xfs-outgoing; Wed, 7 Nov 2001 06:30:43 -0800 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 fA7EUe017346 for ; Wed, 7 Nov 2001 06:30:40 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id CA4941E7E5; Wed, 7 Nov 2001 15:30:34 +0100 (MET) Date: Wed, 7 Nov 2001 15:30:32 +0100 From: Andi Kleen To: mdew Cc: xfs Subject: Re: XFS Limitations rather? Message-ID: <20011107153032.A21290@wotan.suse.de> References: <1005171696.369.7.camel@mdew> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <1005171696.369.7.camel@mdew>; from rpbrown@xtra.co.nz on Thu, Nov 08, 2001 at 11:21:36AM +1300 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Nov 08, 2001 at 11:21:36AM +1300, mdew wrote: > I was looking at this page... > > http://www.suse.de/~aj/linux_lfs.html > > and notice that XFS indicates theres a 2T limitation under Linux, yet > every other FS (ext2/resierfs/jfs) dont seem to have this limitation, > why doesnt this "2T limitation" affect other file systems? The other file systems have the same limitation. The linux block device layer doesn't support devices > 2TB at the moment. This includes LVM and MD block devices. -Andi From owner-linux-xfs@oss.sgi.com Wed Nov 7 06:59:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7Exse26635 for linux-xfs-outgoing; Wed, 7 Nov 2001 06:59:54 -0800 Received: from secure3.developerschoice.net ([209.69.203.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7Exo026612 for ; Wed, 7 Nov 2001 06:59:50 -0800 Received: from [209.69.206.248] (helo=office3) by secure3.developerschoice.net with smtp (Exim 3.20 #27) id 161U3M-0005D5-00; Wed, 07 Nov 2001 09:51:44 -0500 Content-Type: text/plain; charset="iso-8859-1" From: Jeff Breitner Reply-To: memptr@gatecom.com To: Ethan Benson , linux-xfs@oss.sgi.com Subject: Re: Interesting XFS Behavior Date: Wed, 7 Nov 2001 10:00:16 -0500 X-Mailer: KMail [version 1.2] References: <20011105225039.A599@asterix.gallien.de> <01110610360706.01823@office3> <20011107005250.V887@plato.local.lan> In-Reply-To: <20011107005250.V887@plato.local.lan> MIME-Version: 1.0 Message-Id: <01110710001601.03614@office3> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wednesday 07 November 2001 04:52 am, Ethan Benson wrote: > i don't see how, unless the directory is sticky and owned by someone > other then the user. > > You are correct, it's not the zero-byte file that prevents it, but the fact that part of the directory structure is owned by someone else. I made that realization later yesterday afternoon (slapping hand on forehead). However, interesting that the local user could still dump the zero-byte file. That is, however, not of any significance because it still sort of emulates the chattr +i and that keeps me from having to rewrite a bunch of scripts as well as keeping local users from doing stupid things. Thanks.. From owner-linux-xfs@oss.sgi.com Wed Nov 7 07:08:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7F8at26993 for linux-xfs-outgoing; Wed, 7 Nov 2001 07:08:36 -0800 Received: from sa-bwmail1.storageapps.com (smtp.storageapps.com [63.101.83.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7F8L026971 for ; Wed, 7 Nov 2001 07:08:22 -0800 Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Nov 2001 10:05:30 -0500 Message-ID: <23D04BDBA646D411BDDD00D0B774B53904602897@SA-BWMAIL1> From: "Christian, Chip" To: "'Seref Tufan Sen'" , "'MOGUILNY Genevieve'" , linux-xfs@oss.sgi.com Subject: RE: xfs and nfs Date: Wed, 7 Nov 2001 10:05:20 -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 Since you mention NFS, and I see dput in the syslog output, I'm gonna guess it's the problem I reported over the summer. The patch got put in the mainline kernel, but if you want to patch 2.4.3 yourself the problem I encountered was that nfsd_findparent() didn't find '..', then went and called dput(tdentry) twice. My patch added a return(), Neil's dropped a dput(): struct dentry *nfsd_findparent(struct dentry *child) { struct dentry *tdentry, *pdentry; tdentry = d_alloc(child, &(const struct qstr) {"..", 2, 0}); if (!tdentry) return ERR_PTR(-ENOMEM); /* I'm going to assume that if the returned dentry is different, then * it is well connected. But nobody returns different dentrys do they? */ pdentry = child->d_inode->i_op->lookup(child->d_inode, tdentry); d_drop(tdentry); /* we never want ".." hashed */ if (!pdentry && tdentry->d_inode == NULL) { /* File system cannot find ".." ... sad but possible */ Neil Dropped-> dput(tdentry); pdentry = ERR_PTR(-EINVAL); I added------> return pdentry; } if (!pdentry) { ... } dput(tdentry); /* it is not hashed, it will be discarded */ return pdentry; } -----Original Message----- From: Seref Tufan Sen [mailto:tufan@itu.edu.tr] Sent: Wednesday, November 07, 2001 6:36 To: 'MOGUILNY Genevieve'; linux-xfs@oss.sgi.com Subject: RE: xfs and nfs I had the same problems with NFS (RH 7.1 + MegaRAID Controler too) . I was using RPMS from SGI (2.4.3) , then I compiled 2.4.9 with XFS patch. And the problem has gone. > -----Original Message----- > From: owner-linux-xfs@oss.sgi.com > [mailto:owner-linux-xfs@oss.sgi.com]On > Behalf Of MOGUILNY Genevieve > Sent: Wednesday, November 07, 2001 12:48 PM > To: linux-xfs@oss.sgi.com > Subject: xfs and nfs > > > Hello, > > We have installed XFS 1.0 on a RedHat 7.1 system > with MegaRAID controller. On this machine, > there are a hundred of homes, samba server... > As we had problems with Remote/Local accesses > on xfs partitions, we installed XFS 1.0.1. > Since then, nfs stopiped working several times a day. > In the var log, we have messages like : > > Nov 5 17:39:00 hera kernel: invalid operand: 0000 > Nov 5 17:39:00 hera kernel: CPU: 0 > Nov 5 17:39:00 hera kernel: EIP: 0010:[dput+20/324] > Nov 5 17:39:00 hera kernel: EIP: 0010:[] > Nov 5 17:39:00 hera kernel: EFLAGS: 00010246 > Nov 5 17:39:00 hera kernel: eax: 00000000 ebx: d7878d60 > ecx: c458de44 edx: 00178780 > Nov 5 17:39:00 hera kernel: esi: d7878d60 edi: d7878ae0 > ebp: d7878ae0 esp: c458de4c > Nov 5 17:39:00 hera kernel: ds: 0018 es: 0018 ss: 0018 > Nov 5 17:39:00 hera kernel: Process nfsd (pid: 1707, > stackpage=c458d000) > Nov 5 17:39:00 hera kernel: Stack: ffffffea d7878d60 > d8903ee1 d7878d60 00000000 10482e8e > d890 > 4258 d7878ae0 > Nov 5 17:39:00 hera kernel: 00000000 c54ebe14 > 11270000 c54ebe04 4c1b9d86 c60779f8 > 0000 > 0000 ffffff8c > Nov 5 17:39:00 hera kernel: 00000000 d89045d4 > c6077800 10482e8e 00000000 00000000 > 0000 > 0001 c54ebe04 > Nov 5 17:39:00 hera kernel: Call Trace: [] > [] [] > [] [ > schedule+647/976] > Nov 5 17:39:00 hera kernel: Call Trace: [] > [] [] > [] [ > ] > Nov 5 17:39:00 hera kernel: [] [] > [] [] > [ >] [] > Nov 5 17:39:00 hera kernel: [] [] > [] [] > [ >] [kernel_thread+35/48] > Nov 5 17:39:00 hera kernel: [] [] > [] [] > [ >] [] > Nov 5 17:39:00 hera kernel: > Nov 5 17:39:00 hera kernel: Code: 0f 0b ff 0b 0f 94 c0 84 c0 > 0f 84 1e 01 00 00 8d 73 20 39 > 73 > > > And after that message, nobody could access their home space > from a remote host. > > Do you have any idea of what could cause the problem ? > Thank you in advance, > > > Genevieve Moguilny > DMPN - IPGP > Case 89 - Tour 24 > 4 place Jussieu > 75252 Paris cedex 05 > Tel. 01 44 27 24 15 > Fax 01 44 27 38 94 > moguilny@ipgp.jussieu.fr From owner-linux-xfs@oss.sgi.com Wed Nov 7 07:12:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7FC4s27194 for linux-xfs-outgoing; Wed, 7 Nov 2001 07:12:04 -0800 Received: from sa-bwmail1.storageapps.com (smtp.storageapps.com [63.101.83.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7FBp027171 for ; Wed, 7 Nov 2001 07:11:51 -0800 Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Nov 2001 10:09:00 -0500 Message-ID: <23D04BDBA646D411BDDD00D0B774B53904602898@SA-BWMAIL1> From: "Christian, Chip" To: "'Seref Tufan Sen'" , "'MOGUILNY Genevieve'" , linux-xfs@oss.sgi.com Subject: RE: xfs and nfs Date: Wed, 7 Nov 2001 10:08:52 -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 Although I guess the open question is what happened to '..'? I presume the filesystem is in need of repair. -----Original Message----- From: Christian, Chip [mailto:chip_christian@hp.com] Sent: Wednesday, November 07, 2001 10:05 To: 'Seref Tufan Sen'; 'MOGUILNY Genevieve'; linux-xfs@oss.sgi.com Subject: RE: xfs and nfs Since you mention NFS, and I see dput in the syslog output, I'm gonna guess it's the problem I reported over the summer. The patch got put in the mainline kernel, but if you want to patch 2.4.3 yourself the problem I encountered was that nfsd_findparent() didn't find '..', then went and called dput(tdentry) twice. My patch added a return(), Neil's dropped a dput(): struct dentry *nfsd_findparent(struct dentry *child) { struct dentry *tdentry, *pdentry; tdentry = d_alloc(child, &(const struct qstr) {"..", 2, 0}); if (!tdentry) return ERR_PTR(-ENOMEM); /* I'm going to assume that if the returned dentry is different, then * it is well connected. But nobody returns different dentrys do they? */ pdentry = child->d_inode->i_op->lookup(child->d_inode, tdentry); d_drop(tdentry); /* we never want ".." hashed */ if (!pdentry && tdentry->d_inode == NULL) { /* File system cannot find ".." ... sad but possible */ Neil Dropped-> dput(tdentry); pdentry = ERR_PTR(-EINVAL); I added------> return pdentry; } if (!pdentry) { ... } dput(tdentry); /* it is not hashed, it will be discarded */ return pdentry; } -----Original Message----- From: Seref Tufan Sen [mailto:tufan@itu.edu.tr] Sent: Wednesday, November 07, 2001 6:36 To: 'MOGUILNY Genevieve'; linux-xfs@oss.sgi.com Subject: RE: xfs and nfs I had the same problems with NFS (RH 7.1 + MegaRAID Controler too) . I was using RPMS from SGI (2.4.3) , then I compiled 2.4.9 with XFS patch. And the problem has gone. > -----Original Message----- > From: owner-linux-xfs@oss.sgi.com > [mailto:owner-linux-xfs@oss.sgi.com]On > Behalf Of MOGUILNY Genevieve > Sent: Wednesday, November 07, 2001 12:48 PM > To: linux-xfs@oss.sgi.com > Subject: xfs and nfs > > > Hello, > > We have installed XFS 1.0 on a RedHat 7.1 system > with MegaRAID controller. On this machine, > there are a hundred of homes, samba server... > As we had problems with Remote/Local accesses > on xfs partitions, we installed XFS 1.0.1. > Since then, nfs stopiped working several times a day. > In the var log, we have messages like : > > Nov 5 17:39:00 hera kernel: invalid operand: 0000 > Nov 5 17:39:00 hera kernel: CPU: 0 > Nov 5 17:39:00 hera kernel: EIP: 0010:[dput+20/324] > Nov 5 17:39:00 hera kernel: EIP: 0010:[] > Nov 5 17:39:00 hera kernel: EFLAGS: 00010246 > Nov 5 17:39:00 hera kernel: eax: 00000000 ebx: d7878d60 > ecx: c458de44 edx: 00178780 > Nov 5 17:39:00 hera kernel: esi: d7878d60 edi: d7878ae0 > ebp: d7878ae0 esp: c458de4c > Nov 5 17:39:00 hera kernel: ds: 0018 es: 0018 ss: 0018 > Nov 5 17:39:00 hera kernel: Process nfsd (pid: 1707, > stackpage=c458d000) > Nov 5 17:39:00 hera kernel: Stack: ffffffea d7878d60 > d8903ee1 d7878d60 00000000 10482e8e > d890 > 4258 d7878ae0 > Nov 5 17:39:00 hera kernel: 00000000 c54ebe14 > 11270000 c54ebe04 4c1b9d86 c60779f8 > 0000 > 0000 ffffff8c > Nov 5 17:39:00 hera kernel: 00000000 d89045d4 > c6077800 10482e8e 00000000 00000000 > 0000 > 0001 c54ebe04 > Nov 5 17:39:00 hera kernel: Call Trace: [] > [] [] > [] [ > schedule+647/976] > Nov 5 17:39:00 hera kernel: Call Trace: [] > [] [] > [] [ > ] > Nov 5 17:39:00 hera kernel: [] [] > [] [] > [ >] [] > Nov 5 17:39:00 hera kernel: [] [] > [] [] > [ >] [kernel_thread+35/48] > Nov 5 17:39:00 hera kernel: [] [] > [] [] > [ >] [] > Nov 5 17:39:00 hera kernel: > Nov 5 17:39:00 hera kernel: Code: 0f 0b ff 0b 0f 94 c0 84 c0 > 0f 84 1e 01 00 00 8d 73 20 39 > 73 > > > And after that message, nobody could access their home space > from a remote host. > > Do you have any idea of what could cause the problem ? > Thank you in advance, > > > Genevieve Moguilny > DMPN - IPGP > Case 89 - Tour 24 > 4 place Jussieu > 75252 Paris cedex 05 > Tel. 01 44 27 24 15 > Fax 01 44 27 38 94 > moguilny@ipgp.jussieu.fr From owner-linux-xfs@oss.sgi.com Wed Nov 7 08:32:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7GW6c30140 for linux-xfs-outgoing; Wed, 7 Nov 2001 08:32:06 -0800 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 fA7GW2030116 for ; Wed, 7 Nov 2001 08:32:02 -0800 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 RAA1712554 for ; Wed, 7 Nov 2001 17:32:01 +0100 (CET) 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 KAA3525840; Wed, 7 Nov 2001 10:30:43 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA96066; Wed, 7 Nov 2001 10:30:43 -0600 (CST) Subject: Re: XFS+Tux = patch trouble From: Eric Sandeen To: Sean Elble Cc: Tux mailing list , XFS Mailing list In-Reply-To: <03bd01c16739$2318cff0$0a00a8c0@intranet.mp3s.com> References: <02bb01c16720$7fd7d470$0a00a8c0@intranet.mp3s.com> <3BE8A074.8494050A@sgi.com> <03bd01c16739$2318cff0$0a00a8c0@intranet.mp3s.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 07 Nov 2001 10:30:02 -0600 Message-Id: <1005150602.5256.72.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Sean - I guess I wasn't quite clear. That 48k refers only to code changes in the core linux kernel, and does NOT include fs/pagebuf, fs/xfs, or fs/xfs_support. -Eric On Tue, 2001-11-06 at 21:05, Sean Elble wrote: > Whoa . . . I didn't realize that the patch was only 48k. But does that > include all the XFS "dependences", like the Page Buffer code, etc.? I would > imagine that it does, but just checking . . . -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Nov 7 08:50:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7Go8t31336 for linux-xfs-outgoing; Wed, 7 Nov 2001 08:50:08 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7Go1031302 for ; Wed, 7 Nov 2001 08:50:01 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fA7GnuT22012 for ; Wed, 7 Nov 2001 08:49:56 -0800 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 KAA3525122; Wed, 7 Nov 2001 10:48:40 -0600 (CST) Received: from jen.americas.sgi.com (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 KAA15034; Wed, 7 Nov 2001 10:48:39 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA7GimI03615; Wed, 7 Nov 2001 10:44:48 -0600 Subject: Re: xfs_growfs -m From: Steve Lord To: ASANO Masahiro Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011107211320I.masano@tnes.nec.co.jp> References: <20011107211320I.masano@tnes.nec.co.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0+cvs.2001.11.06.15.04 (Preview Release) Date: 07 Nov 2001 10:44:48 -0600 Message-Id: <1005151488.3536.6.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk All the xfs_growfs -m is doing is reducing the allowed number of inodes in the filesystem, this is stored in the superblock as a percentage of disk space I think. On the last execution here you dropped the percentage of inodes below the actual number of inodes allocated, I suspect this is a case the original implementer of this code did not think of. The correct semantics could be to refuse the call since there are already more inodes than this, or to fix up the information being used by df to report a more sane value. XFS never frees space allocated to inodes, once you have allocated space as inodes, it is never returned to free space, just to free inodes. So, if you create a million files and then remove them all, there are still a million inodes out there on the filesystem waiting to be reused. xfs_growfs -m has no interaction with the number of inodes actually in existance, just on the allowed high water mark of inodes. Steve On Wed, 2001-11-07 at 06:13, ASANO Masahiro wrote: > May I reduce the maximum percentage of inodes with "xfs_growfs -m" ? > > `df' showed an negative value: > > $ df -i /mnt/masano1 > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/sda7 13216 9472 3744 72% /mnt/masano1 > # xfs_growfs -m 5 /mnt/masano1 > ... > inode max percent changed from 25 to 5 > $ df -i /mnt/masano1 > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/sda7 13216 9472 3744 72% /mnt/masano1 > # xfs_growfs -m 3 /mnt/masano1 > ... > inode max percent changed from 5 to 3 > $ df -i /mnt/masano1 > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/sda7 13216 9472 3744 72% /mnt/masano1 > # xfs_growfs -m 2 /mnt/masano1 > ... > inode max percent changed from 3 to 2 > $ df -i /mnt/masano1 > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/sda7 10912 9472 1440 87% /mnt/masano1 > # xfs_growfs -m 1 /mnt/masano1 > ... > inode max percent changed from 2 to 1 > $ df -i /mnt/masano1 > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/sda7 5456 -18446744069414593792 4294963280 101% /mnt/masano1 > > > And if I had allocated a large number of inodes and removed them previously, > I could allocate inodes over the maximum percentage after reducing it. > I wonder why. > > Any comments and suggestions are welcome. > > Environment: Red Hat 7.1 (fileutils-4.0.36-4) + XFS (CVS tree 2001-11-06) > > Cheers > -- > masano -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Nov 7 11:29:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7JTJm10169 for linux-xfs-outgoing; Wed, 7 Nov 2001 11:29:19 -0800 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 fA7JTE010144 for ; Wed, 7 Nov 2001 11:29:14 -0800 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 LAA23912 for ; Wed, 7 Nov 2001 11:29:05 -0800 (PST) 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 NAA3415536 for ; Wed, 7 Nov 2001 13:27:57 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA87762 for ; Wed, 7 Nov 2001 13:27:56 -0600 (CST) Subject: RH7.2 installer - updates disk From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 07 Nov 2001 13:27:14 -0600 Message-Id: <1005161234.5256.89.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk There's an updates disk image at ftp://oss.sgi.com/projects/xfs/download/testing/RH7.2-installer/updates-Nov07-13.img CHANGELOG: updates-Nov07-12.img: * Add time that bootloader install waits before trying grub (temp workaround for fs/grub interaction problems) * Skip past SGI screen during kickstart * Remove "registered" character from first screen, GTK didn't like it. * Allow setting of labels on XFS filesystems * Do not allow bootloader to be placed on 1st sector of XFS partition The delay for grub is a bit excessive, but it works for now until a better solution is found. To use the updates disk, dd it to a floppy: dd if=updates-Nov07-12.img of=/dev/fd0 bs=1440k and then run "linux updates" at the installer prompt. 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 Wed Nov 7 11:51:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7JpmV10742 for linux-xfs-outgoing; Wed, 7 Nov 2001 11:51:48 -0800 Received: from emergence.com (IDENT:root@mail.emergence.com [209.5.172.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7Jpj010720 for ; Wed, 7 Nov 2001 11:51:45 -0800 Received: from emergence.com (relative.emergence.com [209.5.172.43]) by emergence.com (8.9.3/8.9.3) with ESMTP id MAA32718 for ; Wed, 7 Nov 2001 12:51:19 -0700 Message-ID: <3BE99220.C53F2788@emergence.com> Date: Wed, 07 Nov 2001 12:57:20 -0700 From: Michael Best X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13SGI_XFS_PR1 i586) X-Accept-Language: en, pdf MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: re: Test RH 7.2 installer available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Things that I noticed in the installer: When I selected update, the installer thought that my main xfs partition was a swap file and wouldn't let me mount it as '/', so I had to choose to format it. When running in expert mode from the install floppy, I wasn't prompted for NIS installation information like I have been in the past for Redhat installers. ( I don't know if this is specific to the SGI installer, or Redhat related ) I tried GRUB and it didn't work for me, so I booted the floppy and XFS cdrom read the grub instructions and made a GRUB boot floppy, but it appeared that it thought my main partition was ext2 at startup and refused to start dumping me to filesystem repair instead. I eventually reinstalled and used Lilo. -Mike From owner-linux-xfs@oss.sgi.com Wed Nov 7 12:22:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7KM6h11522 for linux-xfs-outgoing; Wed, 7 Nov 2001 12:22:06 -0800 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 fA7KM3011500 for ; Wed, 7 Nov 2001 12:22:03 -0800 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 MAA02910 for ; Wed, 7 Nov 2001 12:21:35 -0800 (PST) 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 OAA3529167 for ; Wed, 7 Nov 2001 14:20:46 -0600 (CST) Received: from jen.americas.sgi.com (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 OAA31894 for ; Wed, 7 Nov 2001 14:20:46 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA7KGsR05961; Wed, 7 Nov 2001 14:16:54 -0600 Message-Id: <200111072016.fA7KGsR05961@jen.americas.sgi.com> Date: Wed, 7 Nov 2001 14:16:54 -0600 Subject: TAKE - more posix error code fixup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Another fix from ASANO Masahiro Date: Wed Nov 7 12:20:30 PST 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:106262a linux/fs/xfs/xfs_rename.c - 1.32 From owner-linux-xfs@oss.sgi.com Wed Nov 7 12:44:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7Ki4f12032 for linux-xfs-outgoing; Wed, 7 Nov 2001 12:44:04 -0800 Received: from localhost.localdomain (d8-228-221-dial.mistral.co.uk [195.184.228.221]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7Khw012008 for ; Wed, 7 Nov 2001 12:43:58 -0800 Received: from qmw.ac.uk (words [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id fA7KhIw01265 for ; Wed, 7 Nov 2001 20:43:19 GMT Message-ID: <3BE99CE6.9000204@qmw.ac.uk> Date: Wed, 07 Nov 2001 20:43:18 +0000 From: "P.Dixon" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010701 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Test RH 7.2 installer available References: <3BE99220.C53F2788@emergence.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Apologies if people are bored by this, but I've discovered more problems with my RH 7.2 installation... Some RPMs appear to be installed (rpm -qa shows them) but some files from the packages aren't actually installed. Files so far that I've had to re-install are: uniprocessor kernel (I have an SMP system) kernel-source (nothing appeared to be in /usr/src) xfsprogs (fsck.xfs couldn't be found at boot) kernel-headers (discovered when compiling openafs) I'm not particularly worried by this as I was just playing around with a new machine that arrived this week. Everything else seems to be working fine (although the lack of documentation when playing with printconf was quite annoying - no man pages at all for this beast - a growing Red Hat worry with some of their config tools - where does printconf store it's config files!!??....rant rant...) Anyway, I am now totally happy with the system. OpenAFS was trivial to build (version 1.2.2) and it's the first version I've tried since 1.0.4 that hasn't hung the system (it even manages to install the smp kernel modules without me having to create sym links). Next week I'll be trying to get the GRID tools (http://www.gridpp.ac.uk/) working - is this of any interest to anyone - if so I'll report back. Cheerio, Paul From owner-linux-xfs@oss.sgi.com Wed Nov 7 12:56:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7KuBX12420 for linux-xfs-outgoing; Wed, 7 Nov 2001 12:56:11 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7Ku7012398 for ; Wed, 7 Nov 2001 12:56:07 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fA7Ku2T07137 for ; Wed, 7 Nov 2001 12:56:02 -0800 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 OAA3530001; Wed, 7 Nov 2001 14:54:46 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA76277; Wed, 7 Nov 2001 14:54:45 -0600 (CST) Subject: Re: Test RH 7.2 installer available From: Eric Sandeen To: "P.Dixon" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3BE99CE6.9000204@qmw.ac.uk> References: <3BE99220.C53F2788@emergence.com> <3BE99CE6.9000204@qmw.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 07 Nov 2001 14:54:03 -0600 Message-Id: <1005166443.5256.111.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Paul - On Wed, 2001-11-07 at 14:43, P.Dixon wrote: > Apologies if people are bored by this, but I've discovered more problems > with my RH 7.2 installation... No, bug reports are never boring. :) > Some RPMs appear to be installed (rpm -qa shows them) but some files > from the packages aren't actually installed. Files so far that I've had > to re-install are: Yikes! Those are all our packages... on the other hand, a test box I just installed is fine in that respect. You might run "rpm -Va | grep missing" to see if there is anything else missing. I assume you had plenty of disk space for the install? -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 Nov 7 13:55:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7Ltg813695 for linux-xfs-outgoing; Wed, 7 Nov 2001 13:55:42 -0800 Received: from localhost.localdomain ([200.11.225.153]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7LtO013667 for ; Wed, 7 Nov 2001 13:55:27 -0800 Received: from corvusnet.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id fA7LvNj01215 for ; Wed, 7 Nov 2001 17:57:23 -0400 Message-ID: <3BE9AE43.1B4109F1@corvusnet.com> Date: Wed, 07 Nov 2001 17:57:23 -0400 From: =?iso-8859-1?Q?V=EDctor?= Reinaldo Prada =?iso-8859-1?Q?Jim=E9nez?= X-Mailer: Mozilla 4.76 [es] (X11; U; Linux 2.4.13-CORVUS-LATINUX-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: RH7.2 installer - updates disk References: <1005161234.5256.89.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by localhost.localdomain id fA7LvNj01215 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fA7Lta013670 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen escribió: Hello using this new installer and this updates disk i can install grub as boot loader... when all yhe packahes has been installed the installer prompt a window saying that the next step is install the bootloader and then make an error.. "RuntimeError /sbin/grub-install can not be run" anyone else has seen this error?? Thanks Victor Prada > There's an updates disk image at > > ftp://oss.sgi.com/projects/xfs/download/testing/RH7.2-installer/updates-Nov07-13.img > > CHANGELOG: > > updates-Nov07-12.img: > > * Add time that bootloader install waits before trying grub > (temp workaround for fs/grub interaction problems) > * Skip past SGI screen during kickstart > * Remove "registered" character from first screen, GTK didn't like it. > * Allow setting of labels on XFS filesystems > * Do not allow bootloader to be placed on 1st sector of XFS partition > > The delay for grub is a bit excessive, but it works for now until a > better solution is found. > > To use the updates disk, dd it to a floppy: > > dd if=updates-Nov07-12.img of=/dev/fd0 bs=1440k > > and then run "linux updates" at the installer prompt. > > 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 Wed Nov 7 14:12:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7MCMo14060 for linux-xfs-outgoing; Wed, 7 Nov 2001 14:12:22 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7MCI014038 for ; Wed, 7 Nov 2001 14:12:18 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fA7MCCK10710 for ; Wed, 7 Nov 2001 14:12:12 -0800 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 QAA3522387; Wed, 7 Nov 2001 16:10:56 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA93710; Wed, 7 Nov 2001 16:10:56 -0600 (CST) Subject: Re: RH7.2 installer - updates disk From: Eric Sandeen To: =?ISO-8859-1?Q?V=EDctor?= Reinaldo Prada =?ISO-8859-1?Q?Jim=E9nez?= Cc: linux-xfs@oss.sgi.com In-Reply-To: <3BE9AE43.1B4109F1@corvusnet.com> References: <1005161234.5256.89.camel@stout.americas.sgi.com> <3BE9AE43.1B4109F1@corvusnet.com> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/0.16 (Preview Release) Date: 07 Nov 2001 16:10:13 -0600 Message-Id: <1005171013.5256.124.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fA7MCI014039 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Victor - Was this in a pop-up window, or on a virtual console? Can you switch to virtual console 2 (ctrl-alt-2) and see if /mnt/sysimage/sbin/grub-install exists? I don't think anything on the updates disk should cause this problem. By the way, a slightly newer updates disk image is there now - but it should not affect grub at all. ftp://oss.sgi.com/projects/xfs/download/testing/RH7.2-installer/updates-Nov07-14.img -Eric On Wed, 2001-11-07 at 15:57, Víctor Reinaldo Prada Jiménez wrote: > "RuntimeError /sbin/grub-install can not be run" -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Nov 7 14:24:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7MO5k14421 for linux-xfs-outgoing; Wed, 7 Nov 2001 14:24:05 -0800 Received: from localhost.localdomain ([200.11.225.153]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7MNm014399 for ; Wed, 7 Nov 2001 14:23:50 -0800 Received: from corvusnet.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id fA7MPpj01256 for ; Wed, 7 Nov 2001 18:25:52 -0400 Message-ID: <3BE9B4EE.C83152B0@corvusnet.com> Date: Wed, 07 Nov 2001 18:25:51 -0400 From: =?iso-8859-1?Q?V=EDctor?= Reinaldo Prada =?iso-8859-1?Q?Jim=E9nez?= X-Mailer: Mozilla 4.76 [es] (X11; U; Linux 2.4.13-CORVUS-LATINUX-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: RH7.2 installer - updates disk References: <1005161234.5256.89.camel@stout.americas.sgi.com> <3BE9AE43.1B4109F1@corvusnet.com> <1005171013.5256.124.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by localhost.localdomain id fA7MPpj01256 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fA7MO0014400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen escribió: It was in a pop-up window, then i'd check if /sbin/grub-install was there and wasn't so i modify the scrip upd-instroot to add the grub package and keep it in the instalation process..... but the grub rpm install the grub-install program in /usr/sbin/grub-install so i'd modified bootloader.py to look in /usr/sbin/ instead of /sbin and this didn't work neither... the i try with the update disk to see if this fix the problem but nothing happen? when i use lilo as boot loader i can install without problems do you have any tips or advices on this??? Thanks in advance Victor Prada > Hi Victor - > > Was this in a pop-up window, or on a virtual console? > > Can you switch to virtual console 2 (ctrl-alt-2) and see if > /mnt/sysimage/sbin/grub-install exists? > > I don't think anything on the updates disk should cause this problem. > > By the way, a slightly newer updates disk image is there now - but it > should not affect grub at all. > > ftp://oss.sgi.com/projects/xfs/download/testing/RH7.2-installer/updates-Nov07-14.img > > -Eric > > On Wed, 2001-11-07 at 15:57, Víctor Reinaldo Prada Jiménez wrote: > > > "RuntimeError /sbin/grub-install can not be run" > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Nov 7 14:34:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7MYf614743 for linux-xfs-outgoing; Wed, 7 Nov 2001 14:34:41 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7MYX014717 for ; Wed, 7 Nov 2001 14:34:33 -0800 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 OAA01798 for ; Wed, 7 Nov 2001 14:34:25 -0800 (PST) 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 QAA3530096; Wed, 7 Nov 2001 16:33:08 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA18106; Wed, 7 Nov 2001 16:33:08 -0600 (CST) Subject: Re: RH7.2 installer - updates disk From: Eric Sandeen To: =?ISO-8859-1?Q?V=EDctor?= Reinaldo Prada =?ISO-8859-1?Q?Jim=E9nez?= Cc: linux-xfs@oss.sgi.com In-Reply-To: <3BE9B4EE.C83152B0@corvusnet.com> References: <1005161234.5256.89.camel@stout.americas.sgi.com> <3BE9AE43.1B4109F1@corvusnet.com> <1005171013.5256.124.camel@stout.americas.sgi.com> <3BE9B4EE.C83152B0@corvusnet.com> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/0.16 (Preview Release) Date: 07 Nov 2001 16:32:24 -0600 Message-Id: <1005172345.1925.133.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fA7MYb014719 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Victor - On Wed, 2001-11-07 at 16:25, Víctor Reinaldo Prada Jiménez wrote: > Eric Sandeen escribió: > > It was in a pop-up window, then i'd check if /sbin/grub-install was there and wasn't Just to be sure - when it says "/sbin/grub-install" it's really trying to run /mnt/sysimage/sbin/grub-install. Did you check for /sbin/grub-install, or /mnt/sysimage/sbin/grub-install? > so > i modify the scrip upd-instroot to add the grub package and keep it in the instalation > process..... but the grub rpm install the grub-install program in > /usr/sbin/grub-install That doesn't sound quite right... $ rpm -qpl /mnt/cdrom/RedHat/RPMS/grub-0.90-11.2.i386.rpm | grep install $ /sbin/grub-install When grub is installed, it's actually running off the installed system at this point, not from the installer environment. > do you have any tips or advices on this??? Not yet. :) -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 Nov 7 14:35:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7MZEU14878 for linux-xfs-outgoing; Wed, 7 Nov 2001 14:35:14 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7MZ8014843 for ; Wed, 7 Nov 2001 14:35:08 -0800 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Nov 2001 16:34:37 -0600 Message-ID: <85063BBE668FD411944400D0B744267A88872A@AUSMAIL> From: "Gonyou, Austin" To: "'Ralf G. R. Bergs'" , Linux XFS Mailing List Subject: RE: WANTED: most stable 2.4 kernel ver. plus XFS patches for SMP machines Date: Wed, 7 Nov 2001 16:34:36 -0600 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 >From a full working, everything works, works well perspective, I'd say that 2.4.14 is the best choice. 1. The New VM implementation has been decided as a winner. 2. 2.5 is opening soon, so it's quite likely that the 2.4 VM implementation will be in maintenance mode. 3. Recent issues concerning DMAPI on XFS were recently solved and the verification will be coming soon to say it is definitely fixed with some tests I've been running. 4. 2.4.14 is the most stable implementation of the new VM code + networking code that exists to date, on the 2.4 series. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Ralf G. R. Bergs [mailto:rabe@RWTH-Aachen.DE] > Sent: Wednesday, November 07, 2001 1:22 AM > To: Linux XFS Mailing List > Subject: WANTED: most stable 2.4 kernel ver. plus XFS patches for SMP > machines > > > Hi there, > > we would like to migrate our fileserver to XFS as quickly as possible. > > Therefore, can you recommend the most stable 2.4.x kernel > version plus suitable > XFS patches? > > In case it matters we run Debian stable. We will add the > "Bunk" repository to > our APT sources list in order to update the system to be > 2.4-ready when it's > time to migrate. > > Thanks, > > Ralf > > > -- > Verkaufe Original-BMW-Raeder: L I N U X .~. > http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ > of a GNU /( )\ > Generation ^^-^^ > From owner-linux-xfs@oss.sgi.com Wed Nov 7 17:47:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA81lJR18827 for linux-xfs-outgoing; Wed, 7 Nov 2001 17:47:19 -0800 Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA81lE018805 for ; Wed, 7 Nov 2001 17:47:14 -0800 Received: from static031-81-151-24.nm01-c3.cpe.charter-ne.com ([24.151.81.31] helo=dhcp10) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 161eHX-0003xF-00; Wed, 07 Nov 2001 17:47:03 -0800 Message-ID: <009301c167f7$160628d0$0a00a8c0@intranet.mp3s.com> Reply-To: "Sean Elble" From: "Sean Elble" To: "Eric Sandeen" Cc: "Tux mailing list" , "XFS Mailing list" References: <02bb01c16720$7fd7d470$0a00a8c0@intranet.mp3s.com><3BE8A074.8494050A@sgi.com> <03bd01c16739$2318cff0$0a00a8c0@intranet.mp3s.com> <1005150602.5256.72.camel@stout.americas.sgi.com> Subject: Re: XFS+Tux = patch trouble Date: Wed, 7 Nov 2001 20:38:39 -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 Eric, Thanks for the clarification . . . makes a bit of a difference, don't you think? :-) Either way, it's 48k well worth sticking into the Linus kernel . . .hope he gets around to it soon. Thanks again, and have a good one! ----------------------------------------------- Sean P. Elble Editor, Writer, Co-Webmaster ReactiveLinux.com (Formerly MaximumLinux.org) http://www.reactivelinux.com/ elbles@reactivelinux.com ----------------------------------------------- ----- Original Message ----- From: "Eric Sandeen" To: "Sean Elble" Cc: "Tux mailing list" ; "XFS Mailing list" Sent: Wednesday, November 07, 2001 11:30 AM Subject: Re: XFS+Tux = patch trouble > Hi Sean - I guess I wasn't quite clear. That 48k refers only to code > changes in the core linux kernel, and does NOT include fs/pagebuf, > fs/xfs, or fs/xfs_support. > > -Eric > > On Tue, 2001-11-06 at 21:05, Sean Elble wrote: > > Whoa . . . I didn't realize that the patch was only 48k. But does that > > include all the XFS "dependences", like the Page Buffer code, etc.? I would > > imagine that it does, but just checking . . . > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Nov 7 17:50:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA81ohw19036 for linux-xfs-outgoing; Wed, 7 Nov 2001 17:50:43 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA81of019013 for ; Wed, 7 Nov 2001 17:50:41 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fA81oZT23836 for ; Wed, 7 Nov 2001 17:50:35 -0800 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id MAA31564; Thu, 8 Nov 2001 12:49:34 +1100 Date: Thu, 8 Nov 2001 12:49:34 +1100 From: Keith Owens Message-Id: <200111080149.MAA31564@sherman.melbourne.sgi.com> Subject: TAKE - Make references to CONFIG_XFS_DMAPI consistent Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Nov 7 17:49:09 PST 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:106296a linux/mm/mprotect.c - 1.18 linux/fs/xfs/xfs_log_recover.c - 1.214 linux/fs/xfs/linux/xfs_file.c - 1.53 From owner-linux-xfs@oss.sgi.com Wed Nov 7 17:54:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA81sjB19185 for linux-xfs-outgoing; Wed, 7 Nov 2001 17:54:45 -0800 Received: from devserv.devel.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA81se019163 for ; Wed, 7 Nov 2001 17:54:40 -0800 Received: (from sct@localhost) by devserv.devel.redhat.com (8.11.0/8.11.0) id fA81sNn30523; Wed, 7 Nov 2001 20:54:23 -0500 Date: Thu, 8 Nov 2001 01:26:10 +0000 From: Stephen Tweedie To: Nathan Scott Cc: Andi Kleen , Linus Torvalds , Andreas Gruenbacher , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, acl-devel@bestbits.at, linux-xfs@oss.sgi.com Subject: Re: [Acl-Devel] Re: [RFC][PATCH] extended attributes Message-ID: <20011108012610.C12638@redhat.com> References: <20011107111224.C591676@wobbly.melbourne.sgi.com> <20011107023218.A4754@wotan.suse.de> <20011107141956.F591676@wobbly.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: <20011107141956.F591676@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Wed, Nov 07, 2001 at 02:19:56PM +1100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, On Wed, Nov 07, 2001 at 02:19:56PM +1100, Nathan Scott wrote: > On Wed, Nov 07, 2001 at 02:32:18AM +0100, Andi Kleen wrote: > > EA_FIRST_ENTRY to reset the fd the first entry, EA_READ_ENTRY to > > read the next one. > > I'm not sure this would work for the extattr/lextattr variants where > we don't have an fd to hold the state. > eg. the opening of the file before allowing a list operation could > have implications for XFSs DMAPI support (open might recall data from > tape), There are other much more immediate obstacles: opening /dev/* is not possible if the devices beneath the inodes don't exist. O_OPENONLY (implying neither read nor write access) to get a stub file handle for such inodes is possible, if a bit hackish. There's a problem in the kernel there --- kernel file descriptor operations on "special" inodes such as named sockets/pipes or device nodes don't pass file operations on to the underlying filesystem. As long as you're doing the ACL stuff via inode operations internally, that's not a problem. However, inode operations generally don't take a file descriptor as an argument so you don't have access to the cursor in that case. The DMAPI and special inode problems go away if you don't demand a file descriptor to the file. (Having a file descriptor that specifically belongs to the ACL stream is a different matter entirely.) --Stephen From owner-linux-xfs@oss.sgi.com Wed Nov 7 19:23:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA83Nkv21168 for linux-xfs-outgoing; Wed, 7 Nov 2001 19:23:46 -0800 Received: from www.fortuitous.com (cs6625128-203.austin.rr.com [66.25.128.203]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA83Nh021146 for ; Wed, 7 Nov 2001 19:23:44 -0800 Received: by www.fortuitous.com (Postfix, from userid 500) id 95AD6D8; Wed, 7 Nov 2001 21:23:40 -0600 (CST) Date: Wed, 7 Nov 2001 21:23:40 -0600 From: pac@fortuitous.com To: linux-xfs@oss.sgi.com Subject: Coda anyone? Message-ID: <20011107212340.A25294@bistro.marx> Reply-To: pac@fortuitous.com References: <85063BBE668FD411944400D0B744267A88872A@AUSMAIL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <85063BBE668FD411944400D0B744267A88872A@AUSMAIL>; from austin@coremetrics.com on Wed, Nov 07, 2001 at 04:34:36PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Anyone use Coda. How does it work these days, and does it work with all the new kernels? Please chime in.. -pac -- .--------------------------------------------------------. | Dr. Philip A. Carinhas | pac@fortuitous.com | | Fortuitous Technologies Inc. | http://fortuitous.com | | Linux Consulting & Training | Tel : 1-512-467-2154 | `--------------------------------------------------------' From owner-linux-xfs@oss.sgi.com Wed Nov 7 20:26:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA84QMF22236 for linux-xfs-outgoing; Wed, 7 Nov 2001 20:26:22 -0800 Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA84QG022214 for ; Wed, 7 Nov 2001 20:26:16 -0800 Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id fA84Q8R23169 for ; Thu, 8 Nov 2001 13:26:09 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id fA84Q7a00871 for ; Thu, 8 Nov 2001 13:26:07 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id fA84Q6i23531 for ; Thu, 8 Nov 2001 13:26:06 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA412 for ; Thu, 8 Nov 2001 13:26:04 +0900 Received: FROM tnesgate.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Thu Nov 08 13:26:03 2001 +0900 Received: from rifu.bsd.tnes.nec.co.jp (IDENT:root@rifu.bsd.tnes.nec.co.jp [10.1.101.142]) by tnesgate.tnes.nec.co.jp (8.9.3/3.7W00091816) with ESMTP id NAA78738; Thu, 8 Nov 2001 13:26:03 +0900 (JST) Received: from tagajo.bsd.tnes.nec.co.jp (tagajo.bsd.tnes.nec.co.jp [10.1.101.146]) by rifu.bsd.tnes.nec.co.jp (8.10.2+3.3W/3.7W/BSD-TNES-MX01) with ESMTP id fA84Q3R19863; Thu, 8 Nov 2001 13:26:03 +0900 Received: (from sasaki@localhost) by tagajo.bsd.tnes.nec.co.jp (8.8.5+2.7Wbeta5/3.5Wpl1-97090809) id NAA25457; Thu, 8 Nov 2001 13:26:03 +0900 (JST) Message-Id: <200111080426.NAA25457@tagajo.bsd.tnes.nec.co.jp> To: Dean Roehrich cc: linux-xfs@oss.sgi.com Subject: Re: wbee (sample_hsm) dumped core In-reply-to: Your message of Tue, 06 Nov 2001 10:15:01 -0600. <200111061615.KAA19724@slobber.americas.sgi.com> Date: Thu, 08 Nov 2001 13:26:03 +0900 From: Takayuki Sasaki Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Dean Roehrich wrote: > > >> >In the above situation, I killed the stalled command ( cp ) and > >> >migin by pressing Ctrl + c to find out what is wrong. Then, > >> >unmount the XFS file system, the following console messages > >> >appeared: > >> > > >> > XFS unmount got error 16 > >> > linvfs_put_super: vfsp/0xc2acb38c left dangling! > >> > VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice > >day > > I didn't forget about you :) I'm relieved to here it :) > The problem happens because invisible I/O was not invisible, causing DMAPI to > deadlock on itself. Then you end up with busy vnodes and a mess. > > The VOP_READ/VOP_WRITE calls in xfs_dm_rdwr() were not sending the O_INVISIBLE > flag. I just checked in a fix, and it should make its way to CVS soon. Thanks Dean! cheers. ----- Takayuki From owner-linux-xfs@oss.sgi.com Wed Nov 7 21:10:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA85Anb23208 for linux-xfs-outgoing; Wed, 7 Nov 2001 21:10:49 -0800 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 fA85Af023123 for ; Wed, 7 Nov 2001 21:10:42 -0800 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 GAA1663170 for ; Thu, 8 Nov 2001 06:10:38 +0100 (CET) mail_from (eric@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 XAA2901561 for ; Wed, 7 Nov 2001 23:09:21 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id XAA69458 for ; Wed, 7 Nov 2001 23:09:21 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id fA858ZW21350; Wed, 7 Nov 2001 23:08:35 -0600 Message-Id: <200111080508.fA858ZW21350@stout.americas.sgi.com> Date: Wed, 7 Nov 2001 23:08:35 -0600 From: Eric Sandeen Subject: TAKE - Merge up to 2.4.15-pre1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Merge up to 2.4.15-pre1 Date: Wed Nov 7 21:08:14 PST 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:106301a linux/Documentation/networking/ifenslave.c - 1.1 linux/drivers/atm/idt77252_tables.h - 1.1 linux/drivers/atm/idt77252.h - 1.1 linux/Documentation/networking/bonding.txt - 1.1 linux/drivers/atm/idt77252.c - 1.1 linux/net/ipv4/ip_input.c - 1.13 linux/net/ipv4/icmp.c - 1.24 linux/net/core/dev.c - 1.48 linux/mm/vmscan.c - 1.90 linux/mm/swap.c - 1.20 linux/mm/page_alloc.c - 1.69 linux/include/linux/swap.h - 1.49 linux/include/linux/sockios.h - 1.9 linux/include/linux/mm.h - 1.73 linux/include/linux/kernel.h - 1.28 linux/include/asm-i386/system.h - 1.22 linux/drivers/block/ps2esdi.c - 1.25 linux/arch/sparc64/kernel/ioctl32.c - 1.46 linux/Makefile - 1.151 linux/MAINTAINERS - 1.82 linux/Documentation/networking/multicast.txt - 1.5 linux/Documentation/devices.txt - 1.11 linux/Documentation/Configure.help - 1.115 linux/drivers/atm/atmdev_init.c - 1.9 linux/drivers/atm/Makefile - 1.15 linux/drivers/atm/Config.in - 1.11 linux/include/asm-sparc/pci.h - 1.9 linux/Documentation/filesystems/proc.txt - 1.8 linux/include/linux/pci_ids.h - 1.51 linux/drivers/pci/pci.ids - 1.38 linux/drivers/i2c/i2c-core.c - 1.13 linux/drivers/net/bonding.c - 1.7 linux/include/linux/if_bonding.h - 1.3 linux/net/ipv4/netfilter/ipt_TOS.c - 1.6 linux/net/ipv4/netfilter/ip_nat_core.c - 1.7 linux/net/ipv4/netfilter/ip_fw_compat.c - 1.9 linux/Documentation/i386/boot.txt - 1.3 linux/arch/i386/kernel/dmi_scan.c - 1.9 linux/Documentation/s390/chandev.8 - 1.5 linux/arch/s390x/kernel/ioctl32.c - 1.4 linux/net/ipv4/netfilter/ipt_TCPMSS.c - 1.3 linux/Documentation/s390/Debugging390.txt - 1.3 linux/drivers/mtd/chips/jedec.c - 1.3 linux/drivers/char/drm/drm_vm.h - 1.8 linux/drivers/mtd/chips/jedec_probe.c - 1.2 linux/fs/isofs/compress.c - 1.2 From owner-linux-xfs@oss.sgi.com Wed Nov 7 22:48:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA86muV24484 for linux-xfs-outgoing; Wed, 7 Nov 2001 22:48:56 -0800 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 fA86mr024462 for ; Wed, 7 Nov 2001 22:48:53 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 9A04F1E274; Thu, 8 Nov 2001 07:48:47 +0100 (MET) Date: Thu, 8 Nov 2001 07:48:43 +0100 From: Andi Kleen To: Nathan Scott Cc: Andi Kleen , Linus Torvalds , Andreas Gruenbacher , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, acl-devel@bestbits.at, linux-xfs@oss.sgi.com Subject: Re: [RFC][PATCH] extended attributes Message-ID: <20011108074843.A11858@wotan.suse.de> References: <20011107111224.C591676@wobbly.melbourne.sgi.com> <20011107023218.A4754@wotan.suse.de> <20011107141956.F591676@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <20011107141956.F591676@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Wed, Nov 07, 2001 at 02:19:56PM +1100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Nov 07, 2001 at 02:19:56PM +1100, Nathan Scott wrote: > I'm not sure this would work for the extattr/lextattr variants where > we don't have an fd to hold the state. Should the list operation Right. I forgot that. Then I guess it is better to use EA_LIST_SIZE / EA_GET_LIST (EAGAIN on race) Whole point is to just avoid to have an stateless cursor. -Andi From owner-linux-xfs@oss.sgi.com Thu Nov 8 00:19:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA88JEQ25734 for linux-xfs-outgoing; Thu, 8 Nov 2001 00:19:14 -0800 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 fA88J5025710 for ; Thu, 8 Nov 2001 00:19:05 -0800 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 JAA1295566 for ; Thu, 8 Nov 2001 09:19:02 +0100 (CET) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id TAA85543; Thu, 8 Nov 2001 19:17:42 +1100 (AEDT) Date: Thu, 8 Nov 2001 19:17:42 +1100 From: Timothy Shimmin To: Ethan Benson Cc: linux-xfs@oss.sgi.com Subject: Re: Interesting XFS Behavior Message-ID: <20011108191742.U52179@boing.melbourne.sgi.com> References: <20011105225039.A599@asterix.gallien.de> <1005058628.15251.15.camel@jen.americas.sgi.com> <01110610360706.01823@office3> <20011107005250.V887@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20011107005250.V887@plato.local.lan>; from erbenson@alaska.net on Wed, Nov 07, 2001 at 12:52:50AM -0900 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I don't think this is really an XFS issue but.. On Wed, Nov 07, 2001 at 12:52:50AM -0900, Ethan Benson wrote: > On Tue, Nov 06, 2001 at 10:36:07AM -0500, Jeff Breitner wrote: > > However, what's interesting is that after the user attempts this, the null > > file ".donotdelete" disappears. Where does it go? And even though it's > > gone, further attempts at removal are still met with "permission denied". > > As user root, the file can't be listed nor deleted by name -- it just > > vanishes although something thinks it is there because only root can kill the > > directory containing the null file. > > > > This is the behavior on my Irix 6.2 box as well (a feather in the cap of > > consistency). > > > > Any ideas what's going on? > > perhaps you don't have write permission to the parent directory? a > directory like a file can only be removed if you have permission to > the directory that contains it. Oh, ok, now I understand what Jeff was trying to do. So there is no file which has vanished and yet still there - it _has_ been deleted. It's just that he couldn't delete the containing directory. Yeah, AFAIK, you can't delete a directory entry from a directory when you don't have write and exec permission in that directory. Looking at linux/fs/namei.c, it seems that the function "may_delete", does the testing for this. It has the comment: /* * Check whether we can remove a link victim from directory dir, check * whether the type of victim is right. * 1. We can't do it if dir is read-only (done in permission()) * 2. We should have write and exec permissions on dir * 3. We can't remove anything from append-only dir * 4. We can't do anything with immutable dir (done in permission()) * 5. If the sticky bit on dir is set we should either * a. be owner of dir, or * b. be owner of victim, or * c. have CAP_FOWNER capability * 6. If the victim is append-only or immutable we can't do antyhing with * links pointing to it. * 7. If we were asked to remove a directory and victim isn't one - ENOTDIR. * 8. If we were asked to remove a non-directory and victim isn't one - EISDIR. * 9. We can't remove a root or mountpoint. */ static inline int may_delete(struct inode *dir,struct dentry *victim, int isdir) --Tim From owner-linux-xfs@oss.sgi.com Thu Nov 8 02:21:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8ALBc28702 for linux-xfs-outgoing; Thu, 8 Nov 2001 02:21:11 -0800 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 fA8AL7028665 for ; Thu, 8 Nov 2001 02:21:08 -0800 Received: from heppcl.ph.qmw.ac.uk ([138.37.50.187]) by zeta.qmw.ac.uk with esmtp (Exim 3.32 #1) id 161mIM-00040k-00; Thu, 08 Nov 2001 10:20:26 +0000 Received: from heppcy.ph.qmw.ac.uk (heppcy.ph.qmw.ac.uk [138.37.51.67]) by heppcl.ph.qmw.ac.uk (8.11.6/8.9.3) with ESMTP id fA8AKQh13340; Thu, 8 Nov 2001 10:20:26 GMT Received: from localhost (pd@localhost) by heppcy.ph.qmw.ac.uk (8.11.6/8.9.3) with ESMTP id fA8AKQV08326; Thu, 8 Nov 2001 10:20:26 GMT X-Authentication-Warning: heppcy.ph.qmw.ac.uk: pd owned process doing -bs Date: Thu, 8 Nov 2001 10:20:25 +0000 (GMT) From: "P.Dixon" To: Eric Sandeen cc: Subject: Re: Test RH 7.2 installer available In-Reply-To: <1005166443.5256.111.camel@stout.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 Eric, > Yikes! Those are all our packages... on the other hand, a test box I > just installed is fine in that respect. You might run "rpm -Va | grep > missing" to see if there is anything else missing. > Nothing else is missing. I'll try the gui install on another box and see if this reports any missing files. > I assume you had plenty of disk space for the install? > Yup. The install took 59% of a 4 Gig partition. Cheerio, Paul From owner-linux-xfs@oss.sgi.com Thu Nov 8 03:13:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8BDaT29578 for linux-xfs-outgoing; Thu, 8 Nov 2001 03:13:36 -0800 Received: from queen.bee.lk (queen.bee.lk [203.143.12.182]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8BDU029556 for ; Thu, 8 Nov 2001 03:13:30 -0800 Received: from anuradha by queen.bee.lk with local (Exim 3.12 #1 (Debian)) id 161n8F-0007ab-00 for ; Thu, 08 Nov 2001 17:14:03 +0600 Date: Thu, 8 Nov 2001 17:14:03 +0600 From: Anuradha Ratnaweera To: linux-xfs@oss.sgi.com Subject: XFS and Raid Message-ID: <20011108171403.A28816@bee.lk> 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 have been running XFS on software raid 1 systems without problems. The xfs filesystem was created without giving any special arguments to mkfs.xfs (except -l internal,8000b). Is there any advantage in specifying chunk size etc. when running mkfs.xfs? If yes, where is it documented? I went through what is on the mkfs.xfs man page but is not inadaquate. And is there any extra care needed when running XFS on software raid than a normal partition? Thanks in advance. Anuradha -- Debian GNU/Linux (kernel 2.4.13) A log may float in a river, but that does not make it a crocodile. From owner-linux-xfs@oss.sgi.com Thu Nov 8 03:56:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8BuIb32658 for linux-xfs-outgoing; Thu, 8 Nov 2001 03:56:18 -0800 Received: from home.smithconcepts.com (65.34.25.157.oviedo-ubr-a.cfl.rr.com [65.34.25.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8BuC032636 for ; Thu, 8 Nov 2001 03:56:12 -0800 Received: from ieee.org (IDENT:Ab3BqjTtQbHDl3RF6GfpJjUNkrPqnBEJ@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id GAA32077; Thu, 8 Nov 2001 06:46:45 -0500 Message-ID: <3BEA728D.C298461C@ieee.org> Date: Thu, 08 Nov 2001 06:54:53 -0500 From: Bryan-TheBS-Smith Organization: SmithConcepts, Inc. X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-7SGI_XFS_PR3smp i686) X-Accept-Language: en MIME-Version: 1.0 To: mailinglists@e-cube.nl CC: linux-xfs@oss.sgi.com, pc_support@matrixlist.com Subject: Re: Adaptec dpt_i2o SCSI raid card References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Joost van der Locht wrote: > For Redhat 7.1 is on the website of Adaptec > (http://linuix.adaptec.com/linux_raid_unsupported.html) a driver disk > available for Redhat 7.1 > Creating an own driver disk can be done like this (thanks to Richard Sharpe, > sharpe@ns.aus.com) > www.cantech.net.au/plug/2001-06/msg00248.html I hope everyone notes these are DPT's old drivers, which I've used in Linux over the years. Unlike Adaptec, they actually created their hardware to an open standard interface (I2O) so one driver could power any board, ATA, SCSI, etc... Too bad DPT has now been consumed by Adaptec, which means support is going out the window. Adaptec themselves are still creating endless, incompatible boards with splintering revisions of the same board for OEMs. Since starting to use Linux in 1993 and seeing one board work and another fail with drivers, as well as a number under Windows as well, I gave up. 3Ware for ATA-RAID, Mylex for SCSI, Advansys/Symbios Logic for plain SCSI, and a few select others (e.g., I'll "tolerate" HighPoint's "trick BIOS" ATA controller chips since their Linux drivers work well) are all I'll use. Until Adaptec and Promise get their acts together (not likely since they get so much business from their "brand name"), I won't be using their products in Linux, or even Windows systems for that matter. You'd figure with their size they'd actually make the best products with the best Linux support? Hardly, both usually lose every benchmark I've seen and Linux support for their products has always been a 3rd party/community proposition, or increasingly binary only for only select products. Just my $0.02 ... -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- * Pentium stop, Pentium SMP go, Athlon MP go ... go very fast! * From owner-linux-xfs@oss.sgi.com Thu Nov 8 05:01:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8D1Dq01368 for linux-xfs-outgoing; Thu, 8 Nov 2001 05:01:13 -0800 Received: from camelot.virtualavalon.net (127bus50.tampabay.rr.com [24.94.127.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8D15001337 for ; Thu, 8 Nov 2001 05:01:07 -0800 Received: from arthur.virtualavalon.net (arthur.virtualavalon.net [172.20.1.10]) by camelot.virtualavalon.net (8.12.0/8.12.0) with ESMTP id fA8D13rh024531 for ; Thu, 8 Nov 2001 08:01:03 -0500 Received: from tampabay.rr.com (wayfarer.virtualavalon.net [172.20.1.15]) by arthur.virtualavalon.net (8.12.0/8.12.0) with ESMTP id fA8D0uL5010244 for ; Thu, 8 Nov 2001 08:00:58 -0500 (EST) Message-ID: <3BEA81FA.4020401@tampabay.rr.com> Date: Thu, 08 Nov 2001 08:00:42 -0500 From: "Jesse W. Asher" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS, Linux, and Solaris. References: <4.3.2.7.2.20011107140934.0323c578@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 Isn't this kinda antithetical to the open source movement? This is basically saying, "Hey, we're going to make something open source, just not on these platforms." Are you saying that the source code can't be used by someone to port it to Solaris, or that it just hasn't been done? Seth Mos wrote: > At 07:31 7-11-2001 -0500, Jesse W. Asher wrote: > >> I'm using XFS on RH7.1 successfully so far and I'm pretty happy with >> it. My problem is a little off topic for this list, but it is >> semi-related. Because I don't want to have to manage another type of >> journaling filesystem, I'd like to run XFS on Solaris 8 and I was >> wondering if it was available for Solaris 8. I have a bunch of Linux >> boxes and one Solaris box and I'd rather not have to go through the >> extra work and I can't get rid of the Solaris box (unfortunately). > > > You will have to convert that solaris box to Linux then. Solaris is > not planned and unless they do some really groovy things with their > code and licenses I don't think it's even possible. > >> Any pointers to a Solaris version of XFS would be appreciated.... > > > There are none. > XFS was specifically put under the GPL to prevent Sun from "just" > incorporating XFS into Solaris at no development cost. > > 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. > > -- Jesse W. Asher "They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty or safety." - Benjamin Franklin From owner-linux-xfs@oss.sgi.com Thu Nov 8 05:10:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8DAqG01663 for linux-xfs-outgoing; Thu, 8 Nov 2001 05:10:52 -0800 Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8DAk001638 for ; Thu, 8 Nov 2001 05:10:46 -0800 Received: from erbenson.alaska.net (230-pm16.nwc.alaska.net [209.112.141.230]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id fA8DAjY45502 for ; Thu, 8 Nov 2001 04:10:45 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 276723990 for ; Thu, 8 Nov 2001 04:10:44 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 50D931026B; Thu, 8 Nov 2001 04:10:43 -0900 (AKST) Date: Thu, 8 Nov 2001 04:10:43 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: XFS, Linux, and Solaris. Message-ID: <20011108041043.F28190@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <4.3.2.7.2.20011107140934.0323c578@pop.xs4all.nl> <3BEA81FA.4020401@tampabay.rr.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DEueqSqTbz/jWVG1" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BEA81FA.4020401@tampabay.rr.com>; from jasher1@tampabay.rr.com on Thu, Nov 08, 2001 at 08:00:42AM -0500 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --DEueqSqTbz/jWVG1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 08, 2001 at 08:00:42AM -0500, Jesse W. Asher wrote: >=20 > Isn't this kinda antithetical to the open source movement? This is=20 > basically saying, "Hey, we're going to make something open source, just= =20 > not on these platforms." >=20 > Are you saying that the source code can't be used by someone to port it= =20 > to Solaris, or that it just hasn't been done? No they are saying they don't want Sun to take the XFS code, slap it in the proprietary Solaris kernel and put out a press release for Solaris 9 boasting a `New Advanced Sun Journaling filesystem'. XFS can only be used on GPL compatible kernels, and only by individuals who are going to keep the code Free. the only exception being Irix of course. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --DEueqSqTbz/jWVG1 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 iEYEARECAAYFAjvqhFMACgkQJKx7GixEevxJDACfVf+nV8zL3FEN+HD/SpwNYaMC IgIAn3TVwPha9ewbCdXttPx1B/dGXgGv =wHk/ -----END PGP SIGNATURE----- --DEueqSqTbz/jWVG1-- From owner-linux-xfs@oss.sgi.com Thu Nov 8 06:18:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8EIBg02872 for linux-xfs-outgoing; Thu, 8 Nov 2001 06:18:11 -0800 Received: from uwast.astro.wisc.edu (uwast.astro.wisc.edu [144.92.179.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8EI5002850 for ; Thu, 8 Nov 2001 06:18:05 -0800 Received: from astro.wisc.edu (voodoo.astro.wisc.edu [144.92.179.132]) by uwast.astro.wisc.edu (8.11.6/8.11.6) with ESMTP id fA8EHxj1452865 for ; Thu, 8 Nov 2001 08:18:00 -0600 (CST) Message-ID: <3BEA9417.3523514D@astro.wisc.edu> Date: Thu, 08 Nov 2001 08:17:59 -0600 From: jansen X-Mailer: Mozilla 4.77C-SGI [en] (X11; U; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: NFS oddity between IRIX 6.5.13m and Linux 2.4.9-13SGI_XFS_PR1smp Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I recently installed RedHat 7.2 using the test installer ISO sgi-image-i386-Nov04-01.iso from oss.sgi.com and everything went without a hitch except GRUB didn't seem to work but that may just be pilot error since I've never used it before. GRUB seemed to install OK and it booted into the GRUB prompt but at that point didn't seem to want to recognize the partittions (sorry I didn't write down the messages). I just booted a off the CD and installed lilo. After the install I noticed one oddity that appears to be harmless but I thought I post it just in case it is not. I NFS mounted one of the Linux machines disks onto an SGI O2 running IRIX 6.5.13m and ran an xfsrestore on the IRIX machine onto the NFS mounted Linux disk. At the start of the xfsrestore I get the following message in syslog (on the IRIX host): Nov 8 07:08:23 4A:irixhost unix: WARNING: nfs3_fid: file handle larger than file ID data area I tried this a few times and it seems to log this message once or twice right at the start of the xfsrestore session and that's it, it doesn't log the message during the rest of the xfsrestore session. I have also seen this message a couple times, I can't associate it with anything at this point other than it appears to happen when working on files on the NFS mounted Linux xfs partition: Nov 8 07:33:05 4A:irixhost unix: |$(0x141)WARNING: do_pdflush: error bp->b_vp 0x4004a0e buffer As I said, it doesn't appear to cause any problems it's just a little disturbing. The Linux machine is a two processor AMD 1.2GHz ASL Marquis C120-A with 1GB of RAM and two 80GB seagate IDE disks. All partitions on the Linux machine are XFS. Let me know if you need any more information. -- ------- Stephan From owner-linux-xfs@oss.sgi.com Thu Nov 8 06:25:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8EPw503205 for linux-xfs-outgoing; Thu, 8 Nov 2001 06:25:58 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8EPr003182 for ; Thu, 8 Nov 2001 06:25:53 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=rover.mkp.net) by rover with esmtp (Exim 3.33 #1) id 161q7p-0006fl-00; Thu, 08 Nov 2001 09:25:50 -0500 Received: (from mkp@localhost) by rover.mkp.net (8.11.2/8.9.3) id fA8EPkp02494; Thu, 8 Nov 2001 09:25:46 -0500 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: Anuradha Ratnaweera Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and Raid References: <20011108171403.A28816@bee.lk> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 08 Nov 2001 09:25:44 -0500 In-Reply-To: <20011108171403.A28816@bee.lk> 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 >>>>> "Anuradha" == Anuradha Ratnaweera writes: Anuradha> Is there any advantage in specifying chunk size etc. when Anuradha> running mkfs.xfs? For RAID1, no. For RAID0 and RAID5, potentially. Anuradha> If yes, where is it documented? I went through what is on Anuradha> the mkfs.xfs man page but is not inadaquate. Have you read the sections about sunit and swidth? In general mkfs.xfs will do the right thing. As the man page states, when you run mkfs on an LVM or MD device it will automagically extract the stripe unit and stripe width. If you have a hardware RAID device, however, you'll have to specify these parameters manually to match the configuration of your device. -- 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 Thu Nov 8 07:39:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8FdkQ04575 for linux-xfs-outgoing; Thu, 8 Nov 2001 07:39:46 -0800 Received: from ikar.t17.ds.pwr.wroc.pl (postfix@ikar.t17.ds.pwr.wroc.pl [156.17.235.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8Fdd004551 for ; Thu, 8 Nov 2001 07:39:39 -0800 Received: by ikar.t17.ds.pwr.wroc.pl (Postfix, from userid 1002) id 09446C8015; Thu, 8 Nov 2001 16:38:56 +0100 (CET) Date: Thu, 8 Nov 2001 16:38:55 +0100 From: Arkadiusz Miskiewicz To: linux-xfs@oss.sgi.com Subject: partition recovery Message-ID: <20011108163855.A19171@ikar.t17.ds.pwr.wroc.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.18i X-URL: http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/ X-Operating-System: Linux dark 4.0.20 #119 czw lis 8 16:23:35 CET 2001 i986 pld Organization: Polish(ed) Linux Distribution Team Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Recently I've crashed both partition tables (1 and 2 copy). My setup was: start end hda1 0.031 10001.250 fat 10001.404 29313.918 extended lba hda5 10001.435 20002.807 xfs hda6 20002.838 20198.913 swap hda7 20198.944 20598.969 ext2 hda8 20599.000 23603.312 xfs hda9 23603.344 29313.918 lvm (values in MB as shown by parted) Now I'm trying to recover xfs partitions. Unfortunately I can't create exactly same partition with same positions as previously. Now fdisk, cfdisk, parted always create partition like this: 2 10001.250 20002.992 primary (rounding to cylinder?) So I'm trying to use xfs_repair (1.2.0) on such (not exacly same as in original) partition but. xfs_repair -n /dev/hda2 Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! ...................................... ... attempting to find secondary superblock... nable to verify superblock, continuing... ... It found more than 5 backup superblocks but it was unable to verify all superblocks. Any hints how to recover data from these partitions? i686, 2.4.13, xfs-20011026 -- Arkadiusz Mi¶kiewicz, AM2-6BONE [ PLD GNU/Linux IPv6 ] http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/ [ enabled ] From owner-linux-xfs@oss.sgi.com Thu Nov 8 08:22:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8GMqD08364 for linux-xfs-outgoing; Thu, 8 Nov 2001 08:22:52 -0800 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 fA8GMl008342 for ; Thu, 8 Nov 2001 08:22:47 -0800 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 IAA22485 for ; Thu, 8 Nov 2001 08:22:37 -0800 (PST) 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 KAA3538553; Thu, 8 Nov 2001 10:21:30 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA03302; Thu, 8 Nov 2001 10:21:27 -0600 (CST) Subject: Re: kickstart and xfs problem From: Eric Sandeen To: root@uulogic.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <200111080737.fA87bkW25286@oss.sgi.com> References: <200111080737.fA87bkW25286@oss.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 08 Nov 2001 10:20:38 -0600 Message-Id: <1005236439.1345.157.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi - For starters, you might consider using the 7.2 installer that is now available... If you need 7.1, I'm not sure why this is failing - are you sure you are running the _XFS_ installer? i.e. either booting from one of the XFS images, the XFS cdrom, or if you made a network installation source, you copied over the XFS cdrom last? -Eric p.s. please don't send HTML email to the list. On Thu, 2001-11-08 at 01:37, root@uulogic.com wrote: > Hi, > I'm using RedHat linux 7.1 . I generaly prefered to install in > kickstart mode. Every thing works fine. > Now I made the following changes to my ks.cfg file inorder to use the > XFS file system instade of default > Red Hat old ext2 . > > part /boot --size 35 --fs xfs > part / --size 2000 --fs xfs > part /home --size 7000 --fs xfs --grow > part swap --size 128 > > I burn the auto installer cd . Now while installing anaconda is giving > error "--fs unknown option" and aborting the installation !!! > > I realy don't know what to do. I can not manualy configure XFS fs > over 500 systems !!! > > please help me. > > -- > Sanat Mohanty > Exaband (India) Pvt.ltd. > > India -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Nov 8 08:27:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8GRfR09117 for linux-xfs-outgoing; Thu, 8 Nov 2001 08:27:41 -0800 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 fA8GRR009083 for ; Thu, 8 Nov 2001 08:27:27 -0800 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 IAA22801 for ; Thu, 8 Nov 2001 08:27:18 -0800 (PST) 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 KAA3531631; Thu, 8 Nov 2001 10:26:10 -0600 (CST) Received: from jen.americas.sgi.com (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 KAA44737; Thu, 8 Nov 2001 10:26:10 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA8GM9N08353; Thu, 8 Nov 2001 10:22:09 -0600 Subject: Re: partition recovery From: Steve Lord To: Arkadiusz Miskiewicz Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011108163855.A19171@ikar.t17.ds.pwr.wroc.pl> References: <20011108163855.A19171@ikar.t17.ds.pwr.wroc.pl> Content-Type: text/plain; charset=UTF-8 X-Mailer: Evolution/0.99.0+cvs.2001.11.06.15.04 (Preview Release) Date: 08 Nov 2001 10:22:09 -0600 Message-Id: <1005236529.8162.12.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fA8GRT009086 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2001-11-08 at 09:38, Arkadiusz Miskiewicz wrote: > Hi, > > Recently I've crashed both partition tables (1 and 2 copy). > My setup was: > start end > hda1 0.031 10001.250 fat > 10001.404 29313.918 extended lba > hda5 10001.435 20002.807 xfs > hda6 20002.838 20198.913 swap > hda7 20198.944 20598.969 ext2 > hda8 20599.000 23603.312 xfs > hda9 23603.344 29313.918 lvm > (values in MB as shown by parted) > > Now I'm trying to recover xfs partitions. Unfortunately > I can't create exactly same partition with same positions > as previously. Now fdisk, cfdisk, parted always create > partition like this: > > 2 10001.250 20002.992 primary > (rounding to cylinder?) > > So I'm trying to use xfs_repair (1.2.0) on such (not exacly > same as in original) partition but. > > xfs_repair -n /dev/hda2 > Phase 1 - find and verify superblock... > bad primary superblock - bad magic number !!! > ...................................... > ... > attempting to find secondary superblock... > nable to verify superblock, continuing... > ... > > It found more than 5 backup superblocks but it was > unable to verify all superblocks. > > Any hints how to recover data from these partitions? > > i686, 2.4.13, xfs-20011026 > -- > Arkadiusz MiÅ›kiewicz, AM2-6BONE [ PLD GNU/Linux IPv6 ] > http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/ [ enabled ] You really need to get the partition back to exactly the same blocks it used to be at - and that is your problem here, unless you have partition table output which is in sector format, getting the same ones back again is really hard. You could look at the raw disk for the xfs superblock, this is placed in sector zero of the partition, so it would be a good indication of the sector you need the partition to start at. The superblock starts with the string XFSB, so dumping the disk out you would see something like this: od -c /dev/hda | more 0000000 ú ë | l b a L I L O 001 \0 025 004 Z \0 0000020 \0 \0 001 ã S 024 S ; 030 002 200 y 001 031 002 200 0000040 y 001 027 002 200 y 001 001 \0 \0 \0 \0 \0 \0 \0 033 0000060 002 200 y 001 \a 001 200 G 001 \b 001 200 G 001 \t 001 0000100 200 G 001 \n 001 200 G 001 \v 001 200 G 001 \f 001 200 0000120 G 001 \r 001 200 G 001 016 001 200 G 001 017 001 200 G 0000140 001 020 001 200 G 001 021 001 200 G 001 \0 \0 \0 \0 \0 0000160 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 ¸ 0000200 À \a 216 Ø 214 006 z \0 211 6 x \0 211 036 | \0 0000220 210 026 ~ \0 ¸ \0 232 216 À ¹ \0 001 ) ö ) ÿ 0000240 ü ó Â¥ ê ¨ \0 \0 232 216 Ø ¸ \0 220 216 à ¼ 0000260 \0 ° û ° \r è i \0 ° \n è d \0 ° L è 0000300 _ \0 ¾ 4 \0 h \0 \v \a 1 Û ­ 221 ¬ ¨ ` 0000320 u 017 N ­ 211  \t È t 034 ¬ ´ 002 à 023 ë 0000340 016 210  ­ ö  u 002 0 ä 227 è ; \0 r 0000360 017 200 Ç 002 ë Õ ° I è & \0 ê \0 \0 \0 \v 0000400 ° è 034 \0 è 006 \0 1 À à 023 ë ´ à À 0000420 004 è 003 \0 à À 004 $ 017 004 0 < : r 002 004 0000440 \a P 0 ÿ ´ 016 à 020 X à V Q S 210 Ó 200 0000460 â 217 ö à @ u 3 » ª U ¸ \0 A à 023 r 0000500 ) 201 û U ª u # ö à 001 t 036 [ Y 036 1 0000520 ö V V W Q 006 S j 001 j 020 211 æ 026 037 ¸ 0000540 \0 B à 023 215 d 020 037 ë D [ Y S R W Q 0000560 006 ´ \b à 023 \a r 8 Q À é 006 206 é 211 à 0000600 Y 210 ð þ À 200 á ? ö á 226 X Z 9 ò s 0000620 # ÷ ö 9 ø w 035 À ä 006 206 à 222 ö ñ þ 0000640 Ä \0 â 211 Ñ Z [ 206 ð ¸ 001 002 à 023 ^ à 0000660 Y _ ë 002 ´ @ \0 \0 \0 \0 \0 \0 \0 \0 200 001 0000700 001 \0 203 þ ? A ? \0 \0 \0 203 - 020 \0 \0 \0 0000720 001 B 005 þ ÿ ÿ  - 020 \0 Û 002 ! 001 \0 \0 0000740 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000760 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 U ª 0001000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0077000 X F S B \0 \0 020 \0 \0 \0 \0 \0 \0 002 005 ° 0077020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0077040 ~ ì 034 024 z 004 021 Õ 222 Æ ú B 200 $ ì À 0077060 \0 \0 \0 \0 \0 002 \0 004 \0 \0 \0 \0 \0 \0 \0 200 0077100 \0 \0 \0 \0 \0 \0 \0 201 \0 \0 \0 \0 \0 \0 \0 202 0077120 \0 \0 \0 020 \0 \0 @ ¶ \0 \0 \0 \b \0 \0 \0 \0 0077140 \0 \0 004 ° 204 002 \0 001 \0 \0 020 / b o o 0077160 t \0 \0 \0 \0 \0 \0 \0 \f \t \b 004 017 \0 \0 031 0077200 \0 \0 \0 \0 \0 \0 \0 200 \0 \0 \0 \0 \0 \0 \0 @ 0077220 \0 \0 \0 \0 \0 001 Ó à \0 \0 \0 \0 \0 \0 \0 \0 0077240 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0077260 \0 \0 \0 \0 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 \0 0077300 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0100000 X A G F \0 \0 \0 001 \0 \0 \0 \0 \0 \0 @ ¶ 0100020 \0 \0 \0 001 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 001 0100040 \0 \0 \0 001 \0 \0 \0 \0 \0 \0 \0 \b \0 \0 \0 \v 0100060 \0 \0 \0 004 \0 \0 023 233 \0 \0 \v ï \0 \0 \0 \0 0100100 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 Here you see the superblock, followed by the AGF structure. Best of luck Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Nov 8 08:38:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8GcPO09957 for linux-xfs-outgoing; Thu, 8 Nov 2001 08:38:25 -0800 Received: from hoju-ext.nks.net (hoju-ext.nks.net [216.139.204.180]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8GcH009935 for ; Thu, 8 Nov 2001 08:38:17 -0800 Received: from illusionary.com (two.nks.net [192.168.1.22]) by hoju-ext.nks.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA13658 for ; Thu, 8 Nov 2001 11:38:11 -0500 Message-ID: <3BEAB4F3.503AD086@illusionary.com> Date: Thu, 08 Nov 2001 11:38:11 -0500 From: Derek Glidden X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.13-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS, Linux, and Solaris. References: <4.3.2.7.2.20011107140934.0323c578@pop.xs4all.nl> <3BEA81FA.4020401@tampabay.rr.com> <20011108041043.F28190@plato.local.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ethan Benson wrote: > > On Thu, Nov 08, 2001 at 08:00:42AM -0500, Jesse W. Asher wrote: > > > > Isn't this kinda antithetical to the open source movement? This is > > basically saying, "Hey, we're going to make something open source, just > > not on these platforms." > > > > Are you saying that the source code can't be used by someone to port it > > to Solaris, or that it just hasn't been done? > > No they are saying they don't want Sun to take the XFS code, slap it > in the proprietary Solaris kernel and put out a press release for > Solaris 9 boasting a `New Advanced Sun Journaling filesystem'. > > XFS can only be used on GPL compatible kernels, and only by > individuals who are going to keep the code Free. the only exception > being Irix of course. Didn't Sun announce a few months ago some sort of "Linux Driver Compatiblity Porting Project System" thingie that was supposed to make it "real easy" to take Linux device driver code and rebuild it under Solaris and plug it in as a kernel module? I remember a big brouhaha because they had specifically designed it so you could build your GPL code as a Solaris-equivalent of a "binary-only kernel module" and then load it at boot/run time into a Solaris kernel, thereby avoiding any GPL issues because you weren't actually linking the code, so technically you weren't violating the GPL, but very much against the spirit of what the GPL is supposed to be about. It doesn't seem like quite such a big deal except that Sun was explicitly touting it as a way to use GPL code under Solaris without having to release any additional source code. I don't recall if it extended as far as the VFS layer though, or just device drivers. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/usr/bin/perl -w $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} print+x"C*",@a}';s/x/pack+/g;eval usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec - http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/ http://www.sciencemag.org/cgi/content/full/293/5537/2028 From owner-linux-xfs@oss.sgi.com Thu Nov 8 08:44:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8Gia710321 for linux-xfs-outgoing; Thu, 8 Nov 2001 08:44:36 -0800 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8GiY010299 for ; Thu, 8 Nov 2001 08:44:34 -0800 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 1B8AD1AB2A for ; Thu, 8 Nov 2001 11:44:31 -0500 (EST) Received: by ranma.dkp.com (Postfix, from userid 168) id 948E85A2B3; Thu, 8 Nov 2001 11:44:30 -0500 (EST) Date: Thu, 8 Nov 2001 11:44:30 -0500 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: XFS, Linux, and Solaris. Message-ID: <20011108114430.B7212@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <4.3.2.7.2.20011107140934.0323c578@pop.xs4all.nl> <3BEA81FA.4020401@tampabay.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BEA81FA.4020401@tampabay.rr.com> User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Nov 08, 2001 at 08:00:42AM -0500, Jesse W. Asher wrote: > Isn't this kinda antithetical to the open source movement? > This is basically saying, "Hey, we're going to make something > open source, just not on these platforms." Sure, Solaris could use XFS. They'd just have to GPL whatever code they released it with. :) Andrew Klaassen - why don't you send them an email, ask them if they would do it? From owner-linux-xfs@oss.sgi.com Thu Nov 8 12:14:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8KE1426855 for linux-xfs-outgoing; Thu, 8 Nov 2001 12:14:01 -0800 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8KDt026832 for ; Thu, 8 Nov 2001 12:13:55 -0800 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id PAA31490; Thu, 8 Nov 2001 15:13:46 -0500 Message-ID: <3BEAE784.87ADBA1D@ieee.org> Date: Thu, 08 Nov 2001 15:13:56 -0500 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Jesse W. Asher" CC: linux-xfs@oss.sgi.com Subject: Re: XFS, Linux, and Solaris. -- Dual GPL/Commercial Licensing References: <4.3.2.7.2.20011107140934.0323c578@pop.xs4all.nl> <3BEA81FA.4020401@tampabay.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Jesse W. Asher" wrote: > Isn't this kinda antithetical to the open source movement? This is > basically saying, "Hey, we're going to make something open source, just > not on these platforms." No, it's the _exact_opposite_, "we're going to make something open source, just not on these closed-source platforms." That's what the GPL is all about, instead of other licenses like BSD. If Sun wants XFS for closed-source Solaris, they can commercially license it from SGI since they hold the copyright. This what we mean about free software being "free speech," not "free beer." Dual-licensed GPL/commercial is a very powerful profit model. The community gets it and gets to refine it for free, but your competitors don't. And if the product is good, the community will adopt it as a standard, and then marketshare forces your competitors either out, or to work with you on it. But the best part is that the community decides whether or not your product is good and should be used widespread, not your marketing department. > Are you saying that the source code can't be used by someone to port it > to Solaris, or that it just hasn't been done? If you have the access to the Solaris source code, you can take the XFS source and port it as long as the end-result is only used internally. GPL allows this, unlike many commercial open source licenses (e.g., Apple, Sun, Netscape, etc...). -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- "The [US] Constitution guarantees you Free, not Fair. 'Fair' is a socialist concept." -- Shawn McMahon From owner-linux-xfs@oss.sgi.com Thu Nov 8 12:19:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8KJWv27989 for linux-xfs-outgoing; Thu, 8 Nov 2001 12:19:32 -0800 Received: from smtp.pkwhelan.net (dsl092-072-121.bos1.dsl.speakeasy.net [66.92.72.121]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8KJS027967 for ; Thu, 8 Nov 2001 12:19:28 -0800 Received: (qmail 18949 invoked by uid 500); 8 Nov 2001 20:26:07 -0000 Date: Thu, 8 Nov 2001 15:26:07 -0500 From: pkw@pkwhelan.net To: linux-xfs@oss.sgi.com Subject: Compile errors with 2.4.14 kernel Message-ID: <20011108152607.A22784@stonewall.pkwhelan.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 Hi, I used the linux-2.4.14-xfs-2001-11-07.patch.bz2 patch against a clean 2.4.14 tree. The patch applied cleanly but will not compile. This is the error message I get: ===begin error message=== fs/fs.o(__ksymtab+0x28): multiple definition of `__ksymtab_create_empty_buffers' kernel/kernel.o(__ksymtab+0x580): first defined here fs/fs.o(__ksymtab+0x20): multiple definition of `__ksymtab_set_bh_page' kernel/kernel.o(__ksymtab+0x7c0): first defined here fs/fs.o(.kstrtab+0x55): multiple definition of `__kstrtab_set_bh_page' kernel/kernel.o(.kstrtab+0xe51): first defined here fs/fs.o(.kstrtab+0x61): multiple definition of `__kstrtab_create_empty_buffers' kernel/kernel.o(.kstrtab+0x9fe): first defined here make[1]: *** [kallsyms] Error 1 make[1]: Leaving directory `/home/pk/patchdir/linux-2.4.14-patched' make: *** [vmlinux] Error ===end error message=== I'm compiling it on RH7.2. I tried using gcc-2.96-98 and then tried using kgcc (egcs-2.91.66) and got the same results. The glibc version is glibc-2.2.4-19 (from redhat). Any tips would be appreciated. Thanks, Paul From owner-linux-xfs@oss.sgi.com Thu Nov 8 13:04:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8L4Pq05790 for linux-xfs-outgoing; Thu, 8 Nov 2001 13:04:25 -0800 Received: from imapserverb.fnal.gov (imapserverb.fnal.gov [131.225.9.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8L4L005767 for ; Thu, 8 Nov 2001 13:04:21 -0800 Received: from imapserverb.fnal.gov ([131.225.9.17]) by imapserverb.fnal.gov (Netscape Messaging Server 4.15) with SMTP id GMI2J800.FAZ for ; Thu, 8 Nov 2001 15:04:20 -0600 Received: from fnal.gov ([131.225.7.82]) by imapserverb.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001110815041912693 for ; Thu, 08 Nov 2001 15:04:19 -0600 Message-ID: <3BEAF354.94BD4AF3@fnal.gov> Date: Thu, 08 Nov 2001 15:04:20 -0600 From: Dan Yocum 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: xfs-list Subject: kernel-2.4.9-13SGI_XFS_PR1 bombs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi guys, I know the Red Hat kernel-2.4.9-13SGI_XFS_PR1 is in testing still, but massive I/O errors occur when I run bonnie++ on my 1.12TB FS - the rest of the partitions seem to be behaving themselves, tho. I'll try to get the error messages next time I boot it up. Cheers, Dan -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Thu Nov 8 13:08:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8L8Z806516 for linux-xfs-outgoing; Thu, 8 Nov 2001 13:08:35 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8L8V006493 for ; Thu, 8 Nov 2001 13:08:31 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fA8L8PT15443 for ; Thu, 8 Nov 2001 13:08:25 -0800 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 PAA3540572; Thu, 8 Nov 2001 15:07:08 -0600 (CST) Received: from jen.americas.sgi.com (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 PAA60959; Thu, 8 Nov 2001 15:07:08 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA8L36B09245; Thu, 8 Nov 2001 15:03:06 -0600 Subject: Re: kernel-2.4.9-13SGI_XFS_PR1 bombs From: Steve Lord To: Dan Yocum Cc: xfs-list In-Reply-To: <3BEAF354.94BD4AF3@fnal.gov> References: <3BEAF354.94BD4AF3@fnal.gov> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.07.16.47 (Preview Release) Date: 08 Nov 2001 15:03:05 -0600 Message-Id: <1005253385.9075.6.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2001-11-08 at 15:04, Dan Yocum wrote: > Hi guys, > > I know the Red Hat kernel-2.4.9-13SGI_XFS_PR1 is in testing still, but > massive I/O errors occur when I run bonnie++ on my 1.12TB FS - the rest of > the partitions seem to be behaving themselves, tho. > > I'll try to get the error messages next time I boot it up. Check your inode size, actually, do this: xfs_db /dev/xxxx sb p and send the output. There was a version of mkfs which would create a bad filesystem above 1 Tbyte. Steve > > Cheers, > > Dan > > > -- > Dan Yocum > Sloan Digital Sky Survey, Fermilab 630.840.6509 > yocum@fnal.gov, http://www.sdss.org > SDSS. Mapping the Universe. -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Nov 8 13:17:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8LHEh06836 for linux-xfs-outgoing; Thu, 8 Nov 2001 13:17:14 -0800 Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8LH8006814 for ; Thu, 8 Nov 2001 13:17:08 -0800 Received: from scare.vieo.com ([63.231.179.33]) by lips.thebarn.com (8.12.0/8.12.0) with ESMTP id fA8LIn8G009183; Thu, 8 Nov 2001 15:18:59 -0600 (CST) Subject: Re: XFS, Linux, and Solaris. -- Dual GPL/Commercial Licensing From: Russell Cattelan To: Bryan-TheBS-Smith Cc: "Jesse W. Asher" , linux-xfs@oss.sgi.com In-Reply-To: <3BEAE784.87ADBA1D@ieee.org> References: <4.3.2.7.2.20011107140934.0323c578@pop.xs4all.nl> <3BEA81FA.4020401@tampabay.rr.com> <3BEAE784.87ADBA1D@ieee.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 08 Nov 2001 15:12:51 -0600 Message-Id: <1005253982.2955.30.camel@scare> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2001-11-08 at 14:13, Bryan-TheBS-Smith wrote: > "Jesse W. Asher" wrote: > > Isn't this kinda antithetical to the open source movement? This is > > basically saying, "Hey, we're going to make something open source, just > > not on these platforms." > > No, it's the _exact_opposite_, "we're going to make something open > source, just not on these closed-source platforms." That's what the GPL > is all about, instead of other licenses like BSD. If Sun wants XFS for > closed-source Solaris, they can commercially license it from SGI since > they hold the copyright. This what we mean about free software being > "free speech," not "free beer." > > Dual-licensed GPL/commercial is a very powerful profit model. The > community gets it and gets to refine it for free, but your competitors > don't. And if the product is good, the community will adopt it as a > standard, and then marketshare forces your competitors either out, or to > work with you on it. But the best part is that the community decides > whether or not your product is good and should be used widespread, not > your marketing department. > > > Are you saying that the source code can't be used by someone to port it > > to Solaris, or that it just hasn't been done? > > If you have the access to the Solaris source code, you can take the XFS > source and port it as long as the end-result is only used internally. > GPL allows this, unlike many commercial open source licenses (e.g., > Apple, Sun, Netscape, etc...). > The terms of the GPL can only compel the copyright holder of "other portions" to release their code GPL'ed. If an independent party was to port XFS to solaris and release it under the GPL it would be within the terms of the GPL since said independent party does have the rights to GPL solaris. This is also true of any BSD's. So if anybody knows enough about solaris vfs/mm and is not bound up by some sort of agreement with Sun, and has a large sum of cash to live on... go for it. XFS-Solaris. It might be interesting to note many small companies previously generously developing GPL'ed products by burning all the VC money they could find are either no longer around or quickly moving to a license model that will allow them SELL a product. From owner-linux-xfs@oss.sgi.com Thu Nov 8 13:24:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8LO9E07284 for linux-xfs-outgoing; Thu, 8 Nov 2001 13:24:09 -0800 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8LO5007255 for ; Thu, 8 Nov 2001 13:24:05 -0800 Received: from ieee.org (IDENT:bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id QAA31746; Thu, 8 Nov 2001 16:23:47 -0500 Message-ID: <3BEAF7ED.E5D417AE@ieee.org> Date: Thu, 08 Nov 2001 16:23:57 -0500 From: Bryan-TheBS-Smith Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-6.2.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Russell Cattelan CC: "Jesse W. Asher" , linux-xfs@oss.sgi.com Subject: Re: XFS, Linux, and Solaris. -- Dual GPL/Commercial Licensing References: <4.3.2.7.2.20011107140934.0323c578@pop.xs4all.nl> <3BEA81FA.4020401@tampabay.rr.com> <3BEAE784.87ADBA1D@ieee.org> <1005253982.2955.30.camel@scare> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Russell Cattelan wrote: > It might be interesting to note many small companies previously > generously developing GPL'ed products by burning all the VC money they > could find are either no longer around or quickly moving to a license > model that will allow them SELL a product. With GPL, the days of getting rich off of selling massively reproduced software is over. You have to find another model to make money in combination with the software. In any case, don't expect to get too rich from it -- unless you really have some innovative ideas and/or concepts. Which is what scares the dickens out of the most profitable of software organizations making, what I would term, "commodity" software. -- TheBS -- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com ---------------------------------------------------------------- "The [US] Constitution guarantees you Free, not Fair. 'Fair' is a socialist concept." -- Shawn McMahon From owner-linux-xfs@oss.sgi.com Thu Nov 8 13:28:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8LSZj07508 for linux-xfs-outgoing; Thu, 8 Nov 2001 13:28:35 -0800 Received: from imapserverb.fnal.gov (imapserverb.fnal.gov [131.225.9.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8LSP007484 for ; Thu, 8 Nov 2001 13:28:25 -0800 Received: from imapserverb.fnal.gov ([131.225.9.17]) by imapserverb.fnal.gov (Netscape Messaging Server 4.15) with SMTP id GMI3NC00.3B9 for ; Thu, 8 Nov 2001 15:28:24 -0600 Received: from fnal.gov ([131.225.7.82]) by imapserverb.fnal.gov (NAVIEG 2.1 bld 63) with SMTP id M2001110815282421037 for ; Thu, 08 Nov 2001 15:28:24 -0600 Message-ID: <3BEAF8F9.D77F2561@fnal.gov> Date: Thu, 08 Nov 2001 15:28:25 -0600 From: Dan Yocum 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 CC: xfs-list Subject: Re: kernel-2.4.9-13SGI_XFS_PR1 bombs References: <3BEAF354.94BD4AF3@fnal.gov> <1005253385.9075.6.camel@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: > > On Thu, 2001-11-08 at 15:04, Dan Yocum wrote: > > Hi guys, > > > > I know the Red Hat kernel-2.4.9-13SGI_XFS_PR1 is in testing still, but > > massive I/O errors occur when I run bonnie++ on my 1.12TB FS - the rest of > > the partitions seem to be behaving themselves, tho. > > > > I'll try to get the error messages next time I boot it up. > > Check your inode size, actually, do this: > > xfs_db /dev/xxxx > sb > p > > and send the output. There was a version of mkfs which would create > a bad filesystem above 1 Tbyte. You mean a filesystem with isize=256 instead of 512 (33 bit vs 32 bits), which I ran into a few weeks (months?) back? Or is there another problem with mkfs that I don't know about? (fwiw, yeah, I did the mkfs with 'i size=512.') Here's the output: ]# xfs_db /dev/md0 xfs_db: sb xfs_db: p magicnum = 0x58465342 blocksize = 4096 dblocks = 280145408 rblocks = 0 rextents = 0 uuid = 37dcf492-e042-4be2-a3e1-fbc16d911623 logstart = 140509312 rootino = 64 rbmino = 65 rsumino = 66 rextsize = 256 agblocks = 1048576 agcount = 268 rbmblocks = 0 logblocks = 32768 versionnum = 0x2184 sectsize = 512 inodesize = 512 inopblock = 8 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12 sectlog = 9 inodelog = 9 inopblog = 3 agblklog = 20 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 657920 ifree = 657915 fdblocks = 279504960 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 128 width = 256 dirblklog = 0 This also shows up in xfs_info: ]# xfs_info /export/data/dp15.a/ meta-data=/export/data/dp15.a isize=512 agcount=268, agsize=1048576 blks data = bsize=4096 blocks=280145408, imaxpct=25 = sunit=128 swidth=256 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768 realtime =none extsz=1048576 blocks=0, rtextents=0 Thanks, Dan -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. From owner-linux-xfs@oss.sgi.com Thu Nov 8 13:34:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8LYk707766 for linux-xfs-outgoing; Thu, 8 Nov 2001 13:34:46 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8LYh007743 for ; Thu, 8 Nov 2001 13:34:43 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fA8LYbK01904 for ; Thu, 8 Nov 2001 13:34:37 -0800 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 PAA3537246; Thu, 8 Nov 2001 15:33:21 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA75404; Thu, 8 Nov 2001 15:33:21 -0600 (CST) Subject: Re: Compile errors with 2.4.14 kernel From: Eric Sandeen To: pkw@pkwhelan.net Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011108152607.A22784@stonewall.pkwhelan.net> References: <20011108152607.A22784@stonewall.pkwhelan.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 08 Nov 2001 15:32:29 -0600 Message-Id: <1005255149.22700.14.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Paul - Strange... this works fine for me, with your config, with gcc-2.96-98 >From the error it _looks_ like EXPORT_SYMBOL(create_empty_buffers) is somewhere twice, but it's not in my tree... check kernel/check ksysms.c and fs/buffer.c This is a brand new 2.4.14 tree patched w/ linux-2.4.14-xfs-2001-11-07.patch.bz2? -Eric On Thu, 2001-11-08 at 14:26, pkw@pkwhelan.net wrote: > Hi, > I used the linux-2.4.14-xfs-2001-11-07.patch.bz2 patch against a clean 2.4.14 tree. The > patch applied cleanly but will not compile. This is the error message I get: -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Nov 8 13:34:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8LYwO07825 for linux-xfs-outgoing; Thu, 8 Nov 2001 13:34:58 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8LYm007775 for ; Thu, 8 Nov 2001 13:34:48 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fA8LYgK01912 for ; Thu, 8 Nov 2001 13:34:42 -0800 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 PAA3539864; Thu, 8 Nov 2001 15:33:25 -0600 (CST) Received: from jen.americas.sgi.com (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 PAA60904; Thu, 8 Nov 2001 15:33:25 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA8LTNM09300; Thu, 8 Nov 2001 15:29:23 -0600 Subject: Re: kernel-2.4.9-13SGI_XFS_PR1 bombs From: Steve Lord To: Dan Yocum Cc: xfs-list In-Reply-To: <3BEAF8F9.D77F2561@fnal.gov> References: <3BEAF354.94BD4AF3@fnal.gov> <1005253385.9075.6.camel@jen.americas.sgi.com> <3BEAF8F9.D77F2561@fnal.gov> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.07.16.47 (Preview Release) Date: 08 Nov 2001 15:29:23 -0600 Message-Id: <1005254963.9075.11.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2001-11-08 at 15:28, Dan Yocum wrote: > > > You mean a filesystem with isize=256 instead of 512 (33 bit vs 32 bits), > which I ran into a few weeks (months?) back? Or is there another problem > with mkfs that I don't know about? (fwiw, yeah, I did the mkfs with 'i > size=512.') No, that was the problem, but the initial cut at mkfs with the automatic inode sizing was updating the inode size on the disk, but not one other field which was crucial. You do not have a filesystem like this, and by the look of it, things ran for a while before going belly up. Steve p.s. I do have code to allow 256 byte inodes in a > 1 Tbyte fs without inodes hitting bit 33. I will put it out there when I get a chance. p.p.s. I guess we need to see the error output. > > > Here's the output: > > ]# xfs_db /dev/md0 > xfs_db: sb > xfs_db: p > magicnum = 0x58465342 > blocksize = 4096 > dblocks = 280145408 > rblocks = 0 > rextents = 0 > uuid = 37dcf492-e042-4be2-a3e1-fbc16d911623 > logstart = 140509312 > rootino = 64 > rbmino = 65 > rsumino = 66 > rextsize = 256 > agblocks = 1048576 > agcount = 268 > rbmblocks = 0 > logblocks = 32768 > versionnum = 0x2184 > sectsize = 512 > inodesize = 512 > inopblock = 8 > fname = "\000\000\000\000\000\000\000\000\000\000\000\000" > blocklog = 12 > sectlog = 9 > inodelog = 9 > inopblog = 3 > agblklog = 20 > rextslog = 0 > inprogress = 0 > imax_pct = 25 > icount = 657920 > ifree = 657915 > fdblocks = 279504960 > frextents = 0 > uquotino = 0 > gquotino = 0 > qflags = 0 > flags = 0 > shared_vn = 0 > inoalignmt = 2 > unit = 128 > width = 256 > dirblklog = 0 > > > This also shows up in xfs_info: > > ]# xfs_info /export/data/dp15.a/ > meta-data=/export/data/dp15.a isize=512 agcount=268, agsize=1048576 > blks > data = bsize=4096 blocks=280145408, imaxpct=25 > = sunit=128 swidth=256 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=32768 > realtime =none extsz=1048576 blocks=0, rtextents=0 > > > Thanks, > Dan > > > -- > Dan Yocum > Sloan Digital Sky Survey, Fermilab 630.840.6509 > yocum@fnal.gov, http://www.sdss.org > SDSS. Mapping the Universe. -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Nov 8 13:38:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8LcPK08101 for linux-xfs-outgoing; Thu, 8 Nov 2001 13:38:25 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8LcL008079 for ; Thu, 8 Nov 2001 13:38:21 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id fA8LcGZQ073146; Thu, 8 Nov 2001 22:38:16 +0100 (CET) Message-Id: <4.3.2.7.2.20011108222854.03615d58@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Nov 2001 22:36:13 +0100 To: Dan Yocum , xfs-list From: Seth Mos Subject: Re: kernel-2.4.9-13SGI_XFS_PR1 bombs In-Reply-To: <3BEAF354.94BD4AF3@fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:04 8-11-2001 -0600, Dan Yocum wrote: >Hi guys, > >I know the Red Hat kernel-2.4.9-13SGI_XFS_PR1 is in testing still, but >massive I/O errors occur when I run bonnie++ on my 1.12TB FS - the rest of >the partitions seem to be behaving themselves, tho. I am not seeing it here even after pounding on it heavily. I do have problems that performance degrades over time (> 1 day). But I think this is more of a VM issue. The good news is that this is still 30x faster then the old NCR MP-RAS box :-) My manager was used to seeing performance halved when starting a second database session. Now this happens after the 3rd concurrent session. Even when running 8 concurrent dump and reload session in Progress 8 and 9 databases it handles it well. Oh yeah, before I forget. People with AMI megaraid controllers should update the firmware of their card. The newer version is a lot faster. Going from 1.57/3.13 to 1.61j/3.17 improves the read perfomance in the same configuration (raid 1 or 10). In my case it went from 58MB/sec to 71MB/sec which is a nice perfomance upgrade without costing anuything :-) >I'll try to get the error messages next time I boot it up. Yes please. This might be related to the size of your fs. 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 Nov 8 13:40:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8LebE08294 for linux-xfs-outgoing; Thu, 8 Nov 2001 13:40:37 -0800 Received: from smtp.pkwhelan.net (dsl092-072-121.bos1.dsl.speakeasy.net [66.92.72.121]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8LeX008272 for ; Thu, 8 Nov 2001 13:40:33 -0800 Received: (qmail 14152 invoked by uid 174); 8 Nov 2001 21:47:12 -0000 Message-ID: <20011108214712.19351.qmail@smtp.pkwhelan.net> References: <20011108152607.A22784@stonewall.pkwhelan.net> <1005255149.22700.14.camel@stout.americas.sgi.com> In-Reply-To: <1005255149.22700.14.camel@stout.americas.sgi.com> From: "PK Whelan" To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Compile errors with 2.4.14 kernel Date: Thu, 08 Nov 2001 21:47:12 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks Eric. I'll try unpacking the source again in case something got messed up and try it again. Paul Eric Sandeen writes: > Hi Paul - > > Strange... this works fine for me, with your config, with gcc-2.96-98 > > From the error it _looks_ like EXPORT_SYMBOL(create_empty_buffers) is > somewhere twice, but it's not in my tree... check kernel/check ksysms.c > and fs/buffer.c > > This is a brand new 2.4.14 tree patched w/ > linux-2.4.14-xfs-2001-11-07.patch.bz2? > > -Eric > > On Thu, 2001-11-08 at 14:26, pkw@pkwhelan.net wrote: >> Hi, >> I used the linux-2.4.14-xfs-2001-11-07.patch.bz2 patch against a clean 2.4.14 tree. The >> patch applied cleanly but will not compile. This is the error message I get: > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > From owner-linux-xfs@oss.sgi.com Thu Nov 8 13:59:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8Lx3N08856 for linux-xfs-outgoing; Thu, 8 Nov 2001 13:59:03 -0800 Received: from clubphoto.com (mail-gw.clubphoto.com [64.124.34.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8Lx1008834 for ; Thu, 8 Nov 2001 13:59:01 -0800 Received: from wicked (wicked.clubphoto.local [192.168.168.26]) by clubphoto.com (8.9.3/8.9.3) with SMTP id NAA03338 for ; Thu, 8 Nov 2001 13:59:00 -0800 From: "Gabe E. Nydick" To: Subject: 2001-11-06-2.4.14 patch Date: Thu, 8 Nov 2001 13:57:26 -0800 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I just compiled and rolled out the 11/06 patch to 2.4.14, now today there is a 11/07 patch. What are the changes between 11/06 and 11/07, and the split version patch from the ftp site that doesn't list a patch date? Thanks ------------------------- Gabe E. Nydick Systems Lead ClubPhoto, Inc. P - 408.423.6611 F - 408.557.6799 ------------------------- From owner-linux-xfs@oss.sgi.com Thu Nov 8 14:11:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8MBdM09221 for linux-xfs-outgoing; Thu, 8 Nov 2001 14:11:39 -0800 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 fA8MBY009199 for ; Thu, 8 Nov 2001 14:11:34 -0800 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 XAA1905468 for ; Thu, 8 Nov 2001 23:11:32 +0100 (CET) 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 QAA3537333; Thu, 8 Nov 2001 16:10:15 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA83953; Thu, 8 Nov 2001 16:10:14 -0600 (CST) Subject: Re: 2001-11-06-2.4.14 patch From: Eric Sandeen To: "Gabe E. Nydick" Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 08 Nov 2001 16:09:22 -0600 Message-Id: <1005257362.22700.16.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I respun the 11/6 patch because it somehow had a bunch of cvs cruft in it that didn't get deleted - the i20 dir in particular. Not XFS related. Keith is not dating the split patches AFAIK, so I'm not sure what the differences may be. Bear in mind that these are all snapshots anyway; if you need the latest, use cvs, if you need tested, use a released version, otherwise you get... a snapshot. :) I'll talk to Keith about how we'll keep the "big patches" and the "split patches" in sync, or dating the split patches, just to keep the confusion manageable. -Eric On Thu, 2001-11-08 at 15:57, Gabe E. Nydick wrote: > I just compiled and rolled out the 11/06 patch to 2.4.14, now today there is > a 11/07 patch. What are the changes between 11/06 and 11/07, and the split > version patch from the ftp site that doesn't list a patch date? > > Thanks > ------------------------- > Gabe E. Nydick > Systems Lead > ClubPhoto, Inc. > P - 408.423.6611 > F - 408.557.6799 > ------------------------- > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Nov 8 14:28:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8MSPr09703 for linux-xfs-outgoing; Thu, 8 Nov 2001 14:28:25 -0800 Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8MSN009680 for ; Thu, 8 Nov 2001 14:28:23 -0800 Received: (cpmta 9912 invoked from network); 8 Nov 2001 14:28:17 -0800 Received: from 207.207.51.226 (HELO ?192.168.1.50?) by smtp.tooley.com (209.228.32.64) with SMTP; 8 Nov 2001 14:28:17 -0800 X-Sent: 8 Nov 2001 22:28:17 GMT Subject: Undelete in XFS From: Chris Tooley To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.100+cvs.2001.11.02.08.57 (Preview Release) Date: 08 Nov 2001 16:27:35 -0600 Message-Id: <1005258455.4701.4.camel@itspec.amoa.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is there an undelete procedure for accidentally deleted files under XFS? I unfortunately deleted my Evolution directory from my home directory and all of my mail with it. :( Chris From owner-linux-xfs@oss.sgi.com Thu Nov 8 14:33:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8MXja10716 for linux-xfs-outgoing; Thu, 8 Nov 2001 14:33:45 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8MXg010694 for ; Thu, 8 Nov 2001 14:33:42 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fA8MXbT21066 for ; Thu, 8 Nov 2001 14:33:37 -0800 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 QAA3541182; Thu, 8 Nov 2001 16:32:20 -0600 (CST) Received: from jen.americas.sgi.com (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 QAA65076; Thu, 8 Nov 2001 16:32:20 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA8MSHX09389; Thu, 8 Nov 2001 16:28:17 -0600 Subject: Re: Undelete in XFS From: Steve Lord To: Chris Tooley Cc: linux-xfs@oss.sgi.com In-Reply-To: <1005258455.4701.4.camel@itspec.amoa.org> References: <1005258455.4701.4.camel@itspec.amoa.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.07.16.47 (Preview Release) Date: 08 Nov 2001 16:28:17 -0600 Message-Id: <1005258497.9075.22.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2001-11-08 at 16:27, Chris Tooley wrote: > Is there an undelete procedure for accidentally deleted files under XFS? > I unfortunately deleted my Evolution directory from my home directory > and all of my mail with it. :( Unfortunately the undelete tool is called xfsrestore. Steve (filing evolution bugs as we speak) -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Nov 8 14:46:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8MkbT17026 for linux-xfs-outgoing; Thu, 8 Nov 2001 14:46:37 -0800 Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8MkX017004 for ; Thu, 8 Nov 2001 14:46:33 -0800 Received: (cpmta 23982 invoked from network); 8 Nov 2001 14:46:28 -0800 Received: from 207.207.51.226 (HELO ?192.168.1.50?) by smtp.tooley.com (209.228.32.64) with SMTP; 8 Nov 2001 14:46:28 -0800 X-Sent: 8 Nov 2001 22:46:28 GMT Subject: Re: Undelete in XFS From: Chris Tooley To: linux-xfs@oss.sgi.com In-Reply-To: <1005258497.9075.22.camel@jen.americas.sgi.com> References: <1005258455.4701.4.camel@itspec.amoa.org> <1005258497.9075.22.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.100+cvs.2001.11.02.08.57 (Preview Release) Date: 08 Nov 2001 16:45:46 -0600 Message-Id: <1005259546.5742.9.camel@itspec.amoa.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Wish I could file an evolution bug and blame it on someone else, but my problem is my own stupidity trying to make space on my harddrive. BTW what is the status of being able to move the start point of a partition? I can't do a dump and restore on my workstation and really need to add some space to this partition. However, I'm at the end of the disk. Chris On Thu, 2001-11-08 at 16:28, owner-linux-xfs@oss.sgi.com wrote: > On Thu, 2001-11-08 at 16:27, Chris Tooley wrote: > > Is there an undelete procedure for accidentally deleted files under XFS? > > I unfortunately deleted my Evolution directory from my home directory > > and all of my mail with it. :( > > Unfortunately the undelete tool is called xfsrestore. > > Steve (filing evolution bugs as we speak) > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > From owner-linux-xfs@oss.sgi.com Thu Nov 8 14:53:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8Mr9h17247 for linux-xfs-outgoing; Thu, 8 Nov 2001 14:53:09 -0800 Received: from codon.com (www.stampingcentral.com [64.78.130.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8Mr6017225 for ; Thu, 8 Nov 2001 14:53:07 -0800 Received: (qmail 26208 invoked by uid 516); 8 Nov 2001 23:03:11 -0000 Received: from nw@codon.com by helix with qmail-scanner-0.96 (. Clean. Processed in 0.051713 secs); 08 Nov 2001 23:03:11 -0000 Received: from weasel.local.iboats.com (HELO weasel) (64.78.130.80) by codon.com with SMTP; 8 Nov 2001 23:03:11 -0000 Message-ID: <000b01c168a7$13a21120$50824e40@iboats.com> From: "Steve Wolfe" To: References: <1005258455.4701.4.camel@itspec.amoa.org> <1005258497.9075.22.camel@jen.americas.sgi.com> <1005259546.5742.9.camel@itspec.amoa.org> Subject: Re: Undelete in XFS Date: Thu, 8 Nov 2001 15:45:32 -0700 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 > Wish I could file an evolution bug and blame it on someone else, but my > problem is my own stupidity trying to make space on my harddrive. Hey, just pipe the output of "locate" to "xargs rm -rf". Things *never* go wrong that way... ; ) steve From owner-linux-xfs@oss.sgi.com Thu Nov 8 15:03:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8N3VY17640 for linux-xfs-outgoing; Thu, 8 Nov 2001 15:03:31 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8N3R017617 for ; Thu, 8 Nov 2001 15:03:27 -0800 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Nov 2001 17:02:47 -0600 Message-ID: <85063BBE668FD411944400D0B744267A88873B@AUSMAIL> From: "Gonyou, Austin" To: "'Eric Sandeen'" , "Gabe E. Nydick" Cc: linux-xfs@oss.sgi.com Subject: DMAPI Bug is indeed resolved. Date: Thu, 8 Nov 2001 17:02:46 -0600 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 just ran my test suite against linux-2.4-xfs tree from 2 days ago when that fix was sent out. It works find so far. I'm also using the following to compile: glibc-2.2.4-19 (RedHat updates) gcc3-3.0.1-4 (RedHat Rawhide) libtool-1.4 (RedHat Rawhide) libtool-libs (RedHat Rawhide) automake-1.20 (RedHat Rawhide) autoconf (RedHat Rawhide) make (RedHat updates) -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com From owner-linux-xfs@oss.sgi.com Thu Nov 8 15:24:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8NORh18233 for linux-xfs-outgoing; Thu, 8 Nov 2001 15:24:27 -0800 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 fA8NOM018210 for ; Thu, 8 Nov 2001 15:24:23 -0800 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 PAA27845 for ; Thu, 8 Nov 2001 15:24:13 -0800 (PST) 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 RAA3537135; Thu, 8 Nov 2001 17:23:06 -0600 (CST) Received: from jen.americas.sgi.com (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 RAA69621; Thu, 8 Nov 2001 17:23:05 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fA8NJ2G09487; Thu, 8 Nov 2001 17:19:02 -0600 Subject: Re: Undelete in XFS From: Steve Lord To: Chris Tooley Cc: linux-xfs@oss.sgi.com In-Reply-To: <1005259546.5742.9.camel@itspec.amoa.org> References: <1005258455.4701.4.camel@itspec.amoa.org> <1005258497.9075.22.camel@jen.americas.sgi.com> <1005259546.5742.9.camel@itspec.amoa.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.07.16.47 (Preview Release) Date: 08 Nov 2001 17:19:02 -0600 Message-Id: <1005261542.9077.29.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2001-11-08 at 16:45, Chris Tooley wrote: > Wish I could file an evolution bug and blame it on someone else, but my > problem is my own stupidity trying to make space on my harddrive. BTW > what is the status of being able to move the start point of a > partition? I can't do a dump and restore on my workstation and really > need to add some space to this partition. However, I'm at the end of > the disk. > > Which I think translates into shrinking a filesystem. The answer to that question is also xfsdump/mkfs/xfsrestore, the xfs disk structures are a little complex to shrink. Steve p.s. Disk drives are really cheap now, I have a spare 20Gbyte 7200 rpm IBM IDE drive sitting on a shelf in my office, it cost about $100. p.p.s. No, you cannot have it! -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Nov 8 15:41:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8Nfam18615 for linux-xfs-outgoing; Thu, 8 Nov 2001 15:41:36 -0800 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 fA8NfV018593 for ; Thu, 8 Nov 2001 15:41:31 -0800 Received: from idcomm.com (IDENT:LHXsPzc43qZsWTWhkhNu7kVfDt2Dr0bV@x2-pip60.idcomm.com [209.60.72.71]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id fA8NhqF24246 for ; Thu, 8 Nov 2001 16:43:53 -0700 Message-ID: <3BEB1829.5F5C3D2@idcomm.com> Date: Thu, 08 Nov 2001 16:41:29 -0700 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: Undelete in XFS References: <1005258455.4701.4.camel@itspec.amoa.org> <1005258497.9075.22.camel@jen.americas.sgi.com> <1005259546.5742.9.camel@itspec.amoa.org> <1005261542.9077.29.camel@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: > > On Thu, 2001-11-08 at 16:45, Chris Tooley wrote: > > Wish I could file an evolution bug and blame it on someone else, but my > > problem is my own stupidity trying to make space on my harddrive. BTW > > what is the status of being able to move the start point of a > > partition? I can't do a dump and restore on my workstation and really > > need to add some space to this partition. However, I'm at the end of > > the disk. > > > > > > Which I think translates into shrinking a filesystem. > > The answer to that question is also xfsdump/mkfs/xfsrestore, the > xfs disk structures are a little complex to shrink. > > Steve > > p.s. > > Disk drives are really cheap now, I have a spare 20Gbyte 7200 rpm IBM > IDE drive sitting on a shelf in my office, it cost about $100. I installed a scratch 20 Gb cheap-o into a removeable tray, and have the tray on a couple of computers. Makes a wonderful floppy. Just make sure it is formatted as an extended/logical partition, primaries tend to confuse some more stupid o/s's when the partitions get added and removed. I highly recommend a removeable tray scratch IDE drive. D. Stimits, stimits@idcomm.com > > p.p.s. > > No, you cannot have it! > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Nov 8 21:42:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA95g9224612 for linux-xfs-outgoing; Thu, 8 Nov 2001 21:42:09 -0800 Received: from sundown.cs.cornell.edu (sundown.cs.cornell.edu [128.84.96.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA95g6024590 for ; Thu, 8 Nov 2001 21:42:06 -0800 Received: from hoho.cs.cornell.edu (hoho.cs.cornell.edu [128.84.96.89]) by sundown.cs.cornell.edu (8.11.3/8.11.3/R-3.6) with ESMTP id fA95g5217880 for ; Fri, 9 Nov 2001 00:42:05 -0500 (EST) Date: Fri, 9 Nov 2001 00:42:04 -0500 (EST) From: Avijit Ghosh To: linux-xfs@oss.sgi.com Subject: rh7.2 prerelease In-Reply-To: <3BEB1829.5F5C3D2@idcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I did an upgrade of my 7.1 box which went more or less as according to plan but I seem to be having weird issues w/ any users .kde/share/config/* files sometimes arbitrarily turning into ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ i can't tell if I have some screwed up install of kde or whether its xfs or exactly where and why this is occurring but thought i'd run it through you guys in case it something like this seems familiar.. -avi From owner-linux-xfs@oss.sgi.com Thu Nov 8 21:52:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA95qKI24859 for linux-xfs-outgoing; Thu, 8 Nov 2001 21:52:20 -0800 Received: from sundown.cs.cornell.edu (sundown.cs.cornell.edu [128.84.96.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA95qG024837 for ; Thu, 8 Nov 2001 21:52:16 -0800 Received: from hoho.cs.cornell.edu (hoho.cs.cornell.edu [128.84.96.89]) by sundown.cs.cornell.edu (8.11.3/8.11.3/R-3.6) with ESMTP id fA95qF219270 for ; Fri, 9 Nov 2001 00:52:16 -0500 (EST) Date: Fri, 9 Nov 2001 00:52:14 -0500 (EST) From: Avijit Ghosh To: linux-xfs@oss.sgi.com Subject: Re: rh7.2 prerelease 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 To follow up in /var/log/messages Nov 8 01:00:08 bloosqr fam[1456]: fd 6 write error: Broken pipe On Fri, 9 Nov 2001, Avijit Ghosh wrote: > > > I did an upgrade of my 7.1 box which went more or less as > according to plan but I seem to be having weird issues w/ any users > .kde/share/config/* files sometimes arbitrarily turning into > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ > > i can't tell if I have some screwed up install of kde or whether its xfs > or exactly where and why this is occurring but thought i'd run it through > you guys in case it something like this seems familiar.. > > -avi > > > > From owner-linux-xfs@oss.sgi.com Thu Nov 8 22:22:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA96Mmr25384 for linux-xfs-outgoing; Thu, 8 Nov 2001 22:22:48 -0800 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 fA96Mj025362 for ; Thu, 8 Nov 2001 22:22:45 -0800 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 WAA01479 for ; Thu, 8 Nov 2001 22:22:35 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id RAA24472; Fri, 9 Nov 2001 17:22:39 +1100 Date: Fri, 9 Nov 2001 17:22:39 +1100 From: Keith Owens Message-Id: <200111090622.RAA24472@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade to kbuild 2.5 release 1.6 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk kbuild 2.5 release 1.6 added negated configs (!CONFIG_FOO) which makes it easier to write several of the XFS makefiles, upgrade XFS to the new style. You must now use at least release 1.6 of kbuild 2.5 (this is a cunning plan to get more kbuild 2.5 testing :). Date: Thu Nov 8 22:20:39 PST 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:106421a linux/fs/Makefile.in.append - 1.4 linux/fs/xfs/Makefile.in - 1.7 linux/fs/xfs/linux/Makefile.in - 1.3 From owner-linux-xfs@oss.sgi.com Thu Nov 8 22:43:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA96hAj25726 for linux-xfs-outgoing; Thu, 8 Nov 2001 22:43:10 -0800 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 fA96h3025704 for ; Thu, 8 Nov 2001 22:43:03 -0800 Received: (qmail 23820 invoked by uid 508); 9 Nov 2001 06:42:52 -0000 Received: from unknown (HELO cl3146399-a.mdsn1.wi.home.com) (67.164.116.205) by walden.phpwebhosting.com with SMTP; 9 Nov 2001 06:42:52 -0000 Date: Fri, 9 Nov 2001 00:43:21 -0600 Subject: Re: Adaptec dpt_i2o SCSI raid card Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v472) From: Ben Gollmer To: linux-xfs@oss.sgi.com Content-Transfer-Encoding: 7bit In-Reply-To: <3BEA728D.C298461C@ieee.org> Message-Id: <10BFC93A-D4DD-11D5-B85A-003065B71D96@jatosoft.com> X-Mailer: Apple Mail (2.472) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just wanted to chime in on this - I have a box with an Adaptec 2100s card as well. I have been very happy with the performance & features (probably because it was made by DPT...) Anyway, Linux support for this product has been non-existent, especially as the board was advertised as being 'Linux compatible'. Until recently, the DPT I20 drivers were not present on linux.adaptec.com, and the only drivers that worked were the ones provided by Adaptec (for RedHat 6.2). I read somewhere that the kernel team has included I20 drivers that work for this card in kernel 2.4.10 and up. I haven't had a chance to try this yet...can anyone verify? Also, if you have luck with the old DPT drivers, let me know. My box is due for an upgrade, RH 6.2 is getting pretty old. I'm tempted to move to FreeBSD (drivers are included with the distro), but I really would like to run XFS on this box. Ben On Thursday, November 8, 2001, at 05:54 AM, Bryan-TheBS-Smith wrote: > Joost van der Locht wrote: >> For Redhat 7.1 is on the website of Adaptec >> (http://linuix.adaptec.com/linux_raid_unsupported.html) a driver disk >> available for Redhat 7.1 >> Creating an own driver disk can be done like this (thanks to Richard >> Sharpe, >> sharpe@ns.aus.com) >> www.cantech.net.au/plug/2001-06/msg00248.html > > I hope everyone notes these are DPT's old drivers, which I've used in > Linux over the years. Unlike Adaptec, they actually created their > hardware to an open standard interface (I2O) so one driver could power > any board, ATA, SCSI, etc... Too bad DPT has now been consumed by > Adaptec, which means support is going out the window. > > Adaptec themselves are still creating endless, incompatible boards with > splintering revisions of the same board for OEMs. Since starting to use > Linux in 1993 and seeing one board work and another fail with drivers, > as well as a number under Windows as well, I gave up. 3Ware for > ATA-RAID, Mylex for SCSI, Advansys/Symbios Logic for plain SCSI, and a > few select others (e.g., I'll "tolerate" HighPoint's "trick BIOS" ATA > controller chips since their Linux drivers work well) are all I'll use. > > Until Adaptec and Promise get their acts together (not likely since they > get so much business from their "brand name"), I won't be using their > products in Linux, or even Windows systems for that matter. You'd > figure with their size they'd actually make the best products with the > best Linux support? Hardly, both usually lose every benchmark I've seen > and Linux support for their products has always been a 3rd > party/community proposition, or increasingly binary only for only select > products. > > Just my $0.02 ... > > -- TheBS > > -- > Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 > Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org > President SmithConcepts, Inc. http://www.SmithConcepts.com > ---------------------------------------------------------------- > * Pentium stop, Pentium SMP go, Athlon MP go ... go very fast! * > > From owner-linux-xfs@oss.sgi.com Thu Nov 8 22:57:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA96vT726099 for linux-xfs-outgoing; Thu, 8 Nov 2001 22:57:29 -0800 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 fA96vG026077 for ; Thu, 8 Nov 2001 22:57:16 -0800 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 HAA23563; Fri, 9 Nov 2001 07:57:07 +0100 (MET) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id HAA06313; Fri, 9 Nov 2001 07:57:06 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 4E22157306; Fri, 9 Nov 2001 07:56:19 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 5162325835; Fri, 9 Nov 2001 07:56:13 +0100 (CET) Message-ID: <3BEB7E0D.B42545FD@ch.sauter-bc.com> Date: Fri, 09 Nov 2001 07:56:13 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Steve Lord Cc: Arkadiusz Miskiewicz , linux-xfs@oss.sgi.com Subject: Re: partition recovery References: <20011108163855.A19171@ikar.t17.ds.pwr.wroc.pl> <1005236529.8162.12.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by relay.xlink.net id HAA23563 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fA96vG026078 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord schrieb: > > On Thu, 2001-11-08 at 09:38, Arkadiusz Miskiewicz wrote: > > Hi, > > > > Recently I've crashed both partition tables (1 and 2 copy). > > My setup was: > > start end > > hda1 0.031 10001.250 fat > > 10001.404 29313.918 extended lba > > hda5 10001.435 20002.807 xfs > > hda6 20002.838 20198.913 swap > > hda7 20198.944 20598.969 ext2 > > hda8 20599.000 23603.312 xfs > > hda9 23603.344 29313.918 lvm > > (values in MB as shown by parted) > > > > Now I'm trying to recover xfs partitions. Unfortunately > > I can't create exactly same partition with same positions > > as previously. Now fdisk, cfdisk, parted always create > > partition like this: > > > > 2 10001.250 20002.992 primary > > (rounding to cylinder?) > > > > So I'm trying to use xfs_repair (1.2.0) on such (not exacly > > same as in original) partition but. > > > > xfs_repair -n /dev/hda2 > > Phase 1 - find and verify superblock... > > bad primary superblock - bad magic number !!! > > ...................................... > > ... > > attempting to find secondary superblock... > > nable to verify superblock, continuing... > > ... > > > > It found more than 5 backup superblocks but it was > > unable to verify all superblocks. > > > > Any hints how to recover data from these partitions? > > > > i686, 2.4.13, xfs-20011026 > > -- > > Arkadiusz MiÅ?kiewicz, AM2-6BONE [ PLD GNU/Linux IPv6 ] > > http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/ [ enabled ] > > You really need to get the partition back to exactly the same blocks > it used to be at - and that is your problem here, unless you have > partition table output which is in sector format, getting the same > ones back again is really hard. You could look at the raw disk for the > xfs superblock, this is placed in sector zero of the partition, > so it would be a good indication of the sector you need the partition > to start at. Try to find the start and end of every partition, use dd to dump each of them in separate files and mount them as loop device. This way you don't change anything on the disk until you have recovered all data. -Simon > The superblock starts with the string XFSB, so dumping the disk out > you would see something like this: > > od -c /dev/hda | more > 0000000 ú ë | l b a L I L O 001 \0 025 004 Z \0 > 0000020 \0 \0 001 ã S 024 S ; 030 002 200 y 001 031 002 200 > 0000040 y 001 027 002 200 y 001 001 \0 \0 \0 \0 \0 \0 \0 033 > 0000060 002 200 y 001 \a 001 200 G 001 \b 001 200 G 001 \t 001 > 0000100 200 G 001 \n 001 200 G 001 \v 001 200 G 001 \f 001 200 > 0000120 G 001 \r 001 200 G 001 016 001 200 G 001 017 001 200 G > 0000140 001 020 001 200 G 001 021 001 200 G 001 \0 \0 \0 \0 \0 > 0000160 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 ¸ > 0000200 Ã? \a 216 Ã~ 214 006 z \0 211 6 x \0 211 036 | \0 > 0000220 210 026 ~ \0 ¸ \0 232 216 Ã? ¹ \0 001 ) ö ) ÿ > 0000240 ü ó Â¥ ê ¨ \0 \0 232 216 Ã~ ¸ \0 220 216 Ã? ¼ > 0000260 \0 ° û ° \r è i \0 ° \n è d \0 ° L è > 0000300 _ \0 ¾ 4 \0 h \0 \v \a 1 Ã? ­ 221 ¬ ¨ ` > 0000320 u 017 N ­ 211 Ã, \t Ã^ t 034 ¬ ´ 002 Ã? 023 ë > 0000340 016 210 Ã, ­ ö Ã, u 002 0 ä 227 è ; \0 r > 0000360 017 200 Ã? 002 ë Ã* ° I è & \0 ê \0 \0 \0 \v > 0000400 ° è 034 \0 è 006 \0 1 Ã? Ã? 023 ë ´ Ã? Ã? > 0000420 004 è 003 \0 Ã? Ã? 004 $ 017 004 0 < : r 002 004 > 0000440 \a P 0 ÿ ´ 016 Ã? 020 X Ãf V Q S 210 Ã? 200 > 0000460 â 217 ö Ãf @ u 3 » ª U ¸ \0 A Ã? 023 r > 0000500 ) 201 û U ª u # ö Ã? 001 t 036 [ Y 036 1 > 0000520 ö V V W Q 006 S j 001 j 020 211 æ 026 037 ¸ > 0000540 \0 B Ã? 023 215 d 020 037 ë D [ Y S R W Q > 0000560 006 ´ \b Ã? 023 \a r 8 Q Ã? é 006 206 é 211 Ã? > 0000600 Y 210 ð þ Ã? 200 á ? ö á 226 X Z 9 ò s > 0000620 # ÷ ö 9 ø w 035 Ã? ä 006 206 à 222 ö ñ þ > 0000640 Ã? \0 â 211 Ã? Z [ 206 ð ¸ 001 002 Ã? 023 ^ Ãf > 0000660 Y _ ë 002 ´ @ \0 \0 \0 \0 \0 \0 \0 \0 200 001 > 0000700 001 \0 203 þ ? A ? \0 \0 \0 203 - 020 \0 \0 \0 > 0000720 001 B 005 þ ÿ ÿ Ã, - 020 \0 Ã? 002 ! 001 \0 \0 > 0000740 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 > 0000760 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 U ª > 0001000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 > * > 0077000 X F S B \0 \0 020 \0 \0 \0 \0 \0 \0 002 005 ° > 0077020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 > 0077040 ~ ì 034 024 z 004 021 Ã* 222 Ã? ú B 200 $ ì Ã? > 0077060 \0 \0 \0 \0 \0 002 \0 004 \0 \0 \0 \0 \0 \0 \0 200 > 0077100 \0 \0 \0 \0 \0 \0 \0 201 \0 \0 \0 \0 \0 \0 \0 202 > 0077120 \0 \0 \0 020 \0 \0 @ ¶ \0 \0 \0 \b \0 \0 \0 \0 > 0077140 \0 \0 004 ° 204 002 \0 001 \0 \0 020 / b o o > 0077160 t \0 \0 \0 \0 \0 \0 \0 \f \t \b 004 017 \0 \0 031 > 0077200 \0 \0 \0 \0 \0 \0 \0 200 \0 \0 \0 \0 \0 \0 \0 @ > 0077220 \0 \0 \0 \0 \0 001 Ã? Ã? \0 \0 \0 \0 \0 \0 \0 \0 > 0077240 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 > 0077260 \0 \0 \0 \0 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 \0 > 0077300 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 > * > 0100000 X A G F \0 \0 \0 001 \0 \0 \0 \0 \0 \0 @ ¶ > 0100020 \0 \0 \0 001 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 001 > 0100040 \0 \0 \0 001 \0 \0 \0 \0 \0 \0 \0 \b \0 \0 \0 \v > 0100060 \0 \0 \0 004 \0 \0 023 233 \0 \0 \v ï \0 \0 \0 \0 > 0100100 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 > > Here you see the superblock, followed by the AGF structure. > > Best of luck > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Nov 9 01:03:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA993kl28258 for linux-xfs-outgoing; Fri, 9 Nov 2001 01:03:46 -0800 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 fA993g028235 for ; Fri, 9 Nov 2001 01:03:42 -0800 Received: (qmail 29314 invoked by uid 508); 9 Nov 2001 09:03:35 -0000 Received: from unknown (HELO cl3146399-a.mdsn1.wi.home.com) (67.164.116.205) by walden.phpwebhosting.com with SMTP; 9 Nov 2001 09:03:35 -0000 Date: Fri, 9 Nov 2001 03:04:00 -0600 Subject: Re: Adaptec dpt_i2o SCSI raid card Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v472) From: Ben Gollmer To: linux-xfs@oss.sgi.com Content-Transfer-Encoding: 7bit In-Reply-To: <10BFC93A-D4DD-11D5-B85A-003065B71D96@jatosoft.com> Message-Id: X-Mailer: Apple Mail (2.472) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I read somewhere that the kernel team has included I20 drivers that > work for this card in kernel 2.4.10 and up. I haven't had a chance to > try this yet...can anyone verify? *SMACK* Missed a post in this thread...oops : ) Now if someone will just release a distro with 2.4.10+, so I can install directly to the 2100s's drives... Ben From owner-linux-xfs@oss.sgi.com Fri Nov 9 01:11:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA99BpS28550 for linux-xfs-outgoing; Fri, 9 Nov 2001 01:11:51 -0800 Received: from queen.bee.lk (queen.bee.lk [203.143.12.182]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA99Bk028527 for ; Fri, 9 Nov 2001 01:11:46 -0800 Received: from anuradha by queen.bee.lk with local (Exim 3.12 #1 (Debian)) id 1627hy-0001Ue-00 for ; Fri, 09 Nov 2001 15:12:18 +0600 Date: Fri, 9 Nov 2001 15:12:18 +0600 From: Anuradha Ratnaweera To: linux-xfs@oss.sgi.com Subject: XFS and preemptive kernel patch Message-ID: <20011109151218.A5600@bee.lk> 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 Is anybody using XFS with preemptive kernel patch? Since I don't have any "non-production" machines to do a test, any feedback would be very useful. Thanks. Regards, Anuradha -- Debian GNU/Linux (kernel 2.4.14) Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. -- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982 From owner-linux-xfs@oss.sgi.com Fri Nov 9 01:23:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA99N6829892 for linux-xfs-outgoing; Fri, 9 Nov 2001 01:23:06 -0800 Received: from ikar.t17.ds.pwr.wroc.pl (postfix@ikar.t17.ds.pwr.wroc.pl [156.17.235.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA99N1029870 for ; Fri, 9 Nov 2001 01:23:03 -0800 Received: by ikar.t17.ds.pwr.wroc.pl (Postfix, from userid 1002) id 186EAC8091; Fri, 9 Nov 2001 10:22:57 +0100 (CET) Date: Fri, 9 Nov 2001 10:22:56 +0100 From: Arkadiusz Miskiewicz To: linux-xfs@oss.sgi.com Subject: Re: partition recovery Message-ID: <20011109102256.A24226@ikar.t17.ds.pwr.wroc.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3BEB7E0D.B42545FD@ch.sauter-bc.com> User-Agent: Mutt/1.3.18i X-URL: http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/ X-Operating-System: Linux dark 4.0.20 #119 =?iso-8859-2?Q?pi?= =?iso-8859-2?Q?=B1?= lis 9 10:20:19 CET 2001 i986 pld Organization: Polish(ed) Linux Distribution Team Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On/Dnia Fri, Nov 09, 2001 at 07:56:13AM +0100, Simon Matter wrote/napisa³(a) > Try to find the start and end of every partition, use dd to dump each of > them in separate files and mount them as loop device. I found XFS superblock, dd-ed whole partition and now my all important data is back :-) Thanks for help. > -Simon > > Best of luck > > > > Steve -- Arkadiusz Mi¶kiewicz, AM2-6BONE [ PLD GNU/Linux IPv6 ] http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/ [ enabled ] From owner-linux-xfs@oss.sgi.com Fri Nov 9 01:30:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA99UxO30140 for linux-xfs-outgoing; Fri, 9 Nov 2001 01:30:59 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA99Uu030117 for ; Fri, 9 Nov 2001 01:30:57 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id fA99UmAa056414; Fri, 9 Nov 2001 10:30:55 +0100 (CET) Message-Id: <4.3.2.7.2.20011109102816.040d2d98@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Nov 2001 10:28:47 +0100 To: Arkadiusz Miskiewicz , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: partition recovery In-Reply-To: <20011109102256.A24226@ikar.t17.ds.pwr.wroc.pl> References: <3BEB7E0D.B42545FD@ch.sauter-bc.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 fA99Uv030118 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10:22 9-11-2001 +0100, Arkadiusz Miskiewicz wrote: >On/Dnia Fri, Nov 09, 2001 at 07:56:13AM +0100, Simon Matter wrote/napisa³(a) > > Try to find the start and end of every partition, use dd to dump each of > > them in separate files and mount them as loop device. >I found XFS superblock, dd-ed whole partition and now my all important >data is back :-) Thanks for help. Impressive. Good to hear. -- 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 Nov 9 02:00:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9A0VW30770 for linux-xfs-outgoing; Fri, 9 Nov 2001 02:00:31 -0800 Received: from mail.loewe-komp.de (mail.loewe-komp.de [62.156.155.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9A0L030746 for ; Fri, 9 Nov 2001 02:00:22 -0800 Received: from loewe-komp.de (pippin.loewe-komp.de [192.168.169.19]) by mail.loewe-komp.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id fA9A3sS19709; Fri, 9 Nov 2001 11:03:54 +0100 X-Authentication-Warning: mail.loewe-komp.de: Host pippin.loewe-komp.de [192.168.169.19] claimed to be loewe-komp.de Message-ID: <3BEBA93F.80B0A7E1@loewe-komp.de> Date: Fri, 09 Nov 2001 11:00:31 +0100 From: Peter =?iso-8859-1?Q?W=E4chtler?= Organization: LOEWE. Hannover X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.9-ac3 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: lkml Subject: NFS hit me (2.4.9-xfs) again References: <1005258455.4701.4.camel@itspec.amoa.org> <1005258497.9075.22.camel@jen.americas.sgi.com> <1005259546.5742.9.camel@itspec.amoa.org> <1005261542.9077.29.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Unable to handle kernel NULL pointer dereference at virtual address 00000000 00000000 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[<00000000>] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 00000000 ebx: c9c0d7e0 ecx: 00000000 edx: c03a7b00 esi: c9c0d560 edi: c9c0d7e0 ebp: c9c0d7e0 esp: cbddde84 ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 233, stackpage=cbddd000) Stack: c01729f4 cc97f420 c9c0d560 00000005 cdc40a00 c0172e56 c9c0d7e0 00000005 cd390200 cd390000 cbed2000 cbdddf20 cdc40be8 cd390200 c0173199 cdc40a00 cd390010 00000005 00000001 00000001 00000008 cbe17e00 cbee48c0 cd390200 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: Bad EIP value. >>EIP; 00000000 Before first symbol Trace; c01729f4 Trace; c0172e56 Trace; c0173199 Trace; c0173ad2 Trace; c017843d Trace; c017173c Trace; c0171003 Trace; c0240318 Trace; c0170dab Trace; c010557f This is not the initial crash location - the machine was dead (and no serial console yet). But after restarting, about 6-10 clients tried to reconnect to NFSD and caused the crash. The crash appears because "child->d_inode->i_op->lookup == NULL" struct dentry *nfsd_findparent(struct dentry *child) { struct dentry *tdentry, *pdentry; tdentry = d_alloc(child, &(const struct qstr) {"..", 2, 0}); if (!tdentry) return ERR_PTR(-ENOMEM); /* I'm going to assume that if the returned dentry is different, then * it is well connected. But nobody returns different dentrys do they? */ /* added safety check to prevent crash - peewee */ if (child->d_inode->i_op && child->d_inode->i_op->lookup){ pdentry = child->d_inode->i_op->lookup(child->d_inode, tdentry); } else { printk("normally we had been crashing\n"); printk("child: %p\n",child); printk("child->d_inode: %p\n",child->d_inode); printk("child->d_inode->i_op: %p\n",child->d_inode->i_op); printk("child->d_inode->i_op->lookup: %p\n",child->d_inode->i_op->lookup); return( ERR_PTR(-EINVAL) );  } d_drop(tdentry); /* we never want ".." hashed */ if (!pdentry && tdentry->d_inode == NULL) { /* File system cannot find ".." ... sad but possible */ dput(tdentry); ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ this one was removed in 2.4.10 pdentry = ERR_PTR(-EINVAL); } if (!pdentry) { /* I don't want to return a ".." dentry. * I would prefer to return an unconnected "IS_ROOT" dentry, [...] If I use 2.4.12-xfs (with nfs-utils 0.3.3), clients can't create an archive with "ar": [ strace output of "ar" creating a lib out of several *.o] write(5, "\0\0\1\2\0\0H\2\0\0\1\2\0\0L\2\0\0\1\2\0\0P\2\0\0\1\2\0"..., 3254) = 3 close(5) = 0 munmap(0x4001f000, 4096) = 0 lstat64("lumenuila.a", {st_mode=S_IFREG|0644, st_size=8, ...}) = 0 rename("stO1wjGV", "lumenuila.a") = -1 ESTALE (Stale NFS file handle) My main question is: Is it possible that some interaction with xfs<->nfsd causes this kind of trouble? Especially when lookup("..") fails - and dealing with "disconnected dentries". Does the nfs_fh carry not enough information ( when is oldfh used, when the newer one? [ref_fh->fh_handle.fh_version == 0xca]). So we have an inode with no proper inode_operations, huh? I don't use NFSv3, should I? From owner-linux-xfs@oss.sgi.com Fri Nov 9 02:23:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9ANeF31261 for linux-xfs-outgoing; Fri, 9 Nov 2001 02:23:40 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9ANY031239 for ; Fri, 9 Nov 2001 02:23:34 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id fA9ANQtJ058753; Fri, 9 Nov 2001 11:23:26 +0100 (CET) Message-Id: <4.3.2.7.2.20011109103521.02c42a30@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Nov 2001 11:21:24 +0100 To: Matt_Domsch@dell.com From: Seth Mos Subject: Re: AMI megaraid performance (was: RE: Dell release of Redhat 7.2) Cc: Linux-PowerEdge@dell.com, linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20011108154246.03610b88@pop.xs4all.nl> References: <71714C04806CD5119352009027289217022C3ED2@ausxmrr502.us.del l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Cross posting to linux-xfs@oss.sgi.com At 15:48 8-11-2001 +0100, Seth Mos wrote: >On another note, the newer 1.61j firmware for the PERC2/3 card is a decent >speed improvement on raid 10 arrays. We just got a 13MB/sec extra read >speed (from 58MB/s to 71MB/s). > >The amount of Random seeks was significantly reduced from 7500 to 5000 > >Bonnie 1.0 -------Sequential Output-------- ---Sequential Input-- >--Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- > --Seeks--- >Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec >%CPU >1.61j 2000 15568 100.0 38680 20.9 27593 17.6 13745 91.0 71393 18.5 >5001.7 23.8 >1.57 2000 15572 100.0 38092 19.1 24619 16.0 12786 84.9 58874 14.7 >7541.5 26.4 > >RH Linux 7.1+XFS 6x72GB RAID 10 on AMI MegaRaid (493) dual 1.13Ghz 2Gb ram As a followup I tested the new firmware against different kernel versions and behold. The 2.4.9-12 kernel is the RedHat kernel that was released as a security update. The 2.4.14 kernel is the linus kernel. The filesystem is XFS on both versions. -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 2.4.9-12 2000 15568 100.0 38680 20.9 27593 17.6 13745 91.0 71393 18.5 5001.7 23.8 2.4.14 2000 11999 79.2 34491 23.8 18538 16.7 13615 90.1 89704 22.6 5493.9 23.3 The read speed with the newer 2.4.14 kernel is 18MB/sec faster then 2.4.9-12 kernel from redhat. Now I suspected that the new Andrea VM should make some difference but this is significant. What is odd however is that the write scores are lower across the board. 2.4.9-12: megaraid: v1.17a (Release Date: Fri Jul 13 18:44:01 EDT 2001) 2.4.14: megaraid: v1.18 (Release Date: Thu Oct 11 15:02:53 EDT 2001 When running Bonnie over a ssh modem link where the latency is higher the benchmark scores plummet which suggests that tty latency is affecting disk througput. Very strange. 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 Nov 9 03:02:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9B2NL32084 for linux-xfs-outgoing; Fri, 9 Nov 2001 03:02:23 -0800 Received: from mail.aem.umn.edu (mail.aem.umn.edu [128.101.142.239]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9B2E032061 for ; Fri, 9 Nov 2001 03:02:14 -0800 Received: from lightning.aem.umn.edu (lightning.aem.umn.edu [128.101.143.49]) by mail.aem.umn.edu (8.11.3/8.11.3) with ESMTP id fA9B3B081413; Fri, 9 Nov 2001 05:03:11 -0600 (CST) (envelope-from muno@aem.umn.edu) Received: (from muno@localhost) by lightning.aem.umn.edu (8.11.6/8.9.1) id fA9B2nB02920; Fri, 9 Nov 2001 05:02:49 -0600 Date: Fri, 9 Nov 2001 05:02:49 -0600 From: Ray Muno To: Ben Gollmer Cc: linux-xfs@oss.sgi.com Subject: Re: Adaptec dpt_i2o SCSI raid card Message-ID: <20011109050248.C2807@aem.umn.edu> References: <3BEA728D.C298461C@ieee.org> <10BFC93A-D4DD-11D5-B85A-003065B71D96@jatosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10BFC93A-D4DD-11D5-B85A-003065B71D96@jatosoft.com> User-Agent: Mutt/1.3.19-current-20010622i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am running an Adaptec 3200S in a box with Redhat 7.1 - SGI XFS 1.01, (2.4.3-SGI_XFS_1.0.1smp). Adaptec has the 7.1 drivers up on their site as mentioned. Since it was not one of their stock supported kernels, I applied the patch and recompiled. They had diffs for a variety of kernels but not for 2.4.3. The diffs for RH 7.1, 2.4.2 worked with a minor change for the diffs in the Makefile in drivers/scsi. I now have a 500 GB XFS filesystem on line for our cluster. % df -kl Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda5 8782720 1486432 7296288 17% / /dev/sda1 35328 12908 22420 37% /boot /dev/sdc1 501737024 1940 501735084 1% /u1 The place to look is http://linux.adaptec.com. The link mentioned below will get you to the same place. > Just wanted to chime in on this - I have a box with an Adaptec 2100s > card as well. I have been very happy with the performance & features > (probably because it was made by DPT...) > > Anyway, Linux support for this product has been non-existent, especially > as the board was advertised as being 'Linux compatible'. Until recently, > the DPT I20 drivers were not present on linux.adaptec.com, and the only > drivers that worked were the ones provided by Adaptec (for RedHat 6.2). > > I read somewhere that the kernel team has included I20 drivers that work > for this card in kernel 2.4.10 and up. I haven't had a chance to try > this yet...can anyone verify? Also, if you have luck with the old DPT > drivers, let me know. My box is due for an upgrade, RH 6.2 is getting > pretty old. I'm tempted to move to FreeBSD (drivers are included with > the distro), but I really would like to run XFS on this box. > > Ben > > > On Thursday, November 8, 2001, at 05:54 AM, Bryan-TheBS-Smith wrote: > > >Joost van der Locht wrote: > >>For Redhat 7.1 is on the website of Adaptec > >>(http://linuix.adaptec.com/linux_raid_unsupported.html) a driver disk > >>available for Redhat 7.1 > >>Creating an own driver disk can be done like this (thanks to Richard > >>Sharpe, > >>sharpe@ns.aus.com) > >>www.cantech.net.au/plug/2001-06/msg00248.html > > > >I hope everyone notes these are DPT's old drivers, which I've used in > >Linux over the years. Unlike Adaptec, they actually created their > >hardware to an open standard interface (I2O) so one driver could power > >any board, ATA, SCSI, etc... Too bad DPT has now been consumed by > >Adaptec, which means support is going out the window. > > > >Adaptec themselves are still creating endless, incompatible boards with > >splintering revisions of the same board for OEMs. Since starting to use > >Linux in 1993 and seeing one board work and another fail with drivers, > >as well as a number under Windows as well, I gave up. 3Ware for > >ATA-RAID, Mylex for SCSI, Advansys/Symbios Logic for plain SCSI, and a > >few select others (e.g., I'll "tolerate" HighPoint's "trick BIOS" ATA > >controller chips since their Linux drivers work well) are all I'll use. > > > >Until Adaptec and Promise get their acts together (not likely since they > >get so much business from their "brand name"), I won't be using their > >products in Linux, or even Windows systems for that matter. You'd > >figure with their size they'd actually make the best products with the > >best Linux support? Hardly, both usually lose every benchmark I've seen > >and Linux support for their products has always been a 3rd > >party/community proposition, or increasingly binary only for only select > >products. > > > >Just my $0.02 ... > > > >-- TheBS > > > >-- > >Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 > >Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org > >President SmithConcepts, Inc. http://www.SmithConcepts.com > >---------------------------------------------------------------- > >* Pentium stop, Pentium SMP go, Athlon MP go ... go very fast! * > > > > > ============================================================================= Ray Muno http://www.aem.umn.edu/people/staff/muno University of Minnesota e-mail: muno@aem.umn.edu Aerospace Engineering and Mechanics Phone: (612) 625-9531 110 Union St. S.E. FAX: (612) 626-1558 Minneapolis, Mn 55455 ============================================================================= From owner-linux-xfs@oss.sgi.com Fri Nov 9 03:56:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9BuUS02401 for linux-xfs-outgoing; Fri, 9 Nov 2001 03:56:30 -0800 Received: from camelot.virtualavalon.net (127bus50.tampabay.rr.com [24.94.127.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9BuP002377 for ; Fri, 9 Nov 2001 03:56:25 -0800 Received: from arthur.virtualavalon.net (arthur.virtualavalon.net [172.20.1.10]) by camelot.virtualavalon.net (8.12.0/8.12.0) with ESMTP id fA9BuOrh025150 for ; Fri, 9 Nov 2001 06:56:24 -0500 Received: from tampabay.rr.com (wayfarer.virtualavalon.net [172.20.1.15]) by arthur.virtualavalon.net (8.12.0/8.12.0) with ESMTP id fA9BuJL5011911 for ; Fri, 9 Nov 2001 06:56:19 -0500 (EST) Message-ID: <3BEBC452.5030508@tampabay.rr.com> Date: Fri, 09 Nov 2001 06:56:02 -0500 From: "Jesse W. Asher" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Adaptec dpt_i2o SCSI raid card References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk While they may have included drivers in the kernel, I'd still recommend downloading the file(s) from Adaptec since they also include some utilities for manupulating the settings in the card. I'm running a 3200S and everything went fairly smoothly using the Adaptec drivers and utilities.... Ben Gollmer wrote: >> I read somewhere that the kernel team has included I20 drivers that >> work for this card in kernel 2.4.10 and up. I haven't had a chance to >> try this yet...can anyone verify? > > > *SMACK* > > Missed a post in this thread...oops : ) Now if someone will just > release a distro with 2.4.10+, so I can install directly to the > 2100s's drives... > > Ben > > -- Jesse W. Asher "They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty or safety." - Benjamin Franklin From owner-linux-xfs@oss.sgi.com Fri Nov 9 04:30:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9CUN403190 for linux-xfs-outgoing; Fri, 9 Nov 2001 04:30:23 -0800 Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9CT1003139 for ; Fri, 9 Nov 2001 04:29:01 -0800 Received: from teach.ic.ucsc.edu (jrl@teach.ic.ucsc.edu [128.114.129.197]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id EAA20402 for ; Fri, 9 Nov 2001 04:32:58 -0800 (PST) Date: Fri, 9 Nov 2001 04:29:00 -0800 (PST) From: Johnny Luong X-Sender: jrl@teach.ic.ucsc.edu To: linux-xfs@oss.sgi.com Subject: OOPS: Unable to handle kernel NULL pointer dereference... Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1005308940=:23483" 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-851401618-1005308940=:23483 Content-Type: TEXT/PLAIN; charset=US-ASCII 1. See subject. 2. It oopsed under "normal" desktop usage (X running, sawfish/gnome, etc.) 3. Looks like XFS from the backtrace. 4. Linux version 2.4.14-xfs (root@dual.localdomain) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-96)) #3 SMP Wed Nov 7 02:38:23 PST 2001 5. See attachment. 6. Seem to occur spontaneously. Doesn't cause my machine to crash though. 7.1. Linux dual.localdomain 2.4.14-xfs #3 SMP Wed Nov 7 02:38:23 PST 2001 i686 unknown Gnu C 2.96 Gnu make 3.79.1 binutils 2.11.90.0.8 util-linux 2.11f mount 2.11g modutils 2.4.6 e2fsprogs 1.22 reiserfsprogs 3.x.0j PPP 2.4.1 isdn4k-utils 3.1pre1 Linux C Library 2.2.4 Dynamic linker (ldd) 2.2.4 Procps 2.0.7 Net-tools 1.60 Console-tools 0.3.3 Sh-utils 2.0.11 Modules Loaded tuner tvaudio msp3400 bttv i2c-algo-bit i2c-core videodev tdfx agpgart ppp_deflate bsd_comp ppp_async ppp_generic slhc parport_pc lp parport autofs eepro100 ide-scsi scsi_mod ide-cd cdrom nls_iso8859-1 nls_cp437 vfat fat md es1371 gameport ac97_codec soundcore mousedev hid usbmouse input usb-uhci usbcore 7.2 --- processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 6 model name : Celeron (Mendocino) stepping : 5 cpu MHz : 400.916 cache size : 128 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips : 799.53 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 6 model name : Celeron (Mendocino) stepping : 5 cpu MHz : 400.916 cache size : 128 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips : 801.17 7.3 --- tuner 11165 1 (autoclean) tvaudio 12747 0 (autoclean) (unused) msp3400 18344 1 (autoclean) bttv 67632 0 (autoclean) i2c-algo-bit 8992 1 (autoclean) [bttv] i2c-core 18152 0 (autoclean) [tuner tvaudio msp3400 bttv i2c-algo-bit] videodev 7016 2 (autoclean) [bttv] tdfx 41040 1 agpgart 19395 0 (unused) ppp_deflate 45261 0 (autoclean) bsd_comp 5160 0 (autoclean) ppp_async 7852 1 (autoclean) ppp_generic 24691 3 (autoclean) [ppp_deflate bsd_comp ppp_async] slhc 5850 1 (autoclean) [ppp_generic] parport_pc 31298 1 (autoclean) lp 7900 0 (autoclean) parport 33003 1 (autoclean) [parport_pc lp] autofs 11878 1 (autoclean) eepro100 20550 0 (unused) ide-scsi 9870 0 scsi_mod 65189 1 [ide-scsi] ide-cd 34801 0 cdrom 33381 0 [ide-cd] nls_iso8859-1 3519 1 (autoclean) nls_cp437 5145 1 (autoclean) vfat 12381 1 (autoclean) fat 37039 0 (autoclean) [vfat] md 52056 0 (unused) es1371 33069 1 gameport 2824 0 [es1371] ac97_codec 13214 0 [es1371] soundcore 6309 4 [es1371] mousedev 5266 1 hid 20711 0 (unused) usbmouse 2793 0 (unused) input 5360 0 [mousedev hid usbmouse] usb-uhci 26206 0 (unused) usbcore 63474 1 [hid usbmouse usb-uhci] 7.4 --- 0000-001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 01f0-01f7 : ide0 02f8-02ff : serial(auto) 0378-037a : parport0 037b-037f : parport0 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0cf8-0cff : PCI conf1 4000-403f : Intel Corp. 82371AB PIIX4 ACPI 5000-501f : Intel Corp. 82371AB PIIX4 ACPI 9000-9fff : PCI Bus #01 9000-90ff : 3Dfx Interactive, Inc. Voodoo 3 a000-a01f : Intel Corp. 82371AB PIIX4 USB a000-a01f : usb-uhci a400-a43f : Ensoniq 5880 AudioPCI a400-a43f : es1371 a800-a83f : Intel Corp. 82557 [Ethernet Pro 100] a800-a83f : eepro100 ac00-ac07 : Triones Technologies, Inc. HPT366 / HPT370 ac00-ac07 : ide2 b000-b003 : Triones Technologies, Inc. HPT366 / HPT370 b002-b002 : ide2 b400-b4ff : Triones Technologies, Inc. HPT366 / HPT370 b400-b407 : ide2 b410-b4ff : HPT366 b800-b807 : Triones Technologies, Inc. HPT366 / HPT370 (#2) bc00-bc03 : Triones Technologies, Inc. HPT366 / HPT370 (#2) c000-c0ff : Triones Technologies, Inc. HPT366 / HPT370 (#2) c000-c007 : ide3 c010-c0ff : HPT366 f000-f00f : Intel Corp. 82371AB PIIX4 IDE f000-f007 : ide0 f008-f00f : ide1 7.5 --- 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B+ 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 00:0d.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) Subsystem: Intel Corporation EtherExpress PRO/100+ Management Adapter Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=1M] Capabilities: 00:11.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 11) Subsystem: Hauppauge computer works Inc.: Unknown device 3900 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- 00:11.1 Multimedia controller: Brooktree Corporation Bt878 (rev 11) Subsystem: Hauppauge computer works Inc.: Unknown device 3900 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- 00:13.0 Unknown mass storage controller: HighPoint Technologies, Inc. HPT366/370 UltraDMA 66/100 IDE Controller (rev 01) Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=128K] 00:13.1 Unknown mass storage controller: HighPoint Technologies, Inc. HPT366/370 UltraDMA 66/100 IDE Controller (rev 01) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- [disabled] [size=64K] Capabilities: 7.6 --- Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: IOMEGA Model: ZIPCDINT1536 Rev: 3.27 Type: CD-ROM ANSI SCSI revision: 02 7.7 --- I've included my kernel configuration as an attachment as well. The distribution is based off the roswell beta release and I'll see if the problem occurs as well under the redhat 7.2 release later. It might be bad Redhat stuff... *shrug* Please CC me as I'm not on this mailing list with regards to any questions. Sincerely, Johnny Luong jrl@cats.ucsc.edu ---559023410-851401618-1005308940=:23483 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="2.4.14.config" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Iw0KIyBBdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCBieSBtYWtlIG1lbnVjb25m aWc6IGRvbid0IGVkaXQNCiMNCkNPTkZJR19YODY9eQ0KQ09ORklHX0lTQT15 DQojIENPTkZJR19TQlVTIGlzIG5vdCBzZXQNCkNPTkZJR19VSUQxNj15DQoN CiMNCiMgQ29kZSBtYXR1cml0eSBsZXZlbCBvcHRpb25zDQojDQpDT05GSUdf RVhQRVJJTUVOVEFMPXkNCg0KIw0KIyBMb2FkYWJsZSBtb2R1bGUgc3VwcG9y dA0KIw0KQ09ORklHX01PRFVMRVM9eQ0KIyBDT05GSUdfTU9EVkVSU0lPTlMg aXMgbm90IHNldA0KQ09ORklHX0tNT0Q9eQ0KDQojDQojIFByb2Nlc3NvciB0 eXBlIGFuZCBmZWF0dXJlcw0KIw0KIyBDT05GSUdfTTM4NiBpcyBub3Qgc2V0 DQojIENPTkZJR19NNDg2IGlzIG5vdCBzZXQNCiMgQ09ORklHX001ODYgaXMg bm90IHNldA0KIyBDT05GSUdfTTU4NlRTQyBpcyBub3Qgc2V0DQojIENPTkZJ R19NNTg2TU1YIGlzIG5vdCBzZXQNCkNPTkZJR19NNjg2PXkNCiMgQ09ORklH X01QRU5USVVNSUlJIGlzIG5vdCBzZXQNCiMgQ09ORklHX01QRU5USVVNNCBp cyBub3Qgc2V0DQojIENPTkZJR19NSzYgaXMgbm90IHNldA0KIyBDT05GSUdf TUs3IGlzIG5vdCBzZXQNCiMgQ09ORklHX01DUlVTT0UgaXMgbm90IHNldA0K IyBDT05GSUdfTVdJTkNISVBDNiBpcyBub3Qgc2V0DQojIENPTkZJR19NV0lO Q0hJUDIgaXMgbm90IHNldA0KIyBDT05GSUdfTVdJTkNISVAzRCBpcyBub3Qg c2V0DQojIENPTkZJR19NQ1lSSVhJSUkgaXMgbm90IHNldA0KQ09ORklHX1g4 Nl9XUF9XT1JLU19PSz15DQpDT05GSUdfWDg2X0lOVkxQRz15DQpDT05GSUdf WDg2X0NNUFhDSEc9eQ0KQ09ORklHX1g4Nl9YQUREPXkNCkNPTkZJR19YODZf QlNXQVA9eQ0KQ09ORklHX1g4Nl9QT1BBRF9PSz15DQojIENPTkZJR19SV1NF TV9HRU5FUklDX1NQSU5MT0NLIGlzIG5vdCBzZXQNCkNPTkZJR19SV1NFTV9Y Q0hHQUREX0FMR09SSVRITT15DQpDT05GSUdfWDg2X0wxX0NBQ0hFX1NISUZU PTUNCkNPTkZJR19YODZfVFNDPXkNCkNPTkZJR19YODZfR09PRF9BUElDPXkN CkNPTkZJR19YODZfUEdFPXkNCkNPTkZJR19YODZfVVNFX1BQUk9fQ0hFQ0tT VU09eQ0KIyBDT05GSUdfVE9TSElCQSBpcyBub3Qgc2V0DQojIENPTkZJR19J OEsgaXMgbm90IHNldA0KIyBDT05GSUdfTUlDUk9DT0RFIGlzIG5vdCBzZXQN CiMgQ09ORklHX1g4Nl9NU1IgaXMgbm90IHNldA0KIyBDT05GSUdfWDg2X0NQ VUlEIGlzIG5vdCBzZXQNCkNPTkZJR19OT0hJR0hNRU09eQ0KIyBDT05GSUdf SElHSE1FTTRHIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJR0hNRU02NEcgaXMg bm90IHNldA0KIyBDT05GSUdfTUFUSF9FTVVMQVRJT04gaXMgbm90IHNldA0K Q09ORklHX01UUlI9eQ0KQ09ORklHX1NNUD15DQojIENPTkZJR19NVUxUSVFV QUQgaXMgbm90IHNldA0KQ09ORklHX0hBVkVfREVDX0xPQ0s9eQ0KDQojDQoj IEdlbmVyYWwgc2V0dXANCiMNCkNPTkZJR19ORVQ9eQ0KQ09ORklHX1g4Nl9J T19BUElDPXkNCkNPTkZJR19YODZfTE9DQUxfQVBJQz15DQpDT05GSUdfUENJ PXkNCiMgQ09ORklHX1BDSV9HT0JJT1MgaXMgbm90IHNldA0KIyBDT05GSUdf UENJX0dPRElSRUNUIGlzIG5vdCBzZXQNCkNPTkZJR19QQ0lfR09BTlk9eQ0K Q09ORklHX1BDSV9CSU9TPXkNCkNPTkZJR19QQ0lfRElSRUNUPXkNCkNPTkZJ R19QQ0lfTkFNRVM9eQ0KIyBDT05GSUdfRUlTQSBpcyBub3Qgc2V0DQojIENP TkZJR19NQ0EgaXMgbm90IHNldA0KQ09ORklHX0hPVFBMVUc9eQ0KDQojDQoj IFBDTUNJQS9DYXJkQnVzIHN1cHBvcnQNCiMNCiMgQ09ORklHX1BDTUNJQSBp cyBub3Qgc2V0DQpDT05GSUdfU1lTVklQQz15DQpDT05GSUdfQlNEX1BST0NF U1NfQUNDVD15DQpDT05GSUdfU1lTQ1RMPXkNCkNPTkZJR19LQ09SRV9FTEY9 eQ0KIyBDT05GSUdfS0NPUkVfQU9VVCBpcyBub3Qgc2V0DQpDT05GSUdfQklO Rk1UX0FPVVQ9bQ0KQ09ORklHX0JJTkZNVF9FTEY9eQ0KQ09ORklHX0JJTkZN VF9NSVNDPW0NCkNPTkZJR19QTT15DQpDT05GSUdfQUNQST15DQojIENPTkZJ R19BQ1BJX0RFQlVHIGlzIG5vdCBzZXQNCkNPTkZJR19BQ1BJX0JVU01HUj1t DQpDT05GSUdfQUNQSV9TWVM9bQ0KQ09ORklHX0FDUElfQ1BVPW0NCkNPTkZJ R19BQ1BJX0JVVFRPTj1tDQpDT05GSUdfQUNQSV9BQz1tDQpDT05GSUdfQUNQ SV9FQz1tDQpDT05GSUdfQUNQSV9DTUJBVFQ9bQ0KQ09ORklHX0FDUElfVEhF Uk1BTD1tDQojIENPTkZJR19BUE0gaXMgbm90IHNldA0KDQojDQojIE1lbW9y eSBUZWNobm9sb2d5IERldmljZXMgKE1URCkNCiMNCiMgQ09ORklHX01URCBp cyBub3Qgc2V0DQoNCiMNCiMgUGFyYWxsZWwgcG9ydCBzdXBwb3J0DQojDQpD T05GSUdfUEFSUE9SVD1tDQpDT05GSUdfUEFSUE9SVF9QQz1tDQpDT05GSUdf UEFSUE9SVF9QQ19DTUwxPW0NCiMgQ09ORklHX1BBUlBPUlRfU0VSSUFMIGlz IG5vdCBzZXQNCkNPTkZJR19QQVJQT1JUX1BDX0ZJRk89eQ0KQ09ORklHX1BB UlBPUlRfUENfU1VQRVJJTz15DQojIENPTkZJR19QQVJQT1JUX0FNSUdBIGlz IG5vdCBzZXQNCiMgQ09ORklHX1BBUlBPUlRfTUZDMyBpcyBub3Qgc2V0DQoj IENPTkZJR19QQVJQT1JUX0FUQVJJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BB UlBPUlRfU1VOQlBQIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BBUlBPUlRfT1RI RVIgaXMgbm90IHNldA0KQ09ORklHX1BBUlBPUlRfMTI4ND15DQoNCiMNCiMg UGx1ZyBhbmQgUGxheSBjb25maWd1cmF0aW9uDQojDQpDT05GSUdfUE5QPW0N CkNPTkZJR19JU0FQTlA9bQ0KDQojDQojIEJsb2NrIGRldmljZXMNCiMNCkNP TkZJR19CTEtfREVWX0ZEPXkNCiMgQ09ORklHX0JMS19ERVZfWEQgaXMgbm90 IHNldA0KIyBDT05GSUdfUEFSSURFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JM S19DUFFfREEgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0NQUV9DSVNTX0RB IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfREFDOTYwIGlzIG5vdCBz ZXQNCkNPTkZJR19CTEtfREVWX0xPT1A9bQ0KQ09ORklHX0JMS19ERVZfTkJE PW0NCiMgQ09ORklHX0JMS19ERVZfUkFNIGlzIG5vdCBzZXQNCiMgQ09ORklH X0JMS19ERVZfSU5JVFJEIGlzIG5vdCBzZXQNCg0KIw0KIyBNdWx0aS1kZXZp Y2Ugc3VwcG9ydCAoUkFJRCBhbmQgTFZNKQ0KIw0KQ09ORklHX01EPXkNCkNP TkZJR19CTEtfREVWX01EPW0NCkNPTkZJR19NRF9MSU5FQVI9bQ0KQ09ORklH X01EX1JBSUQwPW0NCkNPTkZJR19NRF9SQUlEMT1tDQpDT05GSUdfTURfUkFJ RDU9bQ0KQ09ORklHX01EX01VTFRJUEFUSD1tDQpDT05GSUdfQkxLX0RFVl9M Vk09bQ0KDQojDQojIE5ldHdvcmtpbmcgb3B0aW9ucw0KIw0KQ09ORklHX1BB Q0tFVD15DQpDT05GSUdfUEFDS0VUX01NQVA9eQ0KIyBDT05GSUdfTkVUTElO SyBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRGSUxURVIgaXMgbm90IHNldA0K Q09ORklHX0ZJTFRFUj15DQpDT05GSUdfVU5JWD15DQpDT05GSUdfSU5FVD15 DQpDT05GSUdfSVBfTVVMVElDQVNUPXkNCiMgQ09ORklHX0lQX0FEVkFOQ0VE X1JPVVRFUiBpcyBub3Qgc2V0DQojIENPTkZJR19JUF9QTlAgaXMgbm90IHNl dA0KIyBDT05GSUdfTkVUX0lQSVAgaXMgbm90IHNldA0KIyBDT05GSUdfTkVU X0lQR1JFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQX01ST1VURSBpcyBub3Qg c2V0DQpDT05GSUdfSU5FVF9FQ049eQ0KQ09ORklHX1NZTl9DT09LSUVTPXkN CiMgQ09ORklHX0lQVjYgaXMgbm90IHNldA0KIyBDT05GSUdfS0hUVFBEIGlz IG5vdCBzZXQNCiMgQ09ORklHX0FUTSBpcyBub3Qgc2V0DQojIENPTkZJR19W TEFOXzgwMjFRIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQWCBpcyBub3Qgc2V0 DQojIENPTkZJR19BVEFMSyBpcyBub3Qgc2V0DQojIENPTkZJR19ERUNORVQg aXMgbm90IHNldA0KIyBDT05GSUdfQlJJREdFIGlzIG5vdCBzZXQNCiMgQ09O RklHX1gyNSBpcyBub3Qgc2V0DQojIENPTkZJR19MQVBCIGlzIG5vdCBzZXQN CiMgQ09ORklHX0xMQyBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfRElWRVJU IGlzIG5vdCBzZXQNCiMgQ09ORklHX0VDT05FVCBpcyBub3Qgc2V0DQojIENP TkZJR19XQU5fUk9VVEVSIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9GQVNU Uk9VVEUgaXMgbm90IHNldA0KIyBDT05GSUdfTkVUX0hXX0ZMT1dDT05UUk9M IGlzIG5vdCBzZXQNCg0KIw0KIyBRb1MgYW5kL29yIGZhaXIgcXVldWVpbmcN CiMNCiMgQ09ORklHX05FVF9TQ0hFRCBpcyBub3Qgc2V0DQoNCiMNCiMgVGVs ZXBob255IFN1cHBvcnQNCiMNCiMgQ09ORklHX1BIT05FIGlzIG5vdCBzZXQN CiMgQ09ORklHX1BIT05FX0lYSiBpcyBub3Qgc2V0DQojIENPTkZJR19QSE9O RV9JWEpfUENNQ0lBIGlzIG5vdCBzZXQNCg0KIw0KIyBBVEEvSURFL01GTS9S TEwgc3VwcG9ydA0KIw0KQ09ORklHX0lERT15DQoNCiMNCiMgSURFLCBBVEEg YW5kIEFUQVBJIEJsb2NrIGRldmljZXMNCiMNCkNPTkZJR19CTEtfREVWX0lE RT15DQojIENPTkZJR19CTEtfREVWX0hEX0lERSBpcyBub3Qgc2V0DQojIENP TkZJR19CTEtfREVWX0hEIGlzIG5vdCBzZXQNCkNPTkZJR19CTEtfREVWX0lE RURJU0s9eQ0KQ09ORklHX0lERURJU0tfTVVMVElfTU9ERT15DQojIENPTkZJ R19CTEtfREVWX0lERURJU0tfVkVORE9SIGlzIG5vdCBzZXQNCiMgQ09ORklH X0JMS19ERVZfSURFRElTS19GVUpJVFNVIGlzIG5vdCBzZXQNCiMgQ09ORklH X0JMS19ERVZfSURFRElTS19JQk0gaXMgbm90IHNldA0KIyBDT05GSUdfQkxL X0RFVl9JREVESVNLX01BWFRPUiBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtf REVWX0lERURJU0tfUVVBTlRVTSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtf REVWX0lERURJU0tfU0VBR0FURSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtf REVWX0lERURJU0tfV0QgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9D T01NRVJJQUwgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9USVZPIGlz IG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfSURFQ1MgaXMgbm90IHNldA0K Q09ORklHX0JMS19ERVZfSURFQ0Q9bQ0KQ09ORklHX0JMS19ERVZfSURFVEFQ RT1tDQpDT05GSUdfQkxLX0RFVl9JREVGTE9QUFk9bQ0KQ09ORklHX0JMS19E RVZfSURFU0NTST1tDQojIENPTkZJR19CTEtfREVWX0NNRDY0MCBpcyBub3Qg c2V0DQojIENPTkZJR19CTEtfREVWX0NNRDY0MF9FTkhBTkNFRCBpcyBub3Qg c2V0DQojIENPTkZJR19CTEtfREVWX0lTQVBOUCBpcyBub3Qgc2V0DQojIENP TkZJR19CTEtfREVWX1JaMTAwMCBpcyBub3Qgc2V0DQpDT05GSUdfQkxLX0RF Vl9JREVQQ0k9eQ0KQ09ORklHX0lERVBDSV9TSEFSRV9JUlE9eQ0KQ09ORklH X0JMS19ERVZfSURFRE1BX1BDST15DQpDT05GSUdfQkxLX0RFVl9BRE1BPXkN CiMgQ09ORklHX0JMS19ERVZfT0ZGQk9BUkQgaXMgbm90IHNldA0KQ09ORklH X0lERURNQV9QQ0lfQVVUTz15DQpDT05GSUdfQkxLX0RFVl9JREVETUE9eQ0K IyBDT05GSUdfSURFRE1BX1BDSV9XSVAgaXMgbm90IHNldA0KIyBDT05GSUdf SURFRE1BX05FV19EUklWRV9MSVNUSU5HUyBpcyBub3Qgc2V0DQojIENPTkZJ R19CTEtfREVWX0FFQzYyWFggaXMgbm90IHNldA0KIyBDT05GSUdfQUVDNjJY WF9UVU5JTkcgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9BTEkxNVgz IGlzIG5vdCBzZXQNCiMgQ09ORklHX1dEQ19BTEkxNVgzIGlzIG5vdCBzZXQN CiMgQ09ORklHX0JMS19ERVZfQU1ENzRYWCBpcyBub3Qgc2V0DQojIENPTkZJ R19BTUQ3NFhYX09WRVJSSURFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19E RVZfQ01ENjRYIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfQ1k4MkM2 OTMgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9DUzU1MzAgaXMgbm90 IHNldA0KIyBDT05GSUdfQkxLX0RFVl9IUFQzNFggaXMgbm90IHNldA0KIyBD T05GSUdfSFBUMzRYX0FVVE9ETUEgaXMgbm90IHNldA0KQ09ORklHX0JMS19E RVZfSFBUMzY2PXkNCkNPTkZJR19CTEtfREVWX1BJSVg9eQ0KQ09ORklHX1BJ SVhfVFVOSU5HPXkNCiMgQ09ORklHX0JMS19ERVZfTlM4NzQxNSBpcyBub3Qg c2V0DQojIENPTkZJR19CTEtfREVWX09QVEk2MjEgaXMgbm90IHNldA0KIyBD T05GSUdfQkxLX0RFVl9QREMyMDJYWCBpcyBub3Qgc2V0DQojIENPTkZJR19Q REMyMDJYWF9CVVJTVCBpcyBub3Qgc2V0DQojIENPTkZJR19QREMyMDJYWF9G T1JDRSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX1NWV0tTIGlzIG5v dCBzZXQNCiMgQ09ORklHX0JMS19ERVZfU0lTNTUxMyBpcyBub3Qgc2V0DQoj IENPTkZJR19CTEtfREVWX1NMQzkwRTY2IGlzIG5vdCBzZXQNCiMgQ09ORklH X0JMS19ERVZfVFJNMjkwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZf VklBODJDWFhYIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lERV9DSElQU0VUUyBp cyBub3Qgc2V0DQpDT05GSUdfSURFRE1BX0FVVE89eQ0KIyBDT05GSUdfSURF RE1BX0lWQiBpcyBub3Qgc2V0DQojIENPTkZJR19ETUFfTk9OUENJIGlzIG5v dCBzZXQNCkNPTkZJR19CTEtfREVWX0lERV9NT0RFUz15DQojIENPTkZJR19C TEtfREVWX0FUQVJBSUQgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9B VEFSQUlEX1BEQyBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0FUQVJB SURfSFBUIGlzIG5vdCBzZXQNCg0KIw0KIyBTQ1NJIHN1cHBvcnQNCiMNCkNP TkZJR19TQ1NJPW0NCkNPTkZJR19CTEtfREVWX1NEPW0NCkNPTkZJR19TRF9F WFRSQV9ERVZTPTQwDQojIENPTkZJR19DSFJfREVWX1NUIGlzIG5vdCBzZXQN CiMgQ09ORklHX0NIUl9ERVZfT1NTVCBpcyBub3Qgc2V0DQpDT05GSUdfQkxL X0RFVl9TUj1tDQpDT05GSUdfQkxLX0RFVl9TUl9WRU5ET1I9eQ0KQ09ORklH X1NSX0VYVFJBX0RFVlM9NA0KQ09ORklHX0NIUl9ERVZfU0c9bQ0KIyBDT05G SUdfU0NTSV9ERUJVR19RVUVVRVMgaXMgbm90IHNldA0KIyBDT05GSUdfU0NT SV9NVUxUSV9MVU4gaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9DT05TVEFO VFMgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9MT0dHSU5HIGlzIG5vdCBz ZXQNCg0KIw0KIyBTQ1NJIGxvdy1sZXZlbCBkcml2ZXJzDQojDQojIENPTkZJ R19CTEtfREVWXzNXX1hYWFhfUkFJRCBpcyBub3Qgc2V0DQojIENPTkZJR19T Q1NJXzcwMDBGQVNTVCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0FDQVJE IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfQUhBMTUyWCBpcyBub3Qgc2V0 DQojIENPTkZJR19TQ1NJX0FIQTE1NDIgaXMgbm90IHNldA0KIyBDT05GSUdf U0NTSV9BSEExNzQwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfQUlDN1hY WCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0FJQzdYWFhfT0xEIGlzIG5v dCBzZXQNCiMgQ09ORklHX1NDU0lfRFBUX0kyTyBpcyBub3Qgc2V0DQpDT05G SUdfU0NTSV9BRFZBTlNZUz1tDQojIENPTkZJR19TQ1NJX0lOMjAwMCBpcyBu b3Qgc2V0DQojIENPTkZJR19TQ1NJX0FNNTNDOTc0IGlzIG5vdCBzZXQNCiMg Q09ORklHX1NDU0lfTUVHQVJBSUQgaXMgbm90IHNldA0KIyBDT05GSUdfU0NT SV9CVVNMT0dJQyBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0NQUUZDVFMg aXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9ETVgzMTkxRCBpcyBub3Qgc2V0 DQojIENPTkZJR19TQ1NJX0RUQzMyODAgaXMgbm90IHNldA0KIyBDT05GSUdf U0NTSV9FQVRBIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfRUFUQV9ETUEg aXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9FQVRBX1BJTyBpcyBub3Qgc2V0 DQojIENPTkZJR19TQ1NJX0ZVVFVSRV9ET01BSU4gaXMgbm90IHNldA0KIyBD T05GSUdfU0NTSV9HRFRIIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfR0VO RVJJQ19OQ1I1MzgwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfSVBTIGlz IG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfSU5JVElPIGlzIG5vdCBzZXQNCiMg Q09ORklHX1NDU0lfSU5JQTEwMCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJ X1BQQSBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0lNTSBpcyBub3Qgc2V0 DQojIENPTkZJR19TQ1NJX05DUjUzQzQwNkEgaXMgbm90IHNldA0KIyBDT05G SUdfU0NTSV9OQ1I1M0M3eHggaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9O Q1I1M0M4WFggaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9TWU01M0M4WFgg aXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9QQVMxNiBpcyBub3Qgc2V0DQoj IENPTkZJR19TQ1NJX1BDSTIwMDAgaXMgbm90IHNldA0KIyBDT05GSUdfU0NT SV9QQ0kyMjIwSSBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1BTSTI0MEkg aXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9RTE9HSUNfRkFTIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1NDU0lfUUxPR0lDX0lTUCBpcyBub3Qgc2V0DQojIENP TkZJR19TQ1NJX1FMT0dJQ19GQyBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJ X1FMT0dJQ18xMjgwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfU0VBR0FU RSBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1NJTTcxMCBpcyBub3Qgc2V0 DQojIENPTkZJR19TQ1NJX1NZTTUzQzQxNiBpcyBub3Qgc2V0DQojIENPTkZJ R19TQ1NJX0RDMzkwVCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1QxMjgg aXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9VMTRfMzRGIGlzIG5vdCBzZXQN CiMgQ09ORklHX1NDU0lfVUxUUkFTVE9SIGlzIG5vdCBzZXQNCiMgQ09ORklH X1NDU0lfREVCVUcgaXMgbm90IHNldA0KDQojDQojIEZ1c2lvbiBNUFQgZGV2 aWNlIHN1cHBvcnQNCiMNCiMgQ09ORklHX0ZVU0lPTiBpcyBub3Qgc2V0DQoj IENPTkZJR19GVVNJT05fQk9PVCBpcyBub3Qgc2V0DQojIENPTkZJR19GVVNJ T05fSVNFTlNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZVU0lPTl9DVEwgaXMg bm90IHNldA0KIyBDT05GSUdfRlVTSU9OX0xBTiBpcyBub3Qgc2V0DQoNCiMN CiMgSUVFRSAxMzk0IChGaXJlV2lyZSkgc3VwcG9ydCAoRVhQRVJJTUVOVEFM KQ0KIw0KQ09ORklHX0lFRUUxMzk0PW0NCkNPTkZJR19JRUVFMTM5NF9QQ0lM WU5YPW0NCiMgQ09ORklHX0lFRUUxMzk0X1BDSUxZTlhfTE9DQUxSQU0gaXMg bm90IHNldA0KIyBDT05GSUdfSUVFRTEzOTRfUENJTFlOWF9QT1JUUyBpcyBu b3Qgc2V0DQpDT05GSUdfSUVFRTEzOTRfT0hDSTEzOTQ9bQ0KQ09ORklHX0lF RUUxMzk0X1ZJREVPMTM5ND1tDQpDT05GSUdfSUVFRTEzOTRfU0JQMj1tDQpD T05GSUdfSUVFRTEzOTRfUkFXSU89bQ0KIyBDT05GSUdfSUVFRTEzOTRfVkVS Qk9TRURFQlVHIGlzIG5vdCBzZXQNCg0KIw0KIyBJMk8gZGV2aWNlIHN1cHBv cnQNCiMNCkNPTkZJR19JMk89bQ0KQ09ORklHX0kyT19QQ0k9bQ0KQ09ORklH X0kyT19CTE9DSz1tDQpDT05GSUdfSTJPX0xBTj1tDQpDT05GSUdfSTJPX1ND U0k9bQ0KQ09ORklHX0kyT19QUk9DPW0NCg0KIw0KIyBOZXR3b3JrIGRldmlj ZSBzdXBwb3J0DQojDQpDT05GSUdfTkVUREVWSUNFUz15DQoNCiMNCiMgQVJD bmV0IGRldmljZXMNCiMNCiMgQ09ORklHX0FSQ05FVCBpcyBub3Qgc2V0DQpD T05GSUdfRFVNTVk9bQ0KQ09ORklHX0JPTkRJTkc9bQ0KIyBDT05GSUdfRVFV QUxJWkVSIGlzIG5vdCBzZXQNCkNPTkZJR19UVU49bQ0KIyBDT05GSUdfTkVU X1NCMTAwMCBpcyBub3Qgc2V0DQoNCiMNCiMgRXRoZXJuZXQgKDEwIG9yIDEw ME1iaXQpDQojDQpDT05GSUdfTkVUX0VUSEVSTkVUPXkNCiMgQ09ORklHX1NV TkxBTkNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hBUFBZTUVBTCBpcyBub3Qg c2V0DQojIENPTkZJR19TVU5CTUFDIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NV TlFFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NVTkxBTkNFIGlzIG5vdCBzZXQN CiMgQ09ORklHX1NVTkdFTSBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfVkVO RE9SXzNDT00gaXMgbm90IHNldA0KIyBDT05GSUdfTEFOQ0UgaXMgbm90IHNl dA0KIyBDT05GSUdfTkVUX1ZFTkRPUl9TTUMgaXMgbm90IHNldA0KIyBDT05G SUdfTkVUX1ZFTkRPUl9SQUNBTCBpcyBub3Qgc2V0DQojIENPTkZJR19BVDE3 MDAgaXMgbm90IHNldA0KIyBDT05GSUdfREVQQ0EgaXMgbm90IHNldA0KIyBD T05GSUdfSFAxMDAgaXMgbm90IHNldA0KQ09ORklHX05FVF9JU0E9eQ0KIyBD T05GSUdfRTIxMDAgaXMgbm90IHNldA0KIyBDT05GSUdfRVdSSzMgaXMgbm90 IHNldA0KIyBDT05GSUdfRUVYUFJFU1MgaXMgbm90IHNldA0KIyBDT05GSUdf RUVYUFJFU1NfUFJPIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hQTEFOX1BMVVMg aXMgbm90IHNldA0KIyBDT05GSUdfSFBMQU4gaXMgbm90IHNldA0KIyBDT05G SUdfTFA0ODZFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0VUSDE2SSBpcyBub3Qg c2V0DQpDT05GSUdfTkUyMDAwPW0NCkNPTkZJR19ORVRfUENJPXkNCiMgQ09O RklHX1BDTkVUMzIgaXMgbm90IHNldA0KIyBDT05GSUdfQURBUFRFQ19TVEFS RklSRSBpcyBub3Qgc2V0DQojIENPTkZJR19BQzMyMDAgaXMgbm90IHNldA0K IyBDT05GSUdfQVBSSUNPVCBpcyBub3Qgc2V0DQojIENPTkZJR19DUzg5eDAg aXMgbm90IHNldA0KIyBDT05GSUdfVFVMSVAgaXMgbm90IHNldA0KIyBDT05G SUdfREU0WDUgaXMgbm90IHNldA0KIyBDT05GSUdfREdSUyBpcyBub3Qgc2V0 DQojIENPTkZJR19ETTkxMDIgaXMgbm90IHNldA0KQ09ORklHX0VFUFJPMTAw PW0NCiMgQ09ORklHX0xORTM5MCBpcyBub3Qgc2V0DQojIENPTkZJR19GRUFM TlggaXMgbm90IHNldA0KIyBDT05GSUdfTkFUU0VNSSBpcyBub3Qgc2V0DQoj IENPTkZJR19ORTJLX1BDSSBpcyBub3Qgc2V0DQojIENPTkZJR19ORTMyMTAg aXMgbm90IHNldA0KIyBDT05GSUdfRVMzMjEwIGlzIG5vdCBzZXQNCiMgQ09O RklHXzgxMzlDUCBpcyBub3Qgc2V0DQojIENPTkZJR184MTM5VE9PIGlzIG5v dCBzZXQNCiMgQ09ORklHXzgxMzlUT09fUElPIGlzIG5vdCBzZXQNCiMgQ09O RklHXzgxMzlUT09fVFVORV9UV0lTVEVSIGlzIG5vdCBzZXQNCiMgQ09ORklH XzgxMzlUT09fODEyOSBpcyBub3Qgc2V0DQojIENPTkZJR19TSVM5MDAgaXMg bm90IHNldA0KIyBDT05GSUdfRVBJQzEwMCBpcyBub3Qgc2V0DQojIENPTkZJ R19TVU5EQU5DRSBpcyBub3Qgc2V0DQojIENPTkZJR19UTEFOIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1ZJQV9SSElORSBpcyBub3Qgc2V0DQojIENPTkZJR19X SU5CT05EXzg0MCBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfUE9DS0VUIGlz IG5vdCBzZXQNCg0KIw0KIyBFdGhlcm5ldCAoMTAwMCBNYml0KQ0KIw0KIyBD T05GSUdfQUNFTklDIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RMMksgaXMgbm90 IHNldA0KIyBDT05GSUdfTVlSSV9TQlVTIGlzIG5vdCBzZXQNCiMgQ09ORklH X05TODM4MjAgaXMgbm90IHNldA0KIyBDT05GSUdfSEFNQUNISSBpcyBub3Qg c2V0DQojIENPTkZJR19ZRUxMT1dGSU4gaXMgbm90IHNldA0KIyBDT05GSUdf U0s5OExJTiBpcyBub3Qgc2V0DQojIENPTkZJR19GRERJIGlzIG5vdCBzZXQN CiMgQ09ORklHX0hJUFBJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BMSVAgaXMg bm90IHNldA0KQ09ORklHX1BQUD1tDQpDT05GSUdfUFBQX01VTFRJTElOSz15 DQpDT05GSUdfUFBQX0ZJTFRFUj15DQpDT05GSUdfUFBQX0FTWU5DPW0NCkNP TkZJR19QUFBfU1lOQ19UVFk9bQ0KQ09ORklHX1BQUF9ERUZMQVRFPW0NCkNP TkZJR19QUFBfQlNEQ09NUD1tDQpDT05GSUdfUFBQT0U9bQ0KIyBDT05GSUdf U0xJUCBpcyBub3Qgc2V0DQoNCiMNCiMgV2lyZWxlc3MgTEFOIChub24taGFt cmFkaW8pDQojDQojIENPTkZJR19ORVRfUkFESU8gaXMgbm90IHNldA0KDQoj DQojIFRva2VuIFJpbmcgZGV2aWNlcw0KIw0KIyBDT05GSUdfVFIgaXMgbm90 IHNldA0KIyBDT05GSUdfTkVUX0ZDIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JD UENJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NIQVBFUiBpcyBub3Qgc2V0DQoN CiMNCiMgV2FuIGludGVyZmFjZXMNCiMNCiMgQ09ORklHX1dBTiBpcyBub3Qg c2V0DQoNCiMNCiMgQW1hdGV1ciBSYWRpbyBzdXBwb3J0DQojDQojIENPTkZJ R19IQU1SQURJTyBpcyBub3Qgc2V0DQoNCiMNCiMgSXJEQSAoaW5mcmFyZWQp IHN1cHBvcnQNCiMNCiMgQ09ORklHX0lSREEgaXMgbm90IHNldA0KDQojDQoj IElTRE4gc3Vic3lzdGVtDQojDQojIENPTkZJR19JU0ROIGlzIG5vdCBzZXQN Cg0KIw0KIyBPbGQgQ0QtUk9NIGRyaXZlcnMgKG5vdCBTQ1NJLCBub3QgSURF KQ0KIw0KIyBDT05GSUdfQ0RfTk9fSURFU0NTSSBpcyBub3Qgc2V0DQoNCiMN CiMgSW5wdXQgY29yZSBzdXBwb3J0DQojDQpDT05GSUdfSU5QVVQ9bQ0KQ09O RklHX0lOUFVUX0tFWUJERVY9bQ0KQ09ORklHX0lOUFVUX01PVVNFREVWPW0N CkNPTkZJR19JTlBVVF9NT1VTRURFVl9TQ1JFRU5fWD0xMDI0DQpDT05GSUdf SU5QVVRfTU9VU0VERVZfU0NSRUVOX1k9NzY4DQpDT05GSUdfSU5QVVRfSk9Z REVWPW0NCkNPTkZJR19JTlBVVF9FVkRFVj1tDQoNCiMNCiMgQ2hhcmFjdGVy IGRldmljZXMNCiMNCkNPTkZJR19WVD15DQpDT05GSUdfVlRfQ09OU09MRT15 DQpDT05GSUdfU0VSSUFMPXkNCkNPTkZJR19TRVJJQUxfQ09OU09MRT15DQoj IENPTkZJR19TRVJJQUxfRVhURU5ERUQgaXMgbm90IHNldA0KIyBDT05GSUdf U0VSSUFMX05PTlNUQU5EQVJEIGlzIG5vdCBzZXQNCkNPTkZJR19VTklYOThf UFRZUz15DQpDT05GSUdfVU5JWDk4X1BUWV9DT1VOVD01MTINCkNPTkZJR19Q UklOVEVSPW0NCiMgQ09ORklHX0xQX0NPTlNPTEUgaXMgbm90IHNldA0KIyBD T05GSUdfUFBERVYgaXMgbm90IHNldA0KDQojDQojIEkyQyBzdXBwb3J0DQoj DQpDT05GSUdfSTJDPW0NCkNPTkZJR19JMkNfQUxHT0JJVD1tDQpDT05GSUdf STJDX1BISUxJUFNQQVI9bQ0KQ09ORklHX0kyQ19FTFY9bQ0KQ09ORklHX0ky Q19WRUxMRU1BTj1tDQpDT05GSUdfSTJDX0FMR09QQ0Y9bQ0KQ09ORklHX0ky Q19FTEVLVE9SPW0NCkNPTkZJR19JMkNfQ0hBUkRFVj1tDQpDT05GSUdfSTJD X1BST0M9bQ0KDQojDQojIE1pY2UNCiMNCiMgQ09ORklHX0JVU01PVVNFIGlz IG5vdCBzZXQNCkNPTkZJR19NT1VTRT1tDQpDT05GSUdfUFNNT1VTRT15DQoj IENPTkZJR184MkM3MTBfTU9VU0UgaXMgbm90IHNldA0KIyBDT05GSUdfUEMx MTBfUEFEIGlzIG5vdCBzZXQNCg0KIw0KIyBKb3lzdGlja3MNCiMNCkNPTkZJ R19JTlBVVF9HQU1FUE9SVD1tDQpDT05GSUdfSU5QVVRfTlM1NTg9bQ0KQ09O RklHX0lOUFVUX0xJR0hUTklORz1tDQpDT05GSUdfSU5QVVRfUENJR0FNRT1t DQpDT05GSUdfSU5QVVRfQ1M0NjFYPW0NCkNPTkZJR19JTlBVVF9FTVUxMEsx PW0NCkNPTkZJR19JTlBVVF9TRVJJTz1tDQpDT05GSUdfSU5QVVRfU0VSUE9S VD1tDQpDT05GSUdfSU5QVVRfQU5BTE9HPW0NCkNPTkZJR19JTlBVVF9BM0Q9 bQ0KQ09ORklHX0lOUFVUX0FEST1tDQpDT05GSUdfSU5QVVRfQ09CUkE9bQ0K Q09ORklHX0lOUFVUX0dGMks9bQ0KQ09ORklHX0lOUFVUX0dSSVA9bQ0KQ09O RklHX0lOUFVUX0lOVEVSQUNUPW0NCkNPTkZJR19JTlBVVF9UTURDPW0NCkNP TkZJR19JTlBVVF9TSURFV0lOREVSPW0NCkNPTkZJR19JTlBVVF9JRk9SQ0Vf VVNCPW0NCkNPTkZJR19JTlBVVF9JRk9SQ0VfMjMyPW0NCkNPTkZJR19JTlBV VF9XQVJSSU9SPW0NCkNPTkZJR19JTlBVVF9NQUdFTExBTj1tDQpDT05GSUdf SU5QVVRfU1BBQ0VPUkI9bQ0KQ09ORklHX0lOUFVUX1NQQUNFQkFMTD1tDQpD T05GSUdfSU5QVVRfU1RJTkdFUj1tDQpDT05GSUdfSU5QVVRfREI5PW0NCkNP TkZJR19JTlBVVF9HQU1FQ09OPW0NCkNPTkZJR19JTlBVVF9UVVJCT0dSQUZY PW0NCiMgQ09ORklHX1FJQzAyX1RBUEUgaXMgbm90IHNldA0KDQojDQojIFdh dGNoZG9nIENhcmRzDQojDQojIENPTkZJR19XQVRDSERPRyBpcyBub3Qgc2V0 DQojIENPTkZJR19JTlRFTF9STkcgaXMgbm90IHNldA0KIyBDT05GSUdfTlZS QU0gaXMgbm90IHNldA0KQ09ORklHX1JUQz15DQojIENPTkZJR19EVExLIGlz IG5vdCBzZXQNCiMgQ09ORklHX1IzOTY0IGlzIG5vdCBzZXQNCiMgQ09ORklH X0FQUExJQ09NIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NPTllQSSBpcyBub3Qg c2V0DQoNCiMNCiMgRnRhcGUsIHRoZSBmbG9wcHkgdGFwZSBkZXZpY2UgZHJp dmVyDQojDQojIENPTkZJR19GVEFQRSBpcyBub3Qgc2V0DQpDT05GSUdfQUdQ PW0NCkNPTkZJR19BR1BfSU5URUw9eQ0KIyBDT05GSUdfQUdQX0k4MTAgaXMg bm90IHNldA0KIyBDT05GSUdfQUdQX1ZJQSBpcyBub3Qgc2V0DQojIENPTkZJ R19BR1BfQU1EIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FHUF9TSVMgaXMgbm90 IHNldA0KIyBDT05GSUdfQUdQX0FMSSBpcyBub3Qgc2V0DQojIENPTkZJR19B R1BfU1dPUktTIGlzIG5vdCBzZXQNCkNPTkZJR19EUk09eQ0KQ09ORklHX0RS TV9UREZYPW0NCiMgQ09ORklHX0RSTV9HQU1NQSBpcyBub3Qgc2V0DQojIENP TkZJR19EUk1fUjEyOCBpcyBub3Qgc2V0DQpDT05GSUdfRFJNX1JBREVPTj1t DQojIENPTkZJR19EUk1fSTgxMCBpcyBub3Qgc2V0DQpDT05GSUdfRFJNX01H QT1tDQpDT05GSUdfTVdBVkU9bQ0KDQojDQojIE11bHRpbWVkaWEgZGV2aWNl cw0KIw0KQ09ORklHX1ZJREVPX0RFVj1tDQoNCiMNCiMgVmlkZW8gRm9yIExp bnV4DQojDQpDT05GSUdfVklERU9fUFJPQ19GUz15DQojIENPTkZJR19JMkNf UEFSUE9SVCBpcyBub3Qgc2V0DQpDT05GSUdfVklERU9fQlQ4NDg9bQ0KIyBD T05GSUdfVklERU9fUE1TIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX0JX UUNBTSBpcyBub3Qgc2V0DQojIENPTkZJR19WSURFT19DUUNBTSBpcyBub3Qg c2V0DQojIENPTkZJR19WSURFT19XOTk2NiBpcyBub3Qgc2V0DQojIENPTkZJ R19WSURFT19DUElBIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX1NBQTUy NDkgaXMgbm90IHNldA0KIyBDT05GSUdfVFVORVJfMzAzNiBpcyBub3Qgc2V0 DQojIENPTkZJR19WSURFT19TVFJBRElTIGlzIG5vdCBzZXQNCiMgQ09ORklH X1ZJREVPX1pPUkFOIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX1pSMzYx MjAgaXMgbm90IHNldA0KIyBDT05GSUdfVklERU9fTUVZRSBpcyBub3Qgc2V0 DQoNCiMNCiMgUmFkaW8gQWRhcHRlcnMNCiMNCiMgQ09ORklHX1JBRElPX0NB REVUIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JBRElPX1JUUkFDSyBpcyBub3Qg c2V0DQojIENPTkZJR19SQURJT19SVFJBQ0syIGlzIG5vdCBzZXQNCiMgQ09O RklHX1JBRElPX0FaVEVDSCBpcyBub3Qgc2V0DQojIENPTkZJR19SQURJT19H RU1URUsgaXMgbm90IHNldA0KIyBDT05GSUdfUkFESU9fR0VNVEVLX1BDSSBp cyBub3Qgc2V0DQojIENPTkZJR19SQURJT19NQVhJUkFESU8gaXMgbm90IHNl dA0KIyBDT05GSUdfUkFESU9fTUFFU1RSTyBpcyBub3Qgc2V0DQojIENPTkZJ R19SQURJT19NSVJPUENNMjAgaXMgbm90IHNldA0KIyBDT05GSUdfUkFESU9f TUlST1BDTTIwX1JEUyBpcyBub3Qgc2V0DQojIENPTkZJR19SQURJT19TRjE2 Rk1JIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JBRElPX1RFUlJBVEVDIGlzIG5v dCBzZXQNCiMgQ09ORklHX1JBRElPX1RSVVNUIGlzIG5vdCBzZXQNCiMgQ09O RklHX1JBRElPX1RZUEhPT04gaXMgbm90IHNldA0KIyBDT05GSUdfUkFESU9f Wk9MVFJJWCBpcyBub3Qgc2V0DQoNCiMNCiMgRmlsZSBzeXN0ZW1zDQojDQpD T05GSUdfUVVPVEE9eQ0KQ09ORklHX0ZTX1BPU0lYX0FDTD15DQpDT05GSUdf QVVUT0ZTX0ZTPW0NCkNPTkZJR19BVVRPRlM0X0ZTPW0NCiMgQ09ORklHX1JF SVNFUkZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JFSVNFUkZTX0NIRUNL IGlzIG5vdCBzZXQNCiMgQ09ORklHX0FERlNfRlMgaXMgbm90IHNldA0KIyBD T05GSUdfQURGU19GU19SVyBpcyBub3Qgc2V0DQojIENPTkZJR19BRkZTX0ZT IGlzIG5vdCBzZXQNCiMgQ09ORklHX0hGU19GUyBpcyBub3Qgc2V0DQojIENP TkZJR19CRlNfRlMgaXMgbm90IHNldA0KQ09ORklHX0ZBVF9GUz1tDQpDT05G SUdfTVNET1NfRlM9bQ0KIyBDT05GSUdfVU1TRE9TX0ZTIGlzIG5vdCBzZXQN CkNPTkZJR19WRkFUX0ZTPW0NCiMgQ09ORklHX0VGU19GUyBpcyBub3Qgc2V0 DQojIENPTkZJR19KRkZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0pGRlMy X0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NSQU1GUyBpcyBub3Qgc2V0DQpD T05GSUdfVE1QRlM9eQ0KIyBDT05GSUdfUkFNRlMgaXMgbm90IHNldA0KQ09O RklHX0lTTzk2NjBfRlM9bQ0KQ09ORklHX0pPTElFVD15DQpDT05GSUdfWklT T0ZTPXkNCiMgQ09ORklHX01JTklYX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklH X1ZYRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfTlRGU19GUyBpcyBub3Qg c2V0DQojIENPTkZJR19OVEZTX1JXIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hQ RlNfRlMgaXMgbm90IHNldA0KQ09ORklHX1BST0NfRlM9eQ0KIyBDT05GSUdf REVWRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfREVWRlNfTU9VTlQgaXMg bm90IHNldA0KIyBDT05GSUdfREVWRlNfREVCVUcgaXMgbm90IHNldA0KQ09O RklHX0RFVlBUU19GUz15DQojIENPTkZJR19RTlg0RlNfRlMgaXMgbm90IHNl dA0KIyBDT05GSUdfUU5YNEZTX1JXIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JP TUZTX0ZTIGlzIG5vdCBzZXQNCkNPTkZJR19FWFQyX0ZTPW0NCiMgQ09ORklH X1NZU1ZfRlMgaXMgbm90IHNldA0KQ09ORklHX1VERl9GUz1tDQpDT05GSUdf VURGX1JXPXkNCkNPTkZJR19VRlNfRlM9bQ0KIyBDT05GSUdfVUZTX0ZTX1dS SVRFIGlzIG5vdCBzZXQNCkNPTkZJR19QQUdFX0JVRj15DQpDT05GSUdfWEZT X0ZTPXkNCkNPTkZJR19YRlNfUlQ9eQ0KQ09ORklHX1hGU19RVU9UQT15DQpD T05GSUdfSEFWRV9BVFRSQ1RMPXkNCkNPTkZJR19YRlNfRE1BUEk9eQ0KDQoj DQojIE5ldHdvcmsgRmlsZSBTeXN0ZW1zDQojDQpDT05GSUdfQ09EQV9GUz1t DQpDT05GSUdfTkZTX0ZTPW0NCkNPTkZJR19ORlNfVjM9eQ0KIyBDT05GSUdf Uk9PVF9ORlMgaXMgbm90IHNldA0KQ09ORklHX05GU0Q9bQ0KQ09ORklHX05G U0RfVjM9eQ0KQ09ORklHX1NVTlJQQz1tDQpDT05GSUdfTE9DS0Q9bQ0KQ09O RklHX0xPQ0tEX1Y0PXkNCkNPTkZJR19TTUJfRlM9bQ0KIyBDT05GSUdfU01C X05MU19ERUZBVUxUIGlzIG5vdCBzZXQNCkNPTkZJR19OQ1BfRlM9bQ0KQ09O RklHX05DUEZTX1BBQ0tFVF9TSUdOSU5HPXkNCkNPTkZJR19OQ1BGU19JT0NU TF9MT0NLSU5HPXkNCkNPTkZJR19OQ1BGU19TVFJPTkc9eQ0KQ09ORklHX05D UEZTX05GU19OUz15DQpDT05GSUdfTkNQRlNfT1MyX05TPXkNCkNPTkZJR19O Q1BGU19TTUFMTERPUz15DQpDT05GSUdfTkNQRlNfTkxTPXkNCkNPTkZJR19O Q1BGU19FWFRSQVM9eQ0KQ09ORklHX1pJU09GU19GUz1tDQpDT05GSUdfWkxJ Ql9GU19JTkZMQVRFPW0NCg0KIw0KIyBQYXJ0aXRpb24gVHlwZXMNCiMNCiMg Q09ORklHX1BBUlRJVElPTl9BRFZBTkNFRCBpcyBub3Qgc2V0DQpDT05GSUdf TVNET1NfUEFSVElUSU9OPXkNCkNPTkZJR19TTUJfTkxTPXkNCkNPTkZJR19O TFM9eQ0KDQojDQojIE5hdGl2ZSBMYW5ndWFnZSBTdXBwb3J0DQojDQpDT05G SUdfTkxTX0RFRkFVTFQ9Imlzbzg4NTktMSINCkNPTkZJR19OTFNfQ09ERVBB R0VfNDM3PW0NCiMgQ09ORklHX05MU19DT0RFUEFHRV83MzcgaXMgbm90IHNl dA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzc3NSBpcyBub3Qgc2V0DQojIENP TkZJR19OTFNfQ09ERVBBR0VfODUwIGlzIG5vdCBzZXQNCiMgQ09ORklHX05M U19DT0RFUEFHRV84NTIgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQ QUdFXzg1NSBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODU3 IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV84NjAgaXMgbm90 IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MSBpcyBub3Qgc2V0DQoj IENPTkZJR19OTFNfQ09ERVBBR0VfODYyIGlzIG5vdCBzZXQNCiMgQ09ORklH X05MU19DT0RFUEFHRV84NjMgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NP REVQQUdFXzg2NCBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0Vf ODY1IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV84NjYgaXMg bm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2OSBpcyBub3Qgc2V0 DQojIENPTkZJR19OTFNfQ09ERVBBR0VfOTM2IGlzIG5vdCBzZXQNCiMgQ09O RklHX05MU19DT0RFUEFHRV85NTAgaXMgbm90IHNldA0KIyBDT05GSUdfTkxT X0NPREVQQUdFXzkzMiBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBB R0VfOTQ5IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV84NzQg aXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfOCBpcyBub3Qgc2V0 DQojIENPTkZJR19OTFNfQ09ERVBBR0VfMTI1MSBpcyBub3Qgc2V0DQpDT05G SUdfTkxTX0lTTzg4NTlfMT1tDQojIENPTkZJR19OTFNfSVNPODg1OV8yIGlz IG5vdCBzZXQNCiMgQ09ORklHX05MU19JU084ODU5XzMgaXMgbm90IHNldA0K IyBDT05GSUdfTkxTX0lTTzg4NTlfNCBpcyBub3Qgc2V0DQojIENPTkZJR19O TFNfSVNPODg1OV81IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19JU084ODU5 XzYgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfNyBpcyBub3Qg c2V0DQojIENPTkZJR19OTFNfSVNPODg1OV85IGlzIG5vdCBzZXQNCiMgQ09O RklHX05MU19JU084ODU5XzEzIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19J U084ODU5XzE0IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19JU084ODU5XzE1 IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19LT0k4X1IgaXMgbm90IHNldA0K IyBDT05GSUdfTkxTX0tPSThfVSBpcyBub3Qgc2V0DQpDT05GSUdfTkxTX1VU Rjg9bQ0KDQojDQojIENvbnNvbGUgZHJpdmVycw0KIw0KQ09ORklHX1ZHQV9D T05TT0xFPXkNCkNPTkZJR19WSURFT19TRUxFQ1Q9eQ0KIyBDT05GSUdfTURB X0NPTlNPTEUgaXMgbm90IHNldA0KDQojDQojIEZyYW1lLWJ1ZmZlciBzdXBw b3J0DQojDQojIENPTkZJR19GQiBpcyBub3Qgc2V0DQoNCiMNCiMgU291bmQN CiMNCkNPTkZJR19TT1VORD1tDQpDT05GSUdfU09VTkRfQlQ4Nzg9bQ0KIyBD T05GSUdfU09VTkRfQ01QQ0kgaXMgbm90IHNldA0KIyBDT05GSUdfU09VTkRf RU1VMTBLMSBpcyBub3Qgc2V0DQojIENPTkZJR19NSURJX0VNVTEwSzEgaXMg bm90IHNldA0KIyBDT05GSUdfU09VTkRfRlVTSU9OIGlzIG5vdCBzZXQNCiMg Q09ORklHX1NPVU5EX0NTNDI4MSBpcyBub3Qgc2V0DQpDT05GSUdfU09VTkRf RVMxMzcwPW0NCkNPTkZJR19TT1VORF9FUzEzNzE9bQ0KIyBDT05GSUdfU09V TkRfRVNTU09MTzEgaXMgbm90IHNldA0KIyBDT05GSUdfU09VTkRfTUFFU1RS TyBpcyBub3Qgc2V0DQojIENPTkZJR19TT1VORF9NQUVTVFJPMyBpcyBub3Qg c2V0DQojIENPTkZJR19TT1VORF9JQ0ggaXMgbm90IHNldA0KIyBDT05GSUdf U09VTkRfUk1FOTZYWCBpcyBub3Qgc2V0DQojIENPTkZJR19TT1VORF9TT05J Q1ZJQkVTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NPVU5EX1RSSURFTlQgaXMg bm90IHNldA0KIyBDT05GSUdfU09VTkRfTVNORENMQVMgaXMgbm90IHNldA0K IyBDT05GSUdfU09VTkRfTVNORFBJTiBpcyBub3Qgc2V0DQojIENPTkZJR19T T1VORF9WSUE4MkNYWFggaXMgbm90IHNldA0KIyBDT05GSUdfTUlESV9WSUE4 MkNYWFggaXMgbm90IHNldA0KIyBDT05GSUdfU09VTkRfT1NTIGlzIG5vdCBz ZXQNCkNPTkZJR19TT1VORF9UVk1JWEVSPW0NCg0KIw0KIyBVU0Igc3VwcG9y dA0KIw0KQ09ORklHX1VTQj1tDQojIENPTkZJR19VU0JfREVCVUcgaXMgbm90 IHNldA0KQ09ORklHX1VTQl9ERVZJQ0VGUz15DQpDT05GSUdfVVNCX0JBTkRX SURUSD15DQpDT05GSUdfVVNCX0xPTkdfVElNRU9VVD15DQpDT05GSUdfVVNC X1VIQ0k9bQ0KIyBDT05GSUdfVVNCX1VIQ0lfQUxUIGlzIG5vdCBzZXQNCiMg Q09ORklHX1VTQl9PSENJIGlzIG5vdCBzZXQNCkNPTkZJR19VU0JfQVVESU89 bQ0KQ09ORklHX1VTQl9CTFVFVE9PVEg9bQ0KQ09ORklHX1VTQl9TVE9SQUdF PW0NCiMgQ09ORklHX1VTQl9TVE9SQUdFX0RFQlVHIGlzIG5vdCBzZXQNCkNP TkZJR19VU0JfU1RPUkFHRV9EQVRBRkFCPXkNCkNPTkZJR19VU0JfU1RPUkFH RV9GUkVFQ09NPXkNCkNPTkZJR19VU0JfU1RPUkFHRV9JU0QyMDA9eQ0KQ09O RklHX1VTQl9TVE9SQUdFX0RQQ009eQ0KQ09ORklHX1VTQl9TVE9SQUdFX0hQ ODIwMGU9eQ0KQ09ORklHX1VTQl9TVE9SQUdFX1NERFIwOT15DQpDT05GSUdf VVNCX1NUT1JBR0VfSlVNUFNIT1Q9eQ0KQ09ORklHX1VTQl9BQ009bQ0KQ09O RklHX1VTQl9QUklOVEVSPW0NCkNPTkZJR19VU0JfSElEPW0NCkNPTkZJR19V U0JfSElEREVWPXkNCkNPTkZJR19VU0JfS0JEPW0NCkNPTkZJR19VU0JfTU9V U0U9bQ0KQ09ORklHX1VTQl9XQUNPTT1tDQpDT05GSUdfVVNCX0RDMlhYPW0N CkNPTkZJR19VU0JfTURDODAwPW0NCkNPTkZJR19VU0JfU0NBTk5FUj1tDQpD T05GSUdfVVNCX01JQ1JPVEVLPW0NCkNPTkZJR19VU0JfSFBVU0JTQ1NJPW0N CkNPTkZJR19VU0JfSUJNQ0FNPW0NCkNPTkZJR19VU0JfT1Y1MTE9bQ0KQ09O RklHX1VTQl9QV0M9bQ0KQ09ORklHX1VTQl9TRTQwMT1tDQpDT05GSUdfVVNC X0RTQlI9bQ0KQ09ORklHX1VTQl9EQUJVU0I9bQ0KIyBDT05GSUdfVVNCX1BF R0FTVVMgaXMgbm90IHNldA0KQ09ORklHX1VTQl9LQVdFVEg9bQ0KQ09ORklH X1VTQl9DQVRDPW0NCkNPTkZJR19VU0JfQ0RDRVRIRVI9bQ0KQ09ORklHX1VT Ql9VU0JORVQ9bQ0KQ09ORklHX1VTQl9VU1M3MjA9bQ0KDQojDQojIFVTQiBT ZXJpYWwgQ29udmVydGVyIHN1cHBvcnQNCiMNCiMgQ09ORklHX1VTQl9TRVJJ QUwgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NFUklBTF9HRU5FUklDIGlz IG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TRVJJQUxfQkVMS0lOIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1VTQl9TRVJJQUxfV0hJVEVIRUFUIGlzIG5vdCBzZXQN CiMgQ09ORklHX1VTQl9TRVJJQUxfRElHSV9BQ0NFTEVQT1JUIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1VTQl9TRVJJQUxfRU1QRUcgaXMgbm90IHNldA0KIyBD T05GSUdfVVNCX1NFUklBTF9GVERJX1NJTyBpcyBub3Qgc2V0DQojIENPTkZJ R19VU0JfU0VSSUFMX1ZJU09SIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9T RVJJQUxfSVIgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NFUklBTF9FREdF UE9SVCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VSSUFMX0tFWVNQQU5f UERBIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TRVJJQUxfS0VZU1BBTiBp cyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VSSUFMX0tFWVNQQU5fVVNBMjgg aXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NFUklBTF9LRVlTUEFOX1VTQTI4 WCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VSSUFMX0tFWVNQQU5fVVNB MjhYQSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VSSUFMX0tFWVNQQU5f VVNBMjhYQiBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VSSUFMX0tFWVNQ QU5fVVNBMTkgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NFUklBTF9LRVlT UEFOX1VTQTE4WCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VSSUFMX0tF WVNQQU5fVVNBMTlXIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TRVJJQUxf S0VZU1BBTl9VU0E0OVcgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NFUklB TF9NQ1RfVTIzMiBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VSSUFMX1BM MjMwMyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VSSUFMX0NZQkVSSkFD SyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VSSUFMX1hJUkNPTSBpcyBu b3Qgc2V0DQojIENPTkZJR19VU0JfU0VSSUFMX09NTklORVQgaXMgbm90IHNl dA0KQ09ORklHX1VTQl9SSU81MDA9bQ0KDQojDQojIEJsdWV0b290aCBzdXBw b3J0DQojDQpDT05GSUdfQkxVRVo9bQ0KQ09ORklHX0JMVUVaX0wyQ0FQPW0N Cg0KIw0KIyBCbHVldG9vdGggZGV2aWNlIGRyaXZlcnMNCiMNCkNPTkZJR19C TFVFWl9IQ0lVU0I9bQ0KQ09ORklHX0JMVUVaX0hDSVVBUlQ9bQ0KQ09ORklH X0JMVUVaX0hDSVZIQ0k9bQ0KDQojDQojIEtlcm5lbCBoYWNraW5nDQojDQpD T05GSUdfREVCVUdfS0VSTkVMPXkNCiMgQ09ORklHX0RFQlVHX0hJR0hNRU0g aXMgbm90IHNldA0KIyBDT05GSUdfREVCVUdfU0xBQiBpcyBub3Qgc2V0DQoj IENPTkZJR19ERUJVR19JT1ZJUlQgaXMgbm90IHNldA0KQ09ORklHX01BR0lD X1NZU1JRPXkNCiMgQ09ORklHX0RFQlVHX1NQSU5MT0NLIGlzIG5vdCBzZXQN CiMgQ09ORklHX0RFQlVHX0JVR1ZFUkJPU0UgaXMgbm90IHNldA0KQ09ORklH X0tEQj15DQpDT05GSUdfS0RCX01PRFVMRVM9bQ0KQ09ORklHX0tEQl9PRkY9 eQ0KQ09ORklHX0tBTExTWU1TPXkNCiMgQ09ORklHX0ZSQU1FX1BPSU5URVIg aXMgbm90IHNldA0K ---559023410-851401618-1005308940=:23483 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="oops.output" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: a3N5bW9vcHMgMi40LjEgb24gaTY4NiAyLjQuMTQteGZzLiAgT3B0aW9ucyB1 c2VkDQogICAgIC1WIChkZWZhdWx0KQ0KICAgICAtayAvcHJvYy9rc3ltcyAo ZGVmYXVsdCkNCiAgICAgLWwgL3Byb2MvbW9kdWxlcyAoZGVmYXVsdCkNCiAg ICAgLW8gL2xpYi9tb2R1bGVzLzIuNC4xNC14ZnMvIChkZWZhdWx0KQ0KICAg ICAtbSAvdXNyL3NyYy9saW51eC9TeXN0ZW0ubWFwIChzcGVjaWZpZWQpDQoN Cldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCBw cm9jX3Njc2kgICwgc2NzaV9tb2Qgc2F5cyBkMDhhN2I2NCwgL2xpYi9tb2R1 bGVzLzIuNC4xNC14ZnMva2VybmVsL2RyaXZlcnMvc2NzaS9zY3NpX21vZC5v IHNheXMgZDA4YTc1YzguICBJZ25vcmluZyAvbGliL21vZHVsZXMvMi40LjE0 LXhmcy9rZXJuZWwvZHJpdmVycy9zY3NpL3Njc2lfbW9kLm8gZW50cnkNCldh cm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCBzY3Np X2RldmljZWxpc3QgICwgc2NzaV9tb2Qgc2F5cyBkMDhhN2I5MCwgL2xpYi9t b2R1bGVzLzIuNC4xNC14ZnMva2VybmVsL2RyaXZlcnMvc2NzaS9zY3NpX21v ZC5vIHNheXMgZDA4YTc1ZjQuICBJZ25vcmluZyAvbGliL21vZHVsZXMvMi40 LjE0LXhmcy9rZXJuZWwvZHJpdmVycy9zY3NpL3Njc2lfbW9kLm8gZW50cnkN Cldhcm5pbmcgKGNvbXBhcmVfbWFwcyk6IG1pc21hdGNoIG9uIHN5bWJvbCBz Y3NpX2hvc3RsaXN0ICAsIHNjc2lfbW9kIHNheXMgZDA4YTdiOGMsIC9saWIv bW9kdWxlcy8yLjQuMTQteGZzL2tlcm5lbC9kcml2ZXJzL3Njc2kvc2NzaV9t b2QubyBzYXlzIGQwOGE3NWYwLiAgSWdub3JpbmcgL2xpYi9tb2R1bGVzLzIu NC4xNC14ZnMva2VybmVsL2RyaXZlcnMvc2NzaS9zY3NpX21vZC5vIGVudHJ5 DQpXYXJuaW5nIChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wg c2NzaV9ob3N0cyAgLCBzY3NpX21vZCBzYXlzIGQwOGE3Yjk0LCAvbGliL21v ZHVsZXMvMi40LjE0LXhmcy9rZXJuZWwvZHJpdmVycy9zY3NpL3Njc2lfbW9k Lm8gc2F5cyBkMDhhNzVmOC4gIElnbm9yaW5nIC9saWIvbW9kdWxlcy8yLjQu MTQteGZzL2tlcm5lbC9kcml2ZXJzL3Njc2kvc2NzaV9tb2QubyBlbnRyeQ0K V2FybmluZyAoY29tcGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIG1k X3NpemUgICwgbWQgc2F5cyBkMDg3MzY4MCwgL2xpYi9tb2R1bGVzLzIuNC4x NC14ZnMva2VybmVsL2RyaXZlcnMvbWQvbWQubyBzYXlzIGQwODczNGEwLiAg SWdub3JpbmcgL2xpYi9tb2R1bGVzLzIuNC4xNC14ZnMva2VybmVsL2RyaXZl cnMvbWQvbWQubyBlbnRyeQ0KV2FybmluZyAoY29tcGFyZV9tYXBzKTogbWlz bWF0Y2ggb24gc3ltYm9sIG1kZGV2X21hcCAgLCBtZCBzYXlzIGQwODcyZTgw LCAvbGliL21vZHVsZXMvMi40LjE0LXhmcy9rZXJuZWwvZHJpdmVycy9tZC9t ZC5vIHNheXMgZDA4NzJjYTAuICBJZ25vcmluZyAvbGliL21vZHVsZXMvMi40 LjE0LXhmcy9rZXJuZWwvZHJpdmVycy9tZC9tZC5vIGVudHJ5DQpXYXJuaW5n IChjb21wYXJlX21hcHMpOiBtaXNtYXRjaCBvbiBzeW1ib2wgdXNiX2RldmZz X2hhbmRsZSAgLCB1c2Jjb3JlIHNheXMgZDA4MzQ2MzQsIC9saWIvbW9kdWxl cy8yLjQuMTQteGZzL2tlcm5lbC9kcml2ZXJzL3VzYi91c2Jjb3JlLm8gc2F5 cyBkMDgzNDBmNC4gIElnbm9yaW5nIC9saWIvbW9kdWxlcy8yLjQuMTQteGZz L2tlcm5lbC9kcml2ZXJzL3VzYi91c2Jjb3JlLm8gZW50cnkNClJlYWRpbmcg T29wcyByZXBvcnQgZnJvbSB0aGUgdGVybWluYWwNClVuYWJsZSB0byBoYW5k bGUga2VybmVsIE5VTEwgcG9pbnRlciBkZXJlZmVyZW5jZSBhdCB2aXJ0dWFs IGFkZHJlc3MgMDAwMDAzMzANCmMwMWNmMmM0DQoqcGRlID0gMDAwMDAwMDAN Ck9vcHM6IDAwMDINCkNQVTogICAgMA0KRUlQOiAgICAwMDEwOls8YzAxY2Yy YzQ+XSAgICBOb3QgdGFpbnRlZA0KVXNpbmcgZGVmYXVsdHMgZnJvbSBrc3lt b29wcyAtdCBlbGYzMi1pMzg2IC1hIGkzODYNCkVGTEFHUzogMDAwMTAyMDIN CmVheDogMDAwMDAyMDAgICBlYng6IDAwMDAwMjAwICAgZWN4OiAwMDAwMDMx YyAgIGVkeDogMDAwMDAwMDANCmVzaTogMDAwMDAwMDEgICBlZGk6IDAwMDAw MDAwICAgZWJwOiAwMDAwMDAwMCAgIGVzcDogYzE0MjNlNTANCmRzOiAwMDE4 ICAgZXM6IDAwMTggICBzczogMDAxOA0KUHJvY2VzcyBrc3dhcGQgKHBpZDog NSwgc3RhY2twYWdlPWMxNDIzMDAwKQ0KU3RhY2s6IGMwMTZhY2ZiIDAwMDAw MzFjIGM0OGY2N2QwIGMwMTZlYjY3IDAwMDAwMjAwIGM0OGY2N2QwIGMwMWE2 M2MwIGM0OGY2N2QwIA0KICAgICAgIGM0OGY2N2QwIGMwMWMzMzc1IGM0OGY2 N2QwIGM0OGY2N2QwIGM0OGY3OTAwIDAwMDAwMDAwIGMwMWMzMjMyIGM0OGY2 N2QwIA0KICAgICAgIDAwMDAwMDAwIDAwMDAwMDAwIGM0OGY3OTAwIDAwMDAw MDAwIGM0OGY3OTAwIGM0OGY3OTE4IGMwMWNkZTQxIGM0OGY2N2U4IA0KQ2Fs bCBUcmFjZTogWzxjMDE2YWNmYj5dIFs8YzAxNmViNjc+XSBbPGMwMWE2M2Mw Pl0gWzxjMDFjMzM3NT5dIFs8YzAxYzMyMzI+XSANCiAgIFs8YzAxY2RlNDE+ XSBbPGMwMWNlMmM2Pl0gWzxjMDFjZTQwYz5dIFs8YzAxY2Q1Y2E+XSBbPGMw MTQ5NDY1Pl0gWzxjMDE0ODg0Zj5dIA0KICAgWzxjMDE0OTRmMD5dIFs8YzAx NDk3NTA+XSBbPGMwMTQ5NzkwPl0gWzxjMDEyZjczZT5dIFs8YzAxMmY3OGM+ XSBbPGMwMTJmODMxPl0gDQogICBbPGMwMTJmOGE2Pl0gWzxjMDEyZjllMT5d IFs8YzAxMmY5NDA+XSBbPGMwMTA1MDAwPl0gWzxjMDEwNTYxNj5dIFs8YzAx MmY5NDA+XSANCkNvZGU6IGZmIDQ5IDE0IGYwIGZmIDA5IDBmIDg4IDNiIDhh IDA5IDAwIGMzIGViIDBkIDkwIDkwIDkwIDkwIDkwIA0KDQo+PkVJUDsgYzAx Y2YyYzQgPF9tdXRleF9sb2NrKzQvMjA+ICAgPD09PT09DQpUcmFjZTsgYzAx NmFjZmIgPHhmc19xbV9kcXJlbGUrYi8yMD4NClRyYWNlOyBjMDE2ZWI2NyA8 eGZzX3FtX2RxZGV0dGFjaF9pbm9kZSsyNy80MD4NClRyYWNlOyBjMDFhNjNj MCA8eGZzX2lyZWNsYWltKzMwLzcwPg0KVHJhY2U7IGMwMWMzMzc1IDx4ZnNf ZmluaXNoX3JlY2xhaW0rMTE1LzEyMD4NClRyYWNlOyBjMDFjMzIzMiA8eGZz X3JlY2xhaW0rMWMyLzFmMD4NClRyYWNlOyBjMDFjZGU0MSA8dm5fcmVjbGFp bSsyMS82MD4NClRyYWNlOyBjMDFjZTJjNiA8dm5fcHVyZ2UrYTYvZDA+DQpU cmFjZTsgYzAxY2U0MGMgPHZuX3JlbW92ZSszYy81MD4NClRyYWNlOyBjMDFj ZDVjYSA8bGludmZzX2NsZWFyX2lub2RlK2EvMzA+DQpUcmFjZTsgYzAxNDk0 NjUgPGNsZWFyX2lub2RlK2I1LzEwMD4NClRyYWNlOyBjMDE0ODg0ZiA8ZGVz dHJveV9pbm9kZSsxZi8zMD4NClRyYWNlOyBjMDE0OTRmMCA8ZGlzcG9zZV9s aXN0KzQwLzYwPg0KVHJhY2U7IGMwMTQ5NzUwIDxwcnVuZV9pY2FjaGUrYzAv ZTA+DQpUcmFjZTsgYzAxNDk3OTAgPHNocmlua19pY2FjaGVfbWVtb3J5KzIw LzQwPg0KVHJhY2U7IGMwMTJmNzNlIDxzaHJpbmtfY2FjaGVzKzZlLzkwPg0K VHJhY2U7IGMwMTJmNzhjIDx0cnlfdG9fZnJlZV9wYWdlcysyYy81MD4NClRy YWNlOyBjMDEyZjgzMSA8a3N3YXBkX2JhbGFuY2VfcGdkYXQrNTEvYTA+DQpU cmFjZTsgYzAxMmY4YTYgPGtzd2FwZF9iYWxhbmNlKzI2LzQwPg0KVHJhY2U7 IGMwMTJmOWUxIDxrc3dhcGQrYTEvYzA+DQpUcmFjZTsgYzAxMmY5NDAgPGtz d2FwZCswL2MwPg0KVHJhY2U7IGMwMTA1MDAwIDxfc3RleHQrMC8wPg0KVHJh Y2U7IGMwMTA1NjE2IDxrZXJuZWxfdGhyZWFkKzI2LzMwPg0KVHJhY2U7IGMw MTJmOTQwIDxrc3dhcGQrMC9jMD4NCkNvZGU7ICBjMDFjZjJjNCA8X211dGV4 X2xvY2srNC8yMD4NCjAwMDAwMDAwIDxfRUlQPjoNCkNvZGU7ICBjMDFjZjJj NCA8X211dGV4X2xvY2srNC8yMD4gICA8PT09PT0NCiAgIDA6ICAgZmYgNDkg MTQgICAgICAgICAgICAgICAgICBkZWNsICAgMHgxNCglZWN4KSAgIDw9PT09 PQ0KQ29kZTsgIGMwMWNmMmM3IDxfbXV0ZXhfbG9jays3LzIwPg0KICAgMzog ICBmMCBmZiAwOSAgICAgICAgICAgICAgICAgIGxvY2sgZGVjbCAoJWVjeCkN CkNvZGU7ICBjMDFjZjJjYSA8X211dGV4X2xvY2srYS8yMD4NCiAgIDY6ICAg MGYgODggM2IgOGEgMDkgMDAgICAgICAgICBqcyAgICAgOThhNDcgPF9FSVAr MHg5OGE0Nz4gYzAyNjdkMGIgPHN0ZXh0X2xvY2srNDRkNy83NzU0Pg0KQ29k ZTsgIGMwMWNmMmQwIDxfbXV0ZXhfbG9jaysxMC8yMD4NCiAgIGM6ICAgYzMg ICAgICAgICAgICAgICAgICAgICAgICByZXQgICAgDQpDb2RlOyAgYzAxY2Yy ZDEgPF9tdXRleF9sb2NrKzExLzIwPg0KICAgZDogICBlYiAwZCAgICAgICAg ICAgICAgICAgICAgIGptcCAgICAxYyA8X0VJUCsweDFjPiBjMDFjZjJlMCA8 X211dGV4X3VubG9jayswLzIwPg0KQ29kZTsgIGMwMWNmMmQzIDxfbXV0ZXhf bG9jaysxMy8yMD4NCiAgIGY6ICAgOTAgICAgICAgICAgICAgICAgICAgICAg ICBub3AgICAgDQpDb2RlOyAgYzAxY2YyZDQgPF9tdXRleF9sb2NrKzE0LzIw Pg0KICAxMDogICA5MCAgICAgICAgICAgICAgICAgICAgICAgIG5vcCAgICAN CkNvZGU7ICBjMDFjZjJkNSA8X211dGV4X2xvY2srMTUvMjA+DQogIDExOiAg IDkwICAgICAgICAgICAgICAgICAgICAgICAgbm9wICAgIA0KQ29kZTsgIGMw MWNmMmQ2IDxfbXV0ZXhfbG9jaysxNi8yMD4NCiAgMTI6ICAgOTAgICAgICAg ICAgICAgICAgICAgICAgICBub3AgICAgDQpDb2RlOyAgYzAxY2YyZDcgPF9t dXRleF9sb2NrKzE3LzIwPg0KICAxMzogICA5MCAgICAgICAgICAgICAgICAg ICAgICAgIG5vcCAgICANCg0KDQo3IHdhcm5pbmdzIGlzc3VlZC4gIFJlc3Vs dHMgbWF5IG5vdCBiZSByZWxpYWJsZS4NCg== ---559023410-851401618-1005308940=:23483-- From owner-linux-xfs@oss.sgi.com Fri Nov 9 04:49:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9Cnpu03933 for linux-xfs-outgoing; Fri, 9 Nov 2001 04:49:51 -0800 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 fA9Cnk003910 for ; Fri, 9 Nov 2001 04:49:46 -0800 Received: from vie-ac.office.ecetra.com (vie-ac.office.ecetra.com [10.251.148.148] (may be forged)) by msg.ecetra.com (8.9.3/8.9.3) with ESMTP id NAA27649; Fri, 9 Nov 2001 13:49:37 +0100 Received: from localhost (localhost [127.0.0.1]) by vie-ac.office.ecetra.com (8.12.1/8.12.1) with ESMTP id fA9CnbUo012665; Fri, 9 Nov 2001 13:49:37 +0100 Date: Fri, 9 Nov 2001 13:49:37 +0100 (CET) From: Adam Cioccarelli To: Anuradha Ratnaweera cc: linux-xfs@oss.sgi.com Subject: Re: XFS and preemptive kernel patch In-Reply-To: <20011109151218.A5600@bee.lk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Anuradha, I've used it on 2.4.10-xfs and now on 2.4.14-xfs without any problems at all. Although I haven't run any tests to see if there is any improvement... ------------------------------------------------------------------------------- Adam Cioccarelli (B.E Mechanical) Adam.Cioccarelli@ecetra.com Database Administrator Phone: +43 1 536 89 17725 Fax: +43 1 536 89 17719 ecetra Central European e-Finance AG Mobile:+43 664 181 4195 ------------------------------------------------------------------------------- On Fri, 9 Nov 2001, Anuradha Ratnaweera wrote: > > Is anybody using XFS with preemptive kernel patch? Since I don't have > any "non-production" machines to do a test, any feedback would be very > useful. > > Thanks. > > Regards, > > Anuradha > > -- > > Debian GNU/Linux (kernel 2.4.14) > > Fools ignore complexity. Pragmatists suffer it. > Some can avoid it. Geniuses remove it. > -- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982 > From owner-linux-xfs@oss.sgi.com Fri Nov 9 05:14:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9DErZ04657 for linux-xfs-outgoing; Fri, 9 Nov 2001 05:14:53 -0800 Received: from casbah.gatech.edu (IDENT:root@casbah.gatech.edu [130.207.165.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9DEm004635 for ; Fri, 9 Nov 2001 05:14:48 -0800 Received: from ransom ([130.207.197.237]) by casbah.gatech.edu (8.9.2/8.9.2) with ESMTP id IAA12962; Fri, 9 Nov 2001 08:14:46 -0500 (EST) Subject: Re: XFS and preemptive kernel patch From: Rob Myers To: Anuradha Ratnaweera Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011109151218.A5600@bee.lk> References: <20011109151218.A5600@bee.lk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.07.16.47 (Preview Release) Date: 09 Nov 2001 08:16:11 -0500 Message-Id: <1005311801.28412.0.camel@ransom> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk anuradha- the preemptive kernel patch works great with kernel 2.4.14-xfs on my workstation. i would not hesitate to use it on any other workstation. rob. On Fri, 2001-11-09 at 04:12, Anuradha Ratnaweera wrote: > > Is anybody using XFS with preemptive kernel patch? Since I don't have > any "non-production" machines to do a test, any feedback would be very > useful. > > Thanks. > > Regards, > > Anuradha > > -- > > Debian GNU/Linux (kernel 2.4.14) > > Fools ignore complexity. Pragmatists suffer it. > Some can avoid it. Geniuses remove it. > -- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982 From owner-linux-xfs@oss.sgi.com Fri Nov 9 05:46:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9DkfX05220 for linux-xfs-outgoing; Fri, 9 Nov 2001 05:46:41 -0800 Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9DkY005198 for ; Fri, 9 Nov 2001 05:46:34 -0800 Received: (cpmta 13555 invoked from network); 9 Nov 2001 05:46:27 -0800 Received: from 207.207.51.226 (HELO ?192.168.1.50?) by smtp.tooley.com (209.228.32.71) with SMTP; 9 Nov 2001 05:46:27 -0800 X-Sent: 9 Nov 2001 13:46:27 GMT Subject: Re: Undelete in XFS From: Chris Tooley To: linux-xfs@oss.sgi.com In-Reply-To: <3BEB1829.5F5C3D2@idcomm.com> References: <1005258455.4701.4.camel@itspec.amoa.org> <1005258497.9075.22.camel@jen.americas.sgi.com> <1005259546.5742.9.camel@itspec.amoa.org> <1005261542.9077.29.camel@jen.americas.sgi.com> <3BEB1829.5F5C3D2@idcomm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.100+cvs.2001.11.02.08.57 (Preview Release) Date: 09 Nov 2001 07:45:43 -0600 Message-Id: <1005313547.6876.7.camel@itspec.amoa.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2001-11-08 at 17:41, owner-linux-xfs@oss.sgi.com wrote: > Steve Lord wrote: > > > > On Thu, 2001-11-08 at 16:45, Chris Tooley wrote: > > > Wish I could file an evolution bug and blame it on someone else, but my > > > problem is my own stupidity trying to make space on my harddrive. BTW > > > what is the status of being able to move the start point of a > > > partition? I can't do a dump and restore on my workstation and really > > > need to add some space to this partition. However, I'm at the end of > > > the disk. > > > > > > > > > > Which I think translates into shrinking a filesystem. > > > > The answer to that question is also xfsdump/mkfs/xfsrestore, the > > xfs disk structures are a little complex to shrink. > > > > Steve > > > > p.s. > > > > Disk drives are really cheap now, I have a spare 20Gbyte 7200 rpm IBM > > IDE drive sitting on a shelf in my office, it cost about $100. > > I installed a scratch 20 Gb cheap-o into a removeable tray, and have the > tray on a couple of computers. Makes a wonderful floppy. Just make sure > it is formatted as an extended/logical partition, primaries tend to > confuse some more stupid o/s's when the partitions get added and > removed. I highly recommend a removeable tray scratch IDE drive. > You can actually find some of these bays that are for IDE drives and are "Hot Swap". I saw one that basically had a PCMCIA controller card and then had a cable to make the disk appear to be a PCMCIA Hard Disk. I think this had size limits though I'm not sure. Alternatively you could reboot, but who wants to reboot a system that's been up more than a couple of weeks to get your budget spreadsheet? Since it appears that there is no way to move the beginning of the partition, I may do an xfsdump, and try some tools to move it, hell maybe it will work maybe it won't but it's worth a shot if I gotta rebuild anyway. As I've never used dump and restore (gasp, amazement, pity) I'll just ask my question. Could I move just /usr or /home with dump/restore, or is it partition based? > D. Stimits, stimits@idcomm.com > > > > > p.p.s. > > > > No, you cannot have it! Gee thanks. I was just going to ask, but since you pre-empted the question I guess I won't :) Chris From owner-linux-xfs@oss.sgi.com Fri Nov 9 06:35:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9EZV406379 for linux-xfs-outgoing; Fri, 9 Nov 2001 06:35:31 -0800 Received: from MXAM1.vantico.ch (mxam1.vantico.com [65.201.195.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9EZG006355 for ; Fri, 9 Nov 2001 06:35:16 -0800 Received: from 65.201.195.109 by MXAM1.vantico.ch (InterScan E-Mail VirusWall NT); Fri, 09 Nov 2001 09:35:12 -0500 (Eastern Standard Time) Received: from USELEX01.vantico.corp.local ([10.144.8.34]) by USELER01.vantico.corp.local with Microsoft SMTPSVC(5.0.2195.1600); Fri, 9 Nov 2001 09:34:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Kernel Oops' content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Date: Fri, 9 Nov 2001 09:34:18 -0500 Message-ID: <29B0F1217C0D8D46B5A0ADC21D75EFC214D0FC@USELEX01.vantico.corp.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Kernel Oops' Thread-Index: AcFpKy8EnUdvvUMwQwyz37VES9KueA== From: "Hengesbach, Jeff (US EL)" To: X-OriginalArrivalTime: 09 Nov 2001 14:34:35.0927 (UTC) FILETIME=[A796C270:01C1692B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fA9EZG006356 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm having a kernel Oops occur when trying to rm or ls the directory: /tmp/orbit-hengeje1 I can mv it to a different name. After the mv it's automatically recreated, I can then and rm,ls,etc.. the recreated dir just fine. However, I can not remove the renamed directory though - gets an oops every time. The first rm -fr /tmp/orbit-hengeje1 will complete but message: "Can't remove directory ... - (not empty)" The second try of the command will hang and generate the Oops in the syslog. I guess its trying to tell me - If at first you don't succeed, don't try again ;-) Kernel versions and Oops'(direct from syslog): This is cvs checkout from oss on the 6th or 7th of November: Linux version 2.4.14-xfs (root@Dexter) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)) #2 Wed Nov 7 10:04:17 EST 2001 Nov 9 07:56:09 localhost kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000152 Nov 9 07:56:09 localhost kernel: printing eip: Nov 9 07:56:09 localhost kernel: c01ad5dd Nov 9 07:56:09 localhost kernel: *pde = 00000000 Nov 9 07:56:09 localhost kernel: Oops: 0000 Nov 9 07:56:09 localhost kernel: CPU: 0 Nov 9 07:56:10 localhost kernel: EIP: 0010:[xfs_iget+269/352] Not tainted Nov 9 07:56:10 localhost kernel: EIP: 0010:[] Not tainted Nov 9 07:56:10 localhost kernel: EFLAGS: 00210246 Nov 9 07:56:10 localhost kernel: eax: 00000000 ebx: ffffffe8 ecx: 00000000 edx: c028d1e0 Nov 9 07:56:10 localhost kernel: esi: c076fcb4 edi: c028d1e0 ebp: c076fca0 esp: d0b57e10 Nov 9 07:56:10 localhost kernel: ds: 0018 es: 0018 ss: 0018 Nov 9 07:56:10 localhost kernel: Process ls (pid: 9872, stackpage=d0b57000) Nov 9 07:56:10 localhost kernel: Stack: 00000000 00000000 c1654000 0000004b 0303151b d3ffe2d4 c01c21b7 c1654000 Nov 9 07:56:10 localhost kernel: 00000000 0303151b 00000000 00000000 d0b57e9c 00000000 00000000 00000000 Nov 9 07:56:10 localhost kernel: 00000008 00000018 000001f5 00000306 d3ffe2ec d3ffe2d4 00000008 d4079460 Nov 9 07:56:10 localhost kernel: Call Trace: [xfs_dir_lookup_int+295/704] [xfs_lookup+151/272] [linvfs_lookup+104/192] [real_lookup+79/192] [link_path_walk+1267/1808] Nov 9 07:56:10 localhost kernel: Call Trace: [] [] [] [] [] Nov 9 07:56:10 localhost kernel: [getname+94/160] [__user_walk+51/80] [sys_lstat64+20/112] [error_code+52/60] [system_call+51/56] Nov 9 07:56:10 localhost kernel: [] [] [] [] [] Nov 9 07:56:10 localhost kernel: Nov 9 07:56:10 localhost kernel: Code: 66 83 bb 6a 01 00 00 00 75 1a 0f b7 83 50 01 00 00 25 f7 ff ************************************************************************ ******************************************* This is the linus kernel with the xfs patch from oss.sgi.com: Linux version 2.4.7-xfs (root@Dexter) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)) #2 Wed Oct 31 09:26:08 EST 2001 Nov 9 08:04:24 localhost kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000152 Nov 9 08:04:24 localhost kernel: printing eip: Nov 9 08:04:24 localhost kernel: c01aef5d Nov 9 08:04:24 localhost kernel: *pde = 00000000 Nov 9 08:04:24 localhost kernel: Oops: 0000 Nov 9 08:04:24 localhost kernel: CPU: 0 Nov 9 08:04:24 localhost kernel: EIP: 0010:[xfs_iget+253/336] Nov 9 08:04:24 localhost kernel: EIP: 0010:[] Nov 9 08:04:24 localhost kernel: EFLAGS: 00010246 Nov 9 08:04:24 localhost kernel: eax: d661ab60 ebx: ffffffe8 ecx: d78f4d68 edx: c02a6be0 Nov 9 08:04:24 localhost kernel: esi: 0303151b edi: 00000000 ebp: d661ab4c esp: d4ce9e04 Nov 9 08:04:24 localhost kernel: ds: 0018 es: 0018 ss: 0018 Nov 9 08:04:24 localhost kernel: Process rm (pid: 1331, stackpage=d4ce9000) Nov 9 08:04:24 localhost kernel: Stack: 00000000 00000000 c17f0000 0000011c 0303151b d4cca964 c01c4467 c17f0000 Nov 9 08:04:24 localhost kernel: 00000000 0303151b 00000000 00000000 d4ce9e90 00000000 00000000 00000000 Nov 9 08:04:24 localhost kernel: 00000008 00000018 d4ccbaac 00000000 d4cca97c d4cca964 00000008 d4c4cfe0 Nov 9 08:04:24 localhost kernel: Call Trace: [xfs_dir_lookup_int+295/704] [xfs_lookup+151/272] [linvfs_lookup+104/192] [xfs_access+47/64] [real_lookup+79/192] [path_walk+1425/2016] [zap_page_range+305/608] Nov 9 08:04:24 localhost kernel: Call Trace: [] [] [] [] [] [] [] Nov 9 08:04:24 localhost kernel: [__user_walk+58/96] [sys_lstat64+19/112] [system_call+51/56] Nov 9 08:04:24 localhost kernel: [] [] [] Nov 9 08:04:24 localhost kernel: Nov 9 08:04:24 localhost kernel: Code: 66 83 bb 6a 01 00 00 00 75 1a 0f b7 83 50 01 00 00 25 f7 ff ************************************************************************ *********************************************** This is the linus kernel with the xfs patch from oss.sgi.com: Linux version 2.4.9-xfs (root@Dexter) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)) #3 Wed Nov 7 09:58:40 EST 2001 Nov 9 08:07:28 localhost kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000152 Nov 9 08:07:28 localhost kernel: printing eip: Nov 9 08:07:28 localhost kernel: c01aef7d Nov 9 08:07:28 localhost kernel: *pde = 00000000 Nov 9 08:07:28 localhost kernel: Oops: 0000 Nov 9 08:07:28 localhost kernel: CPU: 0 Nov 9 08:07:28 localhost kernel: EIP: 0010:[xfs_iget+253/336] Nov 9 08:07:28 localhost kernel: EIP: 0010:[] Nov 9 08:07:28 localhost kernel: EFLAGS: 00010246 Nov 9 08:07:28 localhost kernel: eax: d4defb00 ebx: ffffffe8 ecx: c02a4b70 edx: c02a7300 Nov 9 08:07:28 localhost kernel: esi: 0303151b edi: 00000000 ebp: d4defaec esp: d4e39e04 Nov 9 08:07:28 localhost kernel: ds: 0018 es: 0018 ss: 0018 Nov 9 08:07:28 localhost kernel: Process ls (pid: 1265, stackpage=d4e39000) Nov 9 08:07:28 localhost kernel: Stack: 00000000 00000000 c16a0000 00000000 0303151b d4e164c8 c01c4567 c16a0000 Nov 9 08:07:28 localhost kernel: 00000000 0303151b 00000000 00000000 d4e39e90 00000000 00000000 00000000 Nov 9 08:07:28 localhost kernel: 00000008 00000018 d4e47cec 00000000 d4e164e0 d4e164c8 00000008 d63d8ce0 Nov 9 08:07:28 localhost kernel: Call Trace: [xfs_dir_lookup_int+295/704] [xfs_lookup+151/272] [linvfs_lookup+104/192] [xfs_access+47/64] [real_lookup+79/192] Nov 9 08:07:28 localhost kernel: Call Trace: [] [] [] [] [] Nov 9 08:07:28 localhost kernel: [path_walk+1425/2016] [__user_walk+58/96] [sys_lstat64+19/112] [system_call+51/56] Nov 9 08:07:28 localhost kernel: [] [] [] [] Nov 9 08:07:28 localhost kernel: Nov 9 08:07:28 localhost kernel: Code: 66 83 bb 6a 01 00 00 00 75 1a 0f b7 83 50 01 00 00 25 f7 ff Hardware is a Dell Latitude C600 Laptop 1GHz P3 384MB RAM 18GB disk. Thanks, Jeff Hengesbach Vantico Inc. USA Unix Manager 517.324.1581 517.351.9003(Fax) From owner-linux-xfs@oss.sgi.com Fri Nov 9 07:07:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9F7GX07495 for linux-xfs-outgoing; Fri, 9 Nov 2001 07:07:16 -0800 Received: from mail.dkp.com ([204.191.16.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9F7C007472 for ; Fri, 9 Nov 2001 07:07:12 -0800 Received: from ranma.dkp.com (ranma.dkp.com [205.150.40.12]) by mail.dkp.com (Postfix) with ESMTP id 2C3D31AB2A for ; Fri, 9 Nov 2001 10:07:11 -0500 (EST) Received: by ranma.dkp.com (Postfix, from userid 168) id CFC9A5A90C; Fri, 9 Nov 2001 10:07:10 -0500 (EST) Date: Fri, 9 Nov 2001 10:07:10 -0500 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: rh7.2 prerelease Message-ID: <20011109100710.A1480@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3BEB1829.5F5C3D2@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Nov 09, 2001 at 12:42:04AM -0500, Avijit Ghosh wrote: > I did an upgrade of my 7.1 box which went more or less as > according to plan but I seem to be having weird issues w/ any > users .kde/share/config/* files sometimes arbitrarily turning > into > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ Those are strings of null bytes. You haven't been turning off the power without a proper shutdown, have you? Andrew Klaassen From owner-linux-xfs@oss.sgi.com Fri Nov 9 07:46:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9Fkhk08246 for linux-xfs-outgoing; Fri, 9 Nov 2001 07:46:43 -0800 Received: from sundown.cs.cornell.edu (sundown.cs.cornell.edu [128.84.96.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9Fkd008224 for ; Fri, 9 Nov 2001 07:46:39 -0800 Received: from fafe.cs.cornell.edu (fafe.cs.cornell.edu [128.84.97.167]) by sundown.cs.cornell.edu (8.11.3/8.11.3/R-3.6) with ESMTP id fA9Fka218416; Fri, 9 Nov 2001 10:46:37 -0500 (EST) Date: Fri, 9 Nov 2001 10:40:39 -0500 (EST) From: X-X-Sender: To: Andrew Klaassen cc: Subject: Re: rh7.2 prerelease In-Reply-To: <20011109100710.A1480@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, 9 Nov 2001, Andrew Klaassen wrote: > On Fri, Nov 09, 2001 at 12:42:04AM -0500, > Avijit Ghosh wrote: > > > I did an upgrade of my 7.1 box which went more or less as > > according to plan but I seem to be having weird issues w/ any > > users .kde/share/config/* files sometimes arbitrarily turning > > into > > > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ > > Those are strings of null bytes. You haven't been turning off > the power without a proper shutdown, have you? No not at all it reboots properly as well (no recovery) so i dont think the shutdown mechanism is askew though perhaps I should verify my kde related rpm packages.. I tried moving fam/sgi_fam out of xinet but that didn't seem to fix the issue. I did a deja search on the fam errors and the write errors shows up a german kde group (rh7.2 issue mentioned) so that may be something seperate.. This is a laptop.. I'm a bit worried that i'm hitting some corruption bug .. the config files get saved properly but they get newly screwed up at some point by the time kde starts again. (I'll try and hunt down when exactly this happens at all) -avi From owner-linux-xfs@oss.sgi.com Fri Nov 9 07:59:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9FxfT08606 for linux-xfs-outgoing; Fri, 9 Nov 2001 07:59:41 -0800 Received: from mailboy.pgs.com (mailboy.hstn.tensor.pgs.com [157.147.25.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9FxX008584 for ; Fri, 9 Nov 2001 07:59:34 -0800 Received: from hap.hstn.tensor.pgs.com (hap.hstn.tensor.pgs.com [157.147.132.13]) by mailboy.pgs.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18326 for ; Fri, 9 Nov 2001 09:59:27 -0600 (CST) Received: from idoru.hstn.tensor.pgs.com (idoru.hstn.tensor.pgs.com [157.147.92.80]) by hap.hstn.tensor.pgs.com (8.9.3/8.9.3) with ESMTP id JAA04603 for ; Fri, 9 Nov 2001 09:59:28 -0600 (CST) Subject: write to XFS NFS filesystem From: Derek Richardson To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 09 Nov 2001 09:59:24 -0600 Message-Id: <1005321564.1570.3021.camel@idoru.hstn.tensor.pgs.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk All, I recently installed XFS 1.0.1 on an IBM x340 w/ a ServeRAID controller, root FS is still ext2, created a 400 GB filesystem on an already existing partition (ext2 type 83 partition). NFS mounted by 16 client machines, all of which write to the FS on completion of a compute process, creating a single 12.9 GB file. We know that the write worked correctly on ext2 NFS-mounted filesystem, so it's not application-related (at least in terms of it performing the write correctly in terms of queing/parrallelism). There were no unusual entries in /var/log/messages (other than mount requests - which were successful) on the NFS-serving machine or the clients, yet the write still failed. I am using the rpms from release 1.0.1, and the 2.4.9-13 (RedHat and XFS) kernel from testing : acl-1.0.7-0.i386.rpm acl-devel-1.0.7-0.i386.rpm anaconda-7.1-7XFS.i386.rpm anaconda-runtime-7.1-7XFS.i386.rpm attr-1.0.3-0.i386.rpm attr-devel-1.0.3-0.i386.rpm devfsd-1.3.11-sgi.i386.rpm dmapi-0.1.1-0.i386.rpm dmapi-devel-0.1.1-0.i386.rpm kernel-doc-2.4.9-13SGI_XFS_PR1.i386.rpm kernel-headers-2.4.9-13SGI_XFS_PR1.i386.rpm kernel-smp-2.4.9-13SGI_XFS_PR1.i686.rpm kernel-source-2.4.9-13SGI_XFS_PR1.i386.rpm tux-2.1.0-2.i386.rpm xfsdump-1.0.9-0.i386.rpm xfsprogs-1.2.8-0.i386.rpm xfsprogs-devel-1.2.8-0.i386.rpm Has anyone had experience with this, have any help, hint, suggestions? FYI, unless it's absolutely life-or-death, I would prefer to use the RedHat-release kernels. Any help is very appreciated, thanks in advance. Regards, Derek R. -- Junior Linux Geek 713-817-1197 (cell) 713-781-4000 x2267 (office) "Linux users, fanatical. No way... HEY! Get that MCSE up on the altar, Tux must be appeased!" From owner-linux-xfs@oss.sgi.com Fri Nov 9 08:08:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9G8OI08954 for linux-xfs-outgoing; Fri, 9 Nov 2001 08:08:24 -0800 Received: from mailboy.pgs.com (mailboy.hstn.tensor.pgs.com [157.147.25.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9G8F008931 for ; Fri, 9 Nov 2001 08:08:16 -0800 Received: from hap.hstn.tensor.pgs.com ([157.147.136.17]) by mailboy.pgs.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18772 for ; Fri, 9 Nov 2001 10:08:13 -0600 (CST) Received: from idoru.hstn.tensor.pgs.com (idoru.hstn.tensor.pgs.com [157.147.92.80]) by hap.hstn.tensor.pgs.com (8.9.3/8.9.3) with ESMTP id KAA05137; Fri, 9 Nov 2001 10:08:13 -0600 (CST) Subject: Re: write to XFS NFS filesystem From: Derek Richardson To: Derek Richardson Cc: linux-xfs@oss.sgi.com In-Reply-To: <1005321564.1570.3021.camel@idoru.hstn.tensor.pgs.com> References: <1005321564.1570.3021.camel@idoru.hstn.tensor.pgs.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 09 Nov 2001 10:08:10 -0600 Message-Id: <1005322090.1569.3051.camel@idoru.hstn.tensor.pgs.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk All, My apologies, just found the problem...permissions...arggh! That's what late-night administration with lack of sleep gets you... Thanks anyways, Derek R. On Fri, 2001-11-09 at 09:59, Derek Richardson wrote: > All, > I recently installed XFS 1.0.1 on an IBM x340 w/ a ServeRAID controller, > root FS is still ext2, created a 400 GB filesystem on an already > existing partition (ext2 type 83 partition). NFS mounted by 16 client > machines, all of which write to the FS on completion of a compute > process, creating a single 12.9 GB file. We know that the write worked > correctly on ext2 NFS-mounted filesystem, so it's not > application-related (at least in terms of it performing the write > correctly in terms of queing/parrallelism). There were no unusual > entries in /var/log/messages (other than mount requests - which were > successful) on the NFS-serving machine or the clients, yet the write > still failed. > I am using the rpms from release 1.0.1, and the 2.4.9-13 (RedHat and > XFS) kernel from testing : > acl-1.0.7-0.i386.rpm > acl-devel-1.0.7-0.i386.rpm > anaconda-7.1-7XFS.i386.rpm > anaconda-runtime-7.1-7XFS.i386.rpm > attr-1.0.3-0.i386.rpm > attr-devel-1.0.3-0.i386.rpm > devfsd-1.3.11-sgi.i386.rpm > dmapi-0.1.1-0.i386.rpm > dmapi-devel-0.1.1-0.i386.rpm > kernel-doc-2.4.9-13SGI_XFS_PR1.i386.rpm > kernel-headers-2.4.9-13SGI_XFS_PR1.i386.rpm > kernel-smp-2.4.9-13SGI_XFS_PR1.i686.rpm > kernel-source-2.4.9-13SGI_XFS_PR1.i386.rpm > tux-2.1.0-2.i386.rpm > xfsdump-1.0.9-0.i386.rpm > xfsprogs-1.2.8-0.i386.rpm > xfsprogs-devel-1.2.8-0.i386.rpm > > Has anyone had experience with this, have any help, hint, suggestions? > FYI, unless it's absolutely life-or-death, I would prefer to use the > RedHat-release kernels. Any help is very appreciated, thanks in > advance. > Regards, > Derek R. > > -- > Junior Linux Geek > 713-817-1197 (cell) > 713-781-4000 x2267 (office) > "Linux users, fanatical. No way... > HEY! Get that MCSE up on the altar, > Tux must be appeased!" > -- Junior Linux Geek 713-817-1197 (cell) 713-781-4000 x2267 (office) "Linux users, fanatical. No way... HEY! Get that MCSE up on the altar, Tux must be appeased!" From owner-linux-xfs@oss.sgi.com Fri Nov 9 08:13:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9GDKW09120 for linux-xfs-outgoing; Fri, 9 Nov 2001 08:13:20 -0800 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 fA9GDF009097 for ; Fri, 9 Nov 2001 08:13:16 -0800 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 RAA1910230 for ; Fri, 9 Nov 2001 17:13:14 +0100 (CET) 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 KAA3446473; Fri, 9 Nov 2001 10:11:57 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA36330; Fri, 9 Nov 2001 10:11:56 -0600 (CST) Subject: Re: rh7.2 prerelease From: Eric Sandeen To: avijit@cs.cornell.edu Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 09 Nov 2001 10:10:57 -0600 Message-Id: <1005322257.22702.38.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, just to recap and be certain about this... Your config files at one point are fine, and then, without rebooting, they suddenly contain only nulls? I'm not sure if this might have anything to do with it, but is the laptop suspending in the interim? -Eric On Fri, 2001-11-09 at 09:40, avijit@cs.cornell.edu wrote: > On Fri, 9 Nov 2001, Andrew Klaassen wrote: > > > On Fri, Nov 09, 2001 at 12:42:04AM -0500, > > Avijit Ghosh wrote: > > > > > I seem to be having weird issues w/ any > > > users .kde/share/config/* files sometimes arbitrarily turning > > > into > > > > > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ > > > > Those are strings of null bytes. You haven't been turning off > > the power without a proper shutdown, have you? > > No not at all it reboots properly as well (no recovery) so i dont > think the shutdown mechanism is askew -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Nov 9 08:17:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9GHHu09336 for linux-xfs-outgoing; Fri, 9 Nov 2001 08:17:17 -0800 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 fA9GHD009311 for ; Fri, 9 Nov 2001 08:17:13 -0800 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 RAA1954250 for ; Fri, 9 Nov 2001 17:17:11 +0100 (CET) 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 KAA3551931; Fri, 9 Nov 2001 10:15:54 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA01198; Fri, 9 Nov 2001 10:15:54 -0600 (CST) Subject: Re: XFS, Linux, and Solaris. -- Dual GPL/Commercial Licensing From: Eric Sandeen To: "Jesse W. Asher" Cc: linux-xfs@oss.sgi.com In-Reply-To: <200111091242.fA9CgFL03491@oss.sgi.com> References: <200111091242.fA9CgFL03491@oss.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 09 Nov 2001 10:14:54 -0600 Message-Id: <1005322495.22702.40.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Jesse - > Hmmm. I understand now. Seems pretty reasonable. I guess I'm just > used to open source meaning that I can download the source, compile for > whatever platform I desire and install it on that platform. You can - you just can't necessarily distribute the result. This is all stock and trade for the GPL - nothing unique about XFS's licensing (which is just GPL.) I suppose this topic might be better suited to gnu.misc.discuss... :) -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 Nov 9 08:18:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9GIFG09475 for linux-xfs-outgoing; Fri, 9 Nov 2001 08:18:15 -0800 Received: from smtp.pkwhelan.net (dsl092-072-121.bos1.dsl.speakeasy.net [66.92.72.121]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9GI9009449 for ; Fri, 9 Nov 2001 08:18:09 -0800 Received: (qmail 13977 invoked by uid 174); 9 Nov 2001 16:24:57 -0000 Message-ID: <20011109162457.30746.qmail@smtp.pkwhelan.net> References: <20011108152607.A22784@stonewall.pkwhelan.net> <1005255149.22700.14.camel@stout.americas.sgi.com> <20011108214712.19351.qmail@smtp.pkwhelan.net> In-Reply-To: <20011108214712.19351.qmail@smtp.pkwhelan.net> From: "PK Whelan" To: linux-xfs@oss.sgi.com Cc: Eric Sandeen Subject: Re: Compile errors with 2.4.14 kernel Date: Fri, 09 Nov 2001 16:24:57 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Unpacking the kernel source again did the trick. I afterwards realized that I had previously applied the ext3 patch and that's what messed things up. The ext3 patch puts those 2 EXPORT_SYMBOL statements in fs/buffer.c when xfs had already put them in kernel/ksym.c (like you had said - there were duplicates). So, if you're going to apply the xfs and the ext3 patch you'll have to remove those dups in order to compile. Thanks for the help! PKW PK Whelan writes: > Thanks Eric. > I'll try unpacking the source again in case something got messed up and > try it again. > > Paul > > Eric Sandeen writes: > >> Hi Paul - >> >> Strange... this works fine for me, with your config, with gcc-2.96-98 >> >> From the error it _looks_ like EXPORT_SYMBOL(create_empty_buffers) is >> somewhere twice, but it's not in my tree... check kernel/check ksysms.c >> and fs/buffer.c >> >> This is a brand new 2.4.14 tree patched w/ >> linux-2.4.14-xfs-2001-11-07.patch.bz2? >> >> -Eric >> >> On Thu, 2001-11-08 at 14:26, pkw@pkwhelan.net wrote: >>> Hi, >>> I used the linux-2.4.14-xfs-2001-11-07.patch.bz2 patch against a clean >>> 2.4.14 tree. The >>> patch applied cleanly but will not compile. This is the error message I >>> get: >> >> -- >> Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs >> sandeen@sgi.com SGI, Inc. >> > > From owner-linux-xfs@oss.sgi.com Fri Nov 9 09:17:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9HHW712605 for linux-xfs-outgoing; Fri, 9 Nov 2001 09:17:32 -0800 Received: from sundown.cs.cornell.edu (sundown.cs.cornell.edu [128.84.96.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9HHR012577 for ; Fri, 9 Nov 2001 09:17:27 -0800 Received: from fafe.cs.cornell.edu (fafe.cs.cornell.edu [128.84.97.167]) by sundown.cs.cornell.edu (8.11.3/8.11.3/R-3.6) with ESMTP id fA9HHD203494; Fri, 9 Nov 2001 12:17:14 -0500 (EST) Date: Fri, 9 Nov 2001 12:11:16 -0500 (EST) From: X-X-Sender: To: Eric Sandeen cc: Subject: Re: rh7.2 prerelease In-Reply-To: <1005322257.22702.38.camel@stout.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 9 Nov 2001, Eric Sandeen wrote: > Ok, just to recap and be certain about this... > > Your config files at one point are fine, and then, without rebooting, > they suddenly contain only nulls? > > I'm not sure if this might have anything to do with it, but is the > laptop suspending in the interim? No not at all.. I usually (w/ 7.1) keep the machine suspended and suspension has worked fine but in hunting this down my recipe has been thus far login/make the bottom bar "small" add external taskbar up top.. verify the appropriate files are written in config log out "click reboot" come back .. random files like kwinrc, the taskbar one *randomly* w/ no consistantly get changed..sometimes kdeglobals, sometimes kwinrc sometimes the taskbar one. I put some echo "hello!" dumps in the startkde script to make sure that wasn't doing the rewriting which is what I thought was happening initially (that i was just getting "reset"). I'll be outside of our firewall this weekend so *may* be emailless (its flakey) but will take it w/ me and try out any suggestions offered. I should easily be able to hunt down whether the files are changing before shutdown or on restart or on login for instance and hopefully specifically when and what program/script is doing it. btw I also created a brand new account to make sure that it wasn't due to old files lying around somewhere and had/have the same issue. btw this is a dell5ke/ati128:16mb/xircom cardbus modem (which was a bit flakey w/ the old 2.4* kernels)/ ati 128 vid cards / 32 gig/5400rpm ibm drive/512mb mem (memory is so cheap now its embarrasing :)) -avi From owner-linux-xfs@oss.sgi.com Fri Nov 9 10:00:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9I0JD13567 for linux-xfs-outgoing; Fri, 9 Nov 2001 10:00:19 -0800 Received: from ente.berdmann.de (frnk-d514e1c9.dsl.mediaWays.net [213.20.225.201]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9I0F013544 for ; Fri, 9 Nov 2001 10:00:15 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 162Fwg-0001C3-00 for linux-xfs@oss.sgi.com; Fri, 09 Nov 2001 19:00:03 +0100 Message-ID: <3BEC19A2.A59C9659@berdmann.de> Date: Fri, 09 Nov 2001 19:00:02 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.13-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Linux XFS Mailing List Subject: xfsdump/xfsrestore trash hardlinks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, some day ago, I had to xfsrestore a /usr filesystem (RH 7.1, 2.4.13-xfs, with recent xfstools). After applying several dump levels up to 2, lots of files were missing: /usr/bin/perl /usr/bin/emacs ...lots of mrtg*.png in several subdirectories [etc.] Why does xfsrestore trash hardlinks? Look at a running system: # ll /usr/bin/emacs -rwxr-xr-x 2 root root 4001044 Jun 13 2000 /usr/bin/emacs # find /usr -inum 4368604 /usr/bin/emacs-20.7 /usr/bin/emacs From owner-linux-xfs@oss.sgi.com Fri Nov 9 11:05:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9J5v814987 for linux-xfs-outgoing; Fri, 9 Nov 2001 11:05:57 -0800 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 fA9J5q014965 for ; Fri, 9 Nov 2001 11:05:52 -0800 Received: from idcomm.com (IDENT:uSCPVST2GPJF4KYFYi3Q37mKLkc4IKFM@k56-pip5.idcomm.com [209.60.72.132]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id fA9J8IT17835 for ; Fri, 9 Nov 2001 12:08:18 -0700 Message-ID: <3BEC290F.8FA299AC@idcomm.com> Date: Fri, 09 Nov 2001 12:05:51 -0700 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: rh7.2 prerelease References: <1005322257.22702.38.camel@stout.americas.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, just to recap and be certain about this... > > Your config files at one point are fine, and then, without rebooting, > they suddenly contain only nulls? > > I'm not sure if this might have anything to do with it, but is the > laptop suspending in the interim? > > -Eric > > On Fri, 2001-11-09 at 09:40, avijit@cs.cornell.edu wrote: > > On Fri, 9 Nov 2001, Andrew Klaassen wrote: > > > > > On Fri, Nov 09, 2001 at 12:42:04AM -0500, > > > Avijit Ghosh wrote: > > > > > > > I seem to be having weird issues w/ any > > > > users .kde/share/config/* files sometimes arbitrarily turning > > > > into > > > > > > > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ One suggestion, use lsof on the relevant files just before shutdown, see what might be accessing them. Before doing lsof, verifiy that they are not yet nulled out. Just verify that some particular program is or is not holding them open till the last minute. D. Stimits, stimits@idcomm.com > > > > > > Those are strings of null bytes. You haven't been turning off > > > the power without a proper shutdown, have you? > > > > No not at all it reboots properly as well (no recovery) so i dont > > think the shutdown mechanism is askew > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Nov 9 11:09:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9J9cD15145 for linux-xfs-outgoing; Fri, 9 Nov 2001 11:09:38 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9J9S015120 for ; Fri, 9 Nov 2001 11:09:28 -0800 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Nov 2001 13:08:55 -0600 Message-ID: <85063BBE668FD411944400D0B744267A888741@AUSMAIL> From: "Gonyou, Austin" To: "'Seth Mos'" , Matt_Domsch@dell.com Cc: Linux-PowerEdge@dell.com, linux-xfs@oss.sgi.com Subject: RE: AMI megaraid performance (was: RE: Dell release of Redhat 7.2 ) Date: Fri, 9 Nov 2001 13:08:49 -0600 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 -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Seth Mos [mailto:knuffie@xs4all.nl] > Sent: Friday, November 09, 2001 4:21 AM > To: Matt_Domsch@dell.com > Cc: Linux-PowerEdge@dell.com; linux-xfs@oss.sgi.com > Subject: Re: AMI megaraid performance (was: RE: Dell release of Redhat > 7.2) > > > Cross posting to linux-xfs@oss.sgi.com > > At 15:48 8-11-2001 +0100, Seth Mos wrote: > >On another note, the newer 1.61j firmware for the PERC2/3 > card is a decent > >speed improvement on raid 10 arrays. We just got a 13MB/sec > extra read > >speed (from 58MB/s to 71MB/s). > > > >The amount of Random seeks was significantly reduced from > 7500 to 5000 > > > >Bonnie 1.0 -------Sequential Output-------- ---Sequential Input-- > >--Random-- > > -Per Char- --Block--- -Rewrite-- -Per Char- > --Block--- > > --Seeks--- > >Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU > K/sec %CPU /sec > >%CPU > >1.61j 2000 15568 100.0 38680 20.9 27593 17.6 13745 91.0 > 71393 18.5 > >5001.7 23.8 > >1.57 2000 15572 100.0 38092 19.1 24619 16.0 12786 84.9 > 58874 14.7 > >7541.5 26.4 > > > >RH Linux 7.1+XFS 6x72GB RAID 10 on AMI MegaRaid (493) dual > 1.13Ghz 2Gb ram > > As a followup I tested the new firmware against different > kernel versions > and behold. > > The 2.4.9-12 kernel is the RedHat kernel that was released as > a security > update. > The 2.4.14 kernel is the linus kernel. The filesystem is XFS > on both versions. > > -------Sequential Output-------- ---Sequential Input-- > --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- > --Seeks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU > K/sec %CPU /sec %CPU > 2.4.9-12 2000 15568 100.0 38680 20.9 27593 17.6 13745 91.0 71393 18.5 > 5001.7 23.8 > 2.4.14 2000 11999 79.2 34491 23.8 18538 16.7 13615 90.1 > 89704 22.6 5493.9 > 23.3 > > The read speed with the newer 2.4.14 kernel is 18MB/sec faster then > 2.4.9-12 kernel from redhat. Now I suspected that the new > Andrea VM should > make some difference but this is significant. > What is odd however is that the write scores are lower across > the board. > > 2.4.9-12: megaraid: v1.17a (Release Date: Fri Jul 13 > 18:44:01 EDT 2001) > 2.4.14: megaraid: v1.18 (Release Date: Thu Oct 11 15:02:53 EDT 2001 > > When running Bonnie over a ssh modem link where the latency > is higher the > benchmark scores plummet which suggests that tty latency is > affecting disk > througput. Very strange. > > 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 Nov 9 11:11:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9JBru15317 for linux-xfs-outgoing; Fri, 9 Nov 2001 11:11:53 -0800 Received: from ausmail.coremetrics.com ([209.184.141.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9JBh015294 for ; Fri, 9 Nov 2001 11:11:43 -0800 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Nov 2001 13:11:05 -0600 Message-ID: <85063BBE668FD411944400D0B744267A888742@AUSMAIL> From: "Gonyou, Austin" To: "'Seth Mos'" , Matt_Domsch@dell.com Cc: Linux-PowerEdge@dell.com, linux-xfs@oss.sgi.com Subject: RE: AMI megaraid performance (was: RE: Dell release of Redhat 7.2 ) Date: Fri, 9 Nov 2001 13:10:59 -0600 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 TTY Output will affect many things in this regard. Try doing a test in which you ouput much info to a file very quickly, tail that file from a console. At the same time measure your MB/s written to the file watch -n1 du -k should suffice. Then stop tailing the file. I think you'll see that your throughput does increase a bit, even from the console level. The basic reason is that you must apply more then one access path to the file, this will invariably slow things down. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin@coremetrics.com > -----Original Message----- > From: Seth Mos [mailto:knuffie@xs4all.nl] > Sent: Friday, November 09, 2001 4:21 AM > To: Matt_Domsch@dell.com > Cc: Linux-PowerEdge@dell.com; linux-xfs@oss.sgi.com > Subject: Re: AMI megaraid performance (was: RE: Dell release of Redhat > 7.2) > > > Cross posting to linux-xfs@oss.sgi.com > > At 15:48 8-11-2001 +0100, Seth Mos wrote: > >On another note, the newer 1.61j firmware for the PERC2/3 > card is a decent > >speed improvement on raid 10 arrays. We just got a 13MB/sec > extra read > >speed (from 58MB/s to 71MB/s). > > > >The amount of Random seeks was significantly reduced from > 7500 to 5000 > > > >Bonnie 1.0 -------Sequential Output-------- ---Sequential Input-- > >--Random-- > > -Per Char- --Block--- -Rewrite-- -Per Char- > --Block--- > > --Seeks--- > >Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU > K/sec %CPU /sec > >%CPU > >1.61j 2000 15568 100.0 38680 20.9 27593 17.6 13745 91.0 > 71393 18.5 > >5001.7 23.8 > >1.57 2000 15572 100.0 38092 19.1 24619 16.0 12786 84.9 > 58874 14.7 > >7541.5 26.4 > > > >RH Linux 7.1+XFS 6x72GB RAID 10 on AMI MegaRaid (493) dual > 1.13Ghz 2Gb ram > > As a followup I tested the new firmware against different > kernel versions > and behold. > > The 2.4.9-12 kernel is the RedHat kernel that was released as > a security > update. > The 2.4.14 kernel is the linus kernel. The filesystem is XFS > on both versions. > > -------Sequential Output-------- ---Sequential Input-- > --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- > --Seeks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU > K/sec %CPU /sec %CPU > 2.4.9-12 2000 15568 100.0 38680 20.9 27593 17.6 13745 91.0 71393 18.5 > 5001.7 23.8 > 2.4.14 2000 11999 79.2 34491 23.8 18538 16.7 13615 90.1 > 89704 22.6 5493.9 > 23.3 > > The read speed with the newer 2.4.14 kernel is 18MB/sec faster then > 2.4.9-12 kernel from redhat. Now I suspected that the new > Andrea VM should > make some difference but this is significant. > What is odd however is that the write scores are lower across > the board. > > 2.4.9-12: megaraid: v1.17a (Release Date: Fri Jul 13 > 18:44:01 EDT 2001) > 2.4.14: megaraid: v1.18 (Release Date: Thu Oct 11 15:02:53 EDT 2001 > > When running Bonnie over a ssh modem link where the latency > is higher the > benchmark scores plummet which suggests that tty latency is > affecting disk > througput. Very strange. > > 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 Nov 9 11:35:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9JZti15844 for linux-xfs-outgoing; Fri, 9 Nov 2001 11:35:55 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9JZh015817 for ; Fri, 9 Nov 2001 11:35:43 -0800 Received: from sa-bwmail1.storageapps.com (smtp.storageapps.com [63.101.83.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 LAA00045 for ; Fri, 9 Nov 2001 11:35:33 -0800 (PST) mail_from (chip_christian@hp.com) Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Nov 2001 14:31:46 -0500 Message-ID: <23D04BDBA646D411BDDD00D0B774B539046028B7@SA-BWMAIL1> From: "Christian, Chip" To: =?iso-8859-1?Q?=27Peter_W=E4chtler=27?= , linux-xfs@oss.sgi.com Cc: lkml Subject: RE: NFS hit me (2.4.9-xfs) again Date: Fri, 9 Nov 2001 14:31:45 -0500 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 fA9JZh015818 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The reason that dput was dropped in 2.4.10 is that there's another one that also gets executed, causing the kernel oops right after the if (!pdentry) { } code block. I think you have a filesystem in need of repair. RedHat ships this patch with their 2.4.9 kernels: --- linux/fs/nfsd/nfsfh.c~ Fri Aug 17 21:30:25 2001 +++ linux/fs/nfsd/nfsfh.c Fri Aug 17 21:30:40 2001 @@ -275,7 +275,6 @@ d_drop(tdentry); /* we never want ".." hashed */ if (!pdentry && tdentry->d_inode == NULL) { /* File system cannot find ".." ... sad but possible */ - dput(tdentry); pdentry = ERR_PTR(-EINVAL); } if (!pdentry) { -----Original Message----- From: Peter Wächtler [mailto:pwaechtler@loewe-komp.de] Sent: Friday, November 09, 2001 5:01 To: linux-xfs@oss.sgi.com Cc: lkml Subject: NFS hit me (2.4.9-xfs) again Unable to handle kernel NULL pointer dereference at virtual address 00000000 00000000 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[<00000000>] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 00000000 ebx: c9c0d7e0 ecx: 00000000 edx: c03a7b00 esi: c9c0d560 edi: c9c0d7e0 ebp: c9c0d7e0 esp: cbddde84 ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 233, stackpage=cbddd000) Stack: c01729f4 cc97f420 c9c0d560 00000005 cdc40a00 c0172e56 c9c0d7e0 00000005 cd390200 cd390000 cbed2000 cbdddf20 cdc40be8 cd390200 c0173199 cdc40a00 cd390010 00000005 00000001 00000001 00000008 cbe17e00 cbee48c0 cd390200 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: Bad EIP value. >>EIP; 00000000 Before first symbol Trace; c01729f4 Trace; c0172e56 Trace; c0173199 Trace; c0173ad2 Trace; c017843d Trace; c017173c Trace; c0171003 Trace; c0240318 Trace; c0170dab Trace; c010557f This is not the initial crash location - the machine was dead (and no serial console yet). But after restarting, about 6-10 clients tried to reconnect to NFSD and caused the crash. The crash appears because "child->d_inode->i_op->lookup == NULL" struct dentry *nfsd_findparent(struct dentry *child) { struct dentry *tdentry, *pdentry; tdentry = d_alloc(child, &(const struct qstr) {"..", 2, 0}); if (!tdentry) return ERR_PTR(-ENOMEM); /* I'm going to assume that if the returned dentry is different, then * it is well connected. But nobody returns different dentrys do they? */ /* added safety check to prevent crash - peewee */ if (child->d_inode->i_op && child->d_inode->i_op->lookup){ pdentry = child->d_inode->i_op->lookup(child->d_inode, tdentry); } else { printk("normally we had been crashing\n"); printk("child: %p\n",child); printk("child->d_inode: %p\n",child->d_inode); printk("child->d_inode->i_op: %p\n",child->d_inode->i_op); printk("child->d_inode->i_op->lookup: %p\n",child->d_inode->i_op->lookup); return( ERR_PTR(-EINVAL) );  } d_drop(tdentry); /* we never want ".." hashed */ if (!pdentry && tdentry->d_inode == NULL) { /* File system cannot find ".." ... sad but possible */ dput(tdentry); ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ this one was removed in 2.4.10 pdentry = ERR_PTR(-EINVAL); } if (!pdentry) { /* I don't want to return a ".." dentry. * I would prefer to return an unconnected "IS_ROOT" dentry, [...] If I use 2.4.12-xfs (with nfs-utils 0.3.3), clients can't create an archive with "ar": [ strace output of "ar" creating a lib out of several *.o] write(5, "\0\0\1\2\0\0H\2\0\0\1\2\0\0L\2\0\0\1\2\0\0P\2\0\0\1\2\0"..., 3254) = 3 close(5) = 0 munmap(0x4001f000, 4096) = 0 lstat64("lumenuila.a", {st_mode=S_IFREG|0644, st_size=8, ...}) = 0 rename("stO1wjGV", "lumenuila.a") = -1 ESTALE (Stale NFS file handle) My main question is: Is it possible that some interaction with xfs<->nfsd causes this kind of trouble? Especially when lookup("..") fails - and dealing with "disconnected dentries". Does the nfs_fh carry not enough information ( when is oldfh used, when the newer one? [ref_fh->fh_handle.fh_version == 0xca]). So we have an inode with no proper inode_operations, huh? I don't use NFSv3, should I? From owner-linux-xfs@oss.sgi.com Fri Nov 9 12:37:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9KbNW17631 for linux-xfs-outgoing; Fri, 9 Nov 2001 12:37:23 -0800 Received: from MXAM1.vantico.ch (mxam1.vantico.com [65.201.195.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9Kb3017605 for ; Fri, 9 Nov 2001 12:37:04 -0800 Received: from 65.201.195.109 by MXAM1.vantico.ch (InterScan E-Mail VirusWall NT); Fri, 09 Nov 2001 15:37:00 -0500 (Eastern Standard Time) Received: from USELEX01.vantico.corp.local ([10.144.8.34]) by USELER01.vantico.corp.local with Microsoft SMTPSVC(5.0.2195.1600); Fri, 9 Nov 2001 15:36:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Kernel Oops' content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Date: Fri, 9 Nov 2001 15:36:06 -0500 Message-ID: <29B0F1217C0D8D46B5A0ADC21D75EFC214D20A@USELEX01.vantico.corp.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Kernel Oops' Thread-Index: AcFpKy8EnUdvvUMwQwyz37VES9KueAAMeoug From: "Hengesbach, Jeff (US EL)" To: X-OriginalArrivalTime: 09 Nov 2001 20:36:07.0115 (UTC) FILETIME=[288B61B0:01C1695E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fA9Kb4017606 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk OK - thanks to Eric's help things appear back to normal now(is there is such a thing). The install CD I have is the first one that was put out - I didn't find xfs_repair/xfs_check on it. Luckily I have some space on my /boot partition (mounted to a temp location) where I copied them to(acually all the xfs_* progs some others are required). xfs_check found a few "link count mismatch.....disconnected inode" errors(I have one written down incase there is interest - lots of typing) - I actually have/had another directory that was causing me the same problem from a few weeks back. xfs_repair -n basically found the same things "entry .... references non-existant inode.... would have cleared inode...."(I wrote one of these monsters down also in case there is interest) It didn't appear it wanted to destroy the fs and these were junk directories/files anyway, so I ran xfs_repair on the parition which dumped a few small files into lost+found, and allowed me to remove the previously offending directories&files after the system booted normally. The big question now is, what caused this in the first place ?????? My hats off to yourself(Eric) and all the other XFS developers/contributors. I've been using linux+XFS on all my linux installs since before the first installer came out(over 1 year ago now??) - and have not expereinced an issue before this. Much Thanks, Jeff Hengesbach Vantico Inc. USA Unix Manager 517.324.1581 517.351.9003(Fax) -----Original Message----- From: Hengesbach, Jeff (US EL) Sent: Friday, November 09, 2001 9:34 AM To: linux-xfs@oss.sgi.com Subject: Kernel Oops' I'm having a kernel Oops occur when trying to rm or ls the directory: /tmp/orbit-hengeje1 I can mv it to a different name. After the mv it's automatically recreated, I can then and rm,ls,etc.. the recreated dir just fine. However, I can not remove the renamed directory though - gets an oops every time. The first rm -fr /tmp/orbit-hengeje1 will complete but message: "Can't remove directory ... - (not empty)" The second try of the command will hang and generate the Oops in the syslog. I guess its trying to tell me - If at first you don't succeed, don't try again ;-) Kernel versions and Oops'(direct from syslog): This is cvs checkout from oss on the 6th or 7th of November: Linux version 2.4.14-xfs (root@Dexter) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)) #2 Wed Nov 7 10:04:17 EST 2001 Nov 9 07:56:09 localhost kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000152 Nov 9 07:56:09 localhost kernel: printing eip: Nov 9 07:56:09 localhost kernel: c01ad5dd Nov 9 07:56:09 localhost kernel: *pde = 00000000 Nov 9 07:56:09 localhost kernel: Oops: 0000 Nov 9 07:56:09 localhost kernel: CPU: 0 Nov 9 07:56:10 localhost kernel: EIP: 0010:[xfs_iget+269/352] Not tainted Nov 9 07:56:10 localhost kernel: EIP: 0010:[] Not tainted Nov 9 07:56:10 localhost kernel: EFLAGS: 00210246 Nov 9 07:56:10 localhost kernel: eax: 00000000 ebx: ffffffe8 ecx: 00000000 edx: c028d1e0 Nov 9 07:56:10 localhost kernel: esi: c076fcb4 edi: c028d1e0 ebp: c076fca0 esp: d0b57e10 Nov 9 07:56:10 localhost kernel: ds: 0018 es: 0018 ss: 0018 Nov 9 07:56:10 localhost kernel: Process ls (pid: 9872, stackpage=d0b57000) Nov 9 07:56:10 localhost kernel: Stack: 00000000 00000000 c1654000 0000004b 0303151b d3ffe2d4 c01c21b7 c1654000 Nov 9 07:56:10 localhost kernel: 00000000 0303151b 00000000 00000000 d0b57e9c 00000000 00000000 00000000 Nov 9 07:56:10 localhost kernel: 00000008 00000018 000001f5 00000306 d3ffe2ec d3ffe2d4 00000008 d4079460 Nov 9 07:56:10 localhost kernel: Call Trace: [xfs_dir_lookup_int+295/704] [xfs_lookup+151/272] [linvfs_lookup+104/192] [real_lookup+79/192] [link_path_walk+1267/1808] Nov 9 07:56:10 localhost kernel: Call Trace: [] [] [] [] [] Nov 9 07:56:10 localhost kernel: [getname+94/160] [__user_walk+51/80] [sys_lstat64+20/112] [error_code+52/60] [system_call+51/56] Nov 9 07:56:10 localhost kernel: [] [] [] [] [] Nov 9 07:56:10 localhost kernel: Nov 9 07:56:10 localhost kernel: Code: 66 83 bb 6a 01 00 00 00 75 1a 0f b7 83 50 01 00 00 25 f7 ff ************************************************************************ ******************************************* This is the linus kernel with the xfs patch from oss.sgi.com: Linux version 2.4.7-xfs (root@Dexter) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)) #2 Wed Oct 31 09:26:08 EST 2001 Nov 9 08:04:24 localhost kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000152 Nov 9 08:04:24 localhost kernel: printing eip: Nov 9 08:04:24 localhost kernel: c01aef5d Nov 9 08:04:24 localhost kernel: *pde = 00000000 Nov 9 08:04:24 localhost kernel: Oops: 0000 Nov 9 08:04:24 localhost kernel: CPU: 0 Nov 9 08:04:24 localhost kernel: EIP: 0010:[xfs_iget+253/336] Nov 9 08:04:24 localhost kernel: EIP: 0010:[] Nov 9 08:04:24 localhost kernel: EFLAGS: 00010246 Nov 9 08:04:24 localhost kernel: eax: d661ab60 ebx: ffffffe8 ecx: d78f4d68 edx: c02a6be0 Nov 9 08:04:24 localhost kernel: esi: 0303151b edi: 00000000 ebp: d661ab4c esp: d4ce9e04 Nov 9 08:04:24 localhost kernel: ds: 0018 es: 0018 ss: 0018 Nov 9 08:04:24 localhost kernel: Process rm (pid: 1331, stackpage=d4ce9000) Nov 9 08:04:24 localhost kernel: Stack: 00000000 00000000 c17f0000 0000011c 0303151b d4cca964 c01c4467 c17f0000 Nov 9 08:04:24 localhost kernel: 00000000 0303151b 00000000 00000000 d4ce9e90 00000000 00000000 00000000 Nov 9 08:04:24 localhost kernel: 00000008 00000018 d4ccbaac 00000000 d4cca97c d4cca964 00000008 d4c4cfe0 Nov 9 08:04:24 localhost kernel: Call Trace: [xfs_dir_lookup_int+295/704] [xfs_lookup+151/272] [linvfs_lookup+104/192] [xfs_access+47/64] [real_lookup+79/192] [path_walk+1425/2016] [zap_page_range+305/608] Nov 9 08:04:24 localhost kernel: Call Trace: [] [] [] [] [] [] [] Nov 9 08:04:24 localhost kernel: [__user_walk+58/96] [sys_lstat64+19/112] [system_call+51/56] Nov 9 08:04:24 localhost kernel: [] [] [] Nov 9 08:04:24 localhost kernel: Nov 9 08:04:24 localhost kernel: Code: 66 83 bb 6a 01 00 00 00 75 1a 0f b7 83 50 01 00 00 25 f7 ff ************************************************************************ *********************************************** This is the linus kernel with the xfs patch from oss.sgi.com: Linux version 2.4.9-xfs (root@Dexter) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)) #3 Wed Nov 7 09:58:40 EST 2001 Nov 9 08:07:28 localhost kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000152 Nov 9 08:07:28 localhost kernel: printing eip: Nov 9 08:07:28 localhost kernel: c01aef7d Nov 9 08:07:28 localhost kernel: *pde = 00000000 Nov 9 08:07:28 localhost kernel: Oops: 0000 Nov 9 08:07:28 localhost kernel: CPU: 0 Nov 9 08:07:28 localhost kernel: EIP: 0010:[xfs_iget+253/336] Nov 9 08:07:28 localhost kernel: EIP: 0010:[] Nov 9 08:07:28 localhost kernel: EFLAGS: 00010246 Nov 9 08:07:28 localhost kernel: eax: d4defb00 ebx: ffffffe8 ecx: c02a4b70 edx: c02a7300 Nov 9 08:07:28 localhost kernel: esi: 0303151b edi: 00000000 ebp: d4defaec esp: d4e39e04 Nov 9 08:07:28 localhost kernel: ds: 0018 es: 0018 ss: 0018 Nov 9 08:07:28 localhost kernel: Process ls (pid: 1265, stackpage=d4e39000) Nov 9 08:07:28 localhost kernel: Stack: 00000000 00000000 c16a0000 00000000 0303151b d4e164c8 c01c4567 c16a0000 Nov 9 08:07:28 localhost kernel: 00000000 0303151b 00000000 00000000 d4e39e90 00000000 00000000 00000000 Nov 9 08:07:28 localhost kernel: 00000008 00000018 d4e47cec 00000000 d4e164e0 d4e164c8 00000008 d63d8ce0 Nov 9 08:07:28 localhost kernel: Call Trace: [xfs_dir_lookup_int+295/704] [xfs_lookup+151/272] [linvfs_lookup+104/192] [xfs_access+47/64] [real_lookup+79/192] Nov 9 08:07:28 localhost kernel: Call Trace: [] [] [] [] [] Nov 9 08:07:28 localhost kernel: [path_walk+1425/2016] [__user_walk+58/96] [sys_lstat64+19/112] [system_call+51/56] Nov 9 08:07:28 localhost kernel: [] [] [] [] Nov 9 08:07:28 localhost kernel: Nov 9 08:07:28 localhost kernel: Code: 66 83 bb 6a 01 00 00 00 75 1a 0f b7 83 50 01 00 00 25 f7 ff Hardware is a Dell Latitude C600 Laptop 1GHz P3 384MB RAM 18GB disk. Thanks, Jeff Hengesbach Vantico Inc. USA Unix Manager 517.324.1581 517.351.9003(Fax) From owner-linux-xfs@oss.sgi.com Fri Nov 9 17:54:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAA1sFp10658 for linux-xfs-outgoing; Fri, 9 Nov 2001 17:54:15 -0800 Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAA1sA010636 for ; Fri, 9 Nov 2001 17:54:10 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 6F38EC00B61 for ; Sat, 10 Nov 2001 09:54:06 +0800 (PHT) Received: from mail.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id ECE64C00B60 for ; Sat, 10 Nov 2001 09:54:04 +0800 (PHT) Date: Sat, 10 Nov 2001 09:54:04 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: XFS and preemptive kernel patch In-Reply-To: <20011109151218.A5600@bee.lk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 9 Nov 2001 at 15:12, Anuradha Ratnaweera wrote: > Is anybody using XFS with preemptive kernel patch? Since I don't have > any "non-production" machines to do a test, any feedback would be very > useful. I've been using Robert M. Love's preempt patches since 2.4.10 I think (or was it 2.4.12?) on workstations and a production server that I run X off often and it's improved responsiveness a lot. On the server I decided not to include RML's patch for 2.4.14 and I noticed the lack of responsiveness during peak hours. I'll put his patch back in when 2.4.15 gets out. ;> So yes, it's great. But only if you'll be using the machine's console. For most other server functions the overall kernel throughput will suffer a bit and really won't be worth it. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Fri Nov 9 19:11:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAA3B8r12276 for linux-xfs-outgoing; Fri, 9 Nov 2001 19:11:08 -0800 Received: from queen.bee.lk (queen.bee.lk [203.143.12.182]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAA3B2012254 for ; Fri, 9 Nov 2001 19:11:03 -0800 Received: from anuradha by queen.bee.lk with local (Exim 3.12 #1 (Debian)) id 162OYG-0000IH-00; Sat, 10 Nov 2001 09:11:24 +0600 Date: Sat, 10 Nov 2001 09:11:24 +0600 From: Anuradha Ratnaweera To: Federico Sevilla III Cc: Linux XFS Mailing List Subject: Re: XFS and preemptive kernel patch Message-ID: <20011110091124.A942@bee.lk> References: <20011109151218.A5600@bee.lk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jijo@leathercollection.ph on Sat, Nov 10, 2001 at 09:54:04AM +0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Nov 10, 2001 at 09:54:04AM +0800, Federico Sevilla III wrote: > > On Fri, 9 Nov 2001 at 15:12, Anuradha Ratnaweera wrote: > > > Is anybody using XFS with preemptive kernel patch? Since I don't have > > any "non-production" machines to do a test, any feedback would be very > > useful. > > So yes, it's great. But only if you'll be using the machine's console. For > most other server functions the overall kernel throughput will suffer a > bit and really won't be worth it. How about using preemptive patch on a firewall, running tranparent proxy (squid/iptables) and also a little bit of qos/fair queuing stuff (includes XFS on software raid 1)? Will try it today and send some feedback. Regards, Anuradha -- Debian GNU/Linux (kernel 2.4.13) Jones' Second Law: The man who smiles when things go wrong has thought of someone to blame it on. From owner-linux-xfs@oss.sgi.com Fri Nov 9 19:29:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAA3T7Z12542 for linux-xfs-outgoing; Fri, 9 Nov 2001 19:29:07 -0800 Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAA3T2012519 for ; Fri, 9 Nov 2001 19:29:02 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 4C75EC00B61 for ; Sat, 10 Nov 2001 11:29:00 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 704F9C00B60 for ; Sat, 10 Nov 2001 11:28:58 +0800 (PHT) Date: Sat, 10 Nov 2001 11:28:58 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: XFS and preemptive kernel patch In-Reply-To: <20011110091124.A942@bee.lk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 10 Nov 2001 at 09:11, Anuradha Ratnaweera wrote: > How about using preemptive patch on a firewall, running tranparent > proxy (squid/iptables) and also a little bit of qos/fair queuing stuff > (includes XFS on software raid 1)? I really don't think it will help much, but then I don't know enough kernel internals (and theory) to be able to give authoritative feedback. I was reading an article about how kernel preemption works, though, and bottomline is with kernel preemption you sacrifice overall kernel throughput for responsiveness that comes from being able to put certain things on hold, switching between kernel tasks very quickly (like applications do). So on a pure server (ie: one that is not used as a console/workstation at the same time) I wouldn't use the kernel preemption patch. On everything else, I would. :) > Will try it today and send some feedback. That'll be great. I'm interested in finding out how it actually performs on a "pure server". :) I wonder: there is a component of preemption that is XFS-centric, and the XFS code is already preemptible. Would the XFS developers have authoritative information on how the performance of XFS varies with preemption enabled on an IO-bound system? --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Fri Nov 9 20:26:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAA4QqM13374 for linux-xfs-outgoing; Fri, 9 Nov 2001 20:26:52 -0800 Received: from queen.bee.lk (queen.bee.lk [203.143.12.182]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAA4Qj013351 for ; Fri, 9 Nov 2001 20:26:46 -0800 Received: from anuradha by queen.bee.lk with local (Exim 3.12 #1 (Debian)) id 162Pja-0000jE-00; Sat, 10 Nov 2001 10:27:10 +0600 Date: Sat, 10 Nov 2001 10:27:10 +0600 From: Anuradha Ratnaweera To: Federico Sevilla III Cc: Linux XFS Mailing List Subject: Re: XFS and preemptive kernel patch Message-ID: <20011110102710.A2703@bee.lk> References: <20011110091124.A942@bee.lk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jijo@leathercollection.ph on Sat, Nov 10, 2001 at 11:28:58AM +0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Nov 10, 2001 at 11:28:58AM +0800, Federico Sevilla III wrote: > On Sat, 10 Nov 2001 at 09:11, Anuradha Ratnaweera wrote: > > How about using preemptive patch on a firewall, running tranparent > > proxy (squid/iptables) and also a little bit of qos/fair queuing stuff > > (includes XFS on software raid 1)? > > [...] > > So on a pure server (ie: one that is not used as a console/workstation at the > same time) I wouldn't use the kernel preemption patch. On everything else, I > would. :) Notice that a "pure" server is very much different from a firewall/router. A firewall with a transparent proxy should be able to switch packets even when loaded by other processes. > > Will try it today and send some feedback. > > That'll be great. I'm interested in finding out how it actually performs > on a "pure server". :) This is not a pure server 8) > I wonder: there is a component of preemption that is XFS-centric, and the XFS > code is already preemptible. Would the XFS developers have authoritative > information on how the performance of XFS varies with preemption enabled on > an IO-bound system? Do you mean XFS code can be preemptible at _kernel_ space? Anuradha -- Debian GNU/Linux (kernel 2.4.13) To kick or not to kick... -- Somewhere on IRC, inspired by Shakespeare From owner-linux-xfs@oss.sgi.com Fri Nov 9 20:37:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAA4baU13660 for linux-xfs-outgoing; Fri, 9 Nov 2001 20:37:36 -0800 Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAA4bV013638 for ; Fri, 9 Nov 2001 20:37:32 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 90CEDC00B61 for ; Sat, 10 Nov 2001 12:37:29 +0800 (PHT) Received: from mail.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id A0C6AC00B60 for ; Sat, 10 Nov 2001 12:37:26 +0800 (PHT) Date: Sat, 10 Nov 2001 12:37:26 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: XFS and preemptive kernel patch In-Reply-To: <20011110102710.A2703@bee.lk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 10 Nov 2001 at 10:27, Anuradha Ratnaweera wrote: > Notice that a "pure" server is very much different from a > firewall/router. A firewall with a transparent proxy should be able > to switch packets even when loaded by other processes. The concept of kernel preemption seemed simple, but it's fine lines like this that boggle me. Or perhaps it's only a fine line to me. Hahaha. I'll take it from you, anyway. :) > Do you mean XFS code can be preemptible at _kernel_ space? I'm not sure, either. As far as I remember the XFS code (kernel space) was modified to be preemptible. Exactly what gets preempted is beyond me. I hope the XFS gurus can help us out with this (maybe this is worth a FAQ entry, Seth?). :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: From owner-linux-xfs@oss.sgi.com Fri Nov 9 20:45:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAA4jXi13863 for linux-xfs-outgoing; Fri, 9 Nov 2001 20:45:33 -0800 Received: from queen.bee.lk (queen.bee.lk [203.143.12.182]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAA4jS013840 for ; Fri, 9 Nov 2001 20:45:29 -0800 Received: from anuradha by queen.bee.lk with local (Exim 3.12 #1 (Debian)) id 162Q1i-00019r-00; Sat, 10 Nov 2001 10:45:54 +0600 Date: Sat, 10 Nov 2001 10:45:54 +0600 From: Anuradha Ratnaweera To: Federico Sevilla III Cc: Linux XFS Mailing List Subject: Re: XFS and preemptive kernel patch Message-ID: <20011110104554.A4402@bee.lk> References: <20011110102710.A2703@bee.lk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jijo@leathercollection.ph on Sat, Nov 10, 2001 at 12:37:26PM +0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Nov 10, 2001 at 12:37:26PM +0800, Federico Sevilla III wrote: > > On Sat, 10 Nov 2001 at 10:27, Anuradha Ratnaweera wrote: > > > Do you mean XFS code can be preemptible at _kernel_ space? > > I'm not sure, either. As far as I remember the XFS code (kernel space) was > modified to be preemptible. Exactly what gets preempted is beyond me. I hope > the XFS gurus can help us out with this (maybe this is worth a FAQ entry, > Seth?). :) When I recently raised the question of XFS not being in the mainstream kernel, it was told that it is touching too much kernel internals, some of which are 2.5 stuff. May be this is one... Any clue? Regards, Anuradha -- Debian GNU/Linux (kernel 2.4.13) Make it idiot-proof, and someone will breed a better idiot. -- Oliver Elphick From owner-linux-xfs@oss.sgi.com Fri Nov 9 21:23:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAA5Nhu14864 for linux-xfs-outgoing; Fri, 9 Nov 2001 21:23:43 -0800 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 fAA5Nd014842 for ; Fri, 9 Nov 2001 21:23:39 -0800 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 VAA14580 for ; Fri, 9 Nov 2001 21:23:29 -0800 (PST) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA32265 for linux-xfs@oss.sgi.com; Sat, 10 Nov 2001 16:22:20 +1100 (EST) Date: Sat, 10 Nov 2001 16:22:20 +1100 (EST) From: Timothy Shimmin Message-Id: <200111100522.QAA32265@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsrestore - allow 255 char pathnames Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Fix end condition on max filename size. --Tim Date: Fri Nov 9 21:21:03 PST 2001 Workarea: snort.melbourne.sgi.com:/hosts/snort/home/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:106496a cmd/xfsdump/restore/tree.c - 1.8 - Allow name to be up to 255 chars instead of 254. cmd/xfsdump/dump/content.c - 1.14 - Be over cautious and make the space for the null terminator explicit. cmd/xfsdump/restore/content.c - 1.17 - Allow name to be up to 255 chars instead of 254. From owner-linux-xfs@oss.sgi.com Sat Nov 10 00:36:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAA8aHQ18036 for linux-xfs-outgoing; Sat, 10 Nov 2001 00:36:17 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAA8aB018013 for ; Sat, 10 Nov 2001 00:36:11 -0800 Received: (qmail 18184 invoked from network); 10 Nov 2001 08:36:07 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 10 Nov 2001 08:36:07 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 61BF6300095; Sat, 10 Nov 2001 19:36:05 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 0C6C096; Sat, 10 Nov 2001 19:36:04 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Announce: XFS split patches for 2.4.7 to 2.4.14 Date: Sat, 10 Nov 2001 19:35:59 +1100 Message-ID: <14840.1005381359@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii ftp://oss.sgi.com/projects/xfs/download/patches/ 2.4.7 through 2.4.14. For some time the XFS group have been producing split patches for XFS, separating the core XFS changes from additional patches such as kdb, lvm, acl, kbuild 2.5. These patches were initially intended for internal use and for feeding to Linus but we got no response at all. The split patches are now being released to the world with the hope that developers and distributors will find them useful. Read the README in each directory very carefully, the split patch format has changed over a few kernel releases. Any questions that are covered by the README will be ignored. There is even a 2.4.15/README for the terminally impatient :). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE77Obsi4UHNye0ZOoRAnQ1AKD2cXKpRc0o+On2nxyNKnSipTdtBQCg5WFK 3qte7lgdeHESWh50njfLC/s= =uxZg -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sat Nov 10 02:38:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAAAcZS19675 for linux-xfs-outgoing; Sat, 10 Nov 2001 02:38:35 -0800 Received: from mail.uulogic.com ([203.112.145.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAAAcQ019653 for ; Sat, 10 Nov 2001 02:38:28 -0800 Received: from uulogic.com (sanat.uulogic.com [192.168.1.72]) by mail.uulogic.com (8.11.0/8.11.0) with ESMTP id fAAAZKr00538 for ; Sat, 10 Nov 2001 16:05:20 +0530 Message-ID: <3BED94DE.B2596A8E@uulogic.com> Date: Sat, 10 Nov 2001 15:58:06 -0500 From: Sanat Mohanty X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: kickstart mkfs.xfs error Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I'm using RH7.1-SGI-XFS-1.0.1.iso for installing xfs based Red Hat systems. I'm using the kickstart methord of installation. My ks.cfg file contains the the followings for "part " entry. #--------------------------------# part / --size 3000 --fs xfs part swap --size 256 part /home --size 10000 --fs xfs --grow # My disk is a 20GB IDE #----------------------------------------------# The kickstart installation starts after making the above partitions it shows me a error dialog box giving the following error: Errot mounting device hda6 as / : No such device. Reboot your system. Again in the Alt+F5 windows it showing the following error message. mkfs.xfs: Warning - cannot set blocksize on block device /tmp/hda6 : Input/output error Same for /tmp/hda5, tmp/hda1 I don't know what is the problem . Please help me. If I install manually every thing works fine. rgds Sanat -- Sanat Mohanty Exaband (India) Pvt.ltd. AP India From owner-linux-xfs@oss.sgi.com Sat Nov 10 04:11:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAACBnF21286 for linux-xfs-outgoing; Sat, 10 Nov 2001 04:11:49 -0800 Received: from ente.berdmann.de (frnk-d514e1c9.dsl.mediaWays.net [213.20.225.201]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAACBX021260 for ; Sat, 10 Nov 2001 04:11:33 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 162Wyt-0001Tn-00 for linux-xfs@oss.sgi.com; Sat, 10 Nov 2001 13:11:27 +0100 Message-ID: <3BED196E.A6E54BED@berdmann.de> Date: Sat, 10 Nov 2001 13:11:26 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.14-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Linux XFS Mailing List Subject: Re: xfsdump/xfsrestore trash hardlinks References: <3BEC19A2.A59C9659@berdmann.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I've some more tests to verify xfsrestore trashing hard links. A filesystem mounted on /usr was xfsdumped up to level 2: $ amadmin be info ente /usr Current info for ente /usr: Stats: dump rates (kps), Full: 2724.0, 1300.0, 2625.0 Incremental: 1177.0, 3.0, 1.0 compressed size, Full: 34.0%, 34.0%, 34.5% Incremental: 18.6%, 18.7%, 18.7% Dumps: lev datestmp tape file origK compK secs 0 20011104 BE04 26 2206768 2206784 810 1 20011107 BE07 32 210488 210496 1387 2 20011110 BE10 30 247297 247328 210 These dump images were restored to /scratch/usr in cumulative mode : # mkdir /scratch/usr # cd /scratch/usr # amrestore -p $TAPE |xfsrestore -r -v 3 - . > ../debug.0 # amrestore -p $TAPE |xfsrestore -r -v 4 - . > ../debug.1 # amrestore -p $TAPE |xfsrestore -r -v 4 - . > ../debug.2 Again, one link of emacs is gone: # ll /usr/bin/emacs /scratch/usr/bin/emacs -rwxr-xr-x 1 root root 4001044 Jun 13 2000 /scratch/usr/bin/emacs -rwxr-xr-x 2 root root 4001044 Jun 13 2000 /usr/bin/emacs I used find to get files with a link counter > 1 (hard links) on the original filesystem and on the restored filesystem: # cd /usr # find . -type f -links +1 > /scratch/_usr.hardlinks # cd /scratch/usr # find . -type f -links +1 > /scratch/_usr_restored.hardlinks # ll /scratch/_usr* -rw-r--r-- 1 root root 77628 Nov 10 11:27 /scratch/_usr.hardlinks -rw-r--r-- 1 root root 77628 Nov 10 11:30 /scratch/_usr.hardlinks.sorted -rw-r--r-- 1 root root 59959 Nov 10 11:28 /scratch/_usr_restored.hardlinks -rw-r--r-- 1 root root 59959 Nov 10 11:30 /scratch/_usr_restored.hardlinks.sorted # diff -u _usr.hardlinks.sorted _usr_restored.hardlinks.sorted --- _usr.hardlinks.sorted Sat Nov 10 11:30:05 2001 +++ _usr_restored.hardlinks.sorted Sat Nov 10 11:30:14 2001 @@ -1,35 +1,3 @@ -./X11R6/bin/nxterm -./X11R6/bin/xterm -./bin/c++ -./bin/c++decl -./bin/c2ph -./bin/cdecl -./bin/egcs -./bin/emacs -./bin/emacs-20.7 -./bin/flist -./bin/flists -./bin/folder -./bin/folders -./bin/g++ -./bin/gcc -./bin/gitregrep -./bin/gitrfgrep -./bin/gitrgrep -./bin/i386-glibc20-linux-c++ -./bin/i386-glibc20-linux-g++ -./bin/i386-redhat-linux-gcc -./bin/next -./bin/perl -./bin/perl5.00503 -./bin/prev -./bin/pstruct -./bin/python -./bin/python1.5 -./bin/rb -./bin/rx -./bin/rz -./bin/sb ./bin/sgml2html ./bin/sgml2info ./bin/sgml2latex @@ -38,18 +6,6 @@ ./bin/sgml2txt [...lots of lines following...] # diff -u _usr.hardlinks.sorted _usr_restored.hardlinks.sorted | wc -l 687 Maybe XFS developers don't like people using emacs and perl? ;-) But what's the difference between /usr/bin/emacs (one of two links is deleted) and /usr/bin/sgml2html (which is restored correctly)? # ll /usr/bin/sgml2html /scratch/usr/bin/sgml2html -rwxr-xr-x 8 root root 790 Mar 9 2001 /scratch/usr/bin/sgml2html -rwxr-xr-x 8 root root 790 Mar 9 2001 /usr/bin/sgml2html Let's have a quick check about the link counter distribution in the two filesystems: # for i in 1 2 3 4 5 6 7 8 9; do > echo -n "files with link counter = $i : " > find /usr -type f -links $i | wc -l > done files with link counter = 1 : 90355 files with link counter = 2 : 1208 files with link counter = 3 : 627 files with link counter = 4 : 268 files with link counter = 5 : 215 files with link counter = 6 : 48 files with link counter = 7 : 70 files with link counter = 8 : 56 files with link counter = 9 : 27 # for i in 1 2 3 4 5 6 7 8 9; do > echo -n "files with link counter = $i : " > find /scratch/usr -type f -links $i | wc -l > done files with link counter = 1 : 90535 files with link counter = 2 : 1076 files with link counter = 3 : 489 files with link counter = 4 : 212 files with link counter = 5 : 135 files with link counter = 6 : 36 files with link counter = 7 : 21 files with link counter = 8 : 32 files with link counter = 9 : 0 Some activity was done on /usr this morning, so let's xfsdump in level 3 on the fly (-J) not to interfere with Amanda: # /sbin/xfsdump -J -l 3 - /usr > /dumps/_usr.3.xfsd # cd /scratch/usr # /sbin/xfsrestore -r -v 4 - . < /dumps/_usr.3.xfsd > ../debug.3 # for i in 1 2 3 4 5 6 7 8 9; do > echo -n "files with link counter = $i : " > find /scratch/usr -type f -links $i | wc -l > done files with link counter = 1 : 90504 files with link counter = 2 : 1106 files with link counter = 3 : 513 files with link counter = 4 : 216 files with link counter = 5 : 135 files with link counter = 6 : 36 files with link counter = 7 : 21 files with link counter = 8 : 24 files with link counter = 9 : 0 From owner-linux-xfs@oss.sgi.com Sat Nov 10 05:17:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAADHvm22332 for linux-xfs-outgoing; Sat, 10 Nov 2001 05:17:57 -0800 Received: from ente.berdmann.de (frnk-d514e1c9.dsl.mediaWays.net [213.20.225.201]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAADHI022303 for ; Sat, 10 Nov 2001 05:17:18 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 162Y0W-0001oA-00; Sat, 10 Nov 2001 14:17:12 +0100 Message-ID: <3BED27B6.F853B1E5@berdmann.de> Date: Sat, 10 Nov 2001 14:12:22 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.14-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Timothy Shimmin CC: linux-xfs@oss.sgi.com Subject: Re: TAKE - xfsrestore - allow 255 char pathnames References: <200111100522.QAA32265@snort.melbourne.sgi.com> Content-Type: multipart/mixed; boundary="------------6D9810C6ADA64B3E6A209DE3" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------6D9810C6ADA64B3E6A209DE3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Modid: 2.4.x-xfs:slinx:106496a > cmd/xfsdump/restore/tree.c - 1.8 > - Allow name to be up to 255 chars instead of 254. > > cmd/xfsdump/dump/content.c - 1.14 > - Be over cautious and make the space for the null terminator > explicit. > > cmd/xfsdump/restore/content.c - 1.17 > - Allow name to be up to 255 chars instead of 254. Well done! torture.perl (http://berdmann.dyndns.org/zwicky/testdump.doc.html and http://berdmann.dyndns.org/zwicky/) runs up to pathnames of 4090 bytes. --------------6D9810C6ADA64B3E6A209DE3 Content-Type: text/plain; charset=iso-8859-1; name="results-xfsdump.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="results-xfsdump.txt" # ~be/torture-new/torture.perl First guess at max component length is 255 max path length appears to be 4095 Type a command line which will run a backup program on the dump test dire= ctory: /sbin/xfsdump -J - /mnt/test | (cd /tmp/test; /sbin/xfsrestore - .) Child 1 = /sbin/xfsdump: version 3.0 - Running single-threaded /sbin/xfsrestore: version 3.0 - Running single-threaded /sbin/xfsrestore: searching media for dump /sbin/xfsdump: level 0 dump of apollo:/mnt/test /sbin/xfsdump: dump date: Sat Nov 10 14:01:49 2001 /sbin/xfsdump: session id: cdc3a50a-6b89-4b47-8447-579b82ee597b /sbin/xfsdump: session label: "" /sbin/xfsdump: ino map phase 1: skipping (no subtrees specified) /sbin/xfsdump: ino map phase 2: constructing initial dump list /sbin/xfsdump: ino map phase 3: skipping (no pruning necessary) /sbin/xfsdump: ino map phase 4: skipping (size estimated in phase 2) /sbin/xfsdump: ino map phase 5: skipping (only one dump stream) /sbin/xfsdump: ino map construction complete /sbin/xfsdump: estimated dump size: 6420864 bytes /sbin/xfsdump: creating dump session media file 0 (media 0, file 0) /sbin/xfsdump: dumping ino map /sbin/xfsdump: dumping directories /sbin/xfsrestore: examining media file 0 /sbin/xfsrestore: dump description: = /sbin/xfsrestore: hostname: apollo /sbin/xfsrestore: mount point: /mnt/test /sbin/xfsrestore: volume: /dev/vg01/test /sbin/xfsrestore: session time: Sat Nov 10 14:01:49 2001 /sbin/xfsrestore: level: 0 /sbin/xfsrestore: session label: "" /sbin/xfsrestore: media label: "" /sbin/xfsrestore: file system id: 6d7b26f1-fc06-4810-8fc7-658ae250bb71 /sbin/xfsrestore: session id: cdc3a50a-6b89-4b47-8447-579b82ee597b /sbin/xfsrestore: media id: 490a4d2e-3bf9-4c78-9be0-df4eb2b1d31c /sbin/xfsrestore: searching media for directory dump /sbin/xfsdump: dumping non-directory files /sbin/xfsrestore: reading directories /sbin/xfsrestore: directory post-processing /sbin/xfsrestore: restoring non-directory files /sbin/xfsrestore: WARNING: unable restore ino 262640 gen 1: relative path= name too long (partial junk/DumpTestDir/longfilenames/ddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddd/ddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddd/ddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddd/ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddd/ddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddd/ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddd/ddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddd/239(4090)xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxxxx!) /sbin/xfsrestore: WARNING: unable restore ino 262641 gen 1: relative path= name too long (partial junk/DumpTestDir/longfilenames/ddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddd/ddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddd/ddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddd/ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddd/ddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddd/ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddd/ddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddd/240(4091)xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx!) /sbin/xfsrestore: WARNING: unable restore ino 262642 gen 1: relative path= name too long (partial junk/DumpTestDir/longfilenames/ddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddd/ddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddd/ddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddd/ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddd/ddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddd/ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddd/ddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddd/241(4092)xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx!) /sbin/xfsrestore: WARNING: unable restore ino 262643 gen 1: relative path= name too long (partial junk/DumpTestDir/longfilenames/ddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddd/ddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddd/ddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddd/ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddd/ddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddd/ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddd/ddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddd/242(4093)xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx!) /sbin/xfsrestore: WARNING: unable restore ino 262644 gen 1: relative path= name too long (partial junk/DumpTestDir/longfilenames/ddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddd/ddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddd/ddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddd/ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddd/ddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddd/ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddd/ddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddd/243(4094)xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx!) /sbin/xfsrestore: WARNING: unable restore ino 262645 gen 1: relative path= name too long (partial junk/DumpTestDir/longfilenames/ddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddd/ddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddd/ddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddd/ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddd/ddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddd/ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddd/ddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= dddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd= ddddddddd/244(4095)xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx!) /sbin/xfsdump: ending media file /sbin/xfsdump: media file size 2468856 bytes /sbin/xfsdump: dump size (non-dir files) : 910752 bytes /sbin/xfsdump: dump complete: 47 seconds elapsed /sbin/xfsdump: Dump Status: SUCCESS /sbin/xfsrestore: restore complete: 49 seconds elapsed /sbin/xfsrestore: Restore Status: SUCCESS Backup took 50.00 seconds of clock time and 0.00 seconds of cpu time --------------6D9810C6ADA64B3E6A209DE3-- From owner-linux-xfs@oss.sgi.com Sat Nov 10 06:16:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAAEG0b23149 for linux-xfs-outgoing; Sat, 10 Nov 2001 06:16:00 -0800 Received: from mailout05.sul.t-online.de (mailout05.sul.t-online.com [194.25.134.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAAEFw023127 for ; Sat, 10 Nov 2001 06:15:58 -0800 Received: from fwd04.sul.t-online.de by mailout05.sul.t-online.de with smtp id 162YvM-0008IP-0E; Sat, 10 Nov 2001 15:15:56 +0100 Received: from ernie.sesamstrasse.de (520083570599-0001@[62.226.180.14]) by fmrl04.sul.t-online.com with esmtp id 162YvC-22AyMiC; Sat, 10 Nov 2001 15:15:46 +0100 Received: (from root@localhost) by ernie.sesamstrasse.de (8.9.3/8.9.3/Debian 8.9.3-21) id PAA15494 for linux-xfs@oss.sgi.com; Sat, 10 Nov 2001 15:01:44 +0100 Received: from kruemelmonster (kruemelmonster.sesamstrasse.de [192.168.2.104]) by ernie.sesamstrasse.de (AvMailGate-6.8.0.0) id 15492-05E22ECA; Sat, 10 Nov 2001 15:01:40 +0100 From: "=?iso-8859-1?B?SvZyZyBI5G5zZWw=?=" To: Subject: how to enable quota in fstab Date: Sat, 10 Nov 2001 15:01:40 +0100 Message-ID: <000101c169f0$385c11b0$6802a8c0@sesamstrasse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-AntiVirus: OK (checked by AntiVir Version 6.8.0.3) X-Sender: 520083570599-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hallo, how can I enable quota Support for XFS in /etc/fstab. Is "usrquota/grpquota" like ext2 ? Thanks, Jörg From owner-linux-xfs@oss.sgi.com Sat Nov 10 06:32:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAAEWe923469 for linux-xfs-outgoing; Sat, 10 Nov 2001 06:32:40 -0800 Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAAEWc023445 for ; Sat, 10 Nov 2001 06:32:38 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id AE5F5400E0B; Sat, 10 Nov 2001 09:34:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id A71C3240021F; Sat, 10 Nov 2001 09:34:00 -0500 (EST) Date: Sat, 10 Nov 2001 09:34:00 -0500 (EST) From: Mike Burger To: =?iso-8859-1?B?SvZyZyBI5G5zZWw=?= Cc: Subject: Re: how to enable quota in fstab In-Reply-To: <000101c169f0$385c11b0$6802a8c0@sesamstrasse.de> 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 On Sat, 10 Nov 2001, Jörg Hänsel wrote: > Hallo, > how can I enable quota Support for XFS in /etc/fstab. Is "usrquota/grpquota" > like ext2 ? Yes...but the actual quotas are not controlled by files at the top of the quota'd filesystems. From owner-linux-xfs@oss.sgi.com Sat Nov 10 13:47:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAALlYe31169 for linux-xfs-outgoing; Sat, 10 Nov 2001 13:47:34 -0800 Received: from localhost.localdomain (public-nat.als01.linuxshowcase.org [64.71.175.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAALlV031144 for ; Sat, 10 Nov 2001 13:47:31 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fAALlgd15640; Sat, 10 Nov 2001 13:47:42 -0800 Subject: Re: Undelete in XFS From: Thomas Duffy To: Steve Lord Cc: Chris Tooley , linux-xfs@oss.sgi.com In-Reply-To: <1005258497.9075.22.camel@jen.americas.sgi.com> References: <1005258455.4701.4.camel@itspec.amoa.org> <1005258497.9075.22.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 10 Nov 2001 13:47:42 -0800 Message-Id: <1005428862.15564.0.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2001-11-08 at 14:28, Steve Lord wrote: > Steve (filing evolution bugs as we speak) so Steve, what evolution bugs are there that are XFS specific? I have been banging my head with fejj (one of the main evo developers) about a few bugs I have been seeing and he claimed it must be that I am using a "weird" filesystem -tduffy From owner-linux-xfs@oss.sgi.com Sat Nov 10 16:47:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAB0lDm01641 for linux-xfs-outgoing; Sat, 10 Nov 2001 16:47:13 -0800 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 fAB0l8001617 for ; Sat, 10 Nov 2001 16:47:08 -0800 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 BAA1967880 for ; Sun, 11 Nov 2001 01:47:06 +0100 (CET) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip.americas.sgi.com [128.162.185.208]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA3552002; Sat, 10 Nov 2001 18:45:49 -0600 (CST) Received: from sgi.com (lLjDHz5UYCAMYa8Om1lyY3tapb7wEV0k@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id SAA62086; Sat, 10 Nov 2001 18:45:49 -0600 (CST) Message-ID: <3BEDCA2C.2060700@sgi.com> Date: Sat, 10 Nov 2001 18:45:32 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Thomas Duffy CC: Chris Tooley , linux-xfs@oss.sgi.com Subject: Re: Undelete in XFS References: <1005258455.4701.4.camel@itspec.amoa.org> <1005258497.9075.22.camel@jen.americas.sgi.com> <1005428862.15564.0.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thomas Duffy wrote: >On Thu, 2001-11-08 at 14:28, Steve Lord wrote: > > >>Steve (filing evolution bugs as we speak) >> > >so Steve, what evolution bugs are there that are XFS specific? I have >been banging my head with fejj (one of the main evo developers) about a >few bugs I have been seeing and he claimed it must be that I am using a >"weird" filesystem > >-tduffy > I don't use it on XFS, I use it on NFS. Steve From owner-linux-xfs@oss.sgi.com Sat Nov 10 19:17:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAB3HGo04322 for linux-xfs-outgoing; Sat, 10 Nov 2001 19:17:16 -0800 Received: from corp4.cbn.net.id (corp4.cbn.net.id [202.158.3.28]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAB3HA004300 for ; Sat, 10 Nov 2001 19:17:11 -0800 Received: from navajo.cbn.net.id (unknown [202.158.50.86]) by corp4.cbn.net.id (Postfix) with ESMTP id 7E2D7557D2; Sun, 11 Nov 2001 10:17:03 +0700 (JAVT) Message-Id: <5.1.0.14.2.20011111101759.02a55b70@pop.cbn.net.id> X-Sender: kisanak@pop.cbn.net.id X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 11 Nov 2001 10:18:00 +0700 To: linux-xfs@oss.sgi.com From: kisanak@cbn.net.id Subject: SB validate failed Cc: Steve Lord Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dear All, Steve, There's a problem with my xfs partition (using RAID) while I mount it using: # mount -t xfs /dev/rd/c0d0p1 /home/ mount: wrong fs type, bad option, bad superblock on /dev/rd/c0d0p1, or too many mounted file systems and from /var/log/messages: XFS: bad magic number XFS: SB validate failed # /usr/sbin/xfs_logprint -t /dev/rd/c0d0p1 xfs_logprint: data device: 0x3001 log device: 0x3001 daddr: -919226905192824832 length: 442220544 XFS: Log inconsistent (didn't find previous header) XFS: failed to find log head Any idea how to overcome this problem? Thanks for any help. Regards, Yahya. From owner-linux-xfs@oss.sgi.com Sat Nov 10 20:02:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAB42xc04957 for linux-xfs-outgoing; Sat, 10 Nov 2001 20:02:59 -0800 Received: from corp1.cbn.net.id (corp1.cbn.net.id [202.158.3.24]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAB42r004934 for ; Sat, 10 Nov 2001 20:02:54 -0800 Received: from navajo.cbn.net.id (unknown [202.158.50.86]) by corp1.cbn.net.id (Postfix) with ESMTP id C993368B74; Sun, 11 Nov 2001 09:42:57 +0700 (JAVT) Message-Id: <5.1.0.14.2.20011111094036.03d81ec0@pop.cbn.net.id> X-Sender: kisanak@pop.cbn.net.id X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 11 Nov 2001 09:43:54 +0700 To: linux-xfs@oss.sgi.com From: kisanak@cbn.net.id Subject: SB validate failed Cc: Steve Lord In-Reply-To: <1005428862.15564.0.camel@localhost.localdomain> References: <1005258497.9075.22.camel@jen.americas.sgi.com> <1005258455.4701.4.camel@itspec.amoa.org> <1005258497.9075.22.camel@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 Dear All, Steve, There's a problem with my xfs partition (using RAID) while I mount it using: # mount -t xfs /dev/rd/c0d0p1 /home/ mount: wrong fs type, bad option, bad superblock on /dev/rd/c0d0p1, or too many mounted file systems and from /var/log/messages: XFS: bad magic number XFS: SB validate failed # /usr/sbin/xfs_logprint -t /dev/rd/c0d0p1 xfs_logprint: data device: 0x3001 log device: 0x3001 daddr: -919226905192824832 length: 442220544 XFS: Log inconsistent (didn't find previous header) XFS: failed to find log head Any idea how to overcome this problem? Thanks for any help. Regards, Yahya. From owner-linux-xfs@oss.sgi.com Sun Nov 11 08:30:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fABGUtl20251 for linux-xfs-outgoing; Sun, 11 Nov 2001 08:30:55 -0800 Received: from ente.berdmann.de (frnk-d514e1e6.dsl.mediaWays.net [213.20.225.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fABGUU020228 for ; Sun, 11 Nov 2001 08:30:30 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 162xV2-0007Ty-00 for linux-xfs@oss.sgi.com; Sun, 11 Nov 2001 17:30:24 +0100 Message-ID: <3BEEA79F.9C3643C4@berdmann.de> Date: Sun, 11 Nov 2001 17:30:23 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.14-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Linux XFS Mailing List Subject: Re: xfsdump/xfsrestore trash hardlinks References: <3BEC19A2.A59C9659@berdmann.de> <3BED196E.A6E54BED@berdmann.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm still investigating this hard link story... Now I've got a wonderful reproducible behaviour: each incremental dump with an odd level trashes four of eleven links and each incremental dump with an even level restores the missing four links. The filesystem gets rsync'ed (-aH) to an MRTG (http://www.mrtg.org/) subdirectory tree. Some PNGs (mrtg-{l,m,r,ti}.png) have a link count of 11. In addition, there are eight inodes with a link counter of five and 21 inodes with a link counter of two. Counting the links in the restored filesystem after level 0: # cat hl-count.test2.0 files with link counter = 1 : 624 files with link counter = 2 : 42 files with link counter = 3 : 0 files with link counter = 4 : 0 files with link counter = 5 : 40 files with link counter = 6 : 0 files with link counter = 7 : 0 files with link counter = 8 : 0 files with link counter = 9 : 0 files with link counter = 10 : 0 files with link counter = 11 : 44 files with link counter = 12 : 0 files with link counter = 13 : 0 after having level 1 applied: # cat hl-count.test2.1 files with link counter = 1 : 636 files with link counter = 2 : 18 files with link counter = 3 : 0 files with link counter = 4 : 0 files with link counter = 5 : 40 files with link counter = 6 : 0 files with link counter = 7 : 28 files with link counter = 8 : 0 files with link counter = 9 : 0 files with link counter = 10 : 0 files with link counter = 11 : 0 files with link counter = 12 : 0 files with link counter = 13 : 0 level 2: # cat hl-count.test2.2 files with link counter = 1 : 615 files with link counter = 2 : 32 files with link counter = 3 : 0 files with link counter = 4 : 0 files with link counter = 5 : 40 files with link counter = 6 : 0 files with link counter = 7 : 0 files with link counter = 8 : 0 files with link counter = 9 : 0 files with link counter = 10 : 0 files with link counter = 11 : 44 files with link counter = 12 : 0 files with link counter = 13 : 0 level 3: # cat hl-count.test2.3 files with link counter = 1 : 636 files with link counter = 2 : 18 files with link counter = 3 : 0 files with link counter = 4 : 0 files with link counter = 5 : 40 files with link counter = 6 : 0 files with link counter = 7 : 28 files with link counter = 8 : 0 files with link counter = 9 : 0 files with link counter = 10 : 0 files with link counter = 11 : 0 files with link counter = 12 : 0 files with link counter = 13 : 0 level 4: # cat hl-count.test2.4 files with link counter = 1 : 629 files with link counter = 2 : 32 files with link counter = 3 : 0 files with link counter = 4 : 0 files with link counter = 5 : 40 files with link counter = 6 : 0 files with link counter = 7 : 0 files with link counter = 8 : 0 files with link counter = 9 : 0 files with link counter = 10 : 0 files with link counter = 11 : 44 files with link counter = 12 : 0 files with link counter = 13 : 0 I'll concentrate on the file mrtg/apollo/mrtg-l.png (inode no. 786583). Some output from xfsrestore -r -v 4 in the different levels: level 0: /sbin/xfsrestore: dirent mrtg-l.png 786583 1: adding (new) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: adding (link) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: adding (link) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: adding (link) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: adding (link) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: adding (link) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: adding (link) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: adding (link) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: adding (link) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: adding (link) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: adding (link) /sbin/xfsrestore: restoring mrtg/ente/mrtg-l.png (786583 1) /sbin/xfsrestore: restoring regular file ino 786583 mrtg/ente/mrtg-l.png /sbin/xfsrestore: truncating mrtg/ente/mrtg-l.png from 0 to 538 /sbin/xfsrestore: link mrtg/ente/mrtg-l.png to mrtg/squid/mrtg-l.png (786583 1) /sbin/xfsrestore: linking mrtg/ente/mrtg-l.png to mrtg/squid/mrtg-l.png /sbin/xfsrestore: link mrtg/ente/mrtg-l.png to mrtg/i12/mrtg-l.png (786583 1) /sbin/xfsrestore: linking mrtg/ente/mrtg-l.png to mrtg/i12/mrtg-l.png /sbin/xfsrestore: link mrtg/ente/mrtg-l.png to mrtg/james/mrtg-l.png (786583 1) /sbin/xfsrestore: linking mrtg/ente/mrtg-l.png to mrtg/james/mrtg-l.png /sbin/xfsrestore: link mrtg/ente/mrtg-l.png to mrtg/kpnqwest/mrtg-l.png (786583 1) /sbin/xfsrestore: linking mrtg/ente/mrtg-l.png to mrtg/kpnqwest/mrtg-l.png /sbin/xfsrestore: link mrtg/ente/mrtg-l.png to mrtg/kpnqwest/194.122.243.116/mrtg-l.png (786583 1) /sbin/xfsrestore: linking mrtg/ente/mrtg-l.png to mrtg/kpnqwest/194.122.243.116/mrtg-l.png /sbin/xfsrestore: link mrtg/ente/mrtg-l.png to mrtg/kpnqwest/194.122.243.205/mrtg-l.png (786583 1) /sbin/xfsrestore: linking mrtg/ente/mrtg-l.png to mrtg/kpnqwest/194.122.243.205/mrtg-l.png /sbin/xfsrestore: link mrtg/ente/mrtg-l.png to mrtg/139.4.65.66/mrtg-l.png (786583 1) /sbin/xfsrestore: linking mrtg/ente/mrtg-l.png to mrtg/139.4.65.66/mrtg-l.png /sbin/xfsrestore: link mrtg/ente/mrtg-l.png to mrtg/kpnqwest/194.122.243.206/mrtg-l.png (786583 1) /sbin/xfsrestore: linking mrtg/ente/mrtg-l.png to mrtg/kpnqwest/194.122.243.206/mrtg-l.png /sbin/xfsrestore: link mrtg/ente/mrtg-l.png to mrtg/apollo/mrtg-l.png (786583 1)/sbin/xfsrestore: linking mrtg/ente/mrtg-l.png to mrtg/apollo/mrtg-l.png /sbin/xfsrestore: link mrtg/ente/mrtg-l.png to mrtg/kpnqwest/194.122.243.98/mrtg-l.png (786583 1) /sbin/xfsrestore: linking mrtg/ente/mrtg-l.png to mrtg/kpnqwest/194.122.243.98/mrtg-l.png level 1: /sbin/xfsrestore: dirent mrtg-l.png 786583 1: retaining (nondir) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: retaining (nondir) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: retaining (nondir) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: retaining (nondir) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: retaining (nondir) /sbin/xfsrestore: unlink mrtg/squid/mrtg-l.png /sbin/xfsrestore: unlink mrtg/james/mrtg-l.png /sbin/xfsrestore: unlink mrtg/i12/mrtg-l.png /sbin/xfsrestore: unlink mrtg/apollo/mrtg-l.png /sbin/xfsrestore: processing hardlinks to 786583 1 /sbin/xfsrestore: skipping node 1000001f: real and ref /sbin/xfsrestore: node 1000001f will be link src /sbin/xfsrestore: skipping node 1000015e: real and ref /sbin/xfsrestore: skipping node 10000175: real and ref /sbin/xfsrestore: skipping node 100001a6: real and ref /sbin/xfsrestore: skipping node 100001ee: real and ref /sbin/xfsrestore: skipping node 10000208: real and ref /sbin/xfsrestore: skipping node 100002c6: real and ref level 2: /sbin/xfsrestore: dirent mrtg-l.png 786583 1: retaining (nondir) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: adding (link) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: adding (link) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: adding (link) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: adding (link) /sbin/xfsrestore: link nondir mrtg/ente/mrtg-l.png to mrtg/apollo/mrtg-l.png /sbin/xfsrestore: link nondir mrtg/ente/mrtg-l.png to mrtg/james/mrtg-l.png /sbin/xfsrestore: link nondir mrtg/ente/mrtg-l.png to mrtg/i12/mrtg-l.png /sbin/xfsrestore: link nondir mrtg/ente/mrtg-l.png to mrtg/squid/mrtg-l.png /sbin/xfsrestore: processing hardlinks to 786583 1 /sbin/xfsrestore: skipping node 1000001f: real and ref /sbin/xfsrestore: node 1000001f will be link src /sbin/xfsrestore: skipping node 1000015e: real and ref /sbin/xfsrestore: skipping node 10000175: real and ref /sbin/xfsrestore: skipping node 100001a6: real and ref /sbin/xfsrestore: skipping node 100001ee: real and ref /sbin/xfsrestore: skipping node 10000208: real and ref /sbin/xfsrestore: skipping node 100002c6: real and ref /sbin/xfsrestore: making node 10000229 dst: not real, refed, sel /sbin/xfsrestore: making node 1000004c dst: not real, refed, sel /sbin/xfsrestore: making node 100000e3 dst: not real, refed, sel /sbin/xfsrestore: making node 1000022f dst: not real, refed, sel /sbin/xfsrestore: link nondir mrtg/ente/mrtg-l.png to mrtg/apollo/mrtg-l.png /sbin/xfsrestore: link nondir mrtg/ente/mrtg-l.png to mrtg/james/mrtg-l.png /sbin/xfsrestore: link nondir mrtg/ente/mrtg-l.png to mrtg/i12/mrtg-l.png /sbin/xfsrestore: link nondir mrtg/ente/mrtg-l.png to mrtg/squid/mrtg-l.png level 3: /sbin/xfsrestore: dirent mrtg-l.png 786583 1: retaining (nondir) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: retaining (nondir) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: retaining (nondir) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: retaining (nondir) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: retaining (nondir) /sbin/xfsrestore: unlink mrtg/squid/mrtg-l.png /sbin/xfsrestore: unlink mrtg/james/mrtg-l.png /sbin/xfsrestore: unlink mrtg/i12/mrtg-l.png /sbin/xfsrestore: unlink mrtg/apollo/mrtg-l.png /sbin/xfsrestore: processing hardlinks to 786583 1 /sbin/xfsrestore: skipping node 1000001f: real and ref /sbin/xfsrestore: node 1000001f will be link src /sbin/xfsrestore: skipping node 1000015e: real and ref /sbin/xfsrestore: skipping node 10000175: real and ref /sbin/xfsrestore: skipping node 100001a6: real and ref /sbin/xfsrestore: skipping node 100001ee: real and ref /sbin/xfsrestore: skipping node 10000208: real and ref /sbin/xfsrestore: skipping node 100002c6: real and ref level 4: /sbin/xfsrestore: dirent mrtg-l.png 786583 1: retaining (nondir) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: adding (link) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: adding (link) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: adding (link) /sbin/xfsrestore: dirent mrtg-l.png 786583 1: adding (link) /sbin/xfsrestore: link nondir mrtg/ente/mrtg-l.png to mrtg/apollo/mrtg-l.png /sbin/xfsrestore: link nondir mrtg/ente/mrtg-l.png to mrtg/james/mrtg-l.png /sbin/xfsrestore: link nondir mrtg/ente/mrtg-l.png to mrtg/i12/mrtg-l.png /sbin/xfsrestore: link nondir mrtg/ente/mrtg-l.png to mrtg/squid/mrtg-l.png /sbin/xfsrestore: processing hardlinks to 786583 1 /sbin/xfsrestore: skipping node 1000001f: real and ref /sbin/xfsrestore: node 1000001f will be link src /sbin/xfsrestore: skipping node 1000015e: real and ref /sbin/xfsrestore: skipping node 10000175: real and ref /sbin/xfsrestore: skipping node 100001a6: real and ref /sbin/xfsrestore: skipping node 100001ee: real and ref /sbin/xfsrestore: skipping node 10000208: real and ref /sbin/xfsrestore: skipping node 100002c6: real and ref /sbin/xfsrestore: making node 100000b5 dst: not real, refed, sel /sbin/xfsrestore: making node 10000129 dst: not real, refed, sel /sbin/xfsrestore: making node 1000011d dst: not real, refed, sel /sbin/xfsrestore: making node 10000036 dst: not real, refed, sel /sbin/xfsrestore: link nondir mrtg/ente/mrtg-l.png to mrtg/apollo/mrtg-l.png /sbin/xfsrestore: link nondir mrtg/ente/mrtg-l.png to mrtg/james/mrtg-l.png /sbin/xfsrestore: link nondir mrtg/ente/mrtg-l.png to mrtg/i12/mrtg-l.png /sbin/xfsrestore: link nondir mrtg/ente/mrtg-l.png to mrtg/squid/mrtg-l.png From owner-linux-xfs@oss.sgi.com Sun Nov 11 09:42:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fABHghn21367 for linux-xfs-outgoing; Sun, 11 Nov 2001 09:42:43 -0800 Received: from ente.berdmann.de (frnk-d514e112.dsl.mediaWays.net [213.20.225.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fABHge021342 for ; Sun, 11 Nov 2001 09:42:41 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 162ycs-0007vu-00 for linux-xfs@oss.sgi.com; Sun, 11 Nov 2001 18:42:34 +0100 Message-ID: <3BEEB88A.6EBD617B@berdmann.de> Date: Sun, 11 Nov 2001 18:42:34 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.14-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Linux XFS Mailing List Subject: Re: xfsdump/xfsrestore trash hardlinks References: <3BEC19A2.A59C9659@berdmann.de> <3BED196E.A6E54BED@berdmann.de> <3BEEA79F.9C3643C4@berdmann.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Now I've got a wonderful reproducible behaviour: each incremental dump > with an odd level trashes four of eleven links and each incremental dump > with an even level restores the missing four links. You can get all the debug files from http://berdmann.dyndns.org/xfsdump/debug-hardlinks/test2/ (please see README). From owner-linux-xfs@oss.sgi.com Sun Nov 11 15:24:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fABNOtf00892 for linux-xfs-outgoing; Sun, 11 Nov 2001 15:24:55 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fABNOe000869 for ; Sun, 11 Nov 2001 15:24:42 -0800 Received: from matrix01.home.net.pl (matrix01.home.net.pl [212.85.112.31]) 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 OAA06970 for ; Sun, 11 Nov 2001 14:10:50 -0800 (PST) mail_from (skaarj@post.pl) Received: from pa171.gdansk.cvx.ppp.tpnet.pl (213.76.24.171) by matrix01.home.net.pl with SMTP; 11 Nov 2001 22:11:35 -0000 Date: Sun, 11 Nov 2001 23:08:21 +0100 (CET) From: X-X-Sender: Reply-To: Qba To: Subject: problem with configuring the kernel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am trying to do make menuconfig in the lates cvs snapshot of linux-2.4-xfs kernel source but I get a message like this: root@skaarj:/usr/src/linux[66]#make menuconfig rm -f include/asm ( cd include ; ln -sf asm-i386 asm) make -C scripts/lxdialog all make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux/scripts/lxdialog' gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -DLOCALE -I/usr/include/ncurses -DCURSES_LOC="" -c -o checklist.o checklist.c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -DLOCALE -I/usr/include/ncurses -DCURSES_LOC="" -c -o menubox.o menubox.c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -DLOCALE -I/usr/include/ncurses -DCURSES_LOC="" -c -o textbox.o textbox.c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -DLOCALE -I/usr/include/ncurses -DCURSES_LOC="" -c -o yesno.o yesno.c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -DLOCALE -I/usr/include/ncurses -DCURSES_LOC="" -c -o inputbox.o inputbox.c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -DLOCALE -I/usr/include/ncurses -DCURSES_LOC="" -c -o util.o util.c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -DLOCALE -I/usr/include/ncurses -DCURSES_LOC="" -c -o lxdialog.o lxdialog.c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -DLOCALE -I/usr/include/ncurses -DCURSES_LOC="" -c -o msgbox.o msgbox.c gcc -o lxdialog checklist.o menubox.o textbox.o yesno.o inputbox.o util.o lxdialog.o msgbox.o -lncurses make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/scripts/lxdialog' /bin/sh scripts/Menuconfig arch/i386/config.in Using defaults found in arch/i386/defconfig Preparing scripts: functions, parsingscripts/Menuconfig: line 1: 15334 Segmentation fault awk "$1" ult awk "$1" Awk died with error code 139. Giving up. ........scripts/Menuconfig: ./MCmenu15: line 109: unexpected EOF while looking for matching `'' scripts/Menuconfig: ./MCmenu15: line 110: syntax error: unexpected end of file .scripts/Menuconfig: ./MCmenu16: line 80: syntax error: unexpected end of file ......scripts/Menuconfig: ./MCmenu21: line 121: unexpected EOF while looking for matching `'' scripts/Menuconfig: ./MCmenu21: line 122: syntax error: unexpected end of file ..scripts/Menuconfig: ./MCmenu23: line 154: unexpected EOF while looking for matching `'' scripts/Menuconfig: ./MCmenu23: line 155: syntax error: unexpected end of file ....scripts/Menuconfig: ./MCmenu3: line 123: unexpected EOF while looking for matching `'' scripts/Menuconfig: ./MCmenu3: line 124: syntax error: unexpected end of file ......done. Your kernel configuration changes were NOT saved. This is a full and untouched log from the console... Best regards Qba From owner-linux-xfs@oss.sgi.com Sun Nov 11 15:35:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fABNZgb01124 for linux-xfs-outgoing; Sun, 11 Nov 2001 15:35:42 -0800 Received: from ente.berdmann.de (frnk-d514e112.dsl.mediaWays.net [213.20.225.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fABNZd001101 for ; Sun, 11 Nov 2001 15:35:40 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16348Q-0001lq-00; Mon, 12 Nov 2001 00:35:30 +0100 Message-ID: <3BEF0B41.F796A373@berdmann.de> Date: Mon, 12 Nov 2001 00:35:29 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.14-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Qba CC: linux-xfs@oss.sgi.com Subject: Re: problem with configuring the kernel References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Preparing scripts: functions, parsingscripts/Menuconfig: line 1: 15334 > Segmentation fault awk "$1" > ult awk "$1" > Awk died with error code 139. Giving up. "rpm -V gawk" Same days ago I had a very strange system. In the end, it was a corrupted /bin/sed core dumping all the time... From owner-linux-xfs@oss.sgi.com Sun Nov 11 16:06:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAC06DW01750 for linux-xfs-outgoing; Sun, 11 Nov 2001 16:06:13 -0800 Received: from mailout05.sul.t-online.de (mailout05.sul.t-online.com [194.25.134.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAC069001727 for ; Sun, 11 Nov 2001 16:06:10 -0800 Received: from fwd03.sul.t-online.de by mailout05.sul.t-online.de with smtp id 1634bz-0002zS-09; Mon, 12 Nov 2001 01:06:03 +0100 Received: from mail.pruessmann.org (320092775964-0001@[217.227.55.27]) by fmrl03.sul.t-online.com with esmtp id 1634bx-2ANPnMC; Mon, 12 Nov 2001 01:06:01 +0100 Received: by mail.pruessmann.org (Postfix, from userid 501) id 0F2C2400E4A; Mon, 12 Nov 2001 01:05:28 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.pruessmann.org (Postfix) with ESMTP id DAC3CCC533B for ; Mon, 12 Nov 2001 01:05:28 +0100 (CET) Date: Mon, 12 Nov 2001 01:05:28 +0100 (CET) From: Boris Pruessmann X-X-Sender: To: Subject: fs corrupt ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sender: 320092775964-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi ! After rebooting my system, mounting my xfs partition fails with the following message in the log: XFS: Log inconsistent (didn't find previous header) XFS: empty log check failed I am using kernel 2.4.14, the filesystem is on an hw raid0 device (HPT370) consisting of two IBM 45GB hd. Any recommendations are greatly appreciated since xfs_repair fails with the same message. Best regards, Boris -- From owner-linux-xfs@oss.sgi.com Sun Nov 11 17:36:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAC1aK904028 for linux-xfs-outgoing; Sun, 11 Nov 2001 17:36:20 -0800 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 fAC1aG004005 for ; Sun, 11 Nov 2001 17:36:16 -0800 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 RAA14015 for ; Sun, 11 Nov 2001 17:36:07 -0800 (PST) mail_from (ivanr@sgi.com) From: ivanr@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 MAA01370; Mon, 12 Nov 2001 12:34:55 +1100 Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id MAA74769; Mon, 12 Nov 2001 12:34:55 +1100 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Mon, 12 Nov 2001 12:34:54 +1100 X-X-Sender: ivanr@omen.melbourne.sgi.com To: "Bernhard R. Erdmann" cc: Linux XFS Mailing List Subject: Re: xfsdump/xfsrestore trash hardlinks In-Reply-To: <3BEEB88A.6EBD617B@berdmann.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, 11 Nov 2001, Bernhard R. Erdmann wrote: > > Now I've got a wonderful reproducible behaviour: each incremental dump > > with an odd level trashes four of eleven links and each incremental dump > > with an even level restores the missing four links. > > You can get all the debug files from > http://berdmann.dyndns.org/xfsdump/debug-hardlinks/test2/ > (please see README). Just to let you know ... we're not ignoring you. We'll investigate this as soon as we get the chance. It certainly has the potential to be a serious problem. Thanks for your reports. Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Sun Nov 11 18:21:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAC2LoE04946 for linux-xfs-outgoing; Sun, 11 Nov 2001 18:21:50 -0800 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 fAC2Lk004924 for ; Sun, 11 Nov 2001 18:21:47 -0800 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 DAA2212637 for ; Mon, 12 Nov 2001 03:21:43 +0100 (CET) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA55062; Mon, 12 Nov 2001 13:20:24 +1100 (AEDT) Date: Mon, 12 Nov 2001 13:20:24 +1100 From: Timothy Shimmin To: Chris Tooley Cc: linux-xfs@oss.sgi.com Subject: Re: Undelete in XFS Message-ID: <20011112132023.I52179@boing.melbourne.sgi.com> References: <1005258455.4701.4.camel@itspec.amoa.org> <1005258497.9075.22.camel@jen.americas.sgi.com> <1005259546.5742.9.camel@itspec.amoa.org> <1005261542.9077.29.camel@jen.americas.sgi.com> <3BEB1829.5F5C3D2@idcomm.com> <1005313547.6876.7.camel@itspec.amoa.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <1005313547.6876.7.camel@itspec.amoa.org>; from ctooley@amoa.org on Fri, Nov 09, 2001 at 07:45:43AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Nov 09, 2001 at 07:45:43AM -0600, Chris Tooley wrote: > As I've never used dump and restore (gasp, amazement, pity) I'll just > ask my question. Could I move just /usr or /home with dump/restore, or > is it partition based? > You can specify sub-directories with the -s option (see xfsdump(8)). (Don't forget that the subdir path should be specified relative to the mount point). --Tim From owner-linux-xfs@oss.sgi.com Sun Nov 11 21:03:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAC53l808826 for linux-xfs-outgoing; Sun, 11 Nov 2001 21:03:47 -0800 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 fAC53e008804 for ; Sun, 11 Nov 2001 21:03:40 -0800 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 VAA07659 for ; Sun, 11 Nov 2001 21:03:15 -0800 (PST) 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 QAA02248; Mon, 12 Nov 2001 16:02:12 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA12476; Mon, 12 Nov 2001 16:01:59 +1100 (AEDT) Date: Mon, 12 Nov 2001 16:01:59 +1100 From: Nathan Scott To: Linus Torvalds , Alan Cox , Andi Kleen , Andreas Gruenbacher Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [RFC][PATCH] extended attributes Message-ID: <20011112160159.F583135@wobbly.melbourne.sgi.com> References: <20011107111224.C591676@wobbly.melbourne.sgi.com> <20011107023218.A4754@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011107023218.A4754@wotan.suse.de>; from ak@suse.de on Wed, Nov 07, 2001 at 02:32:18AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Nov 07, 2001 at 02:32:18AM +0100, Andi Kleen wrote: > On Wed, Nov 07, 2001 at 11:12:24AM +1100, Nathan Scott wrote: > > A manual page describing the system call interface can be found here[4]. > > We're very interested in feedback on this. In particular, Linus - would > > The cursor support looks quite complicated. ... > Stateless cursors are just nasty! > ... hi folks, We've removed the cursor operations, and gone back to Andreas' original, simpler list approach. Revised versions of the two extattr man pages are in the XFS CVS repository, or use: http://acl.bestbits.at/man/extattr.2.html http://acl.bestbits.at/man/extattr.5.html I notice that 2.4.15-pre3 doesn't have the patch below - Linus, Alan, could you please apply it? - it will help us a great deal. This would be useful to the ext2/ext3, InterMezzo/SnapFS, NTFS, XFS, JFS and BeFS filesystem implementations for Linux, and to any other filesystems planning to support extended attributes in the future as well. many thanks. -- Nathan diff -Naur 2.4.14-pristine/arch/i386/kernel/entry.S 2.4.14-reserved/arch/i386/kernel/entry.S --- 2.4.14-pristine/arch/i386/kernel/entry.S Sat Nov 3 12:18:49 2001 +++ 2.4.14-reserved/arch/i386/kernel/entry.S Wed Nov 7 10:02:59 2001 @@ -622,6 +622,9 @@ .long SYMBOL_NAME(sys_ni_syscall) /* Reserved for Security */ .long SYMBOL_NAME(sys_gettid) .long SYMBOL_NAME(sys_readahead) /* 225 */ + .long SYMBOL_NAME(sys_ni_syscall) /* reserved for extattr */ + .long SYMBOL_NAME(sys_ni_syscall) /* reserved for lextattr */ + .long SYMBOL_NAME(sys_ni_syscall) /* reserved for fextattr */ .rept NR_syscalls-(.-sys_call_table)/4 .long SYMBOL_NAME(sys_ni_syscall) diff -Naur 2.4.14-pristine/include/asm-i386/unistd.h 2.4.14-reserved/include/asm-i386/unistd.h --- 2.4.14-pristine/include/asm-i386/unistd.h Thu Oct 18 03:03:03 2001 +++ 2.4.14-reserved/include/asm-i386/unistd.h Wed Nov 7 10:02:59 2001 @@ -230,6 +230,9 @@ #define __NR_security 223 /* syscall for security modules */ #define __NR_gettid 224 #define __NR_readahead 225 +#define __NR_extattr 226 /* syscall for extended attributes */ +#define __NR_lextattr 227 /* syscall for extended attributes */ +#define __NR_fextattr 228 /* syscall for extended attributes */ /* user-visible error numbers are in the range -1 - -124: see */ From owner-linux-xfs@oss.sgi.com Sun Nov 11 22:24:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAC6Ogm10776 for linux-xfs-outgoing; Sun, 11 Nov 2001 22:24:42 -0800 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 fAC6N0010740 for ; Sun, 11 Nov 2001 22:23:00 -0800 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 WAA03038 for ; Sun, 11 Nov 2001 22:22:51 -0800 (PST) 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 RAA02623; Mon, 12 Nov 2001 17:21:25 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA23938; Mon, 12 Nov 2001 17:21:13 +1100 (AEDT) Date: Mon, 12 Nov 2001 17:21:13 +1100 From: Nathan Scott To: Al Viro , Andreas Gruenbacher Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: [RFC][PATCH] VFS interface for extended attributes Message-ID: <20011112172113.A636371@wobbly.melbourne.sgi.com> References: <3BECEEA2.4030408@hotmail.com> <5.1.0.14.2.20011112012026.02b3eda8@pop.cus.cam.ac.uk> <20011112142029.D583135@wobbly.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: <20011112142029.D583135@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Mon, Nov 12, 2001 at 02:20:29PM +1100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Nov 12, 2001 at 02:20:29PM +1100, Nathan Scott wrote: > On Mon, Nov 12, 2001 at 01:57:28AM +0000, Anton Altaparmakov wrote: > > At 09:08 10/11/2001, Tim R. wrote: > > >I'm glad to see you guys are working on a common acl api for ext2/3 and xfs. > > >I was just wondering if this api provided what would be needed for linux > > >to support NTFS's acls. > > > > Comments/problems for NTFS with proposed EA/ACL API: > > > > I think the API is good for extended attributes, no doubt. If we ever get > > round to implementing EAs in NTFS then I would be happy to use the API. It > > fully satisfies the needs of the NTFS EAs. > > That's great to hear! Thanks. > ... > I'll put out an initial attempt at some VFS code to sit behind > this system call soon too. > Al, folks, Andreas and I have been looking at several different VFS mechanisms for extended attributes, I've included the code for one below, and we're keen to get a bit of feedback here as well. We started off with the simplest mechanism, just passing everything straight down into the filesystem. I then played around with some ways of separating out the different operations and then passing off to the filesystem that way (see patch) to give the interface a more rigid definition. Andreas' original mechanism was alot like this, except used NULLs in some field values instead of explicit flags to distinguish similar operations - that's another approach. Yet another way would be to have an ea_operations vector separate to the inode_operations with an ea_operations pointer in struct inode, enumerating each EA operation and doing away with the flags (in the patch below) altogether. Any suggestions/improvements? The patch below is very much a work in progress - it may even compile. many thanks. -- Nathan diff -Naur 2.4.14-pristine/arch/i386/kernel/entry.S 2.4.14-explicit/arch/i386/kernel/entry.S --- 2.4.14-pristine/arch/i386/kernel/entry.S Sat Nov 3 12:18:49 2001 +++ 2.4.14-explicit/arch/i386/kernel/entry.S Fri Nov 9 15:34:29 2001 @@ -622,6 +622,9 @@ .long SYMBOL_NAME(sys_ni_syscall) /* Reserved for Security */ .long SYMBOL_NAME(sys_gettid) .long SYMBOL_NAME(sys_readahead) /* 225 */ + .long SYMBOL_NAME(sys_extattr) + .long SYMBOL_NAME(sys_lextattr) + .long SYMBOL_NAME(sys_fextattr) .rept NR_syscalls-(.-sys_call_table)/4 .long SYMBOL_NAME(sys_ni_syscall) diff -Naur 2.4.14-pristine/fs/Makefile 2.4.14-explicit/fs/Makefile --- 2.4.14-pristine/fs/Makefile Tue Nov 6 08:40:59 2001 +++ 2.4.14-explicit/fs/Makefile Fri Nov 9 15:27:42 2001 @@ -14,7 +14,7 @@ super.o block_dev.o char_dev.o stat.o exec.o pipe.o namei.o \ fcntl.o ioctl.o readdir.o select.o fifo.o locks.o \ dcache.o inode.o attr.o bad_inode.o file.o iobuf.o dnotify.o \ - filesystems.o namespace.o + filesystems.o namespace.o extattr.o ifeq ($(CONFIG_QUOTA),y) obj-y += dquot.o diff -Naur 2.4.14-pristine/fs/extattr.c 2.4.14-explicit/fs/extattr.c --- 2.4.14-pristine/fs/extattr.c Thu Jan 1 10:00:00 1970 +++ 2.4.14-explicit/fs/extattr.c Mon Nov 12 11:24:11 2001 @@ -0,0 +1,101 @@ +/* + File: fs/extattr.c + + Extended attribute handling. + + Copyright (C) 2001 by Andreas Gruenbacher + Copyright (C) 2001 SGI - Silicon Graphics, Inc + */ + +#include +#include +#include +#include +#include + +static long +extattr_inode(struct inode *i, int cmd, char *name, void *value, size_t size) +{ + int error = -EOPNOTSUPP, flags = EA_FLAG_USER; + + lock_kernel(); + switch (cmd) { + case EA_SET: + case EA_CREATE: + case EA_REPLACE: + case EA_REMOVE: + if (!i->i_op->setxattr) + break; + if (cmd == EA_CREATE) + flags |= EA_FLAG_CREATE; + else if (cmd == EA_REPLACE) + flags |= EA_FLAG_REPLACE; + else if (cmd == EA_REMOVE) + flags |= EA_FLAG_REMOVE; + error = i->i_op->setxattr(i, name, value, size, flags); + break; + + case EA_GETSIZE: + flags |= EA_FLAG_SZONLY; + case EA_GET: + if (!i->i_op->getxattr) + break; + error = i->i_op->getxattr(i, name, value, size, flags); + break; + + case EA_LISTSIZE: + flags |= EA_FLAG_SZONLY; + case EA_LIST: + if (!i->i_op->listxattr) + break; + error = i->i_op->listxattr(i, name, value, size, flags); + break; + + default: + error = -EINVAL; + } + unlock_kernel(); + return error; +} + +asmlinkage long +sys_extattr(char *path, int cmd, char *name, void *value, size_t size) +{ + struct nameidata nd; + int error; + + error = user_path_walk(path, &nd); + if (error) + return error; + error = extattr_inode(nd.dentry->d_inode, cmd, name, value, size); + path_release(&nd); + return error; +} + +asmlinkage long +sys_lextattr(char *path, int cmd, char *name, void *value, size_t size) +{ + struct nameidata nd; + int error; + + error = user_path_walk_link(path, &nd); + if (error) + return error; + error = extattr_inode(nd.dentry->d_inode, cmd, name, value, size); + path_release(&nd); + return error; +} + +asmlinkage long +sys_fextattr(int fd, int cmd, char *name, void *value, size_t size) +{ + struct file *f; + int error = -EBADF; + + f = fget(fd); + if (!f) + return error; + error = extattr_inode(f->f_dentry->d_inode, cmd, name, value, size); + fput(f); + return error; +} diff -Naur 2.4.14-pristine/include/asm-i386/unistd.h 2.4.14-explicit/include/asm-i386/unistd.h --- 2.4.14-pristine/include/asm-i386/unistd.h Thu Oct 18 03:03:03 2001 +++ 2.4.14-explicit/include/asm-i386/unistd.h Fri Nov 9 15:37:08 2001 @@ -230,6 +230,9 @@ #define __NR_security 223 /* syscall for security modules */ #define __NR_gettid 224 #define __NR_readahead 225 +#define __NR_extattr 226 +#define __NR_lextattr 227 +#define __NR_fextattr 228 /* user-visible error numbers are in the range -1 - -124: see */ diff -Naur 2.4.14-pristine/include/linux/extattr.h 2.4.14-explicit/include/linux/extattr.h --- 2.4.14-pristine/include/linux/extattr.h Thu Jan 1 10:00:00 1970 +++ 2.4.14-explicit/include/linux/extattr.h Mon Nov 12 11:24:01 2001 @@ -0,0 +1,30 @@ +/* + File: linux/extattr.h + + Extended attributes handling. + + Copyright (C) 2001 by Andreas Gruenbacher + Copyright (C) 2001 SGI - Silicon Graphics, Inc +*/ +#ifndef _LINUX_EXTATTR_H +#define _LINUX_EXTATTR_H + +/* Operations */ +#define EA_SET 1 /* set the value, create attr where necessary */ +#define EA_CREATE 2 /* set the value, fail if attr already exists */ +#define EA_REPLACE 3 /* set the value, fail if attr does not exist */ +#define EA_REMOVE 4 /* remove the named attribute entirely */ +#define EA_GET 5 /* get the value for named attribute */ +#define EA_GETSIZE 6 /* size of value for named attribute */ +#define EA_LIST 7 /* get the list of attribute names */ +#define EA_LISTSIZE 8 /* size of list of attribute names */ + +#ifdef __KERNEL__ +#define EA_FLAG_USER 0x0001 +#define EA_FLAG_SZONLY 0x0002 +#define EA_FLAG_CREATE 0x0004 +#define EA_FLAG_REPLACE 0x0008 +#define EA_FLAG_REMOVE 0x0010 +#endif + +#endif /* _LINUX_EXTATTR_H */ diff -Naur 2.4.14-pristine/include/linux/fs.h 2.4.14-explicit/include/linux/fs.h --- 2.4.14-pristine/include/linux/fs.h Tue Nov 6 07:42:14 2001 +++ 2.4.14-explicit/include/linux/fs.h Sat Nov 10 14:10:39 2001 @@ -840,6 +840,9 @@ int (*revalidate) (struct dentry *); int (*setattr) (struct dentry *, struct iattr *); int (*getattr) (struct dentry *, struct iattr *); + int (*setxattr) (struct inode *, char *, void *, size_t, int); + int (*getxattr) (struct inode *, char *, void *, size_t, int); + int (*listxattr) (struct inode *, char *, void *, size_t, int); }; /* From owner-linux-xfs@oss.sgi.com Sun Nov 11 22:47:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAC6l8211441 for linux-xfs-outgoing; Sun, 11 Nov 2001 22:47:08 -0800 Received: from math.psu.edu (leibniz.math.psu.edu [146.186.130.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAC6l4011419 for ; Sun, 11 Nov 2001 22:47:04 -0800 Received: from weyl.math.psu.edu (weyl.math.psu.edu [146.186.130.226]) by math.psu.edu (8.9.3/8.9.3) with ESMTP id BAA07019; Mon, 12 Nov 2001 01:47:03 -0500 (EST) Received: from localhost (viro@localhost) by weyl.math.psu.edu (8.9.3/8.9.3) with ESMTP id BAA20035; Mon, 12 Nov 2001 01:47:02 -0500 (EST) X-Authentication-Warning: weyl.math.psu.edu: viro owned process doing -bs Date: Mon, 12 Nov 2001 01:47:02 -0500 (EST) From: Alexander Viro To: Nathan Scott cc: Linus Torvalds , Andreas Gruenbacher , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [RFC][PATCH] VFS interface for extended attributes In-Reply-To: <20011112172113.A636371@wobbly.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 [Cc'd to Linus since API changes on that level definitely require his approval] On Mon, 12 Nov 2001, Nathan Scott wrote: > +static long > +extattr_inode(struct inode *i, int cmd, char *name, void *value, size_t size) Broken. a) passing inode is an obvious mistake. dentry or vfsmount/dentry. b) for crying out loud, what's that with SGI and ioctl-like abortions? Rule of the tumb: if your function got a "cmd" argument - it's broken. ioctl(2). fcntl(2). prctl(2). quotactl(2). sysfs(2). Missed'em'V IPC syscalls. Enough, already. Folks, it's not a rocket science. Let a function do _one_ thing, don't turn it into a multiplexed monstrosity. Yes, you've used only 3 syscalls. But actually you've managed to hide ~20 of them in that code and the fact that you've spent only 3 syscall table entries doesn't make the things better. Please, come up with a decent API. From owner-linux-xfs@oss.sgi.com Sun Nov 11 23:20:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAC7KkB12130 for linux-xfs-outgoing; Sun, 11 Nov 2001 23:20:46 -0800 Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAC7Kf012107 for ; Sun, 11 Nov 2001 23:20:42 -0800 Received: from melkki.cs.Helsinki.FI (sslwrap@localhost [127.0.0.1]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id fAC7Kd312140 for ; Mon, 12 Nov 2001 09:20:39 +0200 Received: (from hhaataja@localhost) by melkki.cs.Helsinki.FI (8.11.6/8.11.2) id fAC7Kbm05000 for linux-xfs@oss.sgi.com; Mon, 12 Nov 2001 09:20:37 +0200 Date: Mon, 12 Nov 2001 09:20:37 +0200 From: Harri Haataja Cc: linux-xfs@oss.sgi.com Subject: Re: Undelete in XFS Message-ID: <20011112092037.A24732@cs.helsinki.fi> References: <1005258455.4701.4.camel@itspec.amoa.org> <1005258497.9075.22.camel@jen.americas.sgi.com> <1005259546.5742.9.camel@itspec.amoa.org> <1005261542.9077.29.camel@jen.americas.sgi.com> <3BEB1829.5F5C3D2@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BEB1829.5F5C3D2@idcomm.com>; from stimits@idcomm.com on Thu, Nov 08, 2001 at 04:41:29PM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Nov 08, 2001 at 04:41:29PM -0700, D. Stimits wrote: > Steve Lord wrote: > > On Thu, 2001-11-08 at 16:45, Chris Tooley wrote: > > > Wish I could file an evolution bug and blame it on someone else, but my > > > problem is my own stupidity trying to make space on my harddrive. BTW > > > what is the status of being able to move the start point of a > > > partition? I can't do a dump and restore on my workstation and really > > > need to add some space to this partition. However, I'm at the end of > > > the disk. > > Disk drives are really cheap now, I have a spare 20Gbyte 7200 rpm IBM > > IDE drive sitting on a shelf in my office, it cost about $100. > > I installed a scratch 20 Gb cheap-o into a removeable tray, and have the > tray on a couple of computers. Makes a wonderful floppy. Just make sure > it is formatted as an extended/logical partition, primaries tend to > confuse some more stupid o/s's when the partitions get added and > removed. I highly recommend a removeable tray scratch IDE drive. A sleek USB chassis might also be nice as they hot-swap and all. I haven't got one (apart from the CF in my camera) since I'm not quite sure that particular models would work (are there differences? OT, I know, don't answer =). That and an automounter make a nice combination. -- Did you properly position the monitor face down, centered on, and just a little above his shoulders? -- Aaron R. Kulkis on comp.arch From owner-linux-xfs@oss.sgi.com Mon Nov 12 02:53:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACArhn16227 for linux-xfs-outgoing; Mon, 12 Nov 2001 02:53:43 -0800 Received: from mta4-rme.xtra.co.nz (mta4-rme.xtra.co.nz [210.86.15.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACArd016204 for ; Mon, 12 Nov 2001 02:53:40 -0800 Received: from mdew ([210.86.16.122]) by mta4-rme.xtra.co.nz with ESMTP id <20011112105332.GGGD13078.mta4-rme.xtra.co.nz@mdew> for ; Mon, 12 Nov 2001 23:53:32 +1300 Subject: ext3 merge causing problems? From: mdew To: xfs Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 13 Nov 2001 11:05:52 +1300 Message-Id: <1005602753.372.1.camel@mdew> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk is this the reason why pre2/pre3 hasnt been merged into CVS yet? :) from.. http://kt.zork.net/kernel-traffic/kt20011112_141.html * There is an interaction failure between ext3 and the current Extended Attributes and Access Control Lists patch which leads to crashes under heavy load on SMP. This is possibly due to a subtle API change between ext3 in 2.2 and 2.4 kernels (ie: I broke it). On the to-do list. From owner-linux-xfs@oss.sgi.com Mon Nov 12 02:55:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACAtc216409 for linux-xfs-outgoing; Mon, 12 Nov 2001 02:55:38 -0800 Received: from st-peter.stw.uni-erlangen.de (IDENT:qmailr@voyager.st-peter.stw.uni-erlangen.de [131.188.24.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACAtY016386 for ; Mon, 12 Nov 2001 02:55:34 -0800 Received: (qmail 32359 invoked from network); 12 Nov 2001 10:55:32 -0000 Received: from svetljo.st-peter.stw.uni-erlangen.de (HELO st-peter.stw.uni-erlangen.de) (172.17.17.181) by voyager.st-peter.stw.uni-erlangen.de with SMTP; 12 Nov 2001 10:55:32 -0000 Message-ID: <3BEFAA89.2020801@st-peter.stw.uni-erlangen.de> Date: Mon, 12 Nov 2001 11:55:05 +0100 From: svetljo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: PB's compiling 2.4.15-pre3-xfs-cvs Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi i think in the cvs are missing some Makefiles fs/ext3 fs/intermezzo and mybe more when i try " make dep " or "make bzImage " im getting make[4]: Leaving directory `/usr/src/linux-2.4.15-pre3/fs/ext2' make -C ext3 fastdep make[4]: Entering directory `/usr/src/linux-2.4.15-pre3/fs/ext3' make[4]: *** No rule to make target `fastdep'. Stop. make[4]: Leaving directory `/usr/src/linux-2.4.15-pre3/fs/ext3' make[3]: *** [_sfdep_ext3] Error 2 make[3]: Leaving directory `/usr/src/linux-2.4.15-pre3/fs' make[2]: *** [fastdep] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.15-pre3/fs' make[1]: *** [_sfdep_fs] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.15-pre3' make: *** [dep-files] Error 2 From owner-linux-xfs@oss.sgi.com Mon Nov 12 03:40:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACBeFT17513 for linux-xfs-outgoing; Mon, 12 Nov 2001 03:40:15 -0800 Received: from moses.parsec.at (moses.parsec.at [212.236.50.196]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACBe8017491 for ; Mon, 12 Nov 2001 03:40:09 -0800 Received: from localhost (ag@localhost) by moses.parsec.at (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA15085; Mon, 12 Nov 2001 12:39:50 +0100 Date: Mon, 12 Nov 2001 12:39:50 +0100 (CET) From: Andreas Gruenbacher X-Sender: ag@moses.parsec.at To: Alexander Viro cc: Nathan Scott , Linus Torvalds , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [RFC][PATCH] VFS interface for extended attributes 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 Hello Al, On Mon, 12 Nov 2001, Alexander Viro wrote: > > [Cc'd to Linus since API changes on that level definitely require his > approval] > > On Mon, 12 Nov 2001, Nathan Scott wrote: > > > +static long > > +extattr_inode(struct inode *i, int cmd, char *name, void *value, size_t size) > > Broken. > a) passing inode is an obvious mistake. dentry or vfsmount/dentry. There are curently two paths by which the extended attribute inode operations can be invoked: (a) from a system call, (b) from the permission() inode operation, when checking the access ACL of a file. We could trivially use a dentry in (a), but unfortunately we don't have a choice in (b), as permission() itself is not passed a dentry. It's planned that all inode operations use dentries somewhen in 2.5. This would be the proper time to move to dentries in the EA code as well. > b) for crying out loud, what's that with SGI and ioctl-like abortions? > > Rule of the tumb: if your function got a "cmd" argument - it's broken. > ioctl(2). fcntl(2). prctl(2). quotactl(2). sysfs(2). Missed'em'V IPC > syscalls. Enough, already. There is one difference between the interfaces you are complaining about above and the proposed EA interface for EA's: In those interfaces you have wildcard parameters that are used for who-knows-what, depending on a command-like parameter, including use as a value, use as a pointer to a value/struct, etc. In the EA interface we have clear semantics of what the parameters' types and sizes are, so many of the problems there are with ioctl() and friends don't occur here. You could as well call the `cmd' parameter a `flags' parameter here, then you're pretty close to the open() syscall. It would be possible to split the EA syscalls in a set for retrieving and aonther set for setting EA's, and perhaps still a third set for listing the EA's that are present. Those syscalls would only differ in their names. I would consider it much more useful to provide functions in a library for dealing with EA's in user space, which in turn would use the syscalls, though. Cheers, Andreas. From owner-linux-xfs@oss.sgi.com Mon Nov 12 06:23:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACENDM21222 for linux-xfs-outgoing; Mon, 12 Nov 2001 06:23:13 -0800 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 fACEN5021200 for ; Mon, 12 Nov 2001 06:23:05 -0800 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 PAA2185474 for ; Mon, 12 Nov 2001 15:23:03 +0100 (CET) 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 IAA3548050; Mon, 12 Nov 2001 08:21:37 -0600 (CST) Received: from jen.americas.sgi.com (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 IAA99181; Mon, 12 Nov 2001 08:21:37 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fACEGvC23385; Mon, 12 Nov 2001 08:16:57 -0600 Subject: Re: XFS and preemptive kernel patch From: Steve Lord To: Anuradha Ratnaweera Cc: Federico Sevilla III , Linux XFS Mailing List In-Reply-To: <20011110104554.A4402@bee.lk> References: <20011110102710.A2703@bee.lk> <20011110104554.A4402@bee.lk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.07.16.47 (Preview Release) Date: 12 Nov 2001 08:16:57 -0600 Message-Id: <1005574617.23367.0.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2001-11-09 at 22:45, Anuradha Ratnaweera wrote: > On Sat, Nov 10, 2001 at 12:37:26PM +0800, Federico Sevilla III wrote: > > > > On Sat, 10 Nov 2001 at 10:27, Anuradha Ratnaweera wrote: > > > > > Do you mean XFS code can be preemptible at _kernel_ space? > > > > I'm not sure, either. As far as I remember the XFS code (kernel space) was > > modified to be preemptible. Exactly what gets preempted is beyond me. I hope > > the XFS gurus can help us out with this (maybe this is worth a FAQ entry, > > Seth?). :) > > When I recently raised the question of XFS not being in the mainstream kernel, > it was told that it is touching too much kernel internals, some of which are > 2.5 stuff. May be this is one... Any clue? Nothing to do with it. And XFS touching too much of the kernel internals appears to be somewhat of an urban legend. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Nov 12 06:34:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACEYHH21604 for linux-xfs-outgoing; Mon, 12 Nov 2001 06:34:17 -0800 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 fACEYD021580 for ; Mon, 12 Nov 2001 06:34:13 -0800 Received: from pyewacket.nic.uklinux.net (host213-1-190-183.btinternet.com [213.1.190.183]) (authenticated) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id fACEY5K21780 for ; Mon, 12 Nov 2001 14:34:05 GMT Envelope-To: Received: from [127.0.0.1] (helo=there) by pyewacket.nic.uklinux.net with smtp (Exim 3.33 #1) id 163IA0-0006RN-00 for linux-xfs@oss.sgi.com; Mon, 12 Nov 2001 14:34:04 +0000 Content-Type: text/plain; charset="iso-8859-1" From: nic Reply-To: nic@uklinux.net Organization: Quixotic Hackers To: linux-xfs@oss.sgi.com Subject: CVS server config or dir wrong? Date: Mon, 12 Nov 2001 14:34:04 +0000 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk pyewacket Red Hat 7.2 x86 $ export CVSROOT=':pserver:cvs@oss.sgi.com:/cvs' pyewacket Red Hat 7.2 x86 $ cvs -z3 update -d [lots of stuff] ^Ccvs [update aborted]: received interrupt signal pyewacket Red Hat 7.2 x86 $ ls -l total 12 drwxr-xr-x 5 nic bin 73 Nov 12 13:40 arcboot drwxr-xr-x 8 nic bin 4096 Nov 12 13:41 audiofile drwxr-xr-x 7 nic bin 65 Nov 12 13:41 bugs drwxr-xr-x 2 nic bin 48 Nov 12 14:10 CVS drwxr-xr-x 4 nic bin 4096 Nov 12 12:58 CVSROOT drwxr-xr-x 3 nic bin 16 Nov 12 13:41 dmsdk drwxr-xr-x 3 nic bin 4096 Nov 12 13:41 dvhtool drwxr-xr-x 4 nic bin 31 Nov 12 13:41 failsafe drwxr-xr-x 5 nic bin 38 Mar 19 2001 linux-2.4-xfs drwxr-xr-x 4 nic bin 25 Nov 12 12:58 XFree Err, why am I getting all these other projects? My modem ain't going to handle this... :-) This is the same place/method I've been getting my kernel from since March, unless I'm having a Mr Thicky moment. So has someone messed up the cvs server or have I screwed something up? nic From owner-linux-xfs@oss.sgi.com Mon Nov 12 07:09:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACF9m322460 for linux-xfs-outgoing; Mon, 12 Nov 2001 07:09:48 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACF9i022437 for ; Mon, 12 Nov 2001 07:09:44 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fACF9cK11429 for ; Mon, 12 Nov 2001 07:09:38 -0800 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 JAA3570293 for ; Mon, 12 Nov 2001 09:08:23 -0600 (CST) Received: from jen.americas.sgi.com (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 JAA89920 for ; Mon, 12 Nov 2001 09:08:23 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fACF3hv03200; Mon, 12 Nov 2001 09:03:43 -0600 Message-Id: <200111121503.fACF3hv03200@jen.americas.sgi.com> Date: Mon, 12 Nov 2001 09:03:43 -0600 Subject: TAKE - new files from 2.4.15-pre2 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk These files were missing from the original checkin Date: Mon Nov 12 07:07:46 PST 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:106510a linux/drivers/hotplug/Config.in - 1.1 linux/fs/ext3/balloc.c - 1.1 linux/fs/jbd/commit.c - 1.1 linux/fs/ext3/bitmap.c - 1.1 linux/fs/ext3/dir.c - 1.1 linux/drivers/scsi/sym53c8xx_2/ChangeLog.txt - 1.1 linux/drivers/scsi/sym53c8xx_2/Documentation.txt - 1.1 linux/fs/ext3/Makefile - 1.1 linux/fs/ext3/acl.c - 1.1 linux/fs/jbd/Makefile - 1.1 linux/fs/intermezzo/cache.c - 1.1 linux/fs/jbd/checkpoint.c - 1.1 linux/fs/intermezzo/Makefile - 1.1 linux/fs/intermezzo/dir.c - 1.1 linux/fs/intermezzo/dcache.c - 1.1 linux/drivers/scsi/53c8xx_u.h - 1.4 linux/drivers/scsi/53c8xx_d.h - 1.6 linux/drivers/scsi/sim710_d.h - 1.5 linux/drivers/scsi/sim710_u.h - 1.3 From owner-linux-xfs@oss.sgi.com Mon Nov 12 07:31:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACFVrP22971 for linux-xfs-outgoing; Mon, 12 Nov 2001 07:31:53 -0800 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 fACFVp022949 for ; Mon, 12 Nov 2001 07:31:51 -0800 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 HAA00622 for ; Mon, 12 Nov 2001 07:31:28 -0800 (PST) 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 JAA3568095 for ; Mon, 12 Nov 2001 09:30:35 -0600 (CST) Received: from jen.americas.sgi.com (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 JAA17824 for ; Mon, 12 Nov 2001 09:30:34 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fACFPtJ08403; Mon, 12 Nov 2001 09:25:55 -0600 Message-Id: <200111121525.fACFPtJ08403@jen.americas.sgi.com> Date: Mon, 12 Nov 2001 09:25:55 -0600 Subject: TAKE - fix kernel subversion string Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Nov 12 07:30:20 PST 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:106512a linux/Makefile - 1.153 - fix kernel subversion string From owner-linux-xfs@oss.sgi.com Mon Nov 12 08:14:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACGEL425002 for linux-xfs-outgoing; Mon, 12 Nov 2001 08:14:21 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACGEI024974 for ; Mon, 12 Nov 2001 08:14:18 -0800 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 IAA01254 for ; Mon, 12 Nov 2001 08:14:14 -0800 (PST) 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 KAA3568009 for ; Mon, 12 Nov 2001 10:12:55 -0600 (CST) Received: from jen.americas.sgi.com (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 KAA27818 for ; Mon, 12 Nov 2001 10:12:55 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fACG8F612497; Mon, 12 Nov 2001 10:08:15 -0600 Subject: Problems with 2.4.15-pre3 kernel From: Steve Lord To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.07.16.47 (Preview Release) Date: 12 Nov 2001 10:08:15 -0600 Message-Id: <1005581295.23417.23.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The cvs tree was moved up to 2.4.15-pre3 this weekend, some files were missing from the checkin, this has been fixed now, however, there are problems with xfs - I cannot unmount filesystems, this may be an interaction with the ext3 code changes.Hopefully we can get this sorted out soon. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Nov 12 08:22:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACGMNI25270 for linux-xfs-outgoing; Mon, 12 Nov 2001 08:22:23 -0800 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 fACGMK025248 for ; Mon, 12 Nov 2001 08:22:20 -0800 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 IAA07992 for ; Mon, 12 Nov 2001 08:21:56 -0800 (PST) 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 KAA3570268 for ; Mon, 12 Nov 2001 10:21:02 -0600 (CST) Received: from jen.americas.sgi.com (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 KAA15469 for ; Mon, 12 Nov 2001 10:21:02 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fACGGMT12518; Mon, 12 Nov 2001 10:16:22 -0600 Subject: Re: Problems with 2.4.15-pre3 kernel From: Steve Lord To: linux-xfs@oss.sgi.com In-Reply-To: <1005581295.23417.23.camel@jen.americas.sgi.com> References: <1005581295.23417.23.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.07.16.47 (Preview Release) Date: 12 Nov 2001 10:16:22 -0600 Message-Id: <1005581782.23367.25.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2001-11-12 at 10:08, Steve Lord wrote: > The cvs tree was moved up to 2.4.15-pre3 this weekend, some files were > missing from the checkin, this has been fixed now, however, there are > problems with xfs - I cannot unmount filesystems, this may be an > interaction with the ext3 code changes.Hopefully we can get this sorted > out soon. > And I sorted them out when I realized I had an nfs export on the fs I was having difficulties with. Never mind, pilot error on this end, sorry for the confusion. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Nov 12 08:33:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACGXss25537 for linux-xfs-outgoing; Mon, 12 Nov 2001 08:33:54 -0800 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 fACGXj025515 for ; Mon, 12 Nov 2001 08:33:45 -0800 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 RAA2284779 for ; Mon, 12 Nov 2001 17:33:43 +0100 (CET) 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 KAA3569992; Mon, 12 Nov 2001 10:32:24 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA40117; Mon, 12 Nov 2001 10:32:23 -0600 (CST) Subject: Re: kickstart mkfs.xfs error From: Eric Sandeen To: Sanat Mohanty Cc: linux-xfs@oss.sgi.com In-Reply-To: <3BED94DE.B2596A8E@uulogic.com> References: <3BED94DE.B2596A8E@uulogic.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 12 Nov 2001 10:30:55 -0600 Message-Id: <1005582656.22610.78.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Sanat - On Sat, 2001-11-10 at 14:58, Sanat Mohanty wrote: > The kickstart installation starts after making the above partitions it > shows me a error dialog box giving the following error: > > Errot mounting device hda6 as / : No such device. > > Reboot your system. Hm, not sure about that... > Again in the Alt+F5 windows it showing the following error message. > > mkfs.xfs: Warning - cannot set blocksize on block device > /tmp/hda6 : Input/output error Those should be harmless. Unless you specificaly need RH7.1/XFS1.0.1, can you try the RH7.2 installer beta in the testing/ directory on the xfs ftp site? That's where the installer bugfix efforts are focused now... 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 Mon Nov 12 09:12:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACHCVf31848 for linux-xfs-outgoing; Mon, 12 Nov 2001 09:12:31 -0800 Received: from mout02.kundenserver.de (mout02.kundenserver.de [195.20.224.133]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACHCQ031825 for ; Mon, 12 Nov 2001 09:12:27 -0800 Received: from [195.20.224.219] (helo=mrvdom03.schlund.de) by mout02.kundenserver.de with esmtp (Exim 2.12 #2) id 163KdG-0007pK-00 for linux-xfs@oss.sgi.com; Mon, 12 Nov 2001 18:12:26 +0100 Received: from pd958d5cd.dip.t-dialin.net ([217.88.213.205] helo=kernelpanix.aura.of.mankind) by mrvdom03.schlund.de with esmtp (Exim 2.12 #2) id 163KdF-00023u-00 for linux-xfs@oss.sgi.com; Mon, 12 Nov 2001 18:12:25 +0100 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id fACHCOk22424 for linux-xfs@oss.sgi.com; Mon, 12 Nov 2001 18:12:24 +0100 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Mon, 12 Nov 2001 18:12:24 +0100 From: utz lehmann To: linux-xfs@oss.sgi.com Subject: 2.4.15-pre3 compile error Message-ID: <20011112181224.A22379@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 I get this error with 2.4.15-pre3 CVS: kallsyms pass 1 ld -m elf_i386 -T /usr/src/linux-2.4-xfs-20011112/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o --start-group arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o kdb/kdb.o drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/char/agp/agp.o drivers/ide/idedriver.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/pnp/pnp.o drivers/video/video.o drivers/md/mddev.o net/network.o /usr/src/linux-2.4-xfs-20011112/linux/arch/i386/lib/lib.a /usr/src/linux-2.4-xfs-20011112/linux/lib/lib.a /usr/src/linux-2.4-xfs-20011112/linux/arch/i386/lib/lib.a /usr/src/linux-2.4-xfs-20011112/linux/arch/i386/kdb/kdba.o --end-group -o .tmp_vmlinux1 drivers/md/mddev.o: In function lvm_snapshot_alloc': drivers/md/mddev.o(.text+0xdbd2): undefined reference to alloc_kiovec_sz' drivers/md/mddev.o(.text+0xdc04): undefined reference to alloc_kiovec_sz' drivers/md/mddev.o(.text+0xdc51): undefined reference to free_kiovec_sz' drivers/md/mddev.o(.text+0xdc77): undefined reference to free_kiovec_sz' drivers/md/mddev.o: In function lvm_snapshot_release': drivers/md/mddev.o(.text+0xdd2f): undefined reference to free_kiovec_sz' drivers/md/mddev.o(.text+0xdd6b): undefined reference to free_kiovec_sz' make[1]: *** [kallsyms] Error 1 make[1]: Leaving directory /usr/src/linux-2.4-xfs-20011112/linux' make: *** [vmlinux] Error 2 The Source is post "TAKE - new files from 2.4.15-pre2". Compiled with kgcc for K6. utz From owner-linux-xfs@oss.sgi.com Mon Nov 12 09:34:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACHYZw00361 for linux-xfs-outgoing; Mon, 12 Nov 2001 09:34:35 -0800 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 fACHYU000339 for ; Mon, 12 Nov 2001 09:34:30 -0800 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 JAA01890 for ; Mon, 12 Nov 2001 09:34:08 -0800 (PST) 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 LAA3536034; Mon, 12 Nov 2001 11:33:13 -0600 (CST) Received: from jen.americas.sgi.com (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 LAA25156; Mon, 12 Nov 2001 11:33:12 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fACHSWD12931; Mon, 12 Nov 2001 11:28:32 -0600 Subject: Re: 2.4.15-pre3 compile error From: Steve Lord To: utz lehmann Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011112181224.A22379@s2y4n2c.de> References: <20011112181224.A22379@s2y4n2c.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.11.08.57 (Preview Release) Date: 12 Nov 2001 11:28:31 -0600 Message-Id: <1005586111.12886.0.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2001-11-12 at 11:12, utz lehmann wrote: > Hi > > I get this error with 2.4.15-pre3 CVS: > > kallsyms pass 1 > ld -m elf_i386 -T /usr/src/linux-2.4-xfs-20011112/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o --start-group arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o kdb/kdb.o drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/char/agp/agp.o drivers/ide/idedriver.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/pnp/pnp.o drivers/video/video.o drivers/md/mddev.o net/network.o /usr/src/linux-2.4-xfs-20011112/linux/arch/i386/lib/lib.a /usr/src/linux-2.4-xfs-20011112/linux/lib/lib.a /usr/src/linux-2.4-xfs-20011112/linux/arch/i386/lib/lib.a /usr/src/linux-2.4-xfs-20011112/linux/arch/i386/kdb/kdba.o --end-group -o .tmp_vmlinux1 > drivers/md/mddev.o: In function lvm_snapshot_alloc': > drivers/md/mddev.o(.text+0xdbd2): undefined reference to alloc_kiovec_sz' > drivers/md/mddev.o(.text+0xdc04): undefined reference to alloc_kiovec_sz' > drivers/md/mddev.o(.text+0xdc51): undefined reference to free_kiovec_sz' > drivers/md/mddev.o(.text+0xdc77): undefined reference to free_kiovec_sz' > drivers/md/mddev.o: In function lvm_snapshot_release': > drivers/md/mddev.o(.text+0xdd2f): undefined reference to free_kiovec_sz' > drivers/md/mddev.o(.text+0xdd6b): undefined reference to free_kiovec_sz' > make[1]: *** [kallsyms] Error 1 > make[1]: Leaving directory /usr/src/linux-2.4-xfs-20011112/linux' > make: *** [vmlinux] Error 2 > > > The Source is post "TAKE - new files from 2.4.15-pre2". > Compiled with kgcc for K6. > > > utz It looks like Linus broke this in the merge, we have one line of code change in this whole directory, and it is to remove a printk. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Nov 12 09:40:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACHeDe00710 for linux-xfs-outgoing; Mon, 12 Nov 2001 09:40:13 -0800 Received: from falka.mfa.kfki.hu (falka.mfa.kfki.hu [148.6.72.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACHeA000687 for ; Mon, 12 Nov 2001 09:40:10 -0800 Received: (from root@localhost) by falka.mfa.kfki.hu (8.9.3/8.9.3/Debian 8.9.3-21) id SAA05175; Mon, 12 Nov 2001 18:39:22 +0100 Received: from falka.mfa.kfki.hu (falka.mfa.kfki.hu [148.6.72.6]) by falka.mfa.kfki.hu (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id SAA05166; Mon, 12 Nov 2001 18:39:22 +0100 Date: Mon, 12 Nov 2001 18:39:21 +0100 (CET) From: Gergely Tamas To: Steve Lord cc: utz lehmann , Subject: Re: 2.4.15-pre3 compile error In-Reply-To: <1005586111.12886.0.camel@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! > It looks like Linus broke this in the merge, we have one line of code > change in this whole directory, and it is to remove a printk. This is due the lvm 1.0.1rc4(ish) merge from Alan. Alan already sent a fix to Linus for this. Gergely From owner-linux-xfs@oss.sgi.com Mon Nov 12 10:27:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACIR2302027 for linux-xfs-outgoing; Mon, 12 Nov 2001 10:27:02 -0800 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 fACIQx002005 for ; Mon, 12 Nov 2001 10:26:59 -0800 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 TAA2302826 for ; Mon, 12 Nov 2001 19:26:59 +0100 (CET) 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 MAA3496966 for ; Mon, 12 Nov 2001 12:25:40 -0600 (CST) Received: from jen.americas.sgi.com (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 MAA37253 for ; Mon, 12 Nov 2001 12:25:40 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fACIKxs13033; Mon, 12 Nov 2001 12:20:59 -0600 Message-Id: <200111121820.fACIKxs13033@jen.americas.sgi.com> Date: Mon, 12 Nov 2001 12:20:59 -0600 Subject: TAKE - fix lvm build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Nov 12 10:25:28 PST 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:106536a linux/drivers/md/lvm-snap.c - 1.9 - Fix build From owner-linux-xfs@oss.sgi.com Mon Nov 12 11:22:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACJMVf04207 for linux-xfs-outgoing; Mon, 12 Nov 2001 11:22:31 -0800 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 fACJMP004184 for ; Mon, 12 Nov 2001 11:22:26 -0800 Received: from an.local (an.local [192.168.4.50]) by mail.spylog.com (Postfix) with ESMTP id 3A8592C1F4; Mon, 12 Nov 2001 22:22:19 +0300 (MSK) Received: by an.local (Postfix, from userid 1000) id 80EE11CB736D; Mon, 12 Nov 2001 22:22:18 +0300 (MSK) Date: Mon, 12 Nov 2001 22:22:18 +0300 From: Andrey Nekrasov To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - fix lvm build Message-ID: <20011112222218.A23488@spylog.ru> Mail-Followup-To: Steve Lord , linux-xfs@oss.sgi.com References: <200111121820.fACIKxs13033@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200111121820.fACIKxs13033@jen.americas.sgi.com> User-Agent: Mutt/1.3.23i Organization: SpyLOG ltd. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello Steve Lord, Once you wrote about "TAKE - fix lvm build": > Date: Mon Nov 12 10:25:28 PST 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:106536a > linux/drivers/md/lvm-snap.c - 1.9 > - Fix build gcc -D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o proc_misc.o proc_misc.c proc_misc.c: In function `proc_misc_init': proc_misc.c:573: `proc_ksyms_operations' undeclared (first use in this function) proc_misc.c:573: (Each undeclared identifier is reported only once proc_misc.c:573: for each function it appears in.) make[3]: *** [proc_misc.o] ïÛÉÂËÁ 1 make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/proc' make[2]: *** [first_rule] ïÛÉÂËÁ 2 make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/proc' make[1]: *** [_subdir_proc] ïÛÉÂËÁ 2 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs' make: *** [_dir_fs] ïÛÉÂËÁ 2 @an:/usr/src/linux# @an:/usr/src/linux# gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20011006 (Debian prerelease) @an:/usr/src/linux# -- bye. Andrey Nekrasov, SpyLOG. From owner-linux-xfs@oss.sgi.com Mon Nov 12 11:35:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACJZaO04825 for linux-xfs-outgoing; Mon, 12 Nov 2001 11:35:36 -0800 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 fACJZT004800 for ; Mon, 12 Nov 2001 11:35:29 -0800 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 LAA11457 for ; Mon, 12 Nov 2001 11:35:21 -0800 (PST) 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 NAA3561234; Mon, 12 Nov 2001 13:34:11 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA15517; Mon, 12 Nov 2001 13:34:11 -0600 (CST) Subject: Re: TAKE - fix lvm build From: Eric Sandeen To: Andrey Nekrasov Cc: Steve Lord , linux-xfs@oss.sgi.com In-Reply-To: <20011112222218.A23488@spylog.ru> References: <200111121820.fACIKxs13033@jen.americas.sgi.com> <20011112222218.A23488@spylog.ru> Content-Type: text/plain; charset=koi8-r X-Mailer: Evolution/0.99.0 (Preview Release) Date: 12 Nov 2001 13:32:42 -0600 Message-Id: <1005593562.28912.8.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fACJZT004801 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Andrey - this should fix it. --- linux-2.4.13-ac8/fs/proc/proc_misc.c Mon Nov 5 17:34:08 2001 +++ linux/fs/proc/proc_misc.c Mon Nov 5 18:29:55 2001 @@ -619,9 +619,11 @@ entry = create_proc_entry("mounts", 0, NULL); if (entry) entry->proc_fops = &proc_mounts_operations; +#ifdef CONFIG_MODULES entry = create_proc_entry("ksyms", 0, NULL); if (entry) entry->proc_fops = &proc_ksyms_operations; +#endif proc_root_kcore = create_proc_entry("kcore", S_IRUSR, NULL); if (proc_root_kcore) { proc_root_kcore->proc_fops = &proc_kcore_operations; On Mon, 2001-11-12 at 13:22, Andrey Nekrasov wrote: > Hello Steve Lord, > > Once you wrote about "TAKE - fix lvm build": > > Date: Mon Nov 12 10:25:28 PST 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:106536a > > linux/drivers/md/lvm-snap.c - 1.9 > > - Fix build > > > gcc -D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes > -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe > -mpreferred-stack-boundary=2 -march=i686 -c -o proc_misc.o proc_misc.c > proc_misc.c: In function `proc_misc_init': > proc_misc.c:573: `proc_ksyms_operations' undeclared (first use in this function) > proc_misc.c:573: (Each undeclared identifier is reported only once > proc_misc.c:573: for each function it appears in.) > make[3]: *** [proc_misc.o] ïÛÉÂËÁ 1 > make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/proc' > make[2]: *** [first_rule] ïÛÉÂËÁ 2 > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/proc' > make[1]: *** [_subdir_proc] ïÛÉÂËÁ 2 > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs' > make: *** [_dir_fs] ïÛÉÂËÁ 2 > @an:/usr/src/linux# > > > @an:/usr/src/linux# gcc -v > Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs > gcc version 2.95.4 20011006 (Debian prerelease) > @an:/usr/src/linux# > > > -- > bye. > Andrey Nekrasov, SpyLOG. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Nov 12 11:41:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACJf5005057 for linux-xfs-outgoing; Mon, 12 Nov 2001 11:41:05 -0800 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 fACJf3005035 for ; Mon, 12 Nov 2001 11:41:03 -0800 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 LAA12367 for ; Mon, 12 Nov 2001 11:40:55 -0800 (PST) mail_from (eric@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 NAA3539927 for ; Mon, 12 Nov 2001 13:39:45 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA62771 for ; Mon, 12 Nov 2001 13:39:45 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id fACJcGe32338; Mon, 12 Nov 2001 13:38:16 -0600 Message-Id: <200111121938.fACJcGe32338@stout.americas.sgi.com> Date: Mon, 12 Nov 2001 13:38:16 -0600 From: Eric Sandeen Subject: TAKE - fix non-module-enabled build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Nov 12 11:38:31 PST 2001 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:106550a linux/fs/proc/proc_misc.c - 1.24 - fix non-modular builds From owner-linux-xfs@oss.sgi.com Mon Nov 12 13:02:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACL2Cs08720 for linux-xfs-outgoing; Mon, 12 Nov 2001 13:02:12 -0800 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 fACL29008698 for ; Mon, 12 Nov 2001 13:02:09 -0800 Received: from pyewacket.nic.uklinux.net (host213-122-7-247.btconnect.com [213.122.7.247]) (authenticated) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id fACL22Z06436 for ; Mon, 12 Nov 2001 21:02:02 GMT Envelope-To: Received: from [127.0.0.1] (helo=there) by pyewacket.nic.uklinux.net with smtp (Exim 3.33 #1) id 163OBY-0006c8-00 for linux-xfs@oss.sgi.com; Mon, 12 Nov 2001 21:00:04 +0000 Content-Type: text/plain; charset="iso-8859-1" From: nic Reply-To: nic@uklinux.net Organization: Quixotic Hackers To: linux-xfs@oss.sgi.com Subject: [Ignore] Re: CVS server config or dir wrong? Date: Mon, 12 Nov 2001 21:00:04 +0000 X-Mailer: KMail [version 1.3.1] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Monday 12 November 2001 14:34, nic wrote: > pyewacket Red Hat 7.2 x86 $ export CVSROOT=':pserver:cvs@oss.sgi.com:/cvs' > pyewacket Red Hat 7.2 x86 $ cvs -z3 update -d Sorry ran it in the wrong directory. That'll teach me for having a week off. Yet another PBKAC, nic From owner-linux-xfs@oss.sgi.com Mon Nov 12 13:08:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACL8rH08956 for linux-xfs-outgoing; Mon, 12 Nov 2001 13:08:53 -0800 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 fACL8o008933 for ; Mon, 12 Nov 2001 13:08:50 -0800 Received: from an.local (an.local [192.168.4.50]) by mail.spylog.com (Postfix) with ESMTP id B785D2C1D6; Tue, 13 Nov 2001 00:08:44 +0300 (MSK) Received: by an.local (Postfix, from userid 1000) id 925FE1C38738; Tue, 13 Nov 2001 00:08:44 +0300 (MSK) Date: Tue, 13 Nov 2001 00:08:44 +0300 From: Andrey Nekrasov To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - fix non-module-enabled build Message-ID: <20011113000844.A988@spylog.ru> Mail-Followup-To: Eric Sandeen , linux-xfs@oss.sgi.com References: <200111121938.fACJcGe32338@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200111121938.fACJcGe32338@stout.americas.sgi.com> User-Agent: Mutt/1.3.23i Organization: SpyLOG ltd. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello Eric Sandeen, Once you wrote about "TAKE - fix non-module-enabled build": > Date: Mon Nov 12 11:38:31 PST 2001 > Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > Modid: 2.4.x-xfs:slinx:106550a > linux/fs/proc/proc_misc.c - 1.24 > - fix non-modular builds Thanks. Now compile ok. -- bye. Andrey Nekrasov, SpyLOG. From owner-linux-xfs@oss.sgi.com Mon Nov 12 15:37:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACNbci17479 for linux-xfs-outgoing; Mon, 12 Nov 2001 15:37:38 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACNbZ017457 for ; Mon, 12 Nov 2001 15:37:35 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with SMTP id fACNbTK04666 for ; Mon, 12 Nov 2001 15:37:29 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA07621; Tue, 13 Nov 2001 10:36:12 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA28798; Tue, 13 Nov 2001 10:36:10 +1100 (AEDT) Date: Tue, 13 Nov 2001 10:36:10 +1100 From: Nathan Scott To: mdew Cc: xfs Subject: Re: ext3 merge causing problems? Message-ID: <20011113103610.D589112@wobbly.melbourne.sgi.com> References: <1005602753.372.1.camel@mdew> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1005602753.372.1.camel@mdew>; from rpbrown@xtra.co.nz on Tue, Nov 13, 2001 at 11:05:52AM +1300 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Nov 13, 2001 at 11:05:52AM +1300, mdew wrote: > > is this the reason why pre2/pre3 hasnt been merged into CVS yet? :) > > from.. http://kt.zork.net/kernel-traffic/kt20011112_141.html > > * There is an interaction failure between ext3 and the current Extended > Attributes and Access Control Lists patch which leads to crashes under > heavy load on SMP. This is possibly due to a subtle API change between > ext3 in 2.2 and 2.4 kernels (ie: I broke it). On the to-do list. > No, that wasn't the reason - we currently use different EA code to the patch refered to above. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Nov 12 15:35:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACNZgj17399 for linux-xfs-outgoing; Mon, 12 Nov 2001 15:35:42 -0800 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 fACNZY017375 for ; Mon, 12 Nov 2001 15:35:34 -0800 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 AAA2237854 for ; Tue, 13 Nov 2001 00:35:33 +0100 (CET) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA3559360 for ; Mon, 12 Nov 2001 17:34:16 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA03583 for ; Mon, 12 Nov 2001 17:34:15 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id fACNWjs26244; Mon, 12 Nov 2001 17:32:45 -0600 Message-Id: <200111122332.fACNWjs26244@stout.americas.sgi.com> Date: Mon, 12 Nov 2001 17:32:45 -0600 From: Eric Sandeen Subject: TAKE - Merge up to 2.4.15-pre4 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk (Once more, with feeling!) Merge up to 2.4.15-pre4 Date: Mon Nov 12 15:32:07 PST 2001 Workarea: stout.americas.sgi.com:/localhome/eric/merge/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:106589a linux/arch/i386/kernel/acpitable.h - 1.1 linux/drivers/net/pcmcia/ax8390.h - 1.1 linux/drivers/net/pcmcia/axnet_cs.c - 1.1 linux/kernel/sched.c - 1.45 linux/include/linux/pci.h - 1.52 linux/include/linux/kernel.h - 1.29 linux/include/linux/console.h - 1.8 linux/include/asm-i386/processor.h - 1.30 linux/fs/ext2/super.c - 1.20 linux/fs/Makefile - 1.42 linux/fs/Config.in - 1.71 linux/drivers/usb/hub.h - 1.17 linux/drivers/usb/hub.c - 1.40 linux/drivers/pci/pci.c - 1.47 linux/drivers/net/eepro100.c - 1.35 linux/drivers/isdn/isdnloop/isdnloop.c - 1.11 linux/drivers/char/Config.in - 1.54 linux/arch/i386/math-emu/fpu_proto.h - 1.3 linux/arch/i386/kernel/setup.c - 1.60 linux/arch/i386/defconfig - 1.82 linux/arch/i386/boot/compressed/misc.c - 1.13 linux/Makefile - 1.154 linux/Documentation/Configure.help - 1.117 linux/drivers/parport/parport_pc.c - 1.43 linux/include/linux/isapnp.h - 1.11 linux/drivers/pnp/isapnp.c - 1.23 linux/drivers/pcmcia/smc34c90.h - 1.4 linux/drivers/pcmcia/rsrc_mgr.h - 1.6 linux/drivers/pcmcia/rsrc_mgr.c - 1.14 linux/drivers/pcmcia/i82365.c - 1.22 linux/drivers/pcmcia/ds.c - 1.17 linux/drivers/pcmcia/cs.c - 1.30 linux/drivers/pcmcia/cistpl.c - 1.12 linux/drivers/pcmcia/cb_enabler.c - 1.10 linux/drivers/pcmcia/cardbus.c - 1.18 linux/drivers/pcmcia/Makefile - 1.12 linux/drivers/net/pcmcia/Makefile - 1.19 linux/drivers/net/pcmcia/Config.in - 1.25 linux/fs/proc/proc_misc.c - 1.25 linux/drivers/pcmcia/old-yenta.h - 1.3 linux/Documentation/usb/usb-serial.txt - 1.17 linux/drivers/sound/ac97_codec.c - 1.21 linux/include/linux/raid/md_k.h - 1.14 linux/include/linux/ac97_codec.h - 1.12 linux/drivers/video/hgafb.c - 1.12 linux/drivers/parport/ChangeLog - 1.24 linux/drivers/usb/serial/ftdi_sio.c - 1.24 linux/drivers/usb/serial/visor.h - 1.7 linux/drivers/usb/serial/visor.c - 1.25 linux/arch/i386/kernel/bluesmoke.c - 1.14 linux/drivers/md/lvm-snap.c - 1.10 linux/drivers/usb/serial/mct_u232.c - 1.11 linux/drivers/sound/ymfpci.c - 1.13 linux/drivers/usb/usb-skeleton.c - 1.5 linux/fs/partitions/ldm.h - 1.5 linux/fs/partitions/ldm.c - 1.4 linux/include/linux/raid/multipath.h - 1.2 linux/drivers/md/multipath.c - 1.3 linux/drivers/usb/serial/ir-usb.c - 1.4 linux/arch/i386/kernel/acpitable.c - 1.2 linux/fs/intermezzo/journal_xfs.c - 1.2 linux/fs/intermezzo/methods.c - 1.2 linux/fs/seq_file.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Nov 12 16:32:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAD0WZZ18457 for linux-xfs-outgoing; Mon, 12 Nov 2001 16:32:35 -0800 Received: from math.psu.edu (leibniz.math.psu.edu [146.186.130.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAD0WT018435 for ; Mon, 12 Nov 2001 16:32:30 -0800 Received: from weyl.math.psu.edu (weyl.math.psu.edu [146.186.130.226]) by math.psu.edu (8.9.3/8.9.3) with ESMTP id TAA20950; Mon, 12 Nov 2001 19:32:18 -0500 (EST) Received: from localhost (viro@localhost) by weyl.math.psu.edu (8.9.3/8.9.3) with ESMTP id TAA23235; Mon, 12 Nov 2001 19:32:18 -0500 (EST) X-Authentication-Warning: weyl.math.psu.edu: viro owned process doing -bs Date: Mon, 12 Nov 2001 19:32:18 -0500 (EST) From: Alexander Viro To: Andreas Gruenbacher cc: Nathan Scott , Linus Torvalds , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [RFC][PATCH] VFS interface for extended attributes 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, 12 Nov 2001, Andreas Gruenbacher wrote: > There are curently two paths by which the extended attribute inode > operations can be invoked: (a) from a system call, (b) from the > permission() inode operation, when checking the access ACL of a file. We > could trivially use a dentry in (a), but unfortunately we don't have a > choice in (b), as permission() itself is not passed a dentry. Which means that converting permission() to vfsmount/dentry should be done first. And that's not hard to do. > > Rule of the tumb: if your function got a "cmd" argument - it's broken. > > ioctl(2). fcntl(2). prctl(2). quotactl(2). sysfs(2). Missed'em'V IPC > > syscalls. Enough, already. > > There is one difference between the interfaces you are complaining about > above and the proposed EA interface for EA's: In those interfaces you have > wildcard parameters that are used for who-knows-what, depending on a > command-like parameter, including use as a value, use as a pointer to a > value/struct, etc. Yes, and? You've got more than enough material for the same kind of abuse. What's more, you _already_ have it - in some of the subfunctions *data is read from, in some - written to, in some - ignored. Worse yet, in some subfunctions we put structured data in there, in some - just a chunk of something. With all that, who had said that a year down the road we won't get a dozen of new syscalls hiding behind that one? Sorry, folks, but idea of private extendable syscall table (per-filesystem, no less) doesn't look like a good thing. That's _the_ reason why ioctl() is bad. From owner-linux-xfs@oss.sgi.com Mon Nov 12 16:48:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAD0mJh18748 for linux-xfs-outgoing; Mon, 12 Nov 2001 16:48:19 -0800 Received: from green.csi.cam.ac.uk (exim@green.csi.cam.ac.uk [131.111.8.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAD0mA018726 for ; Mon, 12 Nov 2001 16:48:14 -0800 Received: from rain.christs.cam.ac.uk ([131.111.219.141] helo=thunder.cam.ac.uk) by green.csi.cam.ac.uk with esmtp (Exim 3.22 #1) id 163Rju-0003Wt-00; Tue, 13 Nov 2001 00:47:46 +0000 Message-Id: <5.1.0.14.2.20011113004430.03264ec0@pop.cus.cam.ac.uk> X-Sender: aia21@pop.cus.cam.ac.uk X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 13 Nov 2001 00:47:45 +0000 To: Alexander Viro From: Anton Altaparmakov Subject: Re: [RFC][PATCH] VFS interface for extended attributes Cc: Andreas Gruenbacher , Nathan Scott , Linus Torvalds , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-xfs@oss.sgi.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 00:32 13/11/01, Alexander Viro wrote: >On Mon, 12 Nov 2001, Andreas Gruenbacher wrote: > > There is one difference between the interfaces you are complaining about > > above and the proposed EA interface for EA's: In those interfaces you have > > wildcard parameters that are used for who-knows-what, depending on a > > command-like parameter, including use as a value, use as a pointer to a > > value/struct, etc. > >Yes, and? You've got more than enough material for the same kind of >abuse. What's more, you _already_ have it - in some of the subfunctions >*data is read from, in some - written to, in some - ignored. Worse >yet, in some subfunctions we put structured data in there, in some - >just a chunk of something. > >With all that, who had said that a year down the road we won't get a >dozen of new syscalls hiding behind that one? > >Sorry, folks, but idea of private extendable syscall table (per-filesystem, >no less) doesn't look like a good thing. That's _the_ reason why ioctl() >is bad. Al, Out of interest, which access interface(s) would you like to see used? Giving a few suggestions you would be happy with would be a lot easier on anyone trying to develop a filesystem API than for them having to come up with one after the other until one is found which you approve of... (-; Best regards, Anton -- "I've not lost my mind. It's backed up on tape somewhere." - Unknown -- Anton Altaparmakov (replace at with @) Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ From owner-linux-xfs@oss.sgi.com Mon Nov 12 17:58:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAD1w5K20743 for linux-xfs-outgoing; Mon, 12 Nov 2001 17:58:05 -0800 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 fAD1w2020721 for ; Mon, 12 Nov 2001 17:58:02 -0800 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 RAA01773 for ; Mon, 12 Nov 2001 17:57:38 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id MAA22736; Tue, 13 Nov 2001 12:57:34 +1100 Date: Tue, 13 Nov 2001 12:57:34 +1100 From: Keith Owens Message-Id: <200111130157.MAA22736@sherman.melbourne.sgi.com> Subject: TAKE - Remove generated scsi files Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk drivers/scsi/{53c8xx,sim710}_[du].h files are generated and shipped, causing permission problems for source repositories. The XFS tree excludes these files, if you want them then they are automatically generated. Date: Mon Nov 12 17:55:05 PST 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:106600a linux/drivers/scsi/53c8xx_u.h - 1.5 linux/drivers/scsi/53c8xx_d.h - 1.7 linux/drivers/scsi/sim710_d.h - 1.6 linux/drivers/scsi/sim710_u.h - 1.4 From owner-linux-xfs@oss.sgi.com Mon Nov 12 19:22:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAD3MaD24220 for linux-xfs-outgoing; Mon, 12 Nov 2001 19:22:36 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAD3MX024198 for ; Mon, 12 Nov 2001 19:22:33 -0800 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 TAA04086 for ; Mon, 12 Nov 2001 19:22:30 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id OAA17131; Tue, 13 Nov 2001 14:22:25 +1100 Date: Tue, 13 Nov 2001 14:22:25 +1100 From: Keith Owens Message-Id: <200111130322.OAA17131@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade kdbm_pg for 2.4.15-pre4 VM flags Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Nov 12 19:12:34 PST 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:106606a linux/kdb/modules/kdbm_pg.c - 1.43 linux/kdb/ChangeLog - 1.11 From owner-linux-xfs@oss.sgi.com Mon Nov 12 19:28:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAD3SCV24410 for linux-xfs-outgoing; Mon, 12 Nov 2001 19:28:12 -0800 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 fAD3SA024388 for ; Mon, 12 Nov 2001 19:28:10 -0800 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 TAA17162 for ; Mon, 12 Nov 2001 19:28:01 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id OAA17431; Tue, 13 Nov 2001 14:28:04 +1100 Date: Tue, 13 Nov 2001 14:28:04 +1100 From: Keith Owens Message-Id: <200111130328.OAA17431@sherman.melbourne.sgi.com> Subject: TAKE - Add missing dependency for 53c7,8xx.o Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Linus's tree is missing a dependency for 53c7,8xx.o on 53c8xx_u.h. Correct the bug, XFS does not ship 53c8xx_u.h. Date: Mon Nov 12 19:25:49 PST 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:106607a linux/drivers/scsi/Makefile - 1.31 From owner-linux-xfs@oss.sgi.com Mon Nov 12 19:36:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAD3aLw24624 for linux-xfs-outgoing; Mon, 12 Nov 2001 19:36:21 -0800 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 fAD3aJ024602 for ; Mon, 12 Nov 2001 19:36:19 -0800 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 TAA04243 for ; Mon, 12 Nov 2001 19:35:56 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id OAA17554; Tue, 13 Nov 2001 14:35:15 +1100 Date: Tue, 13 Nov 2001 14:35:15 +1100 From: Keith Owens Message-Id: <200111130335.OAA17554@sherman.melbourne.sgi.com> Subject: TAKE - Typo in kdbm_pg.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Nov 12 19:34:05 PST 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:106608a linux/kdb/modules/kdbm_pg.c - 1.44 From owner-linux-xfs@oss.sgi.com Mon Nov 12 19:49:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAD3nxR24880 for linux-xfs-outgoing; Mon, 12 Nov 2001 19:49:59 -0800 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAD3np024856 for ; Mon, 12 Nov 2001 19:49:56 -0800 Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.46 2001/10/25 21:02:55 root Exp $) with SMTP id DAA21798 for ; Tue, 13 Nov 2001 03:49:51 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001111219490511201 for ; Mon, 12 Nov 2001 19:49:05 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Nov 2001 19:49:54 -0800 Received: from fmsmsxfw01.fm.intel.com ([10.1.199.21]) by fmsmsx27.fm.intel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WY0DXGKL; Mon, 12 Nov 2001 19:49:57 -0800 Received: by fmsmsxfw01.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 11:51:42 +0800 Message-ID: <957BD1C2BF3CD411B6C500A0C944CA260A0FE3@pdsmsx32.pd.intel.com> From: "Xie, May" To: "'linux-xfs@oss.sgi.com'" Subject: Questions on XFS Testing Date: Tue, 13 Nov 2001 11:47:05 +0800 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, It assumes xfs release 1.0 will be used in our product ( I definitely need the old release for redhat7.1 kernel 2.4.2, no other choice). You must have done a lot of testing before announcing the release. I am planning the testing for xfs in product environment. I have some questions about xfs testing. See below: 1. What does xfstests cover? I only see xfscrash and some other test cases, such as fsstress. Does it cover all the functionality and stress testing? I guess not. So what else you used for testing of the specific features for journaling file system as well as a basic file system functionality. Such as reliable fault recovery, scalibility (large file sizes, large partitions, large number of files), commit... 2. Did you do reliability testing? What test cases used for it? Where can I get them? 3. What suggestions you can give me on my testing? Such as what kind of testing is my focus? is functional testing ( basic file system functionlity + journaling funtionality) necessary? Or do I just focus on performance and reliabilty testing or something else? 4. Is xfs release 1.0 work with LVM? 5. Do you have Regression Test System(RTS) test suite, I know it from XFS Linux Quality Assurance page. Where can I get them? 6. Is there any major problem with xfs release 1.0? Thanks! May From owner-linux-xfs@oss.sgi.com Mon Nov 12 21:27:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAD5RSn27297 for linux-xfs-outgoing; Mon, 12 Nov 2001 21:27:28 -0800 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 fAD5RJ027274 for ; Mon, 12 Nov 2001 21:27:19 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id C354B1E1CC; Tue, 13 Nov 2001 06:27:13 +0100 (MET) Date: Tue, 13 Nov 2001 06:27:11 +0100 From: Andi Kleen To: Alexander Viro Cc: Andreas Gruenbacher , Nathan Scott , Linus Torvalds , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [RFC][PATCH] VFS interface for extended attributes Message-ID: <20011113062711.A1912@wotan.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: ; from viro@math.psu.edu on Mon, Nov 12, 2001 at 07:32:18PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Nov 12, 2001 at 07:32:18PM -0500, Alexander Viro wrote: > Which means that converting permission() to vfsmount/dentry should be > done first. And that's not hard to do. It's just messy as it will require changes in all file systems. > Sorry, folks, but idea of private extendable syscall table (per-filesystem, > no less) doesn't look like a good thing. That's _the_ reason why ioctl() > is bad. Unless I'm badly misreading the patch the op switch() is fixed in VFS mapping to clearly defined inode operations. It is not extensible per filesystem. Arguably they could be split into individual syscalls, but it looks not more like cosmetics at this point. -Andi From owner-linux-xfs@oss.sgi.com Mon Nov 12 22:38:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAD6cGg28545 for linux-xfs-outgoing; Mon, 12 Nov 2001 22:38:16 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAD6c8028522 for ; Mon, 12 Nov 2001 22:38:08 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-110.quicknet.nl [212.58.163.110]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id fAD6c47g026740; Tue, 13 Nov 2001 07:38:04 +0100 (CET) Message-Id: <4.3.2.7.2.20011113072604.03e0ee68@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Nov 2001 07:35:53 +0100 To: "Xie, May" , "'linux-xfs@oss.sgi.com'" From: Seth Mos Subject: Re: Questions on XFS Testing In-Reply-To: <957BD1C2BF3CD411B6C500A0C944CA260A0FE3@pdsmsx32.pd.intel.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:47 13-11-2001 +0800, Xie, May wrote: >Hi, > >It assumes xfs release 1.0 will be used in our product ( I definitely need >the old release for redhat7.1 kernel 2.4.2, no other choice). You must >have done a lot of testing before announcing the release. I am planning >the testing for xfs in product environment. I have some questions about >xfs testing. See below: Do use the updated 2.4.9 kernel for the security updates. If you also fetch the latest command rpms you would have a completely up to date system. >1. What does xfstests cover? I only see xfscrash and some other test >cases, such as fsstress. Does it cover all the functionality and stress >testing? I guess not. Almost all the functionality is tested such as the ACL and quota support. And formatting filesystems with all available options, the xfs dump and restore utililties etc. >So what else you used for testing of the specific features for journaling >file system as well as a basic file system functionality. Such as reliable >fault recovery, scalibility (large file sizes, large partitions, large >number of files), commit... Testing all the userspace utilities that come with XFS to make sure they still work. >2. Did you do reliability testing? What test cases used for it? Where can >I get them? The XFS QA suite is available by cheking out the linux-2.4-xfs tree from CVS. They are in this tree so you can run them yourself if you want to. >3. What suggestions you can give me on my testing? Such as what kind of >testing is my focus? Focus on what are going to use the machine for in production. That will get you the results you want most of the time. > is functional testing ( basic file system functionlity + journaling > funtionality) necessary? Or do I just focus on performance and reliabilty > testing or something else? XFS has already proven stable and fast for me in the past and since all functionality is already there you should test for reliability and performance. >4. Is xfs release 1.0 work with LVM? Yes, the newer updated kernel use a 1.0.1rc4 I believe while the original 2.4.2 used a 0.9.6 AFAIK >5. Do you have Regression Test System(RTS) test suite, I know it from XFS >Linux Quality Assurance page. Where can I get them? It is in the XFS CVS tree. >6. Is there any major problem with xfs release 1.0? Much bugs have been fixed since then. I recommend installing the 2.4.9 kernel which is currently in the testing directory on the ftp site ftp://oss.sgi.com/projects/xfs/download/testing/ Make sure you also fetch the latest cmd rpms or build your own from the CVS tree. 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 Nov 12 23:20:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAD7KB729299 for linux-xfs-outgoing; Mon, 12 Nov 2001 23:20:11 -0800 Received: from pooh.lsc.hu (IDENT:qmailr@lsc.net23.hu [195.56.172.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAD7K8029276 for ; Mon, 12 Nov 2001 23:20:08 -0800 Received: (qmail 30701 invoked by uid 547); 13 Nov 2001 07:35:55 -0000 Date: Tue, 13 Nov 2001 08:35:55 +0100 From: GCS To: linux-xfs@oss.sgi.com Subject: CVS patch, a bit OT Message-ID: <20011113083555.A30696@lsc.hu> 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, How can I get the newest updates from the CVS as a patch? I wouldn't like to pack the whole subdir for the changes, but I am fail with 'cvs diff'. :-/ Thanks, GCS From owner-linux-xfs@oss.sgi.com Tue Nov 13 01:02:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAD928631776 for linux-xfs-outgoing; Tue, 13 Nov 2001 01:02:08 -0800 Received: from mail.loewe-komp.de (mail.loewe-komp.de [62.156.155.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAD91x031753 for ; Tue, 13 Nov 2001 01:01:59 -0800 Received: from loewe-komp.de (pippin.loewe-komp.de [192.168.169.19]) by mail.loewe-komp.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id fAD94OS05566; Tue, 13 Nov 2001 10:04:24 +0100 X-Authentication-Warning: mail.loewe-komp.de: Host pippin.loewe-komp.de [192.168.169.19] claimed to be loewe-komp.de Message-ID: <3BF0E152.47AC899@loewe-komp.de> Date: Tue, 13 Nov 2001 10:01:06 +0100 From: Peter =?iso-8859-1?Q?W=E4chtler?= Organization: LOEWE. Hannover X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.9-ac3 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: "Christian, Chip" CC: linux-xfs@oss.sgi.com, lkml Subject: Re: NFS hit me (2.4.9-xfs) again References: <23D04BDBA646D411BDDD00D0B774B539046028B7@SA-BWMAIL1> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by mail.loewe-komp.de id fAD94OS05566 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fAD920031755 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Christian, Chip" wrote: > > The reason that dput was dropped in 2.4.10 is that there's another one that also gets executed, causing the kernel oops right after the > > if (!pdentry) { > } > code block. > > I think you have a filesystem in need of repair. > > RedHat ships this patch with their 2.4.9 kernels: > > --- linux/fs/nfsd/nfsfh.c~ Fri Aug 17 21:30:25 2001 > +++ linux/fs/nfsd/nfsfh.c Fri Aug 17 21:30:40 2001 > @@ -275,7 +275,6 @@ > d_drop(tdentry); /* we never want ".." hashed */ > if (!pdentry && tdentry->d_inode == NULL) { > /* File system cannot find ".." ... sad but possible */ > - dput(tdentry); > pdentry = ERR_PTR(-EINVAL); > } > if (!pdentry) { Yes, the patch makes sense. I've checked both: /home and /usr/local with xfs_check and with xfs_repair -n No warning, no error. I have removed /var/tmp, which is a reiserfs, from /etc/exports but it was seldom used (if any). Thanks for your effort. I will now closely follow any nfs related patches. > > -----Original Message----- > From: Peter Wächtler [mailto:pwaechtler@loewe-komp.de] > Sent: Friday, November 09, 2001 5:01 > To: linux-xfs@oss.sgi.com > Cc: lkml > Subject: NFS hit me (2.4.9-xfs) again > > Unable to handle kernel NULL pointer dereference at virtual address 00000000 > 00000000 > *pde = 00000000 > Oops: 0000 > CPU: 0 > EIP: 0010:[<00000000>] > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010286 > eax: 00000000 ebx: c9c0d7e0 ecx: 00000000 edx: c03a7b00 > esi: c9c0d560 edi: c9c0d7e0 ebp: c9c0d7e0 esp: cbddde84 > ds: 0018 es: 0018 ss: 0018 > Process nfsd (pid: 233, stackpage=cbddd000) > Stack: c01729f4 cc97f420 c9c0d560 00000005 cdc40a00 c0172e56 c9c0d7e0 00000005 > cd390200 cd390000 cbed2000 cbdddf20 cdc40be8 cd390200 c0173199 cdc40a00 > cd390010 00000005 00000001 00000001 00000008 cbe17e00 cbee48c0 cd390200 > Call Trace: [] [] [] [] [] > [] [] [] [] [] > Code: Bad EIP value. > > >>EIP; 00000000 Before first symbol > Trace; c01729f4 > Trace; c0172e56 > Trace; c0173199 > Trace; c0173ad2 > Trace; c017843d > Trace; c017173c > Trace; c0171003 > Trace; c0240318 > Trace; c0170dab > Trace; c010557f > > This is not the initial crash location - the machine was dead (and no serial > console yet). But after restarting, about 6-10 clients tried to reconnect > to NFSD and caused the crash. > > The crash appears because "child->d_inode->i_op->lookup == NULL" > From owner-linux-xfs@oss.sgi.com Tue Nov 13 02:34:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADAYXV00854 for linux-xfs-outgoing; Tue, 13 Nov 2001 02:34:33 -0800 Received: from mta1-rme.xtra.co.nz (mta1-rme.xtra.co.nz [210.86.15.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADAYU000832 for ; Tue, 13 Nov 2001 02:34:30 -0800 Received: from mdew ([210.86.52.4]) by mta1-rme.xtra.co.nz with ESMTP id <20011113103420.IHFG3964.mta1-rme.xtra.co.nz@mdew> for ; Tue, 13 Nov 2001 23:34:20 +1300 Subject: 2.5.x status? From: mdew To: xfs Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 14 Nov 2001 10:46:39 +1300 Message-Id: <1005688000.1035.18.camel@mdew> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk with the upcoming 2.5.x being opened, I hope the current 2.4.x will be maintained..2.4.x is relitivly stable now, which is what i prefer..and some user may still prefer until 2.6.x is mature enough, maybe have another cvs tree for 2.5.x devel ? What is the current situation with XFS and 2.5.x ? From owner-linux-xfs@oss.sgi.com Tue Nov 13 04:41:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADCfsB03230 for linux-xfs-outgoing; Tue, 13 Nov 2001 04:41:54 -0800 Received: from mta2-rme.xtra.co.nz (mta2-rme.xtra.co.nz [210.86.15.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADCfp003208 for ; Tue, 13 Nov 2001 04:41:51 -0800 Received: from mdew ([210.86.52.4]) by mta2-rme.xtra.co.nz with ESMTP id <20011113124145.DWCA5089.mta2-rme.xtra.co.nz@mdew>; Wed, 14 Nov 2001 01:41:45 +1300 Subject: Re: CVS patch, a bit OT From: mdew To: GCS Cc: xfs In-Reply-To: <20011113083555.A30696@lsc.hu> References: <20011113083555.A30696@lsc.hu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16 (Preview Release) Date: 14 Nov 2001 12:54:00 +1300 Message-Id: <1005695644.1035.22.camel@mdew> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2001-11-13 at 20:35, GCS wrote: > Hi, > > How can I get the newest updates from the CVS as a patch? I wouldn't like to > pack the whole subdir for the changes, but I am fail with 'cvs diff'. :-/ > > Thanks, GCS > you could tarball the entire /usr/src/linux dir and use it as a backup? From owner-linux-xfs@oss.sgi.com Tue Nov 13 06:32:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADEWXV14385 for linux-xfs-outgoing; Tue, 13 Nov 2001 06:32:33 -0800 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 fADEWT014363 for ; Tue, 13 Nov 2001 06:32:29 -0800 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 GAA19043 for ; Tue, 13 Nov 2001 06:30:45 -0800 (PST) mail_from (tbd@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA3570849 for ; Tue, 13 Nov 2001 08:29:36 -0600 (CST) Received: from fsgi158.americas.sgi.com (fsgi158.americas.sgi.com [128.162.191.39]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA18352; Tue, 13 Nov 2001 08:28:14 -0600 (CST) From: Tad Dolphay Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id IAA24797; Tue, 13 Nov 2001 08:28:13 -0600 (CST) Message-Id: <200111131428.IAA24797@fsgi158.americas.sgi.com> Subject: Re: Questions on XFS Testing To: may.xie@intel.com (Xie, May) Date: Tue, 13 Nov 2001 08:28:13 -0600 (CST) Cc: linux-xfs@oss.sgi.com ('linux-xfs@oss.sgi.com') In-Reply-To: <957BD1C2BF3CD411B6C500A0C944CA260A0FE3@pdsmsx32.pd.intel.com> from "Xie, May" at Nov 13, 2001 11:47:05 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 >1. What does xfstests cover? I only see xfscrash and some other test cases, such as fsstress. Does it cover all the functionality and stress testing? I guess not. >So what else you used for testing of the specific features for journaling file system as well as a basic file system functionality. Such as reliable fault recovery, scalibility (large file sizes, large partitions, large number of files), commit... > See http://oss.sgi.com/projects/xfs/101_qa.html for a description of what testing is done. >2. Did you do reliability testing? What test cases used for it? Where can I get them? We use a number of open source tests including but not limited to the following: connectathon (connectathon.org) bonnie Linux Test Project (http://sourceforge.net/projects/ltp/) iozone lmbench (http://www.bitmover.com/lmbench/get_lmbench.html) We also use a number of tests that are not currently open source. >3. What suggestions you can give me on my testing? Such as what kind of testing is my focus? is functional testing ( basic file system functionlity + journaling funtionality) necessary? Or do I just focus on performance and reliabilty testing or something else? >4. Is xfs release 1.0 work with LVM? Yes, for more information on 1.0 look at the 1.0 release announcement at http://oss.sgi.com/projects/xfs/mail_archive/0105/msg00001.html >5. Do you have Regression Test System(RTS) test suite, I know it from XFS Linux Quality Assurance page. Where can I get them? Some of these tests from RTS are included in the tests from the Linux Test Project mentioned above. >6. Is there any major problem with xfs release 1.0? I know of some NFS panics that were fixed in later releases. Tad From owner-linux-xfs@oss.sgi.com Tue Nov 13 06:32:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADEWvZ14443 for linux-xfs-outgoing; Tue, 13 Nov 2001 06:32:57 -0800 Received: from mhkserv.mhk.lu.se (mhkserv.mhk.lu.se [194.47.215.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADEWp014415 for ; Tue, 13 Nov 2001 06:32:52 -0800 Received: from win95 (e414.mhk.lu.se [194.47.215.90]) by mhkserv.mhk.lu.se (Netscape Messaging Server 3.5) with SMTP id 51 for ; Tue, 13 Nov 2001 15:33:37 +0100 X-Sender: hast@mhkserv.mhk.lu.se X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 13 Nov 2001 15:34:28 +0100 To: linux-xfs@oss.sgi.com From: "Marcus Hast" Subject: Harddrive error and XFS corruption Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <20011113143336109.AAA296.51@e414.mhk.lu.se> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, I have 3 disks in a LVM volume with XFS on it. After a recent powerfailiure it no longer came up. At first it would try to do a recovery and get a lot of: hdg: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdg: dma_intr: error=0x40 { UncorrectableError }, LBAsect=134840697, sector=134840696 end_request: I/O error, dev 22:01 (hdg), sector 134840696 As I go through the log now however I see some new errors: hdg: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } hdg: read_intr: error=0x40 { UncorrectableError }, LBAsect=134840697, sector=134840696 end_request: I/O error, dev 22:01 (hdg), sector 134840696 I take it that this means it has gone worse. (read_intr error instead of dma_intr which I have seen is quite common.) This is on a LVM volume with 220G of data. So I have a few questions: Is there any way of getting the data on the other disks back? From what I've seen of the logs it's hdg that's bad. Is there any way of getting warned about this before it happens? I did get a lot of dma_intr errors first, but it seemed to me then that a lot of other people were getting them and safely (?) ignoring them. (From the kernel and LVM lists.) Is there any way I can be "proactive" in avoiding this? By storing metadata redundantly for instance? (I assume that in this particular case it's those parts of the drive which has gone, which is why I'm left with an unmount and unrecoverable system.) Would a check with for instance Bonnie catch a problem like this before it gets bad? I've seen this in a couple of places now, perhaps it would be a good idea to put it in the FAQ or some documents? Marcus Hast, Lund, Sweden, Earth. Living long and prosperous. From owner-linux-xfs@oss.sgi.com Tue Nov 13 06:41:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADEffP14793 for linux-xfs-outgoing; Tue, 13 Nov 2001 06:41:41 -0800 Received: from mustard.heime.net (mustard.heime.net [194.234.65.222]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADEfb014771 for ; Tue, 13 Nov 2001 06:41:38 -0800 Received: from localhost (roy@localhost) by mustard.heime.net (8.11.2/8.9.3) with ESMTP id fADEfV701022 for ; Tue, 13 Nov 2001 15:41:31 +0100 Date: Tue, 13 Nov 2001 15:41:31 +0100 (CET) From: Roy Sigurd Karlsbakk X-Sender: To: XFS Mailing list Subject: Q: Filesystem block sizes available? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi What block sizes are available on XFS filesystems? I've seen the note 'Filesystem block size' on the features list, and it says it's limited to the page size on the given architecture (eg .4k on ia64). I'm running a lab at Compaq in Oslo now, and some guy at storage told me 4k's a waste, and that the SCSI drives wanted 256kB data blocks to really speed it all up. Could XFS help me out? I need REALLY HIGH-SPEED access to the drives.... Software or hardware RAID - I don't care... I just need the speed. Thanks a lot. roy -- Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA Computers are like air conditioners. They stop working when you open Windows. From owner-linux-xfs@oss.sgi.com Tue Nov 13 06:55:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADEtfS15422 for linux-xfs-outgoing; Tue, 13 Nov 2001 06:55:41 -0800 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 fADEtb015398 for ; Tue, 13 Nov 2001 06:55:37 -0800 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 GAA09257 for ; Tue, 13 Nov 2001 06:55:15 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA3569746; Tue, 13 Nov 2001 08:54:20 -0600 (CST) Received: from jen.americas.sgi.com (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 IAA25807; Tue, 13 Nov 2001 08:54:20 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fADEnU917867; Tue, 13 Nov 2001 08:49:30 -0600 Subject: Re: Q: Filesystem block sizes available? From: Steve Lord To: Roy Sigurd Karlsbakk Cc: XFS Mailing list In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.12.08.57 (Preview Release) Date: 13 Nov 2001 08:49:30 -0600 Message-Id: <1005662970.17836.0.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2001-11-13 at 08:41, Roy Sigurd Karlsbakk wrote: > Hi > > What block sizes are available on XFS filesystems? I've seen the note > 'Filesystem block size' on the features list, and it says it's limited to > the page size on the given architecture (eg .4k on ia64). > > I'm running a lab at Compaq in Oslo now, and some guy at storage told me > 4k's a waste, and that the SCSI drives wanted 256kB data blocks to really > speed it all up. Could XFS help me out? I need REALLY HIGH-SPEED access to > the drives.... Software or hardware RAID - I don't care... I just need the > speed. > > Thanks a lot. Right now the filesystem block size on linux is restricted to the machine page size. Fixing this has been on the todo list for a long time now, but other projects keep getting given higher priority. The first thing to appear would be support for smaller block sizes, not bigger ones - the problem in linux is that the kernel was really not designed to provide chunks of memory larger than 1 page with any reliability (i.e. there is a good chance it will fail). Anyway, having said that, xfs will do larger I/O than this, files should get layed out contiguous on disk, and both the read and write path will end up issuing larger requests to the scsi devices. Steve > > roy > > -- > Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA > > Computers are like air conditioners. > They stop working when you open Windows. -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Nov 13 06:56:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADEu0i15571 for linux-xfs-outgoing; Tue, 13 Nov 2001 06:56:00 -0800 Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADEtq015507 for ; Tue, 13 Nov 2001 06:55:52 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id fADEtXCM040596; Tue, 13 Nov 2001 15:55:44 +0100 (CET) Message-Id: <4.3.2.7.2.20011113154059.03878788@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Nov 2001 15:48:27 +0100 To: "Marcus Hast" , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Harddrive error and XFS corruption In-Reply-To: <20011113143336109.AAA296.51@e414.mhk.lu.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:34 13-11-2001 +0100, Marcus Hast wrote: >Hi all, >I have 3 disks in a LVM volume with XFS on it. After a recent powerfailiure it >no longer came up. At first it would try to do a recovery and get a lot of: >hdg: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } >hdg: read_intr: error=0x40 { UncorrectableError }, LBAsect=134840697, >sector=134840696 >end_request: I/O error, dev 22:01 (hdg), sector 134840696 > >I take it that this means it has gone worse. (read_intr error instead of >dma_intr which I have seen is quite common.) Yes, bad cables. > This is on a LVM volume with 220G >of data. Ouch. >So I have a few questions: >Is there any way of getting the data on the other disks back? From what I've >seen of the logs it's hdg that's bad. Yes the disk is broken. You could try and xfs_repair the device and pray that it can restore anything. Run xfs_repair -n to see what it wants to change. >Is there any way of getting warned about this before it happens? I would like to have a magic ball in which I can see when a disk will fail :-) It's called fortune telling. Most IDE disks have something called smart but is not smart enough to warn you most of the time and is off by default in most bioses even. > I did get a >lot of dma_intr errors first, but it seemed to me then that a lot of other >people were getting them and safely (?) ignoring them. (From the kernel and >LVM >lists.) DMA intr is problematic communication with the IDE disks and you should investigate. If the cable is bad you will see CRC errors. However this one says "{ UncorrectableError }, LBAsect=134840697," which means it is unable to read from the disk at that sector. >Is there any way I can be "proactive" in avoiding this? By storing metadata >redundantly for instance? (I assume that in this particular case it's those >parts of the drive which has gone, which is why I'm left with an unmount and >unrecoverable system.) Use a raid level like raid5 or raid1 (mirroring). You can do this with md. >Would a check with for instance Bonnie catch a problem like this before it >gets >bad? No you're disk just broke down. It happens all the time. >I've seen this in a couple of places now, perhaps it would be a good idea to >put it in the FAQ or some documents? There is something in the FAQ about this in the xfs_shutdown section. But that one you only see when ti happens with the system running. It might be that the disk broke because of the power failure (not uncommon). 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 Nov 13 06:58:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADEwVq15769 for linux-xfs-outgoing; Tue, 13 Nov 2001 06:58:31 -0800 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADEwQ015746 for ; Tue, 13 Nov 2001 06:58:26 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id fADEwIcd075465; Tue, 13 Nov 2001 15:58:19 +0100 (CET) Message-Id: <4.3.2.7.2.20011113154940.037ae900@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Nov 2001 15:55:59 +0100 To: Roy Sigurd Karlsbakk , XFS Mailing list From: Seth Mos Subject: Re: Q: Filesystem block sizes available? 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:41 13-11-2001 +0100, Roy Sigurd Karlsbakk wrote: >Hi > >What block sizes are available on XFS filesystems? 4KB on IA32, 8kb on Alpha I believe and 8KB by default on IA64 >I've seen the note >'Filesystem block size' on the features list, and it says it's limited to >the page size on the given architecture (eg .4k on ia64). > >I'm running a lab at Compaq in Oslo now, and some guy at storage told me >4k's a waste, and that the SCSI drives wanted 256kB data blocks to really >speed it all up. Could XFS help me out? I need REALLY HIGH-SPEED access to >the drives.... Software or hardware RAID - I don't care... I just need the >speed. The fs blocksize has not much to do with the amount it writes in one go. XFS uses delayed allocation so it will probably write a lot of data at once anyways. If you can give some Use software raid 0 over multiple 15K RPM scsi disks or go fiber and make a raid 0 out of that. You can even mix them, for optimal effect use disks that are the same size. more spindles == higher speed. Make sure to use multiple controllers to spread the bus activity. XFS also has some builtin heuristics in mkfs.xfs that will detect the striping and make some reasonable assumptions on how to optimize the fs layout. 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 Nov 13 06:59:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADExIJ15899 for linux-xfs-outgoing; Tue, 13 Nov 2001 06:59:18 -0800 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 fADExA015875 for ; Tue, 13 Nov 2001 06:59:10 -0800 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 PAA28824; Tue, 13 Nov 2001 15:59:08 +0100 (MET) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id PAA19994; Tue, 13 Nov 2001 15:59:08 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id A5E2D57306; Tue, 13 Nov 2001 15:58:52 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 6A8D625835; Tue, 13 Nov 2001 15:58:52 +0100 (CET) Message-ID: <3BF1352C.3EE78829@ch.sauter-bc.com> Date: Tue, 13 Nov 2001 15:58:52 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Marcus Hast Cc: linux-xfs@oss.sgi.com Subject: Re: Harddrive error and XFS corruption References: <20011113143336109.AAA296.51@e414.mhk.lu.se> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Marcus Hast schrieb: > > Hi all, > I have 3 disks in a LVM volume with XFS on it. After a recent powerfailiure it > no longer came up. At first it would try to do a recovery and get a lot of: > > hdg: dma_intr: status=0x51 { DriveReady SeekComplete Error } > hdg: dma_intr: error=0x40 { UncorrectableError }, LBAsect=134840697, > sector=134840696 > end_request: I/O error, dev 22:01 (hdg), sector 134840696 It means you have a disk with bad sectors. Some people can work for along time with this drive until the OS wants to access the area with bad sectors. If you are using softraid you will not be able to use the drive because the problem will occur immediately when resyncing the array. This error was always critical for me. > > As I go through the log now however I see some new errors: > > hdg: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } > hdg: read_intr: error=0x40 { UncorrectableError }, LBAsect=134840697, > sector=134840696 > end_request: I/O error, dev 22:01 (hdg), sector 134840696 Don't know what this is: DataRequest Error. I guess the root of the problem is the same like above. > > I take it that this means it has gone worse. (read_intr error instead of > dma_intr which I have seen is quite common.) This is on a LVM volume with 220G > of data. I felt the same pain several times... > > So I have a few questions: > Is there any way of getting the data on the other disks back? From what I've > seen of the logs it's hdg that's bad. > > Is there any way of getting warned about this before it happens? I did get a > lot of dma_intr errors first, but it seemed to me then that a lot of other > people were getting them and safely (?) ignoring them. (From the kernel and > LVM > lists.) > > Is there any way I can be "proactive" in avoiding this? By storing metadata > redundantly for instance? (I assume that in this particular case it's those > parts of the drive which has gone, which is why I'm left with an unmount and > unrecoverable system.) > > Would a check with for instance Bonnie catch a problem like this before it > gets > bad? My answer: Use RAID! All those cheap big IDE drives have the problem of not being very reliable and SoftRAID is very good on linux. Use it. Sometimes you can buy 8 identical drives and 3 or 4 of them fail after some hours of stress. S.M.A.R.T should also tell you when things go bad with you drive but I don't care about that. -Simon > > I've seen this in a couple of places now, perhaps it would be a good idea to > put it in the FAQ or some documents? > > Marcus Hast, Lund, Sweden, Earth. > Living long and prosperous. From owner-linux-xfs@oss.sgi.com Tue Nov 13 07:00:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADF0mD16079 for linux-xfs-outgoing; Tue, 13 Nov 2001 07:00:48 -0800 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 fADF0f016056 for ; Tue, 13 Nov 2001 07:00:41 -0800 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 QAA2267814 for ; Tue, 13 Nov 2001 16:00:37 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA3293049; Tue, 13 Nov 2001 08:59:20 -0600 (CST) Received: from jen.americas.sgi.com (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 IAA23267; Tue, 13 Nov 2001 08:59:19 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fADEsU217890; Tue, 13 Nov 2001 08:54:30 -0600 Subject: Re: Harddrive error and XFS corruption From: Steve Lord To: Marcus Hast Cc: linux-xfs@oss.sgi.com In-Reply-To: <20011113143336109.AAA296.51@e414.mhk.lu.se> References: <20011113143336109.AAA296.51@e414.mhk.lu.se> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.12.08.57 (Preview Release) Date: 13 Nov 2001 08:54:30 -0600 Message-Id: <1005663270.17836.2.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Unfortunately, without some form of backup, there is not really a lot which can be done with this filesystem, you could try replacing the failed drive and running xfs_repair, but I doubt it will end up with anything which mounts. The only way to protect against this type of thing is to have backups of your data - either in dump format, or using some form of raid mirroring or parity protection. Steve On Tue, 2001-11-13 at 08:34, Marcus Hast wrote: > Hi all, > I have 3 disks in a LVM volume with XFS on it. After a recent powerfailiure it > no longer came up. At first it would try to do a recovery and get a lot of: > > hdg: dma_intr: status=0x51 { DriveReady SeekComplete Error } > hdg: dma_intr: error=0x40 { UncorrectableError }, LBAsect=134840697, > sector=134840696 > end_request: I/O error, dev 22:01 (hdg), sector 134840696 > > As I go through the log now however I see some new errors: > > hdg: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } > hdg: read_intr: error=0x40 { UncorrectableError }, LBAsect=134840697, > sector=134840696 > end_request: I/O error, dev 22:01 (hdg), sector 134840696 > > I take it that this means it has gone worse. (read_intr error instead of > dma_intr which I have seen is quite common.) This is on a LVM volume with 220G > of data. > > So I have a few questions: > Is there any way of getting the data on the other disks back? From what I've > seen of the logs it's hdg that's bad. > > Is there any way of getting warned about this before it happens? I did get a > lot of dma_intr errors first, but it seemed to me then that a lot of other > people were getting them and safely (?) ignoring them. (From the kernel and > LVM > lists.) > > Is there any way I can be "proactive" in avoiding this? By storing metadata > redundantly for instance? (I assume that in this particular case it's those > parts of the drive which has gone, which is why I'm left with an unmount and > unrecoverable system.) > > Would a check with for instance Bonnie catch a problem like this before it > gets > bad? > > I've seen this in a couple of places now, perhaps it would be a good idea to > put it in the FAQ or some documents? > > Marcus Hast, Lund, Sweden, Earth. > Living long and prosperous. -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Nov 13 07:01:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADF1CL16216 for linux-xfs-outgoing; Tue, 13 Nov 2001 07:01:12 -0800 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 fADF18016193 for ; Tue, 13 Nov 2001 07:01:08 -0800 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 HAA09610 for ; Tue, 13 Nov 2001 07:00:47 -0800 (PST) mail_from (sandeen@sgi.com) Received: from localhost (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA03385; Tue, 13 Nov 2001 07:00:36 -0800 (PST) Subject: Re: Questions on XFS Testing From: Eric Sandeen To: "Xie, May" Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: <957BD1C2BF3CD411B6C500A0C944CA260A0FE3@pdsmsx32.pd.intel.com> References: <957BD1C2BF3CD411B6C500A0C944CA260A0FE3@pdsmsx32.pd.intel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 13 Nov 2001 09:00:35 -0600 Message-Id: <1005663636.3186.3.camel@lager2> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi May - On Mon, 2001-11-12 at 21:47, Xie, May wrote: > Hi, > > It assumes xfs release 1.0 will be used in our product ( I definitely need the old release for redhat7.1 kernel 2.4.2, no other choice). You must have done a lot of testing before announcing the release. I am planning the testing for xfs in product environment. I have some questions about xfs testing. See below: Can you share the reason for the 2.4.2 kernel? I understand that you must have some other constraint, but I would feel uneasy with you using 1.0, XFS has moved quite a bit since then. > 1. What does xfstests cover? I only see xfscrash and some other test cases, such as fsstress. Does it cover all the functionality and stress testing? I guess not. Each "0??" file in cmd/xfstests tests different functionality. Edit "common.config" to add your your system, and then run ./check 0??. Read each 0?? file to get some idea of what it tests. > 6. Is there any major problem with xfs release 1.0? You might look at the new features / changelog for 1.0.1 for some info on this. http://oss.sgi.com/projects/xfs/101_changes.html And of course more since then... Hope that helps, -Eric From owner-linux-xfs@oss.sgi.com Tue Nov 13 07:01:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADF1qw16361 for linux-xfs-outgoing; Tue, 13 Nov 2001 07:01:52 -0800 Received: from mustard.heime.net (mustard.heime.net [194.234.65.222]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADF1l016339 for ; Tue, 13 Nov 2001 07:01:47 -0800 Received: from localhost (roy@localhost) by mustard.heime.net (8.11.2/8.9.3) with ESMTP id fADF1PZ01212; Tue, 13 Nov 2001 16:01:25 +0100 Date: Tue, 13 Nov 2001 16:01:25 +0100 (CET) From: Roy Sigurd Karlsbakk X-Sender: To: Steve Lord cc: XFS Mailing list , Tux mailing list Subject: Re: Q: Filesystem block sizes available? In-Reply-To: <1005662970.17836.0.camel@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 > Right now the filesystem block size on linux is restricted to the > machine page size. Fixing this has been on the todo list for a > long time now, but other projects keep getting given higher priority. > The first thing to appear would be support for smaller block sizes, > not bigger ones - the problem in linux is that the kernel was really > not designed to provide chunks of memory larger than 1 page with any > reliability (i.e. there is a good chance it will fail). > > Anyway, having said that, xfs will do larger I/O than this, files should > get layed out contiguous on disk, and both the read and write path will > end up issuing larger requests to the scsi devices. ok. So the fs block size really doesn't matter - is that it? I'm trying to set up streaming of multi-gigabyte files from a file system, and it's all too slow. Even with a RAID-0 with 5 drives (SCSI-3/160MBps/10k spin), I cannot get the speed higher than around 30 on ext2. Do you or anyone else have some idea of when the TUX/XFS potch incompatibility problem will be solved? I need Tux (the in-kernel web server from RedHat) in this project as well... thanks roy -- Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA Computers are like air conditioners. They stop working when you open Windows. From owner-linux-xfs@oss.sgi.com Tue Nov 13 07:05:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADF51S16559 for linux-xfs-outgoing; Tue, 13 Nov 2001 07:05:01 -0800 Received: from mustard.heime.net (mustard.heime.net [194.234.65.222]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADF4v016537 for ; Tue, 13 Nov 2001 07:04:57 -0800 Received: from localhost (roy@localhost) by mustard.heime.net (8.11.2/8.9.3) with ESMTP id fADF4en01236; Tue, 13 Nov 2001 16:04:40 +0100 Date: Tue, 13 Nov 2001 16:04:40 +0100 (CET) From: Roy Sigurd Karlsbakk X-Sender: To: Seth Mos cc: XFS Mailing list Subject: Re: Q: Filesystem block sizes available? In-Reply-To: <4.3.2.7.2.20011113154940.037ae900@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 > The fs blocksize has not much to do with the amount it writes in one go. > XFS uses delayed allocation so it will probably write a lot of data at once > anyways. How about reading? The reading is really essensial here - writing is done by batch, and can take whatever time it likes (almost :-) > > If you can give some que? > Use software raid 0 over multiple 15K RPM scsi disks or go fiber and make a > raid 0 out of that. > You can even mix them, for optimal effect use disks that are the same size. > more spindles == higher speed. Make sure to use multiple controllers to > spread the bus activity. > > XFS also has some builtin heuristics in mkfs.xfs that will detect the > striping and make some reasonable assumptions on how to optimize the fs layout. thanks -- Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA Computers are like air conditioners. They stop working when you open Windows. From owner-linux-xfs@oss.sgi.com Tue Nov 13 07:12:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADFC5c16813 for linux-xfs-outgoing; Tue, 13 Nov 2001 07:12:05 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADFBv016788 for ; Tue, 13 Nov 2001 07:11:57 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fADFBqT23349 for ; Tue, 13 Nov 2001 07:11:52 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA91972; Tue, 13 Nov 2001 09:10:35 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.32 #1 (Debian)) id 163fCt-00012D-00; Tue, 13 Nov 2001 09:10:35 -0600 Date: Tue, 13 Nov 2001 09:10:35 -0600 From: Nathan Straz To: "Xie, May" Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: Questions on XFS Testing Message-ID: <20011113091035.B9701@sgi.com> Mail-Followup-To: "Xie, May" , "'linux-xfs@oss.sgi.com'" References: <957BD1C2BF3CD411B6C500A0C944CA260A0FE3@pdsmsx32.pd.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <957BD1C2BF3CD411B6C500A0C944CA260A0FE3@pdsmsx32.pd.intel.com> User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Nov 13, 2001 at 11:47:05AM +0800, Xie, May wrote: > 1. What does xfstests cover? xfstests, the XFS QA suite, covers functional and regression testing of XFS specific features and some general stress and regression testing. Descriptions of each test are included in the header of the test. > So what else you used for testing of the specific features for > journaling file system as well as a basic file system functionality. > Such as reliable fault recovery, scalibility (large file sizes, large > partitions, large number of files), commit... We pull tests from a large set of test software, including open and closed source tests. > 2. Did you do reliability testing? What test cases used for it? Where > can I get them? We do some "pull the plug" testing as needed. That kind of testing doesn't automate too well and takes up a lot of time. > 3. What suggestions you can give me on my testing? Such as what kind > of testing is my focus? is functional testing ( basic file system > functionlity + journaling funtionality) necessary? Or do I just focus > on performance and reliabilty testing or something else? Test what you need to verify that your application/product works correctly. Also, if you come up with some tests of general use, please contribute them to the Linux Test Project. > 4. Is xfs release 1.0 work with LVM? XFS 1.0 does work with LVM, as does 1.0.1. The next release, 1.0.2, will use LVM 1.0.1rc4. > 5. Do you have Regression Test System(RTS) test suite, I know it from > XFS Linux Quality Assurance page. Where can I get them? This is an internal SGI test suite. It has not been open sourced yet and there are not resources available to open source it. Perhaps if you could give my management some incentive to release them, they could be made available. > 6. Is there any major problem with xfs release 1.0? Major problems vary from person to person. I would suggest looking through all the "TAKE" messages in the mailing list since 1.0 and decide if any of those fixes affect your product. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Tue Nov 13 07:12:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADFCfH16941 for linux-xfs-outgoing; Tue, 13 Nov 2001 07:12:41 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADFCc016919 for ; Tue, 13 Nov 2001 07:12:38 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fADFCXK25815 for ; Tue, 13 Nov 2001 07:12:33 -0800 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3583431 for ; Tue, 13 Nov 2001 09:11:17 -0600 (CST) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA17556 for ; Tue, 13 Nov 2001 09:11:17 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX) id JAA86668 for linux-xfs@oss.sgi.com; Tue, 13 Nov 2001 09:10:44 -0600 (CST) Date: Tue, 13 Nov 2001 09:10:44 -0600 (CST) From: Dean Roehrich Message-Id: <200111131510.JAA86668@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - add informative warning to dmapi set_eventlist test Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Nov 13 07:10:47 PST 2001 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/dmapitests The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs/cmd/xfstests/dmapi Modid: 2.4.x-xfs:slinx:106626a src/suite1/cmd/set_eventlist.c - 1.3 - read/write/trunc events are managed region events--print a warning if we try to set them with this tool. (I get bitten by this, and confused by it, too often) From owner-linux-xfs@oss.sgi.com Tue Nov 13 07:13:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADFDO017077 for linux-xfs-outgoing; Tue, 13 Nov 2001 07:13:24 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADFDL017055 for ; Tue, 13 Nov 2001 07:13:21 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id fADFDGK25907 for ; Tue, 13 Nov 2001 07:13:16 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3578517; Tue, 13 Nov 2001 09:12:00 -0600 (CST) Received: from jen.americas.sgi.com (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 JAA29046; Tue, 13 Nov 2001 09:12:00 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id fADF7AH17915; Tue, 13 Nov 2001 09:07:10 -0600 Subject: Re: Q: Filesystem block sizes available? From: Steve Lord To: Roy Sigurd Karlsbakk Cc: Seth Mos , XFS Mailing list In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.12.08.57 (Preview Release) Date: 13 Nov 2001 09:07:10 -0600 Message-Id: <1005664030.17854.6.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2001-11-13 at 09:04, Roy Sigurd Karlsbakk wrote: > > The fs blocksize has not much to do with the amount it writes in one go. > > XFS uses delayed allocation so it will probably write a lot of data at once > > anyways. > > How about reading? The reading is really essensial here - writing is done > by batch, and can take whatever time it likes (almost :-) Reading in Linux does readahead - but I do not think it asks for more than 32 pages at once. We are using mostly the generic linux code paths for read unless you use O_DIRECT. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Nov 13 07:19:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADFJZd19783 for linux-xfs-outgoing; Tue, 13 Nov 2001 07:19:35 -0800 Received: from mustard.heime.net (mustard.heime.net [194.234.65.222]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADFJV019758 for ; Tue, 13 Nov 2001 07:19:31 -0800 Received: from localhost (roy@localhost) by mustard.heime.net (8.11.2/8.9.3) with ESMTP id fADFJEp01324; Tue, 13 Nov 2001 16:19:14 +0100 Date: Tue, 13 Nov 2001 16:19:14 +0100 (CET) From: Roy Sigurd Karlsbakk X-Sender: To: Steve Lord cc: Seth Mos , XFS Mailing list Subject: Re: Q: Filesystem block sizes available? In-Reply-To: <1005664030.17854.6.camel@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 > Reading in Linux does readahead - but I do not think it asks for more > than 32 pages at once. We are using mostly the generic linux code paths > for read unless you use O_DIRECT. ok... I currently use the Tux web server, and cannot change the way it reads. Can I rather patch the kernel source to allow for 64-page readahead? That'll be 256kB chunks, something the SCSI devices will appreciate a lot, and thus making me a happy man :-) -- Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA Computers are like air conditioners. They stop working when you open Windows. From owner-linux-xfs@oss.sgi.com Tue Nov 13 07:20:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADFKN719988 for linux-xfs-outgoing; Tue, 13 Nov 2001 07:20:23 -0800 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 fADFKK019966 for ; Tue, 13 Nov 2001 07:20:20 -0800 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 HAA00128 for ; Tue, 13 Nov 2001 07:19:58 -0800 (PST) mail_from (sandeen@sgi.com) Received: from localhost (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA58834; Tue, 13 Nov 2001 07:19:48 -0800 (PST) Subject: Re: Q: Filesystem block sizes available? From: Eric Sandeen To: Roy Sigurd Karlsbakk Cc: Steve Lord , XFS Mailing list , Tux mailing list In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 13 Nov 2001 09:19:47 -0600 Message-Id: <1005664789.3186.5.camel@lager2> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Roy - I'm not aware of any particular incompatibility between TUX and XFS - look at the Red Hat RPMS in the testing/ directory of the xfs ftp site, those have both tux and xfs (although I have not tested tux in those RPMS.) If you don't want to use the RH kernels, perhaps they can give you some hints on solving tux/xfs merge conflicts. -Eric On Tue, 2001-11-13 at 09:01, Roy Sigurd Karlsbakk wrote: > Do you or anyone else have some idea of when the TUX/XFS potch > incompatibility problem will be solved? I need Tux (the in-kernel web > server from RedHat) in this project as well... From owner-linux-xfs@oss.sgi.com Tue Nov 13 07:21:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADFLlv20134 for linux-xfs-outgoing; Tue, 13 Nov 2001 07:21:47 -0800 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADFLg020111 for ; Tue, 13 Nov 2001 07:21:42 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id fADFLZcQ084176; Tue, 13 Nov 2001 16:21:35 +0100 (CET) Message-Id: <4.3.2.7.2.20011113161214.03891678@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Nov 2001 16:19:22 +0100 To: Roy Sigurd Karlsbakk From: Seth Mos Subject: Re: Q: Filesystem block sizes available? Cc: XFS Mailing list In-Reply-To: References: <4.3.2.7.2.20011113154940.037ae900@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:04 13-11-2001 +0100, Roy Sigurd Karlsbakk wrote: > > The fs blocksize has not much to do with the amount it writes in one go. > > XFS uses delayed allocation so it will probably write a lot of data at once > > anyways. > >How about reading? The reading is really essensial here - writing is done >by batch, and can take whatever time it likes (almost :-) That should be even better. I noted Higher read speeds with 2.4.14 -linus but worse write speeds. It sounds like it has what you are looking for. > > If you can give some > >que? Ehm...yes. This was the part where I was about to ask about your hardware availability and setup. But I got interrupted and then sent out the email. (I'm like a goldfish. My short term memory spans about 3 seconds ;-) You said in the other mail that you got 30MB/s. That is not right. I already reach about 70MB/sec on a 6 disk 10K RPM raid 10 on hardware raid. Software raid is even faster then hardware raid most of the time. The newer ami megaraid firmware finally does read balancing on all disks instead of one of the raid set drives. A IDE disk already has 30MB/s sequential read so something is really "in the way". You have the disks on multiple scsi channels over multiple cards which are 64 bit PCI cards ofcourse. :-) What motherboard do you use? 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 Nov 13 07:23:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADFNmO22985 for linux-xfs-outgoing; Tue, 13 Nov 2001 07:23:48 -0800 Received: from mustard.heime.net (mustard.heime.net [194.234.65.222]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADFNj022930 for ; Tue, 13 Nov 2001 07:23:45 -0800 Received: from localhost (roy@localhost) by mustard.heime.net (8.11.2/8.9.3) with ESMTP id fADFNZb01366; Tue, 13 Nov 2001 16:23:35 +0100 Date: Tue, 13 Nov 2001 16:23:35 +0100 (CET) From: Roy Sigurd Karlsbakk X-Sender: To: Eric Sandeen cc: Steve Lord , XFS Mailing list , Tux mailing list Subject: Re: Q: Filesystem block sizes available? In-Reply-To: <1005664789.3186.5.camel@lager2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I'm not aware of any particular incompatibility between TUX and XFS - > look at the Red Hat RPMS in the testing/ directory of the xfs ftp site, > those have both tux and xfs (although I have not tested tux in those > RPMS.) If you don't want to use the RH kernels, perhaps they can give > you some hints